UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI)

DISEÑO DEL SISTEMA INFORMÁTICO PARA EL SEGUIMIENTO DE LAS TAREAS DE DESARROLLO Y DE ASEGURAMIENTO DE LA CALIDAD EN PROYECTOS INFORMÁTICOS PARA LA EMPRESA ABSOLUTEC S. A.

GABRIEL VILLALOBOS MOLINA

PROYECTO FINAL DE GRADUACION PRESENTADO COMO REQUISITO PARCIAL PARA OPTAR POR EL TITULO DE MÁSTER EN ADMINISTRACIÓN DE PROYECTOS.

San José, Costa Rica Setiembre, 2009

UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI)

Este Proyecto Final de Graduación fue aprobado por la Universidad como Requisito parcial para optar al grado de Máster en Administración de Proyectos

_________________________ PROF. FABIO MUÑOZ, MAP

________________________________________ PROF. FAUSTO FERNÁNDEZ MARTÍNEZ, MAP

______________________________________ PROF. BERNARDO LÓPEZ GONZÁLEZ, MAP

____________________________ GABRIEL VILLALOBOS MOLINA

ii

DEDICATORIA Le doy gracias a Dios por todo lo que me ha dado en esta vida; por mi madre quien me ha brindado su amor, educación y estudio; por mi padre quien en vida me enseñó la convicción, la solidaridad y el esfuerzo, y que aún me apoya y acompaña; por mi familia que me ha tendido su mano y me han ayudado a seguir un buen camino; y por mi novia quien me ha brindado su gran cariño, apoyo y comprensión para seguir adelante. A todos ellos a quienes Dios ha puesto en mi camino les dedico este Proyecto Final de Graduación.

iii

RECONOCIMIENTOS A Fabio Muñoz Jiménez, mi tutor de tesis, por todos sus aportes, interés y guía para la realización de este proyecto final. A todos los profesores, compañeros y personal de la UCI, quienes fueron parte vital en este proceso de maestría. A Marco Sojo Fernández, Administrador de Proyectos de Prides S.A, por todos sus consejos y confianza brindada en la Administración de Proyectos. A Ricardo Castro Jiménez, compañero y amigo, por todo su aporte en la realización de este proyecto.

iv

INDICE DE CONTENIDO

RESUMEN EJECUTIVO………………………………………………………………….…xi 1.

2.

INTRODUCCIÓN ................................................................................................. 1 1.1.

Antecedentes ................................................................................................. 1

1.2.

Problemática .................................................................................................. 2

1.3.

Justificación .................................................................................................... 4

1.4.

Objetivos ........................................................................................................ 4

1.4.1.

Objetivo General ...................................................................................... 4

1.4.2.

Objetivos Específicos ............................................................................... 5

MARCO TEORICO ............................................................................................... 6 2.1.

Marco Referencial Institucional ...................................................................... 6

2.1.1. 2.2.

Administración de Proyectos .......................................................................... 7

2.2.1.

Gestión del Alcance ............................................................................... 10

2.2.2.

Gestión del Tiempo ................................................................................ 12

2.2.3.

Gestión de la Calidad............................................................................. 13

2.3.

3.

Absolutec S.A. ......................................................................................... 6

Ingeniería de Software ................................................................................. 16

2.3.1.

Metodologías de Desarrollo de Software ............................................... 17

2.3.2.

Orientación a Objetos ............................................................................ 19

2.3.3.

Lenguaje Unificado de Modelado (UML) ................................................ 20

2.3.4.

Diseño de Bases de Datos .................................................................... 26

Marco Metodológico ........................................................................................... 28

v

3.1.

3.1.1.

Reuniones .............................................................................................. 28

3.1.2.

Entrevistas ............................................................................................. 29

3.2.

Herramientas metodológicas para definir el alcance .................................... 29

3.2.1.

EDT........................................................................................................ 29

3.2.2.

Reuniones .............................................................................................. 29

3.3.

Herramientas metodológicas para definir el tiempo ..................................... 30

3.3.1.

Reuniones .............................................................................................. 30

3.3.2.

Software ................................................................................................. 30

3.4.

Herramientas metodológicas para definir la calidad ..................................... 30

3.4.1.

Reuniones .............................................................................................. 30

3.4.2.

Estándares de Programación................................................................. 30

3.5.

4.

Tipo de investigación .................................................................................... 28

Herramientas metodológicas para el desarrollo del proyecto ....................... 31

3.5.1.

Metodologías de diseño ......................................................................... 31

3.5.2.

Software ................................................................................................. 31

DESARROLLO ................................................................................................... 32 4.1.

Plan de Gestión del Alcance ........................................................................ 32

4.1.1.

Planificación del Alcance ....................................................................... 32

4.1.2.

Definición del Alcance............................................................................ 34

4.1.3.

Estructura Detallada de Trabajo (EDT) .................................................. 36

4.1.4.

Diccionario de la EDT ............................................................................ 36

4.2.

Plan de Gestión del Tiempo ......................................................................... 39

4.2.1.

Definición de las actividades .................................................................. 39

4.2.2.

Secuenciamiento de las actividades ...................................................... 41

4.2.3.

Duración de las actividades ................................................................... 41

vi

4.2.4.

Creación del cronograma ....................................................................... 41

4.2.5.

Asignación de recursos .......................................................................... 42

4.3.

Herramientas para el Control de la Calidad.................................................. 42

4.4.

Diseño del Sistema Informático de Apoyo al Desarrollo (SIAD) ................... 43

4.4.1.

Requerimientos del Sistema Informático de Apoyo al Desarrollo .......... 43

4.4.2.

Análisis de Requerimientos ................................................................... 48

4.4.3.

Diagrama de Clases .............................................................................. 48

4.4.4.

Diagrama de Bases de Datos ................................................................ 49

4.4.5.

Casos de Uso ........................................................................................ 49

4.4.6.

Diagramas de Secuencia ....................................................................... 50

4.5.

Guía de Uso para las Herramientas de Calidad ........................................... 50

5.

CONCLUSIONES ............................................................................................... 52

6.

RECOMENDACIONES ...................................................................................... 54

7.

Bibliografía ......................................................................................................... 56

8.

ANEXOS ............................................................................................................ 58 8.1.

Anexo 1. Acta de Constitución del Proyecto................................................. 58

8.2.

Anexo 2. EDT ............................................................................................... 61

8.3.

Anexo 3. Cronograma .................................................................................. 62

8.4.

Anexo 4. Lista Chequeo para Análisis de Requerimientos ........................... 63

8.5.

Anexo 5. Lista de Chequeo para Casos de Uso ........................................... 64

8.6.

Anexo 6. Lista de Chequeo para Diagrama de Clases ................................. 65

8.7.

Anexo 7. Lista de Chequeo para Diagramas de Secuencia ......................... 66

8.8.

Anexo 8. Lista de Chequeo para el Modelo Base Datos .............................. 67

8.9.

Anexo 9. Lista de Chequeo para Documentos Entregables ......................... 68

8.10.

Anexo 10. Análisis de Requerimientos ...................................................... 69

vii

8.11.

Anexo 11. Diagrama de Clases del SIAD.................................................. 87

8.12.

Anexo 12. Diagrama de Casos de Uso ..................................................... 88

8.13.

Anexo 13. Ejemplos de Casos de Uso ...................................................... 89

8.14.

Anexo 14. Ejemplo de Diagramas de Secuencia ...................................... 96

viii

INDICE DE FIGURAS Figura 2.1 Organigrama de Absolutec S.A. ................................................................. 6 Figura 2.2 Áreas de conocimiento del PMBOK (PMI, 2004) ...................................... 10 Figura 2.3 Modelo de Cascada de Desarrollo de Software ....................................... 18 Figura 2.4 Modelo de Espiral de Desarrollo de Software .......................................... 19 Figura 2.5 Diagrama de Casos de Uso (Jacobson, 1999) ......................................... 24 Figura 2.6 Diagrama de Clases (Jacobson, 1999) .................................................... 25 Figura 2.7 Diagrama de Secuencia (Jacobson, 1999) ............................................... 26 Figura 4.1 Estructura Detallada de Trabajo (EDT) .................................................... 33

ix

INDICE DE CUADROS Cuadro 2.1 Diagramas de UML (Jacobson, 1999) .................................................... 22 Cuadro 2.2 Concepto de Tabla.................................................................................. 27 Cuadro 4.1 Diccionario de la EDT ............................................................................. 37 Cuadro 4.2 Listado de Actividades ............................................................................ 39 Cuadro 4.3 Listado de Casos de Uso ........................................................................ 49 Cuadro 4.4 Guía de Uso para las Herramientas de Control de Calidad .................... 50

INDICE DE ABREVIATURAS

SIAD: Sistema Informático de Apoyo al Desarrollo. EDT: Estructura Detallada de Trabajo. CMM: Siglas en inglés del Modelo de Madurez de Capacidades (Capability Maturity Model). CAMTIC: Cámara Costarricense de Tecnologías de Información y Comunicación. TIC: Tecnología de Información y Comunicación. PMI: Siglas en inglés del Instituto de

Administración de Proyectos (Project

Management Institute). SEI: Siglas en inglés del Instituto de Ingeniería de Software (Software Engineering Institute). UML: Siglas en inglés del Lenguaje Unificado de Modelado (Unified Modeling Language). UCI: Universidad para la Cooperación Internacional.

x

RESUMEN EJECUTIVO Absolutec S.A es una empresa dedicada al desarrollo de software que desde su fundación en el 2001 ha desarrollado sistemas de información para diferentes compañías a nivel nacional, mediante un compromiso de calidad cuya prioridad es satisfacer las necesidades de sus clientes. Como parte de sus objetivos está el mejoramiento continuo de sus estándares y procesos de desarrollo interno, de modo que le permita cumplir a cabalidad con las exigencias del mercado tecnológico. Para la empresa es sumamente importante conocer la situación real de los proyectos para determinar acciones preventivas o correctivas. También es de gran importancia para Absolutec minimizar la cantidad de incidencias que reportan los clientes en las etapas de prueba de los sistemas, así como mejorar los tiempos de respuesta de manera interna y frente al cliente. La idea del proyecto surge a partir de la necesidad de ese mejoramiento continuo, de responder con las mejores herramientas tecnológicas a los esfuerzos que se desarrollan para el fortalecimiento de la administración de los proyectos informáticos, principalmente en las áreas de la administración del alcance, administración del tiempo, y administración de la calidad. La herramienta tecnológica diseñada como producto de este proyecto permitirá conocer de manera más precisa el estado de avance real del proyecto de forma inmediata, lo que facilitará a líderes técnicos y administradores de proyectos el manejo de las diferentes situaciones que suceden en los proyectos, y la elaboración de propuestas para las acciones que se deben seguir. Del mismo modo, facilitará el suministro de datos estadísticos a la gerencia para la toma de decisiones según el plan estratégico de la empresa. En el proyecto se desarrollaron los siguientes objetivos: Elaborar el Plan de Gestión del Alcance para las etapas de Análisis y Diseño del SIAD, Realizar un Plan de Gestión del Tiempo para las etapas de Análisis y Diseño del Sistema SIAD, Diseñar herramientas para controlar la calidad del proceso en las etapas de Análisis y Diseño del Sistema SIAD, Realizar el levantamiento de requerimientos del SIAD a través de la recopilación de las necesidades que expresan los directores de proyectos y líderes técnicos de Absolutec S. A. y Elaborar el documento de diseño del SIAD, como base para un posterior desarrollo, implantación y uso en los proyectos desarrollados en Absolutec S.A. Para alcanzar estos objetivos se utilizó una metodología de investigación mixta mediante el método de observación por entrevista y el método analítico sintético. Se realizaron entrevistas y reuniones con líderes técnicos, administradores de proyectos y personal del área de calidad para la definición del alcance, de los tiempos y de las herramientas de calidad. Las entrevistas fueron claves para la recolección de los datos y las reuniones fundamentales para analizar las necesidades de Absolutec S.A. y llevar a cabo el proyecto. Adicionalmente, se usaron metodologías de diseño de software y estándares de diseño de bases de datos para la ejecución del

xi

proyecto, además de la utilización de listas de chequeo para asegurar la calidad y completitud del diseño final. Entre las conclusiones obtenidas producto del desarrollo de este proyecto se tiene que su realización permitió consolidar los procesos de Administración de Proyectos y Calidad de Software, que el Plan de Gestión del Alcance permitió definir claramente los alcances del proyecto, que la EDT es una herramienta que permitió dar a todos los miembros del proyecto una visión global y estandarizada de los entregables y estructura del proyecto, que el Plan de Gestión del Tiempo debe de tomar en cuenta el criterio de personal técnico, que las lecciones aprendidas en proyectos anteriores fueron de suma importancia en la realización de este proyecto, que la definición de métricas y estándares de calidad son vitales para el desarrollo de sistemas de software, y que la correcta planificación del proyecto permitió conceptualizar una herramienta que subsanara las deficiencias en el desarrollo de proyectos informáticos. Como último punto se desarrollaron una serie de recomendaciones al personal de Absolutec. A los administradores de proyectos se les recomendó utilizar la EDT, tomar en cuenta al personal técnico al momento de desarrollar estimación de tiempo y asegurarse de que los desarrolladores tengan acceso al cronograma. Al Departamento de Calidad se le recomendó la tomar como modelo en los diferentes proyectos de Absolutec el plan de gestión de proyecto desarrollado, utilizar las listas herramientas de control de calidad desarrolladas y solicitar a los administradores de proyecto las lecciones aprendidas en cada proyecto para entregarlas al iniciar nuevos proyectos. Finalmente se le recomendó a la gerencia de Absolutec crear una base de datos con estimaciones históricas para cada tipo de actividad de desarrollo de software, iniciar un proyecto de implementación del SIAD y definir un proyecto de implantación del SIAD en cada uno de los proyectos a desarrollar en Absolutec.

xii

1

1. INTRODUCCIÓN 1.1. Antecedentes Absolutec S.A es una empresa dedicada al desarrollo de software. Su fundación fue en junio del 2001 y desde entonces ha desarrollado sistemas de información para diferentes compañías a nivel nacional. En Costa Rica el desarrollo de software es una de las actividades que ha visto uno de los mayores crecimientos, equiparándose con naciones altamente reconocidas en este campo como la India. Muchas empresas transnacionales principalmente estadounidenses han optado por mano de obra costarricense debido a estar altamente calificados y a la calidad del software que se desarrolla. Durante los últimos ocho años, Absolutec ha realizado grandes esfuerzos para desarrollar y mantener software de calidad y clientes altamente satisfechos, y poder mantenerse en este mercado tan competitivo. Los siguientes son los principales esfuerzos realizados en Absolutec: • En el año 2002 se empezaron a realizar documentos de estándares de desarrollo. • En el 2003 se realizaron plantillas para la documentación que se les presenta a los clientes y utilizados en las etapas de levantamientos de requerimientos y pruebas de los sistemas. • En el 2006 se creó el departamento de calidad, el cual tuvo como objetivo medir el trabajo de los administradores de proyecto y servir de apoyo a éstos; así también de brindar reportes y recomendaciones a la gerencia. • En el 2007 el departamento de calidad inició un análisis de la empresa para poder iniciar un proceso de certificación CMM. • A principios del 2008 se creó la figura del líder técnico, como una forma de guiar al equipo de desarrollo desde una perspectiva técnica y apoyar al

2 administrador del proyecto en las decisiones y estimaciones que requieren un criterio técnico. • A finales del 2008 se coordinó realizar reuniones periódicas con los líderes técnicos de cada proyecto, con el fin de documentar las mejores prácticas realizadas en cada proyecto y así mejorar el tiempo y la calidad con la que se realizan los proyectos.

1.2. Problemática A pesar de estos esfuerzos, la gerencia de Absolutec reconoce que presenta serios problemas con los resultados obtenidos en la mayoría de los proyectos realizados: • Proyectos hasta con un 70% de atraso que aumentan los costos del proyecto. • Tiempos excesivos empleados en el retrabajo de funcionalidades en los sistemas, tanto por mala definición de los requerimientos como por errores detectados en las etapas de prueba. • Problemas financieros al no poder hacer efectivo el cobro de las facturas a los clientes debido a dichos atrasos. • Insatisfacción por parte de los clientes al extenderse los plazos y al ver la cantidad de errores detectados. • Insatisfacción del personal debido a la presión ejercida al haber muy poco tiempo y mucho por completar, teniendo que trabajar extras, muchas veces sin pago debido a los problemas financieros. • Alta rotación de personal en la mayoría de proyectos provocando también atrasos en dichos proyectos. Uno de los aspectos analizados como consecuencia de estos resultados negativos es la falta de un detalle más profundo en la definición de los requerimientos y las funcionalidades de los sistemas. Este aspecto no es propio de Absolutec, sino del

