ADMINISTRACIÓN DE REQUERIMIENTOS CMMI ADMINISTRACIÓN DE REQUERIMIENTOS

CMMI NIVEL 2. ÁREAS CLAVE DEL PROCESO Centrado en el proyecto. Establece sus controles de gerencia. Las prácticas claves: “qué” hacer, no “cómo” los objetivos van a ser alcanzados. Prácticas alternas pueden lograr los objetivos del área clave del proceso. Las áreas claves del proceso en el nivel 2 se centran en lo que concierne al proyecto, y establece sus controles de gerencia. Las prácticas claves describen el “qué” se debe hacer, pero no puede ser interpretado como la forma en que los objetivos van a ser alcanzados. Prácticas alternativas pueden lograr los objetivos del área clave del proceso. Las prácticas claves deben ser interpretadas racionalmente para juzgar si los objetivos del área del proceso clave son efectivamente alcanzados, aunque quizás de manera diferente. Las prácticas claves son para juzgar si los objetivos del área del proceso clave son efectivamente alcanzados, aunque quizás de manera diferente.

ADMINITRACIÓN DE REQUERIMIENTOS Propósito: establecer entendimiento común entre cliente y proyecto. El acuerdo, planificación base y gerencia del proyecto. El propósito de la gerencia de requerimientos es establecer un entendimiento común entre el cliente y el proyecto producto de los requerimientos levantados. Este acuerdo con el cliente es la base para hacer la planificación (como se describe en la planificación del proyecto) y la gerencia o manejo (como se describe en el seguimiento del proyecto) del proyecto. El control sobre la relación con el cliente depende del hecho de seguir un proceso efectivo de control de cambios (como se describe en el manejo de la configuración del software) Relación con el cliente depende de proceso efectivo de control de cambios

EL ACUERDO Este acuerdo es llamado “requerimientos del sistema asignados al software”. El “cliente”: grupo de ingeniería de sistemas, el grupo de mercadeo, otra organización interna, o comprador externo. Cubre requerimientos técnicos como no técnicos. El propósito del área de Manejo de Requerimientos es establecer el entendimiento común entre el cliente y el proyecto de software sobre los requerimientos del cliente que vayan a ser adjudicados al proyecto en si. El Manejo de Requerimientos involucra establecer y mantener un acuerdo con el cliente sobre los requerimientos del proyecto de software. Este acuerdo es llamado “requerimientos del sistema asignados al software”. El “cliente” puede ser interpretado como el grupo de ingeniera de sistemas, el grupo de mercadeo, otra organización interna, o un comprador externo. El acuerdo cubre tanto los requerimientos técnicos como los no técnicos (ej. fechas de entrega). El acuerdo forma la base para estimar, planear, ejecutar y rastrear las actividades del proyecto de software a través de todo el ciclo de vida del mismo. El acuerdo forma la base para estimar, planear, ejecutar y rastrear las actividades del proyecto de software a través de todo el ciclo de vida del mismo.

ASIGNACIÓN Y CONTROL DE REQUERIMIENTOS Puede ser hecha por un grupo externo al grupo de ingeniería del software Dicho grupo asegura que todos los requerimientos asignados al SW estén controlados y documentados. El grupo de Ing. Software revisa requerimientos iniciales y ya revisados, antes de ser incorporados al proyecto de software. La asignación de los requerimientos del sistema al software, hardware, y otros componentes del sistema (ej. humanos) puede ser hecha por un grupo externo al grupo de ingeniería del software (ej. el grupo de ingeniería de sistemas), y el grupo de ingeniería del software pudiera no tener control directo sobre esta asignación. Dentro de las constantes del proyecto, el grupo de ingeniería de software realiza los pasos apropiados para asegurar que todos los requerimientos asignados al software, de los cuales ellos son responsables, estén controlados y documentados. Para asegurar este control, el grupo de ingeniería de software revisa tanto los requerimientos iniciales como los requerimientos revisados asignados al software para resolver problemas antes de ser incorporados como tal al proyecto de software. En cualquier momento que los requerimientos del sistema asignados al software son cambiados, los planes de software afectados, productos de trabajo, y actividades son ajustados para permanecer consistentes con los requerimientos actualizados.   Si hay cambios, los planes de SW afectados, productos de trabajo, y actividades son ajustados para permanecer consistentes.

METAS Meta 1: Los requerimientos del sistema asignados al SW son controlados para establecer una línea base para ingeniería del software y gerencia de uso. Metas   Meta 1: Los requerimientos del sistema asignados al software son controlados para establecer una línea base para ingeniería del software y gerencia de uso. Meta 2: los planes de software, productos y actividades se mantienen consistentes con los requerimientos del sistema asignados al software. Meta 2: los planes de SW, productos y actividades se mantienen consistentes con los requerimientos del sistema asignados al software.

