Gestión de Requerimientos REQM 08/07/2010 Slide 1 CMMI REQM.

Gestión de Requerimientos

www.heinsohn.com.co

REQM

08/07/2010 Slide 1CMMI REQM

CMMI REQM

Agenda Objetivos Conceptos Claves Metodología de Levantamiento Modelamiento de Procesos Casos de Uso Entregables y Criterios de Aceptación Prácticas relacionadas Heinsohn - REQM Bibliografía

08/07/2010 Slide 2

08/07/2010 CMMI REQM Slide 3

Objetivos Conocimiento general de las áreas de proceso CMMI Conocer las reglas que se tienen en cuenta para llevar a

cabo el levantamiento de requerimientos Conocer el proceso metodológico que es utilizado para

llevar a cabo el levantamiento de requerimientos Conocer en detalle el proceso de especificación de

requerimientos funcionales utilizando casos de uso Conocer la relación de las prácticas de Heinsohn con REQM

CMMI REQM


08/07/2010 Slide 4

CMMI REQM08/07/2010 Slide 5

Que es CMMI

Es un modelo de mejora de procesos que proporciona a las organizaciones los elementos esenciales de procesos efectivos que en última instancia mejoran su rendimiento.


Áreas de Interés CMMI

Desarrollo de productos y servicios (CMMI para el modelo de desarrollo)

Servicio de creación, gestión y entrega (CMMI para el modelo Servicios)

Productos y servicios de adquisición (CMMI para el modelo de Adquisición)


CMMI para el modelo de desarrollo

Es un modelo o una colección de las "mejores prácticas" que las organizaciones deben seguir para mejorar la eficacia, la eficiencia y la calidad de su producto.


Niveles de Madurez

Nivel 1: Inicial -> Los resultados son obtenidos por el esfuerzo de las personas.

Nivel 2: Gestionado -> Prácticas básicas de gestión de proyectos, requerimientos y control de versiones.

Nivel 3: Definido -> Los procesos para el desarrollo están documentados y son accesibles por el equipo de desarrollo.

Nivel 4: Gestionado cuantitativamente -> Se mide la calidad del producto.

Nivel 5: Optimizado -> Cuenta con medios para identificar debilidades y prevención de defectos.


REQM

Su objetivo es administrar los requerimientos de los proyectos y componentes de productos e identificar las inconsistencias entre requerimientos, planes de proyectos y productos de trabajo.

08/07/2010 CMMI REQM

SP 1.1 Obtener requerimientos por parte de los Stakeholders

SP 1.2 Obtener aprobación de los requerimientos SP 1.3 Administrar cambios en los requerimientos SP 1.4 Mantener una trazabilidad de los requerimientos SP 1.5 Identificar inconsistencias entre el plan del proyecto

y los requerimientos.

Prácticas Especificas

Slide 12


Categorías Áreas de Proceso

Ingeniería Soporte Administración de Proyectos Administración de Procesos

Áreas de Proceso - Categorías - Nivel de Madurez.JPG


Introducción requerimientos 1

Una definición de CALIDAD es:

“El grado en que un producto, proceso o sistema cumple con sus requerimientos” Si los requerimientos no están bien definidos no se obtendrá un producto de Calidad

(IEEE 610.12)



Factores para el éxito de proyectos

Involucrar al usuarioApoyo de los directivosClara definición de los requerimientos

THE STANDISH GROUP REPORT (CHAOS),1995

“ … Obtener un buen conjunto de requerimientos es un proceso muy difícil.”

Ed Meagher, Government Computer News, 2003



Debemos entender qué vamos a desarrollar antes de desarrollarlo.

Deb Jacobs, CrossTalk, 2006



Cada aplicación de software tiene usuarios que confían en ella para mejorar sus vidas. El tiempo que se pasa entendiendo las necesidades de los usuarios es una inversión de alto nivel en el éxito del proyecto.

Karl Wiegers, 2001


Que es un Requerimiento de Software

Una necesidad del usuario, o una característica, función o atributo necesario en un sistema, que puede ser percibido desde un punto externo a dicho sistema