3 desarrollo de software en general, principalmente cuando se tiene un cliente al cual se le desarrolla una solución de software. Es difícil visualizar todas las funcionalidades que puede tener un sistema en las etapas iniciales de análisis y diseño. Los clientes exponen sus necesidades y brindan la información necesaria para iniciar el análisis y diseño. Se realiza un prototipo donde el cliente tiene un contacto visual de lo que sería el sistema, expone casos de uso del sistema, ideas y mejoras para que sean tomadas en consideración. Pero no es hasta que sea desarrollado el sistema y hasta que se realicen las pruebas con datos y casos reales del día a día, cuando salen a la luz otras funcionalidades consideradas por el cliente como vitales, ajustes a las ya existentes o funcionalidades desarrolladas que no toman en cuenta casos específicos necesarios y que no fueron vistos durante el análisis; provocando la realización de tareas no planificadas y retrabajo de tareas antes realizadas que afectan los tiempos de entrega, lo cual provoca conflictos entre la empresa y el cliente. Hay otro aspecto que unido al anterior incrementa los problemas. La mala gestión de las comunicaciones durante el desarrollo de los proyectos es otra de las causas analizadas. El atraso en las tareas se va manejando con la holgura definida en el proyecto para la entrega de las etapas y cuando se realizan reuniones de seguimiento los administradores de proyectos indican que hay atrasos pero que aún son manejables dentro de la holgura establecida y que las metas si van a ser cumplidas. Pero llega un momento en que las tareas no planificadas y los tiempos de retrabajo consumen la holgura y afectan los tiempos de entrega. En la mayoría de los casos cuando la gerencia se entera, son pocas las posibilidades para tomar medidas correctivas: movilización de recursos internos para reforzar el equipo de trabajo serían una carga más para el equipo debido a la curva de aprendizaje que se necesita, implicaría más costos y afectaría otros proyectos que están en desarrollo. La alternativa viable más común es el trabajar horas extras, muchas veces hasta cuatro horas extra diarias, para poder salir con el trabajo, pero esto decae en el rendimiento y motivación del equipo de desarrollo.

4 El tercer aspecto analizado por la gerencia de Absolutec es la calidad del software que se desarrolla en términos de número de errores por funcionalidad de sistema, principalmente antes de que el cliente realice las pruebas del sistema. Los tiempos ajustados no permiten realizar revisiones adecuadas a las funcionalidades desarrolladas. También hay una falta de detalle en las tareas a desarrollar, muchas de las tareas definidas en el cronograma pueden tener un nivel de detalle mayor lo que puede facilitar el tener una lista de revisión de las funcionalidades. Cuando los sistemas son revisados por el cliente surgen una cantidad considerable de errores que impiden que el cliente pueda revisar muchas de las funcionalidades, aumentando los tiempos de revisión mientras se espera a que éstos sean corregidos y de paso aumentando la desconfianza del cliente en el desarrollo realizado.

1.3. Justificación La problemática descrita es la razón por la cual la gerencia de Absolutec ha visto la necesidad primordial de un sistema integral que le permita subsanar estas situaciones y mantenerse firme en el campo del desarrollo de software. La realización de este proyecto como tema de tesis responde a una necesidad generalizada en el desarrollo de software para mejorar las metodologías de desarrollo, principalmente para la especificación de los sistemas, plazos de cumplimiento y calidad de los productos finales. La ingeniería en sistemas es un área continuamente en cambio y que permite un sin número de posibilidades para quien quiere hacer uso de ella. El desarrollo de una herramienta que permita controlar y dar seguimiento a todos esos aspectos técnicos presentes en el desarrollo de software de una manera práctica y sencilla constituye un gran aporte a la comunidad del software, y en caso específico a Absolutec S.A.

1.4. Objetivos 1.4.1. Objetivo General

5 Realizar el Plan de Gestión del Alcance, el Plan de Gestión del Tiempo y Herramientas para el Control de la Calidad, para el diseño del Sistema Informático de Apoyo al Desarrollo (SIAD), la herramienta informática q

ue

apoyará

el

desarrollo de los sistemas informáticos que la empresa Absolutec S. A. elabora para sus clientes.

1.4.2. Objetivos Específicos •

Realizar el levantamiento de requerimientos del SIAD a través de la recopilación de las necesidades que expresan los directores de proyectos y líderes técnicos de Absolutec S. A.

•

Elaborar el documento de diseño del SIAD, como base para un posterior desarrollo, implantación y uso en los proyectos desarrollados en Absolutec S.A.

•

Elaborar el Plan de Gestión del Alcance para las etapas de Análisis y Diseño del Sistema SIAD.

•

Realizar un Plan de Gestión del Tiempo para las etapas de Análisis y Diseño del Sistema SIAD.

•

Diseñar herramientas para controlar la calidad del proceso en las etapas de Análisis y Diseño del Sistema SIAD.

6

2. MARCO TEORICO

2.1. Marco Referencial Institucional 2.1.1. Absolutec S.A. El marco de desarrollo del presente proyecto se ubica en la empresa de desarrollo de software Absolutec S.A. Es una mediana empresa donde la mayoría de sus empleados son ingenieros en computación, los cuales forman parte de una cartera de proyectos en desarrollo. La siguiente figura muestra el organigrama actual de la empresa.

Figura 2.1 Organigrama de Absolutec S.A.

Absolutec se desenvuelve en un mercado de desarrollo de software bastante competitivo, incursionando tanto en el sector público como en el privado. Es tal el crecimiento de este mercado en Costa Rica que es vital la figura de una entidad que

7 vele por el fortalecimiento de este sector, estamos hablando de la Cámara Costarricense de Tecnologías de Información y Comunicación.

2.2. Administración de Proyectos Según PMI (2004), “un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único” (p. 5). Absolutec se ha dedicado al desarrollo de proyectos informáticos desde el 2001 y realiza esfuerzos continuos para mejorar la dirección de sus proyectos. La dirección de proyectos es la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades de un proyecto para satisfacer los requisitos del proyecto. La dirección de proyectos se logra mediante la aplicación e integración de los procesos de dirección de proyectos de inicio, planificación, ejecución, seguimiento y control, y cierre. El director del proyecto es la persona responsable de alcanzar los objetivos del proyecto. (PMI, 2004) La Guía del PMBOK define 44 procesos en la dirección de proyectos divididos en nueve áreas de conocimiento. A continuación se explican brevemente las nueve áreas de conocimiento del PMBOK. •

Gestión de la Integración del Proyecto: describe los procesos y actividades que forman parte de los diversos elementos de la dirección de proyectos, que se identifican, definen, combinan, unen y coordinan dentro de los Grupos de Procesos de Dirección de Proyectos. Se compone de los procesos de dirección de proyectos Desarrollar el Acta de Constitución del Proyecto, Desarrollar el Enunciado del Alcance del Proyecto (Preliminar), Desarrollar el Plan de Gestión del Proyecto, Dirigir y Gestionar la Ejecución del Proyecto, Supervisar y Controlar el Trabajo del Proyecto, Control Integrado de Cambios y Cerrar Proyecto.

•

Gestión del Alcance del Proyecto: describe los procesos necesarios para asegurarse de que el proyecto incluya todo el trabajo requerido, y sólo el trabajo

8 requerido, para completar el proyecto satisfactoriamente. Se compone de los procesos de dirección de proyectos Planificación del Alcance, Definición del Alcance, Crear EDT, Verificación del Alcance y Control del Alcance. •

Gestión del Tiempo del Proyecto: describe los procesos relativos a la puntualidad en la conclusión del proyecto. Se compone de los procesos de dirección de proyectos Definición de las Actividades, Establecimiento de la Secuencia de las Actividades, Estimación de Recursos de las Actividades, Estimación de la Duración de las Actividades, Desarrollo del Cronograma y Control del Cronograma.

•

Gestión de los Costes del Proyecto: describe los procesos involucrados en la planificación, estimación, presupuesto y control de costes de forma que el proyecto se complete dentro del presupuesto aprobado. Se compone de los procesos de dirección de proyectos Estimación de Costes, Preparación del Presupuesto de Costes y Control de Costes.

•

Gestión de la Calidad del Proyecto: describe los procesos necesarios para asegurarse de que el proyecto cumpla con los objetivos por los cuales ha sido emprendido. Se compone de los procesos de dirección de proyectos Planificación de Calidad, Realizar Aseguramiento de Calidad y Realizar Control de Calidad.

•

Gestión de los Recursos Humanos del Proyecto: describe los procesos que organizan y dirigen el equipo del proyecto. Se compone de los procesos de dirección de proyectos Planificación de los Recursos Humanos, Adquirir el Equipo del Proyecto, Desarrollar el Equipo del Proyecto y Gestionar el Equipo del Proyecto.

•

Gestión de las Comunicaciones del Proyecto: describe los procesos relacionados con la generación, recogida, distribución, almacenamiento y destino final de la información del proyecto en tiempo y forma. Se compone de los procesos de dirección de proyectos Planificación de las Comunicaciones,

9 Distribución de la Información, Informar el Rendimiento y Gestionar a los Interesados. •

Gestión de los Riesgos del Proyecto: describe los procesos relacionados con el desarrollo de la gestión de riesgos de un proyecto. Se compone de los procesos de dirección de proyectos Planificación de la Gestión de Riesgos, Identificación de Riesgos, Análisis Cualitativo de Riesgos, Análisis Cuantitativo de Riesgos, Planificación de la Respuesta a los Riesgos, y Seguimiento y Control de Riesgos.

•

Gestión de las Adquisiciones del Proyecto: describe los procesos para comprar o adquirir productos, servicios o resultados, así como para contratar procesos de dirección. Se compone de los procesos de dirección de proyectos Planificar las Compras y Adquisiciones, Planificar la Contratación, Solicitar Respuestas de Vendedores, Selección de Vendedores, Administración del Contrato y Cierre del Contrato.

La siguiente figura ejemplifica las nueve áreas de conocimiento del PMBOK anteriormente descritas.

10

Figura 2.2 Áreas de conocimiento del PMBOK (PMI, 2004)

En el proyecto a desarrollar se han definido tres áreas de conocimiento de gran importancia para asegurar el éxito del mismo, éstas son: Gestión del Alcance, Gestión del Tiempo y Gestión de la Calidad

2.2.1. Gestión del Alcance En el contexto de Administración de Proyectos la palabra alcance puede referirse a alcance del producto o alcance del proyecto:

11 Alcance del producto: Las características y funciones que caracterizan a un producto, servicio o resultado. Alcance del proyecto: El trabajo que debe realizarse para entregar un producto, servicio o resultado con las funciones y características especificadas. Absolutec ha definido claramente el alcance del proyecto, pero para la gerencia es primordial que se realice una detalla especificación del alcance del producto, de forma que contenga soluciones a los problemas que enfrenta. Según PMI (2004), los procesos de la Administración del Alcance son: 2.2.1.1. Planificación del Alcance El plan de gestión del alcance del proyecto es una herramienta de planificación que describe cómo el equipo definirá el alcance del proyecto, desarrollará el enunciado del alcance del proyecto detallado, definirá y desarrollará la estructura de desglose del trabajo, verificará y controlará el alcance del proyecto. 2.2.1.2. Definición del Alcance Se desarrolla un enunciado del alcance del proyecto detallado para futuras decisiones del proyecto. Se analizan las necesidades, deseos y expectativas de los interesados para poder plasmarlos como requisitos. Las asunciones y restricciones se analizan para verificar si están completas y, de ser necesario, se agregan asunciones y restricciones adicionales. 2.2.1.3. Crear EDT Se subdividen los principales productos entregables del proyecto y el trabajo del proyecto en componentes más pequeños y más fáciles de manejar. La EDT es una descomposición jerárquica, orientada al producto entregable, del trabajo que será ejecutado por el equipo del proyecto, para lograr los objetivos del proyecto y crear los productos entregables requeridos. La EDT organiza y define el alcance total del proyecto. La EDT subdivide el trabajo del proyecto en porciones de trabajo más pequeñas y fáciles de manejar, donde cada nivel descendente de la EDT

12 representa una definición cada vez más detallada del trabajo del proyecto. El trabajo planificado comprendido dentro de los componentes de la EDT del nivel más bajo, denominados paquetes de trabajo, puede programarse, supervisarse, controlarse y estimarse sus costes. La EDT representa el trabajo especificado en el actual enunciado del alcance del proyecto aprobado. Los componentes que comprenden la EDT ayudan a los interesados a ver los productos entregables del proyecto. 2.2.1.4. Verificación del Alcance La verificación del alcance es el proceso de obtener la aceptación formal por parte de los interesados del alcance del proyecto completado y los productos entregables relacionados. Verificar el alcance del proyecto incluye revisar los productos entregables para asegurarse de que cada uno se complete satisfactoriamente. La verificación del alcance se diferencia del control de calidad en que la verificación del alcance se relaciona principalmente con la aceptación de los productos entregables, mientras que el control de calidad se relaciona principalmente con cumplir los requisitos de calidad especificados para los productos entregables. 2.2.1.5. Control del Alcance El control del alcance del proyecto se encarga de influir sobre los factores que crean cambios en el alcance del proyecto y de controlar el impacto de dichos cambios. El control del alcance asegura que todos los cambios solicitados y las acciones correctivas recomendadas se procesen a través del proceso Control Integrado de Cambios del proyecto. El control del alcance del proyecto también se usa para gestionar los cambios reales cuando se producen, y está integrado con los demás procesos de control.

2.2.2. Gestión del Tiempo Para Absolutec, una adecuada gestión del tiempo es de vital de importancia debido a la problemática que presentan. Una correcta definición y estimación de las actividades será cuidadosamente revisada por el equipo del proyecto. “La Gestión

13 del Tiempo del Proyecto incluye los procesos necesarios para lograr la conclusión del proyecto a tiempo.” (PMI, 2004, p. 123). Según PMI (2004), los procesos de Gestión del Tiempo son: 2.2.2.1. Definición de las Actividades Identifica las actividades específicas del cronograma que deben ser realizadas para producir los diferentes productos entregables del proyecto. 2.2.2.2. Establecimiento de la Secuencia de las Actividades Identifica y documenta las dependencias entre las actividades del cronograma. 2.2.2.3. Estimación de Recursos de las Actividades Estima el tipo y las cantidades de recursos necesarios para realizar cada actividad del cronograma. 2.2.2.4. Estimación de la Duración de las Actividades Estima la cantidad de períodos laborables que serán necesarios para completar cada actividad del cronograma. 2.2.2.5. Desarrollo del Cronograma Analiza las secuencias de las actividades, la duración de las actividades, los requisitos de recursos y las restricciones del cronograma para crear el cronograma del proyecto.

2.2.2.6. Control del Cronograma Controla los cambios del cronograma del proyecto.

2.2.3. Gestión de la Calidad Los esfuerzos en calidad de software realizados Absolutec incluyen estándares de programación y acercamientos para obtener certificaciones CMM.

14 Los procesos de Gestión de la Calidad del Proyecto incluyen todas las actividades de la organización ejecutante que determinan las políticas, los objetivos y las responsabilidades relativos a la calidad de modo que el proyecto satisfaga las necesidades por las cuales se emprendió. Implementa el sistema de gestión de calidad a través de la política, los procedimientos y los procesos de planificación de calidad, aseguramiento de calidad y control de calidad, con actividades de mejora continua de los procesos que se realizan durante todo el proyecto, según corresponda. (PMI, 2004). Según PMI (2004), los procesos de la Gestión de la Calidad son: 2.2.3.1. Planificación de la Calidad La planificación de calidad implica identificar qué normas de calidad son relevantes para el proyecto y determinar cómo satisfacerlas. 2.2.3.2. Realizar Aseguramiento de la Calidad Aseguramiento de calidad (QA) es la aplicación de actividades planificadas y sistemáticas relativas a la calidad, para asegurar que el proyecto emplee todos los procesos necesarios para cumplir con los requisitos. 2.2.3.3. Realizar Control de la Calidad Realizar control de calidad (QC) implica supervisar los resultados específicos del proyecto, para determinar si cumplen con las normas de calidad relevantes e identificar los modos de eliminar las causas de resultados insatisfactorios. Esto debería ser realizado durante todo el proyecto. Las normas de calidad incluyen los objetivos de los procesos y productos del proyecto. CMM (Capability Maturity Model) EL CMM fue creado por el Software Engineering Institute (SEI). Según el SEI (2009), el CMM es un modelo de calidad del software que clasifica las empresas en niveles de madurez. Estos niveles sirven para conocer la madurez de los procesos que se realizan para producir software.

15 Según consulta en sitio web del SEI (2009), CMM define 5 niveles de madurez os cuales se explican a continuación: • Nivel 1 ó Inicial: Este es el nivel en donde están todas las empresas que no tienen procesos. Los presupuestos se disparan, no es posible entregar los proyectos en las fechas acordadas. No hay control sobre el estado del proyecto, el desarrollo del proyecto es completamente opaco. • Nivel 2 ó Repetible: La principal diferencia entre este nivel y el anterior es que el proyecto es gestionado y controlado durante el desarrollo del mismo. El desarrollo no es opaco y se puede saber el estado del proyecto en todo momento. Los procesos que hay que implantar para alcanzar este nivel son: o Gestión de requisitos o Planificación de proyectos o

Seguimiento y control de proyectos

o Gestión de proveedores o

Aseguramiento de la calidad

o Gestión de la configuración • Nivel 3 ó Definido: La forma de desarrollar proyectos (gestión e ingeniería) está establecida, documentada y que existen métricas (obtención de datos objetivos) para la consecución de objetivos concretos. Los procesos que hay que implantar para alcanzar este nivel son: o Desarrollo de requisitos o Solución Técnica o Integración del producto o Verificación o Validación o Desarrollo y mejora de los procesos de la organización

