S.E.P. S.E.S.T. D.G.E.S.T. - CENIDET - Centro …...3.8 Desarrollo del módulo de estimación de tiempo 46 3.9 Descripción de la herramienta 47 3.10 Búsqueda en la base de datos

S.E.P. S.E.S.T. D.G.E.S.T.

Centro Nacional de Investigación y Desarrollo Tecnológico

cenidet

Ambiente Visual para la Integración de la Planeación de Proyectos de Software y la

Definición de Requerimientos para la suite cenidet-UML

TESIS

Que para Obtener el Grado de:

MAESTRO EN CIENCIAS EN CIENCIAS DE LA COMPUTACIÓN

Presenta:

I.S.C. Paula Araceli Aguilar Alcalá

Director de Tesis: Dr. Máximo López Sánchez

Codirector de Tesis:

M.C. Eurí Salgado Escobar

Cuernavaca, Morelos Septiembre del 2005

TABLA DE CONTENIDO Tabla de contenido iListado de Figuras iiiListado de Tablas v Introducción 1 Capítulo 1. ANTECEDENTES 31.1 Introducción 41.2 Contexto de la investigación 41.3 Trabajos relacionados 6 1.3.1 Herramientas comerciales 61.4 Objetivos 9 1.4.2 Objetivo general 9 1.4.2 Objetivos particulares 101.5 Planteamiento del Problema 101.6 Problemas Técnicos 111.7 Hipótesis 121.8. Beneficios Esperados 121.9. Justificación 121.10. Límites y Alcance del Estudio 13 1.10.1 Los alcances del proyecto 13 1.10.2 Las limitaciones del proyecto 131.11 Metodología de Solución 131.12 Referencias 15 Capítulo 2. MARCO TEÓRICO

16

2.1 Administración de proyectos 17 2.1.1 Plan de Proyecto 172.2 Regresión lineal 192.3 Modelado Orientado a Objetos 212.4 Lenguajes Visuales 232.5 Gramáticas para la especificación de lenguajes visuales 232.6 Referencias 26 Capítulo 3. DESARROLLO DEL SISTEMA 273.1 Vista conceptual de SPYDER 283.2 Análisis de SPYDER 293.3 Diseño Detallado de SPYDER 313.4 Diagrama de clases de SPYDER 35 3.4.1 Definición de clases utilizadas 353.5 Gramática utilizada 423.5.1 Gramática Visual 423.6 Reportes 433.7 Diseño de las estructuras necesarias a utilizar y sus métodos de almacenamiento de la información

44

i

3.8 Desarrollo del módulo de estimación de tiempo 463.9 Descripción de la herramienta 473.10 Búsqueda en la base de datos se hace por medio del siguiente código 51 Capítulo 4. CASOS DE PRUEBA 534.1.-Desarrollo de Casos de Pruebas para aplicar a PLANPRO 544.2 Caso de Prueba 1: Insertar Fechas 544.3 Caso de Prueba 2: Insertar Fecha Inicio-Inicio 554.4 Caso de Prueba 3: Insertar Precedencia 574.5 Caso de Prueba 4: Insertar Precedencia Inicio Fecha 604.6 Caso de Prueba 5: Insertar Precedencia Fin_Fin 624.7 Caso de Prueba 6: Agregar Recursos Humanos 644.8 Caso de Prueba 7: Consulta BD 654.9 Caso de Prueba 8: Regresión Lineal 694.10 Caso de Prueba 9: Captura Tiempo Real 714.11 Caso de Prueba 10: Graficas comparativas 75 Capítulo 5. CONCLUSIONES Y TRABAJO FUTURO 785.1 Conclusiones 795.2 Trabajos Futuros 81 Anexo A 82Anexo B 87

ii

LISTADO DE FIGURAS Figura 1.1 Arquitectura de la suite cenidet-UML 5Figura 1.2 Representación de la metodología de solución 13Figura 1.3 Diagrama de actividades de la metodología de solución 14Figura 2.1 El Proceso de la Calendarización 17Figura 2.2 Ejemplo de una gráfica de Gantt 19Figura 2.3 Operaciones mensuales en una empresa de Transporte de Pasajeros

21

Figura 3.1 Vista Conceptual de SPYDER 29Figura 3.2 Diagrama de Caso de uso principal 29Figura 3.3 Diagrama de CU de estimación de tiempo con regresión lineal 30Figura 3.4 Diagrama de Secuencias General de SPYDER 32Figura 3.5 Diagrama de Secuencias de Calculo de duración 32Figura 3.6 Diagrama de Actividad del Inicio del Sistema 33Figura 3.7 Diagrama de Actividad de Captura de Actividades 34Figura 3.8 Diagrama de Actividad de Cálculo de Tiempo 34Figura 3.9 Diagrama de clases de SPYDER 36Figura 3.10 Interfaz de Reporte para actividades con fecha de inicio, fecha final y duración

44

Figura. 3.11 Apariencia de un archivo “.pro” 45Figura 3.12 Pantalla de registro de los datos del proyecto 47Figura 3.13 Pantalla principal de SPYDER 48Figura 3.14 Pantalla de asignación de recursos humanos a una actividad 48Figura 3.15 Gráfica de regresión 49Figura 3.16 Diálogo para abrir un archivo con extensión pro 50Figura 3.17 Pantalla que muestra los datos de un proyecto existente 50Figura 4.1 Muestra el error cuando se omite la fecha de inicio a la actividad 55Figura 4.2 Muestra que el día elegido es inhábil 56Figura 4.3 Pantalla de error “día no permitido” 57Figura 4.4 Agregar precedencias a una actividad 59Figura 4.5 Modifica las fechas de las Actividades después de haber agregado Precedencias

59

Figura 4.6. Muestra la relación de las actividades en Gantt 60Figura 4.7 Elección de tipo de precedencia 61Figura 4.8 Pantalla que muestra el cambio de la fecha de inicio de la actividad

62

Figura 4.9. Muestra el cambio de fechas al agregar las precedencias 63Figura 4.10 Muestra las precedencias de cada actividad 63Figura 4.11 Muestra las precedencias de cada actividad en Gantt 64Figura 4.12 Muestra que la BD está vacía, no existen Recursos Humanos 65Figura 4.13 Pantalla de captura de recursos humanos con la BD vacía- 65Figura 4.14 Selección de un recurso humano 67Figura 4.15 Muestra el tiempo necesario para que el recurso humano realice la actividad

67

Figura 4.16 Gráfica de Regresión 68Figura 4.17 Recurso Humano asignado a la actividad. 68

iii

Figura 4.18 Recurso Humano asignado 70Figura 4.19 Regresión lineal con recursos humanos diferentes al Seleccionado

70

Figura 4.20 Diálogo que muestra las actividades del proyecto 72Figura 4.21 Captura del tiempo real 72Figura 4.22 Muestra parte de la pantalla de captura con el tiempo real Asignado

72

Figura 4.23 Gráfica de Gantt con el tiempo estimado y el real. 73Figura 4.24 SPYDER agrega la información a la base de datos 73Figura 4.25 Comparativo de tiempo de todas las actividades 74Figura 4.26 Comparativo de tiempos del proyecto total 74Figura 6.1 Pantalla de captura del Plan de Proyecto para el Proyecto81 82Figura 6.2 Pantalla del comparativo del tiempo real y manual por actividades del Proyecto81

82

Figura 6.3 Pantalla del comparativo del tiempo real y manual del tiempo total del Proyecto81

83

Figura 6.4 Pantalla de captura del Plan de Proyecto para el Proyecto84 83Figura 6.5 Pantalla del comparativo del tiempo real y manual por actividades del Proyecto84

84


84

Figura 6.7 Pantalla de captura del Plan de Proyecto para el Proyecto87 85Figura 6.8 Pantalla del comparativo del tiempo real y manual por actividades Del Proyecto87

85


86

iv

LISTADO DE TABLAS Tabla. 1 Tabla comparativa 9Tabla 4.1 Información resultante almacenada en la BD al aplicar las pruebas a SPYDER

75

Tabla 4.2 Porcentajes de concordancia en los proyectos por actividad 76Tabla 4.3 Porcentajes de concordancia en los proyectos por tiempo total del Proyecto

77

v

CAPÍTULO 1. ANTECEDENTES __________________________________________________________________________________

3

CCAAPPÍÍTTUULLOO

AANNTTEECCEEDDEENNTTEESS

En este capítulo se describen aspectos como: Introducción a la investigación, los trabajos relacionados; se describe el problema de la falta de una estimación de tiempo para realizar las actividades de la planeación del proyecto basada en datos históricos, los objetivos de la tesis, las hipótesis, los problemas técnicos, los beneficios esperados, la justificación, los límites, alcances del estudio.


4

1.1 Introducción El propósito principal de la planeación de un sistema de software es permitirle al ingeniero de software realizar un plan de proyecto para estimar el esfuerzo y la duración en tiempo de desarrollo del proyecto a realizar, de manera que pueda tener más claros los objetivos, necesidades y restricciones del software a desarrollar [PROY01].

El desarrollo de productos de software implica además de escribir bloques de código y

ejecutarlos en una computadora, cumplir con los requisitos del cliente a un costo y con una planificación acordada.

Humprey en su libro PSP [HUMP01] menciona que eran pocas las organizaciones de

software que habían satisfecho de forma confiable los compromisos de planificación y costos, menciona un ejemplo de una compañía con problemas es IBM, en donde se observó que debido a los compromisos en cuanto a la entrega del proyecto a tiempo no llega a cumplirse, causa serios problemas en los negocios como: negocios fracasados, disputas de contratos, molestias entre los clientes, etc.

Lo anterior motivó a los directivos de las compañías que menciona Humphey en su

libro, para que analizaran los proyectos principales, dándose cuenta que no había planes documentados, por lo que se dieron a la tarea de realizar los planes de cada proyecto y así poder establecer programaciones realistas. Con sus nuevos planes se mejoraron las fechas de entrega, lo que los motivó a seguir planeando su trabajo [HUMP01]. Después de años de malas experiencias, muchos ingenieros de software han aprendido que para hacer un trabajo efectivo necesitan [HUMP01]: Planificar su trabajo Hacer su trabajo de acuerdo al plan Esforzarse para producir productos de máxima calidad.

A partir de lo anterior descrito, se concluye que es importante realizar planes para proyectos de software documentados, motivo por el cual se plantea la necesidad de hacer hincapié en esta actividad que se definirá a más detalle en el siguiente punto. 1.2. Contexto de la investigación. El presente trabajo de investigación forma parte de un proyecto más extenso que está siendo desarrollado en el Centro Nacional de Investigación y Desarrollo Tecnológico (cenidet), el cuál es denominado Suite cenidet-UML (SCUML), el cual tiene como finalidad facilitar la tarea de desarrollar software. Este ambiente trabaja bajo la metodología UML, y con este, es posible modelar y diseñar un sistema mediante el enfoque orientado a objetos, de tal forma que se puedan crear diferentes diagramas y especificaciones, los cuales pueden interactuar entre sí.


5

La Figura 1.1 muestra la arquitectura de SCUML y está formada por los siguientes módulos: Diagramas de Estados (KE2), Diagramas de Casos de Uso (SADUC), Plan de Proyectos de software (SPYDER), SOODA, Diseño Detallado de Warnier (DDVi) , Diagramas de Secuencias (S3C), Inverjava, Diagramas de Paquetes (Ppkg) y Diagramas de Actividades.

Diagramas de Estados

Ke2

Diagramas de Casos de Uso

SADUC

Diagramas de Clases SOODA

Diagramas de Paquetes

Ppkg

Ing. inversa de Código Java

Inverjava

Diseño detallado

de métodos DDVi

Diagramas de Secuencias

SC3

Ing. Inversa a diagramas

de secuencias

PendienteTerminado Trabajo Realizado

Plan de Proyecto de Software

SPYDER

Suite CENIDET-UML (SCUML)

Figura 1.1 Arquitectura de la suite cenidet-UML.

Como se puede observar en la Figura 1.1, la SCUML incorpora la herramienta denominada SOODA, cuya función es la realización de diagramas de clase basados en UML, y que además se encuentra conectada con una herramienta Diseño Detallado de métodos (DDVi), que es una herramienta que funciona de manera visual y permite modelar el diseño detallado de los métodos de las clases de un sistema OO, utilizando la notación de diseño detallado de Warnier.

Diagramas de Secuencias (S3C). Se enfoca hacia el modelado de las interacciones

entre objetos de un proyecto de software bajo desarrollo. Mediante diagramas de secuencias definidos por el Lenguaje de Modelado Unificado (UML). La obtención de los diagramas de secuencias esta basada en diagramas de clases construidos con la herramienta SOODA junto con el diseño detallado de los métodos definidos con la herramienta DDVi.

Diagramas de Casos de Uso (SADUC). Este módulo permite modelar los

requerimientos de un sistema de software a través de los diagramas de casos de uso propuestos por el Lenguaje de Modelado Unificado (UML); y a la vez esta herramienta facilitará al usuario la obtención del documento de requisitos y del documento de casos de pruebas del sistema, de tal forma que los requisitos del sistema estarán expresados de forma textual y


6

gráfica. Cuando se enuncian los requisitos de un sistema se está estableciendo un comportamiento entre los elementos externos al sistema y el propio sistema, el cual establece lo que se espera que haga el sistema. Aunque con total seguridad, la comprensión de los requisitos evolucionará conforme se vaya implementado el sistema de manera iterativa e incremental.

Diagramas de Estados (KE2). En este módulo se realiza el modelado de la transición

de estados de los objetos de un proyecto en desarrollo y permite describir el comportamiento de los objetos del sistema modelado.

Ingeniería Inversa de Código Java (Inverjava). Es una herramienta que permite la

recuperación del diseño de clases y el diseño detallado de los métodos de las clases a partir de código fuente escrito en lenguaje Java.

El diagrama de clases obtenido podrá ser visualizado y manipulado (agregación y

eliminación de métodos y atributos de las clases, agregar nuevas clases y relaciones entre ellas) desde el ambiente de modelado visual SOODA. Utilizando InverDDVi se mostrará el diseño detallado de los métodos de las clases del código fuente escrito en Java mediante diagramas de Warnier.

Con el propósito de complementar la suite cenidet-UML, se integra el módulo SPYDER

marcado con doble línea en la Figura 1.1, con el cual se pretende atender la fase de planeación de proyectos de software.

1.3. Trabajos relacionados Enseguida se describen las herramientas comerciales diseñadas con el propósito de realizar un plan de proyecto y que fueron objeto de estudio para el desarrollo del presente proyecto. 1.3.1 Herramientas comerciales Actualmente existe una diversidad de herramientas que permiten realizar un plan de proyecto, cada una de ellas es descrita en las siguientes páginas. Herramientas que realizan el plan de proyectos de software MsProject 2000 Microsoft Project 2000 es una potente y flexible herramienta diseñada para ayudar a gestionar una gama completa de proyectos. Se puede programar y hacer un seguimiento cercano a todas las tareas.


7

Características:

Calcula la fecha de inicio y fin del proyecto, fechas de finalización óptima, también identifica las actividades claves para el desarrollo del proyecto en las fechas previstas, calcula y sintetiza los costos, realiza las gráficas de Gantt y Pert. Sus reportes son compatible con aplicaciones Microsoft, se pueden capturar los recursos y asignarlos a las actividades [MSPR04]

Desventajas:

De acuerdo al estudio realizado a esta herramienta, se determina que no cuenta con la capacidad de realizar estimaciones de tiempo basadas en datos históricos de proyectos de tamaño similar que hubieran sido desarrollados con anterioridad.

PlanBee Es una herramienta fácil de utilizar, muestra una gran cantidad de información en su ventana principal y fue creado para realizar un proyecto controlando las fechas del mismo. Características:

Calcula la fecha de inicio y fin del proyecto, fechas de finalización óptima y tardía, identifica las actividades claves para el desarrollo del proyecto en las fechas previstas, además de que permite calcular y sintetizar los costos, muestra los datos del proyecto en una hoja de cálculo para su fácil entendimiento, dispone de dos vistas más para ver cualquier aspecto del proyecto (Pert y Gantt) y soporta más de mil actividades [PLAN04].

Desventajas:

Plan Bee, tiene una pantalla muy saturada de información así como de no poder asignar precedencias a las actividades y otra desventaja muy importante es que no cuenta con la capacidad de realizar estimaciones de tiempo basadas en datos históricos de proyectos de tamaño similar, que hubieran sido desarrollados con anterioridad.

Visio 2002 Fue diseñado pensando en la administración de aplicaciones y desarrollos propios administrativos de redes, analistas y diseñadores de bases de datos, diseñadores de Internet/Intranet, ingenieros de procesos de negocios y desarrolladores de software, en suma, para administrar aplicaciones complejas de tecnologías de información por medio de diagramas. Características:

