Calidad de Software       3 .0 "Consideraciones Prácticas"

Comienza Ya. Es Gratis
ó regístrate con tu dirección de correo electrónico
Calidad de Software       3 .0 "Consideraciones Prácticas" por Mind Map: Calidad de Software       3 .0 "Consideraciones Prácticas"

1. 3.1 Calidad de requerimientos de Software

1.1. 3.1.1 Influencia de factores

1.1.1. Hay varios factores que influyen en actividades y técnicas de la planeación, administración, y selección de la administración de la calidad del software que incluyen:

1.1.1.1. Dominio del sistema

1.1.1.2. Ambiente físico donde reside el software

1.1.1.3. Especificaciones de la ingeniería de software

1.1.1.4. Métodos y herramientas que son utilizadas para desarrollo y mantenimiento y para la calidad y mejoramiento

1.1.2. La información de cómo son organizados esos factores dan beneficios para la asegurar la calidad del software

1.2. 3.1.2 Confiabilidad

1.2.1. Es el principal requisito de calidad que debe tener un sistema, pues cuando hay falla en el mismo, puede afectar a diversos usuarios y procesos de la empresa.

1.2.2. Un software confiable debe de tener las siguientes características:

1.2.2.1. Disponibilidad

1.2.2.2. Fiabilidad

1.2.2.3. Seguridad

1.2.3. Las pruebas V&V ayudan a asegurar que un software sea confiable.

1.3. 3.1.3 Niveles de integridad de software

1.3.1. Son valores que representan la complejidad, riegos, nivel de seguridad, rendimiento deseado, confiabilidad del software, entre otros.

1.3.2. Las técnicas que se usan para determinar esto, varían dependiendo de la aplicación y del uso del sistema. Los niveles de integridad pueden cambiar a manera de que evoluciona el software.

2. 3.2 Caracterización de defectos

2.1. Las técnicas de evaluación de la calidad del software encuentran defectos, errores y fallas. La caracterización de defectos se usa en auditorias y revisiones.

2.2. Presentan una lista de problemas proporcionadas por el equipo para considerar su revisión.

2.3. Tipos de defectos:

2.3.1. Error Computacional

2.3.1.1. Valor mal calculado, medido

2.3.1.2. Condicionales

2.3.2. Error

2.3.2.1. Acción humana incorrecta

2.3.3. Defecto

2.3.3.1. Un producto es defectuoso y necesita ser reparado

2.3.4. Fallo

2.3.4.1. Un defecto en el código fuente (definición de datos)

2.3.5. Problema

2.3.5.1. Un evento en el que el sistema no realice una función

2.4. Es importante registrar deficiencias y defectos encontradas mediante técnicas de gestión (revisiones, auditorias, inspecciones) de calidad ya que pueden perderse.

3. 3.4 Medición de la calidad del software

3.1. Las cuestiones de calidad van más allá de si el software funciona o no hasta qué punto logra objetivos de calidad mensurables

3.2. La medición de la calidad del software incluye la determinación de niveles de preguntas de gestión de la calidad del software sobre esfuerzo, costo y programación; determinar cuándo dejar de probar y liberar un producto y determinar la eficacia de los esfuerzos de mejora del proceso.

3.3. El costo de los procesos SQM es una cuestión frecuentemente planteada al decidir cómo debe organizarse un proyecto o un grupo de desarrollo y mantenimiento de software.

3.4. Los datos de medición de calidad de software pueden ser útiles en sí mismos y se pueden aplicar técnicas matemáticas y gráficas para ayudar en la interpretación de las medidas

3.4.1. Estadística descriptiva

3.4.2. Pruebas estadísticas

3.4.3. Análisis de tendencias

3.4.4. Predicción

3.5. La medición de la calidad del software incluye la medición de los casos de defectos y la aplicación de métodos estadísticos para comprender los tipos de defectos que se producen con mayor frecuencia, para determinar métodos para

3.5.1. Prevenir

3.5.2. Reducir

3.5.3. Eliminar su recurrencia.

3.6. Los puntos de referencia pueden servir como una ayuda para determinar cuándo el producto está listo para su entrega.

4. 3.3 Técnicas de la gestión de calidad del software

4.1. Pueden categorizarse en muchas maneras, pero la forma más simple son Estáticas y dinámicas.

4.1.1. Dinámicas: Ejecutar el software

4.1.2. Estáticas: Analizar documentos y código fuente, pero no ejecutar el software.

4.2. 3.3.1 Técnicas estáticas

4.2.1. Examinan documentación (requerimientos, especificaciones de interfaz, diseños y modelos) y el código fuente sin ejecutar el código.

4.2.2. Otro tipo de técnica más formal son las herramientas usadas para verificar requerimientos y diseños. Han sido usados en la verificación de partes cruciales de un sistema como seguridad o requerimientos seguros.

4.3. 3.3.2 Técnicas dinámicas

4.3.1. Ejecutan el software, y técnicas como simulación y análisis de modelo pueden considerarse como dinámicas.

4.3.2. La lectura del código es considerada prueba estática, pero en ocasiones se utiliza como dinámica.

4.3.3. Diferentes grupos pueden realizar pruebas durante el desarrollo de software incluyendo grupos externos del equipo de desarrollo. Las pruebas KA se dedican completamente a este tema.

4.4. 3.3.3 Pruebas

4.4.1. Dos tipos de pruebas que pueden entrar aquí son V&V

4.4.1.1. Evalúan pruebas y herramientas usadas

4.4.1.2. Conformidad de pruebas de componentes

4.4.2. Personas independientes a V&V verifica prueba planes, procesos, procedimientos y precisión de resultados.

4.4.3. Generalmente una tercera persona prueba el producto conforme a lo específico en los requisitos.