Swebok-v3.pdf

Guía de la Ingeniería de Software de Administración de Conocimiento versión 3.0

SWEBOK

®

Un proyecto del IEEE Computer Society

Guía de la Ingeniería de Software de Administración de Conocimiento versión 3.0

editores Pierre Bourque, Escuela de Tecnología Superior (ETS) Richard E. (Dick) Fairley, Software e Ingeniería de Sistemas Asociados (S2EA)

Derechos de autor y reimpresión Permisos. Se permite el uso personal o educativo de este material sin costes prevista dichas copias 1) No se hacen con fines de lucro o en lugar de la compra de copias para las clases, y que este aviso y una referencia completa a la obra original aparecen en la primera página de la copia y 2) no implican IEEE respaldo de los productos o servicios de terceros . El permiso para reproducir / a publicar este material para fines comerciales, publicidad o con fines promocionales o para la creación de nuevas obras colectivas para la reventa o redistribución debe ser obtenido de IEEE por escrito a la Oficina de Derechos de Propiedad Intelectual IEEE, 445 Hoes Lane, Piscataway, NJ 08854-4.141 [email protected]. La referencia a cualquier producto comercial específico, proceso o servicio no implica reconocimiento alguno por el IEEE. Los puntos de vista y opinio- nes expresadas en esta publicación no reflejan necesariamente las de la IEEE. IEEE pone este documento a disposición “tal cual” y no hace ninguna garantía, expresa o implícita, en cuanto a la exactitud, la du- capaci-, comerciabilidad eficiencia, o el funcionamiento de este documento. En ningún caso, IEEE ser responsable de los daños generales, consecuentes, indirectos, incidentales, ejemplares o especiales, incluso si IEEE ha sido advertido de la posibilidad de tales daños. Copyright © 2014 IEEE. Todos los derechos reservados. Paperback ISBN-10: 0-7695-5166-1 Paperback ISBN-13: 978-0-7695-5166-1 copias digitales de Guía SWEBOK V3.0 se pueden descargar de forma gratuita para uso personal y académico a través www.swebok.org. El personal IEEE Computer Society para esta publicación Angela Burgess, Director Ejecutivo Anne Marie Kelly, Director Ejecutivo Asociado, Director de Gobierno Evan M. Butterfield, Director de Productos y Servicios John Keppler, Gerente Senior de Educación Profesional Kate Guillemette, Producto Editor Desarrollo Dorian McClenahan, Programa de Educación desarrollador del producto Michelle Phon, Educación Profesional y Coordinador del Programa de Certificación Jennie Zhu-Mai, diseñador editorial Productos IEEE Computer Society y Servicios. El IEEE Computer Society de renombre mundial publica, promueve y distribuye los de una amplia variedad de revistas de ciencia e ingeniería equipo autorizado, revistas, actas de congresos y productos de educación profesional. Visite la Sociedad Informática de lawww.computer.org para más información.

TABLA DE CONTENIDO Forewordxvii Prólogo a la Editionxix 2004 Editorsxxi Coeditorsxxi contribuyendo Editorsxxi Cambio de control Boardxxi Área de conocimiento Editorsxxiii Editores Área de Conocimiento de Anterior SWEBOK Versionsxxv revisión Teamxxvii Acknowledgementsxxix Junta actividades profesionales, 2013 Membershipxxix Movimientos respecto a la aprobación de la Guía SWEBOK V3.0xxx Movimientos respecto a la aprobación de la Guía SWEBOK 2004 Versiónxxx Introducción a la Guidexxxi Capítulo 1: Software requisitos 1. Requisitos de software Fundamentals1-1 1.1. Definición de un requisito de software 1.2. Requisitos del producto y de proceso 1.3. Requisitos funcionales y no funcionales 1.4. Propiedades emergentes 1.5. Requisitos cuantificables 1.6. Requisitos del sistema y requisitos de software 2. requisitos Process1-3 2.1. Los modelos de proceso 2.2. Los actores del proceso 2.3. Administración y Apoyo Proceso 2.4. Proceso de Calidad y Mejora 3. requisitos Elicitation1-5 3.1. requisitos Fuentes 3.2. técnicas de obtención 4. requisitos Analysis1-7 4.1. requisitos Clasificación 4.2. Modelado conceptual 4.3. Diseño y requisitos arquitectónicos Asignación 4.4. requisitos de Negociación 4.5. Análisis formal 5. requisitos Specification1-10 5.1. Definición del sistema de documentos 5.2. Requisitos del sistema Especificación 5.3. Especificación de Requerimientos de Software 6. requisitos Validation1-11 6.1. requisitos críticas 6.2. prototipado v

1-1 1-1 1-2 1-3 1-3 1-3 1-3 1-4 1-4 1-4 1-4 1-5 1-6 1-7 1-8 1-9 1-9 1-10 1-10 1-10 1-11 1-11 1-12

6.3. Modelo de validación 6.4. Prueba de aceptacion 7. Considerations1-12 práctica 7.1. La naturaleza iterativa del proceso Requisitos 7.2. Gestión del cambio 7.3. requisitos Atributos 7.4. requisitos de rastreo 7.5. La medición de Requisitos 8. Requisitos de software Tools1-14 Matriz de Temas vs. Referencia Material1-15 Capítulo 2: Software Diseño 1. El software de diseño Fundamentals2-2 1.1. Conceptos generales de diseño 1.2. Contexto de Diseño de Software 1.3. Software de Diseño de Procesos 1.4. Principios de Diseño de Software 2. Aspectos críticos de software Design2-3 2.1. concurrencia 2.2. Control y manejo de Eventos 2.3. Persistencia de datos 2.4. Distribución de Componentes 2.5. Error y control de excepciones y la tolerancia a fallos 2.6. Interacción y Presentación 2.7. Seguridad 3. Estructura del software y Architecture2-4 3.1. Las estructuras arquitectónicas y puntos de vista 3.2. Estilos arquitectónicos 3.3. Patrones de diseño 3.4. Las decisiones Arquitectura Diseño 3.5. Las familias de los programas y marcos 4. Interfaz de usuario Design2-5 4.1. Principios generales para el usuario el diseño de interfaces 4.2. Interfaz de usuario Problemas Diseño 4.3. El diseño de las modalidades de interacción del usuario 4.4. El diseño de la información Presentación 4.5. Proceso de Interfaz de usuario Diseño 4.6. Localización e internacionalización 4.7. Metáforas y modelos conceptuales 5. Diseño Análisis de Calidad de Software y Evaluation2-7 5.1. Los atributos de calidad 5.2. Análisis de calidad y técnicas de evaluación 5.3. medidas 6. El software de diseño Notations2-8 6.1. Las descripciones estructurales (estático Vista) 6.2. Las descripciones de comportamiento (vista dinámica) 7. Software de Diseño y Estrategias Methods2-10 7.1. Las estrategias generales 7.2. Función-Oriented (Estructurado) Diseño 7.3. Diseño Orientado a Objetos

1-12 1-12 1-13 1-13 1-13 1-14 1-14

2-1 2-2 2-2 2-2 2-3 2-4 2-4 2-4 2-4 2-4 2-4 2-4 2-5 2-5 2-5 2-5 2-5 2-6 2-6 2-6 2-6 2-7 2-7 2-7 2-7 2-8 2-8 2-8 2-9 2-10 2-10 2-10

7.4. Estructura de Datos Diseño Centrado 7.5. Diseño basado en componentes (CDB) 7.6. Otros metodos 8. El software de diseño Tools2-11 Matriz de Temas vs. Referencia Material2-12 Capítulo 3: Software Construcción 1. Construcción de Software Fundamentals3-1 1.1. Complejidad minimizando 1.2. pronóstico del cambio 1.3. La construcción de Verificación 1.4. Reutilizar 1.5. Normas de construcción 2. Gerente Construction3-4 2.1. Construcción de Modelos de Ciclo de Vida 2.2. Ordenación de la Edificación 2.3. Medición de la construcción 3. Considerations3-5 práctica 3.1. Diseño de la construcción 3.2. Idiomas de construcción 3.3. Codificación 3.4. Prueba de la construcción 3.5. Construcción de Reutilización 3.6. Construcción con reutilización 3.7. construcción de Calidad 3.8. Integración 4. construcción Technologies3-8 4.1. Diseño y Uso de la API 4.2. Orientado a Objetos Problemas de tiempo de ejecución 4.3. Parametrización y Genéricos 4.4. Afirmaciones, Diseño por contrato, y la programación defensiva 4.5. Control de errores, control de excepciones, y la tolerancia a fallos 4.6. ejecutable modelos 4.7. Las técnicas de construcción basadas en tablas de base estatal y 4.8. Configuración de tiempo de ejecución y la internacionalización 4.9. Procesamiento de la entrada Gramática-Basado 4.10. Las primitivas de concurrencia 4.11. middleware 4.12. Métodos de construcción de software distribuido 4.13. La construcción de sistemas heterogéneos 4.14. Análisis de Rendimiento y ajuste 4.15. Normas de plataforma 4.16. Programación Test-First 5. Construcción de Software Tools3-12 5.1. Entornos de desarrollo 5.2. Constructores GUI 5.3. Herramientas de prueba de unidad 5.4. Perfilado, análisis de rendimiento, y cortar Herramientas Matriz de Temas vs. Referencia Material3-13

Capítulo 4: Software Pruebas

2-10 2-10 2-10

3-1 3-3 3-3 3-3 3-3 3-3 3-4 3-4 3-4 3-5 3-5 3-6 3-6 3-6 3-7 3-7 3-7 3-8 3-8 3-8 3-8 3-9 3-9 3-9 3-10 3-10 3-10 3-10 3-11 3-11 3-11 3-11 3-11 3-12 3-12 3-12 3-12

4-1

1. Software de Pruebas Fundamentals4-3 1.1. Terminología de pruebas relacionados 1.2. Cuestiones clave 1.3. Relación de las pruebas a otras actividades 2. Levels4-5 prueba 2.1. El objetivo de la prueba 2.2. Objetivos de las Pruebas 3. Techniques4-7 prueba 3.1. Sobre la base de la intuición y la experiencia del ingeniero de software 3.2. Las técnicas basadas en el dominio de entrada 3.3. Técnicas de código-base 3.4. Técnicas basada en la culpa 3.5. Técnicas de uso-Basado 3.6. Técnicas de ensayo basado en modelos 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 4. Prueba relacionada Measures4-11 4.1. Evaluación de la prueba el marco del Programa 4.2. La evaluación de las pruebas realizadas 5. Process4-12 prueba 5.1. Consideraciones prácticas 5.2. Prueba Ocupaciones 6. Software de Pruebas Tools4-15 6.1. Pruebas herramienta de soporte 6.2. Categorías de Herramientas Matriz de Temas vs. Referencia Material4-17 Capítulo 5: Software Mantenimiento 1. El software de mantenimiento Fundamentals5-1 1.1. Definiciones y terminología 1.2. Naturaleza de Mantenimiento 1.3. La necesidad de mantenimiento 1.4. La mayoría de los costos de mantenimiento 1.5. Evolución de Software 1.6. Categorías de Mantenimiento 2. Aspectos críticos de software Maintenance5-4 2.1. Técnico Cuestiones 2.2. Asuntos Gerenciales 2.3. Estimación de costes de mantenimiento 2.4. Medición de mantenimiento de software 3. mantenimiento Process5-7 3.1. Los procesos de mantenimiento 3.2. Actividades de mantenimiento 4. Las técnicas para Maintenance5-10 4.1. programa de Comprensión 4.2. reingeniería 4.3. Ingeniería inversa 4.4. Migración 4.5. Jubilación

5. El software de mantenimiento Tools5-11

4-3 4-3 4-4 4-5 4-5 4-8 4-8 4-8 4-9 4-9 4-10 4-10 4-11 4-11 4-12 4-13 4-14 4-15 4-15

5-1 5-1 5-2 5-3 5-3 5-3 5-3 5-4 5-5 5-6 5-7 5-7 5-8 5-10 5-10 5-10 5-10 5-11

Matriz de Temas vs. Referencia Material5-12 Capítulo 6: Software Gestión de la configuración 1. Gestión de la SMC Process6-2 1.1. Contexto de organización de SMC 1.2. Limitaciones y orientación para el proceso SMC 1.3. La planificación de SMC 1.4. plan de SMC 1.5. La vigilancia de la Gestión de la Configuración de Software 2. Configuración del software Identification6-6 2.1. Los productos que la identificación que deben ser controlados 2.2. software Library 3. Configuración del software Control6-8 3.1. Solicitar, evaluar y cambios que aprueba Software 3.2. Cambios en el software de aplicación 3.3. Desviaciones y renuncias 4. Estado de la configuración de software Accounting6-10 4.1. Software de información de estado de configuración 4.2. Informes de estado de configuración de software 5. Configuración del software Auditing6-10 5.1. Software de Auditoría de Configuración Funcional 5.2. Auditoría de Configuración física de software 5.3. En-Proceso de Auditorías de una línea de base del software 6. Gestión de la Entrega de Software y Delivery6-11 6.1. Edificio de software 6.2. Gestión de la Entrega de Software 7. Gestión de la Configuración de Software Tools6-12 Matriz de Temas vs. Referencia Material6-13 Capítulo 7: Software Ingenieria administración 1. Iniciación y Alcance Definition7-4 1.1. La determinación y la negociación de los requisitos 1.2. Análisis de viabilidad 1.3. Proceso para el examen y revisión de los requisitos 2. Proyecto de software Planning7-5 2.1. Planificación de procesos 2.2. determinar entregables 2.3. Esfuerzo, Calendario, y Estimación de Costos 2.4. Asignación de recursos 2.5. Gestión de riesgos 2.6. Gestión de la calidad 2.7. Gestión del plan 3. Proyecto de software Enactment7-7 3.1. Implementación de Planes 3.2. Software de Adquisición y Gestión de Proveedores Contrato 3.3. Implementación de Proceso de medida 3.4. Process monitor 3.5. Control de procesos 3.6. informes

4. Revisión y Evaluation7-8

6-1 6-2 6-3 6-3 6-5 6-5 6-6 6-8 6-8 6-9 6-10 6-10 6-10 6-11 6-11 6-11 6-11 6-12

7-1 7-4 7-4 7-5 7-5 7-5 7-6 7-6 7-6 7-6 7-7 7-7 7-7 7-7 7-7 7-8 7-8

4.1. La determinación de satisfacción de los requisitos 4.2. Revisión y Evaluación del desempeño 5. Closure7-9 5.1. Cierre la determinación 5.2. Actividades de cierre 6. Ingeniería de Software Measurement7-9 6.1. Establecer y mantener el compromiso de Medición 6.2. Planificar el proceso de medición 6.3. Realizar el proceso de medición 6.4. evaluar Medición 7. Ingeniería de Software de Gestión Tools7-11 Matriz de Temas vs. Referencia Material7-13 Capítulo 8: Software Ingenieria Proceso 1. procesos de software Definition8-2 1.1. Gestión de procesos de software 1.2. Infraestructura de Procesos de Software 2. Software vida Cycles8-4 2.1. Categorías de procesos de software 2.2. Modelos de Ciclo de vida del software 2.3. La adaptación de procesos de software 2.4. Consideraciones prácticas 3. Proceso de Evaluación y software Improvement8-6 3.1. Modelos de evaluación de procesos de software 3.2. Proceso de Software Métodos de evaluación 3.3. Modelos de mejora de procesos de software 3.4. Software puntuaciones proceso continuo y puesta en escena 4. software Measurement8-8 4.1. Proceso de Software y Medición del producto 4.2. Calidad de los resultados de medición 4.3. Información de software Modelos 4.4. Técnicas de medición de procesos de software 5. Proceso de Ingeniería de Software Tools8-12 Matriz de Temas vs. Referencia Material8-13 Capítulo 9: Software Modelos de ingeniería y métodos 1. Modeling9-1 1.1. Principios de modelado 1.2. Propiedades y Expresión de Modelos 1.3. Sintaxis, la semántica y la pragmática 1.4. Condiciones previas, postConditions, e invariantes 2. Tipos de Models9-4 2.1. Modelado de información 2.2. Modelado del comportamiento 2.3. Modelado estructura 3. Análisis de Models9-5 3.1. Para completar el análisis 3.2. La consistencia para analizar

3.3. El análisis de la corrección 3.4. trazabilidad

7-8 7-9 7-9 7-9 7-9 7-10 7-11 7-11

8-1 8-3 8-4 8-5 8-5 8-6 8-6 8-7 8-7 8-7 8-8 8-9 8-10 8-10 8-11

9-1 9-2 9-3 9-3 9-4 9-5 9-5 9-5 9-5 9-6

9-6 9-6

3.5. Análisis de interacción 4. Ingeniería de Software Methods9-7 4.1. Los métodos heurísticos 4.2. Métodos formales 4.3. Los métodos de prototipado 4.4. Los métodos ágiles Matriz de Temas vs. Referencia Material9-10 Capítulo 10: Software Quality10-1 1. Software de calidad Fundamentals10-2 1.1. Software de Ingeniería de la Cultura y Ética 1.2. Valor y los costos de Calidad 1.3. Modelos y características de calidad 1.4. Mejora de la Calidad de Software 1.5. software de Seguridad 2. Software de Gestión de Calidad Processes10-5 2.1. Calidad de Software 2.2. Verificación validación 2.3. Revisiones y auditorías 3. Considerations10-9 práctica 3.1. Requisitos de calidad de software 3.2. Caracterización de defectos 3.3. Técnicas de gestión de calidad de software 3.4. Medición de la Calidad de Software 4. Software de calidad Tools10-12 Matriz de Temas vs. Referencia Material10-14 Capítulo 11: Software profesional de la ingeniería Práctica 1. Professionalism11-2 1.1. Acreditación, Certificación y Licencias 1.2. Códigos de Ética y Conducta Profesional 1.3. La naturaleza y la función de las Sociedades Profesionales 1.4. La naturaleza y la función de las normas de ingeniería de software 1.5. Impacto económico de Software 1.6. Contratos de trabajo 1.7. Asuntos legales 1.8. Documentación 1.9. Análisis compensación 2. Dinámica de Grupos y Psychology11-9 2.1. Dinámica de trabajo en equipos / grupos 2.2. cognición individual 2.3. Tratar con el problema Complejidad 2.4. La interacción con las partes interesadas 2.5. Superación de la incertidumbre y la ambigüedad 2.6. Tratar con entornos multiculturales 3. comunicación Skills11-11 3.1. Leer, comprender y resumir

3.2. Escritura 3.3. Equipo y Comunicación Grupo 3.4. Habilidades de presentación

9-6 9-7 9-7 9-8 9-9

10-2 10-3 10-3 10-4 10-4 10-5 10-6 10-6 10-9 10-10 10-11 10-12

11-1 11-3 11-4 11-4 11-4 11-5 11-5 11-5 11-7 11-8 11-9 11-9 11-10 11-10 11-10 11-10 11-11

11-11 11-11 11-12

Matriz de Temas vs. Referencia Material11-13 Capítulo 12: Software Ingenieria Economics12-1 1. Ingeniería de Software Economía Fundamentals12-3 1.1. Financiar 1.2. Contabilidad 1.3. Controlador 1.4. Flujo de fondos 1.5. Proceso de toma de decisiones 1.6. Valuación 1.7. Inflación 1.8. Depreciación 1.9. Impuestos 1.10. Valor del tiempo de dinero 1.11. Eficiencia 1.12. Eficacia 1.13. Productividad 2. Ciclo de Vida Economics12-7 2.1. Producto 2.2. Proyecto 2.3. Programa 2.4. portafolio 2.5. Ciclo de vida del producto 2.6. Ciclo de Vida del Proyecto 2.7. propuestas 2.8. Decisiones de inversión 2.9. Planeando el horizonte 2.10. Precio y precios 2.11. Costo y costeo 2.12. Medición del desempeño 2.13. Gestion del valor ganado 2.14. Las decisiones de terminación 2.15. Las decisiones de reemplazo y jubilación 3. Riesgo y Uncertainty12-10 3.1. Metas, estimaciones, y Planes 3.2. Las técnicas de estimación 3.3. La incertidumbre abordar 3.4. priorización 3.5. Las decisiones en riesgo 3.6. Las decisiones bajo incertidumbre 4. Análisis económico Methods12-12 4.1. Con fines de lucro Análisis de Decisiones 4.2. Tasa de retorno mínima aceptable 4.3. Retorno de la Inversión 4.4. Rendimiento del capital invertido 4.5. Análisis coste-beneficio

4.6. Análisis coste-efectividad 4.7. Punto de equilibrio de analisis 4.8. Business Case 4.9. Evaluación Atributo múltiple

12-3 12-3 12-3 12-3 12-4 12-5 12-6 12-6 12-6 12-6 12-6 12-6 12-6 12-7 12-7 12-7 12-7 12-7 12-7 12-8 12-8 12-8 12-8 12-9 12-9 12-9 12-9 12-10 12-10 12-11 12-11 12-11 12-11 12-12 12-12 12-13 12-13 12-13 12-13

12-13 12-13 12-13 12-14

4.10. Análisis de optimización 5. Considerations12-14 práctica 5.1. El “suficientemente bueno” Principio 5.2. Economía-Friction Free 5.3. ecosistemas 5.4. La deslocalización y la externalización Matriz de Temas vs. Referencia Material12-16 Capítulo 13: Informática Foundations13-1 1. Resolución de Problemas Techniques13-3 1.1. Definición de la resolución de problemas 1.2. Formular el problema real 1.3. Analizar el problema 1.4. Diseñar una estrategia de búsqueda de soluciones 1.5. La resolución de problemas Utilización de programas 2. Abstraction13-4 2.1. Los niveles de abstracción 2.2. La encapsulación 2.3. Jerarquía 2.4. Las abstracciones alternativos 3. programación Fundamentals13-5 3.1. El proceso de programación 3.2. Los paradigmas de programación 4. Lenguaje de Programación Basics13-6 4.1. Lenguaje de Programación general 4.2. Sintaxis y semántica de lenguajes de programación 4.3. Bajo Programación y Lenguajes 4.4. -Programación y Lenguajes 4.5. vs. declarativa de programación imperativo Idiomas 5. Herramientas de depuración y Techniques13-8 5.1. tipos de errores 5.2. Las técnicas de depuración 5.3. Herramientas de depuración 6. Estructura de datos y Representation13-9 6.1. Presentación de la estructura de datos 6.2. tipos de Estructura de Datos 6.3. Las operaciones en Estructuras de Datos 7. Algoritmos y Complexity13-10 7.1. Descripción general de Algoritmos 7.2. Atributos de Algoritmos 7.3. Análisis algorítmico 7.4. Estrategias de diseño algorítmico 7.5. Estrategias de análisis algorítmico 8. Concepto básico de un System13-11 8.1. Propiedades del sistema emergente

8.2. Ingeniería de Sistemas 8.3. Visión general de un sistema informático 9. Organization13-13 equipo 9.1. Organización general del ordenador 9.2. Sistemas digitales

12-14 12-14 12-15 12-15 12-15

13-3 13-3 13-3 13-3 13-3 13-4 13-4 13-4 13-5 13-5 13-5 13-6 13-6 13-7 13-7 13-7 13-8 13-8 13-8 13-9 13-9 13-9 13-10 13-10 13-10 13-11 13-11 13-11

13-12 13-12 13-13 13-13

9.3. lógica digital 9.4. Expresión de datos del ordenador 9.5. La Unidad Central de Procesamiento (CPU) 9.6. Organización del Sistema de memoria 9.7. Entrada y salida (I / O) 10. compilador Basics13-15 10.1. Compilador / intérprete general 10.2. Interpretación y compilación 10.3. El proceso de compilación 11. Sistemas operativos Basics13-16 11.1. Operativo general Sistemas 11.2. Tareas de un sistema operativo 11.3. Las abstracciones del sistema operativo 11.4. Sistemas para realizar la clasificación 12. Fundamentos de bases de datos y los datos Management13-17 12.1. Entidad y de esquema 12.2. Sistemas de Gestión de Bases de Datos (DBMS) 12.3. Lenguaje de consulta de base de datos 12.4. Tareas Los paquetes de DBMS 12.5. Gestión de datos 12.6. La minería de datos 13. Red de Comunicación Basics13-19 13.1. tipos de la Red 13.2. Componentes de la Red Básica 13.3. Protocolos de red y Estándares 13.4. La Internet 13.5. Internet de las Cosas 13.6. Virtual Private Network (VPN) 14. Computing13-21 Paralela y Distribuida 14.1. Computación paralela y distribuida general 14.2. Diferencia entre Computación Paralela y Distribuida 14.3. Modelos de Computación Paralela y Distribuida 14.4. Problemas principales en Distributed Computing 15. Usuario básico Factors13-22 Humano 15.1. Entrada y salida 15.2. Error de mensajes 15.3. La robustez del software 16. Desarrollador básica Factors13-23 Humano 16.1. Estructura 16.2. comentarios 17. Asegurar el desarrollo de software y Maintenance13-24 17.1. Requisitos de software de seguridad 17.2. Diseño de Software de Seguridad 17.3. El software de seguridad de construcción 17.4. El software de seguridad de Pruebas

13-13 13-13 13-14 13-14 13-14

17.5. Construir Seguridad en Ingeniería de Procesos de Software 17.6. Guía de seguridad de software Matriz de Temas vs. Referencia Material13-27

13-25 13-25

Capítulo 14: Matemático Foundations14-1

13-15 13-15 13-15 13-16 13-16 13-17 13-17 13-18 13-18 13-18 13-18 13-19 13-19 13-19 13-19 13-20 13-20 13-20 13-21 13-21 13-21 13-21 13-22 13-22 13-23 13-23 13-24 13-24 13-24 13-25 13-25 13-25

1. Conjunto, Relaciones, Functions14-1 1.1. las operaciones Set 1.2. Propiedades del Conjunto 1.3. Relación y función 2. básico Logic14-5 2.1. Lógica proposicional 2.2. La lógica de predicados 3. Techniques14-6 prueba 3.1. Métodos de demostración de teoremas 4. Fundamentos de la Counting14-7 5. Los gráficos y Trees14-8 5.1. Los gráficos 5.2. árboles 6. discreta Probability14-13 7. Finita Machines14-14 Estado 8. Grammars14-15 8.1. Reconocimiento idioma 9. Numérica de precisión, exactitud y Errors14-17 10. número Theory14-18 10.1. Divisibilidad 10.2. Número primo, GCD 11. algebraica Structures14-19 11.1. Grupo 11.2. anillos Matriz de Temas vs. Referencia Material14-21 Capítulo 15: Ingenieria Foundations15-1 1. Métodos empíricos y Experimental Techniques15-1 1.1. experimento diseñado 1.2. Estudio observacional 1.3. Estudio retrospectivo 2. Análisis estadístico 2.1. Unidad de análisis (unidades de muestreo), Población y Muestra 2.2. Conceptos de correlación y regresión 3. Measurement15-5 3.1. Niveles (Scales) de Medición 3.2. Medidas directos y derivados 3.3. Fiabilidad y Validez 3.4. Fiabilidad evaluar 4. ingeniería Design15-8 4.1. Diseño de ingeniería en la Educación en Ingeniería 4.2. El diseño como Solución de problemas Actividad 4.3. Pasos a seguir en Diseño de Ingeniería 5. Modelado, Simulación y Prototyping15-10 5.1. Modelado

5.2. Simulación 5.3. prototipado 6. Standards15-12 7. Causa Raíz Analysis15-12 7.1. Las técnicas para la realización de análisis de causa raíz

14-2 14-3 14-4 14-5 14-5 14-6

14-8 14-10

14-16

14-18 14-19 14-19 14-20

15-1 15-2 15-2 15-2 15-2 15-5 15-6 15-7 15-8 15-8 15-8 15-9 15-9 15-10

15-11 15-11

15-13

Matriz de Temas vs. Referencia Material15-14 Apéndice A: Área de Conocimiento Descripción Presupuesto

A-1

Apéndice B: IEEE e ISO / IEC Apoyo a la Ingeniería de Software Cuerpo de conocimientos (SWEBOK)

B-1

Apéndice DO: Referencia consolidada Lista

C-1

PREFACIO Cada profesión se basa en un conjunto de conocimientos, a pesar de que el conocimiento no siempre se define de una manera concisa. En los casos en que no existe ninguna formalidad, el cuerpo de conocimiento se “GEN-ralmente reconocido” por los médicos y puede ser codificado en una variedad de formas para una variedad de usos diferentes. Pero en muchos casos, una guía para un cuerpo de conocimiento se documenta formalmente, el aliado no baja en una forma que permite que sea utilizado para fines tales como el desarrollo y la acreditación de programas académicos y de capacitación, certificación de especialistas, o licencia profesional. En general, una asociación profesional u organismo similar mantiene la administración de la definición formal de un conjunto de conocimientos. Durante los últimos cuarenta y cinco años, la ingeniería de software ha evolucionado a partir de una frase conferencia Catch en una profesión de la ingeniería, caracteriza- da por la 1) una sociedad profesional, 2) las normas que especifican las prácticas profesionales generalmente aceptadas; 3) un código de ética, 4) actas de la conferencia, 5) libros de texto, 6) directrices del plan de estudios y planes de estudio, 7) los criterios de acreditación y programas de grado acreditados, 8) la certificación y concesión de licencias, y 9) de esta guía al cuerpo de conocimientos. En esta Guía para la Ingeniería de Software de Administración de Conocimiento, las constituye IEEE Computer Society una versión revisada y del conjunto de conocimientos anteriormente documentado como SWEBOK 2004 actualizado; esta versión revisada y actualizada se denota SWEBOK V3. Este trabajo está en cumplimiento parcial de la responsabilidad de la sociedad para promover el avance de la teoría y la práctica de la profesión de la ingeniería de software. Cabe señalar que esta Guía no presenta la totalidad del cuerpo de conocimientos de ingeniería de soft- ware, sino que sirve como guía para el conjunto de conocimientos que se ha desarrollado durante más de cuatro décadas.

El software de inge- niería cuerpo de conocimientos está constantemente en evolución ing. Sin embargo, esta guía constituye una caracterización valioso poder de la profesión de la ingeniería de software.

En 1958, John Tukey, la istician stat- de renombre mundial, acuñó el término software. La ingeniería de software término fue utilizado en el título de una conferencia de la OTAN celebrada en Alemania en 1968. El IEEE Computer Society publicó por primera vez sus Transacciones de Ingeniería de Software en 1972, y se estableció un tee de compromiso para el desarrollo de Dardos de ingeniería de software dentro de Están- la IEEE Computer Society en 1976. En 1990, se inició la planificación para una norma interna- cional para proporcionar una visión global de ingeniería de soft- ware. La norma se completó en 1995 con la designación de la norma ISO / IEC 12207 y se le dio el título de software estándar para cesos del Ciclo de Vida Pro-. La versión de IEEE 12207 fue publicada en 1996 y proporcionó una base importante para el conjunto de conocimientos

capturado en SWEBOK 2004. La versión actual de 12207 se designa como ISO / IEC 12207: 2008 e IEEE 12.207 a 2.008; eso proporciona la base para este V3 SWEBOK. Esta guía para la Ingeniería de Software de Administración de Conocimiento se presenta a usted, el lector, como un mecanismo para adquirir los conocimientos que necesita en su desarrollo de carrera de toda la vida como un profesional de la ingeniería de software.

Dick Fairley, Presidente Software y Comité de Ingeniería de Sistemas IEEE Computer Society

Don Shafer, vicepresidente Actividades profesionales Junta IEEE Computer Society

xvii

Prólogo a la edición de 2004 En esta guía, lishes la IEEE Computer Society esta- por primera vez una línea de base para el conjunto de conocimientos para el campo de la ingeniería de software, y el trabajo cumple parcialmente la responsabilidad de la sociedad para promover el avance de la teoría y la práctica en esta campo. De este modo, la Sociedad se ha guiado por la experiencia de disciplinas con historias más largas, pero no estaba vinculado por sus problemas o sus soluciones. Cabe señalar que la Guía no PUR puerto para definir el conjunto de conocimientos, sino más bien para servir como un compendio y guías para el conjunto de conocimientos que se ha venido desarrollando y en evolución ing en las últimas cuatro décadas. Por otra parte, este conjunto de conocimientos no es estática. La guía debe, necesariamente, desarrollar y evolucionar a medida que madura la ingeniería de software. Sin embargo, constituye un elemento valioso de la ingeniería del software infraestructura. En 1958, John Tukey, la istician stat- de renombre mundial, acuñó el término software. La ingeniería de software término fue utilizado en el título de una conferencia de la OTAN celebrada en Alemania en 1968. El IEEE Computer Society publicó por primera vez sus Transacciones de Ingeniería de Software en 1972. El comité establecido en la IEEE Computer Society para el desarrollo de estándares de ingeniería de software fue fundada en 1976. La primera visión integral de ingeniería de software para salir de la IEEE Computer Society fue resultado de un esfuerzo dirigido por Fletcher Buckley para desarrollar el estándar IEEE 730 para el software de cali- dad de aseguramiento, que se completó en 1979. El propósito de la norma IEEE Std. 730 era proporcionar uniformes, requisitos mínimos aceptables para la preparación y el contenido de los planes de ANCE assur- de calidad de software. Esta norma fue influyente en completar las normas de desarrollo de los siguientes temas: gestión de configuración, software de

Exámenes, requisitos de software, diseño de software, y la verificación y validación de software. Durante el periodo 1981-1985, la Sociedad IEEE putadora Com- llevó a cabo una serie de talleres con- cerning la aplicación de la ingeniería de software

denomina- ción, ISO / IEC 12207, y se le dio el título de Stan- dard para los procesos de ciclo de vida del software. Std. ISO / IEC 12207 proporciona un importante punto de partida para el conjunto de conocimientos capturados en este libro. Era la Junta IEEE Computer Society de Gobernadores la aprobación de la moción presentada en mayo de 1993 mediante Fletcher Buckley, que dio lugar a la redacción de este libro. La Association for Computing Machinery Consejo (ACM) aprobó una moción relacionada en agosto de 1993. Los dos movimientos condujeron a un comité conjunto bajo la dirección de Mario Barbacci y Stuart Zweben que sirvió como copresidentes. La declaración de la misión de la comisión conjunta era “Establecer los conjuntos apropiados (s) de criterios y normas para la práctica profesional de la ingeniería de software sobre el cual siones industriales terio, la certificación profesional, y los programas de estudio se pueden basar.” El comité directivo grupos de trabajo organizados en las siguientes áreas:

normas. Estos talleres involucrados ners practitio- compartiendo sus experiencias con los Standards existentes. Los talleres también se llevaron a cabo sesiones sobre la Planificación de las normas futuras, incluyendo uno que incluya las medidas y métricas para la ingeniería de software de productos y procesos. La planificación también resultó en IEEE Std. 1002, Taxonomía de Estándares de Ingeniería de Software (1986), que proporcionó una nueva visión holística de la ingeniería de software. La norma describe la forma y el contenido de las normas de ingeniería de un soft- ware taxonomía. Se explican los diferentes tipos de Dardos de ingeniería de software Están-, sus relaciones funcionales y externos, y el papel de las diversas funciones que participan en el ciclo de vida del software. En 1990, se inició la planificación para un Dard Están- internacional con una visión de conjunto. El la Planificación centrada sobre la conciliación de los puntos de vista del proceso de software de IEEE Std. 1074 y la norma revisada 2167A de EE.UU. Departamento de Defensa. La revisión fue publicada como aliado eventu- DoD Std. 498. La norma internacional se completó en 1995 con la

1. Definir Obligatorio cuerpo de conocimientos y Prácticas recomendadas. xix

Guía xx SWEBOK® V3.0

2. Definir Ética y Estándares Profesionales. 3. Definir planes de estudio para la Educación univercomió, graduado, y la educación continua. Este libro suministra el primer componente: requerida Conjunto de conocimientos y recomendar prácticas. El código de ética y práctica profesional de la ingeniería de software se 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. El plan de estudios para los estudiantes está siendo completada por un esfuerzo conjunto de la IEEE Computer Society y de la ACM y se espera que esté terminado en 2004. Cada profesión se basa en un cuerpo de El conocimiento y las prácticas recomendadas, a pesar de que no siempre se definen de una manera precisa. En muchos casos, éstos se documentan formalmente, el aliado no baja en una forma que les permite ser 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.

Se espera que los lectores encontrarán en este libro uso-ful para guiarlos hacia el conocimiento y los recursos que necesitan en su carrera de por vida desa- rrollo como profesionales de ingeniería de software. El libro está dedicado a Fletcher Buckley en reconocimiento a su compromiso con la promoción de la ingeniería de software como una disciplina profesional y su excelencia como Tioner una ingeniería de software prác- en aplicaciones de radar.

Leonard L. Tripp, Fellow de IEEE 2003 Presidente del Comité de Prácticas Profesionales, IEEE Computer Society (2001-2003) Presidente del Comité Directivo Conjunto IEEE Computer Society y ACM para el Establecimiento de Ingeniería de Software como una Profesión (19981999) Presidente del Comité de Estándares de Ingeniería de Software, IEEE Computer Society (1992-1998)

EDITORES Pierre Bourque, Departamento de Ingeniería de Software y TI, Escuela de Tecnología Superior (ETS), Canadá, [email protected] Richard E. (Dick) Fairley, Software e Ingeniería de Sistemas Asociados (S2EA), EE.UU., [email protected]

coeditores Alain Abran, Departamento de Ingeniería de Software y TI, Escuela de Tecnología Superior (ETS), Canadá, [email protected] Juan Garbajosa, Universidad Politécnica de Madrid (Universidad Politécnica de Madrid, UPM), España, [email protected] Gargi Keeni, Tata Consultancy Services, la India, [email protected] Beijun Shen, Escuela de software, Shanghai Jiao Tong Universidad, China, [email protected]

editores colaboradores Las siguientes personas contribuyeron a la edición de la Guía de SWEBOK V3: Don Shafer Linda Shafer Mary Jane Willshire Kate Guillemette

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

xxi

EDITORES área de conocimiento Requisitos de Software Gerald Kotonya, Facultad de Informática y Comunicaciones, Universidad de Lancaster, Reino Unido, [email protected] Peter Sawyer, Facultad de Informática y Comunicaciones, Universidad de Lancaster, Reino Unido, [email protected]

Diseño de software Yanchun Sol, Facultad de Ingeniería Electrónica e Informática, Universidad de Pekín, China, [email protected]

Construcción de software Xin Peng, Escuela de Software de la Universidad de Fudan, China, [email protected]

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

Mantenimiento del software Alain abril de Escuela de Tecnología Superior (ETS), Canadá, [email protected] Mira Kajko-Mattsson, Escuela de Tecnología de Información y Comunicación, KTH Royal Institute of Technology, [email protected]

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á, [email protected]

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., [email protected]

Proceso de Ingeniería de Software Annette Reilly, Sistemas de Información y Lockheed Martin Global Solutions, EE.UU., [email protected] Richard E. Fairley, Software e Ingeniería de Sistemas Asociados (S2EA), EE.UU., [email protected]

Modelos de Ingeniería de Software y Métodos Michael F. Siok, Lockheed Martin Aeronáutica Company, EE.UU., [email protected]

Calidad del software J. David Blaine, EE.UU., [email protected] Durba Biswas, Tata Consultancy Services, la India, [email protected]

Guía xxiv SWEBOK® V3.0

xxiii

Ingeniería de Software Práctica Profesional

EDITORES área de conocimiento

Aura Sheffield, EE.UU., [email protected] Hengming Zou, Shanghai Jiao Tong Universidad, China, [email protected]

Economía Ingeniería de Software Christof Ebert, Servicios Consulting vectorial, Alemania, [email protected]

Fundamentos de computación Hengming Zou, Shanghai Jiao Tong Universidad, China, [email protected]

Fundamentos matemáticos Nabendu Chaki, Universidad de Calcuta, India, [email protected]

Fundamentos de ingeniería Amitava Bandyopadhayay, Instituto de Estadística de la India, la India, [email protected] Mary Jane Willshire, Software e Ingeniería de Sistemas Asociados (S2EA), EE.UU., [email protected]

Apéndice B: IEEE y normas ISO / IEC SWEBOK Apoyando James W. Moore, EE.UU., [email protected]

Guía xxiv SWEBOK® V3.0

DE VERSIONES SWEBOK ANTERIORES Las siguientes personas sirvieron como editores asociados, ya sea para la versión de prueba publicados en 2001, o la versión 2004.

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

Gestión de la Configuración de Software John A. Scott, Laboratorio Nacional Lawrence Livermore, EE.UU. David Nisse, EE.UU.

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

EDITORES área de conocimiento xxv

Guía xxiv 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 figuran a continuación participaron en el proceso de revisión pública de la Guía SWEBOK V3. La membresía de la IEEE Computer Society no era un requisito para participar en este proceso de revisión, y la información de pertenencia no se ha solicitado a los colaboradores. Más de 1.500 comentarios individuales se recogieron y debidamente adjudicadas.

Carlos C. Amaro, EE.UU. Mark Ardis, EE.UU. Mora-Soto Arturo, España Ohad Barzilay, Israel Gianni Basaglia, Italia Denis J. Bergquist, EE.UU. Alexander Bogush, Reino Unido Christopher Bohn, EE.UU. Steve Bollweg, EE.UU. Reto Bonderer, Suiza Alexei Botchkarev, Canadá Pieter Botman, Canadá Robert Bragner, EE.UU. Kevin Brune, EE.UU. Ogihara Bryan, EE.UU. Luigi Buglione, Italia Rick Cagle, EE.UU. Barbara Canody, EE.UU. Rogerio A. Carvalho, Brasil Daniel Cerys, EE.UU. Philippe Cohard, Francia Ricardo Colomo-Palacios, Mauricio Coria España, Argentina Marek Cruz, Reino Unido Stephen Danckert, EE.UU. Bipul K. Das, Canadá James D. Davidson, EE.UU. Jon Dehn, EE.UU. Lincoln P. Djang, EE.UU. Andreas Doblander, Austria Yi-Ben Doo, EE.UU. Scott J. Dougherty, Reino Unido Regina DuBord, EE.UU. Fedor Dzerzhinskiy, Rusia Ann

M. Eblen, Australia David M. Endres, EE.UU. Marilyn Escue, EE.UU. Varuna Eswer, India

Guía xxiv SWEBOK® V3.0

EE.UU. Bob Hillier, Canadá Norman M. Hines, EE.UU. Dave Hirst, EE.UU. Theresa L. Hunt, EE.UU. Kenneth Ingham, EE.UU. Masahiko Ishikawa, Japón Michael A. Jablonski, EE.UU. 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.

Istvan Fay, Hungría José L. FernándezSánchez, Dennis J. España Frailey, EE.UU. Tihana Galinac Grbac, Croacia Colin Garlick, Nueva Zelanda Garth JG Glynn, Reino Unido Jill Gostin, EE.UU. Christiane von Gresse Wangenheim, Brasil Thomas Gust, EE.UU. HN Mok, Singapu r Jon D. Hagar, EE.UU. Anees Ahmed Haidary, India Duncan Hall, Nueva Zelanda James Hart, EE.UU. Jens HJ Heidrich, Alemania Rich Hilliard, xxvii

Stephen P. Masticola, EE.UU. Nancy Mead, EE.UU. Fuensanta Medina-Domínguez, España Silvia Judith Meles, Argentina Oscar A. Mondragon, México David W. Mutschler, EE.UU. Maria Nelson, Brasil John Noblin, EE.UU. Bryan G. Ogihara, EE.UU. Takehisa Okazaki, Japón Hanna Oktaba, México Chin Hwee Ong, Hong Kong Venkateswar Oruganti, India Birgit Penzenstadler, Alemania Larry Peters, EE.UU. SK Pillai, India Vaclav Rajlich, EE.UU. Kiron Rao, India Luis Reyes, EE.UU. Hassan Reza, EE.UU. Steve Roach, EE.UU. Teresa L. Roberts, EE.UU. Dennis Robi, EE.UU. Warren E. Robinson, EE.UU. Jorge L. Rodriguez, EE.UU. Alberto C. Sampaio, Portugal Ed Samuels, EE.UU. María Isabel Sánchez-Segura, España Vineet Sawant, EE.UU. R. Schaaf, EE.UU. James C. Schatzman, EE.UU. Oscar A. Schivo, Argentina Florian Schneider, Alemania

Thom Schoeffling, EE.UU. Reinhard Schrage, Alemania Neetu Sethia, India Cindy C. Shelton, EE.UU. Alan Shepherd, Alemania Katsutoshi Shintani, Japón Erik Shreve, EE.UU. Jaguaraci Silva, Brasil M. Somasundaram, India Peraphon Sophatsathit, Tailandia John Standen, Reino Unido Joyce Statz, EE.UU. Perdita P. Stevens, David Struble Reino Unido, EE.UU. Ohno Susumu, Japón Urcun Tanik, EE.UU. Talin Tasciyan, EE.UU. J. Barrie Thompson, Reino Unido Steve Tockey, EE.UU. Miguel Eduardo Torres Moreno, Colombia Dawid Trawczynski, EE.UU. Adam Trendowicz, Alemania Norio Ueno, Japón Cenk Uyan, Turquía Chandra Sekar Virappan, Singapur Oruganti Venkateswar, India Jochen Vogt, Alemania Hironori Washizaki, Japón Ulf Westermann, Alemania Don Wilson, EE.UU. Aharon Yadin, Israel Hong Zhou, Reino Unido

Guía XXVIII SWEBOK® V3.0

EXPRESIONES DE GRATITUD Los fondos para el desarrollo de la Guía SWEBOK V3 ha sido proporcionada por la IEEE Computer Society. Los editores y coeditores aprecian el importante trabajo realizado por los editores Ka y los editores colaboradores, así como por los de los miembros de la Junta de Control de Cambios. El equipo editorial también debe reconocer la contribución indispensable de los colaboradores. El equipo de redacción desea también agradecer a las personas siguien- tes que han contribuido al proyecto en

diversas maneras: Pieter Botman, Evan Butterfield, Carine Chauny, Pierce Gibbs, Diane Girard, John Keppler, Dorian McClenahan, Kenza Meridji, Sam-uel Redwine, Annette Reilly, y Pam Thompson. Finalmente, seguramente hay otras personas que han contribuido a esta guía, ya sea directa o indirectamente, cuyos nombres tenemos inadvertidamente omitido. Para esas personas, ofrecemos nuestra apre- ciación tácito y disculpas por haber omitido el reconocimiento explícito.

PRESIDENTES IEEE Computer Society Dejan Milojicic, 2014 Presidente David Alan Grier, 2013 presidente Thomas Conte, 2015 Presidente

PROFESIONAL actividades a bordo, 2013 MIEMBROS Donald F. Shafer, Presidente Pieter Botman, PCSD Pierre Bourque Richard Fairley, PCSD Dennis Frailey S. Michael Gayle Phillip Laplante, PCSD Jim Moore, PCSD Linda Shafer, Steve PCSD Tockey, PCSD Charlene “Chuck” Walrad

xxix

Guía xxx SWEBOK® V3.0

MOTIONS sobre la aprobación de SWEBOK V3.0 GUÍA La Guía SWEBOK V3.0 fue sometida a votación por los miembros del IEEE Computer Society verificados en noviembre de 2013, con la siguiente pregunta: “¿aprueba usted el manuscrito de la Guía SWEBOK V3.0 para avanzar al formato y la publicación” Los resultados de esta votación había 259 Sí votos y 5 Sin votos. La siguiente moción fue aprobada por unanimidad por la Junta de Actividades Profesionales de la Sociedad IEEE Com- puter en diciembre de 2013:

La Junta de Actividades Profesionales de la IEEE Computer Society considera que el Guía para la Cesión de Software Ingeniería Cuerpo de Conocimiento Versión 3.0 se ha completado con éxito; y hace suya la Guía de la Ingeniería de Software de Administración de Conocimiento versión 3.0 y lo recomienda a la Junta IEEE Computer Society de Gobernadores para su aprobación. La siguiente moción fue aprobada por la Junta IEEE Computer Society de Gobernadores en diciembre de 2013:

Movido, que la Junta de Gobernadores de la IEEE Computer Society aprueba la versión 3.0 de la Guía de la Ingeniería de Software de Administración de Conocimiento y autoriza al Presidente de la Junta sionales Actividades Profe- para continuar con la impresión.

MOCIONES sobre la aprobación de SWEBOK GUÍA 2004 VERSIÓN La siguiente moción fue aprobada por unanimidad por el Consejo Asesor Industrial de la Guía SWEBOK proyecto en febrero de 2004:

El Consejo Asesor Industrial encuentra que la ingeniería del cuerpo software de proyecto Conocimiento ini- ciada en 1998 se ha completado con éxito; y hace suya la versión del 2004Guía de la SWEBOK y lo recomienda a la Junta IEEE Computer Society de Gobernadores para su aprobación. La siguiente moción fue aprobada por la Junta IEEE Computer Society de Gobernadores en febrero de 2004:

Movido, que la Junta de Gobernadores de la IEEE Computer Society aprueba la edición de 2004 de la Guía de la Ingeniería de Software de Administración de Conocimiento y autoriza al Presidente del Comité de Prácticas pro- fesional para continuar con la impresión. Tenga en cuenta también que la edición de la Guía de la Ingeniería de Software de Administración de Conocimiento 2004 fue presentado por el IEEE Computer Society con la norma ISO / IEC sin ningún cambio y fue reconocido como el informe técnico ISO / IEC TR 19759: 2005.

INTRODUCCIÓN A LA GUÍA KA

Área de conocimiento

La Guía no debe confundirse con el Cuerpo de Conocimiento mismo, que existe en la publicación

SWEBOK

Software Cuerpo de Ingeniería del Conocimiento

1

Publicación de la versión de esta Guía a la Ingeniería de Software de Administración de Conocimiento (BOK SWE- 2004) 2004 fue un hito importante en el establecimiento de la ingeniería de software como una disciplina de ingeniería reconocida. El objetivo en el desarrollo de esta actualización para SWEBOK es mejorar la moneda, la legibilidad, consistencia y facilidad de uso de la Guía. Todas las áreas de conocimiento (KAS) se han actualizado para reflejar los cambios en la ingeniería de software desde la publicación de SWEBOK 2004. Cuatro nuevos dación FunKAs y una Ingeniería de Software Prácticas Profe- sional KA se han añadido. Las herramientas de ingeniería de software y métodos KA ha sido revisada como modelos y métodos de ingeniería de software. herramientas de ingeniería de software es ahora un tema en cada una de la KAS. Tres apéndices proporcionar las especificaciones para la descripción KA, un conjunto anotada de normas pertinentes para cada KA, y una lista de las referencias citadas en la Guía. Esta guía, escrita bajo los auspicios de la Junta de Actividades Profesionales de la Sociedad IEEE Com- puter, representa un siguiente paso en la evoción de la profesión de la ingeniería de software. Qué es la ingeniería de software? ISO / IEC / IEEE Sistemas y de Ingeniería de Software de vocabulario (SEVOCAB) define las soluciones de inge- niería como “la aplicación de una disci- plined, enfoque sistemático y cuantificable al desarrollo, operación y mantenimiento de software; es decir, la aplicación de la ingeniería de software).”1 ¿QUÉ SON LOS OBJETIVOS DE LA GUÍA SWEBOK?

Ver www.computer.org/sevocab.

Guía xxx SWEBOK® V3.0

literatura. El propósito de la Guía es describir la parte del cuerpo de conocimiento que es gene- ralmente aceptadas, para organizar esa parte, y para proporcionar acceso tópica a la misma. La Guía para el swebok (Guía SWEBOK) se estableció con los cinco objetivos siguientes: 1. Para promover una visión coherente de la ingeniería de software en todo el mundo 2. Para especificar el alcance de, y aclarar el lugar de la ingeniería de software con respecto a otras disciplinas como la informática, la gestión del pro- yecto, ingeniería informática y matemáticas 3. Para caracterizar el contenido de la disciplina de la ingeniería de software 4. Para proporcionar un acceso tópica en la Ingeniería de Software de Administración de Conocimiento 5. Para proporcionar una base para el desarrollo curricular y para la certificación individual y material de licencias

El primero de estos objetivos, una amplia visión del mundo coherente de ingeniería de software, fue apoyada por un proceso de desarrollo que dedica aproximada- mente 150 los colaboradores de 33 países. Más información sobre el proceso de desarrollo se puede encontrar en la página web (www.swebok.org). fesionales y las sociedades adquiridas pro y los organismos públicos involucradosse pusieron en contacto en la ingeniería de software, conscientes de este proyecto para actualizar SWEBOK, e invitados a participar en el proceso de revisión. tores KA edi- fueron reclutados de América del Norte, la cuenca del Pacífico, y Europa. Las presentaciones sobre el proyecto se hicieron en varios lugares internacionales. El segundo de los objetivos, el deseo de especificar el ámbito de la ingeniería de software, moti- VATES la organización fundamental de la Guía. El material que se reconoce como estar dentro de esta disciplina se organiza en los quince KAs enumerados en la Tabla I.1. Cada uno de estos Kas es tratado en un capítulo de esta Guía. XXXI

Tabla I.1. El 15 SWEBOK KAs Requisitos de Software Diseño de software Construcción de software Pruebas de software Mantenimiento del software Gestión de la Configuración de Software Gestión de Ingeniería de Software Proceso de Ingeniería de Software Modelos de Ingeniería de Software y Métodos Calidad del software Ingeniería de Software Práctica Profesional Economía Ingeniería de Software Fundamentos de computación Fundamentos matemáticos Fundamentos de ingeniería Al especificar el alcance, también es importante adoptar la definición de las disciplinas que se cruzan con la ingeniería de software. Con este fin, 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 KA en esta guía puede hacer referencia a ellos). No es, sin embargo, un obje- tivo de la Guía SWEBOK para caracterizar el conocimiento de las disciplinas relacionadas. Tabla I.2. Disciplinas relacionadas Ingeniería Informática Ciencias de la Computación Administración General Matemáticas Gestión de proyectos Gestión de la calidad Ingeniería de Sistemas Los elementos pertinentes de la informática y las matemáticas se presentan en los Fundamentos de Informática y Fundaciones KAs matemáticos de la Guía (capítulos 13 y 14).

La organización jerárquica La organización de los capítulos KA es compatible con el tercero de los objetivos de una caracterización del proyecto de los contenidos de la ingeniería de software. Las especificaciones detalladas 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. La Guía se usa una organización jerárquica para descomponer cada KA en un conjunto de temas con etiquetas tificables daciones. Un desglose de nivel dos (a veces tres) proporciona una forma razonable para buscar temas de interés. La guía trata los temas seleccionados de una manera compatible con las principales escuelas de pensamiento y con las averías que se encuentran generalmente en la industria y en la literatura de ingeniería de software y estándares. Las averías de los temas no presumen dominios particulares de aplicación, usos comerciales, filosofías de gestión, métodos de desarrollo, y así sucesivamente. La extensión de la descripción de cada tema es sólo eso necesitaba comprender la naturaleza generalmente aceptada de los temas y para que el lector encuentre éxito material de referencia; el Cuerpo de Conocimiento se encuentra en los materiales de referencia a sí mismos, no en la Guía. MATERIAL DE REFERENCIA Y MATRIZ Para proporcionar acceso tópica en el conocimiento de la cuarta parte de los objetivos del proyecto, la guía identifica material de referencia autorizada para cada KA. Apéndice C proporciona una lista de referencia consolidado del Guía. Cada KA incluye referencias relevante de la lista consolidada de referen- cia y también incluye una matriz que relaciona el material de referencia para los temas incluidos. Cabe señalar que la Guía no pretende ser exhaustivo en sus citas. Mucho material que es a la vez conveniente y excelente no se hace referencia. Material incluido en la lista de referencias Consolidated proporciona cobertura de los temas descritos. Profundidad del tratamiento

Guía V3.0 Para XXXII lograrSWEBOK® 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 conocimiento gene- ralmente aceptada se ha aplicado, para distinguirse de un conocimiento avanzado y la investigación (sobre la base de la madurez) y de conocimiento especializado (por motivos de generalidad de la solicitud). El término equivalente reconocido generalmente proviene del Instituto de Gestión de Proyectos: “Generalmente reconocido significa el conocimiento y las prácticas descritas son aplicables a la mayoría de los proyectos, la mayor parte del tiempo, y no hay consenso sobre su valor y utilidad.” 2 Sin embargo, los términos “generalmente aceptados” o “generalmente reconocido” no implican que el des- conocimiento ignated debe aplicarse de manera uniforme a todos los esfuerzos de ingeniería de software, cada una de las necesidades pro- yecto determinan que-pero sí implica que, ingenieros de software capaces competentes deberían estar equipados con este conocimiento para su aplicación potencial. Más precisamente, el conocimiento generalmente aceptado debe ser incluido en el estudio de material para la ingeniería de licencias de software exami- nación que los graduados tomarían después de ganar cuatro años de experiencia laboral. Aunque este cri- terio es específico para el estilo de los EEUU de la educación y no necesariamente se aplica a otros países, consideramos que es útil. ESTRUCTURA DE LAS DESCRIPCIONES KA Las descripciones KA se estructuran como sigue. En la introducción, se presentan una breve definición de la KA y una visión general de su alcance y de su nave PARENTESCO con otros KAs. 2 Una guía para la Dirección de Proyectos del Conocimiento, 5 ed, el Project Management Institute, 2013.; www.pmi.org.

El desglose de los temas en cada KA constituye el núcleo la descripción KA, que describen la descomposición de la KA en subáreas, temas y subtemas. Para cada tema o subtema, se da una breve descripción, junto con una o más referencias. El material de referencia fue elegido porque se considera que constituye la mejor presentación de los conocimientos en relación con el tema. Una matriz vincula los temas que el material de referencia. La última parte de la descripción de cada KA es la lista de referencias recomendadas y (opcionalmente) las lecturas ther de pieles. normas pertinentes para cada KA se presentan en el Apéndice B de la Guía. APÉNDICE A. KA Descripción Especificaciones Apéndice A describe las especificaciones proporcionadas por el equipo editorial de los editores asociados de los contenidos, referencias, formato y estilo de las descripciones KA recomendado. APÉNDICE B. ASIGNACIÓN DE Normaliza- ción A KAS Apéndice B es una lista comentada de las normas pertinentes, sobre todo del IEEE y de la ISO, para cada una de la KAS de la Guía SWEBOK. LISTA DE REFERENCIA APÉNDICE C. CONSOLIDADO Apéndice C contiene la lista consolidada de las referencias citadas en reco- mienda la KAS (estas referencias están marcados con un asterisco (*) en el texto).

REQUISITOS CAPÍTULO 1 SOFTWARE SIGLAS CIA

Confidencialidad, integridad y Disponibilidad

TROZO Gráfico Acíclico Dirigido DE FSM Funcional de la medida del CUERO Consejo Internacional de Sistemas INCOSE Ingenieria UML SysML

Lenguaje de Modelado Unificado Sysml

INTRODUCCIÓN El área de conocimiento Requisitos de software (KA) se ocupa de la obtención, análisis, specificación, y la validación de los requisitos de software, así como la gestión de los requisitos Duran- todo el ciclo de vida del producto de software. Es ampliamente reconocido entre los investigadores y profesionales de la industria que los proyectos de software son críticamente vulnerables cuando están mal realizan las actividades relacionadas REQUISITOS. Requisitos de software expresan las necesidades y limitaciones impuestas a un producto de software que contribuyen a la solución de algunos problemas del mundo real. La “ingeniería de requisitos” plazo es ampliamente utilizado en el campo para indicar la manipulación sistemática de requisitos. Por razones de coherencia, el término “ingeniería” no se utiliza en este KA excepto para la ingeniería de software en sí. Por la misma razón, “ingeniero de requisitos”, un término que aparece en la parte de la literatura, no se utilizará tampoco. En cambio, el término “ingeniero de software” o, en algunos casos específicos, “los requisitos especialista” se utilizará, este último donde el papel en cuestión se realiza generalmente por una persona que no sea un ingeniero de software. Esta

, No implica, sin embargo, que un ingeniero de software no pudo realizar la función. Un riesgo inherente en la descomposición propuesta es que un proceso de cascada-como puede deducirse. Para evitar esto, el tema 2, los requisitos del proceso, está diseñado para proporcionar una visión general de alto nivel del proceso de requisitos mediante el establecimiento de los recursos y las limitaciones con las que opera el proceso y que actúan para configurarlo. Una descomposición alternativa podría utilizar una estructura a base de pro- ducto (requisitos del sistema, los requisitos de soft- ware, prototipos, casos de uso, y así sucesivamente). La composición basada en el proceso refleja el hecho de que el proceso de requisitos, si ha de tener éxito, debe ser considerada como un proceso que implica actividades complejas, fuertemente acoplados (tanto secuenciales y simultáneas), en lugar de como una discreta, de una sola vez la actividad realizada al inicio de un proyecto de desarrollo de software. Los requisitos de software KA se relaciona estrechamente con el diseño de software, pruebas de software, mantenimiento de software, Software Configuration Management, Gestión de Ingeniería de Software, Software de Ingeniería de Procesos, Ingeniería de Software y Modelos Métodos y Calidad de Software de Kas. DISTRIBUCIÓN DE TEMAS PARA REQUISITOS DEL SOFTWARE El desglose de los temas de los requisitos de software KA se muestra en la Figura 1.1. 1. Requisitos de software Fundamentos [1 *, c4, c4s1, c10s1, c10s4] [2 *, C1, C6, c12] 1.1. Definición de un requisito de software

En su forma más básica, un requisito de software es una propiedad que debe ser exhibido

por algo en

1-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 de automatizar parte de una tarea para alguien para apoyar los procesos de negocio de una organiza- ción, para corregir defectos de software existente, o para controlar un nombre de dispositivo a sólo algunos de los muchos problemas para los que son posibles soluciones de software . Las formas en que los usuarios, pro- cesos de negocio, y dispositivos de función suelen ser complejas. Por extensión, por lo tanto, los requisitos de software de par- ticular son típicamente una compleja combinación de varias personas en diferentes niveles de una organización, y que están en una u otra manera involucrados o relacionados con esta función del entorno en el que el software operará. Una propiedad esencial de todos los requisitos de software es que sean verificables como una característica individual como requisito funcional o a nivel del sistema como un requisito no funcional. Puede ser difícil o costoso para verificar ciertos requisitos de software. Por ejemplo, la verificación del requisito de caudal en un centro de llamadas puede hacer necesario el desarrollo de software de simulación. Requisitos de software, ING Ensayos software y personal de calidad debe asegurar que el

requisitos pueden ser verificados dentro disponibles las limitaciones de recursos. Requisitos tienen otros atributos en adi- ción a las propiedades de comportamiento. Los ejemplos más comunes incluyen una clasificación de prioridad para permitir compensaciones en la cara de los recursos finitos y un valor de estado para permitir el avance del proyecto a vigilar. Tıpicamente, los requisitos de software son singularmente identificadas con los de modo que puedan ser objeto de software de gestión de con- figuración durante todo el ciclo de vida de la entidad y del software. 1.2. Requisitos del producto y de proceso Un requisito de un producto es una necesidad o restricción en el software que se desarrollarán (por ejemplo, “El software verificará que un estudiante cumple con todos los requisitos previos antes de que él o ella se registre en un curso”). Un requisito proceso es esencialmente un con- straint en el desarrollo del software (por ejemplo, “El software se desarrolla utilizando un proceso RUP”). Algunos de los requisitos de software generan implícita

los requisitos del proceso. La elección de la verificación

Requisitos de software 1-3

1-4 Guía SWEBOK® V3.0

técnica es un ejemplo. Otro podría ser el uso de técnicas de análisis particularmente rigurosas (tales como los métodos de especificación formal) para reducir los fallos que pueden conducir a insuficiente fiabilidad. requisitos proceso También pueden imponerse directamente por la organización de desarrollo, su cliente, o un tercero, tal como un regulador de la seguridad. 1.3. Requisitos funcionales y no funcionales Funcional requisitos describen las funciones que el software es ejecutar; por ejemplo, paraestera algún texto o la modulación de una señal. A veces se conocen como capacidades o características. Un requisito funcional también puede ser descrito como uno para el cual un conjunto finito de pasos de prueba se puede escribir para validar su comportamiento. no funcional los requisitos son los que actúan para limitar la solución. Los requisitos no funcionales son a veces conocidos como las restricciones o requisitos de calidad. Pueden ser más clasifi- sified de acuerdo a si son los requisitos de rendimiento, requisitos de mantenimiento, requisitos de seguridad, requisitos de fiabilidad, requisitos de seguridad, requisitos de interoperabilidad o uno de muchos otros tipos de requisitos de software (ver modelos y carac- terísticas de la Calidad La calidad del software KA). 1.4. Propiedades emergentes Algunos requisitos representan emergentes como propiedades del software, es decir, requisitos que no pueden ser tratados por un solo componente, sino que dependerá de cómo interactúen todos los componentes de software. El requisito de caudal para un centro de llamadas, por ejemplo, dependerá de cómo el sistema telefónico, sistema de información, y los operadores de todos interactuaron en condiciones reales de explota- ción. Las propiedades emergentes dependen fundamentalmente de la arquitectura del sistema. 1.5. Requisitos cuantificables Requisitos de software deben expresarse tan claramente y sin ambigüedad como sea posible,

y, en su caso, cuantitativamente. Es importante evitar los requisitos de vagas y no verificables que

dependen para su interpretación en un juicio subjetivo ( “el software será fiable”, “el software debe ser fácil de usar”). Esto es Particularmente importante para los requisitos no funcionales. Dos ejemplos de requisitos cuantificados son los siguientes: software de un centro de llamadas debe aumentar el rendimiento del centro en un 20%; y un sistema tendrá una probabilidad de generar un error fatal durante cualquier hora de operación de menos de 1 * 10 8. El requisito de caudal está en un nivel muy alto y tendrá que ser utilizado para derivar una serie de requisitos detallados. El requisito dad fiabili- será fuertemente restringir la arquitectura del sistema. 1.6. Requisitos del sistema y requisitos de software En este tema, los medios del “sistema” una combinación de interacción de elementos para llevar a cabo un objetivo definido. Estos incluyen elementos de hardware, software, firmware, personas, información, técnicas, instalaciones, servicios y otros apoyos, como se define por el Consejo Internacional de Soft- ware y Ingeniería de Sistemas (INCOSE) [3]. Sistema los requisitos son los requisitos para el sistema en su conjunto. En un sistema que contiene los componentes de software, requisitos de software se derivan de requisitos del sistema. Esta KA define “las necesidades del usuario” en forma restringida, como los requisitos de los clientes del sis- tema o usuarios finales. Los requisitos del sistema, por el contrario, abarcan necesidades de los usuarios, los requisitos de otras partes interesadas (tales como las autoridades miento de reglamentación mentos), y los requisitos sin una fuente humana identificable. 2. requisitos Proceso [1 *, c4s4] [2 *, C1-4, c6, c22, c23] En esta sección se presenta el proceso de requisitos de software, la orientación de los cinco temas restantes y mostrando cómo el proceso se ajusta perfectamente a los requisitos del proceso general de la ingeniería de

software.

Requisitos de software 1-5

1-6 Guía SWEBOK® V3.0

2.1. Los modelos de proceso El objetivo de este tema es el de proporcionar un entendimiento de que el proceso de requisitos • no es una actividad discreta front-end del ciclo de vida soft- ware, sino más bien un proceso iniciado en el comienzo de un proyecto que continúa para ser refinado durante todo el ciclo de vida; • identifica los requisitos de software como elementos de configuración y los gestiona utilizando las mismas prácticas de gestión de configuración de software como otros productos de los procesos del ciclo de vida del software; • necesita ser adaptado al contexto de la organización y del proyecto. En particular, el tema tiene que ver con cómo se configuran las actividades de obtención, análisis, especifica- ción y validación para diferentes tipos de proyectos y limitaciones. El tema también incluye actividades que proporcionan la entrada en el proceso de requisitos, tales como la comercialización y la factibilidad estudios. 2.2. Los actores del proceso Este tema se presentan las funciones de las personas que participan en el proceso de requisitos. Este pro- ceso es fundamentalmente interdisciplinario, y el especialista requisitos necesita para mediar entre el dominio de la parte interesada y la de ingeniería de soft- ware. A menudo hay muchas personas involucradas, además del especialista requisitos, cada uno de los cuales tiene una participación en el programa. Los titulares stake- variarán según los proyectos, pero siempre incluirán los usuarios / operadores y clientes (que no tiene por qué ser el mismo). Ejemplos típicos de grupos de interés de software incluir (pero no se limitan a) los siguientes: • Usuarios: Este grupo comprende aquellos que operará el software. A menudo es un grupo heterogéneo que implica a personas con diferentes roles y necesidades. • Clientes: Este grupo comprende aquellos

que han encargado el software o que REPRESENTA mercado objetivo del software. • Los analistas de mercado: un producto de mercado masivo no tendrá un cliente de puesta en marcha, por lo

la gente de marketing son a menudo necesarios para esta- blecer las necesidades del mercado y para actuar como clientes de proxy. • Reguladores: Muchos dominios de aplicación, como la banca y el transporte público, son re- gulada. Software en estos ámbitos debe com- capas con los requisitos de las autoridades reguladoras. • Los ingenieros de software: Estos individuos tienen un interés legítimo en sacar provecho de desa- oping el software, por ejemplo, la reutilización de componentes o de otros productos. Si, en este escenario, un cliente de un producto particu- lar tiene requisitos específicos que comprometen la posibilidad de reutilización de componentes, los ingenieros de software deben sopesar cuidadosamente su propio juego contra los del cliente. Los requisitos específicos, las limitaciones particular- mente, pueden tener un impacto importante en el precio o la entrega del proyecto, ya sea porque se ajustan bien o mal con el conjunto de habilidades de los ingenieros. ventajas y desventajas importantes entre estos requisitos deben ser identificados. No será posible satisfacer perfectamente las necesidades de todas las partes interesadas, y es el trabajo del ingeniero de software para negociar compensaciones que sean aceptables para los principales grupos de interés y dentro de las limitaciones presupuestarias, técnicas, normativas, y otros. Un requisito previo para esto es que se identifique a todos los interesados, la naturaleza de su “juego” analizados y sus requisitos provocaron. 2.3. Administración y Apoyo Proceso Esta sección presenta los recursos de gestión de proyectos requeridos y consumidos por el proceso de los requisitos. Se establece el contexto para el primer tema (Iniciación y Definición del Alcance) del Software Engineering Management KA. Su objetivo prin- cipal es hacer que el vínculo entre las actividades pro- ceso identificados en 2.1 y los problemas de costo, recursos humanos, capacitación y herramientas. 2.4. Proceso de Calidad y Mejora En este tema se refiere a la evaluación de la

de software calidad y la mejora del procesoRequisitos de requisitos. Su 1-7 propósito es hacer hincapié en el papel clave que desempeña el proceso de requerimientos en términos de la

1-8 Guía SWEBOK® V3.0

costo y puntualidad de un producto de software y de la satisfacción del cliente con él. Esto ayudará a orientar el proceso de requisitos de calidad con Dardos Están- y modelos de mejora de procesos para las mercancías y los sistemas blandas. La calidad del proceso y la mejora está estrechamente relacionado tanto a la calidad del software y KA KA Proceso de Ingeniería de Software, que comprende • la cobertura proceso de requisitos de proceso normas y modelos de mejora; • requirementsprocessmeasuresand la evaluación comparativa; • planificación de la mejora e implementación; • seguridad / CIAimprovement / planningand implementación. 3. la obtención de requisitos [1 *, c4s5] [2 *, c5, c6, c9] La obtención de requisitos tiene que ver con los orígenes de los requisitos de software y cómo el ingeniero de software puede recogerlos. Es la primera etapa en la construcción de una comprensión del problema se requiere el software de resolver. Es recuento fundamen- una actividad humana y es donde se identifican las ERS stakehold- y las relaciones establecidas entre el equipo de desarrollo y el cliente. Se denomina diversamente “captura de requisitos”, “requisitos descubrimiento” y “adquisición requisitos”. Uno de los principios fundamentales de un buen proceso de obtención requisitos es el de la comunicación tivo effec- entre los distintos titulares stake-. Esta comunicación continúa con el proceso entero de desarrollo de software del Ciclo de Vida (SDLC) con diferentes actores a diferentes puntos en el tiempo. Antes de que comience el desarrollo, los especialistas requisitos pueden formar el conducto para esta comunicación. Deben Medi comieron entre el dominio de los usuarios de software (y otras partes interesadas) y el mundo de la técnica del ingeniero de software. Un conjunto de modelos internamente consistentes en diferentes niveles de abstracción facilitar las comunicaciones entre

los usuarios de software / titulares stake- e ingenieros de software. Un elemento crítico de la obtención de requisitos está informando al alcance del proyecto. Esto implica proporcio- nando una descripción del software que se especifica y su propósito y dar prioridad a los entregables

para garantizar las necesidades de negocios más importantes del cliente son las primeras en cubrirse. Esto minimiza el riesgo de especialistas necesidades de gasto de tiempo elicit- requisitos de ING que son de poca importancia, o los que resultan ser ya no es relevante cuando se entrega el software. Por otra parte, la descripción debe ser escalable y extensible para aceptar otras exigencias no se expresa en las primeras listas formales y compatibles con los anteriores como se contempla en métodos recursivos. 3.1. requisitos Fuentes Requisitos tienen muchas fuentes en cerámica típica blandas, y es esencial que se identifican y evalúan todas las fuentes potenciales. Este tema está diseñado para promover el conocimiento de las diversas fuentes de requisitos de software y de los marcos para la gestión de los mismos. Los principales puntos cubiertos son los siguientes: • Metas. El término “objetivo” (a veces llamada “empresa comercial” o “crítico de éxito fac- tor”) se refiere a los objeti- vos generales, de alto nivel de software. Objetivos proporcionan la motiva- ción para el software, pero a menudo son muy vago. Los ingenieros de software deben prestar especial atención a la evaluación del valor (en relación a la prioridad) y el costo de las metas. Un estudio de factibilidad es una forma relativamente barata de hacer esto. • Conocimiento del dominio. El ingeniero de software necesita para adquirir o tener El conocimiento disponible sobre el dominio de aplicación. conocimiento del dominio proporciona el contexto en el que todo el conocimiento requisitos provocada debe ajustarse con el fin de entenderlo.Es una buena práctica para emular un enfoque ontológico en el dominio del conocimiento. relacio- nes entre los conceptos relevantes dentro del dominio de aplicación deben ser identificados. • Las partes interesadas (véase la sección 2.2, actores del proceso). Gran parte del software ha demostrado ser insatisfactorio porque ha hecho hincapié en las exigencias de un grupo de interesados a expensas de los demás. Por lo tanto, el software entregado es difícil de usar, o subvierte las estructuras culturales o

Requisitos de software 1-9 políticas de la organización al cliente central. El ingeniero de software tiene que identificar, representar y administrar

1-10

Guía SWEBOK® V3.0

los “puntos de vista” de muchos tipos diferentes de grupos de interés. • Reglas del negocio. Estas son declaraciones que definen o limitan algún aspecto de la estruc- tura o el comportamiento de la propia empresa. “Un estudiante no puede inscribirse en los cursos del próximo semestre si quedan algunos derechos de matrícula no pagados” sería un ejemplo de una regla de negocio que sería una fuente requisito para el software del curso-registro de una uni- versidad. • El entorno operativo. Requisitos se derivan del entorno en el que se ejecutará el programa. Estos pueden ser, por ejemplo, las limitaciones de tiempo en las restricciones del software o de rendimiento en tiempo real en un entorno empresarial. Estos deben ser buscados activamente, ya que pueden afectar en gran medida la viabilidad y el costo de software así como restringir las opciones de diseño. • El entorno de la organización. El software se requiere a menudo para apoyar un proceso de negocios, la selección de los cuales puede ser condicionado por la estructura, la cultura y la política interna de la organización. El ingeniero de software tiene que ser sensible a éstos, ya que, en general, el nuevo software no debe forzar el cambio no planificado en el proceso de negocio. 3.2. técnicas de obtención Una vez que las fuentes de requisitos se han iden- tificado, el ingeniero de software puede iniciar la obtención de información de los requisitos de los mismos. Tenga en cuenta que los requisitos rara vez se suscitó confeccionada. Más bien, el ingeniero de software obtiene información de la que él o ella formula requisitos. Este tema se centra en técnicas para conseguir los interesados humanos para articular la información relevante REQUISITOS. Es una tarea muy difícil y el ingeniero de software es necesario sensibilizar al hecho de que (por ejemplo) los usuarios pueden tener dificultades para describir sus tareas, puede dejar información importante no declarada, o pueden ser dispuestos o no pueden cooperar. Es particularmente importante entender que la provocación no es una actividad pasiva y que,

incluso si las cooperativas interesadas y articulados están disponibles, el ingeniero de software tiene que trabajar duro para obtener la información correcta. Muchos de los requisitos de negocio o técnicas son tácito o en la retroalimentación que

aún no se ha obtenido a partir de los usuarios finales. La importancia de la planificación, verificación y validación en la obtención de requisitos no puede ser exagerada. Existe un número de técnicas para los requisitos de elicitación; las principales son las siguientes: • Entrevistas. Entrevistando a las partes interesadas es un medio “tradicional” de provocar requisitos. Es importante entender las ventajas y limitaciones de las entrevistas y la forma en que debe llevarse a cabo. • Escenarios. Escenarios proporcionan un medio valioso para proporcionar contexto a la ción elicita- de requisitos del usuario. Permiten que el ingeniero de software para proporcionar un marco para las preguntas sobre las tareas del usuario al permitir que “qué pasaría si” y “cómo se hace” preguntas que se le pregunte. El tipo más común de escena- rio es la descripción de casos de uso. Hay un enlace aquí al Tema 4.2 (Modelado Conceptual) debido a las notaciones de escenarios tales como diagramas de casos de uso son comunes en el software de modelado. • Prototipos. Esta técnica es una herramienta valiosa para aclarar los requisitos ambiguos. Pueden actuar de una manera similar a los escenarios por los prousuarios Viding con un contexto en el que puedan entender mejor lo que la información que necesitan para ofrecer. Hay una amplia gama de técnicas-de prototipado ups papel maqueta de diseños de pantalla a las versiones de las pruebas beta de productos de software y un fuerte solapamiento de sus usos separados para requisitos elicita- ción y para la validación de los requisitos (véase la sección 6.2, Prototyping) . Baja fidelidad prototipos se prefieren a menudo para evitar que las partes interesadas “anclaje” en la características de menor importancia, incidental de un prototipo de mayor calidad que puede limitar la flexibilidad de diseño de formas no deseadas. • reuniones facilitadas. El propósito de estas reuniones es tratar de lograr un efecto acumulativo, por el que un grupo de personas puede traer más información sobre sus exigencias de software que trabajando individualmente. Pueden intercambiar ideas y refinar las ideas que pueden ser difíciles de llevar a la

Requisitos de software superficie utilizando entrevistas. Otra 1-11 ventaja es que los requisitos conflictivos superficie desde el principio en una forma que permite a las partes interesadas reconocen cuando éstos se producen. Cuando funciona bien, esta técnica

1-12

Guía SWEBOK® V3.0

puede resultar en un conjunto más rico y más coherente de los requisitos que de otro modo podrían ser alcanzables. Sin embargo, las reuniones deben ser manejados con cuidado (de ahí la necesidad de un facilitador) para evitar una situación en la que las habilidades críticas del equipo son erosionadas por la lealtad al grupo, o en las que los requisitos que reflejan las preocupaciones de unos pocos pelos en la lengua (y quizás de alto nivel) las personas que se ven favorecidas en detrimento de otros. • Observación. La importancia del contexto de software dentro de la ment ENTORNO organización ha llevado a la adaptación de las técnicas observacionales tales como la etnografía para la obtención de requisitos. Los ingenieros de software aprenden acerca de las tareas del usuario mediante la inmersión de sí mismos en el medio ambiente y la observación de cómo los usuarios realizan sus tareas mediante la interacción con los demás y con herramientas de software y otros recursos. Estas técnicas son relativamente caros, sino también instructiva porque ilustran que muchas tareas de usuario y procesos de negocio son demasiado sutil y complejo por sus actores para describir fácilmente. • Historias de usuarios. Esta técnica se utiliza comúnmente en los métodos de adaptación (ver Métodos ágiles en los modelos de ingeniería de software y Métodos Ka) y se refiere a las descripciones de nivel cortos, de alta de funcionalidad requerida expresada en términos de los clientes. Una historia de usuario típico tiene la siguiente forma: “Como , quiero <Meta / deseo> de manera que “. Una historia de usuario está destinado a contener suficiente información para que los desarrolladores pueden producir una estimación razonable del esfuerzo para que las aplicará. El objetivo es evitar algunos de los residuos que sucede a menudo en proyectos en los que se utilizarán para reunir los requisitos detallados temprano, pero se han invalidado antes de que comience el trabajo. Antes se implementa una historia de usuario, un procedimiento de acep- tación adecuada debe ser escrita por el al cliente central para

determinar si se han cumplido los objetivos de la historia de usuario. • Otras técnicas. Una variedad de otras técnicas para el apoyo a la obtención de información de los requisitos existen y van desde el análisis de productos de la competencia para aplicar los datos min-ing técnicas para el uso de fuentes de bases de datos de conocimiento de dominio o petición del cliente.

4. Análisis de requerimientos [1 *, c4s1, c4s5, c10s4, c12s5] [2 *, c7, c11, c12, c17] Este tema tiene que ver con el proceso de anarequisitos lyzing a • detectar y resolver los conflictos entre los requisitos; • descubrir los límites del software y cómo debe interactuar con su entorno organizacional y operativa; • requisitos del sistema elaborados para derivar los requisitos de soft- ware. La visión tradicional de análisis de requisitos ha sido que ser reducido a ing modelo- conceptual usando uno de una serie de métodos de análisis, tales como el método de análisis estructurado. Si bien el modelado conceptual es importante, incluimos la clasificación de los requisitos para ayudar a informar a soluciones de compromiso entre los requisitos (clasificación requisitos) y el proceso de creación de estas compensaciones (requisitos de negociación). Se debe tener cuidado para describir los requisitos de forma suficientemente precisa para permitir que los requisitos para ser validados, su aplicación a ser verificada, y sus costes a estimar. 4.1. requisitos Clasificación Los requisitos pueden ser clasificadas en varias dimensiones. Ejemplos incluyen los siguientes: • Si el requisito es funcional o no funcional (ver sección 1.3, funcional y requerimientos no funcionales). • Si el requisito se deriva de uno o más requisitos de alto nivel o una propiedad de gent gencia (véase la sección 1.4, propiedades emergentes), o está siendo impuesta directamente en el software por un actor o alguna otra fuente. • Si el requisito es en el producto o el proceso (ver sección 1.2, producto y requisitos del proceso). Requisitos en el proceso pueden limitar la elección de Tor contracción, el proceso de ingeniería de software para ser adoptado, o las normas que deben ser respetados.

Requisitos de software 1-13

1-14

Guía SWEBOK® V3.0

• La prioridad requisito. Cuanto mayor sea la priori- dad, más esencial es el requisito para cumplir con los objetivos generales del software. A menudo clasificada en una escala de coma fija como obligatoria, altamente deseable, deseable u opcional, la prioridad que a menudo tiene que ser equilibrada con el coste de desarrollo e implementación. • El alcance de la prescripción. Ámbito de aplicación se refiere a la medida en que un requisito afecta a los componentes de software y de software. Algunos de los requisitos, en especial a algunos que no funcionales, tienen un alcance global en que su satisfacción no puede ser asignado a un componente discreto. Por lo tanto, un requisito de ámbito global puede afectar en gran medida la arquitectura de software y el diseño de muchos componentes, mientras que uno con un alcance limitado puede ofrecer una serie de opciones de diseño y tienen poco impacto en la satisfacción de otras necesidades. • Volatilidad / estabilidad. Algunos de los requisitos cambiarán durante el ciclo de vida de la Cesión de Software, e incluso durante el propio proceso de desarrollo. Es útil si alguna estimación de la probabilidad de que va a cambiar un requisito se puede hacer. Por ejemplo, en una aplicación de ING banco-, los requisitos para las funciones para el cálculo y el interés de crédito a las cuentas de los clientes tienden a ser más estable que un requisito para apoyar un tipo particular de cuenta libre de impuestos. El primero refleja una característica funda- mental del dominio bancario (cuentas que pueden ganar intereses), mientras que los segundos pueden dejarlo obsoleto por un cambio a la legislación gubernamental. Marcar requisitos potencialmente volátiles puede ayudar al ingeniero de software de establecer un diseño que es más hormiga tolerar de cambio. Otras clasificaciones pueden ser apropiadas, dependiendo de Tice prác- normal de la organización y la propia aplicación. Hay una fuerte superposición entre atributos requisitos de clasificación y requisitos (ver

sección 7.3, Requisitos de atributos).

4.2. Modelado conceptual El desarrollo de modelos de un problema del mundo real es clave para el análi- sis requisitos de software. Su propósito es ayudar a comprender la situación en la que se produce el problema, así como que representa una solución. Por lo tanto, los modelos conceptuales comprenden modelos de entidades del dominio del problema, configurado para reflejar sus relaciones y dependencias del mundo real. Este tema está estrechamente relacionado con las els Ingeniería de Software y Métodos Mod-KA. Hay varios tipos de modelos pueden ser desarrollados. Estos incluyen diagramas de casos de uso, los modelos de flujo de datos, modelos de estado, los modelos basados en objetivos, las interacciones del usuario, modelos de objetos, modelos de datos, y muchos otros. Muchas de estas notaciones de modelado son parte del lenguaje de modelado unificado (UML). Utilice diagramas de casos, por ejemplo, se utilizan rutinariamente para representar escenarios en los que el límite que separa a los actores (usuarios o sistemas en el ronment bientes externa) del comportamiento interno donde cada caso de uso representa una funcionalidad del sistema. Los factores que influyen en la elección de la notación ing modelo- incluyen los siguientes: • La naturaleza del problema. Algunos tipos de software bajo demanda que ciertos aspectos sean ana- lisadas particularmente rigurosa. Para modelos de ejemplo, estatales y paramétricos, que son parte de SysML [4], es probable que sean tant más impor- por software en tiempo real que para los sistemas informa- ción, al tiempo que normalmente sería el opuesto para modelos de objetos y de la actividad. • La experiencia del ingeniero de software. A menudo es más productivo para adoptar una notación de modelado o método con el que el ingeniero de software con experiencia. • Los requisitos del proceso del cliente (ver sección 1.2, el producto y los requerimientos del proceso). Los clientes pueden imponer su notación o método favorecido o prohibir cualquier con las que están familiarizados. Este factor puede entrar en conflicto con el factor anterior. Nota que, en casi todos los casos, es útil

de software comenzar la construcción deRequisitos un modelo del 1-15 contexto del software. El contexto software proporciona una conexión entre los programas informáticos destinados y su entorno externo.

1-16

Guía SWEBOK® V3.0

Esto es crucial para la comprensión de contexto del software en su entorno operativo y para que identifique los valores de sus interfaces con el medio ambiente. Este subtema no busca “enseñar” a un estilo de modelado particu- lar o anotación, sino más bien proporciona orientación sobre el propósito e intención de modelado. 4.3. Diseño y requisitos arquitectónicos Asignación En algún momento, la arquitectura de la solución debe ser derivado. El diseño arquitectónico es el punto en el que el proceso se superpone con los requisitos de software o sistemas de diseño e ilustra lo imposible que es disociar limpiamente las dos tareas. Este tema está estrechamente relacionada con la estructura y arquitectura de software en el diseño de software KA. En muchos casos, el ingeniero de software actúa como arquitecto de software debido a que el proceso de análisis y elaboración de los requisitos que exige ser identificados los componentes / diseño de arquitectura que se encargarán de satisfacer los requisitos. Esta es la asignación de-la requisitos de asignación a componentes de la arquitectura respon- sable para satisfacer los requisitos. La asignación es importante para permitir Ysis anal-detallado de las necesidades. Por lo tanto, por ejemplo, una vez que un conjunto de requisitos se ha asignado a un componente, los requisitos individuales se pueden analizar aún más para descubrir nuevos requisitos sobre cómo el componente tiene que interactuar con otros componen- tes con el fin de satisfacer el requisito asignado mentos. En grandes proyectos, la asignación estimula una nueva ronda de análisis para cada subsistema. Como ejemplo, los requisitos para un rendimiento determinado de frenado para un coche (distancia de frenado, la seguridad en condiciones de conducción pobres, suavidad de apli- cación, la presión del pedal necesarios, y así sucesivamente) puede ser asignada al hardware de frenado (conjuntos mecánicos e hidráulicos) y un sistema de frenado antibloqueo (ABS). Sólo cuando un requisito para un sistema antibloqueo de frenos ha sido identificado, y los requerimientos asignados a ella, se pueden utilizar los lazos capabili- del ABS, el hardware de frenado, y emer-

propiedades Gent (tales como el peso del coche) para identificar la detallada requisitos de software ABS. El diseño arquitectónico está estrechamente identificada con el modelado conceptual (ver sección 4.2, conceptual Modelado).

4.4. requisitos de Negociación Otro término comúnmente utilizado para este subtema es “resolución de conflictos”. Esto se refiere resolv- ing problemas con los requisitos donde los conflictos se producen entre dos actores que requieren mutu- características aliado incompatibles, entre las necesidades y los recursos, o entre los requisitos funcionales y no funcionales, por ejemplo, . En la mayoría de los casos, no es aconsejable para el ingeniero de software para hacer una decisión unilateral, lo que se hace preciso proceder a consultar con la parte interesada (s) para llegar a un consenso sobre una compensación adecuada. A menudo es importante, por razones contractuales, que tales las decisiones sean detectables de nuevo al cliente. Hemos clasificado esto como un tema de análisis de requisitos de software debido a problemas surgen como el resultado del análisis. Sin embargo, un fuerte caso también se puede hacer por considerarlo un tema de validación de requisitos (ver tema 6, los requisitos de validación). Requisitos priorización es necesario, no sólo como un medio para filtrar los requisitos importantes, sino también con el fin de resolver los conflictos y el plan de entregas escalonadas, lo que significa tomar decisiones complejas que requieren el conocimiento de dominio detallado y buenas habilidades de estimación. Sin embargo, a menudo es difícil obtener información real que puede actuar como base para este tipo de decisiones. Además, los requisitos a menudo dependen unos de otros, y prioridades son relativos. En la práctica, los ingenieros de software realizan requisitos priorización con frecuencia sin necesidad de conocer todos los requisitos. Requisitos priorización puede seguir un enfoque de valor de costo que implica un análisis de las partes interesadas en una escala que definen los beneficios o el valor agregado que el ción ¡Ejecución del requisito les lleva, en comparación con las penas de no haber implementado un requisito particular. También implica un análisis de los ingenieros de software de estimación en una escala el costo de la implementación de cada requisito, en relación con otros requisitos. Otro enfoque oritization pri- requisitos llama el proceso analítico jerárquico implica comparar todos los pares únicos de los requisitos para determinar cuál de los dos es de mayor prioridad, y en qué medida.

Requisitos de software 1-17

1-18

Guía SWEBOK® V3.0

4.5. Análisis formal preocupaciones formales de análisis no sólo el tema 4, sino también las secciones 5.3 y 6.3. En este tema también se relaciona con métodos formales en los modelos de ingeniería de software y métodos Área de Conocimiento. Análisis formal ha hecho un impacto en algunos dominios de aplicación, en particular los de los sistemas de alta integridad. La expresión formal de requisitos requiere una lengua con la semántica formalmente definidos. El uso de un análisis formal para la expresión requisitos tiene dos ventajas. En primer lugar, permite a los requisitos expresados en el idioma que se especifique con precisión y forma ambigua, por lo tanto (en principio) para evitar la posibilidad de una mala interpretación. En segundo lugar, los requisitos se puede razonar sobre, permitiendo propiedades deseadas del software especificado para ser probada. razonamiento formal requiere soporte de herramientas para ser practicable para distintos de los sistemas triviales nada, y herramientas generalmente se dividen en dos tipos: los demostradores de teoremas o las damas modelo. En ninguno de los casos puede ser totalmente automatizado prueba, y el nivel de competencia en razonamiento formal sea necesario con el fin de utilizar las herramientas restringe la aplicación más amplia de análisis formal. El análisis más formal, se centra en etapas relativamente tardías de análisis de requisitos. Es general- mente contraproducente para solicitar la formalización hasta que los objetivos de negocio y necesidades de los usuarios han entrado en un enfoque nítido a través de medios tales como los descritos en otras partes de la sección 4. SIN EMBARGO, una vez que los requisitos se han estabilizado y se han elaborado para especificar propie- concreto lazos del software, puede ser beneficioso para para- malize al menos los requisitos críticos. Esto per- mite la validación estática que el software especificado por los requisitos sí tiene las pro- piedades (por ejemplo, ausencia de estancamiento) que el cliente, los usuarios, y el ingeniero de software de esperar que tenga. 5. Especificación de requisitos [1 *, c4s2, c4s3, c12s2-5] [2 *, c10]

Para la mayoría de las carreras de ingeniería, el término “memoria descriptiva” se refiere a la asignación de valores numéricos o los límites a los objetivos de diseño de un producto. En la ingeniería de software, “especificación de requisitos de software” típicamente se refiere a la producción de

un documento que pueda ser revisado de forma sistemática, evaluada y aprobada. Para sistemas complejos, especialmente aquellos que involucran componentes mercancías nonsoft- sustanciales, como se producen hasta tres diferentes tipos de documentos: sistema de defini- ción, requisitos del sistema y los requisitos de software. Para los productos de software simple, sólo se requiere el tercero de estos. Los tres documentos se describen aquí, con el entendimiento de que se pueden combinar según sea apropiado. Una descripción de la ingeniería de sistemas se puede encontrar en las disciplinas de Ingeniería de Software capítulo de esta guía relacionadas. 5.1. Definición del sistema de documentos Este documento (a veces conocido como el documento de requerimientos del usuario o el concepto de documento de operaciones) registra los requisitos del sistema. Define los requisitos del sistema de alto nivel de la perspectiva de dominio. Su número de lectores incluye representantes de los usuarios del sistema / clientes (marketing puede desempeñar estas funciones para el software impulsado de mercado), por lo que su contenido debe ser expresada en términos de dominio. El documento enumera los requisitos del sistema, junto con la información de fondo sobre los objetivos globales para el sistema, su entorno de destino, y una declaración de las limitaciones, supuestos y requisitos no funcionales. Puede incluir modelos conceptuales diseñados para ilustrar el contexto del sistema, escenarios de uso, y las principales entidades de dominio, así como los flujos de trabajo. 5.2. Requisitos del sistema Especificación Los desarrolladores de sistemas con software sustancial y componentes de un forro de aire moderno nonsoftware, por ejemplo, a menudo se separan de la descripción de los requisitos del sistema de la descripción de los requisitos de software. En esta vista, se especifican los requisitos del sistema, los requisitos de software se derivan de los requisitos del sistema y, a continuación los requisitos para el software com- ponentes se especifican. En sentido estricto, la especificación de los requisitos del sistema es un sistema de Engineer- ing actividad y queda fuera del alcance de esta guía.

Requisitos de software 1-19

Requisitos de software 1-11

5.3. Especificación Software

de

Requerimientos

de

especificación de requisitos de software establece la base para un acuerdo entre los clientes y los contratistas o proveedores (en proyec- tos impulsados por el mercado, estas funciones pueden ser jugados por las divisiones de marketing y desarrollo) en lo que el producto de software es a hacer, así como lo que no es espera que lo haga. especificación de requisitos de software permite una evaluación rigurosa de los requisitos de diseño antes de comenzar y se reduce el rediseño más tarde. También debe proporcionar una base realista para ing realizan estimaciones los costos del producto, riesgos y horarios. Las organizaciones también pueden utilizar un documento de especificación de los requisitos de software de base para la elaboración de planes eficaces de verificación y validación. especificación de requisitos de software proporciona una base informada para la transferencia de UCT un software PRODUCIRSE a nuevos usuarios o plataformas de software. Por último, puede proporcionar una base para la mejora del software. Requisitos de software a menudo se escriben en lenguaje natural, pero, en la especificación de requisitos de software, esto puede complementarse con for- mal o descripciones semiformales. La selección de las anotaciones apropiadas permite particulares los requisitos y aspectos de la arquitectura de software que se describirán con mayor precisión y concisión de lenguaje natural. La regla general es que ciones notaciones se deben utilizar que permiten los requisitos que se describen tan precisamente como sea posible. Esto es particularmente crucial para críticos para la seguridad, regulación, y ciertos otros tipos de software fiable. Sin embargo, la elección de la notación a menudo se cuela por la con- formación, habilidades y preferencias de los autores y los lectores del documento. Una serie de indicadores de calidad se han desarrollado que puede ser utilizado para relacionar la calidad de los requisitos de software de especificación a otras variables del proyecto, tales como el coste, la aceptación, Formance per-, programar y reproducibilidad. Los indicadores de calidad para las declaraciones de especificación de requisitos de

software individuales son imperativos, directivas, frases débiles, opciones y ANCES continuidades. Indicadores para todo el documento de especificación de software exigencias incluyen el tamaño, la capacidad de lectura, la especificación, la profundidad y la estructura del texto.

1-12

Guía SWEBOK® V3.0

6. requisitos de Validación [1 *, c4s6] [2 *, c13, c15] Los documentos de los requisitos pueden estar sujetos a procedimientos de Val- idation y verificación. Los requisitos pueden ser validados para asegurar que el ingeniero de software ha entendido los requisitos; También es importante verificar que se ajusta a los requisitos de docu- ment estándares de la compañía y que es comprensible, coherente y completa. En los casos en los estándares de la compañía documentados o terminología sean incompatibles con las normas generalmente aceptadas, una asignación entre los dos debe ser acordado y se anexa al documento. Las notaciones formales ofrecen la importante ventaja de permitir que las dos últimas propiedades a ser probada (en un sentido restringido, por lo menos). Stakedistintos titulares, entre ellos representantes del cliente y desarrollador, deben revisar el documento (s). Los documentos de requisitos están sujetos a las mismas prácticas de gestión de configuración como las demás prestaciones de los procesos del ciclo de vida del software. Cuando sea posible, los requisitos individuales también están sujetos a la gestión de configuración, general- mente con una herramienta de gestión de requisitos (véase el tema 8, requisitos de software Herramientas). Es normal para programar explícitamente uno o más puntos en el proceso de requisitos donde se validan los requisitos. El objetivo es recoger cualquier problema antes de recursos se comprometen a abordar los requisitos. Requisitos validada dación tiene que ver con el proceso de examin- ing el documento de requisitos para garantizar que define el software adecuado (es decir, el software que los usuarios esperan). 6.1. requisitos críticas Tal vez la forma más común de la validación se realiza mediante inspección o revisión del documento (s) requisitos. Un grupo de revisores se le asigna un breve para buscar errores, suposiciones erróneas, falta de claridad, y la desviación de Tice prácestándar. La composición del grupo que lleva a cabo la revisión es importante (al menos una representativa del cliente debe ser incluido para un proyecto impulsado por el cliente, por ejemplo), y puede ayudar a proporcionar

orientación sobre lo que debe buscar en la forma de listas de verificación.

Requisitos de software 1-13

Los comentarios pueden ser constituidos en la finalización del documento de definición del sistema, el documento de especificación del sistema, el documento de especificación de requisitos de software, la especificación de línea de base para un nuevo lanzamiento, o en cualquier otro paso en el proceso. 6.2. prototipado Prototipos es comúnmente un medio para validar la interpretación que el ingeniero de software de los requisitos de software, así como para la obtención de nuevos requisitos. Al igual que con la elicitación, hay una gama de técnicas de prototipado y un número de puntos en el proceso donde la validación prototipo puede ser apropiado. La ventaja de prototipos es que pueden hacer que sea más fácil interpretar los supuestos del ingeniero de soft- ware y, si es necesario, dar información útil acerca de por qué están equivocados. Por ejemplo, el comportamiento dinámico de un usuario interfase se puede entender mejor a través de un ani- acoplado prototipo que a través de descripción textual o modelos gráficos. La volatilidad de un requisito que se define después de la creación de un prototipo que se ha hecho es extremadamente bajo porque no hay acuerdo entre el interesado y el software de inge- Neerpor lo tanto, para la creación de prototipos características cruciales de seguridad crítica y sería una gran ayuda. También hay desventajas, sin embargo. Estos incluyen el peligro de la atención de los usuarios distraerse del núcleo funcionalidad subyacente por cuestiones cosméticas o problemas de calidad con el prototipo. Por esta razón, algunos prototipos defienden que eviten el software, tales como maquetas basadas en rotafolio. totypes pro pueden ser costosos de desarrollar. Sin embargo, si evitan el desperdicio de recursos que supone tratar de satisfacer los requisitos erróneos, su coste se puede justificar más fácilmente. prototipos tempranos pueden contener aspectos de la solución final. Los prototipos pueden ser evolutiva en lugar de usar y tirar. 6.3. Modelo de validación Por lo general es necesario para validar la calidad de los modelos desarrollados durante el

análisis. Por ejem plos, en modelos de objetos, es útil para llevar a cabo un análisis estático para verificar la existencia de rutas de comunicación entre los objetos que, en las partes interesadas

1-14

Guía SWEBOK® V3.0

dominio, el intercambio de datos. Si se utiliza el análisis formal notación ciones, es posible utilizar ing razonable formal para probar las propiedades de especificación. Este tema está estrechamente relacionado con las els Ingeniería de Software y Métodos Mod-KA. 6.4. Prueba de aceptacion Una propiedad esencial de un requisito de software es que debe ser posible validar que el producto final satisface. Requisitos que no pueden ser validados en realidad sólo son “deseos.” Por tanto, una tarea importante es la planificación de cómo ver- ify cada requisito. En la mayoría de los casos, el diseño de las pruebas de aceptación hace esto por cómo los usuarios finales normalmente, un comportamiento camente negocio utilizando el sistema. Identificación y diseño de pruebas de aceptación puede ser difícil para los requisitos no funcionales (véase la sección 1.3, funcional y requerimientos no funcionales). Para ser validado, primero tienen que ser analizados y se descompone hasta el punto en que se pueden expresar cuantitativamente. Información adicional se puede encontrar en la acep- tación / Calificación / pruebas de conformidad en el Testing de Software KA. 7. Consideraciones prácticas [1 *, c4s1, c4s4, c4s6, c4s7] [2 *, c3, c12, c14, c16, c18-21] El primer nivel de descomposición tema pretantes en este KA puede parecer para describir una secuencia lineal de actividades. Esta es una visión simplificada del proceso. El proceso de requisitos abarca todo el ciclo de vida del software. La gestión del cambio y el mantenimiento de los requisitos en un estado que refleja con precisión el software que se construirán, o que se ha construido, son la clave para el éxito del proceso de ingeniería de software. No todas las organizaciones tienen una cultura de requisitos y gestión de docuMenting. Es mon com- en empresas de nueva creación dinámica, impulsada por un fuerte “visión de producto” y los recursos limitados, para ver la documentación de requisitos como una sobrecarga innecesaria. Muy a menudo, sin embargo, ya que estas empre- sas se expanden, a medida que crece su base de clientes, y como

su producto comienza a evolucionar, descubren que necesitan para recuperar los requisitos que

Requisitos de software 1-15

producto motivado cuenta con el fin de evaluar el impacto de los cambios propuestos. Por lo tanto, la documentación y los requisitos de gestión del cambio son la clave para el éxito de cualquier proceso de requisitos. 7.1. La naturaleza iterativa del proceso Requisitos Existe una presión general en el software de indus- tria de los ciclos de desarrollo cada vez más cortos, y esto es particularmente pronunciado en sectores altamente competitivos, impulsados por el mercado. Por otra parte, la mayoría de los proyectos se ven limitados de alguna manera por su entorno, y muchos son actualizaciones o revisiones de software, tentes ing en el que se da por la arquitectura. En la práctica, por lo tanto, casi siempre es práctico para implementar el proceso de requisitos como un proceso lineal y determinista en el que los requisitos de software son provocados a partir de los grupos de interés, bases forrado, asignado y entregado al equipo de desarrollo de software. Sin duda, es un mito que los requisitos para grandes proyectos de software están siempre perfectamente entendidas o perfectamente especificados. En su lugar, los requisitos normalmente iterar hacia un nivel de calidad y detalle que es suficiente para permitir que las decisiones de diseño y de adquisiciones a realizar. En algunos proyectos, esto puede dar lugar a los requisitos que se baselined antes de todas sus propiedades se entienden completamente. Se corre el riesgo expen- retrabajo siva si surgen problemas al final del proceso de ingeniería soft- ware. Sin embargo, los ingenieros de software están necesariamente limitados por los planes de gestión de proyectos y por lo tanto deben tomar medidas para asegurar que la “calidad” de los requisitos es tan alto como sea posible dados los recursos disponibles. Deben, por ejemplo, hacer explícitas las suposiciones que sustentan los requisitos, así como los problemas conocidos. Para los productos de software que se desarrollan ITER tivamente, un equipo de proyecto puede línea de base sólo a los requisitos necesarios para la iteración actual. El especialista requisitos puede seguir desarrollándose requisitos para futuras iteraciones, mientras res desarrollos proceder

con el diseño y la construcción de la iteración actual. Este enfoque proporciona ERS adaptado para el cliente con el valor de negocio de forma rápida, mientras minimizando ing el costo de reproceso. En casi todos los casos, los requisitos de la comprensión continúa evolucionando a medida que el diseño y el desarrollo

1-16

Guía SWEBOK® V3.0

producto. Esto a menudo conduce a la revisión de los requisitos finales del ciclo de vida. Tal vez el punto más crucial en la comprensión de los requisitos de software es que una proporción significativa de los requisitos cambiará. Esto es a veces debido a errores en el análisis, pero a menudo es una consecuencia inevitable del cambio en el “medio ambiente”; por ejemplo, el entorno operativo o de negocio del cliente, procesos de regulación impuestas por las autoridades, o el mercado en el que el software debe vender. Cualquiera que sea la causa, es importante reconocer la inevitabilidad del cambio y tomar medidas para mitigar sus efectos. El cambio tiene que ser gestionado por asegurar que los cambios propuestos pasan por una revisión definido y tasa de aprobación pro y mediante la aplicación de los requisitos cuidadosos trac- ción, análisis de impacto, y la gestión de configuración de software (ver el KA Software Configuration Management). Por lo tanto, los requisitos de pro- ceso no es sólo una tarea para el usuario en el desarrollo de software, pero se extiende por todo el ciclo de vida del software. En un proyecto típico, el software requisito actividades mentos evolucionan con el tiempo de obtención de la gestión del cambio. Una combinación de arriba hacia abajo métodos de análisis y diseño y de abajo hacia arriba y métodos de implementación de refactorización que se reúnen en el medio podría proporcionar lo mejor de ambos mundos. Sin embargo, esto es difícil de lograr en la práctica, ya que depende en gran medida de la madurez y la experiencia de los ingenieros de software. 7.2. Gestión del cambio La gestión del cambio es fundamental para la gestión de requisitos. En este tema se describe el papel de la gestión del cambio, los procedimientos que deben estar en su lugar, y el análisis que se debe aplicar a los cambios propuestos. Tiene fuertes vínculos con la Cesión de Software Gestión de la Configuración KA. 7.3. requisitos Atributos Los requisitos deben consistir no sólo en un ficación speci- de lo que se requiere, sino también de información auxiliar, lo que ayuda a manejar e interpretar los requisitos. Requisitos atributos deben ser definidos, registran y actualizan a medida que el soft-

ware en fase de desarrollo o mantenimiento evoluciona. Esto debe incluir los diversos clasificación

Requisitos de software 1-17

dimensiones de la exigencia (véase la sección 4.1, los requisitos de clasificación) y el método de verificación o sección del plan de prueba de aceptación correspondiente. También puede incluir información adicional, como una justificación de resumen para cada requisito, la fuente de cada requerimiento, y un historial de cambios. Los requisitos más importantes atribuyen, SIN EMBARGO, es un identificador que permite a los requisitos para ser identificadas de manera única e inequívoca. 7.4. requisitos de rastreo Requisitos de rastreo tiene que ver con objeto de reembolso ing la fuente de los requisitos y la predicción de los efectos de los requisitos. El rastreo es fundamental para la realización de análisis de impacto cuando los requisitos cambian. Un requisito debe ser trazable dadas vuelta a los requisitos y las partes interesadas que la motivaron (de un requisito de software de nuevo a la exigencia (s) del sistema que ayuda a satisfacer, por ejemplo). Por el contrario, un requisito debe ser trazable hacia adelante en los requisitos de diseño y entidades que lo satisfacen (por ejemplo, de un requisito del sistema en los requisitos de software que se han elaborado a partir de ella, y en en los módulos de código que lo implementan, o la casos de prueba relacionados con ese código, e incluso una sección dada en el manual de usuario que describe la funcionalidad real) y en el caso de prueba que verifica. Los requisitos de seguimiento para un típico proyec- ect formarán un complejo gráfico dirigido acíclico (DAG) (ver Gráficos en el Computing Foundation ciones KA) de requisitos. El mantenimiento de una matriz gráfica fecha o trazabilidad hasta-a es una actividad que debe ser considerada durante todo el ciclo de vida de un producto. Si la información de trazabilidad no se actualiza como los cambios en los requisitos siguen ocurriendo, la información de trazabilidad deja de ser fiable para el análisis del impacto.

7.5. La medición de Requisitos Como cuestión práctica, suele ser útil tener algún concepto de “volumen” de las exigencias para un producto de software en particular. Este número es útil para evaluar el “tamaño” de un cambio en los requisitos, al estimar el costo de una tarea de desarrollo o mantenimiento, o simplemente para su uso como el denominador en otras mediciones. medida del tamaño funcional (FSM) es una téc- nica para evaluar el tamaño de un cuerpo de requisitos funcio- nales. Información adicional sobre la medición y estándares de tamaño se encuentra en el Proceso de Software niería Inge- KA. 8. Requisitos de software Herramientas Herramientas para hacer frente a los requisitos de software se dividen en dos categorías: herramientas para el modelado y herramientas para la gestión de requisitos. herramientas de gestión de requisitos normalmente el puerto SUP- una serie de actividades, incluyendo docu- mentación, la localización, y la gestión del cambio y han tenido un impacto significativo en la práctica. De hecho, ing trac- y la gestión del cambio son realmente sólo prác- ticable si es compatible con una herramienta. Desde la gestión de requisitos es fundamental para la buena práctica de los requisitos, muchas organizaciones han invertido en herramientas de gestión de requisitos, aunque muchos más manejar sus requisitos en más ad hoc y generalmente menos satisfactorios maneras (por ejemplo, utilizando hojas de cálculo).

Guía SWEBOK® V3.0

Wiegers 2003 [2 *]

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

SommervilLe 2011 [1 *]

1-18

c4 c4s1

c1 C1, C6

1.3. Requisitos funcionales y no funcionales

c4s1

c12

1.4. Propiedades emergentes 1.5. Requisitos cuantificables

c10s1

1. Requisitos de software Fundamentos 1.1. Definición de un requisito de software 1.2. Requisitos del producto y de proceso

1.6. Requisitos del sistema y requisitos de software 2. Requisitos Proceso 2.1. Los modelos de proceso

c1 c10s4

c1

c4s4

c3

2.2. Los actores del proceso 2.3. Administración y Apoyo Proceso

c1, c2, c4, c6 c3

2.4. Proceso de Calidad y Mejora

c22, c23

3. la obtención de requisitos 3.1. requisitos Fuentes 3.2. técnicas de obtención

c4s5 c4s5

C5, C6, C9 c6

Análisis 4. Requisitos 4.1. requisitos Clasificación 4.2. Modelado conceptual

c4s1 c4s5

c12 c11

4.3. Diseño y requisitos arquitectónicos Asignación 4.4. requisitos de Negociación

c10s4 c4s5

c17 c7

4.5. Análisis formal

c12s5

5. Requisitos Especificación 5.1. Definición del sistema de documentos

c4s2 c4s2, c12s2, c12s3, c12s4, c12s5

c10

c4s3

c10

c4s6

c15

6.2. prototipado

c4s6

c13

6.3. Modelo de validación 6.4. Prueba de aceptacion

c4s6 c4s6

c15 c15

5.2. Requisitos del sistema Especificación 5.3. Especificación de Requerimientos de Software 6. Requisitos de Validación 6.1. requisitos críticas

c10

7.2. Gestión del cambio 7.3. requisitos Atributos

Wiegers 2003 [2 *]

7. Consideraciones prácticas 7.1. La naturaleza iterativa del proceso Requisitos

SommervilLe 2011 [1 *]

Requisitos de software 1-19

c4s4

C3, C16

c4s7 c4s1

c18, c19 c12, c14

7.4. requisitos de rastreo 7.5. La medición de Requisitos 8. Requisitos de software Herramientas

c20 c4s6

c18 c21

1-20

Guía SWEBOK® V3.0

LECTURAS I. Alexander y L. Beus-Dukic, Requisitos Descubriendo [5]. Un libro de fácil digestión y de carácter práctico sobre los requisitos de software, esto es quizás el mejor de los libros de texto actuales sobre cómo los diferentes elementos de los requisitos de software encajan entre sí. Está lleno de consejos prácticos sobre (por ejemplo) la manera de identificar los distintos actores del sistema y cómo evaluar soluciones alternativas. Su edad cubierta- es ejemplar y sirve como una referencia útil para técnicas de clave, tales como modelado de caso de uso y requisitos de priorización. C. Potts, K. Takahashi, y A. Antón, “indagación Análisis Requisitos Basado” [6]. Este documento es una cuenta de fácil digestión de trabajo que ha demostrado ser muy influyente en el desa- rrollo de las necesidades de manipulación. En él se describe cómo y por qué la elaboración de requisitos no puede ser un proceso lineal por el cual el analista simplemente transcribe y reformula requisitos provocadas por parte del cliente. El papel de los escenarios se describe de una manera que ayuda a definir su uso en el descubrimiento y la descripción de los requisitos.

A. van Lamsweerde, Ingeniería de Requisitos: A partir de los objetivos del sistema de modelos UML a Especificaciones de software [7]. Sirve como una buena introducción a la ingeniería de requisitos, pero su valor único es como un libro de referencia para los requisitos orientados a objetivos lenguaje de modelado de KAOS. Explica por qué el modelado meta es útil y muestra cómo se puede integrar con técnicas de modelado convencionales usando UML. O. Gotel y A. Finkelstein, “Un análisis del problema Requisitos trazabilidad” [8]. Este trabajo es una obra de referencia clásica en un elemento clave de la gestión de requisitos. Basándose en estudios empíricos, establece las razones y las barreras para el rastreo eficaz de los requisitos. Es una lectura esencial para la comprensión de por qué los requisitos de rastreo es un elemento esencial de un proceso de software efectivo. N. Maiden y C. Ncube, “La adquisición de COTS Requisitos de selección de software” [9]. Este documento es importante porque reconoce explícitamente que los productos de software a menudo integran componentes de terceros. Ofrece una visión de los problemas de la selección de software off-the-shelf para satisfacer los requisitos: por lo general hay una falta de coincidencia. Esto desafía algunos de los supuestos sub fijando la mayor parte de los requisitos tradicionales dling manipulan de, que tiende a asumir software personalizado.

Requisitos de software 1-21

Referencias [1 *] I. Sommerville, Ingeniería de Software, 9ª ed., Addison-Wesley, 2011. [2 *] KE Wiegers, Requisitos de software, segundo ed., Microsoft Press, 2003. [3] INCOSE, Manual de Sistemas de Ingeniería: Una guía para los procesos de ciclo de vida del sistema y Actividades, versión 3.2.2, Consejo Internacional de Ingeniería de Sistemas, 2012. [4] S. Friedenthal, A. Moore, y R. Steiner, Una guía práctica para SysML:. El sysml, 2ª ed, Morgan Kaufmann, 2012. [5] I. Alexander y L. Beus-Deukic, Descubriendo Requisitos: Cómo especificar los productos y servicios, Wiley, 2009.

[6] C. Potts, K. Takahashi, y AI Antón, “basada en la indagación Análisis de Requerimientos,” IEEE Software, vol. 11, no. 2, marzo de 1994, pp. 21-32. [7] A. van Lamsweerde, Ingeniería de Requisitos: A partir de los objetivos del sistema de modelos UML a especificaciones de software, Wiley, 2009. [8] O. Gotel y CW Finkelstein, “Un análisis del problema exigencias de trazabilidad,” Proc. Primero Int'l Conf. Requisitos Eng., IEEE, 1994. [9] NA Maiden y C. Ncube, “La adquisición de Requisitos de Elección COTS software”, IEEE Software, vol. 15, no. 2, marzo-abril. 1998, pp. 46-56.

CAPÍTULO 2 DISEÑO DEL SOFTWARE SIGLAS ADL

Arquitectura Descripción Idioma

CDB

Diseño basado en componentes

CRC DFD

Responsabilidad clase colaborador Diagrama de flujo de datos

ERD IDL MVC

Relación diagrama de entidad Interfaz de lenguaje de descripción de Modelo Vista Controlador

OO PDL

Orientado a objetos Programa de Lenguaje de Diseño

INTRODUCCIÓN Diseño se define como tanto “el proceso de defin- ing la arquitectura, componentes, interfaces y otras características de un sistema o componente” y “el resultado del proceso [que]” [1]. Visto como un proceso, diseño de software es el ing la actividad del ciclo de vida del software en el que Engineer- mentos de software requisito se analizan con el fin de producir una descripción de la estructura interna del software que va a servir de base para su construcción. Un diseño de software (el resultado) describe el software de archi- tecture, es decir, cómo se descompone software y organizado en componentes-y las caras interrelaciones entre esos componentes. También debe describir los componentes a un nivel de detalle que permite su construcción. El diseño de software juega un papel importante en el desarrollo de software: durante el diseño de software, ingenieros de software producen varios modelos que forman una especie de anteproyecto de la solución a implementar. Podemos analizar y evaluar estos modelos para determinar si son o no nos permitirán cumplir con los diversos requisitos.

Nosotros También puede examinar y evaluar soluciones alternativas y compensaciones. Finalmente, podemos utilizar los modelos resultantes para planificar actividades de desarrollo posteriores, como la verificación del sistema y ción validación, además de su uso como entradas y como el punto de partida de la construcción y prueba. En una lista estándar de pro- cesos de ciclo de vida del software, tales como que en la norma ISO / IEC / IEEE Std. 12207, procesos de ciclo de vida del software [2], el diseño de software consta de dos actividades que se ajustan entre el análisis de los requisitos de software y la construcción de software: • diseño de la arquitectura de software (a veces llamado diseño de alto nivel): desarrolla la estructura de alto nivel y organización del software y se identifican los distintos componentes. • Software de diseño detallado: especifica cada componente en suficiente detalle para facilitar su construcción. Esta área de conocimiento Diseño de Software (KA) no habla de todos los temas que incluye la palabra “diseño”. En la terminología de Tom DeMarco [3], los temas tratados en este acuerdo KA principalmente con D-diseño (diseño de descomposición), cuyo objetivo es el mapeo de software en piezas componentes. Sin embargo, debido a su importancia en el campo de la arquitectura de software, también vamos a tratar FP-diseño (diseño del patrón de la familia), cuyo objetivo es establecer aspectos comunes explotables en una familia de productos de software. Esta KA no se ocupa de la I-diseño (diseño invención), que se realiza generalmente durante el proceso de requisitos de software con el objetivo de alizing conceptualización y la especificación de software para satisfacer las necesidades y requerimientos descu- Ered, ya

Requisitos software 1-23 Este software de diseño KA esdeespecificación relacionada camente a los requisitos de software, Software

que este tema es considerado como parte de el proceso de requisitos (ver los requisitos de software KA). 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 de ingeniería de software y met- ods, Calidad de Software y Computación Fundaciones ciones de Kas. DISTRIBUCIÓN DE TEMAS PARA EL DISEÑO DEL SOFTWARE El desglose de temas para el Software de Diseño KA se muestra en la Figura 2.1.

la comprensión de los límites del diseño. Un número de otras nociones y conceptos También son de interés en la comprensión del diseño en su sentido general: objetivos, las limitaciones, las alternativas, las representaciones y las soluciones (véase el problema técnicas de resolución en los Fundamentos de Informática KA). 1.2. Contexto de Diseño de Software [4 *, c3]

1. Fundamentos del diseño de software La conceptos, nociones, y la terminología introducido aquí forman una base subyacente para la sub pie el papel y el alcance de diseño de software. 1.1. Conceptos generales de diseño [4 *, c1] En sentido general, el diseño puede ser visto como una forma de resolución de problemas. Por ejemplo, el con- cepto de una solución de un problema complejo sin solución definitiva, es interesante en términos de

El diseño de software es una parte importante del proceso de desarrollo de soft- ware. Para entender el papel del diseño de software, tenemos que ver cómo se integra en el ciclo de vida del software de desarrollo. Por lo tanto, es importante comprender las principales caracterís- ticas de análisis de requisitos de software, diseño de software, la construcción de software, pruebas de software, y el mantenimiento del software. 1.3. Software de Diseño de Procesos [4 *, c2] El

diseño

del

software

es

generalmente

considerado como un proceso de dos pasos:

2- Diseño de Software3

2-4 Guía SWEBOK® V3.0

• Diseño arquitectónico (también conocido como diseño de niveles altos y diseño de nivel superior) describe cómo el software está organizado en componentes. • El diseño detallado se describe el comportamiento deseado de estos componentes. La salida de estos dos procesos es un conjunto de modelos y artefactos que registran las mayores las decisiones que se han tomado, junto con una explicación de los fundamentos de cada decisión no trivial. Guardando el razonamiento, la capacidad maintain- a largo plazo del producto de software es mayor. 1.4. Principios de Diseño de Software [4] [5 *, c6, c7, c21] [6 *, c1, c8, c9] Un principio es “una completa y fundamen- tal ley, doctrina o suposición” [7]. principios de diseño de software son nociones clave que proporcionan la base para muchos diferentes enfoques de diseño de software y conceptos. diseño de software prin- cipios incluyen la abstracción; acoplamiento y de cohesión; la descomposición y la modularización; ción encapsula- / ocultar información; separación de interfaz y la implementación; suficiencia, integridad, y primitivo; y la separación de preocupaciones. • Abstracción es “una vista de un objeto que se centra en la información relevante para un propósito particular y hace caso omiso de la der restante de la información” [1] (véase Abstracción en los Fundamentos de computación KA). En el contexto del diseño de software, dos mecanismos de abstracción clave son la parametrización y la especificación. Abstracción por resúmenes ción parametrización de los detalles de sentaciones de datos sentantes de representación de los datos como parámetros con nombre. Abstracción por la especificación conduce a tres tipos principales de la abstracción: abstracción de procedimientos, la abstracción de datos, y la abstracción de control (iteración). • Acoplamiento y cohesión. El acoplamiento se define como “una medida de la interdependencia entre los módulos en un

programa de ordenador”, mientras que la cohesión se define como “una medida de la fuerza de la asociación de los elementos dentro de un módulo” [1]. • La descomposición y la modularización. posando descomposición y la modularización significa que grandes

•

•

•

•

el software se divide en una serie de componentes nombrados más pequeños que tienen interfaces bien definidas que describen las interacciones de los componentes. Por lo general, el objetivo es colocar diferentes funcionalidades y responsabilidades en diferentes componentes. Encapsulación y ocultación de la información significa la agrupación y el envasado de los detalles internos de una abstracción y haciendo esos detalles inaccesibles a entidades externas. La separación de interfaz y la implementación. La separación de interfaz y la implementación consiste en definir un componente de specify- ing una interfaz pública (conocidos por los clientes) que es independiente de los detalles de cómo se realiza el componente (ver encapsulación y ocultación de la información anterior). Suficiencia, integridad y primitivo. El logro de suficiencia y medios de integridad para garantizar que un componente de software captura todas las características importantes de una abstracción y nada más. Ness Primitivesignifica que el diseño debe estar basado en patrones que son fáciles de implementar. Separación de intereses. Una preocupación es un “área de interés con respecto a un diseño de software” [8]. Una de las preocupaciones de diseño es un área de diseño que es relevante para uno o más de sus grupos de interés. Cada vista de la arquitectura enmarca uno o más preocupaciones. La separación de las preocupaciones por los puntos de vista permite a las partes interesadas para centrarse en algunas cosas a la vez y ofrece un medio para gestionar la complejidad [9].

2. Cuestiones clave en el diseño de software Una serie de cuestiones clave debe ser tratado en el diseño de software. Algunos son problemas de calidad que todo el software debe abordar, por ejemplo, rendimiento, seguridad, fiabilidad, facilidad de uso, etc. Otra cuestión importante es cómo descomponer, organizar y componentes de software paquete. Esto es tan fundamental que todos los enfoques de diseño enmarcan en una forma u otra (véase la sección 1.4, Principios de diseño de software, y el tema

2- Diseño de 7, Software de Diseño Estrategias y Métodos). Software5 Por el contrario, otras cuestiones “trato con algún aspecto del comportamiento del software que no está en el dominio de la aplicación, pero que aborda algunas de las apoyando

2-6 Guía SWEBOK® V3.0

dominios”[10]. Estas cuestiones, que a menudo crosscut la funcionalidad del sistema, se han referido como aspectos, que “no tienden a ser unidades de softdescomposición funcional de las mercancías, sino más bien a ser propiedades que afectan al rendimiento o tics seman- de los componentes en formas sistémicas”[11]. Varias de estas cuestiones clave, transversales se tratan en las secciones siguientes (presentados en orden alfabético). 2.1. concurrencia [5 *, c18] Diseño para la concurrencia tiene que ver con el software de presentación descomposición en los procesos, tareas y discusiones y hacer frente a cuestiones relacionadas con la eficiencia, la atomicidad, sincronización y programación. 2.2. Control y manejo de Eventos [5 *, c21] Este problema de diseño se ocupa de la forma de organizar los datos y flujo de control, así como la forma de manejar los eventos reactivos y temporales a través de diversos mecanismos como la invocación implícita y devoluciones de llamadas. 2.3. Persistencia de datos

2.6. Interacción y Presentación [5 *, c16]

Este problema de diseño se ocupa de cómo estructura y organizar las interacciones con los usuarios, así como la presentación de información (por ejemplo, la separación de presentación y la lógica de negocio utilizando el enfoque del Modelo-Vista-Controlador). Tenga en cuenta que este tema no especifica detalles de la interfaz de usuario, que es la tarea de diseño de la interfaz de usuario (véase el tema 4, diseño de interfaz de usuario). 2.7. Seguridad [5 *, c12, c18] [13 *, c4] Diseño para la seguridad tiene que ver con la forma de pre ventilar la divulgación no autorizada, creación, cambio, supresión o negación del acceso a la información y otros recursos. También tiene que ver con la forma en que tolerar ataques o violaciónes relacionadas con la seguridad mediante la limitación de daños, funcionamiento continuo, acelerar la reparación y recuperación, y en su defecto y recuperar de forma segura. El control de acceso es un con- cepto fundamental de la seguridad, y también se debe garantizar el buen uso de la criptografía. 3. Estructura del software y Arquitectura

[12 *, c9] Este problema de diseño se ocupa de cómo se manipulan de datos de larga vida dle. 2.4. Distribución de Componentes [5 *, c18] Este problema de diseño se ocupa de cómo redistribuir el software en el hardware (INCLUYENDO hardware de ordenador y hardware de red), cómo se comunican los componentes, y cómo middleware se puede utilizar para tratar con el software heterogéneo. 2.5. Error y control de excepciones y la tolerancia a fallos [5 *, c18]

Este problema de diseño se ocupa de la forma de pre- ventilación, tolerar, y los errores de proceso y hacer frente a condiciones excepcionales.

En su sentido más estricto, una arquitectura de software es “el conjunto de las estructuras necesarias para razonar acerca del sistema, que comprenden elementos de software, las relaciones entre ellos, y las propiedades de ambos” [14 *]. A mediados de la década de 1990, sin embargo, la arquitectura de software comenzó a surgir como una disciplina más amplia que implicaba el estudio de las estructuras y arquitecturas de software de una manera más genérica. Esto dio lugar a una serie de conceptos interesantes sobre el diseño de software en diferentes nive- les de abstracción. Algunos de estos conceptos pueden ser útiles en el diseño arquitectónico (por ejemplo, los estilos arquitectónicos), así como durante el diseño detallado (por ejemplo, el diseño Patcharranes). Estos conceptos de diseño también se pueden utilizar para diseñar las familias de programas (también conocido como líneas de producto). Curiosamente, la mayoría de estos conceptos pueden ser vistas como intentos de describir, y por lo tanto la reutilización, el conocimiento de diseño.

2- Diseño de Software7

2-8 Guía SWEBOK® V3.0

3.1. Las estructuras arquitectónicas y puntos de vista [14 *, c1] Las diferentes facetas de alto nivel de un diseño de software pueden ser descritos y documentados. Estas facetas son a menudo llamados puntos de vista: “Una vista representa un aspecto parcial de una arquitectura de software que muestra propiedades especí- espede un sistema de software” [14 *]. Vistas pertenecen a distintos temas relacionados con el software de diseño, por ejemplo, la vista lógica (satisfaciendo los requisitos funcionales) frente a la vista de procesos (problemas de concurrencia) frente a la vista física (problemas de distribución) frente a la vista de desarrollo (como el el diseño se divide en unidades de ejecución con representación explícita de las dependencias entre las unidades). Varios autores utilizan diferentes terminologías-como frente a la conducta funcional vs. vistas de modelado de datos vs. estructurales. En resumen, un diseño de software es un artefacto multifacético producido por el proceso de diseño y generalmente compuesta de puntos de vista relativamente independientes y ortogonales. 3.2. Estilos arquitectónicos [14 *, c1, c2, c3, c4, c5] Un estilo arquitectónico es “una especialización de tipos Ment y relación ele-, junto con un conjunto de restricciones sobre la forma en que se pueden utilizar” [14 *]. Un estilo arquitectónico de este modo puede ser visto como para simplificar la organización de alto nivel del software. Varios autores han identificado una serie de grandes estilos tectural arqui-: • Las estructuras generales (por ejemplo, capas, tuberías y filtros, pizarra) • Los sistemas distribuidos (por ejemplo, cliente-servidor, tres niveles, broker) • Interactivesystems (porejemplo, Modelo View--Controller, Presentación-AbstracciónControl) • sistemas adaptables (por ejemplo, nel microker-, reflexión) • Otros (por ejemplo, por lotes, intérpretes, control pro- ceso, basado en reglas).

patrones que describen la organización de alto nivel de software, otros patrones de diseño se pueden utilizar para describir los detalles en un nivel inferior. Estos patrones de diseño de bajo nivel son los siguientes: • patrones de creación (por ejemplo, constructor, fábrica, prototipo, Singleton) • patrones estructurales (por ejemplo, adaptador, puente, compuesto, decorador, fachada, peso FLY-, Proxy) • Los patrones de comportamiento (por ejemplo, comandos, intérprete, iterador, mediador, recuerdo, observador, estado, estrategia, plantilla, visitante). 3.4. Las decisiones Arquitectura Diseño [5 *, c6] El diseño arquitectónico es un proceso creativo. Duran- te el proceso de diseño, los diseñadores de software tienen que tomar una serie de decisiones fundamentales que afectan profundamente el proceso de desa- rrollo de software y. Es útil pensar en el proceso de diseño arqui- tectural desde una perspectiva de toma de decisiones en lugar de desde una perspectiva actividad. A menudo, el impacto sobre los atributos de calidad y soluciones de compromiso entre los atributos de calidad que compiten son la base para las decisiones de diseño. 3.5. Las familias de los programas y marcos [5 *, C6, C7, C16] Un enfoque para proporcionar la reutilización de diseños y componentes de software es el diseño de las familias de programas, también conocidas como líneas de productos de software. Esto se puede hacer mediante la identificación de los puntos en común entre los miembros de estas familias y mediante el diseño de componentes reutilizables y personalizables para dar cuenta de la variabilidad entre los miembros de la familia. En la programación orientada a objetos (OO), una noción relacionada clave es que de un marco: un sistema de software parcialmente completado que puede ser extendido por instanciar apropiadamente extensiones específicas (tales como plug-ins).

3.3. Patrones de diseño

2- Diseño de

[15 *, c3, c4, c5]

Sucintamente descrito, un patrón es “una solución común a un problema común en un contexto dado” [16]. Mientras que los estilos arquitectónicos pueden ser vistos como

4. Diseño de interfaz de usuario Software9

diseño de interfaz de usuario es una parte esencial de la proceso de diseño de software. diseño de interfaz de usuario debe asegurarse de que la interacción entre el humano y la máquina proporciona para un funcionamiento eficaz

2-10

Guía SWEBOK® V3.0

y el control de la máquina. Para el software para alcanzar su pleno potencial, la interfaz de usuario debe ser diseñado para que coincida con las habilidades, experiencia y expectativas de sus usuarios previstos. 4.1. Principios generales para el usuario el diseño de interfaces [5 *, c29-web] [17 *, c2] 1 • Facilidad de aprendizaje. El software debe ser fácil de aprender para que el usuario pueda iniciar rápidamente tra- baja con el software. • la familiaridad del usuario. La interfaz debe utilizar términos y conceptos extraídos de los experimentos de los cias personas que vayan a utilizar el software. • Consistencia. La interfaz debe ser tienda de campaña consis- para que las operaciones comparables se acti- vada de la misma manera. • sorpresa mínimo. El comportamiento del software no debe sorprender a los usuarios. • Recuperabilidad. La interfaz debe proporcionar mecanismos que permitan a los usuarios a recuperarse de los errores. • guía para el usuario. La interfaz debe dar retroalimentación significativa cuando se producen errores y proporcionar ayuda contextual para los usuarios. • la diversidad de usuarios. La interfaz debe pro- mecanismos de interacción vide apropiados para diversos tipos de usuarios y para los usuarios con capacidades diferentes (ciegos, problemas de visión, sordos, ciegos al color, etc.). 4.2. Interfaz de usuario Problemas Diseño [5 *, c29-web] [17 *, c2] diseño de interfaz de usuario debe resolver dos cuestiones fundamentales: • ¿Cómo debe el usuario interactuar con el software? • ¿Cómo debe la información desde el software se presenta al usuario? diseño de interfaz de usuario debe integrar la

interacción del usuario y presentación de la información. diseño de interfaz de usuario debe considerar un compromiso entre los estilos más apropiados de interacción 1 Capítulo 29 es un capítulo basado en la web disponible en http://ifs.host.cs.standrews.ac.uk/Books/SE9/ WebChapters/.

y la presentación del software, los antecedentes y la experiencia de los usuarios de software y los dispositivos disponibles. 4.3. El diseño de las modalidades de interacción del usuario [5 *, c29-web] [17 *, c2] La interacción del usuario implica la emisión de comandos y la disponibilidad de datos asociada con el software. estilos de interacción del usuario se pueden clasificar en los estilos primarios siguien- tes: • Pregunta respuesta. La interacción es esencialmente restringido a un único intercambio de preguntas y respuestas entre el usuario y el software. El usuario envía una pregunta al software y el software devuelve la respuesta a la pregunta. • Manipulación directa. Los usuarios interactúan con los objetos en la pantalla del ordenador. La manipulación directa a menudo incluye un dispositivo señalador (como un ratón, trackball o un ger de dedos en las pantallas táctiles) que manipula un objeto e invoca las acciones que especifican lo que se debe hacer con ese objeto. • selección de menú. El usuario selecciona un comando de una lista de los comandos de menú. • Forma de relleno. El usuario llena en los campos de un formulario. A veces campos incluyen menús, en cuyo caso el formulario tiene botones de acción para que el usuario inicie la acción. • lenguaje de comandos. El usuario emite un com- mand y proporciona los parámetros relacionados para dirigir el software qué hacer. • Lenguaje natural. El usuario emite un com- mand en lenguaje natural. Es decir, el lenguaje natural es una interfaz a un lenguaje de comandos y se analiza y se traduce en comandos de soft- ware. 4.4. El diseño de la información Presentación [5 *, c29-web] [17 *, c2] presentación de la información puede ser textual o gráficamente cal en la naturaleza. Un buen diseño mantiene la presentación de información por separado de la información en

2- Diseño de sí misma. El enfoque MVC (Modelo-VistaSoftware11 Controlador) es una forma efectiva de mantener la presentación de información se separe de la información que se presenta.

2-12

Guía SWEBOK® V3.0

Software Los ingenieros también tienen en cuenta el tiempo de respuesta del software y la retroalimentación en el diseño de presentación de infor- mación. El tiempo de respuesta se mide generalmente desde el punto en el que un usuario ejecuta una cierta acción de control hasta que el software responde con una respuesta. Una indicación del progreso es deseable poder mientras que el software está preparando la respuesta. La retroalimentación puede ser proporcionado mediante la reformulación de la entrada del usuario mientras que el procesamiento se está terminando. Abstractos visualizaciones pueden ser utilizados cuando grandes cantidades de información se han de presentar. De acuerdo con el estilo de presenta- ción de la información, los diseñadores también pueden utilizar el color para mejorar la interfaz. Existen varias pautas importantes: • Limitar el número de colores utilizados. • Utilice el cambio de color para mostrar el cambio de softel estado de las mercancías. • Use códigos de colores para apoyar la tarea del usuario. • Use códigos de colores en un reflexivo y consismanera carpa. • Use colores para facilitar el acceso de las personas con ceguera o deficiencia cromática de color (por ejemplo, utilizar el cambio de la saturación del color y el brillo del color, tratar de evitar combinaciones de azul y rojo). • No dependa sólo en el color para transmitir información importante para los usuarios con capacidades diferentes (ceguera, problemas de visión, ceguera por colores, etc.). 4.5. Proceso de Interfaz de usuario Diseño [5 *, c29-web] [17 *, c2] diseño de interfaz de usuario es un proceso iterativo; prototipos de interfaz se utilizan a menudo para determinar las características, la organización, y la apariencia de la interfaz de usuario soft- ware. Este proceso incluye tres actividades principales: • análisis usuario. En esta fase, el diseñador

ana- lyzes tareas de los usuarios, la ment ENTORNO trabajo, otro software, y cómo los usuarios interactúan con otras personas. • creación de prototipos de software. El desarrollo de prototipos de software ayudan a los usuarios a guiar la evolución de la interfaz. • evaluación de la interfaz. diseñadores puede observar experiencias de los usuarios con la interfaz de evolución.

4.6. Localización e internacionalización [17 *, c8, c9] diseño de interfaz de usuario a menudo necesita considerar la internacionalización y localización, que son medios para adaptar software a los diferentes idiomas, diferencias regionales y las exigencias técnicas de un mercado objetivo. La internacionalización es el proceso de diseño de una aplicación de software para que pueda ser adaptado a diferentes idiomas y regiones sin mayores cambios de ingeniería. La localización es el proceso de adaptación de soft- ware internacionalizado para una región o idioma mediante la adiciónlocaleespecíficacomponentes FIC y traducir el texto. Localización e internacionalización deben tener en cuenta factores tales como símbolos, números rencia Cur-, el tiempo y las unidades de medida. 4.7. Metáforas y modelos conceptuales [17 *, c5] los diseñadores de interfaces de usuario pueden utilizar metáforas y modelos conceptuales para establecer correspondencias entre el software y algún sistema de referencia conocida a los usuarios en el mundo real, lo que puede ayudar a los usuarios a aprender más fácilmente y usar la interfaz. Por ejem- plo, la operación de “borrar el archivo” se puede convertir en una metáfora con el icono de un cubo de basura. En el diseño de una interfaz de usuario, ingeniería de software deben tener cuidado de no usar más de una metáfora para cada concepto. Metáforas también problemas potenciales ent PRESION con respecto a internacionalmente lización, ya que no todas las metáforas son significativa o se aplican de la misma manera dentro de todas las culturas. 5. Diseño Análisis y Evaluación de la Calidad de Software En esta sección se incluye una serie de Ysis anal- de calidad y evaluación temas que están específicamente relacionados con el diseño de software. (Véase también la calidad KA software). 5.1. Los atributos de calidad [4 *, c4] Varios atributos contribuyen a la calidad de un

2- Diseño diseño de software, incluyendo variosde“-ilities” Software13 (mantenibilidad, portabilidad, capacidad de prueba, la facilidad de uso)

2-14

Guía SWEBOK® V3.0

y “-nesses” (exactitud, robustez). Hay una interesante distinción entre la calidad atri- buye discernibles en tiempo de ejecución (por ejemplo, perFormance, seguridad, disponibilidad, funcionalidad, facilidad de uso), los que no discernible en tiempo de ejecución (por ejemplo, modificabilidad, portabilidad, reusabilidad, la capacidad de prueba), y las relacionadas con las cualidades intrínsecas de la arquitectura (por ejemplo, conceptual integri- dad, exactitud, integridad) . (Véase también la calidad KA software). 5.2. Análisis de calidad y técnicas de evaluación [4 *, c4] [5 *, c24] Varias herramientas y técnicas pueden ayudar en ing analyz- y la evaluación de la calidad del diseño de software. • Software revisiones de diseño: técnicas malized informales y lucro para determinar la calidad de los artefactos de diseño (por ejemplo, las revisiones de la arquitectura, las revisiones de diseño, y las inspecciones, las técnicas basadas en escenarios, los requisitos de rastreo). las revisiones de diseño de software también pueden evaluar la seguridad. Ayudas para la instalación, fun- cionamiento, y el uso (por ejemplo, manuales y archivos de ayuda) pueden ser revisados. • El análisis estático: static formal o semiformal análisis (no ejecutable) que puede ser utilizado para evaluar un diseño (por ejemplo, análisis de árbol a fallos o automatizada comprobación cruzada). análisis de vulnerabilidad de diseño (por ejemplo, el análisis estático de las debilidades de seguridad) puede llevarse a cabo si la seguridad es una preocupación. El análisis formal del diseño utiliza modelos matemáticos que permiten a los diseñadores predicado el comportamiento y validar el rendimiento del software en lugar de tener que depender por completo de la prueba. análisis de diseño formal puede ser utilizado para detectar errores de especificación y diseño residuales (per- HAPS causado por la imprecisión, la ambigüedad, y algunas veces otros tipos de errores). (Ver también

5.3. medidas [4 *, c4] [5 *, c24] los modelos de ingeniería de software y métodos KA). • Simulación y prototipado: técnicas dinámicas para evaluar un diseño (por ejemplo, la simulación de rendimiento o prototipos de viabilidad).

Las medidas pueden ser utilizados para evaluar o estimar cuantitativamente diversos aspectos de un diseño de software; por ejemplo, tamaño, estructura, o la calidad. La mayoría de las medidas que se han propuesto dependen del método utilizado para la producción del diseño. Estas medidas se clasifican en dos grandes categorías: • medidas (estructurada) de diseño basados en funciones: medidas obtenidas mediante el análisis fun- cional de descomposición; generalmente representado mediante un diagrama de estructura (a veces llamado un diagrama jerárquico) sobre la que se pueden calcular diversas medi- das. • medidas de diseño orientada a objetos: la estructura de diseño se representa típicamente como un diagrama de clases, en el que se pueden calcular diversas medidas. Medidas sobre las propiedades del contenido interno de cada clase también se pueden calcular. 6. Las notaciones de diseño de software Existen muchas notaciones para representar artefactos de diseño de software. Algunos se utilizan para describir la organización estructural de un diseño, otros para representar el comportamiento de soft- ware. Ciertas notaciones se utilizan sobre todo durante el diseño arquitectónico y otros, principalmente durante el diseño detallado, aunque algunas anotaciones se pueden utilizar para ambos propósitos. Además, algunas anotaciones se utilizan sobre todo en el contexto de los métodos de diseño específicos (ver tema 7, Software de Diseño Estrategias y Métodos). Tenga en cuenta que el diseño de software a menudo se logra usando notaciones múlti- ples. A continuación, se clasifican en las notaciones para describir la vista estructural (estático) frente a la vista del comportamiento (dinámico). 6.1. Las descripciones estructurales (estático Vista) [4 *, c7] [5 *, c6, c7] [6 *, c4, c5, c6, c7] [12 *, c7] [14 *, c7] Las siguientes anotaciones, en su mayoría, pero no siempre gráfica, describir y representar los aspectos estructurales de un diseño de software es que, son

2- Diseño de Software15

2-16

Guía SWEBOK® V3.0

se usa para describir los componentes principales y cómo que están interconectados (visión estática): • Descripción de la arquitectura idiomas (AVD): textual, a menudo formal, idiomas utilizados para describir la arquitectura de software en términos de componentes y conectores. • Clase y objeto diagramas: se utilizan para represen- envían un conjunto de clases (y objetos) y sus interrelaciones. • diagramas de componentes: utilizados para representar un conjunto de componentes ( “físico y reemplazar- parte capaz [s] de un sistema que [conforme] para y [proporcionar] la realización de un conjunto de caras inter” [18]) y sus interrelaciones . • tarjetas responsabilidad clase colaboradores (CRC): se utiliza para denotar los nombres de los componentes (clase), sus responsabilidades, y los nombres de sus componentes colaboradoras. • Los diagramas de despliegue: utilizados para representar un conjunto de nodos (físicas) y sus interrelaciones, y, por lo tanto, para modelar los aspectos físicos de software. • diagramas entidad-relación (ERD): se utilizan para representar los modelos conceptuales de los datos almacenados en los depósitos de información. • Descripción de la interfaz de idiomas (IDL): lenguajes de programación que se usa para definir las interfaces (nombres y tipos de operaciones exportados) de los componentes de software. • los diagramas de estructura: se utiliza para describir la estructura de los programas de llamadas (que los módulos de llamada, y se llaman por, qué otros módulos). 6.2. Las descripciones de comportamiento (vista dinámica) [4 *, c7, c13] [5 *, c6, c7] [6 *, c4, c5, c6, c7] [14 *, c8] Las siguientes notaciones y lenguajes, algunos gráfica y textual alguna, se utilizan para describir el comportamiento dinámico de los sistemas y componentes de software. Muchas de estas anotaciones se uso-ful sobre todo, pero no exclusivamente, durante el diseño detallado. Por

otra parte, las descripciones del comportamiento pueden incluir una justificación de la decisión de diseño tales como la forma de un diseño cumplirá con los requisitos de seguridad.

• diagramas de actividad: se utiliza para mostrar el flujo de control de una actividad a. Se puede utilizar para repre- actividades concurrentes resienten. • diagramas de comunicación: se utilizan para mostrar las interacciones que se producen entre un grupo de objetos; se hace hincapié en los objetos, sus enlaces, y los mensajes que intercambian en estos enlaces. • diagramas de flujo de datos (DFDs): Se utiliza para mostrar el flujo de datos entre los elementos. Un flujo de datos gramo diaofrece “una descripción basada en modeloing el flujo de información en torno a una red de elementos operativos, con cada elemento haciendo uso de o la modificación de la información que fluye en ese elemento” [4 *]. Los flujos de datos (y por tanto los diagramas de flujo de datos) se pueden utilizar para el análisis de la seguridad, ya que ofrecen identifica- ción de posibles caminos para el ataque y el cierre difusión de la información confidencial. • Las tablas de decisión y diagramas: se utilizan para REPRESENTA combinaciones complejas de condiciones y acciones. • Diagramas de flujo: se utilizan para representar el flujo de control y las acciones asociadas a realizar. • Los diagramas de secuencia: se utiliza para mostrar las interacciones entre un grupo de objetos, con énfasis en el ordenamiento hora de los mensajes transmitidos entre objetos. • transición de estado y tabla de estado diagramas: se utiliza para mostrar el flujo de control de estado a estado y cómo el comportamiento de un componente cambia sobre la base de su estado actual en una máquina de estado. • lenguajes de especificación formales: idiomas textuales que utilizan nociones básicas de matemá- ticas (por ejemplo, la lógica, set, secuencia) para definir rigurosamente y de manera abstracta interfaces de componentes de software y el comportamiento, a menudo en términos de condiciones previas y posteriores. (Véase también la Ingeniería de Software Modelos y ods met KA). • pseudo código y lenguajes de diseño de programas (PDL): lenguajes de programación como estructurados utilizados para describir, en general, en la etapa de diseño detallado, el comportamiento de un proce- dimiento o método.

2- Diseño de Software17

2-18

Guía SWEBOK® V3.0

7. El software de diseño estrategias y métodos Existen varias estrategias generales para ayudar a guiar el proceso de diseño. En contraste con las estrategias generales, los métodos son más específicos en cuanto a que proporcionan generalmente un conjunto de notaciones para ser utilizado con el método, una descripción del proceso que se utilizará cuando se sigue el método, y un conjunto de directrices para el uso del método. Tales métodos son útiles como un marco común para los equipos de ingenieros de software. (Ver también los modelos niería de Software Engineers y Métodos KA).

diseño de mediados de 1980 (sustantivo = objeto; verbo = Método; adjetivo = atributo), donde heren- cia y el polimorfismo juegan un papel clave, al campo del diseño basado en componentes, donde la formación de metain- se puede definir y se accede a (a través de la reflexión, por ejemplo). Aunque las raíces del diseño orientado a objetos provienen del concepto de abstracción de datos, diseño impulsado por la responsabilidad ha sido propuesta como un enfoque alternativo al diseño orientado a objetos. 7.4. Estructura de Datos Diseño Centrado [4 *, c14, c15]

7.1. Las estrategias generales

[4 *, c8, c9, c10] [12 *, c7]

Algunos ejemplos citados con frecuencia de las estrategias generales útiles en el proceso de diseño incluyen las estrategias de dividir-yvencerás y refinamiento paso a paso, de arriba hacia abajo frente a las estrategias de abajo hacia arriba, y las estrategias que hacen uso de la heurística, el uso de patrones y lenguajes tern PAT- y el uso de un enfoque iterativo y mentales incre-. 7.2. Función-Oriented (Estructurado) Diseño [4 *, c13] Este es uno de los métodos clásicos de diseño de software, donde los centros de descomposición en que identifique los valores las principales funciones del software y luego elab- perorando y refinarlos en una de arriba hacia abajo de forma jerárquica. Diseño estructurado se utiliza generalmente después de un análisis estructurado, produciendo de este modo (entre otras cosas) diagramas de flujo de datos y descripciones de procesos asociados. Los investigadores han propuesto diversas estrategias (por ejemplo, el análisis de la transformación, análisis de transacciones) y heurística (por ejemplo, fan-in / fan-out, el alcance de efecto vs. alcance de control) para transformar un DFD en una arquitectura de software en general representado como una diagrama de estructura.

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 primero describe las estructuras de datos de entrada y salida y luego se desarrolla la estructura de control del programa en base a estos diagramas de estructura de datos. Se han propuesto varias heurísticas para hacer frente a ejemplo especial casos-para, cuando hay una falta de coincidencia entre las estructuras de entrada y salida. 7.5. Diseño basado en componentes (CDB) [4 *, c17] Un componente de software es una unidad independiente, que tiene interfaces bien definidas y dependen- cias que pueden estar compuestos y desplegado de forma independiente. aborda cuestiones de diseño basadas en componentes relacionados con la prestación, el desarrollo y la integración de estos componentes con el fin de mejorar la reutilización. Reutilizados y off-the-shelf software com- ponentes deben cumplir mentos el mismo requisito de seguridad como un nuevo software. gestión de la confianza es un problema de diseño; componentes tratados como hav- ing un cierto grado de confiabilidad no debe depender de componentes o servicios sean menos fiables. 7.6. Otros metodos

de [5 2*, Diseño c19, c21]

7.3. Diseño Orientado a Objetos

[4 *, c16] Se han propuesto numerosos métodos de diseño de software basados en objetos. El campo ha evolucionado a partir de la orientada a objetos temprano (OO)

Software19

También existen otros enfoques interesantes (ver los modelos de ingeniería de software y métodos KA). Los métodos iterativos y adaptativas Imple- incrementos de software Ment y reducir énfasis en el requisito de software rigurosa y diseño.

2- Diseño de Software11

diseño orientada a aspectos es un método por el cual el software se construye utilizando los aspectos a las aplicará las preocupaciones transversales y extensiones que se identifican durante el proceso de los requisitos software. arquitectura orientada a servicios es una manera de construir software distribuido mediante servicios web ejecutados en ordenadores distribuidos. sistemas de soft- ware se construyen a menudo mediante el uso de servicios de diferentes proveedores porque protocolos estándar (tales como HTTP, HTTPS, SOAP) se han diseñado para soportar la comunicación de servicios y el intercambio de información de servicio.

8. Herramientas de diseño de software [14 *, c10, Apéndice A] Las herramientas de diseño de software se puede utilizar para apoyar la creación de los artefactos de diseño de software durante el proceso de desarrollo de software. Pueden apo- parte portuaria o la totalidad de las siguientes actividades: • traducir el modelo de requisitos en una la representación de diseño; • para proporcionar soporte para la representación de los componentes funcionales 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

1. Fundamentos del Diseño de Software 1.1. Diseño general Conceptos 1.2. El contexto de Diseño de Software 1.3. El Proceso de Diseño de Software 1.4. Principios de Diseño de Software 2. Cuestiones clave en el diseño de software 2.1. concurrencia 2.2. Control y Manipulación de Eventos 2.3. Persistencia de

c2 c1

C6, C7, C1, C8, c21 C9

c18 c21 C9

2.5. Error y control de excepciones y la tolerancia a fallos

c18

2.6. interacción y Presentación

c16

2.7. Seguridad

c12, c18

c4

c1 c1, c2, c3, c4, c5 c3, c4, c5

nortea Nielsen 1993 [17 *]

Alabamal en 2008 [13 *] doLEMENTOS et al. 2010 [14 *] Gamma et al. 1994 [15 *]

c3

c18

3.3. Patrones de diseño

Brookshear 2008 [12 *]

c1

datos 2.4. Distribución de Componentes

3. Estructura del software y Arquitectura 3.1. Las estructuras arquitectónicas y puntos de vista 3.2. Estilos arquitectónicos

Página-Jones 1999 [6 *]

SommervilLe 2011 [5 *]

Budgen 2003 [4 *]

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

3.4. Las decisiones Arquitectura 3.5. Las Diseño familias de los

c29web

nortea Nielsen 1993 [17 *] c2

c29web

usuario Problemas Diseño 4.3. El diseño de las modalidades de interacción del usuario 4.4. El diseño

c29web c29web

de la información Presentación 4.5. Interfaz de usuario Proceso de 4.6. Localización e diseño internacionalización

c29web C8, C9

4.7. Metáforas y modelos 5. conceptuales Análisis de

5.3. medidas

Alabamal en 2008 [13 *] doLEMENTOS et al. 2010 [14 *] Gamma et al. 1994 [15 *]

C6, C7, C16

Interfaz de Usuario 4.1. usuario generalDiseño de Interfaces Principio 4.2. Interfaz de

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

Brookshear 2008 [12 *]

c6

programas y 4. marcos Diseño de

Calidad de Software de Diseño y Evaluación 5.1. Calidad atributos

Página-Jones 1999 [6 *]

SommervilLe 2011 [5 *]

Budgen 2003 [4 *]

2- Diseño de Software13

c5

c4

c4

c24

c4

c24

Software estrategias y métodos 7.1. General Estrategias 7.2. FunciónDiseño Orientado (estructurado) 7.3. Orientado a objetos Diseño 7.4. Estructura de datosDiseño Centrado 7.5. ComponenteEl diseño basado 7.6. Otros metodos (CDB) 8. Herramientas de diseño de software

Alabamal en 2008 [13 *] doLEMENTOS et al. 2010 [14 *] Gamma et al. 1994 [15 *]

c7

C6, C7

C4, C5, C6, C7

c7

c7

C7, C13, C6, C7 c18

C4, C5, C6, C7

C8, C9, c10

c8

c7

c13 c16 c14, c15 c17 c19, c21 c10, App. UN

nortea Nielsen 1993 [17 *]

Brookshear 2008 [12 *]

descripciones de comportamiento dinámica) 7. (vista Diseño de

Página-Jones 1999 [6 *]

6. Diseño de Software notaciones 6.1. Las descripciones estructurales (estático 6.2. Las Vista)

SommervilLe 2011 [5 *]

Guía SWEBOK® V3.0

Budgen 2003 [4 *]

2-14

2- Diseño de Software15

LECTURAS Roger Pressman, Ingeniería de Software: Un Enfoque de la practicante (séptima edición) [19]. Por cerca de tres décadas, Ingeniería de Software de Roger Pressman: Enfoque para profesionales ha sido uno de los libros de texto más importantes del mundo en ingeniería de software. Cabe destacar que este libro de texto comple- mentarios a [5 *] integral presenta software de diseño, incluyendo los conceptos de diseño, diseño arquitectónico, diseño a nivel de componentes, diseño de la interfaz de usuario, diseño basado en patrones y diseño de aplicaciones web. “El 4 + 1 Ver Modelo de Arquitectura” [20]. El artículo seminal “The 4 + 1 Vista Modelo” ornoce una descripción de una arquitectura de software utilizando cinco vistas concurrentes. Los cuatro puntos de vista del modelo son la vista lógico, la vista del desarrollo, la vista del proceso, y la vista físico. Además, seleccionadocasos de usoo escenarios se utilizan para ilustrar la arquitectura. Por lo tanto, el modelo contiene 4 + 1 vistas. Las vistas se utilizan para describir el software según lo previsto por las diferentes partes interesadas, tales como los usuarios finales, desarrolladores y administradores de proyectos. Len Bass, Paul Clements, y Rick Kazman, Arquitectura de software en la práctica [21]. Este libro presenta los conceptos y las mejores ticas ticas de arquitectura de software, es decir, cómo el software está estructurado y cómo interactúan los componentes del software. Basándose en su propia experiencia, los autores cubren los temas técnicos esenciales para el diseño, especificación y validación de arquitecturas de software. También hacen hincapié en la importancia del contexto empresarial en el que se ha diseñado gran software. Su objetivo es dar a conocer la arquitectura de software en un entorno del mundo real, lo que refleja tanto las oportunidades y limitaciones que organizaciones encuentran. Este es uno de los

mejores libros disponibles en la actualidad en la arquitectura de software.

2-16

Guía SWEBOK® V3.0

Referencias

[1] ISO / IEC / IEEE 24765: 2010 Sistemas y de Ingeniería de Software-Vocabulario, ISO / IEC / IEEE 2010. [2] IEEE Std. 12207-2008 (también conocido como ISO / IEC 12207: 2008) estándar para los sistemas y software de ingeniería en software procesos de ciclo de vida, IEEE 2008. [3] T. DeMarco, “La paradoja de Arquitectura y Diseño de Software,” Conferencia Premio Stevens, 1999. [4 *] D. Budgen, Diseño de software, 2ª ed., Addison-Wesley, 2003. [5 *] I. Sommerville, Ingeniería de Software, 9ª ed., Addison-Wesley, 2011. [6 *] M. Página-Jones, Fundamentos del Diseño orientado a objetos en UML, 1st ed., Addison-Wesley, 1999. [7] Diccionario Colegiado de Merriam-Webster, ed 11., 2003. [8] IEEE Std. 1069-2009 Estándar de Información Descripción Diseño Tecnología-diseño de sistemas en software, IEEE, 2009. [9] ISO / IEC 42010: 2011 Sistemas y Prácticas de Ingeniería de Software recomendado para la descripción arquitectónica de los sistemas intensivos Software-, ISO / IEC 2011. [10] J. Bosch, Diseño y Uso de Software Arquitecturas: La adopción y el desarrollo de un enfoque Producto-Línea, ACM Press, 2000. [11] G. Kiczales et al., “Programación orientada a aspectos,” Proc. Conf Europea 11. Programación orientada a objetos (ECOOP 97), Springer, 1997.

2- Diseño de Software17

[12 *] JG Brookshear, Ciencias de la Computación: Una visión general, 10ª ed, Addison-Wesley, 2008.. [13 *] JH Allen et al, software de seguridad Ingeniería:. Guía para los gerentes de proyecto, AddisonWesley, 2008. [14 *] P. Clements et al., el software de documentación: Arquitecturas. Vistas y más allá, 2ª ed, Pearson Education, 2010. [15 *] E. Gamma et al, patrones de diseño:.. Elementos de software orientado a objetos reutilizables, 1st ed, Addison-Wesley Professional, 1994. [16] I. Jacobson, G. Booch, Rumbaugh y J., El proceso de desarrollo de software unificado, Addison-Wesley Professional, 1999.

[17 *] J. Nielsen, Ingeniería de usabilidad, Morgan Kaufmann, 1993. [18] G. Booch, J. Rumbaugh, y I. Jacobson, La Guía del usuario de Lenguaje de Modelado Unificado, Addison-Wesley, 1999. [19] RS Pressman, Ingeniería de Software:. El enfoque de un practicante, 7ª ed, McGrawHill, 2010. [20] PB Kruchten, “The 4 + 1 Ver Modelo de Arquitectura,” IEEE Software, vol. 12, no. 6, 1995, pp. 42-55. [21] L. Bass, P. Clements, y R. Kazman, Arquitectura de Software en la práctica, 3ª ed., Addison-Wesley Professional, 2013.

CAPÍTULO 3 CONSTRUCCIÓN DEL SOFTWARE SIGLAS API

de programación de aplicaciones Interfaz

COTS GUI

Commercial Off-The-Shelf Interfaz gráfica del usuario

IDE

Desarrollo integrado Ambiente

Dios mio grupo de administración de objetos Interfaz de sistema operativo POSIX portátil TDD UML

Desarrollo basado en pruebas Lenguaje de Modelado Unificado

INTRODUCCIÓN La construcción software término se refiere a la creación detallada de software que trabaja a través de una combinación de codificación, verificación, la unidad de pruebas, las pruebas de integración, y la depuración. El área de conocimiento Construcción de Software (KA) está vinculado a todos los demás Kas, pero está más fuertemente relacionada con Diseño de software y pruebas de software debido a que el proceso de construcción de software consiste en el diseño de software y pruebas significativa. El proceso utiliza la salida de diseño y proporciona una entrada a la prueba ( “diseño” y “prueba” en este caso se hace referencia a las actividades, no la KAS). IES Boundar- entre el diseño, construcción y pruebas (si alguna) variarán dependiendo de los procesos del ciclo de vida del software que se utilizan en un proyecto. Aunque algunos de diseño detallado se puede realizar antes de la construcción, tanto el trabajo

de diseño se realiza durante la actividad de construcción. Por lo tanto, la construcción del software KA está estrechamente vinculado con el software de diseño KA. A lo largo de la construcción, tanto los ingenieros de software de prueba de unidad e integración a prueba su trabajo.

2- Diseño gestión de proyectos, en la medida endela gestión Software19 de cons- trucción puede presentar retos considerables.

Por lo tanto, la construcción del software KA está estrechamente vinculada a la Prueba de Software KA también. construcción de software normalmente produce el mayor número de elementos de configuración que necesitan ser administrados en un proyecto de software (archivos de código fuente, documentación, casos de prueba, y así sucesivamente). 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 calidad del software es importante en todos los Kas, código es la entrega definitiva de un proyecto de software, y por lo tanto la calidad del software KA está estrechamente ligada a la construcción del software KA. Dado que el software la construcción requiere el conocimiento de algoritmos y de las prácticas de codificación, que está estrechamente relacionado con la Informática Fundamentos KA, que se ocupa de la informática Foundation ciones que apoyan el diseño y construcción de productos de software. También está relacionada con la

DISTRIBUCIÓN DE TEMAS PARA LA CONSTRUCCIÓN DEL SOFTWARE La figura 3.1 muestra una representación gráfica de la descomposición de nivel superior de la avería para la Construcción de Software KA. 1. Fundamentos de software Construcción fundamentos incluyen • • • • •

de

construcción

de

software

minimizando la complejidad anticipar el cambio la construcción para la verificación reutilizar normas de construcción.

Los primeros cuatro conceptos se aplican al diseño, así como a la 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 33

estos conceptos y describen cómo se aplican a la construcción. 1.1. Complejidad minimizando [1 *] La mayoría de las personas están limitadas en su capacidad de mantener estructuras complejas e información en sus memorias de trabajo, especialmente durante un período largo, de tiempo. Esto demuestra ser un factor importante que influye en cómo las personas transmiten intención de com- putadoras y conduce a una de las unidades más fuertes en la construcción de software: minimizando compleji- dad. La necesidad de reducir la complejidad se aplica esencialmente a todos los aspectos de la construcción de software y es particularmente crítico para las pruebas de las construcciones de software. En la construcción de software, complejidad reducida se logra a través enfatizando la creación de código que es simple y fácil de leer en lugar de inteligente. Esto se logra a través de hacer uso de las normas (véase la sección 1.5, Normas de Construcción), el diseño modular (ver sección 3.1, Diseño Construcción), y otras numerosas técnicas específicas (ver sección 3.3, Coding). También es apoyado por técnicas de calidad centrado con la construcción (ver sección 3.7, Construcción de Calidad). 1.2. pronóstico del cambio

[1 *] La mayoría del software va a cambiar con el tiempo, y el anticipación de los cambios a muchos aspectos de la construcción de software; los cambios en los entornos en los que opera el software también afectan al software de diversas maneras. Anticipar el cambio ayuda a los ingenieros de software construir software extensible, lo que significa que pueden mejorar un producto de software sin interrumpir la estructura subyacente. cambio Anticipando es apoyado por muchas técnicas especí- espe- (véase la sección 3.3, Coding).

pruebas independientes y las actividades operacionales. Las técnicas específicas que apoyan la construcción para la verificación incluyen siguiendo los estándares de codificación para apoyar las revisiones de código y pruebas de unidad, la organización de código para apoyar pruebas automatizadas, y restrict- ing el uso de estructuras len- guaje complejas o difíciles de comprender, entre otros. 1.4. Reutilizar [2 *] Reutilización refiere al uso de los activos existentes en la solución de diferentes problemas. En la construcción de software, los activos ical typ- que se reutilizan incluyen bibliotecas, módu-, componentes, código fuente, y off-the-shelf comercial (COTS) activos. La reutilización es mejor ticas ticed sistemáticamente, de acuerdo con un proceso bien definido y repetible. reutilización sistemática puede permitir significativo de la productividad de software, la calidad y mejora de los costes. Reutilización tiene dos facetas estrechamente relacionados: “la construcción para la reutilización” y “reutilización construcción con” Los antiguos medios para crear activos de software reutilizables, mientras que el segundo medio para la reutilización de activos de software en la construcción de una nueva solución. Reutilización menudo trasciende los límites de los proyectos, lo que significa activos reutilizados se pueden construir en otros proyectos u organizaciones. 1.5. Normas de construcción [1 *]

1.3. La construcción de Verificación [1 *] La construcción de medios de verificación de construcción de software de tal manera que los fallos pueden ser lectura ily encontrados por los ingenieros de software de escritura del software, así como por los probadores y usuarios durante

3-4 Guía V3.0de LaSWEBOK® aplicación

Dardos desarrollo dares externos o internos durante la construcción ayuda a lograr los objetivos de un pro- yecto para la eficiencia, la calidad y el costo. En concreto, las opciones de progra- permisible subconjuntos del lenguaje Ming y normas de uso de ayudas son importantes para lograr una mayor seguridad. Normas que afectan directamente a problemas de construcción incluyen • métodos de comunicación (por ejemplo, Standards para formatos de documentos y contenidos) • lenguajes de programación (por ejemplo, las normas len- guaje para lenguajes como Java y C ++) • los estándares de codificación (por ejemplo, los estándares para las convenciones de nomenclatura, el diseño y la sangría) • plataformas (por ejemplo, los estándares de interfaz de llamadas al sistema operativo)

Construcción de Software 35

• herramienta (por ejemplo, normas para anotaciones esquemáticas como UML (Unified Modeling Language)). El uso de estándares externos. La construcción depende de la utilización de estándares externos para lenguajes de construcción, herramientas de construcción, interfaces técnicas, y las interacciones entre el software de construcción KA y otros KAs. Normas proceden de numerosas fuentes, incluyendo especificaciones de la interfaz de hardware y software (como el Grupo de Gestión de Objetos (OMG)) y las organizaciones internacionales (tales como el IEEE o ISO). El uso de estándares internos. Las normas también pueden ser creados sobre una base de organización a nivel corpo- rativa o para su uso en proyectos específicos. Estas normas apoyan la coordinación de las relaciones de grupo activi, lo que minimiza la complejidad, la anticipación del cambio, y la construcción para su verificación. 2. Construcción de la gestión 2.1. Construcción de Modelos de Ciclo de Vida [1 *] Numerosos modelos han sido creados para el desarrollo de software; algunos hacen hincapié en la construcción más que otros. Algunos modelos son más lineal desde el punto cons- trucción de vista, tales como la cascada y modelos de ciclo de vida de la entrega por etapas. Estos modelos tratan de la construcción como una actividad que se produce sólo después del trabajo prerrequisito importante ha sido com- pletó-requisitos detallados incluyendo el trabajo, un extenso trabajo de diseño y planificación detallada. Los enfoques más lineales tienden a enfatizar las actividades que preceden a la construcción (los requisitos y diseño) y para crear menticias SEP más claras entre las actividades. En estos modelos, el énfasis principal de la construcción puede ser de codificación. Otros modelos son más iterativo como el prototipado evolutivo y desa- rrollo ágil. Estos enfoques tienden a tratar la cons- trucción como una actividad que se produce simultáneamente con otras actividades de desarrollo de software

(incluyendo los requisitos, el diseño y la planificación) o que los solapamientos. Estos enfoques tienden a diseño, codificación, y las actividades de prueba mezclar, y que a menudo tratan la combinación de actividades como la construcción (ver

3-6 Guía SWEBOK® V3.0

el Software de Gestión y Procesos de Software KAs). En consecuencia, lo que se considera que es “cons- trucción” depende en cierta medida en el modelo de ciclo de vida utilizado. En general, la construcción de software es en su mayoría codificación y depuración, pero también implica la planificación de la construcción, diseño detallado, las pruebas unitarias, pruebas de integración, y otras actividades. 2.2. Ordenación de la Edificación [1 *] La elección del método de construcción es un aspecto clave de la actividad de la construcción-planificación. La elección del método de construcción afecta el grado en que se realizan los requisitos previos de la construcción, el orden en que se realizan, y el grado en que deben ser completados antes de que comience el trabajo de construcción. El enfoque de la construcción afecta la capacidad del equipo de pro- yecto para reducir la complejidad, anticiparse a los cambios, y construir para su verificación. Cada uno de estos objetivos también pueden ser tratadas en el pro- ceso, requisitos y diseño de los niveles, pero que se verá influido por la elección del método de construcción. planificación de la construcción también define el orden en que se crean los componentes e integrados, la estrategia de integración (por ejemplo, por etapas o integración incremental), los procesos de gestión de calidad de software, la asignación de la asignación de tareas a los ingenieros de software específicos, y otras tareas, de acuerdo con el método elegido. 2.3. Medición de la construcción [1 *] Numerosas actividades de construcción y los artefactos se pueden medir, incluyendo el código desarrollado, código modificado, reutilizado código, el código destruida, código de complejidad, las estadísticas de inspección de código, culpa y culpa-fix-encontrar tarifas, el esfuerzo y la programación. Estos surements Measure pueden ser útiles para los propósitos de la gestión de la construcción, lo que garantiza la calidad durante la construcción, y mejorar el proceso de construcción, entre otros usos (véase la Ingeniería de Procesos de

Software KA para más información sobre la medición).

Construcción de Software 37

3. Consideraciones prácticas La construcción es una actividad en la que el ingeniero de software tiene que hacer frente a las limitaciones del mundo real a veces caóticos y cambiantes, y él o ella debe hacerlo con precisión. Debido a la influencia de las restricciones del mundo real, la construcción está más impulsado por consideraciones prácticas que algunos otros Kas, e ingeniería de software es quizás lo más oficio- como en las actividades de construcción. 3.1. Diseño de la construcción [1 *] Algunos proyectos de diseño asignan considerable activi- dad a la construcción, mientras que otros asignan diseño a una fase centrada explícitamente en el diseño. Independien- temente de la asignación exacta, algún trabajo de diseño detallado se producirá a nivel de la construcción, y que el trabajo de diseño tiende a ser dictado por las limitaciones impuestas por el problema del mundo real que está siendo tratado por el software. Al igual que los trabajadores de la construcción la construcción de una estructura físi- cas deben hacer modificaciones a pequeña escala para dar cuenta de las lagunas no previstos en los planes del constructor, trabajadores de la construcción de software deben hacer modificaciones en una escala más pequeña o más grande para dar cuerpo a los detalles del diseño de software durante la construcción . Los detalles de la actividad de diseño a nivel cons- trucción son esencialmente el mismo que el descrito en el Diseño de Software KA, pero se aplican en una escala más pequeña de algoritmos, estructuras de datos y las interfaces. 3.2. Idiomas de construcción [1 *] lenguas de construcción incluyen todas las formas de comunicación mediante el cual un ser humano puede especificar una solución de un problema ejecutable a un problema. idiomas cons- trucción y sus implementaciones (por ejemplo, los compiladores) pueden afectar a los atributos de calidad de software de rendimiento, fiabilidad, rentabilidad por-, y así

sucesivamente. Pueden ser graves contribuyentes al vulnerabilidades de seguridad. El tipo más simple del lenguaje construcción es un lenguaje de configuración, en la que los ingenieros de software elegir entre un conjunto limitado de opciones predefinidas para crear un software nuevo o personalizado

3-8 Guía SWEBOK® V3.0

instalaciones. Los archivos de configuración basados en texto que se utilizan tanto en los sistemas operativos Windows y Unix son ejemplos de esto, y las listas de selección de estilo de menú de algunos generadores de programas constituiría, otro ejemplo de un lenguaje de configuración. idiomas Toolkit se utilizan para construir aplica- ciones de elementos de juegos de herramientas (series integradas de partes reutilizables específicos de la aplicación); que son más complejos que los idiomas de configuración. idiomas Toolkit pueden definirse explícitamente como lenguajes de programación de aplicaciones, o las aplica- ciones pueden simplemente estar implicados por el conjunto de un conjunto de herramientas de interfaces. Los lenguajes de script son tipos de uso común de los lenguajes de programación de aplicaciones. En algunos lenguajes de script, guiones son llamados archivos por lotes o macros. Programación idiomas son el tipo más flexible de las lenguas de construcción. También contienen la menor cantidad de información sobre áreas específicas de aplicación y desarrollo de procesos-, por lo tanto, requieren más entrenamiento y habilidad para utilizar con eficacia. La elección del lenguaje de programación puede tener un gran efecto sobre la probabilidad de vulnerabilidades de ser introducido durante coding- por ejemplo, el uso acrítico de C y C ++ son opciones cuestionables desde un punto de vista de la seguridad. Hay tres tipos generales de notación que se utiliza para lenguajes de programación, es decir, • lingüística (por ejemplo, C / C ++, Java) • formales (por ejemplo, Evento-B) • visual (por ejemplo, MatLab). notaciones lingüísticas se distinguen en parti- cular por el uso de cadenas de texto para representar construcciones de software complejos. La combinación de cadenas de texto en patrones puede tener una sintaxis frase similar. Si se usa adecuadamente, cada uno de tales cadena debe tener una fuerte connotación semántica proporcionar una comprensión intuitiva inmediata de lo que sucederá cuando el software se ejecuta trucción ción. Las notaciones formales depender menos intuitiva, every- significados día de palabras y

cadenas de texto y más en las definiciones respaldadas por definiciones precisas, de forma ambigua unidades organizativas y formales (o matemáticos). notaciones formales de construcción y ods met formales están en la base semántica de la mayoría de las formas de

Construcción de Software 39

notaciones de programación del sistema, donde la precisión, comportamiento en el tiempo, y la capacidad de prueba son más importantes que la facilidad de mapeo en lenguaje natural. Porconstrucciones mal también utilizan formas definidas con precisión de la combinación de símbolos que evitan la ambigüedad de muchas construcciones de lenguaje natural. Visual notaciones confiar mucho menos en las anotaciones textuales de construcción lingüística y formal y en lugar de confiar en la interpretación visual directa y la colocación de las entidades visuales que representan el software subyacente. Visual de la construcción tiende a ser algo limitado por la dificultad de hacer declaraciones “complejas” utilizando sólo el Organizar- ción de los iconos en una pantalla. Sin embargo, estos iconos pueden ser herramientas poderosas en los casos en que la tarea de programación principal es simplemente para construir y “ajustar” una interfaz visual de un programa, el comportamiento detallado de los cuales tiene una definición subyacente. 3.3. Codificación [1 *] Las siguientes consideraciones se aplican a la actividad de codificación construcción software: • Las técnicas para crear el código fuente comprensible, incluyendo las convenciones de nomenclatura y el diseño de código fuente; • El uso de clases, tipos enumerados, variables, constantes con nombre, y otras entidades similares; • El uso de estructuras de control; • Manipulación de las condiciones-tanto de error anticipó y excepcional (entrada de datos erróneos, por ejemplo); • Prevención de las infracciones a nivel de código de seguridad (desbordamientos de búfer o límites índice de matriz, por ejemplo); • El uso de recursos a través de uso de mecanis- y disciplina de exclusión mecapara acceder a recursos en serie reutilizables (incluyendo hilos y cerraduras de base de datos); • Organización del código fuente (en Estado-

3.4. Prueba de la construcción

[1 *]

mentos, rutinas, clases, paquetes, u otras estructuras); • documentación de código; • Código de sintonía,

3-10 Guía SWEBOK® Construcción implicaV3.0 dos

formas de pruebas, que a menudo son realizadas por el Neer niería de software que escribió el código: • Examen de la unidad • Pruebas de integración. El propósito de las pruebas de la construcción es el de reducir la brecha entre el momento en que los fallos se insertan en el código y el momento cuando se detectan los fallos, reduciendo así el coste incurrido para solucionarlos. En algunos casos, los casos de prueba se escriben después del código ha sido escrito. En otros casos, los casos de prueba pueden crearse antes de código está escrito. pruebas de construcción típicamente implica un subconjunto de los diferentes tipos de pruebas que se describen en el Testing de Software KA. Por ejemplo, las pruebas de construcción no suelen incluir las pruebas del sistema, las pruebas alfa, pruebas beta, pruebas de estrés, pruebas de configuración, las pruebas de usabilidad, u otros tipos más especializados de la prueba. Dos normas se han publicado sobre el tema de las pruebas de la construcción: Norma IEEE 829-1998, Norma IEEE para la Documentación de software de prueba, y la norma IEEE 10081987, IEEE estándar para el software de pruebas unitarias. (Ver secciones 2.1.1., Pruebas unitarias, y 2.1.2., Pruebas de integración, en el KA de Pruebas de Software para el material de referencia más especializado.) 3.5. Construcción de Reutilización [2 *] Construcción para su reutilización crea software que tiene el potencial para ser reutilizado en el futuro para el presente proyecto u otros proyectos que tienen una base amplia, la perspectiva multisistémica. Construcción nueva utilización se basa generalmente en el análisis y diseño de variabilidad. Para evitar el problema de clones de código, se desea encapsular fragmentos de código reutilizables en bibliotecas o componentes bien estructuradas. Las tareas relacionadas con la construcción de software para reutilizar durante la codificación y las pruebas son los siguientes:

Construcción de Software 311

• aplicación variabilidad con mecanismos tales como la parametrización, la compilación condicional, patrones de diseño, y así sucesivamente. • encapsulación variabilidad para que los activos soft- ware fácil de configurar y personalizar. • Prueba de la variabilidad proporcionada por los activos de software capaces Reus-. • Descripción y publicación de soft- ware activos reutilizables. 3.6. Construcción con reutilización [2 *] Construcción con reutilización significa crear un nuevo software con la reutilización de activos de software existentes. El método más popular de reutilización es la reutilización de código de las bibliotecas proporcionadas por el len- guaje, la plataforma, las herramientas que se utiliza, o un repositorio organizativa. Los apartes de estos, las aplica- ciones desarrolladas ampliamente hoy hacen uso de muchas bibliotecas de código abierto. Reutilizados y off-the-shelf software a menudo tienen la misma o mejor calidad requisitos como nuevo desarrollo de software (por ejemplo, nivel de seguridad). Las tareas relacionadas con la construcción de software con reutilizar durante la codificación y las pruebas son los siguientes: • La selección de las unidades reutilizables, Data- bases, procedimientos de prueba, o datos de prueba. • La evaluación de código o prueba de reutilización. • La integración de los activos de software reutilizables en el software actual. • La presentación de la información reutilización de código nuevo, los procedimientos de prueba o datos de prueba. 3.7. construcción de Calidad

[1 *]

Además de los fallos que resultan de los requisitos y de diseño, defectos introducidos durante la construcción pueden dar lugar a problemas graves de calidad -por ejem- plo, las vulnerabilidades de seguridad. Esto incluye no

• pruebas unitarias y pruebas de integración (ver sec- ción 3.4, Pruebas de construcción) • prueba de primer desarrollo (ver sección 2.2 en el Pruebas de software KA) • uso de afirmaciones y programación defensiva • depuración • inspecciones • revisiones técnicas, incluyendo comentarios enteder-ori- seguridad (ver sección 2.3.2 en la calidad KA Cesión de Software) • el análisis estático (véase la sección 2.3 de la Calidad KA Soft- Ware) La técnica o técnicas específicas seleccionadas dependen de la naturaleza del software que se con- structed, así como en el conjunto de habilidades de los ingenieros de software que realizan la construcción activi- lazos. Los programadores deben conocer las buenas prácticas y comunes ejemplo vulnerabilidadespara, a partir de listas ampliamente reconocidos acerca de las vulnerabilidades comunes. análisis estático automatizado de código para las debilidades de seguridad está disponible para varios lenguajes de programación mon com- y se puede utilizar en proyectos críticos para la seguridad. actividades de construcción de calidad diferenciada se ated de otras actividades de calidad por su enfoque. actividades de calidad de la construcción se centran en código y artefactos que están estrechamente relacionados con código como el diseño, a diferencia de otros artefactos que están conectados directamente al menos el código, como los requisitos, diseños de alto nivel, y los planes detallados. 3.8. Integración [1 *]

Una actividad clave durante la construcción es el ción integración de rutinas construidos individualmente, clases, componentes y subsistemas en un único sissólo los fallos en la funcionalidad de seguridad, sino también fallos en otras zonas que permiten la anulación de esta funcionalidad y otras debilidades de seguridad o violaciónes. Existen numerosas técnicas para asegurar la

3-12

Guía cali-SWEBOK® dad de V3.0 código

como se construye. Las técnicas primarios utilizados para la calidad de la construcción incluyen

TEM. Además, puede necesitar ser integrado con otros sistemas de software o hardware de un sistema de software en particular. Las preocupaciones relacionadas con la integración de la construcción incluyen la planificación de la secuencia en la que se integrarán los componentes, la identificación de lo que se necesita utensilios de hardware, creando un andamio para apoyar versiones provisionales del software, para determinar el grado de la prueba y la calidad del trabajo realizado en los componentes antes de que sean integrada, y

Construcción de Software 313

la determinación de puntos en el proyecto en el que se prueban versiones provisionales del software. Los programas pueden estar integrados por medio de uno u otro la gradual o el enfoque incremental. la integración por etapas, también llamada integración “big bang”, implica retrasar la integración de las partes componentes de software hasta que todas las partes destinados a la liberación de una versión se han completado. la integración incremental se cree que ofrecen muchas ventajas sobre el tra- dicional por fases de integración, por ejemplo, la ubicación de error más fácil, un mejor seguimiento de los avances, a principios de la entrega del producto, y la mejora de relaciones con los clientes. En la integración gradual, el ERS desarrollos escribir y probar un programa en pequeños trozos y luego se combinan las piezas una a la vez. infraestructura de pruebas adicionales, tales como talones, los controladores y los objetos de imitación, por lo general se necesita para permitir la integración incrementales. Con la construcción y la integración de una unidad a la vez (por ejemplo, una clase o compo- nente), el proceso de construcción pueden proporcionar información temprana a los desarrolladores y clientes. Otras ventajas de la integración incrementales incluyen la ubicación más fácil error, la mejora de progreso Monitor-ing, unidades probado más completamente, y así sucesivamente.

4.2. Orientado a Objetos Problemas de tiempo de ejecución

[1 *]

lenguajes orientados a objetos soportan una serie de mecanismos de ejecución que incluye el polimorfismo y la reflexión. Estos mecanismos de ejecución aumentan la flexibilidad y adaptabilidad de los programas orientados a objetos. El polimorfismo es la capacidad de un lenguaje para apoyar las operaciones generales con- sin saber hasta que el tiempo de ejecución qué tipo de objetos concretos del software incluirá. Debido a que el programa no conoce el tipo exacto de los objetos de antemano, el comportamiento exacto está determinado en tiempo de ejecución (unión llamada dinámica). La reflexión es la capacidad de un programa para observar y modificar su propia estructura y el comportamiento en tiempo de ejecución. La reflexión permite la inspección de las clases, interfaces, campos y métodos en tiempo de ejecución con- sin saber sus nombres en tiempo de compilación. También permite la instanciación en tiempo de ejecución de nuevos objetos y invocación de métodos que usan nombres de clase y método con parámetros. 4.3. Parametrización y Genéricos

[4 *] 4. Tecnologías de la construcción 4.1. Diseño y Uso de la API

[3 *]

Una interfaz de programación de aplicaciones (API) es el conjunto de firmas que se exportan y disponibles para los usuarios de una biblioteca o un marco para escribir sus aplicaciones. Además de las firmas, una API siempre debe incluir declaraciones sobre efectos y / o comportamientos (es decir, su semántica) del programa. diseño de la API debe tratar de hacer la API fácil de aprender y memorizar, dar lugar a un código legible, ser difícil de mal uso, fácil de extender, ser completa, y mantener la compatibilidad con versiones anteriores. Como

tipos parametrizados, también conocidos como genéricos (ADA, Eiffel) y plantillas (C ++), permiten la definición de un tipo o clase sin especificar todos los otros tipos que utiliza. Los tipos no especificados son las API generalmente duran más que sus implementaciones para una biblioteca o un marco ampliamente utilizado, se desea que la API sea sencillo y se mantiene estable para facilitar el desarrollo y mantenimiento de las aplicaciones cliente. uso API implica los procesos de ING Seleccionar-, el aprendizaje, las pruebas, la integración, y posiblemente se extiende API proporcionadas por una biblioteca o trabajo marco (véase la sección 3.6, de la construcción con la reutilización).

3-14 Guía SWEBOK® V3.0 suministrado como parámetros

en el punto de uso. Tros eterized tipos proporcionan una tercera vía (además de la herencia de clases y composición de objetos) para com- representar comportamientos de software orientado a objetos. 4.4. Afirmaciones, Diseño Por contrato, y programación defensiva [1 *] Una afirmación es un predicado ejecutable que se coloca en un programa de por lo general una rutina o macro- que permite controles de tiempo de ejecución del programa. ciones aseveraciones son especialmente útiles en progra- mas alta fiabilidad. Ellos permiten a los programadores para eliminar más rápidamente los supuestos de interfaz que no coinciden, los errores que se arrastran en cuando se modifica el código, y así sucesivamente. Las afirmaciones se obtiene generalmente en el código en tiempo de desarrollo y posteriormente se compilan fuera del código para que no se degradan el rendimiento.

Construcción de Software 315

Diseño de contrato es un enfoque de desarrollo en los que las condiciones previas y condiciones posteriores se incluyen para cada rutina. Cuando se utilizan condiciones previas y condiciones posteriores, se dice que cada clase de rutina o para formar un contrato con el resto del programa. Por otra parte, un contrato proporciona una especificación precisa de la semántica de una rutina, y por lo tanto ayuda a la comprensión de su comportamiento. Diseño de contrato se cree que mejora la calidad de la construcción de software. La programación defensiva medios para proteger a una rutina de ser roto por las entradas no válidas. Las formas más comunes para manejar las entradas no válidas incluyen la comprobación de los valores de todos los parámetros de entrada y decidir cómo manejar las malas entradas. ciones aseveraciones son de uso frecuente en la programación defensiva para comprobar los valores de entrada. 4.5. Control de errores, control de excepciones, y la tolerancia a fallos [1 *] La forma en que se manejan los errores afecta la capacidad del software para satisfacer los requisitos relacionados con Ness correcta-, robustez, y otros atri- buye no funcionales. Las afirmaciones se utilizan a veces para comprobar si hay errores. -Están mercancías también se utilizan otras técnicas-tales de manejo de errores como devolver un valor neutro, sustituyendo la siguiente pieza de datos válidos, registrando un mensaje de advertencia, devolver un código de error, o el cierre de la soft-. Las excepciones se utilizan para detectar y errores de proceso o acontecimientos excepcionales. La estructura básica de una excepción es que un usos de rutina throw para lanzar una excepción detectada y un bloque de manipu- manipulan de excepción se captura la excepción en un bloque try-catch. El bloque trycatch puede procesar la condición errónea de la rutina o puede devolver el control a la rutina de llamada. políticas de manejo de excepciones deben ser cuidadosamente diseñadas seguimiento ing principios comunes como la inclusión en el mensaje de excepción toda la información que llevó a la excepción, evitando los bloques catch vacías, conociendo las

excepciones al código de la biblioteca lanza, tal vez la construcción de un reportero de excepción centralizada, y la normalización de la el uso del programa de excepciones. tolerancia a fallos es una colección de técnicas que aumentan la fiabilidad del software mediante la detección de errores y, a continuación se recupera de ellos si es posible

3-16

Guía SWEBOK® V3.0

o que contiene sus efectos si la recuperación no es posi- ble. Las estrategias de tolerancia a fallos más comunes incluyen copias de seguridad y de reintentar, utilizando el código auxiliar, utilizando algoritmos de votación, y la sustitución de un valor erróneo con un valor falso que tendrá un efecto benigno. 4.6. ejecutable modelos [5 *] ejecutable modelos abstraer los detalles de los lenguajes de programación específicos y las decisiones sobre la organización del software. Diferente de los modelos tradicionales de software, una especificación construido en un lenguaje de modelado ejecutable como xUML (UML ejecutable) se puede implementar en varios entornos de software sin cambios. Un compilador ejecutable-modelo (transformador) puede convertir un modelo ejecutable en una aplicación utilizando un conjunto de decisiones sobre el hardware de destino y el entorno de software. Por lo tanto, la construcción de modelos ejecutables puede considerarse como una forma de construir software ejecutable. ejecutable modelos son una fundación apoyando actividades de gestión de la arquitectura dirigida por modelos (MDA) inicia- tiva del Object Management Group (OMG). Un modelo ejecutable es una forma de especificar completamente un modelo independiente de la plataforma (PIM); un PIM es un modelo de una solución a un problema que no se basa en ningún tecnologías de implementación. A continuación, un modelo de plataforma específica (PSM), que es un modelo que contenga los detalles de la tación aplica-, puede ser producido por tejer el PIM y la plataforma sobre la que se basa. 4.7. Las técnicas de construcción basadas en tablas de base estatal y [1 *] de programación basado en el estado, o la programación basada en autómatas, es una tecnología de programación utilizando máquinas de estado finito para describir comportamientos del programa. Los gráficos de transición de una máquina de estados se utilizan en todas las etapas de desa- rrollo de software (especificación, implementación, ging debug-, y documentación). La idea principal es la construcción de programas de ordenador de la misma manera se realiza la automatización

de procesos tecnológicos. la programación basada en el estado se suele combinar

Construcción de Software 317

con la programación orientada a objetos, formando un nuevo enfoque compuesto llamado, programación orientado a objetos basado en estado. Un método de la tabla impulsado es un esquema que utiliza tablas para buscar información en lugar de utilizar los estados lógicos (por ejemplo, si y caja). Se utiliza en las circunstancias apropiadas, claves basadas en tablas es más simple que la lógica complicada y más fácil de modificar. Al utilizar métodos basadas en tablas, el programador se centra en dos cuestiones: qué tipo de información a almacenar en la tabla o tablas, y cómo efi- ciente información de acceso en la tabla. 4.8. Configuración de tiempo de ejecución y la internacionalización [1 *] Para lograr una mayor flexibilidad, un programa a menudo se construye para soportar el tiempo de unión finales de sus Ables variabilidad. configuración de ejecución es una técnica que une los valores de variables y ajustes del programa cuando el programa se está ejecutando, por lo general mediante la actualización y la lectura de los archivos de configuración en un modo justo a tiempo. La internacionalización es la activi- dad técnica de la preparación de un programa, generalmente software interactivo, para soportar múltiples lugares. La actividad correspon- diente, localización, es la actividad de la modificación de un programa de apoyo a un idioma local específica. El software interactivo puede contener ens doz- o cientos de instrucciones, indicaciones de estado, mensajes de ayuda, mensajes de error, y así sucesivamente. Los procesos de diseño y construcción deben dar cabida a temas de cuerda y de juego de caracteres que incluye el cual el conjunto de caracteres se va a utilizar, qué tipo de cadenas se usan, cómo mantener las cuerdas sin cambiar el código, y traducir las cadenas en diferentes idiomas con un impacto mínimo en el código de procesamiento y la interfaz de usuario. 4.9. Procesamiento de la entrada GramáticaBasado [dieciséis*]

procesamiento de entrada basado en la gramática implica el análisis de sintaxis, o análisis sintáctico, de la corriente de token de entrada. Se trata de la creación de una estructura de datos (llamado un árbol de análisis sintáctico o árbol de sintaxis) que 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

3-18

Guía SWEBOK® V3.0

las variables definidas por el programador que pueblan el árbol. Después de construir el árbol de análisis, el programa utiliza como entrada a los procesos computacionales. 4.10. Las primitivas de concurrencia [7 *] Una primitiva de sincronización es una abstracción de programación proporcionada por un lenguaje de programación o el sistema operativo que facilita rencia concurrente y sincronización. Conocidos primitivas RENCIA concurrentes incluyen semáforos, monitores y exclusiones mutuas. Un semáforo es un tipo de datos variable o extracto protegida que proporciona un simple pero útil abstracción para controlar el acceso a un recurso común por múltiples procesos o hilos en un entorno de programación concurrente. Un monitor es un tipo de datos abstractos que presenta un conjunto de operaciones definidas por el programador que se ejecutan con la exclusión mutua. Un monitor de con- tains la declaración de variables compartidas y cedimientos o funciones pro que operan en esas variables. El constructo del monitor asegura que sólo un proceso a la vez es activo dentro del monitor. Un mutex (exclusión mutua) es un sincronización primitiva que permite el acceso exclusivo a un recurso compartido por sólo un proceso o hilo en un momento. 4.11. middleware [3 *] [6 *] Middleware es una amplia clasificación de soft- ware que proporciona servicios por encima de la capa del sistema operativo todavía por debajo de la capa de programa de aplicación. Middleware puede proporcionar ERS tiempo de ejecución contención de componentes de software para proporcionar el paso de mensajes, la persistencia, y una ubicación transparente a través de una red. Middleware puede ser visto como un conector entre los componentes que utilizan el middleware. Moderno orientado a mensajes middleware proporciona generalmente un bus de servicios empresariales (ESB), que apoya ción y la comunicación entre múltiples aplicaciones de soft- ware interacción orientada al servicio.

Construcción de Software 311

4.12. Métodos de construcción de software distribuido [7 *] Un sistema distribuido es una colección de sistemas informáticos físicamente separados, posiblemente heterogéneos que están conectados en red para proporcionar a los usuarios el acceso a los diversos recursos que mantiene el sistema. Construcción de software distribuido se distingue de software tradicional trucción ción por cuestiones tales como paralelismo, comunicación, y tolerancia a fallos. Repartido programación típicamente cae en una de varias categorías arquitectónicos básicos: cliente-servidor, arquitectura arquitectura de 3 capas, de n niveles, dis- objetos Tributado, de acoplamiento suelto, o estrecho acoplamiento (véase la sección 14.3 de los fundamentos Informática KA y la sección 3.2 de la Diseño de software KA). 4.13. La construcción de sistemas heterogéneos [6 *] sistemas heterogéneos consisten en una variedad de unidades de computación especializados de diferentes tipos, tales como procesadores de señal digital (DSPs), controladores de microorganismos, y los procesadores periféricos. Estas unidades de cómputo se controlan independientemente y se comunican entre sí. Los sistemas embebidos son típicamente sistemas heterogéneos. El diseño de sistemas heterogéneos puede requerir la combinación de varios lenguajes de especificación para el diseño de diferentes partes del sistema, en otras palabras, codesign de hardware / software. Los temas clave incluyen la validación en varios idiomas, co-simulación e interfaz. Durante el codiseño hardware / software, desarrollo de software y hardware de desarrollo virtual de proceder simultáneamente a través de la descomposición gradual. La parte hardware generalmente se simula en el campo de las matrices de puertas programables (FPGAs) o circui- tos integrados de aplicación específica (ASIC). La parte de software se traduce en un lenguaje de programación de bajo nivel.

algoritmo de selección-influye en una velocidad y el tamaño ejecución. Análisis de rendimiento es la investiga- ción de la conducta de un programa utilizando informa- ción se reunieron como el programa se ejecuta, con el 4.14. Análisis de Rendimiento y ajuste [1 *] eficiencia-determinado código en la arquitectura, las decisiones de diseño detallado, y la estructura de datos y

3-12

Guía SWEBOK® V3.0 objetivo de identificar

posibles puntos calientes en el pro- grama a ser mejorado. Código de sintonía, lo que mejora el rendimiento a nivel de código, es la práctica de modificar el código correcto en formas que hacen que funcione más eficientemente. Código de sintonía por lo general implica sólo cambios a pequeña escala que afectan a una sola clase, una sola rutina, o, más comúnmente, unas pocas líneas de código. Un amplio conjunto de técnicas de optimización de código está disponible, INCLUYENDO las de sintonización expresiones lógicas, bucles, transformaciones de datos, expresiones, y rutinas. El uso de un lenguaje de bajo nivel es otra téc- nica común para la mejora de algunos puntos calientes en un programa. 4.15. Normas de plataforma [6 *] [7 *] estándares de la plataforma permiten a los programadores a desarrollar aplicaciones portátiles que se pueden eje- cuta en entornos compatibles sin cambios. estándares de la plataforma por lo general implican un conjunto de servicios estándar y API que compaimplementaciones de plataforma ible deben implementar. Ejemplos típicos de estándares de la plataforma son de Java 2 Platform Enterprise Edition (J2EE) y el estándar POSIX para sistemas operativos (Portable Operating System Interface), que representa un conjunto de normas implementadas principalmente para sistemas operativos basados en UNIX. 4.16. Programación Test-First [1 *] Ensayos primera programación (también conocido como Test-Driven DevelopmentTDD) es un estilo de desa- rrollo popular en la que los casos de prueba se escriben antes de escribir ningún código. programación de pruebas en primer lugar por lo general puede detectar defectos antes y corregirlos con más facilidad que los estilos de programación tradicionales. Por otra parte, la escritura casos de prueba primeras fuerzas pro-programadores a pensar acerca de los requisitos y el diseño antes de la codificación, exponiendo así a los requerimientos y problemas de diseño más pronto.

Construcción de Software 313

5.3. Herramientas de prueba de unidad

5. Herramientas de software de construcción 5.1. Entornos de desarrollo [1 *]

Un entorno de desarrollo o entorno de desarrollo integrado (IDE), proporciona Comprehensive instalaciones hensive a los programadores de software para la construcción mediante la integración de un conjunto de herramientas de desarrollo. Las opciones de los entornos de desarrollo pueden afectar la eficiencia y la calidad de construcción de software. En adicional a las funciones básicas de edición de código, entornos de desarrollo modernos a menudo ofrecen otras características como la 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 programas, código automatizado transforma y soporte para la refactorización. 5.2. Constructores GUI

[1 *]

Un constructor de GUI (Graphical User Interface) es una herramienta de desarrollo de software que permite el fun desa- para crear y mantener interfaces gráficas de usuario en un WYSI- WYG (lo que ves es lo que obtienes) de modo. Un constructor de interfaz gráfica de usuario por lo general incluye un editor visual para el desarrollador para diseñar formas y ventanas y gestionar la distribución de los widgets por Arrastrando, goteo y ajuste de parámetros. Algunos constructores GUI pueden generar automáticamente el código fuente correspondiente a la interfaz gráfica de diseño visual. Debido a que las aplicaciones GUI actuales generalmente si- bajo el estilo orientado a eventos (en la que el flujo del programa es determinado por eventos y manejo de eventos), las herramientas de desarrollo GUI suelen proporcionar asistentes de generación de código, que automatizan las tareas más repetitivas

[1 *] [2 *] Prueba de la unidad verifica el funcionamiento de los módulos de software en forma aislada de otros elementos de software que son separadamente contrastables (por ejemplo, clases, rutinas, componentes). Prueba de la unidad es a menudo auto-acoplado. Los desarrolladores pueden utilizar herramientas de prueba de unidad y los marcos para extender y crear ambiente de prueba automatizado. Con las herramientas de pruebas unitarias y marcos, el desarrollador puede codificar criterios en la prueba para verificar la exactitud de la unidad bajo variabilidad conjuntos 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 la prueba, los casos de prueba fallidos serán marcados e informaron de forma automática. 5.4. Perfilado, análisis de rendimiento, y cortar Herramientas [1 *] herramientas de análisis de rendimiento se utilizan generalmente para apoyar la sintonización código. Las herramientas de análisis per- formance más comunes son herramientas de perfiles. Un requeridas para el manejo de eventos. El código de soporte se conecta widgets con los eventos salientes y entrantes que activan las funciones que proporcionan la lógica de la aplicación. Algunos entornos de desarrollo modernos proporcionan constructores GUI integradas o constructor GUI plug-ins. También hay muchos constructores GUI independientes.

3-14 Guía SWEBOK® V3.0 herramienta de ejecución

de perfiles supervisa el código mientras se ejecuta y registra el número de veces que se ejecuta cada instrucción o cuánto tiempo el programa pasa en cada ruta declaración o ejecución. Propresentación del código mientras se está ejecutando da una idea de cómo funciona el programa, donde están los puntos calientes, y donde los desarrolladores deben centrarse los esfuerzos de optimización de código. rebanar programa implica el cálculo del conjunto de instrucciones de programa (es decir, el programa de rebanada) que pueden afectar a los valores de las variables especificadas en algún punto de interés, que se conoce como un criterio de fragmentación. rebanar programa puede ser utilizado para la localización de la fuente de errores, programa de comprensión, y análisis de optimización. herramientas de corte en lonchas programa computan las rebanadas de programas para varios lenguajes de programación que utilizan métodos de análisis estáticos o dinámicos.

Construcción de Software 315

1. Fundamentos de construcción de software 1.1. minimizando Complejidad

1.2. pronóstico del cambio 1.3. La construcción de Verificación 1.4. Reutilizar 1.5. Normas de construcción

c2, c3, C7-C9, c24, c27, c28, c31, C3-C5, c32, c34 C24, C31, C32, c8,C34 C23 C20, C31, c34 c4

2. Gestión de la Construcción 2.1. construcción en C2, C3, Modelos de Ciclo de C27, Vida C29 c3, c4, 2.2. Ordenación c21, de la Edificación c27-c29 2.3. Construcción Medición 3. Consideracion es 3.1. prácticas Diseño de la construcción 3.2. Construcción idiomas 3.3. Codificación

c25, c28

C3, C5, C24 c4 C5C19, C25C26

c16

Silberschatz et al. 2008 [7 *]

nully Lobur 2006 [6 *]

Mellor y Balcer 2002 [5 *]

Gamma et al. 1994 [4 *]

doLEMENTOS et al. 2010 [3 *]

SommervilLe 2011 [2 *]

McConnell 2004 [1 *]

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

3.4. Prueba de la c22, c23 construcción 3.5. Construcción de Reutilización 3.6. Construcción con 3.7. reutilización Construcción Calidad 3.8. Integración

y genéricos 4.4. Afirmaciones, Diseño por contrato, y la programación defensiva 4.5. Control de errores, control de excepciones, y la tolerancia a fallos 4.6. Ejecutable modelos 4.7. Las técnicas de construcción basadas en tablas de base estatal y 4.8. Configuración de tiempo de ejecución y la internacionalizació 4.9. Procesamiento nde la entrada Gramática-Basado

c8, C20-C25 c29

c7 C6, C7 c1

C8, C9

C3, C8 c1

c18

C3, C10 c5

c8

Silberschatz et al. 2008 [7 *]

nully Lobur 2006 [6 *]

Mellor y Balcer 2002 [5 *]

Gamma et al. 1994 [4 *]

doLEMENTOS et al. 2010 [3 *]

c16 c16

4. Tecnologías de la Construcción 4.1. Diseño APIy use 4.2. Orientado a Objetos Problemas de 4.3.tiempo de ejecución parametrización

SommervilLe 2011 [2 *]

Guía SWEBOK® V3.0

McConnell 2004 [1 *]

3-16

4.10. Las primitivas de concurrencia 4.11. middleware

c6 c1

c8

4.12. Métodos de construcción de software distribuido 4.13. La construcción de sistemas heterogéneos 4.14. Análisis de Rendimiento y ajuste 4.15. Normas

c2

C9 c25, c26 c10

de plataforma 4.16. Ensayos Primera 5. Programación Instrumento de construcción 5.1. Entornos de desarrollo 5.2. Constructores GUIExamen de 5.3. la unidad Herramientas 5.4. Perfilado, análisis de rendimiento,y Herramienta s de cortado

Silberschatz et al. 2008 [7 *]

nully Lobur 2006 [6 *]

Mellor y Balcer 2002 [5 *]

Gamma et al. 1994 [4 *]

doLEMENTOS et al. 2010 [3 *]

SommervilLe 2011 [2 *]

McConnell 2004 [1 *]

Construcción de Software 317

c22

c30 c30 c22

c25, c26

c8

c1

3-18

Guía SWEBOK® V3.0

LECTURAS

Referencias

IEEE Std. 1517-2010 estándar para la tecnología de la información del sistema y del software-Vida Procesos de reutilización de procesos de ciclo, IEEE, 2010 [8].

[1 *] S. McConnell, código completo, 2ª ed., Microsoft Press, 2004.

Esta norma especifica los procesos, actividades y tareas que deben aplicarse durante cada fase del ciclo de vida del software para permitir que un producto de software para ser construido a partir de los activos reutilizables. Cubre el concepto de desarrollo basado en la reutilización y los procesos de construcción de reutilización y la construcción con la reutilización. IEEE Std. 12207-2008 (también conocido como ISO / IEC 12207: 2008) estándar para los sistemas y software de ingeniería en software procesos de ciclo de vida, IEEE, 2008 [9]. Este estándar define una serie de software los procesos de desa- rrollo, incluyendo el software de construc- ción proceso, el proceso de integración de software, y el software de proceso de reutilización.

[2 *] I. Sommerville, Ingeniería de Software, 9ª ed., Addison-Wesley, 2011. [3 *] P. Clements et al, el software de documentación: Arquitecturas. Vistas y más allá, 2ª ed, Pearson Education, 2010.. [4 *] E. Gamma et al, patrones de diseño:.. Elementos de software orientado a objetos reutilizables, 1st ed, Addison-Wesley Professional, 1994. [5 *] SJ Mellor y MJ Balcer, ejecutable UML:. Una Fundación para el Model-Driven Architecture, 1st ed, Addison-Wesley, 2002. [6 *] L. y J. nulo Lobur, Lo Esencial de la Organización de Computadores y Arquitectura, 2ª ed., Jones and Bartlett Publishers, 2006. [7 *] A. Silberschatz, PB Galvin, y G. Gagne, Operating System Concepts, octava ed., Wiley, 2008. [8] IEEE Std. 1517-2010 estándar para la Tecnología de la Información-sistema y la duración del ciclo de Procesos de Software de reutilización de Procesos, IEEE 2010. [9] IEEE Std. 12207-2008 (también conocido como ISO / IEC 12207: 2008) estándar para los sistemas y software de ingeniería en software procesos de ciclo de vida, IEEE 2008.

Construcción de Software 319

CAPÍTULO PRUEBA 4 SOFTWARE SIGLAS API

Application Program Interface

TDD

Desarrollo basado en pruebas Pruebas y de control de pruebas de notación La versión 3 extrema Programación

TTCN3 XP

INTRODUCCIÓN Las pruebas de software consiste en la verificación dinámica que ofrece un programa de comportamientos esperados en un conjunto finito de casos de prueba, adecuadamente seleccionados a partir del dominio de ejecución generalmente infinita. En la definición anterior, palabras en cursiva uso corresponden a cuestiones clave en la descripción del área de conocimiento de Pruebas de Software (KA): • Dinámica: Este término significa que las pruebas siempre implica la ejecución del programa en las entradas seleccionadas. Para ser precisos, el valor de entrada por sí sola no siempre es suficiente para SPEC- ify una prueba, ya que un sistema complejo, no determinista podría reaccionar a la misma entrada con comportamientos diferentes, dependiendo del estado del sistema. En este KA, sin embargo, el término “entrada” se mantendrá, con la conven- ción implícita que su significado también incluye un estado de entrada fied speci- en aquellos casos en los que es importante. técnicas estáticas son diferentes de y complementaria a la prueba dinámica. técnicas estáticas están cubiertos en la calidad del software

KA. Vale la pena señalar que la terminología gía no es uniforme entre las diferentes comunidades y algunos utilizan el término “prueba” también en referencia a las técnicas estáticas. • Finito: Incluso en los programas simples, por lo que muchos casos de prueba son teóricamente posible que las pruebas tivo tamiento podría requerir meses o años

siempre es fácil, para decidir si los resultados observados de las pruebas del programa son aceptables o no; de lo contrario, el esfuerzo de prueba se usomenos. El comportamiento observado puede ser contrastada con las necesidades del usuario (comúnmente conocidas como pruebas de validación), contra un ficación speci- (prueba para la verificación), o, haps per-, contra el comportamiento esperado de los requisitos implícitos o expectativas (ver pruebas de aceptación en el software de los requisitos KA).

ejecutar. Es por esto que, en la práctica, un conjunto completo de pruebas puede considerarse generalmente infi- nita, y la prueba se lleva a cabo en un subconjunto de todas las pruebas posibles, que está determinada por criterios de riesgo y priorización. Las pruebas siempre implica un equilibrio entre los recursos y los horarios, por un lado limitados y los requisitos de prueba inherentemente ilimitadas, por el otro. • Seleccionado: Las muchas técnicas de prueba propuestos difieren esencialmente en cómo se selecciona el equipo de prueba, y los ingenieros de software deben ser conscientes de que los diferentes criterios de selección pueden producir muy diferentes grados de efectividad. Cómo identificar el criterio de selección más adecuado bajo condiciones dadas es un problema complejo; en la práctica, se aplican técnicas de análisis de riesgos y la ingeniería de software tise exper-. • Esperado: Debe ser posible, aunque no

En los últimos años, la vista de las pruebas de software ha madurado hasta convertirse en una constructiva. Testing ya no se ve como una actividad que se inicia sólo después de la fase de codificación se completa con el propósito limitado de fallos de detección. Las pruebas de software es, o debería ser, omnipresente en todo el ciclo de desarrollo y mantenimiento de la vida. De hecho, la planificación de las pruebas de software debe comenzar con las primeras etapas del proceso de requisitos de software, 4-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 desarrollo de software refinados como Bly-lidades ticamente y continuamente desarrollados y. Estas actividades de planificación y el diseño de prueba de la prueba proporcionan información útil para los diseñadores de software y ayudan a poner de relieve las debilidades potenciales, como descuidos de diseño / contradicciones u omisiones / ambigüedades en la documentación. Para muchas organizaciones, el enfoque de la calidad soft- ware es una de prevención: es, obviamente, mucho mejor para prevenir los problemas que corregirlos. Las pruebas pueden verse, entonces, como un medio para

proporcionar funcionalidad

información

acerca

de

la

y los atributos de calidad del software y también para la identificación de fallas en aquellos casos en los que la prevención de errores no ha sido eficaz. Es quizás obvio, pero vale la pena reconocer que el software todavía puede contener errores, incluso después de la finalización de una extensa actividad de la prueba. Los fallos de software riencia rienced después del parto se abordan mediante el mantenimiento correctivo. temas de mantenimiento de software están cubiertas en el mantenimiento del software KA. En la calidad del software KA (ver Técnicas para el control de calidad de software), técnicas de gestión de la calidad del software se clasifican principalmente en técnicas estáticas (sin ejecución de código) y

Software de Pruebas 4-3

4-4 Guía SWEBOK® V3.0

técnicas dinámicas (la ejecución de código). Tanto catego- rías son útiles. Esta KA se centra en técnicas dinámicas. Las pruebas de software también está relacionado con la construcción de software (vea Pruebas de construcción en el KA Construcción de Software). En particular, la unidad y pruebas de integración están íntimamente relacionados con la construcción de software, si no es parte de ella. DISTRIBUCIÓN DE TEMAS PARA LAS PRUEBAS DE SOFTWARE El desglose de temas para el Software de Exámenes KA se muestra en la Figura 4.1. Un desglose más detallado se proporciona en la Matriz de Temas vs Material de referencia al final de este KA. El primer tema se describen pruebas de software Fundamentals. Cubre las definiciones básicas en el campo de pruebas de software, la terminología básica y las cuestiones clave, y el buque PARENTESCO de pruebas de software con otras actividades. El segundo tema, los niveles de prueba, se compone de dos subtemas (ortogonales): la primera subtema se enumeran los niveles en los que la prueba de software grande se subdivide tradicionalmente, y el segundo subtema considera la prueba para las condiciones específicas o propie- dades y se conoce como objetivos de la prueba. No todos los tipos de pruebas se aplican a todos los productos de software, ni ha sido incluido todos los tipos posibles. El objetivo blanco de prueba y la prueba en conjunto determinan cómo se identifica el conjunto de prueba, tanto con respecto a su consistencia-la cantidad de pruebas es suficiente para alcanzar el indicado objetivo, y a su composición, que los casos de prueba deberían seleccionarse para lograr el objetivo indicado ( aunque por lo general “para lograr el obje- tivo declarado” queda implícita y sólo se plantea la primera parte de las dos preguntas anteriores en cursiva). Criterios para hacer frente a la primera pregunta se conocen como criterios de suficiencia de la prueba, mientras que los relativos a la segunda pregunta son los criterios de selección de las pruebas.

1. Fundamentos de pruebas de software 1.1. Las pruebas relacionada Terminología 1.1.1. Definiciones de Pruebas y terminología relacionada [1 *, c1, c2] [2 *, c8] Definiciones de pruebas y terminología relacionados con las pruebas se proporcionan en las referencias citadas y se resumen como sigue.

1.1.2. Las fallas fallas vs.

[1 *, c1s5] [2 *, c11]

Varias técnicas de prueba se han desarrollado en las últimas décadas, y todavía se están proponiendo nuevas. técnicas generalmente aceptadas están cubiertos en el tercer tema. Las medidas de prueba relacionados se tratan en el cuarto tema, mientras que las cuestiones relativas a la prueba Pro- ceso están cubiertos en el quinto. Finalmente, herramientas de prueba de software se presentan en el tema seis.

Muchos términos se utilizan en la literatura de ingeniería de software para describir un mal funcionamiento: Fallo sobre todo, el fracaso y el error, entre otros. Este gía terminología se define precisamente en [3, c2]. Es esencial distinguir claramente entre la causa de un mal funcionamiento (para el que se utilizará el fallo término aquí) y un efecto no deseado observado en servicio entregado del sis- tema (que se llama un fallo). En efecto bien puede haber fallos en el software que nunca se manifiestan como fracasos (ver limitaciones teóricas y prácticas de pruebas en la sección 1.2, Temas clave). Por lo tanto ing Test- puede revelar fallos, pero es los defectos que pueden y deben ser removidos [3]. El defecto más genérico término puede ser utilizado para hacer referencia a un fallo o un fracaso, cuando la distinción no es importante [3]. Sin embargo, se debe reconocer que la causa de un fallo no siempre puede ser inequívocamente identificados. No existen criterios teóricos para determinar definitivamente, en general, el fallo que provocó un fallo observada. Podría decirse que era la falla que tuvo que ser modificado para eliminar el fallo, pero otras modificaciones podría haber funcionado igual de bien. Para evitar la ambigüedad, se podría hacer referencia a las entradas de fallo causante en lugar de fallos, es decir, aquellos conjuntos de entradas que hacen que aparezca un fracaso. 1.2. Cuestiones clave 1.2.1. Prueba Criterios de selección / Criterios prueba de adecuación (Reglas de parada) [1 *, c1s14, c6s6, c12s7] Un criterio de selección de la prueba es un medio de selección de casos de prueba o la determinación de que un conjunto de casos de prueba

Software de Pruebas 4-5

4-6 Guía SWEBOK® V3.0

es suficiente para un propósito determinado. Prueba criterios quacy ade- se pueden utilizar para decidir cuando la prueba sufi- sufi- será, o se ha logrado [4] (ver terminación en la sección 5.1, las consideraciones prácticas). 1.2.2. Pruebas Efectividad / Objetivos para las pruebas [1 *, c11s4, c13s11] Ensayos sobre la eficacia se determina mediante el análisis de un conjunto de ejecuciones del programa. Selección de las pruebas que se ejecutarán puede ser guiado por diferentes objetivos: es sólo a la luz del objetivo perseguido que la eficacia del equipo de prueba se puede evaluar. 1.2.3. Pruebas Defecto de Descubrimiento [1 *, c1s14] En las pruebas para la detección de defectos, una prueba exitosa es la que hace que el sistema falle. Esto es bastante diferente de las pruebas para demostrar que el software cumple sus especificaciones o otras propiedades deseadas, en los que las pruebas de caso tiene éxito si no se observan fallos en virtud de casos de prueba realistas y entornos de prueba. 1.2.4. El problema de Oracle [1 *, c1s9, c9s7] Un oráculo es cualquier ser humano o agente mecánico que decide si un programa se comportó correctamente en una prueba determinada y, en consecuencia resulta en un diccionario ver- de “pase” o Existen muchos tipos dife- rentes de oráculos “fracaso”.; por ejemplo, las especificaciones inequívocas requisitos, modelos de comportamiento, y las anotaciones de código. La automatización de los oráculos mecanizadas puede ser difícil y costoso. 1.2.5. Limitaciones teóricas y prácticas de las Pruebas [1 *, c2s7]

en este sentido es el aforismo Dijkstra que “las pruebas pro- grama se puede utilizar para mostrar la presencia de insectos, pero nunca para mostrar su ausencia” [5]. La razón obvia de esto es que la prueba completa no es viable en el software realista. Debido a esto, las pruebas deben ser impulsada en función del riesgo [6, parte 1] y puede ser visto como una estrategia de gestión de riesgos. 1.2.6. El problema de no factibles Caminos [1 *, c4s7] caminos no factibles son trayectorias de flujo de control que no pueden ser ejercidos por cualquier dato de entrada. Ellos son un problema no puede signifi- en pruebas basadas en el camino, sobre todo en la derivación automática de entradas de prueba para ejercer trayectorias de flujo de control. 1.2.7. la capacidad [1 *, de prueba c17s2]

la teoría de las pruebas advierte contra atribuir un nivel cado injustificado de confianza a una serie de pruebas con éxito. Desafortunadamente, los resultados más establecidos de la teoría de las pruebas son negativas, ya que afirman que la prueba nunca puede alcanzar a diferencia de lo que se consigue en realidad. La cita más famosa

El término “capacidad de prueba de software” tiene dos significados diferentes pero relacionados: por un lado, se refiere a la facilidad con la que un criterio de cobertura de la prueba dada puede ser satisfecha; por el contrario, se define como la probabilidad, posiblemente medir estadísticamente, que un conjunto de casos de prueba se exponga un fracaso si el software es defectuoso. Ambos significados son importantes. 1.3. Relación de las pruebas a otras actividades Las pruebas de software se relaciona con, pero diferente de, estático técnicas de gestión de la calidad del software, Pruebas de corrección, depuración y construcción de programas. Sin embargo, es informativa para con- prueba Sider desde el punto de vista de los analistas de la calidad del software y de los certificadores. • Pruebas estáticas vs. Calidad de Software Hombre- Técnicas agement (Ver Técnicas de Gestión de la Calidad de Software en la calidad del software KA [1 *, c12]). • Las pruebas de exactitud frente a pruebas y verificación formal (ver los modelos de ingeniería de software y métodos KA [1 *, c17s2]). • Prueba vs. Depuración (ver pruebas de la construcción en la construcción del software KA y herramientas de depuración y técnicas en los cimientos Informática KA [1 *, c3s6]).

Software de Pruebas 4-7

4-8 Guía SWEBOK® V3.0

• Prueba vs. Programa de Construcción (ver pruebas de la construcción en la construcción del software KA [1 *, c3s2]). 2. Prueba niveles Las pruebas de software se realiza generalmente en niveles dife- rentes procesos en todo el manteni- miento y el desarrollo. Los niveles pueden ser distinguidos basado en el objeto de prueba, que se llama el objetivo, o de la finalidad, que se llama el objetivo (del nivel de prueba).

hilos funcionales. Las pruebas de integración es a menudo una actividad continua en cada etapa de desarrollo durante el cual los ingenieros de software abstractos perspectivas de distancia de nivel inferior y se concentran en las perspectivas del nivel en el que están inte- grando. Para que no sea el software pequeño, sencillo, estrategias de pruebas de integración incrementales son el aliado preferido no baja de poner todos los componentes juntos en las pruebas una vez que está a menudo llamado “big bang”. 2.1.3. Prueba del sistema [1 *, c8] [2 *, c8]

2.1. El objetivo de la prueba

[1 *, c1s13] [2 *, c8s1]

El objetivo de la prueba puede variar: un módulo individual, un grupo de tales módulos (relacionadas por finalidad, uso, comportamiento, o estructura), o todo un sistema. Tres etapas de la prueba se pueden distinguir: unidad, inte- gración, y el sistema. Estas tres etapas de prueba no implican ningún modelo de proceso, ni es uno cualquiera de ellos se supone que es más importante que los otros dos. 2.1.1. Examen de la unidad [1 *, c3] [2 *, c8] Prueba de la unidad verifica el funcionamiento en el aislamiento de elementos de software que son comprobables por separado. Dependiendo del contexto, estos podrían ser los subprogramas individuales o un componente más grande hecha de unidades altamente cohesivos. Típicamente, la unidad de pruebas se produce con acceso al código siendo probado y con el apoyo de herramientas de depuración. Los programadores que escribieron el código típicamente, pero no siempre, las pruebas unitarias conducta. 2.1.2. Pruebas de integración [1 *, c7] [2 *, c8] Las pruebas de integración es el proceso de verificar las interacciones entre los componentes de software. estrategias de pruebas de integración Sical cla-, como el de arriba hacia abajo y de abajo hacia arriba, se utilizan a

Las pruebas del sistema se ocupa de probar el comportamiento de todo un sistema. unidad efectiva y menudo con el software quía chically estructurado. , estrategias de integración sistemáticas modernas son típicamente arquitectura dirigida, que consiste en integrar progresivamente los componentes o subsistemas de software basado en com- identificado

pruebas de integración se han identificado muchos de los defectos de software. Las pruebas del sistema se considera generalmente adecuado para evaluar los requisitos del sistema, tales como no funcionales seguri- dad, velocidad, precisión y fiabilidad (ver requisitos funcionales y no funcionales en los requisitos de software y software KA cali- dad en el Requisitos La calidad del software KA). interfaces externas a otras aplicaciones, utilidades, dispositivos de hardware, o los entornos operativos también son generalmente evaluados en este nivel. 2.2. Objetivos de las Pruebas [1 *, c1s7] La prueba se llevó a cabo a la vista de objetivos específicos, que se indican más o menos explícitamente y con diferentes grados de precisión. La indicación de los objetivos de la prueba en términos precisos, cuantitativos apoya la medición y el control del proceso de prueba. Pruebas puede ser destinado a verificar diferentes pro- piedades. Los casos de prueba pueden ser diseñados para comprobar que las especificaciones funcionales son correctamente mentado Implementers, que se refiere vario en el eratura lit- como las pruebas de conformidad, las pruebas de corrección, o pruebas funcionales. Sin embargo, varias otras propiedades no funcionales pueden ser probados como bien incluyendo el rendimiento, la fiabilidad y dad usabil-, entre muchos otros (ver modelos y características de calidad de la calidad del software KA). Otros objetivos importantes para el ensayo incluyen pero no se limitan a la medición de fiabilidad,

Software de Pruebas 4-9

4-10

Guía SWEBOK® V3.0

identificación de las vulnerabilidades de seguridad, evaluación de la usabilidad y la aceptación de software, por lo que sería tomado diferentes enfoques. Tenga en cuenta que, en general, los objetivos de la prueba varían según el destino de la prueba; propósitos diferentes se dirigen a diferentes niveles de pruebas. Los subtemas que figuran a continuación son los más frecuentemente citado en la literatura. Tenga en cuenta que algunos tipos de pruebas son más apropiados para las pruebas de software paquetes de instalación a medida, por ejemplo- y otros para productos de consumo, como las pruebas beta. 2.2.1. La prueba de aceptación / Calificación [1 *, c1s7] [2 *, c8s4]

2.2.4. Logro fiabilidad y Evaluación [1 *, c15] [2 *, c15s2] Las pruebas mejora la fiabilidad mediante la identificación y corrección de fallos. Además, las medidas estadísticas de fiabilidad se pueden derivar por casos de prueba ing generataleatoria de acuerdo con el perfil de funcionamiento del software (ver perfil operativo en la sección 3.5, Técnicas de usobase). Este último enfoque se denomina pruebas de funcionamiento. Usando modelos de crecimiento fiabilidad, ambos objetivos pueden perseguirse juntos [3] (ver Prueba de vida, la evaluación de fiabilidad en la sección 4.1, Evaluación del Programa bajo Test). 2.2.5. Pruebas de regresión [1 *, c8s11,

Las pruebas de aceptación / calificación determina si un sistema cumple con sus criterios de aceptación, por lo general mediante la comprobación de los comportamientos deseados del sistema contra los requerimientos del cliente. El cliente o representativos fies por lo tanto speci- de un cliente o directamente realiza actividades para comprobar que se han cumplido sus requisitos, o en el caso de un producto de consumo, que la organización ha cumplido con los requisitos establecidos para el mercado de Tar conseguir. Esta actividad pruebas pueden o no implicar los desarrolladores del sistema. 2.2.2. Prueba de la instalación [1 *, c12s2] A menudo, después de la finalización del sistema y pruebas de aceptación, el software se verifica después de la instalación en el entorno de destino. las pruebas de instalación se puede ver como las pruebas del sistema llevado a cabo en el entorno operativo de configuraciones de hardware ciones y otras limitaciones operacionales. procedimientos de instala- ción también pueden ser verificados. 2.2.3. Alfa y Beta Testing [1 *, c13s7, c16s6] [2 *, c8s4]

c13s3] De acuerdo con [7], pruebas de regresión es la “repetición de pruebas tiva selec- de un sistema o componente para verificar que las modificaciones no han causado efectos no deseados y que el sistema o componente sigue cumpliendo con sus requisitos especificados.” En la práctica, el enfoque es demostrar que las pruebas de software sigue pasando pasado previamente en un conjunto de pruebas (de hecho, también se refiere a las pruebas de progresión como nonre- veces). Para el desarrollo incremental, el propósito de las pruebas de regresión es mostrar que el comportamiento del software no se ha modificado por los cambios graduales en el software, excepto en la medida en que debería. En algunos casos, una solución de compromiso debe hacerse entre la garantía dada por regresión probando cada vez que se realiza un cambio y los recursos necesarios para llevar a cabo las pruebas de regresión, que puede ser bastante tiempo, debido al gran número de pruebas que pueden ser ejecutados. Las pruebas de regresión consiste en seleccionar, minimizar y / o dar prioridad a un subconjunto de los casos de prueba en un conjunto de pruebas exis- tentes [8]. Las pruebas de regresión puede ser conconductos en cada uno de los niveles de ensayo descritos en sec- ción 2.1, el objetivo de la prueba, y pueden aplicarse a las pruebas funcionales y no funcionales.

Antes se libera el software, se da a veces a un pequeño y selecto grupo de usuarios potenciales para el uso de prueba (pruebas alfa) y / o a un conjunto más amplio de usuarios representativos (pruebas beta). Estos usuarios reportan problemas con el producto. Alfa y beta testing a menudo no están controlados y no siempre se hace referencia en un plan de pruebas.

2.2.6. Pruebas de rendimiento

Software de Pruebas 4-11

[1 *, c8s6]

Las pruebas de rendimiento verifica que el software cumple con los requisitos de funcionamiento específicos y evalúa características de rendimiento-por ejemplo, la capacidad y el tiempo de respuesta.

4-12

Guía SWEBOK® V3.0

2.2.7. Pruebas de seguridad

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

Las pruebas de seguridad se centra en la verificación de que el software está protegido de ataques externos. En particular, las pruebas de seguridad verifica la confidenciales cialidad, integridad y disponibilidad de los sistemas y sus datos. Por lo general, las pruebas de seguridad incluye la verificación contra el mal uso y el abuso de la cerámica o el sistema (pruebas negativas) blandas. 2.2.8. Pruebas de estrés

[1 *, c8s8]

Las pruebas de estrés ejerce de software en la carga máxima de diseño, así como más allá de ella, con el objetivo de determinar los límites de comportamiento, y para poner a prueba los mecanismos de defensa en sistemas críticos.

2.2.12. Prueba de configuración

[1 *, c8s5]

En los casos donde el software se construye para servir a diferentes usuarios, pruebas de configuración verifica el software bajo diferentes configuraciones especificadas. 2.2.13. Usabilidad e inter-Ordenador prueba de la acción [10 *, c6]

La tarea principal de la usabilidad y las pruebas interacción persona-ordenador es evaluar lo fácil que es para los usuarios finales para aprender y utilizar el software. En en general, puede implicar pruebas del software fun- ciones que soporta las tareas del usuario, la documentación que ayuda a los usuarios, y la capacidad del sistema para recuperarse de los errores del usuario (ver diseño de la interfaz de usuario en el software de diseño de KA).

2.2.9. Back-to-Back Testing [7] IEEE / ISO / IEC Standard 24765 define las pruebas de espalda de Regreso a como “prueba en el que dos o más variantes de un programa se ejecutan con las mismas entradas, las salidas se comparan, y los errores se analizan en caso de discrepancias.” 2.2.10. Prueba de recuperación [1 *, c14s2] las pruebas de recuperación está dirigido a comprobar la capacidad de reinicio de software después de un fallo del sistema o de otro tipo “desastre”. 2.2.11. Prueba de interfaz [2 *, c8s1.3] [9 *, c4s4.5] defectos de interfaz son comunes en siste- mas complejas. pruebas de la interfaz tiene como objetivo verificar si la interfaz componentes correctamente para proporcionar el intercambio correcto de datos y control de informa- ción. Por lo general, los casos de prueba se generan a partir de la especificación de interfaz. Un objetivo específico de pruebas de la interfaz es

para simular el uso de las API de aplicaciones de usuario final. Esto implica la genera- ción de los parámetros de las llamadas a la API, el ajuste de las condiciones del entorno externo, y a la definición de los datos interna que afecta a la API.

3. Prueba técnicas Uno de los objetivos de la prueba es detectar la mayor cantidad posible de fallos. Muchas técnicas se han desarrollado para hacer esto [6, parte 4]. Estas técnicas intentan “romper” un programa por ser Tematic como sis- como sea posible en la identificación de las entradas que van a producir comportamientos representativos del programa; por ejemplo, teniendo en cuenta las subclases del dominio de entrada, los escenarios, los estados, y los flujos de datos. La clasificación de las técnicas de prueba pre SENTED aquí se basa en cómo se generan las pruebas: desde la intuición del ingeniero de software y expe- riencia, las especificaciones, la estructura del código, las faltas reales o imaginarios a ser descubiertos, el uso previsto, modelos, o la naturaleza de la aplicación. Una categoría se refiere a la utilización combinada de dos o más técnicas. A veces, estas técnicas se clasifican como de caja blanca (también llamada caja de vidrio), si las pruebas se basan en la información sobre la forma en que el software ha sido diseñado o codificado, o como negro-casilla si los casos de prueba se basan únicamente en la entrada / salida el comportamiento del software. La siguiente lista incluye las técnicas de prueba que se utilizan normalmente, pero algunos médicos se basan en algunas de las técnicas más que otros.

Software de Pruebas 4-13

4-14

Guía SWEBOK® V3.0

3.1. Sobre la base de la intuición y la experiencia del ingeniero de software

3.2.2. Las pruebas por parejas [1 *, c9s3]

3.1.1. Ad hoc Tal vez la técnica que más se practica es la prueba ad-hoc: las pruebas se derivan depender de la habilidad del ingeniero de software, la intuición y ex- periencia con programas similares. pruebas Ad hoc puede ser útil para identificar las pruebas casos que no generan fácilmente por técnicas más formales. 3.1.2. Prueba exploratoria pruebas exploratorias se define como aprendizaje simultáneo, diseño de la prueba, y ejecución de la prueba [6, parte 1]; es decir, las pruebas no se definen por adelantado en un plan de pruebas establecido, pero están diseñados de forma dinámica, ejecutados, y modificados. La eficacia de pruebas exploratorias se basa en el conocimiento de los ingenieros de software, que se puede derivar de varias fuentes: el comportamiento del producto observada durante la prueba, la familiaridad con la aplicación, la plataforma, el proceso falla, el tipo de fallas y fracasos po- sible, el riesgo asociado con un producto en particular, y así sucesivamente. 3.2. Las técnicas basadas en el dominio de entrada 3.2.1. Partición de equivalencia [1 *, c9s4] partición de equivalencia implica la partición del dominio de entrada en una colección de subconjuntos (o clases Alent valente) en base a un criterio especificado o con relación. Este criterio o relación pueden ser diferentes resultados computacionales, una relación basada en el flujo de control o flujo de datos, o una distinción entre entradas válidas que son aceptados y procesados por el sistema y las entradas no válidas, tales como fuera de rango Val- ues, que son no aceptado y debe generar un mensaje de error o iniciar el procesamiento de error. Un conjunto representativo de pruebas (a veces sólo uno) es aliado no baja tomada de cada clase de equivalencia.

Los casos de prueba se derivan mediante la combinación de valores interesantes para cada par de un conjunto de variables de entrada

en lugar de considerar todas las combinaciones posibles. pruebas Pairwise pertenece a prueba combinatoria, que en general también incluye combinaciones de más alto nivel que los pares: estas técnicas se denominan t-sabia, con lo que se considera cada combinación posible de las variables de entrada t. 3.2.3. Análisis de valores en la frontera [1 *, c9s5] Los casos de prueba son elegidos en o cerca de los límites del dominio de las variables de entrada, con la lógica subyacente que muchos fallos tienden a concentrarse cerca de los valores extremos de entradas. Una extensión de esta técnica es la prueba de solidez, en el que los casos de prueba se eligen también fuera del dominio de entrada de variables a robustez programa de prueba en el procesamiento de entradas inesperadas o erróneos. 3.2.4. Pruebas al azar [1 *, c9s7] Las pruebas se generan puramente al azar (que no debe confundirse con la prueba estadística del perfil fun- cional, como se describe en perfil operativo en la sección 3.5). Esta forma de pruebas se encuentra bajo el encabezamiento de las pruebas de dominio de entrada ya que el dominio de entrada debe ser conocido con el fin de ser capaz de recoger puntos al azar dentro de ella. Las pruebas al azar proporciona un enfoque relativamente simple para la automatización de pruebas; recientemente, se han propuesto formas mejoradas de pruebas al azar en los que pling la entrada aleatoria sam- está dirigida por otros criterios de selección de entrada [11]. las pruebas de la pelusa o la formación de pelusa es una forma especial de pruebas al azar dirigida a romper el software; Con mayor frecuencia se utiliza para las pruebas de seguridad. 3.3. Técnicas de código-base 3.3.1. Criterios basados en el flujo de control [1 *, c4] criterios de cobertura basadas en el flujo de control se basa en cubrir todas las declaraciones, los bloques de instrucciones, o combinaciones especificadas de declaraciones en un programa. El más fuerte de los criterios

Software de Pruebas basados Flow Control es la prueba de ruta, cuyo 4-15 objetivo es ejecutar todas las trayectorias de flujo de control de entrada-salida-a en el gráfico de flujo de control de un programa. Dado que las pruebas de ruta exhaustiva por lo general no es factible debido a

4-16

Guía SWEBOK® V3.0

bucles, otros criterios menos estrictos se centran en la cobertura de los caminos que limitan iteraciones del bucle, tales como la cobertura de sentencias, cobertura de sucursales, y conDICIÓN / pruebas de decisión. La adecuación de estas pruebas se mide en porcentajes; por ejemplo, cuando todas las ramas se han ejecutado al menos una vez por los ensayos, se ha logrado 100% de cobertura de rama. 3.3.2. Criterios basados en el flujo de datos [1 *, c5] En las pruebas basadas en el flujo de datos, el gráfico de flujo de control está anotado con información sobre cómo se definen las variables del programa, utilizados y asesinados (sin definir). El criterio más fuerte, todos los caminos definición de uso, requiere que, para cada variable, se ejecuta cada segmento de trayectoria de flujo de control de una definición de esa variable a un uso de esa definición. Con el fin de reducir el número de caminos necesarios, se emplean estrategias más débiles tales como todo-definiciones y todos los usos. 3.3.3. Modelos de referencia de las pruebas basadas en el Código [1 *, c4] Aunque no es una técnica en sí misma, la estructura de control de un programa puede ser gráficamente repre- sentadas usando un gráfico de flujo para visualizar técnicas de ensayo basadas código-. Un gráfico de flujo es un grafo dirigido, los nodos y arcos de los cuales corresponderse a elementos (ver gráficos y los árboles en los fundamentos matemáticos KA) programar. Por ejemplo, los nodos pueden representar declaraciones o secuencias ininterrumpidas de estados, y los arcos pueden representar la transferencia de control entre los nodos.

3.4.1. error de adivinanzas

[1 *, c9s8]

En adivinar de error, los casos de prueba están diseñados específicamente por los ingenieros de software que intentan anticipan las fallas más plausibles en un programa dado. Una buena fuente de información es la historia de los fallos detectados en los proyectos anteriores, así como la experiencia del ingeniero de software. 3.4.2. Las pruebas de mutación [1 *, c3s5]

Un mutante es una versión ligeramente modificada del programa bajo prueba, que difiere de ella por un pequeño cambio sintáctico. Cada caso de prueba ejerce tanto el programa original y todos los mutantes generados: si un caso de prueba tiene éxito en la identificación de la dife- rencia entre el programa y un mutante, se dice que este último sea concebido originalmente como una técnica para evaluar la prueba “muerto”. conjuntos (véase la sección 4.2. Evaluación de las pruebas realizadas), pruebas ción mutatis es también un criterio de prueba en sí mismo: o bien pruebas se generan aleatoriamente hasta que suficientes mutantes han muerto, o pruebas están diseñadas específicamente para matar mutantes supervivientes. En este último caso, las pruebas de mutación también puede ser categorizado como una técnica basada en el código. La suposición subyacente de pruebas de mutación, el efecto de acoplamiento, es que mediante la búsqueda de fallos sintácticos simples, se encontraron defectos más complejos pero reales. Para que la técnica sea eficaz, un gran número de mutantes debe ser generado y ejecutado de forma sistemática [12] automáticamente. 3.5. Técnicas de uso-Basado 3.5.1. Perfil operativa [1 *, c15s5]

3.4. Técnicas basada en la culpa

[1 *, c1s14]

Con diferentes grados de formalización, técnicas de ensayo basadas culpa- diseñar casos de

En las pruebas para la evaluación de la fiabilidad (también llamado pruebas de funcionamiento), el entorno de prueba reproprueba específica- mente destinados a revelar categorías de fallos probables o predefinidas. Para

enfocar mejor la generación de casos de prueba o de selección, un modelo de fallo puede ser introducido que clasifica los diferentes tipos de faltas.

Pruebas duce el entorno operativo de Software la soft- de ware, o el 4-17 perfil operativo, lo más estrechamente posible. El objetivo es inferir a partir de los resultados de las pruebas observadas el futuro fiabilidad del software cuando está en uso real. Para ello, las entradas se asignan probabilidades, o perfiles, en función de su frecuencia de ocurrencia en la operación real. perfiles fun- cional se pueden utilizar durante la prueba del sistema

4-18

Guía SWEBOK® V3.0

para guiar derivación de casos de prueba que evaluarán la consecución de los objetivos de fiabilidad y ejercer uso relativo y importancia de las distintas funciones similares a lo que se encontró en el entorno operativo [3].

3.5.2. La heurística de observación del usuario [10 *, C5, C7] principios de usabilidad pueden proporcionar directrices para los problemas de los descubrimientos confirma en el diseño de la cara del usuario inter [10 *, c1s4] (véase el diseño de la interfaz de usuario en el software de diseño de KA). especializadas heurísticas, también llamados métodos de inspección facilidad de uso, se aplican para la observación sistemática del uso del sistema bajo condiciones controladas con el fin de deter- minar qué tan bien la gente puede utilizar el sistema y sus interfaces. heurísticas de usabilidad incluyen recorridos cognitivos, análisis de reclamaciones, observaciones de campo, pensando en voz alta, y los enfoques incluso indirectos, tales como cuestionarios de usuario y entrevistas. 3.6. Técnicas de ensayo basado en modelos Un modelo en este contexto es una representación abstracta (formal) del software bajo prueba, o de sus requisitos de software (ver Modelado de los modelos de ingeniería de software y métodos KA). pruebas basadas en modelos se utiliza para validar los requisitos, comprobar su consistencia, y generar casos de prueba se centraron en los aspectos de comportamiento del software. Los componentes clave de las pruebas basadas en modelo son [13]: la notación utilizada para representar el modelo del software o de sus requisitos; modelos de flujo de obra o modelos similares; la estrategia de prueba o algoritmo utilizado para la generación de caso de prueba; la infraestructura de apoyo para la ejecución de la prueba; y la evaluación de los resultados de las pruebas en comparación con los resultados esperados. Debido a la complejidad de las técnicas, los métodos de ensayo basados en modelos se utilizan a menudo en conjunción con los arneses ción de prueba automatización. técnicas de pruebas basadas en modelos incluyen los

(Más o menos, las salidas). Los casos de prueba se derivan sistemáticamente por considerar cada posible combinación de condiciones y sus acciones resul- tantes correspondientes. Una técnica relacionada es causa-efecto gráfica [1 *, c13s6]. 3.6.2. Las máquinas de estados finitos siguientes. 3.6.1. Las tablas de decisión

[1 *, c10]

Al modelar un programa como una máquina de estados finitos, las pruebas pueden ser seleccionados con el fin de cubrir los estados y transiciones. 3.6.3. Las especificaciones formales [1 *, c10s11] [2 *, c15] Indicando las especificaciones en un lenguaje formal (ver Métodos formales en la EngineerSoftware ing modelos y métodos KA) permite la derivación automática de casos de prueba funcionales, y, al mismo tiempo, proporciona un oráculo para comprobar los resultados de pruebas. TTCN3 (Pruebas y control de pruebas notación de la versión 3) es un lenguaje desarrollado para escribir casos de prueba. La notación fue concebida para las necesidades específicas de los sistemas de prueba de [1 *, c9s6] Las tablas de decisión representan las relaciones lógicas entre las condiciones (aproximadamente, insumos) y acciones

Pruebas telecomunicaciones, por lo Software que dees 4-19 particularmente adecuado para probar protocolos de comuni- cación complejos.

3.6.4. Flujo de Trabajo modelos [2 *, c8s3.2, c19s3.1] modelos de flujo de trabajo especifican una secuencia de activi- lazos realizadas por los seres humanos y / o software aplica- ciones, generalmente representados a través de notaciones gráficas. Cada secuencia de acciones constituye un flujo de trabajo (también llamado un escenario). Tanto cal normalmente, un y flujos de trabajo alternativos deben ser probados [6, parte 4]. Un enfoque especial en los papeles en una especificación de flujo de obra está dirigida en las pruebas de procesos de negocio. 3.7. Las técnicas basadas en la naturaleza de la aplicación Las técnicas anteriores se aplican a todo tipo de soft- ware. Técnicas adicionales para la derivación y ejecución de pruebas se basan en la naturaleza de la soft- ware siendo probado; por ejemplo,

Software de Pruebas 411

• • • • • • • • • •

software orientado a objetos software basado en componentes software basado en web programas concurrentes software basado en el protocolo sistemas de tiempo real sistemas de seguridad críticos software orientada a servicios software de código abierto software embebido

3.8. La selección y la combinación de técnicas 3.8.1. La combinación funcional y estructural [1 *, c9] Basado en modelos y técnicas de ensayo basadas en código son a menudo contrastan tan funcional frente a las pruebas estructurales. Estos dos enfoques para la selección de la prueba no deben ser vistos como alternativas sino como complementos; de hecho, se utilizan diferentes fuentes de información y se ha demostrado que diferentes tipos de alta luz de los problemas. Pueden ser utilizados en combinación, dependiendo de consideraciones presupuestarias.

en cada punto de decisión. Para evitar este tipo de malentendidos, una clara distinción debe hacerse entre las medidas relacionadas con las pruebas que proporcionan una evaluación del programa que se está probando, a partir de las salidas de prueba observadas y las medidas que evalúan la minuciosidad de la prueba. (Véase la Ingeniería de Software de medición en la Gestión KA Ingeniería de Software para obtener información sobre los programas de medición. Ver Proceso de Software y Medición del producto en el Proceso de Ingeniería de Software KA para obtener información sobre las medidas). La medición se considera generalmente como funda- mental para el análisis de calidad. La medición también se puede utilizar para optimizar la planificación y ejecución de las pruebas. Gestión de pruebas puede utilizar varias medidas de diferencias ent proceso para monitorear el progreso. (Véase la sección 5.1, las consideraciones prácticas, para una discusión de las medidas del proceso de pruebas útiles para fines de gestión). 4.1. Evaluación de la prueba el marco del Programa 4.1.1. Las mediciones de programas que ayudan en la planificación y Análisis Diseñando [9 *, c11]

3.8.2. Determinista vs aleatoria [1 *, c9s6] Los casos de prueba pueden seleccionarse de una manera determinista, de acuerdo con una de muchas técnicas, o aleatoriamente extraídas de alguna distribución de insumos, tal como se suele hacer en las pruebas de fiabilidad. comparaciones analíticas y empíricas erales SeV han llevado a cabo para analizar las condiciones que hacen que un enfoque más eficaz que el otro. 4. Las medidas de prueba relacionados A veces, las técnicas de prueba son confundidos con los objetivos de las pruebas. Técnicas de ensayo pueden ser vistos como auxiliares que ayudan a asegurar el logro de objetivos de la

Medidas basado en el tamaño del software (por ejemplo, líneas de código fuente o tamaño funcional; ver Measure prueba [6, Parte 4]. Por ejemplo, la cobertura de la rama es una técnica de prueba popular. El logro de una cobertura rama medida especificada (por ejemplo, 95% de cobertura de sucursales) no debe ser el objetivo de las pruebas per se: es una forma de improv- ing las posibilidades de encontrar fallos por intentar ejercer sistemáticamente todas las ramas del programa

4-12

Guía SWEBOK® V3.0 en Requisitos Suring

los requisitos de software KA) o en la estructura del programa se pueden usar para guiar las pruebas. Las medidas estructurales incluyen también medidas que determinan la frecuencia con la que llaman módulos entre sí. 4.1.2. FALLO Tipos, clasificación y estadísticas [9 *, c4] La literatura es rica en pruebas de clasificaciones y taxonomías de faltas. Para hacer la prueba tivo más effec-, es importante saber qué tipos de fallos se pueden encontrar en el software bajo prueba y la frecuencia relativa con la que se han producido estos fallos en el pasado. Esta información puede ser uso-ful para hacer predicciones de calidad, así como en la mejora de procesos (véase ción de defectos caracterización de la calidad del software KA).

Software de Pruebas 413

4.1.3. Densidad de fallos

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

Un programa bajo prueba se puede evaluar por recuento fallos descubiertos como la relación entre el número de fallos encontrados y el tamaño del programa. 4.1.4. Prueba de vida, Evaluación Fiabilidad [1 *, c15] [9 *, c3] Una estimación estadística de la fiabilidad del software, que puede ser obtenido mediante la observación de fiabilidad alcanzado, se puede utilizar para evaluar un producto de software y decidir si o no la prueba puede ser detenido (ver sección 2.2, Logro Fiabilidad y evaluación). 4.1.5. Los modelos de crecimiento fiabilidad [1 *, c15] [9 *, c8] modelos de crecimiento Fiabilidad proporcionan una predicción de fiabilidad basado en fracasos. Suponen, en gene- ral, que cuando las fallas que causaron las fallas observadas se han fijado (aunque algunos modelos también aceptan correcciones imperfectas), exposiciones de fiabilidad del pro- ducto estimado, en promedio, una tendencia creciente. Hay muchos modelos de crecimiento fiabilidad publicados. En particular, estos modelos se dividen en el fracaso de conteo y los modelos de tiempo medio entre fallos. 4.2. La evaluación de las pruebas realizadas 4.2.1. Medidas de cobertura / Minuciosidad [9 *, c11] Varios criterios de adecuación de prueba requieren que los casos de prueba ejercen sistemáticamente un conjunto de elementos identificados en el programa o en las especificaciones (véase el tema 3, Técnicas de Prueba). Para evaluar la rigurosidad de las pruebas ejecutadas, nieros de software niería pueden monitorear los elementos cubiertos de manera que puedan medir dinámicamente la relación entre los elementos cubiertos y el número total. Por ejem plos, es posible medir el porcentaje de ramas cubiertas en el gráfico de

4.2.2. Siembra de fallos

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

flujo del programa o el porcentaje de requisitos funcionales ejercidas entre los enumerados en el documento de especificaciones. criterios de adecuación basados en códigos requieren instrumentación apropiada del programa que se está probando.

4-14

Guía SWEBOK® V3.0

En la siembra de fallos, algunos fallos se introducido artificialmente en un programa antes de la prueba. Cuando se ejecutan las pruebas, algunos de estos fallos cabezas de serie se dará a conocer, así como, posiblemente, algunos defectos que ya estaban allí. En teoría, dependiendo de cuáles y cuántos de los defectos artificiales se presen- ten, Ensayos sobre la eficacia puede ser evaluado y el número restante de fallos genuinos puede ser acoplado estimación. En la práctica, los estadísticos cuestionan la distribu- ción y la representatividad de los fallos sembradas en relación con los fallos genuinos y el tamaño pequeño de la muestra sobre la que se basan las extrapolaciones. Algunos también argumentan que esta técnica se debe utilizar con mucho cuidado ya que la inserción de fallos en el software implica el riesgo evidente de dejarlos allí. 4.2.3. Puntuación mutación [1 *, c3s5] En las pruebas de mutación (ver pruebas de mutación en sec- ción 3.4, Técnicas basada en la culpa), la proporción de mutantes muertos al número total de mutantes generados puede ser una medida de la eficacia del equipo de prueba ejecutado. 4.2.4. La comparación y la eficacia relativa de las diferentes técnicas Se han realizado varios estudios para comparar la eficacia relativa de las diferentes técnicas de prueba. Es importante ser preciso en cuanto a la propiedad contra la cual se están evaluando las técnicas; lo que, por ejemplo, es el significado exacto dado al término “eficacia”? Posibles interpretaciones incluyen el número de pruebas necesarias para encontrar el primer fracaso, la proporción entre el número de fallos que se encuentran a través de pruebas de todos los defectos encontrados durante y después de la prueba, y la cantidad de fiabili- dad se ha mejorado. comparaciones analíticas y empíricas entre diferentes técnicas se han llevado a cabo de acuerdo con cada una de las nociones de eficacia especificados anteriormente. 5. Prueba Proceso conceptos de pruebas, estrategias, técnicas, y

medi- das deben integrarse en un definido y

Software de Pruebas 415

proceso controlado. El proceso de prueba es compatible con las actividades de ensayo y proporciona orientación a los probadores y equipos de prueba, desde la planificación de prueba para probar la evaluación de salida, de tal manera como para ofrecer garantías de que los objetivos de la prueba se cumplirán de manera tivo costo-effec-. 5.1. Consideraciones prácticas 5.1.1. Actitudes / programación sin ego [1 * c16] [9 *, c15]

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 gerentes tienen un papel clave en la promoción de una recepción favorable en general hacia el descubrimiento fracaso y la corrección durante el desarrollo y mantenimiento de software; por ejemplo, mediante la superación de la mentalidad de código individual ERSHIP de propia entre los programadores y la promoción de un entorno de colaboración con el equipo de responsa- bilidad de anomalías en el código. 5.1.2. Prueba guías [1 *, c12s1] [9 *, c15s1] Las fases de prueba pueden ser guiados por varios objetivos, por ejemplo, las pruebas basadas en riesgo utiliza los riesgos de los productos de priorizar y centrarse EGY la prueba estra-, y pruebas basadas en escenario define casos de prueba basado en escenarios de software especificados. 5.1.3. Prueba Gestión de proceso [1 *, c12] [9 *, c15] actividades de prueba llevados a cabo en diferentes niveles (ver tema 2, los niveles de prueba) debe ser organizada en conjunto con las personas, herramientas, políticas y medidas en un proceso bien definido que es una parte integral del ciclo de vida. 5.1.4. Prueba Documentación y los productos [1 *, c8s12] [9 *, c4s5]

el elemento de prueba. la documentación de prueba debe hay que producir y actualizada continuamente para el mismo nivel de calidad que los demás tipos de documentación en la ingeniería de software. documentación de prueba también debe estar bajo el control de la gestión de con- figuración 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 usuarios. 5.1.5. Desarrollo basado en pruebas La documentación es una parte integral de la ción formalización del 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, procedimiento de ensayo, la especificación de casos de prueba, registro de la prueba, y el informe de incidente prueba. El software bajo prueba se documenta como

4-16

Guía SWEBOK® V3.0

[1 *, c1s16]

Basado en pruebas de desarrollo (TDD) se originó como una de las prácticas núcleo XP (programación extrema) y consiste en escribir las pruebas unitarias antes de escribir el código para ensayar (ver Métodos ágiles en los modelos de ingeniería de software y métodos KA). De esta manera, TDD desarrolla los casos de prueba como rogate sur- para un documento de especificación de requisitos de software en lugar de como una verificación independiente de que el software ha implementado correctamente los requisitos. En lugar de una estrategia de ensayo, TDD es una práctica que requiere que los desarrolladores de software para definir y mantener las pruebas de unidad; Por lo tanto, también puede tener un impacto positivo en la elaboración de las necesidades del usuario y especificación de requisitos de software. 5.1.6. Interna frente del equipo de pruebas independientes [1 *, c16] La formalización el proceso de prueba también puede implicar la formalización de la organización del equipo de pruebas. El equipo de pruebas puede estar compuesto por miembros internos (es decir, en el equipo del proyecto, se trate o no en la construcción de software), de los miembros externos (con la esperanza de traer una perspectiva imparcial, independiente), o de ambos miem- interna y externa bras. Las consideraciones de costos, plazos, niveles de madurez de las organizaciones involucradas, y criticidad de la aplicación pueden guiar la decisión. 5.1.7. Costo / Esfuerzo de estimación y prueba mide Proceso [1 *, c18s3] [9 *, c5s7] Una serie de medidas relacionadas con los recursos gastados en las pruebas, así como a la relativa eficacia de búsqueda de errores de las diversas fases de prueba, son utilizados por los administradores para controlar y mejorar la prueba

Software de Pruebas 417

proceso. Estas medidas de prueba pueden cubrir aspectos tales como el número de casos de prueba especificados, el número de casos de prueba ejecutados, el número de casos de prueba pasó, y el número de casos de prueba falló, entre otros. Evaluación de los informes de las pruebas de fase puede ser combinarse con el análisis de las causas para evaluar la efectividad del proceso de Exámenes en la búsqueda de fallos tan pronto como sea posible. Tal evaluación puede estar asociada con el análisis de riesgos. Por otra parte, los recursos que merece la pena el gasto en las pruebas deben ser com- realizó medición con el uso / criticidad de la apli- cación: diferentes técnicas tienen diferentes costos y el rendimiento de los diferentes niveles de confianza en la fiabilidad del producto. 5.1.8. Terminación [9 *, c10s4] Una decisión debe ser tomada en cuanto a cuánto ing Test- es suficiente y cuando una etapa de prueba puede ser terminología NAT. Minuciosidad medidas, tales como la cobertura de código alcanzado o cobertura funcional, así como estimaciones de la densidad de culpa o de su confiabilidad operativa, proporcionan un apoyo útil, pero no son sufi- ciente en sí mismos. La decisión también implica consideraciones sobre los costes y los riesgos que corren los posibles fallos restantes, a diferencia de los costos incurridos al continuar la prueba (ver Criterios de selección Prueba / Criterios de prueba de adecuación en la sección 1.2, Temas clave). 5.1.9. Prueba de Reutilización y Patrones de prueba

[9 *, c2s5]

Para llevar a cabo pruebas o mantenimiento de una forma nizado y rentable or-, los medios utilizados para probar cada parte del software deben ser reutilizados de forma sistemática. Un repositorio de materiales de prueba debe estar bajo el control del software de gestión de configuración de modo que los cambios en los requisitos de software de diseño o se pueden reflejar en cambios en las pruebas realizadas. Las soluciones de ensayo adoptadas para

5.2. Prueba Ocupaciones Como se muestra en la siguiente descripción, manejo exitoso de las actividades de prueba depende en gran medida Cess la gestión de configuración de software pro (véase el software de configuración Manage- ment KA). 5.2.1. Planificación [1 *, c12s1, c12s8] Al igual que todos los otros aspectos de la gestión de proyectos, se deben planificar las actividades de prueba. Los aspectos clave de la planificación de controles incluyen la coordinación de la persona-nel, la disponibilidad de instalaciones de prueba y equipos, creación y mantenimiento de todos los docu- mentación relacionada prueba, y la planificación de posibles resultados no deseable. Si se mantiene más de una línea de base del software, a continuación, un plan- importante consideración es la que define el tiempo y el esfuerzo necesarios para garantizar que el entorno de prueba se establece en la configuración adecuada. 5.2.2. Caso de prueba Generacion [1 *, c12s1, c12s3] Generación de casos de prueba se basa en el nivel de pruebas a realizar y las técnicas de ensayo particulares. Los casos de prueba deben estar bajo el con- trol de gestión de configuración de software e incluir los resultados esperados para cada prueba. 5.2.3. Prueba Entorno de desarrollo [1 *, c12s6] probar algunos tipos de aplicaciones, en determinadas circunstancias, con las motivaciones detrás de las decisiones tomadas, forman un patrón de prueba que puede en sí mismo ser documentados para su posterior reutilización en proyectos similares.

4-18

Guía SWEBOK® V3.0

El entorno utilizado para la prueba debe ser com- patible con herramientas niería otro software adoptada niería. Se debe facilitar el desarrollo y control de casos de prueba, así como el registro y la recuperación de los resultados esperados, guiones y otros materiales de prueba. 5.2.4. Ejecución [1 *, c12s7] La ejecución de los ensayos deberá incorporar un prin- cipio básico de la experimentación científica: todo lo realizado durante la prueba debe ser realizado y documentado con claridad suficiente como para que otra persona

Software de Pruebas 419

podrían replicar los resultados. Por lo tanto, las pruebas deben realizarse de acuerdo con los procedimientos documentados usando una versión claramente definida del software bajo prueba. 5.2.5. Prueba Evaluación de resultados

6. Herramientas de prueba de software

[9 *, c15] Los resultados de las pruebas deben ser evaluados para determinar 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 ningún principales resultados inesperados. No todos los resultados inesperados son necesariamente defectos, pero en algún momento se determinan a ser simplemente ruido. Antes de que una falla puede ser eliminado, es necesario un esfuerzo de análisis y depuración de aislar, identificar y describir. Cuando los resultados son particularmente importantes, una junta de revisión formal puede ser con- Vened para evaluarlas. 5.2.6. Informe de problemas / Registro de Pruebas

El software. información de seguimiento de defectos se utiliza para determinar qué aspectos de las pruebas de software y otros procesos necesitan mejora y la eficacia de los enfoques anteriores han sido.

[1 *, c13s9]

Las actividades de prueba se pueden introducir en un registro de pruebas para identificar cuándo se llevó a cabo una prueba, que se realiza el examen, lo que la configuración del software se utilizó, y otra identificación correspondiente infor- mación. resultados de prueba inesperados o incorrectos pueden ser grabados en un sistema de notificación de problema, los datos para el cual constituye la base para más tarde debugging y la fijación de los problemas que se observaron como fallas durante la prueba. Además, las anomalías no clasificados como fallos podrían ser documentados en caso de que más tarde resultan ser más grave de lo previsto inicialmente. Los informes de ensayo son también entradas al proceso de solicitud de la gestión del cambio (véase Control de Configuración de Software en el KA Software Configuration Management). 5.2.7. seguimiento de defectos [9 *, c9]

6.1. Herramienta de Pruebas Apoyo [1 *, c12s11] [9 *, c5] Las pruebas requiere muchas tareas intensivas en mano de obra, de funcionamiento ejecuciones numerosos programas Ning, y el manejo de una gran cantidad de información. herramientas adecuadas pueden aliviar la carga de operaciones de oficina, tediosas y hacerlos menos propensos a errores. Sofisticación herramientas CATed pueden apoyar el diseño de pruebas y generación de casos de prueba, por lo que es más eficaz. 6.1.1. Selección de Herramientas [1 *, c12s11] 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, Los defectos pueden ser rastreados y analizados para determinar cuando se introdujeron en el software, por qué fueron creados (por ejemplo, requisitos de mal definidos, ción incorrecta variable de declara-, pérdida de memoria, error de sintaxis de programación), y cuando podían haber sido observado por primera vez en

4-20

Guía SWEBOK® V3.0 como herramienta

de selección afecta en gran medida la eficiencia y la eficacia de la prueba. Selección de herramienta depende de la evidencia diversa, tales como las opciones de desarrollo, los objetivos de evaluación, instalaciones de ejecución, y así sucesivamente. En general, puede no ser una herramienta única que va a satisfacer necesidades particulares, por lo que un conjunto de herramientas podría ser una opción apropiada. 6.2. Categorías de Herramientas Clasificamos las herramientas disponibles de acuerdo a su funcionalidad: • arneses de prueba (conductores, trozos) [1 *, c3s9] proporcionan un entorno controlado en el que las pruebas pueden ser lanzados y las salidas de prueba se pueden registrar. Con el fin de ejecutar partes de un pro- grama, se proporcionan los conductores y los talones para simular llamadas tarde y llamados módulos, respectivamente. • generadores de prueba [1 *, c12s11] proporcionar tancia asis- en los casos de prueba generación. La gene- ración puede ser al azar, basado en vía modelo- basa, o una mezcla de los mismos. • herramientas de captura / reproducción [1 *, c12s11] autovolver a ejecutarlo ticamente, o de repetición, previamente

Software de Pruebas 421

pruebas ejecutadas que han grabado las entradas y salidas (por ejemplo, pantallas). • comparadores de Oracle / archivo / herramientas de comprobación de aserción [1 *, c9s7] ayudar a decidir si un resultado de la prueba es exitosa o no. • analizadores de cobertura y instrumenters [1 *, c4] trabajar juntos. analizadores de cobertura evaluar qué y cómo se han ejercido muchas entidades de la gráfica de flujo del programa entre todos los requeridos por el criterio de cobertura de prueba seleccionada. El análisis se puede hacer gracias a instrumenters que insertan sondas de grabación en el código del programa.

• trazadores [1 *, c1s7] registrar la historia de una rutas de ejecución del programa. • herramientas de pruebas de regresión [1 *, c12s16] apoyar la ejecución adicional de un conjunto de pruebas después de una sección del software ha sido modificado. También pueden ayudar a seleccionar un subconjunto de pruebas de acuerdo con el cambio realizado. • herramientas de evaluación de la fiabilidad [9 *, c8] resultados de prueba apoyo análisis y ción visualiza- gráfica a fin de evaluar medi- das relacionadas fiabilidad-de acuerdo con los modelos seleccionados.

Guía SWEBOK® V3.0

c8

1.1.2. Las fallas fallas vs.

c1s5

c11

1.2. Cuestiones clave 1.2.1. Criterios de selección de prueba/ Criterios de prueba de adecuación (Reglas de parada) 1.2.2. Prueba de Eficacia /

c1s14, c6s6, c12s7

Terminología relacionada

Objetivos para las pruebas

c13s11, c11s4

1.2.3. Las pruebas de defectos Identificación

c1s14

1.2.4. El problema de Oracle

c1s9, c9s7

1.2.5. Teórico y práctico Limitaciones de las Pruebas

c2s7

1.2.6. El problema de la Inviable Caminos

c4s7

1.2.7. la capacidad de prueba 1.3. Relación de las pruebas de Otras actividades 1.3.1. Prueba de Software vs. estáticoTécnicas de gestión de la calidad 1.3.2. La corrección de pruebas vs. Pruebas y verificación formalvs. 1.3.3. Prueba de depuración

c17s2

c12 c17s2 c3s6

1.3.4. Las pruebas contra

c3s2

2. Niveles de pruebaProgramación 2.1. El objetivo de la prueba 2.1.1. Examen de la unidad

c1s13 c3

c8s1 c8

2.1.2. Pruebas de integración

c7

c8

2.1.3. Prueba del sistema

c8

c8

nortea Nielsen 1993 [10 *]

c1, c2

1. Fundamentos de Software Testing 1.1. Terminología de pruebas relacionados 1.1.1. Definiciones de Pruebas y

Kan 2003 [9 *]

SommervilLe 2011 [2 *]

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

naik y Tripathy 2008 [1 *]

4-22

2.2. Objetivos de las Pruebas 2.2.1. Aceptación / Calificación

c1s7 c1s7

2.2.2. Prueba de la instalación

c12s2 c13s7, c16s6

2.2.3. Alfa y Beta Testing 2.2.4. Logro fiabilidady Evaluación 2.2.5. Pruebas de regresión

c15

nortea Nielsen 1993 [10 *]

Kan 2003 [9 *]

SommervilLe 2011 [2 *]

naik y Tripathy 2008 [1 *]

Software de Pruebas 423

c8s4

c8s4 c15s2

c8s11, c13s3

2.2.6. Pruebas de rendimiento

c8s6

2.2.7. Pruebas de seguridad 2.2.8. Pruebas de estrés

c8s3 c8s8

c11s4

2.2.9. Back-to-Back Testing 2.2.10. Prueba de recuperación 2.2.11. Prueba de interfaz 2.2.12. Prueba de configuración 2.2.13. usabilidady Pruebas Human Computer Interaction 3. Técnicas de Prueba

c14s2 c8s1.3 c8s5 c6

3.1. Basadoen la intuición y la experiencia del ingeniero de software 3.1.1. Ad hoc 3.1.2. Prueba exploratoria 3.2. Basado en el dominio de entrada técnicas 3.2.1. Partición de equivalencia 3.2.2. Las pruebas por parejas 3.2.3. Análisis de valores en la 3.2.4. Pruebas al azar frontera

c9s4 c9s3 c9s5 c9s7

3.3. Técnicas de código-base 3.3.1. -Base de flujo de control criterios

c4s4.5

c4

3.3.2. Criterios basados en el flujo datos de referencia 3.3.3. de Modelos de las pruebas basadas en el Código 3.4. Técnicas basada en la culpa 3.4.1. error de adivinanzas 3.4.2. Las pruebas de mutación 3.5. Técnicas de uso-Basado 3.5.1. Perfil operativa 3.5.2. La heurística de observación del usuario 3.6. Las pruebas basado en modelos técnicas 3.6.1. Tabla de decisión 3.6.2. Las máquinas de estados finitos 3.6.3. Pruebas de formal Presupuesto

c5 c4 c1s14 c9s8 c3s5 c15s5 C5, C7

c9s6 c10 c10s11

c15

3.7. Las técnicas basadasen la naturaleza de la aplicación 3.8. Seleccióny la combinación de técnicas 3.8.1. Funcional y estructural 3.8.2. Determinista vs aleatoria

C9 c9s6

4. Las medidas de prueba relacionados 4.1. Evaluación del Programa Bajo prueba 4.1.1. Las mediciones de programas que ayudan en la planificación y ensayo de Proyectos 4.1.2. Tipos de fallos, clasificación,

c11 c4

y Estadísticas 4.1.3. Densidad de fallos 4.1.4. Prueba de vida, Fiabilidad Evaluación 4.1.5. Los modelos de crecimiento fiabilidad

nortea Nielsen 1993 [10 *]

Kan 2003 [9 *]

SommervilLe 2011 [2 *]

Guía SWEBOK® V3.0

naik y Tripathy 2008 [1 *]

4-24

c13s4

c4

c15

c3

c15

c8

4.2. Evaluación deLas pruebas realizadas 4.2.1. Cobertura / Minuciosidad medidas

c11

4.2.2. Siembra de fallos

c2s5

4.2.3. Puntuación mutación 4.2.4. Comparacióny la eficacia relativa de las diferentes técnicas

c3s5

Proceso 5. Prueba 5.1. Consideraciones prácticas 5.1.1. actitudes/ Programación sin ego 5.1.2. Guías de prueba 5.1.3. Gestión de procesos de 5.1.4. Documentación de laprueba comprobacióny productos de 5.1.5.trabajo Desarrollo basado en pruebas

c16

c15

c12s1

c15s1

c12

c15

c8s12

c4s5

c1s16

5.1.6. Independiente vs interna Equipo de prueba

c16

5.1.7. Costo / estimación de esfuerzoy Otras medidas del proceso

c18s3

5.1.8. Terminación

5.2.2. Generación de casos de prueba 5.2.3. Desarrollo Entorno de prueba 5.2.4. Ejecución 5.2.5. Resultados de la prueba Evaluación

c5s7 c10s4

5.1.9. Prueba de Reutilización y Patrones 5.2. Las actividades de prueba 5.2.1. Planificación

c6

c2s5 c12s1 c12s8 c12s1 c12s3 c12s6 c12s7 c15

nortea Nielsen 1993 [10 *]

Kan 2003 [9 *]

SommervilLe 2011 [2 *]

naik y Tripathy 2008 [1 *]

Software de Pruebas 425

5.2.6. Informe de problemas / Prueba Iniciar sesión 5.2.7. seguimiento de defectos 6. Herramientas de prueba de software 6.1. Herramienta de soporte de pruebas 6.1.1. Selección de Herramientas 6.2. Categorías de Herramientas

c13s9 C9 c12s11 c12s11 c1s7, c3s9, c4, c9s7, c12s11, c12s16

c5

c8

nortea Nielsen 1993 [10 *]

Kan 2003 [9 *]

SommervilLe 2011 [2 *]

Guía SWEBOK® V3.0

naik y Tripathy 2008 [1 *]

4-26

Software de Pruebas 427

Referencias

[2 *] I. Sommerville, Ingeniería de Software, 9ª ed., Addison-Wesley, 2011.

[8] S. Yoo y M. Harman, “pruebas de regresión Minimización, selección y priorización: una encuesta,” Pruebas de verificación de software y Fiabilidad, vol. 22, no. 2, marzo de 2012, pp. 67-120.

[3] MR Lyu, ed., Manual de Ingeniería de Software Fiabilidad, McGraw-Hill y IEEE Computer Society Press, 1996.

[9 *] SH Kan, métricas y modelos en Ingeniería de Software de Calidad, 2ª ed., AddisonWesley, 2002.

[4] H. Zhu, PAV Hall y JHR mayo, “Unidad de Software Cobertura de la prueba y suficiencia,” ACM Computing Surveys, vol. 29, no. 4, diciembre de 1997 pp. 366427.

[10 *] J. Nielsen, Ingeniería de usabilidad, Morgan Kaufmann, 1993.

[1 *] S. Naik y P. Tripathy, pruebas de software y aseguramiento de la calidad: Teoría y Práctica, Wiley-Spektrum, 2008.

[5] EW Dijkstra, “Notas sobre la programación estructurada,” Informe TH-70-WSE-03, Universidad Tecnológica de Eindhoven, 1970; http://www.cs.utexas.edu/users/EWD/ ewd02xx / EWD249.PDF. [6] ISO / IEC / IEEE P29119-1 / DIS Proyecto de Norma para Sistemas de Software y Testing Ingeniería--Parte 1 Software: Conceptos y definiciones, ISO / IEC / IEEE 2012. [7] ISO / IEC / IEEE 24765: 2010 Sistemas y de Ingeniería de Software-Vocabulario, ISO / IEC / IEEE 2010.

[11] TY Chen et al., “Adaptive Testing aleatoria: el arte de caso de prueba Diversidad,” Diario de sistemas y software, vol. 83, no. 1, enero de 2010, pp. 60-66. [12] Y. Jia y M. Harman, “An Analysis y la Encuesta de Desarrollo de pruebas de mutación “, IEEE Trans. Ingeniería de Software, vol. 37, no. 5, Sep.-Oct. 2011, pp. 649-678. [13] M. y B. Utting Legeard, práctico basado en modelos de prueba: Un Enfoque Herramientas, Morgan Kaufmann, 2007.

CAPÍTULO 5 MANTENIMIENTO DE SOFTWARE SIGLAS SEÑO R PR SMC

Solicitud de modificación Informe de problemas Gestión de la Configuración de Software

SLA

Acuerdo de nivel de servicio

SQA

Calidad de Software

V&V

Verificación y validación

INTRODUCCIÓN los esfuerzos de desarrollo de software como resultado la ery deliv- de un producto de software que satisfaga las necesidades del usuario. En consecuencia, el producto de software debe cambiar o evolucionar. Una vez en funcionamiento, los defectos se descubren, cambian entornos operativos, y los nuevos requisitos de los usuarios superficie. La fase de mantenimiento del ciclo de vida comienza después de un período de garantía o soporte posterior a la implementación del parto, pero las actividades de mantenimiento producirse mucho antes. El mantenimiento de software es una parte integral de un ciclo de vida del software. Sin embargo, no ha recibido el mismo grado de atención que las otras fases tienen. Históricamente, el desarrollo de software ha tenido un perfil mucho más alto que el mantenimiento del software en la mayoría de las organizaciones. Esto está cambiando, ya que las empresas se esfuerzan para exprimir el máximo rendimiento de su inversión en el desarrollo de software por el software que opera ING mantener- el mayor tiempo posible. El

paradigma de código abierto ha traído más atención a la cuestión del mantenimiento de artefactos de software desarrollados por otros. En esta guía, el mantenimiento del software se define como el conjunto de actividades necesarias para proporcionar soporte rentable de software. Las actividades se llevan a cabo durante la etapa de pre-entrega, así como

Software de Pruebas 4Esta primera sección presenta los conceptos y 29 terminología que forman una base subyacente a la comprensión de la función y el alcance del mantenimiento del software. Los temas proporcionan definiciones y hacer hincapié en por qué hay una necesidad de mantenimiento. Categorías de mantenimiento de software son fundamentales para la comprensión de su significado subyacente.

durante la etapa de posparto. actividades antes de la entrega incluyen la planificación para las operaciones de posparto, el mantenimiento, y la determinación de la logística para las actividades de transición [1 *, c6s9]. posparto actividades incluyen la modificación de software, capacitación y operativo o interfaz con una mesa de ayuda. El área de conocimiento de mantenimiento de software (KA) se relaciona con todos los demás aspectos de la ingeniería de software. Por lo tanto, esta descripción KA está vinculado a todos los demás de ingeniería de software KAs de la Guía.

1.1. Definiciones y terminología [1 *, c3] [2 *, c1s2, C2S2] El propósito del mantenimiento del software se define en el estándar internacional para el mantenimiento de software:. ISO / IEC / IEEE 14764 [1 *] 1 En el contexto de la ingeniería de software, mantenimiento de software es esencialmente uno de los muchos procesos técnicos.

DISTRIBUCIÓN DE TEMAS PARA MANTENIMIENTO DE SOFTWARE El desglose de temas para el manteni- Software Principal- KA se muestra en la Figura 5.1. 1. Fundamentos software

de

mantenimiento

de

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 software existente, preservando su integridad. La norma internacional también señala la importancia de tener algunas actividades de mantenimiento antes de la entrega final de software (actividades previas a la entrega). En particular, IEEE 14764 hace hincapié en la importancia de los aspectos de mantenimiento previo a la entrega de planificación, por ejemplo. 1.2. Naturaleza de Mantenimiento [2 *, c1s3] mantenimiento de software sostiene UCT el software PRODUCIRSE lo largo de su ciclo de vida (desde el desarrollo de las operaciones). Las solicitudes de modificación se registran y se realiza un seguimiento, se determina el impacto

de los cambios propuestos, código de software y otros artefactos son

modificada, la prueba se lleva a cabo, y una nueva versión del producto de software es liberado. Además, forma- ción y apoyo diario se proporcionan a los usuarios. El término mantenedor se define como una organización que lleva a cabo actividades de mantenimiento. En este KA, el término se referirá en ocasiones a las personas que per- formar esas actividades, lo que contrasta con los desarrolladores. IEEE 14764 identifica las principales actividades de mantenimiento de software como la implementación de procesos, análisis de problemas y la modificación, la implementación de modificación, revisión de mantenimiento / aceptación, la migración, y la jubilación. Estas actividades se describen en la sección 3.2, las actividades de mantenimiento. Mantenedores pueden aprender a partir del conocimiento del software de la ERS desarrollos. El contacto con los desarrolladores y la participación temprana de la

Mantenimiento de Software 5-3

5-4 Guía SWEBOK® V3.0

mantenedor ayuda a reducir el esfuerzo de mantenimiento general. En algunos casos, el desarrollador inicial no puede ser alcanzado o ha pasado a otras tareas, lo que crea un desafío adicional para manrecipientes. El mantenimiento debe tener artefactos de software de desarrollo (por ejemplo, código o documentación) y apoyarlos de inmediato, y luego evolucionar progresivamente / mantenerlas durante un ciclo de vida del software. 1.3. La necesidad de mantenimiento [2 *, c1s5] El mantenimiento es necesario para asegurar que el software continúa para satisfacer las necesidades del usuario. manteni- miento es aplicable al software que se desarrolla utilizando cualquier modelo de ciclo de vida del software (por ejemplo, espiral o lineal). productos de software cambian debido a las acciones correctivas y de software noncorrective. Mantenimiento debe ser realizado con el fin de • • • • •

corregir fallas; mejorar el diseño; implementar mejoras; interactuar con otros softwares; adaptar los programas a fin de que distintos tipos de hardware, el software, las características del sistema y de las telecomunicaciones instalaciones se pueden utilizar; • migrar software heredado; y • retirarse de software. Cinco características clave incluyen las actividades de la er maintain-: • mantener el control sobre las funciones de día-a-día del software; • maintainingcontrolover software modificación; • el perfeccionamiento de las funciones existentes; • la identificación de amenazas a la seguridad y la fijación de las vulnerabilidades de seguridad; y • preventingsoftwareperformancefrom degradantes a inaceptable los niveles.

1.4. La mayoría de los costos de mantenimiento [2 *, c4s3, c5s5.2] Mantenimiento consume una parte importante de la financiales recursos en un ciclo de vida del software. Una común

percepción de mantenimiento del software es que se limita a fijar los fallos. Sin embargo, estudios y encuestas realizadas a lo largo de los años han indicado que la dad de División, más del 80 por ciento, del mantenimiento del software se utiliza para acciones noncorrective [2 *, figura 4.1]. La agrupación de mejoras y correcciones juntos en los informes de gestión contribuye a algunos conceptos erróneos con respecto a los altos costos de correcciones. La comprensión de las categorías de mantenimiento de software ayuda a comprender la estructura de los costes de mantenimiento de software. Además, la comprensión de los factores que influyen en la capacidad de mantenimiento de software puede ayudar a contener los costos. Algunos factores medioambientales y su relación con los costos de mantenimiento de software incluyen los siguientes: • Entorno de funcionamiento se refiere al hardware y el software. • ambiente organizacional se refiere a cies POLI, competencia, proceso, producto, y personal. 1.5. Evolución de Software [2 *, c3s5] El mantenimiento del software en términos de evolución se abordó por primera vez en la década de 1960. Durante un período de veinte años, la investigación condujo a la formulación de ocho “leyes de la evolución.” Las principales conclusiones son una propuesta que el mantenimiento es desa- rrollo evolutivo y que las decisiones de mantenimiento son ayudados mediante la comprensión de lo que ocurre con el software con el tiempo. Algunos afirman que el mantenimiento se continúa el desarrollo, con la excepción de que hay una entrada adicional (o restricción), en otras palabras, que existe gran soft- ware nunca es completa y continúa evolucionando; a medida que evoluciona, crece más compleja si no se toman algunas medidas para reducir esta complejidad. 1.6. Categorías de Mantenimiento [1 *, c3, c6s2] [2 *, c3s3.1] Se han definido tres categorías (tipos) de mantenimiento: correctivo, adaptativo y

Mantenimiento de Software perfec- tivo [2 *, c4s3]. IEEE 14764 incluye una 5-5 cuarta categoría-preventivo.

• El mantenimiento correctivo: modifi- reactiva cación (o reparaciones) de un producto de software

5-6 Guía SWEBOK® V3.0

realizado después de la entrega para corregir problemas Ered descu-. Se incluyen en esta categoría es el mantenimiento de emergencia, que es una modificación no programada se realiza para mantener temporariamente un producto de software en funcionamiento en espera de mantenimiento correctivo. • mantenimiento adaptativo: modificación de un producto de software se realiza después de la entrega para mantener un producto de software que puedan utilizarse en un entorno cambiante o cambiar. Por ejemplo, el sistema operativo puede ser actualizado y algunos cambios en el software puede ser necesario. • mantenimiento perfectivo: modificación de un producto de software después de la entrega para proporcionar mejoras para los usuarios, mejora de la documentación del programa, y la recodificación para mejorar el rendimiento del software, capacidad maintain-, u otros atributos de software. • El mantenimiento preventivo: modificación de un producto de software después del parto para detectar fallas latentes y correctas en el producto de software antes de que sean fallos de funcionamiento. IEEE 14764 clasifica mantenimiento adaptativo y perfectivo como mejoras de mantenimiento. También agrupa a las categorías de mantenimiento tiva correctivas y prevención en una corrección CAT- goría, como se muestra en la Tabla 5.1. Tabla 5.1. Mantenimiento de Software Categorías Corrección Mejora Proactivo Reactivo

Preventivo Correctivo

perfectivo Adaptado

2. Cuestiones clave en el mantenimiento de software Una serie de cuestiones clave debe ser tratada para garantizar el mantenimiento eficaz de software. mantenimiento de software ofrece retos únicos cal y de gestión técnicamente para los ingenieros de software-para ejemplo, tratando de encontrar un fallo en el software que contiene un gran número de líneas de código que

próximo lanzamiento, mientras que el envío de parches de emergencia para la versión actual, también crea un desafío. En la siguiente sección se presentan algunos de los problemas gías Nical y de gestión relacionados con el mantenimiento del software. Se han agrupado bajo los siguientes encabezados de los temas: • • • •

problemas técnicos, asuntos Gerenciales, estimación de costos, y medición.

2.1. Técnico Cuestiones 2.1.1. La comprensión limitada [2 *, c6] comprensión limitada se refiere a la rapidez con que un ingeniero de software puede entender que para hacer un cambio o corrección en el software que él o ella no se desarrolló. Las investigaciones indican que aproximadamente la mitad del total del esfuerzo de mantenimiento se dedica a pie Adjunto del software para ser modificado. Por lo tanto, el tema de la comprensión de software es de gran inter est a los ingenieros de software. La comprensión es más difícil en el código fuente de la representación en orientada a texto, por ejemplo, donde a menudo es difícil trazar la evolución del software a través de sus publicaciones / versiones si los cambios no están documentados y si los desarrolladores no están disponibles a lo explican, lo que suele ser el caso. Por lo tanto, los ingenieros de software pueden ini- cialmente tienen una comprensión limitada del software; aún queda mucho por hacer para remediar esto. 2.1.2. Pruebas [1 *, c6s2.2.2] [2 *, c9] otro ingeniero de software desarrollados. Del mismo modo, compitiendo con los desarrolladores de software de recursos es una batalla constante. La planificación de una versión futura, que a menudo incluye la codificación

El costo de la repetición de la prueba completa en una pieza importante de software es importante en términos de tiempo y dinero. Con el fin de garantizar que los informes de problemas solicitados son válidos, el mantenedor debe replicar o verificar los problemas mediante la ejecución de las pruebas adecuadas. Las pruebas de regresión (la repetición de pruebas selec- tiva de software o un componente de ver- ify que las modificaciones no han causado efectos unincuidados) es un concepto importante en las pruebas de mantenimiento. Además, encontrar tiempo para probar es a menudo difícil. La coordinación de las pruebas cuando diferentes miembros del equipo de mantenimiento están trabajando

Mantenimiento de Software 5-7

5-8 Guía SWEBOK® V3.0

sobre diferentes problemas al mismo tiempo sigue siendo un desafío. Cuando el software realiza fun- ciones críticos, puede ser difícil para llevarlo fuera de línea para la prueba. Las pruebas no se pueden ejecutar en el lugar-ful el sistema de producción más sentido-. La Prueba KA Software proporciona información y referencias adicionales sobre este asunto en su subtema en las pruebas de regresión. 2.1.3. Análisis de impacto [1 *, c5s2.5] [2 *, c13s3] Análisis de impacto describe cómo llevar a cabo, de manera rentable, un análisis completo del impacto de un cambio en el software existente. Mantenedores deben poseer un conocimiento profundo de la estructura y el contenido del software. Ellos usan este conocimiento para llevar a cabo análisis de impacto, que identifica a todos los sistemas y productos de software afectadas por una solicitud de cambio de software y desarrolla una estimación de los recursos necesarios para llevar a cabo el cambio. Además, se determina el riesgo de hacer el cambio. La solicitud de cambio, a veces se llama una petición de modificación (MR) y, a menudo llamado un informe de problemas (PR), primero debe ser analizado y traducido en términos de software. Análisis de impacto se realiza después de una solicitud de cambio entra en el proceso de gestión de la configuración soft- ware. IEEE 14764 establece las tareas de análisis de impacto:

2.1.4. mantenibilidad [1 *, c6s8] [2 *, c12s5.5] IEEE 14 764 [1 *, c3s4] define mantenibilidad como la capacidad del producto de software para ser modificado. Las modificaciones pueden incluir correcciones, mejoras, o la adaptación del software a cambios en el entorno, así como cambios en los requisitos y especificaciones funcionales. Como una característica de calidad del software principal, capacidad de mantenimiento se debe especificar, revisado y controlado durante los lazos de desarrollo de software activi- el fin de reducir los costes de mantenimiento. Cuando se hace correctamente, el mantenimiento del software mejorará. La mantenibilidad es a menudo difícil de lograr debido a las subcaracterísticas menudo no son un foco importante durante el proceso de desarrollo de soft- ware. Los desarrolladores están, por lo general, más preocupados con muchas otras actividades y con frecuencia propensos a ignorar las exigencias del mantenedor. Esto a su vez puede, ya menudo lo hace, dar lugar a una falta de documentación de software y entornos de prueba, que es una de las principales causas de los lazos dificultades en la comprensión del programa y análisis de impacto posterior. La presencia de procesos sistemáticos y maduros, técnicas y herramientas de ayuda para mejorar la capacidad de mantenimiento de software. 2.2. Asuntos Gerenciales

• analizar MRs / IPs; • replicar o verificar el problema; • desarrollar opciones para la aplicación del modificación; • documentar el MR / PR, los resultados y las opciones de ejecución; • obtener la aprobación de la modificación seleccionada opción. La gravedad de un problema a menudo se utiliza para decidir cómo y cuándo va a ser fijo. El ingeniero de soft- ware a continuación, identifica los componen- tes afectados. Se proporcionan varias soluciones posibles, seguido de una recomendación sobre el mejor curso de

2.2.1. La alineación con los objetivos organizacionales [2 *, c4] acción. Software diseñado con capacidad de mantenimiento en mente facilita en gran medida el análisis del impacto. más infor- mación se puede encontrar en el software de gestión de la configuración KA.

objetivos de la organización describen cómo para demostrar los retorno de la inversión de software de man- actividades tenance. desarrollo de software inicial es por lo general basado en proyectos, con una escala de tiempo definido y presupuesto. El énfasis principal es entregar un producto que satisfaga las necesidades del usuario a tiempo y dentro del presupuesto. Por el contrario, el mantenimiento de software a menudo tiene el objetivo de extender la vida de software para el mayor tiempo posible. Además, puede ser impulsado por la necesidad de satisfacer la demanda del usuario para las actualizaciones y mejoras del software. En ambos casos, el retorno de la inversión es mucho menos clara, por lo que la vista en el nivel de la alta dirección es a menudo la de una importante actividad que consume recursos significativos sin ningún beneficio cuantificable clara para la organización.

Mantenimiento de Software 5-9

5-10

Guía SWEBOK® V3.0

2.2.2. dotació n de [2 *, c4s5, persona c10s4] l Dotación de personal se refiere a la manera de atraer y mantener al personal de mantenimiento soft- ware. El mantenimiento no es a menudo visto como un trabajo glamoroso. Como resultado, se ve con más frecuencia el personal de mantenimiento de software como “ciudadanos de segunda clase”, y por lo tanto la moral sufre.

asignación de la responsabilidad de mantenimiento a un solo grupo o persona, independientemente de la estructura de la organiza- ción. 2.2.5. La externalizac ión

[3 *]

• promueve una atmósfera sin ego, universitarios; • reduce la dependencia de los individuos; • permite controles de auditoría periódicas.

2.2.3. Proceso [1 *, c5] [2 *, c5] El proceso del ciclo de vida del software es un conjunto de actividades, métodos, prácticas y transformaciones que PEO uso PLE para desarrollar y mantener el software y sus productos asociados. A nivel de proceso, las actividades de mantenimiento de software tienen mucho en común con el desarrollo de software (por ejemplo, gestión de configuración de software es una actividad crucial en ambos). El mantenimiento también requiere varias actividades que no se encuentran en desarrollo de software (ver sección 3.2 en actividades únicas para más detalles). Estas actividades presentan desafíos para la gestión. 2.2.4. Aspectos de organización de Mantenimiento [1 *, c7s2.3] [2 *, c10] Aspectos organizativos describen cómo identificar qué organización y / o función será responsable del mantenimiento del software. El equipo que desarrolla el software no está necessar- ily asignado para mantener el software una vez que esté en funcionamiento. Al decidir dónde se ubicará la función de mantenimiento de software, las organizaciones de ingeniería de software pueden ser, por ejemplo, quedarse con el desarrollador original o ir a un equipo de mantenimiento específico permanente (o personal de mantenimiento). Tener un equipo de mantenimiento permanente tiene muchos beneficios: • permite la especialización; • crea canales de comunicación;

Puesto que hay muchos pros y los contras de cada opción, la decisión debe hacerse sobre una base de caso por caso. Lo que es importante es la delegación o

La externalización y la deslocalización de software manteni- miento se ha convertido en una industria importante. Las organizaciones que están externalizando carteras enteras de software, incluyendo el mantenimiento del software. Más a menudo, la opción de la externalización se selecciona por menos de software de misión crítica, como las organizaciones no están dispuestos a perder el control del software utilizado en su negocio principal. Uno de los principales retos para los subcontratistas es determinar el alcance de los servicios de mantenimiento requeridos, los términos de un acuerdo de nivel de ser- vicio, y los detalles contractuales. Subcontratistas tendrán que invertir en una infraestructura de mantenimiento y el servicio de asistencia en el sitio remoto debe contar con personal con hablantes de lengua nativa. La externalización requiere una inver- sión inicial importante y la configuración de un proceso de mantenimiento que requerirá la automatización. 2.3. Estimación de costes de mantenimiento Los ingenieros de software deben entender las diferentes categorías de mantenimiento de software, expuestos anteriormente, con el fin de abordar la cuestión de ing realizan estimaciones del costo de mantenimiento de software. Para fines de planificación, estimación de costos es un aspecto importante de la planificación para el mantenimiento del software. 2.3.1. Estimación de costos [2 *, c7s2.4] Sección 2.1.3 se describe cómo el análisis del impacto iden- tifica todos los sistemas y productos de software afectadas por una solicitud de cambio de software y desarrolla una estimación de los recursos necesarios para llevar a cabo ese cambio. estimaciones de los costos de mantenimiento se ven afectados por muchos factores técnicos y no técnicos. IEEE 14764 establece que “los dos métodos más populares a los recursos de estimación para el mantenimiento del software son el uso de modelos paramétricos y el uso de la experiencia” [1 *, c7s4.1]. Una combinación de estos dos también se puede utilizar.

Mantenimiento de Software 5-11

5-12

Guía SWEBOK® V3.0

2.3.2. Los modelos paramétricos

[2 *, c12s5.6]

el modelo de costos paramétricos (modelos matemáticos) se ha aplicado al mantenimiento del software. De significación es que se necesitan datos históricos del pasado de manteni- miento con el fin de usar y calibrar los modelos matemáticos. atributos generador de costos afectan las estimaciones. 2.3.3. Experiencia [2 *, c12s5.5] La experiencia, en forma de juicio de expertos, se utiliza a menudo para estimar el esfuerzo de mantenimiento. Claramente, el mejor enfoque para el mantenimiento mación estimación es combinar los datos históricos y expe- riencia. El coste para llevar a cabo una modificación (en términos de número de personas y la cantidad de tiempo) se deriva entonces. datos históricos de estimación de mantenimiento deben ser proporcionados como resultado de un programa de medición. 2.4. Medición de mantenimiento de software [1 *, c6s5] [2 *, c12] Entidades relacionadas con el mantenimiento del software, cuyos atributos puede ser sometido a medición, incluyen procesos, recursos, y el producto [2 *, c12s3.1]. Hay varias medidas de software que se pueden derivar de los atributos del software, el proceso de mantenimiento y personal, tamaño ing INCLUYENDO, la complejidad, la calidad, la comprensibilidad, mantenibilidad y esfuerzo. medidas de la complejidad del software también se pueden obtener utilizando herramientas comerciales disponibles. Estas medidas constituyen un buen punto de partida para el programa de medi- ción del mantenedor. La discusión de los procesos de software y medición del producto también se presenta en la Ingeniería de Procesos de Software KA. El tema de un programa de medición de software se describe en el Software Engineering Management KA. 2.4.1. Las medidas específicas

modelo de calidad sugiere medidas que son específicos para el mantenimiento del software. Medidas para la carac- subchar- de mantenimiento incluyen el seguimiento [2 *, c12] El mantenedor debe determinar qué medidas son adecuadas para una organización específica basada en el propio contexto de esa organización. El software

ING [4 *, p. 60]: • Analizabilidad: medidas de esfuerzo o recursos utilizados en el intento, ya sea para diagnosticar deficiencias o causas de fallo o para identificar las partes del mantenedor a ser modificados. • Mutabilidad: medidas de esfuerzo del mantenedor asociados con la implementación de una modificación cado speci-. • Estabilidad: medidas del comporta- miento inesperado de software, incluidos los que se encontró durante la prueba. • La capacidad de prueba: medidas del mantenedor del esfuerzo y de los usuarios en el intento de probar el software modificado. • Otras medidas que utilizan los mantenedores incluyen • tamaño del software, • complejidad del software, • comprensibilidad, y • mantenibilidad. Proporcionar esfuerzo de mantenimiento de software, por categorías, para diferentes aplicaciones proporciona información de la empresa a los usuarios y sus organiza- ciones. También puede permitir la comparación de los perfiles de mantenimiento soft- ware internamente dentro de una organización. 3. Proceso de mantenimiento Además de la ingeniería de software cesos pro estándar y las actividades descritas en el estándar IEEE 14764, hay una serie de actividades que son exclusivas de los mantenedores. 3.1. Los procesos de mantenimiento [1 *, c5] [2 *, c5] [5, S5.5] procesos de mantenimiento proporcionan necesarias actividades y las entradas / salidas detalladas a aquellas actividades como se describe en IEEE 14764. actividades Cess el mantenimiento pro- de IEEE 14764 se muestran en la figura 5.2. las actividades de mantenimiento de software incluyen • implementación de procesos, • problema y el análisis de la modificación, • aplicación modificación,

Mantenimiento de Software 5-13

5-14

Guía SWEBOK® V3.0

• opinión de mantenimiento / aceptación, • migración y • Retirada del software.

Figura 5.2. Proceso de Mantenimiento de Software

Otros modelos de procesos de mantenimiento incluyen: • • • • •

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

Recientemente, metodologías ágiles, que promueven los procesos de luz, también se han adaptado a mante- manteni-. Este requisito surge de la creciente demanda en constante para la entrega rápida de los servicios de mantenimiento. Mejoras para el proceso de mantenimiento del software se apoya en modelos especializados capacidad de mantenimiento de software de vencimiento (ver [6] y [7], que están anotados brevemente en la sección Lecturas Además). 3.2. Actividades de mantenimiento [1 *, c5, c6s8.2, c7s3.3] El proceso de mantenimiento contiene las actividades y tareas necesarias para modificar un producto soft- ware existente, preservando su

integridad. Estas

actividades y tareas son responsabilidad del mantenedor. Como ya se ha señalado, muchas actividades de mantenimiento son similares a las del 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. • Transición: una secuencia controlada y coordinada de las actividades durante el cual el software se transfiere progresivamente de la oper desa- al mantenedor. • solicitud de modificación de la aceptación / rechazo: modificaciones que solicitan trabajo más allá de un CER Tain tamaño / esfuerzo / complejidad pueden ser rechazados por los mantenedores y son redirigidos a un desarrollador. • Mantenimiento de mesa de ayuda: un usuario final y la función de soporte de mantenimiento coordinado que desencadena la evaluación, priorización y cálculo de costos de las solicitudes de modificación. • Análisis de impacto: una técnica para identificar las áreas afectadas por un cambio potencial; • Acuerdos de mantenimiento de nivel de servicio (SLA) y licencias de mantenimiento y con- tratos: acuerdos contractuales que describen los servicios y los objetivos de calidad. 3.2.2. Las actividades que apoyen [1 *, c4s1, c5, c6s7] [2 *, c9]

Mantenimiento de Software 5-15

Mantenedores también pueden realizar actividades de apoyo, como la documentación, gestión de configuración de software, verificación y validación, resolución de problemas, el software de control de calidad, revisión,

5-16

Guía SWEBOK® V3.0

y las auditorías. Otra actividad importante apoyo consiste en la formación de los mantenedores y usuarios. 3.2.3. Actividades de mantenimiento Planificación [1 *, c7s3] Una actividad importante para el mantenimiento del software es la planificación, y mantenedores debe abordar las cuestiones relacionadas con la planificación de una serie de perspectivas, incluyendo • la planificación de negocios (nivel de la organización), • la planificación del mantenimiento (nivel de transición), • planificación de entregas / versión (versión de software), y • planificación individual cambio de software petición (nivel de solicitud). A nivel de petición individual, la planificación se lleva a cabo durante el análisis de impacto (ver sec- ción 2.1.3, el análisis del impacto). La actividad de planificación de entregas / versión requiere que el mantenedor: • recoger las fechas de disponibilidad de las solicitudes individuales, • de acuerdo con los usuarios sobre el contenido de versiones posteriores / versiones, • identificar los conflictos potenciales y desarrollar alternativas, • evaluar el riesgo de un comunicado dado y desarrollar un plan de respaldo en caso de que surjan problemas, y • informar a todos los interesados. Considerando que los proyectos de desarrollo de software normalmente pueden durar desde algunos meses hasta unos pocos años, la fase de mantenimiento suele durar muchos años. Haciendo estimaciones de los recursos es un elemento clave de la planificación del mantenimiento. Software de planificación de manteni- miento debe comenzar con la decisión de desarrollar un nuevo producto de software y deben considerar los objetivos de calidad. Un documento de reflexión debe ser desarrollado,

seguido de un plan de mantenimiento. El concepto de mantenimiento para cada producto de software debe ser documentado en el plan [1 *, c7s2] y debe hacer frente a la • ámbito del mantenimiento de software, • la adaptación del proceso de mantenimiento de software,

• identificación del mantenimiento de software organización, y • estimación de los costes de mantenimiento de software. El siguiente paso es desarrollar un plan de mantenimiento de software correspondiente. Este plan debe ser preparado durante el desarrollo de software y debe especificar cómo los usuarios solicitar modifi- caciones de software o reportar problemas. la planificación del mantenimiento de software se aborda en IEEE 14764. Proporciona directrices para un plan de mantenimiento. Por último, al más alto nivel, la organización de mantenimiento tendrá que llevar a cabo actividades de planificación de negocios (y los recursos humanos, presupuestarios financieros) al igual que todas las otras divisiones de la organización. Gestión se discute en el capítulo relacionado Disciplinas de Ingeniería de Software. 3.2.4. Gestión de la Configuración de Software [1 *, c5s1.2.3] [2 *, c11] IEEE 14 764 describe la administración de configuración de software como un elemento crítico del proceso de manteni- miento. Ment procedimientos manage- de configuración de software deben proporcionar para la verificación, validación y auditoría de cada paso necesario para identificar, autorizar, implementar y liberar el producto de software. No es suficiente con realizar un seguimiento de las solicitudes de modifi- cación o informe de problemas. El producto de software y los cambios realizados a la misma deben ser Controlled. Este control se establece por ING implement- y aplicación de un proceso de software de gestión aprobado configu- ración (SMC). La Administración de KA del software de configuración proporciona detalles de SMC y discute el proceso por el cual las solicitudes de cambio soft- Ware presentado, evaluado y aprobado. SMC para el mantenimiento de software es diferente de SMC para el desarrollo de software en el número de pequeños cambios que debe ser controlada con- el software operativo. El pro- ceso SMC se implementa mediante el desarrollo y siguiendo unos procedimientos del plan de gestión y operación de configuración de software. Mantenedores participan en las Juntas de Control de configuración para

Mantenimiento Software/ determinar el contenido de la próximadeversión 5-17 versión.

5-18

Guía SWEBOK® V3.0

3.2.5. Calidad del software [1 *, c6s5, c6s7, c6s8] [2 *, c12s5.3]

4.3. Ingeniería inversa

No es suficiente con la esperanza de que una mayor calidad tendrá como resultado del mantenimiento de soft- ware. Mantenedores deben tener un programa de cali- dad de software. Se debe planificarse y procesos debe ser implementado para apoyar el proceso de mantenimiento. Las actividades y técnicas para la Cesión de Software Quality Assurance (SQA), V & V, opiniones y auditorías deben ser seleccionados de común acuerdo con todos los demás procesos para alcanzar el nivel deseado de calidad. También se recomienda que el tainer man- adaptar el desarrollo de software procesos, técnicas y resultados (por ejemplo, la documentación de la prueba), y los resultados de las pruebas. Más detalles se pueden encontrar en la calidad del software KA.

La ingeniería inversa es el proceso de análisis de software para identificar los componentes del software y sus interrelaciones y crear representaciones del software en otra forma o en los niveles más altos de abstracción. Reverse Engineer- ing es pasivo; no cambia el software o dar lugar a un nuevo software. Invertir Engineeresfuerzos ing producen gráficos de llamada y gráficos de flujo de control de código fuente. Un tipo de ingeniería inversa es redocumentación. Otro tipo es la recuperación de diseño. Por último, los datos inversa inge- niería, donde los esquemas lógicos son recuperados de bases de datos físicos, ha crecido en importancia en los últimos años. Las herramientas son clave para inge- niería inversa y tareas relacionadas, como redocumenta- ción y recuperación de diseño.

[1 *, c6s2] [2 *, c7, c14s5]

4. Las técnicas para mantenimiento Este tema se presentan algunas de las técnicas generalmente aceptados utilizados en el mantenimiento del software.

4.4. Migració n

4.1. programa de Comprensión

Durante la vida de software, que puede tener que ser modificada convenientemente para funcionar en entornos diferentes. Con el fin de migrar a un nuevo entorno, el mantenedor trata de mejorar una estructura pro- grama y su facilidad de mantenimiento. ING técnicas Refactor- se pueden utilizar durante los cambios de menor importancia.

[2 *, c6, c14s5]

Los programadores pasan considerables lectura y la comprensión de los programas con el fin de implementar los cambios de tiempo. navegadores de código son herramientas clave para la comprensión del programa y se utilizan para organizar y código fuente ent PRESION. documentación clara y concisa también puede ayudar en la comprensión del programa. 4.2. reingeniería [2 *, c7] Reingeniería se define como el examen y la alteración de software para reconstituir en una nueva forma, e incluye el ción ¡Ejecución posterior de la nueva forma. A menudo no se lleva a cabo para mejorar la mantenibilidad, pero para reemplazar el envejecimiento de software ACY pierna-. Refactoring es una téc- nica reingeniería que pretende reorganizar un programa sin cambiar su comportamiento. Se

[1 *, c5s5]

necesita determinar las acciones necesarias para la migración cumpla cabalmente, y luego desarrollar y docu- mento los pasos necesarios para llevar a cabo la migración en un plan de migración que cubre los requisitos de migración, herramientas de migración, conversión del producto y datos, ejecución, verificación , y apoyo. Migración de software también puede implicar una serie de actividades adicionales, tales como • notificación de la intención: una declaración de por qué el antiguo entorno ya no ser Apoyado, seguida de una descripción del nuevo entorno y su fecha de disponibilidad es; • operaciones paralelas: poner a disposición los viejos y nuevos entornos de modo que el usuario experimenta una transición suave al nuevo entorno; • notificación de finalización: cuando se haya completado la migración ULed sched-, se envía una notificación a todos los interesados;

Mantenimiento de Software 5-19

Mantenimiento de Software 5-11

• opinión después de la operación: una evaluación de la operación parale- y el impacto del cambio al nuevo entorno; • archivado de datos: almacenamiento de los datos del software de edad. 4.5. Jubilación [1 *, c5s6] Una vez que el software ha alcanzado el final de su vida ful uso-, debe ser retirado. Un análisis debe llevarse a cabo para ayudar a tomar la decisión de retiro. Este análisis debe ser incluido en el plan de retiro, que cubre mentos de jubilación requisitos, el impacto de reemplazo, calendario, y esfuerzo. Accesibilidad de copias de archivo de datos también puede ser incluido. Retirarse de software conlleva una serie de actividades similares a la migración. 5. Herramientas software

de

mantenimiento

de

[1 *, c6s4] [2 *, c14] Este tema abarca herramientas que son particularmente importantes en el mantenimiento de software donde se está modificando el software existen- ing. Ejemplos CON RESPECTO A comprensión del programa incluye

• rebanadoras de programas, que seleccionan sólo partes de una programa afectado por un cambio; • analizadores estáticos, que permiten ing vista- general y resúmenes de un contenido del programa; • analizadores dinámicos, que permiten al tainer man- conocer la vía de ejecución de un programa; • analizadores de flujo de datos, que permiten al tainer man- realizar el seguimiento de todos los posibles flujos de datos de un programa; • cruzadas referencers, que generan los índices de los componentes del programa; y • analizadores de dependencia, que ayudan a ERS maintain- analizar y comprender las interrelaciones entre los componentes de un programa. Herramientas de ingeniería inversa ayudan al proceso trabajando hacia atrás desde un producto existente para crear artefactos tales como especificación y diseño descripciones, que a continuación se pueden transformar para generar un nuevo producto de una antigua. Principaltambién utilizan recipientes de prueba de software, gestión de con- figuración de software, documentación de software y herramientas de medición de software.

5-12

Guía SWEBOK® V3.0

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 1.5. Evolución de Software 1.6. Categorías de Mantenimiento

Sneed 2008 [3 *]

Grubb y Takang 2003 [2 *]

1. Fundamentos de mantenimiento de software 1.1. Definiciones y terminología

yoEEE / ISO / IEC 14764 2006 [1 *]

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

c4s3, c5s5.2 c3s5 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 2.1.2. Pruebas 2.1.3. Análisis de impacto 2.1.4. mantenibilidad

c6 c6s2.2.2

C9

c5s2.5

c13s3

c6s8, c3s4

c12s5.5

2.2. Asuntos Gerenciales 2.2.1. Alineación con objetivos de la organización 2.2.2. dotación de personal 2.2.3. Proceso 2.2.4. OrganizativoAspectos de Mantenimiento 2.2.5. Subcontrataciones / Offshoring 2.3. Estimación de costes de mantenimiento 2.3.1. Estimación de costos

c4 c4s5, c10s4 c5

c5

c7s.2.3

c10 todas

c7s4.1

c7s2.4

2.3.2. Los modelos paramétricos

c12s5.6

2.3.3. Experiencia

c12s5.5

2.4. Medición de mantenimiento de software 2.4.1. Las medidas específicas 3. Proceso de Mantenimiento 3.1. Los procesos de mantenimiento 3.2. Actividades de mantenimiento 3.2.1. Actividades únicas 3.2.2. Las actividades que apoyen 3.2.3. Planificación de mantenimiento Ocupaciones 3.2.4. SoftwareGestión de la configuración 3.2.5. Calidad del software

c6s5

c12, c12s3.1 c12

c5

c5

c5, c5s3.2.2, c6s8.2, c7s3.3 c3s10, c6s9, c7s2, c7s3

C6, C7

c4s1, c5, c6s7

C9

c7s2, c7s.3 c5s1.2.3

c11

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

4.4. Migración

c5s5

4.5. Jubilación

c5s6

5. Herramientas de Mantenimiento de Software

c6s4

c7, c14s5

c14

Sneed 2008 [3 *]

Grubb y Takang 2003 [2 *]

yoEEE / ISO / IEC 14764 2006 [1 *]

Mantenimiento de Software 5-13

5-14

Guía SWEBOK® V3.0

LECTURAS

Referencias

A.

[1 *] IEEE Std. 14764-2006 (también conocido como ISO / IEC 14764: 2006) estándar para el software del ciclo de vida del software de ingeniería y procesos de mantenimiento, IEEE 2006.

abril y A. Abran, Gestión de Mantenimiento de Software: Evaluación y Mejora Continua [6].

Este libro explora el dominio de los procesos de mantenimiento de software pequeños (S3M). Proporciona mapas ROAD- para mejorar cesos pro de mantenimiento de software en las organizaciones. En él se describe un modelo de madurez específica mantenimiento de software organizada por niveles que permiten la evaluación comparativa y la mejora continuas con. Metas para cada área clave Tice prác- se proporcionan, y el modelo de proceso de pretantes está totalmente alineado con la arquitectura y el marco de las normas ISO12207 internacional ISO14764 y ISO15504 y modelos de madurez populares como ITIL, COBIT, CMMI y CM3. M. Kajko-Mattsson, “Hacia un Modelo de Negocio de Mantenimiento,” IEEE Int'l Conf. Mantenimiento Software [7]. Este artículo presenta una visión general del modelo de madurez de mantenimiento correctivas (cm3). A diferencia de otros modelos de procesos, CM3 es un modelo espe- cializada, dedicado exclusivamente al mantenimiento correctivo del software. Se considera que el mantenimiento en términos de las actividades a realizar y su orden, en función de la información utilizada por estas actividades, metas, reglas y motivaciones para su ejecución, y los niveles de organización y roles involucrados en las distintas etapas de un proceso típico de mantenimiento correctivo.

[2 *] P. Grubb y AA Takang, Mantenimiento de Software: Conceptos y Práctica., 2ª ed, Editorial Científico Mundial, 2003. [3 *] HM Sneed, “Mantenimiento de Software como un Servicio de Oferta Marino”, Proc. IEEE Conf Int'l. Mantenimiento de Software (ICSM 08), IEEE, 2008, pp. 1-5. [4 *] JW Moore, La Hoja de Ruta de Ingeniería de Software: Una guía basada en estándares, Wiley-IEEE Computer Society Press, 2006. [5] ISO / IEC / IEEE 24765: 2010 Sistemas y de Ingeniería de Software-Vocabulario, ISO / IEC / IEEE 2010. [6] A. abril y A. Abran, Gestión de Mantenimiento de Software: evaluación y mejora continua, Wiley-IEEE Computer Society Press, 2008. [7] M. Kajko-Mattsson, “Hacia un mantenimiento Modelo de negocios,” Proc. Int'l Conf. Mantenimiento de Software, IEEE, 2001, pp. 500-509.

Mantenimiento de Software 5-15

CAPÍTULO 6 Software Configuration Management SIGLAS CCB CM

Configuration Control Board Gestión de la configuración

FCA

Auditoría de Configuración Funcional Auditoría de Configuración física

PCA SCCE SCI

Control de Configuración de Software Tablero Software Elemento de

SMC

Configuración Gestión de la Configuración de Software

PGCS

Plan de Gestión de la Configuración de Software

SCR SCSA SDD

Solicitud de cambio de software Estado de la configuración de software Contabilidad Documento de Diseño de Software

SEI / CMMI

Capability Maturity Model Integration de Software Engineering Institute

SQA

Calidad de Software

SRS

Requisito de software Especificación

INTRODUCCIÓN Un sistema puede ser definido como la combinación de elementos organizados para lograr uno o más propósitos declarados [1] interactuar. La configuración de un sistema es la carac- terísticas funcionales y físicas de hardware o software que se exponen en técnicacal documentación o conseguidos en un producto [1]; También se puede considerar como una colección de versiones específicas de hardware, firmware, software o elementos combinados de acuerdo a los procedimientos específicos de construcción

para servir a un propósito particular. Configuración hombre-agement (CM), a continuación, es la disciplina de que identifique los valores de la configuración de un sistema en distintos puntos en el tiempo con el fin de sistemáticamente control- ling cambios en la configuración y el mantenimiento de la integridad y la trazabilidad de la configuración de todo el ciclo de vida del sistema. Se define formalmente como Una disciplina aplicando dirección adminis- tración y técnica y vigilancia a: tificar ideny documentar las características funcionales y cal Physicians de un elemento de configuración, los cambios de control a las características, el procesamiento y la aplicación de registro y cambio de informe de estado, y verifican El cumplimiento con los requisitos especificados. [1] gestión de configuración de software (SCM) es un proceso de ciclo de vida del software de apoyo que beneficia a las actividades de gestión de proyectos, desarrollo y mantenimiento, actividades de aseguramiento de la calidad, así como los clientes y usuarios del producto final. Los conceptos de gestión de la configuración se aplican a todos los artículos que deben ser controlados, aunque hay algunas diferencias en la implementación de hardware entre el CM y CM software. SMC está estrechamente relacionado con el aseguramiento de la cali- dad (SQA) actividad de software. Tal como se define en el área de conocimiento de Calidad de Software (KA), SQA procesos garantizan que los productos de software y procesos en el ciclo de vida del proyecto se ajustan a sus requerimientos especificados por la planificación, la promulgación, y la realización de un conjunto de

actividades para proporcionar la confianza adecuada de que la calidad se está construyendo en el software. actividades de SCM ayudan en el cumplimiento de estos

objetivos SQA. En algunos contextos pro- yecto, los requisitos específicos SQA prescriben ciertas actividades de SCM.

6-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 proceso de SMC, identificación de la configuración de software, el control de la configuración de software, la contabilidad de estado de configuración de software, auditoría de configuración de software, y la gestión de versión de software y la entrega. El software de configuración de administración de KA se relaciona con los demás Kas, ya que el objeto de la gestión de la configuración es el artefacto pro ducido y utilizado en todo el software de inge- niería proceso. DISTRIBUCIÓN DE TEMAS PARA LA GESTIÓN DE CONFIGURACIÓN DEL SOFTWARE El desglose de los temas para el ConfigSoftware de Gestión URACIÓN KA se muestra en la Figura 6.1. 1. Gestión del Proceso de SMC SCM controla la evolución y la integridad de un producto mediante la identificación de sus elementos; la gestión y el control del cambio; y verificar, grabación, y la información sobre la

información de configuración. Desde la perspectiva del ingeniero de software, SCM facilita

el desarrollo y el cambio aplicación activilazos. Una implementación exitosa de SMC requiere una planificación y una gestión cuidadosa. Esto, a su vez, requiere una comprensión del contexto de la organización para, y las limitaciones impuestas a, el diseño y la implementación del proceso de SMC. 1.1. Contexto de organización de SMC [2 *, c6, Ann. D] [3 *, la introducción] [4 *, c29] Para planificar un proceso de SMC para un proyecto, es preciso proceder a entender el contexto de la organización y las relaciones entre los elementos de la organización. SMC interactúa con otras actividades o elementos de la organización. Los elementos de la organización responsable de la ingeniería de software procesos de apoyo pueden estructurarse de varias maneras. Aunque la responsabili- dad para realizar ciertas tareas SCM podría ser asignado a otras partes de la organización (por ejemplo, la organización de desarrollo), el responsa- bilidad global para SCM menudo recae en un elemento zational orga- distinta o persona designada. El software se desarrolló con frecuencia como parte de un sistema más grande que contiene los elementos de hardware y firmware. En este caso, las actividades se llevan a cabo SCM

Configuración del software de gestión de 63

6-4 Guía SWEBOK® V3.0

en paralelo con el hardware y el firmware CM activi- dades y deben ser compatibles con CM a nivel de sistema. Tenga en cuenta que el firmware contiene hardware y software; Por lo tanto, ambos conceptos CM de hardware y software son aplicables. SMC podría interactuar con la actividad de aseguramiento de la calidad de una organización en temas como la gestión de registros y elementos no conformes. Respecto al primero, algunos artículos bajo control SMC también pueden incluir datos sobre los proyectos sujetos a las disposiciones del programa de garantía de calidad de la organización. La gestión de elementos no conformes es aliado no baja de la responsabilidad de la actividad de aseguramiento de la calidad; Sin embargo, SCM puede ayudar con pista- ing e informar sobre los elementos de configuración de software que caen en esta categoría. Tal vez la relación más estrecha es con el desarrollo de software y mantenimiento ornizaciones. Es dentro de este contexto que muchas de las tareas de control de la configuración del software se con- canalizado. Con frecuencia, las mismas herramientas soportan desa- rrollo, el mantenimiento y los propósitos de SCM. 1.2. Limitaciones y orientación para el proceso SMC [2 *, c6, Ann. D, Ann. E] [3 *, C2, C5] [5 *, c19s2.2] Limitaciones que afectan, y una guía para el proceso de SMC provenir de varias fuentes. normativas y procedimientos de exponen a niveles de organización corporativos u otros podrían influir o prescribir el diseño y la implementación del pro- ceso SMC para un proyecto determinado. Además, el contrato entre el comprador y el proveedor podría condisposiciones Tain que afectan el proceso de SMC. Por ejemplo, podrían ser necesarias ciertas auditorías de configuración, o puede ser especificado que ciertos artículos pueden colocar bajo CM. Cuando los productos de software para ser desarrollados tienen el potencial de afectar a la seguridad pública, los organismos reguladores externos pueden imponer limitaciones. Por último, el proceso del ciclo de vida del software particular elegido para un proyecto de software y

el nivel de formalismo seleccionado para implementar el software afecta al diseño y la implementación del proceso de SMC. Una guía para el diseño y la implementación de un proceso de SMC también se puede obtener de “mejores prácticas”, como se refleja en las normas sobre el software

ingeniería emitido por las diversas normas orga- nizaciones (ver Apéndice B de las normas). 1.3. La planificación de SMC [2 *, c6, Ann. D, Ann. E] [3 *, c23] [4 *, c29] La planificación de un proceso de SMC para un proyecto dado debe ser coherente con el contexto organiza- zational, las restricciones aplicables, comúnmente aceptado orientación com-, y la naturaleza del proyecto (por ejemplo, el tamaño, la criticidad de seguridad, y la seguridad). Las principales actividades cubiertas son la identificación del software de configuración, control de configuración de software, la contabilidad de estado de configuración de software, auditoría de configuración de software, y la gestión de versión de software y la entrega. Además, cuestiones como la organización y responsabilidades, recursos y horarios, la selección de herramientas y la aplicación, el control de proveedores y subcontratistas, y el control de la interfaz son típicamente sidered con-. Los resultados de la actividad de planificación se registran en un Plan de SCM (SCMP), que es Tıpicamente sujeto a SQA revisión y auditoría. Ramificación y las estrategias que se fusionan deben ser cuidadosamente planeado y comunicado, ya que impactan en muchas actividades de la SCM. Desde el punto un SCM stand-, una rama se define como un conjunto de la evolución de versiones de archivo fuente [1]. La fusión consiste en la combinación de diferentes cambios en el mismo archivo [1]. Este Tıpicamente se produce cuando más de una persona cambia de un elemento de configuración. Hay muchas estrategias de ramas y la mezcla de uso común (véase la sección Lecturas adicionales para una discusión adicional). El modelo de ciclo de vida de desarrollo de software (véase el ciclo de vida del software Modelos en el proceso de ingeniería de software KA) también afecta SCM actividades, y la planificación SMC debe tener esto en cuenta. Por ejemplo, la integración continua es una práctica común en muchos enfoques desarrollo de software. Por lo general se caracteriza por ciclos de acumulación de prueba de implementar frecuentes. SCM actividades deben planificarse en consecuencia.

Configuración del software de gestión de 61.3.1. Organización y responsabilidades SMC 5 [2 *, Ann. DS5, Ann. DS6] [3 *, c1011] [4 *, introducción, c29]

Para evitar la confusión sobre quién desarrollará dada actividades de SCM o tareas, la organización

6-6 Guía SWEBOK® V3.0

papeles para que participen en el proceso de SMC deben ser claramente identificados. Las responsabilidades específicas para las actividades o tareas SCM dados también tienen que ser asignados a entidades de organización, ya sea por título o por el elemento de la organización. Los informes dad y canales globales de Autor-SMC también deben ser identificados, aunque esto puede ser logrado en la etapa de planificación de la gestión de proyectos o la garantía de calidad. 1.3.2. Recursos SCM y horarios [2 *, Ann. DS8] [3 *, c23] La planificación de SMC identifica el personal y las herramientas que participan en la realización de actividades y tareas de SCM. Se abordan cuestiones de programación mediante el establecimiento de secuencias necesarias tareas de SCM y que identifique los valores de sus relaciones con los programas de los proyectos y los hitos establecidos en el proyecto de management etapa de planificación. También se especifican los requisitos de formación necesarios para la ejecución de los planes y la formación de los nuevos miembros del personal. 1.3.3. Herramienta Selección e implementación [3 *, c26s2, c26s6] [4 *, c29s5] En cuanto a cualquier área de la ingeniería de software, la selección e implementación de herramientas de SCM deben ser cuidadosamente planificadas. Los siguientes pre- guntas deben ser considerados: • Organización: lo que motiva adquisi- ción de herramientas desde una perspectiva organizacional? • Herramientas: podemos utilizar herramientas comerciales o a desarrollar nosotros mismos? • Medio Ambiente: ¿cuáles son las limitaciones impuestas por la organización y su téc- nico contexto? • Legado: cómo utilizarán los proyectos (o no) las nuevas herramientas? • Financiación: ¿quién va a pagar por la adquisición de las herramientas,

mantenimiento, formación, y la personalización? • Alcance: cómo se deployed- las nuevas herramientas, por ejemplo, a través de toda la organización o sólo en proyectos específicos? • Propiedad: ¿quién es el responsable de la introducción de nuevas herramientas?

• Futuro: ¿cuál es el plan para el uso de las herramientas en el futuro? • Cambiar: su capacidad de adaptación son las herramientas? • Ramas y la mezcla: son capaci- dades de dichas herramientas compatibles con el ing rama-planificada y estrategias de la fusión? • Integración: hacer las diferentes herramientas de SCM inte- rejilla entre sí? Con otras herramientas en uso en la organización? • Migración: el repositorio puede mantenida por la herramienta de control de versiones ser portado a otra herramienta de control de versiones, manteniendo la historia completa de los elementos de configuración que contiene? SMC por lo general requiere un conjunto de herramientas, en lugar de una sola herramienta. Tales conjuntos de herramientas son algunas veces referidos como bancos de trabajo. En un texto tan con-, otra consideración importante en la Planificación para la selección de la herramienta es determinar si el banco de trabajo SMC estará abierto (en otras palabras, las herramientas de diferentes proveedores serán utilizados en diferentes actividades del proceso SMC) o integrada (donde se han diseñado elementos del banco de trabajo para trabajar juntos). El tamaño de la organización y el tipo de proyectos que participan también puede afectar a la selección de herramientas (ver tema 7, Configuración de Software ManageHerramientas Ment). 1.3.4. Vendedor / Control de Subcontratista [2 *, c13] [3 *, c13s9, c14s2] Un proyecto de software puede adquirir o hacer uso de los productos de software adquiridos, tales como compiladores y otras herramientas. la planificación SMC considera si y cómo se tomarán estos elementos bajo control con- figuración (por ejemplo, integrado en las bibliotecas pro- yecto) y cómo van a ser evaluados y gestionados cambios o actualizaciones. Consideraciones similares se aplican al software subcontratado. Al utilizar el software de subcontratación, tanto los requisitos de SCM a ser impuestas sobre el proceso de SMC del subcontratista como parte del subcontrato y los medios para vigilar pliance com- necesitan

del software de gestión ser establecidos. Configuración Este último incluye la de 67 consideración de lo que debe estar disponible para la vigilancia del cumplimiento efectivo de información SMC.

6-8 Guía SWEBOK® V3.0

1.3.5. control de interfaz

[2 *, c12] [3 *, c24s4]

Cuando un elemento de software de interfaz con otro elemento de software o hardware, un cambio a cualquiera de elemento puede afectar al otro. La planificación para el proceso SMC considera cómo se identificarán los elementos de interfaz y cómo se gestionen y cambios en los elementos. El papel SCM puede ser parte de un proceso de sistema de nivel más grande para la especificación y control de la interfaz; puede tratarse de especificaciones de interfaz, planes de control de interfaz, y los documentos de control de interfaz. En este caso, la planificación de SMC para el control de la interfaz tiene lugar dentro del contexto del proceso de nivel del sistema. 1.4. plan de SMC [2 *, Ann. D] [3 *, c23] [4 *, c29s1] Los resultados de la planificación SMC para un proyecto dado se registran en una configuración de software manage- ment Plan (SCMP), un “documento vivo” que sirve como referencia para el proceso de SMC. Se mantiene (es decir, actualizada y aprobada) según sea necesario durante el ciclo de vida del software. En Menting imple- PGCS, normalmente es necesario desarrollar una serie de procedimientos más detallados, subordinados que define cómo los requisitos específicos se llevará a cabo durante actividades- del día a día, por ejemplo, que se utilizarán estrategias de ramificación y con qué frecuencia se basa ocurrir y auto-pruebas apareadas de todo tipo se ejecutan. Orientación sobre la creación y mantenimiento de un PGCS, basado en la información producida por la actividad de planificación, está disponible a partir de diversas fuentes, como por ejemplo [2 *]. Esta referencia proporciona requisitos para la información a ser contenida en un SCMP; También define y describe seis catego- rías de información SMC que deben incluirse en un SCMP: • Introducción (propósito, el alcance, los términos utilizados) • Gestión de SMC (organización,

• Horarios de SCM (coordinación con otro actividades del proyecto) • Recursos SCM (herramientas, recursos físicos, responsabilidades, autoridades, las políticas aplicables, directivas y procedimientos) • Actividades SCM (identificación de la configuración, control de configuración, etc.)

Configuración del software de gestión de 69

y recursos humanos) • Mantenimiento SCMP. 1.5. La vigilancia de la Gestión de la Configuración de Software [3 *, c11s3] Después del proceso de SMC se ha implementado, un cierto grado de vigilancia puede ser necesario para garantizar que las disposiciones de la PGCS se realicen adecuadamente. No es probable que sean los requisitos especí- SQA espe- para garantizar el cumplimiento de los procesos y procedimientos especificados SCM. La persona responsable de SMC asegura que los que tienen la responsabilidad de realizar las tareas asignadas SCM definidos correctamente. La autoridad de control de calidad de software, como parte de una actividad de auditoría El cumplimiento, también puede realizar esta vigilancia. El uso de herramientas de SCM integrados con capacidad de control de procesos puede hacer más fácil la tarea de vigilancia. Algunas herramientas facilitan el proceso pliance commientras que proporciona flexibilidad para el ingeniero de soft- ware para adaptar los procedimientos. Otras herramientas de cumplir proceso, dejando el ingeniero de software con menos flexibilidad. requisitos de vigilancia y el nivel de flexibilidad para ser proporcionados al ingeniero de software son consideraciones importantes en la selección de herramientas. 1.5.1. Medidas de SCM y Medición [3 *, c9s2, c25s2s3] SCM medidas pueden ser diseñados para proporcionar información CIFIC espe- sobre el producto en evolución o para proporcionar información sobre el funcionamiento del proceso de SMC. Uno de los objetivos relacionados con el proceso de seguimiento de SMC es descubrir las oportunidades de mejora de procesos. Las mediciones de los procesos SCM proporcionan un buen medio para el seguimiento de la eficacia de las actividades de la SCM de manera continua. Estas mediciones son útiles en characteriz- ing el estado actual del proceso, así como en la provisión de una base para hacer comparaciones en el tiempo. El análisis de las mediciones puede producir

6-10

Guía SWEBOK® V3.0

ideas que lleva a procesar los cambios y actualizaciones correspondientes a la PGCS. Bibliotecas de software y las diversas posibilidades de herramientas SCM proporcionan fuentes para extraer información acerca de las características del proceso de SMC (así como el suministro de información agement hombre-proyecto y). Por ejemplo, información sobre el tiempo requerido para llevar a cabo varios tipos de cambios sería útil en una evaluación de los criterios para determinar qué niveles de autoridad son óptimas para la autorización de ciertos tipos de cambios y para la estimación de cambios en el futuro. Se debe tener cuidado para mantener el foco de la vigilancia en las ideas que se pueden obtener a partir de las mediciones, no en las propias mediciones. La discusión de los procesos de software y medición del producto se presenta en el Proceso de Cesión de Software Ingeniería KA. programas de software surement Measure se describen en el Software Engineering Management KA. 1.5.2. En-Proceso de Auditorías de SMC [3 *, C1S1] Las auditorías pueden ser llevadas a cabo durante el proceso de ingeniería de software para investigar la tus esta- actual de elementos específicos de la configuración o para evaluar la aplicación del proceso de SMC. En-proceso de auditoría de SMC proporciona un mecanismo mal más para- para el seguimiento de los aspectos seleccionados del proceso y puede ser coordinado con la función SQA (ver tema 5, Software configuraciones Auditoría ción). 2. Identificación software

de

la

configuración

de

[2 *, c8] [4 *, c29s1.1] identificación de la configuración de software identifica los elementos a controlar, establece esquemas de identificación de los elementos y sus versiones, y establece las herramientas y técnicas a utilizar en la adquisición y gestión de elementos controlados. Estas actividades proporcionan la base para las otras actividades de la SCM.

2.1. Los productos que la identificación que deben ser controlados [2 *, c8s2.2] [4 *, c29s1.1] Uno de los primeros pasos en el cambio de control es la identificación de los elementos de software que se desea controlar.

Esto implica la comprensión de la configuración del software en el contexto de la configuración del sistema, la selección de los elementos de configuración de software, desarrollo de una estrategia para los elementos de software de etiquetado y la descripción de sus relaciones, y la identificación tanto de las líneas de base a ser utilizados y el procedimiento para la adquisición de una línea de base de los artículos. 2.1.1. Configuración del software [1, c3] configuración del software son las características funcionales y ical phys- de hardware o software como se indica en la documentación técnica o se alcance en un producto. Puede ser visto como parte de una configuración general del sistema. 2.1.2. Software Elemento de Configuración [4 *, c29s1.1] Un elemento de configuración (CI) es un elemento o agregación gación de hardware o software o ambos que está diseñado para ser manejado como una sola entidad. Un elemento de configuración de software (SCI) es una entidad de software que se ha establecido como un elemento de configuración [1]. El SCM controla típicamente una variedad de artículos, además del propio código. los elementos de software con potencial para convertirse en LIC incluye planes, especifi- caciones y documentación de diseño, pruebas de materiales, herramientas de software, la fuente y el código ejecutable, librerías de código, datos y diccionarios de datos y documentación para la instalación, mantenimiento, operaciones, y el uso de software . Selección de LIC es un proceso importante en el que se debe lograr un equilibrio entre proporcionar una visibilidad adecuada para el control de proyectos poses PUR y proporcionar un número manejable de artículos controlados. 2.1.3. Software Relaciones elemento de configuración [3 *, c7s4] Las relaciones estructurales entre los LIC seleccionados, y sus partes constituyentes, afectan a otras actividades o tareas SCM, tales como la construcción de software o el análisis del impacto de los cambios propuestos.

Configuración del software de gestión de 6seguimiento adecuado de estas relaciones 11 también es importante para apoyar la trazabilidad. El diseño del esquema de identificación para LIC

6-12

Guía SWEBOK® V3.0

Figura 6.2. Adquisición de artículos

debe considerar la necesidad de asignar elementos identificados a la estructura del software, así como la necesidad de apoyar la evolución de los elementos de software y sus relaciones. 2.1.4. Versión del software [1, c3] [4 *, c29s3] los elementos de software evolucionar como Ceeds pro de proyectos de software. Una versión de un elemento de software es una instancia identifica- do de un elemento. Puede ser considerado como un estado de un elemento en evolución. Una variante es una versión de un programa resultante de la aplicación de la diversidad soft- ware. 2.1.5. Base [1, c3] Una línea de base software es un aprobado formalmente ver- sión de un elemento de configuración (con independencia de los medios de comunicación) que se designa formalmente y se fija en un momento específico durante el ciclo de vida del elemento de configuración. El término también se utiliza para referirse a una ver- sión particular de un elemento de configuración de software que ha sido acordado. En cualquier caso, la línea de base sólo puede modificarse a través de procedimientos trol das a cambios formales. Una línea de base, junto con

todos los cambios aprobados en la línea de base, representa la configuración actual aprobado. líneas de base utilizados comúnmente incluyen fun- cional, asignado, de desarrollo, y el producto

líneas de base. La línea de base funcional corresponde a los requisitos del sistema revisado. La línea de base asignarse los corresponde a la especificación de requisitos de software y los requisitos de la interfaz de software revisado. La línea de base del desarrollo representa la configuración de software que evoluciona a la hora seleccionada durante el ciclo de vida del software. Cambio autoridad de esta línea de base normalmente recae principalmente en la organización de desarrollo, sino que puede ser compartida con otras organizaciones (por ejemplo, SMC o de prueba). La línea de base del producto se corresponde con el producto de software para la integración completado entregado sis- tema. Las líneas de base a utilizar para un proyecto dado, junto con los niveles asociados de autoridad necesario para la aprobación del cambio, son Tıpicamente identificado en el SCMP. 2.1.6. La adquisición de elementos de configuración de software [3 *, c18] los elementos de configuración de software se colocan bajo control SCM en diferentes momentos; es decir, que se incorporan en una línea de base en particular en un punto particular en el ciclo de vida del software. El evento desencadenante es la realización de algún tipo de tarea formal de aceptación, tales como una revisión formal. Figura 6.2 caracteriza el crecimiento de los artículos baselined medida que avanza el ciclo de vida. Esta cifra se basa en el modelo de cascada para los propósitos de la ilustración solamente; los subíndices usados en la figura indican versiones

Configuración del software de gestión de 613

6-14

Guía SWEBOK® V3.0

de los elementos cambiantes. La solicitud de cambio de software (SCR) se describe en la sección 3.1. En la adquisición de un SCI, se deben establecer su origen y integri- dad inicial. Después de la adquisi- ción de un SCI, cambios en el elemento debe ser formalmente aprobado como adecuado para el SCI y la línea de base que participan, como se define en el PGCS. Después de la aprobación, el elemento se incorpora en la línea de base software de acuerdo con el procedimiento adecuado.

qué cambios hacer, la autoridad de approv- ing ciertos cambios, el apoyo a la ción ¡Ejecución de esos cambios, y el concepto de desviaciones formales de los requisitos del proyecto, así como exenciones de ellos. La información derivada de estas actividades es útil en la medición de tráfico el cambio y la rotura, así como los aspectos de reproceso. 3.1. Solicitar, evaluar y cambios que aprueba Software [2 *, c9s2.4] [4 *, c29s2]

2.2. software Library [3 *, c1s3] [4 *, c29s1.2]

Una biblioteca de software es una colección controlada de software y la documentación relacionada diseñado para ayudar en el desarrollo de software, uso o mantenimiento [1]. También es fundamental para la versión de software agement hombre- y actividades de entrega. Existen varios tipos de bibliotecas podrían ser utilizados, cada uno correspondiente a nivel particular del elemento de software de madurez. Por ejemplo, una biblioteca de trabajo podría apoyar la codificación y una biblioteca de soporte proyecto podría apoyar de Exámenes, mientras que una librería maestra podría ser utilizado para productos termi- nado. Un nivel adecuado de SCM trol con- (línea de base y el nivel de autoridad para el cambio asociado) está asociado con cada biblioteca. Seguridad, en términos de control de acceso y las instala- copia de seguridad, es un aspecto clave de la gestión de la biblioteca. La herramienta (s) que se utiliza para cada biblioteca debe ser compatible con las necesidades de control de SMC para esa biblioteca, tanto en términos de control de LIC y controlar el acceso a la biblioteca. A nivel biblioteca de trabajo, se trata de una capacidad de gestión de código que sirve Desa- ERS, mantenedores, y SCM. Se centra en el hombreenvejecimiento de las versiones de los elementos de software, mientras que SUP- portar las actividades de múltiples desarrolladores. En los niveles más altos de control, el acceso es más restringida y SCM es el usuario principal. Estas bibliotecas son también una importante fuente de información para las mediciones de

El primer paso en la gestión de cambios para controlada artículos es determinar qué cambios hacer. los trabajo y progreso. 3. Control de Configuración de Software [2 *, c9] [4 *, c29s2] control de la configuración de software se ocupa de la gestión de cambios durante el ciclo de vida del software. Cubre el proceso para determinar

software de proceso de solicitud de cambio (véase un flujo típico de un proceso de solicitud de cambio en la figura 6.3) proporciona procedimientos formales para la presentación y el registro de las solicitudes de cambio, evaluar el costo TiAl poten- y el impacto de un cambio propuesto, y aceptar, modificar, difiriendo, o rechazar el cambio propuesto. Una solicitud de cambio (CR) es una petición para expandir o reducir el alcance del proyecto; modificar las políticas, procesos, planes o procedimientos; modificar los costos o presupuestos; o horarios Revisar [1]. Las solicitudes de cambios en el software artículos con- figuración pueden ser originados por cualquier persona en cualquier momento del ciclo de vida del software y pueden incluir una propuesta de solución y la prioridad solicitada. Una fuente de un CR es el inicio de una acción correctiva en respuesta a los informes de problemas. Independientemente de la fuente, el tipo de cambio (por ejemplo, defecto o mejora) que se registra en el CR Software (SCR). Esto proporciona una oportunidad para el seguimiento de defectos y la recolección de las mediciones por tipo de actividad el cambio cambio. Una vez que se recibe una SCR, una evaluación técnica (también conocido como un análisis de impacto) se lleva a cabo para determinar la extensión de las modificaciones que serían necesarias se debe aceptar la solicitud de cambio. Una buena comprensión de las relaciones entre el software (y, posiblemente, el hardware) elementos es importante para esta tarea. Por último, una autoridad realizó medición-com- establecida con la línea de base afectada, el SCI involucrados, y la naturaleza del cambio evaluará los aspectos técnicos y de gestión de la solicitud de cambio y, o bien aceptar, modificar, rechazar o posponer el cambio propuesto.

Configuración del software de gestión de 615

6-16

Guía SWEBOK® V3.0

Figura 6.3. Flujo de un proceso de control de cambios

3.1.1. Junta de Control de Configuración de Software [2 *, c9s2.2] [3 *, c11s1] [4 *, c29s2] La autoridad para aceptar o rechazar los cambios propuestos se apoya con una entidad típicamente conocida como un tablero de control de configuración (CCB). En proyectos más pequeños, esta autoridad puede residir de manera efectiva con el líder o una persona asignada en lugar de una tabla con varias personas. Puede haber varios niveles de autoridad cambian dependiendo de una variedad de terios teria, tales como el carácter crítico del tema planteado y la naturaleza del cambio (por ejemplo, impacto en el presupuesto y el calendario), o punto actual del proyecto en la vida ciclo. La composición de los CCBs se utilizan para un sistema dado varía en función de estos criterios (un representante SCM siempre estaría presente). Todos los interesados, de acuerdo al nivel de la CCB, están representados. Cuando el alcance de la autoridad de un CCB es estrictamente cerámica blandas, que se conoce como una Junta de Control de Configuración de Software (SCCE). Las actividades de la CCB son típicamente sujetos a auditoría o revisión de calidad del software. 3.1.2. Software Proceso de Solicitud de Cambio [3 *, c1s4, c8s4]

Una solicitud de cambio de software eficaz (SCR) proceso requiere el uso de herramientas de apoyo y procedi- mientos para originar las solicitudes de cambio, enforc- ing el flujo del proceso de cambio, la captura

decisiones CCB, y la información del proceso de cambio que se informa. Un vínculo entre esta capacidad de la herramienta y el sistema de reporte de problema puede facilitar el seguimiento de soluciones para problemas detectados. 3.2. Cambios en el software de aplicación [4 *, c29] SCRs aprobados se implementan utilizando los procedimientos de software definidos de acuerdo con los requisitos de programación aplicables. Puesto que un número de SCRs aprobados podría implementarse de forma simultánea, es necesario proporcionar un medio para el seguimiento que SCRs se incorporan en las versiones de software particulares y líneas de base. Como parte del cierre del proceso de cambio, cambios pletó com- pueden someterse a auditorías de configuración y la calidad del software de verificación-Esto incluye garantizar que se han realizado cambios aprobados. El proceso de solicitud de cambio de software descrito anteriormente por lo general documentará el SMC (y otra) información de aprobación para el cambio. Los cambios pueden ser apoyadas por herramientas de control de código fuente sión ver-. Estas herramientas permiten a un equipo de ingenieros de software, o un solo ingeniero de software, para realizar un seguimiento y documentar los cambios en el código fuente. Estas herramientas proporcionan un único repositorio para almacenar el código fuente, puede evitar más de un ingeniero de soft- ware de la edición del mismo módulo, al mismo tiempo, y registrar todos los cambios realizados en el

Configuración del software de gestión de 617

6-18

Guía SWEBOK® V3.0

código fuente. Los ingenieros de software de verificación módulos del repositorio, hacer cambios, documentar los cambios, a continuación, guarde los módulos editados en el repositorio. Si es necesario, los cambios también pueden ser descartados, la restauración de una línea de base anterior. herramientas más potentes pueden apoyar el desarrollo paralelo y entornos distribuidos geográficamente. Estas herramientas se pueden manifestar como aplicaciones independientes, especializados bajo el control de un grupo independiente SMC. También pueden aparecer como una parte integrada del entorno de la ingeniería de software. Por último, pueden ser tan elemental como un sistema de control de cambios rudimentaria provisto de un sistema operativo. 3.3. Desviaciones y renuncias [1, c3] Las limitaciones impuestas a un software Engineer- esfuerzo ing o las especificaciones que se producen durante las actividades de desarrollo podría contener disposiciones que no pueden ser satisfechas en el punto designado en el ciclo de vida. Una desviación es un rización autori- escrita, otorgada con anterioridad a la fabricación de un elemento, para apartarse de una actuación en particular o requisito de diseño para un número determinado de unidades o un período específico de tiempo. Una renuncia es un diez autorización ESCRITO para aceptar un elemento de configuración o de otro elemento designado que se encuentra, durante la producción o después de haber sido presentado para su inspección, a apartarse de los requisitos especificados, pero se considera ertheless nevadecuado para uso como-es o después de la reanudación por un método aprobado. En estos casos, un proceso formal se utiliza para obtener la aprobación de las desviaciones de las renuncias, o de, las disposiciones. 4. El software de contabilidad de estado de configuración [2 *, c10]

sistema de información, la información de estado de configuración para ser administrado por los las configuraciones cambiantes deben ser identificados, recogidos, y mantenido. Diversa información y las mediciones son necesarias para apoyar el proceso de SMC y para cumplir con el estado de con- figuración necesidades de información de gestión, ingeniería de software, y otras actividades relacionadas. Los tipos de información disponibles incluyen la identificación de la configuración aprobada, así como la identificación y tus implementación actual de esta- cambios, desviaciones, y las renuncias. Alguna forma de soporte de la herramienta automatizada es preciso proceder para llevar a cabo la recogida de datos SCSA y tareas de informes; esto podría ser una capacidad de base de datos, una herramienta independiente, o una capacidad de un entorno de herramientas más amplio e integrado. 4.2. Informes de estado de configuración de software [2 *, c10s2.4] [3 *, c1s5, c9s1, c17] información reportada puede ser utilizado por varios elementos, incluyendo los proyectos de organización y el equipo de desarrollo, el equipo de mantenimiento, gestión de proyectos, y la calidad del software activi- dades. Informes pueden tomar la forma de Que- hoc Ries anuncios para responder a preguntas específicas o la producción periódica de informes prediseñados. Algunos infor- mación producida por la actividad contable de estado durante el curso del ciclo de vida podría convertirse en los registros de control de calidad. Además de informar el estado actual de la configuración, la información obtenida por el SCSA puede servir como base de diversas mediciones. Los ejemplos incluyen el número de solicitudes de cambio por SCI y el tiempo medio necesario para ejecutar una solicitud de cambio. 5. Auditoría de configuración de software gestionar una configuración efectiva.

Software de contabilidad estado de configuración (SCSA) es un elemento de gestión de la configuración sisting con- del registro y la notificación de la informa- ción necesaria para

4.1. Software de información de estado de configuración [2 *, c10s2.1]

Los diseños de actividad SCSA y opera un sistema para la captura y presentación de la información necesaria a medida que avanza el ciclo de vida. Como en cualquier

Configuración del software gestión de 6[2 *,dec11] 19

Una auditoría de software es una examina- ción independiente de un producto de trabajo o conjunto de productos de trabajo para evaluar el cumplimiento de las especificaciones, normas, acuerdos contractuales, u otros criterios [1]. Las auditorías se llevaron a cabo de acuerdo con un proceso bien definido que consiste en diversas funciones y responsabilidades auditor. En consecuencia, cada auditoría debe ser cuidadosamente planificado. Una auditoría puede requerir un nú- mero de personas para realizar una variedad de tareas durante un período relativamente corto de tiempo. Herramientas de apoyo

Configuración del software de gestión de 611

la planificación y realización de una auditoría pueden facilitar enormemente el proceso. auditoría de configuración software determina el grado en que un elemento satisface las características funcionales y físicas requeridas. auditorías informal de este tipo puede llevarse a cabo en puntos clave del ciclo de vida. Hay dos tipos de auditorías formales podrían ser requeridos por el contrato que rige (por ejemplo, en los contratos que cubren software crítico): la Auditoría funcional de configuración (FCA) y la configuración de auditoría física (PCA). La conclusión con éxito de estas auditorías puede ser un requisito previo para el establecimiento de la línea base del producto. 5.1. Software de Auditoría de Configuración Funcional [2 *, c11s2.1] El propósito de la FCA software es para asegurar que el elemento de software auditado es consistente con sus especificaciones de gobierno. La salida de las mercancías de las actividades de verificación y validación blandos (véase Verificación y validación en el software de cali- dad KA) es un insumo clave para esta auditoría. 5.2. Auditoría software

de

Configuración

física

de

[2 *, c11s2.2] El propósito de la auditoría de software guración física ción (PCA) es asegurar que la documentación de proyectos y de referencia es consistente con el producto de software como incorporado. 5.3. En-Proceso de Auditorías de una línea de base del software [2 *, c11s2.3] Como se mencionó anteriormente, las auditorías pueden ser llevadas a cabo durante el proceso de desarrollo para investigar el estado actual de los elementos específicos de la con- figuración. En este caso, una auditoría se podría aplicar a los elementos de línea de base de la muestra para asegurar que per- formance es consistente con las especificaciones o para asegurar que la documentación evolución sigue siendo compatible con el elemento de referencia en

desarrollo. 6. Gestión de la Entrega de Software y Entrega [2 *, c14] [3 *, c8s2] En este contexto, la liberación se refiere a la distribu- ción de un elemento de configuración de software fuera

6-12

Guía SWEBOK® V3.0

la actividad de desarrollo; esto incluye comunicados internos, así como la distribución a los clientes. Cuando diferentes versiones de un elemento de software están disponibles para la entrega (tales como versiones para diferentes formas plataformas o versiones con diferentes capacidades), frecuentemente es necesario volver a crear versiones específicas y empaquetar los materiales adecuados para la entrega de la versión. La biblioteca de software es un elemento clave en la realización de tareas de liberación y entrega. 6.1. Edificio de software [4 *, c29s4] Software edificio es la actividad de la combinación de las versiones correctas de los elementos de configuración de software, utilizando los datos de configuración apropiados, en un programa ejecutable para la entrega a un cliente u otro receptor, tal como la actividad de pruebas. Para sistemas con hardware o firmware, el programa ejecutable se entrega a la activi- dad de la capacidad del sistema. Construir instrucciones de asegurar que las medidas adecuadas de construcción se toman en la secuencia correcta. Además de la creación de software para los nuevos lanzamientos, por lo general es también necesaria para SMC para tener la capacidad de reproducir versiones anteriores para la recuperación, pruebas, mantenimiento, o para fines de liberación adicionales. El software se construye a partir de versiones particulares de herramientas de apoyo, tales como compiladores (véase Fundamentos Piler Com- en los Fundamentos de Informática KA). Puede ser que sea necesario reconstruir una copia exacta de un elemento de configuración de software previamente construida. En este caso, las herramientas de apoyo y las instrucciones de construcción asociados deben estar bajo el control de SMC para garantizar la disponibilidad de las versiones correctas de las herramientas. Una capacidad de herramienta es útil para la selección de las versiones rect angulares del elementos de software para un entorno de destino dado y para automatizar el proceso de construcción del software de las versiones seleccionadas y datos de configuración apropiados. Para proyectos con am- bientes desarrollo paralelos o distribuidos, esta capacidad herramienta es necesaria. La mayoría de los entornos de ingeniería de

software proporcionan esta capacidad. Estas herramientas varían en complejidad desde que requiere el ingeniero de software para aprender un lenguaje de script espe- cializada a los enfoques orientados a gráficos que ocultan gran parte de la complejidad de una instalación de acumulación “inteligente”. El proceso de construcción y los productos son a menudo sub- ject de verificación de la calidad del software. Las salidas de

Configuración del software de gestión de 613

el proceso de construcción podría ser necesaria para futuras referencias y puede convertirse en los registros de control de calidad.

7. Las herramientas de Software [3 *, c26s1] [4 *, c8s2]

6.2. Gestión de la Entrega de Software

Cuando se habla de herramientas Ment managede configuración de software, es útil para clasificarlos. herramientas de SCM se pueden dividir en tres clases en términos contenidos de liberación de los SCR que se han recibido. Esta capacidad herramienta también puede mantener información sobre diversas plataformas de destino y en diversos entornos de clientes.

[4 *, c29s3.2]

gestión de versiones de software abarca la identificación, el empaquetado, y la entrega de los elementos de un ejemplo de producto-para, un programa capaz execut-, documentación, notas de la versión, y datos de configuración. Teniendo en cuenta que los cambios de producto pueden producirse de manera continua, una preocupación por la gestión de la liberación es determinar cuándo deben emitir un comunicado. La gravedad de los problemas abordados por la liberación y la medición de la falla den- sidades de las versiones anteriores afectan a esta decisión. La tarea de envasado debe identificar qué producto artículos son para ser entregados y luego seleccione las variantes correctas de esos elementos, dada la aplica- ción previsto del producto. La información documento- ing el contenido físico de un comunicado se conoce como un documento de descripción de la versión. Las notas de la versión describen típicamente nuevas capacidades, problemas conocidos y requisitos de plataforma necesarios para el funcionamiento adecuado del producto. El paquete que se lanzará también contiene instrucciones de instalación o actualización. Este último puede ser complicado por el hecho de que algunos usuarios actuales podrían tener versiones que son varias las viejas versiones. En algunos casos, la administración de liberación puede ser necesario con el fin de realizar un seguimiento de la distribución del producto a varios clientes o Sistemas de destino, por ejemplo, en un caso donde se requiere el proveedor para notificar a un cliente de los problemas recién denunciados. Por último, un mecanismo para asegurar la integridad del artículo publicado se puede implementar, por ejemplo mediante la liberación de una firma digital con él. Se necesita una capacidad de herramienta para apoyar estas funciones de gestión de versiones. Se uso-ful tener una relación con la capacidad de herramienta de apoyo al proceso de solicitud de cambio con el fin de asignar los

6-14 Guía SWEBOK® V3.0 a del ámbito de aplicación

la que proporcionan apoyo: el apoyo vidual indicación, el apoyo relacionada con el proyecto, y el apoyoproceso panywide com-. herramientas de apoyo individual son apropiadas y por lo general suficiente para organizaciones o grupos de desarrollo de pequeñas y sin variantes de sus productos de software u otras exigencias SCM compleja. Incluyen: • herramientas de control de versiones: pista, documentar y almacenar elementos de configuración individuales como el código fuente y la documentación externa. • Construir herramientas de manipulación: en su forma más simple, este tipo de herramientas de compilación y enlace para una versión ejecutable del software. Más herramientas avanzadas de construcción extracto de la última versión del software de control de versiones, realizar comprobaciones de cali- dad, ejecutar pruebas de regresión, y producir diversos tipos de informes, entre otras tareas. • Cambiar las herramientas de control: sobre todo apoyar el control de las solicitudes de cambio y eventos noti- ficación (por ejemplo, cambios en el estado de solicitud de cambio, los hitos alcanzados). herramientas de apoyo relacionados con el proyecto principal respaldar la gestión del espacio de trabajo para los equipos e integradores de desarrollo; por lo general son capaces de apo- entornos de desarrollo de puertos distribuido. Tales herramientas son apropiadas para medianas y grandes organizaciones con las variantes de sus productos de software y desarrollo paralelo pero no hay requisitos de certificación. herramientas de apoyo en procesos de toda la compañía puede Tıpicamente automatizar partes de un pro- ceso de toda la compañía, proporcionando soporte para mentos de flujo de trabajo manage-, roles y responsabilidades. Ellos son capaces de manejar muchos artículos, datos y ciclos de vida. Estas herramientas se suman el apoyo relacionados con el proyecto mediante el apoyo a un proceso de desarrollo más formal, incluyendo los requisitos de certificación.

Configuración del software de gestión de 615

SommervilLe 2011 [4 *]

Mugirre 2006 [5 *]

Hass 2003 [3 *]

yoEEE 8282012 [2 *]

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

1. Gestión del Proceso de SMC 1.1. Contexto de organización de SMC 1.2. Limitaciones y orientación para el proceso SMC 1.3. La planificación de SMC 1.3.1. Organización y SMC Responsabilidades 1.3.2. Recursos y SCM horarios 1.3.3. Selección de herramientas y Implementación 1.3.4. Vendedor / Control de Subcontratista 1.3.5. control de interfaz 1.4. plan de SMC

c6, ann.D

Introducción

c6, ann.D, Ana

c2

c6, ann.D, Ana

c23

c29

ann.Ds5-6

c10-11

introducción c29

ann.Ds8

c23 c26s2; s6

c13

c13s9-c14s2

c12

c24s4

ann.D

c23

1.5. La vigilancia de software Gestión de la configuración 1.5.1. Medidas SCMy Medición

introducción c29

c29s5

c29s1

c9s2; c25s2-s3 C1S1 c29s1.1 c8s2.2

c29s1.1

software 2.1.2. SoftwareElemento de configuración 2.1.3. SoftwareRelaciones entre los elementos de configuración 2.1.4. Versión del software

c19s2.2

c11s3

1.5.2. En-Proceso de Auditorías de SMC Identificación 2. Configuración del software 2.1. La identificación de elementos que se van Revisado 2.1.1. Configuración del

c29

c29s1.1 c7s4 c29s3

2.1.5. Base 2.1.6. Software de adquisición de Elementos configuración 2.2. softwarede Library 3. Configuración del software Controlar 3.1. Solicitar, evaluar,Los cambios que aprueba y Software 3.1.1. Configuración del software Tabla de control 3.1.2. Software Proceso

c1s3

Revisión de cuentas 5.1. software funcional Auditoría de configuración 5.2. software física Auditoría de configuración 5.3. En-Proceso de auditorías de una de basededel software 6. Línea El software administración de lanzamientos 6.1. EdificioydeEntrega software

c29s2

c9s2.4

c29s2

c9s2.2

c11s1

c29s2

c1s4, c8s4 c29

c10 c10s2.1 c10s2.4

c1s5, c9s1, c17

c11 c11s2.1 c11s2.2 c11s2.3 c14

c8s2

c29s3 c29s4

6.2. Lanzamiento de software administración 7. Configuración del software Herramientas administrativas

c29s1.2

C9

3.2. La implementación de software cambios 3.3. Desviaciones y renuncias

4.2. Configuración del software de estado 5. Informes Configuración del software

SommervilLe 2011 [4 *]

c18

de Solicitud de Cambio

4. Configuración de Software Determinación del estado de 4.1. SoftwareInformación de estado de configuración

Mugirre 2006 [5 *]

Hass 2003 [3 *]

Guía SWEBOK® V3.0

yoEEE 8282012 [2 *]

6-16

c29s3.2 c26s1

Configuración del software de gestión de 617

LECTURAS

Referencias

Stephen P. Berczuk y Brad Appleton, Patrones de Gestión de la Configuración de Software: El trabajo en equipo eficaz, práctica Integración [6].

[1] ISO / IEC / IEEE 24765: 2010 Sistemas y de Ingeniería de Software-Vocabulario, ISO / IEC / IEEE 2010.

Este libro expresa prácticas de SCM y estrategias útiles como patrones. Los patrones pueden ser implementado utilizando diversas herramientas, sino que se expresa de una manera independiente del instrumento. “CMMI para el Desarrollo”, versión 1.3, pp. 137-147 [7]. Este modelo presenta una recopilación de las mejores ticas ticas para ayudar a las organizaciones de desarrollo de software a mejorar sus procesos. En el nivel de madurez 2, sugiere actividades de gestión de configuración.

[2 *] IEEE Std. 828-2012, Norma para Sistemas de Gestión de la Configuración de Software e Ingeniería, IEEE 2012. [3 *] AMJ Hass, Principios y Prácticas de gestión de configuración, 1st ed., AddisonWesley, 2003. [4 *] I. Sommerville, Ingeniería de Software, 9ª ed., Addison-Wesley, 2011. [5 *] JW Moore, La Hoja de Ruta de Ingeniería de Software: Una guía basada en estándares, Wiley-IEEE Computer Society Press, 2006. [6] SP Berczuk y B. Appleton, Patrones de Gestión de la Configuración del Software: El trabajo en equipo, la integración práctica, Addison-Wesley Professional, 2003. [7] CMMI equipo de productos, “CMMI para el Desarrollo, Versión 1.3,” Software Engineering Institute, 2010; http: // resources.sei.cmu.edu/library/asset-view. cfm? assetId = 9661.

6-18

Guía SWEBOK® V3.0

CAPÍTULO 7 GESTIÓN DE INGENIERÍA DE SOFTWARE SWX.

SIGLAS PMBOK® Guía para la Dirección de Proyectos del Conocimiento Guía SDLC SEM

Ciclo de vida del desarrollo de programas Gestión de Ingeniería de Software

SQA

Calidad de Software

SWX WBS

Extensión de software para el PMBOK® Guía Estructura de desglose del trabajo

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

1 Los términos inicio, planificación, ejecución, seguimiento y control, y de cierre se utiliza para describir grupos de proceso en el PMBOK® Guía y

• A menudo hay una rápida tasa de cambio en la tecnología subyacente.

• Los clientes a menudo no saben lo que se necesita o lo que es factible. • Los clientes a menudo carecen de reconocimiento por las complejidades inherentes a la ingeniería de software, en particular sobre el impacto de los requisitos de ING cam- bios. • Es probable que el aumento de la comprensión y las condiciones cambiantes generarán requisitos nuevos o modificados de software. • Como resultado de cambios en los requisitos, soft- ware se construye a menudo usando un proceso iterativo en lugar de como una secuencia de tareas cerradas. • La ingeniería de software incorpora necesariamente las tasas de creatividad y disciplina. El mantenimiento de un equilibrio adecuado entre los dos es a veces difícil. • El grado de novedad y complejidad es a menudo alta.

actividades de gestión de la ingeniería de software se producen en tres niveles: gestión de la organización y estructura de infraestructura, gestión de proyectos y gestión del programa de medición. Los dos últimos se tratan en detalle en esta descripción KA. Sin embargo, esto no es para disminuir la importancia de los problemas de gestión de la organización y de infraestructura. En general se acepta que los gerentes de ingeniería de software de organización deben estar familiarizados con el proyecto manage- ment conocimiento y la medición del software descrito en este KA. También deben poseer algunos conocimientos de dominio de destino. Del mismo modo, también es útil si los gerentes de proyectos y programas complejos en los que el software es un componente de la arquitectura del sistema son conscientes de las diferencias que los procesos de software introducen en la gestión de proyectos y la medición del proyecto.

7-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 impacto en la ingeniería de software (por ejemplo, políticas de la organización y los procedimientos que constituyen el marco en el que se llevan a cabo proyectos de ingeniería de software). Estas normativas y procedimientos de pueden necesitar ser ajustado por los requisitos de software eficaz Desa-, crear y mantener. Además, una serie de políticas específicas para la ingeniería de software puede necesitar estar en su lugar o establecido para la gestión eficaz de la ingeniería de software a nivel nizational or-. Por ejemplo, las políticas son generalmente necesarios para establecer procesos de toda la organización o procedimientos específicos para tareas de ingeniería de software, tales como diseño de software, software de construc- ción, la estimación, el seguimiento y la presentación de informes. Este tipo de políticas son importantes para la gestión efectiva a largo plazo de los proyectos de ingeniería de software en toda la organización (por ejemplo, el establecimiento de una base constante por el que

analizar los resultados anteriores pro- yecto e implementar mejoras).

Otro aspecto importante de la gestión de la organización son las políticas y procedimientos de gestión de personal para la contratación, capacitación y mentor personal ing para el desarrollo profesional, no sólo a nivel de proyecto, sino también a la Cess Suc a más largo plazo de una organización. el personal de ingeniería de software pueden presentar retos de formación o gestión de personal único (por ejemplo, el mantenimiento de la moneda en un contexto donde la tecno- logía subyacente sufre un cambio rápido y continuo). gestión de la comunicación también se menciona a menudo como un aspecto pasado por alto pero importante del rendimiento de las personas en un campo en el que es necesaria la comprensión precisa de las necesidades del usuario, requisitos de software y diseños de software. Por otra parte, la gestión de carteras, que pro- porciona una visión de conjunto, no sólo de software actualmente en fase de desarrollo en diversos proyectos y programas (proyectos integrados), sino también de software previstas y actualmente en uso en una organiza- ción, se deseable. Además, la reutilización de software es la clave

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

7-4 Guía SWEBOK® V3.0

factor en el mantenimiento y la mejora de la productividad y la competitividad. reutilización efectiva requiere una visión estratégica que refleja las ventajas y desventajas de reutilización. Además de comprender los aspectos de gestión que son influenciados de forma única por los proyectos de software, ingenieros de software deben tener algún conocimiento de los aspectos más generales de gestión que se tratan en este KA (incluso en los primeros años después de la graduación). Los atributos de la cultura organizacional y el comporta- miento, además de la gestión de otras áreas funcionales de la empresa, tienen una influencia, aunque sea indirectamente, en los procesos de ingeniería de software de una organización. Extensa información relativa a la gestión de proyectos de software se puede encontrar en la Guía para la Dirección de Proyectos del Conocimiento (Guía del PMBOK®) y el software de la extensión de la Guía PMBOK (SWX) [1] [2]. Cada una de estas guías incluye KAs diez proyectos de gestión: gestión de la integración de proyectos, gestión del alcance del proyecto, gestión del tiempo, gestión de proyectos, el costo del proyecto de gestión de calidad de proyectos, gestión de recursos humanos, gestión de proyectos comunicaciones del proyecto, la gestión de riesgos de proyectos, gestión de proyectos y adquisiciones gestión de los interesados del proyecto. Cada KA tiene relación directa con esta Ingeniería de Software de Gestión de KA. La información adicional también se proporciona en las otras referencias y otras lecturas de este KA. Este Ingeniería de Software de Gestión de KA se compone de los cesos de gestión de proyectos de software pro en los primeros cinco temas en la Figura 7.1 (Initiative ción y definición del alcance, Software Proyecto planificación, proyecto de software promulgación, revisión y evaluación, de cierre), además de Ingeniería de Software medición en el sexto tema y herramientas de software de gestión de ingeniería en el séptimo tema. Si bien la gestión de proyectos y gestión de medi- ción a menudo se considera una unidad independiente, y de hecho cada sí posee muchos atributos únicos, la estrecha relación que ha dado lugar a tratamiento combinado en este KA.

Por desgracia, una percepción común de la industria del software es que los productos de software se Ered deliv- tarde, por encima del presupuesto, de mala calidad y con una funcionalidad incompleta. La medición-informada

-gestión de un principio básico de cualquier verdadera disciplina inge- niería (ver Medición de las fundaciones inge- niería KA) -pueden ayudar a mejorar la percepción y la realidad. En esencia, la gestión sin medición (cualitativa y cuantitativa) sugiere una falta de disciplina, y la medición sin gestión sugiere una falta de propósito o contexto. La gestión eficaz requiere una combinación de ambos medición y experiencia. Las siguientes definiciones de trabajo se adoptan aquí: • administración es un sistema de procesos y controles necesarios para lograr los objetivos estratégicos fijados por la organización. • Medición se refiere a la asignación de los UE Val- y etiquetas a los productos de trabajo de ingeniería de software, los procesos y los recursos más los modelos que se derivan de ellos, si estos modelos son desarrollados usando técnicas estadísticas u otras [3 *, C7, C8]. Las secciones de gestión de proyectos de ingeniería de software en este KA hacen un amplio uso de la sección de medición de la ingeniería de software. Esta KA está estrechamente relacionado con otros en la Guía SWEBOK, y la lectura de las siguientes descripciones KA en conjunción con éste será particularmente útil: • El Fundamentos de Ingeniería KA describe algunos conceptos generales de medición que son aplicables directamente a la sección de ingeniería de software de medición de este KA. Además, los conceptos y técnicas presentados en la sección Análisis estadístico de los Fundamentos de Ingeniería KA se aplican directamente a muchos temas en este KA. • Los requisitos de software KA se describen algunas de las actividades que deben ser formados per- durante la fase Volumen defini- ción Iniciación y del proyecto. • El software de configuración de administración de KA se ocupa de la identificación, el control, el registro del estado, y la auditoría de software de configuraciones junto con la administración de la versión de software y herramientas de administración y gestión de software de configu- ración.

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

7-6 Guía SWEBOK® V3.0

• El Proceso de Ingeniería de Software KA describe los modelos del ciclo de vida del software y las relaciones entre los procesos y productos de trabajo. • La calidad del software KA hace hincapié en cali- dad como un objetivo de la gestión y como un objetivo de muchas actividades de ingeniería de software. • La Ingeniería de Software Economía KA discute cómo tomar decisiones relacionadas con el software en un contexto empresarial. DISTRIBUCIÓN DE TEMAS PARA LA GESTIÓN DE INGENIERÍA DE SOFTWARE Debido a que la mayoría de los modelos de ciclo de vida del software de desarrollo requieren actividades similares que puedan ser eje- cuta de diferentes maneras, el desglose de los temas es basado en la actividad. Esa ruptura se muestra en la Figura 7.1. Los elementos del Break-nivel superior mostrado en esa figura son las actividades que se realizan por lo general cuando se está gestionando un proyecto de desarrollo de software, independiente del modelo de ciclo de vida de desarrollo de software (ver Software Modelos de Ciclo de Vida de la Ingeniería de Software proceso KA) que ha sido elegido para un proyecto específico. No hay intención en esta averiado para recomendar un modelo específico del ciclo de vida. El desglose implica sólo lo que sucede y no implica cuándo, cómo, o cuántas veces se produce cada actividad. Los siete temas son: • Iniciación y definición del alcance, que se refieren a la decisión de embarcarse en un proyecto de ingeniería de software; • Software de planificación, que se ocupa de las actividades llevadas a cabo para preparar un proyecto de ingeniería de software exitoso desde el punto de vista de gestión; • Proyecto de software Promulgación, que se ocupa de las actividades de gestión de la ingeniería de software generalmente aceptados que se producen durante la ejecución de un proyecto de ingeniería de software; • Revisión y evaluación, que tratan de garantizar que, horario, costo, y las actividades de ingeniería técnica de calidad

son satisfactorios; • Cierre, que se ocupa de las actividades logrado completar un proyecto; • Ingeniería de Software de medición, el cual se ocupa del desarrollo eficaz y

implementación de programas de medición en organizaciones de ingeniería de software; • Herramientas de software de gestión de ingeniería, que describe la selección y el uso de herramientas para la gestión de un proyecto de ingeniería de software. 1. Iniciación y Definición del Alcance El objetivo de estas actividades es de determinación eficaz de los requisitos de software utilizando métodos de obtención variabilidad ous y la evaluación de la viabilidad del proyecto a partir de una variedad de puntos de vista. Una vez que se ha establecido la viabilidad del proyecto, las tareas restantes en esta sección son los ficación speci- de los requisitos y selección de los procesos de revisión y revisión de requisitos. 1.1. La determinación y la negociación de los requisitos [3 *, c3] Determinar y está llevando a cabo los requisitos establecidos de negociación de los límites visibles para el conjunto de tareas (ver los requisitos de software KA). Las actividades incluyen la obtención de requisitos, análi- sis, especificación y validación. Métodos y técnicas deben ser seleccionadas y aplicadas, teniendo en cuenta las diversas perspectivas de los interesados. Esto lleva a la determinación del alcance del proyecto con el fin de cumplir con los objetivos y satisfacer las restricciones. 1.2. Análisis de viabilidad [4 *, c4] El propósito del análisis de viabilidad es el desarrollo de una descripción clara de los objetivos del proyecto y eva- comió enfoques alternativos con el fin de determinar si el proyecto propuesto es la mejor alternativa, dadas las limitaciones de la tecnología, los recursos, las finanzas, y las consideraciones políticas sociales /. Un proyecto inicial y la declaración del alcance del producto, los entregables del proyecto, las limitaciones de duración del proyecto, y una estimación de los recursos necesarios deben estar preparados. Los recursos incluyen un número suficiente de personas que tienen las habilidades necesarias, las instalaciones, la infraestructura y el apoyo (ya sea interna o externamente). Análisis de viabilidad a menudo requiere

Ingeniería Softwarey de estimaciones aproximadas de de esfuerzo el Gestión coste de 7-7 sobre la base de métodos apropiados (véase la sección 2.3, Esfuerzo, Schedule, y el coste de estimación).

7-8 Guía SWEBOK® V3.0

1.3. Proceso para el examen y revisión de los requisitos [3 *, c3] Dada la inevitabilidad del cambio, las partes interesadas deben ponerse de acuerdo sobre los medios por los cuales los requisitos y alcance han de ser examinado y revisado (por ejemplo, procedimientos de gestión del cambio, retrospectivas ciclo tivos iteraciones). Esto implica claramente que el alcance y requisitos no serán “inamovibles”, pero pueden y deben ser revisados en puntos predeter- MINED como se desarrolla el proyecto (por ejemplo, en el momento en que se crean las prioridades de retraso acumulado o al hito comentarios). Si se aceptan los cambios, entonces algún tipo de análisis de trazabilidad y análisis de riesgos se debe utilizar para determinar el impacto de esos cambios (véase la sección 2.5, Gestión de Riesgos y Control de Configuración de Software en el KA Software Configuration Management). Un enfoque de cambio administrado también puede formar la base para la evaluación del éxito durante el cierre de un ciclo incremental o un proyecto completo, basado en los cambios que se han producido a lo largo del camino (véase el tema 5, Cierre). 2. Planificación de proyectos de software El primer paso en la planificación de proyectos de software debe ser la selección de un modelo de desa- rrollo ciclo de vida del software apropiado y quizá adaptándola basado en el alcance del proyecto, los requisitos de software, y una evaluación de riesgos. Otros factores que deben consi- Ered incluir la naturaleza del dominio de aplicación, complejidad funcional y técnica, y los requisitos de calidad blandos Ware (ver Requisitos de calidad de software en la calidad del software KA). En todos los SDLCs, evaluación de riesgos debe ser un elemento de la planificación inicial del proyecto, y el “perfil de riesgo” del proyecto deben ser discutidos y aceptados por todos los interesados. procesos de gestión de la calidad del software (ver Gestión de la Calidad de Software Procesos en la calidad KA software) deben determinarse como parte del proceso de planificación y dan lugar a procedimientos y responsabilidades para la garantía de la calidad

2.1. Planificación de procesos

[3 *, c3, c4, c5] [5 *, c1] del software, verificación y validación, opiniones y auditorías (ver la calidad KA software ). Procesos y responsabilidades para la revisión en curso y la revisión del plan de proyecto y los planes relacionados también deben estar claramente establecidos y acordados.

Software de ciclo de vida de desarrollo (SDLC) els mo- abarcan un continuo que va desde predictivo para adaptable (consulte el software del ciclo de vida Los modelos de la Ingeniería de Procesos de Software KA). SDLCs predictivos se caracterizan por el desarrollo de los requisitos de soft- ware detalladas, la planificación detallada del proyecto, y planificación mínima para la iteración entre fases de desarrollo. SDLCs adaptativos están diseñados para adaptarse a los requisitos de software emergentes y el ajuste iterativo de planes. A predictiva SDLC altamente pre- ejecuta los primeros cinco procesos enumerados en la figura 7.1 en una secuencia lineal con siones revi- a fases anteriores sólo cuando sea necesario. SDLCs tivos adaptaciones se caracterizan por ciclos desa- rrollo iterativos. SDLCs en la gama media de los incrementos SDLC continuum producto de funcio- nalidad ya sea en un horario planificada de antemano (en el lado predictivo del continuo) o como los pro- ductos de los ciclos de desarrollo frecuentemente actualizadas (en el lado de adaptación del continuo) . SDLCs bien conocidos incluyen los modelos de cascada, incremental y espiral más diversas formas de desarrollo ágil de software [2] [3 *, c2]. métodos pertinentes (véase la EngineerSoftware ing modelos y métodos KA) y las herramientas debe ser seleccionado como parte de la planificación. Las herramientas automatizadas que se utilizarán a lo largo del proyecto también se deben planificar y adquiridas. Las herramientas pueden incluir herramientas para la programación de proyectos, los requisitos de software, diseño de software, la construcción de software, mantenimiento de software, gestión de configuración de software, proceso de ingeniería de software, la calidad del software, y otros. Si bien muchas de estas herramientas debe seleccionarse con base principalmente en las consideraciones técnicas discutidas en otros Kas, algunos de ellos están estrechamente relacionados con las consideraciones Ment manage- discutidos en este capítulo. 2.2. determinar entregables [3 *, c4, c5, c6] El producto (s) de trabajo de cada actividad de proyecto (por ejemplo, la arquitectura software docu- mentos de diseño, informes de

de Software de Gestión inspección, elIngeniería software probado) debede 7-9 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-10

Guía SWEBOK® V3.0

deben ser evaluados. Adquisición de software y el uso de terceros para desarrollar las prestaciones debe ser planeada y proveedores seleccionados (ver sección 3.2, Software de Adquisición y Gestión de Proveedores de contrato).

así como por las cuestiones relativas al personal (por ejem- plo, la productividad de las personas y los equipos, la dinámica del equipo, y estructuras de equipo). 2.5. Gestión de riesgos [3 *, c9] [5 *, c5]

2.3. Esfuerzo, Calendario, y Estimación de Costos [3 *, c6] El rango estimado de esfuerzo requerido para un proyecto, o partes de un proyecto, se puede determinar utilizando un modelo de estimación calibrada en base al tamaño y esfuerzo datos históricos (cuando esté disponible) y otros métodos pertinentes, tales como el juicio de expertos y la analogía. dependencias de tareas se pueden establecer y oportunidades potenciales para la realización de tareas al mismo tiempo y de forma secuencial pueden ser identificados y documentados mediante un diagrama de Gantt, por ejem- plo. Para proyectos SDLC predictivos, el calendario previsto de tareas con tiempos de inicio proyectada, ciones durabilidad y el final de los tiempos se produce normalmente durante la planificación. Para proyectos SDLC de adaptación, una estimación general de esfuerzo y el horario típicamente se desarrolló a partir de la comprensión inicial de los requisitos, o, alternativamente, las restricciones sobre el esfuerzo global y el calendario puede ser especificado y se utiliza para determinar una estimación inicial de la nú- mero ciclos y estimaciones del esfuerzo de iterativos y otros recursos asignados a cada ciclo. Recursos necesarios (por ejemplo, personas y herramientas) pueden traducirse en estimaciones de costos. la estimación inicial de esfuerzo, horario, y el costo es una actividad iterativa que debe ser negociado y revisado entre las partes interesadas afectadas hasta que se alcanza consenso sobre los recursos y el tiempo disponible para la finalización del proyecto. 2.4. Asignación de recursos [3 *, c5, c10, c11]

Equipos, instalaciones y personas deben asignarse los que las tareas identificadas,

Riesgo e incertidumbre están relacionados pero distintos conceptos. La incertidumbre resulta de la falta de informa- ción. El riesgo se caracteriza por la probabilidad de un evento que se traducirá en un impacto negativo además de una caracterización de los efectos negativos sobre un proyec- ect. El riesgo es a menudo el resultado de la incertidumbre. Lo contrario de riesgo es la oportunidad, que se caracterizarse por la probabilidad de que un evento que tenga se puede producir un resultado positivo. La gestión del riesgo implica la identificación de factores de riesgo y análisis de la probabilidad y el impacto poten- cial de cada factor de riesgo, la priorización de los factores de riesgo, y el desarrollo de estrategias de mitigación de riesgos para reducir la probabilidad y minimizar el impacto negativo si un factor de riesgo se convierte en un problema. métodos de evaluación de riesgos (por ejemplo, la opinión de expertos, datos históricos, árboles de decisión, y simulaciones de procesos) a veces se pueden utilizar con el fin de identificar y evaluar los factores de riesgo. condiciones de abandono del proyecto también se pueden determinar en este punto de la discusión con todos los interesados. aspectos de software única de riesgo, tales como la tendencia ingenieros de software para añadir características que no sean necesarios, o los riesgos relacionados con la naturaleza intangible del software, puede influir en el riesgo hombreagement de un proyecto de software. aten- ción particular, se debe prestar a la gestión de los riesgos relacionados con los requisitos de calidad de software, tales como la seguridad o la seguridad (ver la calidad KA Software). La gestión del riesgo debe hacerse no sólo en el comienzo de un proyecto, sino también a intervalos periódicos a lo largo del ciclo de vida del proyecto. incluyendo el catión alo de responsabilidades para la realización de

variabilidad

2.6. Gestión de la calidad ous elementos de un proyecto y el proyecto en general. Una matriz que muestra quién es responsable de, responsables de, consultado sobre, e informado sobre cada una de las tareas se pueden utilizar. La asignación de recursos se basa en, y limitada por la disponibilidad de recursos y su uso óptimo, como se

Ingeniería de Software de Gestión de 711

[3 *, c4] [4 *, c24] los requisitos de calidad de software deben ser identifi- cado, tal vez en términos cuantitativos y cualitativos, para un proyecto de software y los productos de trabajo asociados. Los umbrales para las mediciones de calidad aceptables deben establecerse para cada requisito de calidad de software basada en las necesidades de las partes interesadas

7-12

Guía SWEBOK® V3.0

y expectativas. Procedimientos relacionados con el software en curso Garantía de Calidad (SQA) y la mejora de la calidad durante todo el proceso de desarrollo, y para la verificación y validación del producto software entregable, también deben especificarse durante la planificación de la calidad (por ejemplo, las revisiones e inspecciones técnicas o de- mostraciones de completado funcionalidad, véase la calidad del software KA). 2.7. Gestión del plan [3 *, c4] Para proyectos de software, donde el cambio es un tación tivas, los planes deben ser manejados. Administrar el plan de proyecto por lo tanto debe ser planificada. Planes y procesos seleccionados para el desarrollo de software deben ser controlados de forma sistemática, revisados, informaron, y, en su caso, revisada. Planes asociados a los procesos de apoyo (por ejem- plo, la documentación, configuración de software agement hombre- y resolución de problemas) también deberían ser manejadas. Informes, seguimiento y control de un proyecto debe encajar dentro de la SDLC seleccionado y las realidades del proyecto; planes deben tener en cuenta los diversos artefactos que serán utilizados para la edad causados por el hombre del proyecto. 3. La promulgación del proyecto de software Durante software del proyecto promulgación (también conocidos como la ejecución del proyecto) los planes se implementan y se promulgan los procesos incorporados en los planes. En todo momento, debe haber un enfoque en el cumplimiento de los procesos seleccionados SDLC, con una expectativa primordial que la adhesión dará lugar a la exitosa satisfacción de los requisitos de las partes interesadas y el logro de los objeti- vos del proyecto. Fundamental para la incorporación son las actividades de gestión en curso de supervisión, control-ling, y generación de informes. 3.1. Implementación de Planes [4 *, c2]

Las actividades del proyecto deben llevarse a cabo en ajustan al plan del proyecto y los planes de apoyo. Recursos (por ejemplo, personal, tecnología y financiación) son utilizados y productos de trabajo (por

ejemplo, diseño de software, código de software y pruebas de software de los casos) se generan. 3.2. Software de Adquisición y Gestión de Proveedores Contrato [3 *, c3, c4] adquisición de software y contrato de abastecimiento agement hombre- se ocupa de los aspectos que intervienen en la contratación con clientes del software desa- rrollo organización que adquieren los productos de trabajo y entregables con los proveedores que suministran productos o servicios a la organización de ingeniería de software. Esto puede implicar la selección de los tipos apropiados de contratos, como el precio fijo, el tiempo y mate- als, de costo más una cuota fija, o el costo más gasto de incentivo. Acuerdos con clientes y proveedores normalmente, un especifican camente el alcance del trabajo y los Ables deliver- e incluyen cláusulas tales como las sanciones de entrega o de no entrega tardía y acuerdos de propiedad intelectual que especifican lo que el proveedor o proveedores están ofreciendo y lo que el adquirente es pagar - ing para, además de lo que será entregado y propiedad del adquirente. Para el software está siendo desarrollado por los proveedores (internos o externos a la organización de desarrollo de software), los acuerdos comcomúnmente indican los requisitos de calidad de software para la aceptación del software entregado. Después de que el acuerdo se ha puesto en marcha, cution eje- del proyecto de acuerdo con los términos del acuerdo debe gestionarse (véase el capítulo 12 de SWX, Gestión de adquisición de software, para más información sobre este tema [2]). 3.3. Implementación de Proceso de medida [3 *, c7] El proceso de medición debe ser promulgada Duran- el proyecto de software para asegurar que se recogen los datos relevantes y útiles (ver secciones 6.2, planificar el proceso de medición, y 6.3, realizar el proceso de medición). 3.4. Process monitor [3 *, c8] La adhesión al plan del proyecto y planes

Ingeniería de Software de Gestión de 7- y relacionados debe ser continuamente evaluado 13 al

7-14

Guía SWEBOK® V3.0

intervalos predeterminados. Además, se deben evaluar los productos y los criterios pletion compara cada tarea. Entregables deben ser evaluados en términos de sus características requeridas (por ejemplo, a través de las inspecciones o mediante la demostración de la funcionalidad de trabajo). gasto esfuerzo, horario de la adherencia, y los costes hasta la fecha deben ser analizados, y el uso de recursos examinados. El perfil de riesgo del proyecto (ver sección 2.5, gestión de riesgos) debe ser revisada, y la adhesión a los requisitos de calidad de software eva- uated (ver Requisitos de calidad de software en la calidad del software KA). Los datos de medición deben ser analizados (véase Sta- Análisis Statistical en los Fundamentos de Ingeniería KA). El análisis de varianza basado en la desviación de real de los resultados y valores esperados debe ser determinado. Esto puede incluir los excesos de costes, cronograma deslizamiento, u otras medidas similares. identificación y análisis de los datos de calidad y otra de medición de valores atípicos se deben realizar (por ejemplo, análisis de defectos; ver Software Medición de la Calidad en el Software Quality KA). exposiciones de riesgo deben ser recalculados (ver sección 2.5, Gestión de Riesgos). Estas actividades pueden permitir la detección del problema e identificación excepción basada en umbrales que se han superado. Los resultados deben ser reportados cuando se han superado los umbrales, o según sea necesario. 3.5. Control de procesos [3 *, C7, C8] Los resultados de las actividades de seguimiento de proyectos proporcionan la base sobre la cual se pueden tomar decisiones. En su caso, y cuando la probabilidad y el impacto de los factores de riesgo se entienden, se pueden realizar cambios al proyecto. Esto puede tomar la forma de acción correctiva (por ejemplo, volver a probar ciertos componentes de software); que puede implicar calificación incorpora acciones adicionales (por ejemplo, la decisión de utilizar la creación de prototipos para ayudar en software de validación de los requisitos; ver Prototipos en los requisitos de software KA); y / o puede implicar la revisión del plan del proyecto y otros documentos del

proyecto (por ejemplo, los requisitos de software especifi- cación) para dar cabida a eventos no previstos y sus implicaciones. En algunos casos, el proceso de control puede llevar al abandono del proyecto. En todos los casos,

procedimientos de gestión de control de configuración de software y configuración de software deben ser atendidas (ver el software de configuración Hombre- agement KA), las decisiones deben ser documentados y comunicados a todas las partes interesadas, los planes deben ser revisados y revisados cuando sea necesario, y los datos pertinentes registrados ( véase la sección 6.3, Per- formar el proceso de medición). 3.6. informes [3 *, c11] En especificado y acordado veces, el progreso hasta la fecha se debe informar, tanto dentro de la organiza- ción (por ejemplo, a un co- mité de dirección del proyecto) y para los colaboradores externos (por ejemplo, clientes o usuarios). Los informes deben centrarse en las necesidades de información del público objetivo en comparación con el estado detallado de informes dentro del equipo del proyecto. 4. Revisión y Evaluación En tiempos pre-especificados y según sea necesario, reso general prog- hacia el logro de los objetivos planteados y la satisfacción de las partes interesadas (usuarios y clientes) requisitos deben ser evaluados. Del mismo modo, las evaluaciones de la eficacia del proceso de software, el personal involucrado, y las herramientas y métodos empleados también deben llevarse a cabo larmente REG y como determinados por las circunstancias. 4.1. La determinación de satisfacción de los requisitos [4 *, c8] Debido a lograr la satisfacción de las partes interesadas es un objetivo principal de la gerente de ingeniería de software, el progreso hacia este objetivo debe evaluarse periódicamente. El progreso debe ser evaluado en el logro de los principales hitos del proyecto (por ejemplo, la finalización de la arquitectura de diseño de software o la finalización de una revisión técnica de software), oa la conclusión de un ciclo de desarrollo iterativo que se traduce en un incremento del producto. Las variaciones de los requisitos de software deben ser identificados y deben tomarse acciones Apropiada.

Ingeniería de Software Gestión de 7Como en la actividad proceso dedecontrol 15 anteriormente (véase sec- ción 3.5, Process Control), configuración de software

7-16

Guía SWEBOK® V3.0

procedimientos de gestión de configuración de software de control y se deben seguir (véase el Software Configuration Management KA), las decisiones documentado y comunicado a todas las partes interesadas, los planes de examinar y modificar cuando sea necesario, y se registran los datos pertinentes (véase la sección 6.3, realizar el proceso de medición). 4.2. Revisión y Evaluación del desempeño [3 *, c8, c10] evaluaciones de desempeño periódicas para el proyecto sonal per- pueden proporcionar información en cuanto a la probabilidad de cumplimiento de los planes y procesos, así como posibles áreas de dificultad (por ejemplo, conflictos miembros del equipo). Los diversos métodos, herramientas y técnicas empleadas deben ser evaluados para su eficacia y conveniencia, y el proceso siendo utilizados por el proyecto también deben ser evaluados sistemática y periódicamente para Evance rel-, utilidad y eficacia en el contexto del proyecto. En su caso, se deben hacer cambios y gestionados. 5. Cierre Un proyecto completo, una fase importante de un proyecto, o un ciclo de desarrollo iterativo alcanza ClO seguro de que cuando se han aprobado y completado todos los planes y procesos. Los criterios para el proyecto, la fase o el éxito iteración deberían ser evaluados. Una vez que se establece el cierre, de archivo, retrospectivo, y de mejora de procesos actividades se pueden realizar. 5.1. Cierre la determinación [1, s3.7, S4.6] El cierre se produce cuando las tareas especificadas para un proyecto, una fase, o una iteración se han com- pletó logro y satisfactoria de los criterios pletion com- ha sido confirmada. Requisitos de software se pueden confirmar que se cumple o no, y el grado de consecución de los objetivos se pueden determinar. procesos de cierre deben involucrar a las partes interesadas y el resultado en la documentación de aceptación

5.2. Actividades de cierre

[2, s3.7, S4.8]

de las partes interesadas; problemas conocidos deben ser documentados.

Tras el cierre se haya confirmado, el archivo de los materiales del proyecto debe llevarse a cabo de acuerdo con los grupos de interés acordada ods met, la ubicación y la duración, posiblemente incluyendo la destrucción de la información sensible, el software y el medio en el que las copias son residentes. base de datos de medición de la organización debe actualizarse con los datos relevantes del proyecto. Un proyecto, la fase o análisis retrospectivo iteración deben llevarse a cabo para que los temas, problemas, riesgos y oportunidades encontradas pueden ser analizados (ver tema 4, Revisión y Evaluación). Las lecciones aprendidas deben extraerse del proyecto y se introducen en el aprendizaje y la mejora de los esfuerzos de organización. 6. Medición de Ingeniería de Software La importancia de la medición y su papel en mejores prácticas de gestión y de ingeniería es ampliamente reconocido (véase Medición de los Fundamentos de Ingeniería KA). surement medi- efectiva se ha convertido en una de las piedras angulares de la madurez de la organización. La medida puede ser aplicada a las organizaciones, proyectos, procesos y productos de trabajo. En esta sección se centra en la aplicación de la medida a nivel de proyec- tos, procesos y productos de trabajo. Esta sección sigue el estándar IEEE 15939: 2008 [6], que describe un proceso para definir las actividades y tareas necesarias para implementar un proceso de medición de software. El estándar también incluye un modelo de información de medición. 6.1. Establecer y mantener el compromiso de Medición [7 *, c1, c2] 2 • Requisitos para la medición. Cada esfuerzo de medición debe ser guiada por objetivos de la organización y accionado por un conjunto de requisitos de medición establecidos por 2 Tenga en cuenta que estos dos capítulos se pueden descargar de forma gratuita desde www.psmsc.com/ PSMBook.asp.

Ingeniería de Software de Gestión de 717

7-18

Guía SWEBOK® V3.0

la organización y el proyecto (por ejem- plo, un objetivo de la organización podrían ser “los primeros en el mercado con nuevos productos”). • Ámbito de aplicación de la medición. La unidad organizativa a la que cada requisito de medición se va a aplicar debe ser establecido. Esto puede consistir en un área funcional, un solo proyecto, un solo sitio, o toda una empresa.El ámbito temporal de la medición de esfuerzo también debe ser considerado porque puede ser necesario series de tiempo de algunas mediciones; por ejemplo, para calibrar los modelos estimación (ver sección 2.3, Esfuerzo, ULE Sched-, y estimación de costos). • el compromiso del equipo de medición. El compromiso debe establecerse formalmente, comunica, y apoyado por los recursos (ver siguiente punto). • Recursos para la medición. El compromiso de una organiza- ción de medición es un factor esencial para el éxito, como lo demuestra la asignación de recursos para implement- ing el proceso de medición. Asignación de recursos incluye la asignación de responsabili- dad para las diversas tareas del proceso de medición (tales como el analista y bibliotecario). adecuada financiación, formación, herramientas y apoyo para llevar a cabo el proceso también deben asignarse.

6.2. Planificar el proceso de medición [7 *, c1, c2] • Caracterizar la unidad organizativa. La unidad de organización proporciona el contexto para la medición, por lo que el contexto de la organización debe ser explícita, incluyendo los straints confirma que la organización impone en el proceso de medición. La caracterización se puede afirmar en términos de procesos de organización, dominios de aplicación, la tecnología, las interfaces de organización y estructura organizativa. • Identificar las necesidades de información. Las necesidades de información se basan en los objetivos, limitaciones, riesgos y problemas de la unidad organizativa. Ellos

se pueden derivar de negocio, objetivos de la organización, regulación y / o de productos. Ellos deben ser identificados y

•

•

•

•

priorizado. A continuación, un subconjunto de los objetivos que se abordarán se puede seleccionar, documentado, com- municated, y revisado por los interesados. Optar por medidas. medidas candidatos deben ser seleccionados, con claros vínculos con las necesidades de informa- ción. Las medidas deben ser seleccionados en base a las prioridades de las necesidades de información y otros criterios tales como coste de la recogida, el grado de interrupción del proceso durante la recogida, la facilidad de obtención, los datos Consistente precisa, y la facilidad de análisis y ing informe-. Debido a las características de calidad interna (ver modelos y características de calidad de la calidad del software KA) a menudo no contenida en los requisitos de software contractuales, es importante tener en cuenta medi- suring la calidad interna del software para proporcionar un indicador temprano de potencial cuestiones que puedan afectar a las partes interesadas externas. Definir la recogida de datos, análisis y procedimientos de ING informe-. Esto abarca procedimientos de recogida y horarios, almacenamiento, verifica- ción, análisis, informes y gestión de la configuración de datos. Seleccione los criterios de evaluación de los productos de información. Criterios para la evaluación están influidos por los tantes objeciones técnicas y comerciales de la unidad organizativa. Los productos de información incluyen los asociados con el producto que se produce, así como los asociados con los procesos que se utilizan para administrar y medir el proyecto. Proporcionar recursos para las tareas de medición. El plan de medición debe ser revisado y aprobado por los interesados apropiados para incluir todos los procedimientos de recolección de datos; procedimientos de almacenamiento, análisis y presentación de informes; criterios de evaluación; horarios; y responsabilidades. cri- terios para la revisión de estos artefactos deberían haberse establecido a nivel de unidad organizativa o superior y deben utilizarse como base para estas revisiones. Dichos criterios deben tener en cuenta la experiencia previa, la capacidad de disponibilidad de recursos, y las posibles interrupciones a los proyectos cuando se proponen cambios desde ticas ticas actuales. Aprobación demuestra el compromiso con el

Ingeniería de Software de Gestión de 7proceso de medición. 19 • Identificar recursos para poner a disposición de la aplicación de los previsto y aprobado

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

tareas de medición. La disponibilidad de recursos puede ser puesta en escena en los casos en que los cambios han de ser pilotado antes del despliegue generalizado. Deberán tener en cuenta a los recursos necesarios para la implementación exitosa de nuevos procedimientos o medidas. • Adquirir y desplegar tecnologías de apoyo. Esto incluye la evaluacióntecnologías de soporte disponibles de, la selección de las tecnologías más adecuadas, de adquisición de esas tecnologías, y el despliegue de esas tecnologías. 6.3. Realizar el proceso de medición

Fundamentos de ingeniería KA). Los resultados y conclusiones son generalmente revisados, usando un proceso definido por la organización (que puede ser formal o informal). Los proveedores de datos y usuarios de medida deben participar en la revisión de los datos para asegurarse de que son significativos y precisos y que puedan dar lugar a acciones razonables. • Comunicar los resultados. Los productos de información deben ser documentados y comunicados a los usuarios y grupos de interés. 6.4. evaluar Medición

[7 *, c1, c2]

[7 *, c1, c2]

• Integrar los procedimientos de medición con los procesos de software Evant rel. Los procedimientos de medición, tales como la recopilación de datos, deben integrarse en los procesos de software que se está midiendo. Esto puede implicar cam- ing procesos de software actuales para acomodar la recopilación de datos de fecha o actividades de generación. También puede implicar el análisis de los procesos de software actuales para reducir al mínimo esfuerzo adicional y la evaluación del efecto de los empleados para asegurar que se aceptarán los procedimientos de medición. problemas de moral y otros factores humanos deben ser considerados. Además, los procedimientos de medición deben ser comu- nicated a los que proporcionan los datos. También puede ser necesario proporcionar formación y apoyo. procedimientos de análisis de datos y de información están típicamente integrados en los procesos de organización y / o proyecto de manera similar. • Recolectar datos. Los datos deben recogerse, que ha comprobado, y se almacenan. Colección veces se puede automatizar mediante el uso de software de Engineer- herramientas de gestión de ING (véase el tema 7, la Cesión de Software de Gestión de Herramientas de ingeniería) para analizar los datos y elaborar informes. Los datos pueden ser agregados, transformadas, o recodificados como parte del proceso de análisis, utilizando un grado de rigor

apropiado a la naturaleza de los datos y las necesidades de información. Los resultados de este análisis son típicamente indicadores tales como gráficos, números u otras indicaciones que serán interpretadas, resultando en conclusiones y recomendaciones que se presentará a las partes interesadas (ver Análisis estadístico en el

7-12

Guía SWEBOK® V3.0

• Evaluar productos de información y el proceso surement medicontra especificado Evaluation criterios ación y determinar las fortalezas y debilidades de los productos de información o proceso, respectivamente. La evaluación puede ser realizada por un proceso interno o una auditoría nal externamente; que debe incluir la retroalimentación de los usuarios de medición. Las lecciones aprendidas deben ser registrados en una base de datos adecuada. • Identificar las mejoras potenciales. Tales mejoras pueden ser cambios en el formato de los indicadores, los cambios en unidades medidas, o reclasificación de categorías de medición. Los costos y los beneficios potenciales de las mejoras deben ser determinados y acciones de mejora apropiadas deben ser reportados. • Comunicar las mejoras propuestas para el propietario del proceso de medición y ERS stakehold- para su revisión y aprobación. Además, la falta de mejoras potenciales debe comuni- nicated si el análisis no identifica ninguna mejora.

7. Herramientas de Gestión de Ingeniería de Software [3 *, c5, c6, c7] herramientas de gestión de la ingeniería de software a menudo se utilizan para proporcionar visibilidad y control de los procesos de gestión de ingeniería de software. Algunas herramientas son automatizados, mientras que otros son manualmente implementado. Ha habido una tendencia reciente hacia el uso de suites integradas de ingeniería de software herramientas que se utilizan en un proyecto para planificar, recopilar y registrar, monitorear y controlar, y

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

proyecto de informe e información del producto. Las herramientas pueden puede dividir en las siguientes categorías: Planificación de proyectos y herramientas de seguimiento. planificación de proyectos y herramientas de seguimiento se pueden utilizar para estimar el esfuerzo y el coste del proyecto compañero y preparar los programas del proyecto. Algunos proyectos utilizan herramientas automatizadas esti- mación que aceptan como entrada el tamaño estimado y otras características de un producto de software y producen estimaciones del esfuerzo total, el cronograma y costo requerido. herramientas de planificación también incluyen herramientas de programación que analizan las tareas dentro de una estructura de desglose de trabajo automatizado, su estimación acoplado duraciones, sus relaciones de precedencia, y los recursos asignados a cada tarea para pro- ducir un calendario en forma de un diagrama de Gantt. herramientas de seguimiento se pueden utilizar para realizar un seguimiento de los hitos del proyecto, reuniones de estado del proyecto programadas regularmente, ciclos de iteración programadas, demostraciones de productos y / o elementos de acción. Herramientas de gestión de riesgos. herramientas de gestión del riesgo (ver sección 2.5, gestión de riesgos) se pueden utilizar para realizar un seguimiento de la identificación del riesgo, estimación y supervisión. Estas herramientas incluyen el uso de enfoques como la simulación o de árboles de decisión para analizar el efecto de los costos versus beneficios

y estimaciones subjetivas de las probabilidades de los eventos de riesgo. herramientas de simulación Monte Carlo se pueden utilizar para producir distribuciones de probabilidad de esfuerzo, horario, y el riesgo mediante la combinación de múltiples distribuciones de probabilidad de entrada de una manera algorítmica. Herramientas de comunicación. Las herramientas de comunicación pueden ayudar a proporcionar información oportuna y consistente a las partes interesadas que participan en un proyecto. Estas herramientas pueden incluir cosas como las notificaciones de correo electrónico y transmisiones de los miembros del equipo y las partes interesadas. También incluyen comu- nicación de las actas de las reuniones regulares del proyecto, reuniones diarias de stand-up, además de gráficos que muestran el progreso, el trabajo atrasado, y solicitud de mantenimiento resoluciones. Herramientas de medición. Herramientas de medición SUPactividades 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 completamente automatizadas en esta categoría. instrumentos de medición utilizados para reunir, analizar y reportar los datos de medición de proyecto pueden estar basados en hojas de cálculo desarrollados por los miembros del equipo de proyecto o empleados organizativas.

Guía SWEBOK® V3.0

1. Iniciación y Alcance Definición 1.1. La determinación y la negociación de los requisitos 1.2. Análisis de viabilidad 1.3. proceso parael examen y revisión de los requisitos 2. software de planificación 2.1. Planificación de procesos 2.2. determinar entregables 2.3. Esfuerzo, Planificar,y Estimación de Costos 2.4. Asignación de recursos 2.5. Gestión de riesgos 2.6. Gestión de la calidad 2.7. Gestión del plan

c4 c3

c2, c3, c4, c5 c4, c5, c6

C5, C10, C11 C9 c4 c4

c5 c24

c2 C3, C4 c7

3.4. Process monitor

c8 C7, C8 c11

4. Revisión y Evaluación 4.1. La determinación de satisfacción de los requisitos 4.2. revisandoy la evaluación del desempeño

c1

c6

3.3. Implementación de Proceso de medida 3.5. Control de procesos 3.6. informes

c8, c10

mcGarry et al. 2001 [7 *]

BoEHM y Turner 2003 [5 *]

c3

La promulgación 3. Proyecto de Software 3.1. Implementación de Planes 3.2. Software de Adquisición y Proveedor Gestión de contratos

SommervilLe 2011 [4 *]

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

JustaLey de 2009 [3 *]

7-14

mcGarry et al. 2001 [7 *]

BoEHM y Turner 2003 [5 *]

SommervilLe 2011 [4 *]

JustaLey de 2009 [3 *]

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

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 Compromiso de medición

c1, c2

6.2. Planificar la Medición Proceso

c1, c2

6.3. Realizar la medición Proceso

c1, c2

6.4. evaluar Medición

c1, c2

7. Herramientas de Gestión de Ingeniería de Software

C5, C6, C7

7-16

Guía SWEBOK® V3.0

LECTURAS Una guía para la Dirección de Proyectos (PMBOK® Guía) [1]. La Guía PMBOK ® proporciona directrices para la gestión de proyectos individuales y define los conceptos relacionados con la gestión de proyectos. También describe el ciclo de vida de gestión de proyectos y sus procesos relacionados, así como el ciclo de vida del proyecto. Es una guía reconocida a nivel mundial para la profesión agement el proyecto hombre-. Software de Extensión a la Guía de los Fundamentos de la Dirección de Proyectos (Guía del PMBOK®) [2]. SWX ofrece adaptaciones y ampliaciones de las prácticas genéricas de gestión de proyectos documentados en la Guía PMBOK ® para proyectos de software ing manag-. La principal contribución de esta extensión de la Guía PMBOK ® es una descripción de los procesos que son aplicables para la gestión de proyectos de software de ciclo de vida de adaptación. La adopción de la norma IEEE ISO / IEC 15939 [6]. Esta norma internacional identifica un proceso que es compatible con la definición de un conjunto adecuado de medidas para hacer frente a las necesidades específicas de información. Se identidades FIES las actividades y tareas que son necesarias para identificar con éxito, definir, seleccionar, aplicar y mejorar la medición dentro de un proyecto global o la estructura organizativa de medición. J. McDonald, gestión del desarrollo de software de sistemas intensivos, Wiley, 2010 [8]. Este libro de texto proporciona una introducción a la gestión de proyectos para el comienzo de los desarrolladores de software y 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.

Referencias [1] Instituto de Gestión de Proyectos, una guía para la Dirección de Proyectos del Conocimiento (PMBOK (R) Guía), 5ª ed., Project Management Institute, 2013. [2] Instituto de Gestión de Proyectos y IEEE Computer Society, software de la extensión de la Guía del PMBOK® quinta edición, Project Management Institute, 2013. [3 *] RE Fairley, gestionar y liderar proyectos de software, Wiley-IEEE Computer Society Press, 2009. [4 *] I. Sommerville, Ingeniería de Software, 9ª ed., Addison-Wesley, 2011. [5 *] B. Boehm y R. Turner, Equilibrio de la agilidad y disciplina: una guía para los perplejos, Addison-Wesley, 2003. [6] IEEE Std. 15939-2008 La adopción del estándar ISO / IEC 15939: 2007 Sistemas y Procesos de Ingeniería de Software de Mediciones, IEEE 2008. [7 *] J. McGarry et al, Practical Software de medición:. Información Objetivo para los decisores, Addison-Wesley Professional, 2001. [8] J. McDonald, gestión del desarrollo de software de sistemas intensivos, John Wiley and Sons, Inc., 2010.

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

CAPÍTULO 8 SOFTWARE INGENIERÍA DE PROCESOS de software. Para facilitar la lectura “, la ingeniería de software

SIGLAS BPMN

Business Process Modeling Notación

CASO

Software Asistida por Ordenador Ingenieria

CM CMMI

Gestión de la configuración Capability Maturity Model Integration

GQM

Meta-pregunta-Metric

IDEF0 LOE

integración Definición Nivel de esfuerzo

ODC SDLC

Clasificación de defectos ortogonal Ciclo de vida del desarrollo de programas Software del ciclo de vida del

SPLC UML

producto Lenguaje de Modelado Unificado

INTRODUCCIÓN Un proceso de ingeniería consiste en un conjunto de actividades interrelacionadas que transforman una o más entradas en salidas, mientras que consume recursos cumpla cabalmente la transformación. Muchos de los procesos de disciplinas de ingeniería tradicionales (por ejemplo, eléctrica, mecánica, civil, químicos) se refieren a la transformación de la energía y las entidades físicas de una forma a otra, como en una presa hidroeléctrica que transforma la energía potencial en energía eléctrica o una refinería de petróleo que utiliza procesos químicos para transformar el petróleo crudo en gasolina. En esta área de conocimiento (KA), ingeniería de software procesos tienen que ver con las actividades de trabajo realizado por los ingenieros de software para desarrollar, mantener y operar el software, tales como los requisitos, diseño, construcción, pruebas, gestión de con- figuración, y otra procesos de ingeniería

de Software de Gestión de 7-19 la adaptaciónIngeniería y la implementación de procesos de software para un proyecto de software específico (ver Proceso de Planificación en el KA Software Engineering Management). Els y métodos mo- apoyan un enfoque sistemático para el desarrollo de software y modificación. La calidad KA software se ocupa de la planificación, aseguramiento y control de procesos para el proyecto y la calidad del producto. Medición y medición de los resultados en la Ingeniería Foundation ciones KA son esenciales para la evaluación de los procesos de software y control- ling.

proceso”se denomina‘proceso de software’en este KA. Además, tenga en cuenta que “el proceso de software” se refiere a las actividades de trabajo, no el proceso de ejecución para el software implementado. procesos de software se especifican para un número de razones: para facilitar la comprensión humana, la comunicación y la coordinación; para ayudar agement-hombre de los proyectos de software; para medir y mejorar la calidad de los productos de software de una manera eficiente; para apoyar proceso de mejora ción; y para proporcionar una base para el puerto SUP- automatizado de ejecución del proceso. SWEBOK KAs estrechamente relacionados con este proceso de Ingeniería de Software KA incluyen el software de gestión de ingeniería, modelos 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 Fundamentos de Ingeniería KA también está estrechamente relacionado. Software de gestión de ingeniería se ocupa de la adaptación,

DISTRIBUCIÓN DE TEMAS DE INGENIERÍA DE PROCESOS DE SOFTWARE Como se ilustra en la Figura 8.1, este KA tiene que ver con la definición de procesos de software, los ciclos de vida del software, evaluación de procesos de software y la mejora, la medición del software, el software y herramientas de proceso de inge- niería.

8-1

8-2 Guía SWEBOK® V3.0

Figura 8.1. Desglose de los temas para el Proceso de Ingeniería de Software KA

1. Proceso de definición de software [1 *, P177] [2 *, P295] [3 *, p28-29, p36, c5] Este tema tiene que ver con una definición de proceso de software, gestión de procesos de software, y la infraestructura de procesos de software. Como se mencionó anteriormente, un proceso de software es un conjunto de actividades y tareas interrelacionadas que transforman los productos de trabajo de entrada en productos de trabajo de salida. Como mínimo, la descripción de un pro- ceso de software incluye entradas requiere, transformar las actividades de trabajo y genera salidas. Como se ilustra en la Figura 8.2, un proceso de software también puede incluir su entrada y criterios de salida y la descomposición de las actividades de trabajo en tareas, que son las unidades más pequeñas de trabajo sujetas a la responsabilidad de gestión. Una entrada de proceso puede ser un evento ing Trigger o la salida de otro proceso. Los criterios de ingreso deben ser satisfechas antes de que un proceso pueda comenzar. Todas las condiciones

especificadas deben ser satisfechas antes de que un proceso puede ser con éxito

concluido, incluyendo los criterios de aceptación para el producto del trabajo de salida o productos de trabajo. Un proceso de software puede incluir subprocesos. Por ejemplo, la validación de los requisitos de software es un proceso utilizado para determinar si los requisitos proporcionarán una base adecuada para el desarrollo de software; es un subproceso del proceso de requisitos de software. Las entradas para la validación de requisitos son típicamente unos requisitos de software valor especificado y los recursos necesarios para realizar la validación (personal, herramientas de validación, tiempo suficiente). Las tareas de la actividad de validación requisitos podrían incluir requisitos de los comentarios, prototipado y validación del modelo. Estas tareas incluyen las asignaciones de trabajo para las personas y equipos. La salida de validación de requisitos suele ser una especificación de requisitos de software validado que proporciona entradas para el diseño de software y el software de Exámenes procesos ing. validación de requisitos y otros subprocesos del proceso de requisitos de software son a menudo intercalada y reiterada en varias formas;

Software de Ingeniería de Procesos 8-3

8-4 Guía SWEBOK® V3.0

Figura 8.2. Elementos de un proceso de software

el proceso de requisitos de software y sus subprogramas, cesos pueden entraba y salía varias veces durante el desarrollo de software o modificación. definición completa de un proceso de software también puede incluir las funciones y competencias, TI SUP- puerto, técnicas de ingeniería de software y herramientas, y ambiente de trabajo necesario para llevar a cabo el proceso, así como los enfoques y medidas (indicadores clave de rendimiento) que se utiliza para determinar la la eficiencia y la eficacia de la realización del proceso. Además, un proceso de software puede incluir actividades tivas técnicas, colaborativas y administraciones intercalados. Notaciones para la definición de procesos de software incluyen listas textuales de actividades que lo componen y las tareas que se describen en lenguaje natural; diagramas de flujo de datos; gráficos de estado; BPMN; IDEF0; redes de Petri; y los diagramas de actividad UML. Las tareas de transformación dentro de un proceso pueden definirse como procedimien- tos; un procedimiento se puede especificar como un conjunto ordenado de pasos o, alternativamente, como una lista de control del trabajo a llevar a cabo en la realización de una tarea. Se debe enfatizar que no hay mejor proceso de software o conjunto de procesos de software. procesos de soft- ware deben ser seleccionados, adaptados, y se aplican según sea apropiado para cada proyecto y cada contexto de la organización. No hay proceso ideal, o un conjunto de procesos, existe. 1.1. Gestión de procesos de software [3 *, s26.1] [4 *, p453-

454] Dos objetivos de la gestión de procesos de software son para darse cuenta de la eficiencia y eficacia que

resultado de un enfoque sistemático para accomplish- ing procesos de software y producir trabajo Pro- ductos-ya sea a nivel individual, proyecto, o el nivel y organizativa para introducir procesos nuevos o mejorados. Los procesos se cambian con la expectativa de que un proceso nuevo o modificado mejorará la eficiencia y / o la eficacia del proceso y la calidad de los productos de trabajo resultantes. El cambio a un nuevo proceso, la mejora de un proceso existente, el cambio organizacional y cambio de infraestructura (inserción de la tecnología o los cambios de herramientas) están estrechamente relacionados, ya que todos están inicia generalmente con el objetivo de mejorar el coste, el desarrollo sched- ULE, o la calidad de los productos de software. cambio de proceso tiene un impacto no sólo para el producto de software; que a menudo conducen al cambio organizativo. El cambio de un proceso o la introducción de un nuevo proceso puede tener efectos de la ondulación a lo largo de un organización. Por ejemplo, los cambios en las herramientas informáticas infra- estructura y la tecnología a menudo requieren cambios en el proceso. Los procesos existentes pueden ser modificados cuando otros procesos nuevos se despliegan por primera vez (por ejemplo, la introducción de una actividad de inspección dentro de un proyecto de desarrollo de software probablemente tendrá un impacto en las pruebas de software proceso- ver revisiones y auditorías de la calidad de software y KA en las pruebas de software KA). Estas situaciones también pueden ser denominados “evolución del proceso.” Si las modificaciones son extensas, a continuación, los cambios en la cultura y la empresa modelo de organización es probable que sea necesario para acomodar los cambios en el proceso.

Software de Ingeniería de Procesos 8-5

8-6 Guía SWEBOK® V3.0

1.2. Infraestructura de Procesos de Software [2 *, P183, P186] [4 *, p437438]

proceso influye en la calidad del producto de software. 2. Ciclos de vida del software

El establecimiento, implementación y gestión de procesos de software y modelos de ciclo de vida del software a menudo se produce en el nivel de los proyectos de software individuales. Sin embargo, la aplicación sistemática de los procesos de software y de ciclo de vida del software els mo- través de una organización puede proporcionar beneficios a todos los trabajos de software dentro de la organización, a pesar de que requiere un compromiso a nivel orga- zational. Una infraestructura de proceso de software puede proporcionar definiciones de los procesos, las políticas de preting inter y la aplicación de los procesos, y las descripciones de los procedimientos que se utilizarán para implementar los procesos. Además, una infraestructura de proceso de software puede proporcionar financiación, herramientas, ING forma-, y miembros del personal que hayan sido asignadas responsabilidades para establecer y mantener la infraestructura de proceso de software. infraestructura de proceso de software varía, Dependiendo del tamaño y la complejidad de la organización y los proyectos llevados a cabo dentro de la organización. , organizaciones y proyectos sencillos pequeños tienen necesidades de infraestructura pequeños y sencillos. Grandes, organizaciones y proyectos complejos, por sidad nece-, tienen infraestructuras de procesos de software más grandes y complejos. En el último caso, se pueden establecer diferentes unidades organizativas (tal como un grupo de procesos de ingeniería de software o un comité ing steer-) para supervisar la aplicación y mejora de los procesos de software. Un error común es que el establecimiento de una infraestructura de proceso de software e implementación de procesos de software repetibles añadirá tiempo y costo para el desarrollo y mantenimiento de software. Hay un costo asociado con la introducción o la mejora de un proceso de software; Sin embargo, experiencia ha demostrado que la aplicación de la mejora sistemática de los procesos de software tiende a dar lugar a menor costo mediante la mejora de la eficiencia, Ance Evitar- de repetición del trabajo, y el software más fiable y asequible. por lo tanto el rendimiento del

[1 *, c2] [2 *, p190] En este tema se aborda categorías de pro- cesos de software, modelos de ciclo de vida del software, software

adaptación de procesos, y consideraciones prácticas. Un ciclo de vida de desarrollo de software (SDLC) incluye los procesos de software utilizados para especificar y transformar los requisitos de software en un producto de software erable deliv-. Un ciclo de vida del producto de software (SPLC) incluye un software de ciclo de vida de desarrollo de software más procesos adicionales que proporcionan para el despliegue, mantenimiento, soporte, la evolución, la jubilación, y todos los demás procesos inception--a la jubilación para un producto de software, incluyendo la gestión de configuración de software y los procesos de garantía de calidad del software que se aplican a lo largo de un ciclo de vida del software de producto. Un ciclo de vida del producto de software puede incluir software PLE ciclos de vida de desarrollo múltiples para desarrollar y mejorar el software. procesos de software individuales no tienen ningún pedido ral tempo entre ellos. Las naves PARENTESCO temporales entre los procesos de software son proporcionados por un modelo de ciclo de vida del software: ya sea un SDLC o SPLC. modelos de ciclo de vida suelen destacar los procesos de software clave dentro del modelo y sus interdependencias y relaciones cias temporales y lógicas. las definiciones detalladas de los procesos de software en un modelo de ciclo de vida se pueden proporcionar directamente o por referencia a otros documentos. Además de transmitir las relaciones temporales y lógicas entre los procesos de software, el modelo de desarrollo de software de ciclo de vida (o modelos usan dentro de una organización) incluye los mecanismos de control para la aplicación de criterios de entrada y salida (por ejemplo, las revisiones del proyecto, el cliente approv- del als, las pruebas de software , umbrales de calidad, onstrations demos-, equipo de consenso). La salida de un proceso de software a menudo proporciona la entrada para ERS oth- (por ejemplo, requisitos de software proporcionan entrada para un proceso de diseño arquitectónico software y los cesos de construcción de software y pruebas de software pro). ejecución concurrente de varias actividades del proceso de software pueden producir una salida compartida (por ejemplo, las especificaciones de la interfaz para las interfaces entre los múltiples componentes de software desarrollados por diferentes equipos). Algunos procesos de software pueden ser

de aIngeniería de Procesos considerados como menosSoftware efectivo menos que 8-7 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).

8-8 Guía SWEBOK® V3.0

2.1. Categorías de procesos de software [1 *, Prefacio] [2 *, p294-295] [3 *, c22c24] Muchos procesos diferentes de software se han definido para su uso en las diversas partes de los ciclos de vida de desarrollo de software de mantenimiento y software. Estos procesos se pueden clasificar como sigue: 1. procesos primarios cesos incluir pro de software para el desarrollo, operación y mantenimiento de software. 2. apoyar los procesos se aplican de forma intermitente o continua durante todo el ciclo de vida del producto de software para apoyar cesos pro primarias; que incluyen procesos de software, tales como gestión de la configuración, Ance assur- calidad, y la verificación y validación. 3. procesos de organización proporcionar puerto SUP- para la ingeniería de software; que incluyen capacitación, análisis de medición de procesos, gestión de infraestructuras, gestión de cartera y reutilización, mejora de procesos de organización y gestión de los modelos del ciclo de vida del software. 4. procesos entre proyectos, tales como la reutilización, la línea de productos software, y la ingeniería de dominio; que involucran a más de un proyecto de software solo en una organización. procesos de software, además de los mencionados anteriormente incluyen los siguientes. los procesos de gestión de proyectos incluyen procesos para la planificación y la estimación, gestión de recursos, medición y control, lo que lleva, la gestión de riesgos, la gestión de las partes interesadas, y que coordinara la primaria, el apoyo, la organización, y entre proyectos de procesos de software Desa-, crear y mantener proyectos. procesos de software también se han desarrollado para necesidades particulares, tales como las actividades del proceso que se ocupan de las características de calidad de software (ver la calidad KA Software). Por ejemplo, los problemas de seguridad durante el desarrollo de software pueden requerir uno o más procesos de

software para proteger la seguridad de MENT el desarrollo ambiente y reducir el riesgo de actos maliciosos. procesos de soft- ware también pueden ser desarrollados para proporcionar un fundamento adecuado para el establecimiento de la confianza en la integridad del software.

2.2. Modelos de Ciclo de vida del software [1 *, c2] [2 *, S3.2] [3 *, S2.1] [5] La naturaleza intangible y maleable de software permite una amplia variedad de modelos de ciclo de vida del software de desarrollo, que van desde los modelos lineales en los que las fases de desarrollo de software se lleva a cabo secuencialmente con retroalimentación y iteración, según sea necesario, seguido de la integración, ing Test-, y la entrega de una producto único; a los modelos iterativo en el que se desarrolla software en incrementos de aumentar la funcionalidad en ciclos iterativos; a los modelos ágiles que normalmente implican manifestaciones frecuentes de software que trabaja con un representante del cliente o usuario que dirige el desarrollo del software en ciclos iterativos cortos que producen incrementos pequeños de trabajo, software entregable. modelos incrementales, iterativos y ágiles pueden entregar los primeros subconjuntos de software que trabaja en el entorno del usuario, si lo desea. modelos lineales SDLC se refieren a veces como los modelos de predicción del ciclo de vida de desarrollo de software, mientras que SDLCs iterativos y ágiles se conocen como modelos de adaptación del ciclo de vida de desarrollo de software. Cabe señalar que variabilidad actividades de mantenimiento OU durante una SPLC puede llevarse a cabo utilizando diferentes modelos SDLC, según sea apropiado para las actividades de mantenimiento. Una característica distintiva de los diferentes modelos de ciclo de vida de desarrollo de software es la manera en que se gestionan los requisitos de software. modelos de desarrollo del oído Lin- desarrollan típicamente por un juego completo de los requisitos de software, en la medida en que sea posible, durante la iniciación y planificación de proyectos. Los requisitos de software son entonces rigurosamente controlados. Los cambios en los requisitos de software se basan en las solicitudes de cambio que son procesados por un tablero de control de cambios (véase la Solicitud, la evaluación y aprobación de software Cambios en el Consejo de Control de Cambios en el Software de Gestión de Configuración KA). Un modelo incremental produce incrementos sucesivos de traba- jando, software entregable basado en la partición de los requisitos de software para ser

de de Ingeniería de Procesos implementados en Software cada uno los incrementos. 8-9 Los requisitos de software pueden ser rigurosamente controladas, como en un modelo lineal, o puede haber cierta flexibilidad en la revisión de los requisitos de software como el producto de software evoluciona. modelos ágiles pueden definir el alcance del producto y de alto nivel incluye inicialmente; Sin embargo, ágil

8-10

Guía SWEBOK® V3.0

modelos están diseñados para facilitar la evolución de los requisitos de software durante el proyecto. Se debe enfatizar que el continuo de SDLCs de lineal a ágil no es una línea delgada, recta. Elementos de diferentes enfoques pueden ser incorporados en un modelo específico; por ejemplo, un software de modelo de ciclo de vida de desarrollo incremental puede incorporar requisitos de software secuenciales y fases de diseño, pero permitir una gran flexibilidad en la revisión de los requisitos de software y la arquitectura durante la construcción de software. 2.3. La adaptación de procesos de software [1 *, s2.7] [2 *, p51] SDLCs predefinida, SPLCS, y procesos de software individuales a menudo necesitan ser adaptados (o “a medida”) para servir mejor a las necesidades locales. contexto organiza- cional, las innovaciones en la tecnología, el tamaño del proyecto, la criticidad del producto, los requisitos normativos, prácticas de la industria, y la cultura corporativa pueden determinar las adaptaciones necesarias. La adaptación de los procesos de software individuales y los modelos del ciclo de vida del software (desarrollo de productos) y puede consistir en añadir más detalles a los procesos de software, actividades, tareas y procedimientos para abordar los problemas críticos. Puede consistir en el uso de un conjunto alter- nar de las actividades que logra el propósito y los resultados del proceso de software. La adaptación también puede incluir la omisión de los procesos o actividades de software de un modelo de ciclo de vida del producto o de desarrollo que son claramente inaplicables al alcance del trabajo a ser realizado. 2.4. Consideraciones prácticas [2 *, p188-190] En la práctica, los procesos y actividades de software a menudo se entrelazan, se superponen, y se aplican concurrente tualmente. Los modelos del ciclo de vida del software que especifican los procesos de software Creta dis-, con criterios de entrada y salida rigurosamente especificadas y los límites e interfaces prescritas, deben ser reconocidos como idealizaciones que deben

adaptarse para reflejar las realidades del desarrollo y mantenimiento de software dentro del contexto de la organización y ambiente de negocios. Otra consideración práctica: procesos de software (como la gestión de la configuración,

construcción y pruebas) se pueden adaptar para facilitar su manejo Tate, soporte, mantenimiento, migración, y el retiro del software. Otros factores a tener en cuenta en la definición y la adaptación de un modelo de ciclo de vida del software incluyen la conformidad requerida a las normas, las Directivas y políticas; demandas de los clientes; criticidad del producto de software; y organizativo ridad maduración y competencias. Otros factores incluyen la naturaleza del trabajo (por ejemplo, modificación del software existen- tes contra nuevo desarrollo) y el dominio de aplicación (por ejemplo, el espacio aéreo frente a la gestión del hotel). 3. Software de evaluación y mejora de procesos [2 *, P188, P194] [3 *, c26] [4 *, P397, c15] Este proceso de modelos de evaluación de software direcciones tema, ods met evaluación de procesos de software, modelos de mejora de procesos de software, y continua y por etapas clasificaciones de proceso. evaluaciones del proceso de software se utilizan para evaluar la forma y el contenido de un proceso de software, que podrá ser indicada por un conjunto estandarizado de criterios. En algunos casos, los términos “evaluación de proceso” y “capacidad de evaluación” se utilizan en lugar de la evaluación del proceso. evaluaciones de capacidad se realizan típicamente por un adquirente (o adquirente potencial) o por un agente externo en nombre de un adquirente (o adquirente potencial). Los resultados se utilizan como un indicador de si los procesos de software utilizados por un proveedor (o potencial proveedor) son aceptables para el adquirente. Las evaluaciones del desempeño se realizan normalmente dentro de una organización para identificar los procesos de software en necesidad de mejorar o para determinar si un proceso (o procesos) satisface los criterios a un nivel dado de capacidad de proceso o madurez. evaluaciones del proceso se realizan en los nive- les de organizaciones enteras, unidades organizativas dentro de las organizaciones y proyectos individuales. La evaluación puede incluir temas como evalua- ción si se están cumpliendo de entrada de proceso de software y terios salida teria, para revisar los factores de riesgo y la gestión del riesgo, o para identificar las lecciones aprendidas. evaluación de proceso

Software se lleva a cabo utilizando tanto de unIngeniería modelodedeProcesos 8-11 evaluación y un método de evaluación. El modelo puede proporcionar una norma para una evaluación comparativa

8-12

Guía SWEBOK® V3.0

la comparación entre los proyectos dentro de una organiza- ción y entre organizaciones. Una auditoría de proceso difiere de un proceso de Assessment. Las evaluaciones se realizaron para determinar niveles de capacidad o madurez y para identificar los procesos de software que ser mejorado. Las auditorías se realizan normalmente para verificar el cumplimiento con las políticas y normas. Auditorías proporcionan visibilidad ción manage- en las operaciones reales que se lleva a cabo en la organización para que las decisiones precisas y significativas se pueden hacer cuestiones ING concern- que están afectando a una actividad de mantenimiento de desarrollo pro- yecto, o un tema relacionado con el software. factores de éxito de los procesos de software evalua- ción y mejora dentro del software Engineer- organizaciones ing incluyen buque gestión patrocinio, la planificación, la formación, los líderes experimentados y capaces, el compromiso del equipo, gestión de las expectativas, el uso de agentes de cambio, además de proyectos piloto y experimentación con herramientas. fac- tores adicionales incluyen la independencia del evaluador y la oportunidad de la evaluación. 3.1. Modelos de evaluación de procesos de software [2 *, S4.5, S4.6] [3 *, s26.5] [4 *, p4448] 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 DesaMent solamente, o también pueden incluir temas tales como el mantenimiento de software, gestión de proyectos de software, ingeniería de sistemas, o la gestión de recursos humanos. 3.2. Proceso de Software Métodos de evaluación [1 *, p322-331] [3 *, s26.3] [4 *, p44-48, s16.4] [6] Un método de evaluación de procesos de software puede ser cualitativa o cuantitativa. Las valoraciones cualitativas se basan en el juicio de expertos; evaluaciones cuantitativas asignar puntuaciones numéricas a los procesos de software basados en el análisis de pruebas

objetivas que indica la consecución de los objetivos y resultados de un proceso de software definido. Por ejemplo, una evaluación cuantitativa del proceso de inspección soft- ware puede ser realizada por

examinar los pasos del procedimiento seguido y los resultados obtenidos, además de los datos relativos a los defectos encontrados y el tiempo requerido para encontrar y corregir los defectos en comparación con las pruebas de software. Un método típico de proceso de software evalua- ción incluye la planificación, determinación de los hechos (por collectpruebas ing a través de cuestionarios, entrevistas y observación de las prácticas de trabajo), la recopilación y validación de los datos del proceso, y el análisis y generación de informes. evaluaciones del proceso pueden confiar en el criterio subjetivo, cualitativo del evaluador, o en la presencia objetiva o ausencia de artefactos definidos, registros y otras pruebas. Las actividades llevadas a cabo durante una evaluación de procesos de software y la distribución del esfuerzo de las actividades de evaluación son diferentes dependiendo del propósito de la evaluación de procesos de software. evaluaciones del proceso de software se pueden emprender para desarrollar calificaciones de capacidad que se utilizan para hacer recomendaciones para mejoras en el proceso o pueden llevarse a cabo para obtener una calificación de madurez de los procesos con el fin de calificar para un contrato o premio. La calidad de los resultados de la evaluación depende del método de evaluación de procesos de software, la integridad y la calidad de los datos obtenidos, la capacidad y la objetividad del equipo de evaluación, y las pruebas examinadas durante la evaluación. El objetivo de un proceso de evaluación de software es para obtener conocimientos que establecerá el estado actual de un proceso o procesos y proporcionar una base para la mejora de procesos; la realización de una evaluación de procesos de software siguiendo una lista de comprobación para la conformidad y sin hacerse una idea agrega poco valor. 3.3. Modelos de mejora de procesos de software [2 *, p187-188] [3 *, s26.5] [4 *, s2.7] modelos de mejora de procesos de software enfatiza tamaño ciclos iterativos de mejora continua. Un ciclo de mejora de procesos de software general afecta a los subprocesos de medición, lyzing ana- y cambiantes. El modelo de Plan-Do-Check-Act es un enfoque iterativo bien conocido para la mejora de procesos de software. Las actividades de mejora incluyen

Software de mejoras Ingeniería dedeseadas Procesos identificar y priorizar 8-13 (planificación); la introducción de una mejora, incluyendo la gestión y la formación (hacer) el cambio; evaluación de la mejora

8-14

Guía SWEBOK® V3.0

en comparación con los resultados anteriores o ejemplares de proceso y costes (control); y hacer modificaciones adicionales (en funciones). El Plan-Do-Check-Act modelo de mejora de procesos se puede aplicar, por ejemplo, para mejorar los procesos de software que mejoran la prevención de defectos. 3.4. Software puntuaciones proceso continuo y puesta en escena [1 *, p28-34] [3 *, s26.5] [4 *, p39-45] Software de la capacidad de proceso y software de madurez de los procesos se clasifican normalmente usando cinco o seis niveles para caracterizar la capacidad o madurez de los procesos de software utilizados dentro de una organización. Un sistema de evaluación continua implica la asignación de una calificación a cada una de procesos de software de interés; una por etapas se establece sistema de clasificación por la asignación de una calificación por edades de la misma a todos los procesos de software dentro de un nivel de proceso especificado. A representación de continua y el proceso de lev- els se proporciona en la Tabla 8.1 puesta en escena. modelos continuos suelen utilizar un nivel 0 opinión; por etapas modelos Tıpicamente no lo hacen. Tabla 8.1. Niveles de software proceso de calificación La La representación representación Nivel continua de los por etapas de niveles de niveles de capacidad madurez 0 Incompleto 1

realizado

Inicial

2 3

Gestionado definido

Gestionado definido cuantitativam ente Gestionado Optimización

4 5

En la Tabla 8.1, el nivel de 0 indica que un proceso de software se lleva a cabo de forma incompleta o no se puede realizar. En el nivel 1, se está realizando un proceso de software (valoración capacidad), o se están realizando los procesos de software en un grupo de madurez

nivel 1, pero de forma puntual, de manera informal. En el nivel 2, un proceso de software (valoración capacidad) o los procesos en el nivel de madurez 2 están siendo per- forman de una manera que proporciona una gestión

visibilidad de los productos de trabajo intermedios y puede ejercer algún control sobre las transiciones entre procesos. En el nivel 3, un único proceso de software o los procesos en un nivel 3 grupo de madurez más el proceso o los procesos en el nivel de madurez 2 están bien definidas (tal vez en las políticas y procedimientos de organización) y se repiten a través de dife- rentes proyectos. Nivel 3 de la capacidad del proceso o madurez proporciona la base para el proceso de mejora ment través de una organización porque el proceso es (o procesos están) llevó a cabo en un ner Hombresimilar. Esto permite la recogida de datos de rendimiento de manera uniforme a través de múltiples proyectos. En el nivel de madurez 4, las medidas cuantitativas pueden ser aplicados y utilizados para la evaluación de procesos; análisis tical estadís- puede ser utilizado. Al nivel de madurez 5, se aplican los mecanismos para el proceso continuo de mejoras. representaciones continuos y por etapas se pueden utilizar para determinar el orden en que los procesos de software son un ser mejorado. En la representación continua, los diferentes niveles de capacidad para diferentes procesos de software proporcionan una guía para determinar el orden en que serán mejorados procesos de software. En la repre- sentación por etapas, la satisfacción de los objetivos de un conjunto de procesos de software dentro de un nivel de madurez se lleva a cabo para ese nivel de madurez, lo que proporciona una base para la mejora de todos los procesos de software en el siguiente nivel superior. 4. Medición de software [3 *, s26.2] [4 *, s18.1.1] Este proceso de software direcciones tema y medición pro- ducto, la calidad de los resultados de medición, modelos de información, software y técnicas de medición de procesos de software (ver Medición en los Fundamentos de Ingeniería KA). Antes de que un nuevo proceso se ejecute o un proceso actual es modificado, los resultados de medición de la situación actual deben obtenerse a proporcio- nar una línea de base para la comparación entre la situación actual y la nueva situación. Para exami- plo, antes de introducir el proceso de inspección de software, el esfuerzo necesario para reparar defectos descubiertos por las pruebas deben ser medidos. Después de un período de puesta en marcha ini- cial después de que el proceso de

de Ingeniería de Procesos inspección se introduce, Software el esfuerzo combinado 8-15 de la inspección

8-16

Guía SWEBOK® V3.0

además de las pruebas puede ser comparada con la cantidad anterior de esfuerzo requerido para probar solo. consideraciones simi- lar se aplican si se cambia un proceso. 4.1. Proceso de Software y Medición del producto [1 *, S6.3, P273] [3 *, s26.2, P638] procesos de software y medición del producto tienen que ver con la determinación de la eficiencia y la eficacia de un proceso de software, la actividad o tarea. La eficiencia de un proceso de software, la actividad o tarea es la relación entre los recursos consumidos efectivamente a los recursos esperados o deseados para ser consumidos en el cumplimiento de un proceso de software, la actividad o tarea (véase la eficiencia en el software de Economía Ingeniería KA). Esfuerzo (o el costo equivalente) es la principal medida de los recursos para la mayoría de los procesos de software, las actividades y tareas; que se mide en unidades tales como horas-persona-persona, días, semanas, o entre el personal y personameses de esfuerzo o en unidades monetarias equivalentes-tales como euros o dólares. Eficacia es la relación de salida real a la salida esperado producido por un proceso de software, la actividad, o tarea; por ejemplo, el número real de los defectos detectados y corregidos durante las pruebas de software para el número esperado de defectos para ser detectados y corregidos, quizá basada en los datos his- tórica para proyectos similares (véase la Eficacia en el software de Economía Ingeniería KA). Tenga en cuenta que la medición de los procesos de software effec- tividad requiere la medición de los atributos de productos de referencia; por ejemplo, la medición de los defectos de software descubierto y corregido durante pruebas de software. Hay que tener cuidado en la medición de los atributos del producto con el fin de determinar la efectividad del proceso. Por ejemplo, el número de defectos detectados y corregidos por la prueba no puede alcanzar el número esperado de defectos y por lo tanto proporcionar una medida engañosamente baja efectividad, ya sea porque el software que está siendo probado es de mejorque la habitual calidad o quizás debido a la introducción de un proceso de inspección aguas

arriba recién introducido se ha reducido el número restante de defectos en el software. medidas de productos que pueden ser importantes en la determinación de la eficacia de los pro- cesos de software incluyen la complejidad del producto, defectos totales, densidad de defectos, y la calidad de los requisitos,

documentación de diseño, y otros productos de trabajo relacionados. También tenga en cuenta que la eficiencia y la eficacia son conceptos independientes. Un proceso de software eficaz puede ser ineficaz en la consecución de un resultado de procesos de software deseado; por ejemplo, la cantidad de esfuerzo realizado para encontrar defectos de software y solución podría ser muy alto y resultar en una baja eficiencia, en comparación con las expectativas. Un proceso eficiente puede ser ineficaz en acompa- plishing la transformación deseada de los productos de trabajo de entrada en los productos de trabajo de salida; por ejemplo, el hecho de encontrar y corregir un número suficiente de defectos de software durante el proceso de prueba. Las causas de la baja eficiencia y / o baja efectividad en la forma de un proceso de software, la actividad o tarea se ejecuta podría incluir uno o más de los siguientes problemas: trabajo de entrada pro- ductos deficientes, personal sin experiencia, la falta de herramientas e infraestructura adecuados , el aprendizaje de un nuevo proceso, un producto complejo, o un dominio del producto desconocido. La eficiencia y eficacia de la ejecución de procesos de software también se ven afectados (ya sea positiva o negativamente) por factores tales como Turnsobre en el personal de software, cambios de horario, un nuevo representante del cliente, o una nueva política organizativa. En la ingeniería de software, la productividad en per- que forman un proceso, actividad o la tarea es la relación de salida producida dividida por recursos consumidos; por ejemplo, el número de defectos de software dis- cubierto y corregida dividida por horashombre de esfuerzo (véase la productividad en el Engineer- Software ing Economía KA). La medición precisa de la productividad debe incluir el esfuerzo total usado para satisfa- isfy los criterios de salida de un proceso de software, activi- dad o la tarea; por ejemplo, el esfuerzo requerido para corregir defectos descubiertos durante el software de Exámenes deben ser incluidos en la productividad del desarrollo de software. El cálculo de la productividad se debe tener en cuenta el contexto en el que se lleva a cabo el trabajo. Por ejemplo, se incluirá el esfuerzo para corregir los defectos descubiertos en el cal- culación productividad de un equipo de software si los miembros del equipo de corregir

Software de Ingeniería los defectos que encuentran, como en de laProcesos unidad 8-17 de pruebas por los desarrolladores de software o en un equipo ágil de funciones cruzadas. O el cálculo de la productividad puede incluir ya sea el esfuerzo del software

8-18

Guía SWEBOK® V3.0

desarrolladores o el esfuerzo de un equipo ING Ensayos independientes, dependiendo de quién fija los defectos encontrados por los probadores independientes. Tenga en cuenta que este ejemplo se refiere al esfuerzo de los equipos de Ircops o equipos de probadores desa- y no a los individuos. la productividad del software calculado al nivel de los individuos puede ser engañoso debido a los muchos factores que pueden afectar la productividad individual de los ingenieros de software. definiciones estandarizadas y las reglas de recuento para la medición de los procesos de software y productos de trabajo son necesarias para proporcionar resultados de medición estandarizados a través de proyectos dentro de una organización, para rellenar un depósito de datos cal históricamente que pueden ser analizados para identificar procesos de software que necesitan ser mejoradas y para construir modelos predictivos basados en los datos acumulados. En el ejemplo anterior, serían necesarias las definiciones de defectos de software y personal-horas de pruebas esfuerzo más contando reglas para defectos y esfuerzo para obtener resultados de medición satisfactorios. La medida en que se institucionaliza el proceso de software es importante; insuficiencia ins- titucionalización de un proceso de software puede explicar por qué los “buenos” los procesos de software no siempre pro duce resultados anticipados. procesos de software pueden ser institucionalizados por adopción dentro de la unidad organizativa local oa través de unidades más grandes de una empresa. 4.2. Calidad de los resultados de medición [4 *, s3.4-3.7] La calidad del proceso y medición del producto resultados se determina principalmente por la fiabilidad y la validez de los resultados medidos. Las mediciones que no satisfacen estos criterios de calidad pueden dar lugar a interpretaciones erróneas y las iniciativas de mejora de procesos de software defectuoso. Otras propiedades deseables de mediciones de software incluyen la facilidad de recolección, análisis, y previa presentación más una fuerte correlación entre la causa y efecto. El tema de ingeniería de software de medición

de la Ingeniería de Software de Gestión de KA describe un proceso para la implementación de un programa de medición de software.

4.3. Información de software Modelos [1 *, p310-311] [3 *, p712-713] [4 *, s19.2] Software modelos de información permiten el modelado, análisis y predicción de procesos de software y producto de software atributos para proporcionar respuestas a las preguntas pertinentes y lograr los objetivos del proceso y mejora del producto. datos necesarios pueden ser recogidos y retenidos en un repositorio; Los datos pueden ser ana- lisadas y los modelos se pueden construir. La validación y el perfeccionamiento de los modelos de información de software se producen durante los proyectos de software y después de la conclusión de los proyectos para asegurar que el nivel de precisión es suficiente y que sus limitaciones son conocidas y comprendidas. modelos de información de software también pueden ser desarrolladas para contextos distintos proyectos de software; por ejemplo, un modelo de información de software podría ser desarrollado para los procesos que se aplican en toda la organización, tales como los procesos de garantía de calidad del software software de gestión de configu- ración o en el nivel de organización. edificio de información de software modelo de análisis impulsado implica el desarrollo, la calibración y evaluación de un modelo. Un software de infor- mación modelo se desarrolla mediante el establecimiento de una transformación planteado la hipótesis de variables de entrada en resultados deseados; por ejemplo, el tamaño y la complejidad de los productos pueden ser transformados en estimación acoplado esfuerzo necesario para desarrollar un producto de software utilizando una ecuación de regresión desarrollado a partir de los datos observados de proyectos anteriores. Un modelo se calibra mediante el ajuste de los parámetros en el modelo para que coincida con los resultados observados de proyectos anteriores; Por ejemplo, el exponente en un modelo de regresión no lineal puede ser cambiado mediante la aplicación de la ecuación de regresión a un conjunto diferente de proyectos anteriores distintos de los proyectos utilizados para desarrollar el modelo. Un modelo se evalúa mediante la comparación de los resultados calculados con los resultados reales para un conjunto diferente de datos similares. Hay tres posibles Evaluación resultados: 1. resultados calculados para un conjunto de

Software de Ingeniería datos diferente varían ampliamente de de losProcesos 8-19 resultados reales para ese conjunto de datos, en cuyo caso el modelo derivado no es aplicable para establecer los 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 encuentran cerca de los resultados reales de ese conjunto de datos, en cuyo caso los menores se realizan ajustes a los parámetros del modelo para mejorar el acuerdo; 3. Los resultados calculados para los nuevos conjunto de datos y conjuntos de datos posteriores están muy cerca y no se necesitan ajustes en el modelo. La evaluación continua del modelo puede Cate indicación de una necesidad de adaptación en el tiempo como el con- texto en el que se aplica el modelo de cambios. Las Metas / Preguntas / Métrica método (GQM) fue pensado originalmente para el establecimiento de actividades La medición, pero también se pueden utilizar para guiar el análisis y mejora de procesos de software. Se puede utilizar para guiar la construcción de información de software modelo de análisis impulsada; resultados obtenidos del modelo de información de software se pueden utilizar para guiar la mejora del proceso. El siguiente ejemplo ilustra la aplicación del método GQM: • Objetivo: Reducir la solicitud de cambio promedio tiempo de procesamiento en un 10% dentro de los seis meses. • Pregunta 1-1: ¿Cuál es el tiempo de procesamiento de solicitud de cambio de línea de base? • Métricas 1-1-1: Promedio de solicitud de cambio los tiempos de procesamiento en la fecha de inicio • Métricas 1-1-2: La desviación estándar del cambio tiempos de procesamiento de petición a la fecha de inicio • Pregunta 1-2: ¿Cuál es la hora actual de procesamiento de solicitud de cambio? • Métricas 1-2-1: Promedio de solicitud de cambio tiempos procesando en ese momento • Métricas 1-2-2: La desviación estándar del cambio los tiempos de procesamiento de solicitudes actualmente

Técnicas de medición de proceso también proporcionan la información necesaria para medir los efectos de las iniciativas de mejora de procesos. técnicas surement medi- proceso puede ser utilizado para recoger datos tanto cuantitativos como cualitativos. 4.4.1. Técnicas de medición de procesos cuantitativa 4.4. Técnicas de medición de procesos de software [1 *, c8] técnicas de medición de procesos de software se utilizan para recopilar datos de proceso y producto de trabajo, transformar los datos en información útil, y analizar la información para identificar las actividades del proceso que son candidatos para la mejora. En algunos casos, pueden ser necesarios nuevos procesos de software.

8-12

Guía SWEBOK® V3.0

[4 *, S5.1, S5.7, s9.8]

El propósito de las técnicas de medición de procesos cuantitativos es recoger, transformar y analizar los datos de proceso cuantitativo y producto de trabajo que se puede utilizar para indicar dónde se necesitan mejoras de proceso y para evaluar los resultados de las iniciativas de mejora de procesos. Técnicas de medición de proceso cuantitativo se utilizan para COLlect y analizar los datos en forma numérica a la que técnicas matemáticas y estadísticas se pueden aplicar. datos de proceso cuantitativos se pueden recoger como un subproducto de los procesos de software. Por ejemplo, el número de defectos detectados durante las pruebas de software y las horas de personal gastados pueden debe desechar por por medición directa, y la productivi- dad de descubrimiento defecto se pueden derivar por calculatdefectos ing descubiertos por personal horas. Herramientas básicas para el control de calidad se pueden utilizar para analizar los datos de medición de procesos cuantitativos (por ejemplo, hojas de verificación, diagramas de Pareto, histogramas, diagramas de dispersión, gráficos de series, gráficos de control y diagramas de causa y efecto) (véase el análisis de causa raíz en la Ingeniería fundamentos KA). Además, diversas técnicas estadísticas se pueden usar de ese rango de cálculo de las medianas y los medios para métodos de análisis multivariante (ver Análisis estadístico en los Fundamentos de Ingeniería KA). Los datos recogidos usando proceso cuantitativo medi- técnicas surement también se pueden utilizar como entradas a los modelos de simulación (ver Modelando, Prototyp- Ing, y Simulación en la Ingeniería Foundation ciones KA); estos modelos se pueden utilizar para evaluar el impacto de diferentes enfoques para la mejora de procesos de software. Clasificación de defectos ortogonal (ODC) se puede utilizar para analizar los datos Ment medición cuantitativa del proceso. ODC se puede utilizar para los defectos de grupo detectado en categorías y vincular los defectos en

Software de Ingeniería de Procesos 8-13

cada categoría para los procesos del proceso de software o software, donde un grupo de defectos origi- NATed (ver Defecto Caracterización en la Soft mercancías Quality KA). defectos interfaz de software, por ejemplo, pueden haberse originado durante una inade- equiparan proceso de diseño de software; mejorar el proceso de diseño de software reducirá el número de defectos de la interfaz de software. ODC puede proporcionar datos cuantitativos para la aplicación de análisis de causa raíz. Control Estadístico de Procesos se puede utilizar para realizar un seguimiento de la estabilidad del proceso, o la falta de estabilidad del proceso, el uso de gráficos de control. 4.4.2. Técnicas de medición de procesos cualitativos [1 *, s6.4] Cualitativa técnicas- medición de procesos que incluyen entrevistas, cuestionarios y la opinión de expertos, se puede utilizar para aumentar las técnicas de medición de procesos cuantitativos. técnicas de consenso del grupo, incluyendo la técnica Delphi, se pueden utilizar para obtener un consenso entre los grupos de interesados. 5. Herramientas de Ingeniería de Software Process [1 *, s8.7] herramientas de proceso de software soportan muchas de las notaciones ciones utilizadas para definir, implementar y gestionar los procesos de software individuales y los modelos del ciclo de vida del software. Incluyen editores para anotaciones tales como diagramas de flujo de datos, gráficos de estado, BPMN, diagramas IDEF0, redes de Petri, y los diagramas de actividad UML. En algunos casos, las herramientas de proceso de software permiten diferentes tipos de análisis y simulaciones (por ejemplo, de simulación de eventos discretos). En

Además, las herramientas de negocio de propósito general, tal como una hoja de cálculo, puede ser útil. Ingeniería de Software (CASE), herramientas de ayuda de computadora pueden reforzar el uso de procesos integrados, apoyar la ejecución de las definiciones de procesos defi-, y proporcionar orientación a los seres humanos en la formación de per- procesos bien definidos. herramientas simples, tales como procesadores de texto y hojas de cálculo se pueden utilizar para preparar las descripciones textuales de procesos, actividades y tareas; Estas herramientas también SUP- puerto de trazabilidad entre las entradas y salidas de múltiples procesos de software (como el análisis de las necesidades de los interesados, los requisitos de software ción especificaciones, arquitectura de software, y el diseño detallado de software), así como los resultados de los procesos de software como la documentación , componentes de software, casos de prueba, y la información de errores. La mayor parte de las áreas de conocimiento en esta guía se describen las herramientas especializadas que pueden ser utilizados para gestionar los procesos dentro de ese KA. En particu- lar, véase la Gestión de la Configuración de Software KA para una discusión de las herramientas de gestión de configuración de software que pueden ser utilizados para gestionar la construcción, integración y procesos para liberar los productos de software. Otras herramientas, como los de gestión de requisitos y pruebas, se describen en la KAs apropiado. herramientas de proceso de software pueden apoyar proyectos que involucran geográficamente equipos dispersos (virtuales). Cada vez más, las herramientas de proceso de software están disponibles a través de las instalaciones de computación en la nube, así como a través de infraestructuras dedicadas. Un panel de control de proyectos o en el salpicadero pueden dis- proceso seleccionado el juego y los atributos del producto para proyectos de software e indicar las medidas que están dentro de los límites de control y aquellos que necesitan una acción correctiva.

Guía SWEBOK® V3.0

1. Definición del proceso de software

P295

1.1. Gestión de procesos de software 1.2. Infraestructura de Procesos de Software 2. Ciclos de vida del software 2.1. Categorías de procesos de software 2.2. Modelos de Ciclo de vida del software 2.3. La adaptación de procesos de

P183, P186 p190

prefacio

p294-295

c22, c23, c24

c2

S3.2

S2.1

s2.7

p51 p188-190 P188, P194

c26

P397, c15

S4.5, S4.6

s26.5

p44-48

s26.3

p44-48, s16.4

s26.5

s2.7

s26.5

p39-45

s26.2

s18.1.1

p322-331

3.3. Modelos de mejora de procesos de software

p187-188

3.4. Calificaciones continuas y puesta en 4. escena Medición de Software

p28-34

4.1. Proceso de software y de productos Medición

S6.3, P273

s26.2, P638 S3.4, S3.5, S3.6, s3.7

4.2. Calidad de los resultados de medición 4.3. Información de software Modelos

p310-311

4.4. Medición de Procesos de Software técnicas

s6.4, c8

5. Proceso de Ingeniería de Software Herramientas

p453-454 p437-438

c2

3. Software de Evaluación y Mejora de Procesos 3.1. Modelos de evaluación de procesos de software 3.2. Evaluación de Procesos de Software métodos

p28-29, p36, c5 s26.1

software 2.4. Consideraciones prácticas

Kan 2003 [4 *]

P177

SommervilLe 2011 [3 *]

Mugirre 2009 [2 *]

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

JustaLey de 2009 [1 *]

8-14

s8.7

pag. 712713

s19.2 S5.1, S5.7, s9.8

Software de Ingeniería de Procesos 8-15

LECTURAS Software de la extensión de la Guía para la Dirección de Proyectos de Knowledge® (SWX) [5]. SWX ofrece adaptaciones y ampliaciones de las prácticas genéricas de gestión de proyectos documentado en la Guía PMBOK ® para la gestión de proyectos de software. La principal contribución de esta extensión de la Guía del PMBOK® es descrip- ción de los procesos que son aplicables para la gestión de proyectos de software de ciclo de vida de adaptación. D. Gibson, D. Goldenson, y K. Kost, “Rendimiento de resultados de mejora de proceso basado en CMMI” [6]. Este informe técnico resume públicamente dispo- evidencia empírica poder sobre los resultados de rendimiento que pueden ocurrir como consecuencia de la mejora de procesos basados CMMI-. El informe contiene una serie de breves descripciones de casos que fueron CREADA con la colaboración de representantes de 10 organizaciones que han logrado notables resultados de rendimiento cuantitativo a través de sus esfuerzos de mejora basados en CMMI. CMMI® para el Desarrollo, versión 1.3 [7]. CMMI® para el Desarrollo, versión 1.3 proporciona un conjunto integrado de directrices para el proceso de ING Desa- y la mejora de productos y servicios. Estas directrices incluyen las mejores prácticas para el desarrollo y mejora de productos y servicios para satisfacer las necesidades de los clientes y usuarios finales. ISO / IEC 15504-1: 2004 Información tecnologıa-Proceso de evaluación-Parte 1: Conceptos y vocabulario [8]. Este estándar, conocido comúnmente como SPICE (Software Mejora de Procesos y determinación de la capacidad), incluye múltiples partes. Parte 1 proporciona conceptos y vocabulario para los procesos de desarrollo de software y funciones de gestión de negociorelacionados. Otras partes de 15504 definen los requisitos y procedimientos para per- que

forman las evaluaciones de proceso.

8-16

Guía SWEBOK® V3.0

Referencias

[1 *] RE Fairley, gestionar y liderar proyectos de software, Wiley-IEEE Computer Society Press, 2009. [2 *] JW Moore, La Hoja de Ruta de Ingeniería de Software: Una guía basada en estándares, Wiley-IEEE Computer Society Press, 2006. [3 *] I. Sommerville, Ingeniería de Software, 9ª ed., Addison-Wesley, 2011. [4 *] SH Kan, métricas y modelos en Ingeniería de Software de Calidad, 2ª ed., AddisonWesley, 2002. [5] Instituto de Gestión de Proyectos y IEEE Computer Society, software de la extensión de la Guía del PMBOK® quinta edición, ed: Project Management Institute, 2013. [6] D. Gibson, D. Goldenson, y K. Kost, “Rendimiento Resultados de la mejora de procesos basado en CMMI,” Software Engineering Institute, 2006; http: // resources.sei.cmu.edu/library/assetview. cfm? assetId = 8065. [7] CMMI equipo de productos, “CMMI para el Desarrollo, Versión 1.3,” Software Engineering Institute, 2010; http: // resources.sei.cmu.edu/library/assetview. cfm? assetId = 9661. [8] ISO / IEC 15504-1: 2004, Información Tecnología-Proceso de Evaluación-Parte 1: Conceptos y Vocabulario, ISO / IEC 2004.

Software de Ingeniería de Procesos 8-17

CAPÍTULO 9 Modelos y métodos de software de ingeniería SIGLAS 3GL

Idioma tercera generación

BNF FDD

Backus-Naur Form Desarrollo de funciones-Driven

IDE

Desarrollo integrado Ambiente

PBI

Producto Cartera de artículos

RAD

Desarrollo rápido de aplicaciones

UML XP

Lenguaje de Modelado Unificado Programación extrema

INTRODUCCIÓN modelos y métodos de ingeniería de software imponen estructura en la ingeniería de software con el objetivo de hacer que la actividad sistemática y repetible, y en definitiva más éxito-orientado. El uso de modelos proporciona un enfoque para la resolución de problemas, una notación, y los procedimientos para la construcción y análisis de modelo. Métodos proporcionan una aproximación a la especificación sistemática, diseño, construcción, pruebas y verificación del software de punto final y los productos de trabajo asociados. modelos y métodos de ingeniería de software varían ampliamente en su alcance-de abordar una sola fase del ciclo de vida del software de cubrir el ciclo de vida del software pleta com-. El énfasis en esta área de conocimiento (KA) está en ingeniería de software modelos y métodos que abarcan múltiples fases del ciclo de vida del software, ya que los métodos específicos para las fases individuales del ciclo de vida están cubiertas por otra KAs.

DISTRIBUCIÓN DE TEMAS PARA MODELOS Y MÉTODOS DE INGENIERÍA DE SOFTWARE Este capítulo sobre modelos de ingeniería de software y métodos se divide en cuatro áreas temáticas principales: • Modelado: Se analiza la práctica general de la modelización y presenta temas en los principios de modelado; propiedades y expresión de los modelos; modelado de sintaxis, la semántica y la pragmática; y las condiciones previas, postcondi- ciones, e invariantes. • Tipos de modelos: Brevemente discute modelos y agregación de submodelos y proporciona algunas características generales de los tipos de modelo comúnmente encontradas en la práctica de la ingeniería de software. • Análisis de Modelos: Presenta algunas de las técnicas de análisis comunes utilizados en ing modelo- para verificar la integridad, la consistencia, rectness cor-, trazabilidad, y la interacción. • Métodos de ingeniería de software: Presenta un breve resumen de los métodos de ingeniería de software de uso común. La discusión se guía al lector a través de un resumen de los métodos heurísticos, métodos formales, la creación de prototipos, y los métodos ágiles. El desglose de los temas para los modelos de ingeniería de software y métodos KA se muestra en la Figura 9.1. 1. Modelado

técnica para ayudar a los ingenieros de software a entender,

Modelización de software se está convirtiendo en un omnipresente

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 software a las partes interesadas pertinentes. Las partes interesadas son aquellas personas o partes que tienen un interés explícitas o implícitas en el software (por ejemplo, usuario, comprador, proveedor, arquitecto, certificando autori- dad, evaluador, desarrollador, ingeniero de software, y tal vez otros). Si bien hay muchos lenguajes de modelado, notaciones, técnicas y herramientas en la literatura y en la práctica, hay que unifica conceptos generales que se aplican en alguna forma a todos ellos. Las siguientes secciones proporcionan antecedentes sobre estos conceptos generales. 1.1. Principios de modelado [1 *, C2S2, c5s1, c5s2] [2 *, C2S2] [3 *, c5s0] Modelado proporciona al ingeniero de software con un enfoque organizado y sistemático de los aspectos significativos tando sentantes de software en estudio, facilitando la toma de

decisiones sobre el software o elementos de la misma, y la comunicación de los

decisiones importantes a otros en las comunidades interesadas. Hay tres principios generales que guían este tipo de actividades de modelado: • Modelar los Fundamentos: Buenos modelos no suelen representan cada aspecto o característica del software bajo todas las condiciones posibles. Modelado por lo general implica el desarrollo de sólo aquellos aspectos o características del software que necesitan respuestas específicas, abstraerse de cualquier información no esencial. Este enfoque mantiene los modelos manejable y útil. • proporcionar Perspectiva: Modelado proporciona vistas del software bajo estudio utilizando un conjunto definido de normas para la expresión del modelo dentro de cada vista. Este enfoque perspectivaimpulsado proporciona dimensionalidad al modelo (por ejemplo, una vista estructural, vista del comportamiento, vista temporal, vista organizativa, y otros puntos de vista como relevante). La organización de la información en vistas centra los esfuerzos de modelado de software en concreto

Modelos de Ingeniería de Software y Métodos 93

9-4 Guía SWEBOK® V3.0

preocupaciones pertinentes a la vista mediante las apropiadas notación, el vocabulario, métodos y herramientas. • Permitir comunicaciones efectivas: Modelado emplea el dominio de aplicación del vocabulario del software, un lenguaje de modelado, y la expresión semántica (en otras palabras, tras tanto dentro del contexto ing). Cuando se utiliza de manera rigurosa y sistemática, esta modelado resultado en un enfoque de informes que facilita la comunicación eficaz de la información de software para interesados en el proyecto. Un modelo es una abstracción o simplificación de un componente de software. Una consecuencia del uso de la abstracción es que hay una única abstracción completa- mente describe un componente de software. Por el contrario, el modelo del software se representa como una agregación de abstracciones, que, cuando se toman juntos-describir aspectos seleccionados, perspectivas o puntos de vista, sólo aquellos que son necesarios para tomar decisiones informadas y responder a las razones de la creación de la modelo en el primer lugar. Esta simplificación conduce a un conjunto de supuestos sobre el contexto en el que se coloca el modelo que también deben ser capturado en el modelo. Entonces, al reutilizar el modelo, estos supuestos pueden ser validados primero en establecer la relevancia del modelo reutilizados dentro de su nuevo uso y el contexto. 1.2. Propiedades y Expresión de Modelos [1 *, c5s2, c5s3] [3 *, c4s1.1p7, c4s6p3, c5s0p3] Propiedades de los modelos son aquellos las distintas prestaciones distintivas de un modelo en particular utilizados para caracterizar su integridad, la consistencia y exactitud dentro de la notación de modelado elegido y utillaje utilizado. Propiedades de los modelos incluyen los siguientes: • Lo completo: El grado en que se han aplicado todos los requisitos y comprobada dentro del modelo. • Consistencia: El grado en que el modelo no contiene requisitos conflictivos, ciones

aseveraciones, restricciones, funciones o descripciones de componentes. • Exactitud: El grado en que el modelo satisface sus necesidades y cationes de diseño especificación y está libre de defectos.

Los modelos se construyen para representar objetos del mundo real y sus comportamientos para responder a preguntas específicas acerca de cómo se espera que el software para operar. Interrogar a los modelos, ya sea a través de la exploración, simulación, o revisión-puede exponer áreas de incertidumbre dentro del modelo y el software al que se refiere el modelo. Estas incertidumbres y preguntas sin respuesta sobre los requisitos, diseño y / o implementación pueden ser manejados de manera apropiada. El elemento de expresión primaria de un modelo es una entidad. Una entidad puede representar artefactos de hormigón (por ejemplo, procesadores, sensores, o robots) o artefactos abstractas (por ejemplo, módu- los de software o protocolos de comunicación). entidades modelo se conectan a otras entidades que utilizan rela- ciones (en otras palabras, líneas o los operadores textuales en las entidades de destino). Expresión de las entidades modelo se puede realizar usando textuales o gráficas lenguajes de modelado; Ambos tipos de lenguaje de modelado se conectan a través de entidades del modelo de construcciones del lenguaje específicos. El significado de una entidad puede ser representado por su forma, atributos de texto, o ambos. En general, la información textual se adhiere a la estructura sintáctica del idioma. Los significados Cise previas relacionadas con el modelado de contexto, estructura y comportamiento de uso de estas entidades y las relaciones depende del lenguaje de modelado utilizado, el rigor del diseño aplicado al esfuerzo de modelado, la vista específica está construyendo, y la entidad a la que el elemento notación específica puede estar unido. Múltiples vistas del modelo pueden ser necesarios para capturar la semántica necesarios del software. Al usar los modelos soportados con automatización ción, los modelos se pueden comprobará la integridad y consistencia. La utilidad de estas comprobaciones depende en gran medida del nivel de rigor táctica semántica y sin- aplicada al esfuerzo de modelado en adi- ción al soporte de herramientas explícita. La corrección es Tıpicamente comprobado a través de la simulación y / o revisión. 1.3. Sintaxis, la semántica y la pragmática [2 * c2s2.2.2p6] [3 *, c5s0]

Modelos de Ingeniería de Software y Métodos 95

Los modelos pueden ser sorprendentemente engañoso. El hecho de que un modelo es una abstracción con la falta de informa- ción puede conducir a uno en un falso sentido de completamente la comprensión del software de un solo modelo. Un modelo completo ( “completo” siendo

9-6 Guía SWEBOK® V3.0

en relación con el esfuerzo de modelado) puede haber una unión de varios submodelos y cualquiera de los modelos de función especiales. El examen y la relación tivo de toma de decisiones a un modelo único dentro de esta colección de submodelos pueden ser problemáticos. La comprensión de los significados precisos de constructos ELING MOD- también puede ser difícil. lenguajes de modelado se definen por reglas sintácticas y semánticas. Para lenguajes textuales, la sintaxis se define utilizando una gramática notación que define construcciones len- guaje válidos (por ejemplo, la Forma Backus-Naur (BNF)). Para lenguajes gráficos, la sintaxis se define usando modelos gráficos llamados els metamod-. Al igual que con BNF, metamodelos definen las construcciones sintácticas válidas de un lenguaje de modelado gráfico; metamodelo define cómo estos constructos se pueden componer para producir modelos válidos. La semántica de lenguajes de modelado especifican el significado que se atribuye a las entidades y relaciones capturados dentro del modelo. Por ejemplo, un diagrama simple de dos cajas conectadas por una línea está abierto a una variedad de interpretaciones. Sabiendo que el diagrama en el que se colocan las cajas y CONECTADOS es un diagrama de objeto o un diagrama de actividad puede ayudar en la interpretación de este modelo. Como cuestión práctica, por lo general hay un buen entendimiento de la semántica de un modelo de software específico debido al lenguaje de modelado elegido, cómo se utiliza ese lenguaje de modelado para expresar las entidades y las relaciones dentro de ese modelo, la base de la experiencia del modelador (s) y el contexto dentro del cual se ha llevado a cabo el modelado y representado. El significado se communicated a través del modelo incluso en presencia de información incompleta a través de abstracción; pragmática explica cómo el significado se materializa en el modelo y su contexto y comunicarse efectivamente a otros ingenieros de software. Todavía hay casos, sin embargo, donde se necesita cautela ción en relación con el modelado y la semántica. Por ejemplo, las piezas modelo importado de otro modelo o de la biblioteca deben ser examinados para supuestos semánticos que entran en conflicto en el nuevo

entorno de modelado; esto puede no ser obvia. El modelo debe ser revisado para supuestos documentados. Mientras que la sintaxis de modelado puede ser idéntico, el modelo puede significar algo muy diferente en el nuevo entorno, que es un contexto diferente. Además, consideran que como software madura y se realizan cambios, la discordia semántica

puede ser introducido, lo que conduce a errores. Con muchos ingenieros de software que trabajan en una parte del modelo con el tiempo junto con las actualizaciones de la herramienta y tal vez nuevas exigencias, hay oportunidades para partes del modelo para representar algo diferente de la intención del autor original y el contexto modelo inicial. 1.4. Condiciones previas, postConditions, e invariantes [2 *, c4s4] [4 *, c10s4p2, c10s5p2p4] Al modelar las funciones o métodos, el ingeniero de software suele comenzar con un conjunto de suposiciones sobre el estado del software antes de, durante y después de la función o método cutis eje-. Estos supuestos son esenciales para el funcionamiento rect angular de la función o método y se agrupan, para la discusión, como un conjunto de condiciones previas, postcondiciones, e invariantes. • Condiciones previas: Un conjunto de condiciones que deben ser satisfechas antes de la ejecución de la función o método. Si estas condiciones previas no se sostienen antes de la ejecución de la función o método, la función o método pueden producir resultados involuntaria de OU. • poscondiciones: Un conjunto de condiciones que se garantiza que sea cierto después de la función o método ha ejecutado con éxito. Por lo general, las condiciones posteriores representan cómo el estado del software ha cambiado, cómo pará- metros pasados a la función o método han cambiado, cómo los valores de datos han cambiado, o cómo se ha visto afectado el valor de retorno. • invariantes: Un conjunto de condiciones dentro del entorno operativo que persisten (en otras palabras, no cambie) antes y después de la ejecución de la función o método. Estas invariantes son pertinentes y necesarios para el software y el correcto funcionamiento de la función o método. 2. tipos Modelos de Un modelo típico consiste en una agregación de submodelos. Cada submodelo es una descripción parcial y se crea para un propósito

Ingeniería de Software y Métodos 9específico; queModelos puededeestar compuesta de uno o 7 más diagramas. La colección de submodelos puede emplear múltiples

9-8 Guía SWEBOK® V3.0

lenguajes de modelado o una sola modelado LANGUAGE. El Lenguaje de Modelado Unificado (UML) reconoce una rica colección de modelar dia- gramos. El uso de estos diagramas, junto con las construcciones del lenguaje de modelado, lleva cerca de tres tipos de modelos generales de uso común: los modelos de información, modelos de comportamiento, y los modelos de estructura (ver sección 1.1). 2.1. Modelado de información [1 *, c7s2.2] [3 *, c8s1] modelos de información proporcionan un foco central en datos e información. Un modelo de información es una representación abstracta que identifica y define un conjunto de conceptos, propiedades, relaciones y con- straints en entidades de datos. El modelo de información semántica o tual concepción se utiliza a menudo para proporcionar algo de formalismo y el contexto para el software que se modela como se ve desde la perspectiva problema, sin preocuparse de cómo este modelo es en realidad asignado a la implementación del software. El modelo de información semántica o conceptual es una abstracción y, como tal, incluye sólo los conceptos, propiedades, relaciones y restricciones necesarias para conceptualizar el punto de vista del mundo real de la información. transformaciones posteriores del modelo de información semántica o conceptual conducen a la elaboración de modelos de datos, entonces Physicians cal lógico y como se implementa en el software. 2.2. Modelado del comportamiento [1 *, c7s2.1, c7s2.3, c7s2.4] [2 *, c9s2] [3 *, c5s4] modelos de comportamiento identifican y definen las fun- ciones del software que está siendo modelado. Tamiento modelos ioral generalmente tomar tres formas básicas: máquinas de estado, los modelos de flujo de control, y Data- modelos de flujo. Las máquinas de estado proporcionan un modelo de software como una colección de estados definidos, eventos y transiciones. Las transiciones de software de un estado a otro por medio de un

evento de activación guardado o descuido que se produce en el entorno de modelado. modelos de flujo de control representan cómo una secuencia de acontecimientos provoca procesos para ser activado o desactivado. Los datos de flujo tamiento ior se tipifica como una secuencia de pasos donde los datos se mueve a través de procesos hacia almacenes de datos o sumideros de datos.

2.3. Modelado estructura [1 *, c7s2.5, c7s3.1, c7s3.2] [3 *, c5s3] [4 *, c4] modelos de estructura ilustran la composición física o lógica de software a partir de sus diversas partes compo- nente. modelado de estructuras establece el límite definido entre el software en ejecución o modelado y el entorno en el cual se va a operar. Algunas construcciones estructurales comunes utilizados en el modelado de la estructura son la composición, la descomposición, la generalización y especialización de entidades; identificación de las relaciones Evant rel- y cardinalidad entre entidades; y la definición de proceso o caras inter funcionales. diagramas de estructura proporcionados por el UML para el modelado de la estructura incluyen clases, componentes, objetos, despliegue y diagramas de embalaje. 3. Análisis de Modelos El desarrollo de modelos permite el ingeniero de software la oportunidad de estudiar, razonar sobre, y comprender la estructura, función, uso fun- cional, y las consideraciones de montaje se asocia a los programas. Es necesario un análisis de los modelos construidos para asegurar que estos modelos son completos, coherentes, y lo suficientemente correcta para servir a su propósito previsto para las partes interesadas. Las secciones siguientes describen brevemente las técnicas de análisis utilizadas generalmente con modelos de software para asegurarse de que el ingeniero de software y otras partes interesadas adquieren valor adecuado en el desarrollo y uso de modelos. 3.1. Para completar el análisis [3 *, c4s1.1p7, c4s6] [5 *, P811] Con el fin de tener un software que satisfaga plenamente las necesidades de los interesados, la integridad es crítico del proceso de obtención de requisitos para codificar mentación imple-. Integridad es el grado en el que todos los requisitos especificados han sido implementado y verificado. Los modelos pueden ser comprobados por la totalidad de una herramienta de modelado que utiliza técnicas tales como el análisis estructural y análisis de espacio de estado de accesibilidad (que aseguran que todos los caminos en los

de Ingeniería de Software y Métodos 9modelosModelos de estado se alcanzan por un conjunto 9 de entradas correctas); modelos también se pueden examinar para Ness COMPLETEmanualmente mediante inspecciones u otras técnicas de revisión (ver la calidad KA Software). errores

9-10

Guía SWEBOK® V3.0

y avisos generados por estas herramientas de análisis y demostrado en una inspección o revisión indican las acciones correctivas necesarias probables para garantizar la integridad de los modelos. 3.2. La consistencia para analizar [3 *, c4s1.1p7, c4s6] [5 *, P8-11] La consistencia es el grado en que los modelos con- tienen no hay requisitos en conflicto, afirmaciones, straints con-, funciones o descripciones de componentes. Típicamente, la comprobación de consistencia se logra con la herramienta de modelado utilizando una función de análisis automatizado; modelos también se pueden examinar para consistencia de forma manual mediante inspecciones u otras técnicas de revisión (ver la calidad KA Software). Al igual que con integridad, errores y avisos generados por estas herramientas de análisis y demostrado en una inspección o revisión indican la necesidad de una acción correctiva. 3.3. El análisis de la corrección [5 *, P8-11] La corrección es el grado en que un modelo satisfies sus requisitos de software y las especificaciones de diseño de software, está libre de defectos, y, en última instancia, cumple las necesidades de los interesados. El análisis de la corrección incluye la verificación de corrección sintáctica del modelo (es decir, el uso correcto de la gramática lenguaje de modelado y construcciones) y la verificación de la corrección semántica del modelo (es decir, el uso del lenguaje de modelado construye para representar correctamente el significado de que que está siendo modelado). Para analizar un modelo de corrección sintáctica y semántica, se analiza que, ya sea de forma automática (por ejemplo, usando la herramienta de modelado para comprobar modelo corrección sintáctica) o manualmente (mediante inspecciones u otras técnicas de revisión) -searching para posibles defectos y luego retirar o la reparación de los defectos confirmados antes de que el software está liberado para su uso. 3.4. trazabilidad [3 *, c4s7.1, c4s7.2]

El desarrollo de software normalmente implica el uso, creación y modificación de muchos productos de trabajo, tales como documentos de planificación, especificación ciones de proceso, requisitos de software, diagramas, diseños

y pseudo-código, código escrito a mano y generado herramienta, casos manuales y automatizados de prueba e informes, y archivos y datos. Estos productos de trabajo pueden estar relacionados a través de diferentes relaciones de dependencia (por ejemplo, usos, implementos, y las pruebas). A medida que se desarrolla el software, gestionar, mantener, o extendido, hay una necesidad de asignar y controlar estas relaciones de trazabilidad para demostrar los requisitos de software coherencia con el modelo de software (consulte Requisitos de seguimiento en los requisitos de software KA) y los muchos productos de trabajo. El uso de trazabilidad suele mejorar el manage- ment de productos de trabajo de software y software de calidad pro- ceso; sino que también proporciona garantías a los titulares de stakeque todos los requisitos se han cumplido. La trazabilidad permite cambiar el análisis una vez que el software es desarrollado y puesto en libertad, ya que las relaciones a los productos de trabajo de software fácilmente se pueden desplazar para evaluar el impacto del cambio. Las herramientas de modelado suelen proporcionar alguna automatizado o manual de los medios para espec- ify y gestionar enlaces de trazabilidad entre los requisitos, diseño, código y / o entidades de prueba que puedan ser representados en los modelos y otros productos de trabajo de software. (Para obtener más información sobre la trazabilidad, ver el KA Software Configuration Management). 3.5. Análisis de interacción [2 *, c10, c11] [3 *, c29s1.1, c29s5] [4 *, c5] Interacción análisis se centra en las relaciones de las comunicaciones o de control de flujo entre entidades utilizadas para llevar a cabo una tarea o función específica dentro del modelo de software. Este análisis plos ines el comportamiento dinámico de las interacciones entre las diferentes porciones del modelo de software, incluyendo otras capas de software (tal como el sistema oper- ating, middleware, y aplicaciones). También puede ser importante para algunas aplicaciones de software para examinar las interacciones entre la aplicación de software orde- nador y el software de interfaz de usuario. Algunos entornos de modelado de software proporcionan instalaciones de simulación para estudiar aspectos del comportamiento dinámico de software de modelado. de ping paso- a través de la simulación proporciona una opción de

de Ingeniería Software ypara Métodos 9análisis para Modelos el ingeniero de de software 11 revisar el diseño de interacción y verificar que las diferentes partes de la obra de software juntos para proporcionar las funciones previstas.

9-12

Guía SWEBOK® V3.0

4. Métodos de ingeniería de software Software métodos de ingeniería proporcionan un enfoque sistemático y nizado or- al desarrollo de soft- ware para un equipo de destino. Existen numerosos métodos entre los que elegir, y es importante para el ingeniero de software para elegir un método o métodos para la tarea de desarrollo de software a la mano apropiada; esta elección puede tener un efecto dramático en el éxito del proyecto de software. El uso de estos métodos de ingeniería de software, junto con la gente de la derecha conjunto de habilidades y herramientas permiten a los ingenieros de software para visualizar los detalles del software y, finalmente, transformar la representación en un conjunto de trabajo de código y datos. métodos de ingeniería de software seleccionados se dis- cussed a continuación. Las áreas temáticas se organizan en las discusiones de los métodos heurísticos, Métodos formales, métodos de prototipos, y los métodos ágiles. 4.1. Los métodos heurísticos [1 *, c13, c15, c16] [3 *, c2s2.2, c5s4.1, c7s1,] Los métodos heurísticos son aquellos métodos de ingeniería de software basados en la experiencia que han sido y son bastante ampliamente practicados en el software industria. Esta área temática contiene tres grandes categorías: Discusión del análisis estructurado y métodos de diseño, métodos de modelado de datos y métodos de análisis y diseño orientados a objetos. • Análisis estructurado y métodos de diseño: El modelo de software se desarrolla principalmente a partir de un punto de vista funcional o conductual, a partir de una vista de alto nivel del software (incluyendo elementos de datos y de control) y luego descomponiendo progresivamente o refining los componentes del modelo a través de increas- diseños vez más detalladas . El diseño detallado finalmente converge a los detalles o especificaciones del software que deben codificarse muy específicos (con la mano, generado automáticamente, o ambos), construido, probado y verificado. • Los métodos de modelado de datos: El

modelo de datos se construye desde el punto de vista de los datos o informaciones utilizados. Las tablas de datos y barcos PARENTESCO definen los modelos de datos. Este método mo- datos eling se utiliza principalmente para definir y analizar las necesidades de datos de apoyo

diseños de bases de datos o datos de repositorios Tıpicamente encuentran en software de negocios, donde los datos se gestiona activamente como un recurso sistemas de negocio o activo. • ods Análisis y Diseño Orientado a Objetos met-: El modelo orientado a objetos se representa como una colección de objetos que encapsulan datos y las relaciones e interactuar con otros objetos a través de métodos. Los objetos pueden ser objetos del mundo real o elementos virtuales. El modelo de software se construye utilizando diagramas para constituir vistas seleccionadas del software. refinamiento progresivo del software mode- los conduce a un diseño detallado. El diseño detallado se luego se convirtió bien a través de iteración sucesiva o transformada (utilizando algún mecanismo) en la vista de la implementación del modelo, donde el código y Envoltorios enfoque para el lanzamiento eventual producto de software y el despliegue ing se expresa. 4.2. Métodos formales [1 *, c18] [3 *, c27] [5 *, p824] Los métodos formales son los métodos de ingeniería de software utilizadas para especificar, desarrollar y verificar el software mediante la aplicación de un riguroso notación y lenguaje basado camente mathemat-. A través del uso de un lenguaje de especificación, el modelo de software se puede comprobar la consistencia (en otras palabras, la falta de ambigüedad), integridad, y la corrección de forma sistemática y automatizada o la moda semi-automatizado. Este tema está relacionado con la sección de análi- sis formal de los requisitos de software KA. Esta sección se ocupa de los lenguajes de especificación, el refinamiento de programas y de derivación, cationes verificables formal, y la inferencia lógica. • especificación de Idiomas: Lenguajes de especificación proporcionan la base matemática de un método formal; lenguajes de especificación son formales, los lenguajes de programación de alto nivel (en otras palabras, no es un lenguaje clásico de tercera generación (3GL) programa- lenguaje ming) utilizado durante la especificación de software,

Modelos Ingeniería de Software 9análisis dederequerimientos, y / oy Métodos etapas de 13 diseño específico para describir la entrada / salida comportamiento. lenguajes de especificación son idiomas no directamente ejecutables; son

9-14

Guía SWEBOK® V3.0

típicamente compuesto de una notación y sintaxis, la semántica para el uso de la notación, y un conjunto de relaciones permitidos para objetos. • Programa de Perfeccionamiento y Derivación: Pro- gram refinamiento es el proceso de creación de un nivel más bajo (o más detallada) especificación utilizando una serie de transformaciones. Es a través de sucesivas transformaciones que el ingeniero de software se deriva una representación ejecutable de un programa. Las especificaciones pueden ser refinados, añadiendo detalles hasta que el modelo se puede formu- lated en un lenguaje de programación 3GL o en una parte ejecutable de la lengua especifica- ción elegida. Este refinamiento especificación se hace posible mediante la definición de las especificaciones con propiedades semánticas precisas; las especificaciones deben establecer no sólo las relaciones entre las entidades, sino también los significados de tiempo de ejecución exactos de esas relaciones y operaciones. • La verificación formal: Modelo de cheques es un método de verificación formal; que por lo general implica la realización de análisis ción o de alcanzabilidad un exploratorios espacio de estado para demostrar que el diseño de software representado tiene o conserva ciertas propiedades modelo de inter- est. Un ejemplo de comprobación de modelo es un análisis que verifica programa correcto comporta- ior bajo posible entrelazado de eventos o mensajes llegados. El uso de cationes verificables formales requiere un modelo determinado de forma rigurosa el software y en su entorno operativo; este modelo a menudo toma la forma de una máquina de estados finitos u otro autómata formalmente definido. • La inferencia lógica: La inferencia lógica es un método de diseño de software que implica especificar las condiciones previas y condiciones posteriores alrededor de cada bloque importante del diseño, y el uso de la lógica del desarrollo de la prueba de que las condiciones previas y condiciones posteriores deben tener en todas las entradas matemática. Esto proporciona una manera para que el ingeniero de software para

predecir el comportamiento del software sin tener que ejecutar el software. Algunos entornos de desarrollo integrado (IDE) incluyen formas de representar estas pruebas junto con el diseño o código.

4.3. Los métodos de prototipado [1 *, c12s2] [3 *, c2s3.1] [6 *, c7s3p5] creación de prototipos de software es una actividad que generalmente crea siones verincompletas o mínimamente funcionales de una aplicación de software, por lo general para prueba- ing nuevas características, solicitando información sobre los requisitos de software o interfaces de usuario, fur- Ther explorar requisitos de software, diseño de software, o opciones de implementación, y / o la obtención de alguna otra información útil sobre el software. El ingeniero de software selecciona un método de creación de prototipos para entender el menos aspectos o compo- nentes del software primero entiende; este enfoque es en contraste con otros métodos de ingeniería de software que normalmente comienzan desarrollo con las porciones más entendidos primeros. Típicamente, el producto protomecanografiada no se convierta en el producto de software final sin extensa retrabajo desarrollo o la refactorización. En esta sección se analiza estilos de creación de prototipos, Tar recibe, y técnicas de evaluación en breve. • Estilo de prototipos: Esto se refiere a los diversos enfoques para desarrollar prototipos. prototipos pueden desarrollarse como código o productos de papel de usar y tirar, como una evolución de un diseño traba- jando, o como una especificación ejecutable. Diferentes procesos del ciclo de vida de prototipos se utilizan normalmente para cada estilo. El estilo CHO-sen se basa en el tipo de resultados que necesita el proyecto, la calidad de los resultados es necesario, y la urgencia de los resultados. • Objetivo de prototipos: El objetivo de la actividad proto- tipo es el producto específico que se está servido por el esfuerzo de creación de prototipos. Los ejemplos de objetivos de creación de prototipos incluyen una especificación de requisitos, un elemento de diseño arquitectónico o componente, un algoritmo, o una interfaz de usuario hombre-máquina. • Técnicas de Evaluación de prototipos: Un proto- tipo puede ser usado o evaluado en un nú- mero de maneras por el ingeniero de software u otros

Modelos de Software y Métodos 9interesados en deelIngeniería proyecto, impulsado 15 principalmente por las razones subyacentes que llevaron a promover el desarrollo del totipo en el primer lugar. totypes Propueden ser evaluados o probados contra el software implementado real o contra

9-16

Guía SWEBOK® V3.0

un objetivo conjunto de requisitos (por ejemplo, un prototipo requisitos); el prototipo también puede servir como modelo para un futuro esfuerzo de desarrollo de software (por ejemplo, como en una especificación de interfaz de usuario). 4.4. Los métodos ágiles [3 *, c3] [6 *, c7s3p7] [7 *, c6, App. UN] Los métodos ágiles nacieron en la década de 1990 a partir de la necesidad de reducir la gran sobrecarga aparente asocia- dos con el peso pesado, los métodos basados en planes utilizados en los proyectos de desarrollo de software a gran escala. Los métodos ágiles son considerados métodos ligeros en cuanto a que se caracterizan por ciclos cortos, iteraciones de desarrollo tiva, equipos auto-organizados, los diseños más simples, la refactorización de código, desarrollo basado en pruebas, la participación de cliente frecuente, y un énfasis en la creación de un trabajo demostrable producto con cada ciclo de desarrollo. Muchos métodos ágiles están disponibles en la lit- eratura; algunos de los enfoques más populares, que se discuten aquí en breve, incluyen desarrollo rápido de aplicaciones (RAD), eXtreme Pro- gramación (XP), Scrum, y el desarrollo de funciones-Driven (FDD). • RAD: métodos rápidos de desarrollo de software se utilizan principalmente en el desarrollo de aplicaciones sistemas de negocios-intensivo de datos. El método RAD está habilitado con fines especiales herramientas de desarrollo Base de datos se utilizan los ingenieros de software para desarrollar rápidamente, probar e implementar aplicaciones nuevas o modificadas de negocio. • XP: Este método utiliza historias o escenarios para las necesidades, desarrolla pruebas en primer lugar, tiene implicación directa con el cliente en el equipo (por lo general la definición de las pruebas de aceptación), utiliza la programación en parejas, y prevé continua- refactorización código ous e integración. Historias se descomponen en tareas, priorizado, estimación aparearon, desarrollados, y se

ensayaron. Cada ment incre- de software se prueba con pruebas automatizados y manuales; un incremento puede ser liberado con frecuencia, como cada dos semanas más o menos.

• MeléEste enfoque ágil gestión es más amigable que los otros proyectos. El scrum master gestiona las actividades dentro del proyecto de la subasta; cada incremento se llama una carrera de velocidad y no dura más de 30 días. Se desarrolla una lista de reserva de pedidos de productos de artículos (PBI) a partir del cual se identifican las tareas, definidas, prioridad, y estima. Una versión traba- jando del software ha sido probado y puesto en libertad en cada incremento. Las reuniones diarias de scrum asegurar el trabajo se logró planificar. • FDD: Este es un enfoque basado en modelos, corto, iterativo de desarrollo de software tivo usando un proceso de cinco fases: (1) el desarrollo de un modelo de producto a alcance la amplitud del dominio, (2) crear la lista de necesidades o características, (3 ) construir el plan de desarrollo de funciones, (4) el desarrollo de diseños para funciones de iteración específica, y (5) de código, prueba, y luego integrar las funciones. FDD es similar a un enfoque incremental de desarrollo de software; También es similar a XP, excepto que la propiedad del código es asignado a individuos más que el equipo. FDD hace hincapié en un enfoque de arquitectura global para el software, que promueve la creación de la función correctamente la primera vez en lugar de enfatizar refactorización continua. Hay muchas más variaciones de ods met ágiles en la literatura y en la práctica. Tenga en cuenta que siempre habrá un lugar para los pesos pesados, métodos de ingeniería de software basados en plan, así como los lugares donde brillan los métodos ágiles. Hay nuevos métodos derivados de combinaciones de los métodos ágiles y basadas en el plan donde los practicantes están definiendo nuevos métodos que equilibren las características necesarias en ambos métodos de peso pesado y ligero basado principalmente en las necesidades de negocio que prevalece zational nizaciones. Estas necesidades de negocio, ya que por lo general representado por algunos de los interesados en el proyecto, deben y no conducir la elección en el uso de método de ingeniería de software una sobre otra o en la construcción de un nuevo método de las mejores características de una combinación de métodos de ingeniería de

Modelos de Ingeniería de Software y Métodos 9software. 17

9-18

Guía SWEBOK® V3.0

1. Modelado 1.1. Modelado principios 1.2. Propiedades y Expresión de Modelos

C2S 2, c5s1 , c5s2, c5s2 c5s3

1.3. Sintaxis, la semántica y la pragmática

c2s2.2.2 P6

1.4. Condiciones previas, postConditions, e 2. invariantes Tipos de Modelos 2.1. Modelado de información 2.2. conductual Modelado 2.3. Estructura Modelado

c4s1.1p7, c4s6p3, c5s0p3

c10s4p2, c10s5 p2p4

c4s4

c7s2.2 c7s2.1, c7s2.3, c7s2.4 c7s2.5, c7s3.1, c7s3.2

c8s1 c9s2

c5s4

c5s3

3. Análisis de Modelos 3.1. Para completar el análisis 3.2. La consistencia para analizar 3.3. El análisis de la corrección

c4

c4s1.1p7, c4s6

pp8-11

c4s1.1p7, c4s6

pp8-11 pp8-11

c4s7.1, c4s7.2

3.4. trazabilidad 3.5. Interacción Análisis

c5s0

c10, c11

c29s1.1, c29s5

c5

BoEHM y Turner 2003 [7 *]

Brookshear 2008 [6 *]

c5s0

Ala 1990 [5 *]

SommervilLe 2011 [3 *]

C2S2

Página-Jones 1999 [4 *]

Mellor y Balcer 2002 [2 *]

Budgen 2003 [1 *]

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

4. Métodos de ingeniería de software 4.1. Los métodos heurísticos 4.2. Métodos formales 4.3. prototipado métodos 4.4. Los métodos ágiles

c13, c15, c16

c2s2.2, c7s1, c5s4.1

c18

c27

c12s2

c2s3.1

c7s3p5

c3

c7s3p7

BoEHM y Turner 2003 [7 *]

Brookshear 2008 [6 *]

Ala 1990 [5 *]

Página-Jones 1999 [4 *]

SommervilLe 2011 [3 *]

Mellor y Balcer 2002 [2 *]

Budgen 2003 [1 *]

Modelos de Ingeniería de Software y Métodos 911

pp8-24

c6, app. UN

9-12

Guía SWEBOK® V3.0

Referencias [1 *] D. Budgen, Diseño de software, 2ª ed., Addison-Wesley, 2003. [2 *] SJ Mellor y MJ Balcer, ejecutable UML:. Una Fundación para el Model-Driven Architecture, 1st ed, Addison-Wesley, 2002. [3 *] I. Sommerville, Ingeniería de Software, 9ª ed., Addison-Wesley, 2011. [4 *] M. Página-Jones, Fundamentos del Diseño orientado a objetos en UML, 1st ed., Addison-Wesley, 1999.

[5 *] JM Wing, “Introducción de un especificador de métodos formales,” Computer, vol. 23, no. 9, 1990, pp. 8, 10-23. [6 *] JG Brookshear, Ciencias de la Computación:. Una visión general, 10ª ed, Addison-Wesley, 2008. [7 *] B. Boehm y R. Turner, Equilibrio de la agilidad y disciplina: una guía para los perplejos, Addison-Wesley, 2003.

Modelos de Ingeniería de Software y Métodos 913

CAPÍTULO 10 CALIDAD DEL SOFTWARE SIGLAS CMMI

Capability Maturity Model Integration

cosq

Costo de la Calidad del Software

COTS

Commercial Off-The-Shelf Software

FMEA TLC PDCA

Modo de Fallos y Análisis de Efectos Análisis del árbol de fallos Planificar-Hacer-Verificar-Actuar

PDSA

Plan-Do-Study-Act

QFD SPI

Despliegue de la función de calidad Mejora de Procesos de Software

SQA SQC

Calidad de Software Control de Calidad de Software

SQM TQM

Gestión de la calidad del software Total Quality Management

V&V

Verificación y validación

INTRODUCCIÓN ¿Cuál es la calidad del software, y por qué es tan impor- tante que se incluye en muchas áreas de conocimiento (KAS) de la guía SWEBOK? Una de las razones es que la calidad del software término está sobrecargado. La calidad del software puede referirse: a deseable características capaces de productos de software, en la medida en que un determinado posiproducto de software sess esas características, y para procesos, herramientas y técnicas utilizadas para lograr esas características. Con los años, los autores y organizaciones han definido el término calidad diferente. Para Phil Crosby, que era “la conformidad con los requisitos” [1]. Watts Humphrey refiere a él como “lograr excelentes niveles de‘aptitud para el uso’[2]. Entre tanto, IBM acuñó la frase “impulsada por el mercado

calidad “, donde el‘cliente es el árbitro final’[3 *, P8]. Más recientemente, la calidad del software se define como la “capacidad de producto de software para satisfacer necesidades expresadas o implícitas, en condiciones especiales” requisitos [4] y como “el grado en que un producto de software cumple creada; Sin embargo, la calidad depende del grado en que esos requisitos cado blecimientos representan con exactitud las necesidades de los interesados, deseos y expectativas”[5]. Ambas definiciones abrazan la premisa de conformidad con los requisitos. Ni se refiere a tipos de los requisitos (por ejemplo, funcional, fiabilidad, rendimiento, fiabilidad, o cualquier otra característica). Significativamente, sin embargo, estas definiciones hacen hincapié en que la calidad depende de los requisitos. Estas definiciones se ilustran también otra razón de la prevalencia de la calidad del software largo de esta guía: una ambigüedad frecuente de la calidad del software frente a los requisitos de calidad de software ( “los -ilities” es una abreviatura común). los requisitos de calidad de software son en realidad los atributos de (o limitaciones) sobre los requisitos funcionales (lo que hace el sistema). Requisitos de software también pueden especificar el uso de recursos, un protocolo de comunicación, o muchas otras características. Esta KA intenta claridad mediante el uso de la calidad del software en el sentido más amplio de las definiciones anteriores y mediante el uso de los requisitos de calidad de software como con- straints sobre los requisitos funcionales. La calidad del software se logra mediante la conformidad con todos los requisitos, independientemente de lo que es característico manera especificada o cómo se agrupan o se nombra requisitos. La calidad del software también se considera en muchos de los SWEBOK KAs porque es un eter param básica de un esfuerzo de ingeniería

de software. Para todos los productos neered nieros, el objetivo principal es ofrecer un valor máximo de las partes interesadas, mientras que

el equilibrio de las limitaciones de costo y cronograma de desarrollo; esto a veces se caracteriza como “aptitud para 10-1

10-2

Guía SWEBOK® V3.0

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

utilizar.”valor de los grupos de interés se expresa en los requisitos. Para productos de software, los interesados podrían valorar el precio (lo que pagan por el producto), tiempo de espera (la rapidez con que reciben el producto), y la calidad del software. Esta KA aborda las definiciones y proporciona una visión general de las prácticas, herramientas y técnicas para la definición de la calidad del software y para valorar el estado de la calidad del software durante el desarrollo, mantenimiento y despliegue. Las referencias citadas proporcionan detalles adicionales. DISTRIBUCIÓN DE TEMAS PARA LA CALIDAD DEL SOFTWARE El desglose de los temas para la Calidad del Software KA se presenta en la figura 10.1. 1. Fundamentos de la calidad del software Llegar a un acuerdo sobre lo que constituye la calidad de todos los grupos de interés y la comunicación clara de ese acuerdo a los

ingenieros de software que requieren

los muchos aspectos de la calidad se definen formalmente y discutido. Un ingeniero de software debe entender los conceptos cali- dad, las características, valores y su aplicación al software bajo desarrollo o mantenimiento. El concepto importante es que los requisitos de software definen los atributos de calidad requeridos del software. Requisitos de software influyen en los métodos de medición y los criterios de acep- tación para evaluar el grado en que el software y la documentación relacionada a alcanzar los niveles de calidad deseados. 1.1. Software de Ingeniería de la Cultura y Ética [3 *, c1s4] [6 *, c2s3.5] Software Se espera que los ingenieros compartir un compromiso para la calidad del software como parte de su cultura. Una cultura de ingeniería de software saludable incluye muchas características, incluyendo el entendimiento de que los equilibrios entre costes, plazos y calidad son un principio básico de la ingeniería de cualquier pro- ducto. Una ética fuerte de ingeniería de software asume

Calidad de Software 103

10-4

Guía SWEBOK® V3.0

que los ingenieros informan con precisión la información, con- diciones, y los resultados relacionados con la calidad. La ética también juegan un papel importante en la calidad del software, la cultura, y las actitudes de los ingenieros de software. El IEEE Computer Society y la ACM han desarrollado un código de ética y la práctica pro- fesional (ver Códigos de Ética y Conducta Profesional de la Ingeniería de Software KA Práctica Profesional).

software producto al cliente. costos ure Fail externos incluyen actividades para responder a problemas de software descubiertas después de la entrega al cliente. Los ingenieros de software deben ser capaces de utilizar métodos cosq para determinar los niveles de calidad del software y también deben ser capaces de presentar alternativas de calidad y sus costos para que las compensaciones entre costo, horario, y la entrega de valor para los accionistas Puede ser hecho.

1.2. Valor y los costos de Calidad

1.3. Modelos y características de calidad [3 *, c24s1] [7 *, c2s4] [8 *, c17]

[7 *, c17, c22]

Definir y luego la consecución de la calidad del software no es simple. Las características de calidad pueden o pueden no ser necesarios, o se les puede pedir a un mayor o menor grado, y las compensaciones se pueden hacer entre ellos. Para ayudar a determinar el nivel de calidad del software, es decir, el logro de valor para los accionistas, esta sección presenta coste de la calidad del software (cosq): un conjunto de medidas derivadas de la evaluación económica de los procesos de desarrollo y mantenimiento de software de calidad. Las mediciones cosq son ejemplos de mediciones de proceso que pueden utilizarse para inferir carac- terísticas de un producto. La premisa subyacente a la cosq es que el nivel de calidad en un producto de software se puede deducir de los costes de las actividades relacionadas con la oferta- ing con las consecuencias de la mala calidad. La mala calidad significa que el producto de software no totalmente “satisfacer necesidades expresadas o implícitas” o Hay cuatro categorías de calidad coste de “estable- ció requisitos.”: prevención, evaluación, fallo interno y externo fracaso. Prevención costos incluyen las inversiones en los esfuerzos de mejora de procesos de software, infra- estructura de calidad, herramientas de calidad, formación, auditorías y revisiones Ment manage-. Estos costos son por lo general no es específico de un proyecto; que abarcan la organización. surgen los costos de evaluación de las actividades del proyecto que encuentran defectos. Estas actividades de evaluación se pueden clasificar en los costos de los exámenes (diseño, pares) y los costos de las pruebas (pruebas software de la unidad, de integración

de software, pruebas de nivel de sistema, pruebas de aceptación); los costos de evaluación se extenderían a los proveedores de software subcontratados. Los costos de fallos internos son los que se incurre para fijar defectos encontrados durante las actividades de evaluación y descubrió antes de la entrega de la

Terminología para características de calidad de software difiere de una taxonomía (o modelo de la calidad del software) a otro, cada modelo tal vez tener un número diferente de niveles jerárquicos y un número total diferente de características. Varios autores han producido modelos de características de calidad de software o atributos que pueden ser útiles para la discusión, la planificación, y la calificación de la calidad de los productos de software. ISO / IEC 25010: 2011 [4] define la calidad del producto y la calidad en uso como dos modelos de calidad relacionados. Apéndice B de la Guía de SWE- BOK proporciona una lista de las normas aplicables para cada KA. Normas de este KA cubren diversas formas de caracterizar la calidad del software. 1.3.1. Calidad de Procesos de Software gestión de la calidad del software y la calidad de los procesos niería de software niería tienen una influencia directa en la calidad del producto de software. Modelos y criterios que evalúan los lazos capabili- de organizaciones de software son principalmente pro- yecto organización y consideraciones de gestión y, como tales, están cubiertos en el Proceso de Gestión de Ingeniería de Software e Ingeniería de Software de Kas. No es posible distinguir por completo la calidad del proceso de la calidad del producto debido a los resultados del proceso incluyen productos. La determinación de si un proceso tiene la capacidad de productos Duce consistentemente pro de la calidad deseada no es simple. El proceso de ingeniería de software, discutido en el proceso de ingeniería de software KA, las influencias de las características de calidad de software productos, que a su vez afectan a la calidad percibida por los interesados.

Calidad de Software 105

10-6

Guía SWEBOK® V3.0

1.3.2. Calidad del producto de software El ingeniero de software, en primer lugar, debe determinar el verdadero propósito del software. En este sentido, requisitos de los interesados son de suma importancia, y que incluyen los requisitos de calidad, además de los requisitos fun- cionales. Por lo tanto, los ingenieros de software tienen la responsabilidad de obtener los requisitos de calidad que pueden no ser explícita al principio y al Deben conocerse su importancia, así como el nivel de difi- cultad en el logro de ellos. Todos los procesos de desarrollo de software (por ejemplo, la obtención de requisitos, diseño, construcción, construcción, control, mejora de la calidad) están diseñados con estos requisitos de calidad en la mente y puede llevar a los costes de desarrollo adicionales si los atributos tales como la seguridad, la seguridad y la fiabilidad son importantes. Los costos de desa- rrollo adicionales ayudan a asegurar que la calidad obtenida puede canjearse por los beneficios anticipados. El término producto de trabajo significa cualquier artefacto que es el resultado de un proceso utilizado para crear el producto de software final. Ejemplos de un UCT trabajo PRODUCIRSE incluyen una especificación de sistema / subsistema, una especificación de requisitos de software para un componente de software de un sistema, una descripción de diseño de software, código fuente, prueba de software documen- tación, o informes. Aunque se describen algunos tratamientos de calidad en términos de rendimiento del software y el sistema final, buenas prácticas de ingeniería requiere que se evalúen productos de trabajo intermedios correspondientes a la calidad durante todo el proceso de ingeniería de software. 1.4. Mejora de la Calidad de Software [3 *, c1s4] [9 *, c24] [10 *, c11s2.4] La calidad de los productos de software se puede mejorar a través de procesos preventivas o un proceso iterativo tiva de la mejora continua, que requiere control de la gestión, coordinación, y la retroalimentación de muchos procesos concurrentes: (1) los procesos del ciclo de vida del software, (2) el proceso de detección de

fallos / defecto, la eliminación, y pre- vención, y (3) el proceso de mejora de la calidad. La teoría y los conceptos detrás de la mejora de la calidad, tales como la construcción de la calidad a través de la detección temprana y la prevención de defectos, la mejora continua de las partes interesadas, y enfoque son pertinentes para la ingeniería de software. Estos conceptos se basan en el trabajo de los expertos

en la calidad que han declarado que la calidad de un producto está directamente relacionada con la calidad del proceso utilizado para crearlo. Enfoques como el ciclo de mejora de Deming de Ley del Plan-Do-Fecha entrada (PDCA), entrega evolutivo, kaizen, y el despliegue de la función de calidad (QFD) ofrecen técnicas para especificar los objetivos de calidad y determinar si se cumplen. El ideal del Instituto de Ingeniería de Software es otro método [7 *]. gestión de cali- dad ahora es reconocido por la Guía SWE- BOK como una disciplina importante. patrocinio de gestión de procesos y productos apoya las evaluaciones y las conclusiones resultantes. A continuación, un programa de mejora se desarrolla la identificación de acciones detalladas y proyectos de mejora que deben abordarse en un plazo de tiempo posible. apoyo a la gestión implica que cada proyecto mejoría tiene suficientes recursos para lograr el objetivo definido para ello. patrocinio de gestión se solicita con frecuencia mediante la implementación de actividades de comunicación proactivas. 1.5. software de Seguridad [9 *, c11s3] sistemas de seguridad críticos son aquellos en los que un fallo de sis- tema podría dañar la vida humana, los demás seres vivos, las estructuras físicas, o el medio ambiente. El software en estos sistemas es crítico para la seguridad. Hay un número creciente de aplicaciones de software crítico en un número creciente de industrias. Ejemplos de sistemas con software crítico seguridad- incluyen sistemas de transporte masivo, plantas de fabricación de productos químicos, y dispositivos médicos. El fracaso de software en estos sistemas podría tener efectos catastróficos. Existen normas indus- tria, como DO-178C [11], y emerg- procesos ing, herramientas y técnicas para el Desa- software safetycritical ing. La intención de estas normas, instrumentos y técnicas es reducir el riesgo de defectos de inyección en el software y por lo tanto mejorar la fiabilidad del software. software crítico puede ser categorizado como directo o indirecto. Directa es que el software embed- ded en un sistema crítico para la seguridad, como por ejemplo el ordenador de control de vuelo de una aeronave. Indirecta incluye aplicaciones de software utilizadas

de Software 10para desarrollar software críticoCalidad seguridad-. 7 software indirecta se incluye en entornos de ingeniería de software y entornos de prueba de software.

10-8

Guía SWEBOK® V3.0

Tres técnicas complementarias para reducción ing el riesgo de fallo son la evitación, detección y eliminación, y la limitación del daño. Estos software técnicas impacto requisitos funcionales, requisitos de rendimiento del software y los procesos de desarrollo. El aumento de los niveles de riesgo implican el aumento de los niveles de calidad del software assur- técnicas ANCE y control tales como las inspecciones. Los niveles más altos de riesgo pueden requerir una revisión más detallada de los requisitos, el diseño y el código o el uso de técnicas analíticas más formales. Otra técnica para la gestión de riesgos y control- software Ling es la construcción de casos de aseguramiento. Un caso de aseguramiento es un artefacto razonada, auditable creado para apoyar la afirmación de que su demanda o demandas son satisfechas. Contiene las siguientes acciones y sus relaciones: una o más afirmaciones sobre propiedades; argumentos que enlazan lógicamente parte, las pruebas y las posibles hipótesis a las reclamaciones; y un conjunto de pruebas y los supuestos que apoyan estos argumentos [12]. 2. Procesos de software de gestión de calidad gestión de la calidad del software es el conjunto de todos los procesos que garanticen que los productos de software, servicios y la implementación de procesos de ciclo de vida cumplen los objetivos de calidad de software de organización y lograr la satisfacción de las partes interesadas [13, 14]. SQM define los procesos, los dueños del proceso, los requisitos para los procesos, mediciones de los procesos y sus salidas y retroalimentación Nels Chan durante todo el ciclo de vida del software. SQM comprende cuatro subcategorías: software de planificación de la calidad, aseguramiento de la calidad del software (SQA), control de la calidad del software (SQC), y la mejora de procesos de software (SPI). la planificación de la calidad del software incluye la determinación de cuáles estándares de calidad se van a utilizar, la definición de objetivos de calidad específicos, y estimar el esfuerzo y el calendario de actividades de calidad de software. En algunos casos, la planificación de la calidad del software también incluye la definición de los procesos de calidad de software para ser

utilizados. dades SQA activi- definir y evaluar la adecuación de los procesos de software para proporcionar evidencia que establezca la confianza de que los procesos de software son consignados para piado y producir productos de software de calidad traje- poder para los fines previstos [5]. actividades SQC examinan artefactos específicos del proyecto (docu- mentos y ejecutables) para determinar si

cumplir con las normas establecidas para el proyecto (incluyendo los requisitos, limitaciones, diseños, contratos y planes). SQC evalúa inter- medio productos, así como los productos finales. La cuarta categoría SQM se trata de la mejora tiene varios nombres en el software indus- tria, incluyendo SPI, la mejora de la calidad del software y el software de acciones correctivas y preventivas. Las actividades en esta categoría buscan mejorar la eficacia del proceso, la eficiencia, y otras carac- terísticas con el objetivo último de mejorar la calidad del software. Aunque SPI podría incluirse en cualquiera de las tres primeras categorías, un número creciente de organizaciones de organizar SPI en una cate- goría separada que puede extenderse a través de muchos proyectos (ver el Proceso de Ingeniería de Software KA). los procesos de calidad de software consisten en tareas y técnicas para indicar cómo se están implementando planes de software (por ejemplo, gestión de software, desarrollo, gestión de la calidad, o los planes de gestión de configuración) y qué tan bien los productos intermedios y finales están cumpliendo con sus requisitos especificados. Los resultados de estas tareas se montan en los informes de gestión antes de que se tomen medidas correctivas. La gestión de un proceso de SQM tiene la tarea de garantizar que los resultados de estos informes son exactos. La gestión del riesgo también puede jugar un papel importante en la entrega de software de calidad. La incorporación de análisis de riesgos y la gestión gías nicas disciplinados en los procesos del ciclo de vida del software puede ayudar a mejorar la calidad del producto (véase la Ingeniería de Software de Gestión de KA para mate- rial relacionado en la gestión de riesgos). 2.1. Calidad de Software [7 *, C4-C6, c11, c12, c2627] Para sofocar un malentendido generalizado, chorro suave de garantía de calidad cerámica no está probando. aseguramiento de la calidad del software (SQA) es un conjunto de actividades que definen y evaluar la adecuación de los procesos de software para proporcionar evidencia que establece confianza que los procesos de software son apropiados y producen productos de software de calidad adecuada para sus fines previstos. Un atributo clave de SQA es la objetividad de

Calidad de Software La 10la función SQA con respecto al proyecto. 9 función SQA también puede ser organizativamente independiente de la proyecect; es decir, libre de técnica, de gestión y

10-10 Guía SWEBOK® V3.0

las presiones financieras del proyecto [5]. SQA tiene dos aspectos: de garantía de producto y de garantía de proceso, que se explican en la sección 2.3. El plan de la calidad del software (en algunos sectores de la industria que se denomina el plan de software de aseguramiento de la calidad) define las actividades y tareas empleadas para garantizar que el software desarrollado para un producto específico satisface mentos del proyecto establecidos requisitos y necesidades de los usuarios dentro de los costos del proyecto y las restricciones del cronograma y es proporcional a los riesgos del proyecto. El PACS asegura primero que los objetivos de calidad están claramente definidos y entendidos. actividades y tareas de calidad del plan SQA se especifican con sus costos, necesidades de recursos, objetivos y calendario en relación con los objetivos relacionados con la ingeniería de software Ment manage-, desarrollo de software, software y planes de man- tenance. El plan SQA debe ser consistentes con el plan de gestión de configuración de software (ver el software de configuración Manage- ment KA). El plan SQA identifica documentos, normas, prácticas y convenciones que rigen el proyecto y cómo estos artículos son revisados y monitoreados para asegurar la adecuación y cumplimiento. El plan SQA también medidas; técnicas estadísticas; los procedimientos para la presentación de informes de problemas y acciones correctivas; recursos tales como herramientas, técnicas y metodologías; la seguridad de los medios físicos; formación; y SQA informes y documentación. Por otra parte, el plan de SQA se ocupa de las actividades de aseguramiento de la calidad del software de cualquier otro tipo de actividad se describe en los planes a dicho software como la adquisición de software de proveedores para el proyecto, el software offthe-shelf comercial (COTS) de instalación, y servicio después de la entrega de El software. También puede contener la aceptación crite- ria, así como la presentación de informes y la gestión de activi- lazos que son críticos para la calidad del software. 2.2. Verificación validación [9 *, c2s2.3, c8, c15s1.1, c21s3.3] Como se indica en [15],

El propósito de V & V es ayudar a la calidad de construcción organización desarrollo en el sistema durante el ciclo de vida. procesos de V & V proporcionan una evaluación objetiva de los productos y procesos en todo el

ciclo vital. Esta evaluación demuestra si los requisitos son correctos, com- pleta, precisa, coherente y comprobable. Los procesos de V & V determinar si los productos de desarrollo de una actividad dada se ajustan a los requisitos de que la actividad y si el producto cumple sus necesidades de uso y de usuarios previstos. La verificación es un intento de asegurar que el producto se ha construido correctamente, en el sentido de que los productos de salida de una actividad cumplen con las especificacio- nes que se les imponen en las actividades anteriores. La validación es un intento de asegurar que el producto adecuado está construido, es decir, el producto cumple con su finalidad específica. Tanto el proceso de verificación y validación del proceso comienzan temprano en la fase de desarrollo o mantenimiento. Proporcionan un examen de las características clave del producto en relación tanto con predecesora inmediata del producto y las especificaciones que deben cumplirse. El propósito de la planificación de V & V es asegurar que cada recurso, el papel y la responsabilidad está claramente asignadas. Los documentos del plan de V & V resultantes describen los diversos recursos y sus funciones y actividades, así como las técnicas y herramientas que se utilizarán. La comprensión de los diferentes efectos de cada actividad V y V ayuda en la planificación cuidadosa de las técnicas y los recursos necesarios para el cumplimiento de sus fines. El plan también se ocupa de la ment manage-, la comunicación, las políticas y procedimientos de las actividades de V & V y su interacción, así como los requisitos de información y documentación defecto. 2.3. Revisiones y auditorías [9 *, c24s3] [16 *] Los comentarios y los procesos de auditoría se definen ampliamente como la electricidad estática sentido de que no hay programas o modelos de software son artefactos de ingeniería de software ejecutados examen, con respecto a las normas que han sido establecidas por la organización o pro- yecto para esos artefactos. Los diferentes tipos de revisiones y auditorías se distinguen por su finalidad, niveles de la Independencia, herramientas y técnicas, roles, y por el tema de la actividad. la

Calidad de Software 10garantía de producto y auditorías de 11 aseguramiento de proceso son normalmente llevadas a cabo por la garantía de la calidad del software (SQA) personal independiente del desarrollo

10-12 Guía SWEBOK® V3.0

equipos. revisiones por la dirección están a cargo de la gestión de la organización o proyecto. El personal de inge- niería lleva a cabo revisiones técnicas. • revisiones por la dirección evalúan proyecto real resultados con respecto a los planes. • Revisiones técnicas (incluidas las inspecciones, paso a paso, y la comprobación de escritorio) examinar productos de trabajo de ingeniería. • auditorías de aseguramiento de proceso. actividades de aseguramiento proceso SQA asegurarse de que los procesos utilizados para desarrollar, instalar, operar y mantener el software se ajustan a los contratos, cumplir con las leyes, normas y regulaciones impuestas y son adecuados, eficientes y eficaces para el fin previsto [5]. • auditorías de garantía de producto. actividades de garantía de producto SQA se aseguran para proporcionar evidencia de que los productos de software y la documentación relacionada se identifican en y cumplir con los contratos; y asegurar que se identifican y tratan [5] mances nonconfor-. 2.3.1. Los comentarios de gestión Como se indica en [16 *], El propósito de una revisión por la dirección es monitorear el progreso, determinar el estado de los planes y programas, y evaluar la eficacia de los procesos de gestión, herramientas y técnicas. revisiones por la dirección compárense resultados efectivos contra los planes para determinar el estado de los proyectos o esfuerzos de manteni- miento. Los principales parámetros de revisiónhombre agement son los costos del proyecto, el calendario, el alcance y la calidad. revisiones por la dirección evalúan las decisiones sobre las acciones correctivas, cambios en la asignación de los recursos, o cambios en el alcance del proyecto. Las entradas a exámenes de gestión pueden

incluir informes de auditoría, informes, V & V informes y planes de muchos tipos, incluyendo la gestión de riesgos, gestión de proyectos, gestión de configuración de software, la seguridad de software, y Assessment riesgo, entre otros progresar. (Consulte el software de gestión de Inge- niería y el software de configu- ración de Gestión KAs para el material relacionado).

2.3.2. Técnico Comentarios Como se indica en [16 *], El propósito de una revisión técnica es evaluar un producto de software por un equipo de personal cualificado para determinar su idoneidad para el uso previsto e identificar las discrepancias de las especificaciones y normas. Proporciona administración evidencia para confirmar el estado técnico del proyecto. Aunque cualquier producto de trabajo puede ser revisada, revisiones técnicas se realizan en los principales productos de trabajo de ingeniería de software de los requisitos de software y diseño de software. Propósito, funciones, actividades, y lo más importante es el nivel de formalidad distinguen diferentes tipos de exámenes técnicos. Las inspecciones son los más formales, Tutoriales menos, y las revisiones de pares o controles documentales son los menos formal. Ejemplos de roles específicos incluyen un tomador de decisiones (es decir, el plomo de software), un líder de opinión, una grabadora, y damas (miembros del personal técnico que examinan los productos de trabajo). Las revisiones también se distinguen por si las reuniones (cara a cara o electrónico) están incluidos en el proceso. En algunos métodos de revisión de damas solitario exami- productos de trabajo ine y enviar sus resultados a un coordinador. En otros métodos de damas trabajan cooperativamente en las reuniones. Una revisión técnica puede requerir que las aportaciones obligatorias estar en su lugar a fin de proceder: • • • •

Declaración de objetivos producto de software específico plan específico de gestión de proyectos lista de temas relacionados con este producto • procedimiento de revisión técnica. El equipo sigue el procedi- opinión prodocumentado. La revisión técnica se completa una vez que todas las actividades enumeradas en el examen se han completado. Revisiones técnicas de código fuente pueden incluir una amplia variedad de problemas tales como el análisis de algoritmos de, la utilización de los recursos críticos de ordenador, la

Software 10adhesión a la codificación Calidad de lasdenormas, la 13 estructura y

10-14 Guía SWEBOK® V3.0

organización de código para la capacidad de prueba, y Seguridadconsideraciones críticas. Tenga en cuenta que las revisiones técnicas de los modelos de código fuente o el diseño tales como UML también se denominan análisis estático (véase el tema 3, Consideraciones prácticas). 2.3.3. inspecciones “El propósito de la inspección es detectar e identificar anomalías de productos de software” [16 *]. Algunos diferenciadores importantes de las inspecciones en comparación con otros tipos de revisiones técnicas son las siguientes: 1. Reglas. Las inspecciones se basan en el examen de un producto de trabajo con respecto a un conjunto definido de criterios especificados por la organización. Conjuntos de reglas pueden ser definidos para diferentes tipos de workproducts (por ejemplo, reglas para los requerimientos, las descripciones de la arquitectura, el código fuente). 2. Muestreo. Más bien que intento de examinar cada palabra y figura en un documento, el proceso de inspección permite las fichas para eva- subconjuntos comió definidos (muestras) de los documentos que se examina. 3. Mirar. Las personas que llevan a cabo las posiciones de gestión sobre los miembros del grupo de inspección no participan en la inspección. Esta es una distinción clave entre revisión y revisión por la dirección. 4. LED. Un mediador imparcial que está entrenado en técnicas de inspección conduce reuniones de inspección. 5. Reunión. El proceso de inspección incluye reuniones (cara a cara o electrónico) concanalizado por un moderador de acuerdo con un procedimiento formal en el que los equipos de inspección miem- bros informan las anomalías que han encontrado y otras cuestiones. Las inspecciones de software siempre implican el autor de un producto intermedio o final; otras opiniones no. Las inspecciones también incluyen un líder de inspección, una

grabadora, un lector, y algunos (de dos a cinco) Damas (inspectores). Los miembros de un equipo de inspec- ción pueden poseer diferentes conocimientos, tales como experiencia en el campo, experiencia en métodos de diseño de software, o la experiencia lenguaje de programación. las inspecciones se realizan normalmente en un relativamente

pequeña sección del producto a la vez (muestras). Cada miembro del equipo examina el producto de software y otros insumos de revisión antes de la reunión de revisión, tal vez mediante la aplicación de una téc- nica analítica (ver sección 3.3.3) a una pequeña sección del producto o de la totalidad del producto con un enfoque en sólo un aspectopor ejemplo, interfaces. Durante la inspección, el moderador lleva a cabo la sesión y verifica que todo el mundo ha preparado para la inspección y lleva a cabo la sesión. Las inspecciones grabadora ción documentos anomalías encontradas. Un conjunto de reglas, con criterios y preguntas pertinentes a los temas de interés, es una herramienta común utilizada en las inspecciones. La lista resultante a menudo clasifica las anomalías (ver sección 3.2, defecto caracterización ción) y es revisada para su integridad y picante Accu por el equipo. La decisión de salida de inspección corresponde a una de las siguientes opciones: 1. Encaja con ninguna o, a lo sumo, reelaboración de menor importancia 2. Aceptar con la verificación de retrabajo 3. Volver a inspeccionar. 2.3.4. Tutoriales Como se indica en [16 *], El propósito de un recorrido sistemática es evaluar un producto de software. A través de pie- puede llevarse a cabo con el propósito de educar a una audiencia con respecto a un producto soft- ware. Tutoriales se distinguen de las inspecciones. La diferencia principal es que los Ents autor Las presiones para el trabajo de productos a los demás participantes en una reunión (cara a cara o electrónico). A diferencia de una inspección, los participantes de la reunión pueden no haber visto necesariamente el material antes de la reunión. Las reuniones pueden llevarse a cabo Mally menos de lucro. El autor toma el papel de explicar y que muestra el material a los participantes y solicita retroalimentación. Al igual que las inspecciones, tutoriales puede llevarse a cabo en cualquier tipo de trabajoproducto, incluyendo plan de proyecto, requisitos, diseño, código fuente, y los informes de las pruebas.

Calidad de Software 1015

10-16 Guía SWEBOK® V3.0

2.3.5. Proceso de aseguramiento y Aseguramiento de auditorías Como se indica en [16 *], El propósito de una auditoría de software consiste en pro- porcionar una evaluación independiente de la con- Formance de productos de software y pro cesos a los reglamentos aplicables, normas, directrices, planes y procedimientos. Proceso auditorías de aseguramiento de determinar la idoneidad de los planes, los programas y los requisitos para lograr los objetivos del proyecto [5]. La auditoría es una actividad organizada formalmente con los participantes que tienen roles tales especí- especomo auditor principal, otro auditor, una grabadora, o un iniciador y que incluye un representativo de la organización auditada. Auditorías identifican los casos de no conformidad y producir un informe que requiere el equipo para tomar medidas correctivas. Si bien puede haber muchos nombres formales para revisiones y auditorías, tales como los identificados en el estándar [16 *], el punto importante es que pueden ocurrir en casi cualquier producto en cualquier etapa del proceso de desarrollo o mantenimiento. 3. Consideraciones prácticas 3.1. Requisitos de calidad de software [9 *, c11s1] [18 *, c12] [17 *, c15s3.2.2, c15s3.3.1, c16s9.10] 3.1.1. Los factores de influencia Hay varios factores que influyen en la planificación, gestión y selección de actividades SQM y técnicas, incluyendo • el dominio del sistema en el que reside el soft- ware; las funciones del sistema podría ser crítico para la seguridad, de misión crítica, negocio-crítica, la seguridad críticos • el entorno físico en el que reside el sistema de soft- ware • (qué tan bien el sistema realiza sus funciones) requisitos del sistema y software

funcional (lo que hace el sistema) y calidad • los componentes comerciales (externos) o estándar (inter- nal) para ser utilizados en el sistema de

• las normas específicas de ingeniería de software aplicable • los métodos y herramientas de software para ser utilizados para el desarrollo y mantenimiento y para la evaluación y mejora de cali- dad • el presupuesto, el personal, la organización del proyecto, planes, y la programación de todos los procesos • los usuarios previstos y el uso del sistema • el nivel de integridad del sistema. La información sobre estos factores influye en cómo se organizan y documentada, la forma específica se seleccionan las actividades de SQM, qué recursos son necesarios, y cuáles de esos recursos imponen límites a los esfuerzos de los procesos SQM. 3.1.2. Confianza En los casos en que un fallo del sistema puede tener consecuencias muy graves, la fiabilidad global (Ware hardware, software y humana u operativo) es el principal requisito de calidad más allá de la funcionalidad básica. Este es el caso por las siguientes razones: las fallas del sistema afectan a un gran número de personas; los usuarios a menudo rechazan los sistemas que son poco fiables, complica o inseguros; los costes de fallos del sistema pueden ser enormes; y sistemas poco confiables pueden causar pérdida de información. Sistema y fiabilidad soft- ware incluyen características tales como la disponibilidad, fiabilidad, seguridad, y la seguridad. Cuando en desarrollo de software fiable, herramientas y técnicas se pueden aplicar para reducir el riesgo de inyección de fallos en los entregables intermedios o el producto de software final. Verificación, validación ción, y pruebas de procesos, técnicas, métodos y herramientas de identificar las fallas que la fiabilidad impacto tan pronto como sea posible en el ciclo de vida. Addition- aliado, mecanismos puede necesitar estar en el lugar en el software para protegerse contra los ataques externos y de tolerar fallos. 3.1.3. Los niveles de integridad de software Definición de los niveles de integridad es un método de riesgo administración. los niveles de integridad de software son

Calidad de Software un rango de valores que representan la1017 complejidad del software, la criticidad, riesgo, nivel de seguridad, nivel de seguridad,

10-18 Guía SWEBOK® V3.0

rendimiento deseado, fiabilidad, u otras características únicas en proyectos que definen la importancia del software para el usuario y adquirente. Las características utilizadas para determinar el nivel de integridad puede variar dependiendo de la aplicación prevista y el uso del sistema. El software es una parte del sistema, y su nivel de integridad se ha de determinar como una parte de ese sistema. Los niveles de integridad de software asignadas pueden cambiar a medida que evoluciona el software. Diseño, codificación procesal, y la tecnología de características implementadas en el sistema o software puede subir o bajar los niveles de integridad de software asignadas. Los niveles de integridad de software establecidos para un proyecto son el resultado de acuerdos entre el adquiriente, proveedor, desarrollador, y las autoridades de aseguramiento independientes. Un esquema de nivel de integridad de software es una herramienta utilizada en la determinación de niveles de integridad de software. [5] Como se ha indicado en [17 *] “los niveles de integridad se pueden aplicar durante el desarrollo para asignar los esfuerzos de verificación y validación adicionales a los componentes de alta integridad.” 3.2. Caracterización de defectos [3 *, c3s3, c8s8, c10s2] Software de evaluación de la calidad (es decir, el control de calidad de software) Técnicas de encontrar defectos, fallas y fracasos. La caracterización de estas técnicas conduce a una comprensión del producto, facilita las correcciones en el proceso o el producto, e informa a la gestión y otras partes interesadas de la tus esta- del proceso o producto. Existen muchas taxonomías y, si bien se han hecho intentos de obtener el consenso, la literatura indica que hay un buen número en uso. Caracterización defecto también se utiliza en auditorías y revisiones, con el líder de opinión a menudo se presenta una lista de problemas proporcionados por los miembros del equipo para su examen en una reunión de revisión. A medida que nuevos métodos de diseño y las

lenguas evolucionan, junto con los avances en el software en general tecnolo- gías, aparecen nuevas clases de defectos, y se requiere una gran cantidad de esfuerzo para interpretar clases definidas anteriormente. Cuando el seguimiento de defectos, el ingeniero de soft- ware está interesado no sólo en el número de defectos, sino también los tipos. Información por sí sola, sin un poco de clasificación, puede no ser suficiente para identificar las causas subyacentes de los defectos.

Los tipos específicos de problemas deben ser agrupados para identificar tendencias en el tiempo. El punto es establecer una taxonomía de defectos que sea significativo para la organiza- ción y para los ingenieros de software. actividades de control de la calidad del software descubrir infor- mación en todas las etapas de desarrollo de software y mantenimiento. En algunos casos, la palabra defecto está sobrecargado para referirse a diferentes tipos de anomalías. Sin embargo, diferentes cultivos de ingeniería y Standards pueden utilizar algo diferentes significados para estos términos. La variedad de términos solicita esta sec- ción para proporcionar un conjunto ampliamente utilizado de las definiciones [19]: • Error de cálculo: “La diferencia entre un valor calculado, observado o medido o condición y el verdadero, especificado, o el valor o condición teóricamente correcto” • Error: “Una acción humana que produce un resultado incorrecto.” Un resbalón o un error que hace que per- sona. También llamado error humano. • Defecto: Un “imperfección o deficiencia en un producto de trabajo donde ese producto de trabajo no cumple con sus requisitos o especificaciones y necesita ser reparado o reemplazado.” Un defecto es causado por una persona que cometa un error. • Culpa: Un defecto en el código fuente. Un “paso, proceso o definición incorrecta de datos en el programa de ordenador”. La codificación de un error humano en el código fuente. Culpa es el nombre formal de un error. • Fracaso: Un “evento en el cual un sistema o componente de sistema no realiza una función requerida dentro de los límites especificados.” Un fallo se produce cuando una falla se encuentra por el procesador en condiciones especificadas. Usando estas definiciones tres mediciones de calidad de soft- ware ampliamente utilizados son la densidad de defectos (número de defectos por unidad de tamaño de documentos), la densidad de fallo (número de fallos por 1K líneas de código), y la intensidad fallo (fallos por uso-hora o por prueba -hora). modelos de fiabilidad se construyen a partir de datos de fallos recogidos durante las pruebas de software

Software 10o desde el software en el servicio Calidad y por lodetanto 19 pueden ser utilizados para estimar la probabilidad de fallos futuros y para ayudar en las decisiones sobre cuándo detener la prueba. Una probable acción resultante de SQM hallazgo Ings es eliminar los defectos del producto objeto de examen (por ejemplo, encontrar y corregir errores, crear nueva construcción). Otras actividades intentan eliminar

Calidad de Software 1011

las causas de los defectos, por ejemplo, análisis de la causa raíz (RCA). RCA actividades incluyen analizar y resumir los resultados para encontrar las causas de raíz y el uso de técnicas de medición para mejorar el producto y el proceso, así como para realizar un seguimiento de los defectos y su eliminación. La mejora de procesos se discute principalmente en el proceso de software Engineer- ing KA, con el proceso de SQM ser una fuente de información. Los datos sobre las insuficiencias y defectos encontrados por las técnicas de control de calidad de software se pueden perder a menos que se graban. Para algunas técnicas (por ejemplo, revisiones técnicas, auditorías, inspecciones), grabadoras están presentes para establecer ción tales informa-, junto con las cuestiones y decisiones. Cuando se utilizan herramientas automatiza apareadas (ver tema 4, Software cali- dad Herramientas), la salida de la herramienta puede proporcionar la información de defectos. Los informes sobre defectos se proporcionan a la gestión de la organización. 3.3. Técnicas de gestión de calidad de software [7 *, c7s3] [8 *, c17] [9 *, c12s5, c15s1, P417] [dieciséis*] técnicas de control de calidad de software se pueden cat- egorized de muchas maneras, pero un enfoque sencillo utiliza sólo dos categorías: estáticas y dinámicas. técnicas dinámicas implican la ejecución del software; técnicas estáticas implican documentos de análisis y el código fuente, pero no ejecutar el software. 3.3.1. Técnicas estáticas técnicas estáticas examinan software de documentación ción (incluidos los requisitos de interfaz, ciones especificación, diseños y modelos) y el código fuente del software sin ejecutar el código. Hay muchas herramientas y técnicas para el examen de forma estática productos de trabajo soft- ware (véase la sección 2.3.2). En adi- ción, herramientas que analizan fuente de flujo de control de código y la búsqueda de código muerto se considera que son herramientas de análisis estático, ya que no implican la ejecución del código de software. Otros, más formales, los tipos de técnicas de análisis son conocidos como métodos formales.

Se utilizan sobre todo para verificar los requisitos de software y diseños. En su mayoría se han utilizado en la veri ficación de partes cruciales de los sistemas críticos, como los requisitos de seguridad y protección específicas. (Ver

10-12 Guía SWEBOK® V3.0

También Métodos formales en la EngineerSoftware ing modelos y métodos KA). 3.3.2. Las técnicas dinámicas técnicas dinámicas implican la ejecución del código de soft- ware. Diferentes tipos de técnicas dinámicas se realizan durante todo el desarrollo y mantenimiento de software. técnicas Generalmente, estos son pruebas, pero técnicas tales como La simulación y análisis del modelo pueden considerarse dinámica (ver los modelos ingeniería de software y Métodos KA). La lectura de códigos se considera una técnica estática, pero el software de ingenieros pueden ejecutar el código a medida que leen a través de él experimentó. La lectura de códigos puede utilizar técnicas dinámicas. Esta discrepancia en la categorización indica que las personas con diferentes roles y experiencia en la organización pueden considerar y aplicar estas técnicas de forma diferente. Diferentes grupos pueden realizar pruebas durante el desarrollo de software, incluidos los grupos inde- pendiente del equipo de desarrollo. La Prueba KA Software está dedicado enteramente a este tema. 3.3.3. Pruebas Dos tipos de pruebas pueden caer bajo V & V debido a su responsabilidad por la calidad de los mate- riales utilizados en el proyecto: • Evaluación y pruebas de herramientas que se utilizarán en el proyecto • pruebas de conformidad (o revisión de pruebas Mance confor-) de componentes y COTS Pro- ductos para ser utilizados en el producto. A veces, una (de terceros o IV y V) independiente organización puede ser la tarea de realizar pruebas o para controlar el proceso de prueba V & V pueden ser llamados para evaluar la prueba en sí: adecuación de los planes, procesos y procedimientos, y la adecuación y la precisión de resultados. El tercero no es el desarrollador, ni está asociada con el desarrollo del producto. En cambio, el tercero es un independiente para sus instalaciones, por lo general acreditado por algún organismo de la autoridad. Su propósito es poner a prueba un producto para la conformidad con un conjunto específico de requisitos (véase la Prueba KA Software).

Calidad de Software 1013

3.4. Medición de la Calidad de Software [3 *, c4] [8 *, c17] [9 *, p90] mediciones de calidad de software se utilizan para apoyar la toma de decisiones. Con la creciente sofisticación de software, las cuestiones de calidad van más allá de si es o no el software funciona a lo bien que logra los objetivos de calidad medibles. Decisiones soportados por surement medicalidad del software incluyen los niveles de calidad del software determinar (en particular, porque los modelos de la calidad del producto de software incluyen medidas para determinar el grado en que el producto de software logra las metas de calidad); cuestiones de gestión sobre el esfuerzo, costo y cronograma; determinar cuándo parar de Exámenes y liberar un producto (ver terminación en la sección 5.1, las consideraciones prácticas, en el KA SoftTesting Ware); y determinar la eficacia de los esfuerzos de mejora de procesos. El costo de los procesos SQM es un problema FRECUENTEMENTE criado en la decisión de cómo se deben organizar un proyecto o un grupo de desarrollo y mantenimiento de las mercancías blandas. A menudo, se utilizan modelos genéricos de costo, que se basan en cuando se encuentra un defecto y la cantidad de esfuerzo que se necesita para corregir el defecto relación tivo a encontrar el defecto más temprano en el proceso de desa- rrollo. los datos de medición de la calidad de software recopilados internamente pueden dar una mejor idea de costo dentro de este proyecto u organización. Mientras que los datos de medición de la calidad del software puede ser útil en sí mismo (por ejemplo, el número de requisitos defectuosos o la proporción de los requisitos defectuosos), las técnicas matemáticas y gráficas se pueden aplicar para ayudar en la interpretación de las medidas (véase la Ingeniería fundamentos KA). Estas técnicas incluyen • estadística descriptiva base (por ejemplo, análisis de Pareto, diagramas de funcionamiento, diagramas de dispersión, distribución normal) • pruebas estadísticas (por ejemplo, la prueba binomial, chisquared test)

• análisis de tendencia (por ejemplo, gráficos de control; ver La caja de herramientas de calidad en la lista de lecturas adicionales) • la predicción (por ejemplo, modelos de fiabilidad). técnicas basadas en la estadística descriptiva y pruebas a menudo proporcionan una instantánea de la más

10-14 Guía SWEBOK® V3.0

áreas problemáticas del producto de software bajo examen. Las tablas y gráficos resultantes son ayudas de visualización, que la decisión MAK- ERS puede utilizar para enfocar los recursos y llevar a cabo mejoras pro Cess en el que parecen estar más se necesita. Los resultados de análisis de tendencias pueden indicar que se está cumpliendo un horario, tal como en la prueba, o que ciertas clases de fallos pueden llegar a ser más probable que ocurra a menos que se tome alguna acción correctiva en el desarrollo. Las técnicas de predicción facilitar la estimación de esfuerzo de pruebas y el horario y en la predicción de fallos. Más discusión sobre la medición en general aparece en el Proceso de Ingeniería de Software Ingeniería de Software y Gestión de Kas. información más específica sobre la medición de la prueba se presenta en la Prueba de Software KA. Software de medición de la calidad incluye medi- suring ocurrencias de defectos y la aplicación de métodos estadísticos para comprender los tipos de defectos que se producen con mayor frecuencia. Esta información puede ser utilizada por la mejora de procesos de software para los métodos de minería determinantes para prevenir, reducir, o eliminar su recurrencia. También ayudan en la comprensión de las tendencias, lo bien que la detección y contención técni- cas están trabajando, y qué tan bien los procesos, crear y mantener desarrollos están progresando. A partir de estos métodos de medición, los perfiles de defectos se pueden desarrollar para un dominio apli- cación específica. Entonces, para el siguiente proyecto de software dentro de esa organización, los perfiles se pueden utilizar para guiar los procesos que SQM es, hacer el esfuerzo donde los problemas son más probable que ocurra. Del mismo modo, puntos de referencia, o recuentos de defectos típicos de ese dominio, pueden servir como una ayuda en la determinación cuando el producto está listo para la entrega. Discusión del sobre con los datos de SQM para mejorar los procesos rrollo y mantenimiento desa- aparece en la Gestión de Ingeniería de Software y Software Ingeniería de Procesos de Kas. 4. Herramientas de Calidad de Software herramientas de calidad de software incluyen herramientas de análisis estático y dinámico. El análisis estático de código fuente de entrada de herramientas, realizar el análisis sintáctico y

semántico sin ejecutar el código, y presentar los resultados a los usuarios. Hay una gran variedad en la profundidad, THOR oughness, y el alcance de herramientas de análisis estático que

Calidad de Software 1015

se puede aplicar a los artefactos incluyendo modelos, además de código fuente. (Véase el trucción Software Con-, pruebas de software, y manteni- Software Principal- KAs para las descripciones de las herramientas de análisis dinámicos.) Categorías de herramientas de análisis estático incluyen la siguiendo: • Las herramientas que facilitan y automatizan parcialmente las revisiones e inspecciones de documentos y código. Estas herramientas pueden trabajar ruta a diferencias ent participantes con el fin de automatizar y controlar un proceso de revisión parcial. Permiten a los usuarios introducir defectos encontrados durante las inspecciones y revisiones para su posterior eliminación. • Algunas herramientas ayudan a las organizaciones realizar análisis de riesgo para la seguridad soft- ware. Estas herramientas proporcionan, por ejemplo, soporte automatizado para el análisis de modo de fallo y efectos (FMEA) y el análisis de árbol de fallos (FTA).

• Herramientas que apoyan el seguimiento de los problemas más software para proporcionar una entrada de anomalías descu- Ered durante las pruebas de software y análisis posterior, disposición y resolución. Algunas herramientas incluyen soporte para flujo de trabajo y para el seguimiento del estado de resolución de problemas. • Herramientas que analizan los datos capturados a partir de entornos de ingeniería soft- ware y entornos de prueba Ware softy producen pantallas visuales de datos cuantificados en forma de gráficos, tablas, y tablas. Estas herramientas incluyen alguveces la funcionalidad para realizar un análisis estadístico de los conjuntos de datos (por El propósito de las tendencias más exigentes y hacer extremidades anteriores de los contenedores). Algunas de estas herramientas proporcionan tasas de defectos y de inyección de extracción; densidades de defecto; los rendimientos; distribución de inyección de defectos y con cada una de las fases del ciclo de vida.

10-16 Guía SWEBOK® V3.0

1.4. Mejora de la Calidad de Software

2.2. Verificación y Validación

2.3. Revisiones y auditorías

c17, c22 c24s1

c2s4

c1s4

c17

c11s3

C4-C6, C11, c26-27 c2 S2.3, c8, c15 S1.1, c21 S3.3 c24s3

*

Mugirre 2006 [17 *] Wiegers 2003 [18 *]

c11 S2.4

yoAEE Std. 10282008 [16 *]

naik y Tripathy 2008 [8 *]

c24

c2s3.5

1.5. software de Seguridad 2. Procesos de Gestión de Calidad de Software 2.1. Calidad de Software

Voland 2003 [10 *]

1.2. valor y Costo de la Calidad 1.3. modelosy características de calidad

c1s4

SommervilLe 2011 [9 *]

1. Fundamentos de Calidad de Software 1.1. Software de Ingeniería de la Cultura y Ética

Larva del moscard ónt et al. Galin 2004 2000 [6 [7 *] *]

Kan 2002 [3 *]

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

3. Consideraciones prácticas de la calidad del software 3.1. Requisitos de calidad de software

3.2. Caracterización de defectos

4. Herramienta s de software de calidad

c3s3, c8s8, c10s 2 c7s3

c4

c17

c12s5, c15s1 , P417

c17

p90

Mugirre 2006 [17 *] Wiegers 2003 [18 *]

Voland 2003 [10 *]

yoAEE Std. 10282008 [16 *]

s3.2. 2 c15, s3.3.1 c15, s9.10 c16

c11s1

3.3. SQM técnicas 3.4. Medición de la Calidad de Software

SommervilLe 2011 [9 *]

naik y Tripathy 2008 [8 *]

Larva del moscard ónt et al. Galin 2004 2000 [6 [7 *] *]

Kan 2002 [3 *]

Calidad de Software 1017

*

c12

10-18 Guía SWEBOK® V3.0

LECTURAS N. Leveson, Safeware: Sistema de seguridad e Informática [20].

KE Wiegers, Peer Reviews en software: Una guía práctica [23].

Este libro describe la importancia de las prácticas de seguridad de software y cómo estas prácticas se pueden incorporar en los proyectos de desarrollo de software.

Este libro ofrece explicaciones claras y concisas de los diferentes métodos de revisión por pares que se distinguen por el nivel de formalidad y eficacia. orientación pragmática para la aplicación de los métodos y cómo seleccionar qué métodos son apropiados para determinadas circunstancias se proporciona.

T. Gilb, Principios de software de gestión de ingeniería [21]. Este es uno de los primeros libros sobre técnicas de desarrollo iterativo e incremental. El Método Evo define objetivos cuantificados, frecuentes iteraciones en caja tiempo-, las mediciones de progreso hacia las metas, y la adaptación de los planes en base a los resultados reales. T. Gilb y D. Graham, Software de Inspección [22]. Este libro presenta el muestreo y medición de cal estadísticamente para las revisiones y defectos. Presenta técnicas que producen resultados cuantificados para reducir los defectos, la mejora de la productividad, la pistaing proyectos y la creación de documentación.

NR Tague, La Caja de Herramientas de Calidad, 2ª ed., [24]. Proporciona una pragmática de cómo hacerlo explicación de un amplio conjunto de métodos, herramientas y técnicas para la resolución de proble- mas de mejora de calidad. Incluye las siete herramientas básicas de control de calidad y muchos otros. IEEE Std. P730-2013 Proyecto de Norma para los procesos de software de garantía de calidad [5]. Este proyecto de norma expande los procesos SQA identificados en IEEE / ISO / IEC 12207 a 2008. P730 establece normas para iniciar, planificar, controlar y ejecutar los procesos de garantía de calidad del software de desarrollo de software o proyecto de mantenimiento. Se espera que la aprobación de este proyecto de norma en 2014.

Calidad de Software 1019

Referencias [1] PB Crosby, la calidad es gratuito, McGrawHill, 1979. [2] W. Humphrey, Gestión del proceso de software, Addison-Wesley, 1989. [3 *] SH Kan, métricas y modelos en Ingeniería de Software de Calidad, 2ª ed., AddisonWesley, 2002. [4] ISO / IEC 25010: 2011 Sistemas y de Ingeniería de Software-Systems y requisitos de calidad de software y Evaluación (cuadrado) -Sistemas y modelos de calidad del software, ISO / IEC 2011. [5] IEEE P730 ™ / D8 Proyecto de Norma para los procesos de software de garantía de calidad, IEEE 2012. [6 *] F. Bott et al., Cuestiones profesional en Ingeniería de Software, 3ª ed., Taylor & Francis, 2000. [7 *] D. Galin, Calidad de Software: de la teoría a la implementación, Pearson Educación, SA, 2004. [8 *] S. Naik y P. Tripathy, pruebas de software y aseguramiento de la calidad: Teoría y Práctica, Wiley-Spektrum, 2008. [9 *] P. Clements et al, el software de documentación: Arquitecturas. Vistas y más allá, 2ª ed, Pearson Education, 2010.. [10 *] G. Voland, Ingeniería de Diseño, segundo ed., Prentice Hall, 2003. [11] RTCA DO-178C, Consideraciones sobre el software en sistemas de vuelo y Certificación de Equipos, Comisión Técnica de Radio para la Aeronáutica, 2011. [12] IEEE Std. 15.026,1-2011 Trial-Uso Adopción estándar de la norma ISO / IEC TR 15026-1: 2010 Sistemas y Software INGENIERÍA-Sistemas y de Software

Assurance-Parte 1: Conceptos y Vocabulario, IEEE 2011.

10-20 Guía SWEBOK® V3.0

[13] IEEE Std. 12207-2008 (también conocido como ISO / IEC 12207: 2008) estándar para los sistemas y software de ingeniería en software procesos de ciclo de vida, IEEE 2008. [14] ISO 9000: 2005 de calidad de gestión de sistemas Fundamentos y Vocabulario, ISO 2005. [15] IEEE Std. 1012-2012 estándar para el sistema y la verificación y validación de software, IEEE 2012. [16 *] IEEE Std. 1028-2008, software comentarios y auditorías, IEEE 2008. [17 *] JW Moore, La Hoja de Ruta de Ingeniería de Software: Una guía basada en estándares, Wiley-IEEE Computer Society Press, 2006. [18 *] KE Wiegers, requisitos de software, segundo ed., Microsoft Press, 2003. [19] ISO / IEC / IEEE 24765: 2010 Sistemas y de Ingeniería de Software-Vocabulario, ISO / IEC / IEEE 2010. [20] N. Leveson, Safeware: Sistema de seguridad e Informática, AddisonWesley Professional, 1995. [21] T. Gilb, Principios de Ingeniería de Software de Gestión, Addison-Wesley Professional, 1988. [22] T. Gilb y D. Graham, Software de inspección, Addison-Wesley Professional, 1993. [23] K. Wiegers, Peer Reviews en Software: Una Guía Práctica, Addison-Wesley Professional, 2001. [24] NR Tague, La Caja de Herramientas de Calidad, 2ª ed., ASQ Quality Press, 2010.

CAPÍTULO 11 INGENIERÍA DE SOFTWARE LA PRÁCTICA PROFESIONAL SIGLAS ACM BCS CSDA

Association for Computing Maquinaria British Computer Society Desarrollo de software certificada Asociar

PCSD

Desarrollo de software certificada Profesional

IEC

Electrotécnica Internacional Comisión

IEEE CS IEEE Computer Society Internacional. Federación de IFIP Procesamiento de la Información IP

Propiedad intelectual

ISO

Organización Internacional para las Normalización

NDA OMPI OMC

Acuerdo de Confidencialidad Organización Mundial de la Propiedad Intelectual Organización de Comercio Mundial

INTRODUCCIÓN El área de conocimiento Tice ticas Profesional de Ingeniería de Software (KA) tiene que ver con los conocimientos, habilidades y actitudes que los ingenieros de software deben poseer para practicar software de inge- niería de manera cal profesional, responsable, y ethi-. Debido a las aplica- ciones generalizadas de los productos de software en la vida social y personal, la calidad de los productos de software puede tener un profundo impacto en nuestro bienestar personal y la armonía social. Los ingenieros de software deben manejar los problemas de ingeniería únicas, produciendo

de software con las características conocidas y fiabili- dad. Este requisito exige ingenieros de software que poseen un conjunto adecuado de conocimientos, habilidades, capacitación y experiencia en la práctica profesional. El término “práctica profesional” se refiere a una forma de realización de los servicios a fin de lograr los estándares o criterios determi- nados, tanto en el proceso de realización de un servicio y el producto final RESULTEN del servicio. Estas normas y cri- terios pueden incluir tanto los aspectos técnicos y no técnicos. El concepto de la práctica profesional puede ser visto como más aplicable dentro de aquellas profesiones que tienen un cuerpo generalmente aceptada de conocimiento; códigos de ética y conducta profesional con sanciones por violaciónes; aceptadas para los procesos de acreditación, certificación y concesión de licencias; y las sociedades profesionales para proporcionar y administrar todos estos. La admisión a estas sociedades profesionales a menudo se basa en una combinación prescribirse de educación y experiencia. Un ingeniero de software mantiene una práctica profesional mediante la realización de todo el trabajo de conformidad con las prácticas generalmente aceptadas, las normas y directrices establecidas en particular sucesivamente por la sociedad profesional aplicable. Por ejemplo, la Association for Computing Machinery (ACM) y la Sociedad IEEE Com- puter (IEEE CS) han establecido un Código Ingeniería Cesión de Software de Ética y Práctica Profesional. Tanto la British Computer Society (BCS) y la Federación Internacional para el Tratamiento de la Información (IFIP) han establecido normas de la práctica pro- fesional similares. ISO / IEC e IEEE han proporcionado aún más los estándares de ingeniería de software internacionalmente aceptadas (véase el Apéndice B de esta Guía). IEEE CS ha establecido dos

10-22 Guía SWEBOK® programasV3.0 internacionales

de certificación (CSDA, PCSD) y una guía correspondientes a la Ingeniería de Software de Administración de

Conocimiento (Guía SWEBOK). Todos estos son

11-1

11-2

Guía SWEBOK® V3.0

Figura 11.1. Desglose de temas para la Ingeniería de Software Profesional Práctica KA

elementos que sientan las bases para la práctica profe- sional de la ingeniería de software. DISTRIBUCIÓN DE TEMAS PARA LA PRÁCTICA PROFESIONAL DE INGENIERÍA DE SOFTWARE desglose de los temas de la Ingeniería de Software Profesional Práctica de KA se muestra en la figura

11.1. Las subáreas presentados en este KA son el profesionalismo, la dinámica de grupo y la psicología, y habilidades de comunicación. 1. Profesionalismo Un ingeniero de software muestra el profesionalismo en particular mediante la adhesión a códigos de ética y conducta profesional y las normas y

Ingeniería de Software Práctica Profesional 11-3

prácticas que son establecidos por la comunidad profesional del ingeniero. La comunidad profesional es a menudo representada por una o varias sociedades profesionales; aquellas sociedades publican códigos de ética y conducta profe- sional, así como los criterios para la admisión a la comunidad. Estos criterios son la base para las actividades de acreditación y concesión de licencias y pueden ser utilizados como una medida para determinar la competencia de ingeniería o negligencia. 1.1. Acreditación, Certificación y Licencias [1 *, c1s4.1, c1s5.1-c1s5.4] 1.1.1. acreditación Acreditación es un proceso para certificar la tencia tencia, autoridad, o la credibilidad de una organización. escuelas o programas acreditados están asegurados a que se adhieran a las normas particulares y mantener cualidades determinados. En muchos países, los medios básicos por los cuales los ingenieros adquieren conocimientos es a través de la finalización de un curso acreditado de estudio. A menudo, la acreditación de ingeniería se lleva a cabo por una organización gubernamental, tales como el Ministerio de Educación. Tales países con acreditaciones gubernamentales incluyen China, Francia, Alemania, Israel, Italia y Rusia. En otros países, sin embargo, el proceso de acredi- ción es independiente del gobierno y realizado por las asociaciones de miembros privados. Por ejemplo, en los Estados Unidos, Engineer- acreditación ción se lleva a cabo por una organiza- ción conocida como ABET. Una organización conocida como CSAB que actúa como un órgano de participación de la sociedad ABET es el plomo dentro de ABET para la acredi- ción de los programas de grado en ingeniería de software. Si bien el proceso de acreditación pueden diferir de país y para cada jurisdicción, el significado general es la misma. Por supuesto, de una institución de estudio para ser acreditado significa que “el cuerpo ción acredi- reconoce una institución educativa como el mantenimiento de las normas que califican a los graduados para la admisión a más alto o más especializado instituciones o para el ejercicio profesional”[2].

1.1.2. Proceso de dar un título Certificación se refiere a la confirmación de una percaracterísticas particulares del hijo. Un tipo común

11-4

Guía SWEBOK® V3.0

de la certificación es la certificación profesional, cuando una persona está certificado como ser capaz de completar una actividad en una cierta disciplina en un nivel determinado de competencias. certificación profesional también puede verificar la capacidad del titular para cumplir con las normas profesionales y aplicar el juicio profesional en la solución o la solución de los problemas. La certificación profesional también puede implicar la verificación del conocimiento establecido, la de masterización de las mejores prácticas y metodologías comprobadas, y la cantidad de experiencia profesional. Un ingeniero usualmente obtiene la certificación superando un examen en conjunción con otros criterios basados en la experiencia. Estos exámenes son a menudo administrados por organiza- ciones no gubernamentales, como las asociaciones profesionales. En la ingeniería de software, certificación monio con inversión extranjera a la calificación de una persona como ingeniero de software. Por ejemplo, el IEEE CS ha promulgado dos programas de identifi- cier- (CSDA y PCSD) diseñados para confirmar los conocimientos de un ingeniero de software de las prácticas de ingeniería de software estándar y para avanzar en la carrera de uno. La falta de certificación no excluye al individuo de trabajar como ingeniero de software. Actualmente la certificación en ingeniería de soft- ware es completamente voluntaria. De hecho, la mayoría de los ingenieros de software no están certificados bajo cualquier programa. 1.1.3. la concesión de licencias “Las licencias” es la acción de dar a una persona la autorización para realizar ciertos tipos de activi- dades y asumir la responsabilidad de los productos resultantes de ING Engineer-. El sustantivo “licencia” se refiere tanto a la autorización y el documento de grabación que la autorización. Las autoridades gubernamentales u organismos reglamentarios por lo general otorgan licencias. La obtención de una licencia para la práctica requiere no sólo que una persona cumple un cierto nivel, sino que también lo hacen con una cierta capacidad de practicar u operar. A veces hay un requisito de nivel de entrada que establece las habilidades y capacidades mínimas para la práctica, pero a medida que el

profesional a través de su carrera, las habilidades y capacidades requeridas cambiar y evolucionar. En general, los ingenieros tienen licencia como un medio de proteger al público de personas no cualificadas. En algunos países, no se puede ejercer como ingeniero de pro- fesional menos que esté autorizado; o más, sin

Ingeniería de Software Práctica Profesional 11-5

empresa puede ofrecer “servicios de ingeniería” a menos al menos un ingeniero con licencia se emplea allí. 1.2. Códigos de Ética y Conducta Profesional [1 *, c1s6-c1s9] [3 *, c8] [4 *, c1s2] [5 *, c33] [6 *] Los códigos de ética y conducta premio comprofesional de los valores y el comportamiento y las decisiones que la práctica profesional de un ingeniero debe encarnar. La comunidad profesional establece códigos de ética y conducta profesional. Existen en el contexto de, y se ajustan de acuerdo con las normas sociales, y las leyes locales. Por lo tanto, los códigos de ética y conducta profesional presente Ance guid- en la cara de los imperativos contradictorios. Una vez que se han establecido códigos de ética y conducta profesional son impuestas por la profesión, según lo representado por las asociaciones profesionales o por un organismo de derecho público. Violaciónes pueden ser actos de comisión, como la ocultación de trabajo inadecuado, la revelación de información con- Fidential, falsificar información, o desvirtuar las habilidades de uno. También pueden ocurrir a través de la omisión, incluyendo la falta de discercanos riesgos o para proporcionar información importante, el hecho de dar crédito o reconocer las referencias, y el fracaso para representar EST cliente inter. Violaciónes de los códigos de ética y conducta profesional pueden dar lugar a sanciones y po- sible la expulsión del estatus profesional. Un código de ética y conducta profesional de la ingeniería de software fue aprobado por el Consejo de la ACM y la Junta de Gobernadores CS IEEE en 1999 [6 *]. De acuerdo con la versión corta de este código: Los ingenieros de software deberán comprometerse ellos mismos a hacer el análisis, especificación, diseño, desarrollo, prueba y mantenimiento de software una profesión beneficiosa y respetada. De acuerdo con su compromiso con la salud, la seguridad y el bienestar del público, los ingenieros de software deberán cumplir con los ocho principios

con- cerning el público, clientes y empresarios, el producto, el juicio, la gestión, profe- sión, colegas, y el auto, respectivamente .

11-6

Guía SWEBOK® V3.0

Dado que se pueden introducir normas y códigos de ética y conducta profesional, modificado o reemplazado en cualquier momento, inge- niería de software individuales tienen la responsabilidad de su propio estudio tinuing con- para mantenerse al día en su práctica profesional. 1.3. La naturaleza y la función de Sociedades Profesionales [1 *, C1S1-c1s2] [4 *, c1s2] [5 *, c35s1]

las

Las sociedades profesionales se componen de una mezcla de profesionales y académicos. Estas sociedades sirven para definir, impulsar y regular sus profesiones correspon- dientes. Las sociedades profesionales ayudan a establecer estándares profesionales, así como códigos de ética y conducta profesional. Por esta razón, también se dedican a actividades relacionadas, que incluyen • establecer y promulgar un cuerpo de conocimiento gene- ralmente aceptado; • acreditación, certificación, y la concesión de licencias; • dispensación de medidas disciplinarias; • el avance de la profesión a través de las conferencias, capacitación y publicaciones. La participación en sociedades profesionales asiste al ingeniero individuo en el mantenimiento y la nitidez ening sus conocimientos profesionales y la relevancia y en la ampliación y el mantenimiento de su red profesional. 1.4. La naturaleza y la función de las normas de ingeniería de software [1 *, c5s3.2, c10s2.1] [5 *, c32s6] [7 *, c1s2] Software normas de ingeniería cubren una remark- capaces variedad de temas. Ellos proporcionan directrices para la práctica de la ingeniería de software y procesos para ser utilizados durante el desarrollo, mantenimiento y soporte de software. Mediante el establecimiento de un cuerpo consensuada de conocimientos y experiencias, software de inge- niería normas establecen una base sobre la cual fur- directrices ther puede ser desarrollado. Apéndice B de esta Guía proporciona orientación sobre las normas de ingeniería de software IEEE e ISO / IEC que

apoyan las áreas de conocimiento de esta Guía. Los beneficios de las normas de ingeniería de software son muchas e incluyen la mejora de la calidad del software,

Ingeniería de Software Práctica Profesional 11-7

ayudar a evitar errores, la protección de los productores y los usuarios de software, el aumento de disci- plina profesional, y ayudar a la transición de la tecnología. 1.5. Impacto económico de Software [3 *, c10s8] [4 *, c1s1.1] [8 *, c1] El software tiene efectos económicos a nivel individual, negocio, y los niveles de la sociedad. Software “éxito” puede ser determinado por la idoneidad de un producto para un problema reconocido, así como por su efectividad cuando se aplica a ese problema. A nivel individual, el empleo continua- ción de un ingeniero puede depender de su capacidad y disposición para interpretar y ejecutar tareas en el cumplimiento de las necesidades y expectativas de los clientes o empleadores. El cliente o situación finan- cial del empleador pueden a su vez ser positiva o negativamente afectados por la compra de software. A nivel empresarial, el software aplica correctamente a un problema puede eliminar meses de trabajo y traducirse en ganancias elevadas u organizaciones tivos más effec-. Por otra parte, las organizaciones que adquieren o proporcionan software con éxito pueden ser de gran ayuda a la sociedad en la que operan por Viding pro del empleo y de mejora de los servicios. Sin embargo, los costes de desarrollo o adquisición de software también pueden equiparar a las de cualquier adquisición importante. En el ámbito social, los impactos directos del éxito o el fracaso de software incluyen o excluyen los accidentes, interrupciones y pérdida de servicio. Los impactos indirectos incluyen el éxito o el fracaso de la organización que adquiere o se produce el software, aumento o disminución de la productividad de la sociedad, el orden social armónico o perjudicial, e incluso el ahorro o la pérdida de la propiedad y la vida. 1.6. Contratos de trabajo [1 *, c7] servicios de ingeniería de software se pueden proporcionar en una variedad de relaciones cliente-ingeniero. El trabajo de ingeniería de software puede ser solic- ited como

suministrador de empresa a cliente, Engineerasesoramiento a cliente, contratación directa, o incluso como voluntario. En todas estas situaciones, el al cliente central y proveedor de acuerdo en que un producto o ser- vicio será proporcionado a cambio de algún tipo de

11-8

Guía SWEBOK® V3.0

consideración. En este caso, estamos más preocupados con el arreglo de ingeniero a los clientes y sus acompañantes acuerdos o contratos, si son de la variedad contratación directa o consultor, y los problemas que suelen abordar. Una preocupación común en contratos de ingeniería de software es la confidencialidad. Los empleadores obtienen ventajas comerciales de la propiedad intelectual, por lo que se esfuerzan proteger dicha propiedad de cierre dis-. Por lo tanto, los ingenieros de software a menudo tienen que firmar acuerdos de propiedad intelec- tual (IP) no divulgación (NDA) o como una condición previa para trabajar. Estos acuerdos se aplican normalmente a la información del ingeniero de software sólo puede ganar a través de la asociación con el cliente. Los términos de estos acuerdos pueden extenderse más allá de la nación terminología de la asociación. Otra preocupación es la propiedad intelectual. Los derechos sobre los activos de software de ingeniería subproductos, innovaciones, inventos, descubrimientos e ideas pueden residir con el empleador o cliente, ya sea en virtud de los términos del contrato explícitas o leyes pertinentes, si se obtienen dichos activos durante el plazo del ingeniero de software de relación con ese empleador o cliente. Contratos difieren en la propiedad de los activos creados usando ción o información equip- propiedad no por el empleador. Finalmente, contratos también pueden especificar, entre otros elementos la ubicación en la que el trabajo se va a realizar; normas a las que se llevará a cabo ese trabajo; la configuración del sistema que se utiliza para el desarrollo; limitaciones del software nieros Neer y responsabilidad del empleador; una matriz de comunicación y / o plan de escalada; y detalles administrativos tales como los tipos, la frecuencia de compensación, horas de trabajo, y las condiciones de trabajo. 1.7. Asuntos legales [1 *, c6, c11] [3 *, c5s3-c5s4] [9 *, c1s10] cuestiones legales que rodean la práctica profesional de la ingeniería de software incluyen en particular las cuestiones relacionadas con las normas, marcas, patentes, derechos de autor, secretos comerciales, responsabilidad profesional, requisitos legales, de cumplimiento comercial, y la ciberdelincuencia. Por tanto, es beneficioso

para poseer el conocimiento de estas cuestiones y su aplicabilidad. cuestiones legales se basan jurisdiccionalmente; suaveLos ingenieros de mercancías deben consultar a los abogados que

Ingeniería de Software Práctica Profesional 11-9

especializarse en el tipo y la jurisdicción de cualquier problema legal tificado iden-. 1.7.1. normas normas de ingeniería de software establecen líneas directrices para las prácticas generalmente aceptadas y el mini-requisitos mamá de productos y servicios RESPETA por un ingeniero de software. Apéndice B de esta Guía proporciona orientación sobre ingeniería de software estándares que se aplican a cada KA. Los estándares son fuentes valiosas de los requisitos y asistencia durante la conducción cotidiana de las actividades de ingeniería de software. La adhesión a las normas facilita la disciplina mediante la enumeración de las características mínimas de productos y aplicaciones prácticas. Que la disciplina ayuda a mitigar los supuestos subconscientes o exceso de confianza en un diseño. Por estas razones, las organizaciones que realizan actividades de ingeniería de software a menudo incluyen la conformidad con las normas, como parte de sus polí- cias organizativas. Además, la adhesión a las normas es un componente importante en la defensa de la acción legal o de las acusaciones de negligencia. 1.7.2. Marcas comerciales Una marca se relaciona con cualquier palabra, nombre, símbolo o dispositivo que se utiliza en las transacciones comerciales. Se utiliza “para indicar la fuente o el origen de las mercancías” [2]. Marca protección protege a los nombres, logotipos, imágenes y embalaje. Sin embargo, si un nombre, imagen, u otro activo de marca registrada se convierte en un término genérico, a continuación, se anula la protección de marcas. La Organización Mundial de la Propiedad Intelectual (OMPI) es la autoridad que defina las normas y reglamentos en materia de marcas. La OMPI es la agencia de Naciones Unidas dedicada al uso de la propiedad intelec- tual como medio de estimular la in- novación y la creatividad. 1.7.3. patentes Las patentes protegen el derecho del inventor a

cantes tura y vender una idea. Una patente consiste en un conjunto de derechos exclusivos concedidos por una ernment gobier- soberano a un individuo, grupo de individuos, o de la organización durante un periodo limitado de tiempo. patentes

11-10 Guía SWEBOK® V3.0

son una forma antigua de la protección idea de la propiedad y se remontan al siglo 15. Solicitud de patente implica un registro cuidadoso del proceso que condujo a la invención. Los abogados de patentes son útiles para escribir las reclamaciones de divulgación de patentes de una manera más probable para proteger los derechos del ingeniero soft- ware. Tenga en cuenta que, si las invenciones se realizan durante el curso de un contrato de ingeniería de software, propietario-buque puede pertenecer al empleador o cliente o ser realizada en forma conjunta, en lugar de pertenecer al ingeniero de software. Existen normas relativas a lo que es y no es patentable. En muchos países, el código de software no es patentable, aunque los algoritmos de software pueden ser. solicitudes de patentes presentadas existentes y se pueden buscar en la OMPI. 1.7.4. Derechos de autor La mayoría de los gobiernos en el mundo otorgan derechos exclusivos de una obra original de su creador, por lo general por un tiempo limitado, promulgada como los derechos de autor. los derechos de autor protegen la forma en que se presenta, no una idea de la idea en sí misma. Por ejemplo, pueden proteger la formulación particular de una cuenta de un evento histórico, mientras que el evento en sí no está protegido. Los derechos de autor son a largo plazo y renovable; que datan del siglo 17. 1.7.5. Comercio Misterios En muchos países, un activo intelectual, tales como una fórmula, algoritmo, proceso, diseño, método, patrón, instrumento o recopilación de informa- ción puede ser considerado como un “secreto comercial”, a condición de que estos activos no son generalmente conocidos y pueden proporcionar una empresa alguna ventaja económica. La designación de “secreto comercial” proporciona protección legal si el activo es robado. Esta protección no está sujeta a un límite de tiempo. Sin embargo, si la otra parte se deriva o descubre el mismo bien jurídico, entonces el activo ya no está protegido y la otra parte será también poseen todos los derechos de uso de la misma. 1.7.6. Responsabilidad profesional

Es común que los ingenieros de software para ser concerned con cuestiones de responsabilidad profesional. Como

Ingeniería de Software Práctica Profesional 11-11

un individuo presta servicios a un cliente o empleador, es vital para cumplir con las normas y prácticas generalmente aceptadas, protegiendo así contra las acusaciones o procedimientos de o relacionados con negligencia, negligencia o incompetencia. Para los ingenieros, incluyendo ingenieros de software, responsabilidad profesional está relacionada con la responsabilidad del producto. En virtud de las leyes y normas que rigen en su jurisdicción, los ingenieros pueden ser obligados a rendir cuentas por no seguir totalmente y con plena conciencia práctica recomendada; esto se conoce como “negligencia”. También pueden estar sujetos a las leyes gobiernos ing “responsabilidad objetiva” y ya sea implícita o garantía expresa, en donde, por la venta del producto, se lleva a cabo la Neer niería a garantiza que el producto es tanto adecuado y seguro para su uso. En algunos países (por ejemplo, en los EE.UU.), “connivencia” (la idea de que sólo se podría demandar a la persona que vende el producto) ya no es una defensa contra la acción de responsabilidad. Procesos judiciales por responsabilidad pueden ser sometidos en derecho de daños en los EE.UU. permitiendo que cualquier persona que esté dañado para recuperar su pérdida, incluso si no se hicieron garantías. Debido a que es difícil medir la capacidad o la seguridad de software de traje-, el hecho de tener el debido cuidado se puede utilizar para probar la negligencia por parte de los ingenieros de software. Una defensa contra tal acusación es demostrar que las normas y prácticas generalmente aceptadas fueron seguidos en el desa- rrollo del producto. 1.7.7. Requerimientos legales Los ingenieros de software deben operar dentro de los confines de los marcos jurídicos locales, nacionales e internacionales. Por lo tanto, los ingenieros de software deben estar al tanto de los requisitos legales para • registro y autorización, incluyendo nación exami-, la educación, la experiencia y las necesidades de formación; • acuerdos contractuales; • legalidades no contractuales, como los gobier- responsabilidad Erning; • Información básica sobre el marco jurídico

internacional se puede acceder desde la Organización Mundial del Comercio (OMC).

11-12 Guía SWEBOK® V3.0

1.7.8. Comercio Conformidad

Todos los profesionales de software deben estar al tanto de las restricciones legales a la importación, exportación o reexportación de mercancías, servicios y tecnología en las jurisdicciones en las que trabajan. Las consideraciones incluyen controles de exportación y clasificación, transferencia de bienes, adquisición de licencias gubernamentales necesarias para el uso exterior de hardware y software, servicios y tecnología por país sancionado, empresa o entidades individuales, y las restricciones de importación y deberes. Los expertos en comercio debe ser consultado para una guía detallada cumplimiento. 1.7.9. los delitos informáticos La delincuencia informática se refiere a cualquier crimen, que involucra una computadora, software de ordenador, ordenador NETWORKS, o software incorporado el control de un sis- tema. El ordenador o el software pueden haber sido utilizados en la comisión de un delito o que pueden haber sido el blanco. Esta categoría incluye los delitos de fraude, acceso no autorizado, spam, contenido obsceno u ofensivo, amenazas, acoso, robo de datos personales o secretos comerciales sensibles, y el uso de una computadora para dañar o infiltrarse en otros ordenadores conectados en red y controles automatizados del sistema. Los usuarios de ordenadores y software cometer fraude mediante la alteración de los datos electrónicos para facilitar su activi- dad ilegal. Formas de acceso no autorizado incluyen ing cortar metal, una interceptación, y el uso de los sistemas informáticos de una manera que se oculta de sus dueños. Muchos países tienen leyes separadas para cubrir los delitos cibernéticos, pero a veces ha sido difícil de procesar a los delitos cibernéticos, debido a la falta de estatutos pre precisamente enmarcadas. El ingeniero de software tiene la obligación profesional de considerar la amenaza de la delincuencia informática y para entender cómo el sistema de software protegerá o poner en peligro el software y la información de usuario de acceso accidental o malintencionada, uso, modificación, destrucción, o de la divulgación. 1.8. Documentación

[1 *, c10s5.8] [3 *, c1s5] [5 *, c32] Proporcionar clara, completa y precisa documentación es la responsabilidad de cada ingeniero de software. La idoneidad de la documentación es

Ingeniería de Software Práctica Profesional 11-13

juzgado por diferentes criterios basados en las necesidades de los diversos públicos interesados. Una buena documentación cumple con las normas y directrices aceptadas. En particular, los ingenieros de software deben documentar • hechos relevantes, • los riesgos y las ventajas y desventajas significativas, y • advertencias de consecuencias indeseables o peligrosos de uso o mal uso del software. Los ingenieros de software deben evitar • certificar o aprobar productos inaceptables, • revelar información confidencial, o • falsificación de hechos o datos. Además, los ingenieros de software y sus Los directivos deberían proporcionar importantes son los siguientes docu- mentación para su uso por otros elementos de la organización de desarrollo de software: • requisitos de software especificaciones, documentos de diseño de software, los detalles sobre las herramientas de ingeniería de software, de las especificaciones de prueba de software y los resultados, y detalles sobre los métodos de ingeniería de software adoptados; • problemas encontrados durante el proceso de desa- rrollo. Para los interesados externos (clientes, usuarios, otros) documentación del software debe proporcionar particular • información necesaria para determinar si es probable que para satisfacer las necesidades de los usuarios de los clientes y el software, • Descripción de la caja fuerte, y poco seguro, el uso del software, • Descripción de la protección de la información sensible almacenada o creado por el uso del software, y • identificación clara de advertencias y crítico procedimientos. El uso de software puede incluir la instalación, fun- cionamiento, la administración y el

desempeño de otras funciones por varios grupos de usuarios y personal de apoyo. Si el cliente adquirirá la propiedad

11-14 Guía SWEBOK® V3.0

del código fuente del software o el derecho a modificar el código, el ingeniero de software debe proporcionar documentación de las especificaciones funcionales, el diseño del software, el conjunto de pruebas, y el entorno operativo es preciso proceder para el software. La longitud mínima de los documentos de tiempo se debe mantener es la duración del ciclo de vida de los productos de software o el tiempo requerido por los requisitos pertinentes orga- zational o reglamentarias. 1.9. Análisis compensación [3 *, c1s2, c10] [9 *, c9s5.10] Dentro de la práctica de la ingeniería de software, un ingeniero de software a menudo tiene que elegir entre soluciones alternativas problemas. El resultado de estas opciones es determinado por la evaluación profesional del software niería de Neer de los riesgos, los costos y beneficios de las alternativas, en cooperación con las partes interesadas. Evaluación del ingeniero de software se llama “análisis de equilibrio”. El análisis de relaciones de intercambio permite sobre todo la identificación de compe- ING y requisitos de software complementarios con el fin de dar prioridad a la última serie de requisitos que definen el software que se construirá (consulte Requisitos de Negociación de los requisitos de software KA y determinación y negocia- ción de los requisitos en el KA Software de Gestión de inge- niería). En el caso de un proyecto de Desa- ción de software en curso que se retrasa o por encima del presupuesto, análisis de compensación se realiza a menudo para decidir qué requisitos de software pueden estar relajado o se ha caído debido a los efectos de la misma. Un primer paso en un análisis de equilibrio está establecimientos ing objetivos de diseño (ver diseño de ingeniería en el Fundamentos de Ingeniería KA) y establecer la importancia relativa de estos objetivos. Esto permite la identificación de la solución que más se aproxime a esos objetivos; esto significa que la forma en que los objetivos se expresan es de importancia crítica. Los objetivos de diseño pueden incluir la reducción al mínimo de los costos monetarios y la maximización de la fiabilidad, rendimiento, o algún otro criterio sobre una amplia gama de dimensiones. Sin embargo, es difícil formular un análisis de equilibrio de

costo contra el riesgo, especialmente donde la producción primaria y los costos basados en el riesgo ary de segunda deben comercializarse uno contra el otro.

Ingeniería de Software Práctica Profesional 11-15

Un ingeniero de software debe realizar un análisis de equilibrio de una manera ética de manera -en particular por ser objetiva e imparcial la hora de seleccionar los criterios para la comparación de soluciones a los problemas alternativos y en la asignación de pesos o importancia a estos criterios. Cualquier conflicto de intereses debe ser revelada en la delantera. 2. Grupo de Dinámica y Psicología trabajos de ingeniería se llevó a cabo muy a menudo en el contexto del trabajo en equipo. Un ingeniero de software debe ser capaz de interactuar de manera cooperativa y constructivamente con otros para determinar en primer lugar y luego satisfacer tanto las necesidades y expectativas. El conocimiento de la dinámica de grupo y la psicología es un activo en la interacción con los clientes, compañeros de trabajo, proveedores y subordinados para resolver problemas de ingeniería de software. 2.1. Dinámica de trabajo en equipos / grupos [3 *, c1s6] [9 *, c1s3.5, c10] Los ingenieros de software deben trabajar con los demás. Por un lado, trabajan internamente en los equipos de ingeniería; por el contrario, trabajan con tomers cliente central, los miembros del público, reguladores y otras partes interesadas. Realización de los equipos de los que demuestran una calidad constante del trabajo y el progreso hacia las metas-son cohesivas y poseen una atmósfera de cooperación, honesta y enfocada. objetivos individuales y de equipo están alineados de tal manera que los miembros de forma natural se comprometan y se sientan dueños de resultados compartidos. Equipo miembros facilitan esta atmósfera por ser intelectualmente honesto, haciendo uso del pensamiento de grupo, admitiendo la ignorancia, y acknowledg- errores ing. Ellos comparten la responsabilidad, recompensas, y la carga de trabajo de manera justa. Ellos se encargan de comuni- carse con claridad, directamente entre sí y en el docu- mentos, así como en código fuente, por lo que informa- ción es accesible a todos. Peer comentarios sobre los productos de trabajo se enmarcan en una forma constructiva y no personal (ver revisiones y auditorías de la

calidad del software KA). Esto permite que todos los miem- bros que persiguen un ciclo de mejora continua y el crecimiento sin riesgo personal. En general, los miembros de equipos cohesivos demuestran respeto por los demás y su líder.

11-16 Guía SWEBOK® V3.0

Un punto a destacar es que el software de inge- nieros deben ser capaces de trabajar en entornos multidisciplinares y en variados campos de aplicación. Dado que el software de hoy está en todas partes, desde un teléfono a un coche, el software está afectando a la vida de las personas más allá del concepto más tradicional de software hecho para la gestión de la información en un entorno empresarial. 2.2. cognición individual [3 *, c1s6.5] [5 *, c33] Ingenieros deseo de resolver los problemas. La capacidad de resolver problemas con eficacia y eficiencia es lo que se esfuerza para todos los ingenieros. Sin embargo, los límites y los procesos de la cognición individual afectan la resolución de proble- ma. En la ingeniería de software, sobre todo debido a la naturaleza altamente abstracta de software en sí, la cognición individual juega un papel muy importante en la resolución de problemas. En general, de un individuo (en particular, ) La capacidad de un ingeniero de software para descomponer un problema con creatividad y desarrollar una solución puede ser inhibida por • • • •

la necesidad de un mayor conocimiento, supuestos subconscientes, volumen de datos, miedo al fracaso o la consecuencia de la falta, • cultura, eitherapplicationdomainor organizacional, • la falta de capacidad de expresar el problema, • percibida ambiente de trabajo, y • el estado emocional del individuo. El impacto de estos factores inhibidores se puede reducir mediante el cultivo de buenos hábitos de resolución de problemas que minimicen el impacto de suposiciones erróneas. La capacidad de concentrarse es de vital importancia, ya que es la humildad intelectual: ambos permiten un Neer niería de software para suspender las consideraciones personales y con- sultado con los demás libremente, lo que es especialmente importante cuando se trabaja en equipo. Hay una serie de métodos básicos ingenieros utilizan para facilitar la resolución de problemas (véase el problema Solv- ing técnicas en los Fundamentos de Informática

KA). El desglose de los problemas y les resolución de una sola pieza a la vez reduce la sobrecarga cognitiva. Aprovechando la curiosidad profesional y la búsqueda del desarrollo profesional continuo

Ingeniería de Software Práctica Profesional 11-17

mediante la formación y estudio añadir habilidades y El conocimiento de la cartera del ingeniero de software; la lectura, la creación de redes, y experimentando con nuevas herramientas, técnicas y métodos son válidos todos los medios de desarrollo profesional. 2.3. Tratar con el problema Complejidad [3 *, c3s2] [5 *, c33] Muchos, si no la mayoría, blemas de ingeniería de software blemas son demasiado complejos y difíciles de abordar en su conjunto o para ser abordado por los ingenieros de software individuales. Cuando surgen tales circunstancias, los medios habituales para adoptar es el trabajo en equipo y el problema de la descomposición (véase el problema técnicas de resolución en los Fundamentos de Informática KA). equipos trabajar juntos para resolver los problemas más complejos y grandes mediante el intercambio de cargas y N ° de dibujo en el conocimiento y la creatividad de cada uno. Cuando los ingenieros de software trabajan en equipos, puntos de vista dife- rentes y habilidades de los ingenieros individuales se complementan entre sí y ayudar a construir una solución que sea de otro modo difícil de conseguir. Algunos ejemplos de trabajo en equipo espe- CIFIC a la ingeniería de software son la programación en parejas (ver Métodos ágiles en los modelos de ingeniería de software y métodos KA) y la revisión de código (ver revisiones y auditorías de la calidad del software KA). 2.4. La interacción con las partes interesadas [9 *, c2s3.1] El éxito de una empresa de ingeniería de software depende de las interacciones positivas con los titulares de stake-. Deben proporcionar apoyo, informa- ción, y la retroalimentación en todas las etapas del proceso del ciclo de vida del software. Por ejemplo, durante las primeras etapas, es fundamental para identificar todas las partes interesadas y descubrir cómo el producto les afecta, por lo que la definición suficiente de la parte interesada los requisitos puede ser adecuada y completamente capturado.

Por lo tanto, es vital para mantener abierta la comunicación y pro- ductiva con las partes interesadas para la duración de la vida útil del producto de software. 2.5. Superación de la incertidumbre y la ambigüedad [4 *, c24s4, c26s2] [9 *, c9s4] Al igual que con los ingenieros de otros campos, los ingenieros de software a menudo deben atender y resolver la incertidumbre y la ambigüedad, mientras que la prestación de servicios y el desarrollo de productos. El ingeniero de software debe atacar y reducir o eliminar cualquier falta de claridad que es un obstáculo para la realización de trabajos. A menudo, la incertidumbre es simplemente un reflejo de la falta de conocimiento. En este caso, la investigación mediante el recurso a fuentes formales tales como libros de texto y revistas profesionales, entrevistas con ERS stakehold-, o consulta con los compañeros y compañeros puede superarla. Cuando la incertidumbre o ambigüedad no pueden ser excesivamente sido fácil, los ingenieros de software u organizaciones pueden optar por considerar como un riesgo del proyecto. En este caso, las estimaciones de trabajo o de precios se ajustan para mitigar el costo anticipado de hacer frente a ella (véase Gestión de Riesgos en el KA Software Engineering Management). 2.6. Tratar con entornos multiculturales [9 *, c10s7]

Durante el desarrollo, los interesados pueden provide retroalimentación sobre las especificaciones y / o las primeras versiones del software, cambio de prioridad, así como la clarificación de requisitos detallados o nuevo software. Por último, durante el mantenimiento de software y hasta el final de su vida útil, los interesados Pro- retroalimentación vide en evolución o nuevos requisitos que los informes de problemas así para que el software puede ser ampliado y mejorado.

11-18 Guíamulticulturales SWEBOK® V3.0 entornos

pueden tener un impacto en la dinámica de un grupo. Esto es especialmente cierto cuando el grupo está separado geográficamente o comunicación es poco frecuente, ya que tales ración sepa- eleva la importancia de cada contacto. La comunicación intercultural es aún más difeficult si la diferencia de husos horarios que la comunicación oral de menos frecuentes. ambientes multiculturales son bastante frecuentes en la ingeniería de software, quizás más que en otros campos de la ingeniería, debido a la fuerte tendencia a la externalización internacional y el envío fácil de componentes de software de forma instantánea en todo el mundo. Por ejemplo, es bastante común para un proyecto de software que se dividirá en pedazos través de las fronteras nacionales y culturales, y también es bastante común para un equipo de proyecto de software a constan de personas de diversos orígenes culturales. Para un proyecto de software sea un éxito, los miembros del equipo deben alcanzar un nivel de tolerancia,

Ingeniería de Software Práctica Profesional 11-11

reconociendo que algunas reglas dependen de las normas etal ciedades y que no todas las sociedades derivan las mismas soluciones y expectativas. Esta tolerancia y comprensión ing acompañante pueden ser facilitadas por el apoyo de la dirección y gestión. comunicaciones más frecuentes, incluyendo las reuniones cara a cara, puede ayudar a puerta mitiga las divisiones geográficas y culturales, promover la cohesión, y aumentar la productividad. Además, al ser capaz de comunicarse con sus compañeros en su lengua materna podría ser muy beneficioso. 3. Habilidades de comunicación Es vital que un ingeniero de software se comunican bien, tanto de forma oral como la lectura y escritura. Suc logro cessful de los requisitos de software y plazos depende del desarrollo de sub clara de pie entre el ingeniero de software y clientes, supervisores, compañeros de trabajo, y abastecedores ERS. la resolución de problemas óptima es posible gracias a la capacidad de investigar, comprender y resumir la información. la aceptación del producto del cliente y el uso de productos seguros dependen de la provisión de capacitación y la documentación pertinente. De ello se desprende que el propio éxito de la carrera del ingeniero de software se ve afectada por la capacidad para proporcionar de forma coherente la comunicación oral y escrita de forma efectiva ya tiempo. 3.1. Leer, comprender y resumir [5 *, c33s3] Los ingenieros de software son capaces de leer y entienda material técnico. material técnico incluye libros de referencia, manuales, documentos de investigación, y el código fuente del programa. La lectura es no sólo una forma primaria de las habilidades de ING improv-, sino también una manera de reunir informa- ción necesaria para la realización de los objetivos de ingeniería. Un ingeniero de software tamiza a través acumulada información, filtrando las piezas que serán más útiles. Los clientes pueden solicitar que un ingeniero de software se resumen los resultados de dicha recopilación de información

para ellos, lo que simplifica o explicarla de manera que puedan tomar la decisión final entre soluciones de la competencia. La lectura y la comprensión de código fuente es también un componente de recopilación de información y resolución de problemas. Al modificar, extender,

11-12 Guía SWEBOK® V3.0

o software de reescritura, es fundamental para comprender tanto su implementación derivado directamente del código presentado y su diseño, que a menudo se debe inferirse. 3.2. Escritura [3 *, c1s5] Los ingenieros de software son capaces de producir productos escritos como es requerido por las peticiones del cliente o la práctica generalmente aceptado. Estos productos escritos pueden incluir código fuente, los planes de proyectos de software, documentos de requerimientos de software, análisis de riesgos, documentos de diseño de software, planes de pruebas de software, manuales de usuario, informes técnicos y evaluaciones, las justificaciones, diagramas y gráficos, y así sucesivamente. Escritura clara y concisa es muy importante porque a menudo es el principal método de comunicación entre las partes pertinentes. En todos los casos, los productos de ingeniería de software escrito deben ser escritos para que sean accesibles, comprensibles y relevantes para su público (s) previsto. 3.3. Equipo y Comunicación Grupo [3 *, c1s6.8] [4 *, c22s3] [5 *, c27s1] [9 *, c10s4] La comunicación efectiva entre los miembros del equipo y de grupo es esencial para un esfuerzo de ingeniería de software de colaboración. Los interesados deben ser consultados, se deben tomar decisiones, y deben ser generados planes. Cuanto mayor sea el número de miembros del equipo y de grupo, mayor es la necesidad de comunicar. El número de vías de comunicación, SIN EMBARGO, crece cuadráticamente con la adición de cada miembro del equipo. Además, los miembros del equipo no es probable que comunicarse con cualquier per- recibi- do que ser eliminado de ellos por más de dos grados (niveles). Este problema puede ser más grave cuando se esfuerza u organizaciones de ingeniería de software se distribuyen a través de fronteras nacionales y con- tinental. Algún tipo de comunicación puede llevarse a cabo por escrito. documentación de software es un sustituto común para la interacción directa. El correo electrónico es otra pero, aunque es

útil, no siempre es suficiente; También, si uno envía demasiados mensajes, se hace difícil identificar la información importante. Cada vez más, las organizaciones están utilizando la empresa

Ingeniería de Software Práctica Profesional 11-13

herramientas de colaboración para compartir información. Otras medidas, además, el uso de almacenes de información electrónicos, accesibles a todos los miembros del equipo, para las políticas organiza- cionales, normas, procedimientos comunes de la ingeniería, y la información específica del proyecto, puede ser más beneficioso. Algunos equipos de ingeniería de software se centran en la interacción cara a cara y promover dicha interacción por el arreglo de oficinas. Aunque las oficinas privadas mejoran la productividad individual, implantación común de los miembros del equipo en formas físicas o virtuales y proporcionar áreas de trabajo comunal que es importante para los esfuerzos de colaboración. 3.4. Habilidades de presentación [3 *, c1s5] [4 *, c22] [9 *, c10s7-c10s8] Los ingenieros de software confían en sus habilidades de presentación durante los procesos del ciclo de vida del software. Por ejemplo, durante los requisitos de software

fase, los ingenieros de software puede caminar a los clientes y compañeros de equipo a través de los requisitos de software y llevar a cabo los requisitos formales reseñas (véanse los requisitos críticas en el software de los requisitos KA). Durante y después del diseño de software, la construcción de software y mantenimiento de software, ingenieros de software llevan los comentarios, walk-through de productos (véase comprobación y actuaciones en la calidad del software KA), y la formación. Todo esto requiere la capacidad de presentar información técnica a los grupos y solicitar ideas o comentarios. La capacidad del ingeniero de software para transmitir conceptos de manera efectiva en una presentación, por lo tanto influye en la aceptación del producto, gestión y atención al cliente; sino que también influye en la abil- dad de las partes interesadas a comprender y ayudar en los esfuerzos de producto. Este conocimiento tiene que ser archivados en forma de diapositivas, el conocimiento contra escritura hasta, white papers técnicos, y cualquier otro material utilizado para la creación de conocimiento.

11-14 Guía SWEBOK® V3.0

1.3. La naturaleza y la función de las Sociedades Profesionales 1.4. La

c1s9 c1s6-

2.2. Individual Cognición 2.3. 2.3 Tratar con problema Complejidad 2.4. Interactuando con Las partes interesadas

c8

c1s1c1s2

c1s2

c35s1

JustaLey de 2009 [9 *]

*

Mugirre 2006 [7 *] točkey 2004 [8 *]

c33

c32s6

c10s8

c1s1.1

c1s2

c1

c7

1.7. Asuntos C6, C11 legales 1.8. Documentación c10s5.8 1.9. Análisis compensació 2. nGrupo de Dinámica y Psicología 2.1. Dinámica de trabajo en equipos / grupos

c1s2

c1s4.1, c1s5.1c1s5.4

naturaleza y la c5s3.2, función de las c10s2.1 normas de ingeniería de 1.5. Económico software Impacto de Software 1.6. Contratos de trabajo

yoAEE-CS / ACM 1999 [6 *]

1.2. Códigos de Ética y Conducta Profesional

McConnell 2004 [5 *]

1. Profesionalismo 1.1. Acreditación, certificación,y Licencias

SommervilLe 2011 [4 *]

Larva del moscard ónt et al. 2000 [1 Voland 2003 *] *] [3

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

c5s4 c5s3c1s5 c1s2, c10

c1s10 c32 c9s5.10

c1s3.5, c10

c1s6 c1s6.5

c33

c3s2

c33 c2s3.1

2.5. Superación de la incertidumbre y la ambigüedad 2.6. Tratar con

c24s4, c26s2

JustaLey de 2009 [9 *] c10s7

3. Habilidades de Comunicación 3.1. Leer, comprender y resumir 3.3. Equipoy el Grupo Comunicación 3.4. Habilidades de presentación

Mugirre 2006 [7 *] točkey 2004 [8 *]

c9s4

entornos multiculturales

3.2. Escritura

yoAEE-CS / ACM 1999 [6 *]

McConnell 2004 [5 *]

SommervilLe 2011 [4 *]

Larva del moscard ónt et al. 2000 [1 Voland 2003 *] [3 *]

Ingeniería de Software Práctica Profesional 11-15

c33s3 c1s5 c1s6.8

c22s3

c1s5

c22

c27s1

c10s4 c10s7c10s8

11-16 Guía SWEBOK® V3.0

LECTURAS

Referencias

Gerald M. Weinberg, La psicología de Programación [10].

[1 *] F. Bott et al., Cuestiones profesional en Ingeniería de Software, 3ª ed., Taylor & Francis, 2000.

Este fue el primer libro importante para hacer frente programa- ción como un esfuerzo individual y de equipo y se convirtió en un clásico en el fielre. Kinney y Lange, PA, Ley de Propiedad Intelectual para el negocio Abogados [11]. Este libro cubre las leyes de propiedad intelectual en los EE.UU.. No sólo habla de lo que el derecho de propiedad intelectual es; También explica por qué se ve la forma en que lo hace.

[2] Diccionario Colegiado de Merriam-Webster, ed 11., 2003. [3 *] G. Voland, Ingeniería de Diseño, 2ª ed., Prentice Hall, 2003. [4 *] I. Sommerville, Ingeniería de Software, 9ª ed., Addison-Wesley, 2011. [5 *] S. McConnell, código completo, 2ª ed., Microsoft Press, 2004. [6 *] IEEE / ACM Fuerza de Tarea Conjunta de CS Software Ética de ingeniería y prácticas profesionales, “Software Ingeniería Código de Ética y Práctica Profesional (Versión 5.2),” 1999; www.acm.org/serving/se/code.htm. [7 *] JW Moore, La Hoja de Ruta de Ingeniería de Software: Una guía basada en estándares, Wiley-IEEE Computer Society Press, 2006. [8 *] S. Tockey, Retorno de software: maximizar el retorno de su inversión en software, Addison-Wesley, 2004. [9 *] RE Fairley, gestionar y liderar proyectos de software, Wiley-IEEE Computer Society Press, 2009. [10] GM Weinberg, La Psicología de la Programación: Plata Edición de aniversario, Dorset House, 1998. [11] Kinney y Lange, PA, Ley de la Propiedad Intelectual de negocio Abogados, Thomson West, 2013.

Ingeniería de Software Práctica Profesional 11-17

CAPÍTULO 12 ECONOMÍA INGENIERÍA DE SOFTWARE SIGLAS EVM TIR

Gestion del valor ganado Tasa interna de retorno

TREMA

Tasa aceptable mínimo de Regreso

SDLC SPLC

Ciclo de vida del desarrollo de programasdel ciclo de vida del Software

ROI ROCE

producto Retorno de la Inversión Rendimiento del capital invertido

TCO

Costo total de la propiedad

INTRODUCCIÓN la economía de ingeniería de software se trata de decisiones de ING MAK- relacionados con la ingeniería de software en un contexto empresarial. El éxito de un software PRODUCIRSE UCT, el servicio, y la solución depende de una buena gestión de Em- presas. Sin embargo, en muchas empresas y organizaciones, las relaciones comerciales de software para el desarrollo de software e ingeniería siguen siendo vagos. Esta área de conocimiento (KA) proporciona una visión general sobre la economía de ingeniería de software. La economía es el estudio de los valores, costos, recursos, y su relación en un contexto o situación dada. En la disciplina de la niería de software niería, actividades tienen costos, pero el software resultante tiene atributos económicos. la economía de ingeniería de software proporciona una manera de estudiar los atributos de los procesos de software y software de una manera sistemática que los relaciona con las medidas económicas. Estas medidas económicas pueden ser pesados y analizados al tomar las decisiones que están dentro del alcance de un software de orga- nización y los que están dentro del alcance integral de toda una

producción o adquisición de negocios. la economía de ingeniería de software se ocupa de la alineación de las decisiones técnicas de software con

los objetivos de negocio de la organización. En todos los tipos de organizaciones-sea “con fines de lucro”, “sin fines de lucro,” o gubernamental, esto se traduce en forma sostenible permanecer en el negocio. En las organizaciones con fines de lucro “” Esto, además, se relaciona con achiev- ing un retorno tangible de los invertidos en capital los activos y el capital empleado. Esta KA ha sido formulado de una manera para hacer frente a todo tipo de organizaciones independientes de foco, cartera de productos y servicios, o la propiedad del capital y las restricciones de la tributación. Decisiones como “¿Hay que utilizar un compo- nente específico?” Puede parecer fácil desde el punto de vista técnico, pero pueden tener graves consecuencias sobre la viabilidad empresarial de un proyecto de software y el producto resultante. A menudo, los ingenieros se preguntan si estas preocupaciones se aplican en absoluto, ya que son “sólo los ingenieros.” Análisis económico y la toma de decisiones son importantes consideraciones de ingeniería porque los ingenieros son capaces de evaluar

las decisiones tanto técnicamente como desde un punto de vista comercial. El contenido de esta área de conocimiento son importantes ics de alta para los ingenieros de software a tener en cuenta, incluso si nunca realmente están involucrados en concreto de Em- presas de decisiones; van a tener una visión cabal de las cuestiones de negocios y el papel racio técnicos consideraciones juegan en la toma de decisiones de negocio. Muchas de las propuestas de ingeniería y decisiones, tales como hacer frente a comprar, tienen profundos impactos económicos intrínsecos que deben ser considerados de manera explícita. Esta KA cubre primero las fundaciones, minology clave ter-, conceptos básicos y las prácticas comunes de la economía de ingeniería de software para indicar la forma en la toma de decisiones en ingeniería de software incluye o debe incluir un negocio perspec- tiva. A continuación, proporciona una perspectiva del ciclo de vida, destaca la gestión del riesgo y la incertidumbre, y muestra cómo se utilizan los métodos de análisis económico. Algunas consideraciones prácticas terminar el área El conocimiento. 12-1

12-2

Guía SWEBOK® V3.0

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

Software Economía Ingeniería 12-3

DISTRIBUCIÓN DE TEMAS PARA ECONOMÍA INGENIERÍA DE SOFTWARE

1.2. Contabilidad

El desglose de temas para el Software Ingeniería Economía KA se muestra en la figura 12.1.

La contabilidad es parte de las finanzas. Permite a las personas cuyo dinero está siendo utilizado para dirigir una organización

[1 *, c15]

1. Fundamentos de Ingeniería de Software Economía 1.1. Financiar [1 *, c2] Finanzas es la rama de la economía que se ocupan de cuestiones tales como la asignación, administración, adquisición, y la inversión de los recursos. La financiación es un elemento de todas las organizaciones, incluidas las organizaciones de ingeniería de software. El campo de las finanzas se ocupa de los conceptos de tiempo, dinero, riesgo, y cómo se relacionan entre sí. También se ocupa de cómo se gasta el dinero y geted presu-. finanzas corporativas se ocupa de pro- Viding los fondos para las actividades de una organización. En general, se trata de equilibrar el riesgo y la capacidad de utilidades, al intentar maximizar la riqueza de una organiza- ción y el valor de sus acciones. Esto es válido sobre todo para las organizaciones “con fines de lucro”, pero también se aplica a los “sin fines de lucro” organizaciones. Este último necesita recursos financieros para garantizar la sostenibilidad, aunque no es la orientación de beneficio tangible. Para ello, una organización debe • identificar los objetivos de la organización, los horizontes de tiempo, factores de riesgo, consideraciones de impuestos, y las limitaciones financieras; • identificar e implementar la estrategia de Ness Busi- apropiado, como el que las decisiones de cartera y de inversión a tomar, cómo gestionar el flujo de caja, y dónde obtener los fondos; • medir el desempeño financiero, tales como el flujo de caja y el retorno de la inversión (véase la sección 4.3, Retorno de la Inversión), y tomar acciones correctivas en caso de desviación de los objetivos y la estrategia.

12-4

Guía SWEBOK® V3.0

para conocer los resultados de su inversión: sacaron los beneficios que se esperaban? En las organizaciones “con fines de lucro”, esto se relaciona con el retorno de la inversión tangible (ver sección 4.3, Retorno de la Inversión), mientras que en “sin fines de lucro” y las organizaciones gubernamentales, así como organizaciones “con fines de lucro”, que se traduce en forma sostenible permanecer en el negocio. La función principal de la contabilidad es medir el rendimiento financiero real de la organiza- ción y para com- municar información financiera sobre una entidad de negocio para las partes interesadas, como los accionistas, auditores financieros e inversores. La comunicación es generalmente en la forma de estados financieros que muestran en términos monetarios los recursos económicos que deben ser controlados. Es importante seleccionar la información adecuada que sea relevante y fiable para el usuario. La información y su distribución están parcialmente rigen por las políticas de gestión de riesgos y de gobierno. Los sistemas de contabilidad son también una rica fuente de datos históricos para estimar. 1.3. Controlador [1 *, c15] El control es un elemento de las finanzas y una contabilidad. Controladora implica medir y correcta- ing el desempeño de las finanzas y la contabilidad. Se asegura de que los objetivos y planes de la organización se llevan a cabo. El control de costos es una rama especia- espe- de controlar utilizado para detectar varianzas de los costes reales de los costes previstos. 1.4. Flujo de fondos [1 *, c3] El flujo de caja es el movimiento de dinero que entra o sale de un negocio, proyecto o producto financiero durante un período determinado. Los conceptos de instancias de flujo de caja y las corrientes de flujo de efectivo se utilizan para describir la perspectiva de negocio de una propuesta. Para tomar una decisión de negocios significativa sobre cualquier propuesta específica, tendrá que ser evaluado desde una perspectiva empresarial dicha propuesta. En una propuesta para desarrollar y poner en marcha el producto X, el pago por nuevas licencias de software es un ejemplo de una instancia de flujo de caja ing outgo-. tendría

que ser gastado para llevar a cabo esa propuesta dinero. Los ingresos por ventas de producto X en el mes 11 después de su lanzamiento al mercado es un ejemplo de un flujo de caja entrante

Software Economía Ingeniería 12-5

Figura 12.2. Un Diagrama de Flujo de Caja

ejemplo. El dinero iba a venir a causa de llevar a cabo la propuesta. La corriente de flujo de efectivo término se refiere al conjunto de instancias de flujo de efectivo con el tiempo que son causados por la realización de alguna propuesta dada. El flujo de caja es, en efecto, el cuadro financiero completo de esa propuesta. ¿Cuánto dinero se apaga? ¿Cuándo se apaga? ¿Cuánto dinero entra? ¿Cuándo se presenta? Simplemente, si la corriente de flujo de efectivo de Propuesta A es más deseable que la corriente de flujo de caja para la Propuesta B, entonces todas las demás cosas son iguales, la organización es ter BET de la realización de la propuesta A de la Propuesta B. Por lo tanto, el flujo de efectivo stream es un insumo importante para las decisiones de inversión. Un ejemplo de flujo de efectivo es una cantidad específica de dinero que fluye hacia dentro o fuera de la organización en un momento específico, como consecuencia directa de alguna actividad. Un diagrama de flujo de caja es una imagen de una corriente de flujo de efectivo. Se le da al lector una visión general de la situación financiera de la organización tema o proyecto. La figura 12.2 muestra un ejemplo de un diagrama de flujo de caja para una propuesta. 1.5. Proceso de toma de decisiones [1 *, c2, c4] Si asumimos que las soluciones candidatas a resolver un problema técnico determinado

igualmente bien, ¿por qué se elige el cuidado organización cuál? La respuesta es que por lo general hay una gran diferencia en los costes e ingresos de los diferentes

12-6

Guía SWEBOK® V3.0

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

Software Economía Ingeniería 12-7

Figura 12.3. El proceso de toma de decisiones de negocio básico

ninguno de los pasos se omiten o reducirse. También es importante entender que este mismo proceso se aplica a todos los niveles de toma de decisiones: de una decisión tan grande como la determinación de si un proyecto de software se debe hacer en absoluto, a una decisión sobre una estructura de algoritmo o de datos a utilizar en un módulo de software. La diferencia es la forma económicamente sig- sig- es la decisión y, por lo tanto, la cantidad de esfuerzo debe ser invertido en la toma de esa decisión. La decisión a nivel de proyecto es económicamente sig- SIG-y probablemente justifica un nivel relativamente alto de esfuerzo para tomar la decisión. La selección de un algoritmo es a menudo mucho menos financieramente no puede signifi- y garantiza un nivel mucho más bajo de lo posible para tomar la decisión, a pesar de que el mismo proceso de toma de decisiones básica está siendo utilizado. Más a menudo que no, una organización puede llevar a cabo más de una propuesta si así lo quisiera, y por lo general no son relaciones importantes entre las propuestas. Tal vez Propuesta Y sólo puede llevarse a cabo si la propuesta X también se lleva a cabo. O tal vez Propuesta P no puede llevarse a cabo si Propuesta Q se lleva a cabo, ni podía Q llevarse a cabo si P fuera. Las opciones son mucho más fáciles de hacer cuando hay caminos -por ejemplo que se excluyen mutuamente, ya sea A o B o C o lo que sea que se elija. En decisiones previas pelado, se recomienda convertir cualquier conjunto de propuestas, junto con sus

1.6. Valuació n

[1 *, C5, C8]

diversas interrelaciones, en un conjunto de alternativas sive excluyen mutuamente. La elección puede hacerse entonces entre estas alternativas.

12-8

Guía SWEBOK® V3.0 En un sentido abstracto,

el Cess -sea decisiones financieras pro de toma de toma de decisiones o de otro- se trata de maximizar el valor. La alternativa que maximiza el valor total siempre debe ser elegido. Una base financiera para la comparación basada en valores se comparan dos o más flujos de efectivo. Varias bases de comparación están disponibles, incluyendo • • • • •

valor actual valor futuro anual equivalente tasa interna de retorno (Descuento) periodo de recuperación.

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

Software Economía Ingeniería 12-9

1.7. Inflació n

[1 *, c13]

La inflación se describen las tendencias a largo plazo de los precios. La inflación significa que las mismas cosas cuestan más que antes. Si el horizonte de planificación de una decisión de negocios es más de unos pocos años, o si la tasa de inflación es más de un par de puntos porcentuales por año, puede causar cambios notables en el valor de una propuesta. Por lo tanto, el valor del tiempo actual necesita ser ajustado por inflación y las tasas también para las fluctuaciones del tipo de cambio. 1.8. Depreciación [1 *, c14] La depreciación implica la difusión del costo de un activo tangible a través de una serie de períodos de tiempo; que se utiliza para determinar cómo las inversiones en activos talized capi- se cargan contra los ingresos durante varios años. La depreciación es una parte importante de la determinación después de impuestos de flujo de caja, que es criti- cal para abordar con precisión los beneficios y los impuestos. Si un producto de software se va a vender después de que los costes de desa- rrollo se incurren, los costos deben ser activadas y depreciadas durante períodos de tiempo posteriores. El gasto de depreciación para cada período de tiempo es el costo capitalizado de desarrollar el software dividida a través del número de periodos en los que se venderá el software. Una propuesta de proyecto de software puede ser comparado con otro software y propuestas nonsoftware o para opciones alternativas de inversión, por lo que es importante para deter- minar cómo esas otras propuestas serían ciados depre- y cómo se calcula ganancias. 1.9. Impuestos [1 *, c16, c17] Los gobiernos cobran impuestos para financiar los gastos que la sociedad necesita, pero que ninguna organiza- ción invertiría en. Las empresas tienen que pagar impuestos sobre la renta, que puede tomar una parte sustancial de la

1.10. Valor temporal del dinero

[1 *, c5, c11]

utilidad bruta de una corporación. Un análisis de decisión que no tiene en cuenta los impuestos puede conducir a una mala elección. Una propuesta con una alta ganancia antes de impuestos no se parecerá casi tan rentable en términos posttax. Sin tener en cuenta los impuestos también puede conducir a unrealistically altas expectativas sobre la rentabilidad podría ser un producto propuesto.

12-10 Guía SWEBOK® V3.0

Uno de los conceptos más fundamentales en las finanzas y, por tanto, en los negocios decisiones- es que el dinero tiene valor temporal: su valor cambia con el tiempo. Una cantidad específica de dinero en este momento casi siempre tiene un valor diferente que la misma cantidad de dinero en algún otro momento. Este con- cepto ha estado presente desde la historia humana registrada más temprana y es comúnmente conocida como valor tiempo-. Con el fin de comparar las propuestas o elementos lio portfo-, deben ser normalizados en el costo, valor, y el riesgo para el valor actual neto. variaciones de cambio de divisas a través del tiempo hay que tener en cuenta sobre la base de los datos históricos. Esto es Particularmente importante en la evolución transfronteriza de todo tipo. 1.11. Eficiencia [2 *, c1] La eficiencia económica de un proceso, actividad o tarea que es la relación entre los recursos consumidos efectivamente a los recursos previstos para ser consumidos o deseado para ser consumidos en el cumplimiento del proceso, actividad o tarea. Eficiencia significa “hacer las cosas bien.” Un comportamiento eficiente, como un comportamiento efectivo, entrega resultados, pero mantiene el esfuerzo necesario a un mínimo. Los factores que pueden afectar la eficiencia en ingeniería de software incluyen dad producto complejidad, requisitos de calidad, la presión del tiempo, la capacidad del proceso, la distribución de equipo, interrupciones, la rotación característica, las herramientas y lenguaje de programación. 1.12. Eficacia [2 *, c1] La eficacia es acerca de tener impacto. Es la relación entre los objetivos alcanzados a objetivos definidos. Eficacia significa “hacer las cosas bien.” La eficacia sólo se fija en si se alcanzan los objetivos definidos, y no en la forma en que se alcanzan. 1.13. Productividad [2 *, c23] La productividad es la relación de la salida sobre la entrada de una perspectiva económica. La salida es el valor

Software Economía Ingeniería 12-11

entregado. Entrada abarca todos los recursos (por ejemplo, esfuerzo) pasaron a generar la salida. Productividad com- eficiencia y eficacia combina desde una perspectiva orientada de valor: la maximización de la productividad es sobre la generación de mayor valor con menor consumo de recursos.

desde la gestión de ellos individualmente.”2 Los programas se utilizan a menudo para identificar y gestionar las diferentes entregas a un solo cliente o mercado en un horizonte de tiempo de varios años.

2. Ciclo de Vida Economía

Los portafolios son “proyectos, programas, subcarteras y operaciones gestionadas como un grupo para alcanzar los objetivos estratégicos.” 3 carteras se utilizan para agrupar y gestionar simultáneamente todos los activos dentro de una línea de negocio o de la organización. Mirando a una totalidad de la cartera se asegura de que los impactos de las decisiones son consideradas, tales como la asignación de recursos a un proyecto específico, lo cual significa que los mismos recursos no están disponibles para otros proyectos.

2.1. Producto

[2 *, c22] [3 *, c6]

Un producto es un bien económico (o de salida) que se crea en un proceso que transforma factores de productos (o entradas) a una salida. Cuando se vende, un pro- ducto es un entregable que crea un valor y una experiencia para sus usuarios. Un producto puede ser una combinación de sistemas, soluciones, materiales, y servicios entregados internamente (por ejemplo, en casa de la solución IT) o externamente (por ejemplo, software aplicabilidad ción), ya sea tal cual o como un componente para otro producto (por ejemplo, , software embebido). 2.2. Proyecto [2 *, c22] [3 *, c1] Un proyecto es “un esfuerzo temporal emprendido para crear un producto único, servicio o resultado” .1 En la ingeniería de software, diferentes tipos de proyectos se distinguen (por ejemplo, el desarrollo de productos, servicios externalizados, mantenimiento de software, creación de servicios, etc. ). Durante su ciclo de vida, un producto de software puede requerir muchos proyectos. Por ejemplo, durante la fase de concepción del producto, un proyecto podría llevarse a cabo para determinar los requisitos de necesidad del cliente y del mercado; durante el mantenimiento, un proyecto podría llevarse a cabo para producir una próxima versión de un producto.

2.4. portafolio

2.5. Ciclo de vida del producto [2 *, c2] [3 *, c2] Un ciclo de vida del producto de software (SPLC) incluye todas las actividades necesarias para definir, construir, operar, mantener y retirar un producto de software o servicio y sus variantes. Las actividades de SPLC “opercomió”, “mantener” y “retirarse” suelen ocurrir en un período de tiempo mucho más largo que el desarrollo de software inicial (el software de vida de desarrollo del ciclo de SDLC-ver els Software del ciclo de vida en el mo- Ingeniería de Software proceso KA). También las actividades de operación y mantenimientoretirarse de un SPLC consumen típicamente más esfuerzo total y otros recursos de las actividades SDLC (ver La mayoría de los costos de mantenimiento en el KA Mantenimiento de Software). El valor aportado por un producto de software o servicios asociados puede determinarse objetivamente durante el marco de “operar y mantener” tiempo. ingeniería de software Economics deben preocuparse por todas las actividades SPLC, incluyendo las actividades después de la liberación inicial del producto.

2.3. Programa Un programa es “un grupo de proyectos

relacionados, subprogramas

y

actividades del programa

12-12 Guía SWEBOK® V3.0 gestionado de manera

coordinada para obtener beneficios que no están disponibles

1

Project Management Institute, Inc., PMI Lexicon

2.6. Ciclo de Vida del Proyecto

[2 *, c2] [3 *, c2] las actividades del ciclo de vida del proyecto implican típicamente cinco grupos de iniciación de procesos, planificación, Execut- ción, seguimiento y control, y cierre [4]

del Proyecto Términos de gestión, 2012, www.pmi.org/ 2 PMBOK-Guía-y-Normas / ~ / media / registro / 3 PMI_Lexicon_Final.ashx.

Ibídem. Ibídem.

Software Economía Ingeniería 12-13

(Ver el KA Software Engineering Management). Las actividades dentro de un ciclo de vida del proyecto de software a menudo se entrelazan, se superponen, y iterada de diversas maneras [3 *, c2] [5] (ver el Proceso de Ingeniería de Software KA). Por ejemplo, el desarrollo de productos ágil dentro de un SPLC implica múltiples iteraciones que producen incrementos de software entregable. Un SPLC debe incluir la gestión del riesgo y la sincronización con los proveedores dife- rentes (si los hay), al tiempo que proporciona información audit- poder de toma de decisiones (por ejemplo, comply- ing con las necesidades de responsabilidad por productos o las reglas de gobierno). El ciclo de vida del proyecto de software y el software de ciclo de vida del producto están relacionados entre sí; un SPLC puede incluir varios SDLCs. 2.7. propuestas [1 *, c3] De tomar una decisión de negocios comienza con la noción de una propuesta. Propuestas se refieren a alcanzar un objetivo de negocio, en el proyecto, producto o nivel de cartera. Una propuesta es una opción única, separada que se está considerando, como llevar a cabo un proyecto de desarrollo de software en particular o no. Otra propuesta podría ser para mejorar un componente de software existen- tes, y todavía podría ser otra que volver a desarrollar mismo software desde cero. Cada propuesta representa una unidad de elección, ya sea que usted puede elegir para llevar a cabo esa propuesta o puede optar por no hacerlo. Todo el propósito de la toma de decisiones de negocio es averiguar, dadas las circunstancias actuales de negocios, que las propuestas deben llevarse a cabo y cuáles no. 2.8. Decisiones de inversión

[1 *, c4]

Los inversores a tomar decisiones de inversión para gastar dinero y recursos en la consecución de un objetivo obje- tivo. Los inversores están ya sea en el interior (por ejemplo, las finanzas, la placa) o fuera (por ejemplo, bancos) de la organización. El objetivo se relaciona con

2.9. Planeando el horizonte

[1 *, c11]

Cuando una organización decide invertir en una propuesta cular par-, el dinero se hace atar en esa propuesta, los llamados “activos congelados.” El impacto económico de los bienes congelados tiende a comenzar y disminuye con el tiempo. Por otra parte, ING y mantenimiento operatcostes de los elementos asociados con la propuesta tienden a empezar con poco, pero aumentará con el tiempo. El costo total de la propuesta, es decir, poseer y operar un producto es la suma de estos dos costos. Al principio, los costos de los activos congelados dominan; más tarde, los costos de operación y mantenimiento dominan. Hay un punto en el tiempo que se minimiza la suma de los costos; esto se llama el tiempo de vida de costo mínimo. A comparar adecuadamente una propuesta con una vida útil de cuatro años a una propuesta con una vida útil de seis años, los efectos económicos de la propuesta, ya sea de corte de seis años por dos años o invertir los beneficios de la propuesta de cuatro años por otros dos años deben abordarse. El horizonte de planificación, a veces conocido como el período de estudio, es el marco de tiempo constante durante los cuales se consideran propues- tas. tendrán que tenerse en cuenta en el establecimiento de un horizonte de planificación efectos tales como el software vida tiempo. Una vez establecido el horizonte de planificación, varias técnicas están disponibles para presentar propuestas de vida diferentes períodos en que el horizonte de planificación. 2.10. Precio y precios [1 *, c13]

Un precio es lo que se paga a cambio de un bien o servicio. El precio es un aspecto fundamental de la modelización financiera y es una de las cuatro P de la comercialización algunos criterios económicos, tales como el logro de un alto retorno de la inversión, el fortalecimiento de las capacidades de la organización, o de mejorar el valor de la empresa. aspectos Intangi- bles tales como la buena voluntad, la cultura y competen- cias deben ser

12-14 Guía SWEBOK® V3.0 considerados.

mezcla. Los otros tres son Sal producto, promoción y lugar. El precio es el ele- mento única generadora de ingresos entre las cuatro P; el resto son costes. El precio es un elemento de finanzas y marketing. Es el proceso de determinar lo que es una empresa recibirá a cambio de sus productos. factores de fijación de precios incluyen el coste de fabricación, colo- cación mercado, la competencia, las condiciones del mercado, y la calidad del producto. La fijación de precios se aplica a los precios de productos y servicios basados en factores tales como cantidad fija, ruptura cantidad, promoción o campaña de ventas,

Software Economía Ingeniería 12-15

cotización específica del proveedor, embarque o factura fecha, combinación de varios pedidos, ofertas de servicios, y muchos otros. Las necesidades del consumidor se pueden convertir en la demanda sólo si el consumidor tiene la voluntad y la capacidad para comprar el producto. Por lo tanto, el precio es muy importante en la comercialización. La fijación de precios se realiza inicialmente durante la fase ción iniciativa del proyecto y es una parte de la toma de decisiones “ir”.

parámetros utilizados para determinar si los programas, inversiones y adquisiciones están logrando los resultados deseados. Se utiliza para evaluar si realmente se logran los objetivos de rendimiento; para controlar los presupuestos, los recursos, el progreso y las decisiones; y para mejorar el rendimiento. 2.13. Gestion del valor ganado

[3 *, c8] 2.11. Costo y costeo [1 *, c15] Un coste es el valor del dinero que se ha utilizado para producir algo y, por lo tanto, no está disponible para su uso más. En economía, un coste es una alter- nativa que se da como resultado de una decisión. Un costo hundido es los gastos antes de un cierto tiempo, normalmente se utiliza para decisiones abstractas de los gastos en el pasado, lo que puede causar obstáculos emocionales en el futuro. Desde un punto de vista económico tradicional, los costos hundidos no deben ser considerados en la toma de decisiones. El costo de oportunidad es el costo de una alternativa que debe ser ido lucro con el fin de seguir otra alternativa. Cálculo del coste forma parte de las finanzas y manage- ment producto. Es el proceso para determinar el costo basado en los gastos (por ejemplo, producción, ingeniería de software, distribución, retrabajo) y sobre el costo objetivo de ser competitivos y exitosos en un mercado. El costo de destino puede estar por debajo del costo estimado real. La planificación y el control de estos costos (llamada de gestión de costes) es importante y siempre deben ser incluidos en los costos. Un concepto importante en el costeo es el coste total de propiedad (TCO). Esto es válido especialmente para el software, ya que hay muchos costos no tan obvias relacionadas con las actividades SPLC después del desarrollo de pro- ducto inicial. TCO para un producto de software se define como el costo total de la adquisición, activar y mantener ese producto en funcionamiento. Estos costos se pueden agrupar como los costes directos e indirectos. TCO es un método de contabilidad que es crucial en la toma

Gestión del Valor Ganado (EVM) es un proyecto técnica de gestión para medir el progreso de decisiones económicas. 2.12. Medición del desempeño [3 *, C7, C8] La medición del desempeño es el proceso mediante el cual una organización establece y mide la

12-16 Guía SWEBOK® V3.0 basado en el valor

creado. En un momento dado, los resultados obtenidos hasta la fecha en un proyecto se Comparado con el presupuesto proyectado y el progreso calendario previsto para esa fecha. El progreso se refiere recursos consumidos ya-y ha logrado resultados en un punto dado en el tiempo con los valores planificados respectivos de la misma fecha. Ayuda a identificar los posibles problemas de rendimiento en una etapa temprana. Un principio clave en EVM es el seguimiento de las variaciones de costos y programas a través de la comparación de horario programado versus real y el presupuesto frente a los costos reales. EVM da seguimiento mucho más temprano vis bilidad a las desviaciones y por lo tanto permite correcciones antes de lo clásico y el costo de seguimiento horario que sólo se basa en documentos y productos entregados. 2.14. Las decisiones de terminación [1 *, c11, c12] [2 *, c9] El cese significa poner fin a un proyecto o producto. La terminación puede ser planificada de antemano para el final de un curso de la vida del producto largo (por ejemplo, cuando previendo que un producto alcanzará su vida) o puede venir en lugar espontáneamente durante el desarrollo de productos (por ejemplo, cuando no se consiguen los objetivos de rendimiento del proyecto). En ambos casos, la decisión debe ser cuidadosamente preparado, teniendo en cuenta siempre las alternativas de continuidad versus terminación. Los costos de las diferentes alternativas deben ser temas de ING como el reemplazo, la información lección COL-, los proveedores, las alternativas, los activos y recursos de ING utiliz- para otras oportunidades cubierta- estima. Los costos hundidos no deben ser considerados en dicha toma de decisiones, ya que se han gastado y no Reap, pera como un valor.

Software Economía Ingeniería 12-17

Figura 12.4. Metas, estimaciones, y Planes

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

en su mayoría los objetivos de negocio (u objetivos de negocio).

12-18 Guía SWEBOK® V3.0

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

Software Economía Ingeniería 12-11

un proyecto (véase el software de planificación en el KA Software Engineering Management). El plan debe estar en consonancia con la meta y la estimación compañero, que no es necesariamente fácil y obvi- ous-por ejemplo, cuando un proyecto de software con los requisitos dados tomaría más tiempo que la fecha límite prevista por el cliente. En tales casos, los planes exigen una revisión de los objetivos iniciales, así como Las estimaciones y las incertidumbres subyacentes y las inexactitudes. soluciones creativas con los fundamentos del sistema de alcanzar una posición de ganar-ganar se aplican para resolver conflictos. A ser de valor, la planificación debe involucrar consideración conde las restricciones del proyecto y los compromisos a los interesados. La figura 12.4 muestra cómo se definen inicialmente objetivos. Los cálculos se realizan sobre la base de los objetivos iniciales. El plan intenta hacer coincidir los objetivos y las estimaciones. Este es un proceso iterativo, debido a una estimación inicial normalmente no cumple con los objetivos iniciales. 3.2. Las técnicas de estimación [3 *, c6] Las estimaciones se utilizan para analizar y prever los recursos o el tiempo necesarios para implementar los requisitos (ver Esfuerzo, Calendario, y Estimación de Costos de la Ingeniería de Software de Gestión de KA y Estimación de Costos de Mantenimiento en el KA Mantenimiento de Software). Existen cinco familias de técnicas de estimación: • • • • •

Juicio experto Analogía Estimación por piezas métodos paramétricos Métodos de estadística.

Sin sola técnica de estimación es perfecto, por lo que el uso de la técnica de estimación múltiple es útil. La convergencia entre las estimaciones producidas por diferentes técnicas indica que las estimaciones son probablemente exacta. Difundir entre los compañeros estimación indica que ciertos factores podrían haber sido pasados por alto. La búsqueda de los

3.3. La incertidumbre abordar

[3 *, c6]

Debido a los muchos factores desconocidos durante la iniciación y planificación de proyectos, las estimaciones son inciertas; que la incertidumbre debe tratarse de decisiones de negocio. Las técnicas para hacer frente a la incertidumbre incluyen • considerar rangos de estimaciones • analizar la sensibilidad a los cambios de las hipótesis • retrasar las decisiones finales. 3.4. priorización [3 *, c6] Priorización implica alternativas clasificación basada en criterios comunes para ofrecer el mejor valor posible. En los proyectos de ingeniería de software, requisitos de software a menudo se priorizan con el fin de ofrecer el mayor valor al cliente dentro de straints con- de programación, presupuesto, recursos y tecnología, o para proporcionar para la construcción de incrementos de productos, donde los primeros incrementos proporcionar el mayor valor para el cliente (ver requisitos de clasificación y requisitos de la Negociación en los requisitos de software KA y del ciclo de vida del software los modelos de la Ingeniería de procesos de Software KA). 3.5. Las decisiones en riesgo factores que causaron la propagación y luego volver a estimar de nuevo para pro- ducir resultados que convergen podría conducir a una mejor estimación.

12-12 Guía SWEBOK® V3.0

[1 *, c24] [3 *, c9]

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

la toma de decisiones valor esperado varianza expectativa y la toma de decisiones El análisis de Monte Carlo árboles de decisión valor esperado de la información perfecta.

Software Economía Ingeniería 12-13

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

3.6. Las decisiones bajo incertidumbre [1 *, c25] [3 *, c9]

4. Métodos de análisis económicos

Las decisiones bajo incertidumbre técnicas se utilizan cuando el tomador de decisiones no puede asignar probabivínculos con los diferentes resultados posibles porque la información necesaria no está disponible (véase Gestión de Riesgos en el KA Software Engineering Management). Las técnicas específicas incluyen

4.1. Con fines de lucro Análisis de Decisiones

• • • • •

Regla de Laplace Regla Maximin Regla maximax Regla Hurwicz Regla arrepentimiento minimax.

[1 *, c10]

Figura 12.5 se describe un procedimiento para la identificación de la mejor alternativa de un conjunto de alternativas sivos mutuamente exclusiones. Los criterios de decisión dependen de los objetivos de negocio y por lo general incluyen retorno de la inversión (véase la sección 4.3, Retorno de la Inversión) o Retorno sobre el capital empleado (ROCE) (ver sección 4.4, rendimiento del capital invertido). Para fines de lucro técnicas de toma no se aplican a las organizaciones gubernamentales y sin fines de lucro. En estos casos, las organizaciones tienen diferentes objetivos, lo que significa que se necesita un conjunto diferente de las técnicas de toma, como el costebeneficio o el análisis coste-efectividad Ness.

12-14 Guía SWEBOK® V3.0

4.2. Tasa de retorno mínima aceptable [1 *, c10] La tasa mínima aceptable de rendimiento (TREMA) es la más baja tasa interna de retorno de la organiza- ción consideraría como una buena inversión. En términos generales, no sería inteligente para invertir en una actividad con un rendimiento del 10% cuando no hay otra actividad que se sabe que devolver el 20%. La TREMA es una declaración de que una organización confía en que puede lograr al menos que la tasa de rendimiento. La TREMA representa el costo de oportunidad de la organización para las inversiones. Al elegir a invertir en algún tipo de actividad, la organización está decidiendo explícitamente a no invertir ese mismo dinero en otro lugar. Si la organización es ya confía en que puede conseguir un poco de velocidad conocida de retorno, otras alternativas deben elegirse sólo si su tasa de rendimiento es al menos tan alto. Una manera sencilla para dar cuenta de que el coste de oportunidad es utilizar la TREMA como la tasa de interés en las decisiones empresariales. valor actual de una alternativa evaluada en la TREMA muestra cuánto más o menos (en términos de caja actuales) que vale la pena alternativa es que la inversión en el Marr.

4.5. Análisis costebeneficio

[1 *, c18]

Análisis coste-beneficio es uno de los métodos más utilizados para la evaluación de ALS propues- individuales. Cualquier propuesta con una relación beneficio-costo de menos de 1,0 por lo general puede ser rechazada sin análisis adicional porque costaría más que el beneficio. Las propuestas con una necesidad mayor proporción de con- Sider el riesgo asociado de una inversión y comparar los beneficios con la opción de invertir el dinero a una tasa de interés garantizada (ver sec- ción 4.2, aceptable tasa de retorno mínima). 4.6. Análisis coste-efectividad [1 *, c18] Análisis coste-efectividad es similar al análisis de coste-beneficio. Hay dos versiones de análisis coste-eficacia: la versión de costos fijos maximiza el beneficio dado alguna cota superior en el precio; la versión de la eficacia fijo minimiza el costo necesario para lograr un objetivo fijo. 4.7. Punto de equilibrio de analisis [1 *, c19]

4.3. Retorno de la Inversión

[1 *, c10]

Retorno de la inversión (ROI) es una medida de la rentabilidad de una empresa o unidad de negocio. Se define como la relación entre el dinero ganado o perdido (realizadas o no realizadas) en una inversión con respecto a la cantidad de dinero invertido. El propósito de retorno de la inversión varía e incluye, por ejemplo, proporcionando una base para futuras inversiones y decisiones de adquisición.

análisis de equilibrio identifica el punto donde los costos de desarrollo de un producto y los ingresos a generarse son iguales. Tal análisis se puede utilizar para elegir entre diferentes propuestas a diferentes costos estimados y los ingresos. estimación dada acoplado costes e ingresos de dos o más ALS propues-, análisis de equilibrio ayuda a la hora de elegir entre ellos. 4.8. Business Case describe el rendimiento del capital utilizado.

4.4. Rendimiento del capital invertido El retorno sobre el capital empleado (ROCE) es un seguro de medi- de la rentabilidad de una unidad de empresa o negocio. Se define como la relación de un beneficio bruto antes de impuestos e intereses (EBIT) para el total de activos menos pasivos corrientes. En él se

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

Software Economía Ingeniería 12-15

12-16 Guía SWEBOK® V3.0

gerente y utilizada en apoyo de la consecución de los objetivos de negocio. 4.9. Evaluación Atributo múltiple [1 *, c26] Los temas tratados hasta ahora se utilizan para hacer las decisiones sobre la base de un único criterio de decisión: el dinero. La alternativa con el mejor valor actual, la mejor ROI, y así sucesivamente es la seleccionada. Aparte de viabilidad técnica, el dinero es casi siempre el criterio de decisión más importante, pero no es siempre el único. Muy a menudo hay otros criterios, otros “atributos”, que deben tenerse en cuenta, y esos atributos no se pueden colar en términos de dinero. de toma de atributos múltiples técnicas permiten otros criterios no financieros, que sean fac- reada en la decisión. Hay dos familias de múltiples técnicas de toma de atributos que difieren en cómo utilizan los atributos en la decisión. Una familia es la “compensación”, o, técnicas-dimensionada individuales. Esta familia se derrumba todos los atributos en un único factor de mérito. La familia está llamada compensatoria, ya que, para cualquier alternativa dada, una puntuación más baja en un atributo puede ser compensada por-oobjeto de comercio frente una puntuación más alta en otros atributos. Las técnicas de compensación incluyen • escala adimensional • de ponderación aditiva • proceso analítico jerárquico. Por el contrario, la otra familia es la “compensatorio no transmisibles”, o totalmente dimensionada, técnicas. Esta familia no permite concesiones entre los atributos. Cada atributo es tratada como una entidad separada en el proceso de decisión. Las técnicas tory noncompensaincluyen • dominio • satisficing • lexicografía. 4.10. Análisis de optimización [1 *, c20] El uso típico de análisis de optimización es el

estudio de una función de coste en un rango de valores para

encontrar el punto en el rendimiento general es mejor. clásica disyuntiva espacio-tiempo de software es un ejemplo de optimización; un algoritmo que se ejecuta más rápido con frecuencia utiliza más memoria. Optimización equilibra el valor del tiempo de ejecución más rápida contra el costo de la memoria adicional. El análisis de opciones reales se puede usar para cuantificar el valor de opciones de proyectos, incluyendo el valor de retrasar una decisión. Estas opciones son difíciles de calcular con precisión. Sin embargo, la conciencia de que las opciones tienen un valor monetario proporciona la penetración en el calendario de las decisiones tales como el personal del proyecto ING increas- o alargando el tiempo de comercialización para mejorar la calidad. 5. Consideraciones prácticas 5.1. El “suficientemente bueno” Principio [1 *, c21] A menudo los proyectos de ingeniería de software y productos no son precisos acerca de los objetivos que deben alcanzarse. Requisitos de software se expresan, pero el valor marginal de agregar un poco más de funciona- lidad no se pueden medir. El resultado podría ser la entrega tarde o demasiado-alto costo. El “suficientemente bueno” principio se relaciona valor marginal al coste marginal y proporciona orientación para determinar los criterios cuando un entregable es “suficientemente bueno” para ser entregados. Estos criterios dependen de los objetivos del negocio y en la priorización de las distintas alternativas, tales como la clasificación de los requisitos de software, atributos medibles cali- dad, o relativas a la programación con- tenido y coste del producto. El principio RACE (reducir los accidentes y la esencia de control) es un gobierno popular hacia un buen software suficiente. Los accidentes implican gastos generales innecesarios tales como la sobrerregulación y retrabajo debido a la eliminación de defectos tarde o demasiado muchos cambios requisitos. Esencia es lo que pagan los clientes por. Softeconomía de ingeniería cerámica ofrece los meca- nismos para definir los criterios que determinan cuándo un entregable es “suficientemente bueno” para ser entregados. También destaca que ambas palabras son relevantes: “suficiente” “bueno” y la

Economía Ingeniería 12-17 insuficiente calidad oSoftware cantidad insuficiente no es lo suficientemente bueno. Los métodos ágiles son ejemplos de “suficientemente bueno” que tratan de optimizar el valor mediante la reducción de la cabeza excesiva de retrabajo retrasado y el chapado de oro que

12-18 Guía SWEBOK® V3.0

resulta de la adición de características que tienen valor marginales bajos para los usuarios (ver Métodos ágiles en los modelos de ingeniería de software y métodos KA y Vida Software Modelos de Ciclo de la Ingeniería de Procesos de Software KA). En ods met ágiles, planificación detallada y las largas fases de desarrollo se sustituyen por la planificación incrementales y entrega frecuente de pequeños incrementos de un producto erable deliv- que se prueba y evaluadas por representantes de los usuarios. 5.2. Economía-Friction Free la fricción económica es todo lo que mantiene merca- dos de tener la competencia perfecta. Se trata de distancia, el costo de la entrega, las regulaciones restrictivas, y / o información imperfecta. En los mercados de alta fricción, los clientes no tienen muchos proveedores entre los que elegir. Después de haber sido en un negocio por un tiempo o ser propietario de una tienda en una buena ubicación determina la posición económica. Es difícil para los nuevos competidores para iniciar negocios y competir. El mercado se mueve lentamente y de manera previsible. mercados libres de fricción son justo lo contrario. Surgen nuevos competidores y los clientes son rápidos en responder. El mercado es cualquier cosa menos capaces predecible. En teoría, el software y TI son rozamientos. Las nuevas empresas pueden crear fácilmente los productos y a menudo lo hacen a un costo mucho más bajo que blecimientos empresas cado, ya que no tendrá que considerar cualquier legado. Marketing y ventas se pueden hacer a través de Internet y las redes sociales, y los mecanismos de distribución bási- camente libres pueden permitir una rampa hasta un negocio global. Software Engineer- economía ing tiene como objetivo proporcionar bases para juzgar cómo un negocio de software lleva a cabo y cómo libre de fricción un mercado que realmente es. Por ejemplo, la competencia entre los desarrolladores de aplicaciones de software se inhibe cuando las aplicaciones deben ser vendidos a través de una tienda de aplicaciones y cumplen con las normas de esa tienda. 5.3. ecosistemas

Un ecosistema es un entorno compuesto por todas las partes mutuamente dependientes, unidades de negocio y empresas que trabajan en un área particular.

En un ecosistema típico, hay productores y consumidores, en los que los consumidores agregan valor a los recursos consumidos. Tenga en cuenta que un consumidor no es el usuario final, sino una organización que utiliza el producto para mejorarla. Un ecosistema de software es, por ejemplo, un proveedor de una aplicación trabajando con las empresas que hacen la instalación y el puerto SUP- en diferentes regiones. Ninguno de los dos puede existir sin el otro. Los ecosistemas pueden ser permanentes o temporales. la economía de ingeniería de software proporciona los mecanismos para evaluar alternativas en el establecimiento o la ampliación de una instancia ecosistema para, evaluar si trabajar con un distribuidor espe- CIFIC o tiene la distribución realizada por una empresa que realiza el servicio en un área. 5.4. La deslocalización y la externalización La deslocalización significa la ejecución de una actividad de negocio más allá de ventas y comercialización fuera del país de origen de una empresa. Las empresas típicamente tienen sus ramas de deslocalización en países de bajos costes o que piden las empresas especializadas en el extranjero para ejecutar la actividad respectiva. ING Offshor- tanto, no debe confundirse con la externalización. La deslocalización dentro de una empresa se llama deslocalización cautiva. La subcontratación es la relación entados resultado-ori- con un proveedor que ejecuta actividades de negocio para una empresa cuando, tradicional- mente, esas actividades fueron ejecutadas dentro de la empresa. La externalización es un sitio independiente. El proveedor puede residir en la vecindad de la empresa o en alta mar (subcontratado offshor- ing). la economía de ingeniería de software proporciona los criterios básicos y herramientas de negocio para evaluar diferentes mecanismos de aprovisionamiento y controlar su rendimiento. Por ejemplo, el uso de un proveedor de externalización de desarrollo de software y el mantenimiento podría reducir el coste por hora de desarrollo de software, pero aumentar el número de horas y los gastos de capital debido a una mayor necesidad de seguimiento y comunicación. (Para más infor- mación sobre la deslocalización y la externalización, consulte “externalización” en cuestiones de gestión en el mantenimiento del software KA).

Software Economía Ingeniería 12-19

12-20 Guía SWEBOK® V3.0

1. Fundamentos de Ingeniería de Software Economía 1.1. Financiar

JustaLey de 2009 [3 *]

c2

1.2. Contabilidad

c15

1.3. Controlador

c15

1.4. Flujo de fondos

c3

1.5. Proceso de toma de decisiones

SommervilLe 2011 [2 *]

točkey 2005 [1 *]

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

c2, c4

1.6. Valuación

C5, C8

1.7. Inflación

c13

1.8. Depreciación

c14

1.9. Impuestos

c16, c17

1.10. Valor temporal del dinero

C5, C11

1.11. Eficiencia

c1

1.12. Eficacia

c1

1.13. Productividad

c23

2. La vida de ciclo Economía 2.1. Producto

c22

c6

c22

c1

2.5. Ciclo de vida del producto

c2

c2

2.6. Ciclo de Vida del Proyecto

c2

c2

2.2. Proyecto 2.3. Programa 2.4. portafolio

2.7. propuestas

c3

2.8. Decisiones de inversión

c4

2.9. Planeando el horizonte

c11

2.10. Precio y precios

c13

2.11. Costo y costeo

c15

2.12. Medición del desempeño

C7, C8 c8

2.13. Gestion del valor ganado 2.14. Las decisiones de terminación 2.15. Las decisiones de reemplazo y jubilación

c11, c12

C9

c12

C9

JustaLey de 2009 [3 *]

SommervilLe 2011 [2 *]

točkey 2005 [1 *]

Software Economía Ingeniería 12-21

3. Riesgo e Incertidumbre 3.1. Metas, estimaciones, y Planes

c6

3.2. Las técnicas de estimación

c6

3.3. La incertidumbre abordar

c6

3.4. priorización

c6

3.5. Las decisiones en riesgo

c24

C9

3.6. Las decisiones bajo incertidumbre

c25

C9

4. Métodos de Análisis Económico 4.1. Con fines de lucro Análisis de Decisiones

c10

4.2. Tasa de retorno mínima aceptable

c10

4.3. Retorno de la Inversión

c10

4.4. Rendimiento del capital invertido 4.5. Análisis coste-beneficio

c18

4.6. Análisis coste-efectividad

c18

4.7. Punto de equilibrio de analisis

c19

4.8. Business Case

c3

4.9. Evaluación Atributo múltiple

c26

4.10. Análisis de optimización

c20

5. Consideraciones prácticas 5.1. El “suficientemente bueno” Principio 5.2. Economía-Friction Free 5.3. ecosistemas 5.4. La deslocalización y la externalización

c21

12-22 Guía SWEBOK® V3.0

LECTURAS Una guía para la Dirección de Proyectos (Guía del PMBOK®) [4]. La Guía PMBOK ® proporciona directrices para la gestión de proyectos individuales y define conceptos relacionados con la gestión de proyectos. También describe el ciclo de vida de gestión de proyectos y sus procesos relacionados, así como el ciclo de vida del proyecto. Es una guía reconocida a nivel mundial para la profesión agement el proyecto hombre-. Software de la extensión a la Guía de los Fundamentos de la Dirección de Proyectos (SWX) [5]. SWX proporciona adaptaciones y ampliaciones de las prácticas genéricas de gestión de proyectos documentado en la Guía PMBOK ® para la gestión de proyectos de software. La principal contribución de esta extensión de la Guía del PMBOK® es descrip- ción de los procesos que son aplicables para la gestión de proyectos de software de ciclo de vida de adaptación. BW Boehm, Software Economía Ingeniería [6]. Este libro es la lectura clásica en la economía de ingeniería de software. Proporciona una visión general del pensamiento empresarial en ingeniería de software. Aunque los ejemplos y figuras son anticuadas, todavía vale la pena leer. C. Ebert y R. Dumke, Medición Software [7]. Este libro ofrece una visión general sobre los métodos cuantitativas en la ingeniería de software, comenzando con la teoría de la medición y procediendo a la gestión del rendimiento y la toma de decisiones empresariales. DJ Reifer, Haciendo el caso Business Software: Mejora por los números [8]. Este libro es una lectura clásica en la fabricación

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

Referencias [1 *] S. Tockey, Retorno de software: maximizar el retorno de su inversión en software, Addison-Wesley, 2004. [2 *] JH Allen et al, software de seguridad Ingeniería:. Guía para los gerentes de proyecto, Addison-Wesley, 2008. [3 *] RE Fairley, gestionar y liderar proyectos de software, Wiley-IEEE Computer Society Press, 2009. [4] Project Management Institute, Guía para la Dirección de Proyectos del Conocimiento (PMBOK (R) Guía), 5ª ed., Project Management Institute, 2013. [5] Instituto de Gestión de Proyectos y IEEE Computer Society, software de la extensión de la Guía del PMBOK® quinta edición, ed: Project Management Institute, 2013. [6] BW Boehm, Software Economía Ingeniería, Prentice-Hall, 1981. [7] C. y R. Ebert Dumke, software de medición, Springer, 2007. [8] DJ Reifer, Haciendo el caso Business Software: Mejora de los números, Addison Wesley, 2002.

Software Economía Ingeniería 12-23

CAPÍTULO 13 FUNDAMENTOS DE INFORMATICA SIGLAS AOP ALU

Programación Orientada a Aspectos Unidad aritmética lógica

API

de programación de aplicaciones Interfaz

Cajero Modo de Transferencia Asíncrona automátic B/S Navegador-Servidor o Equipo de Respuesta a Emergencias CERT Informáticas COTS

Commercial Off-The-Shelf

CRUD C/S

Crear, leer, actualizar, eliminar Servidor de cliente

CS DBMS FPU

Ciencias de la Computación Sistema de administración de base de datos Flotar unidad de coma

I/O ES UN

Entrada y salida Set de instrucciones arquitectura

ISO

Organización Internacional para las Normalización

ISP

Proveedor de servicios de Internet

LAN

Red de área local

MUX NIC

multiplexor Tarjeta de interfaz de red

POO OS

Programación orientada a objetos Sistema operativo

OSI Sistemas abiertos de interconexión ordenado Computadora personal rPDA personal Asistente personal digital PPP RFID

Punto-a-Punto Protocolo Identificación de frecuencia de radio

RAM ROM

Memoria de acceso aleatorio Memoria de sólo lectura

SCSI

Small Computer System Interface

SQL TCP

lenguaje de consulta estructurado Protocolo de control de transporte

UDP VPN

User Datagram Protocol Red Privada Virtual

PÁLIDO Red de área amplia

INTRODUCCIÓN El alcance de los Fundamentos Informática knowl- área de borde (KA) abarca el desarrollo y el medio ambiente operacional en el que evoluciona de software y se ejecuta. Debido a que ningún software puede existir en un vacío o correr sin un ordenador, el núcleo de un entorno de este tipo es el ordenador y sus diversos componentes. El conocimiento acerca de la computadora y sus principios subyacentes de las mercancías de hardware y software sirve como un marco en el que se ancla la ingeniería de software. Por lo tanto, todos los ingenieros de software deben tener una buena comprensión de los ing Fundamentos de Informática KA. En general se acepta que el software de ingeniería se acumula en la parte superior de la informática. Por ejemplo, “Ingeniería de Software 2004: Directrices riculum mentos para los programas de licenciatura en Ingeniería de Software” [1] establece claramente, “Un aspecto particularmente importante es que la ingeniería de software se basa en la informática y las matemáticas” (la cursiva es nuestra). Steve Tockey escribió en su libro Retorno de software:

Software Economía Ingeniería 12-25

Tanto la informática y el software de inge- niería acuerdo con ordenadores, computación y software. La ciencia de la computación, como un conjunto de conocimientos, está en el centro de ambos. 13-1

13-2

Guía SWEBOK® V3.0

Figura 13.1. Desglose de los temas de los Fundamentos de Informática KA

... Ingeniería de software se ocupa de la aplicación de las computadoras, computación y software para propósitos prácticos, específica- mente el diseño, la construcción y funciona- miento de los sistemas de software eficientes y económicos. Por lo tanto, en el centro de ingeniería de software es una comprensión de la informática. Aunque pocas personas negarán las obras de informática papel en el desarrollo de la ingeniería de software, tanto como disciplina y como un conjunto de conocimientos, la importancia de la informática a la ingeniería de software no puede ser demasiado hincapié tamaño; Por lo tanto, esta Fundamentos de Informática KA está siendo escrito. La mayoría de los temas tratados en los Fundamentos Com- Puting KA también son temas de dis- cusión en los cursos básicos que figuran en los programas de grado y posgrado de la informática. Dichos cursos incluyen la programación, estructura de datos, algoritmos, organización de computadores, sistemas operativos, compiladores, bases de datos, redes, sistemas de dis- tribuido, y así sucesivamente. Por lo tanto, cuando Break-ing por temas, puede ser tentador para descomponer el Fundamentos de Informática KA acuerdo con estas divisiones a menudo se encuentran en-cursos pertinentes. Sin embargo, una división basada curso de temas puramente sufre graves inconvenientes. Por un lado, no todos los cursos de informática están relacionados o igualmente importante para la ingeniería de software. Por lo tanto, algunos

de los temas que de otra forma estarían cubiertos en un curso de informática no están cubiertos en este

KA. Por ejemplo, los gráficos de ordenador, mientras que un curso importante en un programa de grado de la informática, no está incluido en este KA. En segundo lugar, algunos de los temas tratados en esta línea guía- no existen como cursos independientes de programas informáticos graduados o graduados insuficientemente. Por consiguiente, tales temas pueden no estar cubiertos adecuadamente en un desglose basado cursopuramente. Por ejemplo, la abstracción es un tema incorporado en varios cursos de informática diferentes; no está claro qué abstracción curso deben pertenecer a una avería basada en el transcurso de los temas. Los fundamentos de computación KA se divide en diecisiete temas diferentes. Ness útildirecta de un tema a los ingenieros de software es el criterio utilizado para la selección de temas para su inclusión en este KA (véase la figura 13.1). La ventaja de esta distribución basada en el tema es su fundamento en la creencia de que si daciones-Computing Fun- es para ser agarrado firmemente-deben considerarse como una colección de temas relacionados lógicamente ciñendo la ingeniería de software en la construcción general y el software, en particular . Los fundamentos de computación KA se relaciona estrechamente con el Diseño de Software, Software Con- trucción, pruebas de software, software Principal- manteni-, Calidad de Software y fundaciones KAs matemáticas. DISTRIBUCIÓN DE TEMAS PARA FUNDAMENTOS DE INFORMATICA El desglose de los temas para la Informática Fundamentos KA se muestra en la figura 13.1.

Fundamentos de computación 13-3

13-4

Guía SWEBOK® V3.0

1. Técnicas de resolución de problemas [2 *, S3.2, c4] [3 *, c5] La conceptos, nociones y terminología introducida aquí forman una base subyacente para la comprensión de la función y el alcance de las técnicas de resolución de problemas. 1.1. Definición de la resolución de problemas La resolución de problemas se refiere a los lazos de pensamiento y activi- realizados para responder o derivar una solución a un problema. Hay muchas maneras de abordar un problema, y cada camino emplea diferentes herramientas y utiliza procesos diferentes. Estas diferentes formas de abordar los problemas se expanden gradualmente y definen a sí mismos y, finalmente, dan lugar a diferentes disciplinas. Por ejemplo, el software de inge- niería se centra en la resolución de problemas utilizando computadoras y software. Si bien los distintos problemas garantizan soluciones diferentes y pueden requerir diferentes herramientas y procesos, la metodología y las técnicas utilizadas en la solución de problemas hacen seguir algunas directrices y, a menudo se pueden generalizar como las técnicas de resolución de problemas. Por ejemplo, una pauta general para la resolución de un problema de ingeniería genérica es utilizar el proceso de tres pasos dada a continuación [2 *]. • Formular el problema real. • Analizar el problema. • Diseñar una estrategia de búsqueda de solución. 1.2. Formular el problema real Gerard Voland escribe: “Es importante reconocer que un problema específico debe ser formulada si uno va a desarrollar una solución específica” [2 *]. Esta formulación se llama el planteamiento del problema, que especifica explícitamente lo tanto el problema y el resultado deseado son. Aunque no hay forma universal de stat- ing un problema, en general, un problema debe expresarse de tal manera que se facilite el desarrollo de soluciones. Algunas técnicas generales

para ayudar a uno formular el problema real incluyen la declaración-reexpresión, determinar el origen y la causa, la revisión de la declaración, analizando el estado actual y el deseado, y utilizando el enfoque del ojo fresco.

1.3. Analizar el problema Una vez que el planteamiento del problema se encuentra disponible, el siguiente paso es analizar el planteamiento del problema o la situa- ción para ayudar a estructurar nuestra búsqueda de una solución. Cuatro tipos de análisis incluyen análisis de la situación, en la que se identifican primero los aspectos más urgentes o críticos de una situación; análisis de problemas, en el que la causa del problema debe ser extraído deter-; análisis de decisión, en el que necesita la acción (s) para corregir el problema o eliminar su causa se debe determinar; y análisis problema potencial, en el que necesita la acción (s) para prevenir cualquier recurrencia del problema o el desarrollo de nuevos problemas debe ser determinado. 1.4. Diseñar una estrategia de búsqueda de soluciones Una vez que el análisis de los problemas es completa, podemos centrarnos en la estructuración de una estrategia de búsqueda para encontrar la solución. Con el fin de encontrar la “mejor” solución (en este caso, “mejor” puede significar cosas diferentes para personas diferentes, tales como rápido, más barato, más usables diferentes capacidades, etc.), necesitamos eliminar caminos que no conducen a soluciones viables, las tareas de diseño de una manera que proporciona la mayor orientación en la búsqueda de una solución, y utilizan diversos atributos del estado de solución final para guiar nuestras decisiones en el proceso de resolución de problemas. 1.5. La resolución de problemas Utilización de programas La singularidad de los programas informáticos da la resolución de problemas un sabor que es distinta de la ingeniería general, la resolución de problemas. Para resolver un problema utilizando las computadoras, hay que responder a las siguientes preguntas. • ¿Cómo podemos averiguar qué decirle al orde- nador a hacer? • ¿Cómo podemos convertir el planteamiento del problema en un algoritmo? • ¿Cómo podemos convertir el algoritmo en instrucciones de máquina?

Fundamentos de computación 13-5resolver un problema de

La primera tarea utilizando una computadora es determinar qué decirle a la computadora para hacer. Puede haber muchas maneras de contar la historia, pero todos deben tener la perspectiva de una computadora tales

13-6

Guía SWEBOK® V3.0

de que el equipo con el tiempo puede resolver el pro- blema. En general, un problema debe expresarse de tal manera que se facilite el desarrollo de algoritmos y estructuras de datos para resolverlo. El resultado de la primera tarea es ment un problema por el estado. El siguiente paso es convertir el problema ción estatal en los algoritmos que resuelven el problema. Una vez que se encuentra un algoritmo, el paso final convierte el algoritmo en instrucciones de máquina que forman la solución final: software que resuelve el problema. Hablando en abstracto, la resolución de problemas utilizando un ordenador puede ser considerado como un proceso de transformación problema, en otras palabras, la etapa de transformación a paso de un planteamiento del problema en una solución de un problema. Para la disciplina de la ingeniería de software, el objetivo último de la resolución de problemas es transformar un problema expresado en lenguaje natural en electrones que se ejecutan en un circuito. En general, esta transformación se puede dividir en tres fases: a) Desarrollo de algoritmos de la declaración pro- blema. b) La aplicación de algoritmos para el problema. c) Transformación de algoritmos para el código del programa. La conversión de un planteamiento del problema en los algoritmos y algoritmos en códigos de programa generalmente sigue un “refinamiento paso a paso” (descomposición aka sistemática) en el que empezamos con un planteamiento del problema, reescribir como una tarea, y de forma recursiva descomponer la tarea en unos sub-tareas más simples hasta que la tarea es tan sencilla que las soluciones a que son sencillas. Hay tres formas básicas de descomposición: secuenciales, condicionales, e iterativos. 2. Abstracción [3 *, s5.2-5.4] La abstracción es una técnica indispensable asocia- dos con la resolución de problemas. Se refiere tanto al proceso y el resultado de la

generalización mediante la reducción de la información de un concepto, un problema o un fenómeno observable de manera que uno puede centrarse en el “cuadro grande”. Una de las habilidades más importantes en cualquier empresa de ingeniería que se enmarca la niveles de abstracción adecuadamente.

“A través de la abstracción”, según Voland, “vemos el problema y sus posibles vías de solución a partir de un mayor nivel de comprensión conceptual. Como resultado, podemos llegar a ser mejores pre recortaron para reconocer posibles relaciones entre los diferentes aspectos del problema y de ese modo erate ge- soluciones de diseño más creativas”[2 *]. Esto es particularmente cierto en informática en general (tales como hardware vs software) y en ingeniería de software en particular (estructura de datos vs flujo de datos, y así sucesivamente). 2.1. Los niveles de abstracción Cuando la abstracción, nos concentramos en un “nivel” de la gran imagen a la vez con la confianza de que podemos conectar eficazmente con niveles por encima y por debajo. Aunque nos centramos en una sola planta, abstracción no significa saber nada acerca de los niveles vecinos. niveles de abstracción no necesariamente corresponden a componentes discretos en la realidad o en el dominio del problema, pero para bien definido de interfaces estándar como API de programación. Las ventajas que proporcionan interfaces estándar incluyen la portabilidad, el software más fácil / integración de hardware y utensilios de uso más amplio. 2.2. La encapsulación La encapsulación es un mecanismo utilizado para implementar la abstracción ción. Cuando se trata de un nivel de abstracción, la información relativa a los niveles por debajo y por encima de ese nivel se lated encapsulada. Esta información puede ser el concepto, proble- ma, o fenómeno observable; o puede ser las operaciones permitidas en estas entidades pertinentes. La encapsulación por lo general viene con un cierto grado de ocultación de información en los que algunos o todos los detalles subyacentes están ocultas desde el nivel por encima de la interfaz proporcionada por la abstracción. A un objeto, la ocultación de información significa que no necesitamos conocer los detalles de cómo el objeto es representadas o cómo se implementan las operaciones sobre dichos objetos. 2.3. Jerarquía Cuando usamos la abstracción en nuestro

problema y la solución de Fundamentos formulaciónde computación ción, 13-7 podemos utilizar diferentes abstracciones

13-8

Guía SWEBOK® V3.0

en diferentes momentos, en otras palabras, se trabaja en diferentes niveles de abstracción como la situación lo requiere. La mayoría de las veces, estos diferentes niveles de abstracción se organizan en una jerarquía. Hay muchas maneras de estructurar una jerarquía particular y los criterios utilizados para determinar el contenido específico de cada capa en la jerarquía varía dependiendo de los individuos que realizan el trabajo. A veces, una jerarquía de abstracción es secuencial, lo que significa que cada capa tiene una y sólo una predecesor capa (inferior) y uno y sólo un sucesor (superior) capa excepto la capa upmost (que no tiene un sucesor) y la capa más inferior ( que no tiene predecesor). A veces, sin embargo, la jerarquía está organizada en una estructura de árbol, lo que significa que cada capa puede tener más de una capa predecesor, pero sólo una capa sucesor. Ocasionalmente, una jerarquía puede tener un muchos- estructura a varios, en el que cada capa puede tener múltiples predecesores y sucesores. En ningún momento, habrá ninguna bucle en una jerarquía. Una jerarquía a menudo forma natural en la posición tarea descomposición. A menudo, un análisis de tareas se puede descomponer de forma jerárquica, empezando por las tareas y objetivos de la organización más grande y romper cada uno de ellos hacia abajo en subtareas más pequeñas que una vez más se pueden subdividir Esta divi- sión continua de tareas en otros más pequeños produciría una estructura jerárquica de las tareas de subtareas. 2.4. Las abstracciones alternativos A veces es útil tener múltiples abstracciones alternativas para el mismo problema, de modo que uno puede mantener diferentes perspectivas en mente. Por ejem- plo, podemos tener un diagrama de clases, una tabla de estado, y un diagrama de secuencia para el mismo software en el mismo nivel de abstracción. Estas abstracciones alternativas no forman una jerarquía, sino que se complementan entre sí para ayudar a la comprensión del problema y su solución. Aunque beneficiosos, es como tiempos difíciles para mantener abstracciones alternativas en sincronía. 3. Fundamentos de programación

[3 *, C6-19] La programación se compone de las metodologías o actividades para la creación de programas informáticos que

realizar una función deseada. Es una parte indispensable en la construcción de software. En general, programa- ción puede considerarse como el proceso de diseñar, escribir, probar, depurar y man- TaiNing el código fuente. Este código fuente es escriben normalmente con un lenguaje de programación. El proceso de escribir código fuente a menudo requiere experiencia en muchas áreas, incluyendo sujetos diferentes conocimientos del dominio de aplicación, estructuras de datos apropiadas, algoritmos izadas especial-, varias construcciones del lenguaje, buenas técnicas de programación, e ingeniería de software. 3.1. El proceso de programación La programación implica el diseño, la escritura, pruebas, depuración y mantenimiento. El diseño es la concepción o la invención de un esquema para convertir un requisito de cliente para el software de la computadora en el software operativo. Es la actividad que une a los requisitos de aplicación a la codificación y debug- ging. La escritura es la codificación real del diseño en un lenguaje de programación adecuado. La prueba es la actividad para verificar que el código se escribe en realidad hace lo que se supone que debe hacer. Depuración ging es la actividad de encontrar y corregir errores (fallos) en el código fuente (o diseño). El mantenimiento es la actividad de actualizar, corregir y mejorar los programas existentes. Cada una de estas actividades es un tema enorme y, a menudo garantiza que la explicación de toda una KA en la Guía SWEBOK y muchos libros. 3.2. Los paradigmas de programación La programación es muy creativo y por lo tanto lo que algu- personal. Diferentes personas suelen escribir programas dife- rentes para los mismos requisitos. Esta diversidad de la programación provoca mucha dificultad en la construcción y mantenimiento de software complejo grande. digmas Varios programación para- se han desarrollado a lo largo de los años para poner un poco de normalización en esta actividad altamente creativa y personal. Cuando uno los programas, él o ella puede usar uno de varios paradigmas de programación para escribir el código. Los principales tipos de paradigmas de programación se discuten a continuación. La programación no estructurada: en

Fundamentos de computación estructurado 13-9 programación, programador sigue a su / su

13-10 Guía SWEBOK® V3.0

presentimiento a escribir el código de la manera que él / ella le gusta, siempre y cuando la función está operativa. A menudo, la práctica es escribir código para cumplir una utilidad específica sin tener en cuenta cualquier otra cosa. Los programas escritos de esta manera, no exhiben estructura- particular, de ahí el nombre de “programación estructurada.” Programación no estructurada también a veces se llama la programación ad hoc. Estructurada / Procedimientos / Imperativo programa- ción: Una característica distintiva de la programación estructurada es el uso de estructuras de control bien definidas, procedimientos INCLUYENDO (y / o funciones) con cada procedi- miento (o función) realizar una tarea específica. Existen interfaces entre los procedimientos para facilitar las operaciones de llamada correcta y adecuada de los pro- gramas. En virtud de la programación estructurada, los programadores a menudo siguen los protocolos y reglas generales establecidas al escribir código. Estos protocolos y normas pueden ser numerosas y cubrir casi todo el ámbito de programación que van desde el tema más simple (por ejemplo, cómo nombrar variables, funciones, procedimientos, etc.) a cuestiones complejas más com- (tales como la forma de estructurar una interfaz, cómo manejar excepciones, etc.). Programación orientada a objetos: Mientras dimientos de programación dural organiza programas en torno a los procedimientos, programación orientada a objetos (POO) organizar un programa alrededor de los objetos, que son estructuras de datos abstractos que combinan tanto los datos y métodos utilizados para acceder o manipular los datos. Las características primarias de la OOP son que los objetos que representan diversas entidades abstractas y concretas son creados y estos objetos interactúan entre sí para cumplir colectivamente las funciones deseadas. Programación Orientada a Aspectos: Aspecto-ori- programación entados (AOP) es un paradigma de programación que se construye en la parte superior de la programación orientada a objetos. AOP pretende aislar funciones secundarias o de apoyo de la lógica de negocio del programa principal, centrándose en las secciones transversales (preocupaciones) de los objetos. La principal motivación para AOP es resolver el enredo objeto y de dispersión

asociado con la programación orientada a objetos, en el que las interacciones entre los objetos se convierten en muy compleja. La esencia de AOP es la separación en gran medida enfatizado de preocupaciones, que separa las preocupaciones funcionales no esenciales o lógica en varios aspectos. Programación funcional: Aunque menos poblalar, la programación funcional es tan viables como los otros paradigmas de programación en la solución de

problemas. En la programación funcional, todas las computaciones son tratados como la evaluación de las funciones ematical Matemáticas-. En contraste con la programación imperativo que enfatiza los cambios de estado, la programación funcional hace hincapié en la apli- cación de las funciones, evita los datos del estado y mutables, y proporciona transparencia referencial. 4. Conceptos básicos programación

del

lenguaje

de

[4 *, c6] El uso de ordenadores para resolver problemas implica programación que está escribiendo y organiz- ing instrucciones que le indican a la computadora qué hacer en cada paso. Los programas deben ser escritos en algún lenguaje de programación con el cual ya través del cual se describen los cálculos necesarios. En otras palabras, usamos las facilidades proporcionadas por un lenguaje de programación para describir los problemas, el desarrollo de algoritmos, y la razón acerca de las soluciones de problemas. Para escribir cualquier programa, uno debe soportar sub al menos un lenguaje de programación. 4.1. Lenguaje de Programación general Un lenguaje de programación está diseñado para expresar computaciones que pueden ser realizadas por un orde- nador. En un sentido práctico, un len- guaje de programación es una notación para escribir programas y por lo tanto debe ser capaz de expresar la mayoría de las estructuras de datos y algoritmos. Algunas, pero no todas, las personas restringen el término “lenguaje de programación” a aquellas lenguas que pueden expresar todos los algoritmos posibles. No todos los idiomas tienen la misma importancia y popularidad. Los más populares son a menudo definidos por un documento de especificación establecida por una organización bien conocida y respetada. Por ejemplo, el lenguaje de programación C se manera especificada por una norma ISO denominado ISO / IEC 9899. Otros lenguajes, como Perl y Python, no disfrutan de dicho tratamiento y con frecuencia tienen una aplicación dominante que se utiliza como referencia.

Fundamentos 4.2. Sintaxis y semántica de lenguajes de de computación 13-11 programación

Al igual que los lenguajes naturales, muchos lenguajes de programación tienen alguna forma de especifica- ción por escrito de su sintaxis (forma) y semántica (Entretanto ing). Tales especificaciones incluyen, por ejemplo,

13-12 Guía SWEBOK® V3.0

requisitos específicos para la definición de Ables variabilidad y constantes (en otras palabras, declara- ción y tipos) y requisitos de formato para las mismas instrucciones. En general, un lenguaje de programación compatible con construcciones tales como variables, tipos de datos, con- stants, literales, instrucciones de asignación, las sentencias de control, procedimientos, funciones y comentarios. La sintaxis y la semántica de cada construcción deben estar claramente especificado. 4.3. Bajo Programación y Lenguajes lenguaje de programación se pueden clasificar en dos clases: los lenguajes de bajo nivel y lenguajes de alto nivel. lenguajes de bajo nivel pueden ser entendidos por un ordenador sin o con un mínimo de ayuda y por lo general incluyen lenguajes de máquina y lenguajes Bly bleas. Un lenguaje de máquina utiliza unos y ceros para representar instrucciones y variables, y es directamente comprensible por un ordenador. Un lenguaje ensamblador contiene las mismas instrucciones como un lenguaje máquina, pero las instrucciones y variables tienen nombres simbólicos que son más fáciles para los seres humanos a tener en cuenta. Los lenguajes ensambladores no pueden ser directamente Adjunto se pusieron junto a un ordenador y deben ser traducidos a un lenguaje de máquina por un programa de utilidad llamada un ensamblador. A menudo existe una correspondencia entre las instrucciones de un lenguaje ensamblador y un lenguaje de máquina, y la traducción del código ensamblador a código máquina es la sala straightfor-. Por ejemplo, “añadir R1, R2, R3” es una instrucción Bly Asam- para añadir el contenido del registro R2 y R3 y almacenar la suma en registro r1. Esta instrucción puede ser fácilmente traducido a código de máquina “0001 0001 0010 0011.” (Suponga el código fun- cionamiento para la adición es 0001, véase la figura 13.2). añadir 0001

r1,

r2,

R3

0001

0010

0011

Figura 13.2. Asamblea-a-binario Traducciones

Un rasgo común compartido por estos dos

tipos de lenguaje es su estrecha asociación con las características específicas de un tipo de arquitectura del ordenador Conjunto de instrucciones (ISA).

4.4. -Programación y Lenguajes Un lenguaje de programación de alto nivel tiene una fuerte abstracción de los detalles de ISA de la computadora. En comparación con los lenguajes de programación de bajo nivel, a menudo se utiliza ele- mentos de lenguaje natural y por lo tanto mucho más fácil de entender para los humanos. Tales lenguajes permiten ing nam- simbólica de variables, proporcionan expresividad, y permitir que la abstracción del hardware subyacente. Por ejemplo, mientras que cada uno tiene su propio microprocesador ISA, el código escrito en un lenguaje de programa- ming alto nivel suele ser portable entre muchas plataformas de hardware diferentes. Por estas razones, la mayoría de los programadores utilizar y la mayoría del software están escritos en lenguajes de programación de alto nivel. Ejemplos de lenguajes de programación de alto nivel incluyen C, C ++, C #, y Java. 4.5. vs. declarativa de programación imperativo Idiomas La mayoría de los lenguajes de programación (de alto nivel o de bajo nivel) permiten a los programadores especificar las instrucciones indi- viduales que una computadora es ejecutar. Tales lenguajes de programación son llamados lenguajes de programación imperativo porque uno tiene que especificar claramente cada paso a la computadora. Sin embargo, algunos lenguajes de programación permiten que los programadores sólo para describir la función que se formaron per- sin especificar las secuencias de instrucciones exactas para ser ejecutados. Tales lenguajes de programación son llamados lenguajes de programación declarativos. lenguajes declarativos son lenguajes de alto nivel. La implementación real de la computación escrito en un lenguaje tal está oculto a los programadores y por lo tanto no es una preocupación para ellos. El punto clave a tener en cuenta es que la programa- ción declarativa sólo describe lo que el programa debe lograr sin describir cómo lograrlo. Por esta razón, muchas personas creen que la programación declarativa facilita el desarrollo de software más fácil. lenguajes de programación declarativos incluyen Lisp (también un lenguaje de programación funcional) y Prolog, mientras que los lenguajes de programación imperativos incluyen C, C ++ y

Java.

Fundamentos de computación 13-13

13-14 Guía SWEBOK® V3.0

5. Las herramientas y técnicas de depuración

5.2. Las técnicas de depuración [3 *, c23]

Una vez que un programa se codifica y se compila (ción compilación será discutido en la sección 10), el siguiente paso es la depuración, que es un proceso metódico de encontrar y reducir el número de errores o fallos en un programa. El propósito de la depuración es averiguar por qué un programa no funciona o produce un resultado o salida equivocada. Excepto en los programas muy simples, la depuración es siempre necesario. 5.1. Tipos de error Cuando un programa no funciona, a menudo es debido a que el programa contiene errores o errores que pueden ser o errores sintácticos, errores lógicos o errores en los datos. Los errores lógicos y de datos de errores también se conocen como dos categorías de “fallos” en la terminología de ingeniería de software (véase el tema 1.1, Ter-Testing relacionada minology, en el KA de Pruebas de Software). Los errores de sintaxis son simplemente cualquier error que, impediría el traductor (compilador / intérprete) de analizar con éxito el comunicado. Cada ment estatal en un programa debe analizar-poder antes de su significado puede ser entendido e interpretado (y, por lo tanto, ejecuta). En los lenguajes de programación de alto nivel, los errores de sintaxis son capturados durante la compilación o la traducción del lenguaje de alto nivel en código máquina. Por ejemplo, en el lenguaje de programación C C / ++, la instrucción “123 = constante;” contiene un error de sintaxis que será capturado por el compilador durante la compilación. Los errores lógicos son los errores semánticos que resultan en cálculos incorrectos o comportamientos del programa. Su programa es legal, pero mal! Por lo que los resultados no coinciden con el planteamiento del problema o ex- pectativas de usuario. Por ejemplo, en el lenguaje de programación C / C ++, la función en línea “int f (int x) {return f (x-1);}” para el cálculo de x factorial! es legal, pero lógicamente incorrecto. Este tipo de error no puede ser atrapado por un compilador durante la compilación y, a menudo se descubre a través de

Depuración implica muchas actividades y puede ser rastreo de la ejecución del programa (damas estáticos modernos hacen identificar algunos de estos errores. Sin embargo, el punto es que estos no son verificables máquina en general). errores en los datos de entrada son los errores que resultan ya sea en los datos de entrada que es diferente de lo que el programa espera o en el tratamiento de los datos erróneos.

estático, dinámico o postmortem. depuración estático por lo general toma la forma de revisión de código, mientras que la depuración dinámico generalmente toma la forma de rastreo y está estrechamente asociada con la prueba. depuración Postmortem es el acto de la depuración de la volcado de memoria (volcado de memoria) de un proceso. Los vaciados de memoria se generan a menudo después de un proceso ha le ponga fin debido a una excepción no controlada. Las tres técnicas se utilizan en diversas etapas del desarrollo del programa. La principal actividad de depuración dinámica está trazando, que está ejecutando el programa de una pieza a la vez, el examen de los contenidos de los registros y la memoria, con el fin de examinar los resultados en cada paso. Hay tres modos de buscar un programa. • Solo paso a paso: ejecutar una instrucción a la hora de asegurarse de que cada instrucción se ejecu- tados correctamente. Este método es tedioso, pero útil para verificar cada paso de un programa. • Los puntos de interrupción: decir que el programa deje ing execut- cuando llega a una instrucción específica. Esta técnica permite una rápida ejecutar secuencias de código seleccionado para obtener una visión general de alto nivel del comportamiento de ejecución. • Ver puntos: decirle al programa que parar cuando un registro o memoria ubicación cambia o cuando es igual a un valor específico. Esta técnica es útil cuando uno no sabe dónde o cuando se cambia un valor y cuando este cambio de valor de las posibles causas del error. 5.3. Herramientas de depuración La depuración puede ser complejo, difícil y tedioso. Como la programación, depuración también es muy creativo (a veces más creativa que la programación). De este modo la ayuda de herramientas está en orden. Para la depuración dinámica, depuradores son ampliamente utilizados y permiten al programador para controlar la ejecución de un programa, detienen la ejecución, reiniciar la ejecución, establecer puntos de interrupción, los valores de cambio en la memo- ria, e incluso, en algunos casos, se remontan en hora. Para la depuración estática, hay muchas herramientas de análisis de código estático, que buscan un conjunto específico de problemas conocidos dentro del código fuente.

Fundamentos de computación 13-15

13-16 Guía SWEBOK® V3.0

Existen dos herramientas comerciales y gratuitas en varios idiomas. Estas herramientas pueden ser extremadamente útil para comprobar muy grandes árboles de origen, donde no es práctico hacer tutoriales de código. El programa de pelusa UNIX es un ejemplo temprano. 6. Estructura de datos y representación [5 *, s2.1-2.6] Los programas funcionan en los datos. Pero los datos se expresan y organizan dentro de los ordenadores antes de ser procesados por los programas. Esta organización y expresión de datos para su uso programas es el tema de la estructura de datos y la representación. Simponer capas, una estructura de datos intenta almacenar y organizar los datos en un ordenador de una manera tal que los datos pueden ser utilizados de manera eficiente. Hay muchos tipos de estructuras de datos y cada tipo de estructura es adecuada para algunos tipos de aplicaciones. Por ejemplo, B / B + árboles son muy adecuadas para la implementación de sistemas de archivos maestras sivos y bases de datos. 6.1. Presentación de la estructura de datos Las estructuras de datos son representaciones informáticas de datos. Las estructuras de datos se utilizan en casi todas las pro- grama. En un sentido, ningún programa significativo puede ser construido sin el uso de algún tipo de estructura de datos. Algunos métodos de diseño y lenguajes de progra- ming incluso organizan todo un sistema de software alrededor de las estructuras de datos. Fundamentalmente, las estructuras de datos son abstracciones definidas en una lection COL- de datos y sus operaciones asociadas. A menudo, las estructuras de datos están diseñados para el programa de ING improv- o la eficiencia del algoritmo. Ejemplos de tales estructuras de datos incluyen pilas, colas y montones. En otras ocasiones, las estructuras de datos se utilizan para la unidad conceptual (resumen tipo de datos), tales como el nombre y dirección de una persona. A menudo, una tura de datos estruc- puede determinar si un programa se ejecuta en unos pocos segundos o en unas pocas horas o incluso unos pocos días. Desde la

perspectiva de ordenamiento cal física y logi-, una estructura de datos es ya sea lineal o no lineal. Otras perspectivas dan lugar a dife- rentes clasificaciones que incluyen homogénea vs. heterogénea, estático vs. dinámico, persistente vs. transitoria, externo vs. interna, primitivo vs. agregado, recursiva vs. no recursiva; vs pasiva activo; y estructuras con estado vs sin estado.

6.2. tipos de Estructura de Datos Como se mencionó anteriormente, diferentes perspectivas se pueden utilizar para clasificar las estructuras de datos. Sin embargo, la perspectiva predominante usado en la clasificación se centra en orden físico y lógico entre los elementos de datos. Esta clasificación divide estructuras de datos en las estructuras lineales y no lineales. estructuras lineales organizan los elementos de datos en una única dimensión en la que cada entrada de datos tiene una (físico o lógico) predecesor y sucesor uno con la excepción de la primera y última entrada. La primera entrada no tiene predecesor y la última entrada no tiene sucesor. estructuras no lineales organizan los elementos de datos en dos o más dimensiones, en cuyo caso, una entrada puede tener varios predecesores y sucesores. Ejemplos de estructuras lineales incluyen listas, pilas y colas. Ejemplos de estructuras no lineales incluyen montones, tablas hash, y los árboles (tales como árboles binarios, árboles de equilibrio, los árboles B, y así sucesivamente). Otro tipo de estructura de datos que se encuentra a menudo en la programación es la estructura del compuesto. Una estructura de datos compuesto se acumula en la parte superior de otros (más primitivos) estructuras de datos y, de alguna manera, se puede ver como la misma estructura que la estructura subyacente. Ejemplos de estructuras compuesto incluyen conjuntos, gráficos y ciones culas. Por ejemplo, una partición puede ser vista como un conjunto de conjuntos. 6.3. Las operaciones en Estructuras de Datos Todas las estructuras de datos soportan algunas operaciones que producen una estructura y un orden específico, o recuperar los datos relevantes de la estructura, almacenar datos en la estructura, o borrar los datos de la estructura. Operaciones básicas con el apoyo de todas las estructuras de datos incluyen crear, leer, actualizar y eliminar (ABM). • Crear: Inserte una nueva entrada de datos en el estructura. • Lea: Recuperar una entrada de datos de la estructura. • Actualización: modificar una entrada de datos existente. • Eliminar: Eliminar una entrada de datos de la

estructura.

Fundamentos de computación 13-17

Algunas estructuras de datos también apoyan adicional operaciones:

13-18 Guía SWEBOK® V3.0

• Buscar un elemento en particular en la estructura. • Ordenar todos los elementos de acuerdo con algún orden. • Recorrer todos los elementos en un orden específico. • Reorganizar o reequilibrar la estructura. Diferentes estructuras de apoyo diferentes opera- ciones con diferentes eficiencias. La diferencia entre la eficiencia de la operación puede ser significativo. Por ejemplo, es fácil de recuperar el último elemento insertado en una pila, pero encontrar un ele- mento particular dentro de una pila es bastante lento y tedioso. 7. Algoritmos y Complejidad [5 *, s1.1-1.3, s3.3-3.6, s4.1-4.8, s5.1-5.7, s6.1-6.3, s7.1-7.6, s11.1, S12.1] Los programas no son al azar piezas de código: están escritos meticulosamente para realizar acciones a la esperada por el usuario. La guía uno utiliza para componer programas son algoritmos, que organizan diversas funciones en una serie de pasos y tienen en cuenta el dominio de aplicación, la estrategia de solución, y las estructuras de datos que se utiliza. Un algoritmo puede ser muy simple o muy compleja. 7.1. Descripción general de Algoritmos Hablando en abstracto, algoritmos guían las opera- ciones de ordenadores y consisten en una secuencia de acciones compuestas para resolver un problema. Definiciones alternativas incluyen, pero no se limitan a: • Un algoritmo es cualquier procedimiento computacional bien definido que lleva algún valor o conjunto de valores como entrada y produce un cierto valor o conjunto de valores como salida. • Un algoritmo es una secuencia de pasos de cálculo que transforman la entrada en la salida. • Un algoritmo es una herramienta para la resolución de un problema de cálculo especificada bien. Por supuesto, las diferentes definiciones son favorecidos por diferentes personas. Aunque no

existe una definición universalmente aceptada de Sally, existe cierto acuerdo en que un algoritmo tiene que ser correcta, finita (en otras palabras, terminan con el tiempo o uno debe ser capaz de escribir en un número finito de pasos), y sin ambigüedades.

7.2. Atributos de Algoritmos Los atributos de algoritmos son muchos y a menudo incluyen la modularidad, la corrección, dad maintainabil-, funcionalidad, robustez, facilidad de uso (es decir, fácil de ser entendido por personas), el tiempo mer programa-, simplicidad y extensibilidad. Un atributo comúnmente enfatizado com- es “rendimiento” o “eficiencia” por lo que entendemos tanto tiempo y eficiencia de los recursos en el uso, mientras que por lo general haciendo hincapié en el eje del tiempo. Hasta cierto punto, la deficiencia efi- determina si un algoritmo es factible o práctico. Por ejemplo, un algoritmo que toma cien años para terminar es prácticamente uso- menos y se considera incluso incorrecta. 7.3. Análisis algorítmico Análisis de algoritmos es el estudio teórico de rendimiento programa de ordenador y el uso de recursos; en cierta medida, que determina la bondad de un algoritmo. Tal análisis generalmente abstrae los detalles particulares de un equipo específico y se centra en el análisis dent asintótica, máquina-indepen-. Hay tres tipos básicos de análisis. En el análisis del peor caso, se determina el tiempo de mamá maxi- o los recursos requeridos por el algoritmo en cualquier entrada de tamaño n. En el análisis de caso promedio, se determina el tiempo esperado o los recursos requeridos por el algoritmo sobre todas las entradas de tamaño n; en la realización de análisis en el caso promedio, a menudo se tiene que hacer suposiciones sobre la dis- tribución estadística de los insumos. El tercer tipo de análisis es el análisis mejor de los casos, en los que se determina el tiempo mínimo o los recursos requeridos por el algoritmo en cualquier entrada de tamaño n. Entre los tres tipos de análisis, análisis de caso promedio es el más relevante pero también el más difícil de realizar. Además de los métodos de análisis básicos, también hay el análisis amortizado, en el que uno de- termina el tiempo máximo requerido por un Rithm algo- sobre una secuencia de las operaciones; y el análisis competitivo, en el que se determina el mérito relativo rendimiento de un algoritmo contra el algoritmo óptimo (que no puede ser conocido) de la misma categoría (por las mismas operaciones).

Fundamentos de computación 13-19

Fundamentos de computación 13-11

7.4. Estrategias de diseño algorítmico El diseño de algoritmos sigue generalmente una de las siguientes estrategias: la fuerza bruta, divide y vencerás, programación dinámica, y la selección codiciosos. La estrategia de la fuerza bruta es en realidad una estrategia no. Se trata de manera exhaustiva todos los medios posibles para hacer frente a un problema. Si un problema tiene una solu- ción, esta estrategia está garantizada para encontrarlo; Sin embargo, el gasto de tiempo puede ser demasiado alto. La estrategia de divide y vencerás mejora en la estrategia de la fuerza bruta dividiendo un gran problema en problemas más pequeños y homogéneos. Se resuelve el gran problema por resolver de forma recursiva los problemas más pequeños y peinado de las soluciones a los problemas más pequeños para formar la solución al gran problema. El supuesto subyacente de divide y vencerás es que los problemas más pequeños son más fáciles de resolver. La estrategia de programación dinámica mejora en la estrategia de divide y vencerás por ING reconocibles que algunos de los subproblemas producidos por la división puede ser el mismo y por lo tanto evita la solución de los mismos problemas una y otra vez. Este ción de elimina- subproblemas redundantes puede mejorar dramáticamente la eficiencia. La estrategia de selección codiciosos mejora aún más en programación dinámica mediante el reconocimiento de que no todos los subproblemas contribuyen a la solu- ción de la gran problema. Al eliminar todas menos una subproblema, la estrategia de selección codiciosos logra la más alta eficiencia entre todas las estrategias de diseño rithm algo-. A veces, el uso de la aleatorización puede mejorar en la estrategia de selec- ción codiciosos al eliminar la complejidad en la determinación de la elección codicioso a través de monedas de ping flip o aleatorización. 7.5. Estrategias de análisis algorítmico Las estrategias de análisis de algoritmos incluyen el análisis de contar en forma básica, en la que uno realmente cuenta el número de pasos de un algoritmo tarda en completar su tarea; análisis asintótico, en el que uno sólo considera el orden de magnitud del número de pasos de un

algoritmo toma para com- pleta su tarea; análisis probabilístico, en el que se hace uso de las probabilidades en el análisis del rendimiento medio de un algoritmo; amor- análisis Tized, en el que uno utiliza los métodos de

13-12 Guía SWEBOK® V3.0

agregación, potencial, y la contabilidad para ana- Lyze el peor rendimiento de un algoritmo en una secuencia de operaciones; y análisis de la competencia, en el que uno utiliza métodos tales como el potencial y la contabilidad para analizar el rendimiento relativo de un algoritmo para el algoritmo óptimo. Para problemas complejos y algoritmos, uno puede necesitar usar una combinación de las estrategias de análisis cionado aforemen-. 8. Concepto básico de un sistema de [6 *, c10] Ian Sommerville escribe, “un sistema es una colección propósito de componentes interrelacionados que trabajan en conjunto para lograr algún objetivo” [6 *]. Un sis- tema puede ser muy simple e incluir sólo unos pocos componentes, como una pluma de tinta, o más bien complejo, como un avión. Dependiendo de si los seres humanos son parte del sistema, los sistemas se pueden dividir en sistemas basados en computadoras técnicas y sistemas sociotécnicos. Un técnico funciones del sistema basado en computadora sin intervención humana, tales como televisores, teléfonos móviles, termostato, y algún tipo de software; un sistema socio-técnico no funcionará sin la intervención humana. Ejemplos de tal sistema incluyen vehículos tripulados espaciales, chips embebidos dentro de un ser humano, y así sucesivamente. 8.1. Propiedades del sistema emergente Un sistema es más que la simple suma de sus partes. Por lo tanto, las propiedades de un sistema no son simplemente la suma de las propiedades de sus componentes. En cambio, un sistema a menudo exhibe propiedades que son propiedades del sistema como un todo. Estas propiedades se denominan propiedades emergentes porque se desarrollan sólo después de la integración de las partes constituyentes en el sistema. las propiedades del sistema Emergentes pueden ser funcional o no funcional. propiedades funcionales describen las cosas que hace un sistema. Por ejemplo, las propiedades funcionales de un avión incluyen la flotación en el aire, llevando a las personas o carga, y su uso como arma de destrucción masiva. propiedades no funcionales describen cómo se comporta el sistema en su entorno operativo. Estos pueden incluir cualidades tales como consistencia, dad capaci-, el peso, la

seguridad, etc.

Fundamentos de computación 13-13

Figura 13.3. Los componentes básicos de un sistema informático basado en el modelo de von Neumann

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

Una computadora es una máquina que ejecuta programas o software. Se compone de una colección con propósito de mecánica, eléctrica,

13-14 Guía SWEBOK® V3.0

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

Fundamentos de computación 13-15

9. Organización de computadoras

[8 *, c1-c4]

Desde la perspectiva de un ordenador, existe una gran diferencia semántica entre su intención comporta- miento y el funcionamiento de los dispositivos electrónicos subyacentes que realmente hacen el trabajo dentro del equipo. Esta brecha se puentea a través del ordenador orga- nización, que engrana Various, Tronic elec- eléctrica, y dispositivos mecánicos en un solo dispositivo que forma un ordenador. Los objetos que se ocupa de la organización de ordenador son los dispositivos, las conexiones y controles. La abstracción construida en la organización del equipo es el equipo. 9.1. Organización general del ordenador Un equipo consiste generalmente en una CPU, memo- ria, dispositivos de entrada y dispositivos de salida. Hablando en abstracto, la organización de un ordenador se puede dividir en cuatro niveles (Figura 13.4). El nivel de arquitectura macro es la especificación formal de todas las funciones de una máquina en particular se puede llevar a cabo y se conoce como la arquitectura del conjunto de instrucciones (ISA). El nivel de arquitectura micro es la actividad mental en práctica de la ISA en un específico CPU-en otras palabras, la manera en que las especificaciones del ISA se llevan a cabo realmente. El nivel de los circuitos lógicos es el nivel en el que cada componente funcional de la micro arquitectura se construye de circuitos que toman decisiones basadas en reglas simples. El nivel de los dispositivos es el nivel donde, finalmente, cada circuito lógico está construido de dispositivos electrónicos tales como semiconductores complementarios de óxido metálico (CMOS), n de canal-semiconductores de óxido de metal (NMOS), o arseniuro de galio (GaAs) transistores, y por lo tanto adelante. Macro Arquitectura Nivel (ISA) Micro Arquitectura Nivel Circuitos lógicos Nivel Nivel dispositivos Figura 13.4. Niveles arquitectura de la máquina

la ISA, que especifica las cosas tales como el nativo de tipos de datos, instrucciones, registros, modos de direccionamiento, la arquitectura de memoria, interrumpir y Cada nivel proporciona una abstracción al nivel superior y es dependiente en el nivel inferior. Para un programador, el más importante es la abstracción

13-16 Guía SWEBOK® V3.0 manejo de excepciones,

y las E / S. En general, el ISA especifica la capacidad de un ordenador y qué se puede hacer en el equipo con la programación. 9.2. Sistemas digitales En el nivel más bajo, los cálculos se llevan a cabo por los dispositivos eléctricos y electrónicos dentro de un ordenador. El equipo utiliza circuitos y memo- ria para sostener los cargos que representa la presencia o ausencia de tensión. La presencia de tensión es igual a un 1 mientras que la ausencia de tensión es un cero. En el disco de la polaridad de la tensión está representada por 0 y 1 que a su vez representa los datos almacenados. Todo, incluyendo la instrucción y los datos se expresa o se codifica mediante ceros digitales y unos. En este sentido, un ordenador se convierte en un sistema digital. Por ejemplo, el valor decimal 6 puede ser codificada como 110, la instrucción de adición puede ser codificado como 0001, y así sucesivamente. El componente del ordenador, tales como la unidad de control, ALU, la memoria y E / S usa la información para calcular las instrucciones. 9.3. lógica digital Obviamente, se necesitan lógicas para manipular los datos y para controlar el funcionamiento de los ordenadores. Esta lógica, que está detrás ción fun- adecuada de un ordenador, se llama la lógica digital, ya que se ocupa de las operaciones de ceros digitales y unos. lógica digital especifica las reglas tanto para la construcción de diversos dispositivos digitales de los elementos más simples (tales como transistores) y para gobernar el funcionamiento de los dispositivos digitales. Por ejemplo, la lógica digital detalla cuál será el valor si un cero y uno es un AND, un OR o un OR exclusivo juntos. También especifica cómo construir decodificadores, multiplexores ERS (MUX), memoria y sumadores que se utilizan para montar el equipo. 9.4. Expresión de datos del ordenador Como se mencionó antes, un ordenador expresa los datos con las señales eléctricas digitales o ceros y unos. Puesto que hay sólo dos dígitos utilizados en diferentes

Fundamentos de computación 13-17

expresión de datos, un sistema de este tipo se llama un sistema de expresión binario. Debido a la naturaleza inherente de un sistema binario, el valor numérico máximo expresable por un código binario de n bits es 2n - 1. En concreto, el número binario aa aa ... pondiente norte n-11 0 ponde a unan  2norte + a n-1 + ... + a 1 + o r t e

n-1

1

u0  20. Por lo tanto, el valor numérico de la n  1 = 11. Expresar un valor no numérico, necesitamos para decidir el número de ceros y unos de usar y el orden en que están dispuestos los ceros y unos. Por supuesto, hay diferentes maneras de hacer la codificación, y esto da lugar a diferentes esquemas de expresión de datos y subsistemas. Por ejemplo, los números enteros se pueden expresar en forma de, complemento de uno o complemento sin firmar de dos. Para los personajes, hay ASCII, Unicode y normas EBCDIC de IBM. Para los números de punto flotante, hay IEEE-754 FP 1, 2 y 3 estándares. 9.5. La Unidad Central de Procesamiento (CPU) La unidad central de procesamiento es el lugar en el que las instrucciones (o programas) son realmente ejecutados. La ejecución por lo general toma varias medidas, ING INCLUYENDO ir a buscar la instrucción de programa, la decodificación de la instrucción, ir a buscar operandos, que realizan operaciones aritméticas y lógicas de los operandos, y almacenar el resultado. Los principales componentes de una CPU constan de registros donde instruc- ciones y los datos son a menudo leer y escribir a, la unidad aritmética y lógica (ALU) que realiza la aritmética real (tales como la adición, ción subtrac-, multiplicación y división) y lógicas (tales como y, O, las operaciones de cambio, y así sucesivamente), la unidad de control que es responsable de producir las señales apropiadas para controlar las operaciones, y varios estandares (datos, dirección y control) autobuses que enlazan la componentes juntos y los datos de transporte hacia y desde estos componentes. 9.6. Organización del Sistema de memoria

• • • •

Las células de memoria y chips placas y módulos de memoria jerarquía de memoria y la memoria caché La memoria como un subsistema del equipo.

Las células de memoria y chips tratar con un solo digitales La memoria es la unidad de almacenamiento de un ordenador. It preocupaciones con- el montaje de un sistema de memoria a gran escala a partir de unidades más pequeñas y de almacenamiento de un solo dígito. Los principales temas tratados en la arquitectura de memoria tem sis- incluyen los siguientes:

13-18 Guía SWEBOK® el almacenamiento y elV3.0 montaje

de unidades de un solo dígito en matrices de memoria unidimensionales, así como el montaje de matrices de almacenamiento unidimensionales en chips de memoria de almacenamiento multidimensionales. placas y módulos de memoria se refieren al montaje de chips de memoria en la memoria TEMS sis-, con el foco que está en la organización, el funcionamiento y la gestión de los chips individuales en el sistema. jerarquía de memoria y la memoria caché se utilizan para apoyar las operaciones de memoria eficientes. La memoria como un subsistema se ocupa de la interfaz entre el sistema de memoria y otras partes de la computadora. 9.7. Entrada y salida (I / O) Un ordenador es inútil sin I / O. dispositivos de entrada comunes incluyen el teclado y ratón; dispositivos de salida comunes incluyen el disco, la pantalla, la impresora y altavoces. Diferentes dispositivos de E / S funcionan a diferentes velocidades de datos y capacidades reli-. ¿Cómo se conectan los ordenadores y administrar varios dispositivos de entrada y salida para facilitar la interacción entre computadoras y seres humanos (u otros equipos) es el foco de los temas de E / S. Los principales problemas que deben ser resueltos en la entrada y la salida son las formas de E / S pueden y deben llevarse a cabo. En general, I / O se lleva a cabo tanto a nivel Ware y software duro. Hardware I / O se puede realizar en cualquiera de tres maneras. Dedicado I / O dedica a la CPU para las operaciones de entrada y salida reales durante I / O; trata de E / S mapeada en memoria de E / S de operaciones como operaciones de memoria; y híbrido I / O combina dedicado I / O y la memoria-E / S mapeada en un solo modo de operación de E / S holística. Coincidentemente, el software de E / S puede estar formada también per- en una de tres maneras. E / S programada permite la espera de la CPU mientras que el dispositivo de E / S está haciendo E / S; interrumpir impulsada I / O deja para el manejo de la CPU de I / O ser accionado por el dispositivo de I / O; y acceso directo a memoria (DMA) permite I / O ser manejado por un CPU secundaria incrustado en un dispositivo DMA (o

Fundamentos de computación 13-19

canal). (Excepto durante la configuración inicial, la CPU principal no se altera durante una operación de DMA I / O). Independientemente de los tipos de esquema de E / S que se utilizan, las principales cuestiones relacionadas con la E / S incluyen E / S de direccionamiento (que se ocupa de la cuestión de cómo identificar el dispositivo de E / S para un específico de E / S opera- ción) , sincronización (que se ocupa de la cuestión de cómo hacer que la CPU y I / O dispositivo funcione en armonía durante I / O), y la detección y corrección de errores (que trata de la ocurrencia de errores de transmisión). 10. Fundamentos del compilador [4 *, s6.4] [8 *, S8.4] 10.1. Compilador / intérprete general Los programadores suelen escribir programas en código de lenguaje de alto nivel, que la CPU no puede eje- linda; por lo que este código fuente tiene que ser convertido en código de máquina para ser entendido por un ordenador. Debido a las diferencias entre los diferentes NIA, la traducción debe hacerse para cada ISA o espelenguaje de máquina CIFIC bajo consideración. La traducción se realiza generalmente por una pieza de software llamado un compilador o un intérprete. Este proceso de traducción de un lenguaje de alto nivel a un lenguaje máquina se llama compilación ción, o, a veces, la interpretación. 10.2. Interpretación y compilación Hay dos formas de traducir un programa escriben normalmente con un lenguaje de alto nivel en código de máquina: interpretación y compilación. Interpretación traduce el código fuente de una instrucción a la vez en lenguaje de máquina, lo ejecuta en el lugar, y luego regresa para otro comunicado. Tanto el código fuente de nivel de lengua alto y el intérprete se requieren cada vez que se ejecuta el programa. Compilacion traduce el código de nivel de lengua fuente alta en todo un programa en lenguaje de máquina (una imagen ejecutable) por un programa que se llama un compilador. Después de la compilación, sólo se necesita la

imagen ejecutable para ejecutar el programa. La mayoría del software aplica- ción se vende en esta forma. Mientras tanto la compilación e interpretación con- vert código de lenguaje de alto nivel en código máquina,

13-20 Guía SWEBOK® V3.0

hay algunas diferencias importantes entre los dos métodos. En primer lugar, un compilador hace que la conver- sión sólo una vez, mientras que un intérprete normalmente con- verts cada vez que se ejecuta un programa. En segundo lugar, la interpretación de código es más lenta que la ejecución del código compilado, ya que el intérprete debe analizar cada declaración en el programa cuando se ejecuta y luego realizar la acción deseada, mientras que el código compilado solo realiza la acción dentro de un contexto fijo determinado por el Compilacion. En tercer lugar, el acceso a las variables también es más lento en un intérprete porque la asignación de identificadores a los lugares de almacenamiento debe realizarse varias veces en tiempo de ejecución en lugar de en tiempo de compilación. Las tareas principales de un compilador pueden incluir preprocesamiento, análisis léxico, análisis sintáctico, análisis semántico, generación de código, y el código de optimización ción. averías causadas por el comportamiento del programa compilador incorrecto pueden ser muy difíciles de localizar. Por esta razón, los ejecutores del compilador invierten mucho tiempo, garantizar la exactitud de su software. 10.3. El proceso de compilación La compilación es una tarea compleja. La mayoría de los compiladores dividen el proceso de compilación en muchas fases. Una composición típica es la siguiente: • • • •

Análisis léxico Análisis de sintaxis o de análisis Análisis semántico Codigo de GENERACION

Análisis léxico divide el texto de entrada (el código fuente), que es una secuencia de caracteres, en observaciones separadas, que son para ser ignorado en acciones posteriores, y los símbolos básicos, que tienen significados léxicos. Estos símbolos básicos deben corresponder a algunos símbolos terminales de la gramática de la len- guaje de programación en particular. Aquí símbolos terminales se refieren a los símbolos ele- mentarios (o fichas) en la gramática que no se pueden cambiar. análisis sintáctico se basa en los resultados del análisis de léxico y descubre la estructura en el programa y determina si o no un texto se

ajusta a un formato esperado. ¿Es esta una correcta programa aliado textu- C ++? o ¿Es esta entrada tex- tualmente correcta? son preguntas típicas que pueden ser

Fundamentos de computación 13-21

respondida por análisis de sintaxis. análisis sintáctico determina si el código fuente de un programa es rect cor- y la convierte en una representación (árbol de análisis sintáctico) más estructurado para el análisis o la transformación semántica. El análisis semántico agrega la información semántica al árbol de análisis sintáctico construido durante el análisis sintáctico y construye la tabla de símbolos. Se realiza variabilidad comprobaciones semánticas OU que incluyen la comprobación de tipos, objeto de enlace (asociación de variables y funciones referencias con sus definiciones), y la asignación definitiva (que requieren todas las variables locales a ser inicializado antes de su uso). Si se encuentran errores, las sentencias de programa semánticamente incorrectos son rechazados y marcados como errores. Una vez que el análisis semántico es completa, la fase de generación de código comienza y transforma el código intermedio producido en las fases anteriores en el lenguaje de máquina nativo de la computadora bajo consideración. Esto implica recursos y almacenamiento de decisiones-tales como decidir qué variables para encajar en los registros y la memoria y la selección y programación de instrucciones de la máquina apropiados, junto con sus modos de direccionamiento asociados. A menudo es posible combinar múltiples fases en un solo pase el código en un compilador imple- mentación. Algunos compiladores también tienen una fase de preprocesado en el comienzo o después del análisis léxico que hace el trabajo de limpieza es necesario, tales como el procesamiento de las instrucciones de programa para el compilador (directivas). Algunos compiladores proporcio- nar una fase de optimización opcional al final de la compilación completa para optimizar el código (como el reordenamiento de la secuencia de instrucciones) para la eficiencia y otros objetivos deseables solicitados por los usuarios. 11. Sistemas operativos Fundamentos [4 *, c3] Cada sistema de complejidad significativa debe ser gestionado. Un ordenador, como un sistema eléctrico-mecánicos más bien compleja, necesita

su propio hombre-ager para la gestión de los recursos y actividades que tienen lugar en él. Que el gerente se llama un sistema de explota- ción (OS).

13-22 Guía SWEBOK® V3.0

11.1. Operativo general Sistemas sistemas operativos es una colección de software y firmware, que controla la ejecución de programas de ordenador y proporciona servicios tales como la asignación de recursos del ordenador, control de trabajo, entrada / salida de control y gestión de archivos en un sistema informático. Conceptualmente, un sistema operativo es un programa informático que gestiona los recursos de hardware y hace que sea más fácil de utilizar por aplicaciones mediante abstracciones agradables tando previas. Esta abstracción agradable a menudo se llama la máquina virtual e incluye cosas tales como procesos, memoria virtual y sistemas de archivos. Un sistema operativo oculta la complejidad del hardware subyacente y se encuentra en todos los equipos modernos. Las principales funciones desempeñadas por los sistemas operativos son ment manage- y la ilusión. Gestión se refiere a la gestión del sistema operativo (asignación y recuperación) de los recursos físi- cas entre múltiples usuarios / aplicaciones / tareas que compiten. La ilusión se refiere a las buenas abstracciones del sistema operativo proporciona. 11.2. Tareas de un sistema operativo Las tareas de un sistema operativo difieren significativamente dependiendo de la máquina y el tiempo de su invención. Sin embargo, los sistemas operativos modernos han llegado a un acuerdo en cuanto a las tareas que deben ser realizadas por un sistema operativo. Estas tareas incluyen la gestión de la CPU, la gestión de memoria, gestión de disco (sistema de archivos), I / O de gestión de dispositivos, y la seguridad y protección. Cada tarea OS hombreedades un tipo de recurso físico. Específicamente, ofertas de gestión de la CPU con la asignación y liberación de la CPU entre los programas que compiten entre sí (llamados procesos / hilos en la jerga OS), incluyendo el propio sistema operativo. La abstracción principal proporcionada por la administración de la CPU es el modelo de proceso / hilo. ofertas de gestión de memoria con la asignación y liberación de espacio de memoria entre procesos competitivos, y la principal abstracción proporcionada por la gestión de memoria es la memoria virtual. Gestión del disco se refiere a la puesta en común de los discos de estado magnéticos u ópticos o sólidos entre varios programas /

usuarios y su abstracción principal es el sistema de archivos. Yo dispositivo de E / S manageofertas de unificación con la asignación y liberación de varios dispositivos de E / S entre los procesos que compiten.

Fundamentos de computación 13-23

Seguridad y acuerdo de protección con la protección de los recursos informáticos de uso ilegal. 11.3. Las abstracciones del sistema operativo El arsenal de sistemas operativos es la abstracción. Correspondiente a las cinco tareas físicas, sistemas operativos utilizan cinco abstracciones: proceso / hilo, memoria virtual, siste- mas de archivos, de entrada / salida, y dominios de protección. La abstracción general OS es la máquina virtual. Para cada área de tareas de sistema operativo, no es tanto una realidad Physicians cal y una abstracción conceptual. La realidad ical phys- se refiere al recurso de hardware, en la gestión; la abstracción conceptual se refiere a la interfaz del sistema operativo presenta a los usuarios / programas anteriores. Por ejemplo, en el modelo de rosca del sistema operativo, la realidad física es la CPU y la abstracción es varias CPU. De este modo, el usuario no tiene que preocuparse acerca de compartir la CPU con los demás cuando trabajan en la abstracción proporcionada por un sistema operativo. En la abstracción de la memoria virtual de un sistema operativo, la realidad física es la memoria RAM física o ROM (lo que sea), la abstracción es el espacio de memoria ITED unlim- múltiple. De este modo, el usuario no tiene que preocuparse acerca de compartir la memoria física con otros o sobre el tamaño de la memoria física limitada. Las abstracciones pueden ser virtual o transparente; en este contexto virtual se aplica a algo que parece estar allí, pero no es (como memoria utilizable más allá física), mientras transparente se aplica a algo que está ahí, pero parece no estar allí (como ir a buscar contenido de la memoria desde el disco o la memoria física ). 11.4. Sistemas para realizar la clasificación Los diferentes sistemas operativos pueden tener una implementación diferente funcionalidad. En los primeros días de la era de los ordenadores, sistemas operativos fueron relativa- mente simple. A medida que pasa el tiempo, la complejidad y sofisticación de los sistemas operativos aumenta significativamente. Desde una perspectiva histórica, un sistema operativo

puede ser clasificado como uno de los siguientes. • OS procesamiento por lotes: organiza procesos de trabajo en lotes. Ejemplos tales sistemas operativos incluyen FMS IBM, IBSYS, y Universidad de UMES Michigan.

y de de de

13-24 Guía SWEBOK® V3.0

• Multiprogramado OS procesamiento por lotes: añade la capacidad de multi- titask en principios simples de procesamiento por lotes sistemas operativos. Un ejemplo de un sistema operativo como es de IBM OS / 360. • Tiempo compartido OS: agrega multi-tarea y las capacidades activas inter en el sistema operativo. Ejemplos de tales sistemas operativos incluyen UNIX, Linux y NT. • Sistema operativo en tiempo real: añade sincronización la previsibilidad en el sistema operativo mediante la programación de las tareas individuales de acuerdo con los plazos de realización de cada tarea. Ejemplos de tales OS incluyen VxWorks (WindRiver) y DART (EMC). • OS distribuido: Agrega la capacidad del hombre: el envejecimiento de una red de computadoras en el sistema operativo. • OS incrustado: tiene una funcionalidad limitada y se utiliza para sistemas embebidos, tales como automóviles y PDAs. Ejemplos de tales sistemas operativos como Palm OS, Windows CE, y PRIMERO.

Alternativamente, un OS se puede clasificar por su aplicable objetivo de la máquina / medio ambiente en lo siguiente. • OS unidad central: Se ejecuta en el computadoras centrales e incluyen OS / 360, OS / 390, AS / 400, MVS y VM. • Sistema operativo del servidor: se ejecuta en estaciones de trabajo o servidores e incluye sistemas como UNIX, Win- dows, Linux y VMS. • OS multicomputer: se ejecuta en múltiples ordenadores com- e incluyen ejemplos tales como Novell Netware. • ordenadores personales OS: se ejecuta en computadoras personales, e incluyen ejemplos tales como DOS, Windows, Mac OS y Linux. • OS dispositivo móvil: se ejecuta en dispositivos personales como teléfonos móviles, iPad e incluyen ejemplos de este tipo de iOS, Android, Symbian, etc. 12. Fundamentos de bases de datos y gestión de datos [4 *, c9] Una base de datos se compone de una

colección organizada de datos para uno o más usos. En un sentido, una base de datos es una generalización y expansión de estructuras de datos. Pero la diferencia es que una base de datos suele ser externa a programas individuales y permanente en existencia en comparación con las estructuras de datos. Las bases de datos se utilizan cuando el volumen de datos es grande o lógico

Fundamentos de computación 13-25

las relaciones entre los elementos de datos son importantes. Los factores considerados en el diseño de la base de datos incluyen Formance per-, concurrencia, la integridad, y la recuperación de fallos de hardware. 12.1. Entidad y de esquema Las cosas una base de datos intenta modelar y almacenar se denominan entidades. Las entidades pueden ser objetos del mundo real, como las personas, coches, casas, etc., o pueden ser conceptos abstractos tales como las personas, salario, nombres, y así sucesivamente. Una entidad puede ser primitiva, tales como un nombre o compuesto tal como un empleado que consiste en un nombre, número de identificación, el salario, dirección, y así sucesivamente. El concepto más importante en una base de datos es el esquema, que es una descripción de toda la estructura de la base de la cual se construyen todas las demás actividades de base de datos. Un esquema define los barcos relación entre las diversas entidades que componen una base de datos. Por ejemplo, un esquema de un sistema de nómina de la compañía consistiría en cosas tales como la identificación de empleado, nombre, tipo de salario, dirección, y así sucesivamente. software de base de datos mantiene la base de datos de acuerdo con el esquema. Otro concepto importante en la base de datos es el modelo de base de datos que describe el tipo de tionship relación entre las diversas entidades. Los modelos utilizados comúnmente incluyen relacional, la red y modelos de objetos. 12.2. Sistemas de Gestión de Bases de Datos (DBMS) Sistema de gestión de base de datos (DBMS) componentes incluyen aplicaciones de bases de datos para el almace- namiento de los datos estructurados y no estructurados y las funciones de gestión de base de datos necesarios necesarios para visualizar, recoger, almacenar y recuperar datos de las bases de datos. Un DBMS controla la creación, manteni- miento, y el uso de la base de datos y por lo general se clasifica de acuerdo con el modelo de base de datos que soporta tales como el, la red o modelo de objeto relacional. Por ejemplo, un sistema de gestión de

base de datos relacional (RDBMS) implementa las distintas prestaciones del modelo relacional. Un sistema de gestión de base de datos de objeto (ODBMS) implementa las distintas prestaciones del modelo de objetos.

13-26 Guía SWEBOK® V3.0

12.3. Lenguaje de consulta de base de datos Usuarios / aplicaciones interactúan con una base de datos a través de un lenguaje de consulta de base de datos, que es un lenguaje de programación cializada espe- adaptados a la utilización de bases de datos. El modelo de base de datos tiende a determinar los lenguajes de consulta que están disponibles para acceder a la base de datos. Un lenguaje de consulta de uso general para la base de datos relacional es el lenguaje de consulta estructurado, más comúnmente abreviado como SQL. Un lenguaje de consulta común para bases Datade objetos es el lenguaje de consulta de objeto (abreviado como OQL). Hay tres componentes de SQL: Lenguaje de definición de datos (DDL), Lenguaje de manipulación de datos (DML) y el Lenguaje de control de datos (DCL). Un ejemplo de una consulta DML puede ser similar al siguiente: SELECT Component_No, Cantidad de Component DONDE Item_No = 100 La consulta anterior selecciona todos los Component_No y su cantidad correspondiente de un componente de tabla de base de datos llamada, donde el Item_No es igual a 100. 12.4. Tareas Los paquetes de DBMS Un sistema DBMS proporciona las siguientes capacidades: • Las bases de datos se utiliza para definir y organizar el contenido, las relaciones, y la estructura de los datos necesarios para construir una base de datos. • la interrogación de bases de datos se utiliza para acceder a los datos en una base de datos para la recuperación de información y generación de informes. Los usuarios finales pueden recuperar de forma selectiva y mostrar información y producir informes impresos. Esta es la operación que la mayoría de los usuarios saben acerca de las bases de datos. • Mantenimiento de base de datos se utiliza para agregar, eliminar, actualizar y corregir los datos en una base de datos. • Desarrollo de aplicaciones se utiliza para desarrollar prototipos de pantallas de entrada de datos, consultas, formularios, informes, tablas y etiquetas para una

aplicación escrita a máquina proto. También se refiere al uso de cuarto de idioma o aplicación de generación de erators generaciones para desarrollar o generar código de programa.

Fundamentos de computación 13-27

12.5. Gestión de datos Una base de datos debe gestionar los datos almacenados en ella. Esta gestión incluye tanto la organización y almacenamiento. La organización de los datos reales en una base de datos depende del modelo de base de datos. En un modelo relacional, los datos se organizan en forma de tablas con diferentes tablas que representan entidades o relaciones diferentes entre un conjunto de entidades. El almacenamiento de datos se refiere a la conservación de estas tablas de bases de datos en discos. Las formas más comunes para lograr esto es utilizar los archivos. Secuencial, indexada, y los archivos de hash se utiliza en toda esta finalidad con diferentes estructuras de archivos que proporcionan un rendimiento diferente acceso y comodidad. 12.6. La minería de datos A menudo se tiene que saber qué buscar antes de consultar una base de datos. Este tipo de “localización de” acceso no hace un uso completo de la gran cantidad de información almacenada en la base de datos, y de hecho reduce la base de datos en una colección de registros discretos. Para sacar el máximo provecho de una base de datos, se puede llevar a cabo el análisis estadístico y el patrón de discovery sobre el contenido de una base de datos utilizando una tecno- minería de datos llamados nique. Tales operaciones se pueden utilizar para apoyar una serie de actividades comerciales que incluyen, pero no se limitan a, la comercialización, la detección de fraudes y análisis de tendencias. Numerosas formas de realización de la minería de datos se han inventado en la década pasada e incluyen técnicas comunes tales como descripción de la clase, la discriminación de clase, análisis de conglomerados, análisis de asociación, y el análisis de valores atípicos. 13. Conexión de red básica de comunicación [8 *, c12] Una red de ordenadores se conecta un conjunto de equipos y permite a los usuarios de los diferentes ordenadores compartir recursos con otros usuarios. Una red facilita las

comunicaciones entre todos los ordenadores conectados y puede dar la ilusión de un único equipo, omnipresente. Cada dispositivo puter o com- conectado a una red se llama un nodo de red. Anumber de los paradigmas de computación han surgido para beneficiarse de las funciones y capacidades

13-28 Guía SWEBOK® V3.0

proporcionada por las redes de ordenadores. Estos paradigmas incluyen computación distribuida, grid computing, computación Internet, y la nube. 13.1. tipos de la Red Las redes de ordenadores no todos son iguales y pueden clasificarse de acuerdo a una amplia variedad de características, incluyendo el método de la red de conexiones ción, tecnologías alámbricas, las tecnologías inalámbricas, la escala, la topología de red, funciones y velocidad. Sin embargo, la clasificación que es familiar a la mayoría se basa en la escala de las redes. • Red de área personal / red doméstica es una red de ordenador utilizado para la comunicación entre la computadora (s) y diferentes dispositivos tecnológicos información cerca de una per- sona. Los dispositivos conectados a una obra tal NET pueden incluir ordenadores, faxes, PDAs, y televisores. Esta es la base sobre la que se construye el Internet de las cosas. • Red de área local (LAN) conecta computadoras y dispositivos en un área geográfica limitada, como un campus de la escuela, la oratoria en laboratorio informático, edificio de oficinas, o grupo de cerca posicionado de edificios. • campus Red es una red de ordenadores compuesto por una interconexión de redes de área local (LAN) dentro de un área geográfica limitada. • Red de área amplia (WAN) es una red de computadoras que cubre una gran área geográfica, como una ciudad o país o incluso a través de distancias intercontinentales. Una WAN limitado a una ciudad a veces se llama una Red de Área Metropolitana. • Internet es la red mundial que conecta los ordenadores ubicados en muchos (tal vez todos) los países. Otras clasificaciones pueden dividir las redes en las redes de control, redes de almacenamiento, redes pri- vado virtuales (VPN), redes inalámbricas, redes punto-apunto, e Internet de las Cosas. 13.2. Componentes de la Red Básica Todas las redes se componen de los mismos

componentes básicos hard- ware, incluyendo las computadoras, la red

Fundamentos de computación 13-29

tarjetas de interfaz (NIC), puentes, concentradores, conmutadores y routers. Todos estos componentes se denominan nodos en la jerga de las redes. Cada componente per- forma una función distintiva que es esencial para el embalaje, la conexión, la transmisión, catión amplifi-, controlando, desembalaje, y la interpretación de los datos. Por ejemplo, un repetidor amplifica las señales, un interruptor realiza muchos-a-muchos conexiones, un concentrador realiza uno-a-muchas conexiones, una tarjeta de interfaz está conectado al ordenador y realiza el embalaje de datos y de transmisión, un puente conecta uno red con otro, y un router es un ordenador en sí y realiza el análisis de datos y control de flujo para regular los datos de la red. Las funciones realizadas por diversos componentes de la red corresponden a las funciones especificadas por uno o más niveles de la interconexión de sistemas abiertos (OSI) modelo de red de siete capas, que se discute a continuación. 13.3. Protocolos de red y Estándares Las computadoras se comunican entre sí a través de protocolos, que especifican las ciones de formato y reglamentos utilizados para empacar y datos no-carga. Para facilitar más fácil la comunicación y la mejor estructura, protocolos de trabajo Net- se dividen en diferentes capas y cada capa se trata de un aspecto de la comunicación. Por ejemplo, el ERS lay- físicos se refieren a la conexión física entre las partes que se han de comunicar, las ofertas de la capa de enlace de datos con la transmisión de datos en bruto y el control de flujo, y las ofertas de la capa de red con el embalaje y unempaquetamiento de datos en un formato particular que sea comprensible por los lazos par- pertinentes. El modelo de red OSI más comúnmente utilizado organiza protocolos de red en siete capas, como se representa en la figura 13.5. Una cosa a tener en cuenta es que no todos los cols de red proto implementan todas las capas del modelo OSI. Por ejemplo, el protocolo TCP / IP implementa ni la capa de presentación ni la capa de sesión. No puede haber más de un protocolo para cada capa. Por ejemplo, UDP y TCP ambos trabajan en la capa de transporte por encima de

la capa de red IP, pro Viding de mejor esfuerzo, el transporte no fiable (UDP) vs. función de transporte confiable (TCP). protocolos de capa física incluyen token ring, Ethernet, Fast Ethernet, Gigabit Ethernet, y Ethernet inalámbrico. Datos

13-30 Guía SWEBOK® V3.0

protocolos de capa de enlace incluyen frame relay, modo de transferencia asíncrona (ATM), y el Protocolo de punto a punto (PPP). Los protocolos de capa de aplicación incluyen canal de fibra, Small Computer System Interface (SCSI) y Bluetooth. Para cada capa o incluso cada protocolo individual, puede haber normas establecidas por las organizaciones nacionales o internacionales para orientar el diseño y desa- rrollo de los protocolos correspondientes. Capa de aplicación Capa de presentación capa de sesión Capa de transporte Capa de red Capa de enlace de datos Capa fisica Figura 13.5. El modelo OSI de siete capas de redes

13.4. La Internet El Internet es un sistema mundial de interconectados gubernamental, académico, empresarial, público y redes de ordenadores privados. En el acceso al dominio público a Internet es a través de las organizaciones conocidas como proveedores de servicios de Internet (ISP). La ISP mantiene uno o más centros de conmutación llamado un punto de presencia, que en realidad con- nects los usuarios a Internet. 13.5. Internet de las Cosas La Internet de las cosas se refiere al establecimiento de una red de objetos cotidianos-tales como automóviles, teléfonos celulares, PDAs, televisores, refrigeradores, e incluso edificios: el uso de las tecnologías de redes cableadas o inalámbricas. La función y el propósito de la Internet de las cosas es interconectar todas las cosas para facilitar la vida autó- MOU y mejor. Las tecnologías utilizadas en el Internet de las cosas incluyen RFID, inalámbricas y redes cableadas, tecnología de sensores, software y mucho, por supuesto. A medida que el paradigma de Internet de las cosas todavía está tomando forma, se necesita mucho trabajo para la Internet de las cosas para ganar la aceptación

de amplia difusión.

Fundamentos de computación 13-31

13.6. Virtual Private Network (VPN) Una red privada virtual es una conexión virtual planificada de antemano entre los nodos de una red LAN / WAN o Internet. Permite al administrador de red para separar el tráfico de red en grupos de usuarios que tienen una afinidad común por los demás, como todos los usuarios de la misma organización o grupo de trabajo. Este tipo de circuito puede mejorar el rendimiento y la seguridad entre los nodos y permite el mantenimiento de los circuitos fácilIER para solucionar problemas. 14. Computación Paralela y Distribuida [8 *, c9] La computación paralela es un paradigma de computación que surge con el desarrollo de unidades multi-cionales fun- dentro de un ordenador. La principal tiva obje- de computación en paralelo es para ejecutar varias tareas simultáneamente en diferentes unidades funcionales y por lo tanto mejorar el rendimiento o la respuesta o ambos. La computación distribuida, por el contrario, es un paradigma de computación que surge con el desa- rrollo de las redes informáticas. Su principal objetivo es o bien hacer uso de varios ordenadores en la red para llevar a cabo las cosas de otra manera no posi- ble en un único ordenador o mejorar la eficiencia com- putation aprovechando el poder de varios equipos. 14.1. Computación paralela y distribuida general Tradicionalmente, la computación paralela investiga formas de maximizar la concurrencia (la ejecución simultánea de múltiples tareas) dentro del aria obligados- de un ordenador. estudios de sistemas de computación distribuida, que consiste en varios equipos autónomos que se comunican a través de una red de ordenadores distribuidos. Alternativamente, la informática distribuida también puede referirse a la utilización de sistemas distribuidos para resolver problemas de cálculo o transaccionales. En la definición anterior, la computación distribuida investiga los protocolos, mecanismos y estrategias que constituyen la base para el cálculo distribuido; en esta última definición, la

computación distribuida estudia las formas de dividir un problema en muchas tareas y la asignación de estas tareas a varios equipos implicados en el cálculo.

13-32 Guía SWEBOK® V3.0

Fundamentalmente, la informática distribuida es otra forma de computación en paralelo, aunque en una escala más grande. En computación distribuida, las unidades funcionales no son ALU, FPU, o núcleos separados, pero los ordenadores individuales. Por esta razón, algunas personas consideran que el cálculo distribuido por ser la misma que la computación paralela. Debido a que tanto distri- buido la computación y en paralelo implican algún tipo de concurrencia, que son a la vez también llamado alquiler de computación concurrente. 14.2. Diferencia entre la Computación Paralela y distri- buido A pesar de la computación paralela y distribuida resem- ble entre sí en la superficie, hay una distinción sutil pero real entre ellos: la computación en paralelo no se refiere necesariamente a la ejecución de programas en diferentes Computadoras- lugar, que se pueden ejecutar en diferentes procesadores en un único ordenador. De hecho, el consenso entre los profesionales de computación limita el alcance de la computación paralela al caso en que una memoria compartida es utilizada por todos los procesadores implicados en la computación, mientras que la computación distribuida se refiere a cálculos donde existe memoria privada para cada procesador implicados en los cálculos. Otra diferencia sutil entre la computación paralela y distribuida es que la computación paralela hace necesario la ejecución simultánea de varias tareas mientras computación distribuida no tiene esta necesidad. Basándose en la discusión anterior, es posible clasificar sistemas concurrentes como “paralelo” o “distribuido” en base a la existencia o tencia nonex- de memoria compartida entre todos los sor procesiones: ofertas de computación en paralelo con los cálculos dentro de una sola computadora; distribuido ofertas de computación con cálculos dentro de un conjunto de res computa. De acuerdo con este punto de vista, de múltiples núcleos de computación es una forma de computación paralelo. 14.3. Modelos de Computación Paralela y Distribuida Desde múltiples ordenadores / procesadores / núcleos están involucrados en la computación

distribuida / paralelo, una cierta coordinación entre las partes involucradas es nece- Essary para garantizar un comportamiento correcto del sistema.

Fundamentos de computación 13-33

Las diferentes formas de coordinación dan lugar a diferencias ent modelos de computación. Los els mo- más comunes en este sentido son la memoria compartida (paralelismos lel) modelo y el paso de mensajes (distribuido) modelo. En un modelo de memoria compartida (paralelo), todas las com- putadoras tienen acceso a una memoria central compartida donde se utilizan cachés locales para acelerar la capacidad de procesamiento. Estas cachés utilizan un protocolo para asegurar los datos localizada es fresco y hasta la fecha, típicamente el protocolo MESI. El diseñador algoritmo elige el programa para su ejecución por cada equipo. El acceso a la memoria central puede ser síncrono o asíncrono, y debe ser coordinada de tal manera que se mantiene la coherencia. modelos de acceso diferentes se han inventado para tal fin. En un modelo de paso de mensajes (distribuido), todos los equipos que ejecutan algunos programas que permitan alcanzar colectivamente algún propósito. El sistema debe funcionar correctamente, independientemente de la estructura de la obra NET. Este modelo se puede clasificar además en cliente-servidor (C / S), el navegador-servidor (B / S), los modelos y de n niveles. En el modelo C / S, el pro servicios y las solicitudes de los clientes de servicios desde el servidor Vides servidor. En el B / S modelo, el servidor de servicios de Vides pro y el cliente es el navegador. En el modelo de n niveles, cada nivel (es decir, capa) proporciona servicios a la capa inmediatamente por encima de ella y solicitudes de servicios desde el nivel inmediatamente por debajo de ella. De hecho, el modelo de n niveles puede ser visto como una cadena de modelos cliente-servidor. A menudo, los niveles entre el nivel más inferior y el nivel superior se llaman middleware, que es un objeto independiente de estudio por derecho propio. 14.4. Problemas principales en Distributed Computing La coordinación entre todos los componentes en un entorno informático buido dis- es a menudo complejo y requiere mucho tiempo. Como el número de núcleos / CPUs / ordenadores aumenta, la complejidad de la computación distribuida también aumenta. Entre los muchos problemas que enfrentan, la coherencia de la

15. Los factores humanos básicos de los usuarios

[3 *, c8] [9 *, c5]

memoria y el consenso entre todos los equipos son los más ficult rencias. Muchos paradigmas de computación se han inventado para resolver estos problemas y son los principales puntos de discusión en la computación distribuida / paralela.

13-34 Guía SWEBOK® V3.0para El software se desarrolla

satisfacer deseos o necesidades humanas. Por lo tanto, todo el diseño de software y desa- rrollo deben tener en cuenta factores-usuario humano consideración por ejemplo, cómo las personas utilizan software, software de cómo la gente ve, y lo que los humanos esperan de software. Hay numerosos factores en la interacción hombre-máquina, y 9241 serie ISO documento definen todas las normas detalladas de tales interacciones. [10] Pero los factores básicos para el usuario humano considerados aquí incluyen entrada / salida, el manejo de los mensajes de error y la robustez del software en general. 15.1. Entrada y salida La entrada y salida son las interfaces entre los usuarios y el software. El software es inútil sin entrada y salida. Seres humanos software de diseño para procesar algunos de entrada y producir una salida deseable. Todos los ingenieros de software deben tener en cuenta la entrada y OUT- poner como una parte integral del producto de software que ingeniero o desarrollan. Los temas considerados para la entrada incluyen (pero no se limitan a): • Lo que de entrada se requiere? • ¿Cómo se pasa de la entrada de los usuarios a las computadoras? • ¿Cuál es el modo más conveniente para los usuarios introducciones? • ¿Qué formato requiere el equipo de los datos de entrada? El diseñador debe solicitar los datos mínimos de la intervención humana, sólo cuando los datos aún no está guardada en el sistema. El diseñador debe formatear y editar los datos en el momento de la entrada para reducir los errores derivados de la introducción de datos incorrectos o maliciosos. Para la salida, debemos tener en cuenta lo que los usuarios desear ver: • ¿En qué formato se desea ver los usuarios de salida? • ¿Cuál es el modo más agradable a mostrar ¿salida?

Fundamentos de computación 13-35

Si la parte que interactúa con el software no es humana sino otro software o equipo o sistema de con- trol, entonces tenemos que considerar el tipo de entrada / salida y el formato que el software debe producir para garantizar el intercambio de datos entre sistemas adecuada. Hay muchas reglas de oro para los desarrolladores a seguir para producir el bien de entrada / salida para un soft- ware. Estas reglas generales incluyen diálogo sencillo y natural, hablando el lenguaje de los usuarios, minimizando la carga de usuarios de la memoria, la coherencia, la mínima sorpresa, la conformidad con las normas (si lo acordado o no: por ejemplo, los automóviles tienen una interfaz Dard Están- de acelerador, el freno , dirección). 15.2. Error de mensajes Es comprensible que la mayoría de software con- tiene defectos y no de vez en cuando. Sin embargo, los usuarios deben ser notificados si hay algo que impide la correcta ejecución del programa. Nada es más frustrante que una terminación inesperada o desviación del comportamiento del software sin ningún aviso o explicación. Para ser fácil de usar, el software debe informar de todos los con- diciones de error a los usuarios o aplicaciones de nivel superior, de manera que hasta cierto punto se puede tomar para rectificar la situación o para salir con gracia. Existen varias pautas que definen lo que constituye un buen mensaje de error: mensajes de error deben ser claros, hasta el punto, y oportuna. En primer lugar, los mensajes de error deben explicar claramente lo que está sucediendo para que los usuarios sepan lo que está pasando en el software. En segundo lugar, los sabios de error men- deben determinar la causa del error, si es posible, por lo que las acciones adecuadas se pueden tomar. En tercer lugar, los mensajes de error deben mostrarse justo cuando se produce la condición de error. De acuerdo con Jakob Nielsen, “Los buenos mensajes de error deben expresarse en un lenguaje sencillo (sin códigos), indican precisamente el problema y sugerir una solución constructiva” [9 *]. En cuarto lugar, los mensajes de error no deben sobrecargar los usuarios con informa- ción demasiado y hacer que se ignoran los mensajes de todos juntos.

Sin embargo, los mensajes relacionados con errores de acceso de seguridad no deben proporcionar información adicional que ayude a las personas no autorizadas minan.

13-36 Guía SWEBOK® V3.0

15.3. La robustez del software robustez del software se refiere a la capacidad de soft- ware para tolerar las entradas erróneas. Software se dice que es robusta si sigue funcionando incluso cuando se dan las entradas erróneas. Por lo tanto, es inaceptable para el software se bloquee simplemente cuando encuen- tering un problema de entrada ya que esto puede provocar consecuencias inesperadas, como la pérdida de datos valiosos. El software que exhibe tal comportamiento es sidered con- carecer de robustez. Nielsen da una descripción más simple de la robustez del software: “El software debe tener una baja tasa de error, por lo que los usuarios hacen algunos errores durante el uso del sistema y por lo que si lo hacen cometer errores que pueden recuperarse fácilmente de ellos. Además, los errores catastróficos no deben ocurrir”[9 *]. Hay muchas maneras de evaluar la robustez del software y al igual que muchas maneras de hacer el software más robusto. Por ejemplo, para mejorar la robustez, uno debe siempre comprobar la validez de las entradas y valores de retorno antes de progreso- ing aún más; uno siempre debe lanzar una excepción cuando ocurre algo inesperado, y uno nunca debe salir de un programa sin antes dar a los usuarios / aplicaciones la oportunidad de corregir la condición. 16. Desarrollador básica factores humanos [3 *, c31-32] factores humanos desarrolladores se refieren a las consideraciones de factores humanos tomadas en el desarrollo de software. El software se desarrolla por los seres humanos, leídos por los seres humanos, y mantenido por los seres humanos. Si Any-lo que está mal, los seres humanos son responsables de Correcting esos males. Por lo tanto, es esencial para escribir software de una manera que sea fácilmente comprensible por el ser humano o, por lo menos, por otros desarrolladores de software. Un programa que es fácil de leer y entender la legibilidad exposiciones. Los medios para garantizar que el software de cumplir este objetivo son numerosas y van desde la arquitectura adecuada a nivel macro al estilo de codificación particular y el uso variable en el nivel micro. Pero los dos factores importantes son la estructura (o programa) y los diseños de los comentarios

(documentación).

Fundamentos de computación 13-37

16.1. Estructura programas bien estructurados son más fáciles de entender y modificar. Si un programa no está bien estructurado, entonces ninguna cantidad de explicación o comentarios es suficiente para que sea comprensible. Las formas de organizar un programa son numerosas y van desde el uso adecuado de los espacios en blanco, la sangría, y los paréntesis de buenos arreglos de agrupaciones, las líneas en blanco, y los apoyos. Sea cual sea el estilo que se elija, debe ser consistente a través de todo el programa. 16.2. comentarios Para la mayoría de la gente, la programación es la codificación. Estas personas no se dan cuenta que la programación también incluye comentarios que escriben y que los comentarios son una parte integral de la programación. Es cierto que los comentarios no son utilizados por el equipo y, desde luego, no constituyen las últimas instrucciones para el ordenador, pero mejoran la legibilidad de los programas, explicando el significado y la lógica de los estados o secciones de código. Debe recordarse que los programas no sólo son para los ordenadores, sino que también se leen, escriben, y modificados por los seres humanos. Los tipos de comentarios incluyen la repetición del código, explicación del código, marcador del código, resumen del código, descripción de la intención del código, y la información que no pueda ser posi- blemente expresada por el propio código. Algunos comentarios son buenos, algunos no lo son. Los buenos son los que explican la intención del código y justificar por qué este código es la forma en que lo hace. Los malos son repetición del código y la información que indica Evant irrel-. Los mejores comentarios son de código auto-documentación. Si el código está escrito de manera clara y precisa que su significado es proclamado uno mismo, entonces no se necesita ningún comentario. Pero esto es más fácil decirlo que hacerlo. La mayoría de los programas no son fáciles de entender y son a menudo difíciles de leer y entender si no se dan los comentarios. Aquí hay algunas pautas generales para la escritura de comentarios:

• Los comentarios deben ser coherentes en todo el programa. • Cada función debe estar asociado con los comentarios que explican el propósito de la función y su papel en el programa general.

13-38 Guía SWEBOK® V3.0

• Dentro de una función, los comentarios se deben dar por cada sección lógica de codificación para explicar el significado y propósito (intención) de la sección. • Los comentarios deben estipular lo que hace la libertad (o no) los programadores de mantenimiento tienen con respecto a realizar cambios en el código. • Los comentarios son rara vez necesarios para las declaraciones indi- viduales. Si necesita una declaración comen- tarios, se debe reconsiderar el comunicado.

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

política y objetivos de seguridad en los requisitos de software, los cuales

Fundamentos de computación 13-39

sienta las bases para consideraciones de seguridad en el desarrollo de software. Los factores a considerar en esta fase incluyen los requisitos de software y amenazas / riesgos. El primero se refiere a las funciones específicas que se requieren para el bien de seguri- dad; Este último se refiere a las posibles formas en que se ve amenazada la seguridad del software. 17.2. Diseño de Software de Seguridad Ofertas de software de seguridad de diseño con el diseño de módulos de software que encajan entre sí para cumplir con los objetivos de seguridad especificadas en los requisitos de seguridad. Este paso aclara los detalles de las consideraciones de seguridad y desarrolla los pasos específicos para su implementación. Los factores considerados pueden incluir marcos y modos de acceso que se instalan las estrategias de seguridad de supervisión / aplicación general, así como los mecanismos de aplicación de políticas individuales. 17.3. El software de seguridad de construcción Software la seguridad de la construcción se refiere a la cues- ción de cómo escribir código de programación real para situaciones específicas tales que las consideraciones de seguridad son atendidos. El término “Construcción de Software de Seguridad” puede significar cosas diferentes para diferentes personas. Puede significar la forma en que una función específica está codificada, de manera que la codificación en sí es seguro, o puede significar la codificación de seguridad en el software. La mayoría de las personas se enredan los dos juntos sin distinción. Una de las razones para tal enredo es que no está claro cómo se puede garantizar que una codificación específica es seguro. Por ejemplo, en lenguaje C programación, la expresión de i << 1 (cambio de la representación binaria del valor i de a la izquierda de un bit) y 2 * i (multiplicar el valor de la variable i por la constante 2) significa la misma lo semánticamente, pero no tienen la misma ramificación de seguridad? La respuesta podría ser diferente para diferentes combinaciones de las NIA y compiladores. Debido a esta falta de entendimiento, la

construcción de software de seguridad en su estado actual de refiere existencia-principalmente con el segundo aspecto mencionado anteriormente: la codificación de seguridad en el software. La codificación de la seguridad en el software se puede lograr siguiendo las normas recomendadas. Unos dichas reglas a continuación:

13-40 Guía SWEBOK® V3.0

• Estructurar el proceso para que todas las secciones que requieren privilegios adicionales son módulos. Los módulos deben ser lo más pequeña posible y se deben realizar sólo aquellas tareas que requieren esos privilegios. • Asegúrese de que los supuestos en el programa son validados. Si esto no es posible, docu- mento ellos para los instaladores y mantenedores para que sepan que los supuestos atacantes tratarán de invalidar. • Asegúrese de que el programa no comparte objetos en la memoria con cualquier otro programa. • El estado de error de cada función debe ser comprobado. No trate de recuperar a menos que ni la causa del error ni sus efectos afectan a las consideraciones de seguridad. El programa debe restaurar el estado del software al estado que tenía antes de que comenzara el proceso, y luego terminar.

17.4. El software de seguridad de Pruebas Las pruebas de software de seguridad determina que soft- ware protege los datos y mantiene la seguridad ficación speci- como algo dado. Para obtener más información, consulte la Prueba de Software KA. 17.5. Construir Seguridad en Ingeniería de Procesos de Software El software es tan segura como su proceso de desarrollo va. Para garantizar la seguridad del software, la seguridad debe ser incorporado en el software Engineer- proceso ing. Una tendencia que surge en este sentido es la CEPT asegurar el desarrollo del ciclo de vida (SDL) con-, que es un modelo en espiral clásica que tiene una visión integral de la seguridad desde la perspectiva del ciclo de vida del software y asegura que la seguridad es inherente en el diseño y desarrollo de software, no es una idea de último momento después de la producción. El pro- ceso SDL se demanda para reducir los costes de mantenimiento de software y aumentar la fiabilidad del software de concerning fallos relacionados con la seguridad de software. 17.6. Guía de seguridad de software Aunque no hay maneras a prueba de balas para

el desarrollo de software seguro, existen algunas pautas generales que se pueden utilizar para ayudar a tales esfuerzos. Estas

Fundamentos de computación 13-41

directrices abarcan todas las fases del ciclo de vida de desarrollo de software. Algunas líneas directrices de buena reputación son publicados por el Equipo de Respuesta a Emergencias Informáticas (CERT) y por debajo son las 10 mejores prácticas de seguridad de software (los detalles se pueden encontrar en [12]:

1. Validar entrada. 2. Cuidado con las advertencias del compilador. 3. El arquitecto y el diseño de las políticas de seguridad. 4. Mantenlo simple. 5. Por defecto negar. 6. Observar el principio de privilegios mínimos. 7. Desinfectar los datos enviados a otro software. 8. la práctica de defensa en profundidad. 9. Utilizar técnicas eficaces de aseguramiento de la calidad. 10. Adoptar un estándar de seguridad de construcción de software.

13-42 Guía SWEBOK® V3.0

1. Técnicas de Resolución de Problemas 1.1. Definicion de La resolución de 1.2. Formular el problemas problema real 1.3. Analizar el problema 1.4. Diseñar una estrategia de búsqueda de soluciones 1.5. La resolución de problemas Utilización de 2. programas Abstracción 2.1. Niveles de Abstracción 2.2. La encapsulación 2.3. Jerarquía 3. Fundamentos de programación 3.1. El proceso de programación 3.2. Los paradigmas de programación 3.3. La programación 4. defensiva Principios básicos del lenguaje de 4.1. Programación programación idioma general 4.2. Sintaxis y semántica del lenguaje de programación

S3.2 , S4.2 S3.2 S3.2 S3.2 S4.2 c5 5.4 s5.2 5.3 s5.2 S5.3 S5.2 C6-19 C6-C19 C6-C19 c8 c6 S6.1

S6.2

nortea Nielsen 1993 [9 *] 2002 Bishop [11 *]

nully Lobur 2006 [8 *]

SommervilLe 2011 [6 *]

HoRowitz et al. 2007 [5 *]

Brookshear 2008 [4 *]

McConnell 2004 [3 *]

Voland 2003 [2 *]

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

4.3. Bajo nivel de lenguaje de programación

depuración y Técnicas 5.1. Tipos de error 5.2. depuración técnicas: 5.3. Herramientas depuración 6. de Estructura de datos y representación 6.1. Estructura de datos Visión de de 6.2. Tipos conjunto Estructuras de Datos 6.3. Las operaciones en Estructuras de datos

7. Algoritmos y Complejidad

s6.56,7 s6.56,7 c23 s23.1 s23.2 s23.5 2.6 s2.12.6 s2.12.6 s2.12.6 s2.1s1.11.3, s3.33.6, s4.14,8, s5.15,7, s6.16.3, s7.17,6, s11.1, S12.1

nortea Nielsen 1993 [9 *] 2002 Bishop [11 *]

nully Lobur 2006 [8 *]

SommervilLe 2011 [6 *]

HoRowitz et al. 2007 [5 *]

s6.56,7

4.4. Alto Nivel de Programación Lenguaje 4.5. frente a declarativa lenguaje de programación 5. imperativo Herramientas de

Brookshear 2008 [4 *]

McConnell 2004 [3 *]

Voland 2003 [2 *]

Fundamentos de computación 13-43

7.1. Visión general de algoritmos 7.2. Atributos de Algoritmos 7.3. Análisis algorítmico

7.4. Estrategias de diseño algorítmico

7.5. Estrategias de análisis algorítmico

8. Concepto básico de un sistema de 8.1. Propiedades del sistema emergente 8.2. Ingeniería de sistemas 8.3. Descripción de una Sistema informático

s1.1-1.2 S1.3 S1.3 s3.33.6, s4.14,8, s5.15,7, s6.16.3, s7.17,6, s11.1, S12.1 s3.33.6, s4.14,8, s5.15,7, s6.16.3, s7.17,6, s11.1, S12.1 c10 s10.1 s10.2

nortea Nielsen 1993 [9 *] 2002 Bishop [11 *]

nully Lobur 2006 [8 *]

SommervilLe 2011 [6 *]

HoRowitz et al. 2007 [5 *]

Brookshear 2008 [4 *]

McConnell 2004 [3 *]

Voland 2003 [2 *]

13-44 Guía SWEBOK® V3.0

9. Organización del ordenador 9.1. Organización general del ordenador 9.2. Sistemas digitales 9.3. lógica digital

c3 c3 c2 4.2 s4.1S4.6

del Sistema de memoria 9.7. Entraday salida (I

S4.5

/ O)

11. Fundamentos de Sistemas Operativos 11.1. Operativo general Sistemas 11.2. tareas de Sistema operativo 11.3. Operando sistema Abstracciones 11.4. Sistemas para realizar la clasificación

s6.4

S8.4 S8.4 S8.4

s6.4 c3 S3.2 S3.3 S3.2 S3.1

S8.4

nortea Nielsen 1993 [9 *] 2002 Bishop [11 *]

nully Lobur 2006 [8 *] s1.1-1.2

Central de Procesamiento (CPU) 9.6. Organización

y compilación 10.3. El proceso de compilación

SommervilLe 2011 [6 *]

C1-4

9.4. Expresión de datos del ordenador 9.5. La Unidad

10. Fundamentos del compilador 10.1. Compilador Visión de conjunto 10.2. Interpretación

HoRowitz et al. 2007 [5 *]

Brookshear 2008 [4 *]

McConnell 2004 [3 *]

Voland 2003 [2 *]

Fundamentos de computación 13-45

12. Conceptos básicos de bases de datos y gestión de datosy 12.1. Entidad de esquema 12.2. Sistemas de Gestión de Bases de Datos (DBMS) 12.3. Base de datos Lenguaje dede 12.4. tareas consulta Los paquetes de DBMS 12.5. Datos administración 12.6. La minería de 13.datos Conexión de

C9 S9.1 S9.1 S9.2 S9.2 s9.5 s9.6

red básica de comunicación 13.1. Tipos de Red 13.2. Componentes de la Red Básica

c12 12.3 s12.2-

13.3. Protocolos de red y Estándares

s12.412.5

13.4. La Internet 13.5. Internet de las Cosas 13.6. Red Privada

s12.8

S12.6

Virtual 14. Computación Paralela y Distribuida 14.1. Computación paralela y distribuida general

C9

9.4.3 s9.4.1-

nortea Nielsen 1993 [9 *] 2002 Bishop [11 *]

nully Lobur 2006 [8 *]

SommervilLe 2011 [6 *]

HoRowitz et al. 2007 [5 *]

Brookshear 2008 [4 *]

McConnell 2004 [3 *]

Voland 2003 [2 *]

13-46 Guía SWEBOK® V3.0

14.2. Las diferencias entre Computación Paralela y Distribuida 14.3. Paralela y

humanos básicos de los y 15.1. Entrada usuarios salida 15.2. Error de mensajes 15.3. La robustez del 16.software Developer básico Factores Humanos 16.1. Estructura 16.2. comentarios 17. asegurar el desarrollo y mantenimiento de software 17.1. DosAspectos de codificación segura 17.2. Codificació n de Seguridad 17.3. en Software RequisitoSegurida d17.4. Seguridad diseño 17.5. Implementación Seguridad

nortea Nielsen 1993 [9 *] 2002 Bishop [11 *]

nully Lobur 2006 [8 *]

SommervilLe 2011 [6 *]

HoRowitz et al. 2007 [5 *]

9.4.5 s9.4.49.4.5 s9.4.4-

Distribuida Los modelos informáticos 14.4. Problemas principales en Distributed 15.Computing Los factores

Brookshear 2008 [4 *]

McConnell 2004 [3 *]

Voland 2003 [2 *]

Fundamentos de computación 13-47

c8

c5 S5.1, S5.3 S5.2 , s5.8 5.6 s5.5 -

c31-32 c31 c32 c29 s29.1 s29.4 s29.2 s29.3 s29.5

13-48 Guía SWEBOK® V3.0

Referencias [1] Grupo de Trabajo Conjunto sobre Computación planes de estudio, IEEE Computer Society y la Association for Computing Machinery, Ingeniería de Software 2004: Directrices Curriculares para Pregrado Programas de Grado en Ingeniería de Software, 2004; http: // sites. computer.org/ccse/SE2004Volume.pdf.

[7] ISO / IEC / IEEE 24765: 2010 Sistemas y de Ingeniería de Software-Vocabulario, ISO / IEC / IEEE 2010.

[2 *] G. Voland, Ingeniería de Diseño, 2ª ed., Prentice Hall, 2003.

[9 *] J. Nielsen, Ingeniería de usabilidad, Morgan Kaufmann, 1993.

[3 *] S. McConnell, código completo, 2ª ed., Microsoft Press, 2004.

[10] ISO 9241 a 420: 2011 ergonomía de la interacción del sistema Human-, ISO, 2011.

[4 *] JG Brookshear, Ciencias de la Computación:. Una visión general, 10ª ed, Addison-Wesley, 2008.

[11 *] M. Bishop, Computer Security: Arte y Ciencia, Addison-Wesley, 2002.

[5 *] E. Horowitz et al., Algoritmos de ordenador, 2ª ed., Silicon Press, 2007. [6 *] I. Sommerville, Ingeniería de Software, 9ª ed., Addison-Wesley, 2011.

[8 *] L. y J. nulo Lobur, Lo Esencial de la Organización de Computadores y Arquitectura, 2ª ed., Jones and Bartlett Publishers, 2006.

[12] RC Seacord, el CERT c Fije codificación estándar, Addison-Wesley Professional, 2008.

Capítulo 14 fundamentos matemáticos INTRODUCCIÓN profesionales de software en vivo con los programas. En un lenguaje muy simple, se puede programar sólo para algo que sigue una lógica ambigua no bien entendida. El área de Fundamentos del conocimiento matemático (KA) ayuda a los ingenieros de software comprender esta lógica, que a su vez se traduce en código de lenguaje de programación. El ICS mathemat- que es el objetivo principal en este KA es muy diferente de la aritmética típica, donde los números son tratados y discutidos. La lógica y razonable ING son la esencia de las matemáticas que un ingeniero de software debe abordar. Matemáticas, en cierto sentido, es el estudio de los sistemas formales. La palabra “formal” se asocia con precisión, por lo que no puede ser cualquier interpretación ambigua o errónea de la realidad. Por lo tanto, ics Mathemat- es el estudio de todos y cada uno ciertas verdades sobre cualquier concepto. Este concepto puede ser acerca de los números, así como sobre los símbolos, imágenes, sonidos, vídeo-casi cualquier cosa. En resumen, no sólo números y ecuaciones numéricas están sujetas a posibles precisión. Por el contrario, un ingeniero de software debe tener una abstracción precisa en un dominio de aplicación diversa. Guía del SWEBOK Matemática Foundation ciones KA abarca las técnicas básicas para identificar un conjunto de reglas para el razonamiento en el contexto del sistema en estudio. Cualquier cosa que se puede deducir siguien- tes estas reglas es una certeza absoluta en el contexto de dicho sistema. En este KA, técnicas que se pueden representar y llevar adelante el razonamiento y el juicio de un ingeniero de software de una manera precisa (y por lo tanto matemática) se definen y discutidos. El lenguaje y los métodos de la lógica que se discute aquí nos permiten describir pruebas

ematical Matemáticas- para deducir de forma concluyente la verdad absoluta de ciertos conceptos más allá de los números. En

13-50 Guía SWEBOK® V3.0

palabras, es una miembro del conjunto. Su negación está representado por ∉, por ejemplo, 1 ∈ S, pero 4 ∉ S. En una representación más compacta del conjunto usando la notación establecer constructor, {x | P (x)} es el conjunto de todos los x tales que P (x) para cualquier proposición P (x) sobre cualquier universo de discurso. Ejemplos de algunos conjuntos impor- tantes incluyen los siguientes:

resumen, se puede escribir un programa para un problema sólo si se sigue una cierta lógica. El objetivo de este KA es ayudar a desarrollar la habilidad de identificar y describir tal lógica. El énfasis está en ayudar a entender los conceptos básicos más que en desafiar sus habilidades aritméticas. DISTRIBUCIÓN DE TEMAS PARA fundamentos matemáticos El desglose de temas para los fundamentos matemáticos KA se muestra en la figura 14.1.

N = {0, 1, 2, 3, ...} = el conjunto de no negativo enteros. Z = {..., -3, -2, -1, 0, 1, 2, 3, ...} = el conjunto de enteros.

1. Set, relaciones, funciones [1 *, c2] Conjunto. Un conjunto es una colección de objetos, llamado elementos del conjunto. Un conjunto puede ser representado por listar sus elementos entre aparatos ortopédicos, por ejemplo, S = {1, 2, 3}. El símbolo ∈ se usa para expresar que un eleción pertenece a un conjunto, o, en otras

Conjunto finito e infinito. Un conjunto con un nú- mero finito de elementos se denomina un conjunto finito. Por el contrario, cualquier conjunto que no tiene un número finito de elementos en que es un conjunto infinito. El conjunto de los números naturales, por ejemplo, es un conjunto infinito.

14-1

14-2

Guía SWEBOK® V3.0

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

Cardinalidad. La cardinalidad de un conjunto finito S es el número de elementos en S. Esto se representa | S |, por ejemplo, si S = {1, 2, 3}, entonces | S | = 3. Conjunto universal. En general S = {x ∈ U | p (x)}, donde T es el universo de discurso en el que debe interpretarse el predicado P (x). El “verso uniforme del discurso” de un predicado dado se refiere a menudo como el conjunto universal. Alternativamente, uno puede definir conjunto universal como el conjunto de todos los elementos. Establecer la igualdad. Dos conjuntos son iguales si y sólo si tienen los mismos elementos, es decir: X = Y ≡ ∀ p (p ∈ X ↔ p ∈ Y). Subconjunto. X es un subconjunto del conjunto Y, o X está contenido en Y, si todos los elementos de X se incluyen en Y. Esto se denota por X ⊆ Y. En otras palabras, X ⊆ Y si y sólo si ∀ p (p ∈ X → p ∈ Y). Por ejemplo, si X = {1, 2, 3} y Y = {1, 2, 3, 4, 5}, entonces X ⊆ Y. Si X no es un subconjunto de Y, que se denota como X Y. Apropiado Subconjunto. X es un subconjunto propio de Y (denotado por X ⊂ Y) si X es un subconjunto de Y, pero no es igual a Y, es decir, hay algún elemento en Y que no está en X. En otras palabras, X ⊂ Y si (X ⊆ Y) ∧ (X ≠ Y). Por ejemplo, si X = {1, 2, 3}, Y = {1, 2, 3, 4}, y Z = {1, 2, 3}, entonces X ⊂ Y, pero X no es un adecuada subconjunto de Z. Establece X y Z son conjuntos iguales. Si X no es un subconjunto propio de Y, se

denota como X ⊄ Y. Superconjunto. Si X es un subconjunto de Y, entonces Y se llama un superconjunto de X. Esto se denota por Y ⊇ X, es decir, Y ⊇ X si y sólo si X ⊆ Y. Por ejemplo, si X = {1, 2, 3} y Y = {1, 2, 3, 4, 5}, entonces Y ⊇ X.

Conjunto vacio. Un conjunto sin elementos se llama un conjunto vacío. Un conjunto vacío, denotado por ∅ , también se conoce como un conjunto nula o ineficaz. Set de poder. El conjunto de todos los subconjuntos de un conjunto X se llama el conjunto potencia de X. Se representa como ℘ (X). Por ejemplo, si X = {a, b, c}, entonces ℘ (X) = {∅ , {A}, {b}, {c}, {a, b}, {a, c}, {b, c}, {a, b, c}}. Si | X | = N, entonces | ℘ (X) | = 2n. Venn Diagramas. Venn diagramas son resentations tantes gráficas de conjuntos como áreas cerradas en el plano. Por ejemplo, en la figura 14.2, el repre- rectángulo resiente el conjunto universal y la región sombreada representa un conjunto X. Figura 14.2. Diagrama de Venn para el conjunto X

1.1. las operaciones Set Intersección. La intersección de dos conjuntos X e Y, denotado por X ∩ Y, es el conjunto de ele- mentos comunes tanto en X como Y. En otras palabras, X ∩ Y = {p | (P ∈ X) ∧ (p ∈ Y)}. Como, por ejemplo, {1, 2, 3} ∩ {3, 4, 6} = {3} Si X ∩ Y = f, entonces los dos conjuntos X e Y se dijo ser un par disjunta de conjuntos.

Fundamentos matemáticos 14-3

14-4

Guía SWEBOK® V3.0

Un diagrama de Venn para intersección de conjuntos se muestra en la figura 14.3. La parte común de los dos conjuntos representa la intersección de conjuntos.

Figura 14.3. Intersección de conjuntos X e Y

Unión. La unión de dos conjuntos X e Y, denotado por X ∪ Y, es el conjunto de todos los elementos, ya sea en X, o en Y, o en ambos. En otras palabras, X ∪ Y = {p | (P ∈ X) ∨ (p ∈ Y)}. Como, por ejemplo, {1, 2, 3} ∪ {3, 4, 6} = {1, 2, 3, 4, 6}.

La parte sombreada del diagrama de Venn en Fig- ure 14.5 representa el complemento conjunto de X. Establecer diferencia o complemento relativa. El conjunto de elementos que pertenecen a X del sistema, pero no para establecer Y construye la diferencia conjunto de Y de X. Esto se repreresentido por X - Y. En otras palabras, X - Y = {p | (P ∈ X) ∧ (p ∉ Y)}. Como, por ejemplo, {1, 2, 3} - {3, 4, 6} = {1, 2}. Puede probarse que X - Y = X ∩ Y'. Conjunto diferencia X - Y se ilustra por la región sombreada en la figura 14.6 el uso de un diagrama de Venn.

Figura 14.6. Diagrama de Venn para X - Y Figura 14.4. Unión de conjuntos X e Y

Cabe señalar que | X ∪ Y | = | X | + | Y | - | X ∩ Y |. Un diagrama de Venn que ilustra la unión de dos conjuntos se representa por la región sombreada en la figura 14.4. Complemento. El conjunto de elementos en el conjunto uni- versal que no pertenecen a un conjunto dado X se llama su conjunto complemento X'. En otras palabras, X'= {p | (P ∈ U) ∧ (p ∉ X)}.

Producto cartesiano. Un par ordinario {p, q} es un conjunto con dos elementos. En un conjunto, el orden de los elementos es irrelevante, por lo que {p, q} = {q, p}. En un par ordenado (p, q), el orden de ocurrencias de los elementos es relevante. Por lo tanto, (p, q) ≠ (q, p) a menos que p = q. En general (p, q) = (s, t) si y sólo si p = s y q = t. Dados dos conjuntos X e Y, su producto cartesiano X × Y es el conjunto de todos los pares ordenados (p, q) tal que p ∈ X y q ∈ Y. En otras palabras, X × Y = {(p, q) | (P ∈ X) ∧ (q ∈ Y)}. Como por ejemplo, {a, b} x {1, 2} = {(a, 1), (a, 2), (B, 1), (b, 2)} 1.2. Propiedades del Conjunto

Figura 14.5. Diagrama de Venn para el complemento Conjunto de X

Algunas de las propiedades y leyes de conjuntos importantes se mencionan a continuación.

1. Leyes asociativas: X ∪ (Y ∪ Z) = (X ∪ Y) ∪ Z X ∩ (Y ∩ Z) = (X ∩ Y) Z ∩

Fundamentos matemáticos 14-5

14-6

Guía SWEBOK® V3.0

2. La ley conmutativa: X ∪ Y = Y ∪ XX

∩Y=Y∩X

3. La ley distributiva: X ∪ (Y ∩ Z) = (X ∪ Y) ∩ (X ∪ Z) X ∩ (Y ∪ Z) = (X ∩ Y) ∪ (X ∩ Z) 4. La ley de identidad: X ∪ ∅ = XX ∩ U = X 5. Complementar Leyes: X ∪ X'= UX ∩ X'= ∅ 6. La ley Idempotent: X ∪ X = XX ∩ X = X 7. La ley Bound: X ∪ U = UX ∩ ∅ = ∅ 8. La ley de absorción: X ∪ (X ∩ Y) = XX

∩ (X ∪ Y) = X

9. La ley de De Morgan: (X ∪ Y) '= X' ∩ Y '(X ∩ Y) '= X' ∪ Y' 1.3. Relación y función Una relación es una asociación entre dos conjuntos de información. Por ejemplo, consideremos un conjunto de residentes de una ciudad y sus números de teléfono. El emparejamiento de los nombres con números de teléfono correspondientes es una relación. Este emparejamiento se ordena para toda la relación. En el ejemplo ser conveniente examinar para cada par, ya sea el nombre viene primero, seguido del número de teléfono o a la inversa. El conjunto de la que se extrae el primer elemento se denomina dominio conjunto y el otro conjunto se llama el conjunto rango. El dominio es lo que empezar y es el rango de lo que se termina con. Una función es una relación de buen comportamiento. Un R con relación (X, Y) se comporta bien si la función de los mapas de cada elemento del conjunto X de dominio a un solo elemento del conjunto rango Y. Consideremos conjunto de dominio X como un conjunto de personas y dejar un margen establecido Y almacenar sus números de teléfono. Suponiendo que una persona puede tener más de un número de teléfono, la relación que se considera que no

es una función. Sin embargo, si dibujamos una relación entre los nombres de los residentes y su fecha de nacimiento con el nombre establecido como dominio,

esto se convierte en una relación de buen comportamiento y por lo tanto una función. Esto significa que, mientras que todas las funciones son las relaciones, no todas las relaciones son funciones. En caso de una función dada una x, se obtiene uno y exactamente uno y para cada par ordenado (x, y). Por ejemplo, consideremos las dos relaciones siguientes. A: {(3, -9), (5, 8), (7, -6), (3, 9), (6, 3)}. B: {(5, 8), (7, 8), (3, 8), (6, 8)}. Son estas funciones, así? En el caso de la relación A, el dominio es todos los valores de x, es decir, {3, 5, 6, 7}, y el rango es todo el y-valores, es decir, {-9, -6, 3, 8, 9}. Relación A no es una función, ya que hay dos valores de rango diferentes, -9 y 9, para el mismo valor de x de 3. En el caso de la relación B, el dominio es mismo que el de A, es decir, {3, 5, 6, 7}. Sin embargo, el intervalo es de un solo elemento {8}. Esto califica como un ejemplo de una función incluso si todos los valores de x se asignan a la misma-valor y. Aquí, cada valor de x es distinto y, por tanto, la función se comporta bien. Relación B puede ser representada por la ecuación y = 8. La característica de una función puede ser verificada utilizando una prueba de la línea vertical, que aparece a continuación: Dada la gráfica de una relación, si se puede dibujar una línea vertical que atraviesa el gráfico en más de un lugar, entonces la relación no es una función. Figura 14.7. Prueba de la recta vertical para la Función

En este ejemplo, las dos líneas L1 y L2 cortan el gráfico para la relación tres veces. Esto significa que para el mismo valor de x, hay tres valores de y diferentes para cada uno de caso. Por lo tanto, la relación no es una función.

Fundamentos matemáticos 14-7

14-8

Guía SWEBOK® V3.0

2. La lógica básica

[1 *, c1]

2.1. Lógica proposicional Una proposición es una afirmación que es verdadera o falsa, pero no ambas. Vamos a considerar frases declarativas de los que es significativa para asignar cualquiera de los dos valores de estado: verdadero o falso. Algunos ejemplos de proposiciones se dan a continuación. 1. El sol es una estrella 2. Los elefantes son mamíferos. 3. 2 + 3 = 5. Sin embargo, a + 3 = b no es una propuesta, ya que es ni verdadero ni falso. Depende de los valores de las variables a y b. La ley del medio excluido: Por cada sición propues- p, o bien p es verdadera o falsa p es. La ley de la contradicción: Por cada proposición p ción, no es el caso de que p es verdadera y falsa. La lógica proposicional es el área de la lógica que se ocupa de proposiciones. Una tabla de verdad muestra las relaciones entre los valores de verdad de proposiciones. Una variable booleana es uno cuyo valor es verdadero o falso. operaciones de bits equipo corresponden a operaciones lógicas de variables booleanas. Los operadores lógicos básicos, incluyendo la negación (¬ p), conjuntamente (p ∧ q), disyunción (p ∨ q), exclusiva o (p q ⊕), e implicación (p → q) son para ser estudiado. proposiciones compuestas se pueden formar usando diversos operadores lógicos. Una proposición compuesto que es siempre verdad es una tautología. Una proposición compuesta que siempre es falsa es una contradicción. Una proposición compuesta que no es ni una tautología ni una contradicción es una contingencia. proposiciones compuestas que siempre tienen el mismo valor de verdad se llaman lógicamente equivalente (denotado por ≡). Algunos de los Lences equivalencias comunes son: leyes de identidad: p ∧ t ≡ páginas ∨ F ≡ p

leyes Idempotent: p ∨ p ≡ páginas

∧p≡p

leyes de dominación: p ∨ T ≡ tp ∧F≡F

Fundamentos matemáticos 14-9

Ley doble negación: ¬ (¬ p) ≡ p conmutativa: p ∨ q ≡ q ∨ páginas

∧q≡q∧p

leyes asociativas: (P ∨ q) ∨ r ≡ p ∨ (q ∨ r) (p ∧ q) ∧ r ≡ p ∧ (q ∧ r) leyes distributivas: p ∨ (q ∧ r) ≡ (p ∨ q) ∧ (p ∨ r) p ∧ (q ∨ r) ≡ (p ∧ q) ∨ (p ∧ r) las leyes de De Morgan: ¬ (p ∧ q) ≡ ¬ p ∨ ¬ q¬ (P ∨ q) ≡ ¬ p ∧ ¬ q 2.2. La lógica de predicados Un predicado es una plantilla frase verbal que describe una propiedad de los objetos o una relación entre los objetos representados por las variables. Por ejemplo, en la oración, la flor es de color rojo, la plantilla es de color rojo es un predicado. En él se describe la propiedad de una flor. El mismo predicado puede ser utilizado en otras oraciones también. Los predicados se dan a menudo un nombre, por ejemplo, “Red” o simplemente “R” pueden ser usados para representar la cate predi- es de color rojo. Suponiendo R como el nombre para la cate predi- es rojo, frases que afirman un objeto es del color rojo se puede representar como R (x), donde x repre- senta un objeto arbitrario. R (x) es el x es de color rojo. Cuantificadores permiten afirmaciones sobre Lections COL- enteros de objetos en lugar de tener que enumercomió los objetos por su nombre. El cuantificador universal ∀ x afirma que una sen- tencia es cierto para todos los valores de la variable x. Por ejemplo, ∀ X Tiger (x) → Mamífero (x) significa todos los tigres son mamíferos. El cuantificador existencial ∃ x afirma que una tence sen- es cierto para al menos un valor de la variable x. Por ejemplo, ∃ x Tiger (x) → Man-Eater (x) significa que existe al menos un tigre que es un devorador de hombres. Por lo tanto, mientras que la cuantificación universal utiliza implicación, rally de la cuantificación existencial natuutiliza conjuntamente.

14-10 Guía SWEBOK® V3.0

Una variable x que se introduce en una expresión lógica por un cuantificador está unido al cuantificador de encerramiento más cercano. Una variable se dice que es una variable libre si no es unido a un cuantificador. Del mismo modo, en un lenguaje de programación de bloques estructurados, una variable en una expresión lógica se refiere al cuantificador más cercano dentro de cuyo ámbito aparece. Por ejemplo, en ∃ x (Cat (x) ∧ ∀ x (Negro (x))), x en Negro (x) es universalmente cuantificados. La expre- sión implica que existen gatos y todo es negro. La lógica proposicional se queda corto en la representación de muchas afirmaciones que se utilizan en ENCE y matemáticas equipo cien-. También falla para comparar la equivalencia y otros tipos de relación entre las proposiciones. Por ejemplo, la afirmación de a es mayor que 1 no es una proposición porque uno no puede deducir si es verdadero o falso sin conocer el valor de a. Por lo tanto, la lógica de proposiciones no puede hacer frente a este tipo de frases. Sin embargo, estas afirmaciones parecen bastante a menudo en las matemáticas y queremos inferir en esas afirmaciones. Además, el patrón involucrado en las siguientes dos Lences equivalencias lógicas no puede ser capturado por la lógica proposicional: “No todos los hombres son fumadores” y cada una de estas dos proposiciones se trata de forma independiente en la lógica proposicional “Algunos hombres no fuman.”. No hay ningún mecanismo en la lógica de proposiciones para averiguar si los dos son equivalentes entre sí. Por lo tanto, en la lógica de proposiciones, cada proposición equivalente es tratado individualmente en lugar de tratar con una fórmula general que cubre todas las equivalencias colectivamente. la lógica de predicados se supone que es una lógica roso más pow- que aborde estos temas. En un sentido, la lógica de predicados (también conocido como lógica de primer orden o cálculo de predicados) es una extensión de la lógica sitional propues- a las fórmulas que implican términos y predicados. 3. Técnicas de prueba

[1 *, c1] Una prueba de ello es un argumento que establece rigurosamente la verdad de un enunciado. Las pruebas pueden estar a su vez representadas formalmente como estructuras discretas.

Declaraciones utilizados en una prueba incluyen axiomas y postulados que son esencialmente los supuestos subyacentes sobre estructuras matemáticas, las hipótesis del teorema de ser probadas, y pre viamente teoremas probadas. Un teorema es una declaración que puede ser mostrado para ser verdad. Un lema es un teorema simple que se usa en la prueba de otros teoremas. Un corolario es una proposición que puede ser estable- cido directamente de un teorema que ha sido demostrado. Una conjetura es una declaración, cuyo valor de verdad es desconocida. Cuando se encuentra una prueba de una conjetura, la conjetura se convierte en un teorema. Muchas veces las conjeturas se muestran para ser falsa y, por lo tanto, no son teoremas. 3.1. Métodos de demostración de teoremas La prueba directa. prueba directa es una técnica para esta- blecer que la implicación p → q es cierto, mostrando que q debe ser verdadera cuando p es verdadera. Por ejemplo, para demostrar que si n es entonces extraño n2-1 es aún, supongamos que n es impar, es decir, n = 2k + 1 para algún entero k: ∴ n2 = (2k + 1) 2 = 4K2 + 4k + 1. A medida que los dos primeros términos de la mano del lado derecho (RHS) son números pares, independientemente del valor de k, de la mano del lado izquierdo (LHS) (es decir, n2) es un número impar. Por lo tanto, es aún N2-1. Prueba por la contradicción. Una proposición p es verdadera por la contradicción de ser probadas sobre la base de la verdad de la implicación ¬ p → q, donde q es una contradicción. Por ejemplo, para mostrar que la suma de 2x + 1 y 2y - 1 es par, considerar que la suma de 2x + 1 y 2y - 1 es impar. En otras palabras, 2 (x + y), que es un múltiplo de 2, es impar. Esta es una contradicción. Por lo tanto, la suma de 2x + 1 y 2y - 1 es par. Una regla de inferencia es un patrón que se establece que si un conjunto de premisas son ciertas, entonces se puede deducir que una determinada declaración conclusión es verdadera. Las normas de referencia de adición, la simplificación, y conjuntamente necesitan ser estudiadas.

Fundamentos matemáticos 14-11 Demostración por inducción. Demostración por inducción se realiza en dos fases. En primer lugar, la proposición se estable- cido para ser verdad para una base de caso-típicamente para la

14-12 Guía SWEBOK® V3.0

entero positivo 1. En la segunda fase, es estab-formas, n2 y cuando estas actividades no pueden realizarse o el en cado que si la proposición es válida para un r mismo tiempo, entonces hay n + n maneras de t hacerlo, ya12 sea arbitrario número entero positivo k, entonces e debe también mantener durante el próximo tarea. número entero mayor, k + 1. En otras palabras, • Si A y B son conjuntos disjuntos, entonces | demostración por inducción se basa en la regla A∪ B|=|A| de inferencia que nos dice que la verdad de una + | B |. secuencia infinita de proposiciones P (n), ∀ n ∈ • En general, si A1, A2, .... , An son disjuntos [1 ... ∞] se establece si P (1) es verdadero, y en conjuntos, entonces | A1 A2 ∪ ∪ ... ∪ An | = segundo lugar, ∀ k ∈ [2 ... n] si P (k) | A1 | + | A2 | → P (k + 1). + ... + | An |. Cabe señalar aquí que, para una demostración por inducción ematical Matemáticas-, no se Por ejemplo, si hay 200 atletas que realizan supone que P (k) es verdadera para todos los pruebas de velocidad y 30 atletas que participan números enteros positivos k. Probar una rem teo en el evento de salto de longitud, entonces o proposición sólo nos requiere para establecer cuántas formas hay que elegir un atleta que es o que si se supone P (k) es cierto para cualquier bien un velocista o un largo puente? arbitraria entero positivo k, entonces P (k + 1) Usando la regla de la suma, la respuesta sería también es cierto. La corrección de la inducción 200 matemática como una técnica de prueba válida + 30 = 230. está más allá de la discusión del texto CurLa regla del producto establece que si una tarea 1 alquiler. Probemos el siguiente proposición puede ser t 1 2 usando hecho en maneras y una segunda tarea t se puede inducción. n 2 hacer Proposición: La suma de los primeros n Pos maneras después de la primera tarea que se positivo impar ada ha hecho, a continuación, números enteros P (n) es n2. hay n * n maneras de hacer el procedimiento. Paso base: La proposición es verdadera para n 1 2 = 1 como P (1) = 12 = 1. La etapa de base es completa. • Si A y B son conjuntos disjuntos, entonces | A×B|= Paso inductivo: la hipótesis de inducción (IH) | A | * | B |. es que la proposición es verdadera para n = k, siendo k una • En general, si A1, A2, ..., An son conjuntos arbitraria entero positivo k. disjuntos, entonces | A1 A2 × × × ... Un | = | A1 | * | A2 | * .... * | An |. ∴ 1 + 3 + 5 + ... + (2k - 1) = k2 Ahora, es necesario demostrar que P (k) → P (k + 1). P (k + 1) = 1 + 3 + 5 + ... + (2k - 1) + (2k + 1) = P (k) + (2k + 1) = K2 + (2k + 1) [usando IH] = K2 + 2k + 1 = (K + 1) 2

Por lo tanto, se demuestra que si la proposición es verdadera

Por ejemplo, si hay 200 atletas que realizan pruebas de velocidad y 30 atletas que participan en el evento de salto de longitud, entonces ¿Cuántas maneras hay para recoger dos atletas por lo que uno es un velocista y el otro es un saltador de longitud? Usando la regla del producto, la respuesta sería de 200 x 30 = 6000. El principio de estados de inclusión-exclusión que si una tarea t puede hacerse de n maneras y una 1 1 segunda 2 2 T se puede hacer en maneras al mismo tarea n tiempo

para n = k, entonces también es cierto para n = k + 1. El paso de base junto con el paso inductivo la prueba de que P (1) es verdadera y el condicional declaración P (k) → P (k + 1) es verdadera para todos positivos K enteros. Por lo tanto, la proposición se prueba.

matemáticos 14-13 con t, a continuación,Fundamentos para encontrar el número total de maneras las 1 dos tareas se puede hacer, restar el número de maneras de hacer ambas + N.2 1 tareas de n

• Si A y B no son disjuntos, | A ∪ B | = | A | + | B | - | A ∩ B |.

4. Fundamentos de Conteo [1 * c6] La regla de la suma indica que si una tarea t se 1 puede hacer Posa1 maneras y una segunda 2 se puede hacer da tarea t de

En otras palabras, el principio de inclusiónexclusión tiene por objeto asegurar que los objetos en la intersección de dos conjuntos no se cuentan más de una vez.

14-14 Guía SWEBOK® V3.0

recursividad es el término general para la práctica de la definición de un objeto en términos de sí mismo. Hay algoritmos recursivos, fun- ciones definidas recursivamente, relaciones, juegos, etc. Una función recursiva es una función que llama sí mismo. Por ejemplo, definimos f (n) = 3 * f (n - 1) para todo n ∈ N y n ≠ 0 y f (0) = 5. Un algoritmo es recursivo si se soluciona un problema reduciéndolo a una instancia de la mismo problema con una entrada más pequeña. Un fenómeno se dice que es al azar, si los resultados individuales son inciertos, pero el largo plazo golondrina Pat- de los muchos resultados individuales es predecible. La probabilidad de cualquier resultado de un fenómeno dom ran- es la proporción de veces que el resultado sería posible en un tiempo muy larga serie de repeticiones. La probabilidad P (A) de cualquier evento a satisface 0 ≤ P (A) ≤ 1. Cualquier probabilidad es un número entre 0 y 1. Si S es el espacio de la muestra en un modelo de probabilidad, el P (S) = 1. Todos los posibles resultados conjuntamente, deben tienen probabilidad de 1. Dos sucesos A y B son disjuntos si no tienen resultados en común y por lo tanto nunca pueden ocurrir juntos. Si A y B son dos sucesos disjuntos, P (A o B) = P (A) + P (B). Esto se conoce como la regla ción adiciones para eventos disjuntos. Si dos eventos no tienen resultados en común, la probabilidad de que uno u otro se produce es la suma de sus probabilidades individuales. Permutación es un arreglo de objetos en los que el orden es importante, sin repetición. Uno puede elegir r elementos en un orden determinado a partir de una total de n objetos mediante el uso de formas NP, donde, np =

5. Los gráficos y los árboles

¡norte! / (N - r) !. Varios notaciones como NP y r P (n, r) se utilizan para representar el número de permutaciones de un conjunto de n objetos tomados r a la vez. La combinación es una selección de objetos en los que el orden no importa sin repetición. Esto es diferente de una permutación porque el orden no es importante. Si el pedido sólo se cambia (y no los miembros), entonces no se forma nueva

combinación. Uno puede elegir r objetos en cualquier orden de un total de n objetos mediante el uso de formas NC, donde, NC = n! / [R! * (N r)]!.

[1 *, c10, c11]

5.1. Los gráficos

Un gráfico G = (V, E) donde V es el conjunto de vértices (nodos) y E es el conjunto de bordes. Los bordes también se conocen como arcos o enlaces.

Figura 14.8. Ejemplo de un gráfico

F es una función que mapea el conjunto de aristas E a un conjunto de pares ordenados o no ordenados de elementos de V. Por ejemplo, en la figura 14.8, G = (V, E) donde V = {A, B, C}, E = {e1, e2, e3}, y F = {(e1, (A, C)), (e2, (C, B)), (e3, (B, A))}. El gráfico de la figura 14.8 es un gráfico simple que consiste en un conjunto de vértices o nodos y un conjunto de aristas que conectan pares no ordenadas. Los bordes en gráficos simples no son dirigidas. Tales gráficos también se conocen como no dirigida gráficos.

rr

Por ejemplo, en la figura 14.8, (e1, (A, C)) puede ser reemplazado por (e1, (C, A)) como el par entre los vértices A y C es desordenada. Esto vale para los otros dos bordes también. En una multigrafo, más de un borde puede con- Nect los mismos dos vértices. Dos o más Connect- bordes ING entre el mismo par de vértices pueden reflejar múltiples asociaciones entre los mismos dos vértices. Tales bordes se llaman paralelo o múltiples bordes. Por ejemplo, en la figura 14.9, los bordes E3 y E4 son ambos entre A y B. La figura 14.9 es una multigrafo donde los bordes E3 y E4 son múltiples bordes.

Fundamentos matemáticos 14-15

14-16 Guía SWEBOK® V3.0

Un grafo dirigido G = (V, E) se compone de un conjunto de vértices V y un conjunto de bordes E que son pares ordenados de elementos de V. Un grafo dirigido puede con- bucles tain. Por ejemplo, en la figura 14.11, G = (V, E), donde V = {A, B, C}, E = {e1, e2, e3}, y F = {(e1, (A, C)), (e2, (B, C)), (e3, (B, A))}.

Figura 14.9. Ejemplo de un Multigraph

En una pseudógrafo, cantos conexión de un nodo a sí mismo están permitidos. Tales bordes son llamados bucles.

Figura 14.12. Ejemplo de un grafo ponderado

Figura 14.10. Ejemplo de un pseudógrafo

Por ejemplo, en la figura 14.10, el borde E4 ambos comienza y termina en B. Figura 14.10 es un gráfico en el que pseudo- e4 es un bucle.

En un gráfico ponderado G = (V, E), cada borde tiene un peso asociado a él. El peso de un borde típicamente representa el valor numérico asociado a la relación entre los correspondientes dos vértices. Por ejemplo, en la figura 14.12, se toman los pesos para los bordes E1, E2, y E3 a ser 76, 93, y 15 respectivamente. Si los vértices A, B y C representan tres ciudades en un estado, los pesos, por ejemplo, podrían ser las distancias en millas entre estas ciudades. Sea G = (V, E) sea un grafo no dirigido con borde conjunto E. A continuación, para un borde ∈ e E donde = {u, v}, a menudo se utilizan e los siguientes terminologías: • u, v se dice que son adyacentes o vecinos o conectado. • arista e es incidente con vértices u y v. • arista e conecta uy v. • vértices u y v son los puntos finales de la arista e. Si vértice v ∈ V, el conjunto de vértices en el gráfico rected Gastos no dis-G (V, E), entonces:

Figura 14.11. Ejemplo de un grafo dirigido

• el grado de v, deg (v), es su número de bordes inci- dente, excepto que cualquier auto-bucles se cuentan dos veces.

Fundamentos matemáticos 14-17

• un vértice con grado 0 se denomina vértice aislado. • un vértice de grado 1 se llama un vértice colgante. Sea G (V, E) un grafo dirigido. Si e (u, v) es un borde de G, a continuación, a menudo se utilizan las siguientes terminologías: Figura 14.13. Ejemplo de ciclos C34 y C

• • • • •

u es adyacente a v, y v es adyacente de u. e trata de u y va a v. E U se conecta a V, o correo va de u a v. el vértice inicial de e es u. el vértice terminal de la e es v.

Si vértice v está en el conjunto de vértices para el grafo dirigido G (V, E), entonces • en grados de v, deg-(V), es el número de aristas que van a v, es decir, para el que v es el vértice borne. • grado de salida de v, deg+(V), es el número de aristas que vienen de v, es decir, para el que v es el vértice inicial. • la licenciatura de v, deg (v) = deg-(V) + deg+(V), es el vs suma de los grados de entrada y salida grados. • un bucle en un vértice contribuye 1 a tanto grado dentro y fuera de grado de este vértice. Se puede observar que, después de las definiciones anteriores, el grado de un nodo es sin cambios si tenemos en cuenta sus bordes para ser dirigidos o no dirigidos. En un grafo no dirigido, un camino de longitud n de u a v es una secuencia de n bordes adyacentes de vértice u al vértice v. • Un camino es un circuito si u = v. • Un camino atraviesa los vértices a lo largo de ella. • Un camino es simple si no contiene ningún borde más de una vez. Un ciclo en n vértices Cn para cualquier n ≥ 3 o donde V = {v, v, ..., es un gráfico que PLE simr t v} y E = {{v, 1 e2n1 v}, {v, v}, ..., {v, v}, {v, v}}. 22

3n-1

nn

1

Por ejemplo, la figura 14.13 ilustra dos ciclos de longitud 3 y 4.

Una lista de adyacencia es una tabla con una fila por cada vértice, enumerando sus vértices adyacentes. La adyacencia listado para un grafo dirigido mantiene una lista de los nodos terminales para cada uno de los vértices en el gráfico. Vértic e UN segundo do

Lista de adyacen cia ANTES DE ABC CRIST O A, B

Figura 14.14. Listas de adyacencia para los gráficos de las Figuras 14.10 y 14.11

Por ejemplo, la figura 14.14 ilustra las listas decencia adja- para la pseudógrafo en la figura 14.10 y el gráfico dirigido en la figura 14.11. A medida que el cabo-grado de vértice C en la figura 14.11 es cero, no hay ninguna entrada en contra de C en la lista de adyacencia. Diferentes representaciones para una matriz gráfica similar de adyacencia, matriz de incidencia, y adyacencia listas-necesidad de ser estudiados. 5.2. árboles Un árbol T (N, E) es una estructura de datos jerárquica de n = | N | nodos con un nodo raíz especialmente designado R mientras que los restantes n - 1 forman nodos subárboles en virtud de la R. nodo raíz el número de bordes | E | en un árbol siempre sería igual a | N | - 1. El subárbol en el nodo X es el subgrafo de la árbol que consiste en nodo X y sus descendientes y todos los bordes incidente a los descendientes. Como

14-18 Guía aSWEBOK® V3.0 alternativa esta definición

recursiva, un árbol se puede definir como un grafo no dirigido conectado sin circuitos simples.

Fundamentos matemáticos 14-11

términos de número de saltos que se llama su nivel. Los nodos en un árbol se encuentran en diferentes niveles. El nodo raíz es

Figura 14.15. Ejemplo de un árbol de

Sin embargo, hay que recordar que un árbol es estrictamente de naturaleza jerárquica, en comparación con un gráfico, que es plana. En caso de un árbol, un par ordenado se construye entre dos nodos como padre e hijo. Cada nodo hijo en un árbol está asociado con un único nodo padre, mientras que esta restric- ción deja de tener sentido para un gráfico donde no existe asociación entre padres e hijos. Un grafo no dirigido es un árbol si y sólo si existe una trayectoria simple única entre cualesquiera dos de sus vértices. La figura 14.15 presenta un árbol T (N, E), donde el conjunto de nodos N = {A, B, C, D, E, F, G, H, I, J, K}. El conjunto de aristas E es {(A, B), (A, C), (A, D), (B, E), (B, F), (B, G), (C, H), (C, I), (D, J), (D, K)}. El padre de un nodo no raíz v es el único nodo U con un borde dirigido de u a v. Cada nodo del árbol tiene un nodo padre única excepción de la raíz del árbol. Por ejemplo, en la figura 14.15, nodo raíz A es el nodo padre de los nodos B, C y D. De manera similar, B es la matriz de E, F, G, y así sucesivamente. El nodo raíz A no tiene ningún padre. Un nodo que tiene los niños se llama un nodo interno. Por ejemplo, en la figura 14.15, el nodo A o el nodo B son ejemplos de nodos internos. El grado de un nodo en un árbol es el mismo que el número de sus hijos. Por ejemplo, en la figura 14.15, nodo raíz A y su hijo B son ambos de grado 3. Los nodos C y D tienen grado 2. La distancia de un nodo desde el nodo raíz en

14-12 Guía SWEBOK® V3.0

en el nivel 0. Alternativamente, el nivel de un nodo X es la longitud de la trayectoria única de la raíz del árbol al nodo X. Por ejemplo, el nodo raíz A es en el nivel 0 en Fig- ure 14,15. Los nodos B, C, y D son en el nivel 1. Los nodos restantes en la figura 14.15 son todas en el nivel 2. La altura de un árbol es el máximo de la levels de nodos en el árbol. Por ejemplo, en la figura 14.15, la altura de la árbol es 2. Un nodo se llama una hoja si no tiene hijos. El grado de un nodo hoja es 0. Por ejemplo, en la figura 14.15, los nodos E a través K son todos nodos de hoja con grado 0. Los antepasados o predecesores de un nodo no raíz X son todos los nodos en el camino desde la raíz hasta el nodo X. Por ejemplo, en la figura 14.15, los nodos A y D formar el conjunto de ancestros por J. Los sucesores o descendientes de un nodo X son todos los nodos que tienen X como su antepasado. Para un árbol con n nodos, todos los restantes n - 1 nodos son sucesores del nodo raíz. Por ejemplo, en la figura 14.15, el nodo B tiene sucesores en E, F y G. Si el nodo X es un antepasado del nodo Y, a continuación, el nodo Y es un sucesor de X. Dos o más nodos que comparten el mismo nodo padre se llaman nodos hermanos. Por ejemplo, en la figura 14.15, los nodos E y G son hermanos. Sin embargo, los nodos E y J, aunque desde el mismo nivel, no son hermanos nodos. Dos nodos hermanos son del mismo nivel, pero dos nodos en el mismo nivel no son necesariamente hermanos. Un árbol se llama un árbol ordenado si la posición relativa de las ocurrencias de los nodos hijos es significativo. Por ejemplo, un árbol es un árbol ordenado si, por regla general, el nombre de un hermano mayor siempre aparece antes (es decir, a la izquierda de) el hermano más joven. En un árbol desordenada, la posición relativa de las ocurrencias entre los hermanos no guarda ninguna importancia y puede ser alterado de manera arbitraria. Un árbol binario está formado con cero o más nodos en los que hay una raíz nodo R y todos los nodos restantes forman un par de subárboles ordenados bajo el nodo raíz.

Fundamentos matemáticos 14-13

En un árbol binario, ningún nodo interno puede tener más de dos hijos. Sin embargo, hay que considerar que, además de este criterio en términos del grado de los nodos internos, un árbol binario es siempre ordenado. Si se intercambian las posiciones de los subárboles izquierdo y derecho para cualquier nodo en el árbol, a continuación, un nuevo árbol se deriva.

Figura 14.18. Ejemplo de árboles binarios completos

Figura 14.16. Ejemplos de árboles binarios

Por ejemplo, en la figura 14.16, los dos árboles binarios son diferentes como las posiciones de las apariciones de los niños de A son diferentes en los dos árboles.

Figura 14.17. Ejemplo de un árbol binario completo

De acuerdo con [1 *], un árbol binario se llama un árbol binario completo si cada nodo interno tiene exactamente dos hijos. Por ejemplo, el árbol binario en la figura 14.17 es un árbol binario completo, ya que ambos de los dos nodos internos A y B son de grado 2. Un árbol binario completo después de la definición anteriormente también se conoce como un árbol estrictamente binario. Por ejemplo, ambos árboles binarios en la figura 14.18 son árboles binarios completos. El árbol de la figura 14.18 (a) es un un binario completo completa, así como

árbol. Un árbol binario completo tiene todos sus

Curiosamente, a raíz de las definiciones anteriores, el árbol de la figura 14.18 (b) es un árbol binario completo, pero no completo como nodo B ha sólo un niño en D. Por el contrario, el árbol de la figura 14.17 es un completo -pero no completar binario árbol, como los hijos de B se producen en el árbol, mientras que los hijos de C no aparecen en el último nivel. Un árbol binario de la altura H está equilibrado si todos sus nodos hoja ocurrir a niveles H o H - 1. Por ejemplo, los tres árboles binarios de las Figuras 14,17 y 14,18 son árboles binarios equilibrados. Hay a lo sumo 2H hojas en un árbol binario de la altura H. En otras palabras, si un árbol binario con hojas L es completa y equilibrada, a continuación, su altura es H = ⎡log2L⎤. Por ejemplo, esta afirmación es cierta para el dos árboles en las figuras 14,17 y 14,18 (a) ya que ambos árboles son completa y equilibrada. Sin embargo, la expre- sión anterior no coincide con el árbol de la figura 14.18 (b) ya que no es un árbol binario completo. Un árbol de búsqueda binaria (BST) es un tipo especial de árbol binario en el que cada nodo contiene un valor de clave distinta, y el valor de la clave de cada nodo del árbol es menos de todos los valores clave en su subárbol derecho y mayor que todos los valores clave en su subárbol izquierdo. Un algoritmo de recorrido es un procedimiento para visitar de forma sistemática todos los nodos de un árbol binario. recorrido de árboles pueden definirse de forma recursiva. Si T es un árbol binario con raíz R y el restante nodos ing forman un par ordenado de izquierda no nulo L R niveles, subárbol T y no nulo

14-14 Guía SWEBOK® subárbol derecho de T V3.0

por debajo de R, con la posible excepción de la última, se llenó entonces el orden previo función preorder hasta los topes. En caso de que el último nivel de traversal (T) se define como: un árbol binario completo no está lleno, los PREORDER (t) = R, PREORDER (T), nodos se producen desde las posiciones más a la PREORDER (T) izquierda disponibles. L ... la ecuación. 1

R

Fundamentos matemáticos 14-15

El proceso recursivo de encontrar el recorrido en preorden de los subárboles continúa hasta que los subárboles se encuentran para ser nulo. Aquí, las comas se han utilizado como delimitadores en aras de mejorar la legibilidad. El orden posterior y en orden pueden ser definidos de forma similar usando la ecuación. 2 y la ecuación. 3 respectivamente. Postorden (T) = postorden (T), postorden (T), LR

R ... la ecuación 2 Finde (T) = finde (T), R, a finde (T ) …UN LR la ecuac ión 3

aleatoriedad se ha definido en la sección 4 de este KA. A continuación, vamos a empezar con los conceptos detrás de la distribución de probabilidad y la probabilidad discreta. Un modelo de probabilidad es una descripción matemática de un fenómeno aleatorio que consta de dos partes: un espacio de muestra S y una forma de asignar probabilidades a los eventos. El espacio de muestra define el conjunto de todos los posibles resultados, mientras que un evento es un subconjunto de un espacio muestral que representa una posiresultado ble o un conjunto de resultados. variable aleatoria es una función o regla que asigna un número a cada resultado. Básicamente, se es sólo un símbolo que representa el resultado de un experimento. Por ejemplo, sea X el número de cabezas cuando el experimento se lanzar una moneda n veces. Del mismo modo, sea S la velocidad de un coche, ya registrado en un detector de radar. Los valores para una variable aleatoria podrían ser Crete dis- o continua dependiendo del experimento. Una variable aleatoria discreta puede contener todos los resultados po- sible sin perder ninguna, aunque podría tener una cantidad infinita de tiempo. Una variable aleatoria continua se utiliza para asegurarse de medi- un incontable número de valores, incluso si se le da una cantidad infinita de tiempo.

Figura 14.19. Un árbol de búsqueda binaria

6. Probabilidad discreta Por ejemplo, el árbol de la figura 14.19 es un árbol binario de búsqueda (BST). Las salidas de recorrido preorden, postorden, y en orden para la BST se dan a continuación en su orden respectivo. PREORDER salida: 9, 5, 2, 1, 4, 7, 6, 8, 13, 11, 10, 15 Postorden de salida: 1, 4, 2, 6, 8, 7, 5, 10, 11, 15, 13, 9 Dentro de la orden de salida: 1, 2, 4, 5, 6, 7, 8, 9, 10, 11, 13, 15 Más discusión en los árboles y su uso se ha incluido en la sección 6, Estructura de Datos y de re- presentación, de los Fundamentos de Informática KA.

[1 *, c7] La probabilidad es la descripción matemática de aleatoriedad. definición básica de la probabilidad y

14-16 Guía PorSWEBOK® ejemplo,V3.0 si

una variable aleatoria X representa un resultado que es un número real entre 1 y 100, entonces X puede tener un número infinito de ues Val-. Uno nunca puede enumerar todos los posibles resultados para X incluso si se permite que una cantidad infinita de tiempo. Aquí, X es una variable aleatoria continua. Por el contrario, para el mismo intervalo de 1 a 100, otro Y variable aleatoria se puede utilizar para listar todos los valores de número entero de la gama. Aquí, Y es una variable aleatoria Creta dis-. Una letra mayúscula, digamos X, representará el nombre de la variable aleatoria. Su contraparte minúscula, x, representará el valor de la variable dom ran-. La probabilidad de que la variable aleatoria X se igual x es: P (X = x) o, más simplemente, P (x). Una función de distribución de probabilidad (densidad) es una tabla, fórmula, o un gráfico que describe los valores de una variable aleatoria y la probabilidad aso- ciados con estos valores.

Fundamentos matemáticos 14-17

Probabilidades asociadas con aleatoria discreta variables tienen las siguientes propiedades: i. 0 ≤ P (x) ≤ 1 para todo x ii. ΣP (x) = 1 Una distribución de probabilidad discreta puede repre- tantes como una variable aleatoria discreta.

x

1

2

3

4

5

6

P (x)

1/6

1/6

1/6

1/6

1/6

1/6

Estos números de hecho apuntan a derivar el valor de edad promedios a partir de experimentos repetidos. Esto se basa en el único fenómeno más importante de la probabilidad, es decir, el valor promedio de los experimentos repetidos es probable que sea próximo al valor esperado de un experimento. Por otra parte, el valor medio es más probable que sea más próximo al valor esperado de cualquier un experimento como el número de experimentos aumenta. 7. Máquinas de estados finitos [1 *, c13]

Un sistema informático puede ser abstraído como un mapeo de de estado a estado impulsado por insumos. En otras palabras, un sistema puede ser La media μ de un modelo de distribución de considerado como una función T transición: S × I probabilidad es la suma de los términos de → S × O, donde S es el conjunto de estados y I, O son las funciones de entrada y de salida. Si el productos para eventos individuales y su estado conjunto S es finito (no infinita), el sisprobabilidad de resultado. En otras palabras, por tem se denomina una máquina de estados finitos los posibles resultados x, x, ..., x (FSM). 12n en un espacio de es la probabilidad de Alternativamente, una máquina de estado finito k muestra S si p OUT(FSM) es una x llegado, la media de la probabilidad sería abstracción μmathematical compuesto por una k finito = XP + XP + ... + XP. número de estados y las transiciones entre las 11 22 nn Por ejemplo, la media de la densi- dad de estados. Si el dominio S × I es razonablemente probabilidad para la distribución en la figura pequeño, entonces se puede especificar T 14.20 sería explícitamente usando diagramas similares a un gráfico de flujo para ilustrar el 1 * (1/6) + 2 * (1/6) + 3 * (1/6) + 4 * (1/6) + 5 caminológicafluye para diferentes entradas. Sin embargo, esto es prác- tica sólo para máquinas * (1/6) + 6 * (1/6) que tienen una capacidad muy pequeña = 21 * (1/6) = 3,5 información. Un FSM tiene una memoria finita interna, una Aquí, el espacio de muestra se refiere al conjunto de todos característica de entrada que lee símbolos en una posibles resultados. secuencia y de una en una, y una entidad de El s2 varianza de un modelo de probabilidad salida. discreta El funcionamiento de una MEF inicia desde un comienzo es: s2 = 1 – μ)2p + (X – μ)2p + ... + (x estado, pasa a través de transiciones en función de (x ag ag μ)2pag entrada . 1 2 2 k k 2 * (1/6) + Las desviaciones estándar es la raíz cuadrada de (3 - 3.5) 2 * (1/6) + (4 - 3.5) 2 * (1/6) + (5 la varianza. 3.5) 2 * (1/6) + (6 - 3,5) 2 * (1/6)] Por ejemplo, para la distribución de probabilidad en = (6,25 + 2,25 + 0,25 + 0,5 + 2,25 + 6,25) * Figura 14.20, el σ2 variación sería (1/6) = 17,5 * (1/6) s2 = [Resultados (1 - 3.5) 2 * (1/6) + (2 - 3.5) = 2.90 Figura 14.20. Una función de probabilidad discreta para una herramienta de laminación

14-18 Guía SWEBOK® V3.0

∴ = desviación estándar s

a diferentes estados, y puede terminar en cualquier estado válido. Sin embargo, sólo unos pocos de todos los estados marcan un flujo exitoso de la operación. Estos se llaman aceptar estados. La capacidad de información de una MEF es C = log | P |. Por lo tanto, si representamos una máquina que tiene una capacidad de información de bits C como un FSM, entonces su gráfica de transición de estado tendrá | S | = Nodos 2C. Una máquina de estado finito se define formalmente como M = (S, I, O, f, g, s). 0 S es el conjunto de estado; yo es el conjunto de símbolos de entrada; O es el conjunto de símbolos de salida; F es la función de transición de estado;

Fundamentos matemáticos 14-19

gramo es la función de salida; La difereny s 0 es el estado inicial.

Dado un x de entrada ∈ I en estado Sk, la FSM hace una transición al después de tranm a Estado estado S r i función sición f y produce una salida y ∈ O d usando la función de salida og.

valores de transición y de salida de estado para entradas ent en diferentes estados pueden ser representados utilizando una tabla de estados. La tabla de estado para el FSM: Figura 14.21 se muestra en la figura 14.22. Cada pareja en contra de un símbolo de entrada representa el nuevo estado y el símbolo de salida. Por ejemplo, las Figuras 14.22 (a) y 14.22 (b) son dos representaciones alternativas de la FSM en Fig- ure 14,21. 8. gramáticas [1 *, c13]

La gramática de una lengua natural nos dice si una combinación de las palabras hace una sentencia válida. A diferencia de los lenguajes naturales, un len- guaje formal, se especifica mediante un conjunto bien definido de reglas de sintaxis. Las frases válidas de un lenguaje formal puede ser descrito por una gramática con la ayuda de estas reglas, conocidas como reglas Figura 14.21. Ejemplo de una FSM de producción. Un lenguaje formal es un conjunto de palabras Por ejemplo, la figura 14.21 ilustra una FSM de longitud finita o cuerdas sobre algún alfabeto finito, y una gramática especifica las reglas para la formación de con S 0 como el estado de como el estado estas palabras o cadenas. Todo el conjunto de inicio y S final. palabras 1 Aquí, S = {S, S, S}; I = {0, 1}; O = {2, 3}; f (S, Que son válidos para una gramática constituye el len0120 0) = S, f (S, 1) = S, f (S, 0) = S, f (S, 1) = S, f (S , Indicador de la gramática. Por lo tanto, la gramática G es 20112122 0) = S, f (S, 1) = S; g (S, 0) = 3, g (S, 1) = 2, G (S,alguna compacto, definición matemática precisa de una 220001 0) = 3, g (S, 1) = 2, G (S, 0) = 2, G (S, 1) = actual 0 1 0 1 3. 122 S S S 3 2 0

Estado actual S 0

Entrada 0 1 S S 2

1

S

S

S

S

S

S

1 2

2 2

Salida Entrada

1

3

2

S

S

S

2

3

S

S

1 2

2 2

2 0

(segundo)

2 0

(un)

Estado

2

S

Estado Entrada

Figura 14.22. Representación tabular de una MEF

14-20 Guía SWEBOK® V3.0 de lenguaje L en lugar

sólo una lista sin procesar de todos de frases o ejemplos de esas frases legales de la lengua. Una gramática implica un algoritmo que genere todas las sentencias legales de la lengua. Hay diferentes tipos de gramáticas. A-estructura de la frase o de tipo 0 gramática G = (V, T, S, P) es un 4-tupla en los que: • V es el vocabulario, es decir, conjunto de palabras. • T ⊆ V es un conjunto de palabras llamadas terminales. • S ∈ N es una palabra especial llamado el inicio símbolo. • P es el conjunto de reglas producciones para sustituyéndolo por un fragmento de frase para otra. Existe otro conjunto N = V - T de palabras llamado no terminales. Los no terminales representan conceptos como sustantivo. Las reglas de producción se aplican en las cadenas que contienen no terminales hasta que no haya más símbolos no terminales están presentes en la cadena. El símbolo inicial S es un no terminal.

Fundamentos matemáticos 14-21

El lenguaje generado por una gramática formal G, denotado por L (G), es el conjunto de todas las cadenas sobre el conjunto de alfabetos V que se puede generar, puesta en ing con el símbolo de inicio, mediante la aplicación de normas de pro- ducción hasta que todo el símbolos no terminales son sustituidos en la cadena. Por ejemplo, sea G = ({S, A, a, b}, {a, b}, S, S { → aA, S → b, A → aa}). En este caso, el conjunto de termina- nales son N = {S, A}, donde S es el símbolo inicial. Las tres reglas de producción de la gramática se dan como P1: S → aA; P2: S → b; P3: A → AA. La aplicación de las normas de producción en todas las formas posibles, las siguientes palabras pueden ser generados a partir del símbolo de inicio. S → aA (utilizando el símbolo de inicio P1) → aaa (usando P3) S → b (P2 utilizando el símbolo de inicio)

Nada más se puede derivar para G. Por lo tanto, el lenguaje de la gramática G consta de sólo dos palabras: L (g) = {aaa, b}. 8.1. Reconocimiento idioma gramáticas formales pueden ser clasificados de acuerdo a los tipos de producciones que se permiten. La jerarquía de Chomsky (introducido por Noam Chomsky en 1956) describe un esquema de dicha clasificación.

Figura 14.23. Jerarquía de Chomsky de gramáticas

Como se ilustra en la figura 14.23, inferimos la si-

3. Cada CSG es una gramática-estructura de la frase (PSG). Gramáticas sensibles al contexto: Todos los fragmentos en el RHS son o bien más largo que los fragmentos correspondientes en el LHS o vacío, es decir, si b → a, entonces | B | <| A | o a = ∅ . Un lenguaje formal es sensible al contexto, si una gramática sensible al contexto genera. Gramática de contextos libre: Todos los fragmentos en el LHS son de longitud 1, es decir, si A → a, entonces | A | = 1 para todos A ∈ N. El término deriva libres de contexto desde el hecho de que A siempre puede ser sustituido por una, independientemente del contexto en el que ocurre. Un lenguaje formal es independiente del contexto, si una gramática libre del contexto genera. lenguajes libres de contexto son la base teórica para la sintaxis de los lenguajes de programación. La gramática regular. Todos los fragmentos en el RHS son o bien terminales individuales o un par construido por un terminal y un no terminal; es decir, si A → a, entonces o bien a ∈ T, o a = CD, o a = Dc para c ∈ T, D ∈ N. Si a = cD, entonces la gramática se llama una gramática lineal derecha. Por otra parte, si a = Dc, a continuación, la gramática se llama una gramática lineal izquierda. Ambos la derecha y gramáticas lineales lineales izquierda son regu- lar la gramática o el Tipo-3. El lenguaje L (G) generado por una gramática regular G se denomina un lenguaje regular. Una expresión A regular es una cadena (o patrón) formado a partir de los siguientes seis piezas de informa- ción: a ∈ S, el conjunto de alfabetos, E, 0 y las operaciones, o (+), PRODUCTO, concatenación (.) NACIÓN (*). El lenguaje de G, L (G) es igual a todas aquellas cadenas que coinciden con G, L (G) = {x ∈ S * | x} G partidos. Para cualquier a ∈ S, L (A) = a; L (e) = {ε}; L (0) = 0. + funciona como un o, L (A + B) = L (A) ∪ L (B). . crea una estructura de producto, L (AB) = L (A). L (B). * Denota la concatenación, L (A *) = {x xx ... |

14-22 Guía SWEBOK® V3.0

lowing en diferentes tipos de gramáticas: 1. Cada gramática regular es una gramática libre de contexto (CFG). 2. Cada CFG es una gramática sensible al contexto (CSG).

xi L (A) ∈ y n ³ 0}

1 2n

Por ejemplo, la expresión regular (ab) * coincide con el conjunto de cadenas: {e, ab, ABAB, ababab, ABABABAB, ...}.

Fundamentos matemáticos 14-23

Por ejemplo, la expresión regular (aa) * coincide con el conjunto de cadenas en una carta que tienen una longitud uniforme. Por ejemplo, la expresión regular (aaa) * + (aaaaa) * coincide con el conjunto de cadenas de longitud igual a un múltiplo de 3 o 5. 9. Numéricos precisión, exactitud y errores [2 *, c2] El objetivo principal del análisis numérico es desarrollar algoritmos eficientes para calcular los valores numéricos de las funciones pre-Cise, soluciones de ecuaciones algebraicas y diferenciales, problemas de optimización, etc. Una cuestión de hecho es que todos los equipos digitales sólo pueden almacenar números finitos. En otras palabras, no hay manera de que una computadora puede representar un gran número infinitamente-ya sea un número entero, número racional, o cualquier real o todos los números complejos (véase la sección 10, Teoría de Números). Así las matemáticas de aproximación es muy crítica para manejar todos los números en el rango finito que un ordenador puede manejar. Cada número en un ordenador se le asigna un ción PAR- o palabra, que consta de un número especificado de dígitos binarios o bits. Una palabra k de bits puede almacenar un total de N = 2k números diferentes. Por ejemplo, un equipo que utiliza 32 bits aritmética puede almacenar un total de N = 232 ≈ 4,3 × 109 números diferentes, mientras que otro que utiliza 64 bits puede manejar N'= 264 ≈ 1,84 × 1019 números diferentes. La cuestión es cómo distribuir estas N números sobre la recta real para la eficiencia máxima efi- y precisión en los cálculos prácticos. Una opción evidente es la de distribuir de manera uniforme, dando lugar a aritmética de coma fija. En este sistema, el primer bit en una palabra se utiliza para representar un signo y los bits restantes son tratados para ues enteros Val-. Esto permite la representación de los números enteros de 1 - ½N, es decir, = 1 - 2k-1 a 1. Como un método de apareamiento aproximada, esto no es bueno para los números no enteros. Otra opción es el espacio de los números estrechamente-dicen con una separación uniforme de 2-n-y así distribuir el número total N de manera uniforme sobre el intervalo -2-n-

1N <x ≤ 2-n-1N. Los números reales que se encuentran entre los huecos están representados por cualquiera de ING redonda (es decir, el representante más cercano exacta)

14-24 Guía SWEBOK® V3.0

o cortar (es decir, el representante exacto inmediatamente debajo -OR anteriormente, si es negativo-el número). Los números que están más allá del rango deben estar representados por el mayor número (o más grande negativo) que puede ser representado. Esto se convierte en un símbolo de desbordamiento. Desbordamiento se produce cuando un ción computacional produce un valor mayor que el valor máximo de la gama. Cuando la velocidad de procesamiento es un cuello de botella importante, el uso de las representaciones de punto fijo es una alternativa atractiva y más rápido que el de punto flotante más engorroso aritmética más comúnmente utilizado en la práctica. Vamos definir un par de términos muy importantes: la exactitud y precisión como asociados con el análisis ical numer-. Exactitud es la cercanía con la que un valor calculado o Sured medi- está de acuerdo con el valor real. Precision, por otro lado, es la cercanía con la que dos o más medidos o calculados valores para la misma sustancia física de acuerdo entre sí. En otras palabras, la precisión es la Cerrar-dad con la que un número representa una exacta valor. Sea x un número real y sea x * sea una aproximación. El error absoluto en la aproximación x * x ≈ se define como | x * - x |. El error relativo se define como la relación entre el error absoluto con el tamaño de x, es decir, | x * - x | / | x |, que asume x ¹ 0; de lo contrario, no se define error relativo. Por ejemplo, 1000000 es una aproximación a 1.000.001 con un error absoluto de 1 y un error relativo de 10-6, mientras que 10 es una aproximación de 11 con un error absoluto de 1 y un error relativo de 0.1. Típicamente, error relativo es más intuitivo y el determinador preferida del tamaño del error. La presente Convención es que los errores son siempre Geq 0, y son = 0 si y sólo si la aproximación es exacta. Una aproximación x * tiene k dígitos significativos mal deci- si su error relativo es <5 × 10-k-1. Esto significa que los primeros k dígitos de x * siguientes su primer dígito distinto de cero son los mismos que los de x. dígitos significativos son los dígitos de un número que se sabe que ser correcta. En una medición, se incluye un dígito incierto. Por ejemplo, la medición de longitud con

una regla de 15,5 mm con ± 0,5 mm máximo

Fundamentos matemáticos 14-25

error permisible tiene 2 dígitos significativos, mientras que una medición de la misma longitud usando un calibrador y se registrará como 15,47 mm con ± 0,01 mm error permisible mamá maxi- tiene 3 dígitos significativos. 10. Teoría de los números [1 *, c4] la teoría de números es una de las ramas más antiguas de las matemáticas puras y uno de los más grandes. Por supuesto, se trata de preguntas acerca de los números, por lo general significa números enteros y números fraccionarios o racionales. Los diferentes tipos de números incluyen número entero, el número real, número natural, número complejo, número racional, etc. 10.1. Divisibilidad Vamos a empezar esta sección con una breve descripción de cada uno de los tipos anteriores de los números, empezando por los números naturales. Números naturales. Este grupo de números comienza en 1 y sigue: 1, 2, 3, 4, 5, y así sucesivamente. Cero no es en este grupo. No hay números negativos o fracciones cionales en el grupo de los números naturales. El símbolo matemático común para el conjunto de los números naturales es N. Números enteros. Este grupo tiene todos los números natu- ral en él más el número 0. Por desgracia, no todo el mundo acepta las definiciones anteriores de los números naturales y enteros. No parece haber un acuerdo general sobre si se debe incluir 0 en el conjunto de los números naturales. Muchos matemáticos consideran que, en Europa, la secuencia de números naturales que tradicionalmente se inició con 1 (0 ni siquiera fue considerado para ser un número por los griegos). En el siglo 19, situado teóricos y otros matemáticos comenzaron la convención de incluir a 0 en el conjunto de los números naturales. Enteros. Este grupo tiene todos los números enteros en ella y sus negativos. El símbolo cal matemáticamente común para el conjunto de todos los números enteros es Z, es decir, Z = {..., -3, -2, -1, 0, 1, 2, 3, ...}. Numeros racionales. Estos son los números

que se pueden expresar como un cociente de dos números enteros. El símbolo común para el conjunto de todas las fibras No. de orden racional es Q. Los números racionales pueden clasificarse en tres tipos, en función de cómo actúan los decimales. los

14-26 Guía SWEBOK® V3.0

decimales o no existen, por ejemplo, 15, o, cuando existen decimales, pueden terminar, como en 15.6, o pueden repetir con un patrón, como en 1,666 ..., (que es 5/3). Numeros irracionales. Estos son números que no se pueden expresar como un número entero dividido por un número entero. Estos números tienen decimales que nunca se terminan y nunca se repiten con un patrón, por ejemplo, PI o √2. Numeros reales. Este grupo está formado por todos los números racionales e irracionales. Los números que se encuentran en el estudio de álgebra son números reales. El símbolo matemático común para el conjunto de todos los números reales es R. Los números imaginarios. Estos se basan en el número imaginario i. Este número imaginario es igual a la raíz cuadrada de -1. Cualquier verdadero múltiple número de i es un número imaginario, por ejemplo, i, 5i, 3.2i, -2.6i, etc. Números complejos. Un número complejo es una combinación de un número real y un número imaginario en la forma a + bi. La parte real es una, y b se llama la parte imaginaria. El símbolo ematical Matemáticas- común para el conjunto de todas las fibras No. de orden complejos es C. Por ejemplo, 2 + 3i, 3-5i, 7,3 + 0i, y 0 + 5i. Tenga en cuenta los dos últimos ejemplos: 7.3 + 0i es el mismo que el número real 7.3. De este modo, todos los números reales son números complejos con cero para la parte imaginaria. Del mismo modo, 0 + 5i es sólo el 5i número imaginario. De este modo, todos los números imaginarios son números complejos con cero para la parte real. La teoría de números elemental implica la divisibilidad entre números enteros. Sean a, b ∈ Z con a ≠ 0. El expre- sión a | b, es decir, que se divide una b si ∃ c ∈ Z: b = ac, es decir, no es un número entero c tal que c veces a es igual a b. Por ejemplo, 3 | -12 es cierto, pero 3 | 7 es falsa. Si se divide una b, entonces se dice que a es un factor de segundo o a es un divisor de b, y b es un múltiplo de a. b es par si y sólo si 2 | b. Sean a, d ∈ Z con d> 1. A continuación, un mod d denota que el resto r desde el algoritmo de la división con dividendo a y divisor d, es decir, el resto cuando una se divide por d. Podemos calcular (un mod

d) por: a - d * ⎣ a / d⎦ , donde ⎣ a / d⎦ representa la piso del número real. Sea Z+ = {N ∈ Z | n> 0} y a, b ∈ Z, m ∈ Z+, Entonces a es congruente con b módulo m, escrito como a ≡ b (mod m), si y sólo si m | a-b.

Fundamentos matemáticos 14-27

Alternativamente, a es congruente con b módulo m si y sólo si (a-b) m mod = 0. 10.2. Número primo, GCD Un número entero p> 1 es primo si y sólo si no es el producto de dos números enteros mayores que 1, es decir, p es primo si p> 1 ∧ ∃ ¬ a, b ∈ N: a> 1, b> 1, a * b = p. Los únicos factores positivos de un primo p es 1 yp sí. Por ejemplo, los números 2, 13, 29, 61, etc., son números primos. nonprime números enteros mayores que 1 se llaman números compuestos. Un número compuesto puede estar compuesto por plying multi- dos números enteros mayores que 1. Hay muchas aplicaciones interesantes de números primos; entre ellos se encuentran el esquema de criptografía de clave pública, lo que implica el intercambio de claves públicas que contienen el producto p * q de dos números primos grandes aleatoria p y q (una clave privada) que debe mantenerse en secreto por un partido determinado. El gcd máximo común divisor (a, b) de Gers inte- a, b es el mayor número entero d que es un divisor tanto de A y de B, es decir,

11.1. Grupo Un conjunto S cerrado bajo una operación binaria • forma un grupo si la operación binaria satisface el seguimiento ing cuatro criterios: • Asociativa: ∀ a, b, c ∈ S, la ecuación (a • b) • c = a • (b • c) se mantiene. • Identidad: Existe un elemento de identidad I ∈ S tal que para todo a ∈ S, I • a = a • I = a. • Inverse: Cada elemento a ∈ S, tiene una inversa a '∈ S con respecto a la operación binaria, es decir, un • a' = I; Por ejemplo, el conjunto de los enteros Z con respecto a la operación de suma es un grupo. El elemento de identidad del conjunto es 0 para la operación de adición. ∀ x ∈ Z, la inversa de x sería -x, que también se incluye en Z. • propiedad Cierre: ∀ a, b ∈ S, el resultado de la • operación de un b ∈ S. • Un grupo que es conmutativa, es decir, un • b b = • a, que se conoce como una grupo conmutativo o abeliano.

El conjunto de números naturales N (con el funcionamiento de adición) no es un grupo, ya d = gcd (a, b) para max (d: d | a ∧ d | b) que no hay inversa para cualquier x> 0 en el conjunto de números naturales. Por lo tanto, se Por ejemplo, gcd (24, 36) = 12. viola la tercera regla (de inversa) para nuestra Números enteros a y b se llaman primos entre operación. Sin embargo, el conjunto de los sí o números naturales tiene alguna estructura. primos entre sí, si y sólo si su MCD es 1. Sets con una operación asociativa (la primera Por ejemplo, ni 35 ni 6 son primos, pero son primos entre sí, ya que estos dos números no condición anterior) se llaman semigroups; si tienen factores comunes mayor que 1, por lo que también tienen un elemento de identidad (el su MCD es 1. Un conjunto de números enteros X segundo ción condi-), entonces se les llama = {i, i, ...} es relativamente monoides. Nuestro conjunto de los números naturales es bajo la adición a continuación, un ejemplo de un monoide, una estructura que 12 primo si todos los pares posibles i, i, h ≠ k dibujan No Fromis un grupo bastante porque falta el HK el conjunto X son primos entre sí. ningunos. Por ejemplo, grupo, monoid, anillo, y celosía 11. Estructuras algebraicas son ejemplos de estructuras algebraicas. Cada una de ellas se define en esta sección. En esta sección se presenta un par de representaciones utilizadas en álgebra superior. Una estructura algebraica consiste en uno o dos conjuntos cerrados bajo algunas operaciones y que satisfacen una serie de axiomas, incluyendo

14-28 Guía SWEBOK® requisito de queV3.0 cada

elemento tiene una inversa bajo la operación. A monoid es un conjunto S que está cerrado en una sola operación binaria asociativa • y tiene un elemento de identidad I ∈ S tal que para todo a ∈ S, I • a = a • I = A. A monoid debe contener al menos un elemento. Por ejemplo, el conjunto de números naturales N forma un monoide conmutativo bajo la adición con el elemento de identidad 0. El mismo conjunto de números naturales N también forma un monoide bajo la multiplicación con el elemento de identidad 1. El conjunto de Gers inte- positivos P forma una monoide conmutativo bajo múltiples plicatura con elemento de identidad 1. Cabe señalar que, a diferencia de los de una grupo, elementos de un monoide no necesitan tener inversas. UN

Fundamentos matemáticos 14-29

monoid también puede ser pensado como una semigrupo con un elemento de identidad. Un subgrupo es un grupo H contenida dentro de uno más grande, G, de tal manera que el elemento de identidad de 2 GRAMO está contenido en H, y yh so 1 cuando h n -1. en H, entonces también yh Por lo tanto, el 1 2 lo son h • h ele- 1 mentos de H, equipadas con la operación del grupo en GRAMO restringido a H, en efecto formar un grupo. Dado cualquier subconjunto S de un grupo G, el subgrupo generado por S se compone de productos de elementos de S y sus inversos. Es el subgrupo más pequeño de G que contiene S. Por ejemplo, sea G el grupo abeliano cuyos elementos son G = {0, 2, 4, 6, 1, 3, 5, 7} y cuya operación de grupo es suma de módulo 8. Este grupo tiene un par de subgrupos no triviales: J = {0, 4} y H = {0, 2, 4, 6}, donde J es también un subgrupo de H. en la teoría de grupos, un grupo cíclico es un grupo que puede ser generada por un solo elemento, en el sentido que el grupo tiene un elemento un (llamado el generador del grupo) de tal manera que, cuando se escribe multiplicativa, cada elemento del grupo es una poder de una. Un grupo G es cíclico si G = {an para cualquier número entero n}. Puesto que cualquier grupo generado por un elemento en un grupo es un subgrupo de dicho grupo, mostrando que el único subgrupo de un grupo G que contiene una es en sí G es suficiente para mostrar que G es cíclico. Por ejemplo, el grupo G = {0, 2, 4, 6, 1, 3, 5, 7}, con respecto a la operación de adición módulo 8, es cíclico. El subgrupos J = {0, 4} y H = {0, 2, 4, 6} también son cíclicos.

11.2. anillos Si tomamos un grupo abeliano y definimos un segundo operación con dicho elemento, una nueva estructura se encuentra que es diferente de sólo un grupo. Si esta segunda operación es asociativa y es distributiva sobre la En primer lugar, entonces tenemos un anillo. Un anillo es un triple de la forma (S, +, •), donde (S, +) Es un grupo abeliano, (S, •) es un semigrupo, y • es distributiva sobre +; es decir, “a, b, c ∈ S, la ecuación ción a • (b + c) = (a • b) + (a • c) sostiene. Además, si • es conmutativo, entonces el anillo se dice que es conmutativa. Si hay un elemento de identidad para el • funcionamiento, entonces el anillo se dice que tiene una identidad. Por ejemplo, (Z, +, *), es decir, el conjunto de los enteros Z, con la adición usual y multiplicación opera- ciones, es un anillo. Como (Z, *) es conmutativo, este anillo es un anillo conmutativo o abeliano. El anillo tiene 1 como elemento de identidad. Vamos en cuenta que la segunda operación no puede tener un elemento de identidad, ni tenemos que encontrar un inverso para cada elemento con respecto a esta segunda operación. En cuanto a lo que significa la distribución, de manera intuitiva que es lo que hacemos en matemá- ticas elementales al realizar el siguiente cambio: una * (B + c) = (a * b) + (a * c). Un campo es un anillo para el que los elementos del conjunto, con exclusión de 0, forman un grupo abeliano con la segunda operación. Un ejemplo simple de un campo es el campo de los números gestionar racionalmente (R, +, *) con las operaciones de suma y multiplicación habituales. Los números del formato a / b ∈ R, donde a, b son números enteros y b ≠ 0. El inverso aditivo de una fracción tal es simplemente -a / b, y el inverso multiplicativo es b / a condición de que a ≠ 0.

14-30 Guía SWEBOK® V3.0

1. conjuntos, relaciones, funciones 2. Lógica Básica

c2 c1

3. Técnicas de prueba

c1

4. Recuento básico 5. Los gráficos y los árboles

c6 c10, c11

6. probabilidad discreta 7. máquinas de estados finitos

c7 c13

8. gramáticas

c13 c2

9. numérica precisión, exactitud y errores 10. Teoría de Números 11. Estructuras algebraicas

cheney y Kincaid 2007 [2 *]

rosen 2011 [1 *]

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

c4

Fundamentos matemáticos 14-31

Referencias

EXPRESIONES DE GRATITUD

[1 *] K. Rosen, Matemática Discreta y sus Aplicaciones, 7ª ed., McGraw-Hill, 2011.

El autor reconoce por suerte la contribución del profesor Arun Kumar Chatterjee, Ex-Jefe del Departamento de Matemáticas de la Universidad de Manipur, India, y el Prof. Devadata Sinha, Ex-Jefe del Departamento de Ciencias de la Computación y Engineer- ing, Universidad de Calcuta, India, en la preparación de este capítulo sobre Fundamentos matemáticos.

[2 *] EW Cheney y DR Kincaid, Numéricos Matemáticas y Computación, 6 ª ed., Brooks / Cole, 2007.

14-32 Guía SWEBOK® V3.0

FUNDAMENTOS DE INGENIERÍA Capítulo 15 SIGLAS CANALL Diseño asistido por ordenador A Capability Maturity Model CMMI Integration pdf PMF

Función de densidad de probabilidad Función de probabilidad

RCA

Análisis Causa Raíz

SDLC

Ciclo de vida del desarrollo de programas

INTRODUCCIÓN IEEE define la ingeniería como “la aplicación de un enfoque sistemático, disciplinado, cuantificable a las estructuras, máquinas, productos, sistemas o procesos” [1]. En este capítulo se describen algunas de las habilidades básicas de ingeniería y técnicas que son útiles para un ingeniero de software. La atención se centra en los temas que apoyan otros KAs mientras minimizando la duplicación de los temas tratados en otra parte de este documento. A medida que la teoría y la práctica de la ingeniería de software madura, es cada vez más evidente que la ingeniería de software es una disciplina de ingeniería que se basa en el conocimiento y las habilidades com- mon a todas las disciplinas de ingeniería. Esta área de conocimiento Fundamentos inge- niería (KA) se ocupa de los fundamentos técnicos que se apliquen a la ingeniería de software y otras disciplinas de ingeniería. Temas de esta KA incluyen métodos empíricos y técnicas experimentales; análisis estadístico; medición; diseño de ingeniería; modelado, prototipado y la simulación; normas; y análisis de la causa raíz. La aplicación de este conocimiento, en su caso, permitirá a los ingenieros de software para desarrollar y mantener el software de manera más eficiente y efectiva. Com- pletar su trabajo

efectivamente es un objetivo de todos los ingenieros en todas las disciplinas de inge- niería. DISTRIBUCIÓN DE TEMAS PARA FUNDAMENTOS DE INGENIERÍA El desglose de los temas para la Ingeniería Fundamentos KA se muestra en la figura 15.1. 1. Métodos empíricos y técnicas experimentales de manera eficiente y de ingeniería

[2 *, c1] Un método de ingeniería para la resolución de problemas implica proponer soluciones o modelos de soluciones y luego la realización de experimentos o ensayos para estudiar las soluciones o modelos propuestos. Por lo tanto, los ingenieros deben entender cómo crear un iment exper- y luego analizar los resultados del experi- mento con el fin de evaluar la solución propuesta. Los métodos empíricos y técnicas experimentales ayudan al ingeniero para describir y entender la variabilidad en sus observaciones, para identificar las fuentes de variabilidad, y para tomar decisiones. experimentos tres tipos diferentes de estudios empíricos com- utilizan comúnmente

en los esfuerzos de ingeniería están diseñados, estudios observacionales y estudios retrospectivos. Breves descripciones de los commétodos utilizados comúnmente se dan a continuación. 1.1. experimento diseñado Un experimento diseñado o controlada es un investiga- ción de una hipótesis comprobable donde una o más variables independientes son manipuladas para medir su efecto sobre una o más variables dependientes. Una condición previa para la realización de un experimento es la existencia de una hipótesis clara. Es importante para un ingeniero para entender cómo formular hipótesis claras. 15-1

15-2

Guía SWEBOK® V3.0

Figura 15.1. Desglose de los temas de los Fundamentos de Ingeniería KA

experimentos diseñados permiten a los ingenieros para determinar de forma precisa cómo se relacionan las variables y, en concreto, si una causa-efecto existe relación entre ellos. Cada combinación de valores de las variables independientes es un tratamiento. Los experimentos simples tienen sólo dos tratamientos que representan dos niveles de una variable independiente GLE pecado (por ejemplo, usando una herramienta frente a no usar una herramienta). surgen Más diseños experimentales complejas cuando se utilizan más de dos niveles, más de una variable independiente, o cualquier variables dependientes. 1.2. Estudio observacional Un estudio observacional o caso es una investigación empírica que hace observaciones de los procesos o fenómenos dentro de un contexto de la vida real. Mientras que un experimento ignora deliberadamente contexto, un estudio de observación o caso incluye contexto como parte de la observación. Un estudio de caso es más uso- ful cuando el foco del estudio está en cómo y por qué preguntas, cuando el comportamiento de los participantes en el estudio no puede ser manipulada, y cuando las condiciones con- textual son relevantes y los límites entre el fenómeno y el contexto no son claras. 1.3. Estudio retrospectivo Un estudio retrospectivo implica el análisis de his- datos tórica. Los estudios retrospectivos son también conocidos como los estudios históricos. Este tipo de estudio utiliza datos (en relación con algún fenómeno) que se ha archivado en el tiempo. Estos datos archivados se anacontinuación lisó en un intento de encontrar una relación entre las variables, para predecir

2. Análisis estadístico

[2 *, c9s1, C2S1] [3 *, c10s3]

eventos futuros, o para identificar tendencias. La calidad de los resultados del análisis dependerá de la calidad de la información contenida en los datos archivados. Los datos históricos pueden ser incompleta, inconsistente medido, o incorrecta.

Con el fin de llevar a cabo sus responsabilidades, inge- nieros deben entender cómo las diferentes características del producto y de proceso varían. Los ingenieros a menudo se encuentran con situaciones en las que la relación entre las diferentes variables debe ser estudiado. Un punto importante a destacar es que la mayoría de los estudios se llevan a cabo sobre la base de muestras y por lo que los resultados observados necesita ser entendido con respecto a la población completa. Los ingenieros deben, por lo tanto, desarrollar una comprensión adecuada de ING técnicas estadísticas para la recogida de datos fiables en cuanto a la toma de muestras y análisis para llegar a resultados que pueden generalizarse. Estas técnicas se discuten a continuación. 2.1. Unidad de análisis (unidades de muestreo), Población y Muestra Unidad de Análisis. Mientras lleva a cabo cualquier estudio cal empíricamente, las observaciones deben hacerse en unidades sen CHO- llamados las unidades de análisis o las unidades de muestreo. La unidad de análisis debe ser identificado y debe ser apropiado para el análisis. Por ejem- plo, cuando una empresa de productos de software quiere encontrar la utilidad percibida de un producto de software, el usuario o la función de software pueden ser la unidad de análisis. Población. El conjunto de todos los encuestados o artículos (posibles unidades de muestreo) para ser estudiado formas la población. Como ejemplo, considere el caso de estudio de la usabilidad percibida de un producto de software. En este caso, el conjunto de todos los posibles usuarios forma la población. Si bien la definición de la población, se debe tener cuidado para comprender la población de estudio y objetivo. Hay casos en que la población estudiada y la población para la cual el

Fundamentos de ingeniería 15-3

15-4

Guía SWEBOK® V3.0

resultados están siendo generalizadas pueden ser diferentes. Por ejemplo, cuando la población de estudio consta de sólo el pasado observaciones y generalizaciones son necesarios para el futuro, la población estudiada y la población objetivo puede no ser la misma. Muestra. Una muestra es un subconjunto de la población. La cuestión más crucial para la selección de una muestra es su representatividad, incluyendo el tamaño. Las muestras deben extraerse de una manera a fin de asegurar que los sorteos son independientes, y las reglas de dibujo de las muestras deben ser definidos prede modo que la probabilidad de seleccionar una unidad de muestreo ticular par- se conoce de antemano. Este método de selección de las muestras se llama muestreo probabilístico. Variable aleatoria. En la terminología estadística, el proceso de hacer las observaciones o las mediciones en las unidades de muestreo que se estudian se conoce como la realización del experimento. Por ejemplo, si el experimento es lanzar una moneda 10 veces y luego contar el número de veces que la moneda cae en cabezas, cada 10 lanzamientos de la moneda es una unidad de muestreo y el número de cabezas de una muestra dada es la observación o el resultado para el experimento. El resultado de un experimento se obtiene en términos de números reales y define la variable aleatoria en estudio. Por lo tanto, el atributo de los artículos que se mide en el resultado del experimento representa la variable aleatoria que se está estudiando; la observación obtenido a partir de una unidad de muestreo particular es una realización particular de la variable aleatoria. En el ejemplo de la sacudida de la moneda, la variable aleatoria es el número de cabezas observados para cada experimento. En estu- dios estadísticos, se hacen intentos para entender características de la población sobre la base de muestras. El conjunto de posibles valores de una variable aleatoria puede ser finito o infinito pero numerable (por ejemplo, el conjunto de todos los números enteros o el conjunto de todos los números impares). En tal caso, la variable aleatoria se llama una variable aleatoria Creta dis-. En otros casos, la variable aleatoria bajo consideración puede tomar valores en una escala continua y que se llama una variable aleatoria continua. Evento. Un subconjunto de valores posibles de

una variable aleatoria se llama un evento. Supongamos que X denota algún variable aleatoria; entonces, por ejemplo, podemos definir diferentes eventos tales como X ³ X <x x o y así sucesivamente.

Distribución de una variable aleatoria. La gama y el patrón de variación de una variable aleatoria está dada por su distribución. Cuando se conoce la distribución de una variable aleatoria, es posible calcular la probabilidad de cualquier evento. Algunos las distribuciones se encuentran a ocurrir comúnmente y se utilizan para modelar muchas variables aleatorias que se producen en la práctica en el contexto de la ingeniería. Algunas de las distribuciones que se producen más comúnmente se dan a continuación. • distribución Binomial: utilizado para modelar variables aleatorias que cuentan el número de éxitos en n ensayos llevados a cabo independientemente una de otra, donde cada ensayo resultados en el éxito o fracaso. Hacemos una suposición de que la posibilidad de obtener un éxito permanece cons- tante [2 *, c3s6]. • distribución de Poisson: se utiliza para modelar el conteo de ocurrencia de un evento con el tiempo o en el espacio [2 *, c3s9]. • La distribución normal: se utiliza para modelar variables aleatorias OU continuidades o variables aleatorias discretas mediante la adopción de un número muy grande de valores [2 *, c4s6]. Concepto de parámetros. Una distribución estadística se caracteriza por algunos parámetros. Por ejem- plo, la proporción de éxito en cualquier ensayo dado es el único parámetro que caracteriza una distribución binomial. Del mismo modo, la distribución de Poisson se caracteriza por una tasa de ocurrencia. Una distribución normal se caracteriza por dos parámetros: a saber, su media y la desviación estándar. Una vez que se conocen los valores de los parámetros, la distribución de la variable aleatoria es completa- mente conocido y la posibilidad (probabilidad) de cualquier evento puede ser calculado. Las probabilidades para una variable aleatoria discreta se pueden calcular a través de la función de masa de probabilidad, llamado el PMF. El PMF se define en puntos discretos y le da al punto de masa, es decir, la probabilidad de que la variable aleatoria se llevará a ese valor particular. Del mismo modo, para una variabilidad aleatoria continua capaz, tenemos la función de densidad de probabilidad, llamado el pdf. El pdf es muy parecido a la

Fundamentos 15-5 densidad y tiene que integrarse endeuningeniería rango para obtener la probabilidad de que los continuos variabilidad aleatoria capaces mentiras entre ciertos valores. Por lo tanto, si el pdf

15-6

Guía SWEBOK® V3.0

o PMF se conoce, las posibilidades de la variabilidad aleatoria capaz teniendo cierto conjunto de valores pueden ser calculadas teóricamente. Concepto de estimación [2 *, c6s2, c7s1, c7s3]. Los verdaderos valores de los parámetros de una distribución son generalmente desconocidas y necesitan ser estimada a partir de las observaciones de la muestra. Las estimaciones son funciones de los valores de la muestra y se llaman estadísti- cas. Por ejemplo, la media de la muestra es una estadística y puede ser utilizado para estimar la media poblacional. Del mismo modo, la tasa de aparición de defectos de estimación se aparearon de la muestra (tasa de defectos por línea de código) es una estadística y sirve como la estimación de la tasa de población de tasa de defectos por línea de código. El estadístico utilizado para estimar algún parámetro pobla- ción se refiere a menudo como el estimador del parámetro. Un punto muy importante a tener en cuenta es que los resultados de los mismos estimadores son aleatorios. Si tomamos una muestra diferente, es probable que obtener una estimación diferente del parámetro de la población. En la teoría de estimación, es necesario entender las diferentes propiedades de los estimadores -en particular, la cantidad de las estimaciones pueden variar a través de muestras y cómo elegir entre diferentes modos alternativos para obtener las estimaciones. Por ejemplo, si deseamos estimar la media de una población, podríamos utilizar como nuestro estimador de la media de una muestra, una mediana de la muestra, un modo de muestra, o la gama media de la muestra. Cada uno de estos estimadores tiene diferentes propiedades estadísticas que pueden impactar el error estándar de la estimación. tipos de las estimaciones [2 *, c7s3, c8s1] .Hay dos tipos de estimaciones: a saber, las estimaciones puntuales y las estimaciones de intervalo. Cuando se utiliza el valor de una estadística para estimar un parámetro de la población, se obtiene una estimación puntual. Como su nombre indica, una estimación puntual da un valor en puntos de la param eter está estimando. Aunque a menudo se utilizan las estimaciones puntuales, que dan cabida a muchas preguntas. Por ejemplo, no se nos dice nada acerca de la

posible tamaño del error o propiedades estadísticas del compañero de estimación punto. Por lo tanto, necesitan un suplemento de una estimación puntual con el tamaño de la muestra, así como la varianza de la estimación. Como alternativa, podríamos utilizar una estimación de intervalo. Una estimación de intervalo es un intervalo aleatorio con el li- inferior y superior del intervalo de sus siendo funciones de la muestra

observaciones, así como el tamaño de la muestra. Los límites se calculan sobre la base de algunas suposiciones con respecto a la distribución de muestreo de la estimación puntual en que se basan los límites. Propiedades de los estimadores. Varias propiedades estadísticas de los estimadores se utilizan para decidir sobre la conveniencia de un estimador en una situación dada. Las propiedades más importantes son que es un estimador imparcial, eficiente y coherente con respecto a la población. pruebas de hipótesis [2 *, c9s1] .A hipótesis es una declaración acerca de los posibles valores de un eter param. Por ejemplo, supongamos que se afirma que un nuevo método de desarrollo de software reduce la aparición de defectos. En este caso, la hipótesis es que la tasa de aparición de defectos se ha reducido. En las pruebas de hipótesis, decidimos-sobre la base de las observaciones de la muestra, ya sea un pro- puesto hipótesis debe ser aceptada o rechazada. Para la prueba de hipótesis, se forman las hipótesis nula y alternativa. La hipótesis nula es la hipótesis de no cambio y se denota como H. La hipótesis alternativa se escribe como H. Es impor- tante tener en cuenta que la hipótesis alternativa puede ser unilateral o bilateral. Por ejemplo, si tenemos la hipótesis nula de que la media poblacional no es menor que un cierto valor dado, la hipótesis alternativa sería que es inferior a ese valor y que tendría una prueba unilateral. Sin embargo, si tenemos la hipótesis nula de que la media poblacional es igual a un valor determinado, la hipótesis alternativa sería que no es igual y que tendría una prueba bilateral (debido a que el valor real podría ser menor que o mayor que el valor dado). Con el fin de probar alguna hipótesis, primero se compute alguna estadística. Junto con el cálculo de la estadística, una región se define de tal manera que en caso de que el valor calculado de la estadística cae en esa región, se rechaza la hipótesis nula. Esta región es llamada la región crítica (también conocido como el intervalo de confianza). En las pruebas de hipótesis, tenemos que aceptar o rechazar la hipótesis nula sobre la base de las pruebas obtenidas. Observamos que, en general, la hipótesis alternativa es la hipótesis de interés. Si el valor calculado de la estadística no cae dentro de la región crítica, entonces no podemos rechazar la hipótesis nula. Esto indica que no hay suficiente evidencia para cree que la hipótesis alternativa es verdadera.

Fundamentos de ingeniería 15-7

0 1

15-8

Guía SWEBOK® V3.0

A medida que se toma la decisión sobre la base de las observaciones de la muestra, los errores son posibles; los tipos de tales errores se resumen en la tabla siguien- tes. Decisión estadística Natural aceptar H rechazar H eza 0 0 Su error tipo I 0 DE (probabilidad = ciert AC o a) Su errorUE tipo II 0 DE (probabilidad = falso RD AC b) O UE En la prueba de hipótesis, nuestro RD objetivo es maximizar la potencia de la prueba (el O valor de 1-b), mientras que fin de • asegurar que la probabilidad de un error de tipo I (el valor de a) se mantiene dentro de una de valor particular, típicamente de 5 por ciento . Es de notar que la construcción de una prueba de hipótesis estadística incluye la identificación (s) para estimar el parámetro (s) y que define una región crítica de tal manera que si el valor calculado de la estadística cae en la región crítica, el hypoth nula - se rechaza ESIS. 2.2. Conceptos de correlación y regresión [2 *, c11s2, c11s8] Un objetivo principal de muchas investigaciones estadísticos es establecer relaciones que hacen que sea posi- ble para predecir una o más variables en función de otras. Aunque es deseable para predecir una cantidad exactamente en términos de otra cantidad, es posible dom SEL- y, en muchos casos, tenemos que estar satisfechos con la estimación de los valores medios o esperados. La relación entre dos variables se IED estuutilizando los métodos de correlación y de regresión. Estos dos conceptos se explican brevemente en los siguientes párrafos. Correlación. La fuerza de la nave PARENTESCO lineal entre dos variables se mide utilizando el coeficiente de correlación. Si bien el cálculo del coeficiente de correlación entre dos variables, se supone que estas variables miden dos atributos dife- rentes de la misma entidad. El coeficiente de correlación toma un valor entre -1 a +1. Los valores -1 y 1 indican una situación en la que la asociación

entre las variables es perfecto, es decir,

dado el valor de una variable, la otra puede estimarse sin error. Un coeficiente de correlación positivo indica una relación que positiva es, si una variable aumenta, también lo hace la otra. Por otro lado, cuando las variables tienen una correlación negativa, un aumento de un conduce a una disminución de la otra. Es importante recordar que la correlación no implica causalidad. Por lo tanto, si se correlacionan dos variables, no podemos concluir que uno causa el otro. Regresión. El análisis de correlación sólo mide el grado de relación entre dos variables. El análisis para encontrar la relación entre dos variables se denomina análisis de regresión. La fuerza de la relación entre dos variables se mide utilizando el coeficiente de determinación. Este es un valor entre 0 y 1. Cuanto más cerca el coeficiente es de 1, mayor es la relación entre las variables. Un valor de 1 indica una relación perfecta. 3. Medición [4 *, c3s1, c3s2] [5 *, c4s4] [6 *, c7s5] [7 *, p442-447] Saber qué medir y qué método de medición ción a utilizar es crítica en los esfuerzos de ingeniería. Es importante que todos los involucrados en un proyecto de ingeniería entender los métodos de medición y los resultados de la medición que se utilizarán. Las medidas pueden ser, tal ambien- física, económica, operacional, o algún otro tipo de medida que sea significativo para el proyecto en particular. Esta sección explora la teoría de la medi- surement y la forma en que es fundamental para Engineer- ing. La medición se inicia como una conceptualización entonces se mueve de conceptos abstractos a las definiciones del método de medición para la aplica- ción real de que el método para obtener un resultado de la medición. Cada uno de estos pasos debe entenderse, comunicado, y adecuadamente empleados a fin de generar datos utilizables. En inge- niería tradicional, a menudo se utilizan medidas directas. En la ingeniería de software, una combinación de ambas medidas directas y derivadas es necesaria [6 *, P273]. La teoría de la medida establece que la medida es un intento de describir un subyacente

Fundamentos de ingeniería 15-9

15-10 Guía SWEBOK® V3.0

sistema empírico real. Métodos de medición definen actividades que asignan un valor o un símbolo a un atributo de una entidad. Los atributos deben entonces ser definidos en términos de las operaciones utilizadas para identificar y medir ellos- es decir, los métodos de medición. En este enfoque, se define un método de medición para ser una operación especificada precisamente que produce un número (llamado el resultado de la medición) cuando medi- suring un atributo. De ello se deduce que, para ser útil, el método de medición tiene que estar bien definida. La arbitrariedad en el método se reflejará en la ambigüedad en los resultados de medición. En algunos casos, particularmente en el mundo de los atributos físicos que deseamos medir son fáciles de entender; Sin embargo, en un mundo artificial como la ingeniería de software, la definición de los atributos puede no ser tan simple. Por ejemplo, los atributos de altura, peso, distancia, etc. son fácil y uniforme comprendido formemente (aunque pueden no ser muy fácil de medir en todas las circunstancias), mientras que los atributos como el tamaño o la complejidad del software requieren definiciones claras. Definiciones operacionales. La definición de atri- buye, para empezar, es a menudo bastante abstracto. Tales definiciones no facilitan mediciones. Por ejemplo, podemos definir un círculo como una línea que forma un bucle cerrado de tal manera que la distancia entre cualquier punto en esta línea y un punto interior fijo llamado centro es constante. Podemos decir, además, que la distancia fija desde el centro a cualquier punto en el bucle cerrado da el radio del círculo. Cabe señalar que aunque el concepto se ha definido, se ha propuesto ningún medio de la medición de la radio. La definición operacional especifica los pasos exactos o el método utilizado para llevar a cabo una medición específica. Esto también puede ser llamado el método de medición; a veces un procedimiento de medición puede ser necesaria para ser aún más preciso. La importancia de las definiciones operacionales difícilmente puede ser exagerada. Tomemos el caso de la aparentemente simple medición de la talla de los individuos. A menos que especifiquemos varios factores como el momento en el que se medirá la altura (se sabe

que la altura de los individuos varían a través de varios puntos de tiempo del día), cómo la variabilidad debida al cabello lo que se ocuparon de, si la medición será con o sin zapatos, ¿qué clase de precisión que se espera (corregir hasta una pulgada, 1/2 pulgada, centímetro, etc.) -, incluso

esta simple medida dará lugar a una variación sustancial. Los ingenieros deben apreciar la necesidad de definir medidas desde una perspectiva operacional. 3.1. Niveles (Scales) de Medición [4 *, c3s2] [6 *, c7s5] Una vez que se determinan las definiciones operacionales, las medidas reales deben llevarse a cabo. Es de notar que la medición puede ser car- ried a cabo en cuatro escalas diferentes: a saber, nominal, ordinal, intervalo, y la relación. Breves descripciones de cada uno se dan a continuación. Escala nominal: Este es el nivel más bajo de surement medi- y representa la asignación más sin restricciones de numerales. Los números sólo sirven como etiquetas y palabras o letras servirían también. La escala nominal de la medición sólo implica la clasificación y las unidades de muestreo observados se ponen en una cualquiera de las categorías mutuamente excluyentes y colectivamente exhaustivos (clases). Algunos ejemplos de escalas nominales son: • Los puestos de trabajo en una empresa • El ciclo de vida de desarrollo de software (SDLC) modelo (como cascada, iterativa, ágil, etc.) seguido de diferentes proyectos de software En escala nominal, los nombres de las diferentes catego- rías son sólo etiquetas y no se asume ninguna relación entre ellos. Las únicas operaciones que se pueden llevar a cabo en la escala nominal es la de contar el número de ocurrencias en las diferentes clases y determinar si dos sucesos tienen el mismo valor nominal. Sin embargo, los análisis estadísticos se pueden llevar a cabo para entender cómo las entidades pertenencias ing a diferentes clases realizan con respecto a alguna otra variable de respuesta. Escala ordinal: Se refiere a la escala de medición donde los diferentes valores obtenidos a través del proceso de la medición tienen una ing orden- implícita. Los intervalos entre los valores no son manera especificada y no hay objetivamente definido elemento cero. Ejemplos típicos de las mediciones en escalas ordinales son: • Los niveles de habilidad (bajo, medio, alto)

de ingeniería 15• Capability Maturity Fundamentos Model Integration 11 (CMMI) niveles de madurez de software de desa- rrollo organizaciones

15-12 Guía SWEBOK® V3.0

• Nivel de adherencia a procesar tal como se mide en una escala de 5 puntos de excelente, encima de la media, media, por debajo de la media, y pobre, lo que indica el intervalo de adhesión total a no adherencia en absoluto La medición en escala ordinal satisface la propiedad sibilidad tran- en el sentido de que si A> B y B > C, entonces A> C. Sin embargo, las operaciones aritméticas no puede llevarse a cabo en variables medidas en escalas ordinales. Por lo tanto, si se mide la satisfacción del cliente en una escala ordinal de 5 puntos de 5 lo que implica un alto nivel de satisfacción y 1 lo que implica un alto nivel de insatisfacción, no podemos decir que una puntuación de cuatro es dos veces mejor que una puntuación de dos. Por lo tanto, es mejor utilizar terminología como excelente, encima de la media, media, por debajo de la media, y pobres que los números ordinales con el fin de evitar el error de tratamiento de una escala ordinal como una escala de proporción. Es importante tener en cuenta que las medidas ordinales escala son comúnmente mal y el mal uso puede llevar a conclusiones erróneas [6 *, P274]. Un mal uso común de medi- das escala ordinal es presentar una media y la desviación estándar para el conjunto de datos, los cuales son de sentido. Sin embargo, podemos encontrar la mediana, como el cálculo de la mediana consiste en el conteo solamente. escalas de intervalo: Con la escala de intervalos, llegamos a una forma que es cuantitativa en el sentido ordinario de la palabra. Casi todas las medidas habituales Statistical Sta son aplicables aquí, a menos que requieran el conocimiento de un verdadero punto cero. El punto cero en una escala de intervalo es una cuestión de con- vención. Proporciones no tienen sentido, pero la diferencia entre los niveles de atributos se pueden calcular y es significativo. Algunos ejemplos de escala de intervalo de seguimiento de medición:

medido en escala de intervalo, ya que no es preciso proceder a definir lo que significaría cero inteligencia. Si una variable se mide en escala de intervalos, la mayoría de los análisis estadísticos habituales, como media, Normaliza- dard desviación, correlación y regresión pueden llevarse a cabo sobre los valores medidos. Escala de proporción: Estos son muy comúnmente encon- trada en la ciencia física. Estas escalas de medi- das se caracterizan por el hecho de que existen operaciones para la determinación de los 4 relaciones: igualdad, orden de rango, la igualdad de los intervalos, y la igualdad de las proporciones. Una vez que tal escala está disponible, sus ues Val- numérico se pueden transformar de una unidad a otra con sólo multiplicar por una constante, por ejemplo, la conversión de pulgadas a pies o centímetros. Cuando las mediciones se realizan en escala de razón, la existencia de un cero no arbitrario es obligatorio. Todas las medidas estadísticas son aplicables a escala de razón; uso logaritmo sólo es válido cuando se utilizan estas escalas, como en el caso de decibelios. Algunos ejemplos de medidas de razón son • el número de declaraciones en un programa de software • temperatura medida en la escala Kelvin (K) o en Fahrenheit (F). Una escala de medición adicional, la escala absoluta, es una escala de proporción con singularidad del seguro de medi-; es decir, una medida para la cual no es posible la transformación (por ejemplo, el número de los programadores trabajando en un proyecto). 3.2. Medidas directos y derivados [6 *, c7s5] Las medidas pueden ser directa o derivado (algutiempos de llamada medidas indirectas). Un ejemplo de

• Medición de la temperatura en diferentes escalas, tales como grados Celsius y Fahrenheit. Cenarplantea1 y T se miden temperaturas una medida directa sería una cuenta de cuántas rT 2 en alguna escala. Observamos que el hecho 1de queTtimes ocurrió un evento, tal como el número

es el doble2 no quiere decir que un objeto es T dos veces tan caliente como otra. También observamos que los puntos cero son arbitrarias. • Las fechas del calendario. Mientras que la diferencia entre las fechas para medir el tiempo transcurrido es un concepto ingful Entretanto, la relación no tiene sentido. • Muchas mediciones psicológicas aspiran a crear escalas de intervalo. La inteligencia es a menudo

Fundamentos de ingeniería 15de 13 defectos encontrados en un producto de software. Un derivado medida es el que combina medidas directas de alguna manera que sea consistente con el método de medición. Un ejemplo de una medida derivada sería el cálculo de la productividad de un equipo como el número de líneas de código desarrolladas por mes Developer-. En ambos casos, el método de medición determina cómo hacer la medición.

15-14 Guía SWEBOK® V3.0

3.3. Fiabilidad y Validez [4 *, c3s4, c3s5] Una cuestión fundamental que se plantea para cualquier método de medi- ción es si el método de medi- ción propuesta es realmente medir el concepto de buena calidad. Fiabilidad y validez son los dos criterios más importantes para abordar esta cuestión. La fiabilidad de un método de medición es el grado en el que la aplicación del método de medición proporciona resultados de medición consistentes. Esencialmente, la fiabilidad se refiere a la consistencia de los valores obtenidos cuando el mismo artículo se mide un número de veces. Cuando los resultados están de acuerdo entre sí, se dice que el método de medición fiables. Fiabilidad por lo general depende de la definición operativa. Se puede cuantificarse utilizando el índice de variación, que se computadas como la relación entre la desviación estándar y la media. Cuanto menor sea el índice, más fiables serán los resultados de la medición. Validez se refiere a si el método de medición mide realmente lo que pretendemos mediseguro. Validez de un método de medición puede ser visto desde tres perspectivas diferentes: a saber, la validez de constructo, validez criterios, y validez de contenido. 3.4. Fiabilidad evaluar

[4 *, c3s5] Hay varios métodos para evaluar su confiabilidad; Estos incluyen el método de ensayo-retest, el método de forma alternativa, el método split mitades, y el método de consistencia interna. El est easi- de estos es el método de ensayo-retest. En el método testretest, simplemente aplicamos el método de medición para los mismos sujetos en dos ocasiones. El coeficiente de correlación entre el primer y segundo conjunto de resultados de la medición da la fiabilidad del método de medida. 4. Diseño de ingeniería [5 *, c1s2, c1s3, c1s4]

El diseño de un producto de software es guiada por las características que deben incluirse y los atri- buye calidad que deben presentar. Es importante observar que ingenieros de software usan el término “diseño” en su propio contexto; si bien hay algunas lidades de common, también hay muchas diferencias entre el diseño de ingeniería como se explica en esta sección y software de diseño de ingeniería como se discutió en el software de diseño KA. El alcance del diseño de inge- niería es generalmente visto como mucho más amplio que el de diseño de software. El objetivo principal de esta sección es identificar los conceptos necesarios para desarrollar una comprensión clara con respecto a la pro- ceso de diseño de ingeniería. Muchas disciplinas participan en la solución de problemas actividades donde hay una única solu- ción correcta. En ingeniería, la mayoría de los problemas tienen muchas soluciones y la atención se centra en la búsqueda de una solución factible (entre las muchas alternativas) que mejor se adapte a las necesidades planteadas. El conjunto de soluciones po- sible es a menudo limitada por explic- limitaciones impuestas tamente como el coste, recursos disponibles, y el estado de la disciplina o el dominio del conocimiento. En los problemas de ingeniería, a veces también hay limitaciones implícitas (como las propiedades físicas de los materiales o las leyes de ics phys-) que también restringen el conjunto de soluciones factibles para un problema dado. los costos del ciclo de vida del producto están muy influenciados por el diseño del producto. Esto es cierto para los productos manufacturados, así como para productos de software.

4.1. Diseño de ingeniería en la Educación en Ingeniería La importancia del diseño de ingeniería en la formación de ingenieros puede ver claramente por las altas expectativas de los diferentes IES DBO de acreditación para la formación de ingenieros. Tanto la Junta de Acreditación de Ingeniería dian Cana- y la Junta de Acreditación de Ingeniería y Tech- nology (ABET) señalan la importancia de incluir el diseño de ingeniería en programas de educación. El Consejo de Acreditación de Ingeniería de Canadá incluye los requisitos para la cantidad de experiencia en el diseño de ingeniería / cursos que es necesario que los estudiantes de ingeniería, así como los requisitos para los miembros de la facultad que enseñan estos cursos o supervisan los proyectos de diseño. Sus criterios de acreditación establece lo siguiente:

Fundamentos de ingeniería 1515

15-16 Guía SWEBOK® V3.0

Diseño: La capacidad de diseñar soluciones de ingeniería, proble- blemas indefinidos complejas y diseñar sistemas, componentes o procesos que satisfagan las necesidades especificadas con la debida atención a los riesgos de salud y seguridad, las normas aplicables, y con económico, ambiental, cultural y social consideraciones. [8, p12] De una manera similar, ABET define ingeniería el diseño como el proceso de elaboración de un sistema, compo- nente o proceso para satisfacer las necesidades deseadas. Es un proceso de toma de decisiones (a menudo tivo iterativo), en el que se aplican las ciencias básicas, las matemáticas, las ciencias de la ingeniería y los recursos para convertir de manera óptima para satisfacer estas necesidades establecidas. [9, p4] Por lo tanto, está claro que el diseño de ingeniería es un componente vital en la formación y la educación para todos los ingenieros. El resto de esta sección se centrará en varios aspectos de diseño de ingeniería. 4.2. El diseño como Solución de problemas Actividad [5 *, c1s4, C2S1, c3s3] Es de notar que el diseño de ingeniería es un problema primar- ily actividad de resolución. Los problemas de diseño están abiertas y más vagamente definidos. Por lo general hay varias formas alternativas para resolver el mismo problema. El diseño se considera generalmente que es un problema de un malvado término acuñado por Horst Rittel en la década de 1960 cuando los métodos de diseño fueron objeto de un intenso interés. Rittel buscó una alternativa al modelo lineal paso a paso del proceso de diseño siendo explorado por muchos diseñadores y teóricos del diseño y argumentó que la mayoría de los proble- mas abordados por los diseñadores son proble- mas malvados. Como se explica por Steve McConnell, un problema complejo es uno que podría ser claramente definido únicamente por su solución o mediante la resolución de parte de ella. Esta paradoja

implica, esencialmente, de que un problema complejo tiene que ser resuelto de una vez con el fin de definir con claridad y luego resuelve de nuevo para crear una solución que funcione. Esta ha sido una idea importante para los diseñadores de los programas durante varias décadas [10 *, c5s1].

4.3. Pasos a seguir en Diseño de Ingeniería [7 *, c4] la resolución de problemas de ingeniería comienza cuando se reconoce una necesidad y ninguna solución existente satisfacer esa necesidad. Como parte de esta resolución de problemas, se deben identificar los objetivos de diseño que deben alcanzarse en la solución. Además, un conjunto de criterios de aceptación debe ser definido y se utiliza para determinar qué tan bien una solución propuesta va a satisfacer la necesidad. Una vez a la necesidad de una solución a un problema ha sido identificado, el proceso de diseño de ingeniería tiene los siguientes pasos genéricos: a) definir el problema b) recopilar información pertinente c) generar múltiples soluciones d) analizar y seleccionar una solución de e) implementar la solución Todas las etapas de diseño de ingeniería son tivo iterativo, y los conocimientos adquiridos en cualquier etapa del proceso se puede utilizar para informar a las tareas anteriores y desencadenar una iteración en el proceso. Estos pasos se expandieron en las secciones subsiguientes. a. Define el problema. En esta etapa, se reúnen los requisitos de la er adaptado para el cliente. informa- ción específica sobre las funciones y características del producto también se examina de cerca. Este paso incluye el perfeccionamiento de la declaración de problemas para identificar el verdadero problema que hay que resolver y el establecimiento de los objetivos de diseño y criterios de éxito. La definición del problema es una etapa crucial en el diseño de ingeniería. Un punto a tener en cuenta es que este paso es engañosamente simple. Por lo tanto, la atención suficiente se debe tomar para llevar a cabo este paso con criterio. Es importante identificar las necesidades y vincular los criterios de éxito con las características de los productos requeridos. También es una tarea de ingeniería para limitar el alcance de un problema y su solución a través de la negociación entre las partes interesadas. b. Recopilar información pertinente. En esta etapa, el diseñador intenta ampliar su / su El

Fundamentos ingeniería 15conocimiento sobre el problema.de Esta es una 17 etapa vital, ya menudo no. La recopilación de información pertinente puede revelar hechos que conducen a una redefinición de la

15-18 Guía SWEBOK® V3.0

problemas, en particular, los errores y las salidas en falso puede ser identificado. Este paso puede implicar también la descomposición del problema en subproblemas más pequeños y más fáciles de resolver. En la recogida de información pertinente, se debe tener cuidado para identificar cómo un producto puede ser usado como un mal uso. También es importante entender el valor percibido del producto / servicio que se ofrece. Incluida en la información pertinente es una lista de restricciones que deben ser satisfechas por la solución o que pueden limitar el conjunto de soluciones factibles. c. Generar múltiples soluciones. Durante esta etapa, las diferentes soluciones al mismo problema son de- sarrollados. Ya se ha indicado que el diseño proble- blemas tienen múltiples soluciones. El objetivo de este paso es conceptualizar múltiples solu- ciones posibles y refinar a un nivel de detalle suficiente que la comparación puede hacerse entre ellos. d. Analizar y seleccionar una solución. Una vez que se han identificado soluciones alternativas, es necesario que se ana- lyzed para identificar la solución que mejor se adapte a la situación Curalquiler. El análisis incluye un análisis funcional para evaluar si el diseño propuesto cumpliría los requisitos funcionales. soluciones físicas que implican usuarios humanos a menudo incluyen el análisis de la ergonomía o la facilidad de uso de la solución propuesta. Otros aspectos de la solución, tales como la seguridad del producto y la responsabilidad, un análisis nómica o mercado ecológico para asegurar un retorno (ganancia) en la solución, predicciones y análisis de rendimiento para satisfacer las características de calidad, oportunidades para la entrada de datos incorrectos o fallos de hardware, y así sucesivamente-se pueden estudiar. Los tipos y la cantidad de análisis utilizado en una solución propuesta son dent depen- del tipo de problema y las necesidades que la solución debe abordar, así como las limitaciones impuestas en el diseño. e. Implementar la solución. La fase final del proceso de diseño es la implementación. tación aplica- se refiere al desarrollo y ensayo de la solución propuesta. A veces una solución preliminar, parcial llamado un prototipo puede

ser de- sarrollados inicialmente para probar la solución de diseño propuesto bajo ciertas condiciones. Comentarios como resultado de la prueba de un prototipo puede ser utilizado ya sea para

refinar el diseño o conducir a la selección de una solución de diseño alter- nativa. Una de las actividades más impor- tantes en el diseño es la documentación de la solución de diseño, así como de las ventajas y desventajas de las decisiones tomadas en el diseño de la solución. Este trabajo debe llevarse a cabo de tal manera que la solución al problema de diseño se puede com- municated claramente a los demás. La prueba y verificación nos llevan de vuelta a los criterios de éxito. El ingeniero tiene que diseñar pruebas de tal manera que la capacidad del diseño para cumplir con los criterios de éxito se demuestra. Mientras diseño- ing las pruebas, el ingeniero debe pensar a través de diferentes modos de fallo posibles y luego diseñar pruebas basadas en los modos de fallo. El ingeniero puede optar por llevar a cabo los experimentos diseñados para evaluar la validez del diseño. 5. Modelado, Simulación y Prototipos [5 *, c6] [11 *, c13s3] [12 *, c2s3.1] El modelado es parte del proceso de abstracción usado para representar algunos aspectos de un sistema. ción simulaciones utiliza un modelo del sistema y proporciona un medio para la realización de experimentos diseñados con ese modelo para comprender mejor el sistema, su comportamiento, y las relaciones entre los subsistemas, así como para analizar los aspectos del diseño. Mod eling y simulación son técnicas que se pueden utilizar para construir teorías o hipótesis sobre el comportamiento del sistema; ingenieros luego usar esas teorías para hacer predicciones sobre el sistema. Prototyping es otro proceso abstracción donde se construye una representación parcial (que captura aspectos de interés) del producto o sistema. A proto- tipo puede ser una versión inicial del sistema, pero carece de la funcionalidad completa de la versión final. 5.1. Modelado Un modelo es siempre una abstracción de algún artefacto real o imaginario. Los ingenieros utilizan modelos de muchas maneras, como parte de sus actividades de resolución de problemas. Algunos modelos son físicas, tales como la construcción en miniatura hecha a escala de un puente o edificio. Otros modelos pueden ser representaciones no

de diente ingeniería 15físicos, tales como un dibujoFundamentos CAD de un 19 o un modelo matemático para un proceso. Los modelos ayudan a los ingenieros a entender la razón y los aspectos de

Fundamentos de ingeniería 15-11

un problema. También pueden ayudar a los ingenieros Deben conocerse lo que saben y lo que no saben sobre el problema en cuestión. Hay tres tipos de modelos: icónicas, la lógica ana- y simbólica. Un modelo icónico es un equivalente aliado visu- pero incompleta representación, por ejemplo de 2 dimensiones o 3 dimensiones, mapas, globos, o modelos construidos a escala de las estructuras tales como puentes o carreteras. Un modelo icónico en realidad se asemeja al modelo de artefacto. Por el contrario, un modelo analógico es una representación funcionalmente equivalente pero incompleta. Es decir, el modelo se comporta como el artefacto físico a pesar de que no puede parecerse físicamente. Ejemplos de modelos analógicos incluyen un avión en miniatura para las pruebas de túnel de viento o una simulación por ordenador de un proceso de fabricación. Finalmente, un modelo simbólico es un mayor nivel de abstracción, donde el modelo se representa usando símbolos tales como ecuaciones. El modelo captura los aspectos relevantes del proceso o sistema en forma simbólica. Los símbolos pueden ser utilizados para aumentar la comprensión del ingeniero del sistema final. Un ejemplo es una ecuación tal como F = ma. Tales modelos matemáticos se pueden utilizar para describir y predecir las propiedades o comportamiento del sistema final o producto. 5.2. Simulación Todos los modelos de simulación son una especificación de la reali- dad. Un tema central en la simulación es abstraer y especifique una adecuada simplificación de la realidad. El desarrollo de esta abstracción es de vital importancia, ya que la mala especificación de la abstracción invalidaría los resultados del ejercicio de simulación. La simulación puede ser utilizado para una variedad de propósitos de prueba. La simulación se clasifican en función del tipo de sistema en estudio. Por lo tanto, la simulación puede ser continua o discreta. En el contexto de la ingeniería de software, se hará hincapié principalmente en la simulación discreta. simulaciones discretas pueden modelar la programación de eventos o interacción proceso. Los principales componentes de un modelo de

este tipo incluyen entidades, actividades y eventos, recursos, el estado del sistema, un reloj de simulación, y un generador de números aleatorios. De salida es generada por la simulación y debe ser analizada.

15-12 Guía SWEBOK® V3.0

Un problema importante en el desarrollo de una simulación discreta es el de inicialización. Antes de una simulación puede ejecutarse, se deben proporcionar los valores iniciales de las variables de estado. Como el diseñador La simulación puede no saber qué valores iniciales son apropiados para las variables de estado, estos valores podrían ser elegidos de manera algo arbitraria. Por ejemplo, podría decidirse que una cola debe ser inicializado tan vacío e inactivo. Tal elección de la condición inicial puede tener un impacto significativo, pero ognized unrec- sobre el resultado de la simulación. 5.3. prototipado La construcción de un prototipo de un sistema es otro proceso de abstracción. En este caso, una versión inicial del sistema se construye, a menudo mientras que el sistema está siendo diseñado. Esto ayuda a los diseñadores a determinar la viabilidad de su diseño. Hay muchos usos para un prototipo, INCLUYENDO la elicitación de requisitos, el diseño y el refinamiento de una interfaz de usuario al sistema, validados dación de los requisitos funcionales, y así sucesivamente. Los objetivos y propósitos para la construcción del prototipo determinarán su construcción y el nivel de abstracción usado. El papel de los prototipos es algo diferente entre los sistemas físicos y de software. Con los sistemas físicos, el prototipo puede ser en realidad la primera versión totalmente funcional de un sistema o puede ser un modelo del sistema. En la ingeniería de software, prototipos son también un modelo abstracto de una parte del software, pero por lo general no se construyen con todos los arquitectónicas su rendimiento óptimo y otras características, calidad esperados en el producto acabado. En cualquier caso, la construcción de prototipos debe tener un propósito claro y ser planificado, supervisado y controlado por ella es una técnica para estudiar un problema específico dentro de un contexto limitado [6 *, c2s8]. En conclusión, el modelado, simulación y totyping pro son técnicas poderosas para el estudio del comportamiento de un sistema desde un punto de vista determinado. Todos pueden ser usados para llevar a cabo los experimentos diseñados para estudiar diversos aspectos del sistema. SIN EMBARGO, éstos son abstracciones y, como tal, no puede modelar todos los atributos de interés.

Fundamentos de ingeniería 15-13

6. normas [5 *, c9s3.2] [13 *, c1s2] Moore afirma que una estándar puede ser; (A) un objeto o medida de comparación que define o representa la magnitud de una unidad; (B) una caracterización que establece niveles de tolerancia admisibles para categorías de artículos; y (c) un grado o nivel de excelencia o el logro requerido. Los estándares son de definición en la naturaleza, estable- cido ya sea a más normas de características o el comportamiento exhibidos comprensión y la interacción o reconocer observado (o deseado). [13 *, p8] Las normas proporcionan los requisitos, las especificaciones, directrices o características que deben ser observadas por los ingenieros para que los productos, pro- cesos y materiales tienen niveles aceptables de calidad. Las cualidades que diversas normas pro-vide pueden ser los de seguridad, fiabilidad, u otras características del producto. Las normas se consideran críticos para los ingenieros y los ingenieros se espera a conocer y utilizar los Standards apropiadas en su disciplina. El cumplimiento o conformidad con una norma permite a una organización dicen al público que ellos (o sus productos) cumplen con los requisitos establecidos en dicha norma. Por lo tanto, las normas se dividen organiza- ciones o de sus productos en los que se ajustan a la norma y los que no lo hacen. Para una norma sea útil, conformidad con la norma debe añadir valor real o percibida al producto, proceso o esfuerzo. Además de los objetivos de la organización, las normas se utilizan para una serie de otros propósitos tales como la protección del comprador, la protección de la empresa, y una mejor definición de los métodos y procedimientos a seguir por la práctica. Las normas también proporcionan a los usuarios una terminología común y las expectativas. Hay muchas organizaciones normativas como la Unión Internacional de Telecomunicaciones (UIT), la Comisión Electrotécnica Internacional (IEC), IEEE, y la Organización Internacional de

regional y gubernamental reconocida organizaciones que generan estándares para esa región o país. Por ejemplo, en los Estados Unidos, hay más de 300 organizaciones que desarrollan Standards. Estos incluyen organizaciones tales como la Normalización (ISO) reconocidas internacionalmente. Además, hay

15-14 GuíaNational SWEBOK® V3.0 American Standards

Institute (ANSI), la Sociedad Americana para Pruebas y Materiales (ASTM), la Sociedad de Ingenieros Automotrices (SAE) y Underwriters Laboratories, Inc. (UL), así como el gobierno de Estados Unidos. Para más detalles sobre los estándares usados en ingeniería de software, consulte el Apéndice B en las normas. Hay una serie de principios de uso común detrás de los estándares. fabricantes de Normas de intentar tener un consenso en torno a sus decisiones. Por lo general hay una apertura dentro de la comunidad de intereses de modo que una vez que una norma se ha establecido, hay una buena probabilidad de que será ampliamente aceptado. La mayoría de las organizaciones de normalización tienen procesos bien definidos por sus esfuerzos y se adhieren a esos procesos con cuidado. Los ingenieros deben estar al tanto de las normas existentes, sino que también deben actualizar su conocimiento de las normas que las normas cambian con el tiempo. En muchos esfuerzos de ingeniería, conocer y comprender las normas aplicables es crítica y la ley puede incluso requerir el uso de normas particulares. En estos casos, las normas menudo REPRESENTA requisitos mínimos que se deben cumplir por el esfuerzo y por lo tanto son un elemento en los straints conimpuestas a cualquier esfuerzo de diseño. El Neer niería debe revisar todas las normas actuales en relación con una tarea dada y determinar que se deben cumplir. Sus diseños deben luego incorporar cualquier y todas las restricciones impuestas por el Dard Estánaplicable. Normas importantes para los ingenieros de software se discuten con más detalle en un apéndice específica- mente sobre este tema. 7. Análisis Causa Raíz [4 *, c5, c3s7, c9s8] [5 *, c9s3, c9s4, c9s5] [13 *, c13s3.4.5] análisis de la causa raíz (RCA) es un proceso diseñado para investigar e identificar cómo y por qué un evento no deseado ha sucedido. causas fundamentales son causas subyacentes. El investigador debe intentar identificar las causas subyacentes específicas del evento que ha ocurrido. El objetivo primario

Fundamentos de ingeniería 15-15

de RCA es para prevenir la recurrencia del evento no deseable. Por lo tanto, cuanto más específico sea el tor investiga- puede ser acerca de por qué se produjo un acontecimiento, más fácil será para prevenir la recurrencia. Una forma común de identificar la causa subyacente específica (s) es hacer una serie de preguntas por qué. 7.1. Las técnicas para la realización de análisis de causa raíz [4 *, c5] [5 *, c3] Hay muchos enfoques utilizados tanto para el control de calidad y análisis de la causa raíz. El primer paso en cualquier esfuerzo de análisis de causa raíz es identificar el problema real. Técnicas tales como la declaración-ción restate-, por qué, por qué diagramas, el método de revisión, estado actual y diagramas de estado deseados, y el enfoque de ojos frescos se utilizan para identificar y perfilar el verdadero problema que debe ser abordado. Una vez que el verdadero problema ha sido identificado, entonces el trabajo puede comenzar a determinar la causa del problema. Ishikawa es conocido por los siete herramientas para el control de calidad que él promovió. Algunas de estas herramientas son útiles en la identificación de las causas para un problema dado. Esas herramientas son hojas de verificación o listas de control, diagramas de Pareto, histogramas, diagramas de comportamiento, diagramas de dispersión, gráficos de control y diagramas de espina de pescado o causa-efecto. Más recientemente, han surgido otros enfoques para la mejoría de la calidad y el análisis de la causa raíz. Algunos ejemplos de estos métodos más nuevos son diagramas de afinidad, diagramas de relaciones, diagramas de árbol, tablas de matriz, de matriz de gráficos de análisis de datos, criteria programa de gráficos sion de proceso, y los diagramas de flecha. Algunas de estas técnicas se describen brevemente a continuación. Un diagrama de espina de pescado o de causa y efecto es una manera de visualizar los diversos factores que afectan a alguna característica. La línea principal en el diagrama representa el problema y las líneas de conexión representan los factores que llevaron a o influenciados el problema. Esos factores se dividen en

subfactores y sub-subfactores hasta fundamentales pueden ser identificados.

causas

15-16 Guía SWEBOK® V3.0

Un enfoque muy simple que es útil en el control de calidad es el uso de una lista de verificación. Las listas de verificación son una lista de los puntos clave en un proceso con las tareas que debe ser completado. A medida que se completa cada tarea, se comprueba fuera de la lista. Si se produce un problema, entonces a veces la lista de verificación puede identificar rápidamente las tareas que pueden haber sido omitidos, o sólo par- cialmente completados. Finalmente, diagramas de relaciones son un medio para dis- relaciones complejas de juego. Dan apoyo visual a causa y efecto pensamiento. El diagrama se refiere el específico a lo general, revelando principales causas y efectos clave. Análisis de causa raíz tiene por objeto prevenir la recurrencia de eventos indeseables. Reducción de la variación debida a causas comunes requiere zación utili- de una serie de técnicas. Un punto importante a destacar es que estas técnicas se deben utilizar fuera de línea y no necesariamente en respuesta directa a la ocurrencia de un evento no deseado. Algunas de las técnicas que pueden utilizarse para reducir la variación, debido a causas comunes se dan a continuación. 1. diagramas de causa y efecto se pueden utilizar para identificar las causas sub y sub-sub. 2. El análisis del árbol de fallos es una técnica que se puede utilizar para entender las fuentes de fallos. 3. experimentos diseñados se pueden usar para sub soportar el impacto de diversas causas de la aparición de acontecimientos adversos (ver Empir- Métodos iCal y técnicas experimentales en este KA). 4. Hay varios tipos de análisis de correlación se pueden utilizar para comprender la relación entre las diversas causas y sus efectos. Estas técnicas se pueden utilizar en los casos en Conducta- experimentos controlados ING es difícil, pero los datos se puede reunir (véase el análi- sis estadístico en este KA).

Fundamentos de ingeniería 15-17

2. Análisis estadístico

c9s1, c10s3 C2S1 c3s6, c3s9, 2.1. Concepto de c4s6, unidad de c6s2, análisis (unidades c7s1, de muestreo), c7s3, Muestra,y c8s1, Población c9s1 2.2. Conceptos c11s2, de correlacióny c11s8 regresión

3. Medición 3.1. Niveles (Scales) de Medición 3.2. Medidas directos y derivados

c3s2

c7s5

P442 -447

Mugirre 2006 [13 *]

c7s5

1.3. Estudio retrospectivo

SommervilLe 2011 [12 *]

JustaLey de 2009 [6 *] točkey 2004 [7 *]

c4s4

De observación Estudiar

cheney y Kincaid 2007 [11 *]

Voland 2003 [5 *]

c3s1, c3s2

c1

McConnell 2004 [10 *]

Kan 2002 [4 *]

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

nully Lobur 2006 [3 *]

Montgomery y Runger 2007 [2 *]

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

3.3. Fiabilidad y Validez

c3s4, c3s5

3.4. Fiabilidad evaluar

c3s5

Mugirre 2006 [13 *]

SommervilLe 2011 [12 *]

cheney y Kincaid 2007 [11 *]

McConnell 2004 [10 *]

JustaLey de 2009 [6 *] točkey 2004 [7 *]

Voland 2003 [5 *]

Kan 2002 [4 *]

nully Lobur 2006 [3 *]

Montgomery y Runger 2007 [2 *]

15-18 Guía SWEBOK® V3.0

c1s2, c1s3, c1s4

4. Diseño de Ingeniería 4.1. Diseño de la Educación en Ingeniería 4.2. El

c1s4, C2S 1, c3s3

diseño como un problema actividad 4.3. Pasosde a resolución seguir en Diseño de Ingeniería

c5s1

c4

5. Modelado, creación de prototipos y simulación 5.1. Modelado

c6

c13s3

c2 S3.1

5.2. Simulación 5.3. prototipado

c5, c3s7, c9s8

S3.2 c9 c9s3, c9s4, c9s5

c5

c3

6. Normas Análisis Causa Raíz 7. 7.1. Las técnicas para la realización de análisis de causa raíz

c1s2 s3.4. 5 c13

Fundamentos de ingeniería 15-19

LECTURAS A. Abran, Software Metrics y software de metrología. [14]

W.G.Vincenti, lo que los ingenieros saber y cómo lo saben. [15]

Este libro ofrece muy buena información sobre el uso correcto de la medida de términos, método de medición y los resultados de medición. Proporciona material de soporte fuerte para toda la sección sobre la medición.

Este libro ofrece una introducción interesante para bases de ingeniería a través de una serie de estudios de casos que muestran muchos de los conceptos fundacionales que se utiliza en aplicaciones de ingeniería del mundo real.

15-20 Guía SWEBOK® V3.0

Referencias [1] ISO / IEC / IEEE 24765: 2010 Sistemas y de Ingeniería de Software-Vocabulario, ISO / IEC / IEEE 2010. [2 *] DC Montgomery y GC Runger, Estadística Aplicada y Probabilidad para Ingenieros, 4ª ed., Wiley, 2007. [3 *] L. y J. nulo Lobur, Lo Esencial de la Organización de Computadores y Arquitectura, 2ª ed., Jones and Bartlett Publishers, 2006. [4 *] SH Kan, métricas y modelos en Ingeniería de Software de Calidad, 2ª ed., AddisonWesley, 2002. [5 *] G. Voland, Ingeniería de Diseño, 2ª ed., Prentice Hall, 2003. [6 *] RE Fairley, gestionar y liderar proyectos de software, Wiley-IEEE Computer Society Press, 2009. [7 *] S. Tockey, el rendimiento de software: maximizar el retorno de su inversión en software, Addison-Wesley, 2004. [8] Consejo Canadiense de Acreditación de Ingeniería, Ingenieros Canadá, “Criterios de Acreditación y Procedimientos”, Consejo Canadiense de Ingenieros, 2011; www. engineerscanada.ca/files/w_Accreditation_ Criteria_Procedures_2011.pdf.

[9] Comisión de Acreditación ABET Ingeniería, “Criterios para la Acreditación de Programas de Ingeniería, 2012-2013” ABET, 2011; www.abet.org/uploadedFiles/ Acreditación / Accreditation_Process / Accreditation_Documents / Corriente / eaccriterios-2012-2013.pdf. [10 *] S. McConnell, código completo, 2ª ed., Microsoft Press, 2004. [11 *] EW Cheney y DR Kincaid, Numéricos Matemáticas y Computación, 6ª ed., Brooks / Cole, 2007. [12 *] I. Sommerville, Ingeniería de Software, 9ª ed., Addison-Wesley, 2011. [13 *] JW Moore, La Hoja de Ruta de Ingeniería de Software: Una guía basada en estándares, Wiley-IEEE Computer Society Press, 2006. [14] A. Abran, Métricas de software y software de metrología, Wiley-IEEE Computer Society Press, 2010. [15] WG Vincenti, lo que los ingenieros saber y cómo ellos lo saben, John Hopkins University Press, 1990.

Fundamentos de ingeniería 15-21

APÉNDICE A Área de conocimiento Descripción Especificaciones INTRODUCCIÓN En este documento se exponen las características de RESPETA a los editores Área de Conocimiento (Editores KA) con respecto a las descripciones Área de Conocimiento (KA) Descripciones de la edición de la versión 3 (V3) de la Guía de la Ingeniería de Software de Administración de Conocimiento (Guía SWEBOK) . Este documento también permitirá a los lectores, revisores y los usuarios a entender claramente lo que las especificaciones fueron utilizados en el desarrollo de esta versión de la Guía SWEBOK. Este documento comienza situando la Guía SWE- BOK como un documento fundamental para el conjunto de la IEEE Computer Society de productos de ingeniería de software y más ampliamente dentro de la comunidad de ingeniería de software en general. Se describe a continuación el papel de la Junta de Control de la línea de base y el Cambio. Criterios y requisitos se definen para las averías de los temas, para la lógica subyacente en las averías y la descripción sucinta de los temas, y para materiales Las alusiones. También se identifican los documentos de entrada importantes, y su papel dentro del proyecto se explica. También se discuten los temas NONCONTENT como las directrices de formato de presentación y estilo. LA GUÍA SWEBOK ES UN DOCUMENTO FUNDAMENTAL PARA LA IEEE Computer Society conjunto de productos de ingeniería de software La Guía SWEBOK es un buque insignia de la IEEE Computer Society y el documento estructural para el conjunto de la IEEE Computer Society de ingeniería de software productos. La Guía SWEBOK es también más

ampliamente reconocido como un documento fundamental dentro de la comunidad de ingeniería de software en

IEEE Computer Society (www.computer.org/portal/web/education/ Los planes de estudio). c) La lista de referencias consolidado (ver Appen- Dix C), es decir, la lista de materiales de referencia recomendados (a nivel de número de sección) que acompaña a la ruptura de los temas dentro de cada KA también es adoptada por la certificación de la ingeniería de software y el desarrollo profesional ciados aso- productos ofrecidos por la IEEE Computer Society.

grande en particular mediante el reconocimiento oficial de la versión 2004 como Informe Técnico ISO / IEC 19759: 2005. Se describe la lista de áreas de conocimiento (KAS) y la descomposición de los temas dentro de cada KA y se detalla en la introducción de esta Guía SWEBOK. En consecuencia, la Guía SWEBOK es fundacional a otras iniciativas dentro de la Sociedad IEEE Com- puter: a) La lista de Kas, y la ruptura de los temas dentro de cada KA también son adoptados por la certificación de la ingeniería de software y productos asociados de desarrollo profesional ofrecido por el IEEE Computer Society (ver www. computer.org/certification). b) La lista de Kas, y la ruptura de ics Toptambién son fundamentales para las pautas de los planes de estudio de ingeniería de software desarrollado o avalados por la

Línea de base y JUNTA DE CONTROL DE CAMBIO Debido a la naturaleza estructural de la Guía SWEBOK y su adopción por otros productos, una línea de base fue desarrollado desde el principio del proyecto formó parte de la lista de Kas, en el desglose de

A-1

UN-2 V3.0

Guía SWEBOK®

temas dentro de cada KA, y la Lista consolidada rencia Ref-. Una Junta de Control de Cambios (CCB) ha estado en vigor durante el desarrollo de esta versión de Han-dle todas las solicitudes de cambio a esta línea de base procedentes de los editores KA, que se produce durante el proceso de revisión, o de otra manera. Las solicitudes de cambio deben ser aprobadas tanto por los Editores Guía SWEBOK y por el CCB antes de su implementación. Este CCB está compuesta por miembros de las iniciativas enumeradas arriba y actuando bajo la autoridad del Software y Sistemas Comité de Ingeniería de la IEEE Computer Society Profesional activi- ata Junta. CRITERIOS Y REQUISITOS PARA LA DISTRIBUCIÓN DE TEMAS EN UN ÁREA DE CONOCIMIENTO a) Editores KA son instruidos para adoptar la ruptura línea de base de temas. b) Se espera que el desglose de los temas a ser “Razonable” y no “perfecto”. c) El desglose de los temas dentro de un KA debe descomponer el subconjunto del Software Ingeniería cuerpo de conocimiento que es “GEN-ralmente reconocido”. Véase más abajo para una discusión más detallada de este punto. d) El desglose de los temas dentro de un KA no debe suponer dominios específicos de la aplicación, las necesidades del negocio, tamaños de organizaciones, estructuras organiza- zational, filosofías de gestión, modelos del ciclo de vida del software, software tecnolo- gías, o métodos de desarrollo de software. e) El desglose de los temas debe, en lo posible, ser compatible con las escuelas variabilidad ous de pensamiento dentro de la ingeniería de software. f) El desglose de los temas dentro de un KA debe ser compatible con el desglose de la ingeniería de software que se encuentra generalmente en indus- tria y en la literatura y las normas de ingeniería de software. g) Se espera que el desglose de los temas a ser lo más inclusivo posible. h) La Guía SWEBOK adopta la postura de que a pesar de que los siguientes “temas” son comunes en todas las áreas de

conocimiento, que son también una parte integral de todo el conocimiento

Las áreas y, por tanto, deben ser incorporados en la propuesta de reparto de los temas de cada área de conocimiento. Estos temas comunes son la medición, la calidad (en gene- ral), y la seguridad. i) El desglose de los temas debe ser a lo sumo dos o tres niveles de profundidad. A pesar de que hay un límite superior o inferior se impone sobre el número de temas dentro de cada KA, se espera que un número razonable y manejable de temas que se incluirán en cada KA. También énfasis debe ser puesto en la selección de los mismos, más que en su organización en una adecuada jerarquía temas. j) nombres de los temas deben ser lo suficientemente importantes como para ser significativa incluso cuando fuera de la citada Guía SWEBOK. k) La descripción de un KA incluirá un gráfico (en forma de árbol) que describe la descomposición conocimiento. CRITERIOS Y REQUISITOS PARA LA DESCRIPCIÓN DE TEMAS Temas sólo necesitan ser descritos suficientemente para que el lector puede seleccionar la referencia adecuada de mate- rial de acuerdo con su / sus necesidades. las descripciones de los temas no deben ser preceptivo. CRITERIOS Y REQUISITOS PARA MATERIAL DE REFERENCIA a) Editores KA son instruidos para usar los las referencias (a nivel de número de sección) asigna- do a su KA por la Lista consolidada de referen- cia como sus referencias recomendadas. b) Hay tres categorías de referencia material: »Referencias recomendados. El conjunto de referencias recomendadas (a nivel de número de sección) se conoce colectivamente como la lista de referencia consolidado. Otras lecturas ». »Referencias adicionales citadas en el KA descripción (por ejemplo, la fuente de un material cita o referencia en apoyo de una razón de ser de

un argumento particular). Apéndice A A-3

UN-4 V3.0

Guía SWEBOK®

c) La Guía SWEBOK está destinado por definición ser selectivo en su elección de los temas y material de referencia asociado. La lista de material de referencia debe ser claramente vista como una “selección informada y razonable” y no como una lista definitiva. d) material de referencia puede ser capítulos de libros, artículos en revistas arbitradas, artículos técnicos referenciados conferencia, arbitrado informes técnicos o industriales, o cualquier otro tipo de reconocido arti- hecho. También se permiten referencias a otro KA, subárea, o tema. e) material de referencia debe ser generalmente dispo- capaz y no debe ser de naturaleza confidencial. f) material de referencia debe estar en Inglés. g) Criterios y requisitos para el material de referencia recomendada o la lista de referencia consolidada: »En conjunto la lista de referencias debe ser recomendados i.

completar: que cubre la totalidad alcance de la Guía SWEBOK ii. suficiente: proporcionar suficiente información para describir “gene- aliado aceptado” conocimiento iii. consistente: no proporcionar los conocimientos contradictorios ni prácticas conflictivos iv. creíble: reconocido como proporcionar tratamiento experto v. actual: tratar el tema de una manera que sea acorde con el conocimiento generalmente aceptado actualmente vi. sucinta: lo más corto posible (tanto en número de unidades de referencia y en el número total de páginas) sin fallar otros objetivos. »Material de referencia recomendados deben ser identificados para cada tema. Cada elemento de referencia

recomiendan especialmente puede cubrir por supuesto múltiples temas. Excepcionalmente, un tema puede ser auto-descriptivo y no cita un artículo de material de referencia (por ejemplo, un tema que es una definición o una materia competencia de la descripción misma sin ningún

material de referencia citado es suficiente para los objetivos de la Guía SWEBOK). »Cada referencia al material de referencia recomendada debe ser tan preciso como sea posible mediante la identificación de cuáles capítulo o sección específica es relevante. »Una matriz de material de referencia (a la nivel de número de sección) frente a los temas debe ser proporcionada. »Una cantidad razonable de recomendada material de referencia debe ser identificado para cada KA. Las siguientes pautas deben ser utilizados en la determinación de cuánto es razonable: i.

ii.

iii.

Si el material de referencia recomendada fueron escritas de manera coheren- que siguió a la propuesta de reparto de temas y en un estilo uniforme (por ejemplo, en un nuevo libro basado en la descripción propuesta KA), un promedio Tar conseguir a través de todos KAs para el número de páginas sería 750. sin embargo, este objetivo no puede ser posible cuando se selecciona el material de referencia existente debido a las diferencias de estilo y la superposición y la redundancia entre los materiales de referencia seleccionados. En otras palabras, el objetivo para el número de páginas para la colección completa de las referencias recomendadas de la Guía SWEBOK está en el rango de 10.000 a 15.000 páginas. Otra forma de ver esto es que la cantidad de material de referencia recomendada sería razonable si consistiera en el material de estudio en este KA para un examen de licencia de ingeniería de software que pasaría un graduado después de

Apéndice completar cuatro añosA A-5de experiencia laboral.

h) material de referencia adicional puede ser incluido por el Editor KA en una lista “Otras lecturas”:

UN-6 V3.0

Guía SWEBOK®

»Estas lecturas adicionales deben estar relacionados con los temas de la descomposición en lugar de, por ejemplo, a temas más avanzados. »La lista debe ser anotado (a menos de 1 párrafo por referencia) de por qué este material de referencia se incluyó en la lista de lecturas adicionales. Lecturas adicionales podrían incluir: nuevas versiones de una referencia existen- tes ya incluidos en las referencias recomendadas, puntos de vista alternativos sobre una KA, o un tratamiento seminal de un KA. »Una pauta general a seguir es 10 o un menor número de lecturas adicionales por KA. »No hay matriz de los materiales de referencia que figuran en lecturas adicionales y la ruptura de temas. i) Criterios y requisitos relativos a las referencias adiciona- les citados en el KA Descripción: »La Guía SWEBOK no es un documento de investigación y su número de lectores será IED Var-. Por lo tanto, un delicado equilibrio debe mantenerse entre la garantía de un alto nivel de legibilidad dentro del documento, manteniendo su lencia tecnológico consolidado. material de referencia adicional, por tanto, sólo debe ser traído por el Editor de KA si es necesario a la discusión. Ejemplos de ello son la identificación de la fuente de una cita o para citar elemento de referencia en apoyo de una lógica detrás de un argumento en particular e importante. estructura común KA descripciones deben utilizar la siguiente

estructura: • acrónimos • Introducción • Desglose de los temas de la KA (incluyendo una figura que describe la descomposición) • Matriz de Temas vs. Material de Referencia • Lista de lecturas recomendadas • referencias

¿QUÉ SIGNIFICA “GENERALMENTE RECONOCIDAS DE CONOCIMIENTO”? La Ingeniería de Software de Administración de Conocimiento es un término inclusivo que describe la suma de conocimientos dentro de la profesión de la ingeniería de software. Sin embargo, la Guía SWEBOK busca identificar y describir ese subconjunto del conjunto de conocimientos que generalmente se reconoce o, en otras palabras, el cuerpo de la base de conocimientos. Para BET ter ilustrar lo que “generalmente reconocido” el conocimiento es en relación con otros tipos de conocimiento, la figura A.1 propone un esquema de tres categorías de clasificación de conocimiento. El Instituto de Gestión de Proyectos en su Guía de los Fundamentos de la Dirección de Proyectos define “generalmente reconocido” el conocimiento de la gestión de proyectos como ser: el subconjunto de la Dirección de Proyectos del conocimiento generalmente reconocido como buenas prácticas. “Generalmente reconocido” significa el conocimiento y las prácticas descritas son aplicables a la mayoría de los proyectos, la mayor parte del tiempo, y no hay consenso sobre su valor y utilidad. “La buena práctica” significa que hay acuerdo general en que la aplicación de estas habilidades, herramientas y técnicas puede mejorar las posibilidades de éxito en una amplia gama de proyectos. “La buena práctica” no significa que el conocimiento descrito siempre deben ser aplicadas de manera uniforme a todos los proyectos; la nización y / o gestión de proyectos orga- equipo es responsable de determinar lo que es apropiado para cualquier proyecto dado. [1] “Generalmente aceptados” conocimiento también se podría ver como el conocimiento que debe incluirse en el material de estudio de un examen de licencia de software de ingeniería (en los EE.UU.) que un graduado tomaría después de completar cuatro años de experiencia laboral. Estas dos definiciones deben ser vistos como complementarios. También se espera que los editores KA a ser un poco hacia el futuro en su interpretación por tak- ing en cuenta no sólo lo que se “reconoce

Apéndice en general”, pero hoy y lo que esperan será A A-7 “generalmente reconocido” en un 3 a 5 años periodo de tiempo.

Guía SWEBOK®

Prácticas especializado que se utiliza sólo para ciertos tipos de software

UN-8 V3.0

Generalmente reconocido Establecidas ticas ticas tradicionales recomendadas por muchas organizaciones

Avanzada e Investigación prácticas innovadoras probados y utilizados solamente por algunas organizaciones y conceptos todavía siendo desarrolladas y probadas en organizaciones La figura A.1. Categorías de Conocimiento de investigación

LONGITUD DE KA DESCRIPCIÓN Las descripciones son KA ser aproximadamente de 10 a 20 páginas utilizando la plantilla de formato para documentos de publi- cado aún en actas de la conferencia de la IEEE Computer Society. Esto incluye texto, las referencias, apéndices, tablas, etc. Esto, por supuesto, no incluye los materiales de referencia mismos. DOCUMENTOS IMPORTANTE

RELACIONADOS

1. Graduado de Ingeniería de Software 2009 (GSwE2009): Lineamientos Curriculares para los programas de título de grado en Ingeniería de Software, 2009; www.gswe2009.org. [2] Este documento “Proporciona directrices y recomenda- ciones” para definir el plan de estudios del programa de nivel de maestría profesional en ingeniería de software. La Guía SWEBOK se identifica como una “referencia primaria” en el desarrollo del conjunto de conocimientos que subyace a estas directrices. Este documento ha sido aprobado oficialmente por el IEEE Computer Society y patrocinada por la Association for Computing Machinery. 2. IEEE Std. 12207-2008 (también conocido como ISO / IEC 12207: 2008) estándar para los sistemas y software de ingeniería en software procesos de ciclo de vida, IEEE, 2008 [3]. Esta norma se considera el estándar clave en cuanto a la definición de procesos de ciclo de

vida y ha sido adoptado por los dos principales organismos de normalización en la ingeniería de software: ISO / IEC JTC 1 / SC7 y la Sociedad IEEE Computer Software

y comités de normas de sistemas de ingeniería. También se ha designado como norma fundamental por el Comité de software y sistema de ingeniería Normaliza- ción (S2ESC) de la IEEE. A pesar de que no tenemos la intención de que la Guía de la ingeniería del cuerpo software del Conocimiento sea plenamente 12207-conformes, esta norma sigue siendo un insumo clave para la Guía SWEBOK, y un cuidado especial será tomada a lo largo de la Guía SWEBOK sobre la compatibilidad de la Guía de la norma 12207. 3. JW Moore, La Hoja de Ruta de Ingeniería de Software: Una guía basada en estándares, Wiley-IEEE Computer Society Press, 2006. [4 *] Este libro describe el alcance, funciones, usos y tendencias de desarrollo de las normas de ingeniería de soft- ware más ampliamente utilizados. Se concentra en las actividades importantes-cali- dad de ingeniería de software y gestión de proyectos, ingeniería de sistemas, confiabilidad y seguridad. El análisis y la reagrupación de las colecciones estándar expone al lector a las relaciones clave entre las normas. A pesar de que la Guía SWEBOK no es un estándar de ingeniería soft- ware per se, la atención especial se tendrá en todo el documento con respecto a la compatibilidad de la Guía con la corriente IEEE y / Sistemas y Software ISO IEC IngeNormas Colección niería. 4. Ingeniería de Software 2004: Lineamientos Curriculares para los programas de licenciatura en Ingeniería de Software, IEEE Computer Society y la Association for Computing Machinery, 2004; http: // sites. computer.org/ccse/SE2004Volume.pdf. [5] Este documento describe las directrices del plan de estudios para una licenciatura en ingeniería de software. La Guía SWEBOK se identifica como “una de las fuentes primarias” en el desarrollo del conjunto de conocimientos que subyace a estas directrices. 5. ISO / IEC / IEEE 24765: 2010 Sistemas y de Ingeniería de Software-Vocabulario, ISO / IEC / IEEE, 2010; www.computer.org/ sevocab. [6]

Apéndice A A-9

UN-10 V3.0

Guía SWEBOK®

La jerarquía de referencia para la terminología es Diccionario Colegiado de Merriam Webster (11 ed.) [7], IEEE / ISO / IEC 24765 [6], y el nuevo pro- puesto definiciones si es necesario. 6. “Certificación y Capacitación para Profesionales de software,” IEEE Computer Society, 2013; www.computer.org/certification. [8] Información sobre la certificación y productos de desarrollo profesional asociados desarrollados y ofrecidos por la IEEE Computer Society para los profesionales en el campo de la ingeniería de software se puede encontrar en este sitio web. La Guía SWEBOK es fundamental para estos productos. Estilo y las Directrices Técnicas • Las descripciones KA deben ajustarse a la plantilla de Word disponible en www.computer. org / portal / web / cscps / formato. • Se espera Descripción KA seguir la guía de estilo IEEE Computer Society (www. computer.org/portal/web/publications/ guía de estilo). • Los archivos son para ser presentadas en Microsoft Word formato. • Todas las citas de material de referencia han de ser producido utilizando EndNote Web como se indica en las instrucciones proporcionadas a los editores KA en este sentido. OTROS directrices detalladas Al hacer referencia a la Guía para la Ingeniería de Software de Administración de Conocimiento, utilizar el título de “Guía SWEBOK.” A los efectos de simplicidad, evitar las notas al pie y tratar de incluir su contenido en el texto principal. Utilizar referencias explícitas a las normas, en contraposición a la simple introducción de los números que hacen referencia a los elementos de

la bibliografía. Creemos que este enfoque permite al lector a ser mejor expuesta a la fuente y el alcance de una norma. Las figuras y tablas que se acompañan de texto deben explicarse por sí mismo o tener suficiente texto relacionado. Esto garantizaría que el lector sabe lo que las figuras y tablas significan. A asegúrese de que alguna información en la Guía de SWEBOK no se convierta rápidamente lete obso- y debido a su carácter genérico, por favor evite nombrar directamente herramientas y productos. En su lugar, tratar de nombrar sus funciones. EDICIÓN Los editores de la Guía SWEBOK así como profesiones correctores sionales editarán Descripción KA. La edición incluye edición de textos (gramática, tuation pun-, y las mayúsculas), edición de estilo (confor- Mance el libro de estilo Computer Society), y la edición de contenidos (flujo, es decir, la claridad, Ness directa-, y la organización). La edición final será un proceso de colaboración en el que los editores de la Guía SWEBOK y el KA Editores trabajar juntos para lograr una concisa, bien redactado-y útil KA Descripción. DIVULGACIÓN DE AUTOR Todos los derechos de propiedad intelectual asociados con la Guía SWEBOK permanecerán con el estándar IEEE. Editores KA deben firmar un formulario de autorización de derechos de autor. También se entiende que la Guía SWEBOK seguirá siendo disponible de forma gratuita en el dominio público en al menos un formato, proporcionado por la IEEE Computer Society través de la web tecnolo- gía o por otros medios. Para más información, ver www.computer.org/ copyright.htm.

Apéndice A A-11

Referencias [1] Instituto de Gestión de Proyectos, una guía para la Dirección de Proyectos del Conocimiento (PMBOK (R) Guía), 5ª ed., Project Management Institute, 2013. [2] Integrado de Software e Ingeniería de Sistemas Curriculum (ISSEC) Proyecto, graduado de Ingeniería de Software 2009 (GSwE2009): Lineamientos Curriculares para programas de postgrado en Ingeniería de Software, Stevens Institute of Technology, 2009; www.gswe2009.org. [3] IEEE Std. 12207-2008 (también conocido como ISO / IEC 12207: 2008) estándar para los sistemas y procesos de ciclo de vida del software Ingeniería de Software, IEEE 2008. [4 *] JW Moore, La Hoja de Ruta de Ingeniería de Software: Una guía basada en estándares, Wiley-IEEE Computer Society Press, 2006.

[5] Grupo de Trabajo Conjunto sobre Computación planes de estudio, IEEE Computer Society y la Association for Computing Machinery, Ingeniería de Software 2004: Directrices Curriculares para Pregrado Programas de Grado en Ingeniería de Software, 2004; http: // sites. computer.org/ccse/SE2004Volume.pdf. [6] ISO / IEC / IEEE 24765: 2010 Sistemas y de Ingeniería de Software-Vocabulario, ISO / IEC / IEEE 2010. [7] Diccionario Colegiado de Merriam-Webster, ed 11., 2003. [8] IEEE Computer Society, “Certificación y Capacitación para Profesionales de software”, 2013; www.computer.org/certification.

UN-12 V3.0

Guía SWEBOK®

APÉNDICE B IEEE e ISO / IEC NORMAS soportar el cuerpo SOFTWARE INGENIERÍA DE CONOCIMIENTO (SWEBOK) Algunos podrían decir que el suministro de normas niería de software niería supera con creces la demanda. Rara vez se escucha una conferencia sobre el tema sin sufrir alguna broma aparentemente obligatoria que hay demasiados de ellos. Sin embargo, la existencia de normas tiene una muy grande (posiblemente infinita) de espacio comercial de alternativas y reduce ese espacio para un conjunto más pequeño de opciones, una gran ventaja para los usuarios. Sin embargo, todavía puede ser difícil elegir entre docenas de alternativas, por lo que una orientación complementaria, como este apéndice, puede ser útil. Una lista resumida de las normas citadas en este apéndice aparece al final. A reducir el tedio en la lectura, algunas simplificaciones y compendios se hacen en este apéndice: • ISO / IEC JTC 1 / SC 7 mantiene casi doscientos normas sobre la materia. IEEE mantiene unos cincuenta años. Las dos organizaciones están en el décimo año de un programa sistemático para coordinar e integrar sus colecciones. En general, este artículo se centrará en los Standards que son reconocidos por ambas organiza- ciones, teniendo esta condición como prueba de que se ha obtenido un amplio consenso. Otras normas serán mencionados brevemente. • Normas tienden a tener títulos largos, taxonómicas. Si hubiera un único estándar para la construcción de un automóvil, el uno para su Camry probablemente se titula algo así como “vehículo de combustión interna, de cuatro ruedas, pasajeros, sedán.” Además, las organizaciones de estándares modernos proporcionan a sus estándares de

bases de datos . Como cualquier base de datos, estos contienen a veces errores, sobre todo para los títulos. Así que este artículo menudo parafraseará la

el IEEE coloca una marca en todas sus denominaciones normalizadores.

título de la norma o simplemente utilizar su número. En la obtención de un nivel de interés, el lector debe basarse en el número, no el título, dada en este artículo. Por razones de coherencia, el artículo va a utilizar la convención del IEEE para la capitalización de títulos sustantivos, pronombres, adjetivos, verbos, adverbios y primera y última palabra tiene una letra, a pesar de capital inicial el hecho de que IEEE e ISO / IEC uso diferente convenciones. • Debido a que estas normas están siendo aliado continua- revisarse para tener en cuenta las nuevas tecnolo- gías y patrones de uso, este artículo será obsoleta antes de su publicación. Por lo tanto, de vez en cuando discuten las normas que aún no han sido publicados, si existe la posibilidad de asumir una importancia significativa. • marcas explícitas se omiten. Baste decir que

Hay algunos otros convenios de interés: • En tanto IEEE e ISO / IEC, las normas para la ingeniería de sistemas son mantenidos por el mismo comité que para la ingeniería de software. Muchas de las normas se aplican a ambos. Así, en lugar de hacer distinciones sutiles, este artículo va a tratar con ambos. • Por otro lado, tanto S2ESC y SC 7 (ver más abajo para una descripción de estas organiza- ciones) son responsables de las normas que no califican como “ingeniería”. En los EE.UU. y muchos otros países, los servicios de un ingeniero con licencia son requiere cuando un producto puede afectar a la seguridad pública, la salud, B-1

SEGUNDO-2 Guía SWEBOK® V3.0

y el bienestar en lugar de afectar únicamente el bolsillo del cliente. En este apéndice se respetará esa distinción e ignorar Standards que parecen ser meramente económica en consecuencia. • documentación del usuario se supone que es de- sarrollados de forma similar al software. Por ejemplo, un estándar en relación con el diseño de la documentación del usuario se describe en el software de diseño KA. • Algunas normas elaboradas conjuntamente se explic- tamente etiquetados como desarrollos conjuntos, por ejemplo, ISO / IEC / IEEE 24765. En otros casos, las normas tienen diferentes denominaciones en las dos organizaciones. Ejemplos incluyen »IEEE Std. 12207: 2008 (también conocido como ISO / IEC 12207: 2008), donde “alias” ( “también conocido como”) es abreviatura ción de este apéndice para señalar la designación en la otra organización; »IEEE Std. 15939: 2008 adopción Estándar ción de la norma ISO / IEC 15939: 2007, la adop- ción por IEEE de un estándar desarrollado en la norma ISO / IEC; »IEEE Std. 1220: 2005 (también conocido como ISO / IEC 26702: 2007), una “vía rápida” por la norma ISO / IEC de un estándar desarrollado en el estándar IEEE. En cada uno de estos casos, las normas son sustancialmente idénticos en las dos organiza- ciones, que sólo difieren en la materia frente y, en ocasiones, agregó material informativo. Se proporciona una lista de resumen de todos los Standards mencionados al final de este apéndice. ISO / IEC JTC 1 / SC 7, software y sistemas INGENIERÍA ISO / IEC JTC 1 / SC 7 es la principal fuente de las normas internacionales sobre el software e ingeniería de sistemas. Su nombre está formado taxonómicamente. Comité Técnico Conjunto 1

(JTC 1) es un niño de la Organización Internacional para la estandarización (ISO) y la Comisión Electrotécnica Internacional (IEC); tiene el alcance de la “tecnología de información” y subdivida su trabajo entre varios subcomités; Subcomité 7 (SC

7) es el responsable de software y siste- mas de ingeniería. SC 7, y sus grupos de trabajo, se reúne dos veces al año, atrayendo delegaciones represen- tando los organismos nacionales de normalización de los países partici- pantes. Cada país sigue su propio procedi- mientos para determinar las posiciones nacionales y cada nación tiene la responsabilidad de determinar si existe una norma ISO / IEC debería ser adoptado como norma nacional. SC 7 crea tres tipos de documentos: • Normas internacionales: Los documentos, con tener requisitos que deben cumplirse con el fin de exigir la conformidad. • Especificaciones técnicas (anteriormente llamados informes técnicos, tipo 1 y tipo 2): docu- mentos publicados en forma preliminar mientras que el trabajo continúa. • Informes Técnicos (anteriormente llamados Informes Técnicos, tipo 3): Los documentos inherentemente inadecuadas para ser estándares, por lo general debido a que son más descriptiva que prescriptiva. La clave para recordar es que sólo la primera categoría cuenta como una norma de consenso. El lector puede reconocer fácilmente a los demás por el TS sufijo o TR antepone al número del documento. IEEE SOFTWARE Y SISTEMAS DE INGENIERÍA Comité de Normas (S2ESC) IEEE es la mayor organización mundial de profesionales gías Nical, con cerca de 400.000 miembros en más de 160 países. La publicación de normas se lleva a cabo por la Asociación de Estándares IEEE (IEEE-SA), pero los comités que redactan y patrocinan las normas se encuentran en las distintas sociedades del IEEE; S2ESC es una parte de la Sociedad IEEE orde- nador. IEEE es un fabricante de normas global porque sus estándares se utilizan en muchos países diferentes. A pesar de su La membresía internacional (alrededor del 50% fuera de Estados Unidos), sin embargo, el IEEE-SA somete habitualmente a sus estándares de la American National Standards Institute (ANSI) para Endorsement como “American National Standards.” Algunos se desarrollan las normas S2ESC dentro S2ESC, algunos se elabora conjuntamente con el SC 7, y algunos son adoptados después de ser desarrollado por

Carolina del Sur 7.

Apéndice B B-3

SEGUNDO-4 Guía SWEBOK® V3.0

IEEE-SA publica tres tipos de “normas”: • Normas, con una preponderancia del verbo "deberá" • Métodos recomendados, con una preponderancia del verbo “debería” • Guías, con una preponderancia de la palabra “podrá”. Los tres de estos comparan con Dardos ISO / IEC Están-. IEEE-SA tiene el concepto de un “uso juicio-” estándar, que es más o menos comparable a la norma ISO / IEC Especificación Técnica. Sin embargo, no tiene nada comparable a un Informe de cal ISO / IEC Técnicamente; se buscaría en otro lugar IEEE para los documentos de esta calaña. LOS ESTANDARES El resto de este artículo asigna los estándares seleccionados a áreas de conocimiento relevantes (KAS) de la guía SWEBOK. Hay una sección para cada KA. Dentro de cada sección, las normas pertinentes son los que se aplican principalmente a la KA, así como otros que se aplica principalmente a otra KAs sino que también están relacionados con el alquiler de un Cur- los enumerados. Después de cada estándar es un breve resu- men. En la mayoría de los casos, el resumen es una cita o paráfrasis del material introductorio abstracto o otra del texto de la norma. La mayor parte de las normas caber fácilmente en un solo KA. Algunos encajan en más de uno; en tales casos, se proporciona una referencia cruzada. Dos normas se aplican a todos los Kas, por lo que se enumeran en una categoría

para cualquiera de las categorías del IEEE. En la norma ISO / IEC, se trata de un “informe técnico” -definido como un documento inherentemente inadecuado para ser un estándar. La Guía SWEBOK IEEE 2004 fue adoptado por la ISO / IEC con- cabo el cambio. Presumiblemente, la norma ISO / IEC adoptará Ver- sión 3 de la Guía SWEBOK.

ISO / IEC TR 19759: 2005 Guía de IngenieríaSoftware para la Ingeniería de Software de Administración de Conocimiento (SWEBOK)

Se aplica a todos los KAs ISO / IEC 19759: 2005, una Guía de la Ingeniería de Software de Administración de Conocimiento (SWEBOK), identifica y describe ese subconjunto del conjunto de conocimientos que es generalmente aceptado, a pesar de que los ingenieros de software deben ser capaces no sólo de conocimientos en ingeniería de software, sino también, por supuesto, en otras disciplinas relacionadas. SWEBOK es un término inclusivo que describe la suma de conocimientos dentro de la profesión de la ingeniería de software.

El texto de la Guía SWEBOK está dispolibremente al poder www.swebok.org/. La adopción de ISO / IEC de la Guía está disponible gratuitamente en http: // estándares. iso.org/ittf/PubliclyAvailableStandards/index. html. ISO / IEC / IEEE 24765 proporciona una ulary vocab- compartido para los sistemas y normas de ingeniería de software, tanto de SC 7 y S2ESC. llamado “General”. Todos los estándares relacionados a ingeniería (CASE), herramientas y entornos de software asistida por ordenador se enumeran en los modelos de ingeniería de software y métodos sección KA. GENERAL Los dos primeros niveles son tan importantes que podrían ser ranurados en toda la KAS. Dos más están descritas en el Proceso de Ingeniería de Software KA, pero se mencionan aquí, ya que proporcionan un marco útil y porque las

descripciones de varias otras normas se refieren a ellos. ISO / IEC TR 19759 es la Guía SWEBOK sí. No es un estándar IEEE porque, a falta de verbos prescriptivos, que no satisface los criterios

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

Se aplica a todos los KAs ISO / IEC / IEEE 24765: 2010 proporciona un vocabulario común aplicable a todos los sistemas y obras de ingeniería de software. Fue preparado para recoger y apoyar a la normalización de la terminología. ISO / IEC / IEEE 24765: 2010 está destinado a servir como una referencia útil para aquellos en el campo de la información tecno- logía y para fomentar el uso de los sistemas y estándares de ingeniería de software preparados por la ISO y organizaciones de enlace IEEE Computer Society y el Instituto de Gestión de Proyectos. ISO / IEC / IEEE 24765: 2010 incluye referencias a la

Apéndice B B-5

SEGUNDO-6 Guía SWEBOK® V3.0

normas de origen activos para cada definición de manera que el uso de la expresión puede ser analizada más.

El vocabulario es descriptiva, en lugar de prescriptivo; que recoge todas las definiciones de todas las normas pertinentes, así como algunas otras fuentes, en lugar de elegir entre las definiciones que compiten entre sí. El contenido de la norma 24765 es de libre acceso en línea en www.computer.org/sevocab. Dos estándares, 12207 y 15288, proporcionan un conjunto completo de procesos de todo el ciclo de vida de un sistema o de un producto de software. Los dos Standards están alineadas para su uso simultáneo en un solo proyecto o en una sola organización. Se mencionan aquí porque se utilizan a menudo como un marco para explicar o localizar el papel de otras normas en el ciclo de vida.

Se define la construcción de un buen requisito, proporciona atributos y características de los requisitos, y discute la aplicación iterativa y recursiva de los procesos de requisitos pasantes a cabo el ciclo de vida. ISO / IEC / IEEE 29148: 2011 proporciona orientación adicional en la aplicación de los procesos de requisitos de ingeniería y gestión de las actividades de los requisitos relacionados en la norma ISO / IEC 12207: 2008 e ISO / IEC 15288: 2008. Los elementos de información aplicables a la ingeniería de requisitos y su contenido están definidos. El contenido de la norma ISO / IEC / IEEE 29148: 2011 puede ser añadido al conjunto existente de los procesos del ciclo de vida relacionada REQUISITOS definidos por la norma ISO / IEC 12207: 2008 o ISO / IEC 15288: 2008, o puede ser utilizado de forma independiente.

Una norma ISO / IEC multiparte proporciona prin- cipios y métodos para el software “apresto”, basada en sus requisitos. El tamaño funcional es a menudo

utilizarIEEE Std. 12207-2008 (también conocido como ISO / IEC 12207: 2008) Estándar para los sistemas y el software Ingeniería- Software Procesos del ciclo de vida

Consulte Software Ingeniería de Procesos KA

ful en el denominador de las mediciones de calidad y la productividad en el desarrollo de software. También puede desempeñar un papel en la contratación de los acuerdos de nivel de servicio.

IEEE Std. 15288-2008 (también conocido como ISO / IEC15288: 2008) Estándar para los sistemas y el software Ingeniería- vida del sistema los procesos de ciclo

Consulte Software Ingeniería de Procesos KA

REQUISITOS DE SOFTWARE La norma principal para la ingeniería de requisitos de software y sistemas es una nueva que sustituye varios estándares IEEE existentes. Se pro- porciona una visión amplia de la ingeniería de requisitos a través de todo el ciclo de vida.

ISO / IEC 14143 [seis partes] Información Techgía-funcional de software de medición-Medida del tamaño

ISO / IEC 14143 describe FSM (medida del tamaño funcional). Los conceptosde la medición de tamaño funcional (FSM) están diseñados para superar las limitaciones de los métodos anteriores de dimensionamiento software desplazando el foco lejos de la medición de cómo el software se implementa para medir el tamaño en términos de las funciones requeridas por el usuario. Ingeniería de Requisitos

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

ISO / IEC / IEEE 29148: 2011 contiene

disposiciones para los procesos y los productos relacionados con la inge- niería de requisitos para los sistemas y productos de software y servicios a lo largo del ciclo de vida.

Apéndice B B-7

FSM es a menudo conocido como “punto de la función de cuenta.” Las cuatro normas que figuran a continuación son métodos alternativas para poder punto de la función de cuenta, todo cumplir con los requisitos de la norma ISO / IEC 14143. El método dominante, en términos de cuota de mercado, es el método IFPUG, que se describe en la norma ISO / IEC 20926. Otros métodos están destinados variaciones para mejorar la validez de la cuenta en diversas circunstancias. Por ejemplo, ISO / IEC 19761cósmico es

SEGUNDO-8 Guía SWEBOK® V3.0

sobre todo destinados a ser utilizados en el software con una componente en tiempo real.

DISEÑO DE SOFTWARE El diseño del software KA incluye tanto software diseño arquitectónico (para la determinación del

relaciónISO / IEC 19761: 2011 Ingeniería de SoftwareCOS MIC: Un Tamaño Funcional Método de medición ISO / IEC 20926: 2009 Software y Sistemas de Inge- niería-Software-Medición IFPUG fun- cional Método de Medición del Tamaño ISO IEC 20968/2002: Manual de Prácticas de Análisis de Puntos de Función de conteo de Ingeniería de Software-MK II ISO / IEC 24570: 2005 Software IngenieríaNESMA funcional Tamaño sión Método de medición Ver- 2.1-Definiciones y Lineamientos contando para la Aplicación del Análisis de Puntos de Función

A veces requisitos se describen en lenguaje natu- ral, pero a veces se describen en las notaciones formales o semiformales. El objetivo de Unified Modeling Language (UML) es proporcionar a los arquitectos de sistemas, ingenieros de software y desarrolladores de software con herramientas para el análisis, diseño e implementación de sistemas basados en software, así como para el modelado de negocios y procesos similares. Las dos partes de la norma ISO / IEC 19505 definen UML, revisión 2. La mayor ISO / IEC 19501 es una versión anterior de UML. Se mencionan aquí porque a menudo se utilizan para modelar los requisitos.

ISO / IEC 19501: 2005 Información Tecnología distribuido abierto Modeling Language (UML) Versión 1.4.2 Procesamiento-Unificado

Ver Modelos de Ingeniería de Software y métodos KA ISO / IEC 19505: 2012 [dos partes] Grupo de Gestión de la Información Tech- nology-Objeto Unificado Modelo- ing Language (UML del OMG)

barcos entre los elementos del software y el diseño detallado (para la descripción de los elementos individuales). ISO / IEC / IEEE 42010 se refiere a la descripción de la arquitectura de sistemas y software.

ISO / IEC / IEEE 42010: 2011 Sistemas y Software de Ingeniería-Arquitectura Descripción

ISO / IEC / IEEE 42010: 2011 se refiere a la crea- ción, el análisis, y el mantenimiento de arquitecturas de sistemas mediante el uso de las descripciones de la arquitectura. Se establece un modelo conceptual de la descripción de la arquitectura. Los contenidos requeridos de una descripción de la arquitectura se especifican. puntos de vista arqui- tectura, los marcos de arquitectura y descripción de la arquitectura idiomas se introducen para la codificación de convenciones y prácticas comunes de la descripción de la arquitectura. El contenido requerido de puntos de vista de la arquitectura, la arquitectura marco funciona y descripción de la arquitectura idiomas se especifica. Anexos proporcionan la motivación y los antecedentes de los principales conceptos y terminología gía y ejemplos de aplicación de la norma ISO / IEC / IEEE 42010: 2011.

Al igual que la norma ISO / IEC / IEEE 42010, el siguiente Stan- dard trata de software “diseño” como una abstracción, independiente de su representación en un documento. En consecuencia, la norma coloca disposiciones sobre la descripción del diseño, en lugar de en diseño Ver Modelos de Ingeniería de Software y métodos KA

Apéndice B B-9

sí mismo. IEEE Std. 1016-2009 estándar para descripciones Diseño Tecnología de Información-Sistemas-Diseño de Software

las la

Esta norma describe los diseños de software y establece el contenido de la información y la organiza- ción de una descripción de diseño de software (SDD). Un SDD es una representación de un diseño de software que se utiliza para registrar la información de diseño y com- carse que la información de diseño de diseño de la llave

SEGUNDO-10 Guía SWEBOK® V3.0

grupos de interés. Esta norma está destinada para su uso en situaciones de cálculo en la que una descripción explícita de diseño de software es estar preparado. Estas situaciones incluyen actividades tradicionales de construcción de software (cuando el diseño conduce a código) y situaciones de ingeniería inversa (cuando una descripción del diseño se recupera de una implementación existente). Esta norma se puede aplicar a, cien- cien- comercial, militar o el software que se ejecuta en los ordenadores digitales. Aplicabilidad no está limitado por el tamaño, la complejidad o criticidad del software. Esta norma puede ser aplicado a la descripción de alto nivel y diseños detallados. Este Dard Están- no prescribe metodologías específicas para el diseño, gestión de la configuración, o la garantía de cali- dad. Esta norma no requiere el uso de cualquier lenguaje de diseño particulares, pero esta- lishes requisitos en la selección de lenguajes de diseño para su uso en un SDD. Esta norma se puede aplicar a la preparación de los agentes de valores capturados como documentos en papel, bases de datos automatizadas, herramientas de desarrollo de software, u otros medios de comunicación.

norma es aplicable a la documentación del usuario para los sistemas de hardware incluyendo también.

CONSTRUCCIÓN DEL SOFTWARE El término “construcción de software” se refiere a la creación detallada de software de trabajo, significativa a través de una combinación de codificación, verificación, la unidad de pruebas, las pruebas de integración, y la depuración. Hay pocas normas sobre los detalles de la codificación de soft- ware. Se ha encontrado a través de (en su mayoría mala) experiencia de que las convenciones de codificación no son apropiados para la estandarización, ya que, en la mayoría de los casos, el beneficio real viene de la consistencia de la aplicación de una convención arbitraria en lugar de la propia convención. Así, a pesar de las convenciones de codificación son una buena idea, en general se deja a la organización o el proyecto para desarrollar un estándar tales. Sin embargo, el tema de la codificación segura ha atraído la atención en los últimos años debido a que algunos lenguajes de codificación son inseguros en la cara de ataque. Un informe técnico preparado por la norma ISO / IEC JTC 1 / SC 22 (lenguajes de programación) describe nerabilities vul- en lenguajes de programación y cómo se puede evitar.

Por convención, este apéndice trata usuario docu- mentación como parte de un sistema de software. Por lo tanto, los diversos aspectos de usuario Documentación- su diseño, su prueba, y así sucesivamente-se asignan a diferentes KAs. Los próximos Norma se ocupe deel diseño de la documentación del usuario.

través IEEE Std. 26514-2010 La adopción del estándar ISO / IEC 26514: 2008 Sistemas y ingeniería de software-Requisitos para los diseñadores y desarrolladores de documentación del usuario

Esta norma establece los requisitos para el diseño y desarrollo de software de usuario documentación como parte de los procesos del ciclo de vida. Define el proceso de documentación desde el punto de la promotora documentación vista- y también cubre el producto documentación. En él se especifica la estructura, contenido y formato de los documentos del

ISO / IEC TR 24772: 2013 Tecnología de Información Lenguajes de ProgramaciónOrientación a Evitar vulnerabilidades en lenguajes de programación a

usuario y también proporciona una guía informativa para el estilo de documentación del usuario. Es independiente de las herramientas de software que pueden ser utilizados para producir la documentación y se aplica tanto a la documentación impresa y la documentación en pantalla. Gran parte de esta

Selección de idioma y Uso

ISO / IEC TR 24772: 2013 especifica el software pro vulnerabilidades idioma programa- que deben evitarse en el desarrollo de sistemas en los que se requiere un comportamiento seguro para la seguridad, la seguridad, la mis- sion-crítico, y el software crítico para el negocio. En general, esta guía es aplicable al soft- ware desarrollado, revisado, o mantenido para cualquier aplicación. Las vulnerabilidades se describen en un hombre-ner genérico que se aplica a una amplia gama de lenguajes de programación. Anexos se refieren la orientación genérica a una selección de lenguajes de programación específicos.

Apéndice B B-11

SEGUNDO-12 Guía SWEBOK® V3.0

El Informe Técnico está disponible gratuitamente en http: // standards.iso.org/ittf/PubliclyAvailableStandards/ index.html. Dos Se mencionan las normas aquí porque la unidad de pruebas es a menudo considerado como una actividad de software construcción. IEEE e ISO / IEC soncooperar en el desarrollo de una norma conjunta de cuatro partes, 29119, que proporcionará un tratamiento integral de la prueba y suplantar IEEE Std. 1008.

PRUEBAS DE SOFTWARE Curiosamente, hay pocos estándares para las pruebas. IEEE Std. 829 es el más completo.

IEEE Std. 829-2008 estándar para el software y Sys tem Documentación de la comprobación

procesos de prueba a determinar si el DesaMent productos de una determinada actividad se

ajustan a el IEEE Std. 1008-1987 estándar para el software de pruebas unitarias

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

Consulte Software Testing KA

La siguiente norma prevé la elaboración de la documentación de usuario durante un proceso de desarrollo ágil. Se menciona aquí porque el desarrollo ágil es a veces considerado como la construcción.

ISO / IEC / IEEE 26515: 2012 Sistemas y de Ingeniería de Software-El desarrollo de documentación del usuario en un entorno ágil

Ver Modelos de Ingeniería de Software y métodos KA

Codificación no es la única manera de crear un producto de software. A menudo código (así como los requisitos y diseño) se vuelve a utilizar en proyectos anteriores o Engineers neered para su reutilización en proyectos futuros. IEEE Std. 1517 se menciona aquí, ya que proporciona un marco común para la ampliación de los procesos del ciclo de vida del sistema y software de IEEE Std. 12207: 2008 para incluir la práctica sistemática de la reutilización.

requisitos de esa actividad y si el tem y / o software sis- satisface sus necesidades de uso y de usuarios previstos. tareas de proceso de pruebas se especifican para diferentes niveles de integridad. Estas tareas de proceso determinan la amplitud y la profundidad adecuada de la documentación de prueba. Los elementos de documentación para cada tipo de documentación de prueba a continuación, pueden ser seleccionados. El alcance de las pruebas abarca sistemas basados en software, software, hardware, cerámica y sus interfaces. Esta norma se aplica a los sistemas basados en software a desarrollar, mantener, o reutilizados (herencia, comerciales off-the-shelf, artículos nondevelopmental). El término “software” también incluye el firmware, microcódigo, y documentación. procesos de prueba pueden incluir inspección, análisis, demostración, verificación, y validación de software y software basado en productos del sistema.

IEEE Std. 1008 se centra en las pruebas unitarias.

IEEE Std. 1008-1987 estándar para el software de pruebas unitarias

El objetivo principal es especificar un método estándar para la unidad de pruebas de software que puede ser utilizado como base para el software de sonido Engineer- ing práctica. Un segundo objetivo es describir los conceptos de ingeniería de software y los supuestos de prueba en la que el enfoque estándar es

Apéndice B B-13 basado. Un tercer objetivo es proporcionar

dirección IEEE Std. 1517-2010 estándar para la tecnología de la información del sistema y del software-Vida Procesos de reutilización de procesos de ciclo

Consulte Software Ingeniería de Procesos KA

y la información de recursos para ayudar con la puesta en imple- y el uso del enfoque de la unidad de pruebas estándar.

SEGUNDO-14 Guía SWEBOK® V3.0

IEEE e ISO / IEC JTC 1 / SC 7 están En él se especifica procesos para su uso en cooperando en un proyecto para desarrollar una pruebas y revisión de la documentación del única norma global que cubre todos los aspectos usuario. No se limita- das a la fase de prueba y de las pruebas. Uno puede esperar la publicación revisión del ciclo de vida, sino que incluye de la norma de cuatro partes para el año 2014. actividades durante los procesos de gestión de Las porciones del contenido siendo información y de gestión de la documentación. controversial. Una cuestión es si taxonómico “métodos estáticos” -tales como la inspección, revisión y análisis de estática-deben encontrarse Dos Se mencionan las normas aquí porque dentro del alcance de la “ing Ensayos” o deben algunas fuentes consideran la verificación y ser distinguido como “verificación y validación de software que se incluyen en las validación.” A pesar de que la resolución de la pruebas taxonómicamente. cuestión es, probablemente, de poca importancia para los usuarios de la norma, asume una gran importancia a la en estándares escritores que deben gestionar una integrado El conjunto de normas interoperar.

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

El propósito de la norma ISO / IEC 29119 Software Testing es definir un estándar internacionalmente aceptado para las pruebas de software que puede ser utilizado por cualquier organiza- ción al realizar cualquier tipo de pruebas de software.

IEEE Std. 1012-2012 estándar para el sistema y SoftArtículos de Verificación y Validación

Ver la calidad del software KA IEEE Std. 1044-2009 norma para la clasificación de Las anomalías de software

Ver la calidad del software KA

MANTENIMIENTO DEL SOFTWARE Este estándar el resultado de la armonización de distintos estándares IEEE e ISO / IEC en el sujeto-describe un proceso integral para la gestión y ejecución de software de mantenimiento. Se expande en lo dispuesto en el proceso de mantenimiento de soft- ware previsto en la norma ISO / IEC / IEEE 12207.

Las pruebas de la documentación del usuario se describe en el próximo estándar, proporcionando requisitos para el examen y revisión de la documentación de usuario del software como parte de los procesos del ciclo de vida. Define el proceso de documentación del punto de vista del probador de documentación y revisor. Es relevante a los roles que participan en pruebas y desarrollo de software y documentación del usuario, incluyendo proyec- gestores ect, expertos en usabilidad y desarrolladores de información adicionales a los probadores y colaboradores.

IEEE Std. 14764-2006 (también conocido como ISO / IEC 14764: 2006) Estándar de Ciclo de Vida del Software Ingeniería de Software-Procesos-Mantenimiento

ISO / IEC14764: 2006describesingreater IEEE Std. 26513-2010 La adopción del estándar ISO / IEC 26513: 2009 Sistemas y ingeniería de software-Requisitos para Probadores y revisores de Documentación

ISO / IEC 26513 proporciona las exigencias mínimas para la comprobación y revisión de usuario docu- mentación, incluyendo tanto

documentos impresos y en pantalla se utilizan en el entorno de trabajo de los usuarios del software de sistemas. Se aplica a los manuales impresos de usuario, ayuda en línea, tutoriales y documentación Las alusiones usuario.

Apéndice gestión detalle del proceso de mantenimiento se B B-15 describe en ISO / IEC 12207, incluyendo tos modifica-. También establece las definiciones de los tipos ous variabilidad de mantenimiento. ISO / IEC 14764: 2006 proporciona orientación que se aplica a la planificación, eje- cución y control, revisión y evaluación, y el cierre del proceso de mantenimiento. El alcance de la norma ISO / IEC 14764: 2006 incluye el mantenimiento de múltiples productos de software con los mismos recursos de mantenimiento. “Mantenimiento” en la norma ISO / IEC 14764: 2006 significa el mantenimiento del software a menos que se indique lo contrario.

SEGUNDO-16 Guía SWEBOK® V3.0

ISO / IEC 14764: 2006 proporciona el marco dentro del cual se pueden ejecutar los planes de mantenimiento de software genéricas y específicas, evaluados y adaptados al ámbito mantenimiento y la magnitud de los productos de software dadas. Proporciona el marco, la terminología precisa, y procesos para permitir la aplicación coherente de gía tecnolo(herramientas, técnicas y métodos) para mantenimiento de software. No se refiere a la operación del software y las funciones operativas, por ejemplo, copia de seguridad, recuperación y administración del sistema, que normalmente se lleva a cabo por aquellos que operan el software. ISO / IEC 14764: 2006 está dirigido principalmente a los encargados del mantenimiento de software y, además, para los responsables del desarrollo y Ance assurcalidad. También puede ser utilizado por los adquirentes y usuarios de sistemas que contienen software, que pueden proporcionar insumos para el plan de mantenimiento.

Software Configuration Management Thereisonestandardfor configuración administración.

IEEE Std. 828-2012 estándar para la configuración Gestión de Sistemas e Ingeniería de Software

en la ISO / IEC / IEEE Std. 24765 y los requisitos de elemento de información de IEEE Std. 15939.

ISO / IEC JTC 1 / SC 7 aún no ha determinado qué medidas se deben tomar con respecto a la nueva norma IEEE Std. 828. Hay cuestiones relativas a la medida de la compatibilidad con la norma ISO / IEC / IEEE 12207 y otras normas en la suite SC 7. Cabe señalar, sin embargo, que SC 7 no tiene un estándar de competencia. GESTIÓN DE INGENIERÍA DE SOFTWARE La mayoría de los lectores interpretar la expresión “gestión de la ingeniería de software” en el sentido de la gestión de un proyecto que se refiere el software. Hay al menos dos posibles extensiones a este eralization ge-, sin embargo. Algunas de las actividades de software se gestionan de acuerdo con un acuerdo de nivel de servicio (SLA). SLA no cumplen con los criterios de “pro- yecto” de acuerdo con algunas definiciones. También, se ha convertido en un acuerdo general de que algunos gestión de software debe ocurrir en la organización a un nivel por encima del proyecto, por lo que todos los proyectos se pueden beneficiar de una inversión común. Un ejemplo comúnmente citado es la provisión de pro- software cesos y herramientas de la organización. gestión de proyectos de software puede ser considerado como una especialización de “gestión de proyectos” - a menudo considerado como una disciplina distinta. Guía del Instituto de Gestión de Proyectos para la Dirección de Proyectos (Guía del PMBOK®) es a menudo considerado como la fuente autorizada para este conocimiento. De vez en cuando, IEEE adopta la versión más reciente de la Guía PMBOK ® como un estándar IEEE.

Esta norma establece las exigencias mínimas para los procedimientos de gestión de la configuración (CM) en los sistemas e ingeniería de software. La aplicación de esta norma se aplica a cualquier forma, clase o tipo de software o sistema. Esta revisión de la norma amplía la versión anterior para explicar CM, incluyendo la identificación y adquisición los elementos de configuración, el control de cambios, informeing el estado de los elementos de configuración, así como el software construye y liberar la ingeniería. Su predece- predefinido sólo el contenido de un plan de gestión de configuración de software. Esta norma aborda lo

que CM actividades se van a hacer, cuando están a suceder en el ciclo de vida, y qué planificación y se requieren recursos. También se describen las áreas de contenido para un plan de CM. Los puertos SUP- estándar ISO / IEC / IEEE 12207: 2008 e ISO / IEC / IEEE 15288: 2008 y se adhiere

a la terminología

Apéndice B B-17 IEEE Std. 1490-2011 Guía-Aprobación del Project Management Institute (PMI ®) estándar, Una Guía para la Gestión de Proyectos El conocimiento (Guía del PMBOK®) -Cuarto Edición

La Guía del PMBOK® identifica el subconjunto de la Dirección de Proyectos del conocimiento gene- ralmente reconocida como buena práctica. “Generalmente reconocido” significa el conocimiento y las prácticas descritas son aplicables a la mayoría de los proyectos de la mayoría de

SEGUNDO-18 Guía SWEBOK® V3.0

el tiempo y existe un consenso sobre su valor y Particularmente en aplicaciones de alta utilidad. “La buena práctica” significa que hay tecnología y proyectos de graves consecuencias, acuerdo general en que la aplicación de estas la gestión de riesgos es un aspecto importante de habilidades, herramientas y técnicas puede las responsabilidades de gestión en general promejorar las posibilidades de éxito en una amplia yecto. Esta norma se ocupa de ese tema. gama de proyectos. La buena práctica no significa que el conocimiento descrito siempre debe aplicarse de manera uniforme a todos los proyectos; elorganización y / o el equipo de gestión de proyectos es respon- sable para determinar lo que es apropiado para cualquier proyecto dado. La Guía del PMBOK® también proporciona y promueve un vocabulario común dentro de la profesión de gestión de proyectos para la discusión, la escritura y la aplicación de conceptos de gestión de proyectos. Tal vocabulario estándar es un elemento esencial de una disciplina profesional. El Project Management Institute (PMI) considera que esta norma como referencia fundamental la gestión de proyectos para sus programas y certificaciones de desarrollo profesional.

Las revisiones de la norma ISO / IEC / IEEE 2008 12207 y 15288 proporcionan los procesos de gestión de proyectos de software y sistemas y relacionarlos con los procesos a nivel de organización, así como los procesos gías Nical. El desarrollaron conjuntamente norma 16326, en sustitución de dos normas más antiguas, amplía estas disposiciones con orientación para su aplicación.

ISO / IEC / IEEE 16326: 2009 Sistemas y Cesión de Software Ingeniería de Procesos-Life-Cycle Gestión de Proyectos

IEEE Std. 16085-2006 (también conocido como ISO / IEC 16085: 2006) Estándar para los sistemas y el software Ingeniería- vida del software de Procesos-Riesgos ciclo de gestión

ISO / IEC 16085: 2006 define un proceso para la gestión del riesgo en el ciclo de vida. Se puede añadir al conjunto existente de los procesos del ciclo de vida del software del sistema y definidos por la norma ISO / IEC 15288 y ISO / IEC 12207, o puede ser utilizado independientemente. ISO / IEC 16085: 2006 puede ser aplicado igualmente a sistemas y software. El propósito de la gestión de riesgos es idenpotenciales problemas de gestión y técnicas tificar antes de que ocurran de manera que se pueden tomar medidas que reducen o eliminan la probabilidad y / o el impacto de estos problemas que puedan producirse. Es una herramienta de cal criti- para determinar continuamente la viabilidad de los planes de proyecto, para mejorar la búsqueda e identificación de problemas potenciales que pueden afectar a las actividades del ciclo de vida y la calidad y rendimiento de los productos, y para mejorar la gestión activa de proyectos .

El análisis de riesgos y mitigación de riesgo depende crucialmente de medición. Esta norma internacional proporciona una elaboración del proceso de medi- ción de la norma ISO / IEC / IEEE 15288: 2008 e ISO / IEC / IEEE 12207: 2008.

ISO / IEC / IEEE 16326: 2009 proporciona las especificaciones de contenido normativo de los planes de gestión de proyectos que abarca proyectos de software y softwareproyectos de sistemas intensivos. También proporcionadetallado discusión y asesoramiento sobre la aplicación de un conjunto de procesos pro- yecto que son comunes tanto para el ciclo de vida del sistema

ware y blandas como cubiertos por la norma ISO / IEC 12207: 2008 (IEEE Std 12207-2008.) e ISO / IEC

15288: 2008 (IEEE Std 15.288-2008.), Respectivamente. La discusión y consejos están destinados a ayudar en la preparación del contenido normativo de los planes de gestión de proyectos. ISO / IEC / IEEE 16326: 2009 es el resultado de la armonización de la norma ISO / IEC TR 16326: 1999 e IEEE Std. 1058-1998.

IEEE Std. 15939-2008 La adopción del Apéndice estándar B B-19 ISO / IEC 15939: 2007 Sistemas y Procesos ingeniería de software-Medición

ISO / IEC 15939 define un proceso de medición aplicables a sistema y ingeniería de software y disciplinas de gestión. El proceso se describe a través de un modelo que define las activi- dades del proceso de medición que se requieren para especificar adecuadamente lo que se requiere informa- ción de medición, cómo se pueden aplicar a las medidas y análi- sis resultados, y cómo determinar

Apéndice B B-11

si los resultados del análisis son válidos. El para producir o gestionar la documentación, y se proceso de medición es flexible, tailorable, y aplica tanto a la documentación impresa y la adaptable a las necesidades de diferentes documentación en pantalla. Gran parte de su usuarios. orientación es aplicable a la documentación del ISO / IEC 15939: 2007 identifica un proceso usuario para los sistemas que incluyen utensilios que es compatible con la definición de un de hardware así como software. conjunto adecuado de medidas que aborden las necesidades de información específica. En él se identifican las actividades y tareas que son A veces, el software o los componentes del necesarias para éxito- totalmente identificar, sistema se adquieren en lugar de desarrollarse. definir, seleccionar, aplicar y mejorar la medición dentro de un proyecto global o la estructura de medición zational orga-. También proporciona definiciones de los términos de medición comúnmente usado dentro de las industrias de sistemas y software.

proyectos de software a menudo requieren el desa- rrollo de la documentación del usuario. Gestión del proyecto, por lo tanto, incluye la gestión del esfuerzo de documentación.

ISO / IEC / IEEE 26511: 2012 Sistemas y de Ingeniería de Software-Requisitos para los gerentes de Documentación del usuario

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

Se describe un conjunto de prácticas útiles de calidad que pueden ser seleccionados y aplicados durante uno o más pasos de un proceso de adquisición de software. Esta práctica recomendada se puede aplicar al software que se ejecuta en cualquier sistema informático sin tener en cuenta el tamaño, complejidad o criticidad del software, pero es más adecuado para su uso on-off-themodificado software comercial y software completamente desarrollado.

ISO / IEC / IEEE 26511: 2012 especifica los procedimientos para la gestión de la A veces, la documentación del usuario se documentación de usuario en todo el ciclo de vida del software. Se aplica a las personas u adquiere con independencia de que el software organiza- ciones que producen suites de se describe fue adquirida. Los siguientes Norma documentación, a los que realizan un único se ocupe de ese tema. proyecto de documentación, y la documentación producida internamente, como bien en cuanto a la documentación contratado para las organizaciones de servicios externos. Proporciona una visión general de los procesos de documentación ware y gestión de la información blandos, y también presenta aspectos de la planificación de la cartera y gestión de contenidos que los administradores de la documentación de usuario se aplican. Abarca las actividades de gestión en el inicio de un proyecto, incluyendo el establecimiento de procedimientos y especificaciones, el establecimiento de infraestructura y construcción de un equipo. Incluye ejemplos de

funciones necesarias en un equipo de documentación del usuario. Se ocupa de las mediciones y estimaciones necesarias para el control de la gestión y el uso de procesos tales como la gestión del cambio, el horario y el control de costes, gestión de recursos y gestión de la calidad y el proceso de mejora ción de apoyo. Incluye requisitos para documentos clave producidos para la gestión de la documentación del usuario, incluyendo los planes de documentación y los planes de gestión de documentación. ISO / IEC / IEEE 26511: 2012 es independiente de las herramientas de software que

SEGUNDO-12 Guía pueden utilizarse SWEBOK® V3.0

ISO / IEC / IEEE 26512: 2011 Sistemas y de Ingeniería de Software-Requisitos para los adquirentes y SUP- pinzas de Documentación del usuario

ISO / IEC / IEEE 26512: 2011 ha sido desarrollado para ayudar a los usuarios de la norma ISO / IEC / IEEE 15288: 2008 o ISO / IEC / IEEE 12207: 2008 para la adquisición o la documentación de usuario del software de alimentación como parte de los procesos del ciclo de vida del software. Define el proceso de documentación desde el punto de vista de la entidad adquirente y el punto de vista del proveedor. ISO / IEC / IEEE 26512: 2011 cubre los requisitos de los elementos de información utilizados en la adquisición de productos de documentación de usuario: el plan de adquisición, especificación documento, Ment por el estado de trabajo, solicitud de propuestas, y propuesta. Proporciona una visión general de los procesos de documentación de usuario del software y la gestión de la información que pueden requerir la adquisición y suministro de productos y servicios de documentación de usuario de software. Se ocupa de la preparación de los requisitos para

Apéndice B B-13

software documentación del usuario. Estos requisitos son esenciales para la especificación de documentos del usuario y declaración de trabajo. Incluye requisitos para salidas de documentos primarios del proceso de adquisición y suministro: la solicitud de propuesta y la propuesta de productos y servicios de documentación del usuario. También se analiza el uso de un plan de gestión de la documentación y la de un plan de documento a medida que surjan en los procesos de adquisición y suministro. ISO / IEC / IEEE 26512: 2011 es independiente de las herramientas de software que pueden ser utilizados para producir la documentación y se aplica tanto a la documentación impresa y la documentación en pantalla. Gran parte de su orientación es aplicable a la documentación del usuario para los sistemas que incluyen hardware, así como el software.

Se mencionan las siguientes dos normas aquí, porque proporcionan información utilizada en la toma de decisiones ción manage-.

mejora de las prácticas. Por ejemplo, se podría pro- poner una práctica mejorada para el software de análisis de los requisitos. Un tratamiento ingenuo podría relacionar la descripción a una etapa temprana del modelo del ciclo de vida. Un enfoque superior es para describir la práctica en el contexto de un proceso que puede ser aplicado en cualquier etapa del ciclo de vida. El proceso de análisis de requisitos, por ejemplo, es preciso proceder a la etapa de desarrollo, para el mantenimiento, y con frecuencia para el retiro, por lo que una mejora de la práctica se describe en términos del proceso de análisis de requisitos se puede aplicar a cualquiera de estas etapas. Las dos normas principales son la norma ISO / IEC / IEEE 12207, los procesos de ciclo de vida del software, e ISO / IEC / IEEE 15288, la vida del sistema los procesos de ciclo. Las dos normas tienen historias distintas, pero ambos fueron revisados en 2008 para alinear sus procesos, lo que permite su uso interoperable a través de un amplio espectro de proyectos que van desde un componente de software autónomo a un sistema con contenido de software ligible neg. Ambos están siendo revisados de nuevo con la intención de que contiene una

idéntico IEEE Std. 1028-2008 estándar para las revisiones de software y auditorías

lista de procesos, pero con disposiciones especializadas para las respectivas disciplinas.

Ver la calidad del software KA IEEE Std. 1061-1998 Estándar de Calidad de Software Metodología Métrica

Ver la calidad del

IEEE Std. 12207-2008 (también conocido como ISO / IEC 12207: 2008) Estándar para los sistemas y el software Ingeniería- Software Procesos del ciclo de vida

software KA

La siguiente norma se menciona, ya que incluye el papel del gerente en el desarrollo de documentación de usuario en un proyecto ágil.

ISO / IEC 12207: 2008 establece un marco común para los procesos del ciclo de vida del software, con la terminología bien definida que puede ser referenciado por la industria del software. ISO / IEC 12207: 2008 se aplica a la adquisición de los sistemas y productos de software y

serISO / IEC / IEEE 26515: 2012 Sistemas y de Ingeniería de Software-El desarrollo de documentación del usuario en un entorno ágil

Ver Modelos de Ingeniería de Software y métodos KA

SOFTWARE INGENIERÍA DE PROCESOS procesos de software e ingeniería de sistemas son fundamentales para la normalización de esas dos disciplinas, no sólo porque muchos están interesadas en la mejora de procesos, sino también porque los procesos son eficaces para la descripción de

SEGUNDO-14 Guíael vicios y con SWEBOK® V3.0

suministro, desarrollo, operación, mantenimiento y eliminación de productos de software y la parte de software de un sistema, ya sea interna o externamente a cabo a una organiza- ción. se incluyen aquellos aspectos de la definición del sistema necesario para proporcionar el contexto para los productos y servicios de software. ISO / IEC 12207: 2008 proporciona también un procedimiento que puede ser empleado para definir, controlar y mejorar los procesos del ciclo de vida del software. Los procesos, actividades y tareas de la norma ISO / IEC 12207: 2008, ya sea solo o en combinación con la norma ISO / IEC 15288también puede ser aplicado durante la adquisición de un sistema que contiene el software.

Apéndice B B-15

IEEE Std. 15288-2008 (también conocido como ISO / IEC 15288: 2008) Estándar para los sistemas y el software Ingeniería- vida del sistema los procesos de ciclo

elementos de información (productos de información, docu- mentación) para ser desarrollados y revisados en los sistemas y los ciclos de vida del software y procesos de gestión de servicios. Se especifica el propósito y el contenido de todos los sistemas identificados y los registros de datos de software y elementos de información de ciclo de vida, así como los registros y elementos de información para la gestión de servicios de tecnología de la información. El contenido elemento de información se definen de acuerdo con los tipos genéricos de documentos (descripción, plan de, helado Pol, el procedimiento, informe, solicitud, y en las especificaciones) y el propósito específico del documento. Para simplificar la referencia, cada elemento de información se describe como si se publicó como documento separado. Sin embargo, los elementos de información pueden ser inéditos pero está disponible en un repositorio para refe- rencia, dividido en documentos separados o volúmenes, o en combinación con otros elementos de información en un solo documento. ISO / IEC / IEEE 15289: 2011 se basa en los procesos del ciclo de vida que se especifican en la norma ISO / IEC 12207: 2008 (. IEEE Std 12207-2008) e ISO / IEC 15288: 2008 (IEEE Std 15288-. 2008), y la gestión de servicios de procesos especificados en la norma ISO / IEC 20000-1: 2005 e ISO / IEC 20000-2: 2005.

ISO / IEC 15288: 2008 establece un marco común para describir el ciclo de vida de los siste- mas creados por los seres humanos. Se define un conjunto de procesos y terminología asociada. Estos procesos se pueden aplicar en cualquier nivel en la jerarquía de la estructura de un sistema. conjuntos seleccionados de estos procesos se pueden aplicar durante todo el ciclo de vida de la gestión y la realización de las etapas del ciclo de vida de un sistema. Esta es plished acompa- mediante la participación de todas las partes interesadas, con el objetivo último de lograr la satisfacción al cliente central. ISO / IEC 15288: 2008 también proporciona procesos que apoyan la definición, el control, y la mejora de los procesos del ciclo de vida utilizadas dentro de una organización o de un proyecto. Las organizaciones y los proyectos pueden utilizar estos procesos de ciclo de vida en que la adquisición y el suministro de sistemas. ISO / IEC 15288: 2008 se refiere a los sistemas que son hechas por el hombre y pueden ser configurados con uno o más de los siguientes: hardware, software, datos, los humanos, los procesos (por ejemplo, los procedimientos para el servicio a los usuarios Viding pro), procedimientos ( por ejemplo, instrucciones de opera- tor), instalaciones, Los siguientes dos guías proporcionan materiales y entidades de rally que ocurre natu-. complementaria Cuando un elemento del sistema es el software, información útil en la aplicación de 12207 y los procesos del ciclo de vida del software docu- 15288. mentado en la norma ISO / IEC 12207: 2008 se puede utilizar a aplicar ese elemento del sistema. ISO / IEC 15288: 2008 e ISO / IEC 12207: 2008 están armonizadas para el uso simultáneo en un solo proyecto o en una sola organización.

Estas dos normas especifican que los procesos pueden producir elementos de información, pero no pre- escriba su contenido o formato. El siguiente estándar proporciona ayuda con eso.

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

ISO / IEC TR 24748-2 es una guía para la aplicación de la norma ISO / IEC 15288: 2008. Aborda sis- tema, ciclo de vida, proceso, organización, proyecto, y los conceptos de adaptación, principalmente a través de la referencia a la norma ISO / IEC TR 24748-1 e ISO / IEC 15288: 2008. A continuación, da orientaciones

SEGUNDO-16 Guía sobre la aplicación SWEBOK® V3.0

de

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

ISO / IEC 15288: 2008, de los aspectos de la estrategia, la planificación, la aplicación en las organizaciones, y la aplicación de proyectos.

ISO / IEC / IEEE 15289: 2011 proporciona los requisitos para la identificación y planificación de la específica

IEEE Std. 24.748,3-2012 Guía de implantación de la norma ISO / IEC TR 24748-3: 2011 Sistemas y Software

Apéndice B B-17

Ingeniería-Life Management-Parte 3 Ciclo: Guía para la aplicación de la norma ISO / IEC 12207 (procesos de ciclo de vida Cesión de Software)

ISO / IEC TR 24748-3 es una guía para la aplicación de la norma ISO / IEC 12207: 2008. Aborda sis- tema, ciclo de vida, proceso, organización, proyecto, y los conceptos de adaptación, principalmente a través de la referencia a la norma ISO / IEC TR 24748-1 e ISO / IEC 12207: 2008. Se proporciona orientación sobre la aplicación de la norma ISO / IEC 12207: 2008, de los aspectos de estrategia, la planificación, la aplicación en las organizaciones, y la aplicación de proyectos.

Las normas 12207 y 15288 proporcionan cesos pro que cubren el ciclo de vida, pero que no proporcionan un modelo estándar de ciclo de vida (cascada, la entrega incrementales, prototipo impulsado, etc). La selección de un modelo de ciclo de vida apropiado para un proyecto es una de las principales preocupaciones de la norma ISO / IEC 24748-1.

guías de aplicación actualizados para los estándares internacionales. ISO / IEC TR 247481 es el resultado de la etapa de alineación de la armonización de la norma ISO / IEC 12207 y ISO / IEC 15288.

La siguiente norma amplía las disposiciones de la norma ISO / IEC / IEEE 12207 para hacer frente a la reutilización del software sistemática.

IEEE Std. 1517-2010 estándar para la tecnología de la información del sistema y del software-Vida Procesos de reutilización de procesos de ciclo

Un marco común para la ampliación de los procesos del ciclo de vida del sistema y software de IEEE Std. 12207: 2008 para incluir se proporciona la práctica sistemática de la reutilización. Los procesos, actividades y tareas que deben aplicarse durante cada proceso de ciclo de vida para permitir a un sistema y / o producto para ser construido a partir de los activos reutilizables se especifican. Los procesos, actividades y tareas a

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

la identificación, construcción, mantenimiento y gestión de los bienes suministrados también se especifican.

ISO / IEC TR 24748-1 proporciona información sobre los conceptos de ciclo de vida y las descripciones de las poses PUR y los resultados de las etapas del ciclo de vida representativos. También ilustra el uso de un modelo de ciclo de vida para los sistemas en el contexto de la norma ISO / IEC 15288 y proporciona una ilustración correspondiente de la utilización de un modelo de ciclo de vida para el software en el contexto de la norma ISO / IEC 12207. ISO / IEC TR 24748- 1 además proporciona una discusión detallada y asesoramiento sobre la adaptación de un modelo de ciclo de vida para su uso en un proyecto específico y entorno de la organización. Se proporciona orientación adicional sobre el ciclo de vida modelo de uso de los ámbitos, disciplinas y especialidades. ISO / IEC TR 24748-1 da una comparación detallada entre las

IEEE Std. 1220 ha sido ampliamente aplicado como un proceso de ingeniería de sistemas y fue adoptado por la norma ISO / IEC 26702. con el número Desafortunadamente, la norma no es totalmente compatible con la norma ISO / IEC / IEEE 15288 y está siendo revisada para resolver ese problema. El resultado será publicado como ISO / IEC / IEEE 24748-4.

versiones anteriores y actuales de ISO / IEC 12207 y ISO / IEC 15288, así como consejos sobre la transición de antes de las versiones actuales y sobre el uso de sus guías de aplicación. La dis- cusión y asesoramiento están destinadas a proporcionar un modelo de referen- cia para los modelos de ciclo de vida, facilitar el uso de la

SEGUNDO-18 Guía versión actualizada SWEBOK® V3.0

de la norma ISO / IEC 15288 e ISO / IEC 12207, y proporcionar un marco para el desarrollo de

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

ISO / IEC 26702 define las tareas interdisciplinares que se requieren a lo largo del ciclo de vida de un sistema para transformar las necesidades del cliente, requisitos y restricciones en una solución de sistema. En adi- ción, que especifica los requisitos para el proceso de ingeniería de sistemas y su aplicación pasantes a cabo el ciclo de vida del producto. ISO / IEC 26702: 2007 se centra en las actividades de ingeniería necesarias para guiar el desarrollo de productos, garantizando al mismo tiempo

Apéndice B B-19

que el producto está correctamente diseñado para que sea asequible para producir, poseer, operar, mantener y eventualmente gastar sin riesgos indebidos para la salud o el medio ambiente.

Desde SC 7 e IEEE han escrito hasta muchos normas de proceso, uno puede que no se sorprenda al saber que su modelo para la descripción del proceso se registra en un informe técnico.

IEEE Std. 24774-2012 Guía de implantación de la norma ISO / IEC TR 24474: 2010 Sistemas y ingeniería de software-Life Cycle ManagementDirectrices para Pro- ceso Descripción

Un número cada vez mayor de, y las normas internacionales, nacionales industria de procesos mode- los describa. Estos modelos son desarrollados para una serie de propósitos, incluyendo la implementación de procesos y evaluación. Los términos y las descripciones utilizadas en tales modelos varían en formato, contenido y nivel de prescripción. ISO / IEC TR 24774: 2010 PRESION ents directrices para los elementos utilizados más fre- cuentemente en la descripción de un proceso: el título, PUR pose, resultados, actividades, tareas y elemento de información. Mientras que el propósito primario de ISO / IEC TR 24774: 2010 es fomentar la coherencia en modelos de referencia proceso Dard Standards, las directrices que proporciona se pueden aplicar a cualquier modelo de proceso desarrollado para cualquier propósito.

Una muy pequeña entidad (VSE) es una empresa, una organización, un departamento o un proyecto que tiene hasta 25 personas. La serie 29110 ISO / IEC “pro” archivos grandes, tales como las normas ISO / IEC 12207 para el software y la norma ISO / IEC 15288 para sistemas, en otras más pequeñas para las MPE. ISO 29110 es aplicable a VSE que no desarrollan sistemas críticos o critisoftware de cal. Perfiles proporcionan una hoja de ruta que permite una puesta en marcha a crecer un paso a la vez usando las guías de gestión y de ingeniería ISO 29110.

A VSE podría obtener una ISO / IEC 29110 certifica- ción. El conjunto de informes técnicos está disponible sin costo alguno en el sitio web de la ISO. Muchos ISO 29110 documentos están disponibles en Inglés, Español, tugueses Por-, japonés y francés.

ISO / IEC TR 29110-5-1-2: Perfiles 2011 Ingeniería de Software-ciclo de vida de entidades muy pequeñas (MPE) -Parte 5-1-2: Gestión y Guía de Ingeniería: Perfil genérico Grupo: todos los datos generales

ISO / IEC TR 29110-5-1-2: 2011 es aplicable a entidades muy pequeñas (MPE). Un VSE se define como una empresa, organización, departamento, o pro- yecto que tiene hasta 25 personas. Un conjunto de normas y guías se ha desarrollado de acuerdo con un conjunto de características y necesidades MPE. Las guías se basan en subconjuntos de estándares apropiados ele- mentos, conocidos como perfiles VSE. El propósito de un perfil VSE es definir un subconjunto de las normas internacionales ISO / IEC pertinentes al contexto las empresas muy pequeñas. ISO / IEC TR 29110-5-1-2: 2011 proporciona la guía de gestión e ingeniería para el perfil VSE base aplicable a empresas muy pequeñas que no desarrollan software crítico. El grupo de perfil genérico no implica ningún dominio de aplicación específica.

El siguiente estándar puede ser visto como una alternativa a 12207 para proyectos individuales. La norma de 1074, explica cómo definir los procesos para su uso en un proyecto determinado. Las normas 12207 y 15288, sin embargo, se centran en la definición de procesos para la adopción de la organización y el uso repetido en muchos proyectos. La corriente 1074 es la actualización de una norma que fue un precursor de 12207.

ISO / IEC 29110 serie de normas e informes técnicos son el blanco de la audiencia tales como las microempresas, los clientes o los auditores. ISO / IEC 29110 no pretende excluir el uso de

SEGUNDO-20 Guíaciclos diferentes SWEBOK® V3.0

de vida se acerca, como la cascada, iterativo e incremental, evolutivo, o ágil.

IEEE Std. 1074-2006 estándar para desarrollar un proceso del ciclo de vida del software del proyecto

Esta norma proporciona un proceso para la creación de un proceso del ciclo de vida del proyecto de software (SPLCP). Está dirigida principalmente a los del arquitecto proceso para un proyecto de software determinado.

Apéndice B B-21

Todas las normas descritas hasta ahora en esta sec- ción proporcionar una base para la definición de procesos. Algunos usuarios están interesados en la evaluación y la mejora de sus procesos después de la implementación. La serie 15504 prevé la evaluación del proceso; que actualmente es de ser revisado y pasa a ser 330xx.

• es aplicable en todos los dominios de aplicación y tamaños de organización; y • mayprovideanobjectivebenchmark entre las organizaciones. El conjunto mínimo de requisitos definidos en la norma ISO / IEC 15504-2: 2003 asegura que la evaluación resultados son objetiva, imparcial, consistente,

repetibilidad ISO / IEC 15504 [diez partes] Evaluación Información Tech- gía-Proceso

ISO / IEC 15504-2: 2003 define los requisitos para realizar la evaluación de proceso como base para su uso en la mejora de procesos y la determinación de la capacidad. evaluación de proceso se basa en un modelo sional de dos dimen- que contiene una dimensión de proceso y una dimensión de capacidad. La dimensión proceso es proporcionado por un modelo de referencia de proceso externo (tal como 12.207 o 15.288), que define un conjunto de procesos que se caracteriza por los estados de proceso propósito y el proceso resultados. loscapacidad dimensión consiste en un marco de medición que comprende seis niveles de capacidad del proceso y sus atributos de proceso asociados. La salida de evaluación consta de un conjunto de puntuaciones de atributos proceso para cada proceso evaluado, denominado el perfil de proceso, y también puede incluir el nivel de capacidad alcanzado por ese proceso. ISO / IEC 15504-2: 2003 define el marco medi- ción de la capacidad del proceso y los requisitos para • • • •

realizar una evaluación; modelos de referencia proceso; modelos de evaluación de proceso; la verificación de la conformidad de la evaluación del proceso.

Los requisitos para la evaluación de procesos definidos en la norma ISO / IEC 15504-2: 2003 forman una estruc- tura que • facilita la autoevaluación; • proporciona una base para uso en el proceso de mejora ment y determinación de la

capaz, y representante de los procesos evaluados. Resultados de las evaluaciones de proceso conformes pueden compararse cuando se consideran los alcances de las evaluaciones a ser similares; para obtener orientación sobre este tema, consulte la norma ISO / IEC 15504-4.

Se mencionan varias otras normas aquí porque están escritos como elaboraciones de los procesos de 12207 o 15288. Están asignados a otras KAs debido a que cada uno se ocupa de temas descritos en los otros KAs.

capacidad; • tiene en cuenta el contexto en el que la proceso evaluado se implementa; • produce una calificación de proceso; • aborda la capacidad del proceso para lograr su propósito;

SEGUNDO-22 Guía estándar para la configuración IEEE Std. 828-2012 SWEBOK® V3.0

Gestión de Sistemas e Ingeniería de Software

Consulte Gestión de la Configuración de Software KA IEEE Std. 14764-2006 (también conocido como ISO / IEC 14764: 2006) Estándar de Ciclo de Vida del Software Ingeniería de Software-Procesos-Mantenimiento

Ver Mantenimiento de Software KA ISO / IEC 15026-4: 2012 Sistemas y Software Inge- niería-Sistemas y de Software AssuranceParte 4: Control de calidad en el ciclo de vida

Ver la calidad del software KA IEEE Std. 15939-2008 La adopción del estándar ISO / IEC 15939: 2007 Sistemas y Procesos ingeniería de software-Medición

Consulte Software Engineering Management KA ISO / IEC 15940: 2006-Tecnologías de la Información Ingeniería de Software Environment Services

Ver Modelos de Ingeniería de Software y métodos KA IEEE Std. 16085-2006 (también conocido como ISO / IEC 16085: 2006) Estándar para los sistemas y el software Ingeniería- vida del software de Procesos-Riesgos ciclo de gestión

Consulte Software Engineering Management KA

Apéndice B B-23

ISO / IEC / IEEE 16326: 2009 Sistemas y Cesión de Software Ingeniería de Procesos-Life-Cycle Gestión de Proyectos

Consulte Software Engineering Management KA ISO / IEC / IEEE 29148: 2011 Sistemas y Software Ingeniería-Life Cycle procesos de Ingeniería de Requisitos

Consulte Requisitos de software

ejemplo. Ni tampoco S2ESC SC 7 tiene un estándar para el desarrollo ágil, pero no existe un estándar para el desarrollo de documentación de usuario en un proyecto ágil.

ISO / IEC / IEEE 26515: 2012 Sistemas y de Ingeniería de Software-El desarrollo de documentación del usuario en un entorno ágil

KA

Algunos usuarios desean estándares de procesos que pueden utilizarse para operaciones de TI o la gestión de servicios de TI. La serie ISO / IEC 20000 describen la gestión de servicios. Los procesos se definen con menos rigor que los de las normas antes mencionadas inge- niería, pero pueden ser preferibles para situa- ciones donde los riesgos de fracaso implican dinero o la satisfacción del cliente en lugar de la salud pública, la seguridad y el bienestar. La serie ISO / IEC 20000 se extienden ahora a muchas partes. El fundamento de la serie, ISO / IEC 20000-1, se describe brevemente a continuación.

ISO / IEC / IEEE 26515: 2012 especifica la manera en que la documentación del usuario se puede desarrollar en los proyectos de desarrollo ágil. Está diseñado para su uso en todas las organizaciones que están utilizando desa- rrollo ágil o están considerando la implementación de sus proyec- tos utilizando estas técnicas. Se aplica a las personas u organizaciones que producen suites de documentación, a los que realizan un único proyecto de documentación, y la documentación producida internamente, así como a la documentación contratada para las organizaciones de servicios externos. ISO / IEC / IEEE 26515: 2012 se refiere a la relación entre el proceso de documentación del usuario y el proceso de documentación del ciclo de vida de desarrollo ágil. Eso describe cómo el desarrollador de información o

proyecISO / IEC 20000-1: 2011 Tecnología de Información de Gestión de Servicio-Parte 1: Requisitos del Sistema de Gestión de Servicios

ISO / IEC 20000-1: 2011 es un sistema de gestión de servicios (SMS) estándar. Especifica los requisitos para el proveedor de servicios para planificar, establecer, imple- ment, operar, supervisar, revisar, mantener y mejorar un SMS. Los requisitos incluyen el diseño, la transición, la entrega y la mejora de los servicios para satisfacer los requisitos de servicio acordados.

IEEE ha adoptado las dos primeras partes de la serie ISO / IEC 20000. SOFTWARE INGENIERIA MODELOS Y MÉTODOS Algunos enfoques de métodos de ingeniería de software de uso que abarcan gran parte de su ciclo de vida, en lugar de centrarse en procesos

gerente ect puede planificar y gestionar el desarrollo de usuario docu- mentación en un entorno ágil. Se pretende ni para alentar ni a desanimar el uso de cualquier herramienta de desarrollo ágil particulares o métodos.

Muchas metodologías se basan en descripciones semiformales del software que se construirá. Estos van desde notaciones descriptivas simples a los modelos que pueden ser manipulados y probados y, en algunos casos, puede generar código. Dos técnicas antiguas rela- tivamente comienzan la lista; la primera ha sido ampliamente aplicado para el modelado de procesos y flujos de trabajo. específicos. “Jefe programador” era uno ejem- plo tradicionales. “El desarrollo ágil” (en realidad un ejemplo de entrega incrementales tradicional) es una corriente

SEGUNDO-24 Guía 1320,1-1998 IEEE Std. SWEBOK® V3.0

estándar para Modfuncional eling Idioma-sintaxis y la semántica de IDEF0

modelado IDEF0 función está diseñada para repre- sentan las decisiones, acciones y actividades de una organización o sistema existente o potencial. IDEF0 gráficos y textos que acompañan están pre-tantes de una manera organizada y sistemática para ganar

Apéndice B B-25

comprensión, el análisis de apoyo, proporcionan Las siguientes dos normas proporcionan dos la lógica de los cambios potenciales, especificar versiones de necesidades, y el diseño de apoyo a nivel de el lenguaje UML. sistema y activi- integración corbatas. IDEF0 se puede usar para modelar una ampliavariedad de sistemas, compuestos por personas, máquinas, mate- riales, las computadoras y la información de todas las variedades, y estructuradas por las relaciones entre ellos, tanto automatizados y no automatizados. Para los nuevos siste- mas, IDEF0 puede ser utilizado por primera vez para definir los requisitos y especificar las funciones a realizar por el sistema futuro. Como base de esta arquitectura, IDEF0 continuación, se puede utilizar para diseñar una aplicación que cumple con estos requisitos y realiza estas funciones. Para siste- mas existentes, IDEF0 se puede utilizar para analizar las funciones que el sistema funciona y para grabar los medios por los cuales estos se realizan. IEEE Std. 1320,2-1998 estándar para Modelado Conceptual Idioma-sintaxis y la semántica de IDEF1X97 (IDEFobject)

ISO / IEC 19501: 2005 Información Tecnología distribuido abierto Modeling Language (UML) Versión 1.4.2 Procesamiento-Unificado

ISO / IEC 19501 describe el Modelo- Unificado ing Language (UML), un lenguaje gráfico para visualizar, especificar, construir y documentando los artefactos de un sis- tema intensivos en software. El UML ofrece una forma estándar para escribir planos de un sistema, incluyendo cosas conceptuales tales como procesos de negocio y funciones del sistema, así como las cosas concretas, tales como instrucciones de lenguaje de programación, esquemas de bases de datos y componentes de software capaces Reus-. ISO / IEC 19505: 2012 [dos partes] Grupo de Gestión de la Información Tech- nology-Objeto Unificado Modelo- ing Language (UML del OMG)

ISO / IEC 19505 define el Unified Modeling IDEF1X 97 consta de dos lenguajes de Language (UML), revisión 2. El objetivo de modelado conceptual. El lenguaje de estilo clave UML es proporcionar arquitectos de sistemas, soporta el modelado de datos / información y es ingenieros de software y desarrolladores de a la baja COMPATIBLES con el estándar del software con herramientas para el análisis, gobierno de Estados Unidos 1993, FIPS PUB diseño e implementación de sistemas basados en 184. El lenguaje de estilo identidad se basa en el software, así como para modelado de negocios y modelo de objetos con las reglas y restricciones procesos similares. declarativas. IDEF1X 97 estilo identidad incluye construcciones para los componentes distintos pero relacionados de abstracción objeto: Dos estándares más construyen sobre la base interfaz, solicitudes y realización; utiliza de UML para proporcionar capacidades de gráficos para indicar la interfaz; y define un modelado adicionales: lenguaje de reglas y la restricción declarativa, directamente ejecutable para solicitudes y realiza- ciones. IDEF1X 97 soportes de modelado conceptual aplicación por bases de datos relacionales, extendido bases de datos relacionales, bases de datos de objetos y lenguajes de programación de objetos. IDEF1X 97 se define formalmente en términos de la lógica de primer orden. Un procedimiento se da por el que cualquier válido modelo IDEF1X 97 puede ser transformada en una teoría equivalente en la lógica de primer orden. Este procedimiento se aplica entonces a un

metamodelo de IDEF1X 97 para definir el conjunto válido de IDEF1X 97 modelos.

En los últimos años, la notación UML se ha convertido en popular para el modelado de sistemas intensivos en software.

SEGUNDO-26 ISO / IEC Guía 19506: SWEBOK® V3.0

2012 Tecnología de Información Objeto-Driven Architecture Group Gestión de la Modernización (ADM) Conocimiento Descubrimiento Meta-Modelo (KDM)

ISO / IEC 19506: 2012 define un metamodelo para repre- resentir activos de software existentes, sus las asociaciones y entornos operativos, conocido como el metamodelo descubrimiento de conocimiento (KDM). Este es el primero de la serie de especificaciones relacionadas con la garantía de software (SWA) y las actividades de modernización (ADM), la arquitectura de motor. KDM facilita

Apéndice B B-27

proyectos que involucran sistemas de software existentes asegurando la interoperabilidad y el intercambio de datos entre las herramientas proporcionadas por diferentes proveedores. ISO / IEC 19507: 2012 Tecnología de Información Object Management Group Object Constraint LANGUAGE (OCL)

ISO / IEC 19507: 2012 define el objeto ConIdioma straint (OCL), versión 2.3.1. OCL versión 2.3.1 es la versión de OCL que está alineado con UML 2.3 y 2.0 MOF.

Algunas organizaciones invierten en entornos de software niería niería (SEE) para ayudar en la construcción de software. Un SEE, per se, no es un sustituto de los procesos de sonido. Sin embargo, un VER adecuada debe ser compatible con los procesos que han sido elegidos por la organización.

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

ISO / IEC 15940: 2006 define el entorno de ingeniería de software (SEE) servicios conceptualmente en un modelo de referen- cia que se puede adaptar a cualquier EES a automática- compañero de una o más actividades de ingeniería de software. En él se describen los servicios que apoyan las definiciones de proceso como en la norma ISO / IEC 12207 para que el conjunto de los servicios SEE es compatible con la norma ISO / IEC 12207. ISO / IEC 15940: 2006 se puede utilizar ya sea como refe- rencia general o para definir un proceso de software automatizado.

La selección de herramientas para un entorno de ingeniería de software es en sí una tarea difícil. Dos estándares proporcionan algún tipo de asistencia. ISO / IEC 14102: 2008 define tanto un conjunto de procesos y un conjunto estructurado de la ingeniería de software asistida por computadora (CASE) características de la

Dentro de los sistemas e ingeniería de software, ingeniería com- putadora asistido por software (CASE) representan una parte importante de las tecnolo- gías de apoyo utilizados para desarrollar y mantener sistemas de tecnología de información. Su selección debe llevarse a cabo con una cuidadosa consideración de tanto los requisitos técnicos y de gestión. ISO / IEC 14102: 2008 define tanto un conjunto de cesos pro y un conjunto estructurado de herramienta del caso de carac- terísticas para su uso en la evaluación técnica y la selección final de una herramienta CASE. De ello se sigue el modelo de evaluación de productos de software se define en la norma ISO / IEC 145985: 1998. ISO / IEC 14102: 2008 adopta el modelo general de las características de calidad de producto de software y subcaracterísticas definidas en la norma ISO / IEC 9126- 1: 2001 y se extiende estos cuando el producto de software es una herramienta CASE; que proporciona carac- terísticas de productos únicos para herramientas CASE. herramienta para su uso en la evaluación técnica y la selección final de una herramienta CASE.

SEGUNDO-28 Guía ElV3.0 siguiente SWEBOK®

documento es una guía sobre cómo adoptar herramientas CASE, una vez seleccionado.

Proporciona una guía para establecer cesos y actividades que se van a aplicar para la adopción exitosa de la tecnología CASE pro. El uso de la norma ISO / IEC TR 14471: 2007 ayudará a

IEEE Std. 14471-2010 Guía de implantación de la norma ISO / IEC TR 14471: 2007 Tecnología de la Información-Ingeniería de SoftwareDirectrices para la adopción de las herramientas CASE

maximizar el rendimiento y minimizar el riesgo de invertir en la tecnología CASE. Sin embargo, la norma ISO / IEC TR 14471: 2007 no establece criterios El cumplimiento. Se utiliza mejor en combinación con la norma ISO / IEC 14102 para la evaluación herramienta CASE y selección. Que ni dictados ni defensores particular, las normas de desa- rrollo, los procesos de software, diseño de metods, metodologías, técnicas, programación idiomas, o paradigmas del ciclo de vida.

El propósito de la norma ISO / IEC TR 14471: 2007 es proporcionar una práctica recomendada para la adop- ción CASO. IEEE Std. 14102-2010 La adopción del estándar ISO / IEC 14102: 2008 línea de Tecnología de la Información-Guía-para la evaluación y selección de herramientas CASE

Apéndice B B-29

Dentro de un entorno de ingeniería de software, es importante para las diversas herramientas para interoperar. Las siguientes normas proporcionan un esquema para la interconexión.

IEEE Std. 1.175,1-2002 Guía para la caja de herramienta Interconexiones de Clasificación y Descripción IEEE Std. 1175,2-2.006 Práctica Recomendada para la caja de herramienta de interconexiónCaracterización de las interconexiones IEEE Std. 1.175,3-2004 estándar para la caja de herramienta Interconexiones-modelo de referencia para especificar el comportamiento del software IEEE Std. 1175,4-2008 estándar para la caja de herramienta Interconexiones-Modelo de Referencia para su comportamiento Especificación

El propósito de esta familia de normas es especify un conjunto común de conceptos de modelado en base a los encontrados en las herramientas CASE comerciales para describir el comportamiento operacional de un sistema de software. Estas normas establecen un uniforme, modelo integrado de conceptos de software relacionados con la funcionalidad del software. También proporcionan una sintaxis tual Tex para expresar las propiedades comunes (atributos y relaciones) de esos conceptos, ya que se han utilizado para modelar el comportamiento del software.

La calidad del software Un punto de vista de la calidad del software se inicia con la norma ISO 9001, Requisitos de Gestión de Calidad, que trata de la política de calidad a lo largo de una organiza- ción. La terminología de la norma que pueden ser desconocidos para los profesionales de software, y los auditores de gestión de la calidad puede no estar familiarizados con la jerga de software. La siguiente norma describe la relación entre la ISO 9001 y la ISO / IEC 12207. Por desgracia, la ver- sión actual se refiere a las ediciones obsoletas de ambos; ción una sustitución en curso:

para la aplicación de la norma ISO 9001: 2000 para Programas informáticos

ISO / IEC 90003 proporciona una guía para organiza- ciones en la aplicación de la norma ISO 9001: 2000 para la adquisición, suministro, desarrollo, operación, y

SEGUNDO-30 mantenimientoGuía de SWEBOK® V3.0

software y servicios de apoyo relacionados. ISO / IEC 90003: 2004 no se suma a cambiar o no los requisitos de la norma ISO 9001: 2000. Las directrices establecidas en la norma ISO / IEC 90003: 2004 no están destinados a ser utilizados como criterios de As- sessment en la gestión de la calidad del sistema de registro / certificación. La aplicación de la norma ISO / IEC 90003: 2004 es apropiado para el software que es • parte de un contrato comercial con otra organización, • un producto disponible para un sector del mercado, • utilizado para apoyar los procesos de una organización, • incrustado en un producto de hardware, o • en relación con los servicios de software. Algunas organizaciones pueden estar involucrados en todas las actividades

mencionadas; otros pueden especializarse en un área. Sea cual sea la situación, el sistema de gestión de calidad de la organiza- ción debe cubrir todos los aspectos (relacionados con el software y nonsoftware relacionado) de la empresa. ISO / IEC 90003: 2004 identifica las cuestiones que deben abordarse y es independiente de la tecnología de procesos, modelos de ciclo de vida, Desa- Ment, secuencia de actividades y estructura organizativa utilizada por una organiza- ción. orientaciones adicionales y referen- cias frecuente a las normas de ingeniería de software 7 1 / SC ISO / IEC JTC se proporcionan para ayudar en la aplicación de la norma ISO 9001: 2000: en particu- lar, ISO / IEC 12207, ISO / IEC TR 9126, ISO / IEC 14598, ISO / IEC 15939 e ISO / IEC TR 15504.

El enfoque de la ISO 9001 postula un proceso de gestión de la calidad organiza- ción de nivel emparejado con la garantía de calidad a nivel de proyecto

planificación IEEE Std. 90003-2008 Guía de implantación de la norma ISO / IEC 90003: 2004 Ingeniería de Software-Directrices

para alcanzar los objetivos de la organización. IEEE 730 describe la planificación de la calidad a nivel de proyecto. Es

Apéndice B B-31

Actualmente alineado con una edición obsoleta de 12207, pero se está preparando una revisión.

IEEE Std. 730-2002 estándar para los planes de garantía de calidad de software

cuadrados ofrece • • • •

Términos y definiciones, modelos de referencia, guías normas para los requisitos de la especificación con fines de evaluación, planificación y gestión, medición y.

El estándar especifica el formato y el contenido de software planes de aseguramiento de la calidad.

Otro punto de vista de la calidad del software comienza con la enumeración de las características deseadas de un producto de software y la selección de las medidas u otras evaluaciones para determinar si el nivel deseado de se ha logrado características. los así llamado Serie cuadrada (requisitos de calidad del producto y la evaluación del software) de las normas SC 7 cubre este enfoque en gran detalle.

ISO / IEC 25000 25099 a través del software Engineer--ing de software Requisitos de calidad del producto y Evaluación (cuadrados)

Algunos de los estándares cuadrados se seleccionan a continuación para una atención particular. La primera es la guía general para la serie.

ISO / IEC 25000: 2005 Software de ingeniería y software Requisitos de calidad del producto y Evaluación (cuadrados) -Guía de cuadrar

ISO / IEC 25000: 2005 proporciona orientación para el uso de la nueva serie de normas internacionales nombrados software Requisitos de calidad del producto y Evaluación (cuadrados). El propósito de esta guía es proporcionar una visión general de los contenidos cuadrados, modelos de referencia comunes, y definiciones, así como la relación entre los docu- mentos, permitiendo a los usuarios de esta guía una buena comprensión de las normas internacionales. Este documento

El próximo estándar cuadrados proporciona una Omy taxón de las características de calidad de software que puede ser útil en la selección de características relevantes para un proyecto específico:

contiene una explicación del proceso de transición entre la antigua norma ISO / IEC 9126 y la serie 14598 y cuadrados, y también presenta información sobre el uso de la serie ISO / IEC 9126 y 14598 en su forma anterior.

SEGUNDO-32 Guía 25010: 2011 Sistemas y Software ISO / IEC SWEBOK® V3.0

Engineers niería-Sistemas y Calidad de Software REQUISITOS DE y Evaluación (cuadrados) Sistema y modelos de calidad del software

ISO / IEC 25010: 2011 define lo siguiente: 1. A la calidad del modelo en uso compuesto de cinco características (algunas de las cuales se subdividen en subcaracterísticas) que se relacionan con el resultado de la interacción cuando un producto se utiliza en un contexto particular de uso. Este modelo de sistema es aplicable al sistema hombre-máquina com- pleta, incluyendo tanto los sistemas informáticos en uso y productos de software en uso. 2. Un modelo de la calidad del producto compone de ocho características (que se subdividen en subcaracterísticas) que se relacionan con propiedades estáticas de software y las propiedades dinámicas del sistema informático. El modelo es aplicable tanto a los sistemas informáticos y productos de software. Las características definidas por ambos modelos son relevantes para todos los productos de software y sistemas de ordenador. Las características y carac- subcharproporcionan terminología coherente para especificar, medir y sistema y la calidad del producto software de evaluación. También proporcionan un conjunto de características de calidad contra el que declararon los requisitos de calidad se pueden comparar para la integridad.

Apéndice B B-33

Aunque el alcance del modelo de calidad del producto está destinado a ser software y sistemas informáticos, muchas de las características también son Evant rel a los sistemas y servicios más amplios. ISO / IEC 25012 contiene un modelo para cali- datos dad que es complementaria a este modelo. El alcance de los modelos excluye propiedades puramente funcionales, pero incluye idoneidad funcional. El ámbito de aplicación de los modelos de calidad incluye el apoyo a la especificación y evaluación de software y de software intensivo Systematic informáticos TEMS desde diferentes perspectivas por aquellos que están asociados con su adquisición, requisitos, desarrollo, uso, evaluación, apoyo, manteni- miento, la calidad aseguramiento y control y auditoría. Los modelos pueden ser, por ejemplo, ser usado para operadores desa-, adquirentes, garantía de calidad y personal de control, y los evaluadores independientes, en particular los responsables de especificar y evaluar la calidad del producto de software. Las actividades durante el desarrollo de pro- ducto que pueden beneficiarse de la utilización de los modelos de calidad incluyen • la identificación de los requisitos de software y del sistema; • la validación de la amplitud de una definición de requisitos; • la identificación de software y sistema de diseño objetivos; • la identificación de software y sistema de prueba objetivos; • la identificación de los criterios de control de calidad como parte de seguro de calidad; • la identificación de los criterios de aceptación para un producto de software y / o el sistema informático de software intensivo; • el establecimiento de medidas de calidad tics carac- en apoyo de estas actividades. algunos documentos en la serie de cuadrados acuerdo específica- mente con la característica de facilidad de uso. El formato de la Industria común (CIF) para ING usabilidad informecomenzó en el Instituto Nacional de Estándares

Evaluación del formato (cuadrados) Industria Common (CIF) de la Usabilidad

Una familia de estándares internacionales, designados con la industria de formatos comunes (CIF), documenta la especificación y evaluación de la usabilidad de los sistemas interactivos. Proporciona una visión general general del marco CIF y contenidos, defini- ciones, y la relación de mentos el marco ele-. Los usuarios previstos del marco se identifican, así como las situaciones en las que el marco se puede aplicar. Los supuestos y las limitaciones del marco también se enumeran. El contenido de marco incluye lo siguiente: • terminología coherente y clasificación de especificación, evaluación y presentación de informes; • una definición del tipo y alcance de los formatos y la estructura de alto nivel que se utilizará para documentar la información requerida y los resultados de la evaluación. La familia de normas CIF es aplicable a los productos de software y hardware utilizados para la pre- tareas definidas. Los elementos de información están destinadas a ser utilizado como parte de la documentación de nivel de sistema resultante de los procesos de desarrollo tales como los que en la norma ISO 9241 a 210 y ISO / IEC JTC 1 / SC estándares 7 de proceso. La familia CIF centra en documentar aquellos elementos necesarios para el diseño y desarrollo de sistemas utilizables, en lugar de prescribir un proceso específico. Está destinado a ser utilizado en conjunción con las normas internacionales existentes, INCLUYENDO ISO 9241, ISO 20282, ISO / IEC 9126, y la serie cuadrada (ISO / IEC 25000 a ISO / IEC 25099). La familia de normas CIF no prescribe cualquier tipo de método, ciclo de vida o proceso.

y Tecnología (NIST) de Estados Unidos y se trasladó a la norma ISO / IEC JTC 1 / SC 7 para fines de estandarización.

SEGUNDO-34 Guía SWEBOK® V3.0

No todo el mundo está de acuerdo con la taxonomía de las características de calidad en la norma ISO / IEC 25010. La norma tiene un factor de calidad llamado “fiabilidad” que tiene

subfactores de la madurez, disponibilidad, tolerancia a fallos, y capacidad de recuperación. IEC TC 65, que es responsable de las normas sobre “dependabildad” define ese término como com- no

cuantitativo ISO / IEC 25060 25064 a través del software Engineer--ing de software Requisitos de calidad del producto y la

Posite de fiabilidad, facilidad de mantenimiento y soporte de manteni- miento. Otros utilizan el término “fiabilidad”

Apéndice B B-35

para denotar una medida definida por una ecuación matemática. El desacuerdo sobre el uso de estas palabras significa que las normas sobre la materia son inherentemente no alineado. Unos pocos se verá más adelante, pero las palabras como los mencionados más arriba pueden tener diferentes significados en diferentes estándares.

Un enfoque para el logro de la calidad del software es llevar a cabo un amplio programa de verificación y validación. IEEE Std. 1012 es probablemente estándar más ampliamente aplicada del mundo en esta sub-Ject. Una revisión se publicó recientemente.

IEEE Std. 1012-2012 estándar para el sistema y SoftIEEE Std. 982,1-2.005 estándar para Diccionario de Medidas de los aspectos del software de Fiabilidad

Un diccionario estándar de las medidas de los aspectos del software de fiabilidad para evaluar y predecir la fiabilidad, facilidad de mantenimiento, y la disponibilidad de cualquier sistema de software; en particular, se aplica a los sistemas de software de misión crítica. IEEE Std. 1633-2008 Práctica Recomendada para la fiabilidad del software

Los métodos para evaluar y predecir su confiabilidad de software, basado en un enfoque de ciclo de vida para la ingeniería de la fiabilidad del software, se prescriben en esta práctica recomendada. Se proporciona la información necesaria para la aplicación de la fiabilidad del software de medición (SR) a un proyecto, establece una base para la construcción de métodos consistentes, y establece el principio básico para la recogida de los datos necesarios para evaluar y predecir la fiabilidad del software. La práctica recomendada prescribe cómo cualquier usuario puede participar en las evaluaciones y predicciones SR.

Artículos de Verificación y Validación

Verificación y validación procesos (V & V) se utilizan para determinar si el desarrollo Productos de una actividad dada ajustarse a las exigencias de que la actividad y si el producto cumple su uso previsto y las necesidades del usuario. requisitos del proceso de ciclo de vida de V & V se especifican para niveles de integridad de dife- rentes. El alcance de los procesos de V & V abarca sistemas, software y hardware, e incluye sus interfaces. Esta norma se aplica a los sistemas, el software y el hardware se está desarrollando, mantenida o reutilizados [legacy, comercial plataforma frente-el-(COTS), artículos nondevelopmental]. El término software también incluye el firmware y el microcódigo, y cada uno de los términos del sistema, software y hard- ware incluye documentación. procesos de V & V incluyen el análisis, evaluación, revisión, inspec- ción, evaluación, y el ensayo de los productos.

Hay otras normas que apoyan los procesos ficación y validación veri. Uno describe las técnicas para llevar a cabo revisiones y auditorías durante un proyecto de software.

IEEE tiene un estándar global para el software la calidad del producto que tiene un alcance similar al el serie 250xx ISO / IEC descrito anteriormente. Su terminología difiere de la serie ISO / IEC, pero es sustancialmente más compacto.

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

Cinco tipos de revisiones de software y auditorías, junto con los procedimientos necesarios para la ejecuIEEE Std. 1061-1998 Estándar de Calidad de Software Metodología Métrica

se define una metodología para establecer los requisitos de calidad y definición, ejecución, análisis y validación de las métricas de calidad de

SEGUNDO-36 procesoGuía y SWEBOK® V3.0

de producto de software. La metodología abarca todo el ciclo de vida del software.

ción de cada tipo, se definen en esta norma. Esta norma se refiere únicamente a las revisiones y auditorías; procedimientos para la determinación de la sidad nece- de una revisión o auditoría no están definidos, y la disposición de los resultados de la revisión o auditoría no se especifica. Tipos incluidos son revisiones de la dirección, revisiones técnicas, inspecciones, walk-through, y auditorías.

Apéndice B B-37

En muchos casos, una base de datos de software de anoma- reside se utiliza para apoyar las actividades de verificación y validación. La siguiente norma sugiere cómo deben clasificarse anomalías.

utilizar de cada parte y el uso combinado de múltiples partes. La cobertura de la garantía para un servicio que es operado y administrado de forma continua no está cubierto en la norma ISO / IEC 15026.

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

La segunda parte de la norma describe la estructura de un “caso de aseguramiento”, que pretende ser un argumento estructurado que la propiedad crítica se ha logrado. Es una generalización de diversos constructos específicos de dominio como “casos de seguridad”.

Esta norma proporciona un enfoque uniforme para la clasificación de las anomalías de software, independientemente del momento en que se originan o cuando se encuencados dentro del proyecto, producto o sistema de vida ciclo. Los datos de clasificación pueden ser utilizados para una varie- dad de propósitos, incluyendo causal defecto análi- sis, gestión de proyectos, y la mejora de procesos de software (por ejemplo, para reducir la probabilidad de inserción de defectos y / o aumentar la probabilidad de detección de defectos temprano).

En algunos sistemas, una propiedad particular del software es tan importante que requiere un tratamiento especial más allá de la proporcionada por un programa de verificación y validación convencional. El término emergente para este tipo de tratamiento es “sistemas de garantía de software.” Los ejemplos incluyen la seguridad, la privacidad, de alta seguridad, y ultrareliability. La norma 15026 está en desarrollo para hacer frente a tales situaciones. La primera parte del estándar de cuatro partes ofrece la terminología y los conceptos utilizados en las partes restantes. Fue escrito antes de las otras partes y ahora está siendo revisada para el acuerdo com- pleta con los otros.

IEEE Std. 15026,2-2.011 adopción del estándar ISO / IEC 15026-2: 2011 Sistemas y ingeniería de software-Systems y Software Assurance-Parte 2: Aseguramiento de la caja

ISO / IEC 15026-2: 2011 es adoptada por esta Dard Están-. ISO / IEC 15026-2: 2011 especifica los requisitos mínimos para la estructura y contenido de un caso de garantía para mejorar la coherencia y la comparabilidad de los casos de aseguramiento y para faci- comunicaciones tate interesados, las decisiones de ingeniería y otros usos de los casos de aseguramiento. Un caso de aseguramiento incluye un reclamo de primer nivel para una propiedad de un sistema o producto (o un conjunto de reclamaciones), la argumentación sistemática con respecto a esta reclamación, y la evidencia y supuestos explícitos que subyacen a esta argumentación. Discutiendo a través de múltiples niveles de las reivindicaciones subordinadas, esta argumentación estructurado conecta la reclamación de nivel superior para las pruebas y supuestos. casos de Aseguramiento generalmente se desarrollaron para apoyar las reivindicaciones en áreas tales como la seguridad, la fiabilidad, maintaincapacidad, factores humanos, operatividad y

seguridad, IEEE Std. ción 15026,1-2.011 Trial-Uso estándar adopción de la norma ISO / IEC TR 15026-1: 2010 Sistemas y de Software Ingeniería de SoftwareSystems y aseguramiento de la-Parte 1: Conceptos y Vocabulario

Este estándar de prueba de uso adopta la norma

ISO / IEC TR 15026-1: 2010, que define los términos y esta- lishes un conjunto amplio y organizado de los conceptos y sus relaciones para el software y los sistemas de seguridad, estableciendo así una base para la comprensión común de los conceptos y cen- tral principios de la norma ISO / IEC 15026 a través de sus comu-

SEGUNDO-38 Guía nidades de usuarios. SWEBOK® V3.0

Proporciona información a los usuarios de las partes subsecuentes de la norma ISO / IEC 15026, incluyendo la

Aunque estos casos de garantía son a menudo llamados por los nombres más específicos, por ejemplo, el caso de seguridad o la fiabilidad de dichas y mantenibilidad caso (R & M). ISO / IEC 15026-2: 2011 no impone requisitos sobre la calidad de los contenidos de un caso de garantía y no requiere el uso de una terminología particular o de representación gráfica. Así mismo, no impone requisitos sobre los medios de implementación física de los datos, incluidos los requisitos para la redundancia o la colocación.

En muchos sistemas, algunas porciones son críticos para el logro de la propiedad deseada, mientras que otros sólo están

Apéndice B B-39

incidental. Por ejemplo, el sistema de control de vuelo deun avión de pasajeros es fundamental para la seguridad, pero el horno microondas no lo es. Convencionalmente, las diversas partes se asignan niveles de criticidad “” para indicar su significación para el logro general de la propiedad. La tercera parte de la ISO / IEC 15026 describe cómo se hace. Esta parte será revisado para un mejor ajuste con el resto de la norma 15026.

ISO / IEC 15026-3: niería-Sistemas y Aseguramiento de la Parte 3-2011 Software de Sistemas y Software Engineers: Niveles de Integridad del sistema

TR 15026-1 proporciona información y referencias adicionales para ayudar a los usuarios de la norma ISO / IEC 15026-3: 2011. ISO / IEC 15026-3: 2011 no requiere el uso de los casos de aseguramiento descritos en la norma ISO / IEC 15026-2, pero describe cómo los niveles de integridad y de garantía de los casos pueden trabajar juntos, especialmente en la definición de las especificaciones de los niveles de integridad o mediante el uso de la integridad los niveles dentro de una porción de una caso de aseguramiento.

La parte final de 15026 proporciona orientación adicional para la ejecución de los procesos del ciclo de vida de 12207 y 15288 cuando se requiere un sistema o software para conseguir una propiedad importante.

ISO / IEC 15026-3: 2011 especifica el concepto de niveles de integridad con nivel de integridad correspondiente requisitos que se requieren para ser conocido en orden para demostrar la consecución del nivel de integridad. Se coloca requisitos sobre y recomienda ods met para la definición y el uso de los niveles de integridad y de sus requisitos de nivel de integridad, incluyendo la asignación de niveles de integridad a los sistemas, productos de artículos blandos, sus elementos, y dependencias exter- nos pertinentes. ISO / IEC 15026-3: 2011 es aplicable a los siste- mas de software y está diseñada para uso por:

ISO / IEC 15026-4: 2012 Sistemas y Software Ingeniería-Sistemas y de Software Assurance-Parte 4: Control de calidad en el ciclo de vida

• definidores de los niveles de integridad, tales como organizaciones de la industria y profesionales, organizaciones de estándares y agencias gubernamentales; • usuarios de los niveles de integridad como desarrolladores y mantenedores, proveedores y compradores, usuarios y asesores de sistemas o software, y para el puerto SUP- administrativa y técnica de sistemas y / o productos de software.

Esta parte de la norma ISO / IEC 15026 proporciona orientación y recomendaciones para la realización de pro- cesos seleccionados, actividades y tareas para los sistemas y productos de software que requieren las reclamaciones de garantía de las propiedades seleccionadas de una atención especial, llamadas propiedades críticas. Esta parte de la norma ISO / IEC 15026 especifica una lista erty independiente prop- de procesos, actividades y tareas para lograr la reclamación y mostrar el logro de la reclamación. Esta parte de la norma ISO / IEC 15026 establece los procesos, actividades, tareas, orientación y recomendaciones en el contexto de un modelo de ciclo de vida definido y un conjunto de procesos de ciclo de vida para el sistema y / o gestión del ciclo de vida del software.

Un uso importante de los niveles de integridad es mediante pinzas SUP- y adquirentes en los acuerdos; por ejemplo, para ayudar a asegurar las características de seguridad, económico, o de seguridad de un sistema o producto entregado. ISO / IEC 15026-3: 2011 no prescribe una

Los estándares siguientes se ocupa de una seguridad que a menudo se identifica como propiedad-crítico. Originalmente fue desarrollado en cooperación con la industria de la energía nuclear de Estados Unidos.

SEGUNDO-40 conjuntoGuía específico SWEBOK® V3.0

de niveles de integridad o su

requisitos de nivel. Además, no se pre- escriba la forma en que el uso nivel de integridad se interallado con el conjunto del sistema o software inge- niería procesos del ciclo de vida. ISO / IEC 15026-3: 2011 se puede utilizar solo o con otras partes de la norma ISO / IEC 15026. Se puede utilizar con una variedad de análisis de riesgos y desarrollo enfoques técnicos y especializados. ISO / IEC

integridad IEEE Std. 1228-1994 estándar para los planes de seguridad del software

Se establecen los requisitos mínimos aceptables para el contenido de un plan de seguridad de software. Esta norma se aplica al plan de seguridad de software utilizado para el desarrollo, adquisición, mantenimiento y retirada de software crítico.

Apéndice B B-41

Esta norma requiere que el plan se preparará en el marco del pro- grama de seguridad del sistema. Sólo se incluyen los aspectos de seguridad del software. Esta norma no contiene especial disposiciones necesarias para el software utilizado en los sistemas de distri- buido o en procesadores paralelos.

Conocimiento (SWEBOK)

ver general

Un estándar de 7 SC proporciona un marco para las comparaciones entre las certificaciones de profesionales de la ingeniería de software. Que norma indica que las áreas consideradas en la certificación debe estar correlacionado con la Guía SWEBOK.

tratamientos clásicos sugieren que la “verificación” trata de los métodos de evaluación estática y que ofertas de “prueba” con la evaluación dinámica metods. tratamientos recientes, incluyendo la norma ISO / IEC 29119, proyecto están difuminando esta distinción, aunque, por lo que aquí se mencionan las normas de ensayo.

ISO / IEC 24773: 2008 Ingeniería de Software-certificación de Profesionales de Ingeniería de Software

ISO / IEC 24773: 2008 establece un marco para comparación de los esquemas de certificación

software IEEE Std. 829-2008 estándar para el software y Sys tem Documentación de la comprobación

Consulte Software Testing KA IEEE Std. 1008-1987 estándar para el software de pruebas unitarias

Consulte Software Testing KA IEEE Std. 26513-2010 La adopción del estándar ISO / IEC 26513: 2009 Sistemas y ingeniería de software-Requisitos para Probadores y revisores de Documentación

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

profesionales de la ingeniería. Un esquema de certificación es un conjunto de requisitos de certificación para profesionales de la ingeniería de software. ISO / IEC 24773: 2008 especifica los artículos que se requiere un esquema para contener e indica lo que debe ser definida para cada elemento. ISO / IEC 24773: 2008 facilitará la Portabilidad de ingeniería de software tifications cierprofesionales entre los diferentes países o organiza- ciones. En la actualidad, diferentes países y organizaciones han adoptado diferentes enfoques sobre el tema, que se implementan por medio de reglamentos y estatutos. La intención de la norma ISO / IEC 24773: 2008 es estar abierto a éstos individual y específico se acerca al proporcionar un marco para expresarlos en un esquema común que puede conducir a la comprensión.

Consulte Software Testing KA

INGENIERÍA DE SOFTWARE LA PRÁCTICA PROFESIONAL IEEE es un proveedor de productos relacionados con el CER tificación de los practicantes profesionales de la ingeniería de software. La primera ya se ha descrito, la Guía para la Ingeniería de Software de Administración de

Conocimiento. La Guía SWEBOK ha sido adoptado por la norma ISO / IEC como un esquema de los conocimientos que los ingenieros de software pro- fesionales deben tener.

SEGUNDO-42 Guía SC 7 estáV3.0 elaborando SWEBOK®

una guía que

suplementar 24773.

ECONOMÍA INGENIERÍA DE SOFTWARE

No hay normas se asignan a este KA. FUNDAMENTOS DE INFORMATICA No hay normas se asignan a este KA.

MATEMÁTICO CIMIENTOS ISO / IEC TR 19759: 2005 Software Engineering-Guía de los Fundamentos de Ingeniería de Software

No hay normas se asignan a este KA.

Apéndice B B-43

FUNDAMENTOS DE INGENIERÍA No hay normas se asignan a este KA. ACTUAL STAYING Este artículo era obsoleto el momento en que se redactó. Algunos lectores necesitan saber cómo conseguir designaciones y descripciones de las normas vigentes. En esta sección se describen algunos recursos útiles. DONDE ENCONTRAR NORMAS La lista de normas publicadas por ISO / IEC JTC 1 / SC 7 se puede encontrar en www.iso.org/iso/iso_ Catálogo / catalogue_tc / catalogue_tc_browse. htm? commid = 45086. Debido a que la URL puede cambiar, los lectores podrían tener que desplazarse a la lista. comenzará a laswww.iso.org/ ISO / store.htm, A continuación, haga clic en “Catálogo de estándares de exploración”, luego “navegar por el TC,” y luego “JTC 1” y luego “SC 7.” Encontrar la lista actual de normas para S2ESC es un poco más difícil. comenzará a lashttp: // estándares. ieee.org/. En el cuadro de búsqueda en “Buscar Standards,” tipo “S2ESC.” Esto debería producir una lista de normas publicadas por el cual es responsable S2ESC. Tenga en cuenta que las bases de datos accesibles son compilaciones. Al igual que cualquier base de datos, que pueden contener errores que conducen a resultados de búsqueda incompletos. DONDE OBTENER LAS NORMAS Algunos lectores querrán obtener normas descritas en este artículo. Lo primero que debe saber es que algunas normas internacionales están disponibles gratuitamente para su uso individual. La lista actualizada de las normas ISO / IEC disponible bajo los términos se encuentra enhttp://standards.iso.org/ittf/ PubliclyAvailableStandards / index.html. Uno de los estándares disponibles públicamente es la adopción de ISO / IEC Guía del SWEBOK, ISO / IEC 19759.

Las definiciones contenidas en la norma ISO / IEC / IEEE 24765, Sistema y Software Vocabulario, están libremente disponibles en www.computer.org/sevocab. Sin embargo, la gran mayoría de las normas no son libres. normas ISO / IEC generalmente se compran desde el organismo nacional de normalización del país en que se vive. Por ejemplo, en los EE.UU., las normas internacionales se pueden adquirir en el Instituto Americano de Estándares Nacionales enhttp://webstore.ansi.org/. Alternativamente, Standards se pueden comprar directamente de ISO / IEC enwww.iso.org/iso/store.htm. Cabe señalar que cada nación es libre de fijar sus propios precios, por lo que puede ser útil para comprobar ambas fuentes. Los estándares IEEE pueden estar disponibles para usted de forma gratuita si su empleador o la biblioteca tiene una suscripción a IEEE Xplore:http://ieeexplore.ieee.org/. Algunas suscripciones a Xplore proporcionan acceso sólo a los resúmenes de las normas; El texto completo puede entonces ser adquirido a través de Xplore. Alternativamente, las normas pueden ser adquiridos a través de la tienda de los estándares IEEE enwww.techstreet.com/ieeegate.html. Cabe señalar que la IEEE-SA veces haces normas en grupos disponibles con un descuento considerable. Finalmente, el lector debe tener en cuenta que los estándares IEEE que ha adoptado de ISO / IEC, las normas que la norma ISO / IEC tiene “vía rápida” de la IEEE, y las normas que se han desarrollado o se revisan en conjunto están disponibles de ambas fuentes. Para todas las normas descritas en este artículo, la versión IEEE y la versión ISO / IEC son sustancialmente idénticos. Las versiones respectivas pueden tener diferentes frontal y la materia de nuevo pero los cuerpos son idénticos. DONDE VER LA GUÍA SWEBOK La Guía SWEBOK se publica bajo un derecho de autor IEEE. La versión actual de la Guía SWEBOK es gratuita para el público enwww. swebok.org/. La adopción de ISO / IEC Guía del SWEBOK, ISO / IEC TR 19759, es una de las normas de libre disposición.

SEGUNDO-44 Guía SWEBOK® V3.0

RESUMEN lista de las normas Número y Título (enumerados en orden de número) IEEE Std. 730-2002 estándar para los planes de garantía de calidad de software IEEE Std. 828-2012 Norma para la Gestión de la Configuración de Sistemas e Ingeniería de Software IEEE Std. 829-2008 estándar para el software y la prueba del sistema Documentación IEEE Std. 982,1-2.005 estándar para Diccionario de Medidas de la Aspectos de software de Fiabilidad IEEE Std. 1008-1987 estándar para el software de pruebas unitarias IEEE Std. 1012-2012 estándar para el sistema y verificación de software y Validación IEEE Std. 1016-2009 estándar para la Tecnología de la InformaciónSystems Las de diseño de para software de diseñode software y IEEEdescripciones Std. 1028-2008 estándar las revisiones

Más relevantes KA SW Calidad Gestión de la Configuración SW Prueba de SW SW Calidad Prueba de SW SW Calidad SW Diseño SW Calidad

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

SW Calidad

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

SW Calidad

IEEE Std. 1062-1998 Práctica Recomendada para la adquisición de software IEEE Std. 1074-2006 estándar para desarrollar una vida de Proyectos de Software Proceso del1.175,1-2002 ciclo IEEE Std. Guía para el CASO Clasificación

Ingeniería SW administración Proceso de Ingeniería de SW

Interconnections- herramienta y Descripción

Ingeniería SW Modelos y Métodos

IEEE Std. 1175,2-2.006 Práctica Recomendada para la caja de herramienta de interconexión-Caracterización de las interconexiones

Ingeniería SW Modelos y Métodos

IEEE Std. 1.175,3-2004 estándar para la caja de herramienta Ingeniería SW Interconnections- modelo de referencia para especificar el Modelos y Métodos comportamiento del software IEEE Std. 1.175,4 a 2.008 estándar para CASE Modelo de Referencia de Ingeniería SW herramientas Interconnections- para su comportamiento Especificación Modelos y Métodos IEEE Std. 1220-2005 (también conocido como ISO / IEC 26702: 2007) estándar para la aplicación y gestión del proceso de Ingeniería de Sistemas IEEE Std. 1228-1994 estándar para los planes de seguridad del software

Proceso de Ingeniería de SW

IEEE Std. 1320,1-1998 estándar para Modelado funcional Lenguajesintaxis y la semántica de IDEF0

Ingeniería SW Modelos y Métodos

IEEE Std. 1320,2-1998 estándar para Modelado Conceptual Lenguajesintaxis y la semántica de IDEF1X97 (IDEFobject)

Ingeniería SW Modelos y Métodos

IEEE Std. 1490-2011 Guía de implantación de la Gestión de Proyectos Institute (PMI ®) estándar, una guía para la Dirección de Proyectos del Conocimiento (Guía del PMBOK®) -Cuarto Edición

Ingeniería SW administración

IEEE Std. 1517-2010 estándar para la tecnología de la información del sistema y del software-Vida Procesos de reutilización de procesos de ciclo

SW Calidad

Proceso de Ingeniería de SW

Apéndice B B-45

Número y Título (enumerados en orden de número) IEEE Std. 1633-2008 Práctica Recomendada para la fiabilidad del software IEEE Std. 12207-2008 (también conocido como ISO / IEC 12207: 2008) estándar para Sistemas de SoftwareLa Ingeniería Software-procesos de 14102: ciclo de2008 vida IEEE Std.y14102-2010 adopcióndedel estándar ISO / IEC Tecnología de la Información-Directrices para la evaluación y selección de herramientas CASE

Más relevantes KA SW Calidad Proceso de Ingeniería de SW Ingeniería SW Modelos y Métodos

ISO / IEC 14143 [seis partes] Tecnología de la Información-funcional de Requisitos SW software de medición-Medida del tamaño IEEE Std. 14471-2010 Guía de implantación de la norma ISO / IEC TR 14471: 2007 Tecnología de la Información-Ingeniería de SoftwareDirectrices para la adopción de las herramientas CASE

Ingeniería SW Modelos y Métodos

IEEE Std. 14764-2006 (también conocido como ISO / IEC 14764: 2006) Mantenimiento SW estándar para Software ciclo de vidaTrial-Uso del software de ingeniería y procesos de IEEE Std.del 15.026,1-2011 Adopción estándar de la norma mantenimiento ISO / IEC TR 15026-1: 2010 Sistemas y de Ingeniería de SoftwareSW Calidad Sistemas y de Software Assurance-Parte 1: Conceptos y Vocabulario IEEE Std. 15026,2-2.011 adopción del estándar ISO / IEC 15026- 2: 2011 Sistemas y de Ingeniería de Software-Systems y Software Assurance-Parte 2: Aseguramiento de la caja ISO / IEC 15026-3 Sistemas y de Ingeniería de Software-Sistemas y de Software Assurance-Parte 3: Niveles de Integridad del sistema ISO / IEC 15026-4: 2012 Sistemas y de Ingeniería de SoftwareSistemas y de Software Assurance-Parte 4: Control de calidad en el ciclo vida IEEEde Std. 15288-2008 (también conocido como ISO / IEC 15288: 2008) estándar para Sistemas de ciclo deSistemas vida del ysoftware deIngenieríaingeniería-Sistema ISO / IECy/procesos IEEE 15289: 2011 Software contenido del Ciclo de Vida de Productos de Información (Documentación) ISO / IEC 15504 [diez partes] Tecnología de la Información-Proceso Evaluación IEEE Std. 15939-2008 La adopción del estándar ISO / IEC 15939: 2007 Sistemas y Procesos de Ingeniería de Software de Mediciones ISO / IEC 15940: 2006 Tecnología de la Información Ingeniería de SoftwareServicios de entorno IEEE Std. 16085-2006 (también conocido como ISO / IEC 16085: 2006) estándar para Sistemas y Gestión de Riesgos de Ingeniería de Software-Software Ciclo de procesosISOVida / IEC / IEEE 16326: 2009 de Gestión de Sistemas y de Ingeniería de Software-Life Cycle Procesos-Proyecto

SW Calidad SW Calidad SW Calidad Proceso de Ingeniería de SW Proceso de Ingeniería de SW Proceso de Ingeniería de SW Ingeniería SW administración Ingeniería SW Modelos y Métodos Ingeniería SW administración Ingeniería SW administración

ISO / IEC 19501: 2005 Tecnología de la Información-distribuido abierto Ingeniería SW Modeling Language (UML) Versión 1.4.2 Procesamiento-Unificado Modelos y Métodos

SEGUNDO-46 Guía SWEBOK® V3.0

Número y Título (enumerados en orden de número) ISO / IEC 19505: 2012 [dos partes] a objetos Grupo de Tecnología de Gestión de Información Unified Modeling Language (UML del OMG)

Más relevantes KA Ingeniería SW Modelos y Métodos

ISO / IEC 19506: 2012 Tecnología de la Información-Object Management Group arquitectura dirigida Modernización (ADM) Conocimiento Descubrimiento Meta-Modelo (KDM)

Ingeniería SW Modelos y Métodos

ISO / IEC 19507: 2012 Tecnología de la Información-Object Management Group Object Constraint Language (OCL)

Ingeniería SW Modelos y Métodos

ISO / IEC TR 19759: 2005 Ingeniería de Software-Guía de la Ingeniería de Software de Administración de Conocimiento (SWEBOK)

[General]

ISO / IEC 19761: 2011 Ingeniería de Software-CÓSMICO: Un Tamaño Funcional Método de medición ISO / IEC 20000-1: 2011 Tecnología de la Información-Servicio de Gestión-Parte 1: Requisitos del sistema de gestión de servicios

Requisitos SW Proceso de Ingeniería de SW

ISO / IEC 20926: 2009 Software e Ingeniería de Sistemas-SoftwareMedición IFPUG funcional Tamaño Método de medición

Requisitos SW

ISO IEC 20968/2002: Manual de Prácticas de Análisis de Puntos de Función de conteo de Ingeniería de Software-MK II

Requisitos SW

ISO / IEC 24570: 2005 Ingeniería de Software-NESMA funcional tamaño de la medida Método Versión 2.1-Definiciones y Requisitos SW Lineamientos contando para la Aplicación del Análisis de Puntos de Función IEEE Std. 24.748,1-2011 Guía de implantación de la norma ISO / IEC Proceso de Ingeniería TR 24748-1: 2010 de SW Ingeniería de Sistemas y Gestión-Life-Cycle Software Parte 1: Guía para la Gestión del Ciclo de Vida IEEE Std. 24748,2-2012 Guía de implantación de la norma ISO / IEC TR 24748-2: 2011 Sistemas y de Ingeniería de Software de Gestión de Vida-Parte 2 Ciclo: Guía para la aplicación de la norma ISO / IEC 15288 (Procesos ciclo de vidaGuía del sistema) IEEE Std. del 24748-3: 2012 de implantación de la norma ISO / IEC

Proceso de Ingeniería de SW

TR 24748-3: 2011 Sistemas y de Ingeniería de Software de Gestión-Life-Cycle Parte 3: Guía para la aplicación de la norma ISO / IEC 12207 (procesos del ciclo vida del software) ISO / de IEC / IEEE 24765: 2010 Sistemas y Software

Proceso de Ingeniería de SW

Ingeniería-Vocabulario ISO / IEC TR 24772: 2013 Idiomas tecnología de la información de programación - Orientación para evitar vulnerabilidades en lenguajes de programación a través de selección de idioma y Uso ISO / IEC 24773: 2008 Ingeniería de Software-Certificación de Software Los profesionales de ingeniería IEEE Std. 24774: 2012 Guía de implantación de la norma ISO / IEC TR 24474: 2010 Sistemas y de Ingeniería de Software-Life Cycle Directrices para Management- Descripción del Proceso ISO / IEC 25000: 2005 Software de ingeniería y software Requisitos de calidad del producto y Evaluación (cuadrados) -Guía de cuadrar

[General] Construcción SW SW Ingeniería Práctica Profesional Proceso de Ingeniería de SW SW Calidad

Apéndice B B-47

Número y Título (enumerados en orden de número) ISO / IEC 25000 25099 a través de software de ingeniería y software Requisitos de calidad del producto y Evaluación (cuadrados) ISO / IEC 25010: 2011 Sistemas y de Ingeniería de Software-Systems

Más relevantes KA

y requisitos de calidad de software y Evaluación (cuadrados) -Sistema y modelos de calidad del software

SW Calidad

Formato ISO / IEC 25060 25064 a través de software de ingeniería y software Requisitos de calidad del producto y Evaluación (cuadrados) Industria -Common (CIF) de la Usabilidad ISO / IEC / IEEE 26511: 2012 Sistemas y Software INGENIERÍA-Requisitos para los gerentes de Documentación del ISOusuario / IEC / IEEE 26512: 2011 Requisitos de Sistemas y Software

SW Calidad

SW Calidad Ingeniería SW administración

Ingeniería SW ingeniería- para adquirentes y proveedores de Documentación del usuario administración IEEE Std. 26513-2010 La adopción del estándar ISO / IEC 26513: 2009 Sistemas y de Ingeniería de Software-Requisitos para Probadores y Prueba de SW revisores de Documentación IEEE Std. 26514-2010 La adopción del estándar ISO / IEC 26514: 2008 Sistemas y de Ingeniería de Software-Requisitos para los diseñadores y desarrolladores de documentación del usuario ISO / IEC / IEEE 26515: 2012 Sistemas y Software Ingenieríadesarrollo de la documentación del usuario en un entorno ágil ISO / IEC 29110 [varias partes] Ingeniería de Software-ciclo de vida de los perfiles de entidades muy pequeñas (VSE) / IEC / IEEE 29119 [cuatro partes] (Borrador) Software ISO y Sistemas Las pruebas de ingeniería en software

SW Diseño Ingeniería SW Modelos y Métodos Proceso de Ingeniería de SW Prueba de SW

ISO / IEC / IEEE 29148: 2011 Sistemas y de Ingeniería de Software-Life Requisitos SW Ciclo procesos de Ingeniería de Requisitos ISO / IEC / IEEE 42010: 2011 Sistemas y Software IngenieríaArquitectura Descripción

SW Diseño

IEEE Std. 90003: 2008 Guía de implantación de la norma ISO / IEC 90003: 2004 Ingeniería de Software-Directrices para la aplicación de la norma ISO 9001: 2000 para Programas informáticos

SW Calidad

LISTA DE REFERENCIA ANEXO C CONSOLIDADO La lista de referencias consolidado identifica todos los materiales de referencia recomendados (a nivel de número de sección) que acompañan a la descomposición de los temas dentro de cada área de conocimiento (KA). Esta lista de referencias consolidado es adoptada por la certificación de ingeniería de software y productos asociados de desarrollo profesional ofrecido por el IEEE Computer Society. Editores KA utilizan las referen- cias asignadas a su KA por la Lista de referencia consolidado como sus referencias recomendadas. En conjunto esta lista de referencia es consolidado • Completar: Cubriendo todo el ámbito de la Guía SWEBOK. • Suficiente: Proporcionar suficiente información para describir “generalmente aceptadas” conocimiento. • Consistente: No es proporcionar conocimientos contradictorios ni prácticas conflictivas. • Creíble: Reconocido como proporcionar experto tratamiento. • Actual: Tratar el tema de una manera que sea acorde con los conocimientos actualmente generalmente aceptada. • Sucinta: Lo más corto posible (tanto en número de elementos de referencia y en el número total de páginas) sin fallar otros objetivos. [1 *] JH Allen et al, software de seguridad Ingeniería:. Guía para los gerentes de proyecto, Addison-Wesley, 2008. [2 *] M. Bishop, Computer Security: Arte y Ciencia, Addison-Wesley, 2002. [3 *] B. Boehm y R. Turner, Balancing agilidad y disciplina: Una guía para los perplejos, Addison-Wesley, 2003.

[4 *] F. Bott et al., Cuestiones profesional en Ingeniería de Software, 3ª ed., Taylor & Francis, 2000. [5 *] JG Brookshear, Ciencias de la Computación:. Una visión general, 10ª ed, Addison-Wesley, 2008. [6 *] D. Budgen, Diseño de software, 2ª ed., Addison-Wesley, 2003. [7 *] EW Cheney y DR Kincaid, Numérica Matemáticas y Computación, 6 ª ed., Brooks / Cole, 2007. [8 *] P. Clements et al, el software de documentación: Arquitecturas. Vistas y más allá, 2ª ed, Pearson Education, 2010.. [9 *] RE Fairley, gestionar y liderar proyectos de software, Wiley-IEEE Computer Society Press, 2009. [10 *] D. Galin, Calidad de Software: de la teoría a la implementación, Pearson Educación, SA, 2004. [11 *] E. Gamma et al, patrones de diseño:.. Elementos de software orientado a objetos reutilizables, 1st ed, AddisonWesley Professional, 1994. [12 *] P. Grubb y AA Takang, Mantenimiento de Software: Conceptos y Práctica., 2ª ed, Editorial Científico Mundial, 2003. [13 *] AMJ Hass, Principios y Prácticas de gestión de configuración, 1st ed., AddisonWesley, 2003.

Apéndice B B-49

C-1

Guía de C-2 SWEBOK® V3.0

[14 *] E. Horowitz et al., Algoritmos de ordenador, 2ª ed., Silicon Press, 2007.

[25 *] S. Naik y P. Tripathy, pruebas de software y aseguramiento de la calidad: Teoría y Práctica, Wiley-Spektrum, 2008.

[15 *] IEEE / ACM Fuerza de Tarea Conjunta de CS Software Ética de ingeniería y prácticas profesionales, “Software Ingeniería Código de Ética y Práctica Profesional (Versión 5.2),” 1999; www.acm.org/serving/se/code.htm.

[26 *] J. Nielsen, Ingeniería de usabilidad, 1st ed., Morgan Kaufmann, 1993.

[16 *] IEEE Std. 828-2012, Norma para Sistemas de Gestión de la Configuración de Software e Ingeniería, IEEE 2012. [17 *] IEEE Std. 1028-2008, software comentarios y auditorías, IEEE 2008. [18 *] ISO / IEC 14764 IEEE Std. 14764-2006, Software del ciclo de vida del software de ingeniería y procesos de mantenimiento, IEEE 2006. [19 *] SH Kan, métricas y modelos en Ingeniería de Software de Calidad, 2ª ed., AddisonWesley, 2002. [20 *] S. McConnell, código completo, 2ª ed., Microsoft Press, 2004. [21 *] J. McGarry et al, Practical Software de medición:. Información Objetivo para los decisores, Addison-Wesley Professional, 2001. [22 *] SJ Mellor y MJ Balcer, ejecutable UML:. Una Fundación para el Model-Driven Architecture, 1st ed, Addison-Wesley, 2002. [23 *] DC Montgomery y GC Runger, Estadística Aplicada y Probabilidad para Ingenieros, 4ª ed., Wiley, 2007. [24 *] JW Moore, La Hoja de Ruta de Ingeniería de Software:. Una guía basada en estándares, 1st ed, Wiley-IEEE Computer Society Press, 2006.

[27 *] L. y J. nulo Lobur, Lo Esencial de la Organización de Computadores y Arquitectura, 2ª ed., Jones and Bartlett Publishers, 2006. [28 *] M. Página-Jones, Fundamentos del Diseño orientado a objetos en UML, 1st ed., Addison-Wesley, 1999. [29 *] K. Rosen, Matemática Discreta y sus Aplicaciones, 7ª ed., McGraw-Hill, 2011. [30 *] A. Silberschatz, PB Galvin, y G. Gagne, Operating System Concepts, octava ed., Wiley, 2008. [31 *] HM Sneed, “Mantenimiento de Software como un Servicio de Oferta Marino”, Proc. IEEE Conf Int'l. Mantenimiento de Software (ICSM 08), IEEE, 2008, pp. 1-5. [32 *] I. Sommerville, Ingeniería de Software, 9ª ed., Addison-Wesley, 2011. [33 *] S. Tockey, Retorno de software: maximizar el retorno de su inversión en software, 1st ed, Addison-Wesley, 2004.. [34 *] G. Voland, Ingeniería de Diseño, segundo ed., Prentice Hall, 2003. [35 *] KE Wiegers, requisitos de software, segundo ed., Microsoft Press, 2003. [36 *] JM Wing, “Introducción de un especificador de métodos formales,” Computer, vol. 23, no. 9, 1990, pp. 8, 10-23.