16 o Definición de los procesos de la organización o Planificación de la formación o Gestión de riesgos o Análisis y resolución de toma de decisiones • Nivel 4 ó Cuantitativamente Gestionado: Los proyectos usan objetivos medibles para alcanzar las necesidades de los clientes y la organización. Se usan métricas para gestionar la organización. Los procesos que hay que implantar para alcanzar este nivel son: o Gestión cuantitativa de proyectos o Mejora de los procesos de la organización • Nivel 5 ó Optimizado: Los procesos de los proyectos y de la organización están orientados a la mejora de las actividades. Mejoras incrementales e innovadoras de los procesos que mediante métricas son identificadas, evaluadas y puestas en práctica. Los procesos que hay que implantar para alcanzar este nivel son: o Innovación organizacional o Análisis y resolución de las causas

2.3. Ingeniería de Software Según el Diccionario de la Real Academia Española (2009), software se define como: “conjunto de programas, instrucciones y reglas informáticas para ejecutar ciertas tareas en una computadora”. Con esta definición podemos introducir el concepto de Ingeniería de Software. “Ingeniería de Software es el estudio de los principios y metodologías para el desarrollo y mantenimiento de sistemas de software.” (Zelkovitz, 1978)

17 La realización del presente proyecto incluye aspectos técnicos en cuanto al diseño de software. A continuación se presenta un marco de referencia para la comprensión del producto del proyecto.

2.3.1. Metodologías de Desarrollo de Software El desarrollo de software es una industria que tuvo un rápido crecimiento en muy poco tiempo. A raíz de esto se definieron varias metodologías de desarrollo con el fin de mejorar la productividad en el desarrollo y la calidad del software. En el desarrollo de un sistema de software se conceptualizan un conjunto de etapas en las cuales se divide la totalidad del desarrollo. A estas etapas se les llama Ciclo de Vida del Software. Según la Organización Internacional para la Estandarización en su norma 12207 (2009), define al ciclo de vida de un software como un marco que contiene las actividades y las tareas involucradas en el desarrollo, la explotación y el mantenimiento de un producto de software, abarcando desde la definición hasta la finalización de su uso. A continuación se explica de manera general las etapas del desarrollo de software. •

Análisis de Requerimientos: La captura, análisis y especificación de requisitos o requerimientos es fundamental en el desarrollo de software. Un alto grado del éxito de un proyecto de software radica en la correcta definición y análisis de los requerimientos, así como la interacción con las personas que utilizarán el sistema para la recolección, clasificación, identificación, priorización y especificación de los requerimientos del software.

•

Diseño: La etapa de diseño tiene como finalidad definir la estructura, arquitectura y comportamiento que tendrá el software una vez desarrollado, principalmente mediante la utilización de diagramas. Una de las metodologías de diseño más utilizadas es Lenguaje Unificado de Modelado (UML).

•

Programación: En la etapa de programación se construye el sistema según los requerimientos plasmados en el diseño del sistema.

18 •

Pruebas: Esta etapa consiste en verificar que el sistema realice todas las funciones requeridas de manera correcta.

•

Implantación: Esta etapa consiste en la instalación final del software para ser utilizado por el cliente. Durante esta etapa se monitorea el desempeño del sistema ya en un ambiente real y se realizan ajustes en caso de que sea necesario.

•

Mantenimiento: Durante esta etapa se le da mantenimiento al software, se corrigen errores descubiertos o se desarrollan nuevos requisitos.

Entre las metodologías de desarrollo de software más utilizadas se encuentran las siguientes: •

Modelo en Cascada: Este modelo ordena de manera estricta todas las etapas, las etapas del ciclo de vida del software, de tal forma que el inicio de cada etapa debe esperar a la finalización de la inmediatamente anterior.

Figura 2.3 Modelo de Cascada de Desarrollo de Software

•

Modelo en Espiral: Este modelo realiza ciclos sobre las etapas del desarrollo. En cada ciclo se evoluciona en el desarrollo del producto final.

19

Figura 2.4 Modelo de Espiral de Desarrollo de Software

2.3.2. Orientación a Objetos La orientación a objetos se define como una metodología de diseño de software que modela las características de objetos reales o abstractos por medio del uso de clases y objetos. La orientación a objetos involucra muchos conceptos, pero es importante conocer los conceptos básicos necesarios, estos conceptos son explicados a continuación. 2.3.2.1. Objeto El objeto, es el concepto principal sobre el cual se fundamenta la tecnología orientada a objetos. Según el Diccionario de la Real Academia Española, un objeto es “todo lo que puede ser materia de conocimiento o sensibilidad de parte del sujeto, incluso este mismo.” Según literatura de orientación a objetos, se menciona que “un objeto tiene identidad, estado y comportamiento.” (Booch, 1990). En el mundo real podemos encontrar muchos ejemplos que cumplen con ésta definición, algunos de ellos son: una persona, un automóvil, un perro, un edificio, etcétera. 2.3.2.2. Atributos

20 Un atributo corresponden a una característica de un objeto. Según el Diccionario de la Real Academia Española, un atributo es “cada una de las cualidades o propiedades de un ser”. En el mundo real cada objeto tiene un conjunto de características. Por ejemplo, en el caso un automóvil, sus características o atributos corresponderían al modelo, el color, la marca, el número de placa, tamaño, etcétera. 2.3.2.3. Acciones Además de un conjunto de atributos, un objeto tiene comportamiento, el cual es expresado mediante un conjunto de acciones. “Una acción es una determinada actividad que puede afectar los atributos del objeto” (De Champeaux, 1994) En el caso concreto del automóvil, entre las posibles acciones podrían estar: acelerar, frenar y virar. 2.3.2.4. Clase Según De Champeaux (1994), una clase puede entenderse como una familia de objetos que tienen algo en común, ó más precisamente hablando, una clase es todo aquello que el conjunto de objetos tiene en común. De esta manera, una clase es caracterizada por su conjunto de atributos definidos y acciones; esta colección de atributos y acciones no cambia. Así, podemos tener una clase Automóvil con sus atributos (modelo, el color, la marca, el número de placa, tamaño) y acciones (acelerar, frenar, virar); y podemos tener múltiples objetos o instancias de esta clase, por ejemplo podemos tener un automóvil color verde marca Toyota ó un automóvil azul marca Ferrari, ambos con la capacidad de acelerar, frenar y virar.

2.3.3. Lenguaje Unificado de Modelado (UML)

21 Tal como indica su nombre, UML es un lenguaje de modelado. El objetivo del modelado de un sistema es capturar las partes esenciales del sistema. Para facilitar este modelado, se realiza una abstracción y se plasma en una representación gráfica del sistema. “El UML se define como un lenguaje que permite especificar, visualizar y construir los artefactos de los sistemas de software. Es un sistema notacional destinado a los sistemas de modelado que utilizan conceptos orientados a objetos.” (Larman, 1999). UML nació en 1994 por iniciativa de Grady Booch, Jim Rumbaugh e Ivar Jacobson. Permite a los desarrolladores de sistemas generar diseños que capturen sus ideas en una forma convencional y fácil de comprender para comunicarlas a otras personas. Los siguientes son parte de los objetivos de UML:

• Visualizar: permite expresar de una forma gráfica un sistema de manera que otra persona lo pueda entender. • Especificar: permite especificar cuáles son las características de un sistema antes de su construcción. • Construir: los sistemas pueden construirse a partir de los modelos especificados. • Documentar: los mismos elementos gráficos sirven como documentación del sistema. Para poder representar correctamente un sistema, UML ofrece una amplia variedad de perspectivas y diagramas. El siguiente cuadro muestra los diagramas de UML por el tipo de diagrama (área), la vista que representa y los principales conceptos que manejan.

22 Cuadro 2.1 Diagramas de UML (Jacobson, 1999)

23 Los principales elementos de UML se describen a continuación: 2.3.3.1. Modelo de Casos de Uso El modelado de Casos de Uso es la técnica más efectiva y a la vez la más simple para modelar los requisitos del sistema desde la perspectiva del usuario. El modelo de casos de uso consiste en actores y casos de uso. “Un actor es una idealización de una persona externa, de un proceso, o de una cosa que interactúa con un sistema. Un actor caracteriza las interacciones que los usuarios exteriores pueden tener con el sistema.” (Jacobson, 1999). Cada actor puede participar en uno o más casos de uso, interactúa con el caso de uso mediante el intercambio de mensajes. “Un caso de uso es una descripción lógica de una funcionalidad del sistema.” (Jacobson, 1999). Se utiliza para modelar cómo un sistema o negocio funciona actualmente, o cómo los usuarios desean que funcione. Los casos de uso representan el comportamiento del sistema, los escenarios que el sistema atraviesa en respuesta a un estímulo por parte de un actor. Cada caso de uso se documenta por una descripción del escenario. La descripción puede ser escrita en modo de texto o en un formato paso a paso. 2.3.3.2. Diagrama de Casos de Uso Según Jacobson (1999), el diagrama de casos de usos representa gráficamente los casos de uso que tiene un sistema.

24

Figura 2.5 Diagrama de Casos de Uso (Jacobson, 1999)

2.3.3.3. Diagrama de Clases El diagrama de clase es el diagrama principal de diseño y análisis para un sistema. La estructura de clases del sistema se especifica, con relaciones entre clases y estructuras de herencia.

25

Figura 2.6 Diagrama de Clases (Jacobson, 1999)

2.3.3.4. Diagrama de Secuencia El diagrama de secuencia es uno de los diagramas más efectivos para modelar la interacción entre objetos en un sistema. Se realiza un diagrama de secuencia para cada caso de uso. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como vectores horizontales. Los mensajes se dibujan cronológicamente desde la parte superior del diagrama a la parte inferior.

26

Figura 2.7 Diagrama de Secuencia (Jacobson, 1999)

2.3.4. Diseño de Bases de Datos Según el diccionario de la Real Academia Española (2009), una base de datos es un conjunto de datos organizado de tal modo que permita obtener con rapidez diversos tipos de información. En la actualidad, las bases de datos son el principal medio de almacenamiento sobre el cual se apoyan los sistemas de información para hacer caminar al mundo. Por esta razón es suma importancia que las bases de datos sean diseñadas de la manera más óptima posible. Existen varios conceptos relacionados a bases de datos. Una tabla es el concepto fundamental en bases de datos. “Una tabla nos permite mostrar la información de una forma compacta. La tabla tiene una columna para cada atributo de los objetos o

27 entidades descritas. Cada entrada de la tabla es una fila que contiene los valores para cada atributo. Las filas se pueden considerar como registros, y las columnas como campos de registro.” (Mayne y Wood, 1985). En el cuadro 2.2 se muestra un ejemplo de una tabla con información de estudiantes. En este ejemplo el Carné, Nombre, Provincia y Edad corresponden a las columnas de la tabla y la información de los 6 estudiantes corresponde a 6 de los registros de la tabla. Cuadro 2.2 Concepto de Tabla

Carné

Nombre

Provincia

Edad

18945

Juan Pérez

Puntarenas

18

2455

José Díaz

Alajuela

19

2913

Karla Segura

San José

20

3866

Francisco Mata

Limón

22

5524

María Córdoba

Heredia

25

6299

Ericka Solano

Cartago

19

Otro concepto importante es el de llave. “Las llaves sirven para identificar registros, y, de esta forma, poder referenciarlos o acceder a ellos.” (Mayne y Wood, 1985). Una llave puede estar formada por una o más columnas e identifican el registro de manera única. En el ejemplo anterior la columna Carné sería la llave de la tabla que identifica de manera única cada registro.

28

3. Marco Metodológico

3.1. Tipo de investigación Para la realización del proyecto se utilizará una metodología basada en la Guía del PMBOK

(PMI,

2004).

Mediante

una

investigación

mixta,

se analizará

la

documentación sobre proyectos y desarrollo de software de Absolutec S.A., y se realizará una recopilación de datos entre el personal de personal de Absolutec. Los métodos de investigación para alcanzar los objetivos propuestos serán los siguientes: • Método de observación por entrevista: intercambio conversacional en forma oral, entre dos personas, con la finalidad de obtener información, datos o hechos. El método de la entrevista puede ser informal, estructurado o no estructurado. (UCI, 2008). • Método analítico sintético: descompone una unidad en sus elementos más simples, examina cada uno de ellos por separado, volviendo a agrupar las partes para considerarlas en conjunto. (UCI, 2008). Estos métodos serán desarrollados mediante las siguientes herramientas de investigación. 3.1.1. Reuniones Según el Diccionario de la Lengua Española (2009), una reunión es un “acto en que se reúnen un conjunto de personas, particularmente para tratar algún asunto.” Las reuniones con el personal de Absolutec serán la base para la realización del producto final del proyecto. Las reuniones del equipo de trabajo son necesarias para tomar decisiones importantes, recolectar la información requerida, analizar la información recolectada y plantear una adecuada solución de diseño.

29 En cada reunión se realizará una minuta. Se cuenta con una plantilla para dicha minuta la cual lleva el registro del día y lugar, agenda tratada, acuerdos tomados, acciones a realizar y miembros del equipo participantes. 3.1.2. Entrevistas Entrevista según la enciclopedia Wikipedia (2009) “es un hecho que consiste en un diálogo entablado entre dos o más personas: el entrevistador o entrevistadores que interrogan y el o los entrevistados que contestan.” Las entrevistas se utilizarán para realizar el levantamiento de requerimientos con los administradores de proyecto y líderes técnicos. Éstas entrevistas se realizarán con previa coordinación de la gerencia de Absolutec. Dichas entrevistas serán documentadas adecuadamente en un formato estándar o plantilla.

3.2. Herramientas metodológicas para definir el alcance 3.2.1. EDT “La EDT es una descomposición jerárquica, orientada al producto entregable, del trabajo que será ejecutado por el equipo del proyecto, para lograr los objetivos del proyecto y crear los productos entregables requeridos.” (PMI, 2004) Ésta valiosa herramienta permitirá planificar el trabajo que es necesario realizar en cuanto a los entregables. Será la guía para desarrollar el proyecto. Para el manejo del EDT, se utilizará el programa de software WBS Chart Pro. 3.2.2. Reuniones Las reuniones serán fundamentales para una adecuada definición del alcance. Es importante que el juicio experto de cada una de las partes sea tomado en cuenta en las reuniones que se desarrollan.

30

3.3. Herramientas metodológicas para definir el tiempo 3.3.1. Reuniones Para la definición del tiempo de cada una de las actividades, se utilizarán las reuniones con los directores de proyecto y demás integrantes del equipo de trabajo de Absolutec. 3.3.2. Software Se utilizará el programa de software Microsoft Project. Según Wikipedia (2009), Microsoft Project es un software de administración de proyectos diseñado, desarrollado y comercializado por Microsoft para asistir a administradores de proyectos en el desarrollo de planes, asignación de recursos a tareas, dar seguimiento al progreso, administrar presupuesto y analizar cargas de trabajo.

3.4. Herramientas metodológicas para definir la calidad 3.4.1. Reuniones Para la definición la calidad, se realizarán reuniones con el personal de calidad de Absolutec. El aporte de su juicio experto permitirá definir métricas de calidad adecuadas para el desarrollo del producto del proyecto. 3.4.2. Estándares de Programación Los estándares de programación de Absolutec serán la fuente de información principal para la definición de las métricas de calidad. Los estándares definen mejores prácticas de desarrollo de sistemas que deben ser contempladas.

31

3.5. Herramientas metodológicas para el desarrollo del proyecto 3.5.1. Metodologías de diseño El diseño es la base fundamental del desarrollo del proyecto. Por lo se utilizará como metodología el Lenguaje de Modelado Unificado (UML), descrito en la sección 2.3.2. 3.5.2. Software Se utilizará el programa de software Microsoft Visio. Según Wikipedia (2009), Microsoft Visio es un software de dibujo vectorial para Microsoft Windows. Visio comenzó a formar parte de los productos de Microsoft cuando fue adquirida la compañía Visio en el año 2000. Las herramientas que lo componen permiten realizar diagramas de oficinas, diagramas de bases de datos, diagramas de flujo de programas, UML, y más, que permiten iniciar al usuario en los lenguajes de programación.

32

4. DESARROLLO En el presente capítulo se detalla del desarrollo del proyecto, según los objetivos planteados en la introducción. El acta de constitución del proyecto que da origen a este desarrollo se encuentra en el anexo 1.

4.1. Plan de Gestión del Alcance 4.1.1. Planificación del Alcance El presente plan de gestión del alcance describirá de forma breve pero concisa los procesos de elaboración del enunciado del alcance detallado, el EDT, la verificación y aceptación de los entregables y el manejo de las solicitudes de cambio al enunciado del alcance. 4.1.1.1. Enunciado del alcance del proyecto detallado El alcance detallado del proyecto se definió mediante la realización de entrevistas y lluvias de ideas realizadas con los líderes técnicos, administradores de proyecto y personal de calidad de Absolutec. Se definió un equipo de trabajo que analizó las necesidades y requerimientos y revisó el documento del alcance. El enunciado del alcance se desglosa en la sección 4.1.2. 4.1.1.2. Creación de la EDT La estructura detallada del trabajo se realizó a través de la recopilación de información mediante reuniones y entrevistas con los administradores de proyecto y el personal del Departamento de Calidad, tomando en cuenta las metodologías para el desarrollo de software de Absolutec. La siguiente figura muestra la EDT definida para el proyecto.

33

Figura 4.1 Estructura Detallada de Trabajo (EDT)

