Desarrollo de un Banco del Tiempo usando Personal Software Process

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.

Qué es un Banco del Tiempo?

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.

Qué es PSP?

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 

  • Proceso: Secuencia de pasos que se deben seguir para realizar una tarea determinada
  • Proceso definido: Secuencia documentada de pasos para hacer un trabajo específico. Los procesos se definen para los trabajos repetitivos.
  • Plan: Los planes incluyen los pasos del proceso y otros elementos para llevar a cabo el producto, como son recursos necesarios, roles de los participantes del proyecto, plan de calendario, presupuesto, metas y objetivos, compromisos del proyecto, riesgos identificados.
  • Fases: Estados del proceso, PSP tiene 3, Planeación, Desarrollo (Diseño, Revisiones de diseño, Codificación, Revisiones de código, Compilación y Pruebas), Postmortem
  • Guiones (Scripts): Descripciones expertas que guían la aplicación de un proceso
  • Formatos: Proporcionan un marco adecuado para la recopilación y almacenamiento de datos del proceso
  • Métricas: Cuantifican el proceso y el producto
  • Estándares: Proporcionan definiciones precisas que guían el trabajo , la recopilación y uso de datos del proceso
  • Defecto: Cualquier cosa que deba ser solucionada antes de que el producto esté completado, puede estar en los requerimientos, diseño o un problema de implementación.
  • Tiempo de interrupción: Tiempo destinado en el trabajo que no está definido en el plan ni definido por el proceso. Algunos ejemplos pueden ser llamadas o descansos.
  • Calidad: La calidad de un producto se mide en términos de la cantidad de defectos (ej. 5 defectos por cada 1000 líneas de código)
  • Yield: Porcentaje de defectos en el producto que se eliminan en una fase particular o grupo de fases.
  • Yield de fase: Porcentaje de defectos removidos durante una fase.
  • Yield del proceso: Porcentaje de defectos removidos antes de entrar en la fase de compilación o pruebas
  • Yield de revisión: Porcentaje de defectos en el programa encontrados durante la revisión.
  • Porcentaje de costo de evaluación de la calidad COQ:  Porcentaje de tiempo de desarrollo empleado en revisión de diseño y código
  • Porcentaje de fallas COQ: Porcentaje de tiempo de desarrollo empleado en compilación y pruebas.
  • Costo de la calidad COQ: Porcentaje de tiempo dedicado a realizar tareas de evaluación y corrección. Las principales métricas de COQ son:
  • Relación de evaluación / fallas (COQ): Proporción de tiempo invertido en tareas de evaluación con respecto al tiempo invertido en tareas de corrección de fallas.
  • Densidad de defectos: Número de defectos detectados por unidad de tamaño (ejemplo: número de defectos / Líneas de código).
  • Tasa de eliminación de defectos de fase: Número de defectos encontrados por hora en la fase.
  • Tasa de revisión: Tamaño del producto revisado por hora.
  • Apalancamiento de eliminación de defectos (DLR): Medida de la eficacia relativa de la eliminación de defectos entre dos fases cualquiera del proceso.
  • Índice de calidad del proceso (PQI): Métrica derivada para determinar la calidad de un proceso de desarrollo de software. El valor del PQI es el producto de cinco valores de componentes de perfil de calidad:
    • Calidad de diseño: Proporción del tiempo del diseño con respecto al tiempo de codificación.
    • Calidad de revisión del diseño: Proporción de tiempo de revisión del diseño con respecto al tiempo del diseño.
    • Calidad de revisión del código: Proporción del tiempo de revisión del código con respecto al tiempo de codificación.
    • Calidad de codificación: Proporción de defectos de compilación con respecto al tamaño del producto.

Calidad del programa: Proporción de defectos en pruebas con respecto al tamaño del producto.

Fases de desarrollo

PSP tiene guiones, formatos y metricas definidas para cada fase del desarrollo, los cuales iremos explicando en la medida que miremos cada fase.

Planeación

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:

  • Descripción del problema: Este criterio es la descripción del problema que se requiere solucionar.
  • Formulario del Resumen del Plan del Proyecto PSP0.1: Aquí se registran los tiempos estimados, los tiempos reales, tiempos a la fecha y defectos.
  • Log de Registro de Tiempos y Defectos: El registro de logs se puede llevar a cabo en hojas de cálculo.
  • Estándares de
    • Tipo de Defecto: Tabla de Estandar de tipo de defectos mas abajo.
    • Codificación: Depende del lenguaje de programación utlizado, para el desarrollo del Banco del Tiempo se uso PEP8, un estándar de Python y ECMAScript 6, un estándar de Javascript.
    • Conteo del tamaño: El conteo de tamaño se puede hacer utilizando Líneas de código (Lines Of Code - LOC) o cantidad de hojas.
  • Cronómetro: El cronómetro es para medir el tiempo llevado en todas las actividades.

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

 

Paso 1 (Planeación)

El paso 1 del Guión de planeación tiene los siguientes puntos:

