• Author / Uploaded
• Jhojan Cordoba

Citation preview

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 Semana 1 Semana 2 Total

Historias de Usuario FO %FO 0 0% 2 100% 2 100%

Tabla 2 Tiempo de trabajo por actividad del done Actividad

Tiempo planeado FO %FO

Tiempo Ejecutado FO %FO

0,32 0,67 1

1% 3% 4%

0,32 0,67 1

1% 3% 4%

Elaborar el diagrama de la interfaz

2

8%

2

8%

Realizar el código del mundo

6

23%

6

24%

10 1,3

38% 5%

10 1,3

40% 5%

2 1 2 26,29

8% 4% 8% 100%

2 0 2 25,29

8% 0% 8% 100%

Especificar las HU (Historias de Usuario) Elaborar el diagrama de clase del modelo del mundo Elaborar prototipo de la Interfaz

Realizar el código de la interfaz Implementar bases de datos Realizar pruebas unitarias Ejecutar pruebas unitarias Resolver errores de software TOTAL

Tabla 3 Tiempo de trabajo por semana Semanas Semana 1 Semana 2 Total

tiempo de Tiempo no % tiempo % Tiempo no trabajo trabajado trabajado trabajado 6,92633333 4,1 62,97% 37,03% 14 3 82,35% 17,65% 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.

% TIEMPO TRABAJADO

17.65%

Semana 2

37.03%

82.35%

62.97%

Semana 1

% 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 Historias de Usuario Semana 1 Semana 2 Total

Sprint 3 %FO

FO 0 2 2

0% 100% 100%

Tabla 5 Tiempo de trabajo por actividad del done

Sprint 2 Tiempo planeado Tiempo Ejecutado

Actividad Especificar las HU (Historias de Usuario) Elaborar el diagrama de clase del modelo del mundo Elaborar prototipo de la Interfaz Elaborar el diagrama de la interfaz Realizar el código del mundo Realizar el código de la interfaz Realizar pruebas unitarias Ejecutar pruebas unitarias Resolver errores de software TOTAL

FO %FO FO %FO 0,16666667 1% 0,16666667 1% 0,22 2% 0,22 2% 0,22 2% 0,22 2% 1 8% 1 9% 4 31% 4 36% 4 31% 4 36% 1 8% 1 9% 2 16% 0,5 4% 0,1 1% 0,1 1% 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

Semanas

% Tiempo % Tiempo Tiempo de no Tiempo no trabajo trabajado trabajado trabajado 4,8 6,18 44% 56% 5,5 5,5 50% 50% 10,3233333

Semana 1 Semana 2 Total

56%

60% 50%

50%

50%

44%

40% 30% 20%

10% 0% 1 % Tiempo trabajado

2 % 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 no trabajado

37%

63%

127%

% Tiempo trabajado

2 -27%

1

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

SPRINT 2

1

50%

% Tiempo no trabajado 50%

44%

56%

% Tiempo trabajado

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.