Se utiliza para crear esquemas organizacionales (organigramas), permite modelar con todos los diagramas de UML, permite la asignación de actividades de un plan de proyecto y la generación automática de las gráficas de Pert y Gantt, es compatible con aplicaciones Microsoft [VISIO04]


8

Desventajas: No permite asignar precedencias entre actividades, es lento cuando se requiere definir un plan de proyecto grande, no permite asignar recursos así mismo no cuenta con la capacidad de realizar estimaciones de tiempo basadas en datos históricos de proyectos de tamaño similar, que hubieran sido desarrollados con anterioridad.

Project KickStart Es una herramienta poderosa y fácil de usar que ayuda a diseñar, organizar y programar cualquier proyecto Características:

Se puede utilizar en proyectos de cualquier tamaño - hasta 1000 tareas y 100 recursos, se puede iniciar con ejemplos de proyectos- que ya contienen información y están listos para utilizarse, permite visualizar las actividades por medio de la gráfica de Gantt, permite realizar siete tipos de informes preestablecidos, se puede archivar como HTML, permite enlazarse con algunas herramientas de Microsoft como Word, Excel, Project, etc. [KICK04]

Desventajas: No permite asignar precedencias entre actividades ni asignar recursos, así no cuenta con la capacidad de realizar estimaciones de tiempo basadas en datos históricos de proyectos de tamaño similar, que hubieran sido desarrollados con anterioridad.

Las herramientas de planificación de proyectos existentes en el mercado que no se

basan en un proceso como PSP o TSP como Project, sólo permiten realizar planes de proyecto y visualizarlos en una gráfica de Gantt. Dashboard

Dashboard es una herramienta que está basada en PSP creada para facilitar el trabajo de registro de información y de estimaciones, realizando de manera rápida, fácil y con exactitud los procesos.

Ventajas:

Realiza estimaciones basadas en registros históricos Permite realizar planes de proyectos de un recurso humano

Desventajas: No permite realizar un plan de proyecto en el cual estén involucradas varias personas, por lo tanto, sólo permite realizar estimaciones individuales, no cuenta con la capacidad de realizar una gráfica de Gantt, no permite utilizar precedencias entre actividades.


9

En la tabla comparativa No. 1 se puede notar que las herramientas analizadas poseen características importantes, tales como: la gráfica de Gantt; la que permite visualizar de una mejor forma las actividades y las fechas en que se deben realizar éstas, y así poder controlar el avance del proyecto; también utilizan la asignación de recursos y en el caso de Project, permite visualizar o establecer las precedencias que son muy importantes porque permiten observar en forma gráfica las actividades que dependen de otras y así organizar al personal que trabaja en cada actividad de manera independiente, pero también se observa que ninguna de las herramientas proporciona al usuario una estimación de manera automática del tiempo necesario para realizar una actividad, además de que no llevan un registro histórico en tiempo real de las actividades realizadas en proyectos anteriores, Dashboard permite realizar estimaciones, pero no utiliza precedencias ni visualiza sus actividades en una gráfica de Gantt. La herramienta desarrollada en esta tesis denominada SPYDER, si permite realizar estimaciones de tiempo basadas en datos históricos además de utilizar precedencias y una gráfica de Gantt para visualizar las actividades.

Tabla No. 1 Tabla comparativa

Herramientas Gráfica de Gantt

Asignación de precedencias

Captura de actividades

Asignación de recursos

Estimación automática del tiempo de las actividades

Utilización de un registro histórico de información

Conduce la planificación y actividades del ciclo de vida del software

Plan Bee √ / √ √ / / / Kick star √ / √ √ / / /

Microsoft Project

√ √ √ √ / / √

VISIO 2002

√ / √ / / / /

SPYDER √ √ √ √ √ √ √

Dashboard / / √ √ √ √ √

1.4 Objetivos 1.4.1 Objetivo general Agregar al Ambiente Integrado de Soporte de Desarrollo de los planes de Sistemas de Software “Suite Cenidet UML” una herramienta visual que permita definir la planeación de proyectos de software con apoyo de una base de datos que contenga un registro histórico de datos de proyectos anteriores y con esos datos, permita estimar el tiempo de desarrollo de las actividades del plan de un nuevo proyecto con el fin de darle seguimiento y generar el documento de planeación, ajustándose al ambiente integrado suite cenidet-UML.


10

1.4.2 Objetivos particulares Desarrollar una herramienta prototipo que permita al usuario:

-Realizar la planeación de proyectos de software en la cual se puedan especificar las actividades con fecha de inicio y fecha de terminación de cada actividad. -Diseñar un módulo de estimación de la duración de actividades por medio del cálculo de regresión lineal utilizando una base de datos históricos. - Crear una gráfica de regresión lineal que muestre el valor calculado y la información de la base de datos que se utiliza para la realización de la estimación de tiempo para cada actividad. -Generar una gráfica de Gantt por proyecto una vez que han sido capturadas las actividades. -Generar un reporte de actividades del Plan de Proyecto.

1.5 Planteamiento del Problema

El administrador de proyectos es el actor encargado de realizar los planes de proyectos

de software. Estos planes presentan los siguientes problemas:

1. En las herramientas analizadas se observa que no permiten estimar de manera automática la duración de las actividades del plan de proyecto de software, por lo que el administrador debe confiar en su memoria y en la de sus colaboradores para estimar la duración de las actividades de un proyecto a lo que podríamos llamar dependencia de personal.

2. Se produce un retrabajo al realizar los cálculos manuales para estimar la duración de

las actividades.

3. El no tener un registro de tiempos reales y actividades no comunes que surgieron durante el desarrollo del trabajo, hace que al estimar el tiempo necesario para concluir el proyecto confiando en la memoria, no sea el mejor, debido a olvidos de las actividades no comunes.

Considerando los problemas anteriormente mencionados, el propósito de ésta tesis es

proporcionarle al Administrador de proyectos (usuario) una herramienta que le permita realizar un plan de proyecto que incluya:

Una estimación automática del tiempo necesario para desarrollar una actividad utilizando un registro histórico de proyectos anteriores.


11

Permitir actualizar el registro histórico una vez que se haya terminado el proyecto en desarrollo.

Ingresar el avance real de cada actividad terminada del plan de un proyecto de software.

Visualizar en la gráfica de Gantt tanto el avance estimado como el avance real del proyecto.

Visualizar en una gráfica el comparativo del tiempo real del proyecto y el estimado por SPYDER.

1.6 Problemas Técnicos Los problemas que se presentaron en el desarrollo del trabajo son:

1. Desarrollar una gramática visual para representar las actividades de un sistema de software. En este caso fue necesario desarrollar una gramática visual para poder establecer la construcción de una gráfica de Gantt. Debido a que las actividades pueden iniciar en paralelo a una actividad o al terminar una actividad anterior, etc. y su actualización puede afectar a otras y esto se define por medio de reglas.

2. Integrar el mecanismo que permita actualizar la base de datos real una vez

concluidas las actividades del proyecto. Una vez que se concluyo el proyecto o parte de él, se procede a capturar el tiempo real y es cuando hay que guardar la información en la Base de Datos, información como la actividad realizada, recurso(s) humano(s) que la realizaron, tiempo en días que necesitaron para concluir la actividad, nombre del proyecto, Tipo de Proyecto.

3. Diseñar las estructuras para modificar, borrar y consultar las actividades y sus

recursos. Para realizar las operaciones de borrar, modificar, eliminar las actividades una vez capturadas, fue necesario establecer las estructuras para poder hacer más fácil su manejo y, que cada operación que se realice con ellas actualice de manera automática todas las demás actividades en caso de ser necesario en lo que se refiere a las precedencias, fechas y hacerlo tanto en la pantalla de captura como en la gráfica de Gantt..

4. Establecer el formato de almacenamiento en disco que permita recuperar y

explotar la información procesada. Una vez que ya se capturó el plan de proyecto, es muy importante tener un formato de almacenamiento de la información, que se determinó fuera un archivo. También se desarrolló un algoritmo que pudiera recuperar la información del archivo y estructurar el documento de actividades.

5. Diseñar una base de datos y el módulo de regresión lineal que la utilizará. Fue necesario establecer los datos necesarios que debería de contener la tabla recurs de la base de datos de cada actividad del plan de proyecto y con base en estos datos, el


12

módulo que realiza la regresión los utilice para estimar automáticamente la duración de las actividades, mostrando además el tiempo estimado y la gráfica de regresión.

1.7 Hipótesis Utilizando una BD que contenga información histórica de las actividades de los proyectos realizados anteriormente, se pueda llevar a cabo la planeación de un nuevo proyecto estimando automáticamente el tiempo para cada actividad.

1.8. Beneficios Esperados

• Contar con una herramienta que estime automáticamente la duración de un plan de

proyecto por medio del método de regresión lineal.

• Dar seguimiento y continuidad en el proceso de desarrollo del software, de tal forma que la información generada durante la etapa de planeación pueda ser utilizada en las siguientes etapas.

• Contribuir en el desarrollo del proyecto Suite cenidet-UML.

• Contar con una herramienta didáctica para la planeación de proyectos de software

que pueda ser utilizada por los estudiantes del sistema de institutos tecnológicos, en la cual puedan aplicar los conocimientos adquiridos en materias como Planeación de Proyectos de Software e Ingeniería de Software.

1.9. Justificación

La mayoría de las herramientas de planeación de proyectos existentes en el mercado y de software libre no utilizan un histórico de datos de proyectos anteriores, por lo que la asignación de tiempo en las actividades la realizan a juicio del administrador de proyectos confiando en su memoria y experiencia y en la de sus colaboradores. Pero si existen otras herramientas como Kanav y Dashboard que si utilizan un histórico de datos de proyectos anteriores para realizar la estimación de tiempo.

Algunas herramientas del mercado como Project y Visio 2000 que son herramientas

para planificación de proyectos sólo realizan planes de proyectos que incluyen las actividades con las gráficas o calendario, en el cual sólo se esquematizan cada una de ellas. Si se pudieran planear las actividades y que además se pudiera realizar la estimación automática de la duración de cada actividad, se tornaría interesante y sería por lo tanto más utilizada debido a que por medio de la gráfica de Gantt se observaría el tiempo real y el tiempo estimado para un proyecto de software.

Por lo que se resalta que es muy interesante contar con una herramienta que además de

CAPÍTULO 1. ANTECEDENTES __________________________________________________________________________________ permitir realizar un plan de proyecto, realice estimaciones de tiempo para las actividades.

La herramienta desarrollada en este trabajo de tesis permite apoyar a la persona que

hace la planeación de proyectos, determinando automáticamente el tiempo que se llevará una actividad de acuerdo al recurso asignado, teniendo como apoyo una base de datos históricos y utilizando el método de regresión lineal. 1.10. Límites y Alcances del Estudio 1.10.1 Los alcances del presente proyecto son:

1. Se diseñó la arquitectura de la herramienta. 2. Se cuenta con una interfaz gráfica desarrollada en Visual C++. 3. Se creó un módulo del plan de proyecto. 4. Se cuenta con un módulo que genera automáticamente la gráfica de Gantt. 5. Se desarrollaron acciones como :

1. Almacenamiento 2. Recuperación 3. Impresión

6. Se definió el formato de la gráfica de regresión. 7. Se definió la base de datos para estimar la duración de actividades. 8. Se desarrolló el módulo de regresión lineal que utiliza la base de conocimiento. 9. Se cuenta con gráficas para realizar un análisis comparativo de resultados.

1.10.2 Las limitaciones del proyecto son: 1. No trabaja en un ambiente de red o multiusuario. 2. No realiza la estimación por otro tipo de regresión que no sea lineal.

1.11 Metodología de Solución ENTRADA PROCESO SALIDA Captura de actividades

Regresión Lineal Gráfica de Gantt Captura de Tiempo Real.a la BD

Nombre de la actividad Fecha de inicio Nombre del Rec. Hum. Precedencias Tipo de Proyecto Lenguaje de Prog. Tipo de Programa LOC o num. De unidades realiazadas de cada actividad

Figura 1.2 Representación de la Metodología de solució

Nombre de la actividad Fecha de inicio Nombre del Rec. Hum. Precedencias Tipo de Proyecto Lenguaje de Prog. Tipo de Programa LOC o num. De unidades realiazadas de cada actividad

13

n


14

Creacion de la clase CGrid

Creación de la clase AsignacionRH

Creacion de la clase AsignaciónRM

Creación de la clase CGráficaRegresiónLineal

Creación de la clase CapturaTiempoReal

Figura 1.3 Diagrama de actividades de la Metodología de solución.


15

1.12 Referencias. [HUMP01] HUMPHREY WATTS. S. Introducción al Proceso de Software

-Personal (PSP) Addison Wesley, 2001. [KICK04] http://www.projectkickstart.com/html/pkswin3.htm última consulta 16

Nov. 2004. [MSPR04] http://www.monografias.com/trabajos/msproyect4/ msproyect4.shtml

última consulta 16 Nov. 2004 [PLAN04] http://www.guysoftware.com/planbee.htm última consulta 17-Nov-

2004-11-17 [PROY01] http://www.itcdguzman.edu.mx/ingsoft/objetivo.htm última consulta

Nov. 2004. [SOMM02] SOMMERVILLE IAN, Ingeniería de Software, Addisson Wesley,

sexta edición 2002 [VISIO04] www.angelfire.com/music5/visio2002/visio.htm última consulta 16-

Nov. 2004

CCAAPPÍÍTTUULLOO

MARCO TEÓRICO En este capítulo se explican los temas relacionados con el desarrollo de esta tesis como son: el concepto de plan de proyectos, la importancia de la administración de proyectos, el papel de la regresión lineal en el plan de proyectos, el uso de lenguajes visuales, las gramáticas, la utilización de una base de datos y la interfaz de usuario.

CAPÍTULO 2. MARCO TEÓRICO ____________________________________________________________________________

2.1 Administración de proyectos. Administración de proyectos. Una definición de administración de proyectos dice: “Es la planeación, organización, dirección y control de los recursos para lograr un objetivo a corto plazo” [ADMI05].

Para obtener un sistema de software de calidad se hace necesario vigilar el proceso de desarrollo de software, en donde queda incluido el plan del proyecto. Los puntos que hacen crítico el desarrollo de los proyectos son la parte presupuestal y el tiempo de entrega, por lo que los participantes del proyecto deberán estar pendientes de cumplir los compromisos pactados dentro del proyecto [SOMM02] [PRES98][HUMP01].

Existen diversas razones que generan retrasos en la entrega del software como son: establecer una fecha de entrega poco realista, que el cliente cambie sus requisitos de manera arbitraria, hacer una mala estimación de cuanto personal se requiere y que además exista una mala comunicación entre ellos [SOMM02][PRES98][LARM99].

Debido a estas razones es recomendable llevar a cabo una buena planificación del proyecto, la que debe incluir el analizar el proyecto detalladamente para identificar las tareas. Esto se puede realizar mediante una planificación temporal que es la actividad que distribuye el esfuerzo estimado a lo largo de la duración del proyecto.

En la planificación temporal para poder analizar el proyecto se considera que se debe

dividir este en tareas, las cuales además deben especificar las precedencias entre actividades. Se define a quien son asignadas las tareas y que resultado se espera de cada una de ellas, también se debe tener en cuenta cuantas personas están disponibles y no tratar de asignar a más de las que existen. 2.1.1 Plan de Proyecto La planificación de un proyecto de software es una actividad que distribuye el esfuerzo estimado a lo largo de la duración prevista del proyecto, donde se hace una asignación del esfuerzo a las tareas.

El plan de proyecto debe contar con la siguiente información: 1. El alcance y los recursos a utilizar para el desarrollo de un proyecto, donde se incluya a

los administradores de software, personal técnico y al cliente. 2. Definir los riesgos y sugerir la manera de resolver dichos riesgos. 3. Definir los costos y planificación temporal de las revisiones. 4. Proporcionar un enfoque general del desarrollo del software para todo el personal que

este relacionado con el proyecto. 5. Describir cómo se garantiza la calidad y se administran los cambios.

Es importante mencionar que el plan debe ser revisado con regularidad, debido a que puede necesitar actualizaciones en cuanto al tiempo o recursos ya que muchas de las veces algunas de las actividades pueden retrasarse o acabarse antes de lo planeado, y eso amerita que el plan se actualice de acuerdo al avance que se lleva en el proyecto.

17


En la Figura 2.1 se muestra el Proceso de Calendarización de un proyecto, el cual

consta de varias etapas que implican: la identificación de las actividades y las dependencias existentes entre ellas; además, realiza una estimación de los recursos, se asigna el personal según el tipo de actividad a desarrollar y para finalizar se plantea la elaboración de gráficos que permitan visualizar los resultados obtenidos al llevar a cabo las etapas anteriores [SOMM02].

