Unidad 4

1 //Escenario
Escenario28
Lectura fundamental
Fundamental

Administración
Etapas de un plan
dede
defectos,
comunicación
estratégica y control de procesos
seguimiento

Contenido

1 Seguimiento y control de procesos de desarrollo de software

2 Administración de defectos

Palabras clave: ZenHub, repositorios, GitHub, gerencia de proyectos, pruebas de software, logs.
Introducción
Esta última sección del curso está centrada en las etapas intermedias y últimas de la administración
de un proyecto de software (seguimiento y control). Comúnmente se considera que la administración
o gestión de proyectos se supedita al planteamiento de un cronograma que es estático y que no se
modifica durante el desarrollo del proyecto, lo cual es ideal, pero no se cumple en el contexto real.

Inicio Planeación

Seguimiento Desarrollo
y control o ejecución

Cierre

Figura 1. Grupos de procesos de la gestión de proyectos

Fuente: elaboración propia

Específicamente se presenta la herramienta ZenHub (ZenHub, 2017), un complemento que de

adiciona al navegador Chrome y que funciona como administrador de cualquier proyecto, incluso de
desarrollo de software a nivel personal (usualmente ágil) que se trabaja con el repositorio (© 2017
GitHub, Inc., 2017).

POLITÉCNICO GRANCOLOMBIANO 2
1. Seguimiento y control de procesos de desarrollo de software
Para el gerente del proyecto de software el trabajo no termina al finalizar su planeación. Una vez
culminada esta etapa, se procede a la fase de ejecución; la única manera de garantizar que el proyecto
se desarrolle de acuerdo con lo planeado es a través del seguimiento y control de los procesos. En
el caso de PPS es indispensable conocer las formas y niveles de proceso (Escenario 7) y algunas
herramientas que apoyen su gestión como GitHub + ZenHub.

1.1. ¿Cómo contribuye GitHub al desarrollo de software a nivel personal?

GitHub es una interfaz que permite acceso a un repositorio Git o de control de versiones; esta
herramienta está basada en servicios web y de alojamiento en la nube o Internet. Se utiliza
principalmente para el código, aunque es posible alojar cualquier tipo de archivo o documentación
relacionada con el proyecto en cualquier tipo de formato.

Es factible utilizarla para la gestión de proyectos tanto a nivel de desarrollo de software personal
como de equipo: permite el control de versiones, así como la adición de características o plugins
que mejoran el desempeño y funcionalidad -como es el caso de ZenHub-, y proporciona control de
acceso y varias funciones de colaboración como seguimiento de errores, administración de tareas,
solicitudes de funciones y wikis para cada proyecto.

El uso de adiciones o plugins, como ZenHub, es bastante útil; específicamente, esta es la única herramienta
de gestión de proyectos que se integra de forma nativa con la interfaz de usuario de GitHub. Los
desarrolladores no se tienen que preocupar por cambiar de herramienta o estar reportando su trabajo en
una herramienta adicional y la configuración del ambiente de trabajo es muy sencilla.

GitHub es ideal para el seguimiento y control de procesos de desarrollo de software, ya que tiene
integración con la mayoría de entornos integrados de desarrollo (Integrated Development Environment IDE´s)
o los más comunes (eclipse y netbeans). Al adicionar herramientas de gestión de la información registrada,
los directores de proyecto o los desarrolladores obtienen visibilidad total en el proceso de desarrollo.

POLITÉCNICO GRANCOLOMBIANO 3
 ¿Sabía qué...?
A partir de abril de 2017, GitHub cuenta con 57 millones de repositorios,
cerca de 20 millones de usuarios, por lo que es el mayor número de
código fuente en el mundo. Para la gestión de proyectos SW, la línea de
desarrollo de software del Politécnico GranColombiano tiene alojados allí
gran parte de sus trabajos. Ver: https://goo.gl/u56Kqb

Una de las gráficas de control de desarrollo de software es el BurnDown Chart. Este gráfico permite ver la
forma como se agotan, a través del tiempo, un conjunto de tareas o partes de código, en el caso de PPS
podemos pensar en PROXYs. En la figura 2 se presenta la gráfica generada por ZenHub para un sprint del
proyecto de aula de la línea de desarrollo de software, titulado Videojuego pacto de honor.

La variable independiente es el tiempo y se ubica en el eje horizontal; un sprint es una unidad de