Alan Davis

Una condición o capacidad que debe tener un sistema o un componente para satisfacer un contrato, especificación u otro documento formalmente impuesto.

IEEE (1997)


Niveles de Requerimientos

CMMI REQM


08/07/2010 Slide 20


PR-INGE-001- Requerimientos


Reunión PreliminarObjetivos:

Cuáles tareas del proceso se van a realizar. Qué documentación va a entregar el cliente y con qué nivel de detalle será entregada. Cuál es el nivel de aprobación de cada entregable. Qué entregables se van a producir por el equipo de levantamiento.

Salida: PT-GINF-001-Acta_de_reunion.doc

Slide 22


Reunión de LanzamientoObjetivos:

Dar inicio al proceso de levantamiento de requerimientos. Presentar los miembros del equipo del cliente y de HBT. Mostrar los objetivos del proyecto. Dar a conocer reglas de juego generales del proyecto.

Salida: PT-GINF-001-Acta_de_reunion.doc

Slide 23


Desarrollar la VisiónObjetivos:Enunciar el problema y proponer soluciones al mismo.

Pasos:Ponerse de acuerdo en el problema.Identificar los interesados (Stakeholders)Definir los límites y restricciones del sistema.Formular enunciados del problemaEvaluar los resultadosSalida: PT-INGE-012-Vision.doc

Slide 24


Ejemplo formular enunciado del problema

El problema de: La resolución tardía e incorrecta de los problemas de soporte al cliente.Afecta a: Nuestros clientes, los representantes de soporte al cliente y los técnicos de servicio.El impacto del problema es: Insatisfacción del cliente, disminución de la calidad percibida, empleados descontentos y pérdida de ingresos.Una solución satisfactoria sería: Proporcionar acceso en tiempo real a una base de datos de localización de problemas para los representantes de soporte y facilitar el envío de técnicos de servicio de manera puntual, sólo a aquellas ubicaciones que necesiten realmente su asistencia.

Slide 25


Especificar procesos de negocio

Objetivo:Obtener el entendimiento del negocio por parte de HBT con todos los flujos que participan en un proceso o subproceso y reflejarlo en un diagrama de actividades, en el cual se identifiquen que actividades pueden ser automatizadas.

Pasos:Reuniones aclaratoriasDiagramas de ProcesosDefinir Reglas de NegocioCrear Glosario

Slide 26

CMMI REQM

Reglas de NegocioObjetivo:

Es identificar y documentar las reglas de negocio del proceso. Se debe aclarar que no siempre se encuentran reglas de negocio en un proceso, de hecho su uso es escaso.TiposLeyes, regulacionesEstándares, procesos de la compañíaDirectivas

08/07/2010 Slide 27

CMMI REQM


08/07/2010 Slide 28


Modelamiento de Procesos• Estados Inicial y Final: Todo proceso

debe tener un inicio y un fin. Los elementos Inicio no reciben ninguna entrada y los elementos Final no generan ninguna salida

• Actividad: Representa un paso de un proceso

Inicio

Final

cd Due Diligence pre para ...

«ROL Analista de DD»Pr0074 Seleccionar

archiv os planos

Actividad

Slide 29


Modelamiento de Procesos

• Enlace: Los enlaces se utilizan para representar la transición de un estado a otro y el paso de una actividad a otra

• Decisión: Se utiliza para representar caminos alternativos en el flujo del proceso. Tiene una única entrada y puede tener dos o más salidas. Por cada salida se tiene una expresión booleana que será evaluada al llegar a la bifurcación. Las condiciones deben ser excluyentes y se deben contemplar todos los posibles casos que se puedan generar

Enlace

Slide 30


Modelamiento de Procesos• Fork / Join: Para representar las

tareas concurrentes que pueden formar parte de un proceso se utiliza el elemento Fork. En el diagrama de ejemplo las actividades 2 y 3 se pueden ejecutar concurrentemente. El elemento Join se utiliza para representar la unión al flujo de control secuencial del proceso

Slide 31

CMMI REQM


08/07/2010 Slide 32