Identificar actividades

Identificar dependencias entre actividades

Estimar recursos para cada actividad

Asignar recursos a las actividades

Crear gráficos del proyecto

Requerimientos de software

Redes de actividades y gráficos de barras

Figura 2.1 El Proceso de Calendarización

Actividades. Conjunto de tareas que se llevan a cabo en un plan de proyecto y tienen un inicio y un fin [ADMI05]. Precedencias o dependencia entre Actividades. Naturaleza de la relación entre dos actividades vinculadas. Las actividades se vinculan definiendo una dependencia entre sus fechas de comienzo y de fin.

Existen tres tipos de dependencias entre actividades en SPYDER: Inicio a Inicio, Fin a

Inicio y Fin a Fin.

Recursos. Los recursos son el personal, equipo y materiales utilizados para completar las actividades de un proyecto. Duración. Es la cantidad de tiempo que transcurre desde la fecha de inicio de la actividad hasta la fecha en que es terminada.

Una vez determinadas las actividades se identifican las dependencias entre estas actividades, se estiman los recursos para las actividades que se llevarán a cabo en el proyecto y el paso siguiente que debe seguir el administrador del software es llevar a cabo la graficación de las actividades, denominada gráfica de Gantt.

18


Gráficos Es la representación de datos numéricos, en forma de líneas o dibujos, y en los que se muestra de una forma gráfica la relación que dichos datos guardan entre sí.

En las etapas del proceso de calendarización la última de estas se refiere a la creación de

gráficos, ya que estos permiten una visualización más clara sobre las actividades que se llevarán a cabo y en los gráficos se considera que deban contar con la siguiente información:

- Lista de las actividades que se van a realizar durante el desarrollo del proyecto. - Duración de cada actividad. - Fecha de inicio y terminación de cada actividad. - Definición de las tareas que dependen de la finalización de otra u otras.

Gráfico de Gantt Se define como una sencilla gráfica de barras en la cual cada barra simboliza una actividad del proyecto; el eje horizontal representa el tiempo y el eje vertical de la columna izquierda, se listan las actividades (Figura 2.2). Características

• Su trazado es simple. • Como medio de control muestra el estado actual del proyecto en cada una de sus

actividades y permite comparar éste con el estado propuesto. • Muestra la magnitud de los retrasos existentes. • Es sencillo de especificar y fácil de entender. • Permite una apreciación visual de todo el proyecto.

Fig. 2.2 Ejemplo de Gráfica de Gantt

Un tema importante para el desarrollo de la tesis es el cálculo de la regresión lineal, la cual

se utiliza para apoyar la estimación de un proyecto de software, haciendo uso de un método con apoyo de un registro histórico y no a juicio del ingeniero. 2.2 Regresión lineal La regresión es un método de análisis de los datos de la realidad, sirve para poner en evidencia las relaciones que existen entre diversas variables.

19


El objetivo del análisis de regresión es investigar la relación estadística que existe entre una variable dependiente (Y) y una o más variables independientes (X1, X2, X3,…). Cuando sólo existe una variable independiente, esto se reduce a la ecuación de la línea recta:

Y = a + bX donde: a es la ordenada en el origen, y b es la pendiente

El valor de a indica cual es el valor de Y cuando X es igual a 0, y b indica cuanto aumenta Y por cada incremento de una unidad en X, también es llamada la pendiente de la recta. La regresión lineal se utiliza para obtener estimaciones de estos coeficientes a partir de una muestra de observaciones sobre las variables X y Y. Las fórmulas para calcular los valores de a y b se muestran a continuación: [EST05]

nxby

an

i

n

i ii∑ ∑= =

−= 1 1

∑ ∑

∑ ∑ ∑

= =

= =

−

−= n

i

n

i ii

n

i

n

i

n

i iiii

xxnyxyxn

b1 1

22

1 1

)()()(

=1

Estas expresiones permiten obtener los valores cuando los puntos en la gráfica se acercan a la recta. Si los puntos están muy dispersos. Se utilizan otras expresiones para el cálculo de análisis de regresión.

Nuestro problema consiste en obtener estimaciones de estos coeficientes a partir de una

muestra de observaciones sobre las variables Y y X. Como ejemplo consideremos las cifras de la Figura 2.3, donde se muestran datos

mensuales de producción y costos de operación para una empresa británica de transporte de pasajeros por carretera durante los años 1949-52 (la producción se mide en términos de miles de millas-vehículo recorridas por mes, y los costos se miden en términos de miles de libras por mes). Primeramente se elabora un diagrama de dispersión de los datos, que es una representación en un sistema de coordenadas cartesianas de los datos numéricos observados. En el diagrama resultante, en el eje X, se etiqueta con las millas-vehículo recorridas, y en el eje Y se etiqueta el costo de operación mensual. Cada punto en el diagrama muestra la pareja de datos (millas-vehículo y costos de operación) que corresponden a un mes determinado.

20


El resultado que se aprecia es que existe una relación positiva entre estas variables: una mayor cantidad de millas-vehículo recorridas, corresponden a un mayor nivel de costos de operación.

Los datos reales se ven dispersos en una recta que ha sido obtenida con la información de costos y millas; esta recta se denomina recta de regresión. Los datos reales se encuentran dispersos a lo largo de la recta de regresión, lo que representa la variación que existe entre un dato real y el valor calculado de la recta de regresión en ese punto.

Diagrama de dispersión

Costos Millas Totales Vehículo

(miles) (miles) Mes Nº Y X

1 213.9 3147 2 212.6 3160 3 215.3 3197 4 215.3 3173 5 215.4 3292 6 228.2 3561 7 245.6 4013 8 259.9 4244 9 250.9 4159 10 234.5 3776 11 205.9 3232 12 202.7 3141 13 198.5 2928 14 195.6 3063 15 200.4 3096 16 200.1 3096 17 201.5 3158 18 213.2 3338 19 219.5 3492 20 243.7 4019 21 262.3 4394 22 252.3 4251 23 224.4 3844 24 215.3 3276 25 202.5 3184 26 200.7 3037 27 201.8 3142 28 202.1 3159 29 200.4 3139 30 209.3 3203 31 213.9 3307 32 227.0 3585 33 246.4 4073

Figura 2.3 Operaciones mensuales en una empresa de Transporte de Pasajeros

Para el desarrollo de la tesis es necesario conocer lo referente al modelado orientado a

objetos, ya que para el desarrollo de este trabajo, se modela bajo conceptos orientados a objetos. 2.3 Modelado Orientado a Objetos El modelado orientado a objetos nos ayuda a modelar un sistema de software. Los elementos que se incluyen son: clases, objetos, estados, relaciones, etc., se hace uso de distintos

21


diagramas y estos, permiten mostrar una solución gráfica del sistema que se esta tratando.

Los métodos de modelado orientado a objetos comparten los siguientes pasos básicos de diseño, aunque los detalles varíen[GRAH96].

• Se identifican los objetos y sus atributos, así como los nombres de los métodos. • Se establece la visibilidad de cada objeto en relación con los demás objetos. • Se establece la interfaz de cada objeto y el tratamiento de excepciones. • Se realizan y comprueban los objetos.

Cuando se modelan sistemas reales, sea cual sea el dominio del problema, muchas

veces se dibujan los mismos tipos de diagramas, porque representan varias vistas de modelos comunes. Normalmente las partes estáticas de un sistema se representarán mediante uno de los diagramas siguientes:

• Diagramas de clases. • Diagramas de objetos. • Diagramas de componentes. • Diagramas de despliegue.

A menudo se emplean cinco diagramas adicionales para ver las partes dinámicas del

sistema:

1. Diagramas de casos de uso. 2. Diagramas de secuencia. 3. Diagramas de colaboración. 4. Diagramas de estados. 5. Diagramas de actividades.

Cuando se modela un sistema desde diferentes vistas, se está construyendo el sistema

simultáneamente desde múltiples dimensiones. Eligiendo un conjunto apropiado de vistas, se establece un proceso que obliga a plantearse preguntas sobre el sistema.

Para modelar un sistema desde diferentes vistas, es necesario:

• Decidir que vistas se necesitan para expresar mejor la arquitectura del sistema e identificar los riesgos técnicos del proyecto.

• Para cada una de estas vistas, decidir que artefactos se necesitan crear para capturar los

detalles esenciales.

• Como parte del proceso de planificación, decidir cuales de estos diagramas se pondrán bajo algún tipo de control formal o semiformal. Estos son los diagramas para los que se planificarán revisiones y se mantendrán como documentación del proyecto[BOOC99].

22


2.4 Lenguajes Visuales Los lenguajes visuales son un nuevo paradigma para expresar los sistemas computacionales. Ellos ofrecen la posibilidad de manipular directamente los objetos. Un lenguaje visual esta compuesto de sentencias visuales. Para lenguajes visuales basados en íconos, cada sentencia visual es un arreglo espacial de objetos o íconos gráficos [CHAN90].

Un lenguaje visual es concebido como una colección de figuras obtenidas por un

arreglo gráfico de objetos en dos o más dimensiones. Los lenguajes visuales pueden ser modelados sintácticamente a través de un vocabulario, un conjunto de relaciones usadas para componer las figuras y un conjunto de reglas describiendo las figuras pertenecientes al lenguaje. Los objetos gráficos de un vocabulario de un lenguaje visual se caracterizan por contar con un conjunto de atributos. Los atributos de un objeto gráfico pueden ser: atributos gráficos, atributos sintácticos y atributos semánticos [MARR98]. Un tema que se ha tornado interesante es el uso de las gramáticas en proyectos de software y particularmente forma parte del desarrollo de ésta tesis. 2.5 Gramáticas para la especificación de lenguajes visuales:

a) Gramáticas textuales generalizadas. Este tipo de gramática provee una adaptación apropiada de la concatenación de símbolos para dos dimensiones. Su principal ventaja es que conservan los elementos teóricos de las gramáticas textuales y los eficientes algoritmos de análisis de éstos últimos. Su principal desventaja es que éstas gramáticas no son tan poderosas y sólo pueden especificar clases restringidas de lenguajes visuales.

b) Métodos basados en gramáticas de grafos. Un ejemplo de este tipo de gramáticas son las gramáticas de red. Las oraciones generadas con gramáticas de red son grafos dirigidos con símbolos en los nodos. Estos grafos son llamados redes. Una producción de éste tipo de gramáticas es de la siguiente forma:

α → β E donde α y β son redes y E es una forma de conectar a β cuando α es conectada a otra red anfitriona.

La mayor desventaja de las gramáticas de red, es que no han probado ser totalmente útiles para la especificación de gramáticas arbitrarias, por la complejidad para reescribir grafos y al hecho de que no todo lenguaje visual está compuesto exclusivamente por grafos.

c) Gramáticas de multiconjuntos de atributos. En estas gramáticas, las producciones

reescriben conjuntos o multiconjuntos de símbolos que tienen atributos con información sobre geometría o semántica. La reescritura se controla con restricciones sobre los atributos de los símbolos en el lado derecho de las producciones.

23


Un ejemplo de estas gramáticas es la Gramática Coordinada, la que especifica una notación matemática de dos dimensiones. En esencia, las producciones en una gramática coordinada n-coordinada libre del contexto tienen la siguiente forma:

A → α donde C F

Todos los símbolos de este tipo de gramática tienen n atributos geométricos, A es un símbolo no terminal, α es una cadena no vacía de símbolos, C es una restricción sobre los atributos de los símbolos en α, y F es una expresión que computa los atributos de los símbolos de A en términos de los atributos de los símbolos en α, no importando el orden de los símbolos en α.

d) Gramáticas Posicionales. Las gramáticas posicionales son un formalismo para la definición e implementación de lenguajes visuales, las gramáticas posicionales extienden naturalmente a las gramáticas libres de contexto. Una gramática libre de contexto posicional PG es una six-tupla (N, T, S, P, POS, PE) donde:

N es un conjunto finito no vacío de símbolos no terminales T es un conjunto finito no vacío de símbolos terminales, con N ∩ T = φ S ∈ N es el símbolo no terminal de inicio P es un conjunto finito de producciones POS es un conjunto finito de identificadores de relación binaria PE es un evaluador pictórico

Cada producción en P tiene la siguiente forma: A → x1 R1 x2 R2 ... xm-1 Rm-1 xm, ∆

e) Gramáticas relacionales. Este tipo de gramática pertenecen a las gramáticas libres de

contexto. La gramática relacional (RG’s) es una 6-tupla G (N, Σ, S, R, Attr, P) donde:

N: es un conjunto finito de símbolos no terminales Σ: es un conjunto de símbolos terminales. S: es un símbolo distinguido en N llamado símbolo inicial. R: es un conjunto finito de símbolos de relación. Attr: es un conjunto finito de atributos de símbolos. P: es un conjunto de producciones de la forma A-> α/β/F, donde: A ∈ N; α ∈ (n|σ)+ Donde n ∈ N, σ ∈ Σ;

β: Es un conjunto de relaciones de la forma (r x y) donde r ∈ R y x, y son enteros que hacen referencia a un miembro de α y también una expresión de la forma (a, i), donde a ∈ Attr e i es un entero que hace referencia a un miembro de α.

24


F: Es un conjunto de declaraciones de asignación de características de la forma (a, 0)=x donde a ∈ Attr y x es un entero que hace referencia a un miembro de a o a una expresión de la forma (a, i). [MARR98]

25


2.6 REFERENCIAS [ADMI05] http://html.rincondelvago.com/administracion-de-proyectos.html [BOOC99] BOOCH, JACOBSON, RUMBAUGH, The Unified Modeling

Languaje Reference Manual Addison Wesley 1999.

[CHAN90] CHANG, SHI-KUO, “Visual Languages and visual

programming”, Plenum Press, 340 Páginas, ISBN: 0-306-43428-8, QA-76.65-.V57-1990, 1990.

[ESTI05] http://www.eumed.net/cursecon/medir/estima.html. [FLOW99] FLOWER, MARTIN UML gota a gota

(Addisson Wesley Longman de México S.A. de C.V. México 1999).

[GRAH96] GRAHAM, IAN; Modelado Orientado a Objetos Adisson Wesley/ Díaz de Santos, segunda edición 1996. [HACK98] T. HACKOS, JOANN / C. REDISH JANICE, “User and Task

Análisis for Interface Design”, Wiley Computer Publishing, 488 Páginas, ISBN: , QA-76.9-.U83-H33-1998, 1998.

[HUMP01] HUMPHREY WATTS. S Introducción al Proceso de Software

Personal (PSP) Addison Wesley, 2001. [INCE93] INCE, D.C., Temas selectos de Ingeniería, Ingeniería de

Software,Addison Wesley Iberoamericana Año1993. [LARM99] LARMAN, CRAIG UML y PATRONES: Introducción al

análisis y diseño orientado a objetos. Prentice Hall, primera edición 1999.

[MARR98] MARRIOT, KIM / MEYER, BERND, “Visual Language

Theory”, Springer, 381 Páginas, P-93.5-.V567-1998, 1998. [PRES98] PRESSMAN ROGER Ingeniería de Software: Un enfoque

práctico cuarta edición , España Mc Graw Hill 1998. [SOMM02] SOMMERVILLE, IAN; Ingeniería de Software Addisson Wesley, sexta edición 2002.

26

CAPÍTULO 3 DESARROLLO DEL SISTEMA __________________________________________________________________________________________________________________

CCAAPPÍÍTTUULLOO

DESARROLLO DEL SISTEMA En este capítulo se describe el modelo conceptual del sistema SPYDER, su arquitectura, así como también los elementos que la componen. La Gramática Visual Relacional utilizada para la gráfica de Gantt y la definición de una base de datos históricos como apoyo en la determinación automática del tiempo de desarrollo de las actividades del plan de proyecto.

27


SPYDER (Sistema de Planeación de Proyectos de Software y Definición de Requerimientos) es el resultado de esta tesis; el producto creado como parte final, para permitirle al usuario crear planes de proyectos de software, que cuente con una alternativa para realizar la estimación de tiempo (duración de las actividades) en forma automática, utilizando una base de datos que contenga información histórica de actividades realizadas por los recursos humanos, utilizando el método de regresión lineal. Cuando no exista conocimiento sobre la(s) actividad(es), el sistema permite asignar el tiempo de forma manual.

Para generar la gráfica de Gantt, se elaboró una gramática visual. Se diseñó una interfaz gráfica del sistema, las cajas de diálogo para la entrada de datos y actividades del plan de proyecto.

3.1 Vista conceptual de SPYDER En la Figura 3.1 se puede observar de forma muy general cómo funciona internamente SPYDER y también cuáles son los resultados que genera.

SPYDER está conformado por las siguientes cuatro funcionalidades: 1. La interfaz, la cual le brinda al usuario la oportunidad de poder ingresar los datos

