Métricas de la Calidad de la Especificación.

Slides:



Advertisements
Presentaciones similares
Ciclo de vida de desarrollo de software
Advertisements

Métrica v2.1 : Técnica - Diagrama de Flujo de Datos (DFD)
Fundamentos de Diseño de Software INFT.1
Ingeniería del Software UMG Ingeniería en Sistemas
ANÁLISIS DE REQUERIMIENTOS
Ingeniería de Software
CALIDAD DE PRODUCTO PORTADA CALIDAD DE PRODUCTO.
DISEÑO ORIENTADO AL OBJETO
Pruebas Orientadas a Objeto
Gestión de proyectos Es la primera etapa de Ingeniería del Software.
Diseño orientado al flujo de datos
DSOO - María Eugenia Valencia
MODELADO DE ANALISIS Y DISEÑO
Guia Diseño Robert Echeverria
Modelos de confiabilidad
INGENIERIA DE REQUERIMIENTOS
Requerimientos del Usuario y Requerimientos del Sistema 3ero BB
IEEE-std Práctica Recomendada para la Especificación de Requerimientos de Software Fuente: IEEE Recommendad Practice for Software Requirements.
Administración de Procesos de Pruebas
DESCRIPCION DEL PROBLEMA
REQUISITOS DE SOFTWARE
SISTEMAS DE INFORMACION
Modelado de Procesos en la Ingeniería de Requerimientos
DSOO - María Eugenia Valencia
MESA 3 Evaluación, seguimiento y mejora, auditorias internas y Revisión por la dirección Requisitos P
GESTION NIVELES DE SERVICIO.
IS ILic. Patricia Pesado.1 INGENIERIA DE REQUERIMIENTOS.
 El primer navegador Web incluía un lenguaje de estilo interno que utilizaba dicho navegador para mostrar las páginas HTML.  Sin embargo estos primeros.
Métrica v2.1 : Técnica - Diagrama de Flujo de Datos (DFD)
1.1 Concepto y terminología
DISEÑO DE SOFTWARE 1ª. Parte
DATA WAREHOUSE Equipo 9.
Bases de Datos Modelamiento.
Ingeniería de Requisitos
5.3 APROXIMACIONES AL DISEÑO
Análisis de Sistemas.
Ingeniería del Software
Diseño: Fundamento y Documentación ISF5501 Ingeniería de Software Semana 13/2.
Análisis y Diseño de Sistemas
Notas de Clase Modelado de Procesos de Negocio
Construcción de Software
Ingeniería de Software
INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE
“condición que necesita el usuario para resolver un problema o conseguir un objetivo determinado”. Los requisitos de un sistema son los aspectos que el.
Ing. Noretsys Rodríguez. Definición de Conceptos  Falla: Ocurre cuando un programa no se comporta de manera adecuada. Es una propiedad estadística de.
REQUISITOS.
INGENIERIA DE SOFTWARE
Alexander Aristizabal Ángelo flores herrera
Factores y Métricas que determinan la Calidad de un producto
Control de Calidad de Software
IDENTIFICACIÓN DEL CICLO DE VIDA DEL SOFTWARE. POLITÉCNICO COLOMBIANO JAIME ISAZA CADAVID.
Ingeniería de Requerimientos
Introducción al proceso de verificación y validación.
CICLO DE VIDA CLÁSICO DE UN SISTEMA
Actividades en el Proceso de desarrollo de Software
NOMBRE DE LA ASIGNATURA: VERIFICACIÓN Y VALIDACIÓN DEL SOFTWARE
Simón Esneider Herrera Álvarez Media Técnica Casd 10-2
MÓDULO INTRODUCCIÓN AL CICLO DE VIDA DEL SOFTWARE
Un requerimiento es una condición o capacidad a la que el sistema (siendo construido) debe conformar [ Rational ]. Un requerimiento de software puede.
¿QUÉ ES EL MODELO ENTIDAD-RELACIÓN?  Como ya he comentado este modelo es solo y exclusivamente un método del que disponemos para diseñar estos esquemas.
Evaluación interna Nivel superior (NS)
Análisis de Requerimientos
Proceso de desarrollo de Software
LILIANA JIMENEZ GARCIA FERANANDO CANO GOMEZ. El proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema es llamado Ingeniería.
6.6 Administración de defectos
CICLO DE VIDA DE UN SOFTWARE. Es el conjunto de los programas de cómputo, procedimientos, reglas, documentación y datos asociados, que forman parte de.
Requerimientos del software
VERIFICACIÓN Y VALIDACIÓN DE SISTEMAS 3.10 Fase de manejo de requerimientos 4.1 Modelado de pruebas en UML Ponente: ing. Alejandro tapia vazquez.
Métricas de la Calidad de la Especificación.
Transcripción de la presentación:

Métricas de la Calidad de la Especificación. Tema: 4.1.3 Métricas de la Calidad de la Especificación.

Métricas de la Calidad de la Especificación Se a Propuesto una lista de características que pueden emplearse para valorar la calidad del modelo de análisis y la correspondiente especificación de requisitos: Especificidad (ausencia de ambigüedad, corrección, compleción, comprensión, capacidad de verificación, consistencia externa e interna, capacidad de logro, concisión, traza habilidad, capacidad de modificación, exactitud y capacidad de reutilización). Además se apunta que las especificaciones de alta calidad deben estar almacenadas electrónicamente, ser ejecutables o al menos interpretables, anotadas por importancia y estabilidad relativas, con su versión correspondiente, organizadas, con referencias cruzadas y especificadas al nivel correcto de detalle.

