Revision Tecnica Formal
Short Description
Download Revision Tecnica Formal...
Description
Aplicaciones de Ingeniería de Software Administración de la Calidad del Producto de Software
¿Qué es la gestión de la calidad?
Es una actividad protectora o de sombrilla que se aplica a lo largo del proceso de software. Con frecuencia es llamada garantía de la calidad de software
1
La gestión de la calidad abarca
Un proceso de garantía de la calidad del software (Software Quality Assurer/Advisor)
Tareas específicas de aseguramiento y control de la calidad (revisiones técnicas formales y una estrategia de pruebas)
Prácticas efectivas de ingeniería de software (métodos y herramientas)
La gestión de la calidad abarca Control
de todos los productos de trabajo del software y los cambios que generan Un
procedimiento para garantizar la concordancia con los estándares de desarrollo del software Mecanismos
de medición e informe
2
Control de calidad
Involucra la serie de inspecciones, revisiones y pruebas empleadas a lo largo del proceso de software para garantizar que cada producto de trabajo satisfaga los requisitos que se le han asignado.
Garantía de la calidad del software (SQA) Concordancia con los requisitos funcionales y de desempeño explícitamente establecidos, estándares de desarrollo explícitamente documentados y características implícitas que se esperan de cualquier software desarrollado profesionalmente.
“La gente olvida cuán rápido hiciste un trabajo, pero siempre recuerdan cuán bien lo hiciste”. Howard Newton
3
Actividades de SQA
Preparar un plan de SQA para un proyecto. Identifica las evaluaciones que se harán, las auditorías y revisiones a llevar a cabo, los estándares aplicables al proyecto, los procedimientos para el informe y el seguimiento de errores, los documentos que debe producir el grupo SQA y la cantidad de retroalimentación proporcionada al equipo de proyecto.
Actividades de SQA
Participar en el desarrollo de la descripción del proceso de software del proyecto. El equipo de software selecciona un proceso para el trabajo que habrá de realizarse. El grupo de SQA revisa la descripción del proceso para que concuerde con las políticas organizacionales, los estándares internos de software, los estándares impuestos de manera externa (ISO 9000) y otras partes del plan de proyecto de software.
4
Actividades de SQA
Revisar las actividades de ingeniería del software para verificar que se ajustan al proceso de software definido. El grupo de SQA identifica, documenta y sigue las desviaciones del proceso y verifica que se hayan hecho las correcciones.
Actividades de SQA
Audita productos de trabajo de software seleccionados para verificar que se ajusten con los definidos como parte del proceso del software. El grupo de SQA revisa los productos de trabajo seleccionados, identifica, documenta y sigue las desviaciones; verifica que se hayan hecho las correcciones; y periódicamente informa de los resultados de su trabajo al gerente del proyecto.
5
Actividades de SQA
Garantiza que las desviaciones en el trabajo del software y en los productos de trabajo estén documentadas y se manejen de acuerdo con el procedimiento establecido. Las desviaciones se pueden encontrar en el plan del proyecto, en la descripción del proceso, en los estándares aplicables o en los productos de trabajo técnicos.
Actividades de SQA
Registra cualquier falta de ajuste y lo informa al gestor ejecutivo. A los seguimientos que no se ajustan se les da seguimiento hasta resolverlos.
6
Validación
La validación se refiere al proceso de evaluación del software al final de su desarrollo para asegurar que está libre de fallas y cumple con los requisitos. La validación se lleva a cabo mediante la utilización de diversos enfoques de prueba. También se pueden validar productos intermedios como la descripción de requisitos, esto se hace mediante la utilización de un prototipo.
Verificación
Se refiere al proceso de determinar si los productos de una determinada fase del proceso de desarrollo de software cumplen con los requerimientos establecidos durante la fase previa. Trata de identificar defectos o errores que generen fallas. Una de las técnicas más comunes para la verificación es la revisión técnica. Por ejemplo, una revisión de especificaciones intenta verificar el modelo del análisis contra la Especificación de Requisitos
7
Tipos de Productos para V&V
Requisitos Diseño Implementación Administración de la Configuración y Cambios
Objetivo de la V&V
Asegurar que el producto satisface las necesidades del usuario. Aspectos considerados por la V&V: { { { { { {
Funcionalidad Portabilidad Desempeño Mantenibilidad Seguridad Usabilidad
8
Clasificación de la aplicabilidad de las técnicas y enfoques de V&V
Correctud {
Consistencia {
El grado en que lo contenido en el producto es necesario.
Suficiencia (Completud) {
El grado en el que el producto es consistente consigo mismo y con otros productos.
Necesidad {
El grado en el que el producto está libre de defectos.
El grado en el que el producto está completo.
Desempeño {
El grado en el que el producto satisface sus requisitos de desempeño.
Enfoques y técnicas de V&V
Revisiones Técnicas del Software (Recorridos e Inspecciones) Prueba de Software Simulación y Prototipos Rastreabilidad de Requisitos
9
Revisión Técnica Formal (RTF) Actividad del control de calidad del software Objetivos: {
{
{
Descubrir errores en la función, lógica o implementación en cualquier representación del software. Verificar que el software en revisión satisface sus requisitos Garantizar que el software se ha representado de acuerdo con los estándares predefinidos.
Revisión Técnica Formal (RTF) {
{
Lograr software desarrollado en una manera uniforme. Hacer proyectos más manejables.
10
Revisión Técnica Formal (RTF)
Sirve como un proceso de entrenamiento pues permite que los ingenieros menos experimentados observen diferentes enfoques respecto al análisis, el diseño y la construcción de software.
Promueve el soporte y la continuidad, pues varias personas se familiarizan con partes del software que de otra forma nunca verían.
Cada RTF se realiza en una junta y tendrá éxito si se planifica, controla y atendiende apropiadamente.
Junta de revisión Cualquier junta de revisión debe atenerse a las siguientes restricciones: { En la revisión se deben involucrar entre 3 y 5 personas. { Se debe preparar con anticipación, pero sin que requiera más de 2 horas de trabajo de cada persona. { La duración de la junta de revisión debe ser menor a dos horas. Estas restricciones implican que una RTF se enfoca en una parte específica y pequeña del software total (Porción de especificación, diseño detallado de componente, listo de código fuente. Esto también se le conoce como un Recorrido
11
Participantes en la preparación y realización de la junta de revisión
El Productor {
Es el ingeniero que ha desarrollado el artefacto.
Jefe del Proyecto
Jefe de Revisión
{
{
{
Es el responsable del proyecto. Evalúa la disponibilidad del producto, genera copias del material necesario y las distribuye a dos o tres revisores para que realicen sus observaciones antes de la junta. Revisa el producto y establece una agenda.
Revisores {
Se familiarizan con el producto considerando entre una y dos horas y toman sus notas.
Desarrollo de la Reunión
Uno de los revisores asume el papel de registrador Presentación de la agenda por parte del Jefe de Revisores y breve introducción por parte del Productor. El Productor inicia el recorrido del producto explicando el material. Los Revisores exponen los problemas que descubrieron antes de la junta.
12
Desarrollo de la Reunión
El Registrador va anotando los problemas o errores encontrados. Al final todos los asistentes deben decidir si: {
{
{
Aceptan el producto sin modificaciones posteriores. Rechazan el artefacto debido a errores severos encontrados. Aceptan el producto provisionalmente.
Desarrollo de la Reunión
Se llena documento de finalización indicando la participación y conformidad con los hallazgos del equipo revisor.
13
Informe de la revisión y conservación de registros Un informe resumen de la revisión responde 3 preguntas: { { {
Qué se revisó? Quién lo revisó? Cuáles fueron los hallazgos y conclusiones?
Directrices de la revisión
Revisar el producto, no al productor Establecer una agenda y respetarla Limitar el debate y la impugnación Enunciar áreas de problemas, pero no se intente resolver todos los que se hayan señalado.
14
Directrices de la revisión
Tomar notas Limitar el número de participantes e insistir en la preparación anticipada. Desarrollar una lista de verificación para cada producto que tenga probabilidad de ser revisado.
Directrices de la revisión
Asignar recursos y programar las RTF. Realizar un entrenamiento significativo de todos los revisores. Analizar las revisiones previas.
15
Simulación y Prototipos
Son técnicas para analizar el comportamiento esperado de un producto. Para los propósitos de la V&V, son normalmente utilizadas para analizar las especificaciones de requisitos asegurarando que reflejan las necesidades de los usuarios. También se utilizan para analizar el desempeño esperado del producto en relación a los requisitos no funcionales.
Rastreo de Requisitos
Es una técnica para asegurar que el producto, así como la prueba del producto corresponden a cada uno de sus requisitos. El enfoque tradicional para llevarlo a cabo es mediante el uso de matrices.
16
Garantía de la calidad estadística del software
La información acerca de los defectos de software se recopila y clasifica. Se intenta determinar la causa de cada defecto Mediante el principio de Pareto (80% de los defectos se encuentran en 20% de todas las causas posibles) se aisla un 20%
Garantía de la calidad estadística del software
Una vez que las causas vitales han sido identificadas, se corrigen los problemas que han provocado los defectos.
17
Un ejemplo genérico de la aplicación de métodos estadísticos
Supóngase que una organización recopila los defectos de un año {
{
{
Especificaciones incompletas o erróneas (EIE) Mala interpretación de la comunicación con el cliente (MCC) Desviación intencional de las especificaciones (DIE)
Un ejemplo genérico de la aplicación de métodos estadísticos {
{
{
{ {
Violación de los estándares de programación (VEP) Errores en la representación de los datos (modelos de clases, datos) (ERD) Interfaz de componente inconsistente (ICI) Error en la lógica del diseño (ELD) Prueba incompleta o errónea (PIE)
18
Un ejemplo genérico de la aplicación de métodos estadísticos {
{
{
{ {
Error en la traducción del diseño al lenguaje de programación (TLP) Errores en la representación de los datos (modelos de clases, datos) (ERD) Interfaz de componente inconsistente (ICI) Error en la lógica del diseño (ELD) Prueba incompleta o errónea (PIE)
Datos estadísticos Total Error
Número
Serios %
Número
Moderados %
Número
Menores
%
Número
%
EIE
205
24
34
27
68
20
103
27
MCC
156
18
12
10
68
20
76
20
DIE
48
6
1
1
24
7
23
6
VEP
25
3
0
0
15
4
10
3
ERD
130
15
26
21
68
20
36
9
ICI
58
7
9
7
18
5
31
8
ELD
45
5
14
11
12
3
19
5
PIE
95
11
12
10
35
10
48
12
DII
36
4
2
2
20
6
14
4
TLP
60
7
15
12
19
5
26
7
858
100
125
100
347
100
386
100
Totales
19
Interpretación sobre los resultados presentados La tabla indica que EIE, MCC y ERD son las causas vitales al representar el 53% de todos los errores. Sin embargo, se debe observar que EIE, ERD, TLP y ELD se seleccionarían como causas vitales si sólo se consideran errores serios.
Acciones correctivas
Para corregir EIE y MCC implementar técnicas que faciliciten la recopilación de requisitos y que a su vez mejoren la comunicación con el cliente. Para mejorar ERD adquirir herramientas para el modelado de clases y datos y ejecutar revisiones de diseño más rigurosas
20
La aplicación de SQA y el principio de apareto pueden resumirse en una sola oración: Emplee su tiempo enfocándose en las cosas que realmente importan, !pero primero asegúrese de entender qué es lo que realmente importa!
Referencias
Pressman, R. Ingeniería Ed.,McGrawHill, 2006.
de
software:
un
enfoque
práctico.
6ta
21
View more...
Comments
