IEEE-std-830-1998 Práctica Recomendada para la Especificación de Requerimientos de Software Fuente: IEEE Recommendad Practice for Software Requirements.

Slides:



Advertisements
Presentaciones similares
IEEE-std Práctica Recomendada para la Especificación de Requerimientos de Software Fuente: IEEE Recommendad Practice for Software Requirements.
Advertisements

PROGRAMA DE FORTALECIMIENTO INSTITUCIONAL LOCAL ESCUELAS DE LIDERAZGO Y/O GOBIERNO NIVEL 4 - MÓDULO 4.
Lcda. Ingrid Graü Diseño de Sistemas 1. Lcda. Ingrid Graü Diseño de Sistemas 2.
ISO 9000 ESTÁNDARES INTERNACIONALES APLICADO AL SOFTWARE Ing. Carlos Javier Fernández Corrales.
NORMA ISO DIS 9001:2015 Draft International Standard.
Reforzar los conocimientos sobre la planificación, control y mejora de la calidad de acuerdo con los requisitos de la Norma ISO 9001 en su Requisito 8.
NTC - ISO 9001 NORMA TÉCNICA COLOMBIANA (TERCERA ACTUALIZACIÓN)
Calidad de Software.   ¿Qué es?  ¿Quién lo hace?  ¿Por qué es importante?  ¿Cuáles son los pasos?  ¿Cuál es el producto final?  ¿Cómo me aseguro.
TEMA: PSP (Personal Software Process) ANALISIS DE SISTEMAS I ING. EDGAR RAUL MOLINA INTEGRAMTES: HANNSEL E. CORDON AC JESSICA IDALMY KRESS FREDERIC HESTIB.
Análisis de Proyecto de Software.
Técnica de relevamiento de datos
Proceso de Implantación y Aceptación del Sistema de Información (IAS)
Ejercicio práctico.
Metodología de Implementación de Sistemas ERP
El Lenguaje de Modelación Unificado
Sistemas de Gestión.
ISO BIENVENIDOS.
Ingeniería de requisitos y
SWEBOK.
U.T. 11: Introducción A Las Bases De Datos
Técnica de relevamiento de datos
Caracterización de los Procesos de Negocio
NORMA INTERNACIONAL DE AUDITORÍA 330
NORMA INTERNACIONAL DE AUDITORÍA 300
Auditoría Informática Informe de auditoría informática
INTRODUCCIÒN AL SISTEMA GESTOR DE BASE DE DATOS
BREVE INTRODUCCIÓN.... El estándar fue generado por un equipo de trabajo del IEEE, su finalidad es la integración de los requerimientos del sistema.
Especificación de Requisitos
Ingeniería de Sistemas Requerimientos
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.
Políticas de Seguridad Los Sistemas de Información y la Seguridad.
SISTEMA DE GESTION DE CALIDAD ISO 9001:2015
USO DE MODELOS EN CAPAS Equipo 7 Karen Berenice Magaña Ceferino
Metodología de la programación
ORGANIGRAMA METODOLOGIA PARA LA IMPLANTACION DE UN PROYECTO EDI
Especificación de requerimientos por: Sonia Cristina Gamboa Sarmiento
Ingeniería del Software
Conceptos Relacionados Unidad I. Parte A.
GUIA ILAC G 13 Lineamientos para los requerimientos de competencia de proveedores de esquemas de ensayos de aptitud Disertante: Dra. Celia Puglisi ::
Taller Organización de Procedimientos Administrativos.
Danny Frank Otero Arrascue Ingeniería de Requisitos / Requerimientos Advisor: MEJIA CABRERA HEBER IVAN.
Unidad 5: Evaluación de los sistemas
Ciclo de vida del Software
Comprensión y obtención de los requerimientos
En este periodo el analista se esfuerza por comprender la información que necesitan los usuarios para realizar su trabajo de la manera correcta.
ISO 9001:2015 ISO 9001 es la norma internacional encargada de definir los requisitos para un Sistema de Gestión de la Calidad (SGC). Este permite a las.
EXPOSITOR L.C. EDUARDO M. ENRÍQUEZ G.
LA GESTIÓN DE LA CALIDAD
FUNDACIÓN BARCELO Gestión de la Calidad
INGENIERIA DE REQUISITOS
Nuestros canales de comunicación Gestión de la Calidad del Software Modelos y Estándares de Calidad en el Software.
Manual de funciones y de procedimientos
Vicerrectoría Académica Dirección de Formación General Programa de Emprendimiento PROTOTIPOS.
IEEE Estándar para documentación de pruebas de software
IEEE-STD PRÁCTICA RECOMENDADA PARA LA ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE.
TALLER DE INVESTIGACION I PROCESO DE CAPTACION DE LA INFORMACION Y ELABORACION DEL CRONOGRAMA DE INVESTIGACION.
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.
Elaboración de procedimientos
PRUEBAS DE CAJA NEGRA. -Internationa Software Testing Qualification Board (ISTQB) Internationa Software Testing Qualification Board (ISTQB) Técnica de.
Diagrama de fujo. QUE ES UN DIAGRAMA DE FLUJO ? Un diagrama de flujo es la representación gráfica del flujo o secuencia de rutinas simples. Tiene la ventaja.
TEMA: Funciones, Roles y Procesos Docente: Jesús Ulloa Ninahuamán.
Estudio de Viabilidad del Sistema (EVS). Estudio de Viabilidad del Sistema Cuestiones ¿Qué es la viabilidad de un sistema? ¿Cuáles son los objetivos del.
Plan de Sistemas de Información (PSI). Plan de Sistemas de Información (PSI) Descripción y Objetivos Tiene como objetivo la obtención de un marco de referencia.
Especificación de Requerimientos
ISO Esta norma internacional proporciona orientación sobre la auditoría de los sistemas de gestión, incluyendo los principios de la auditoría, la.
Ing. Carlos García P. C.I UNIDAD EDUCATIVA “SALINAS INNOVA” P Identifique el contexto para el cual se Planifica un nuevo sistema ÁREA.
ICI 502 Procesos de Software
Sistemas de Administración
OTRAS NORMAS ISO TÓPICOS AVANZADOS DE CALIDAD. ISO 10005:2005 Directrices para los planes de la calidad  Reemplaza la versión 1995  Se establecen las.
Transcripción de la presentación:

IEEE-std-830-1998 Práctica Recomendada para la Especificación de Requerimientos de Software Fuente: IEEE Recommendad Practice for Software Requirements Specifications

Objetivos de Aprendizaje Conocer la norma IEEE 830 Aprender a formular especificaciones de software Escribir especificaciones de software que Indiquen exactamente lo que desea el cliente Permitan al proveedor entender exactamente lo que quiere el cliente Aprender a establecer las bases de acuerdo entre cliente y proveedor sobre lo que debe hacer un determinado software Aprender a elaborar una línea base para validación y verificación

Definiciones Contrato Cliente Documento legalmente obligatorio en el cual cliente y proveedor llegan a acuerdos. Incluye requisitos técnicos, requerimientos de la organización, costo y tiempo para un producto. También puede contener la información informal pero útil como los compromisos o expectativas de las partes involucradas. Cliente Persona(s) que paga(n) por el producto Normalmente (pero no necesariamente) definen los requisitos. En la práctica el cliente y el proveedor pueden ser miembros de la misma organización.

Definiciones Proveedor: Usuario: Persona(s) que produce(n) un producto para un cliente Usuario: Persona(s) que operan o actúan recíprocamente directamente con el producto. El(los) usuario(s) y el(los) cliente(s) a menudo no son la(s) misma(s) persona(s).

Consideraciones para una buena ERS* Naturaleza de la ERS Ambiente de la ERS Características de una buena ERS Preparación conjunta de la ERS Evolución de la ERS Prototipos Diseño en la ERS Requisitos del proyecto en la ERS * ERS Especificación de Requerimientos de software

Naturaleza de la ERS* ERS ERS escrita por Aspectos básicos Especificaciones para un producto particular de software, programa o juego de programas que realizan ciertas funciones en un ambiente específico ERS escrita por Uno o más representantes del proveedor Uno o más representantes del cliente o Por ambos (proveedor y cliente). Aspectos básicos Funcionalidad Interfaces externas (personas, hardware, otro software) Rendimiento Atributos (portable, exacto, mantenimiento, seguridad, …) Restricciones (de diseño, idioma, integridad, limitaciones, ambiente, …) * ERS Especificación de Requerimientos de software

Ambiente de la ERS* Puede contener toda la funcionalidad del proyecto Si es parte de un sistema más grande Se declaran las interfaces entre el sistema y el software modular Se indica la funcionalidad del software modular La ERS Parte del proceso de desarrollo de software Debe definir todos los requisitos del software correctamente No debe describir detalles de diseño o implementación No debe imponer restricciones adicionales al software (van en otro documento, por ejemplo en aseguramiento de la calidad) * ERS Especificación de Requerimientos de software