4.1.1.3. Verificación y aceptación formal de los productos entregables La verificación de los productos entregables será realizada por el departamento de calidad de software de Absolutec; y su aceptación formal se realizará mediante reuniones formales con el personal de calidad y el gerente general de Absolutec, los cuales firmarán los documentos de aceptación respectivos. 4.1.1.4. Solicitudes de cambio al enunciado del alcance del proyecto detallado Las solicitudes de cambio al alcance del proyecto deben realizar de manera formal presentando un documento con los detalles de los cambios. Dichas solicitudes deberán analizarse para cuantificar el impacto en tiempo y costos. Después de dicho análisis se podrá rechazar o aceptar la solicitud. Los formularios de solicitud fueron brindados por el Departamento de Calidad de Absolutec.

34 4.1.2. Definición del Alcance 4.1.2.1. Objetivo General Elaborar, en plazo no mayor a tres meses, los documentos de diseño del Sistema Informático de Apoyo al Desarrollo (SIAD), la herramienta informática que apoyará el desarrollo de los sistemas informáticos que la empresa Absolutec S. A. elabora para sus clientes, para que este sistema permita el seguimiento detallado de los tiempos de las tareas que se realizan durante las etapas de desarrollo de los sistemas. 4.1.2.2. Objetivos Específicos • Realizar el levantamiento de requerimientos del SIAD a través de la recopilación de las necesidades que expresan los directores de proyectos y líderes técnicos de Absolutec S. A. • Elaborar el documento de diseño del SIAD, como base para un posterior desarrollo, implantación y uso en los proyectos desarrollados en Absolutec S.A. • Elaborar el Plan de Gestión del Alcance para las etapas de Análisis y Diseño del Sistema SIAD. • Realizar un Plan de Gestión del Tiempo para las etapas de Análisis y Diseño del Sistema SIAD. • Diseñar herramientas para controlar la calidad del proceso en las etapas de Análisis y Diseño del Sistema SIAD. 4.1.2.3. Alcance del Proyecto El producto final del proyecto es el documento de diseño del SIAD el cual contendrá la definición de casos de uso del SIAD, el diagrama de casos de uso, el diagrama de clases, los diagramas de secuencia y el modelo conceptual de la base de datos y la definición de la arquitectura sobre la cual se implementará el SIAD.

35 El documento de diseño se basará en el documento de análisis elaborado en el primer entregable del proyecto. Este documento de análisis contendrá el análisis de requerimientos. Entre los requerimientos principales del SIAD están: •

Administración de tareas: creación de tareas generales y por módulo del sistema; asignación de tareas a los recursos del proyecto.

•

Seguimiento de tareas: manejo de las variables tiempo estimado, tiempo empleado y tiempo restante por tarea; historial de atención de las tareas.

•

Manejo de incidencias y versionamiento.

•

Manejo de alertas, advertencias e indicadores.

•

Consultas de tareas, incidencias, versionamientos e indicadores.

•

Reportes estadísticos sobre cumplimiento de tareas y resolución de incidencias.

4.1.2.4. Requisitos del proyecto Los siguientes son los requisitos planteados: •

El documento de diseño del SIAD debe contener todos los requerimientos planteados en el documento de levantamiento de requerimientos.

•

El documento de diseño del SIAD debe cumplir con la metodología UML.

4.1.2.5. Límites del proyecto El presente proyecto no contemplará la programación y la implantación del SIAD. Estos dos puntos serán desarrollados en un proyecto posterior. 4.1.2.6. Productos entregables del proyecto El producto final del proyecto abarcará los siguientes entregables: 1. Documento

de

análisis

del

SIAD:

contendrá

el

levantamiento

requerimientos del SIAD, el análisis de requerimientos definidos.

de

36 2. Documento de diseño del SIAD: contendrá la definición de casos de uso del SIAD, el diagrama de casos de uso, el diagrama de clases, los diagramas de secuencia, el modelo conceptual de la base de datos y la definición de la arquitectura sobre la cual se implementará el SIAD. 3. Plan de Gestión del Alcance para las etapas de Análisis y Diseño del Sistema SIAD. 4. Plan de Gestión del Tiempo para las etapas de Análisis y Diseño del Sistema SIAD. 5. Herramientas para controlar la calidad del proceso en las etapas de Análisis y Diseño del Sistema SIAD.

4.1.2.7. Criterios de aceptación La aceptación del proyecto será realizada por el departamento de calidad de software y el departamento de informática de Absolutec, mediante una reunión formal con el gerente general de Absolutec, los cuales firmarán el documento de aceptación una vez validados los requisitos del proyecto. 4.1.2.8. Restricciones •

La ejecución del proyecto se realizará fuera de horas laborales, en caso de reuniones para el levantamiento y análisis de requerimientos se deberá negociar el tiempo disponible con los involucrados y sus respectivos jefes.

•

La fecha límite de finalización del proyecto debe ser antes de 1 de setiembre del 2009.

4.1.3. Estructura Detallada de Trabajo (EDT) El equipo de trabajo del proyecto, a través de las diferentes reuniones y revisiones, definió la estructura detallada de trabajo del proyecto. Ver anexo 2. 4.1.4. Diccionario de la EDT

37 El Diccionario de la EDT explica cada uno de las tareas a desarrollar en el proyecto. El siguiente cuadro muestra el diccionario de la EDT. Cuadro 4.1 Diccionario de la EDT

Diseño del Sistema Informático de Apoyo al Desarrollo Código EDT: 1

Planificación

Este componente de la EDT se refiere a la iniciación y coordinación del proyecto y a la realización de los planes de gestión del alcance, gestión de la calidad y creación de las herramientas para el control de la calidad durante el proyecto. Código EDT: 1.1

Reunión Inicial

Esta actividad ha sido incluida en la EDT debido a su alto nivel de importancia. En ella se definirán puntos claves con el cliente, tanto para el desarrollo del proyecto como para el cierre del mismo. Código EDT: 1.2

Presentar Planes de Gestión

Una vez realizada la reunión inicial, se realizarán los planes de gestión definidos en el alcance del proyecto y se le entregarán al equipo del trabajo de Absolutec. Código EDT: 1.2.1

Plan de Gestión del Alcance

Se realizará el Plan de Gestión del Alcance según la Guía del PMBOK. Código EDT: 1.2.2

Plan de Gestión del Tiempo

Se realizará el Plan de Gestión del Tiempo según la Guía del PMBOK. Código EDT: 1.2.1

Herramientas para el Control de la Calidad

Se crearán un conjunto de herramientas para controlar la calidad durante el desarrollo del producto del proyecto, según los estándares de Absolutec. Código EDT: 2

Análisis del SIAD

38 Este componente de la EDT se refiere al proceso de conceptualización y análisis de requerimientos del SIAD. Se realizará una serie de entrevistas y reuniones para discutir y analizar las funcionalidades que va a tener el SIAD. Código EDT: 2.1

Levantamiento de Requerimientos

Para el levantamiento de los requerimientos del SIAD se realizará una serie de entrevistas y reuniones con el personal de la EDT: líderes técnicos, administradores de proyectos, calidad y gerencia. Se creará un documento con los requerimientos manifestados por todas las partes, el cual será revisado por éstos. Código EDT: 2.2

Análisis de Requerimientos

En el análisis de requerimientos se profundizará en cada uno de los requerimientos solicitados. Se determinará la viabilidad de estos según las necesidades reales de Absolutec y se detallará en cuanto a la información que se debe manejar y a las funcionalidades que se deben realizar. Código EDT: 3

Diseño del SIAD

Este componente de la EDT se refiere a la manera en que se representarán los requerimientos en el SIAD, en cuanto a estructura y funcionalidades. El diseño se realizará con base en el modelo UML. Código EDT: 3.1

Definición de Casos de Uso

Se definirán los casos de uso según los requerimientos definidos y lo estipulado por el modelo UML. Código EDT: 3.2

Diagramas de Clases

Se definirá el diagrama de clases del SIAD según la información de los requerimientos y los casos de uso realizados. Código EDT: 3.3

Diagramas de Secuencia

39 Se definirán los diagramas de secuencia de los casos de uso realizados, según el modelo UML. Código EDT: 3.4

Modelo de Base de Datos

Se realizará el modelo de la base de datos donde se almacenará toda la información recolectada y procesada por el SIAD.

4.2. Plan de Gestión del Tiempo 4.2.1. Definición de las actividades Para la definición de las actividades fue de suma importancia el criterio experto en cuanto al desarrollo de software. Las actividades están definidas de acorde a la Estructura Detallada de Trabajo. El cuadro 4.2 muestra el listado de actividades definidas. Cuadro 4.2 Listado de Actividades Id Nombre 1 Proyecto SIAD 2 3 4 5

Organización del Proyecto Reunión Inicial Presentar Planes de Gestión Plan de Gestión del Alcance

Duración 188 h 54 h 4h 50 h 16 h

6

Planificación del alcance

6h

7

Definición del alcance

6h

8

Crear EDT

4h

9 10 11

Plan de Gestión del Tiempo Definición de las actividades Establecer secuencia de las actividades

20 h 4h 2h

Comienzo 01/06/2009 16:00 01/06/2009 16:00 01/06/2009 16:00 02/06/2009 16:00 02/06/2009 16:00 02/06/2009 16:00 03/06/2009 18:00 05/06/2009 16:00 08/06/2009 16:00 08/06/2009 16:00 09/06/2009 16:00

Fin 04/08/2009 20:00 18/06/2009 18:00 01/06/2009 20:00 18/06/2009 18:00 05/06/2009 20:00 03/06/2009 18:00 04/06/2009 20:00 05/06/2009 20:00 12/06/2009 20:00 08/06/2009 20:00 09/06/2009 18:00

Predecesoras

3 6 7

8 10

40

12 13 14 15 16 17 18 19 20 21

Estimación de recursos de las actividades Estimación de duración de actividades Desarrollo del cronograma Herramientas para el Control de la Calidad Definir Herramientas Realizar herramientas análisis Realizar herramientas diseño

2h 4h 8h 14 h 2h

para 6h para

Análisis del SIAD Levantamiento de Requerimientos Entrevistas

6h 78 h 22 h 6h

22

Entrevista con Gerencia

1h

23

Entrevista con Calidad

1h

24

Entrevista con Líder Técnico 1

1h

25

Entrevista con Líder Técnico 2 Entrevista con Administrador de Proyecto 1 Entrevista con Administrador de Proyecto 2 Realizar Documento de requerimientos

1h

26 27 28 29 30

Análisis de Requerimientos

1h 1h 16 h 56 h

32

Análisis de los Requerimientos Realizar Documento de Análisis del SIAD Revisión del documento con Departamento de Calidad

33

Revisión del documento con Administradores de Proyecto y Lideres Técnicos

8h

34

Realizar ajustes

8h

31

35 36 37

Diseño del SIAD Definición de Casos de Uso Diagrama de Clases

16 h 16 h 8h

52 h 12 h 8h

09/06/2009 18:00 10/06/2009 16:00 11/06/2009 16:00 15/06/2009 16:00 15/06/2009 16:00 15/06/2009 18:00 17/06/2009 16:00 18/06/2009 18:00 18/06/2009 18:00 18/06/2009 18:00 18/06/2009 18:00 18/06/2009 19:00 19/06/2009 16:00 19/06/2009 17:00 19/06/2009 18:00 19/06/2009 19:00 22/06/2009 16:00 26/06/2009 16:00 26/06/2009 16:00 02/07/2009 16:00 08/07/2009 16:00

09/06/2009 20:00 10/06/2009 20:00 12/06/2009 20:00 18/06/2009 18:00 15/06/2009 18:00 16/06/2009 20:00 18/06/2009 18:00 15/07/2009 20:00 25/06/2009 20:00 19/06/2009 20:00 18/06/2009 19:00 18/06/2009 20:00 19/06/2009 17:00 19/06/2009 18:00 19/06/2009 19:00 19/06/2009 20:00 25/06/2009 20:00 15/07/2009 20:00 01/07/2009 20:00 07/07/2009 20:00 09/07/2009 20:00

10/07/2009 16:00 14/07/2009 16:00 16/07/2009 16:00 16/07/2009 16:00 21/07/2009

13/07/2009 20:00 15/07/2009 20:00 03/08/2009 20:00 20/07/2009 20:00 22/07/2009

11 12 13

14 16 17

18 22 23 24 25 26 27

28 30 31

32 33

34 36

41

38

Revisión de casos de uso y diagrama de clases con líderes técnicos y calidad

4h

39

Realizar ajustes

4h

40

Diagramas de Secuencia

8h

41

Modelo de Bases de Datos

8h

42

Revisión de diagramas de secuencia y modelo de base de datos con líderes técnicos y calidad

4h

43

Realizar ajustes

4h

44

Realizar Entregable Final

4h

16:00

20:00

23/07/2009 16:00 24/07/2009 16:00 27/07/2009 16:00 29/07/2009 16:00

23/07/2009 20:00 24/07/2009 20:00 28/07/2009 20:00 30/07/2009 20:00

31/07/2009 16:00 03/08/2009 16:00 04/08/2009 16:00

31/07/2009 20:00 41 03/08/2009 20:00 42 04/08/2009 20:00 43

37 38 39 40

4.2.2. Secuenciamiento de las actividades Una vez definidas las actividades, el secuenciamiento de las mismas se realizó de una manera muy sencilla, debido a las características del proyecto, donde no se ejecutará todo el proceso de desarrollo de software, sino solamente hasta la etapa de diseño, se realizó un ordenamiento secuencial de todas las actividades. Este secuenciamiento fue realizado por el director del proyecto el Ingeniero Gabriel Villalobos Molina. El cuadro 4.2 muestra la secuencia dada a las actividades. 4.2.3. Duración de las actividades La estimación de la duración de las actividades, fue supervisada por los directores de proyectos y líderes técnicos de Absolutec. Éstos realizaron observaciones que permitieron ajustar los tiempos de cada actividad. El cuadro 4.2 muestra la duración estimada para las actividades. 4.2.4. Creación del cronograma En el desarrollo de cronograma del proyecto, se determinaron las fechas de inicio y fin de las actividades planificadas, las cuales requirieron especial cuidado al utilizar la herramienta Microsoft Project, ya que la duración estaba definida en horas y no en

42 días y la jornada de trabajo se determinó en 4 horas diarias, de 4 de la tarde a 8 de la noche. Esto porque el proyecto se tenía que desarrollar en lo máximo posible fuera de la jornada ordinaria de trabajo. El cuadro 4.2 muestra las horas de inicio y de fin de cada actividad y el anexo 3 muestra el cronograma del proyecto. 4.2.5. Asignación de recursos La asignación de recursos se extendió hasta el secuenciamiento lineal de las actividades, pues solamente un recurso se encargaría del desarrollo de todas las actividades del proyecto.

4.3. Herramientas para el Control de la Calidad El SIAD será una herramienta indispensable en la ejecución de los proyectos Absolutec, por lo que su análisis y diseño debe realizarse cumpliendo los parámetros de calidad establecidos. El director de proyecto con el apoyo del Departamento de Calidad de Absolutec, definieron las siguientes herramientas de control de calidad a utilizar en las etapas de análisis y diseño del SIAD: •

Lista de chequeo para análisis de requerimientos: esta herramienta se utilizará en la etapa de análisis para verificar la correctitud de los requerimientos. Ver anexo 4.

•

Lista de chequeo de para casos de uso de UML: esta herramienta permitirá asegurar que los casos de uso estén correctamente construidos según las especificaciones del UML. Ver anexo 5.

43 •

Lista de chequeo de para diagrama de clases de UML: esta herramienta permitirá asegurar que el diagrama de clases esté correctamente construido según las especificaciones del UML. Ver anexo 6.

•

Lista de chequeo de para diagramas de secuencia de UML: esta herramienta permitirá asegurar que los diagramas de secuencia estén correctamente construidos según las especificaciones del UML. Ver anexo 7.

•

Lista de chequeo de estándares para el modelo de bases de datos: esta herramienta permitirá asegurar que el modelo de la base de datos esté correctamente construidos según los estándares de bases de datos de Absolutec. Ver anexo 8.

•

Lista de chequeo para el formato de los documentos entregables: esta herramienta se utilizará para revisar el formato de los documentos entregables para Absolutec. Ver anexo 9.

4.4. Diseño del Sistema Informático de Apoyo al Desarrollo (SIAD) La presente sección detalla los documentos entregables finales que forman parte del producto del proyecto. 4.4.1. Requerimientos del Sistema Informático de Apoyo al Desarrollo El Sistema Informático de Apoyo al Desarrollo (SIAD) permitirá mantener y mejorar la calidad de sus productos informáticos. Gracias al SIAD se podrán tomar de manera más acertada acciones a seguir y permitirá recompilar información estadística para identificar puntos débiles y fuertes que ayuden en proyectos futuros. Los objetivos que se pretenden alcanzar en la compañía con el desarrollo del SIAD son los siguientes: •

Incremento de la calidad del software que se desarrolla, permitiendo aplicar mejoras desde el inicio del proyecto.

44 •

Seguimiento diario del proyecto permitiendo identificar posible atrasos antes de que se vean afectados los tiempos de entrega.

•

Mejoramiento de las técnicas de estimación en los proyectos.

•

Mayor organización del proyecto, permitiendo tener una visión global en cuanto a tareas pendientes, avances, tiempos, incidencias, documentación relacionada entre otros.

