- Idiomas:
Tiempo de lectura: 40 minutos.
Público objetivo: Desarrolladores de software y Aseguradores de Calidad
Nivel: Básico/Intermedio.
Fecha publicación: 4 de Junio de 2021
Hola!, despues de mucho rato de no hacer una escrito, quiero compartirles parte del desarrollo de un proyecto personal en el que aplique Personal Software Process (PSP - en español Proceso Personal de Software) como metodologia, la parte mas importante es el PostMortem, ahi esta todo el analisis del proceso, dado que el enfoque es en PSP, voy a omitir algunas cosas como toma de requerimientos o diseño, para los cuales PSP no especifica metodologias.
El desarrollo final esta aquí: bancodeltiempo.net los invito a que se registren y usen Banco del Tiempo, tambien me gustaria que me hicieran alguna retroalimentación, Empecemos.
Un banco del tiempo es un sistema de intercambio de servicios por servicios donde se usa como medida el tiempo en vez del dinero para contabilizar las horas de los servicios prestados o recibidos.
Algunos ejemplos de servicios pueden ser: conversaciones de idiomas, asesorías, tareas domésticas, clases de música, informática, matemática, entre otros, este link pueden encontrar otros ejemplos: Que intercambiar en Banco del tiempo?
El Banco del Tiempo desarrollado es una plataforma web que permite realizar intercambios de servicios en línea, tiene básicamente un registro de personas público para que cualquier persona pueda usarlo, a cada persona dentro de la plataforma se le registraran las horas prestadas o recibidas por sus servicios, además cuenta con una interfaz donde se pueden hacer publicaciones para ofrecer servicios o ayuda y sumar horas y otra donde se puede solicitar algún servicio o ayuda, en este caso sus horas serán restadas.
Metodología predictiva y procesos definidos y de mejora continua, PSP hace énfasis en la documentación de todo proceso (planes, tiempos, errores, tipos de errores) y con estos datos predecir mejor el desarrollo de otros módulos, componentes o aplicaciones con el fin de construir productos de alta calidad a tiempo y con el presupuesto establecido.
Aquí les recomiendo ahondar mucho mas en el tema leyendo el siguiete libro: "PSP: A Self-Improvement Process for Software Engineers" de Watts S. Humphrey.
Las siguientes definiciones son usadas por la metodología PSP
Calidad del programa: Proporción de defectos en pruebas con respecto al tamaño del producto.
PSP tiene guiones, formatos y metricas definidas para cada fase del desarrollo, los cuales iremos explicando en la medida que miremos cada fase.
Para la planeación se utilizó un Guión del Proceso, estos guiones son definidos ya por la metodología, cada uno de los pasos se siguió a cabalidad con el fin de asegurar una calidad en el proceso mismo y en el producto final.
El guión del proceso tiene unos criterios de entrada, es decir, requisitos que se deben tener antes de empezar con cada uno de los pasos, los cuales son:
|
Estandar de tipo de defectos |
|
|
Nombre |
Descripción |
|
Documentación |
Comentarios, mensajes |
|
Sintaxis |
Ortografía, puntuación, formato de las instrucciones |
|
Construir, paquetes |
Gestión del cambio, librerías, control de versión |
|
Asignación |
Declaración, nombres duplicados, ámbito, límites |
|
Interfaz |
Llamadas a procedimientos y referencias, E/S, formatos de usuario |
|
Chequeo |
Mensajes de error, chequeos inadecuados |
|
Datos |
Estructura, contenido |
|
Función |
Lógica, punteros, bucles, recursión, computación, defectos de la función |
|
Sistema |
Configuración, temporización, memoria |
|
Entorno |
Diseño, compilación, pruebas y otros problemas que soporta el sistema |
El paso 1 del Guión de planeación tiene los siguientes puntos:
PSP no tiene una metodologia definida para obtener requerimientos. Para el Banco del Tiempo se hicieron encuentas, esto con el fin de construir una solución de software de acuerdo a las necesidades de ciertos grupos de personas, algunas de las preguntas fueron: Usaría la aplicación del Banco del Tiempo para intercambiar servicios?, ¿Qué tipo de servicios intercambiaría en la aplicación del Banco del Tiempo? ¿Qué funcionalidad adicional le añadiría a la aplicación del Banco del Tiempo?, de estas preguntas y del planteamiento del problema se definieron los requerimientos y el siguiente alcance:
También se definio una estructura de Hardware del sistema (servidores, conexiones, etc.)
En este paso se subdividen los modulos por tareas y se estiman los tiempos de cada tarea, no solo de la codificación como tal si no tambien de la planeación misma, del diseño de la arquitectura de software, de las pruebas y demas. PSP no tiene metodologia de diseño, se puede usar UML por ejemplo. (se mostrará mas adelante)
El propósito de PSP es tener una mejora continua de todo el proceso del desarrollo de un software, con esta información se hará un analisis para determinar la calidad de la aplicación.
Registro de tiempo llevado a cabo en cada tarea (se mostrará mas adelante)
PSP divide el desarrollo en 4 actividades, Diseño, Codificación, Compilación y Pruebas
Para el desarrollo también existe un guión, el cual esta en el siguiente enlace: Guión de la Desarrollo
El diseño y la codificación de software tiene unas subactividades, estas son revisión de diseño y revisión de la codificación. Para el diseño lo que se hace es que tan pronto se termina por ejemplo el diseño de los casos de uso, estos se les hace una revisión con el fin de corregir algún error, dado que PSP tiene un enfoque personal, esta revisión deberia ser realizada por otra persona.
Así como en la pleaneación, a estas actividades también se les debe cronometrar el tiempo.
De acuerdo a los requerimientos definidos, se hace el diseño, este diseño ya tuvo que haber sido planeado y estimado en el paso anterior, en esta actividad lo que se hace es ejecutar lo planeado, es decir, hacer el diseño como tal. Dentro del diseño también se deben abarcar el diseño de casos de prueba.
Para el desarrollo del Banco del Tiempo se realizo el modelo relacional o de base de datos, se hicieron diagramas de casos de uso y diagramas de secuencia.
Posterior al diseño se debe hacer una revisión del diseño, PSP sugiere imprimir el diseño para ser revisado en una interfaz diferente a la donde se hizó el mismo.
Esta actividad hace referencia a la creación de base de datos y codificación del software, posterior a la codificación se debe hacer una revisión del código, esta revisión se sugiere que se haga en una interfaz diferente a la donde se hizo, PSP sugiere incluso imprimir el código y revisarlo impreso, en lugar de revisarlo en el IDE.
En esta actividad se compila el codigo desarrollado, si hay errores, estos se deben reparar y se deben anotar en el log de defectos.
En esta actividad se utilizan los casos de prueba para probar el modulo o parte del código hecha, si hay errores, estos se deben corregir y se deben anotar en el log de defectos.
En la medida en que se avance con cada una de las actividades anteriores, se debe anotar el tiempo en el log de registro de tiempos (se mostrará mas abajo)
El tamaño de la aplicación se definió en líneas de código (LOC), PSP hace referencia a que el tamaño de la aplicación se debe hacer tomando en cuenta los lenguajes de programación utilizados, dado que HTML5 y CSS3 no son lenguajes, se decidió separar el tamaño de la aplicación en 2.
El tamaño de la aplicación en Líneas de código para los lenguajes de programación usados (Python y Javascript - Reactjs) fue de: 5.667
Si sumamos la estructura en HTML y estilos (CSS), el tamaño en Líneas de código fue de: 8.180
Este paso esta relacionado con la documentación de todo el proceso, se revisa que haya una consistencia en la información, que los defectos hayan sido registrados en su totalidad, que se hayan registrado todos los tiempos, adicionalmente se contabiliza el tamaño del software (LOC).
Para el PostMortem también existe un guión, el cual esta en el siguiente enlace: Guión de la PostMortem
El registro de defectos que se muestra acontinuación muestra los tipos de defectos, el tiempo que tomado en resolver los mismos, en que fase se inyectaron y en que fase se removieron, el objetivo es poder determinar cuales son los defectos se inyectan y de acuerdo a eso generar un plan de acción como programador para reducir esa cantidad de defectos, también reducir el tiempo tomado en solucionarlos.
PSP tiene como premisa de que los defectos encontrados y solucionados antes de hacer pruebas (es decir en fases de revisión de diseño y de codificación) mejoran la calidad del software y el tiempo en corregir estos defectos en el tiempo.
Para el Banco del Tiempo, los defectos encontrados y corregidos en diseño, no fue posible encajarlos en el estandar de tipos de defectos sugerido por PSP, por eso se colocaron aparte. En la fase de planeación se insertaron 4 defectos que fueron corregidos en codificación, estos fueron difícil de encajar en también en los tipos de defectos, estos suman 30 minutos.
Los tipos de defectos de Asignación y Sintaxis deberían haberse detectado en su mayoría desde las revisiones de código, casi todos los defectos de asignación fueron por no importar las dependencias requeridas o por estar mal nombradas, defectos que se debieron hallar desde la misma codificación o desde una revisión de código más minuciosa, estos representan el casi el 62% de todos las fallas encontradas.
En el registro de tiempos que se muestra acontinuación se empezó a detallar desde la planeación, donde se empezó a estimar cuanto tiempo llevaria cada tarea (columna Tiempo estimado), luego, a medida que se avanzo con el desarrollo del proyecto se fue completando con el tiempo real (columna Tiempo Actual), tambien se añadieron los defectos añadidos y removidos por cada parte del código realizada.
En este registro tambien esta la revisión de diseño y de codificación. Dado que el desarrollo se hace de manera modular, una iteración en codificación es mas o menos asi:
Vamos a tomar como ejemplo la Implementación registro de usuarios y entidades
| Tabla de Resumen del Plan del proyecto | ||
| Tiempos por fase | ||
| Fase | Tiempo planeado | Tiempo actual |
| Planeación | 22:30:00 | 22:03:34 |
| Diseño | 17:00:00 | 18:50:00 |
| Revisión Diseño | 6:30:00 | 2:11:00 |
| Codificación | 67:30:00 | 92:27:00 |
| Revision Codificación | 22:00:00 | 5:52:00 |
| Compilación | 6:00:00 | 6:23:00 |
| Pruebas | 19:00:00 | 14:04:00 |
| Postmorten | 10:00:00 | 13:20:00 |
| Total | 168 horas | 165 horas, 40 minutos, 34 segundos |
| Tabla de Defectos inyectados | ||
| Fase | Planeados | Actuales |
| Planeación | 2 | 4 |
| Diseño | 2 | 8 |
| Revisión Diseño | 0 | 0 |
| Codificación | 20 | 200 |
| Revision Codificación | 0 | 0 |
| Compilación | 10 | 0 |
| Pruebas | 0 | 0 |
| Postmorten | 0 | 0 |
| Total | 34 | 212 |
| Defectos removidos | ||
| Fase | Planeados | Actuales |
| Planeación | 0 | 0 |
| Diseño | 0 | 0 |
| Revisión Diseño | 0 | 8 |
| Codificación | 4 | 4 |
| Revision Codificación | 0 | 45 |
| Compilación | 20 | 125 |
| Pruebas | 10 | 30 |
| Postmorten | 0 | 0 |
| Total | 34 | 212 |
PSP tiene una serie de formulas para analizar productividad y calidad, son las siguientes:
La productividad se calcula con la siguiente fórmula:
Productividad = Total de Lineas de Código / Tiempo total
Productividad = 5.667 / 165.43
La productividad tomando solo los lenguajes de programación fue de: 34 LOC/Hr aproximadamente.
La productividad sumando la estructura en HTML y estilos (CSS) fue de: 49 LOC/Hr Aproximadamente.
La calidad de la aplicación debe partir de una responsabilidad personal, de mantener una disciplina en el desarrollo y en el seguimiento de los planes realizados. La calidad es una prioridad máxima.
PSP ha definido algunos principios de calidad del software, como los siguientes:
PSP hace mucho énfasis en las revisiones de código, no solo en hacer las revisiones, sino en hacerlas bien, en destinar un porcentaje de tiempo del desarrollo para hacerlas y para detectar defectos antes de pasar a compilación y pruebas.
Revisión de diseño:
El porcentaje de defectos removidos durante la revisión de diseño fue de: 66.67 %
Codificación:
El porcentaje de defectos removidos durante la fase de codificación fue de: 100 %
Revisión de codificación:
El porcentaje de defectos removidos durante la fase de revisión de codificación fue de: 22.5 %
Compilación:
El porcentaje de defectos removidos durante la fase de revisión de codificación fue de: 80.65 %
El porcentaje de defectos removidos antes de entrar en la fase de compilación o pruebas fue de: 26.89 %
El porcentaje de defectos removidos durante las revisiones fue de: 25 %
El porcentaje de tiempo de desarrollo empleado en revisión de diseño y codificación fue de: 4.55 %
El porcentaje de tiempo de desarrollo empleado en compilación y pruebas fue de: 12.34 %
El porcentaje de tiempo dedicado a realizar tareas de evaluación y corrección fue de: 16.89 %.
La proporción de tiempo invertido en tareas de evaluación con respecto al tiempo invertido en tareas de corrección de fallas fue de: 0.37
Densidad de defectos totales:
El número de defectos detectados por cada 1000 líneas de código fue de: 37.41
Densidad de defectos en compilación:
El número de defectos detectados por cada 1000 líneas de código fue de: 22.06
Tomando en cuenta la estructura (HTML) y estilos (CSS3) la densidad de defectos en la fase de compilación fue de: 15.28
Densidad de defectos en pruebas:
El número de defectos detectados por cada 1000 líneas de código fue de: 5.29
Tomando en cuenta la estructura (HTML) y estilos (CSS3) la densidad de defectos en la fase de pruebas fue de: 3.67
Calidad del diseño:
La calidad del diseño fue de: 0.17
Calidad de revisión del diseño:
La Calidad de revisión del diseño fue de: 0.22
Calidad de revisión del código:
La Calidad de revisión del diseño fue de: 0.13
Calidad de codificación:
La Calidad de codificación fue de: 0.79
Calidad del programa:
La calidad de programa fue de: 1.15
Calcular el PQI
Los 5 componentes de PQI se deben normalizar a [0, 1], “0” representa una mala práctica y “1” la práctica deseada.
El PQI fue de: 0
Revisión de diseño:
El número de defectos encontrados por hora en la fase de revisión de diseño fue: 4.75
Revisión de codificación:
El número de defectos encontrados por hora en la fase de revisión de codificación fue: 7.67
Compilación:
El número de defectos encontrados por hora en la fase de compilación fue: 18.58
Pruebas:
El número de defectos encontrados por hora en la fase de compilación fue: 2.13
Revisión de codificación:
El tamaño de producto revisado por hora es de: 887.78 Líneas de código.
La medida de la eficacia relativa de eliminación de defectos en la revisión de diseño fue de: 2.23
La medida de la eficacia relativa de eliminación de defectos en la revisión de codificación fue de: 3.6
PSP hace hincapié en hacer revisiones de código que permitan encontrar defectos antes de las fases de compilación y/o pruebas, el yield de revisión fue del 25%, es decir que de todos los defectos que se corrigieron en el sistema solo se detectaron en las revisiones el ¼ de ellos, un porcentaje que es bajo.
Con respecto al porcentaje de fallas (COQ), el resultado fue que más del 12% por ciento del tiempo fue destinado en compilación y pruebas, un tiempo normal para el desarrollo de la aplicación, sin embargo el porcentaje de evaluación (COQ) si es demasiado bajo (4.55 %) es decir, muy poco tiempo se destinó a revisiones de diseño y codificación.
Para los componentes de calidad PSP recomienda unos valores, por ejemplo para la densidad de defectos en la fase de pruebas lo recomendado es tener menos de 5 defectos por cada 1.000 líneas de código, la densidad de defectos obtenida la fase de pruebas de la aplicación Banco de Tiempo fue de 3.67, una densidad de defectos muy buena.
El índice de calidad del proceso castiga mucho el hecho de que uno o dos componentes sea demasiado bajo, para empezar PSP recomienda que el tiempo destinado al diseño sea mayor al tiempo destinado en codificación, también que el tiempo en revisión de diseño sea por lo menos la mitad del tiempo destinado al diseño y lo mismo para codificación, estos componentes fueron demasiado bajos en el desarrollo de la aplicación. Con respecto a los defectos en compilación, PSP sugiere que sean menos de 10 por cada 1.000 líneas de código y para pruebas que sean menos de 5 por cada 1.000 líneas de código, en estos 2 componentes el resultado fue muy bueno.
El apalancamiento de eliminación de defectos que para la revisión de diseño fue de 2.23 y para la revisión de codificación fue de 3.6 son valores buenos.
Uno de los problemas encontrados en el proceso fue el desconocimiento de Reactjs, uno de los lenguajes de programación usados en la aplicación, a pesar de que Reactjs es una librería hecha en Javascript, la forma en como se utiliza es muy diferente, esto generó que se llevara más tiempo en las fase de codificación y que aumentó también considerablemente la cantidad de defectos por la inexperiencia en el lenguaje.
De los resultados obtenidos en las métricas de calidad podemos generar unas sugerencias de mejora, una de ellas es destinar más tiempo en la revisión del diseño y de la codificación, esto con el fin de mejorar la calidad de la aplicación, PSP hace mucho énfasis en hallar defectos antes de las fases de compilación y pruebas, esto implica no sólo destinar más tiempo, si no hacerlo bien, PSP sugiere hacer las revisiones en una herramienta diferente a la donde se hizo el diseño o el código, incluso recomienda imprimir el diseño o el código para hacer las revisiones.
También es importante conocer muy bien las herramientas a utilizar antes de empezar el proceso, ya que hay entornos de programación (IDE) que hacen revisión del código para detectar errores de sintaxis y que sean solucionados antes de pasar a las fases de compilación y/o pruebas.
Las métricas obtenidas en el desarrollo de la aplicación nos deja algunas lecciones para el desarrollo de aplicaciones futuras, entre ellas que las prácticas utilizadas (estimación de tiempos, revisiones de código, estándares, medición de tiempos) son realmente muy útiles para medir y mejorar la calidad de una aplicación y que es importante utilizar para generar productos de calidad.
La estimación realizada durante la fase de planeación nos arrojó que el tiempo planeado en la fase de codificación fue mucho menor (25% aproximadamente) que el llevado en el desarrollo de la aplicación, también que la cantidad de defectos inyectados que se planearon fue muy bajo (84% aproximadamente) que el real, estas métricas son útiles para hacer una mejor planeación en proyectos futuros.
Las fases de revisión de diseño y revisión de codificación son fases muy importantes dentro de un proceso de desarrollo, destinar un buen tiempo a estas fases definitivamente disminuyera la cantidad de fallas de una aplicación.
No siendo mas, los invito a que se registren en Banco del tiempo en el sigiente enlace: https://bancodeltiempo.net/accounts/signup/
Hasta la próxima...
Autor: Jhon J Valero R 
Ingeniero de Software en Elemental Lab
