I genier i í er a í de Requeri er m i i m en t s

Transcripción

1 Ingeniería de Requerimientos WEBinar

2 Objetivos Describir los conceptos relacionados con la ingeniería y administración de Identificar actividades y productos relacionados

3 Referencias Software Requirements. Karl E. Wiegers Use Cases, Requirements in Context. Daryl Kulak and Eamonn Guiney More about software requirements. Karl E. Wiegers The Capability Maturity Model. Addison Wesley icles.html

4 Contenido Introducción Qué son los? Ingeniería de Obtención de Análisis de Especificación de Verificación de Aceptación de Administración de 4

5 Introducción

6 Por qué fracasan los proyectos? 6

7 Por qué fracasan los proyectos? Pobre definición de los Falta de experiencia en el contexto o dominio del negocio Falta de una definición clara de los Errores amplificados conforme va avanzando el ciclo de vida de los proyectos Los no se administran adecuadamente Planeación errónea o inexacta 7

8 Problemas con los No satisfacen las necesidades del cliente Insuficiente involucramiento por parte del usuario No proveen soluciones consistentes Requerimientos ambiguos Gold plating Especificación mínima o exigua Valdez Aldrete Berta Alicia, Pérez Villaseñor José Enrique, Administración de Proyectos de Software para Micro y Pequeña Empresa Tutorial, SEPG LA, Fuente: CIMAT 8

9 Problemas con los No permiten la implementación de sistemas estables (cambios frecuentes) Los son obtenidos por personas sin el perfil adecuado o la suficiente capacitación No se sabe a qué requerimiento satisface determinado procedimiento No se sabe qué procedimiento implementa un determinado requerimiento Valdez Aldrete Berta Alicia, Pérez Villaseñor José Enrique, Administración de Proyectos de Software para Micro y Pequeña Empresa Tutorial, SEPG LA, Fuente: CIMAT 9

11 Qué son los? 11

12 Qué es un requerimiento? El estándar de IEEE (1997 ) define un requerimiento como: Una capacidad necesitada por un usuario para resolver un problema o llevar a cabo un objetivo Una condición o capacidad que debe tener un sistema o un componente del sistema para satisfacer un contrato, estándar, especificación u otros documentos formales 12

13 Características deseables de los Completo Necesario Consistente Priorizado Correcto Verificable Factible Rastreable Modificable Claro 13

14 Que No son los En una especificación de no se incluyen: Detalles de diseño e implementación Uso de lenguaje tecnológico Información sobre la planeación del proyecto o sobre pruebas A este tipo de se le conocen como del proyecto que no tienen que ver con los de negocio o de la solución. Ejemplos de los del proyecto son: Requerimientos del ambiente de desarrollo Limitaciones del cronograma Limitaciones del presupuesto Requerimientos para liberar un producto, etc. Fuente: Wiegers, Karl E., Software Requirements, 2nd edition, Microsoft Press,

15 Tipos de Requerimientos de negocio Requerimientos de usuario Requerimientos funcionales Requerimientos No funcionales Fuente: Wiegers, Karl E., More AboutSoftware Requirements,, Microsoft Press,

16 Requerimientos de negocio Representan los objetivos de alto nivel de la organización, en general las necesidades del cliente. Establecen los beneficios que los clientes esperan recibir del producto. Describen porqué la organización esté llevando a cabo el proyecto. Se podrían documentar por ejemplo en: Documento de visión y alcance Documento de caso de negocio Project charter 16

17 Requerimientos de Usuario Describen lo que los usuarios podrán realizar con el producto. Definen los de software desde el punto de vista del usuario, describe las tareas que los usuarios necesitan realizar con el producto. Se podrían documentar por ejemplo en: Casos de uso Escenarios Historias de usuario 17

18 Requerimientos Funcionales Los funcionales son lo que los usuarios necesitan para que el sistema funcione. Incluyen las cosas que los usuarios y los desarrolladores requieren que el sistema haga. La identificación y definición de los funcionales no es un ejercicio de cómo el sistema soportará las funciones, actividades, tareas, sino un ejercicio de detallar qué funciones soportará el sistema y cómo verán y sentirán el sistema los usuarios. Este tipo de podrían documentarse en una especificación de de software o SRS, y es la que se entregara a los desarrolladores o a los tester s. 18

