User stories, un punto de partida para los requisitos

Las historias de usuarios (User Stories) constituyen una de las técnicas de documentación de requisitos más ampliamente utilizada dentro del entorno Agile. Una descripción del requisito en una o dos frases escritas por el usuario.

En el contexto de las prácticas de CMMI se aplican, esencialmente,  para identificar las necesidades del cliente en la Definición de los requisitos (RD), ayudan fácilmente a la gestión de cambios en la Gestión de los requisitos (REQM) y ayudan a la estimación y planificación de tareas y compromisos para la Planificación del proyecto (PP).

Inconsistencia con los requisitos, una práctica poco valorada o entendida

Zeedonk by sannse

La gestión de requisitos considera diferentes tareas desde el acuerdo sobre lo que se va a hacer, el control de las modificaciones a lo que se acordó y la revisión de que se está haciendo lo correcto. Cuando las dos primeras se realizan correctamente se podría pensar que la última está de más, pero sería como pensar que porque el proyecto va bien no existen riesgos.

El modelo CMMI establece en el área de proceso de REQM las prácticas necesarias para la gestión de los requisitos. Su propósito es gestionar los requisitos de productos y componentes y asegurar que se mantienen alineados con los planes y productos de trabajo. La segunda parte de ese propósito es el foco principal de este artículo.

Categorias de requisitos no funcionales

Mientras que los requisitos funcionales describen lo que debe hacer un producto, los requisitos no funcionales son propiedades o cualidades que el producto debe tener. Estos últimos pueden marcar la diferencia entre un producto bien aceptado y uno con poca aceptación.

El modelo CMMI no considera expresamente una diferencia entre requisitos funcionales y no funcionales. Éstos se identifican básicamente en las prácticas de RD mezclados o derivados entre los requisitos del cliente, productos y componentes y asociados con los atributos de calidad del producto. En el proceso de definición de los requisitos se tienen prácticas que ayudan a identificar no solamente lo que se espera del producto sino también las expectativas de comportamiento o cualidades que se esperan.

Cuadernos de Calidad y CMMI: Gestión y definición de requisitos

“El cliente no sabe lo que quiere, hasta que se lo muestras”. – Steve Jobs

Nueva edición de los Cuadernos de Calidad y CMMI con información que puede ayudarle en diversos tópicos relacionados con la calidad y el modelo CMMI. En este número se presentan temas relacionados con la gestión y definición de requisitos.

Requisito es la condición o circunstancia necesaria para algo. Requerimiento es la acción y efecto de requerir. Muchas veces se utilizan de manera indistinta, pero hay diferencias en el uso de uno u otro. En este cuaderno se presentan artículos relacionados con el requisito, como condición a cumplir por un producto o servicio y la forma en que se puede garantizar que se cumpla.

Puede obtener el cuaderno directamente al comprar en Amazon.

Aproveche la oferta por tres días y descargue el cuaderno de manera gratuita 
(Válido del 30 de agosto al 1 de septiembre)

Trazabilidad de requisitos

La trazabilidad de requisitos es una herramienta fundamental para la gestión de requisitos. Es elemental para el control y como apoyo para la toma de decisiones en el proyecto. Como no es un entregable o componente del producto, se debe cuidar que su creación y uso sea lo más eficiente posible.

Se define trazabilidad, o en algunos textos rastreabilidad, como la asociación del requisito con otros requisitos y las diferentes instancias con que se relaciona durante la evolución de las diferentes fases del ciclo de desarrollo del producto o servicio. Esa asociación se controla en ambos sentidos, de los requisitos a los resultados y viceversa. La intención principal es poder determinar si todos los requisitos base han sido considerados y si las instancias que han sido generadas pueden asociarse con un requisito válido.

Atributos y medidas de calidad del software

Una atributo es una propiedad del producto, que cuando es asociada con la calidad se relaciona con los elementos que considera el cliente para aceptar o rechazar el producto. Estos atributos de calidad deben ser medidos para poder ser comparados. 

Es importante entenderlos desde la concepción de la idea a partir de las necesidades del cliente o mercado, considerarlos como parte de la solución y creación del producto para finalmente demostrar que han sido adecuadamente integrados en el producto final. Aquí se presentan diferentes atributos y medidas considerados en los entornos de desarrollo, instalación y operación que pueden ser útiles identificar en cada caso.

Aprobación y compromiso

"Cuando te reclamen para un favor o un compromiso, infórmate, previamente, de qué se trata, no vaya a ser que no estés dispuesto a hacerlo, ya sea por incapacidad o falta de voluntad."

Aprobar es la acción de calificar, aceptar, dar por bueno o suficiente algo o a alguien. Un compromiso se refiere a una obligación contraída o convenio. La existencia de una aprobación no garantiza el compromiso. Una aprobación se puede hacer de forma unilateral, mientras que el compromiso se da, al menos, entre dos personas el que otorga y el que acepta. 