¿Qué es un caso de uso? Artefacto cuyo objetivo principal es capturar el

comportamiento del sistema, a través de una secuencia de acciones (flujo de trabajo), que desde la perspectiva del usuario final permiten alcanzar los objetivos deseados.

Un caso de uso describe lo QUE debe hacer el sistema para satisfacer un requisito, NO COMO debe hacerlo.

El caso esta compuesto por uno o más flujos (secuencia de acciones) y es invocado por un actor (usuario o sistema)

Slide 33


¿Qué es un caso de uso?

• Los casos de uso describen la interacción del usuario con el sistema

• La especificación de la interacción debe contemplar posibles flujos alternos ante distintas condiciones que se pueden dar en medio

Actor Sistema

Acción 1

Acción 2

Acción 3

Slide 34


Elementos de Caso de Uso• Actor: Es un rol que un usuario juega en el

sistema. No necesariamente es una persona. Puede estar representado por un grupo de usuarios, otro sistemas o hardware

• Flujo Básico de Eventos: Corresponde al flujo de eventos cuando todas las circunstancias son ideales (todas las validaciones son cruzadas exitosamente).– Se deben numerar cada uno de los pasos

– En cada paso hay que describir la acción efectuada por el actor o por el sistema

Slide 35


Elementos de Caso de Uso

• Flujos Alternos: Toda situación que impida que se pueda llevar a cabo el flujo normal como está presupuestado. Habitualmente validaciones.

• Tipos de validaciones:

Sintácticas : Inherentes a la naturaleza del dato : Obligatoriedad, tipo de dato, rango y formato

Semánticas : A partir del significado del dato o conjunto de datos (Reglas del Negocio)

Se debe indicar el paso en el que se da la situación, la situación, la acción del sistema y a qué paso se retorna

Slide 36


Elementos de Caso de Uso• Pre-condiciones: Preconcepciones acerca del

sistema que deben darse para que se pueda llevar a cabo el caso de uso como esta concebido

• Post-condiciones: Especifica cual es el resultado de valor que genera el caso de uso (cómo modifica su entorno)

Slide 37


EjemploCASO DE ESTUDIO DEL RESTAURANTE “HBT”El restaurante “HBT” desea construir una solución que le permita administrar la elaboración de los diversos platos que ofrece a sus clientes. Para esto, el administrador quiere que se maneje una relación de cada plato junto con los ingredientes necesarios para elaborarlo. Cada relación de ingrediente debe tener la cantidad y costo del mismo. De esta manera, también será posible establecer el costo del plato. El precio cobrado a los clientes siempre será un porcentaje fijo por encima de la suma de los costos de los ingredientes que se requieren para su elaboración. Con esta información registrada, su gerente y dueño desea obtener solo dos servicios:•Que el cocinero, cuando lea una orden escrita por un mesero, consulte en el sistema el plato y conozca cómo elaborar el mismo, junto con sus ingredientes y cantidades.•Que el cajero, al momento de elaborar la cuenta, consulte cada plato y el sistema le diga cuánto cobrar por él. Con ésta información, el cajero puede calcular (con calculadora) el costo total de la cuenta.

Slide 38


Ejemplo

uc Primary Use Cases

System Boundary

Consultar elaboración de plato

Cocinero

Consultar plato

Cajero

Roles

Asociaciones

Casos de uso

Slide 39


Ejemplo• Consultar elaboración de un plato

– Breve Descripción: Permite la consulta de la elaboración e ingredientes de un plato

– Entradas: Código del plato. Es un campo alfanumérico. Es obligatorio

– Flujo Básico de Eventos

1. El sistema solicita le sea ingresado el código del plato

2. El actor digita el código del plato y acepta

3. El sistema despliega la información del plato: nombre, elaboración y la lista de ingredientes con código, nombre y cantidad

Slide 40


Ejemplo• Flujos alternativos

– Código del plato no ingresado

1. Si en el paso 1, no se ingresa ningún código, el sistema informa del error y retorna al paso 1 (Obligatoriedad)

– Código del plato no existente

