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

Slides:



Advertisements
Presentaciones similares
Ingeniería del Software UMG Ingeniería en Sistemas
Advertisements

Bases de Datos Modelamiento.
Análisis y Diseño de Sistemas
Métricas de la Calidad de la Especificación.
IDENTIFICACIÓN DEL CICLO DE VIDA DEL SOFTWARE. POLITÉCNICO COLOMBIANO JAIME ISAZA CADAVID.
Análisis de Requerimientos
Clase 09.  Garantizar la calidad de software  La prueba nunca termina, del IS translada se translada al usuario  Las casas de software invierte del.
Lcda. Ingrid Graü Diseño de Sistemas 1. Lcda. Ingrid Graü Diseño de Sistemas 2.
Compensaciones y Beneficios Sonia Boiarov. RESULTADO PRINCIPIOS EQUIDAD INTERNA COMPETITIVIDAD EXTERNA INDIVIDUALIDAD HERRAMIENTAS ANALISIS, DESCRIPCION;
Redacción. Lenguaje claro, sencillo y directo El lenguaje claro y sencillo —correcto ortográfica y gramaticalmente— es esencial para todas las comunicaciones.
Lcdo. Eddy Cortez Sistemas II. Ingeniería de Requisitos.
COMUNICACIÓN Y TIC Ángela Espinosa Hayler Peñaranda.
NTC - ISO 9001 NORMA TÉCNICA COLOMBIANA (TERCERA ACTUALIZACIÓN)
ALCIBIADES VALLEJO BERRIO 2.1 INTRODUCCION 2- Requerimientos  Una de las fases más importantes en el proceso de construcción de software es la de adquisición,
TEMA: PSP (Personal Software Process) ANALISIS DE SISTEMAS I ING. EDGAR RAUL MOLINA INTEGRAMTES: HANNSEL E. CORDON AC JESSICA IDALMY KRESS FREDERIC HESTIB.
APLICACIONES E IMPORTANCIA Lic. Humberto Morales Casillas.
Pruebas de Funcionalidad de Software: Caja Negra y Caja Blanca Curso: Diseño de Sistemas 9no. Semestre.
Estado del arte y Gestión de la Información
Normatividad relativa a la calidad
Ingeniería de requisitos y
Diseño de interfases Sistemas de Información
IEEE-std Práctica Recomendada para la Especificación de Requerimientos de Software Fuente: IEEE Recommendad Practice for Software Requirements.
SWEBOK.
Fundamentos de Auditoría
U.T. 11: Introducción A Las Bases De Datos
De alguna forma, toda organización por más pequeña que sea, necesita saber su pasado y su presente, la situación actual en la que se encuentra y con que.
INSTRUMENTOS PARA LA VALIDACIÓN DE MATERIALES IMPRESOS
Gestión de Información en las Organizaciones
ALGORITMOS Por Carolina R.
Procesos de la Ingeniería de Requerimientos
INTRODUCCIÒN AL SISTEMA GESTOR DE BASE DE DATOS
Especificación de Requisitos
METODOLOGÍA DE SISTEMAS
Ingeniería de Sistemas Requerimientos
CREAR DIAGRAMA DE FLUJO
Presenta: TSU. Yuridia Luna Marcos Asesora de tesis:
UNIVERSIDAD NACIONAL DE LOJA Área de la Educación, el Arte y la Comunicación Informática Educativa IV INGENIERIA DE SOFTWARE Taller de Análisis y Diseño.
Verificación y Validación de Software
Ingeniería del Software
Conceptos Relacionados Unidad I. Parte A.
Danny Frank Otero Arrascue Ingeniería de Requisitos / Requerimientos Advisor: MEJIA CABRERA HEBER IVAN.
Unidad 5: Evaluación de los sistemas
Investigación de mercados
Ciclo de vida del Software
Comprensión y obtención de los requerimientos
Metodologías de Desarrollo de Software RUP – Proceso Racional Unificado Gilber BASILIO ROBLES I.E.S.T.P. “DANIEL ALCIDES CARRIÓN” Taller de Modelamiento.
En este periodo el analista se esfuerza por comprender la información que necesitan los usuarios para realizar su trabajo de la manera correcta.
Análisis y diseño de aplicaciones. Introducción Crisis del software - conferencia organizada en 1968 por la Comisión de Ciencias de la OTAN en Garmisch.
Taller Contexto de la organización. Ing. Jorge Everardo Kaldman Vega. Ingeniero Ambiental Industrial Hermosillo Sonora, México C.P JULIO, 2018.
CICLO DE VIDA DE SOFTWARE
DISEÑO DEL SOFTWARE EDUCATIVO
Criterios cobertura de grafos: casos de uso
Requisitos Ing. Maribel Valenzuela Beltrán 1.
Tema: Administración de la configuración de software UNIVERSIDAD TECNOLÓGICA ISRAEL CALIDAD DE SOFTWARE.
INGENIERIA DE REQUISITOS
Nuestros canales de comunicación Gestión de la Calidad del Software Modelos y Estándares de Calidad en el Software.
ESTRUCTURA DE SISTEMAS OPERATIVOS Carbajal Rojas karla.
SOFTWARE EDUCATIVO JORGE RODRIGUEZ CARRILLO
IEEE-STD PRÁCTICA RECOMENDADA PARA LA ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE.
NORMA ISO/IEC 9126 Norma publicada en Usada para la evaluación de la calidad de software. Establece las características de calidad para productos.
Análisis de Procesos Informáticos Ing. Renato Toasa  Daniel Quintana  Leonardo Herrera  Fernando Moya.
GESTIÓN DE PROYECTOS La gestión de proyectos está conformada por todas aquellas acciones que debes realizar para cumplir con una objetivo definido dentro.
MODELO EN CASCADA Integrantes: Felipe Alemán Lester Blandón.
¿Qué es la celda de manufactura? La celda de manufactura es un conjunto de componentes electromecánicos, que trabajan de manera coordinada para el logro.
PRUEBAS DE CAJA NEGRA. -Internationa Software Testing Qualification Board (ISTQB) Internationa Software Testing Qualification Board (ISTQB) Técnica de.
CONSTRUCCION DE BANCO DE REACTIVOS
ESTRUCTURA DE LOS SISTEMAS OPERATIVOS
ESTRUCTURA DE SISTEMAS OPERATIVOS - ROY CANEPA JUAN FABIO
ESTRUCTURA DE LOS SISTEMAS OPERATIVOS. Estos sistemas no tienen una estructura definida, sino que son escritos como una colección de procedimientos donde.
Luis Fernando Muñoz Pantoja Ingeniero de Sistemas Copyright 2019 Luis Fernando Muñoz Pantoja Ingeniero de Sistemas Derechos reservados UML.
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.