•

Mayor control sobre los requerimientos definidos en el análisis y las nuevas funcionalidades que el cliente solicita durante el desarrollo del proyecto.

•

Disminución de los tiempos de respuesta al cliente.

•

Identificación, a través de reportes estadísticos, de puntos débiles en el desarrollo del proyecto, sea por mal análisis, fallas en los recursos del proyecto, mala administración, entre otros.

La creación, asignación y seguimiento de tareas es la base del sistema. Las tareas son la fuente de trabajo de los programadores, material de seguimiento del proyecto para los líderes técnicos y administradores de proyecto y fuente de estadísticas para la gerencia. Lista de Requerimientos 1. El SIAD permitirá la creación, modificación y eliminación de tareas; necesarias para el desarrollo de los sistemas. Cada tarea tiene una descripción de la tarea, una duración estimada para ser completada y una prioridad. Las tareas pueden corresponder a casos de uso completos o a un listado de tareas necesarias para desarrollar un caso de uso u otra tarea. Es decir una tarea puede contener subtareas. Éstas pueden pertenecer a un módulo en específico del sistema en desarrollo o generales al proyecto. 2. La organización de las tareas se manejará como la de un cronograma. Las tareas tendrán tareas predecesoras, fechas de inicio y de fin, se podrán tener tareas

45 entregables o hitos del proyecto. Esta definición de tareas podrá realizarse de manera manual o cargando la estructura del proyecto importando un archivo de Microsoft Excel o Microsoft Project. 3. El sistema debe permitir la creación de recursos para el proyecto y la asignación de tareas a estos recursos; eventualmente una tarea podría ser asignada a más de un recurso. En caso de que dos tareas que se traslapen en su tiempo de ejecución sean asignadas a un mismo recurso, el SIAD debe mostrar la alerta correspondiente y mostrar las opciones posibles: permitir la asignación, modificar las fechas de las tareas o asignar a otro recurso. Debe permitir ver la carga de trabajo asignada a cada recurso y redistribuir las cargas de trabajo en caso de que sea necesario. Cada recurso podrá visualizar el listado de tareas que le han sido asignadas con sus tiempos estimados y el resto de recursos asignados a esa tarea si fuera el caso. El líder técnico podría reasignar la tarea a otro recurso, por lo cual la tarea debería tener un historial de asignaciones. En caso de que un programador registre una tarea adicional el líder técnico recibirá la notificación de que una nueva tarea ha sido incluida. 4. El SIAD debe realizar un seguimiento al avance de las tareas. Para cada tarea se debe registrar día a día de forma manual el tiempo utilizado en el desarrollo de la tarea y el tiempo estimado restante para completarla, con el cual se puede calcular el porcentaje de avance. En caso de que no se registren las horas a final del día el SIAD debe mostrar un recordatorio al recurso y una alerta al líder técnico u administrador de proyecto. El SIAD también tener la opción de llevar la contabilización del tiempo de forma automática. 5. El SIAD debe permitir visualizar el avance diario realizado tanto en horas como en porcentaje de avance, tanto de manera general como por recurso, por módulo del sistema o por funcionalidad. El SIAD debe permitir ver el total de horas laboradas por un recurso, ordinarias y extras, en un rango de fechas dado. En caso de que un recurso ya no tenga tareas asignadas pendientes el SIAD debe enviar una

46 alerta al líder técnico o administrador de proyecto para que le sean asignadas nuevas tareas. 6. El SIAD debe permitir adjuntar cualquier tipo de información documental a las tareas y al proyecto en general, ya sean archivos o correos electrónicos. El SIAD debe enviar una notificación indicando que nueva documentación ha sido adjuntada a la tarea o proyecto. 7. El SIAD debe permitir la administración de incidencias (errores) reportadas, tanto por testing a nivel interno como por pruebas realizadas a nivel del cliente. Las incidencias deben ser asociadas a un módulo, opción del sistema y funcionalidad realizada en la etapa de desarrollo del sistema. Deben haber tipos de incidencias para

permitir

realizar

estadísticas

posteriormente,

como

por

ejemplo:

funcionalidad, interfaz, validación de datos; y una categoría de incidencia: mejora, nueva funcionalidad, error. La incidencia deberá tener un historial de atención por parte del equipo y de reporte por parte del cliente. Deben contener el nombre de quien reporta la incidencia y la prioridad que tiene, la fecha de reportada y la fecha de solución; además se podrá adjuntarle documentación. Las incidencias en primera instancia deben asignarse al recurso que desarrolló la funcionalidad. 8. Debe existir la funcionalidad para crear versiones del sistema. Cada vez que el sistema sea instalado para pruebas por parte del cliente se debe crear una versión del sistema, la cual incluirá todas la funcionalidades ya realizadas ó incidencias ya atendidas que van en dicha instalación. El SIAD debe permitir imprimir las funcionalidades ó incidencias de dicha versión por módulo, por opción del sistema, por requerimiento y por tipo de incidencia; además de mostrar errores reincidentes e indicadores de calidad, por ejemplo: cantidad de incidencias reportadas a nivel interno entre cantidad de incidencias reportadas por el cliente. 9. Debe crearse un módulo web, mediante el cual el cliente podrá ingresar sus incidencias, ver el estado de las ya reportadas y sacar reportes de las incidencias que ya han sido instaladas para su revisión. El registro de las incidencias por

47 parte del cliente puede realizarse de manera manual o mediante carga masiva a través de un Excel con un formato ya predefinido. Cada vez que el cliente realice la carga de incidencias, el SIAD debe enviar una notificación al administrador de proyecto o líder técnico. 10. El SIAD debe permitir visualizar la cantidad o el listado de tareas pendientes, en desarrollo o atrasadas, por módulo por caso de uso, por recurso o en un rango de fechas dado. Debe mostrar de manera visual el desfase producto de los atrasos en las tareas según la ruta crítica y las principales rutas e hitos del cronograma del proyecto. 11. Las tareas puede tener asociado uno o más tipos de elementos: mantenimiento básico, pantalla de consulta, procedimiento almacenado, proceso, reporte, cubo olap, proceso de carga de datos, etc. A cada uno de estos elementos se le debe de asignar un grado de dificultad, por ejemplo, el grado de dificultad de un mantenimiento básico en términos generales es menor al de una pantalla de consulta. Este grado de dificultad será generalizado para todos los proyectos manejados por el SIAD, sin embargo, dependiendo de los requerimientos de los clientes un mismo elemento puede variar en su complejidad, por lo que adicionalmente la tarea deberá tener un factor de complejidad: básico, intermedio y complejo. Otro aspecto importante es que cada elemento puede desarrollarse mediante una herramienta de programación diferente, no es lo mismo realizar un mantenimiento básico en arquitectura Windows que en una arquitectura Web, ó una carga de datos en SQL Server 2000 que en SQL Server 2005. Por ello se debe manejar un tercer factor, un nivel de eficiencia entre las herramientas disponibles para desarrollar un determinado elemento. Toda esta categorización servirá para realizar estadísticas de estimación de tiempos, de rendimiento de los recursos y de incidencias. Por lo tanto el SIAD debe mostrar gráficos y reportes que reflejen estas estadísticas. 12. Cada una de las consultas del SIAD debe tener la opción de impresión.

48 13. El SIAD debe contemplar que no todos los proyectos se desarrollan dentro de red de Absolutec. Muchos de los proyectos se realizan en las instalaciones del cliente, por lo que debe proveer una forma de comunicación con el servidor central para el trabajo en línea. En caso de que no pueda mantenerse una comunicación en línea debe existir una modalidad de trabajo desconectado que permita la sincronización de datos cuando el SIAD pueda entrar en línea o mediante la carga manual de un archivo XML. 14. El SIAD debe proveer de un módulo de seguridad, el cual realice la administración de roles, usuarios y accesos a las funcionalidades del SIAD. La autenticación para el ingreso al sistema puede ser autenticación Windows para los empleados de Absolutec registrados dentro de la red de la empresa ó también puede ser mediante un usuario y contraseña fuera de la red para los clientes. El SIAD debe implementar seguridad de datos, es decir, un administrador de proyectos no podría ver los datos de un proyecto para el cual no tiene permisos. 15. La interfaz del SIAD debe permitir un rápido ingreso de la información. El registro de las tareas debe ser ágil, así como el registro de los tiempos para que no consuma tiempo excesivo y no interrumpa las labores diarias. Debe hacer uso de teclas rápidas para así disminuir el uso del mouse. Aunque no se esté utilizando el SIAD de forma directa, la información necesaria para cada usuario dependiendo de su rol debe estar a la mano, sin elementos de interfaz que distraigan el trabajo diario en las otras herramientas, es decir debe visualizarse de forma discreta y estética.

4.4.2. Análisis de Requerimientos El anexo 10 lista cada uno de los requerimientos definidos durante el análisis de requerimientos. 4.4.3. Diagrama de Clases

49 El diagrama de clases muestra la estructura funcional del sistema. El anexo 11 muestra el diagrama de clases del SIAD. 4.4.4. Diagrama de Bases de Datos El diseño de la base de datos es fundamental para un correcto diseño del sistema. Para su realización se tomó como base las entrevistas realizadas y la información contenida en cada caso de uso. 4.4.5. Casos de Uso Los casos de uso del sistema se desarrollaron de acuerdo al modelo UML y fueron verificados utilizando las herramientas de control de calidad definidas. El cuadro 4.2 muestra el listado de los casos de uso.

Cuadro 4.3 Listado de Casos de Uso

Número 01

Descripción Administrar Tareas

02

Cargar Estructura del Proyecto

03

Administrar Recursos

04

Asignar Tareas

05

Consultar Carga de Trabajo

06

Consultar Historial de Asignaciones

07

Ver Pendientes

08

Registrar Avance de Tareas

09

Consultar Estado de Avance

10

Consultar Horas Laboradas

11

Incluir Documentación

12

Administrar Incidencias

13

Administrar Versionamientos

14

Consultar Versionamientos

15

Cargar Incidencias

16

Consultar Incidencias

50 17

Administrar Usuarios

18

Administrar Roles

19

Asignar Usuarios a Roles

20

Asignar Permisos a Roles

El anexo 12 muestra el diagrama de casos de uso para el SIAD. El detalle de cada uno de los casos de uso definidos se muestra en el anexo 13. 4.4.6. Diagramas de Secuencia A continuación se detallan los diagramas de secuencia correspondientes a los casos de uso desarrollados. El anexo 14 muestra cada uno de los diagramas de secuencia.

4.5. Guía de Uso para las Herramientas de Calidad Para la utilización de las herramientas de control de calidad descritas en la sección 4.3, se ha elaborado una guía de uso que tiene como finalidad establecer una descripción de los pasos que habría que llevar a cabo para utilizar dichas herramientas en un proyecto de software. Cada plantilla o lista de chequeo se usa para cada uno de los principales elementos del análisis y diseño de software. Cuando cada elemento sea finalizado se le aplicará la lista de chequeo para determinar que haya sido hecho de la manera correcta. El siguiente cuadro muestra la guía de uso para cada plantilla. Cuadro 4.4 Guía de Uso para las Herramientas de Control de Calidad

Lista Chequeo Análisis de requerimientos Ver Anexo 4.

Elemento de Uso Análisis/Diseño Documento de Una vez que los requerimientos Análisis de han sido definidos se deben listar Requerimientos todos en la columna Requerimiento. Cada vez que uno haya sido analizado se debe marcar en la columna Analizado. En la columna Revisado se deben marcar aquellos requerimientos analizados que ya han sido revisados por el cliente. Se marcará un requerimiento en la

Responsable Líder Técnico: deber llevar control de los requerimientos analizados, revisados y aprobados.

51

Casos de Uso. Ver Anexo 5.

Casos de Uso del Sistema

Diagrama de Clases. Ver Anexo 6.

Diagrama de Clases del Sistema

Diagrama de Secuencia. Ver Anexo 7.

Diagramas Secuencia

Modelo de Bases de Datos. Ver Anexo 8.

Modelo de Bases de Datos

Documentos Entregables. Ver Anexo 9.

Documentos Entregables

de

columna Listo cuando un requerimiento analizado sea revisado por el cliente, corregido y aceptado por el cliente. En la columna Caso de Uso se deben listar todos los casos de uso definidos. Para cada caso de uso se debe chequear si cumple con todos los criterios de las demás columnas. En caso de que alguno no cumpla debe de ser corregido por el encargado del caso de uso. Una vez realizado el diagrama de clases, en la columna Si/No se debe poner si el diagrama de clases cumple con cada uno de los criterios listado en la columna Criterio. En la columna Diagramas de Secuencia se deben listar todos los diagramas de secuencia realizados. Para cada diagrama se debe chequear si cumple con todos los criterios de las demás columnas. En caso de que alguno no cumpla debe de ser corregido por el encargado del diagrama. Una vez realizado el modelo de bases de datos, en la columna Si/No se debe poner si el modelo cumple con cada uno de los criterios listado en la columna Criterio. Para cada documento que se deba entregar al cliente se debe revisar. En la columna Si/No se debe poner si el modelo cumple con cada uno de los criterios listado en la columna Criterio.

Líder Técnico: debe chequear todos los casos de uso realizados por los programadores. Líder Técnico

Líder Técnico: debe chequear todos los diagramas realizados por los programadores.

Líder Técnico

Líder Técnico

52

5. CONCLUSIONES

•

El desarrollo de este proyecto ha sido de gran importancia para Absolutec, pues ha permitido nivelar los conocimientos y fortalecer los procesos en cuando a Administración de Proyectos y Calidad de Software entre todo el personal de Absolutec.

•

Una

buena

definición

de

requerimientos,

una

buena

gestión

de

las

comunicaciones y el aseguramiento de una buena calidad del software son de suma importancia para alcanzar un alto nivel de madurez de desarrollo de software y evitar problemas en los proyectos de la empresa, tanto internos como con el cliente. •

El desarrollo del Plan de Gestión del Alcance permitió definir claramente los alcances del proyecto y sentó, una base a ser considerada para futuros proyectos de software.

•

El desarrollo del Plan de Gestión del Alcance es fundamental para realizar una EDT que vaya completamente de acuerdo con los objetivos del proyecto.

•

La EDT es una herramienta de suma utilidad para iniciar con la definición de las actividades del proyecto, pues permitió dar a todos los miembros del proyecto una visión global y estandarizada de los entregables y estructura del proyecto.

•

El desarrollo del Plan de Gestión del Tiempo de manera conjunta con todo el equipo de trabajo de Absolutec, permitió tomar conciencia de que tomar en cuenta el criterio de personal técnico y no sólo el criterio del administrador del proyecto, permite tener una mayor exactitud y visión en la realización del cronograma.

53 •

El cronograma es la principal herramienta en el desarrollo de un proyecto, ya que centra alcance, actividades, tiempos y recursos, mediante los cuales se puede saber el estado de un proyecto.

•

El tener registro de la duración real de las actividades según lo estimado durante la planificación es de suma importancia para Absolutec, ya que de esta manera puede tener datos concretos para futuras estimaciones dependiendo del tipo de actividad y características de los recursos que las realizan.

•

Una correcta definición del Plan de Gestión del Alcance, del Plan de Gestión del Tiempo y de parámetros de Calidad, son indispensables en la etapa de cierre del proyecto para concluir de forma exitosa con la aprobación del proyecto.

•

El desarrollo de las listas de chequeo para el control de la calidad en el proyecto fue fundamental para obtener el producto definido en el alcance.

•

La definición de métricas y metodologías para el control de la calidad son necesarias a nivel general en los proyectos de Absolutec.

•

La elaboración del diseño del SIAD permitió conceptualizar una herramienta que subsanara las deficiencias en el desarrollo de proyectos informáticos, para así solucionar de manera incremental las problemáticas descritas por Absolutec.

•

Las lecciones aprendidas en proyectos anteriores son de gran utilidad, por ello durante el transcurso del proyecto deben registrarse y ponerse a disposición de los otros proyectos.

54

6. RECOMENDACIONES •

Se recomienda al departamento de calidad tomar como modelo en los diferentes proyectos de la empresa, el plan de gestión del alcance desarrollado en el presente proyecto.

•

Se recomienda a los administradores de proyectos realizar la EDT y el diccionario de la EDT en los proyectos que desarrollan.

•

Se recomienda a los administradores de proyecto tomar en cuenta al personal técnico de la empresa al momento de desarrollar la estimación de tiempos de las actividades.

•

Se recomienda a los administradores de proyecto y al departamento de calidad asegurarse de que los desarrolladores tengan acceso al cronograma actualizado del proyecto.

•

Se recomienda al departamento de calidad utilizar las listas de chequeo desarrolladas en este proyecto para el control de la calidad en las etapas de análisis y diseño de los proyectos de la empresa.

•

Se recomienda al personal de calidad solicitar a los administradores de proyecto las lecciones aprendidas al final de cada proyecto, y entregar las lecciones recolectadas cada vez que se inicie un nuevo proyecto.

•

Se recomienda a la gerencia de Absolutec y al departamento de Calidad crear una base de datos con estimaciones históricas para cada tipo de actividad de desarrollo de software realizada, para así tener más certeza en futuras estimaciones. La base de datos del SIAD, una vez implementada, proveería de dicha información.

55 •

Se recomienda a la gerencia de Absolutec, iniciar

un proyecto de

implementación del SIAD, el cual tomará como fuente principal el documento de diseño producto de este proyecto. •