Métricas de la Calidad de la Especificación Aunque muchas de las características anteriores pueden ser de naturaleza cuantitativa, Se sugiere que todas puedan representarse usando una o más métricas. Por ejemplo asumimos que hay nr requisitos en una especificación, tal como: nr = nf + nnf Donde nf es el numero de requisitos funcionales y nnf es el número de requisitos no funcionales ( por ejemplo, rendimiento). Para determinar la especificidad de los requisitos, Se sugiere una métrica basada en la consistencia de la interpretación de los revisores para cada requisito: Q1= nui/ nr Donde nui es el numero de requisitos para los que todos los revisores tuvieron interpretaciones idénticas. Cuanto más cerca de uno este el valor de Q1 menor será la ambigüedad de la especificación.

Métricas de la Calidad de la Especificación La compleción de los requisitos funcionales pueden terminarse calculando la relación. Q2= nu/ (ni * ns) Donde nu es el número de requisitos de función únicos, ni es el número de entradas (estímulos) definidos o implicados por la especificación y ns es el número de estados especificados. La relación Q2 mide porcentaje de funciones necesarias que se han especificado para un sistema, sin embargo, no trata los requisitos no funciónales. Para incorporarlos a una métrica global completa, debemos considerar el grado de validación de los requisitos: Q3= nc/ (nc * nnv) Donde nc es el número de requisitos que se han validados como correctos y nnv el número de requisitos que no se han validado todavía.

Métricas de la Calidad de la Especificación CARACTERÍSTICAS DESEABLES DE UNA ERS Una ERS de calidad debería poseer las siguientes características: No ambigua: La ERS es no ambigua si todo requisito posee una sóla interpretación Completa: Una ERS es completa si todo lo que se supone que el software debe hacer está incluído en la ERS. Por completitud, deberían describirse todas las posibles respuestas a todas las posibles entradas y en todas las situaciones posibles. Además, la ERS no contendrá secciones de tipo “por determinar…” Correcta: Todo requisito de la ERS contribuye a satisfacer una necesidad real. Comprensible: Todo tipo de lectores (clientes, usuarios, desarrolladores, equipo de pruebas, gestores, etc.) entienden la ERS. Verificable: Si para cada requisito expresado en la ERS existe un procedimiento de prueba finito y no costoso para demostrar que el futuro sistema lo satisface. Internamente Consistente: No existen subconjuntos de requisitos contradictorios.

Métricas de la Calidad de la Especificación Externamente Consistente: Ninguno de los requisitos está en contradicción con lo expresado en documentos de nivel superior. Por ejemplo, en un sistema (hardware + software), los requisitos del software no pueden contradecir los requisitos del sistema. Realizable: Si, dados los actuales recursos, la ERS es implementable. Concisa: La ERS debe ser lo más breve posible, sin que esto afecte al resto de atributos de calidad. Independiente del diseño: Existen más de un diseño e implementación que realizan la ERS. Para ello la ERS debería limitarse a describir el comportamiento externo del sistema. Trazable: Cada requisito se puede referenciar de forma unívoca. Es fundamental para precisar qué requisitos son implementados por qué componente del diseño, lo cual es imprescindible a la hora de realizar las pruebas de dicho componente. Modificable: Los cambios son fáciles de introducir.

Métricas de la Calidad de la Especificación Electrónicamente almacenada: Se encuentra en un archivo de texto, en una base de datos o, mejor aún, ha sido creada con una herramienta de gestión de requisitos (Doors, etc.) Ejecutable/Interpretable/Prototipable/Animable: Si existe una herramienta software que, recibiendo como entrada la ERS, realice un modelo ejecutable de la misma. Aplicable tan sólo a ciertas notaciones como las notaciones formales o los diagramas de transición de estados. Anotada por importancia relativa: Si los requisitos se clasifican según su importancia. Como mínimo un requisito puede ser “Obligatorio, Deseable u Opcional”. Esto sirve para no asignar demasiados recursos a la implementación de requisitos no esenciales. Anotada por estabilidad relativa: Los requisitos son, en general, inestables y volátiles. A cada requisito se le asigna una probabilidad de cambio (p.ej. “Alta, Media o Baja”). Esto ayudará a los diseñadores a diferenciar los componentes más flexibles de los más estables. Anotada por versión: Si un lector de la ERS puede determinar qué requisitos serán satisfechos por qué versión del producto. No redundante: Cada requisito se expresa en un solo lugar de la ERS. La redundancia, de todas formas, no es del todo mala si aumenta la legibilidad.

Métricas de la Calidad de la Especificación Al nivel adecuado de abstracción: Ni demasiado detallada ni demasiado vaga. Precisa: Una ERS es precisa si hace uso de valores numéricos para precisar las características del sistema. La precisión es aplicable, ante todo, a los requisitos no funcionales. Por ejemplo, no es útil decir “El tiempo de respuesta será más bien rápido”, sino “El tiempo de respuesta será menor que dos segundos”. NOTA: en la práctica diaria, este atributo es difícil de conseguir pues es fuertemente dependiente de la tecnología disponible, lo cual no siempre se conoce al principio de un proyecto. Reutilizable: Si ciertas secciones de la ERS se pueden reutilizar. Trazada: Si está claro el origen de cada requisito (quién o qué lo pide). Organizada: Si el lector puede fácilmente encontrar la información buscada. Con referencias cruzadas: Si se utilizan referencias entre requisitos relacionados (trazabilidad intra-ERS) o entre secciones relacionadas.