PRO-TDT-009 Proceso de Desarrollo

v 1.5 / TS, VER, VAL, PMC, RD, CM, PPQA, REQM

Propósito

Definir la forma de trabajo al momento de desarrollar un requerimiento funcional. Incrementar el yield en la detección de defectos en la misma fase que son inyectados.

Notas introductorias

No se incluye la preparación de ambiente de desarrollo porque el acuerdo técnico inicial del proyecto se comprometió a entregar el código fuente y el socio formador a desplegar dicho código.

Las inconsistencias dentro del equipo de CR pueden ser definidas como las discrepancias entre productos de trabajo tales como tener modelos y matrices desactualizadas, documentación que se encuentre fuera de lugar, tener código, diseños o análisis que no cumplan con las checklists, una validación hecha con pruebas desactualizadas, la falta de puntualidad o no registrar el valor ganado en las entregas, o la entrega de una tarea hecha por alguien que no fue asignado.

Involucrados

Equipo de Desarrollo

Entradas

Salidas

Requerimiento funcional terminado.
Documentación actualizada.

Descripción

Fase	Actividades	Responsables	Prácticas Asociadas al CMMI
Análisis	1. Definir criterios de aceptación que describan la funcionalidad del requisito y los limitantes del mismo. 2. Actualizar el issue en Github con los nuevos criterios. 3. Otro miembro del equipo (que no vaya a desarrollar el requisito) deberá diseñar pruebas de escenarios, de integración y de voz alta; para ello, revisar el Plan de Pruebas. 4. Diseñar wireframes de bajo nivel en el pizarrón del salón 2001. Tomar una foto a tu wireframe e incluirlo en la siguiente carpeta con el identificador del requerimiento "RF ##". 5. Realizar actualizaciones al MER si es necesario. 6. Si al analizar el requerimiento es demasiado grande y es necesario dividirlo usar el PRO-TDT-006. 7. Incluye todos los ítems de trabajo en la Matriz de Trazabilidad de Requerimientos (RTM). En la fase de Análisis debe estar el issue y los wireframes. 8. Al terminar, registrar el tiempo en el Plan de valor ganado en Análisis. 9. El requisito al finalizar ya con los criterios actualizados debe estar en ready. Se debe marcar así en el plan.	Team Member	REQM SP 1.4 TS SP 2.3 RD SP 2.1 RD SP 2.2 RD SP 2.3 RD SP 3.1 VER 1.3 PMC SP 1.1 RD SP 3.2
Verificación del Análisis	1. Verificar los criterios de aceptación, pruebas y wireframes con la checklist personal de Análisis. 2. En caso de encontrar defectos registrarlos en el Log de defectos y solucionarlos hasta que el número de defectos sea 0. 3. Al terminar, registrar el tiempo en el Plan de valor ganado en Análisis.	Team Member	VER SP 1.1 VER SP 1.3 VER SP 3.1 VER SP 3.2 PMC SP 1.1 RD SP 3.3 RD SP 3.5
Validación del Análisis	1. Validar pruebas y criterios de aceptación con una de las personas certificadas, se utiliza la Checklist de análisis. 2. En caso de encontrar defectos registrarlos en el Log de defectos y solucionarlos hasta que el número de defectos sea 0. 3. Validar los wireframes con el socio formador en una de las dos juntas, ya sea martes o jueves. Al validar debes de presentar el requerimiento, su funcionalidad y explicar el wireframe. 2. En caso de encontrar defectos registrarlos en el Log de defectos y solucionarlos hasta que el número de defectos sea 0. 4. Al terminar las tareas, registrar el tiempo en el Plan de valor ganado en Análisis. 5. Mejorar checklist personal de Análisis con los defectos de análisis que más inyectas tú como desarrollador.	Team Member	VER SP 2.1 VER SP 2.2 VER SP 2.3 VAL SP 1.3 VAL SP 2.1 VAL SP 2.2 RD SP 3.3 RD SP 3.5 PMC SP 1.1
Diseño	1. Diseñar el requerimiento usando el Estándar de Diseño, se recomienda diagrama de secuencia. 2. Crea tu carpeta con el identificador de tu requerimiento "RF ##" en la siguiente carpeta y añade tu diseño. 3. Actualizar el diccionario de datos. 4. Registrar el link al diagrama en la Matriz de Trazabilidad de Requerimientos (RTM) en la fase de Diseño. 5. Al terminar las tareas, registrar el tiempo en el Plan de valor ganado en Diseño.	Team Member	TS SP 2.1 RD 2.2 PMC SP 1.1 REQM SP 1.4
Verificación del Diseño	1. Verificar el diseño del requerimiento con la checklist personal de Diseño. 2. En caso de encontrar defectos registrarlos en el Log de defectos y solucionarlos hasta que el número de defectos sea 0. 3. Al terminar, registrar el tiempo en el Plan de valor ganado en Diseño.	Team Member	VER SP 1.1 VER SP 1.3 VER SP 3.1 VER SP 3.2 PMC SP 1.1 RD SP 3.3 RD SP 3.5 REQM SP 1.5
Validación del Diseño	1. Validar el diseño con una de las personas certificadas, se utiliza la Checklist de diseño. 2. En caso de encontrar defectos registrarlos en el Log de defectos y solucionarlos hasta que el número de defectos sea 0. 3. Mejorar checklist personal de Diseño con los defectos de diseño que más inyectas tú como desarrollador. 4. Al terminar, registrar el tiempo en el Plan de valor ganado en Diseño.	Team Member	VER SP 2.1 VER SP 2.2 VER SP 2.3 VAL SP 1.2 VAL SP 1.3 VAL SP 2.1 VAL SP 2.2 PMC SP 1.1 RD SP 3.3 RD SP 3.5 REQM SP 1.5
Desarrollo	1. Abrir el diseño y el estándar de codificación como "sidebar" antes de empezar a codificar. 2. Crear una rama para tu requerimiento apegándose a el estándar para nombres de ramas. 3. Empezar a tomar el tiempo. Codificar dividiendo las tareas en los paquetes de trabajo del Plan de valor ganado. 4.Documentar tu código siguiendo el Estándar de XML. Hacer los commits siguiendo el Estándar para commits. 5. En caso de encontrar la solución a un problema documentarla en el Manual de Arquitectura. 6. Continuar hasta terminar todos los paquetes de trabajo. 7. Al terminar la tarea, registrar el tiempo en el Plan de valor ganado en Desarrollo. Importante: Las pruebas unitarias se incluyen en el desarrollo.	Team Member	VER SP 1.3 TS SP 3.1 TS SP 3.2 PMC SP 1.1 CM SP 1.2
Verificación del Desarrollo	1. Verificar el código del requerimiento con la checklist personal de Desarrollo. 2. En caso de encontrar defectos registrarlos en el Log de defectos y solucionarlos hasta que el número de defectos sea 0. 3. Al terminar las tareas, registrar el tiempo en el Plan de valor ganado en Desarrollo.	Team Member	VER SP 1.1 VER SP 1.3 VER SP 3.1 VER SP 3.2 PMC SP 1.1 RD SP 3.3 RD SP 3.5 REQM SP 1.5
Validación del Desarrollo	1. Validar el código con una de las personas certificadas, se utiliza la Checklist de desarrollo. 2. En caso de encontrar defectos registrarlos en el Log de defectos y solucionarlos hasta que el número de defectos sea 0. 3. Al terminar las tareas, registrar el tiempo en el Plan de valor ganado en Desarrollo.	Team Member	VER SP 2.1 VER SP 2.2 VER SP 2.3 VAL SP 1.2 VAL SP 1.3 VAL 2.1 VAL 2.2 PMC SP 1.1 RD SP 3.3 RD SP 3.5 REQM SP 1.5
Pruebas	Otro miembro del equipo (que no haya desarrollado el requisito y, de preferencia, que no haya diseñado las pruebas) deberá seguir lo siguiente: 1. Ejecutar pruebas de escenarios e integración, registrar los resultados en el siguiente archivo. 2. Ejecutar pruebas de voz alta con un usuario externo al proyecto y registrar los resultados en el siguiente archivo. 3. Registrar los defectos encontrados en el Log de defectos y solucionarlos hasta que el número de defectos sea 0. 4. Al terminar, registrar el tiempo en el Plan de valor ganado en la sección de Testing. Importante: Cualquier duda en las pruebas o en qué consisten consulta el plan de pruebas del proyecto.	Team Member	RD SP 3.5 PPQA SP 1.2 VER SP 3.1 VER SP 3.2 VAL SP 2.1 VAL SP 2.2 PMC SP 1.1 RD SP 3.3 RD SP 3.5 REQM SP 1.5
Entrega	1. Añadir tu requerimiento al Manual de usuario si es una función que puede ejecutar el administrador siguiendo la Guía para Agregar requeriementos al manual de usuario. 2. Hacer tu PR siguiendo el estándar de Pull Request. 3. Verificar tu Pull Request con la checklist de revisión de pull request. Si seguiste el proceso al verificar deberías cumplir con todos los criterios de esta checklist. 4. Haz merge de develop a tu rama para solucionar posibles conflictos en la misma rama y no en develop. 5. Pide dos revisores para tu Pull Request. Al revisar un PR, deberás verificar que cumpla con el estándar, el número de defectos activos sean 0 para ese requerimiento y que se hayan realizado las pruebas. 6. Después de hacer merge, registrar el tiempo y la fecha de finalización en el Plan de valor ganado en la sección de Entrega. 7. Una vez hecho merge se marca en la Matriz de Trazabilidad de Requerimientos (RTM) la historia de usuario como done.	Team Member	TS SP 3.2 CM SP 2.1 CM SP 2.2 PMC SP 1.1 RD SP 3.2 CM SP 1.2 REQM SP 1.4

