ANALISIS DE TIEMPOS RESPECTO A LA CONSTRUCCIÓN DE

SOFTWARE

Nicolás Alexander Ibarra Portilla1

a Ingeniería de Software I, Universidad Mariana, Calle 18 No. 34-104, San Juan de Pasto, Nariño-Colombia

Resumen
El objetivo principal de este artículo es saber interpretar la información obtenida respecto a la
estimación de tiempos en la construcción de software. Como resultado, se logró identificar la
necesidad de basarse en los tiempos realizados de cada historia de usuario en la gestión del proceso
de software y estar capacitado en la herramienta que se realizara el proceso de software. El trabajo
presenta la información e interpretación de los tiempos al desarrollar el software.

Palabras clave: Construcción de Software, Gestión del Proceso de Software, Proceso de

Software.

Abstract

The main objective of this article is to know how to interpret the information obtained regarding the estimation of
times in software development. As a result, it was possible to identify the need to be based on the timing of each user
story in software development and to be well trained in the tool that the software will be developed. The work presents
the information and interpretation of the times when developing the software.

Keywords: Software Development, Software Development Management, Software Process.

1. Introducción

La Ingeniería de Software es un campo que tiene pasos muy importantes dentro de ella que
siempre se dirigirán por gestiones elementales para la realización de un software. En la
construcción de software aparecerán dificultades para avanzar en el desarrollo del software como

1 Nombres y Apellidos. Estudiante de Ingeniería de Sistemas, Universidad Mariana (Pasto, Nariño, Colombia).
por ejemplo el no gestionar la construcción de un software, esto ocurre a la hora de no manejar
correctamente los diferentes grupos de procesos que abarca la gestión de proyectos en un software.
Los problemas que con más frecuencia se dan es el manejo del tiempo al momento de realizar
cada proceso siendo el tiempo planeado el más importante para una empresa ya que incluye costos
al no gestionar de manera correcta un proyecto.

La construcción de software es un proyecto que se realiza a través de ciertos procesos definidos

como, iniciación, ejecución, monitoreo y control, y cierre, se llevan acabo para que la planeación
de la construcción del software salga futuramente igual de cómo se planeó.

El proceso de software según Sommerville, I. (2005) se relaciona por varias actividades que
producen un software y cada una de estas actividades son llevadas a cabo por expertos que realizan
software. Las actividades son presentadas de la siguiente manera:

1. En la primera actividad se encuentran los ingenieros y clientes determinando cómo se

realizará el software.
2. En la segunda actividad los ingenieros comienzan a desarrollar, diseñar y programar el
software.
3. En la tercera actividad se verifica los requerimientos que necesita el cliente.
4. En la cuarta actividad al software se le realizan ajustes con cada cambio que el cliente y el
mercado requieran.

La gestión del proceso de software consiste en realizar los diferentes procesos que conlleva el
realizar la construcción de un software como mencionaba anteriormente cada proceso se define
como… gestionando cada uno de estos procesos de la manera en que la construcción del software
se pueda dar y realizar de la mejor manera.

Para conocer y desarrollar habilidades en la construcción de software, en el semestre A de 2018

para la materia Ingeniería de Software I, se planteó el caso de estudio basado en la problemática
para la administración de la cafetería de la Universidad. En este sentido, se recopiló y priorizó las
necesidades del cliente para plantear como parte de la solución una aplicación de escritorio que
incluya persistencia, mediante el desarrollo de 2 incrementos e iteraciones.

2. Metodología
 El trabajo se desarrolló mediante 2 incrementos e iteraciones. Cada Sprint tuvo un tiempo de
duración de 2 semanas de trabajo con una dedicación de 11 horas a la semana. En el primer Sprint,
se logró dar respuesta a 2 historias de usuario. En el segundo Sprint, se logró dar respuesta a 2
historias de usuario. Como parte del cierre del proyecto, se realizó un análisis del desempeño,
sirviendo como insumo para realizar una comparación de los resultados obtenidos en los 2 Sprints.