2. Si en el paso 1 se ingresa un código de plato que no existe registrado en el sistema, el sistema informa del error y retorna al paso 1 (validación semántica)

Slide 41


Ejemplo

• Pre-condiciones

– El sistema cuenta con todo el registro de los platos y sus elaboraciones

• Post-condiciones

– El sistema despliega los datos de la elaboración del plato junto con sus ingredientes

Slide 42


Relaciones de los casos de uso• Inclusión

– Se factoriza una interacción en un conjunto de casos (al menos 2) uc Primary Use Cases

Administrador

(from Actors)

Consultar estado cartera

Cancelar pedido

Validar usuario y password

«include»

«include»

Los dos casos de uso incluyen en su narración la validación del usuario y password

1. El sistema solicita le sea ingresado el usuario y la palabra clave

2. El actor digita los datos y acepta3. El sistema verifica el usuario y el

password y genera un mensaje de éxito

Slide 43

08/07/2010

Relaciones de los casos de uso• Extensión

– Permite que se pueda extender un flujo de eventos de un caso hacia otro caso de uso bajo una situación excepcional

uc Primary Use Cases

Administrador

(from Actors)

Consultar pedido Cancelar pedido«extend»

Luego de consultar un pedido, el actor puede ir al caso de uso de Cancelar pedido

Slide 44

08/07/2010

Luego de consultar un pedido, el actor puede ir al caso de uso de Cancelar pedido

Malas prácticas• El sistema solicita le sea ingresado el dato del plato

– El diseñador y el programador NO saben cuál es el dato. Debe enunciarse específicamente qué datos son ingresados en cada paso de un caso de uso.

• El sistema despliega la información del plato

– El diseñador y el programador no saben cuáles son los datos que se deben desplegar o contemplar en este caso de uso

• El sistema despliega la información del plato: nombre, elaboración y lista de ingredientes

– El diseñador y el programador NO saben qué datos desplegar para los ingredientes = información incompleta

Slide 45

08/07/2010

OTROS TIPOS REQUERIMIENTOS

Requerimientos no funcionales: Utilización, Fiabilidad, Rendimiento, Soportabilidad.

Requerimientos de cumplimiento. Requerimientos de licencia. Requerimientos de documentación.

Slide 46

CMMI REQM


08/07/2010 Slide 47

08/07/2010

Algunos entregables• Requerimiento Funcional. PT-INGE-017-Requerimiento_funcional.doc

• Requerimiento no funcional. PT-INGE-018-Requerimientos_no_funcionales.doc

• Documento de visión. PT-INGE-012-Vision.doc

• Cronograma y resumen del proyecto. 4.19-R2 Plan del proyecto.doc

• Definición preliminar de alcance

• Modelo de procesos

• Matriz de trazabilidad de Procesos vs. Casos de uso

• Especificaciones de casos de uso. PT-INGE-014-Caso_de_uso.doc

• Glosario PT-INGE-016-Glosario.doc

• Reglas de negocio. PT-INGE-019-Reglas_de_Negocio.doc

Slide 48

CMMI REQM


08/07/2010 Slide 49

08/07/2010

Relación REQM con Prácticas Heinsohn• Matriz_Evidencias_CMMI-Health Check.xls

Slide 50

CMMI REQM


08/07/2010 Slide 51

CMMI REQM

BibliografíaCMMI for Develoment 1.2

http://www.sei.cmu.edu/cmmi/ HUP

http://hup.heinsohn.com.co Requirements Engineering Journal

http://www.springerlink.com/content/102830/Crosstalk

http://www.stsc.hill.af.mil/crosstalk/Software Mag

http://www.softwaremag.com/Especialización Ingeniería de Software Universidad Autónoma de Manizales 2010

Sandra Victoria Hurtado Gil

08/07/2010 Slide 52

08/07/2010

ANDRÉS FELIPE NARANJO HENAO

Preguntas

[email protected]

Slide 53

Gestión de Requerimientos REQM 08/07/2010 Slide 1 CMMI REQM.

Documents

Transcript of Gestión de Requerimientos REQM 08/07/2010 Slide 1 CMMI REQM.