Control de cambios

Versión	Cambio realizado	Análisis	Autor	Revisor(es)	Fecha de cambio
v 1.0	Creación del proceso	Se crea un proceso de desarrollo con base en la forma de trabajo actual pero se añaden la fases de verificación y validación con la intención de bajar la cantidad de defectos inyectados en las fases iniciales. También se busca que se detecten en la misma fase en la que son inyectados. Se añaden las pruebas de escenarios y de voz alta para cada requerimiento.	Alejandra Cabrera Ricardo Rosales David Langarica José Riosmena	Carlos Velasco	15/05/2024
v 1.1	Agregar sp faltante	Se agregaron sp faltantes por retro de scampi	Ricardo Rosales	David Langarica	24/05/2024
v 1.2	Agrega el rol de otros miembros del equipo en la fase de análisis y pruebas	Con base en la retroalimetación grupal, se anexan los roles de otros miembros del equipo en el proceso	David Langarica	Ricardo Rosales	28/05/2024
v 1.3	Agrega la verificación de ready y done	Se añade el uso de ready y done para las historias de usuario	Alejandra Cabrera	Denisse Domínguez	29/05/2024
v 1.4	Prácticas RD	Se Agregan las prácticas de RD	Ricardo Rosales	Alejandra Cabrera	07/06/2024
v 1.5	Agregar prácticas de REQM 1.4 y 1.5	Se identifican las prácticas de reqm 1.5 en los log de defectos y reqm 1.4 la matriz de trazabilidad	Alejandra Cabrera	Sergio Garnica	07/06/2024

PRO-TDT-009 Proceso de Desarrollo

Propósito​

Notas introductorias​

Involucrados​

Entradas​

Salidas​

Descripción​

Control de cambios​