Desarrollador
8 de mayo, 2020
El administrador de desarrollo de aplicaciones Darroll Walsh comparte una introducción al desarrollo de CMMI para desarrolladores.
El Modelo de Madurez de Capacidades Integrado (CMMI) es un programa de mejora y evaluación de procesos que se integra con otros programas de mejora de procesos, como el Cuerpo de Conocimiento de Gestión de Proyectos (PMBOK) y Agile. Trabaja para optimizar y estandarizar todos los procesos y proporcionar un medio para tener supervisión y métricas procesables para el Desarrollo, los Servicios, la Gestión de proveedores, la Madurez cibernética y otros.
Lo que quiero hacer es proporcionar una visión general de CMMI Dev desde la perspectiva de un desarrollador. Nos saltaremos las partes de gestión de proyectos, análisis de negocios, gestión de configuración y pruebas de CMMI DEV para centrarnos en el impacto de CMMI en un equipo de desarrollo. Si hay interés en los otros roles o capacidades que puede ser un buen tema para una entrada de blog posterior. Solo tenga en cuenta que hay mucho trabajo que sucede antes de que los desarrolladores comiencen, incluso en el desarrollo ágil.
Comencemos:
El BRS, o Especificación de Requisitos comerciales, es donde todo comienza, esta es la única fuente de verdad. Aquí es donde los requisitos comerciales que el propietario del producto firma. Si bien se puede consultar a los desarrolladores sobre la creación de los BRS, esto es principalmente responsabilidad de BA. Sin embargo, aquí es donde un desarrollador puede realmente conocer la aplicación que está desarrollando; un lugar para obtener el panorama general.
Los diseños de alto y bajo nivel son la documentación de arquitectura que muestra cómo se conectan los componentes de la aplicación. En el diseño de alto nivel, estableceríamos dependencias externas y cómo los usuarios y/o sistemas interactuarán con nuestro sistema. El diseño de bajo nivel establecería cómo interactúan los componentes internos entre sí. La revisión de estos daría a otro desarrollador una comprensión muy rápida del funcionamiento de la aplicación.
El SRS, o Especificación de Requisitos de software, es donde el desarrollador documenta cómo se va a construir la aplicación. Aquí es donde se documentan los servicios, se establecen las dependencias y, en general, cómo se supone que debe funcionar el código, basado en los BRS que se crearon. Esto se hace normalmente antes de que se escriba el código y es una tarea estándar. Sé que algunos se preguntan por qué tendríamos que hacer esto. Mi código se documenta a sí mismo. Y aunque estoy seguro de que lo es, el código se distribuye a través de cientos de archivos y miles de líneas de código. Y a veces la intención no es tan clara como nos gustaría. El SRS nos da un documento a mirar con un esquema claro de lo que podemos esperar. Describe los casos de uso y el comportamiento esperado en una mansión consistente.
Después de definir lo que vamos a hacer, y luego escribir el código, es hora de que alguien revise lo que hicimos. Ingrese la Revisión del Código. Esto no solo es una buena práctica para detectar cualquier error y garantizar que seguimos las mejores prácticas y directrices, sino que es una excelente manera de compartir lo que está haciendo la aplicación. El mero hecho de revisar el código con un segundo par de ojos nos da una segunda persona que está familiarizada con cómo funciona el código. Como esto se ha convertido en una práctica estándar en la mayoría de los equipos de desarrollo, no voy a insistir en esto.
Las pruebas unitarias son otra de las actividades principales de la mayoría de los programas de desarrollo. Las pruebas unitarias, ya sea como parte de un Desarrollo basado en pruebas o después de escribir el código, son una de las mejores formas de asegurarse de que los cambios futuros no introduzcan errores en nuestro código. En una canalización de CI / CD podemos asegurarnos de que todas las pruebas pasen antes de permitir que se registre el código. Esto nos ayuda a mantener el código en buen estado de funcionamiento.
Individualmente hay valor en cada conjunto de documentos anteriores, sin embargo, las ganancias reales comienzan cuando puede unir toda esta información. Al comienzo del proceso de recopilación de requisitos, comenzamos una Matriz de Trazabilidad de Requisitos que nos permite vincular los requisitos comerciales, los requisitos de software, el código, las pruebas unitarias, los planes y casos de prueba y la aceptación del usuario. Imagine seis meses de un proyecto grande y un cambio hace que un caso de prueba falle. Ahora podemos volver a los requisitos, averiguar cuál es el propósito de ese código, saber exactamente dónde está el código para esa lógica, modificar la prueba unitaria para detectar el nuevo caso e implementar una solución en cuestión de horas, no de días.
A corto plazo, el CMMI puede parecer excesivo, pero incluso en proyectos pequeños, el conocimiento capturado siguiendo el proceso acorta el ciclo cuanto más tiempo esté lejos del proyecto. Sin mencionar si nunca has trabajado en el proyecto antes.
Soporte para desarrolladores
Administrador de Cuentas de Éxito del Cliente de Desarrollo de aplicaciones, Soporte para Desarrolladores de Microsoft
Seguir