1. Definiciones
1.1. Cro79: Lograr definir y atender las necesidades o requerimientos de los usuarios
1.2. Hum89: Lograr un excelente desempeño en el manejo del software
1.3. IBM: Calidad orientada al mercado.
1.4. NIST03: Calidad orientada al cliente
1.5. ISO90001-00: El grado en que un conjunto de caracterisiticas cumple con los requerimientos
2. 1. Fundamentos
2.1. Definir los requerimientos de calidad, sus caracteristicas, metodos y criterios de Evaluacion (Buena Comunicacion)
2.2. 1.1. Ingenieria de Software: Cultura y Etica
2.2.1. La IEEE ha desarrollado un codigo de etica para ayudar a los ingenieros de software a que refuerzen actitudes relacionadas con la calidad
2.2.2. Compartir el compromiso de calidad del software como parte de su cultura
2.3. 1.2. Valor y Costos de Calidad
2.3.1. El costo de la calidad se puede medir en cuanto a sus fallas internas o externas.
2.4. 1.3 Modelos y características de Calidad
2.4.1. La planificacion y la calificacion de la calidad de productos de software ha definifo 3 modelos: Calidad Interna, Externa y en uso (ISO 9126-01)
2.5. 1.4. Mejora de Calidad
2.5.1. La calidad de los productos de software se puede mejorar a traves de un proceso interactivo de mejora continua que requiere de gestion, coordinacion y retroalimentacion de procesos
2.5.1.1. 1. Ciclo de Vida del Software
2.5.1.2. 2. Error/Prevencion y deteccion
2.5.1.3. 3. Mejora de Calidad
2.5.1.3.1. La Calidad de un producto esta directamente ligado a la calidad del proceso utilizado para crearlo
2.5.2. Enfoques: Son herramientas con las que se puede cumplir los objetivos de calidad
2.5.2.1. TQM: Plan de Procesos
2.5.2.2. PDCA: Planear, Hacer, Verificar y Actuar
3. 2. Procesos de Gestión y Calidad de Software
3.1. 2.1 Garantia de Calidad de software (SQA)
3.1.1. Asegurarse de que el problema es claro y debidamente declarado y que los requisitos de la solución son adecuadamente definidos y expresados.
3.1.2. Busca mantener la calidad a través del desarrollo y mantenimiento del producto por la ejecución de una variedad de actividades en cada etapa que puede resultar en la identificación temprana de problemas.
3.2. 2.2 Verificacion y Validacion (V&V)
3.2.1. Aborda directamente la calidad de productos de software por mdio de técnicas de prueba que puede localizar defectos de forma que se pueden abordar
3.2.2. El proceso de V & V determina si los productos de un desarrollo determinado o actividad de mantenimiento se ajustan a el requisito de que la actividad, y si el producto final de software cumple su propósito y cumple con los requisitos del usuario.
3.3. 2.3 Revisiones y Auditorias
3.3.1. 2.3.1 Examenes de Gestion
3.3.1.1. Su propósito es monitorear el progreso en el desarrollo del software, determinando el estado de los planes y horarios establecidos, adecuándolos y confirmando los requisitos supervisando las inconsistencias.
3.3.1.2. Evaluar la eficacia de los enfoques de gestión utilizados.
3.3.1.3. Apoyar las decisiones acerca de los cambios y las acciones correctivas que se requieren durante un proyecto de software.
3.3.2. 2.3.2. Las revisiones técnicas
3.3.2.1. PROPÓSITO
3.3.2.1.1. Evaluar un producto de software para determinar su pertinencia
3.3.2.1.2. Identificar las diferencias de las especificaciones y los estándares aprobados
3.3.2.1.3. Determinar si el producto cumple con las especificaciones, se adhiere a las normas y los cambios son controlados
3.3.2.2. ROLES
3.3.2.2.1. Un líder
3.3.2.2.2. Un grabador
3.3.2.2.3. Personal para apoyar las actividades de revisión
3.3.2.3. REQUERIMIENTOS PREVIOS
3.3.2.3.1. Declarar los objetivos
3.3.2.3.2. El producto de software
3.3.2.3.3. La lista de temas relacionados con este producto
3.3.3. 2.3.3. Inspecciones
3.3.3.1. PROPÓSITO
3.3.3.1.1. Identificar anomalías de productos de software
3.3.3.2. QUIENES PARTICIPAN
3.3.3.2.1. Una persona ocupe un cargo directivo sobre cualquier miembro del equipo de inspección no podrá participar en la inspección.
3.3.3.2.2. Una inspección debe ser dirigida por un imparcial facilitador que está entrenado en la inspección técnicas
3.3.3.3. PROCEDIMIENTO
3.3.3.3.1. Un técnico o individuo calificado presenta una visión general del producto.
3.3.3.3.2. El examen se lleva a cabo durante una o más reuniones.
3.3.3.4. ROLES
3.3.3.4.1. Líder de inspección
3.3.3.4.2. Un grabador
3.3.3.4.3. Un lector
3.3.3.4.4. unos pocos inspectores. Los miembros pueden poseer diferentes conocimientos, como: experiencia en el campo, método de diseño o la experiencia del lenguaje.
3.3.3.5. A QUE SE REALIZA
3.3.3.5.1. A una parte del producto de software
3.3.3.5.2. A tdo el producto de software, enfocado n un sólo aspecto
3.3.4. 2.3.4. Recorrido
3.3.4.1. PROPÓSITO
3.3.4.1.1. Encontrar anomalías
3.3.4.1.2. Mejorar el producto de software
3.3.4.1.3. Considerar implementaciones alternativas
3.3.4.2. Lo organiza principalmente el ingeniero de software para que los compañeros de su equipode trabajo revisen el producto del software
3.3.5. 2.3.5. Auditorías
3.3.5.1. PROPÓSITO
3.3.5.1.1. Proporcionar una evaluación independiente de la conformidad del producto de software y procesos a la normativa aplicable, normas, directrices, planes y procedimientos.
3.3.5.2. ROLES
3.3.5.2.1. Auditor líder
3.3.5.2.2. Otro auditor
3.3.5.2.3. Una grabadora o un iniciador
3.3.5.2.4. Representante de la organización auditada
3.3.5.3. RESULTADO
3.3.5.3.1. Identificación de los casos de no conformidad, mediate un informe que requiere el equipo para tomar medidas correctivas.
3.3.5.4. SE REALIZAN
3.3.5.4.1. En cualquier etapa del desarrollo
3.3.5.4.2. A un producto de software
4. 3. Consideraciones prácticas
4.1. 3.1. Requisitos de Calidad del Software
4.1.1. 3.1.1. factores de influencia
4.1.1.1. El dominio del sistema (crítico de seguridad, de misión crítica, Business-crítico)
4.1.1.2. Requisitos del sistema y software
4.1.1.3. Las normas específicas de ingeniería de software aplicable
4.1.1.4. Los métodos y las herramientas de software que se utilizará para el desarrollo y mantenimiento
4.1.1.5. Evaluación y mejora
4.1.1.6. El presupuesto
4.1.1.7. El personal
4.1.1.8. La programación de todos los procesos
4.1.1.9. Los usuarios
4.1.1.10. El nivel de integridad del sistema
4.1.2. 3.1.2. Fiabilidad
4.1.2.1. Es el principal requisito de calidad sobre, por encima de la funcionalidad básica
4.1.2.2. tolerancia a fallos, la seguridad, la seguridad y usabilidad.
4.1.3. 3.1.3. Niveles de integridad de software
4.1.3.1. Se determina en base a la posible consecuencias de un fallo del software y de la probabilidad de fracaso
4.1.3.2. Se utilizan técnicas como el análisis de riesgos para el análisis de la seguridad o la amenaza para la seguridad puede ser utilizado para desarrollar una actividad de planificación que identificar dónde posibles puntos débiles que se encuentran.
4.2. 3.2. Caracterización de los Defectos
4.2.1. Conduce a una comprensión del producto
4.2.2. Facilita las correcciones en el proceso o el producto
4.2.3. Informa al personal de gestión de proyectos sobre los defectos
4.3. 3.3. Técnicas de Gestión de Calidad de Software
4.3.1. 3.3.1. técnicas estáticas
4.3.1.1. El examen del proyecto (documentación y software), y otra información sobre los productos de software, sin ejecutarlas.
4.3.2. 3.3.2. técnicas intensivas
4.3.2.1. revisiones y auditorías, pueden variar de una reunión formal a una reunión informal
4.3.3. 3.3.4. técnicas dinámicas
4.3.3.1. la simulación, el modelo de chequeo, y ejecución simbólica
4.3.4. 3.3.5. Pruebas
4.3.4.1. Permiten examinar cada salida en relación con la especificación de requisitos software para garantizar la trazabilidad de los productos, coherencia, la integridad, exactitud y rendimiento.
4.3.4.2. Las pruebas se discute en detalle en el Testing de Software KA
4.3.4.2.1. IEEE 1462-1498
4.4. 3.4. Medición de la Calidad de software
4.4.1. Basado en la estadística (por ejemplo, análisis de Pareto, gráficos, diagramas de dispersión)
4.4.2. Las pruebas estadísticas (por ejemplo, la prueba binomial)
4.4.3. Predicción (por ejemplo, modelos de fiabilidad)