del plan de proyecto, determinar las precedencias entre las actividades, asignar recursos materiales y humanos al proyecto.

2. La de estimación, la que a través de una base de datos el usuario podrá determinar el tiempo que necesita para realizar las actividades.

3. La de graficación, en la que el sistema mostrará de forma gráfica el tiempo estimado para las actividades por medio del método de regresión lineal, así como la gráfica de Gantt; además de permitir el almacenamiento de información y poder agregarla al registro histórico de los proyectos realizados. Los servicios que proporciona SPYDER al usuario a través de su Interfaz Gráfica son:

• Permitir crear planes de proyecto utilizando una base de datos históricos.

• Guardar el plan de proyecto elaborado. • Visualizar la gráfica de Gantt. • Calcular la estimación de tiempo mediante la regresión lineal. • Visualizar la gráfica de regresión lineal. • Generar documentos de actividades. • Visualizar un comparativo de los tiempos estimados y reales una vez

finalizado el proyecto.

4. La de reportes, la que se encarga de generar los reportes tales como: visualizar actividades con fechas de inicio y fin, actividades con precedencias, actividades con recursos humanos y actividades con recursos materiales.

28


Figura 3.1 Vista Conceptual de SPYDER

3.2 Análisis de SPYDER Enseguida se presentan dos diagramas de casos de uso que corresponden al modelado del sistema.

La Figura 3.2 muestra los casos de uso principales de la herramienta y muestra la función que tienen los actores. Se describen los casos de uso principales como: Captura Actividades, Captura de Tiempo Real, Gráfica de Gantt, Asigna RH y Agrega RH. Los actores en estos casos de uso son: Usuario, que es la persona que utiliza la herramienta; Archivo.pro que es el archivo que guarda la información del plan de proyecto como: nombre del proyecto, nombre y número de recursos humanos, materiales y actividades, etc.; Archivo.dbk que es el archivo que contiene la información del tiempo real y el tiempo estimado a juicio del administrador del proyecto y BD que contiene la información de todos los proyectos terminados a los que se ha capturado el tiempo real.

A continuación se definen los casos de uso y escenarios de SPYDER, de las Figuras

3.2 y 3.3

Captura TR

Usuario

Archivo .pro

Agrega RM

Gráfica de Gantt

Asigna RM

Archivo .dbkCaptura Actividades

Agrega RH Asigna RH

BD

INCLUDE<<INCLUDE>>

<<INCLUDE>>

<<INCLUDE>><<INCLUDE>>

<<INCLUDE>>

Figura 3.2 Diagrama principal de Casos de uso.

29


BD

Usuario

Asignar RHConsultar BD

<<INCLUDE>>

Realizar RegresiónVer Gráfica

<<include>>

<<include>><<include>>

Figura 3.3 Diagrama de CU de estimación de tiempo con regresión lineal.

UC1: Principal

ACTOR SISTEMA Paso Acción Paso Acción Exc.

1 El usuario agrega actividades y precedencias a un plan de proyecto.

2 El usuario captura los recursos materiales del proyecto.

3 El sistema muestra el diálogo de captura.

4 El usuario selecciona la opción aceptar recursos materiales

5 El usuario captura los recursos humanos del proyecto.

6 El sistema muestra el diálogo de captura.

7 El usuario asigna los recursos materiales a las actividades.

E1

8 El usuario asigna los recursos humanos a las actividades.

E2, E3

9 El usuario realiza la captura del tiempo real

Id Acción E1 El sistema muestra un mensaje de que no se han capturado los recursos materiales E2 El sistema muestra un mensaje de que no se han capturado los recursos humanos E3 El sistema muestra un mensaje de que el recurso humano no está disponible

30


UC2: Estimación de tiempo

ACTOR SISTEMA Paso Acción Paso Acción Exc.

1 El usuario agrega un recurso humano a una actividad del plan de proyecto.

2 El sistema realiza la regresión E1,E2

3 El usuario captura los recursos materiales del proyecto.

4 El sistema consulta la BD

5 El usuario selecciona la opción de realizar regresión

6 El sistema hace el calculo y permite visualizar gráficamente la regresión

Id Acción E1 El sistema muestra un mensaje de que el RH no está disponible E2 El sistema muestra un mensaje de que no existen elementos para realizar la

regresión y se pide se haga manualmente

En la Figura 3.3 se observa el caso de uso estimación del tiempo con regresión lineal,

que es invocado desde el caso de uso Asigna RH cuando se elige un recurso humano para asignarlo a una actividad y es entonces cuando se hace uso del registro histórico (BD) de proyectos para estimar el tiempo necesario que se requiere para realizar la actividad a la que fue asignado el recurso humano utilizando el método de regresión lineal.

3.3 Diseño Detallado de SPYDER

Para mostrar cómo funciona el sistema, se muestran dos diagramas de secuencia que permitirán que se entienda el flujo de los principales mensajes existentes entre las distintas clases de la aplicación.

En la Figura 3.4 se muestran los mensajes enviados cuando se crea un plan de

proyecto, la secuencia empieza cuando el usuario decide crear un plan de proyecto e inicia en CpracticaView y, después es necesario agregar los recursos humanos y materiales que van a intervenir en el plan de proyecto en Cdialog1 y Captura_Recursos respectivamente. Se envía un mensaje de Cgrid a Actividades_Previas para agregar las precedencias en las actividades y en CcapturaTiempoReal se asigna el tiempo y se asigna a la BD.

La Figura 3.5 muestra el diagrama de secuencias para calcular la duración de una

actividad e inicia cuando en la pantalla de captura de actividades, se quiere agregar un recurso humano y manda el mensaje de OnHacerCalculos, y requiere de la información de la BD que por medio del mensaje de Consulta_BD a la clase CGraficaRegresiónLineal en la cual se hace el cálculo de duración y manda los datos al método Asignacion_Rec_Hum que verifica si está disponible el recurso humano y se grafique la regresión, de tal manera que se agregue el tiempo estimado en la columna duración de la pantalla de captura de actividades.

31


Figura 3.4 Diagrama de Secuencias General de SPYDER

Figura 3.5 Diagrama de Secuencias de Cálculo de duración

32


Enseguida se muestran los diagramas de actividades para el proceso de captura de actividades.

Figura 3.6 Diagrama de Actividad del Inicio del Sistema

La Figura 3.6 muestra el diagrama de actividad del método Inicio_ de_Sistema, en donde el primer paso que se da es saber si se va a realizar un nuevo proyecto. Si es así, se piden los datos del proyecto y después se muestra la pantalla de captura de actividades y se guarda la información, pero en caso de que se quiera trabajar en un proyecto existente, se elige el proyecto en el que se quiere trabajar , se muestra la pantalla de captura con los datos cargados y se modifica el plan de proyecto y después se guardan los cambios.

En la Figura 3.7 se muestra el diagrama de actividad del método Captura de Actividades de la clase CPracticaView. Lo primero que se hace es la captura de cada actividad con su fecha de inicio, después se capturan las precedencias en caso de que las haya, agregar los recursos humanos y materiales y por último guardar los datos en un archivo con extensión “.pro”.

La Figura 3.8 muestra el diagrama de actividad del método Cálculo de tiempo, en donde para cada actividad capturada se asignan uno o más recursos quienes van a realizar la actividad y si existe la experiencia almacenada en la BD, se realiza el cálculo de tiempo y se tiene la opción de ver la gráfica de regresión resultante del cálculo o proceder a asignar el recurso humano a la actividad; pero si no existe experiencia en la BD, entonces se permite que el usuario del sistema, pueda ingresar manualmente el tiempo que crea necesario para que esa actividad se lleve a cabo.

33


Figura 3.7 Diagrama de Actividad de Captura de Actividades

Figura 3.8 Diagrama de Actividad de Cálculo de Tiempo

34


3.4 Diagrama de clases de SPYDER Un diagrama de clases provee la vista estática de un software Orientado a Objetos. Dentro de la arquitectura estática de SPYDER se pueden visualizar las clases que comprende el sistema de software de esta tesis, y se muestra en la Figura 3.9. En la clase CPracticaView se definen los métodos como: Graficar_Gantt para visualizar la gráfica de Gantt; Calcula_duración para realizar el cálculo por medio de la regresión lineal; AgregarActividadesalGrid para el manejo de la pantalla de captura, la gráfica de comparativo de actividades, Asignación_Rec_Hum para asignar recursos humanos y materiales, CcapturaTiempoReal para capturar el tiempo real del proyecto y Act_Previas para el manejo de las precedencias. 3.4.1 Definición de clases utilizadas

CFormView

Es una clase de vista, tiene muchas de las características de una ventana de diálogo no modal, como cualquier clase derivada de CDialog, una clase CFormView está asociada a un recurso de diálogo que define las características del marco y enumera los controles.

Un objeto CFormView recibe mensajes de notificación directamente desde sus

controles y recibe mensajes de orden del marco de la aplicación. Esta capacidad de procesamiento de órdenes del marco de la aplicación distingue con claridad a CFormView de CDialog, y hace sencillo controlar la vista desde el menú principal o la barra de herramientas del marco.

La clase CFormView se deriva de la clase CView (realmente de CScroll View).

CFile

Esta clase presenta las funcionalidades básicas para el tratamiento de archivos, esto es, aportando funciones de alto nivel tales como:

Funciones Open/ Close para abrir y cerrar archivos. Funciones Read/ Write, para lectura y escritura de archivos. Funciones Seek/ SeekToBegin/CFile::SeekToEnd que permiten posicionamiento

directo dentro del archivo. Funciones GetLenght/ SetLenght que permiten obtener y cambiar el tamaño del

archivo. Función Rename/ Remove que permiten renombrar (mover) y eliminar archivos

respectivamente.

35


Figura 3.9 Diagrama de clases de SPYDER

Clase CTime

CTime presenta las funcionalidades básicas de tratamiento de fecha y hora. Al estilo de como se hace en C/C++ mediante el tipo de dato "time_t", representa un determinado instante de tiempo (con fecha, horas, minutos y segundos).

Algunas de las funciones son:

Función GetCurrentTime, que obtiene el instante actual. Funciones de extracción que permiten acceder a cualquiera de los datos significativos

que componen un CTime: el día del mes o el día de la semana, el mes, el año, la hora, etc.

36


Función Format, que permite construir un string formateado a partir de un CTime. Operadores de asignación, suma, resta y comparación. Como complementaria a esta

clase aparece CTimeSpan, la cual representa un intervalo de tiempo. Las operaciones de suma se realizan con esta clase, y una resta de dos fechas dadas siempre da como resultado un CTimeSpan.

Clase CRect

CRect automatiza el tratamiento de rectángulos. En Windows este concepto se utiliza continuamente ya que las posiciones o el tamaño de las ventanas se representan mediante los rectángulos que ocupan en la pantalla.

Un rectángulo viene representado físicamente por las coordenadas de su esquina superior izquierda y la de su esquina inferior derecha. Estos datos se almacenan en sus variables miembro públicas: top, left, bottom y right.

Dispone de funciones como:

Width/ Height, que permiten saber el ancho/alto de un rectángulo. PtInRect¸que permite saber si un determinado punto está contenido dentro de un

rectángulo.

CDialog

La clase CDialog proporciona una interfaz para administrar cuadros de diálogo, el editor de cuadros de diálogo de Visual C++ facilita el diseño de cuadros de diálogo y la creación de los recursos de plantilla de cuadro de diálogo correspondientes.

Los asistentes para código simplifican el proceso de inicialización y validación de los controles de un cuadro de diálogo y el proceso de recopilación de los valores escritos por el usuario.

CDialog es una clase abstracta, por lo que no es posible utilizarla directamente (no se pueden crear objetos CDialog). El programador deberá derivar sus propias clases desde CDialog para crear sus propios diálogos.

Los cuadros de diálogo contienen controles entre los que se incluyen:

Controles comunes de Windows tales como cuadros de edición, botones de comando, cuadros de lista, cuadros combinados, controles de árbol, controles de lista e indicadores de progreso.

Controles ActiveX. Controles dibujados por el propietario: controles de cuyo dibujo se hace responsable en

el cuadro de diálogo.

La mayor parte de los cuadros de diálogo son modales, lo cual requiere que el usuario cierre el cuadro de diálogo antes de utilizar cualquier otra parte del programa. Pero es posible

37


la creación de cuadros de diálogo no modales, que permitan a los usuarios trabajar con otras ventanas mientras está abierto el cuadro de diálogo.

La MFC admite ambos tipos de cuadros de diálogo con la clase CDialog. Los controles se organizan y administran mediante un recurso de plantilla de cuadro de diálogo, creado con el editor de cuadros de diálogo.

Clases derivadas de CDialog.

ConsultaID

Esta clase muestra un diálogo con la información del número de los recursos humanos y materiales agregados a un plan de proyecto.

Inicio_Sistema

Esta clase permite elegir si se va a trabajar en un proyecto existente o en un nuevo proyecto, y dependiendo de la elección muestra un plan de proyecto o la pantalla de captura de datos del proyecto.

Inicio_sistemaInicio_sistema()OnOk()OnRadio1()OnRadio2()

Act_Previas

Permite elegir de una lista de actividades las que serán predecesoras. Además de permitir elegir el tipo de precedencia.

Act_PreviasAct_Previas()Onfinfin()Onfininicio()Oninicioinicio()

Asignación RM

Es la clase que verifica que los recursos materiales dados de alta en el proyecto, no sean utilizados en actividades paralelas.

Asignacion_RMRecursosM_Disponibles()Asignacion_RM()

38


Duracion_Act

Esta clase permite ingresar de forma manual la duración de las actividades en caso de que no exista registro de conocimiento en la BD.

Duracion_ActDuracion_Act()OPnAceptarDias()

CReporte_de_Actividades

Permite visualizar en pantalla los reportes de: actividades con precedencias, actividades con fecha de inicio y fin, actividades con recursos humanos y actividades con recursos materiales.

CReporte_de_ActividadesBuscar_Lista()CReporte_de_Actividades()

NuevoProyecto

Permite capturar los datos del nuevo proyecto a realizar como: el encargado del proyecto, empresa, tipo de programa, lenguaje a utilizar.

NuevoProyectoNuevoProyecto()OnCancelar()OnAceptar()

Fechas

Esta clase permite obtener la fecha final de una actividad al agregar la duración en forma manual o por medio de la estimación, teniendo en cuenta el mes, año y día en que se inicia la actividad, si es año bisiesto y que el día final no debe caer en sábado o domingo porque son días no permitidos.

FechasAgregar_1Dia_mas()Calcula_Fecha_Inicial()Conv_Fecha_Entero_Cadena()Conv_Fecha_Cadena_Entero()Rest_Dias()bisiesto()Sum_Dias()Duracion_Fechas()Calculo_Duracion()Dias_del_mes()Calculo_Dias()Fechas()

39


CcapturaTiempoReal

Esta clase sirve para capturar el tiempo real de las actividades del plan de proyecto una vez que han sido terminadas y, guarda el tiempo real en un archivo con extensión “dbk” para cuando se cargue el plan de proyecto.

También agrega el tiempo en la base de datos “recurs”, en la cual todas las actividades de los proyectos terminados, deberán ser utilizadas como experiencia al estimar tiempos para nuevos proyectos.

CCapturaTiempoRealCompruebaActivas()Conectar()CCapturaTiempoReal()OnAsignarTiempo()SeleccionaActividad()

CDialog1

Permite visualizar los recursos humanos existentes en la BD “recurs”, para poder elegir los recursos que van a participar en el proyecto. Permite agregarlos en caso de que un recurso humano no esté en la BD.

CDialog1CDialog1()CargaLista()AgregarOtroRecurso()

GraficaRegresion Lineal

En esta clase se estima la duración de la actividad a realizar utilizando la base de datos “recurs”, además de graficar los datos con los cuales se realizó la estimación y los muestra en pantalla.

GraficaRegresionLineal

CalculoDuración()OnPaint()OnInfo()opname2()

CcapturaRecursos

Aquí se capturan los recursos materiales que van a utilizarse en el plan de proyecto, y son agregados a una lista.

40


CCaptura_RecursosCCaptura_Recursos()OnKeyPressMs()OnMouseDown()

CGrid

En esta clase se capturan los datos del plan de proyecto al hacer click en sus columnas, muestra la pantalla principal de captura.

CGridFecha_inicio()Fecha_final()OnClickGrid()OnKeyPressGrid()GoUp()GoDown()GoLeft()GoRight()OnEnterCell()Cambia_color_de_actividades()Verificacion_Fecha()CGrid()~CGrid()TransferValue()

CPracticaView

En esta clase es donde se tiene el acceso a las clases que fueron implementadas para cubrir el funcionamiento del proyecto de tesis.

