ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE

link1jdcsistemas
Mind Map by link1jdcsistemas, updated more than 1 year ago
link1jdcsistemas
Created by link1jdcsistemas over 5 years ago
4
0

Description

INGENIERIA DE SOFTWARE

Resource summary

ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE
1 OBJETIVOS PRINCIPALES
1.1 Planificar las actividades de SQA
1.2 Verificar la adherencia de los productos de trabajo y de las actividades a los estándares, procedimientos y requerimientos establecidos.
1.3 Informar a los grupos e individuos afectados sobre las actividades de SQA y sus resultados
1.4 Comunicar a la administración superior sobre desviaciones no resueltas dentro del proyecto.
2 GRUPO DE SQA
2.1 SQA es una especialidad compleja y abundante en metodologías, por lo que es necesario la especialización de sus profesionales. De ahí, que el liderazgo de SQA deba ser asumido por uno o más ingenieros de calidad, lo que se conoce como grupo de SQA.
2.2 ACTIVIDADES DEL GRUPO SQA
2.2.1 Preparar el Plan de SQA para cada proyecto
2.2.2 Participar en el desarrollo de la descripción del proceso de software para un proyecto
2.2.3 Revisar las actividades de ingeniería en acuerdo con el proceso definido.
2.2.4 Auditar los productos de trabajo designados, para verificar su adherencia con aquellos definidos en el modelo de proceso.
2.2.5 Asegurar que las desviaciones en el desarrollo y en los productos de trabajo sean documentadas y apoyadas por el procedimiento de documentación.
2.2.6 Registrar cualquier disconformidad e informar a la administración superior.
2.2.7 Coordinar la gestión de configuración
2.2.8 Apoyar la recolección y análisis de métricas de software.
2.3 ACTIVIDADES DEL PROCESO SQA
2.3.1 ESTÁNDARES
2.3.1.1 Los estándares son los cimientos de cualquier sistema de calidad de software, pues proveen la base para la evaluación y medición de las actividades y de los productos de trabajo durante todo el ciclo de vida del software. Por tanto, ellos establecen el marco de trabajo para el desarrollo de software, constituyéndose en un factor crítico de este último.
2.3.2 REVISIONES
2.3.2.1 Las revisiones son una metodología definida, estructurada y disciplinada para la detección e identificación de defectos en los productos de trabajo durante el ciclo de vida del software. Cuenta con seis etapas: planificación, orientación, preparación, inspección, rework y seguimiento, las cuales son llevadas a cabo por un equipo con tareas y responsabilidades definidas, con documentación específica y por un período determinado.
2.3.3 PRUEBA
2.3.3.1 La prueba es la última actividad de evaluación del producto que permite detectar defectos y establecer el nivel de satisfacción de los requerimientos. Sus actividades incluyen la planificación, diseño, ejecución y reporte sobre los diferentes niveles de prueba existentes durante el proyecto. Estos niveles van desde las pruebas de unidad, pasando por la de integración, hasta las del sistema y aceptación.
2.3.4 Análisis de defectos
2.3.4.1 Los defectos ocurren a lo largo de todo del ciclo de vida del software sin excepción. Por ello resulta natural concentrar esfuerzos en su detección y corrección. No obstante a que la corrección de defectos es importante, más lo es su prevención. Esta sólo puede alcanzarse a partir del registro y seguimiento de los defectos, puntapié inicial para un posterior análisis. Es, entonces, el análisis de defectos la actividad responsable de corregir las deficiencias actuales en el proceso y así disminuir los defectos en futuros proyectos.
2.3.5 Gestión de Configuración
2.3.5.1 El propósito de la Gestión de Configuración (Software Configuration Management, SCM) es establecer y mantener la integridad de los productos a través de todo el ciclo de vida del software, proveyendo un adecuado control de los cambios producidos en los diversos ítems de configuración1. Para ello, SCM se compone de cuatro actividades principales: identificación de la configuración, control de cambios, contabilidad y auditorías de la configuración.
3 ACTIVIDADES DE SQA DURANTE EL CICLO DE VIDA DE UN PROYECTO
3.1 PLANIFICACIÓN
3.1.1 Durante la etapa de planificación, SQA debe participar de la elaboración del plan de proyecto. Es su responsabilidad producir el Plan de SQA y verificar que los procesos, procedimientos y estándares identificados en el plan de proyecto son apropiados, claros, específicos y auditables. El contenido del plan de SQA debe identificar: evaluaciones, auditorías y revisiones, estándares, procedimientos de seguimiento y reporte de errores, y la documentación por producir.
3.2 ESPECIFICACIÓN DE REQUERIMIENTOS
3.2.1 SQA debe corroborar que en la especificación estén expresados todos los requerimientos funcionales, técnicos, operacionales y de interfaz, de manera tal que puedan ser verificados en el producto final.
3.3 DISEÑO
3.3.1 La adherencia del diseño y su documentación a los estándares definidos en el plan del proyecto.
3.3.2 La presencia de todo módulo en el diseño
3.3.3 La incorporación de los resultados de las inspecciones en el diseño.
3.3.4 El ingreso del diseño a la configuración del software, tras su aprobación.
3.4 IMPLEMENTACÓN
3.4.1 Los resultados de las actividades de diseño y codificación.
3.4.2 El estado de todos los entregables
3.4.3 Las actividades de gestión de configuración y de la biblioteca del software.
3.4.4 Los informes sobre desviaciones y las acciones correctivas.
3.5 INTEGRACIÓN Y PRUEBA
3.5.1 Con relación a la integración y a la prueba, a SQA le corresponde garantizar la concordancia de las pruebas con el plan y los procedimientos definidos, así como también que toda desviación haya sido informada y corregida. Además, debe certificar que las actividades de prueba se han completado satisfactoriamente y que el software y su documentación se encuentran listos para la entrega del producto final.
3.6 ACEPTACIÓN Y ENTREGA
3.6.1 En la fase de aceptación, SQA es responsable de realizar la última auditoría de configuración del software, con el objetivo de determinar que los deliberables están listos para la entrega.
3.7 MANTENCIÓN
3.7.1 Durante la operación pueden presentarse correcciones o mejoras que originen pequeños “ciclos de desarrollo”. En tal caso, se repetirán las actividades de SQA descritas con anterioridad.
Show full summary Hide full summary

Similar

Mapa Conceptual de la arquitectura de base de datos
Alan Alvarado
Mapa Conceptual Hardware y Software
Jeferson Alfonso Alvarado Suarez
Abreviaciones comunes en programación web
Diego Santos
MAPA CONCEPTUAL SOBRE LA INICIATIVA CDIO
Victor Antonio Rodriguez Castañeda
Historia de la Ingeniería
Camila González
Los ordenadores
Adela Rico Torres
Diapositivas neumática
Victor Zamora Delgado
Mapa Neumática
Victor Zamora Delgado
Ejercicios neumática
Victor Zamora Delgado
Planificación de Proyectos
Gerald Leonel Alarcon
Analisis y Requerimientos en un Sistema de Informacion
junacu