COMPROMISO A LA REALIZACIÓN Compromiso 1: El proyecto sigue una política organizacional para manejar requerimientos del sistema asignados al SW Los requerimientos asignados: Compromiso 1: El proyecto sigue una política organizacional (previamente escrita) para manejar requerimientos del sistema asignados al software. Los requerimientos del sistema asignados al software son llamados “requerimientos asignados” en este tipo de prácticas. Los requerimientos asignados son el subconjunto de los requerimientos del sistema que van a ser implementados en los componentes de software del sistema. Los requerimientos asignados son una entrada primaria al plan de desarrollo de software Los análisis de requerimientos de software elaboran y refinan los requerimientos asignados que están documentados. Son el subconjunto de los requerimientos del sistema que van a ser implementados en los componentes de SW del sistema. Son una entrada primaria al plan de desarrollo de SW

COMPROMISO A LA REALIZACIÓN El compromiso 1 especifica que: Los requerimientos asignados están documentados. Los requerimientos asignados son revisados por los gerentes de software y grupos afectados. Esta política típicamente especifica que: 1. Los requerimientos asignados están documentados. 2. Los requerimientos asignados son revisados por: - Los gerentes de software. - Otros grupos afectados: Entre los ejemplos de grupos afectados se incluyen: -          Pruebas del sistema. -          Ingeniería del software (incluyendo todos los subgrupos, como diseño de software) -          Ingeniería de sistemas. -          Aseguramiento de la calidad del software -          Manejo de configuraciones de software -          Soporte de documentación. 3. Los planes de software, productos de trabajo, y actividades son cambiadas para ser consistentes con los cambios a los requerimientos asignados. Los planes de SW, productos de trabajo, y actividades son cambiadas para ser consistentes con los cambios a los requerimientos asignados.

HABILIDAD PARA LA REALIZACIÓN Habilidad 1: Para cada proyecto, se establece una responsabilidad para analizar los requerimientos del sistema, y asignarlos al hardware, software, y otros componentes del sistema. Esta responsabilidad cubre: Manejo y documentación de requerimientos del sistema y su asignación a lo largo de la vida del proyecto. Hacer efectivos los cambios a los requerimientos del sistema y su asignación. Habilidad 1: Para cada proyecto, es establecida una responsabilidad para analizar los requerimientos del sistema, y asignarlos al hardware, software, y otros componentes del sistema. El análisis y asignación de los requerimientos del sistema no es responsabilidad del grupo de ingeniería del software, pero es un prerrequisito para su trabajo.   Esta responsabilidad cubre: 1. Manejo y documentación de los requerimientos del sistema y su asignación a lo largo de la vida del proyecto. 2. Hacer efectivos los cambios a los requerimientos del sistema y su asignación.

HABILIDAD PARA LA REALIZACIÓN Habilidad 2: Los requerimientos asignados están documentados Los requerimientos asignados incluyen: Los requerimientos “no técnicos” que afecten y determinen las actividades del proyecto de SW. Los requerimientos técnicos para el software. El criterio de aceptación usado para validar que los productos de software satisfacen a los requerimientos asignados. (Habilidad 2) Los requerimientos asignados están documentados. Los requerimientos asignados incluyen: 1. Los requerimientos “no técnicos” (es decir, los acuerdos, condiciones, y/o términos contractuales) que afecten y determinen las actividades del proyecto de software Ejemplos de acuerdos, condiciones, y términos contractuales incluyen: - Productos a ser entregados - Fechas de entrega - Reuniones de chequeo. 2. Los requerimientos técnicos para el software. Ejemplos de requerimientos técnicos incluyen: - Funciones de usuario final, soporte, o de integración - Requerimientos de desempeño - Restricciones de diseño - Lenguaje de programación - Requerimientos de interfaz.  3. El criterio de aceptación que será usado para validar que los productos de software satisfacen a los requerimientos asignados.

HABILIDAD PARA LA REALIZACIÓN Habilidad 3: Recursos e inversiones adecuadas provienen de administración de requerimientos asignados. Esto incluye: Asignar expertos con experiencia en el dominio de la aplicación y en ingeniería de SW para gerenciar los requerimientos. Deben estar disponibles herramientas para soporte de actividades del manejo de requerimientos. (Habilidad 2) Los requerimientos asignados están documentados. Los requerimientos asignados incluyen: 1. Los requerimientos “no técnicos” (es decir, los acuerdos, condiciones, y/o términos contractuales) que afecten y determinen las actividades del proyecto de software Ejemplos de acuerdos, condiciones, y términos contractuales incluyen: - Productos a ser entregados - Fechas de entrega - Reuniones de chequeo. 2. Los requerimientos técnicos para el software. Ejemplos de requerimientos técnicos incluyen: - Funciones de usuario final, soporte, o de integración - Requerimientos de desempeño - Restricciones de diseño - Lenguaje de programación - Requerimientos de interfaz.  3. El criterio de aceptación que será usado para validar que los productos de software satisfacen a los requerimientos asignados.