CPracticaViewCPracticaView()GetDocument()Actualizacion_Fechas()Graficar_Gantt()Guardar_Cambios()OnAsignarRM()OnAsignar_RH()OnDuración()OnFileNew()OnFileOpen()OnSave()OnMostrarGrid()OnReportes()OnBorrar()OnTiempoReal()

41


CAsignacion_Rec_Hum

En esta clase es donde se realiza la consulta a la BD para estimar la duración de una actividad, se toma en cuenta la experiencia del recurso humano que va a realizar la actividad y si no la tiene, entonces se busca la experiencia de otros recursos humanos, se verifica que el recurso humano esté disponible y por último se visualiza en la pantalla el recurso humano agregado y la duración de la actividad.

Asignacion_Rec_HumConsulta_BD2()Regresion_Lineal()Consulta_BD()Rec_Hum_Disponibles()Asignacion_Rec_Hum()OnHacerCalculos()OnGraficarRegresion()

CGráficaComparativaProyecto

Aquí se muestra la gráfica comparativa de los tiempos estimados y reales del proyecto que van a utilizarse en el plan de proyecto, y son agregados a una lista.

CGráf icaComparativ aProy ecto

CPaint()CGráf icaComparativ aProy ecto()

3.5 Gramática utilizada.

3.5.1 Gramática Visual El trabajo de la diagramación de los gráficos de Gantt está basado en la gramática relacional, debido a que esta gramática tiene ciertas ventajas en la especificación de lenguajes visuales con respecto a la gramática posicional, ya que permite definir la relación de un objeto con otro sin importar el número de relaciones existentes entre ellas y la posición espacial de los mismos.

3.3.2 Definición de la gramática Relacional. [1]

La gramática relacional (RGs) es una 6-tupla G(N, Σ, S, R, Atrr, P) donde: 1. N: Es un conjunto finito de símbolos no terminales 2. Σ: Es un conjunto de símbolos terminales. 3. S: Es un símbolo distinguido en N llamado símbolo inicial.

42


4. R: Es un conjunto finito de símbolos de relación. 5. Atrr: Es un conjunto finito de símbolos de atributos. 6. P: Es un conjunto de producciones de la forma A-> α/β/F, donde:

A ∈ N; α ∈ (n|σ)+ Donde n ∈ N, σ ∈ Σ;

β: Es un conjunto de relaciones de la forma (rxy) donde r ∈ R y x,y son enteros que hacen referencia a un miembro de α y también una expresión de la forma (a,i) donde a ∈ Atrr e i es un entero que hace referencia a un miembro de α. F: Es un conjunto de declaraciones de asignación de características de la forma (a, 0)=x donde a ∈ Atrr y x es un entero que hace referencia a un miembro de a o a una expresión de la forma (a, i).

Se definirá la gramática para crear la gráfica de Gantt de acuerdo a los términos

anteriormente citados, quedando la gramática de la siguiente manera. N: { Gantt } Σ:{ } S: { Gantt } R:{ Flecha_fininicio, Flecha_iniini, Flecha_finfin } Atrr:{ izq, der, aba }

1 2 P: { Gantt

Flecha- finini 1 (izq 2)+ Flecha- iniini 1 (izq 2)+ Flecha-finfin 1 (izq 2)+ }

En donde el símbolo no terminal estará definido por el término Gantt, el símbolo

terminal estará representado por un rectángulo, el símbolo inicial será Gantt, las relaciones que se determinaron que definen la relación entre actividades serán Flecha_finini(fi), Flecha_iniini(ii) y Flecha_finfin(ff). Los atributos de los elementos de la gramática están definidos por izq, der, aba. 3.6 Reportes El módulo de reportes de actividades permite al usuario obtener 4 opciones de reportes: 1. Reporte de actividades con fecha de inicio y fecha de fin. 2. Reporte de actividades con actividades previas o precedencias. 3. Reporte de actividades con recursos humanos. 4. Reporte de actividades con recursos materiales.

La primera opción se refiere a que se desplegará en pantalla la fecha de inicio y fecha de fin de cada actividad del proyecto, así como su duración.

43


La segunda opción mostrará la actividad y sus actividades precedentes. La tercera y cuarta opción mostrarán la actividad y sus recursos humanos y materiales

respectivamente. Ambos reportes contienen como encabezado los datos generales del proyecto como:

Nombre del Proyecto, Nombre del Encargado, Empresa Desarrolladora etc.

Para llevar a cabo este módulo de reportes se utilizó el Microsoft FlexGrid Control, debido a su fácil manejo y que además se adapta a las necesidades para la generación de los reportes. El control puede contener 5 o 3 columnas dependiendo de la opción del reporte que se quiera generar y tiene una capacidad de 200 actividades; se observa en la Figura 3.10

Los datos generales del proyecto se despliegan en Etiquetas (StaticText) y se

inicializan al momento de la llamada al reporte.

Todos estos controles se despliegan dentro de un diálogo, el cual contiene un menú con la opción de Imprimir Reporte, la que permite al usuario hacer la impresión del reporte, y la opción Cerrar que cierra el diálogo y regresa a la pantalla de captura de actividades del sistema.

Etiquetas

rol

Reporte de Actividades x

**** Reporte de Actividades *****

Nombre del Proyecto: Nombre del Encarga: Nombre de la Empresa: Lenguaje de Programación:

Tipo de Proyecto:

ID Actividad Fecha de Inicio Fecha de Fin Duración

Menú

Opciones

3.7 Diseño la informac SPYDER utcon extensió

Para

delimitadorearchivo cadaeficientemen

Microsoft FlexGrid ContFigura 3.10 Interfaz de Reporte para actividades con fecha de inicio, fecha final y duración.

de las estructuras necesarias a utilizar y los métodos de almacenamiento de ión.

iliza archivos como almacenamiento del plan de proyecto. Estos archivos se crean n “.pro” y con extensión “.dbk”.

llevar a cabo el almacenamiento de la información dentro del archivo, se agregan s de información para poder distinguirla y, que al momento de la lectura del uno de los tipos de información, se almacene correctamente y pueda ejecutarse te.

44


El orden de almacenamiento de la información se presenta en la Figura 3.11, la cual muestra la apariencia del archivo “.pro” que genera SPYDER. Plan_Pruebas%Paula Araceli$Info Systems&Visual C¿Calculo 3*Marissa,Jaime,Ernesto 3*compu1,cañon,audiovisual 4 1|Analisis|06/05/2005|12/05/2005| 1||5 dias|*6,5+ 2|Diseño|13/05/2005|24/05/2005| 2||8 dias|1fi*6,3+2 3|Pruebas|25/05/2005|01/06/2005| 1||6 dias|2fi*4,4+2 4|Codificación|02/06/2005|02/06/2005|||1 dia|3fi*5,5+2

En la primera línson:

1. Nombre d2. Encargad3. Empresa 4. Lenguaje5. Tipo del p

En la segunda y

asignados al pr

En la cuarta lproyecto.

A partir de la

siguiente inform1. Número d2. Nombre d3. Fecha de 4. Fecha de 5. Duración6. Actividad7. Día de la 8. Día de la 9. Tipo de P

La información d

opción Guardar Proyect

Además de los aestructura para almacenutilizada cuando se quie

Los elementos d

Figura.3.11 Contenido de un archivo “.pro”.

ea del archivo se encuentran los datos generales del proyecto como lo

el Proyecto, delimitado por "%". o del Proyecto, delimitado por "$". Desarrolladora, delimitado por "&". de Programación, delimitado por "¿". royecto, delimitado por "\n”.

tercera línea se observan los recursos humanos y materiales que están oyecto.

ínea se almacena el número de actividades que forman parte del

quinta línea se empiezan a agregar cada una de las actividades con la ación:

e actividad, delimitado por “|”. e la actividad delimitado por “|“ inicio, delimitado por “|”. fin, delimitado por “|”. , delimitado por “|”. es Previas delimitado por “*”. semana de la fecha inicial, delimitado por “,”. semana de la fecha final, delimitado por “+”. recedencia de sus actividades previas, delimitado por “\n”.

el proyecto se almacena en este archivo una vez que se selecciona la o.

rchivos, variables y arreglos locales o globales, SPYDER utiliza una ar temporalmente la información de las actividades, pero ésta solo es re desplegar la gráfica de Gantt. e esta estructura son los siguientes:

45


struct datos

{ long duracion; long ini_ayo; long ini_mes; long ini_dia; long ini_dia_semana; long fin_ayo; long fin_mes; long fin_dia; long fin_dia_semana; CString precedencias; CString nombre; }; Todos estos datos son capturados cuando el usuario hace click en el icono de Gantt.

Esta información es tomada y transformada para llenar esta estructura, y ser pasada a la clase que se encarga de llevar a cabo la graficación. 3.8 Desarrollo del módulo de estimación de tiempo. Para el desarrollo del módulo de estimación se utilizó la regresión lineal, utilizándose la información que se obtiene de la experiencia de los diversos recursos humanos que han trabajado en proyectos de software. Para almacenarla se utiliza una base de datos llamada “recurs”.

La base de datos “recurs” es utilizada para guardar información de las actividades de los planes de proyectos ya terminados, usando access para su manejo.

La tabla que contiene la base de datos para guardar los datos históricos es llamada

“pruebas”. A continuación se menciona una breve descripción de cada campo.

Tabla: Pruebas

Id: Identificador de la actividad. Nombre: Nombre del recurso humano con experiencia en esta actividad. Lenguaje: Lenguaje en el que se desarrolló el proyecto. TDP: Naturaleza del proyecto desarrollado. Actividad: Nombre de la actividad en el plan de proyecto. Tiempo: Tiempo real en el que se desarrolló la actividad. Número de Unidades: Expresa la cantidad de actividades realizadas excepto en el caso

de la actividad de Codificación en donde las unidades se mide en LDC.

46


La información almacenada en la BD “recurs”, sirve para realizar el cálculo de tiempo necesario para que una actividad pueda llevarse a cabo utilizando una estimación de tiempo por medio de la técnica de análisis de regresión lineal. 3.9 Descripción de la herramienta. La herramienta SPYDER tiene como pantalla de inicio del sistema, el cuadro de diálogo que se muestra en la Figura 3.12. En esta pantalla se introducen los datos del proyecto como son: el nombre del sistema, nombre del encargado del proyecto, nombre de la empresa, lenguaje a utilizar y tipo de programa.

La pantalla de captura de actividades se muestra en la Figura 3.13 y esta cuenta con

una rejilla (grid) con apariencia de una hoja de cálculo en la cual se capturan las actividades del plan de proyecto. A la izquierda de la rejilla se observan los iconos utilizados para ver la gráfica de Gantt que son: agregar los recursos materiales, agregar los recursos humanos y registrar el tiempo real a cada una de las actividades del plan de proyecto actual.

Figura 3.12 Pantalla de registro de los datos del proyecto.

También cuenta con los siguientes menús Archivo, para seleccionar el proyecto que se

quiere abrir o guardar el proyecto existente. El menú Ver que permite visualizar la barra de herramientas o la barra de estado; el menú Reportes que permite visualizar la gráfica de Gantt y las gráficas comparativas de tiempo real, estimado por SPYDER y manual además de los distintos reportes mencionados en el punto 3.6

En la captura de las actividades del proyecto se da la fecha de inicio de la actividad y automáticamente agrega la fecha final, mostrándose en la Figura 3.13 un día de duración. Para agregar los recursos humanos o materiales a cada actividad, es necesario haberlos registrado como participantes del proyecto, debiendo hacer click en el icono correspondiente.

47


Figura 3.13 Pantalla principal de SPYDER

Una vez que los recursos son agregados al proyecto, es posible elegirlos para ser

asignados a cada actividad como lo muestra la Figura 3.14.

Figura 3.14 Pantalla de asignación de recursos humanos a una actividad.

48


Al momento de asignar un recurso humano se puede observar que en el diálogo de la Figura 3.14 se pide en el caso de la actividad de codificación, el número de líneas de código a desarrollar, para poder efectuar la estimación de tiempo basada en datos históricos por medio del método de regresión lineal.

Con esa información y además de los datos del proyecto se hace la búsqueda de la

experiencia existente en la base de datos, una vez obtenida la información, se realiza la regresión lineal y se muestra el resultado. En dado caso de que el usuario requiera ver la gráfica así como la ecuación de la recta resultante de haber realizado la regresión para una actividad y un recurso humano específico, es necesario hacer click en el botón Graficar Regresión y se observará la gráfica como en la Figura 3.15, en donde se visualiza el tiempo estimado y los datos con los cuales se realizó la regresión como son por ejemplo: nombre del recurso humano Marissa quien codificó 300 LDC en 12 días, Sergio quien codificó 530 LDC en 20 días, etc.

Figura 3.15 Gráfica de regresión

Si se quiere trabajar en un proyecto existente entonces, lo que se muestra es el cuadro

de diálogo “Open” que se observa en la Figura 3.16, en donde se permite abrir cualquier archivo con la extensión .pro.

49


Figura 3.16 Diálogo para abrir un archivo con extensión pro

Una vez abierto el archivo este es mostrado como en la pantalla de la Figura 3.17,

conteniendo los datos del proyecto seleccionado y entonces es posible realizar alguna modificación como: agregar mas actividades al plan de proyecto, asignar el tiempo real a las actividades terminadas u observar gráficamente el comparativo de tiempo estimado y tiempo real de las actividades en la opción de reportes.

Figura 3.17 Pantalla que muestra los datos de un proyecto existente.

¨

50


3.10 Búsqueda en la base de datos de los Recursos Humanos para realizar la regresión. A continuación se presenta el código que permite que se haga la búsqueda en la base de datos cuando se asigna un recurso humano a una actividad para saber si existe conocimiento almacenado para poder utilizarlo en el módulo de cálculo de tiempo por medio de la regresión lineal. void Asignacion_Rec_Hum::Consulta_BD() { CString nom; CString nomen; char strSql[300] = "Select * from Pruebas where nombre= '"; elementos=0; unidades=0; duraciones=0; nom=rec_hum; nom=nom + " ' and Actividad = ' " + m_actividad + " ' and Lenguaje = ' " + lenguaje_programacion + " ' and TDP = ' " + tipo_proyecto + " ' "; strcat(strSql, nom); CDaoDatabase *m_proy; CDaoRecordset *record; m_proy=new CDaoDatabase; CoInitialize(NULL); try{ m_proy->Open("recurs.mdb"); record=new CDaoRecordset(m_p roy); record->Open(dbOpenDynaset,strSql); while(!record->IsEOF()) { COleVariant v; v=record->GetFieldValue(6); m_unidades_bd.Format ("%i",v.intVal); v=record->GetFieldValue(5); m_tiempo.Format ("%i",v.intVal); v=record->GetFieldValue(1); nomen.Format("%s",v.bstrVal); promedios_regre[elementos][0]=float(strtol(m_tiempo,NULL,10)); promedios_regre[elementos][1]=float(strtol(m_unidades_bd,NULL,10)); nom_rec_hum[elementos]=rec_hum; Coordenadas.CPunto[elementos].np=rec_hum; Coordenadas.CPunto[elementos].x=promedios_regre[elementos][1]; Coordenadas.CPunto[elementos].y=promedios_regre[elementos][0]; Coordenadas.TPuntos=elementos+1; elementos++; record->MoveNext(); } record->Close(); delete record; m_proy->Close();

51


delete m_proy; } catch(CDaoException e) { AfxMessageBox("Error al abrir la base de datos"); } }

En el código anterior, se realiza una consulta a la base de datos y para la obtener la información de la BD se utiliza un componente llamado DAO.

Se define una cadena llamada strSql, se crea la cadena de consulta que contiene los datos relevantes para la consulta, enseguida se declara la variable de conexión a la BD llamada m_proy, declarando la variable de consulta llamada record, después se crea un puntero a la base de datos y por último se establece la consulta.

Se hace un ciclo Mientras no sea fin de archivo y, dentro de él se declara una variable

COleVariant que es el tipo de dato que regresan los métodos de DAO, luego se obtienen los valores de nombre, tiempo y unidades realizadas almacenadas en la BD y éstos se guardan en los arreglos promedios_regre y Cpunto que se van a utilizar cuando se haga el cálculo de la regresión.

En el Anexo B se encuentran otros métodos, utilizados en el desarrollo de SPYDER

como, Cálculo de Precedencias y Gráfica de regresión.

52

CCAAPPÍÍTTUULLOO

CCAASSOOSS DDEE PPRRUUEEBBAA Con el propósito de verificar la calidad del software desarrollado, se definieron casos de pruebas basados en el estándar IEEE 829 – 1998 para la Documentación de Pruebas de Software. De este estándar se toma el punto de casos de prueba. Finalmente se presentan los documentos obtenidos con la herramienta.

CAPÍTULO 4. CASOS DE PRUEBA ______________________________________________________________________________________________________________