tiempo variable, usualmente de 2 a 4 semanas. La variable dependiente son las unidades de trabajo
o Historys. El comportamiento ideal de esta gráfica es que, a medida que pasa el tiempo, las tareas o
unidades de trabajo partan del total o conjunto de tareas y, de manera uniforme, se aproximen a cero,
es decir cada vez sean menos.

En una implementación real es difícil que se agoten las tareas de manera uniforme; sin embargo, a
través de PPS es posible lograr un trabajo disciplinado y constante.

Figura 2. Ejemplo Reporte de ejecución de trabajo (Burn Down Chart) en el sprint 16

Fuente: Pantallazo GITHub (2017)

POLITÉCNICO GRANCOLOMBIANO 4
Otra de las herramientas con las que cuenta el repositorio de GITHub para el seguimiento, supervisión
y control de manera nativa son los insights. El más usado es el reporte de la medición de la frecuencia de
actualización de código en el repositorio. A esto se le denomina reporte de commits; siempre que se realiza
una actualización o adición de código se deben guardar esos cambios registrándolos en el repositorio, con el
fin de tener un control del trabajo realizado.

A pesar de que el trabajo sea constante, es indispensable que el registro (commit) sea periódico para que
a partir de el se pueda realizar monitoreo y control del proceso. Es posible que un programador codifique
dos horas diarias pero solo registre semanalmente su trabajo. En este caso, para quien supervisa el trabajo
debería significar una labor disciplinada y constante; sin embargo, dado que no realiza el registro de los
tiempos diariamente, no hay forma que la herramienta genere información adecuada.

También puede suceder lo contrario: una persona puede realizar commit todos los días, pero no realizar
mayor aporte al trabajo.

Suponiendo que el registro es acorde con el trabajo, en la figura 3 se presenta el reporte de commits
durante una de las últimas semanas del proyecto, semana de entregas. En esta gráfica se puede evidenciar
el comportamiento en dos reportes: el diagrama de barras y la función de commits en escala diaria. Este
curso tiene sesión de trabajo en clase los días miércoles; en la figura 3, claramente hay una relación
proporcional entre los días que hay trabajo en clase y los días de entrega con el mayor volumen de commits.

Cómo mejorar...
Las herramientas de gestión y control de proyectos no pueden ser utilizadas
si no se alimentan a diario, y difícilmente se puede hacer reingeniería a un
proceso ya ejecutado para determinar los ritmos de trabajo, la ejecución de las
fases y el rendimiento o velocidad de codificación. A parte de esto, diariamente
es bueno dedicar como mínimo 5 minutos para reflexionar:
• ¿Qué faltó registrar?

• ¿Se puede hacer más eficiente?

• ¿Se puede hacer más eficaz?

POLITÉCNICO GRANCOLOMBIANO 5
Figura 3. Reporte de commits semanales
Fuente: elaboración propia.(2017)

En la figura 3, mediante el diagrama de barras, también podemos observar el tiempo de duración del
proyecto, para el caso, desde febrero (02/19/2017) hasta junio (06/04/2017). Esto corresponde al
primer periodo académico de 2017.

El control del proceso solo es posible mediante el correcto, constante y disciplinado registro, el cual
puede ser semiautomático a partir de las herramientas mencionadas, aunque también puede realizarse
de manera manual, mediante un archivo Excel o con herramientas propias del framework PPS. Sin
embargo, se recomienda el uso de repositorios y de los monitores y herramientas de gestión nativos.

PPS es fundamental para conocer no solo el proceso de construcción de software, sino como guía en
las etapas necesarias para mejorar y alcanzar la calidad del proceso y lograr la disciplina necesaria para
registrar el trabajo de manera constante. Solo así es posible realizar seguimiento y control al proceso
de manera acertada.

POLITÉCNICO GRANCOLOMBIANO 6
2. Administración de defectos
Los defectos son algo que en ocasiones pasa a un segundo plano; no obstante, estos están ligados
con la calidad de software y no pueden ser descuidados. No solo es importante el número, sino el
porcentaje de error asociado a cada parte y la relación entre el tamaño y el error total. Debemos
considerar el porcentaje de defectos en relación con el esfuerzo o tamaño del software en cantidad de
código. No es lo mismo un programa de 100 líneas con 20 defectos que un programa de 5000 con
los mismos 20 defectos; tampoco es lo mismo que los errores sean aislados o estén relacionados.

