Ingenieria de Requerimientos REQM - Requirements Management - CMMI v1.2 RD - Requirements Development - CMMI v1.

2 Cubika Development Process (CDP) 2007 Historia de cambios Fecha Versin Descripcin 08/02/2006 1.0 Versin inicial del documento 09/02/2006 1.1 Revisin y mnimas modificaciones 10/02/2006 1.2 11/04/2006 1.3 Revisin y mnimas modificaciones Autor Ernesto del Puerto Germn Boccoleri Ernesto del Puerto, Germn Boccoleri Germn Boccoleri Laura Delfini Laura Delfini Laura Delfini Laura Delfini Laura Delfini Marcelo Schenone Marcelo Schenone Marcelo Schenone Marcelo Schenone Autor Laura Delfini Marcelo Schenone

Simplificacin en descripciones de procedimiento. Cambios en el formato Modificacin del flujo principal. Revisin de Matas 03/05/2006 1.4 Wepfer y Matas Gorostegui, para customizar a los proyectos de CBK. 05/05/2006 1.5 Redefinicin y escritura de todo el documento. Ajustes en la descripcin de las actividades y en el 17/05/2006 1.6 formato del documento. 18/05/2006 1.7 Ajuste final en la definicin de las actividades Incorporacin de actividades segn modelo CMMI nivel 19/05/2006 1.8 2 v1.1 17/07/2006 1.9 Correcciones de acuerdo a revisin. Cambios menores en referencia a un documento de 20/02/2007 2.0 Control de Cambios. Ajustes en actividades de acuerdo al Workflow de 07/05/2007 2.1 Actividades. Se mejor el workflow de procedimiento para una mejor 11/05/2007 2.2 comprensin. Historia de Revisiones, Aprobaciones, y Publicaciones Fecha Versin Descripcin Se public, con un curso de presentacin y se habilit la 22/05/2006 1.8 casilla SPI@cubika.com para las observaciones. 10/07/2006 1.9 Se revis completamente el documento.

Tabla de Contenidos Ingenieria de Requerimientos o Historia de cambios Tabla de Contenidos o Informacin sobre este documento Responsables Informacin de referencia y sugerencias Audiencia sugerida Referencias Objetivo Alcance Controles Roles definidos y responsabilidades o Diagramma de Actividades del Proceso

Actividades para levantar Requerimientos Objetivo Frecuencia Entradas Salidas Paso a Paso Actividades para refinar la definicin del sistema Definir la Visin y el SRS Objetivo: Frecuencia: Entradas: Salidas: Paso a Paso Definir el Modelo de Casos de Uso Objetivo Frecuencia Entradas Salidas Paso a Paso Actividades para revisar requerimientos Objetivo Frecuencia Responsable Entradas: Salidas: Paso a Paso Actividades para generar una Lnea Base Objetivo Frecuencia Responsable Entradas: Salidas: Actividades para Desarrollar Requerimientos Objetivo Frecuencia Entradas: Salidas: Paso a Paso Actividades para Revisar Especificaciones de Requerimientos Objetivo Frecuencia Entradas: Salidas: Actividades para refinar los requerimientos suplementarios Objetivo Frecuencia Entradas Salidas: Paso a Paso Actividades para Administrar los Requerimientos de Cambio Objetivos Frecuencia Entradas Salidas

Paso a Paso Actividades para especificar Gap de requerimientos Objetivos Frecuencia Entradas: Salidas Paso a Paso

Informacin sobre este documento Responsables Sponsor del Proyecto de Mejora: Juan Cabrera Responsables del Proceso: PMO Miembros del sector Software Process Improvement (SPI)

Informacin de referencia y sugerencias http://confluence.cub2k.com/display/CDP/Cubika+Development+Process spi@cubika.com Audiencia sugerida Analistas Funcionales

Referencias IBM-RUP 2005 SEI-CMMi DEV v1.2 CM.Nomenclatura de Artefactos.doc EN.Glosario Organizacional Proceso Cubika.doc Objetivo Especificar el procedimiento de Administracin de Requerimientos, artefactos, entregables internos y pblicos, criterios y lineamientos aplicables a los procesos de anlisis en proyectos de desarrollo de software manejados por Cubika. Alcance Este procedimiento se aplica en todos los proyectos de desarrollo de software "manejados" de Cubika.