4.1.-Desarrollo de Casos de Pruebas para aplicar a SPYDER. Los casos de prueba se presentan de acuerdo a las opciones con que cuenta cada uno de los módulos de la herramienta.

La estructura de los casos de prueba es la siguiente: o Identificador de especificación.- Especifica el único identificador asignado a

esta especificación de caso de prueba. o Artículo a probar.- identifica y describe brevemente los elementos y

características a ser probadas por este caso de prueba. o Especificaciones de entrada.- Especifica cada entrada requerida para ejecutar

el caso de prueba. Algunas de las entradas pueden ser especificadas por valor, mientras otras como tablas o archivos pueden ser especificadas por nombre. Identificar todas las bases de datos, archivos, mensajes, áreas de memoria y valores pasados por el sistema operativo.

o Especificaciones de salida.- Especifica todas las salidas y características requeridas de los elementos de prueba.

o Dependencia entre casos.- Lista los identificadores de los casos a ser ejecutados antes de este caso de prueba.

Una vez descrito cada caso de prueba se muestran los resultados obtenidos y se

describen en: o Resultados.

4.2 Caso de Prueba 1 Artículo a probar: Insertar fechas de inicio y final. En este caso de prueba se intenta probar el comportamiento de SPYDER cuando se inserta una actividad sin dar la fecha de inicio. Especificación de entrada:

Introducir la primera actividad. Análisis preliminar

No agregar ninguna fecha tanto de inicio como final.

Actividad F. Inicio F. Final Duración Act.

Previas 1 Análisis preliminar Desplazarse a la fila 2 con las flechas de desplazamiento.

Especificación de salida:

Observar un mensaje de error. “Falta una fecha en el renglón anterior”

Dependencias entre casos: Ninguno.

53


Resultados: En la Figura 4.1 se muestra la pantalla de error debido a que el usuario omitió la fecha de inicio de la actividad capturada y trata de introducir una nueva actividad, se da clic en aceptar y el usuario puede capturar la fecha de inicio de la actividad.

Figura 4.1 Muestra el error cuando se omite la fecha de inicio a la actividad.

4.3 Caso de Prueba 2: Artículo a probar: Insertar fecha de inicio. Probar el comportamiento de SPYDER cuando se inserta como fecha de inicio un sábado o domingo. Especificación de entrada.

Introducir la primera actividad. Análisis preliminar

54


Actividad F. Inicio F. Final Duración Act. Previas

1 Análisis preliminar Desplazarse a la segunda columna de Fecha Inicio con las fechas de desplazamiento

o seleccionarla con el botón izquierdo del mouse. Seleccionar la fecha 13/06/2004. Oprimir el botón de Aceptar.

Especificación de salida.

Observar un mensaje de error. “El día de inicio de actividad no esta permitido”

Dependencias entre casos: Ninguno. Resultados: La Figura 4.2 muestra un diálogo en el que se elige la fecha de inicio de la actividad y, se observa que el día elegido es inhábil mostrándose con un óvalo relleno.

En la Figura 4.3 se observa un diálogo que muestra un mensaje de error porque el día elegido fue inhábil, por lo que hay que volver a seleccionar un día que sea hábil para que pueda realizarse de manera satisfactoria la captura de la actividad.

Figura 4.2 Muestra que el día elegido es inhábil.

55


Figura 4.3 Pantalla de error “día no permitido”.

4.4 Caso de Prueba 3: Artículo a probar: Insertar Precedencia Tipo INICIO-INICIO(ii). Probar el comportamiento de SPYDER cuando se inserta una Actividad Previa tipo INICIO-INICIO a una actividad diferente a la primera. Especificación de entrada.

Introducir la primera actividad: Investigación Preliminar. Desplazarse a la columna de Fecha Inicio. Seleccionar la fecha de inicio: 16/06/2004. Desplazarse a la columna de Duración con las flechas de desplazamiento o con el

mouse. Seleccionar la duración: 2 días.

Actividad F. Inicio F. Final Duración Act.

Previas 1 Análisis Preliminar 16/06/2004 17/06/2004 2 días

Desplazarse a la fila siguiente. Introducir la segunda actividad: Búsqueda Bibliográfica. Desplazarse a la columna de Fecha Inicio.

56


Seleccionar la fecha de inicio: 16/06/2004.

Actividad F. Inicio F. Final Duración Act. Previas

1 Análisis Preliminar 16/06/2004 17/06/2004 2 días 2 Búsqueda Bibliográfica 16/06/2004 16/06/2004 1 día

Desplazarse en la actividad 2 a la columna de Act. Previas con las flechas de

desplazamiento o con el mouse. Seleccionar: Análisis Preliminar, Tipo: Inicio-Inicio.


Desplegar en la columna de Actividades Previas, el número de actividad y su tipo de precedencia.

Actividad F. Inicio F. Final Duración Act. Previas 1 Análisis Preliminar 16/06/2004 17/06/2004 2 días 2 Búsqueda Bibliográfica. 16/06/2004 16/06/2004 1 día 1ii

Dependencias entre casos: Este caso depende del Caso de Prueba 1, porque es necesario haber capturado la actividad Análisis Preliminar antes de agregar la precedencia. Resultados: En la Figura 4.4, se observa el diálogo de captura que aparece después de hacer click con el botón derecho del mouse en la columna de precedencias en la actividad a la cual se desea agregar una o más precedencias, pudiendo ser estas de los tipos “Inicio -> Inicio”(ii), “Fin ->Inicio”(fi) y “Fin->Fin”(ff).

El resultado de agregar las precedencias se puede observar en la Figura 4.5. En la Figura 4.6 se puede ver como se representa este tipo de precedencias en la

gráfica de Gantt.

57


Figura 4.4 Agregar precedencias a una actividad.

Figura 4.5 Modifica las fechas de las Actividades después de haber agregado precedencias.

58


Figura 4.6. Muestra la relación de las actividades en Gantt.

4.5 Caso de Prueba 4: Artículo a probar: Insertar Precedencia Tipo INICIO-INICIO. Probar el comportamiento de SPYDER cuando se inserta una Actividad Previa tipo INICIO-INICIO y cuya fecha de inicio es mayor a la de su predecesora. Especificación de entrada.

Introducir la primera actividad: Análisis Preliminar. Desplazarse a la columna de Fecha Inicio. Seleccionar la fecha de inicio: 16/06/2004. Desplazarse a la columna de Duración y seleccionar 2 días.

Actividad F. Inicio F. Final Duración Act. Previas 1 Análisis Preliminar 16/06/2004 17/06/2004 2 días

Desplazarse a la fila siguiente. Introducir la segunda actividad: Búsqueda Bibliográfica. Desplazarse a la columna de Fecha Inicio. Seleccionar la fecha de inicio: 17/06/2004.

Actividad F. Inicio F. Final Duración Act. Previas 1 Análisis Preliminar 16/06/2004 17/06/2004 2 días Búsqueda Bibliográfica 17/06/2004 17/06/2004 1 día

Desplazarse a la fila siguiente. Introducir la tercera actividad: Estudio de Visual C++. Desplazarse a la columna de Fecha Inicio. Seleccionar la fecha de inicio: 16/06/2004.

Actividad F. Inicio F. Final Duración Act. Previas 1 Análisis Preliminar 16/06/2004 17/06/2004 2 días 2 Búsqueda Bibliográfica 17/06/2004 17/06/2004 1 día 3 Estudio de Visual C++ 16/06/2004 16/06/2004 1 día

59


Desplazarse a la columna de Act. Previas con las flechas de desplazamiento o con

| el mouse. Seleccionar: Búsqueda Bibliográfica. Tipo: Inicio-Inicio.



Actualizar la fecha de inicio de la Actividad 3: Estudio de Visual C++ a 17/06/2004.

Actualizar la fecha final de la Actividad 3: Estudio de Visual C++ a 17/06/2004

Actividad F. Inicio F. Final Duración Act. Previas 1 Análisis Preliminar 16/06/2004 17/06/2004 2 días 2 Búsqueda Bibliográfica 17/06/2004 17/06/2004 1 día 3 Estudio de Visual C++ 17/06/2004 17/06/2004 1 día 2ii

Dependencias entre casos: Este caso depende del caso de prueba 1, porque es necesario que se realice el caso de prueba 1 antes de realizar este caso. Resultados: En la Figura 4.7 se muestran las fechas de las actividades antes de agregar la precedencia y en la cual se observa que la fecha de inicio de la actividad 3 es menor a la de inicio de la actividad 2.

Una vez que se ha agregado la precedencia, la Figura 4.8 muestra el cambio que sufre la Actividad 2

Figura 4.7 Elección de tipo de precedencia

60


Figura 4.8 Pantalla que muestra el cambio de la fecha de inicio de la actividad 3.

4.6 Caso de Prueba 5: Artículo a probar: Insertar Precedencia Tipo FIN-FIN. Probar el comportamiento de SPYDER cuando se insertan Actividades Previas tipo FIN-FIN en una lista de actividades. Especificación de entrada:

Repetir los pasos de Especificación de entrada del Caso de Prueba 1 hasta llenar el área de captura de actividades.

Actividad F. Inicio F. Final Duración Act. Previas 1 Análisis Preliminar 08/07/2004 19/07/2004 8 días 2 Búsqueda Bibliográfica 08/07/2004 13/07/2004 4 días 3 Estudio del lenguaje

Java 08/07/2004 15/07/2004 6 días

4 Diseño 12/07/2004 22/04/2004 9 días 5 Pruebas 08/07/2004 14/04/2004 5 días

Desplazarse a la columna de Actividades Previas y marcar las precedencias de tipo

FIN-FIN especificadas enseguida.

61


Actividad F. Inicio F. Final Duración Act. Previas 1 Análisis Preliminar 08/07/2004 19/07/2004 8 días 2 Búsqueda Bibliográfica 08/07/2004 13/07/2004 4 días 1ff 3 Estudio del lenguaje Java 08/07/2004 15/07/2004 6 días 1ff 4 Diseño 12/07/2004 22/04/2004 9 días 5 Pruebas 08/07/2004 14/04/2004 5 días 3ff,4ff



Actualización de las fechas de inicio y fin. Actividad F. Inicio F. Final Duración Act. Previas 1 Análisis Preliminar 08/07/2004 19/07/2004 8 días 2 Búsqueda Bibliográfica 14/07/2004 19/07/2004 4 días 1ff 3 Estudio del lenguaje Java 12/07/2004 19/07/2004 6 días 1ff 4 Diseño 12/07/2004 22/07/2004 9 días 5 Pruebas 16/07/2004 22/07/2004 5 días 3ff,4ff

Dependencias entre casos: Este caso depende del Caso de Prueba 1. Resultados: En la Figura 4.9 se observa como al agregar las precedencias a las actividades ocurre un cambio en las fechas, en este caso particular las fechas finales son las que sufren cambios.

En la Figura 4.10 se muestra como son representadas las precedencias tipo“Fin -> Fin” en la pantalla de captura de actividades.

Figura 4.9. Muestra el cambio de fechas al agregar las precedencias.

Figura 4.10 Muestra las precedencias de cada actividad.

62


Figura 4.11 Muestra las precedencias de cada actividad en Gantt.

4.7 Caso de Prueba 6: Artículo a probar: Agregar Recursos Humanos al Proyecto. Probar el comportamiento de SPYDER cuando no hay información en la base de datos y se requieren agregar recursos humanos a un proyecto. Especificación de entrada:

Hacer click en el icono de agregar Recursos Humanos Capturar los recursos Humanos al proyecto

Jaime, Paula, Marissa, Eurí, Max y Sergio Hacer click en el botón Aceptar


Desplegar en la columna Agregados al Proyecto del diálogo Agregar Recursos Humanos, los Recursos Humanos capturados.

Dependencias entre casos: Ninguna. Resultados: La Figura 4.12 muestra que la BD está vacía, por lo tanto se tienen que agregar Recursos Humanos al proyecto.

Al Agregar Recursos Humanos al proyecto cuando se tiene vacía la BD, sólo se muestran los recursos en la lista de “Agregados al proyecto”como se observa en la Figura 4.13.

63


Figura 4.12 Muestra que la BD está vacía, no existen Recursos Humanos.

Figura 4.13 Pantalla de captura de recursos humanos con la BD vacía

4.8 Caso de Prueba 7: Artículo a probar: Consulta_BD. Probar el comportamiento de SPYDER cuando se asigna un Recurso Humano a una actividad y, en la BD existe el registro de experiencia del recurso en esa actividad.

64


Especificación de entrada:

Posicionarse en el renglón de la actividad Pruebas. Hacer click en la columna Recursos Humanos con el botón derecho del mouse. Elegir el Recurso Humano = Sergio. Capturar el número de unidades a realizar de esa actividad = 8. Hacer click en el botón Hacer Cálculo. Si se quiere ver la gráfica de regresión hacer click en Graficar Regresión. Hacer clic en Asignar el Recurso Humano.


Se debe mostrar en un diálogo los recursos humanos que se pueden agregar a la actividad.

Desplegar en un diálogo el mensaje “Se realiza la regresión porque hay elementos para hacerla”

Muestra los días necesarios para el desarrollo de la actividad = 7 días Dependencias entre casos: Depende de los casos de prueba 1 y 5 Resultados: La Figura 4.14 muestra un diálogo para elegir el recurso humano que se agrega a la actividad de Pruebas en el Plan de Proyecto.

En la Figura 4.15 se observa el tiempo necesario para que el recurso humano Sergio pueda realizar 8 pruebas y para realizar el cálculo se utilizó la información almacenada en la base de datos, que consta de 10 registros de información de diversos proyectos en donde el recurso humano Sergio ha trabajado en la actividad de Pruebas. Por ejemplo:

Se tiene la información que Sergio realizó 13 pruebas en 9 días, 6 pruebas en 6 días

y así sucesivamente como se puede visualizar en la Figura 4.16, así como la gráfica de regresión resultante en la cual también se observa el punto estimado por el proyecto y se encuentra sobre la línea de regresión, que corresponde al cálculo en días necesarios para que el recurso humano pueda realizar la actividad.

Al hacer clic en agregar, el identificador del recurso humano Sergio se agregó a la

actividad para la que se realizó la estimación se muestra la pantalla de la Figura 4.17, en donde se visualiza que a la actividad ya se le asignó el recurso humano.

65


Figura 4.14 Selección de un recurso humano.

Figura 4.15 Muestra el tiempo necesario para que el recurso humano realice la actividad.

66


Figura 4.16 Gráfica de Regresión.

Figura 4.17 Recurso Humano asignado a la actividad.

67


4.9 Caso de Prueba 8: Artículo a probar: Regresión Lineal. Probar el comportamiento de SPYDER cuando se asigna un Recurso Humano que no tiene experiencia en una actividad, pero en la BD existe el registro de experiencia de otros recursos humanos en esa actividad. Especificación de entrada:

Hacer click en la columna Recursos Humanos con el botón derecho del mouse. Elegir el Recurso Humano = Olivia. Capturar el número de unidades a dar de alta de esa actividad =8. Hacer click en el botón Hacer Cálculo. Si se quiere ver la gráfica de regresión hacer click en Graficar Regresión. Hacer clic en Asignar el Recurso Humano.


Se debe mostrar en un diálogo los recursos humanos que se pueden agregar a la actividad.

Desplegar en un diálogo el mensaje: “Se realiza la regresión porque hay elementos para hacerla

Muestra los días necesarios para el desarrollo de la actividad = 7 días Dependencias entre casos: Depende de los casos de prueba 1 y 5, porque se deben realizar estos casos de prueba con éxito para que el caso de prueba 8 pueda llevarse a cabo. Resultados: Las pantallas que se muestran son las Figura 4.14 y 4.15. Además de la Figura 4.18 en la cual se muestra que el recurso es agregado a la pantalla de captura de las actividades.

En la Figura 4.19 se puede observar la gráfica de regresión lineal y los datos de los recursos humanos con los que se realizó la regresión.

68


Figura 4.18 Recurso Humano asignado.

Figura 4.19 Regresión lineal con recursos humanos diferentes al seleccionado.

69


4.10 Caso de Prueba 9: Artículo a probar: Captura de Tiempo Real. Probar el comportamiento de SPYDER en el módulo de Captura de Tiempo Real y cómo se visualiza en la gráfica de Gantt. Especificación de entrada:

Hacer click en el icono Asignación de tiempo real. Elegir la actividad Análisis Preliminar. Capturar el tiempo real de esa actividad =10. Hacer click en el botón Asignar. Repetir los pasos anteriores para todas las actividades cambiando sólo el tiempo real. Hacer clic en el botón OK. Hacer clic en el icono Gráfica de Gantt.


Se debe mostrar en un diálogo las actividades con su información. Muestra en la pantalla de captura los días asignados como tiempo real en la columna

