Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

SIREN - Jornadas de Ingeniería de Requisitos Aplicada

874 views

Published on

Un Proceso de Ingeniería de Requisitos Basado en Reutilización

Published in: Technology
  • Be the first to comment

  • Be the first to like this

SIREN - Jornadas de Ingeniería de Requisitos Aplicada

  1. 1. SIREN: Un Proceso de Ingeniería de Requisitos Basado en Reutilización Ambrosio Toval, Joaquín Nicolás y Begoña Moros Departamento de Informática y Sistemas. Facultad de Informática. Universidad de Murcia Jornadas de Ingeniería de Requisitos Aplicada Sevilla, 11-12 de junio de 2001
  2. 2. Contenido„ Introducción„ IR + Reutilización„ SIREN ƒ Plantillas de documentos de requisitos ƒ Repositorio de requisitos reutilizables ‚ Seguridad y Protección de Datos ƒ Modelo de proceso ƒ SIREN y Métrica„ Conclusiones y trabajo futuro 2
  3. 3. IntroducciónSIREN = “Método práctico de IR basado en reutilizaciónde requisitos, compatible con los principales estándares en Ingeniería del Software” Estándares y buenas prácticas en IR IEEE 830-1998 SEGURIDAD IEEE 1233-1998 ... Repositorio con Requisitos PROTECCIÓN DE DATOS Especificación SyRS SyTS Ingeniero de Requisitos de Requisitos IRS SRS STS 3 Usuarios
  4. 4. IR y Reutilización„ Nuseibeh & Easterbrook (ICSE00), ƒ “Esperamos el desarrollo de modelos de referencia para especificar requisitos en muchos dominios de aplicación.”„ A. van Lamsweerde (ICSE00), ƒ “Sorprendentemente, las técnicas para recuperar, adaptar y consolidar requisitos reutilizables han recibido relativamente poca atención en relación con todo el trabajo en reutilización del software.” 4
  5. 5. Enfoque SIREN de reutilizaciónde requisitos „ Método de especificación de requisitos: ƒ modelo de proceso ƒ guías (p.ej. la estructura de los documentos de especificación de requisitos) ƒ requisitos para dominios específicos ƒ herramienta de soporte 5
  6. 6. Jerarquía de documentos de requisitos SyRS Especificación de Requisitos SyTS del Sistema Especificación de pruebas (IEEE Std. 1233; del Sistema IEEE Std. 12207.1) IRS SRSEspecificación de Requisitos Especificación de Requisitos STS de Interfaz del Software Especificación de pruebas (IEEE Std. 830) (IEEE Std. 830 + del Software VOLERE) „ Cada documento se debe corresponder con un nivel de especificación diferente ⇒ diferentes objetivos y usuarios „ La jerarquía se decide en función de la complejidad y el tamaño del proyecto 6
  7. 7. 1 Introducción 2 Descripción globalsistema 1.1 Propósito del del sistemaSyRS- System Requirements 1.2 Alcance del sistema 2.1 Contexto del sistema 3 Capacidades del sistema, abreviaturas y restricciones 1.3 Definiciones, acrónimos y condiciones 2.2 Modos y estados del sistema 1.4 Referencias capacidades del sistema 2.3 Físicas Principales 3.1 Visión global del sistema 1.5 Principales condiciones del sistema 2.4 3.1.1 Construcción 2.5 Principales restricciones del sistema 3.1.2 Durabilidad 2.6 Características de usuarios 3.1.3 Adaptabilidad 2.7 Suposiciones y dependencias 3.1.4 Condiciones ambientales 2.8 Escenarios operacionales 3.2 Características de rendimiento del sistema 3.3 Seguridad del sistema 3.4 Gestión de la informaciónSpecification 3.5 Operaciones del sistema 3.5.1 Factores humanos del sistema 3.5.2 Mantenimiento del sistema 3.5.3 Fiabilidad del sistema 3.6 Política y regulación 3.7 Apoyo al ciclo de vida del sistema 4 Interfaces del sistema 5 Anexos 7
  8. 8. SRS- Software Requirements 1 Introducción 1.1 Propósito 2 Descripción global 1.2 Alcance 2.1 Visión del producto 3 Requisitos específicos 2.2 Funciones delacrónimos y abreviaturas 1.3 Definiciones, producto 3.1 Requisitos de interfaces externas 1.4 Referencias 2.3 Características de usuario 3.2 Requisitos funcionales 1.5 Visión general del documento 2.4 Limitaciones generales 3.3 Requisitos de prestaciones 3.3.1 Requisitos de velocidad 2.5 Suposiciones y dependencias 3.3.2 Requisitos de seguridad críticos 3.3.3 Requisitos de precisión 3.3.4 Requisitos de capacidad 3.4 Restricciones de diseño 3.4.1 Entorno físico esperado 3.4.2 Entorno tecnológico esperado 3.4.3 Aplicaciones asociadas 3.4.4 Cumplimiento de estándaresSpecification 3.5 Atributos del sistema software 3.5.1 Fiabilidad 3.5.2 Disponibilidad 3.5.3 Seguridad 3.5.4 Mantenimiento 3.5.5 Portabilidad 3.6 Otros requisitos 3.6.1 Requisitos de apariencia 3.6.2 Requisitos de utilización 3.6.3 Requisitos políticos y culturales 3.6.4 Requisitos legales 4 Anexos 8
  9. 9. Repositorio de requisitos SRS … „ dominios 3. Requisitos específicos … 3.5 Requisitos de Sistema Software … „ perfiles 3.5.3.Seguridad …3.5.3.1 Confidencialidad SRS3531S23 El usuario... SRS3531L12 La auditoría... … Repositorio de Requisitos Reutilizables SRS SRS … SRS 3. Requisitos específicos … … … 3. Requisitos específicos 3. Requisitos específicos 3.5 Atributos del sistema software … … … 3.5 Attributes del sistema software 3.5 Atributos del sistema software 3.5.3.Seguridad … … …3.5.3.1 Confidencialidad 3.5.3.Seguridad 3.5.3.Seguridad … …3.5.3.1 Confidencialidad …3.5.3.1 Confidencialidad SRS3531L12 La auditoría ... SRS3531S23 El usuario ... … … Perfil de Seguridad Perfil de la LOPD Perfil … 9
  10. 10. Clasificación de requisitos„ parametrizados:S R S .3 .5 .3 .1 .S .3 0 El administrador de seguridad deberá realizar comprobaciones cada [Tiempo en meses] para detectar identificadores de usuario que no hayan sido utilizados en los últimos [Tiempo en meses].„ no-parametrizados:S Y R S .3 .1 .1 .S .6 8 . Los documentos y disquetes deberán guardarse perfil en armarios cuando no se usen Ubicación y especialmente fuera de la jornada laboral. documento sección dentro del documento 10
  11. 11. Atributos de los requisitos„ Obligatorios: ƒ identificación (única) ƒ justificación ƒ prioridad ƒ mantenimiento ƒ criticidad ƒ prestaciones ƒ viabilidad ƒ fiabilidad IEEE 1233 ƒ estado (pendiente de definición, pendiente de revisión, definido, descartado, aprobado, implementado y verificado)„ Dependientes del dominio o perfil (p.ej. Seguridad y Protección de datos): ƒ Fuente ƒ Cumplimiento 11
  12. 12. Relaciones de traza„ Representan dependencias entre requisitos„ Tipos de dependencias: ƒ inclusivas ƒ exclusivas entre requisitos ƒ del mismo documento ƒ de documentos diferentes 12
  13. 13. Ejemplo. Extracto del SyRS ( ...)3. Capacidades del sistema. Condiciones y restricciones. 3.1. Físicas. 3.1.1. Construcción. ( ...)( R 1) S Y R S 3 11S 6 8 . Los documentos y disquetes se guardarán bajollave cuando no se estén utilizando y fuera de la jornada laboral. 3.6. Política y Regulación.( R 2 ) S Y R S 3 6 S 2 6 . Los usuarios autorizados del sistema deinformación deberán conocer su responsabilidad en relación a los controlesde acceso y a la información que está bajo su disposición. Para ello seestablecerán tres condiciones:a)Los usuarios autorizados tendrán que usar su clave de manera adecuada.b)Los usuarios autorizados no pueden descuidar ni un momento lainformación que manejan.c)Los usuarios autorizados tienen que seguir las medidas de seguridadimpuestas para evitar accesos no autorizados a la información quemanejan. 13 Dependencias: R1, R3 (...)
  14. 14. Ejemplo. Extracto del SRS...3. Requisitos específicos. R1 3.5. Atributos del software. R2 3.5.3. Seguridad. R3 R4 3.5.3.1. Confidencialidad.( R 3 ) S R S 3 5 3 1S 1. El sistema operativo que se utilice proporcionará elmecanismo de claves para controlar y/o limitar el acceso a los usuarios. D e p e n d e n c ia s : R 4( R 4 ) S R S 3 5 3 1S 14 . El sistema operativo que se utilice proporcionaráprogramas para verificar la calidad de las contraseñas en el Sistema deControl de Accesos. Se dice que una clave es de calidad si cumple por lomenos estas tres características:a)El número mínimo de caracteres es [n, n >= 6].b)Tiene al menos [n, n>=1] caracteres numéricos y [m, m>=1] caracteresalfanuméricos.c)Se cambia cada [tiempo en días] para usuarios generales y cada [tiempoen días] para usuarios con privilegios. 14
  15. 15. Ejemplo de traza exclusivaintradocumentoS R S .3 .4 .3 .S .5 . El firewall deberá ser establecido en unaconfiguración screened host.Exclusiones: SRS.3.4.3.S.6S R S .3 .4 .3 .S .6 . El firewall deberá ser establecido en unaconfiguración screened subnet.Exclusiones: SRS.3.4.3.S.5. 15
  16. 16. Perfiles de Seguridad y Protecciónde Datos„ Seguridad ƒ Fuente: MAGERIT ƒ Estudiar los riesgos que afectan al SI ƒ Especificar los requisitos que gestionan dichos riesgos (medidas de salvaguarda)„ Protección de Datos ƒ Fuente: LOPD y RMS ƒ Más práctico que consultar directamente la ley 16
  17. 17. Modelo de proceso de SIREN RequisitosUtilización informales delRepositorio Análisis y Elicitación Negociación Documento de Requisitos requisitos e aceptados informe de validación Validación Documentación Borrador de documento de requisitos 17
  18. 18. Repositorio Reutilizable Selección de Requisitosreutilización de requisitos SEGURIDAD Plantillas rellenas con Requisitos LOPD SyRS SyTS DB reutilizados ... Plantillas SyRS SyTS vacías IRS SRS STSEnfoque SIREN para IRS SRS STS Requisitos Informales Mejora del Elicitación de Análisis y Repositorio Requisitos Negociación Específicos Requisitos Aceptados SyRS SyTST Documentos de SyRSSyTS Requisitos Validados IRS SRS STS IRS SRS STST Validación Documentación SyRSSyTS Continuar: análisis, diseño, IRS SRS STS implementación, ... Stakeholders Borrador de Documentos de Requisitos Analista 18
  19. 19. SIREN y Métrica v.3„ Soporte a la actividad ASI 2. “Establecimiento de Requisitos”: ƒ estructura del catálogo de requisitos de Métrica ƒ modelo de proceso para llevar a cabo las tareas de obtención, análisis y validación de requisitos.„ Además, soporte a: ƒ tarea DSI 1.7. “Especificación de Requisitos de Operación y Seguridad” ƒ interfaz de Seguridad de Métrica v.3 con MAGERIT (perfiles de seguridad y protección de datos) 19
  20. 20. Conclusiones„ Método basado en la reutilización de requisitos y en estándares de Ing. Sw. ƒ Acelera el proceso de desarrollo ƒ Plantea explícitamente los requisitos de calidad del software ƒ Compatible con Métrica v.3 20
  21. 21. Trabajo futuro „ Refinar el modelo de referencia de requisitos ƒ plantillas de requisitos, patrones lingüísticos, relaciones de traza „ Gestión de inconsistencias „ Soporte al proceso ƒ reutilización ƒ relaciones exclusivas ƒ requisitos parametrizados ƒ estructura del repositorio „ Nuevos dominios y perfiles ƒ Tarjeta inteligente „ Más casos de estudio reales 21
  22. 22. SIREN: Un Proceso deIngeniería de Requisitos Basado en Reutilización Gracias por su atención !

×