Se recomienda a la gerencia de Absolutec, definir un proceso de implantación del SIAD en cada uno de los proyectos de Absolutec después de que éste haya sido implementado.

•

Se recomienda a la gerencia de Absolutec, iniciar un proceso de capacitación y retroalimentación continuo y periódico sobre las mejores prácticas en Administración de Proyectos y lecciones aprendidas en proyectos realizados o en ejecución. En dicho proceso de capacitación la información estadística recompilada por el SIAD debe ser revisada con el fin de ayudar a la toma de decisiones según los objetivos de la empresa.

56

7. Bibliografía Booch, Grady. Object Oriented Design with Applications, Benjamin/Cummings, 1990. Cámara Costarricense de Tecnología de Información y Comunicación (CAMTIC). Consultado en http://www.camtic.org/ES/camtic/sobre_nosotros/. Accesado el 8 de agosto del 2009. Carnegie

Mellon

Software

Engineering

Institute

–

SEI.

Consultado

en

http://www.sei.cmu.edu/cmmi/. Accesado el 15 de agosto del 2009. Cleland, David; King, William. Manual para la Administración de Proyectos, Primera Edición, Décima Reimpresión. México D.F.: Compañía Editorial Continental, 2005. De Champeaux, Dennis; Lea, Douglas; Faure, Penelope. Object Oriented System Development,

Tercera

Edición.

Massachussetts:

Addison-Wesley

Publishing

Company, 1994. Diccionario

de

la

Lengua

Española.

Espasa-Calpe,

2005.

Consultado

en

http://www.wordreference.com/definicion/. Accesado el 31de agosto del 2009. Diccionario

de

la

Real

Academia

Española.

Consultado

en

http://www.rae.es/rae.html. Accesado el 10 de agosto del 2009. JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James. El Lenguaje Unificado de Modelado, Ed. Addison Wesley. 1999. LARMAN, Craig. UML y Patrones. Una introducción al análisis y diseño orientado a objetos y al proceso unificado, Segunda Edición. Ed. Addison Wesley. 2003. Mayne, Allan y Wood, Michael. Introducción a las bases de datos relacionales, Primera Edición. Madrid: Editorial Díaz de Santos, 1985.

57 Organización

Internacional

para

la

Estandarización

(ISO).

Consultado

en

http://www.iso.org. Accesado el 5 de setiembre del 2009. PMI (Project Management Institute).

Guía de los Fundamentos de la Dirección

de Proyectos, Guía del PMBOK, Tercera Edición. Pennsylvania, USA: PMI Publications, 2004. UCI (Universidad para la Cooperación Internacional). Estructura Básica para Elaborar el Documento Final del PFG. San José, 2008. Wikipedia. Consultado en http://es.wikipedia.org/. Accesado el 31de agosto del 2009. Zelkovitz, M.V; Shaw, A.C; Gannon, J.D. Principles of Software Engineering and Design.

Prentice

Halls,

1979.

58

8. ANEXOS 8.1. Anexo 1. Acta de Constitución del Proyecto Información principal y autorización de proyecto Fecha: 30-04-2009

Nombre de Proyecto: Diseño del Sistema Informático para el Seguimiento de las Tareas de Desarrollo y de Aseguramiento de la Calidad en Proyectos Informáticos para la Empresa Absolutec S.A. Áreas de conocimiento / Área de aplicación (sector / actividad): procesos: Alcance, Tiempo y Desarrollo de Sistemas de Información. Calidad. Fecha de inicio del proyecto: Fecha tentativa de finalización del proyecto: 01-09-2009 12-06-2009 Objetivos del proyecto: Objetivo General Realizar el Plan de Gestión de Proyecto para el diseño del Sistema Informático de Apoyo al Desarrollo (SIAD), la herramienta informática que apoyará el desarrollo de los sistemas informáticos que la empresa Absolutec S. A. elabora para sus clientes, abarcando las áreas de Gestión del Alcance, Gestión del Tiempo y Gestión de la Calidad. Objetivos Específicos
Realizar el levantamiento de requerimientos del SIAD a través de la recopilación de las necesidades que expresan los directores de proyectos y líderes técnicos de Absolutec S. A.
Elaborar el documento de diseño del SIAD, como base para un posterior desarrollo, implantación y uso en los proyectos desarrollados en Absolutec S.A.
Elaborar el Plan de Gestión del Alcance para las etapas de Análisis y Diseño del Sistema SIAD.
Realizar un Plan de Gestión del Tiempo para las etapas de Análisis y Diseño del Sistema SIAD.
Diseñar herramientas para controlar la calidad del proceso en las etapas de Análisis y Diseño del Sistema SIAD. Descripción del producto y entregables: El producto final del proyecto abarcará los siguientes entregables: 1. Documento de análisis del SIAD: contendrá el levantamiento de

59

2.

3. 4. 5.

requerimientos del SIAD, el análisis de requerimientos definidos, la definición de la arquitectura sobre la cual se implementará el SIAD. Documento de diseño del SIAD: contendrá la definición de casos de uso del SIAD, el diagrama de casos de uso, el diagrama de clases, los diagramas de secuencia y el modelo conceptual de la base de datos. Plan de Gestión del Alcance para las etapas de Análisis y Diseño del Sistema SIAD. Plan de Gestión del Tiempo para las etapas de Análisis y Diseño del Sistema SIAD. Herramientas para controlar la calidad del proceso en las etapas de Análisis y Diseño del Sistema SIAD.

Necesidad del proyecto: Absolutec S.A es empresa dedicada al desarrollo de software que desde su fundación en el 2001 ha desarrollado sistemas de información para diferentes compañías a nivel nacional, mediante un compromiso de calidad cuya prioridad es satisfacer las necesidades de sus clientes. Como parte de sus objetivos está el mejoramiento continuo de sus estándares y procesos de desarrollo interno, de modo que le permita cumplir a cabalidad con las exigencias del mercado tecnológico. Para la empresa es sumamente importante conocer la situación real de los proyectos para determinar las acciones a seguir. También es de gran importancia para la empresa minimizar la cantidad de incidencias que reportan los clientes en las etapas de prueba de los sistemas y, además, mejorar los tiempos de respuesta interna y frente al cliente. La idea del proyecto surge a partir de la necesidad de ese mejoramiento continuo, de responder con las mejores herramientas tecnológicas a los esfuerzos que se desarrollan para el fortalecimiento de la administración de los proyectos informáticos, principalmente en las áreas de la administración del alcance, administración del tiempo, y administración de la calidad. La herramienta tecnológica que se desarrollará permitirá conocer de manera más precisa el estado actual y real del proyecto de forma inmediata, lo que facilitará a líderes técnicos y administradores de proyectos el manejo de las diferentes situaciones que pasan los proyectos, y la elaboración de propuestas para las acciones que se deben seguir. Del mismo modo, facilitará el suministro de datos estadísticos a la gerencia para la toma de decisiones según el plan estratégico de la empresa. Justificación de impacto:

60
Incremento de la calidad del software que se desarrolla, permitiendo aplicar mejoras desde el inicio del proyecto.
Seguimiento en tiempo real del proyecto permitiendo identificar posibles atrasos antes de que se vean afectados los tiempos de entrega.
Mejoramiento de las técnicas de estimación de tiempos en los proyectos.
Mayor control sobre los requerimientos definidos en el análisis y las nuevas funcionalidades que el cliente solicita durante el desarrollo del proyecto.
Identificación, a través de reportes estadísticos, de puntos débiles en el desarrollo del proyecto, sea por mal análisis, fallas en los recursos del proyecto, mala administración, entre otros. Restricciones / limitantes / factores críticos de éxito:
La ejecución del proyecto se realizará fuera de horas laborales.
La colaboración de todas las áreas de la empresa, en cuanto a información y equipo, es fundamental para obtener de manera exitosa un producto que realmente satisfaga las necesidades de Absolutec en cuanto al seguimiento y control de la calidad en el desarrollo de sistemas informáticos. Para lograr esta integración es vital el apoyo y seguimiento del Gerente General de Absolutec.
La fecha límite de finalización del proyecto debe ser antes de 1 de setiembre del 2009. Identificación de grupos de interés (stakeholders):
Apoderado General de Absolutec S.A. (CEO), Principal
Administradores de Proyectos de Absolutec S.A.
Líderes Técnicos de Absolutec S. A.
Desarrolladores de Absolutec S.A. Aprobado por: Firma:

61

8.2. Anexo 2. EDT

62

8.3. Anexo 3. Cronograma

63

8.4. Anexo 4. Lista Chequeo para Análisis de Requerimientos

Lista Chequeo para Análisis de Requerimientos Requerimiento Mantenimiento de tareas Reportes Asignación de tareas

Analizado 

Revisado

Listo

64

8.5. Anexo 5. Lista de Chequeo para Casos de Uso

Lista de Chequeo para Casos de Uso Caso de Uso

01 02 03 04

Describe una tarea del negocio que sirva a una meta de negocio.

Tiene definido el flujo normal y los flujos alternos, con un nivel apropiado del detalle.

Tiene definido los actores o casos de uso que hacen uso de él.

Tiene definido los requerimientos que satisface.

Está representado en el diagrama de casos de uso.

Ha sido entendido, analizado y revisado por el cliente.

Ha tenido correcciones debido a observaciones del cliente.

65

8.6. Anexo 6. Lista de Chequeo para Diagrama de Clases

Lista de Chequeo para Diagrama de Clases Criterio Las clases tienen nombres significativos. Las clases tienen definidos los atributos. Las clases tiene definidos las operaciones. Los atributos tienen nombres significativos. Los atributos tienen definido el tipo de dato. Los atributos tienen definida el tipo de visibilidad. Las operaciones tienen nombres significativos. Las operaciones tienen definido los parámetros. Las operaciones tienen definidos el tipo de retorno. Las operaciones tienen definida el tipo de visibildad. Las relaciones entre las clases son lógicas y correctas. Las relaciones entre las clases tienen definida la multiplicidad. Ha sido entendido, analizado y revisado por el cliente. Ha tenido correciones debido a observaciones del cliente.

Si/No

66

8.7. Anexo 7. Lista de Chequeo para Diagramas de Secuencia

Lista de Chequeo para Diagramas de Secuencia Diagrama de Secuencia

Indica el caso de uso y escenario al que hace referencia.

Visualiza actores y clases involucradas.

Las interacciones se muestran de manera temporal.

Las operaciones (tipo de retorno y parámetros) utilizadas para el envío de mensajes están definidas en el diagrama de clases.

Ha sido entendido, analizado y revisado por el cliente.

Ha tenido correcciones debido a observaciones del cliente.

67

8.8. Anexo 8. Lista de Chequeo para el Modelo Base Datos

Lista de Chequeo para Modelo de Bases de Datos Criterio Se utiliza notación CamelCase para nombres de tablas y campos. El diagrama se encuentra en la tercera forma normal según las reglas de normalización de bases de datos. Utilización de campos varchar(MAX) en vez de campos Text. Se utilizan solamente llaves numéricas. Ha sido entendido, analizado y revisado por el cliente. Ha tenido correciones debido a observaciones del cliente.

Si/No

68

8.9. Anexo 9. Lista de Chequeo para Documentos Entregables

Lista de Chequeo para Documentos Entregables Criterio Utilización de Letra Arial Portada con logo de la empresa, nombre del cliente, etapa del proyecto, nombre del documento, fecha y número de versión. Tabla para el control de las versiones del documento: Fecha, Autor, Versión, Referencia a Cambios. Tabla de contenido. Numeración en las páginas. Ortografía revisada.

Si/No

69

8.10. Anexo 10. Análisis de Requerimientos

RE-01

Administración de Tareas

Involucrados

Programador, Líder Técnico, Administrador de Proyectos.

Descripción

Se debe realizar la creación, modificación y eliminación de tareas.

Elementos de La creación y modificación de una tarea deberá recibir los entrada de datos siguientes datos Nombre

Descripción

Identificador

Corresponde a un número consecutivo de la tarea brindado por el sistema.

Descripción

Corresponde a una descripción detallada de la tarea a realizar.

Fecha Inicio

Fecha y hora del inicio de la tarea.

Fecha Fin

Fecha y hora de finalización de la tarea.

Duración Estimada

Corresponde a la duración estimada de la tarea en días u horas.

Prioridad

Los tipos de prioridad ser Baja, Normal, Alta y Urgente.

Tipo de tarea

Los tipos pueden ser caso de uso, tarea de desarrollo, incidencia, reunión, investigación, entregable, etc.

Predecesoras

Si la tarea que se crea se realiza después de una o varias tareas, se dice que tiene tareas predecesoras. Estas tareas son listadas en este campo.

Tarea Base

En caso de que la tarea sea parte de otra tarea, es decir es una subtarea, el identificador de la tarea a la que pertenece se especifica en este campo.

Tipo de elemento

Tipos de elemento asociado a la tarea. Pueder ser mantenimiento básico, pantalla de consulta, procedimiento almacenado, proceso, reporte, cubo olap, proceso de

70 carga de datos, etc. Complejidad

Corresponde al factor de complejidad de la tarea: básico, intermedio y complejo.

Herramienta

Corresponde a la herramienta utilizada para desarrollar la tarea: SQL Server 2000, SQL Server 2005, Windows Forms, ASP .NET, Cristal Reports, Reporting Services.

Validado por Comentarios

RE-02

Carga de Estructura de Proyecto

Involucrados

Administrador de Proyectos.

Descripción

Debe existir una opción para importar una estructura de proyecto previamente definida, mediante la utilización de una hoja Excel. Microsoft Project puede almacenar los proyectos como un archivo Excel para que sea importada por la aplicación.

Elementos de El archivo a cargar debe contener la siguiente información: entrada de datos Nombre

Descripción

Descripción

Corresponde a una descripción detallada de la tarea a realizar.

Fecha Inicio

Fecha y hora del inicio de la tarea.

Fecha Fin

Fecha y hora de finalización de la tarea.

Duración Estimada

Corresponde a la duración estimada de la tarea en días y horas.

Predecesoras

Si la tarea que se crea se realiza después de una o varias tareas, se dice que tiene tareas predecesoras. Estas tareas son listadas en este campo.

Elementos de El SIAD definirá valores predeterminados para los siguientes entrada de datos datos de una tarea Nombre

Descripción

Identificador

Corresponde a un número consecutivo de

71 la tarea brindado por el sistema. Prioridad

El sistema definirá una prioridad Normal a las tareas importadas.

Tipo de tarea

Si una tarea tiene subtareas será cargada como tipo módulo, sino será cargada como tipo tarea

Tarea Base

Si es una subtarea se cargará el identificador de la tarea dentro de la cual está contenida.

Validado por Comentarios

RE-03

Administración de Recursos

Involucrados

Administrador de Proyectos, Administrador del Sistema.

Descripción

Se debe realizar la creación, modificación y eliminación de recursos, las cuales serán generales al SIAD para poder ser utilizados en los diferentes proyectos.

Elementos de La creación y modificación de un recurso deberá recibir los entrada de datos siguientes datos Nombre

Descripción

Nombre

Nombre del recurso.

Primer Apellido

Primer apellido del recurso.

Segundo Apellido

Segundo apellido del recurso.

Validado por Comentarios

RE-04

Asignación de tareas

Involucrados

Líder Técnico, Administrador de Proyectos.

Descripción

Una tarea debe asignarse a uno o más recursos. En caso de que dos tareas que se traslapen en su tiempo de ejecución sean

72 asignadas a un mismo recurso, se debe mostrar la alerta correspondiente y mostrar las opciones posibles: permitir la asignación, modificar las fechas de las tareas o asignar a otro recurso. Elementos de La asignación de tareas deberá recibir la siguiente información: entrada de datos Nombre

Descripción

Recurso

El nombre del recurso al cual se le asignará la tarea. Se escogerá de un listado.

Tarea

El nombre de la tarea que será asignada. Se escogerá de un listado.

Validado por Comentarios

RE-04

Consulta de Carga de Trabajo

Involucrados

Líder técnico, Administrador de Proyectos.

Descripción

Esta consulta debe permitir visualizar la carga de trabajo asignada a los recursos del proyecto.

Elementos de La consulta debe recibir los siguientes parámetros de búsqueda entrada de datos

Elementos de resultados de datos

Nombre

Descripción

Recurso

El recurso o recursos a ser consultados.

Fecha Desde

Fecha inicial del rango de fechas por el cual se realizará la consulta.

Fecha Hasta

Fecha final del rango de fechas por el cual se realizará la consulta.

La consulta deberá mostrar los siguientes datos por cada uno de los recursos consultados en el rango de fechas indicado. Nombre

Descripción

Tareas Asignadas

Cantidad total de tareas asignadas.

73 Horas Asignadas

Total de horas asignadas.

Validado por Comentarios

RE-06

Reporte de Carga de Trabajo

Involucrados

Líder técnico, Administrador de Proyectos.

Descripción

Este reporte debe mostrar el listado de tareas asignadas a los recursos del proyecto.

Elementos de El reporte debe recibir los siguientes parámetros de búsqueda entrada de datos

Elementos de resultados de datos

Nombre

Descripción

Recurso

El recurso o recursos que incluirá el reporte.

Fecha Desde

Fecha inicial del rango de fechas que contemplará el reporte.

Fecha Hasta

Fecha final del rango de fechas que contemplará el reporte.