Controles Controles sern llevados a cabo por lo procedimientos definidos dentro de la disciplina PPQA. Roles definidos y responsabilidades Analista (Funcional) El analista funcional es el rol que releva y especifica los requerimientos, modelando y especificando los casos de uso, delineando la funcionalidad del sistema y delimitando su alcance. Es el responsable de:

1. Obtener y analizar en detalle los requerimientos de los stakeholders. 2. Elaborar y administrar el Plan de Administracin de Requerimientos junto con el PM del proyecto. 3. Definir en detalle el alcance del sistema. 4. Analizar el impacto de los requerimientos de cambio, realizados sobre la funcionalidad ya definida. 5. Armar y mantener actualizado el glosario de trminos comunes en el sistema. 6. Identificar actores y casos de uso de negocio y de implementacin. 7. Especificar casos de uso, modelo de caso de uso, especificaciones suplementarias, y dems artefactos que se utilicen para comenzar con el desarrollo del producto. 8. Desarrollar y mantener actualizado el Documento de Visin. 9. Administrar y mantener las dependencias entre casos de uso y actores, as como tambin la trazabilidad funcional. Lder de Proyecto: El lder de proyecto es el rol que gestiona el proyecto y es el responsable final por el xito del mismo. En relacin a requerimientos, debe validar y gestionar el alcance del producto durante el ciclo de vida del proyecto. Es el responsable de: 1. Validar la lnea base de requerimientos, el Documento de Visin y el SRS 2. Armar la planificacin en funcin de los requerimientos definidos 3. Gestionar el alcance a lo largo del ciclo de vida 4. Participar como miembro del CCB en la resolucin de los pedidos de cambio QA-Quality Assurance: El QA es el rol que verifica la calidad en los artefactos de requerimientos. Es el responsable de: 1. Verificar consistencia y coherencia de artefactos de requerimientos. 2. Asegurar la calidad del proceso de requerimientos. 3. Verificar que los cambios hayan sido correctamente impactados en los requerimientos. Arquitecto de software: El arquitecto tiene la responsabilidad de conducir las principales decisiones tcnicas, denominadas "arquitectura del software". Esto incluye identificar y documentar los aspectos ms significativos de la arquitectura, incluyendo requerimientos no funcionales, diseo, implementacin y deployments del sistema. Es el responsable de: 1. Anlisis de la arquitectura. 2. Asegurar la viabilidad de la arquitectura requerida. 3. Identifica mecanismos de diseo. 4. Estructura el modelo de implementacin. 5. Describe la arquitectura en tiempo de ejecucin. 6. Describe la distribucin del sistema en las distintas etapas.

Diagrama de Actividades del Proceso

Actividades para levantar Requerimientos Objetivo El objetivo principal de este workflow es mejorar los conocimientos acerca del problema a ser resuelto, identificar a los stakeholders, definir el entorno, las funcionalidades clave y las restricciones de la solucin propuesta.

Frecuencia Las tareas de este workflow se debern realizar en reiteradas oportunidades durante la fase de Incepcin. Luego, a lo largo del ciclo de vida del proyecto ser necesario repetirlo para poder atender a los inevitables requerimientos de cambios que se presenten. Esta tarea se realiza normalmente al principio de cada iteracin.

Entradas Salidas Documento de Visin Inicial Modelo de Casos de Uso de Negocio Modelo de Entidades de Dominio Realizaciones de Casos de Uso de Negocio RFP Project Charter Propuesta Econmica

Paso a Paso Descripcin Analizar la informacin relevada del negocio (Modelo de Casos de Uso de Negocio, RFP) para comprender la Conocer en totalidad el totalidad del problema a ser resuelto. problema a ser resuelto En este punto no deben quedar dudas sobre el entendimiento del problema entre todos los stakeholders. Identificar las restricciones que se hayan detectado Identificar las durante el relevamiento impuestas al nuevo sistema. restricciones impuestas Las restricciones deben ser detalladas en el documento sobre el sistema de Visin inicial. Definir las caractersticas Tomar como input si existieran las caractersticas del sistema ofrecidas en la Propuesta Econmica o en el RFP (Request For Proposal) entregado por el cliente. En caso de no existir esta informacin en el RFP se deben relevar y especificar las caractersticas que debe tener el sistema a construir para demarcar el alcance. En sesiones con el Cliente, mediante la aplicacin de diversas tcnicas, relevar cuales son los features de la solucin que se propone. Los features deben ser validados con los stakeholders del proyecto y volcados en el Documento Visin inicial. Las tcnicas que pueden usarse son: Brainstorming Actividad Responsable Analista Funcional