HABILIDAD PARA LA REALIZACIÓN Habilidad 4: Miembros del equipo de ingeniería de SW y de algún grupo relacionado son entrenados para realizar las actividades de gerencia de requerimientos. Esto incluye: Asignar expertos con experiencia en el dominio de la aplicación y en ingeniería de SW para gerenciar los requerimientos. Deben estar disponibles herramientas para soporte de actividades del manejo de requerimientos. (Habilidad 2) Los requerimientos asignados están documentados. Los requerimientos asignados incluyen: 1. Los requerimientos “no técnicos” (es decir, los acuerdos, condiciones, y/o términos contractuales) que afecten y determinen las actividades del proyecto de software Ejemplos de acuerdos, condiciones, y términos contractuales incluyen: - Productos a ser entregados - Fechas de entrega - Reuniones de chequeo. 2. Los requerimientos técnicos para el software. Ejemplos de requerimientos técnicos incluyen: - Funciones de usuario final, soporte, o de integración - Requerimientos de desempeño - Restricciones de diseño - Lenguaje de programación - Requerimientos de interfaz.  3. El criterio de aceptación que será usado para validar que los productos de software satisfacen a los requerimientos asignados.

REALIZACIÓN DE ACTIVIDADES Actividad 1: El equipo de ingeniería de SW revisa los requerimientos antes de incorporarlos al proyecto. Esto incluye: Se identifican los incompletos o faltantes Son revisados para determinar si son o están: - Factible y apropiados para implementarlos. - Establecidos clara y apropiadamente. - Consistentes entre ellos. - Pueden ser sometidos a pruebas. Realización de Actividades Actividad 1: El equipo de ingeniería de software revisa los requerimientos antes de incorporarlos al proyecto de software 1. Se identifican los requerimientos incompletos o faltantes 2. Los requerimientos son revisados para determinar si son o están: - factible y apropiados para implementarlos en software - establecidos clara y apropiadamente - consistentes entre ellos - pueden ser sometidos a pruebas

REALIZACIÓN DE ACTIVIDADES Actividad 2 incluye: Cualquier requerimiento identificado como potencialmente problemático, es revisado por grupo de responsables para analizar y asignar requerimientos del sistema, y hacer los cambios necesarios. 3. Cualquier requerimiento que haya sido identificado como potencialmente problemático, es revisado con un grupo de responsables para analizar y asignar requerimientos del sistema, y hacer los cambios necesarios 4. Compromisos resultantes de los requerimientos, son negociados con los grupos afectados. Por ejemplo: - Ingenieria de software (incluyendo todos los subgrupos tales como los de diseño del sw) - estimaciones de sw - pruebas de sistema - Certificación de calidad del sw - Manejo de configuracion de sw - Manejo de contrato - Soporte de documentación. Compromisos resultantes de los requerimientos, son negociados con los grupos afectados.

REALIZACIÓN DE ACTIVIDADES Actividad 3: Los cambios a los requerimientos levantados son revisados e incorporados dentro del proyecto Se determina el impacto a los compromisos existentes Los cambios que se necesitan hacer a los planes del software, productos de trabajo, y a las actividades resultantes de los cambios a los requerimientos son trabajados y analizados 3. Cualquier requerimiento que haya sido identificado como potencialmente problemático, es revisado con un grupo de responsables para analizar y asignar requerimientos del sistema, y hacer los cambios necesarios 4. Compromisos resultantes de los requerimientos, son negociados con los grupos afectados. Por ejemplo: - Ingenieria de software (incluyendo todos los subgrupos tales como los de diseño del sw) - estimaciones de sw - pruebas de sistema - Certificación de calidad del sw - Manejo de configuracion de sw - Manejo de contrato - Soporte de documentación.

MEDIDAS Y ANÁLISIS Estado de cada uno de los requerimientos Actividad de cambio para cada requerimiento Número acumulativo de los cambios a los requerimientos, incluyendo el número total de cambios propuestos, abiertos, aprobados e incorporados al sistema 3. Cualquier requerimiento que haya sido identificado como potencialmente problemático, es revisado con un grupo de responsables para analizar y asignar requerimientos del sistema, y hacer los cambios necesarios 4. Compromisos resultantes de los requerimientos, son negociados con los grupos afectados. Por ejemplo: - Ingenieria de software (incluyendo todos los subgrupos tales como los de diseño del sw) - estimaciones de sw - pruebas de sistema - Certificación de calidad del sw - Manejo de configuracion de sw - Manejo de contrato - Soporte de documentación.

VERIFICANDO LA IMPLEMENTACIÓN Las actividades para el manejo de los requerimientos son revisados con la alta gerencia en una base periódica Las actividades para el manejo de los requerimientos son revisados con el gerente de proyecto 3. Cualquier requerimiento que haya sido identificado como potencialmente problemático, es revisado con un grupo de responsables para analizar y asignar requerimientos del sistema, y hacer los cambios necesarios 4. Compromisos resultantes de los requerimientos, son negociados con los grupos afectados. Por ejemplo: - Ingenieria de software (incluyendo todos los subgrupos tales como los de diseño del sw) - estimaciones de sw - pruebas de sistema - Certificación de calidad del sw - Manejo de configuracion de sw - Manejo de contrato - Soporte de documentación. El grupo encargado de asegurar la calidad del software revisa y/o audita las actividades y los productos de trabajo para la gerencia de los requerimientos y reportan los resultados

ADMINISTRACIÓN DE REQUERIMIENTOS CMMI ADMINISTRACIÓN DE REQUERIMIENTOS Hector Simáncas Astrid Salazar Joe Liscano