El reporte deberá mostrar los siguientes datos por cada uno de los recursos consultados en el rango de fechas indicado. Nombre

Descripción

Descripción

Corresponde a una descripción detallada de la tarea a realizar.

Fecha Inicio

Fecha y hora del inicio de la tarea.

Fecha Fin

Fecha y hora de finalización de la tarea.

Duración estimada

Duración estimada de la tarea en días u horas.

Prioridad

Prioridad de la tarea.

Total Tareas

Cantidad total de tareas asignadas al recurso.

Total Horas

Total de horas asignadas al recurso.

74 Validado por Comentarios

RE-07

Consulta Historial de Asignaciones

Involucrados

Líder técnico, Administrador de Proyectos.

Descripción

Esta consulta debe permitir visualizar el historial de asignaciones que se han hecho a una tarea.

Elementos de resultados de datos

La consulta deberá mostrar los siguientes datos para la tarea seleccionada. Nombre

Descripción

Fecha

Fecha de asignación de la tarea.

Recurso

Nombre del recurso al cuál se le asignó la tarea.

Validado por Comentarios

RE-08

Ventana de Pendientes, Notificaciones y Alertas

Involucrados

Programador, Líder Técnico, Administrador de Proyecto.

Descripción

Esta ventana mostrará diariamente un listado de las tareas pendientes, de las notificaciones recibidas y de las alertas recibidas por parte del sistema.

Elementos de resultados de datos para Pendientes

Esta ventana contendrá una sección de Pendientes la cual mostrará todas las tareas pendientes que tiene el recurso. Para cada pendiente debe mostrar la siguiente información. Nombre

Descripción

75

Elementos de resultados de datos para Notificaciones

Elementos de resultados de datos para Alertas

Identificador

Corresponde a un número consecutivo de la tarea brindado por el sistema.

Fecha Asignación

Fecha y hora de asignación de la tarea.

Descripción

Corresponde a una descripción detallada de la tarea a realizar.

Fecha Inicio

Fecha y hora del inicio de la tarea.

Fecha Fin

Fecha y hora de finalización de la tarea.

Duración Estimada

Corresponde a la duración estimada de la tarea en días u horas.

Prioridad

Los tipos de prioridad ser Baja, Normal, Alta y Urgente.

Tipo de tarea

Los tipos pueden ser módulo, caso de uso ó tarea.

Tarea Base

En caso de que la tarea sea parte de otra tarea, es decir es una subtarea, el identificador de la tarea a la que pertenece se especifica en este campo.

Esta ventana contendrá una sección de Notificaciones la cual mostrará todas las notificaciones que reciba el recurso. Para cada notificación debe mostrar la siguiente información. Nombre

Descripción

Fecha

Fecha y hora de recibida la notificación.

Tipo

Corresponde al tipo de notificación recibida.

Descripción

Texto de la notificación.

Acceso Directo

Corresponde a un acceso directo al elemento adjunto a la notificación. Puede ser un acceso directo a una tarea o a un documento.

Esta ventana contendrá una sección de Alertas la cual mostrará todas las alertas que reciba el recurso. Para cada alerta debe mostrar la siguiente información. Nombre

Descripción

Fecha

Fecha y hora de recibida la alerta.

Tipo

Corresponde al tipo de alerta recibida.

76 Descripción

Texto de la alerta.

Validado por Comentarios

RE-09

Notificación de Tareas

Involucrados

Programador.

Descripción

•

•

Cuando un programador registra una nueva tarea no planificada se deberá enviar una notificación del tipo nueva tarea al líder técnico o Administrador de Proyectos de que una nueva tarea ha sido agregada por un programador. Cuando un recurso ya no tenga tareas asignadas pendientes el SIAD debe enviar una alerta del tipo seguimiento de tareas al líder técnico o administrador de proyecto para que le sean asignadas nuevas tareas.

Validado por Comentarios

RE-10

Registro de Avance de Tareas

Involucrados

Programador, Líder Técnico, Administrador de Proyecto.

Descripción

Se debe realizar un seguimiento al avance de las tareas. En caso de que no se registren las horas a final del día el SIAD debe enviar un tipo de alerta recordatorio al recurso y una alerta de avance no registrado al líder técnico u administrador de proyecto.

Elementos de El registro de avance deberá recibir la siguiente información. entrada de datos Nombre

Descripción

Horas Trabajadas

Corresponde a la cantidad de horas trabajadas en la tarea durante el día.

77 Horas Restantes Elementos de resultados de datos

Corresponde a la cantidad de horas restantes estimadas para finalizar la tarea.

El registro de avance deberá mostrar la siguiente información.

Nombre

Descripción

Porcentaje de Avance

Corresponde al porcentaje de avance en la tarea según la fórmula: (Horas Trabajadas * 100) / (Horas Trabajadas + Horas Restantes)

Validado por Comentarios

El SIAD también tener la opción de llevar la contabilización del tiempo de forma automática. En tal caso, el registro de avance será realizado por el sistema.

RE-11

Consulta de Estado de Avance

Involucrados

Líder Técnico, Administrador de Proyecto.

Descripción

La consulta debe permitir visualizar el avance diario realizado tanto en horas como en porcentaje de avance, tanto de manera general como por recurso, por módulo del sistema o por funcionalidad.

Elementos de consulta de datos

La consulta de avance deberá recibir los siguientes parámetros de consulta. Nombre

Descripción

Recurso

Recurso o recursos por los cuales se realizará la consulta.

Módulo

Módulo o módulos que contemplará la consulta.

Funcionalidad

Funcionalidad o funcionalidades que contemplará la consulta.

Fecha Consulta

Fecha hasta la cual se quiere analizar el avance del proyecto.

78

Elementos de resultados de datos

Tipo Tarea

Tipos de tareas que contemplará la consulta.

Tipo Elemento Tarea

Tipo de elemento de tarea que contemplará la consulta.

Nivel Complejidad

Tipo de nivel de complejidad de tarea que contemplará la consulta.

Tipo Herramienta

Tipo de herramienta de tarea que contemplará la consulta.

La consulta de avance deberá mostrar cualquiera de los siguientes resultados. Nombre

Descripción

Total de horas avanzadas

Representa el total de horas avanzadas según los criterios de búsqueda.

Porcentaje de avance

Porcentaje de avance según los criterios de búsqueda.

Indicador de atraso

Indica si los datos retornados presentan atraso según las estimaciones realizadas originalmente.

Validado por Comentarios

RE-12

Consulta de Horas Laboradas

Involucrados

Programador, Líder Técnico, Administrador de Proyecto.

Descripción

La consulta debe permitir ver el total de horas laboradas por un recurso, ordinarias y extras.

Elementos de consulta de datos

La consulta de horas laboradas deberá recibir los siguientes parámetros de consulta. Nombre

Descripción

Recurso

Recurso o recursos por los cuales se realizará la consulta.

Rango Fechas

Rango de fechas por el cual se consultarán las horas laboradas.

79 Elementos de resultados de datos

La consulta de avance deberá mostrar cualquiera de los siguientes resultados. Nombre

Descripción

Total de horas laboradas

Representa el total de horas laboradas según los criterios de búsqueda.

Total de horas ordinarias

Representa el total de horas ordinarias laboradas según los criterios de búsqueda.

Total de horas extra

Representa el total de horas extra laboradas según los criterios de búsqueda.

Validado por Comentarios

RE-13

Inclusión de Documentación

Involucrados

Programador, Líder Técnico, Administrador de Proyectos.

Descripción

Se debe permitir adjuntar cualquier tipo de información documental a las tareas y al proyecto en general, ya sean archivos o correos electrónicos. El SIAD debe enviar una notificación indicando que nueva documentación ha sido adjuntada a la tarea o proyecto.

Elementos de Se deberá recibir los siguientes datos entrada de datos

Validado por Comentarios

Nombre

Descripción

Fecha Documento

Corresponda a la fecha en el que el documento fue creado o recibido por parte del equipo del proyecto.

Descripción

Corresponde a una descripción detallada del documento adjuntado.

Documento

Corresponde al documento recibido.

80

RE-14

Administración de Incidencias

Involucrados

Programador, Líder Técnico, Administrador de Proyectos, Cliente.

Descripción

Se debe realizar la creación, modificación y eliminación de incidencias. Las incidencias en primera instancia deben asignarse al recurso que desarrolló la funcionalidad.

Elementos de La creación y modificación de una incidencia deberá recibir los entrada de datos siguientes datos. Nombre

Descripción

Identificador

Corresponde a un número consecutivo de la incidencia brindado por el sistema.

Descripción

Corresponde a una descripción detallada de la incidencia reportada.

Fecha Reportada

Fecha en que fue reportada la incidencia.

Fecha Atendida

Fecha en que fue atendida la incidencia.

Duración Estimada

Corresponde a la duración estimada de la incidencia en días u horas.

Persona Reporta

Nombre de la persona que reporta la incidencia.

Prioridad

Los tipos de prioridad ser Baja, Normal, Alta y Urgente.

Tipo de incidencia

Los tipos pueden ser funcionalidad, interfaz, validación de datos.

Categoría de incidencia

Las categorías pueden ser mejora, nueva funcionalidad, error.

Documentación

Documentos asociados al reporte de la incidencia.

Validado por Comentarios

El cliente accesará esta funcionalidad a través del módulo web.

RE-15

Administración de Versionamientos

Involucrados

Líder Técnico, Administrador de Proyectos.

81 Descripción

Se debe realizar la creación, modificación y eliminación de versionamientos del sistema. Cada vez que el sistema sea instalado para pruebas por parte del cliente se debe crear una versión del sistema, la cual incluirá todas la funcionalidades ya realizadas ó incidencias ya atendidas que van en dicha instalación.

Elementos de La creación y modificación de un versionamiento deberá recibir entrada de datos los siguientes datos Nombre

Descripción

Fecha

Corresponde a la fecha del versionamiento.

Validado por Comentarios

RE-16

Consulta de Versionamientos

Involucrados

Líder Técnico, Administrador de Proyecto, Cliente.

Descripción

La consulta debe permitir ver el listado de tareas ó incidencias para un versionamiento.

Elementos de consulta de datos

La consulta deberá recibir los siguientes parámetros de consulta.

Elementos de resultados de datos

Nombre

Descripción

Versionamiento

Corresponde a uno de los versionamientos registrados para el proyecto.

Módulo

Módulo o módulos que contemplará la consulta.

Funcionalidad

Funcionalidad o funcionalidades que contemplará la consulta.

La consulta deberá mostrar una lista de las tareas o incidencias pertenecientes a la versión del sistema, cada tarea o incidencia debe tener la siguiente información. Nombre

Descripción

Tipo

Indica si es funcionalidad o incidencia.

82 Identificador

Corresponde a un número consecutivo de la tarea brindado por el sistema.

Descripción

Corresponde a una descripción detallada de la tarea a realizar.

Validado por Comentarios

La consulta se deberá imprimir.

RE-17

Carga Masiva de Incidencias

Involucrados

Líder Técnico, Administrador de Proyectos, Cliente.

Descripción

El SIAD debe permitir la carga masiva de incidencias a través de un archivo Excel. Cada vez que el cliente realice la carga de incidencias, el SIAD debe enviar una notificación del tipo Incidencias al administrador de proyecto o líder técnico.

Elementos de El archivo Excel deberá tener los siguientes campos definidos. entrada de datos Nombre

Descripción

Descripción

Corresponde a una descripción detallada de la incidencia reportada.

Fecha Reportada

Fecha en que fue reportada la incidencia.

Prioridad

Los tipos de prioridad ser Baja, Normal, Alta y Urgente.

Tipo de incidencia

Los tipos pueden ser funcionalidad, interfaz, validación de datos.

Categoría de incidencia

Las categorías pueden ser mejora, nueva funcionalidad, error.

Validado por Comentarios

El cliente accesará esta funcionalidad a través del módulo web.

RE-18

Consulta de Incidencias

Involucrados

Líder Técnico, Administrador de Proyecto, Cliente.

83 Descripción

La consulta debe permitir ver el listado de incidencias.

Elementos de consulta de datos

La consulta deberá recibir los siguientes parámetros de consulta.

Elementos de resultados de datos

Nombre

Descripción

Módulo

Módulo o módulos que contemplará la consulta.

Funcionalidad

Funcionalidad o funcionalidades que contemplará la consulta.

Recurso

Recurso o recursos que atendieron la incidencia

Tipo

Tipo de incidencias que mostrará la consulta.

La consulta deberá mostrar una lista de las tareas o incidencias pertenecientes al versionamiento, cada tarea o incidencia debe tener la siguiente información. Nombre

Descripción

Tipo

Tipo de incidencia

Identificador

Corresponde a un número consecutivo de la tarea brindado por el sistema.

Descripción

Corresponde a una descripción detallada de la tarea a realizar.

Clasificación

Indica si la incidencia fue reportada internamente o por el cliente.

Reincidente

Indica si la incidencia ha sido atendida más de una vez.

Validado por Comentarios

La consulta se deberá imprimir. El cliente accesará esta funcionalidad a través del módulo web.

RE-19

Comunicación con el servidor central

Involucrados Descripción

Se debe proveer una forma de comunicación con el servidor

84 central para el trabajo en línea para los proyectos que se realizan en el cliente fuera de la red interna de Absolutec. En caso de que no pueda mantenerse una comunicación en línea debe existir una modalidad de trabajo desconectado que permita la sincronización de datos cuando el SIAD pueda entrar en línea o mediante la carga manual de un archivo XML. Validado por Comentarios

RE-20

Administración de Usuarios

Involucrados

Administrador del Sistema.

Descripción

Se debe realizar la creación, modificación y eliminación de usuarios, las cuales serán generales al SIAD para poder ser utilizados en los diferentes proyectos.

Elementos de La creación y modificación de un usuario deberá recibir los entrada de datos siguientes datos Nombre

Descripción

Nombre

Nombre del usuario.

Primer Apellido

Primer apellido del usuario.

Segundo Apellido

Segundo apellido del usuario.

Usuario

Nombre de usuario para el ingreso al sistema.

Contraseña

Contraseña de ingreso al sistema.

Validado por Comentarios

RE-21

Administración de Roles

Involucrados

Administrador del Sistema.

Descripción

Se debe realizar la creación, modificación y eliminación de roles, las cuales serán generales al SIAD para poder ser utilizados en

85 los diferentes proyectos. Elementos de La creación y modificación de un rol deberá recibir los siguientes entrada de datos datos Nombre

Descripción

Nombre

Nombre del rol.

Descripción

Descripción detallada del rol.

Validado por Comentarios

RE-22

Asignación de Usuarios a Roles

Involucrados

Administrador del Sistema.

Descripción

Los usuarios deben asignarse a roles según el proyecto en que participen.

Elementos de La asignación de usuarios a roles deberá recibir la siguiente entrada de datos información: Nombre

Descripción

Usuario

El nombre del usuario al cual se le asignará el rol. Se escogerá de un listado.

Rol

El nombre del rol que será asignado. Se escogerá de un listado.

Proyecto

Proyecto al cual se le asignará ese rol. Se escogerá de un listado.

Validado por Comentarios

RE-23

Asignación de Permisos a Roles

Involucrados

Administrador del Sistema.

Descripción

Los permisos a las funcionalidades del sistema deben asignarse a roles.

Elementos

de La asignación de permisos a roles deberá recibir la siguiente

86 entrada de datos información: Nombre

Descripción

Funcionalidad

El nombre de la funcionalidad a la cual se le dará permiso al rol. Se escogerá de un listado.

Rol

El nombre del rol al que se le dará permiso. Se escogerá de un listado.

Validado por Comentarios

RE-24

Usabilidad

Involucrados Descripción

Validado por Comentarios

La interfaz del SIAD debe permitir un rápido ingreso de la información. El registro de las tareas debe ser ágil, así como el registro de los tiempos para que no consuma tiempo excesivo y no interrumpa las labores diarias. Debe hacer uso de teclas rápidas para así disminuir el uso del mouse. Aunque no se esté utilizando el SIAD de forma directa, la información necesaria para cada usuario dependiendo de su rol debe estar a la mano, sin elementos de interfaz que distraigan el trabajo diario en las otras herramientas, es decir debe visualizarse de forma discreta y estética.

87

8.11. Anexo 11. Diagrama de Clases del SIAD

Rol

RecursosPorProyecto -Fecha : Date -Rol

Proyecto +ID : Integer +Nombre : String +Codigo : String +FechaInicio : Date +FechaFinal : Date +UsuarioCreacion : Integer +FechaCreacion : Date +Agregar(in proyecto : Proyecto) +Modificar(in proyecto : Proyecto) +Eliminar(in proyecto : Proyecto) +AgregarRecurso(in usuario : Usuario) +CrearVersionamiento(in version) +CargarEstructura(in Datos : Object) +QuitarRecurso(in Usuario : Usuario) +ListarRecursos() +ListarTareas() +CargarIncidencias(in Incidencias)

1

1

-ID : Integer -Nombre : String +Agregar(in rol : Rol) +Modificar(in rol : Rol) +Eliminar(in rol : Rol) +Listar() : Rol +AsignarUsuarios(in Usuarios : Usuario) +AsignarPermisos()

Permisos -ID : Integer -Nombre : String +Listar() : Permisos

* *

1 1 *

*

Usuario

1 *

