Estimación de funciones para un juego de software
Ron Jeffries posó un software desafío de estimación para determinar el esfuerzo probable requerido para ofrecer un próximo conjunto de características de un juego que él y su equipo están escribiendo. Decidí aceptar este desafío y realizar una estimación del tamaño COSMIC y tal vez al hacerlo, llamaré la atención sobre los méritos de la estimación de la PPC y cómo puede ayudar con el pensamiento de diseño.
Se nos pide que estimemos el esfuerzo requerido para diseñar alguna funcionalidad dentro de un juego parcialmente construido; aquí está el requisito de alto nivel:
Proporcionar a un miembro del equipo de diseño de niveles la posibilidad de controlar la ubicación de los objetos de la mazmorra, incluidos los monstruos, el punto de partida del jugador, los elementos decorativos que contienen botín y el botín que contienen, y los elementos de botín independientes.
Hay más contexto que se puede leer aquí:
https://ronjeffries.com/articles/-z022/0222ff/cfp-est-chal/
Este es un requisito de alto nivel. Hay muchas cosas que no sabemos. No es posible realizar una medición precisa de la CFP del software entregado final, pero podemos medir los requisitos siempre que sean lo suficientemente claros para una interpretación coherente.
Las dos razones principales para buscar una estimación son tener una indicación confiable de la cantidad de esfuerzo necesario (que generalmente nos indica el costo) y la duración probable transcurrida. Armados con estos dos datos, podemos planificar de forma eficaz.
Una estimación del tamaño funcional puede ayudarnos a responder estas dos preguntas, pero también la El proceso de estimación es valioso.. El proceso de estimación nos ayuda a aclarar y mejorar la calidad de los requisitos, lo que a su vez puede ayudar a reducir el retrabajo.
Primero, debemos establecer qué es lo que estamos estimando (y qué no estamos estimando). Podemos considerar esto como establecer los límites de la estimación. Estimaremos el tamaño (no el esfuerzo) de la funcionalidad a desarrollar únicamente para este conjunto de funciones. Sólo estamos considerando la funcionalidad tal como se describe, no adivinaremos ninguna otra funcionalidad.
Dada la alta granularidad de los requisitos proporcionados, solo podemos dimensionar lo que sabemos y luego permitir lo que no sabemos (ScopeMaster hace ambas cosas). Así que ahora profundicemos en los detalles.
Qué debe hacer el software
"Ofrecer a un miembro del equipo de diseño de niveles la capacidad de controlar la ubicación de los objetos de la mazmorra, incluidos los monstruos, el punto de partida del jugador, los elementos decorativos que contienen botín y el botín que contienen, y los elementos de botín independientes".
El objetivo general es controlar la ubicación inicial de los objetos en un espacio limitado.
Las consideraciones contenidas en la explicación incluyen las siguientes:
- Límites 2D predefinidos de ubicaciones permitidas (pisos, no paredes)
- Necesitamos reconocer la adyacencia del muro
- No tenemos que preocuparnos por los pasillos, sólo por las habitaciones.
- Hay diferentes tipos de Objetos que en su mayoría tienen las mismas características para nuestros propósitos: Tesoro, Decoración y Monstruos.
- Decoración que contiene Tesoro
- Jugador (para la posición inicial)
Por ahora no nos preocuparemos de los límites de cuántos objetos se pueden colocar en un nivel, ni de si se pueden colocar muchos objetos en el mismo lugar.
Así que ahora comenzamos a dividir esto en un conjunto de historias de usuarios (o requisitos de usuario funcionales orientados al usuario FUR). Por supuesto, utilizamos ScopeMaster para ayudarnos a acelerar esto; en total, pasé poco menos de 1 hora leyendo y comprendiendo los requisitos, creando historias de usuario y refinándolas. (Luego pasé 1,5 horas más escribiendo esto y publicando estos resultados). ScopeMaster dimensionó las historias por nosotros pero también nos ayudó a mejorar nuestra visión de los requisitos y el diseño simultáneamente.
Estos son los pasos que tomé:
Primero, averigüe con qué objetos identificables del usuario necesitamos trabajar, estos son
• Niveles (que tienen habitaciones)
• Habitaciones (que tengan dimensiones)
• Objetos (que tienen una ubicación inicial)
• Contención (describe cuándo en Decoración contiene un tesoro).
Luego describa la funcionalidad desde la perspectiva de un usuario y el resultado serán solo estas tres historias de usuarios.
-
Como level_designer puedo seleccionar el nivel en el que quiero trabajar y las habitaciones que contiene.
-
Como diseñador de niveles, puedo seleccionar una habitación [dentro de un nivel] y crear un objeto de nivel [con ubicación_de_habitación en la que colocar un objeto].
-
Como diseñador de niveles, puedo buscar objetos de nivel y luego crear un objeto de contención de nivel.
Estas no fueron mis versiones iniciales del requisito. Cada uno tuvo algunas revisiones. ScopeMaster brindó comentarios que me ayudaron a mejorar la calidad y a determinar el tamaño de cada requisito.
Diagrama de modelo de caso de uso generado automáticamente para un conjunto de requisitos
Para cada requisito obtenemos una interpretación funcional, que determina la estimación de la CFP y el desglose del movimiento de datos:
Interpretación funcional de un requisito que muestra los movimientos de datos y el tamaño de la CFP.
Otra perspectiva potencialmente útil sobre el requisito en forma de diagrama de secuencia (también generado automáticamente).
Diagrama de secuencia generado automáticamente para un requisito funcional individual
Una vez revelada la intención funcional, podemos empezar a pensar en cómo probar el software entregado según estos requisitos. ScopeMaster hace gran parte de ese trabajo por nosotros:
Escenarios de prueba generados automáticamente para un requisito funcional individual
Mejorar la calidad del pensamiento y los requisitos
Las ilustraciones anteriores, que se generan automáticamente a partir del texto de requisitos, nos ayudan a alcanzar una comprensión clara de la intención funcional de lo que se ha escrito. Para los profesionales de desarrollo de software con mucha experiencia, estas ilustraciones pueden revelar poca información adicional sobre tan solo tres requisitos, pero cuando se trabaja en un conjunto grande de requisitos pueden ser muy efectivas para exponer problemas potenciales antes de que se escriba el código. ScopeMaster puede analizar un conjunto de hasta 2500 requisitos.
Estimación del tamaño
El dimensionamiento COSMIC es una metodología ágil y amigable para medir el tamaño de la funcionalidad del software, porque le permite dimensionar los requisitos que conoce sin necesidad de conocer otros requisitos. Es posible que haya leído mal el desafío e idealmente tendría algunas preguntas de seguimiento, pero dado lo que sé al leer el desafío, el tamaño (de lo que sabemos) es 17 PPC.
Estimaciones de esfuerzo y duración
Lo que realmente nos gustaría saber es cuánto esfuerzo y cuánto tiempo llevaría ofrecer la funcionalidad. Los estudios, los puntos de referencia y las experiencias han demostrado que los promedios típicos para desarrollo y pruebas unitarias son de alrededor de 4 a 8 horas por CFP. Ocasionalmente se observa mucho peor que esto (más de 20 horas/CFP) en organizaciones ineficientes. En el otro extremo del espectro, equipos altamente competentes, con altos niveles de reutilización, pueden reducir esto a 2-3 horas/CFP, pero esto es poco común. Para este ejercicio asumiremos que desarrolladores altamente capacitados y con buenas herramientas están trabajando en esto. Su única limitación son los requisitos volátiles, por lo que entre 4 y 6 horas por CFP es un rango razonable. Normalmente nunca ofrezco estimaciones puntuales, sólo rangos, con explicaciones. Y entonces tenemos un rango estimado de 68 a 102 horas de esfuerzo. Un desarrollador rara vez es productivo durante más de 5 horas por día, por lo que serían entre 14 y 20 días.
¡Pero espera! Podría haber más (incógnitas cognoscibles). ScopeMaster realizó un análisis CRUD en el conjunto de 3 requisitos e identificó que puede haber funciones adicionales que omitimos:
Si se espera que el desarrollador cree también toda la funcionalidad CRUD que falta, entonces es posible que este trabajo aumente a 53 CFP (42 -63 días).
Conclusión
El dimensionamiento de COSMIC sigue los principios del diseño de software y mide los movimientos de datos solo dentro del contexto dado. Es aplicable a la gran mayoría de dominios de software, incluidos los juegos. La metodología de dimensionamiento ayuda con el pensamiento de diseño y, como tal, generalmente terminamos con mejores requisitos y un mejor ajuste del diseño. El dimensionamiento se puede realizar manualmente y se necesita un porcentaje muy pequeño del tiempo del desarrollador para hacerlo. Es incluso más rápido cuando se utiliza ScopeMaster®. En este caso el trabajo de lectura, comprensión, análisis, aclaración y dimensionamiento de los requisitos tomó apenas 1 hora. Esto representa sólo 1,41 TP3T del esfuerzo total (o sólo 0,31 TP3T teniendo en cuenta los requisitos de tamaño faltantes). Recuerde que lo que necesita saber para dimensionar los requisitos de la CFP es un subconjunto de lo que necesita saber para construirlos, es decir, que no haya desperdicio.
Cuando un gerente/ejecutivo lo desafía, es importante conocer el límite de la imposibilidad. CFP nos ayuda a comprender el tiempo mínimo que probablemente tomará entregar esta funcionalidad. En este caso, menos de 68 horas sería bueno, menos de 32 horas sería bastante extraordinario.
Cuanto más sepamos dónde queremos terminar, menos callejones sin salida tendremos que recorrer en el camino. En otras palabras, tener requisitos claros reducirá el retrabajo. El dimensionamiento de COSMIC y ScopeMaster aceleran el trabajo para obtener claridad sobre los requisitos, el tamaño y el diseño, por lo que juntos pueden reducir el retrabajo y brindar mayor certeza sobre el esfuerzo y la duración de la entrega del software.
Me gustaría agradecer a Ron Jeffries por el desafío y espero que le resulte útil.
Apéndice
Después de escribir esto, volví y noté que había omitido la funcionalidad de “ubicación inicial del reproductor”. Esto sería al menos 3 CFP.