Analista Funcional Analista Funcional

Prototipos de GUI Storyboarding Roleplaying Entrevistas Cuestionarios Sesiones JAD

Actividades para refinar la definicin del sistema Definir la Visin y el SRS Objetivo: El objetivo principal de este workflow es detallar los features a nivel requerimientos, es decir, cuales son las capacidades requeridas del sistema para resolver las necesidades de negocio.

Frecuencia: Las tareas de este workflow se debern realizar en forma posterior al relevamiento durante la fase de Incepcin.

Entradas: Documento de Visin inicial Modelo de Casos de Uso de Negocio

Salidas: Documento de Visin SRS Matrices de Trazabilidad

Paso a Paso Descripcin Determinar y priorizar el origen de cada requerimiento. Determinar los criterios para su aceptacin, considerando Determinar origen de su: consistencia, claridad, testeabilidad, trazabilidad, requerimientos y criterios de aceptacin identificacin unvoca. Si fuera necesario obtener ms respuestas para clarificar los requerimientos, realizar reuniones con los stakeholders Refinar los para validar las respuestas ya dadas, y obtener nueva requerimientos informacin. No deben quedar dudas, sobre las necesidades planteadas. Generar el SRS Se especifican todos los requerimientos funcionales, no (Sofware Requirement funcionales, reglas de negocio y restricciones que Specifications) conforman el dominio del conjunto de necesidades a cubrir. Asignar atributos a los Los requerimientos se clasifican de acuerdo a ciertos requerimientos atributos: prioridad, esfuerzo, riesgo, criticidad. Actividad Responsable Analista Funcional

Analista Funcional Analista Funcional Analista Funcional

Prioridad: la prioridad para el negocio del requerimiento. Crtico, Importante, til. Esfuerzo: El esfuerzo en tiempo y recursos que demandar la construccin. Riesgo: El riesgo a mitigar en cuanto a la performance y disponibilidad del producto.

Criticidad: en cuanto al costo / beneficio que demandar la construccin e implementacin del escenario. Establecer la relacin entre: Establecer e identificar la trazabilidad Los requerimientos y los Casos de Uso de Negocio. Analista Funcional

Definir el Modelo de Casos de Uso Objetivo Colaborar en la definicin del alcance del sistema, en forma explcita y en detalle, focalizando el mismo en un conjunto de requerimientos manejables en cada iteracin. Definir el set de escenarios de comportamientos, para uno o ms casos de uso de negocio, que representen el centro de la funcionalidad ms significativa. Definir cmo ser mantenida la trazabilidad, considerando los atributos de los requerimientos.

Frecuencia El mayor porcentaje de esta actividad se realiza en la etapa inicial el proyecto, y se vuelve a repetir, en las sucesivas iteraciones.

Entradas Salidas Modelo de Casos de Uso Documento de Visin

Paso a Paso Actividad Identificar los actores Identificar casos de uso Descripcin Identificar dentro de las caractersticas de la Visin los actores involucrados en la operacin del negocio. Se deben clasificar segn el rol o puesto dentro de la organizacin. En lo posible detallar las responsabilidades que tienen asignadas. Los actores se deben documentar en el EA (Enterprise Architect). Durante el relevamiento se deben identificar los casos de uso que surgen del anlisis de las actividades actuales de los Responsable Analista Funcional Analista Funcional

actores identificados. No confundirse con los deseos de mejoras o caractersticas solicitadas al sistema. Deben ser los casos de uso o actividades que realizan actualmente los actores de la empresa. Los casos de uso se deben documentar en el EA. Describir como interactan los actores con los casos de uso Realizar un diagrama de actividades para describir como interactan los actores entre si para definir con sus responsabilidades. Los diagramas se deben documentar en el EA. Analista Funcional

Definir el Modelo de Casos de Uso

Realizar el Modelo de Casos de Uso agrupados por mdulos si fuera necesario. En estos diagramas se deben representar las Analista Analista relaciones entre las diferentes actividades que realizan los Funcional actores para cumplir sus responsabilidades. Los diagramas se deben documentar en el EA.