19 Ejemplo de tipos de Programa para procesamiento de texto Requerimiento de negocio: Los usuarios podrán corregir errores de ortografía en un documento de manera sencilla y eficiente Requerimiento de usuario: Encontrar los errores de ortografía en el documento y permitir al usuario decidir si quiere reemplazar cada palabra que contenga un error de ortografía con alguna de las palabras correctas sugeridas en una lista. Requerimiento funcional: Encontrar cada uno de los errores de ortografía en el documento y resaltarlas, desplegar una caja de dialogo con las palabras correctas sugeridas y permitir corregir solo la palabra seleccionada o todas las que se encuentran en el documento. 19

20 Requerimientos No Funcionales (Atributos de Calidad) Están relacionados con las características de calidad del sistema Fácilmente modificable Seguridad Portabilidad Confiabilidad Fácil de probar. Propiedad que debe tener el producto resultante y comportamiento que deben tener las funciones establecidas. Usabilidad Eficiencia Escalabilidad Desempeño Seguridad Disponibilidad 20

22 Ingeniería de Requerimientos 22

23 Ingeniería de Requerimientos Disciplina para desarrollar una especificación completa, consistente y no ambigua, la cual servirá como base para acuerdos comunes entre todas las partes involucradas y en dónde se describen las funciones que realizará el sistema" Boehm Es el proceso por el cual se transforman los declarados por los clientes, ya sean hablados o escritos, a especificaciones precisas, no ambiguas, consistentes y completas acerca del comportamiento del sistema, incluyendo funciones, interfaces, rendimiento y limitaciones". STARTS Guide Es el proceso mediante el cual se intercambian diferentes puntos de vista para recopilar y modelar lo que el sistema va a realizar. Este proceso utiliza una combinación de métodos, herramientas y actores, cuyo producto es un modelo del cual se genera un documento de " Leite

24 Fases Ingeniería de Requerimientos Obtención de Aceptación de Análisis de Verificación de Especificación de Administración de Requerimientos 24

25 Obtención de Requerimientos Obtención de Aceptación de Análisis de Verificación de Especificación de Administración de Requerimientos 25

26 Obtención de Requerimientos La elicitación es el proceso para identificar y entender las necesidades y restricciones del producto que requiere el usuario o el cliente. Es la etapa de mayor interacción con el usuario. Es el momento en el que se recurre, por ejemplo, a la observación, lectura de documentos, entrevistas, levantamiento, entre otras técnicas.

27 Actividades Identificar los de negocio y desarrollar un documento de visión y alcance Definir un procedimiento para el desarrollo de Identificar los diferentes tipos de usuario Identificar y seleccionar a los expertos de negocio que especificaran los de negocio (usuarios clave) Establecer grupos clave para la identificación de Identificar casos de uso Preparar y realizar talleres que faciliten la obtención de Observar a los usuarios realizar su trabajo cotidiano y analizar sus flujos de trabajo Identificar los atributos de calidad Identificar que se pueden re-utilizar de la base de conocimiento de la organización o de los proyectos

28 Productos generados Procedimiento p/desarrollo de Lista stakeholders y grupos de trabajo Necesidades y objetivos del negocio Obtención Visión y alcance Necesidades de los usuarios Atributos de calidad/ No funcionales Flujos de trabajo de usuarios Casos de uso Requerimientos Funcionales (Preliminar) 28

29 Análisis de Requerimientos Obtención de Aceptación de Análisis de Verificación de Especificación de Administración de Requerimientos 29

30 Análisis de Requerimientos El análisis de implica refinar, analizar, y examinar/escudriñar los obtenidos para asegurar que todos los stakeholders entienden lo que pidieron, y para encontrar errores, omisiones y otras deficiencias.