En especial, es importante realizar la administración de defectos por dos características:

2.1. Crecen en forma exponencial (the hidden factory)

El efecto “la fábrica escondida” hace referencia a la producción de errores por una parte o proxy; esto
obedece a que en un proceso, el error está relacionado potencialmente con el error de cada parte. De
la misma manera, un proyecto de desarrollo de software está constituido a partir de varios pasos y cada
uno tiene la posibilidad de tener un porcentaje de defectos. Matemáticamente, la probabilidad de que el
producto final tenga defectos es igual a la multiplicación de las probabilidades de cada fase o parte.

Este término es introducido por Six Sigma (Tennant, 2017) y su foco por la identificación de las fallas en los
procesos que producen retrabajo. Es importante tener presente este fenómeno tanto a nivel de planeación
como en la administración de defectos.

2.2. Se repiten con regularidad (fijaciones)

Se ha demostrado que los seres humanos tendemos a repetir defectos. Así, existe una alta
probabilidad que los defectos cometidos en la codificación de proyectos anteriores se repitan. El
cerebro establece caminos cerebrales que se van formando gracias a la construcción repetida de
código, por lo que, por ejemplo, si existen defectos constantes en la declaración de variables, aumenta
la probabilidad de que se repita en cada proceso de construcción. Afortunadamente el ser humano
aprende más de sus aciertos que de sus errores (Martínez, 2019). La tarea es rastrearlos y destruir la
fijación a través del tiempo.

POLITÉCNICO GRANCOLOMBIANO 7
 2.3. Tipos de pruebas personales

En el proceso de desarrollo personal es transcendental el uso de los distintos tipos de pruebas para asegurar
la calidad del software; estos deben ser aplicados no solo al final del proceso de construcción, sino durante
el mismo. El tipo de prueba más común que se realiza dentro del proceso de desarrollo es la prueba unitaria
o prueba de caja negra. Consiste en la evaluación segmentada del código verificando que, frente a unas
condiciones iniciales, el segmento de código produzca el resultado esperado.

Son numerosos los distintos tipos de prueba debido a que dependen tanto de la técnica aplicada (unitaria,
de interfaz, funcional, de carga, de estrés, de desempeño, de usabilidad, etc.), como de la plataforma (móvil,
web, firmware, etc.) y del tipo de lenguaje que se esté utilizando (.net, Java, phyton, ruby, php, entre otros).

Por consiguiente, esta sección se enfoca en el proceso de pruebas mas no en las técnicas, lenguajes
o herramientas.

2.4. Logs de pruebas

Los logs en PPS se generan en cada una de las fases del proceso de pruebas (ver figura 4) y apoyan
en una serie de formatos (ver figuras 5 y 6, y tabla 1).

Corección de
Registro de
defectos y Análisis de datos
defectos
prueba

Figura 4. Proceso de pruebas de software PPS

Fuente: elaboración propia

2.4.1. Registro de defectos:

La trazabilidad de los defectos, o el log de defectos, requiere información personal y otra relacionada
con el desarrollo; esta última comprende los datos tanto del error y los tiempos asociados a la
remoción, su clasificación, el tipo y referencia del mismo, así como por los metadatos, es decir,
información de clasificación del lenguaje, el programa, el problema-contexto o materia y el cliente o
docente. A continuación, se presenta un formato de ejemplo para el registro de pruebas en PPS, PSP
Defect Recording Log (figura 5).

POLITÉCNICO GRANCOLOMBIANO 8
Figura 5. Forma para el registro de defectos
Fuente: Adaptado de Humphrey

2.4.2. Corrección de defectos y prueba

Dado que el número de herramientas y lenguajes son variados, la salida de control o de ejecución de
la prueba tiene un formato distinto. En este caso para PPS no hay un formato tan detallado, pues el
detalle específico lo da la herramienta que se use para validar el software. A continuación se presenta
un formato (figura 6) que puede ser utilizado para tener el log o comprobante de la ejecución exitosa
de la prueba o la corrección de defectos.

Figura 6. Log de capturas de pruebas

Fuente: Adaptado de Humphrey

POLITÉCNICO GRANCOLOMBIANO 9
 2.4.3. Análisis de datos

