Jfcastillo

281 views
179 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
281
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Jfcastillo

  1. 1. Requerimientos No-Funcionales y Arquitectura de Software Jaime F. Castillo. QuarkSoft, S.C. CIMAT, A. C. © QuarkSoft
  2. 2. Agenda • • • • • • • • • © QuarkSoft Objetivo Ingeniería de Requerimientos Niveles de Requerimientos Documentos de Requerimientos Requerimientos No-Funcionales Requerimientos Arquitecturales Atributos de Calidad Conclusiones Comentarios y Preguntas
  3. 3. Objetivo • Presentar los conceptos generales de la Ingeniería de Requerimientos y el impacto de los requerimientos no funcionales en el desarrollo de la arquitectura de software. © QuarkSoft
  4. 4. Ingeniería de Requerimientos © QuarkSoft
  5. 5. Niveles de requerimientos • Los Requerimientos de Software incluyen tres niveles: – Requerimientos de Negocio (RN). – Requerimientos de Usuario (RU). – Requerimientos Funcionales / No Funcionales (RF / RNF). © QuarkSoft
  6. 6. Documentos Requerimientos Template de RN n Template de RN ... Objetivos de negocio que se quieren alcanzar con el Sistema Template de RN 3 Template de RN 2 Template de RN 1 Template de RU n Template de RU ... Actividades que el usuario realiza con el sistema Template de RU 3 Template de RU 2 Template de RU 1 Visión y Alcance de Negocio (VAN) Documento Integrador de Requerimientos de Usuario (DIRU) Template de RF n Template de RF ... Template de RF 3 Template de RF 2 Template de RF 1 Funcionalidad del Sistema Template de RNF n Template de RNF ... Template de RNF 3 Template de RNF 2 Template de RNF 1 © QuarkSoft Especificación de Requerimientos de Software (Software Requirement Specification - SRS)
  7. 7. Requerimientos No Funcionales • Los requerimientos no funcionales incluyen: – Restricciones • Las restricciones son características que no pueden ser negociadas y que son impuestas por el cliente como guía o definición para el sistema – Atributos de calidad. • Son propiedades o características del sistema que importan a los stakeholders y que por lo tanto afectarán el grado de satisfacción del sistema. • Este tipo de requerimientos pueden ser evaluados con dos enfoques: – Factores de Calidad (externo) – ejecución. – Criterios de Calidad (interno) - desarrollo. © QuarkSoft
  8. 8. Requerimientos Arquitecturales • Los requerimientos que tienen una mayor influencia sobre la arquitectura y sus componentes son: – Objetivos de Negocio – Requerimientos Funcionales. – Atributos de Calidad – Restricciones © QuarkSoft
  9. 9. Atributos de Calidad • De acuerdo a los autores del libro “Software Architecture in Practice” en alrededor del 90% de los sistemas que se han evaluado, los atributos de calidad se agrupan en seis categorías principales: – De importancia para el cliente / usuario. • • • • • Desempeño (3). Usabilidad (6). Disponibilidad (1). Seguridad (4). Interoperabilidad, Confiabilidad, Escalabilidad, Precisión. – De importancia para el desarrollador. • Modificabilidad (2). • Facilidad de Prueba (5). • Reusabilidad, Extensibilidad, Portabilidad, Facilidad de Instalación. © QuarkSoft
  10. 10. Documentación de los RNF • Dependiendo de los tipos de RNF solicitados por cliente/usuario, se recomienda hacer un análisis para identificar el costo/beneficio de cumplir unos u otros. • La definición de los RNF debe realizarse considerando las siguientes características (SMART por sus siglas en inglés): – Específico (Specific): sin ambigüedad, conciso, claro, simple y con suficiente detalle. – Medible (Measurable): debe poderse evaluar si se cubrió el requerimiento o no. ¿Qué pruebas se deben realizar? O ¿Qué criterios se deben cumplir? – Alcanzable (Attainable): técnicamente factible. Análisis profesional de la posibilidad del requerimiento. © QuarkSoft
  11. 11. Documentación de los RNF – Realizable (Realizable): se puede llevar a cabo con los recursos disponibles. ¿Se tiene a la gente, la habilidad, la infraestructura, el tiempo…? – Rastreable (Traceable): se le puede dar seguimiento desde su concepción, a través de la especificación, diseño, implementación y prueba. © QuarkSoft
  12. 12. Documentación de los RNF • Una técnica para validar la claridad y definición de un RNF es la técnica de escenarios. © QuarkSoft
  13. 13. Documentación de RNF • Entradas – Fuente de Estímulo: es el actor que genera el estímulo (usuario, sistema, etc…) – Estímulo: es la condición que necesita ser considerada al presentarse en el sistema. • Condiciones – Entorno: condiciones en las que se encuentra el sistema al presentarse un estímulo. – Artefacto: componente o destinatario que recibe el estimulo (puede ser todo el sistema o una o más partes) • Resultados Esperados – Respuesta: es la actividad que se realiza una vez detectado el estímulo. – Medida de Respuesta: métrica definida para el tipo de estímulo y poder determinar un valor cuantificable. © QuarkSoft
  14. 14. Ejemplos de RNF Número de requerimiento SICOBIM-RE01 Descripción del requerimiento Las consultas del sistema deberán responder de manera inmediata Req. de usuario relacionado N/A. Razón por la que es requerido Si una consulta tarda mucho, podría dejar esperando a otros procesos, afectar en el servidor e interferir con el trabajo cotidiano del usuario. Métrica con la que se determinará que el requerimiento esta cubierto Segundos (máximo de tiempo por consulta, medido en segundos). Dependencias con otros requerimientos en caso de existir] SICOBIM-RE02 Conflictos con otros requerimientos en caso de existir N/A. © QuarkSoft
  15. 15. Ejemplos de RNF Atributo Despempeño Fuente Usuario Estímulo Consulta Catálogo de Productos Artefacto Sistema Entorno Operación Normal Respuesta Resultado de la Consulta Medida T <= 3s El usuario podrá consultar el catálogo de productos del sistema, en un horario de operación normal, obteniendo el resultado en un tiempo máximo de 3 segundos Disponibilidad Externa Fallo en dispositivo I/O Controlador Operación Normal -Mensaje de error en pantalla -Deshabilitar Dispositivo Sin interrupción en la operación El sistema deberá mostrar un mensaje de error en pantalla y deshabilitar un dispositivo, cuando algún fallo en este último afecte al controlador del sistema, sin ocasionar interrupción en la operación. Modificabilidad Desarrollador Agregar Regla de Negocio Otorgamiento de Crédito Fase de Desarrollo El código es integrado # clases modificadas <= 2 Un desarrollador podrá agregar una nueva regla de negocio al módulo de otorgamiento de crédito modificando máximo 2 clases. Seguridad Usuario Intentos erróneos consecutivos de acceso Login de Sistema Operación -Registro de evento en bitácora -Bloqueo de cuenta # intentos = 3 El sistema bloqueará la cuenta del usuario y registrará dicho evento en bitácora cuando el usuario tenga 3 intentos erróneos consecutivos de acceso. © QuarkSoft
  16. 16. Problemática • El desarrollo de la Arquitectura se convierte en una preferencia tecnológica por parte del Arquitecto de Software y no en el cumplimiento de los RNF. • No se evalúa la arquitectura de software. • Dentro del desarrollo de requerimientos la obtención de requerimientos no funcionales representa un área de oportunidad. © QuarkSoft
  17. 17. Retos • Investigación sobre la obtención, análisis, especificación y validación de requerimientos no funcionales. • Desarrollo de una estrategia para la mejora de competencias de Ingenieros de Requerimientos y Arquitectos de Software (y su relación). • Mejora de la calidad de los productos de trabajo de la fase de requerimientos a través de inspecciones (fondo). © QuarkSoft
  18. 18. Comentarios y Preguntas FIN eMail jcastillo@quarksoft.ne castillo@cimat.mx © QuarkSoft
  19. 19. Referencias • • • • • • • • © QuarkSoft Use cases; Daryl Kulak, Eamonn Guiney Verification and validation for quality of UML 2.0 models; Bhuvan Unhelkar Requirement Engineering, Karls E. Wiegers, Second Edition. Use case modeling; Kurt Bittner, Ian Spence, Ivar Jacobson More About Software Requirements: Thorny Issues and Practical Advise; Karl E. Wiegers Defining Non-Functional Requirements; Ruth Malan and Dana Bredemeyer Models for Evaluating and Improving Architecture Competence, Len Bass, Paul Clements, Rick Kazman, Mark Klein, March 2008, TECHNICAL REPORT, CMU/SEI-2008TR-006 Conceptos de Arquitectura de Software: Requerimientos Arquitecturales; Humberto Cervantes Maceda

×