Tiempo real

Actividad F. Inicio F. Final Duración Act. Prev. T.Real 1 Análisis Preliminar 08/07/2004 19/07/2004 8 días 8 2 Búsqueda

Bibliográfica 14/07/2004 19/07/2004 4 días 1ff 6

3 Estudio del lenguaje Java

12/07/2004 19/07/2004 6 días 1ff 15

4 Diseño 12/07/2004 22/07/2004 9 días 5 5 Pruebas 16/07/2004 22/07/2004 5 días 3ff,4ff 12

Dependencias entre casos: Depende de los casos de prueba 1 y 5, porque se deben realizar estos casos de prueba con éxito para que el caso de prueba 8 pueda llevarse a cabo. Resultados: La Figura 4.20 muestra un diálogo con la información de cada actividad que está definida en el proyecto. Se puede observar en la Figura 4.21 una paloma que indica que ya se le asignó el tiempo real a esa actividad.

Una vez que se ha capturado el tiempo real en las actividades, se puede visualizar tanto el tiempo real como el tiempo calculado por el proyecto en la pantalla de captura, en la gráfica de Gantt, Figuras. 4.22, 4.23 y para ver la información que se almacenó en la base de datos se utilizó ACCESS, éste se muestra en la Figura 4.24.

70


Figura 4.20 Diálogo que muestra las actividades del proyecto.

Figura 4.21 Captura del tiempo real.

Figura 4.22 Muestra parte de la pantalla de captura de SPYDER con el tiempo real asignado.

71


Figura 4.23 Gráfica de Gantt con el tiempo estimado y el real.

Figura. 4.24 SPYDER agrega la información a la base de datos.

En la Figura 4.25 se muestra un comparativo del tiempo tanto estimado como el real

del plan del proyecto, que contempla a todas las actividades. En la Figura 4.26 se observa de manera general el tiempo total tanto estimado como

real del proyecto.

72


Figura 4.25 Comparativo de tiempo de todas las actividades.

4.26 Comparativo de tiempos del proyecto total.

73


4.11 Caso de Prueba 10: Artículo a probar: Gráficas comparativas. Probar el comportamiento de SPYDER en el módulo de Gráficas comparativas. Especificación de entrada:

Tomando como base la información y planes de proyectos que realizaron estudiantes de 7o. 8o. y 9o. semestre de la carrera de ingeniería en sistemas del Instituto Tecnológico de Ciudad Madero. Se aplicaron varios casos de prueba a SPYDER. En la tabla 5.1 se muestran los resultados de 7 planes de proyectos que se utilizaron para estimar el tiempo en nuevos proyectos

Pruebas

Id Nombre Lenguaje Tipo de Proyecto Actividad Tiempo(días)

Numero Unidades Proyecto

354 José C++ Administrativo Investigación 4 1 Proyecto81 355 José C++ Administrativo Entrevistas 2 3 Proyecto81 356 Luis C++ Administrativo Estudio C++ 10 5 Proyecto81 357 Alberto C++ Administrativo Análisis 10 1 Proyecto81 358 Alberto C++ Administrativo Diseño 4 1 Proyecto81 359 Luis C++ Administrativo Codificación 17 620 Proyecto81 360 Alberto C++ Administrativo Pruebas 2 10 Proyecto81 361 Manuel C++ Administrativo Investigación 4 1 Proyecto82 362 Manuel C++ Administrativo Entrevistas 1 2 Proyecto82 363 Julio C++ Administrativo Análisis 12 1 Proyecto82 364 Sofía C++ Administrativo Diseño 3 1 Proyecto82 365 Julio C++ Administrativo Codificación 18 650 Proyecto82 366 Sofía C++ Administrativo Pruebas 2 12 Proyecto82 367 Omar C++ Administrativo Entrevistas 3 3 Proyecto83 368 Laura C++ Administrativo Análisis 10 1 Proyecto83 369 Omar C++ Administrativo Diseño 4 1 Proyecto83 370 Martel C++ Administrativo Codificación 16 520 Proyecto83 371 Laura C++ Administrativo Pruebas 5 20 Proyecto83 372 Sandra C++ Administrativo Investigación 4 1 Proyecto84 373 Azucena C++ Administrativo Análisis 9 1 Proyecto84 374 Sandra C++ Administrativo Diseño 3 1 Proyecto84 375 Marcela C++ Administrativo Codificación 18 580 Proyecto84 376 Azucena C++ Administrativo Pruebas 3 12 Proyecto84 377 Ana C++ Administrativo Investigación 6 1 Proyecto85 378 Miguel C++ Administrativo Análisis 10 1 Proyecto85 379 Ana C++ Administrativo Diseño 3 1 Proyecto85 380 Rocío C++ Administrativo Codificación 18 600 Proyecto85 381 Miguel C++ Administrativo Pruebas 2 10 Proyecto85

74


Pruebas

Id Nombre Lenguaje Tipo de Proyecto Actividad Tiempo(días)

Numero Unidades Proyecto

382 Sonia C++ Administrativo Investigación 5 1 Proyecto86 383 Andrea C++ Administrativo Análisis 10 1 Proyecto86 384 Sonia C++ Administrativo Diseño 3 1 Proyecto86 385 Diana C++ Administrativo Codificación 22 750 Proyecto86 386 Andrea C++ Administrativo Pruebas 3 12 Proyecto86 387 Juan C++ Administrativo Investigación 3 1 Proyecto87 388 Juan C++ Administrativo Análisis 10 1 Proyecto87 389 Yoab C++ Administrativo Diseño 5 1 Proyecto87 390 Ricardo C++ Administrativo Codificación 18 635 Proyecto87 391 Yoab C++ Administrativo Pruebas 3 10 Proyecto87

Tabla 4.1 Información resultante almacenada en la BD al aplicar las pruebas a SPYDER. Especificación de salida:

Se deben mostrar las gráficas en pantalla de cada plan de proyecto.

Resultados: En la Tabla 4.1, se muestra la información de tiempo real de 7 proyectos, en donde se visualiza que para el Proyecto81, no existe información en la BD, que pueda utilizarse para realizar las estimaciones de tiempo de las actividades, por lo que es necesario hacer una estimación a juicio del administrador y una vez terminado el proyecto, se procede a capturar el tiempo real en SPYDER y se almacene en la BD.

Para proyectos posteriores ya se contará con información en la BD, pudiendo realizar estimaciones como sucedió en el caso de los proyectos: Proyecto82, Proyecto83, Proyecto84, Proyecto85, Proyecto86 y Proyecto87.

PROYECTOS

Proyecto81 Proyecto84 Proyecto87

Investigación 80 100 80 Entrevistas 100 - - Estudio C++ 66 - - Análisis 66 90 100 Diseño 80 75 75 Codificación 88 94 90 Pruebas 66 100 100

Tabla 4.2 Porcentajes de concordancia en los proyectos por actividad.

75


PROYECTOS

Proyecto81 Proyecto84 Proyecto87

Concordancia por proyecto SPYDER vs. Real 81 97 97.5 Concordancia por proyecto Manual vs. Real 81 54 92

Tabla 4.3 Porcentajes de concordancia en los proyectos por tiempo total del proyecto.

Manual. – Tiempo estimado a juicio del administrador Real.- Tiempo real utilizado SPYDER.- Tiempo estimado por SPYDER

Los porcentajes que se muestran en la tabla 4.2 son determinados tomando los resultados dados por SPYDER en cuanto al número de días estimados y reales para cada actividad, resultados que se pueden observar en el Anexo A, en las Figuras 6.1, 6.2, 6.4, 6.5, 6.7 y 6.8. Los porcentajes de la Tabla 4.3 se determinan utilizando los resultados mostrados en el Anexo A en las Figuras 6.3, 6.6 y 6.9. En la Figura 6.9 no se muestra el tiempo manual porque al ser el primer proyecto a estimar, no hay conocimiento y por lo tanto en la gráfica se maneja como tiempo de SPYDER.

Después de determinar los porcentajes y elaborar las tablas, se observa en el caso del Proyecto81 que el porcentaje de concordancia entre los tiempos por actividad resultó ser bajo, debido a que los tiempos fueron introducidos manualmente, estos tiempos fueron a juicio del Administrador; referente a los tiempos Manual-Real del proyecto completo es del 81% debido a que al no existir información en la BD para realizar la estimación, se tiene que introducir manualmente y difiere un 19% en cuanto al tiempo real. Observando los datos tanto por actividad como por proyecto completo, para el Proyecto84 y el Proyecto 87 la concordancia se incrementa.

Los casos de prueba muestran en general los diferentes módulos que conforman la herramienta y se hace énfasis en los casos de prueba 7 y 10 que es la aportación relevante del presente trabajo de tesis y que corresponde al cálculo del tiempo a partir del registro histórico que se encuentra almacenado en la BD.

76

CAPÍTULO 5 CONCLUSIONES Y TRABAJO FUTURO ______________________________________________________________________________________________________________

CCAAPPÍÍTTUULLOO

CCOONNCCLLUUSSIIOONNEESS YY TTRRAABBAAJJOO FFUUTTUURROO En este capítulo se muestran las observaciones generadas al finalizar el trabajo y se verifican los resultados de las hipótesis. Se determinan qué trabajos futuros se pueden derivar para mejorar el trabajo de tesis realizado, esto, debido a los grandes avances y los diversos temas existentes en la Administración de Proyectos.

78


5.1 Conclusiones El realizar un plan de proyecto tiene como objetivo el buen aprovechamiento de los recursos tanto materiales y humanos, así como el poder entregar a tiempo un sistema de software.

Los siguientes puntos, son acciones que resultaron del trabajo de tesis que fue desarrollado y presentado dentro de este documento. Esto permite confirmar que se cumplen los objetivos planteados de:

a. Realizar un plan de proyecto de software en el cual se pueden especificar

tareas o acciones las cuales pueden tener una fecha de inicio y terminación de cada actividad.

b. Contar con un módulo de estimación de la duración de actividades por

medio de regresión lineal utilizando una base de datos históricos.

c. Plantear la implementación de una gráfica de regresión lineal que muestre el valor calculado y la información de la base de datos que se utiliza para la realización de la estimación.

d. Generar una gráfica de Gantt una vez que han sido capturadas las

actividades de un proyecto.

e. Generar un reporte de actividades del Plan de Proyecto.

Por otro lado, las aportaciones de este trabajo de tesis son:

Una estimación automática del tiempo necesario para desarrollar una actividad utilizando un registro histórico de proyectos anteriores.

Permitir actualizar el registro histórico una vez que se haya terminado el proyecto en desarrollo.

Ingresar el avance real de cada actividad terminada en el plan de un proyecto de software.

Visualizar en la gráfica de Gantt tanto el avance estimado como el avance real del proyecto.

Visualizar mediante gráficas comparativas los tiempos de cada actividad de un plan de proyecto, en las cuales se podrán observar los tiempos estimados por SPYDER, el tiempo estimado por el administrador a juicio de él y el tiempo real que se necesitó para llevar a término el proyecto.

De acuerdo a los resultados obtenidos de la aplicación de los casos de prueba 7 y 10 se tiene que:

En el caso de prueba 7, teniendo un plan de proyecto en donde se desea asignar el recurso humano Sergio a la actividad de pruebas de ese plan, es posible estimar cuánto tiempo se lleva en la ejecución de 8 pruebas. Para poder llevar a cabo la estimación,

79


SPYDER hace el cálculo utilizando la información almacenada en la base de datos, la cual consta de 10 registros de información de diversos proyectos, en donde el recurso humano Sergio ha trabajado en la actividad de Pruebas.

En la Figura 4.15 se observa la gráfica de regresión resultante, en la cual se

visualiza el punto estimado para el proyecto y éste se encuentra sobre la línea de regresión. Éste punto corresponde al cálculo en días que son necesarios para que el recurso

humano pueda realizar la actividad a la cual fue asignado. Para el caso de prueba 10, se utilizó la información que se encuentra en la tabla 4.1

y corresponde a información histórica de 7 planes de proyecto: Proyecto81, Proyecto82, Proyecto83, Proyecto84, Proyecto85, Proyecto86 y el Proyecto87.

Como se observa en la Tabla 4.2, el porcentaje de que tan cercanos son los valores

de la estimación realizada por SPYDER con respecto al tiempo real de cada unas de las actividades de los planes de proyectos y podemos observar que en el proyecto81, las actividades tienen un porcentaje bajo debido a que no existía información en la BD que permitiera realizar la estimación y se hizo uso del juicio de quien realizó la actividad.

Conforme se almacena información histórica de datos de los proyectos como en el

caso del proyecto84, donde ya existe la información de los proyectos: proyecto81, proyecto82 y proyecto83; los porcentajes van aumentando, lo que significa que la estimación realizada por SPYDER se acerca al tiempo real utilizado para llevar a término las actividades.

De acuerdo a la información que se encuentra en la tabla 4.3, se tiene que el

porcentaje de SPYDER y manual (estimado por el administrador) son el mismo, debido a que para el proyecto81 no se contaba con información histórica para realizar la estimación de las actividades del proyecto, por lo que su porcentaje con respecto al tiempo real difiere en un 19%.

En el caso del proyecto84, como ya existe información histórica de los proyectos:

proyecto81, proyecto82 y proyecto83, la diferencia existente entre el tiempo real y el estimado por SPYDER disminuye y la diferencia llega a ser de un 3%. En caso contrario, la diferencia existente entre el tiempo real y el tiempo manual es de 46%, por lo que se puede decir que hubo una mala estimación de tiempo por parte del alumno encargado de realizar la estimación.

Para el caso del proyecto 87, en donde se encuentra almacenada la información de

los proyectos: Proyecto81, Proyecto82, Proyecto83, Proyecto84, Proyecto85 y el Proyecto86 la diferencia entre el tiempo real y el estimado por SPYDER disminuye y es del 2.5%. En el caso de la diferencia existente entre el tiempo real y el manual, es de 8% lo que permite pensar que en este caso el alumno encargado de realizar estimación se acercó a los valores reales, pero este resultado no necesariamente garantiza que siempre se vayan a obtener valores cercanos a lo realmente da como resultado un proyecto.

80


El caso de prueba 10, afirma la hipótesis planteada en la sección 1.7 de este documento, la cual menciona que al realizar la estimación de tiempo en cada actividad utilizando una base de datos que contiene datos históricos de proyectos realizados anteriormente, se mejora la planeación de proyectos de software dando estimaciones de tiempo y recursos más reales y confiables.

En el caso de los cálculos realizados a juicio del administrador de proyectos, se

observa que no son consistentes porque del proyecto81 al proyecto84 hay una diferencia muy grande que es del 27% y en el caso de SPYDER auque el incrementó del proyecto84 al proyecto87 fue pequeño del 0.5% sigue incrementando su acercamiento al tiempo real.

También se afirma que es posible estimar el tiempo de las actividades de un proyecto de software con los datos históricos de proyectos realizados como se demostró en la aplicación del caso de prueba 7.

5.2 Trabajos Futuros Los trabajos que pueden ser de gran ayuda para solucionar problemas no resueltos en esta tesis y que contribuirán a fortalecer este trabajo de tesis son: 1. Agregar un módulo de estimación de costos. 2. Utilizar el marco estadístico desarrollado por el grupo de ingeniería de software del

cenidet, para que se tenga otra perspectiva de cálculo. 3. Transformar esta herramienta como servicio Web, debido a la facilidad que pueden

tener los desarrolladores de acceder al sistema SPYDER y que éste no se encuentre alojado en su computadora.

4. Otro punto importante es incluir en SPYDER el manejo de catálogos de actividades estandarizadas por dominio de aplicaciones de planes de proyectos

5. Considerar en el algoritmo de estimación de tiempo otros factores que pueden afectar dicha estimación.

81

ANEXO A _________________________________________________________________________

Anexo A En este Anexo, se muestra la información generada por SPYDER y que se utilizó para comprobar la hipótesis1.

Figura 6.1 Pantalla de captura del Plan de Proyecto para el Proyecto81.

Figura 6.2 Pantalla del comparativo del tiempo real y manual por actividades del Proyecto81.

82

ANEXO A _________________________________________________________________________

Figura 6.3 Pantalla del comparativo del tiempo real y manual del tiempo total del Proyecto81.


83

ANEXO A _________________________________________________________________________



84

ANEXO A _________________________________________________________________________



85

ANEXO A _________________________________________________________________________


86

ANEXO B _________________________________________________________________________