Finalmente, es posible hacer un análisis estadístico y de seguimiento a cada una de las pruebas
realizadas al software para determinar variaciones en el rendimiento o clasificar los defectos que más
trabajo tienen para la corrección. El detalle de la prueba está dado por la especificación de los valores
de entrada y salida; esto también permite verificar que no se repita la prueba.

Tabla 1. Ejemplo resumen de pruebas

Tiempo Entrada Salida

Prueba N° 1 20

Prueba N° 2 10

Prueba N° 3 15

Promedio 15,00000

Desvincular estandar 5,00000

Fuente: Adaptado de Humphrey

POLITÉCNICO GRANCOLOMBIANO 10
 En síntesis...
ZenHub: es una herramienta de gestión de proyectos bastante útil, siendo
la única de su tipo que se integra de forma nativa con la interfaz de usuario
de GitHub.

Seguimiento y control de procesos: son procesos asociados a las etapas

intermedias y finales del proyecto y, por consiguiente, son dependientes
del correcto registro, lo que implica que para su éxito debe existir un
trabajo disciplinado y constante.

En especial es importante realizar administración de defectos por dos

características: crecen en forma exponencial (the hidden factory) y se
repiten con regularidad (creamos fijaciones).

Logs de pruebas: los logs en PPS se generan en cada una de las fases del
proceso de pruebas (ver figura 4) y apoyan en una serie de formatos (ver
figuras 5 y 6, Tabla1).

POLITÉCNICO GRANCOLOMBIANO 11
Referencias bibliográficas
Firestine, B. (2017). Celebrating nine years of GitHub with an anniversary sale. Recuperado de GitHub :
https://github.com/blog/2345-celebrating-nine-years-of-github-with-an-anniversary-sale

@GitHub, Inc. (12 de 06 de 2017). GitHub. Recuperado de https://github.com/

Gousios, G., Vasilescu, B., Serebrenik, A. y Zaidman, A. (2017). Lean GHTorrent: GitHub Data on Demand.

Hughes, B. y Cotterell, M. (2006). Software Project Management. Berkshire, U. K.: McGraw Hill
Higher Education.

Humphrey, W. S. (1994). A Discipline for Software Engineering. Reading: Addison-Wesley.

Humphrey, W. S. (2002). Personal Software Process (PSP). En: J. Marciniak. (Ed.). Encyclopedia Of
Software Engineering, Volume 2 (948-961). Wiley.

MacGregor, D. G. (2001). Decomposition for Judgmental Forecasting and Estimation. En: J. S.

Armstrong (Ed.) Principles of Forecasting. (107-123). New York: Springer Science, Business Media.

Martínez, Y. (31 de 06 de 2009). Explican por qué el ser humano aprende más de sus aciertos que de sus
errores. Recuperado de http://www.tendencias21.net

PMI. (2004). A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Fifth Edition.
Newtown Square: Project Management Institute.

PSP(SM) / TSP(SM). (09 de 06 de 2017). The Software Process Dashboard Initiative The Software Process
Dashboard Initiative. Recuperado de http://www.processdash.com/download

Software Engineering Institute (SEI). (01 de 05 de 2017). Software Engineering Institute. Recuperado de
http://www.sei.cmu.edu/about/

Tennant, G. (2017). Six Sigma: SPC and TQM in Manufacturing and Services. London and New York: Routledge

W3C. (05 de 02 de 2017). Markup Validation Service. Recuperado de https://validator.w3.org/

Weaver, P. (21 de 06 de 2012). Henry L Gantt. A retrospective view of his work. Mosaic Project Services Pty
Ltd. Recuperado de https://mosaicprojects.com.au/Resources_Papers_158.html

zenhub. (2017). Agile project management within GitHub. Recuperado de https://www.zenhub.com/.

POLITÉCNICO GRANCOLOMBIANO 12
 INFORMACIÓN TÉCNICA

Módulo: Proceso de Software Personal PSP

Unidad 4: Niveles, seguimiento y control de PSP
Escenario 8: Administración de defectos, seguimiento
y control de procesos

Autor: Diego Iván Oliveros Acosta

Asesor Pedagógico: Jeiner Velandia

Diseñador Gráfico: Kelly Yohana Valencia Forero
Asistente: Laura Andrea Delgado Forero
Este material pertenece al Politécnico Grancolombiano. Por
ende, es de uso exclusivo de las Instituciones adscritas a la Red
Ilumno. Prohibida su reproducción total o parcial.

POLITÉCNICO GRANCOLOMBIANO 13