Actividades para revisar requerimientos Objetivo Validar con el cliente, el avance del anlisis realizado sobre sus requerimientos y necesidades, y obtener su conformidad sobre el mismo. Documentacin y acuerdo sobre cada lnea base, se acordar en reuniones rutinarias del equipo de proyecto (ver el SDP, seccin Plan de Comunicaciones - Reuniones de Avance Semanales). Alcanzar un claro entendimiento de los requerimientos con los proveedores de los mismos, de tal forma que todos los participantes se comprometan con el proyecto.

Frecuencia Esta actividad es realizada durante la Incepcin y tantas veces como ingresen requerimientos de cambio.

Responsable La responsabilidad de obtener la conformidad del cliente es del PM, pero puede ser compartida con el analista, quien es responsable del anlisis y del detalle del alcance.

Entradas: Documento de Visin SRS.

Salidas: Documento de Visin (Validado) SRS (Validado)

Paso a Paso Actividad Validar con Arquitectura Descripcin u Objetivo Rol El objetivo de esta actividad es validar bsicamente con el Analista arquitecto, la factibilidad de construccin de los requerimientos. Arquitectura Principalmente, esta actividad se desarrolla en la etapa de

Validar con Comercial

Incepcin. Si fuera necesario, se revalida al principio de cada iteracin. El objetivo de esta actividad es validar bsicamente con el rea Analista comercial, la consistencia de los requerimientos contra la Comercial propuesta original. QA Analista Ciente

Verificar El objetivo de esta actividad es verificar la consistencia y Requerimientos por coherencia de los documentos de Visin y el SRS. QA El objetivo de esta actividad es validar bsicamente con el Validar con el cliente, los requerimientos y los casos de uso. Esta validacin Cliente tiene que ver con la conformidad desde un punto de vista funcional de los artefactos de la disciplina de requerimientos. Actividades para generar una Lnea Base Objetivo

Definir y acordar el conjunto de artefactos, funcionalidad y alcance sobre el cul se comenzar a especificar en detalle durante la Elaboracin.

Frecuencia Esta actividad se desarrolla al final de la etapa de Incepcin. La lnea base tambin se actualizar, en caso de surgir algn requerimiento de cambio.

Responsable Remitirse a la disciplina CM, que es la que administra los requerimientos de cambio y define el procedimiento para establecer la lnea base.

Entradas: Documento de Visin SRS Modelo de Casos de Uso GUI

Salidas: Lnea Base de Requerimientos.

Actividades para Desarrollar Requerimientos Objetivo Definir los requerimientos del sistema de acuerdo a la Lnea Base de la Incepcin, bajndolos a nivel Caso de Uso.

Frecuencia Esta actividad se desarrolla al comienzo de la etapa de Elaboracin y luego se contina al comienzo de cada una de las iteraciones. La lnea base tambin se actualizar, en caso de surgir algn requerimiento de cambio.

Remitirse al CDP, disciplina de Software Configuration Management, documento de CM.Procedimiento de Gestion de Cambio de artefactos desde un CR.

Entradas: Documento de Visin Modelo de Casos de Uso SRS

Salidas: Especificaciones de Casos de Uso GUI Mapa de Navegacin

Paso a Paso Descripcin u Objetivo A partir del Modelo de Casos de Uso, se tomar cada Caso de Uso y se generar la GUI que dar solucin a la funcionalidad Generar GUI especificada en este. Para cada Caso de Uso se podr generar una o ms GUI que resuelvan la lgica. A partir de las GUI, el Analista construye el Mapa de Armar Mapa de Navegacin por cada Caso de Uso. Este mapa muestra como Navegacin el usuario navega la aplicacin en funcin de las acciones que va ejecutando. Por cada caso de uso se debe entender en detalle el flujo principal, los flujos alternativos y los flujos de excepcin y Generar las poder describirlos en prosa. especificaciones de los Se debe generar las especificaciones de los casos de uso casos de uso para mostrar con detalle el rol del actor ms representativo y/o el rol del cliente. Definir la forma en que se abrirn los casos de uso. Se podrn Refinar el Modelo de agrupar teniendo en cuenta la funcionalidad, la reusabilidad, la Casos de Uso modulacin de acuerdo a la posibilidad de crecimiento en relacin a su funcionalidad y la testeabilidad. Actividades para Revisar Especificaciones de Requerimientos Objetivo Verificacin por parte de QA de las especificaciones de requerimientos; obtener la conformidad sobre los mismos. Alcanzar un claro entendimiento de los requerimientos a ser implementados, de tal forma que todos los participantes se comprometan con el proyecto. Actividad Rol Analista Funcional