Producir u obtener listado de requerimientos:

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:

  • Módulo de usuarios: Administración de perfiles dentro de la aplicación web del banco del tiempo, como por ejemplo: registro de usuarios, autenticación de usuarios, actualización de datos de usuario.
  • Módulo de intercambios: Administración de los registros de servicios y postulaciones de intercambios entre usuarios.
  • Módulo de notificaciones: Notificaciones a los usuarios del sistema en caso de que haya alguna postulación a un servicio ofrecido o viceversa.
  • Módulo de calificaciones: Calificaciones a otro al prestar o recibir un servicio y viceversa.

También se definio una estructura de Hardware del sistema (servidores, conexiones, etc.)

 

Estimar el tiempo requerido de desarrollo (diseño, codificación, 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)

Ingresar la información del Plan en el formulario Resumen del Plan de Proyecto.

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.

Completar el Log de Registro de Tiempo

Registro de tiempo llevado a cabo en cada tarea (se mostrará mas adelante)

Paso 2 (Desarrollo)

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.

Diseño del programa

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.

Implementación del Diseño del programa

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.

Compilación del programa, y reparar registrar todos los defectos encontrados.

En esta actividad se compila el codigo desarrollado, si hay errores, estos se deben reparar y se deben anotar en el log de defectos.

Probar el programa, arreglar y registrar todos los defectos encontrados.

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.

Completar el Log de Registro del Tiempo.

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)

Tamaño de la aplicación

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

Paso 3 (PostMortem)

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 

Registro de defectos

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.

Registro de tiempos

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

  1. Para la codificación de esta parte del codigo usamos los requerimientos, uno de los cuales dice: La aplicación web debe tener un formulario de registro con nombre de usuario, correo electrónico y contraseña accesible para cualquier persona o entidad.
  2. También revisamos en el diseño el caso de uso y los diagramas de secuencia para tener claro el flujo de desarrollo, asi como el modelo relacional para tener claro los nombres usados en la base de datos.
  3. Codificación: Se hace la codificación, dado que el propósito es medir los tiempos (cronometrados) en cada etapa y los defectos, NO podemos hacer pruebas del código hasta terminar, es decir, la codificación se hace de manera seguida (si se hacen pausas como ir al baño, esto debe estar por fuera de los tiempos).
  4. Se deben anotar los tiempos llevados en la codificación, es posible que en la codificación se hallan encontrado defectos de una iteración anterior, si se corrigen, deben quedar anotados en las columnas de defectos removidos.
  5. Revisión de la codificación: En esta etapa se revisa el codigo realizado, solo para lo que es relacionado con la implementación de registro de usuarios y entidades, la revisión deberia hacerse en otra interfaz, puede ser imprimiendo el código. En caso de encontrar defectos inyectados en codificación, estos deben anotarse en codificación para llevar el registro, esos defectos deben ser corregidos y ser anotados tambien.
  6. Se deben anotar los tiempos de la revisión.
  7. Compilación: En esta etapa se compila el software, si hay algun defecto o error, se debe anotar en que etapa se inyecto (codificación o revisión de codificación), se deben corregir los defectos encontrados-
  8. Se deben anotar los tiempos de la compilación.
  9. Pruebas: Utilizando el plan pruebas, se hacen las pruebas necesarias en el sistema, si se encuentran defectos, se anotan en que etapa se inyectaron y se corrigen, las pruebas se hacen hasta no encontrar mas defectos.
  10. Se deben anotar los tiempos de las pruebas.

Resumen del Plan del proyecto
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
Defectos Inyectados
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
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

Analisis del Proceso

PSP tiene una serie de formulas para analizar productividad y calidad, son las siguientes:

Productividad de la aplicación

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.

Calidad de la aplicación (Métricas)

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:

  • Es menos costoso corregir defectos antes en un proceso, que después.
  • Cuanto más tiempo permanece un defecto en un producto, mayor será el costo para extraerlo
  • Las pruebas son una manera ineficiente e ineficaz para eliminar defectos.
  • Las revisiones son más eficientes que las pruebas para corregir defectos.
  • Es más eficiente prevenir defectos que corregirlos.

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.

 

Yield de fase

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 %

 

Yield del proceso

El porcentaje de defectos removidos antes de entrar en la fase de compilación o pruebas fue de: 26.89 %

 

Yield de revisión

El porcentaje de defectos removidos durante las revisiones fue de: 25 %

 

Porcentaje de costo de evaluación de la calidad COQ

El porcentaje de tiempo de desarrollo empleado en revisión de diseño y codificación fue de: 4.55 %

 

Porcentaje de fallas COQ

El porcentaje de tiempo de desarrollo empleado en compilación y pruebas fue de: 12.34 %

 

Costo de la calidad COQ

El porcentaje de tiempo dedicado a realizar tareas de evaluación y corrección fue de: 16.89 %.

 

Relación de evaluación / fallas COQ

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

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

 

Índice de calidad del proceso (PQI)

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

 

Tasa de eliminación de defectos de fase

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

 

Tasa de revisión

Revisión de codificación:

El tamaño de producto revisado por hora es de: 887.78 Líneas de código.

 

Apalancamiento de eliminación de defectos (DLR)

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

Análisis de la Calidad

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.

Plan de mejora del proceso

 

Problemas del proceso

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.

Sugerencias de mejora

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.

Lecciones aprendidas

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

Compartir Compartir