-ID : Integer -Nombre : String -PrimerApellido : String -SegundoApellido : String -Usuario : String +Agregar(in usuario : Usuario) +Modificar(in usuario : Usuario) +Eliminar(in usuario : Usuario) +Listar() : Usuario

Alerta -ID : Integer -TipoAlerta : Integer -Fecha : Date -Descripcion : String +Agregar(in Alerta : Alerta) +Listar(in Alerta : Alerta) : Alerta

*

1 1

*

Versionamiento

Estructura

1

Asignacion

-ID : Integer -Nombre : String -TipoEstructura : Integer +Agregar(in estructura : Estructura) +Modificar(in estructura : Estructura) +Eliminar(in estructura : Estructura) +AgregarTarea() 1 *

-ID : Integer -FechaAsignacion : Date -IndActiva : Boolean

Tare

1 *

*

Documento -ID : Integer -TipoDocumento : Integer -Descripcion : String -FechaRecibido : Date -Documento : Object +Modificar(in documento : Documento) +Eliminar(in documento : Documento) +Agregar(in Documento : Documento) *

-Consecutivo : Integer -Fecha : Date -Descripción : String +Agregar(in version : Versionamiento) +Modificar(in version : Versionamiento) * +Eliminar(in version : Versionamiento) +ConsultarVersionamiento(in version : Versionamiento) : Tarea

*

Notificacion -ID : Integer -TipoNotificacion : Integer -Fecha : Date -Descripcion : String -ElementoReferencia : Object +Agregar(in notificacion : Notificacion) +Modificar(in notificacion : Notificacion) +Listar(in Recurso : Usuario) : Notificacion

1

-ID : Integer -Descripcion : String -TipoTarea : Integer -TipoElemento : Integer -Prioridad : Integer -Complejidad : Integer -FechaInicio : Date -FechaFin : Date -DuracionEstimada : Integer -Medida : Integer -Herramienta : Integer -TiempoTrabajado : Integer -TiempoRestante : Integer -PersonaReporta : String -TipoIncidencia : Integer -CategoriaIncidencia +AgregarVersion() +RegistrarAvance(in horasAvance : Integer, in horasRestantes : Integer) : Decimal +ConsultarEstadoAvance(in filtros : Tarea) : Tarea +ListarTareas(in filtros : Tarea) : Tarea +AgregarDocumento(in documento) +AsignarTarea(in recurso : Usuario) +Agregar(in Tarea : Tarea) +Modificar(in Tarea : Tarea) +Eliminar(in Tarea : Tarea) +ConsultarCargaTrabajo(in filtros : Tarea) : Tarea +ConsultarHistorialAsignaciones(in filtros : Tarea) : Tarea +ConsultarHorasLaboradas(in filtros : Tarea) : Tarea +ListarPendientes(in Recurso : Usuario) : Tarea +ConsultarIncidencias() : Tarea *

*

88

8.12. Anexo 12. Diagrama de Casos de Uso

89

8.13. Anexo 13. Ejemplos de Casos de Uso 01-Administrar Tareas Requerimientos RE-01 Actores Programador, Líder Técnico, Administrador de Proyectos Descripción Este caso de uso describe la funcionalidad del sistema para llevar a cabo la administración de las tareas Pre1.1. El usuario debe haber ingresado al sistema Condiciones PostCondiciones Curso normal de los eventos 1. El usuario selecciona la opción de administrar las tareas del proyecto. 2. El sistema muestra un diagrama de los módulos del proyecto. 3. El sistema muestra los siguientes elementos para el ingreso de datos: 3.1. Descripción: Corresponde a una descripción detallada de la tarea a realizar. 3.2. Fecha Inicio: Fecha y hora del inicio de la tarea. 3.3. Fecha Fin: Fecha y hora de finalización de la tarea. 3.4. Duración Estimada: Corresponde a la duración estimada de la tarea en días u horas. 3.5. Prioridad: Los tipos de prioridad ser Baja, Normal, Alta y Urgente. 3.6. Tipo de tarea: Los tipos pueden ser caso de uso, tarea de desarrollo, incidencia, reunión, investigación, entregable, etc. 3.7. Predecesoras: Si la tarea que se crea se realiza después de una o varias tareas, se dice que tiene tareas predecesoras. Estas tareas son listadas en este campo. 3.8. Tarea Base: En caso de que la tarea sea parte de otra tarea, es decir es una subtarea, el identificador de la tarea a la que pertenece se especifica en este campo. 3.9. Tipo de elemento: Tipos de elemento asociado a la tarea. Pueder ser mantenimiento básico, pantalla de consulta, procedimiento almacenado, proceso, reporte, cubo olap, proceso de carga de datos, etc. 3.10. Complejidad: Corresponde al factor de complejidad de la tarea: básico, intermedio y complejo. 3.11. Herramienta: Corresponde a la herramienta utilizada para desarrollar la tarea: SQL Server 2000, SQL Server 2005, Windows Forms, ASP .NET, Cristal Reports, Reporting Services. 3. Se termina el caso de uso [FA1] [FA2] [FA3]. Flujos alternos [FA1] – Insertar una tarea 1.1) El usuario indica que desea insertar una nueva tarea. 1.2) El sistema solicita que se digiten los datos de la tarea.

90 1.3) El usuario completa los datos. 1.4) El usuario selecciona la opción de guardar [FA4]. 1.5) El sistema valida que los datos fueron digitados correctamente [FE2]. 1.6) El sistema registra la información en la base de datos [FE1]. 1.7) El sistema informa al usuario del éxito de la operación. 1.8) El sistema retorna al paso 2. [FA2] – Modificar un registro 2.1) El usuario selecciona una tarea para modificación. 2.2) El sistema muestra los datos de la tarea seleccionada para modificación. [FE1]. 2.3) El usuario realiza los cambios respectivos. 2.4) El usuario selecciona la opción de guardar [FA4]. 2.5) El sistema valida que los datos fueron digitados correctamente [FE3]. 2.5) El sistema registra la información en la base de datos [FE1]. 2.6) El sistema informa al usuario del éxito de la operación. 2.7) El sistema retorna al paso 2. [FA3] – Eliminar un registro 3.1) El usuario selecciona una tarea para eliminación. 3.2) El sistema muestra la tarea seleccionada para eliminación [FE1]. 3.3) El usuario selecciona la opción de eliminar [FA4]. 3.4) El sistema solicita confirmación al usuario indicando que el registro será eliminado permanentemente 3.5) El usuario confirma la eliminación [FA4]. 3.6) El sistema elimina el registro de la base de datos [FE1]. 3.7) El sistema informa al usuario del éxito de la operación. 3.8) El sistema retorna al paso 2. [FA4] – Usuario cancela la operación 4.1) El usuario decide cancelar la operación 4.2) El sistema retorna al paso 2. Flujos de excepción [FE1] – Error ejecutando la operación 1.1) El sistema encuentra un error inesperado a la hora de ejecutar la operación solicitada. 1.2) El sistema captura el error. 1.3) El sistema registra un evento con el error. 1.4) El sistema informa al usuario sobre el problema encontrado. 1.5) Se termina el caso de uso. [FE2] – Error al validar los datos digitados para insertar 2.1) El sistema encuentra un error de validación en los datos digitados por el usuario. 2.2) El sistema informa al usuario sobre el problema encontrado. 2.3) El sistema retorna al paso 1.2 del [FA1]. [FE3] – Error al validar los datos digitados para modificar 3.1) El sistema encuentra un error de validación en los datos digitados por el usuario. 3.2) El sistema informa al usuario sobre el problema encontrado.

91 3.3) El sistema retorna al paso 2.2 del [FA2].

02-Cargar Estructura del Proyecto Requerimientos RE-02 Actores Administrador de Proyectos. Descripción Este caso de uso describe la funcionalidad para importar una estructura de proyecto previamente definida, mediante la utilización de una hoja Excel. Microsoft Project puede almacenar los proyectos como un archivo Excel para que sea importada por la aplicación. Pre1.1. El usuario debe haber ingresado al sistema Condiciones 1.2. El archivo Excel debe contener la siguiente información: • Descripción: Corresponde a una descripción detallada de la tarea a realizar. • Fecha Inicio: Fecha y hora del inicio de la tarea. • Fecha Fin: Fecha y hora de finalización de la tarea. • Duración Estimada: Corresponde a la duración estimada de la tarea en días y horas. • Predecesoras: Si la tarea que se crea se realiza después de una o varias tareas, se dice que tiene tareas predecesoras. Estas tareas son listadas en este campo. Post1.1. La información de las tareas queda debidamente cargada al Condiciones SAID. Curso normal de los eventos 1. El usuario solicita cargar la estructura del proyecto. 2. El sistema solicita la ruta del archivo Excel para realizar la carga. 3. El usuario proporciona la ruta del archivo Excel y selecciona la opción de Cargar. 4. El sistema lee el archivo y determina que la estructura de la información es correcta. [FE1] 5. El sistema carga la estructura y la información de las tareas a la base de datos. [FE1] 6. El sistema indica que la carga fue realizada exitosamente. 7. Se termina el caso de uso. Flujos alternos Flujos de excepción [FE1] – Error ejecutando la operación 1.1) El sistema encuentra un error inesperado a la hora de ejecutar la operación solicitada. 1.2) El sistema captura el error. 1.3) El sistema registra un evento con el error.

92 1.5) Se termina el caso de uso.

03-Administrar Recursos Requerimientos RE-03 Actores Administrador de Proyectos, Administrador del Sistema. Descripción Este caso de uso describe la funcionalidad del sistema para llevar a cabo la administración de los recursos. Pre1.1. El usuario debe haber ingresado al sistema Condiciones PostCondiciones Curso normal de los eventos 1. El usuario selecciona la opción de administrar los recursos del proyecto. 2. El sistema muestra los recursos existentes. 3. El sistema muestra los siguientes elementos para el ingreso de datos: 3.1. Nombre: Nombre del recurso. 3.2. Primer Apellido: Primer apellido del recurso. 3.3. Segundo Apellido: Segundo apellido del recurso. 4. Se termina el caso de uso [FA1] [FA2] [FA3]. Flujos alternos [FA1] – Insertar una tarea 1.1) El usuario indica que desea insertar un nuevo recurso. 1.2) El sistema solicita que se digiten los datos del recurso. 1.3) El usuario completa los datos. 1.4) El usuario selecciona la opción de guardar [FA4]. 1.5) El sistema valida que los datos fueron digitados correctamente [FE2]. 1.6) El sistema registra la información en la base de datos [FE1]. 1.7) El sistema informa al usuario del éxito de la operación. 1.8) El sistema retorna al paso 2. [FA2] – Modificar un registro 2.1) El usuario selecciona un recurso para modificación. 2.2) El sistema muestra los datos del recurso seleccionado para modificación. [FE1]. 2.3) El usuario realiza los cambios respectivos. 2.4) El usuario selecciona la opción de guardar [FA4]. 2.5) El sistema valida que los datos fueron digitados correctamente [FE3]. 2.5) El sistema registra la información en la base de datos [FE1]. 2.6) El sistema informa al usuario del éxito de la operación. 2.7) El sistema retorna al paso 2. [FA3] – Eliminar un registro 3.1) El usuario selecciona un recurso para eliminación. 3.2) El sistema muestra el recurso seleccionado para eliminación [FE1]. 3.3) El usuario selecciona la opción de eliminar [FA4].

93 3.4) El sistema solicita confirmación al usuario indicando que el registro será eliminado permanentemente 3.5) El usuario confirma la eliminación [FA4]. 3.6) El sistema elimina el registro de la base de datos [FE1]. 3.7) El sistema informa al usuario del éxito de la operación. 3.8) El sistema retorna al paso 2. [FA4] – Usuario cancela la operación 4.1) El usuario decide cancelar la operación 4.2) El sistema retorna al paso 2. Flujos de excepción [FE1] – Error ejecutando la operación 1.1) El sistema encuentra un error inesperado a la hora de ejecutar la operación solicitada. 1.2) El sistema captura el error. 1.3) El sistema registra un evento con el error. 1.4) El sistema informa al usuario sobre el problema encontrado. 1.5) Se termina el caso de uso. [FE2] – Error al validar los datos digitados para insertar 2.1) El sistema encuentra un error de validación en los datos digitados por el usuario. 2.2) El sistema informa al usuario sobre el problema encontrado. 2.3) El sistema retorna al paso 1.2 del [FA1]. [FE3] – Error al validar los datos digitados para modificar 3.1) El sistema encuentra un error de validación en los datos digitados por el usuario. .2) El sistema informa al usuario sobre el problema encontrado. 3.3) El sistema retorna al paso 2.2 del [FA2].

04-Asignar Tareas Requerimientos RE-04 Actores Líder Técnico, Administrador de Proyectos. Descripción Este caso de uso describe la funcionalidad para asignar una tarea a uno o más recursos del proyecto. Pre1.1. El usuario debe haber ingresado al sistema Condiciones Post1.1. Las tareas pueden ser vistas por los recursos a las cuales Condiciones fueron asignadas. Curso normal de los eventos 1. El usuario selecciona la opción de asignación de tareas. 2. El sistema muestra el listado de tareas y el listado de recursos existentes. 3. El usuario selecciona la tarea o las tareas que quiere asignar. 4. El usuario selecciona el recurso o los recursos a los cuales quiere asignar las tareas. 5. El usuario selecciona la opción de guardar [FA1].

94 6. El sistema valida que las asignaciones sean válidas [FA2]. 7. El sistema registra las asignaciones en la base de datos [FE1] [FE2]. 8. El sistema informa al usuario del éxito de la operación. 9. Se termina el caso de uso. Flujos alternos [FA1] – Usuario cancela la operación 1.1) El usuario decide cancelar la operación 1.2) Se termina el caso de uso. [FA2] – Sistema muestra mensaje de advertencia 1.1) El sistema determina que dos o más tareas que están siendo asignadas a un mismo recurso se traslapan en su tiempo de ejecución. 1.2) El sistema muestra un mensaje de advertencia y pide confirmación de si en realidad se quiere asignar en esas condiciones. 1.3) El usuario selecciona la opción de cancelar la asignación. [FA3] 1.4) Se retorna al paso 2 del curso normal de los eventos. [FA3] – Usuario confirma la asignación 1.1) El usuario selecciona la opción de aceptar la asignación. [FA3] 1.2) Se termina el caso de uso. Flujos de excepción [FE1] – Error ejecutando la operación 1.1) El sistema encuentra un error inesperado a la hora de ejecutar la operación solicitada. 1.2) El sistema captura el error. 1.3) El sistema registra un evento con el error. 1.4) El sistema informa al usuario sobre el problema encontrado. 1.5) Se termina el caso de uso.

05-Consultar Carga de Trabajo Requerimientos RE-05, RE-06 Actores Líder técnico, Administrador de Proyectos. Descripción Este caso de uso describe la funcionalidad del sistema para llevar a cabo la consulta de carga de trabajo, esta consulta permitirá visualizar la carga de trabajo asignada a los recursos del proyecto. Pre1.1. El usuario debe haber ingresado al sistema Condiciones PostCondiciones Curso normal de los eventos 1. El usuario ingresa a la opción de Consulta de Carga de Trabajo. 2. El sistema muestra los siguientes filtros de búsqueda: 2.1. Recurso: El recurso o recursos a ser consultados.

95 2.2. Fecha Desde: Fecha inicial del rango de fechas por el cual se realizará la consulta. 2.3. Fecha Hasta: Fecha final del rango de fechas por el cual se realizará la consulta. 3. El usuario llena los elementos que considere necesarios [FA1]. 4. El usuario realiza la consulta [FE1] 5. El sistema valida que haya digitado o seleccionado como mínimo un filtro [FE2]. 6. El sistema carga un listado con la siguiente información para cada uno de los recursos consultados en el rango de fechas indicado: 6.1. Tareas Asignadas: cantidad total de tareas asignadas. 6.2. Horas Asignadas: total de horas asignadas. 7. Se termina el caso de uso [FA1] [FA2]. Flujos alternos [FA1] – Cancelar la consulta 1.1) El usuario decide cancelar la consulta. 1.2) El limpia los elementos de pantalla. 1.3) El sistema retorna al paso 2. [FA2] – Imprimir reporte de la consulta 1.1) El usuario selecciona la opción de imprimir el reporte de la consulta realizada. 1.2) El sistema muestra el reporte con los siguientes datos: • Descripción: Corresponde a una descripción detallada de la tarea a realizar. • Fecha Inicio: Fecha y hora del inicio de la tarea. • Fecha Fin: Fecha y hora de finalización de la tarea. • Duración estimada: Duración estimada de la tarea en días u horas. • Prioridad: Prioridad de la tarea. • Total Tareas: Cantidad total de tareas asignadas al recurso. • Total Horas: Total de horas asignadas al recurso. 1.3) El sistema retorna al paso 7 del curso normal de los eventos. Flujos de excepción [FE1] – Error ejecutando la consulta 1.1) Se produce un error inesperado en el momento de ejecutar la consulta. 1.2) El sistema registra un evento con el error. 1.3) El sistema informa al usuario acerca del error mostrando un mensaje. 1.4) Se termina el caso de uso. [FE2] – Filtro requerido 2.1) El indica que hace falta llenar información en al menos uno de los parámetros de consulta. 2.2) El sistema retorna al paso 3.

96

8.14. Anexo 14. Ejemplo de Diagramas de Secuencia

97

98