3. Resultados y discusión

A continuación, se presentan los resultados obtenidos en los Sprints 1 y 2; y el análisis

comparativo.

3.1. Resultados del primer incremento e iteración 1 sprint (2)

En la Tabla 1 se puede observar que en el primer Sprint se realizó 2 historias de usuario por la
complejidad definida como “ALTA” sin embargo no se logró ejecutar las pruebas de
funcionamiento como se puede ver en la Tabla 2.

Al realizar las historias de usuario como se puede observar en la Tabla 2 que es donde se
presenta el rendimiento del trabajo realizado en el proceso de los requerimientos del usuario, la
mayor complejidad en el proyecto se encuentra en el desarrollo de la codificación y del diseño de
la interfaz ya que al sumar los porcentajes del tiempo realizado de estos dos ítems se necesita más
del 60% del tiempo que se ha estimado por los ingenieros.

Tabla 1
Historias de usuario realizada por semana Historias de Usuario
Historias de Usuario FO %FO
Semana 1 0 0%
Semana 2 2 100%
Total 2 100%

Tabla 2

Tiempo de trabajo por actividad del done Tiempo planeado Tiempo Ejecutado
Actividad FO %FO FO %FO
 Especificar las HU (Historias de Usuario) 0,32 1% 0,32 1%
Elaborar el diagrama de clase del modelo del mundo 0,67 3% 0,67 3%
Elaborar prototipo de la Interfaz 1 4% 1 4%
Elaborar el diagrama de la interfaz 2 8% 2 8%
Realizar el código del mundo 6 23% 6 24%
Realizar el código de la interfaz 10 38% 10 40%
Implementar bases de datos 1,3 5% 1,3 5%
Realizar pruebas unitarias 2 8% 2 8%
Ejecutar pruebas unitarias 1 4% 0 0%
Resolver errores de software 2 8% 2 8%
TOTAL 26,29 100% 25,29 100%

Tabla 3

Tiempo de trabajo por semana

tiempo de Tiempo no % tiempo % Tiempo no
Semanas
trabajo trabajado trabajado trabajado
Semana 1 6,92633333 4,1 62,97% 37,03%
Semana 2 14 3 82,35% 17,65%
Total 20,9 7,1

En el trabajo de las dos historias realizadas se identificaron importantes resultados en cuanto al

tiempo que se ejecutó de lo antes planeado por el ingeniero. Como se puede observar y relacionar
la Tabla 3 y el Grafico 1, en la primer semana el tiempo trabajado en los requerimientos es de un
menor porcentaje que de la segunda semana pero se denota que en las dos semanas se ha trabajado
más del 50 % por lo que aporta de gran manera al proyecto en disminuir costos, y cabe recalcar
la comparación de la cantidad de horas trabajadas y no trabajadas es que demuestra que no supera
el 40% en cada semana respecto al tiempo perdido.
 Semana 1 Semana 2

82.35%
62.97%

37.03%

17.65%
% TIEMPO TRABAJADO % TIEMPO NO
TRABAJADO

Gráfica 1. Tiempo de trabajo por semana

3.2. Resultados del segundo incremento e iteración 2 sprint (3)

En este segundo sprint se realizaron 2 historias de usuario como se puede ver en la tabla 4. La
complejidad en estas historias es denominada como “MEDIA”. Siguiendo con la Tabla 5 se puede
observar con gran relevancia que al sumar los ítems de codificación del mundo y codificación de
interfaz haciendo referencia al diseño, se utilizó más del 70% del tiempo a comparación con los
demás ítems pero en relación con el tiempo planeado y el tiempo ejecutado se pudo realizar
acertadamente el mismo tiempo y hasta menos en el tiempo ejecutado.

A continuación se indica la forma de presentar los resultados de una tabla (Ver Tabla 2)

Tabla 4
Historias de usuario realizada por semana Sprint 3
Historias de Usuario FO %FO
Semana 1 0 0%
Semana 2 2 100%
Total 2 100%