Diferentes prácticas en el modelo CMMI se refieren a la obtención y revisión de los compromisos, en particular en las áreas de proceso de REQM, PP, PMC e IPM en relación con los requisitos y planes. En ocasiones se confunde la existencia de una aprobación en lugar del compromiso, pero es vital el establecimiento del compromiso para alcanzar los objetivos.

JIRA y RMsis dos herramientas en una solución integral

Ronhjones

El uso de herramientas en apoyo a los procesos es fundamental para optimizar los resultados. A partir de la definición del proceso se deben seleccionar y evaluar las herramientas que ayudan a mejorar los resultados que se esperan obtener. Posteriormente, ajustarla adecuadamente y capacitar en el uso efectivo de la herramienta para dar respuesta a las necesidades del proceso y como resultado obtener los beneficios que se esperan para el negocio. Mientras mayor flexibilidad tenga la herramienta, mucha mayor posibilidad de ajustarse a las necesidades que se tienen. 

Guías generales para documentar requisitos

La adecuada definición de requisitos es fundamental para un buen resultado en los productos que se desarrollan o los servicios que se ofrecen. El 60% de los defectos presentes en un producto están asociados con una mala definición de los requisitos. Por ello es importante trabajar para obtener una adecuada definición que soporte la creación de un producto o servicio correcto y bien.

Resumen de Desarrollo del sistema de servicio en CMMI SVC v1.3

Sdepares

El área de proceso de Service System Development (SSD) es adicional para el modelo CMMI SVC y corresponde al nivel 3 de madurez en la representación por etapas y está ubicada en la categoría de procesos de Establecimiento y prestación del servicio para la representación continua.  Su propósito es analizar, diseñar, desarrollar, integrar, verificar y validar el sistema de servicio, incluyendo los componentes del sistema de servicio, para satisfacer los acuerdos de servicios existentes o previstos.


Esta área de proceso se considera adicional porque se ofrece como una alternativa para el desarrollo del sistema de servicio integrando diferentes prácticas en una única área de proceso.  De forma alternativa se pueden utilizar las áreas de proceso de ingeniería del modelo CMMI DEV para los que están familiarizados con este enfoque. 


Considera tanto el desarrollo de sistemas de servicio nuevos o de los cambios a los sistemas existentes. Como sistema de servicio considera la combinación de los componentes del sistema; procesos, productos, personas, consumibles, clientes u otros recursos que permiten ofrecer un valor en respuesta a las necesidades de los interesados. 


En términos generales las metas específicas consideran la recolección, coordinación, análisis, validación y asignación de los requisitos de los interesados para el sistema de servicios. La evaluación y selección de alternativas de solución, el diseño, construcción, integración y documentación del sistema de servicio que cumple esos requisitos. Finalmente el sistema de servicio es verificado y validado para confirmar que satisface los requisitos y que cubrirá las expectativas de uso del cliente y usuarios durante la prestación del servicio.

Resumen de Prestación del servicio en CMMI SVC v1.3

El área de proceso de Service Delivery (SD) corresponde al nivel 2 de madurez en la representación por etapas y ubicada en la categoría de procesos de Establecimiento y prestación del servicio para la representación continua en el modelo CMMI SVC. Tiene como propósito la prestación de los servicios según los acuerdos de servicios. 


La prestación de servicios implica el establecimiento de acuerdos para ofrecimiento del servicio, estar al pendiente de las solicitudes de servicio y operar el sistema de servicios. Las prácticas establecidas ayudan a lograr la preparación para la operación de los servicios en tiempo y con los niveles de calidad requeridos, considerar los recursos necesarios para ofrecer servicios de manera consistente, confiable y compatible sobre la base de los acuerdos de niveles de servicio definidos con el cliente, realizar los mantenimientos preventivos para garantizar la continuidad del servicio y la disponibilidad en el momento que el cliente lo solicite, ya sea de forma continua o eventual. 


La prestación del servicio requiere del establecimiento de acuerdos de servicio con el cliente, considerar la forma en que el cliente solicita la prestación del servicio, los requisitos del servicio que se va a desarrollar y ofrecer, la integración del sistema de servicio y el ofrecimiento del servicio. Todos esos elementos se integran en las tres metas específicas del área de proceso.

Inconsistencias con requisitos

Richard Croft

Uno de los cambios que se realizaron con la nueva versión de CMMI tiene que ver con la SP1.5 de REQM. En esta práctica se identifican inconsistencias entre los requisitos establecidos y los planes y productos de trabajo que reflejan esos requisitos.


El cambio básicamente modifica la frase "identificar las inconsistencias" por "asegurar que los planes y productos de trabajo permanecen alineados con los requisitos". Con esta variación se le da más sentido a la práctica, que es una de las más cuestionadas particularmente cuando no se presentan problemas.

Cambios a requisitos y control de cambios