Anexo B En este Anexo, se encontrarán algunos métodos utilizados en el desarrollo de SPYDER para la asignación de precedencias, la búsqueda en la BD y la Gráfica de regresión. Método Precedencias. void CPracticaView ::Precedencias() {// variables utilizadas en precedencias CString fecha; Fechas f; char Texto[10]; int j=1; int tipo; int num_act_pres, valor, ya_esta; // número de actividad que le precede CString fecha_inicio,fecha2,auxiliar,auxiliar2,te; int pres[100][15]; fecha_inicio=fecha2=auxiliar=auxiliar2=""; ya_esta=0; Act_Previas ap; int renglon_actual; renglon_actual=m_actividades.GetRow(); for(int i=0;i<renglon_actual-1;i++) { ap.nom_act[i]=m_actividades.GetTextMatrix(j,1); j++; } ap.no_se_cancelo==0; ap.total_act=renglon_actual-1; ap.DoModal(); modificar_precedencias=0; if(ap.no_se_cancelo==1) { modificar_precedencias=1; num_act_pres=ap.actividad;// obtiene el núm. de activ. la cual precede // despliege de el número en pantalla de la precedencia tipo=strtol(ap.tipo,NULL,10); itoa(num_act_pres,Texto,10); te=Texto; // para agregar al número de la precedencia el tipo //para que el usuario visualice el tipo de realcion que tienen las actividades switch(tipo) { case 1:te+="ii";break; case 2:te+="fi";break;

87

ANEXO B _________________________________________________________________________

case 3:te+="ff";break; } // para saber si ya tiene otra precedencia auxiliar=m_actividades.GetTextMatrix(renglon_actual,7); // si ya tiene otra agregar la nueva nada mas size_t num=0; if(auxiliar!="") { ya_esta=0;//band para saber si la precedencia está en la lista i=0; j=0; auxiliar2=""; num= strlen(auxiliar);// se optiene la longitud de la cadena // para recorrer la cadena que tiene los núm. de las preced. while (i<num)// mientras no se llegue al fin de la cadena { if(auxiliar.GetAt(i)!=',') auxiliar2+=auxiliar.GetAt(i); // se recorre la cadena hasta que encuentre una coma if(auxiliar.GetAt(i)==','||i==num-1) // se convierten a enteros valor=strtol(auxiliar2,NULL,10); // se agrega a un arreglo las preced. de esta activ. pres[renglon_actual][j]=valor; pres[renglon_actual][0]++; j++; // si ya se encuentra el núm. en la lista de precedencias // se hace la bandera 1 if(valor==num_act_pres) { ya_esta=1; AfxMessageBox("No se puede enlazar una

actividad predecesora dos veces a la misma sucesora");

return; } auxiliar2=""; // se borra los elem. de la cad.

Auxiliar para concatenar el nuevo valor hasta encontrar otra coma

} i++; } } else { //*** guardamos el tipo en el arreglo**// if(tipo_precedencia[renglon_actual]!="")

88

ANEXO B _________________________________________________________________________

{ auxiliar2=","+ap.tipo; tipo_precedencia[renglon_actual] = tipo_precedencia[renglon_actual] + auxiliar2; } else tipo_precedencia[renglon_actual]=ap.tipo; } /// si no esta el elemento en pantalla if(ya_esta==0&&auxiliar!="") { auxiliar2=""; // guardar el tipo en el arreglo if(tipo_precedencia[renglon_actual]!="") { auxiliar2=","+ ap.tipo; tipo_precedencia[renglon_actual] = tipo_precedencia[renglon_actual] + auxiliar2; } else tipo_precedencia[renglon_actual]=ap.tipo; auxiliar+=","; auxiliar+=te; m_actividades.SetTextMatrix(renglon_actual,7,auxiliar); m_actividades.SetCol(7);// es en la columna no. 5 m_actividades.SetText(auxiliar); m_actividades.SetCellAlignment(1); m_actividades.SetCol(1);// agrega el numero corrido hacia la izqu } /// si no hay elementos en pantalla if(auxiliar=="") { Modifica_Presc__modi_fechafin();// actualizar las fechas de las precedencias m_actividades.SetTextMatrix(renglon_actual,7,te); m_actividades.SetCol(7);// es en la columna no. 5 m_actividades.SetText(te); m_actividades.SetCellAlignment(1); m_actividades.SetCol(1);// agrega el num. recorrido hacia la izq. } }// fin del if 3 if(num_act_pres>0&&ya_esta==0) { Actualizacion_Fechas_TipoPrecedencia(tipo,renglon_actual,num_act_pres); Modifica_Presc__modi_fechafin();// actualizar las fechas de las preced. } }// fin función de precedencias

89

ANEXO B _________________________________________________________________________

Método Regresión Lineal. void Asignacion_Rec_Hum::Regresion_Lineal(int element) { if(element==0) { if(AfxMessageBox("No se cuenta con conocimiento suficiente para calcular la duracion, se tendra que hacer manualmente ",MB_OKCANCEL)== IDOK) { Duracion_Act da; da.DoModal(); if(da.se_cancelo==0&&da.duracion!="") { duracion=da.duracion; m_duracion=duracion; UpdateData(false); manual=true; } } } else { UpdateData(TRUE); AfxMessageBox("Se hace la regresion por que si hay elementos para hacerla"); Coordenadas.PMAX=0;//INICIALIZA XMAX Coordenadas.PMAY=0;//INICIALIZA Y MAX //SE SELECCIONAN LAS X Y Y MAXIMAS for(int i=0;i<Coordenadas.TPuntos;i++) { if(Coordenadas.PMAX<Coordenadas.CPunto[i].x) Coordenadas.PMAX=Coordenadas.CPunto[i].x; if(Coordenadas.PMAY<Coordenadas.CPunto[i].y) Coordenadas.PMAY=Coordenadas.CPunto[i].y; } char ex[10]; strcpy(ex,m_LDC); Coordenadas.pd1=atoi(ex); if (Coordenadas.pd1>10000) { MessageBox("El programa no puede graficar puntos mayores a 10000 unidades", "ERROR AL GRAFICAR", MB_ICONSTOP); GetDlgItem(IDC_GRAFICAR_REGRESION)->ShowWindow(false); } else GetDlgItem(IDC_GRAFICAR_REGRESION)->ShowWindow(true); Coordenadas.escodigo=escodigo; //SE CALCULA LA DURACION // Coordenadas.Calculo_Duracion();

90

ANEXO B _________________________________________________________________________

//SE SELECCIONAN LAS X Y Y MAXIMAS TOMANDO EN CUENTA LA X Y Y DEL ELEMENTO CALCULADO if(Coordenadas.PMAX<Coordenadas.pd1) Coordenadas.PMAX=Coordenadas.pd1; if(Coordenadas.PMAY<Coordenadas.pd2) Coordenadas.PMAY=Coordenadas.pd2; if (Coordenadas.a1>Coordenadas.PMAY) Coordenadas.PMAY=Coordenadas.a1; itoa(Coordenadas.pd2,ex,10); m_duracion=ex; m_duracion+= " dias"; char tex[10]; CString texto; if(Coordenadas.pd2<=0) { promedio_total=promedios_regre[0][0]/promedios_regre[0][1]; if(unidades2*promedio_total<=0) texto+="1 dia"; else { itoa(int(unidades2*promedio_total),tex,10);// se multiplica la duración promedio por el número de unidades seleccionadas texto=tex; texto+=" dias"; // se despliega la duración m_duracion=texto; UpdateData(false); } duracion=texto; GetDlgItem(IDC_GRAFICAR_REGRESION)->ShowWindow(false); } //MessageBox("El valor introducido para calcular la duración\nno se visualizará debido a que el número dado es\nmucho mayor que los valores estándar de la regresión,\npor lo tanto la operación retornará un valor negativo","ERROR", MB_ICONSTOP); UpdateData(FALSE); } }

91

Dedicatorias

A mi mamá, Irma Alcalá de Aguilar. Por darme tu amor, apoyo y motivación para poder concluir este trabajo. Eres la

mejor mamá del mundo. Te quiero.

A mi papá, Luis Aguilar Martínez. Por enseñarme lo importante que es ser responsable en lo que realices. Te

quiero.

A mi pequeña hija, Marissa. Preciosa, a pesar de tu corta edad, siempre me has demostrado tener

perseverancia y seguridad en ti, tu excelente desempeño académico es el motivo más grande que he tenido para concluir este trabajo, ¿Cómo decirte ya no puedo,

si tu si puedes?. Te quiero nena.

A mi esposo Jaime Hernández León. Por darme tu apoyo, amor y espacio para poder concluir una etapa que estaba

pendiente. Eres muy especial. Te amo.

Agradecimientos.

A Dios, por darme la vida y permitirme vivir este momento. Al CONACYT y a la SEP, por brindarme apoyo económico como becaria, porque sin ese gran apoyo no hubiera sido posible realizar mis estudios de Maestría. Al Centro Nacional de Investigación y Desarrollo Tecnológico CENIDET, y a todo el personal que labora en ésta institución, por el amable trato que siempre he recibido a lo largo de mis estudios. Al Tecnológico de Ciudad Madero, por permitirme formar parte de ésta gran Institución. A mi director de tesis, Dr. Máximo López Sánchez y mi codirectora de tesis M.C. Eurí Salgado Escobar, por haberme dado la oportunidad y la confianza de trabajar con ellos y compartir sus experiencias, conocimientos consejos y una amistad. Al comité revisor Dr. René Santaolaya Salgado, M.C. Felipe de Jesús Alaníz Quezada y M.C. Olivia Graciela Fragoso Díaz, por su tiempo, comentarios y sugerencias realizadas a éste trabajo de tesis una gran contribución para que se enriqueciera, mil gracias. A la Lic. Flora Alicia González Jiménez, por haberme apoyado para que mis viajes a CENIDET fueran mas relajados, sin tener que preocuparme tanto por el dinero. A mis hermanos, porque siempre me han puesto la etiqueta de “inteligente” sin merecérmelo, un punto más que me motivó a seguir con mis estudios para no defraudarlos a pesar de la gran pausa que hice. A mis compañeros de generación, por compartir grandes momentos. Claudia I. Claudia N. Yasmín, Antolino, Jose Antonio, Miguel ,Italo, Fortino, Javier y Carlos. A Maty, gracias por tu apoyo, por ofrecerme tu casa, te aprecio mucho eres una excelente persona. A mis amigas:

Eurí. Por creer en mi todo el tiempo y siempre darme ánimos. Gracias por ser así, no cambies. Taide, Tus pláticas me ayudaron a tranquilizarme en momentos de tensión sin que lo supieras. Gracias por tu tolerancia. Elizabeth. A pesar del poco tiempo de conocernos me alegra saber que tenemos mucho en común, pero me falla el orden y administración de tiempo algo que tengo que poner en práctica.

A Enrique, por ser un buen amigo y la primera persona que conocí en Cuernavaca, recuerdo las reuniones en casa de Don Marcelo, el cantar “Tampico Hermoso” en compañía de Claudia y Yasmín, fue divertido. Disfruta de la vida feliz en compañía de tu esposa e hijo. A Ana María, gracias por mostrarme siempre una sonrisa y por enseñarme que cuando uno desea en realidad algo lo logra brincando los obstáculos que te encuentres en el camino. A mis compañeros del Tecnológico de Ciudad Madero en estricto orden alfabético: Alma, Ana V., Apolinar, Araceli., Armando, Arquímides, Betty, Carmen de la C., Carmen, Clarita, Denisse, Edna, Elizabeth, Eurí, Fraire, Gil, Guille, Jaime C., Javier B., José A,, Laura C., Laura V., Laura Vargas., Martha Ch., Martha M.,Peralta, Taide, Trejo, y Victor Por compartir momentos, experiencias y hacer agradable el ambiente durante mi desarrollo del trabajo de tesis. A Etelvina, Adriana y Marco, por su amistad, sinceridad y apoyo, sin ustedes no lo hubiera logrado de la misma manera. A Alma y a Gil, gracias por apoyarme con los trámites que necesitaba. A Bárbara, amiga gracias por tu gran apoyo, confianza y fuerza que me diste contribuiste grandemente sin saberlo. De las nuevas generaciones del cenidet, Mariana y Armando siempre tan amables y tratando de ayudar, es tan agradable conocer personas así, que te hacen sentir en confianza, no cambien. A cada uno de ustedes que han formado parte de mi vida, gracias porque he aprendido cosas de cada uno que me han servido y me han motivado a concluir éste trabajo de tesis.

¡ MIL GRACIAS!.

Resumen. Una de las actividades más importantes en el proceso de desarrollo de software es la planeación del proyecto, pues en esta actividad recae el compromiso de especificar una fecha de entrega al cliente, así como la especificación de los recursos a utilizar y por consecuencia el costo de construcción del proyecto. El reto principal al que se enfrenta el administrador de proyectos, es coordinar y controlar los recursos disponibles para desarrollar software de calidad con restricciones de tiempo y un costo mínimo. Esto puede parecer una tarea fácil, pero el uso óptimo de los recursos es una de las tareas más complejas que puedan existir. Muchos administradores de proyectos están reacios a diseñar un plan de proyecto. Uno de los motivos por los que no se prepara un plan de proyecto, es porque requiere de un esfuerzo adicional, toma mucho tiempo y cuesta mucho dinero. Pero el plan de proyecto es un medio para evitar realizar acciones innecesarias o erróneas e ignorar acciones necesarias y permite visualizar dificultades potenciales que pueden aumentar el costo y tiempo de desarrollo del proyecto. Los administradores de proyectos sienten que pueden manejar cualquier eventualidad que se presente, pues la experiencia que poseen les permite tomar decisiones al momento. Desafortunadamente, estas adversidades afectan el desempeño del desarrollo del software y reducen la efectividad del equipo de trabajo. En este trabajo se propone una estrategia que permite mejorar los tiempos estimados para el desarrollo de las actividades de un proyecto, mejorar la precisión de la fecha de entrega, y ajustarse al presupuesto establecido, obteniendo así un software con calidad y un cliente satisfecho con el sistema. Como parte de la investigación se ha desarrollado un Sistema para la Planeación y Desarrollo de Proyectos (SPYDER), el cual proporciona una característica adicional de la que proporcionan los sistemas administradores de proyectos existentes en el mercado. SPYDER realiza el cálculo automático de la estimación de tiempo utilizando el método de análisis de regresión. Básicamente, el administrador de proyectos utiliza su experiencia y buen juicio para realizar estimaciones de tiempo, también puede revisar la información de proyectos que haya desarrollado, pero debe tener cuidado de que los datos que revise hayan sido actualizados. En los proyectos anteriores, hay mucha información para mejorar la estimación de nuevos proyectos, pero esta información debe ser obtenida en forma manual. Cada error que se cometa en la estimación del tiempo, cada falta u omisión, causa retrasos en la fecha de entrega, además de un trabajo adicional (no considerado en el plan original) para los participantes en el desarrollo del sistema. Sin información histórica, la estimación es más propensa a errores. Si se utilizan registros de tiempos de actividades anteriores, la estimación de costos, se puede mejorar.

ABSTRACT One of the main activities in the process of software development is the planning of the project, since the commitment to a date of delivery to the customer rests on this activity, as also does the specification of the resources used and, consequently, the cost of the project. The main challenge with which a project manager is confronted is to coordinate and control the resources that are available to develop a quality software with time restrictions and at a minimum cost. This may seem an easy task, but the optimum use of the resources is one of the most complex tasks that can exist. Many project managers are reluctant to design a project plan. One of the reasons for not preparing a project plan is that it requires additional effort, takes considerable time and costs a significant amount of money. But the project plan is a means of prevent carrying out unnecessary or erroneous actions and it allows visualizing potential difficulties that can increase the cost and duration of the development of the project. Project managers feel that they can handle any event that may occur, because the experience they possess allows them to make decisions "on the fly". Unfortunately, these adversities have an effect on the performance of software construction and reduce the effectiveness of the workgroup. In this work, a strategy is proposed which allows reducing the estimated period required to complete the development of the activities of a project, improve the precision of the delivery date, and to work within an established budget, in this way obtaining a quality software and a customer who is satisfied with the system As part of the research work, a system for project planning and development (SPYDER) has been developed; this system presents an additional feature which is not present in project managers currently in the market. SPYDER carries out the automatic computation of the time estimation using regression analysis. Basically, the project manager uses his experience and good judgment to carry-out time estimations; he/she can also review the information regarding the projects that he/she has developed, but must be careful that the data has been updated. In the previous projects, there is a lot of information to improve the estimation of the new projects, but this information has to be obtained manually. Each mistake made in the time estimation, each error or omission, causes delays in the delivery date, apart from additional work (not considered in the original plan) for participants in the development of the system. Without historic information, the estimation is more error-bound. If the time records of previous activities are used, the estimation of costs can be improved.

Documents

S.E.P. S.E.S.T. D.G.E.S.T. - CENIDET - Centro …...3.8 Desarrollo del módulo de estimación de tiempo 46 3.9 Descripción de la herramienta 47 3.10 Búsqueda en la base de datos