Tabla 5

Tiempo de trabajo por actividad del done Sprint 2

Tiempo planeado Tiempo Ejecutado
 Actividad FO %FO FO %FO
Especificar las HU (Historias de Usuario) 0,16666667 1% 0,16666667 1%
Elaborar el diagrama de clase del modelo del mundo 0,22 2% 0,22 2%
Elaborar prototipo de la Interfaz 0,22 2% 0,22 2%
Elaborar el diagrama de la interfaz 1 8% 1 9%
Realizar el código del mundo 4 31% 4 36%
Realizar el código de la interfaz 4 31% 4 36%
Realizar pruebas unitarias 1 8% 1 9%
Ejecutar pruebas unitarias 2 16% 0,5 4%
Resolver errores de software 0,1 1% 0,1 1%
TOTAL 12,7066667 100% 11,2066667 100%

Siguiendo con la tabla 6 y el gráfico 2 la información obtenida representa qué, la semana 1

denominada en el grafico 2 como “1”, el tiempo ejecutado fue menor al tiempo de la semana 2
representando la semana 2 como la mejor trabajada por su balanceo en los porcentajes que se
presentan en el gráfico 2.

Tabla 6

Tiempo de trabajo pro semana Sprint 2

%
Tiempo % Tiempo
Tiempo de no Tiempo no
Semanas trabajo trabajado trabajado trabajado
Semana 1 4,8 6,18 44% 56%
Semana 2 5,5 5,5 50% 50%
Total 10,3233333

60% 56%
50% 50%
50% 44%
40%
30%
20%
10%
0%
1 2

% Tiempo trabajado % Tiempo no trabajado

Gráfica 2. Tiempo de trabajo por semana

 3.3. Análisis comparativo

En la información obtenida se rescataron varios aspectos de mejora y desmejora que se

comparan entre el sprint 1 y el sprint 2.

Tomando la información de los gráficos 3 y 4 se pueden ver las mejoras al proyectar los
porcentajes del tiempo trabajado y el no trabajado ya que en comparación del sprint 1 y el 2, en el
sprint 1 se necesitó más del tiempo estimado por lo que se identificó mejoras en el sprint 2
representando un porcentaje más estable que del sprint 1.

Por otra parte se reconoce que en los dos Sprints realizados no se ejecuta el tiempo de la manera
correcta ya que del tiempo no trabajado hay un alto porcentaje que emerge por no aprovechar el
tiempo establecido de cada semana.

SPRINT 1
% Tiempo trabajado % Tiempo no trabajado
127%
63%

37%

1 2
-27%

Gráfica 3. Tiempo de trabajo por semana sprint 1

 SPRINT 2
% Tiempo trabajado % Tiempo no trabajado

56%

50%

50%
44%

1 2

Gráfica 4. Tiempo de trabajo por semana sprint 2

4. Conclusiones

Conclusión 1. El tiempo estimado para realizar cada ítem de cada historia de usuario fue menor al
planeado y eso no permitió completar cada historia de usuario.

Conclusión 2. Se concluye que es necesario verificar la complejidad de las historias de usuario

y así estimar de la manera en que se ocupe todo el tiempo establecido en cada semana.

Conclusión 3. Se concluye que la estimación es un factor fundamental para evitar sobre costos
cuando se desarrolla software.

5. Recomendaciones

En el primer sprint se necesitó más del tiempo planeado, por esta razón, se recomienda que
cada vez que se termina un sprint se deba revisar las horas que utiliza cada historia de usuario para
escoger y estimar correctamente las siguientes historias de usuarios y Sprints.

Por otro lado al desarrollar software se recomienda utilizar herramientas de codificación que le
permitan mejorar el rendimiento a la hora de codificar como Papyrus ya que esta herramienta
utiliza extensiones que le permiten generar código a través del modelo por medio de la extensión
conde reverse.
Referencias

1. Sommerville, I. (2005). Ingeniería del software. Madrid: Pearson Educación.