31 Objetivo del análisis de Representar algunos de los en más de una forma (textual o gráfica). Trabajar con los clientes/usuarios para aclarar confusiones y para establecer que son más importantes que otros. Asegurar que entre los clientes/usuarios hay un entendimiento común, una visión compartida, de lo que tendrán cuando el producto esté terminado. 31

32 Actividades Dibujar un diagrama de contexto Asociar a subsistemas para dividir el problema Analizar la factibilidad de los Priorizar los Modelar los (modelos gráficos) Crear prototipos Crear interfaces de usuario (un prototipo si es necesario) Crear un diccionario de datos (de alto nivel)

33 Productos generados Diagrama de contexto Prototipos Productos generados en la Obtención de Requerimientos Análisis Análisis de factibilidad Diccionario de datos Requerimientos priorizados Modelado de Diagramas Flujo de datos Actividad Clases Entidad relación Interacción Transición de estados Mapas de dialogo 33

34 Especificación de Requerimientos Obtención de Aceptación de Análisis de Verificación de Especificación de Administración de Requerimientos 34

35 Especificación de Requerimientos En esta actividad se documenta la descripción completa de las necesidades y funcionalidades del sistema que será desarrollado; describe el alcance del sistema y la forma como hará sus funciones, definiendo los funcionales y no funcionales.

36 Actividades Elaborar la SRS Identificar cada requerimiento (etiquetar) Documentar reglas de negocio Especificar los atributos de calidad Crear la matriz de rastreabilidad 36

37 Ejemplo SRS Alcance del producto Perspectiva y funciones del producto Tipos de usuario y características Suposiciones y dependencias Restricciones de diseño e implementación Requerimientos funcionales Atributos de calidad / Requerimientos no funcionales (desempeño, seguridad, usabilidad, confiabilidad) Requerimientos de interfase (hw, sw, usuario, externas, comunicación) Reglas de negocio Ambiente de operación Documentación de usuario 37

38 Productos generados Template SRS Requerimientos Funcionales SRS Productos generados en la obtención y análisis de Especificación Matriz de rastreabilidad Requerimientos no funcionales 38

39 Verificación de Requerimientos Obtención de Aceptación de Análisis de Verificación de Especificación de Administración de Requerimientos 39

40 Importancia de la detección de defectos en las fases tempranas Fuente: CIMAT 40

41 Propósito Asegurar que se realizó una descripción correcta del comportamiento y características del sistema Cubrir las características deseables de los Completo, Consistente, Correcto, Factible, Modificable, Necesario, Priorizado, Verificable, Rastreable, Claro Proveer una base adecuada para continuar con el diseño 41

42 Consideraciones Seleccionar revisores de diferentes disciplinas Asegurar entrenamiento en ingeniería de Conocimiento y establecimiento de estándares de documentación de Preparar checklist para la revisión de 42

43 Actividades Realizar inspecciones a los documentos de Aplicar pruebas a los Definir los criterios de aceptación para los productos de los 43

44 Productos generados Criterios de aceptación Documentos de revisados Productos generados en la obtención y análisis especificación de Verificación Casos de prueba Manual de usuario 44

45 Aceptación de Requerimientos Obtención de Aceptación de Análisis de Verificación de Especificación de Administración de Requerimientos 45

46 Aceptación de Requerimientos Obtener la aprobación para la especificación de. Presentar la especificación de Formalizar el compromiso hacia la especificación de por todos los involucrados en el proyecto Obtener la aprobación por parte del cliente

47 Productos generados Productos generados en la obtención y análisis especificación de Aceptación Documentos de Requerimientos aceptados 47

48 Fases de la Ingeniería de Requerimientos Obtención Lista stakeholders y grupos de trabajo Atributos de calidad/ No funcionales Visión y alcance Requerimientos Funcionales (Preliminar) Casos de uso Análisis Diagrama de contexto Diccionario de datos Prototipos Análisis de factibilidad Requerimientos priorizados Modelo de Especificación SRS Matriz de rastreabilidad Requerimientos Funcionales Requerimientos no funcionales Verificación Criterios de aceptación Documentos de revisados Casos de prueba Manual de usuario Aceptación Documentos de Requerimientos aceptados 48