Desarrollo de sistemas con Behaviour-Driven Development y Cucumber

Imagen de: Rachel Davies

El Behaviour-driven development (BDD) es un procedimiento de ingeniería de software desarrollado por Dan North como una mejora del Test-Driven Development (TDD).

En español, BDD significa “Desarrollo guiado por comportamientos”, así como de manera similar, TDD se traduce al español como “Desarrollo guiado por pruebas”.

La idea básica del Behaviour-Driven Development (BDD) es explorar, descubrir y luego desarrollar el comportamiento deseado del software, usando conversaciones, ejemplos concretos y pruebas automatizadas.

Al igual que TDD, BDD requiere validar los comportamientos ejecutando pruebas una y otra vez, haciendo necesaria una herramienta de automatización de software testing. Cucumber es una herramienta orientada específicamente a implementar el BDD.

PMOInformatica presenta a continuación Desarrollo de sistemas con Behaviour-Driven Development y Cucumber:

Plantilla de matriz de trazabilidad de requisitos

Siguiendo la definición establecida por el PMI, la matriz de trazabilidad de requisitos es un cuadro que vincula los requisitos del proyecto desde su origen hasta los entregables que lo satisfacen (Definición de la guía del PMBOK).

La matriz de requisitos ayuda a asegurar que cada requerimiento agrega valor al negocio, mostrándote el vínculo entre requisitos, necesidades de negocio y objetivos de proyecto. De esta forma puedes hacer un seguimiento durante el ciclo de vida, mejorando la ingeniería de requisitos al asegurar que estos sean entregados según especificaciones.

Aquí te presentamos una matriz de trazabilidad de requisitos, con la que podrás documentar información de cada requisito, códigos y subcódigos, criterios de aceptación, oportunidades y metas de negocio, entregable que satisface el requisito, interesados (stakeholders), nivel de complejidad, estado actual y más.

PMOInformatica, La oficina de proyectos de informática presenta la plantilla de matriz de trazabilidad de requerimientos.

Plantilla de solicitud de cambios en proyectos

Siguiendo la metodología de gerencia de proyectos del PMI, una solicitud de cambios contiene una propuesta formal de modificaciones a la línea base o documento de proyecto, que se presenta para aprobación al comité de cambios de proyecto u otra entidad designada en el plan de dirección de proyectos.

Estas solicitudes pueden abarcar todo tipo de cambios en el proyecto, como modificaciones de alcance, replanificaciones en el cronograma, incrementos de presupuesto, cambios en niveles de calidad, procedimientos de trabajo, acciones correctivas, preventivas asignaciones de recursos entre otros.

Aquí te presentamos una plantilla para la solicitud de cambios en proyectos. Incluye las secciones para especificar la categoría de cambio realizado, descripción del cambio, justificación e impacto sobre variables de línea base o procedimientos de dirección de proyectos. También tiene un espacio para indicar si está aprobada o rechazada, con la justificación correspondiente.

PMOInformatica, La Oficina de proyectos de informática presenta la Plantilla de solicitud de cambios en proyectos.

Requerimientos no funcionales: Ejemplos

Imagen de: Epicentre

Presentamos la tercera parte de la serie sobre los requerimientos no funcionales, con algunos ejemplos que puedan servir de guía en su definición.

Los requerimientos no funcionales representan características generales y restricciones de la aplicación o sistema que se esté desarrollando.

Suelen presentar dificultades en su definición dado que su conformidad o no conformidad podría ser sujeto de libre interpretación, por lo cual es recomendable acompañar su definición con criterios de aceptación que se puedan medir.

Entre los ejemplos de requerimientos no funcionales presentados, tenemos los referidos a atributos como la eficiencia, seguridad, dependibilidad y usabilidad del sistema. También presentamos ejemplos de requerimientos no funcionales organizacionales y externos.

PMOInformatica presenta: Ejemplos de requerimientos no funcionales.

Estimación de proyectos de software con puntos de función: Determinar tipo de conteo y componentes funcionales

Este articulo esta basado en el contenido del Curso de Análisis de Puntos de Función: Medición y Estimación de Software suministrado por FATTO. Los puntos de función son una herramienta útil para realizar estimaciones de esfuerzo exactas. Para mayor información visita la pagina del curso.

El Análisis de puntos de función, mide el tamaño de los sistemas de información en base a la funcionalidad entregada a los usuarios desde una perspectiva externa de los requerimientos funcionales, tal como veíamos en la primera parte de esta serie Estimación de proyectos de software por puntos de función: Introducción.

Por lo tanto, la medición de los requisitos del software se expresa en término de las transacciones de negocio que el usuario puede ejecutar y de los datos de negocio que se pueden almacenar y acceder.

Al ejecutar un Análisis de puntos de función se dice que estamos realizando un “conteo”. El primer paso a realizar es establecer el tipo de conteo y el segundo paso consiste identificar las transacciones y componentes de datos que vamos a contar.

En esta segunda parte de la serie, presentaremos los distintos tipos de conteo que se pueden realizar y a describir cómo se identifican las transacciones de negocio y componentes de datos. En una tercera parte de la serie se profundizará sobre el cálculo y suma de los puntos de función.

PMOInformatica presenta como determinar el tipo de conteo y componentes funcionales cuando realizas estimaciones de proyectos de software con puntos de función.