Características de una buena ERS* Correcta Inequívoca Completa Con todos los requisitos relacionados con funcionalidad, rendimiento, restricciones de diseño, atributos e interfaces externas. Respuestas a todas los posibles entradas (válidas e inválidas) Con todas las etiquetas y referencias a figuras, tablas, diagramas en la ERS Definición de las unidades de medida. Consistente Organizada por orden de importancia y/o estabilidad Esencial/Condicionada/Opcional Con/Sin cambios Comprobable Modificable Trazable * ERS de Requerimientos de software

Preparación conjunta de la ERS* Cliente y Proveedor en trabajo conjunto * ERS Especificación de Requerimientos de software

Evolución de la ERS* Cambios a medida que Se conozca más a cerca del contenido del proyecto Se llegue a detalles Avance el proyecto Se detecten deficiencias Se detecten inexactitudes * ERS Especificación de Requerimientos de software

Prototipos Ayudan a entender los problemas y/o soluciones Muestran posibles comportamientos Dan más estabilidad a la ERS Generalmente hacen que en la implementación Haya menos cambios Disminuya el tiempo * ERS Especificación de Requerimientos de software

Diseño dentro de la ERS* Una ERS debe especificar Qué funciones serán realizadas Con qué datos Para producir qué resultados En qué situación Para quien Una ERS no debe especificar Módulos en que divide el software Funciones a los módulos Flujo de información entre módulos Controles entre módulos Estructuras de datos * ERS Especificación de Requerimientos de software

Diseño dentro de la ERS* Necesidad de especificar condiciones de diseño para casos especiales, para restricciones por: Seguridad Confiabilidad Necesidad de funciones en módulos separados Restricciones de comunicaciones entre áreas del programa Garantía de integridad en variables críticas Disponibilidad física Disponibilidad de programas/aplicativos/utilitarios Cumplimiento de estándares * ERS Especificación de Requerimientos de software

Requisitos del proyecto en la ERS* ERS, dirigida al producto del software, no al proceso de producir el software ERS, requisitos acordados entre el cliente y el proveedor, incluyen Costos Tiempos de entrega Procedimientos para reportes Métodos para el desarrollo de Software Aseguramiento de Calidad Criterios para validación y verificación Procedimientos para aceptación * ERS Especificación de Requerimientos de software

Partes de una ERS – IEEE 830 Tabla de Contenido 1. Introducción 1.1 Propósito 1.2 Alcance 1.3 Definiciones, siglas, y abreviaciones 1.4 Referencias 1.5 Descripción global de la ERS 2. Descripción global del producto 2.1 Perspectiva del producto 2.2 Funciones del producto 2.3 Características de usuario 2.4 Restricciones 2.5 Condiciones y dependencias 3. Requisitos específicos Apéndices Índice

1.1 Propósito Delinear el propósito de la ERS Especificar a qué público va dirigida la ERS

1.2 Alcance Identificar el(los) producto(s) de software a construir Explicar qué hace y qué no hace el(los) producto(s) de software Describir el software especificando beneficios, objetivos y metas Ser consistente con otras especificaciones de niveles superiores

1.4 Referencias Proporcionar lista completa de todas las referencias de los documentos de la ERS Identificar cada documento por el título, número de reporte, fecha y publicación de la organización Especificar la fuente de las referencias

1.5 Descripción global de la ERS Describir el contenido de la ERS Explicar la organización de la ERS

2.1 Perspectiva del producto Interfaces del sistema Interfaces del usuario Interfaces con el hardware Interfaces con el software Interfaces de comunicaciones Restricciones de memoria Funcionamiento del sistema (normal y especial) Requisitos del Sitio

2.4 Restricciones Políticas reguladoras Limitaciones del Hardware Interfaces con otras aplicaciones Operaciones en paralelo Funciones de Auditoría Funciones de Control Requerimientos de lenguaje(s) de alto nivel Protocolos Requerimientos de fiabilidad Criticidad de la aplicación Consideraciones de seguridad y confiabilidad

3. Requisitos específicos Deben declararse los requisitos específicos Ver la sección “características del usuario” Deben tener referencias cruzadas a los documentos que los relacionen Todos los requisitos deben ser singularmente identificables Debe buscarse el máximo de legibilidad

Software - Atributos del sistema Fiabilidad Disponibilidad Seguridad Mantenimiento Portabilidad