Analista Funcional

Analista Funcional

Analista Funcional

Frecuencia Esta actividad es realizada durante la Elaboracin y tantas veces como ingresen requerimientos de cambio.

Entradas:

Especificaciones de Casos de Uso GUI Mapa de Navegacin

Salidas: Reportes de Calidad Minutas de Acuerdo con el Cliente Actividad

Descripcin Responsable El objetivo de esta actividad es verificar consistencia y Revisar Especificaciones de coherencia de las especificaciones de Casos de Uso. QA Casos de Uso Se debe remitir al Plan de Testing del proyecto para ver el detalle de esta verificacin. El objetivo de esta actividad es verificar consistencia y coherencia de Prototipos de GUI y Mapa de Revisar Prototipos de GUI y Navegacin. QA Mapa de Navegacin Se debe remitir al Plan de Testing del proyecto para ver el detalle de esta verificacin. El objetivo de esta actividad es llevar a cabo la lnea base de casos de uso y artefactos realizados durante Generar Lnea Base de Analista la Elaboracin. Casos de Uso Funcional A partir de esta instancia, se pasa a un proceso de Administracin de Cambios. Actividades para refinar los requerimientos suplementarios Objetivo El objetivo principal de este workflow es refinar los requerimientos suplementarios de manera de poder validar la arquitectura candidata en funcin de estos.

Frecuencia Esta actividad es realizada durante la Elaboracin.

Entradas SRS

Salidas: SRS (con requerimientos refinados)

Paso a Paso Actividad Refinar requerimientos suplementarios Descripcin Responsable El objetivo de esta actividad es el de verificar la factibilidad de los requerimientos no suplementarios. El Arquitecto toma estos requerimientos del SRS, y analiza opciones de arquitectura para soportarlos. Arquitecto Como parte de esta tarea, el Arquitecto podr refinar los requerimientos no funcionales para tener un mayor detalle de las cualidades operativas de la aplicacin.

Probar arquitectura

Se verifica que la arquitectura propuesta cumpla los requerimientos no funcionales puestos en el SRS. Remitirse al CDP, disciplina de Analysis & Design, documento de Procedimiento de Anlisis y Diseo.

Arquitecto

Actividades para Administrar los Requerimientos de Cambio Objetivos Para asegurar el cumplimiento de los compromisos asumidos y garantizar la calidad esperada durante el proyecto, es preciso que el plan del proyecto, el alcance y otros entregables sean mantenidos en forma continua, de manera de identificar cambios y administrarlos. Estos cambios pueden generar ajustes en los planes, en el alcance y en otros entregables. Cada cambio debe ser aceptado o no, por el PM del proyecto e informado a la Gerencia.

Frecuencia Esta actividad se desarrolla a lo largo de todas las etapas del proyecto.

Entradas Salidas Lnea Base de Requerimientos (Modificada) Remitirse al CDP, disciplina de Software Configuration Management, documento de CM.Procedimiento de Gestion de Cambio de artefactos desde un CR. Lnea Base de Requerimientos Pedido de Cambio.

Paso a Paso Descripcin Los cambios requeridos deben estar acordes al Plan de Administrar los Administracin de Cambios. El analista deber analizar el requerimientos de impacto que generan los mismos sobre la trazabilidad cambio definida. Si fuera necesario, refinar con ms detalle el Documento de Actualizar el Visin, considerando, si hubiese, los requerimientos de Documento de Visin cambio. Actividades para especificar Gap de requerimientos Objetivos Consiste en afectar todos los artefactos de requerimientos asociados a un pedido de cambio en particular. Actividad Responsable Analista Funcional Analista Funcional

Frecuencia Esta actividad se desarrolla ante cada pedido de cambio que es aceptado por el CCB, y que es planificado por el Lder de Proyecto para ser implementado.

Entradas: Salidas Lnea Base de Requerimientos (nueva) Lnea Base de Casos de Uso (nueva) Lnea Base de Requerimientos Lnea Base de Casos de Uso.

Paso a Paso Descripcin En funcin del cambio solicitado, se deben impactar todos Actualizar Artefactos aquellos artefactos que forman la cadena de desarrollo: de Requerimientos Requerimiento en el SRS, Especificacin de Caso de Uso, Modelo de Casos de Uso, Prototipo GUI. Actividad Responsable Analista Funcional