El modelo CMMI establece prácticas para control de cambios en dos áreas de proceso: REQM y CM. En la primera la SP 1.3 gestiona los cambios a requisitos durante el proyecto, mientras que en la segunda la SG2 contiene prácticas para registrar y controlar los cambios a los componentes bajo gestión de la configuración.


Estas prácticas son complementarias y para efectos del modelo se separan para analizarlas con propósitos diferentes. La organización puede determinar un mecanismo de control que le permita cumplir con ambas perspectivas.

Asignación de requisitos a componentes

La SP 2.2 en RD establece la necesidad de asociar los componentes del producto con los requisitos que los definen. De manera que los componentes que se van derivando tienen un requisito asociado que los define. 


Por su parte en REQM, en la SP 1.4 se establece la trazabilidad bidireccional de los requisitos hacia las entidades que se obtienen. Lo cual constituye una herramienta fundamental en la evaluación de impacto de los cambios a requisitos. 


¿Cuál es el sentido de cada práctica, si aparentemente ambas llevan una relación de requisitos a componentes?

Características deseables de un requisito

Dentro de las prácticas de REQM en la SP1.1 se tiene que establecer cuáles son los requisitos que serán acordados. Para lograr esto además de que se tenga una fuente autorizada para definir los requisitos, éstos deben ser adecuadamente definidos. Cuando se implementa en conjunto con RD, en la SP 3.3, se puede revisar el cumplimiento de esas características como elemento para comprobar que los requisitos son necesarios y suficientes. 


Para facilitar la actividad se puede elaborar una lista de verificación con las características que se deben cumplir y considerarlas en la realización de la revisión de los requisitos. Los requisitos que no cumplan con estas condiciones deben ser redefinidos y ajustados antes de ser comprometidos para evitar problemas en el desarrollo del producto.

10 Claves para una adecuada definición y gestión de requisitos

El establecimiento de los requisitos para un producto es vital para obtener un excelente resultado. Es la base para arrancar el trabajo de desarrollo y la fuente de muchos de los problemas que se presentan, por lo que una adecuada definición y gestión de los mismos es la clave para evitar contratiempos, retrabajos e incrementos de costos.

 Existen elementos imprescindibles, que se deben tomar en cuenta, para una correcta definición y gestión de requisitos y que son presentados aquí como diez elementos claves. Estos deben ser considerados como parte del sistema de procesos, prácticas, herramientas y disciplinas a integrar para identificar, analizar, especificar, verificar y gestionar los requisitos de un producto

Gestión de requisitos antes que definición de requisitos

El modelo CMMI DEV en su representación por etapas establece REQM a nivel 2 de madurez antes que RD que aparece a nivel 3. Para el orden de implementación de las áreas de proceso, le da mayor prioridad a la gestión de requisitos que a la definición de requisitos. Esto es una duda, sino en todos, en la gran mayoría de los cursos de Introduction to CMMI.
En principio el modelo va de un proceso caótico y reactivo a un proceso de mejora continua definido, controlado y proactivo. En ese orden iniciamos poniendo orden a lo que se está haciendo para luego hacerlo mejor hasta intentar alcanzar la perfección o excelencia en lo que se hace.

Modelado de procesos con BPMN

BPMN (Business Process Modeling Notation) permite definir procesos con una notación sencilla y entendible por el usuario. Los objetos gráficos, que considera la notación, permiten establecer el flujo del proceso y complementarlo con la descripción de las actividades y características de los diferentes elementos.

En CMMI un subproceso muy recurrente tiene que ver con la identificación y seguimiento de acciones. PMC en SG2 establece las prácticas que se requieren para implementar la gestión de acciones correctivas hasta su cierre. Revisemos como se pueden establecer estas prácticas en un flujo con BPMN.

Herramientas de apoyo a requisitos

El modelo CMMI no establece como condición el uso de herramientas específicas para la implementación de las prácticas en las áreas de proceso. Aunque la herramienta no hace el proceso, es útil apoyarse en ellas para facilitar las tareas que se requieren. En particular las áreas de proceso de REQM y RD se benefician mucho si el proceso se refuerza con alguna herramienta.
IRQA es una herramienta desarrollada por Visure que permite identificar, analizar y gestionar los requisitos. Una solución completa e integral para el proceso de definición y gestión de requisitos.

Requisitos del cliente, producto, componentes del producto e interfaz

En el modelo CMMI las prácticas de RD consideran básicamente tres niveles de requisitos, del cliente, producto y componentes del producto. Adicionalmente a estos se menciona la identificación de requisitos de interfaz, igualmente importantes. 
Los diferentes niveles de requisitos cubren, durante todo el desarrollo del producto, las diferentes etapas de refinamiento de las necesidades iniciales del cliente que son diseñadas en la solución a nivel de requisitos del producto y a un nivel más bajo de instanciación como requisitos de componentes del producto. Estos niveles de requisitos se van obteniendo a través de diferentes iteraciones y refinamientos donde se detallan, derivan y asignan las dependencias de requisitos de alto nivel hacia los requisitos obtenidos a niveles más bajos.