Desarrollo e implementación de un sistema de gestión del Conclisan CIA. LTDA. en la provincia by Pontificia Universidad Católica del Ecuador sede Santo Domingo PUCE SD

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO Dirección Académica – Escuela de Sistemas

DESARROLLO E IMPLEMENTACIÓN DE UN SISTEMA DE GESTIÓN DE PROYECTOS

PARA

DEPARTAMENTO

SISTEMAS

DEL

CONCLISAN CIA. LTDA. EN LA PROVINCIA SANTO DOMINGO DE LOS TSÁCHILAS Trabajo de Titulación previo a la Obtención del Título de INGENIEROS DE SISTEMAS Y COMPUTACIÓN

LÍNEA DE INVESTIGACIÓN: ESTUDIO, DISEÑO E IMPLEMENTACIÓN DE SOFTWARE

AUTORES: PALADINES MORALES DIANA CAROLINA PANTOJA SÁNCHEZ JEFFERSON FERNANDO DIRECTOR: Mg. RICHARD ESTALIN MAFLA TOBAR

Santo Domingo – Ecuador Agosto, 2016

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO Dirección Académica – Escuela de Sistemas HOJA DE APROBACIÓN DESARROLLO E IMPLEMENTACIÓN DE UN SISTEMA DE GESTIÓN DE PROYECTOS PARA EL DEPARTAMENTO DE SISTEMAS DEL CONCLISAN CIA. LTDA. EN LA PROVINCIA SANTO DOMINGO DE LOS TSÁCHILAS LÍNEA DE INVESTIGACIÓN: ESTUDIO, DISEÑO E IMPLEMENTACIÓN DE SOFTWARE AUTORES:

PALADINES MORALES DIANA CAROLINA PANTOJA SÁNCHEZ JEFFERSON FERNANDO

Richard Estalin Mafla Tobar, Mg.

f. _______________________

DIRECTOR DEL TRABAJO DE TITULACIÓN

Willian Javier Ocampo Pozos, Mg.

f. _______________________

CALIFICADOR

Luis Javier Ulloa Meneses, Mg.

f. _______________________

CALIFICADOR

Margoth Elisa Guaraca Moyota, Mg.

f. _______________________

DIRECTORA DE LA ESCUELA DE SISTEMAS Santo Domingo – Ecuador Agosto, 2016

iii

DECLARACIÓN DE AUTENTICIDAD Y RESPONSABILIDAD Yo, Diana Carolina Paladines Morales portadora de la cédula de ciudadanía No.1722354493 declaro que los resultados obtenidos en la investigación que presento como informe final, previo la obtención del Grado de Ingeniera de Sistemas y Computación son absolutamente originales, auténticos y personales. En tal virtud, declaro que el contenido, las conclusiones y los efectos legales y académicos que se desprenden del trabajo propuesto de investigación y luego de la redacción de este documento son y serán de mi sola y exclusiva responsabilidad legal y académica.

Diana Carolina Paladines Morales CI. 172235449-3

DECLARACIÓN DE AUTENTICIDAD Y RESPONSABILIDAD Yo, Jefferson Fernando Pantoja Sánchez portador de la cédula de ciudadanía No. 230028944-0 declaro que los resultados obtenidos en la investigación que presento como informe final, previo la obtención del Grado de Ingeniero de Sistemas y Computación son absolutamente originales, auténticos y personales. En tal virtud, declaro que el contenido, las conclusiones y los efectos legales y académicos que se desprenden del trabajo propuesto de investigación y luego de la redacción de este documento son y serán de mi sola y exclusiva responsabilidad legal y académica.

Jefferson Fernando Pantoja Sánchez CI. 230028944-0

AGRADECIMIENTO Agradezco a Dios por tenerme con vida y salud, ser mi guía espiritual y haberme dado la fuerza, fortaleza y sabiduría para llegar hasta donde estoy. A mis padres por apoyarme siempre y ser mi pilar fundamental para mi formación personal y académica. A los docentes de la Escuela de Sistemas de la Pontificia Universidad Católica de Santo Domingo por los conocimientos impartidos en todos estos años de formación académica, a los compañeros que de una u otra forma aportaron en el transcurso de la carrera. Diana Paladines

Agradezco primeramente a Dios quien me acompaña día a día y me da la fuerza espiritual necesaria para seguir adelante a pesar de los obstáculos que encuentro en mi camino. A mis padres por su amor incondicional, por estar siempre ahí escuchándome y apoyándome en todas las decisiones que tomo. A todos los docentes de la Pontificia Universidad Católica del Ecuador Sede Santo Domingo por los conocimientos impartidos durante estos más de cuatro años de formación, especialmente al Mg. Richard Mafla que con sus consejos ha ayudado a sacar adelante este trabajo de titulación. Y finalmente a mis compañeros y amigos que han estado acompañándome en este camino y con los cuales he compartido y aprendido mucho. Jefferson Pantoja S.

DEDICATORIA El presente trabajo va dedicado a mis padres Maribel y Geovanny que siempre me han apoyado en las buenas y las malas, que con su amor, esfuerzo y trabajo me han formado para ser una persona de bien y responsable, a mi hermana Gissela que es mi amiga fiel y compañera de vida, a mis abuelos Eloísa y Porfirio que me han formado con sus enseñanzas y siempre me han apoyado en lo que me proponga y de manera especial dedico este trabajo a mi abuela Facunda que aunque ya no esté en este mundo terrenal, siempre me apoyó y aconsejó en todo sentido durante mi vida. Diana Paladines

Este trabajo está dedicado a las personas más maravillosas de mi vida, mis padres Olga y Felipe que gracias a ellos soy la persona que soy y estoy donde estoy, a mis hermanos, familiares y amigos que de una u otra forma me han ayudado seguir adelante. Jefferson Pantoja S.

vii

RESUMEN El presente proyecto de disertación de grado tiene como objetivo principal el Desarrollo e Implementación de un Sistema de Gestión de Proyectos para el departamento de Sistemas del CONCLISAN CIA. LTDA. en la Provincia Santo Domingo de los Tsáchilas, el cual permitirá optimizar el control y seguimiento de los diferentes proyectos realizados en dicho departamento, logrando de esta manera mejorar la comunicación de los equipos de trabajo mediante la utilización de foros y wiki colaborativo, reduciendo de esta manera el número de reuniones que se lleva actualmente para la socialización de avances y correcciones de tareas de los mismos. El software desarrollado es un sistema web enfocado bajo el paradigma orientado a objetos, que cumple con los requerimientos brindados por la institución. Para su desarrollo se utilizó la metodología clásica Incremental, que nos ayudó a interactuar con el cliente en cada etapa de su construcción, como lenguaje de programación PHP 5.2 conjuntamente con HTML5, CSS3 y JavaScript, los cuales sirven para crear un sistema web atractivo y dinámico, ayudándonos para la presentación de la interfaz de usuario en el framework MaterializeCSS. Como gestor de base de datos escogimos a MaríaDB, por su fácil utilización y procesamiento de datos, además de ser una herramienta open source, basada en el conocido SGBD MySQL.

viii

ABSTRACT The present project has as main objective the Development and Implementation of a Project Management System for the Systems department of CONCLISAN CIA. LTDA. In the Santo Domingo de los TsĂĄchilas Province, which will allow optimizing the control and monitoring of the different projects in such department, achieving to improve the communication of the teams through the use of forums and collaborative wikis, decreasing the number of meetings carried out for the socialization of progress and corrections of the tasks that take part of those projects. The software used is a web system focused on the paradigm to Objects that fulfills with the requirements provided by the institution. For its development, the incremental classic methodology, which helped to interact with the customer in each stage of its development, as programming language PHP 5.2 with HTML5, CSS3 and JavaScript, which are used to create an attractive and dynamic web system, helping for the presentation of the user interface in the MaterializeCSS framework. As data base management MarĂaDB was selected, for its easy use and data processing, also it is an open source tool based on the known SGBD MySQL.

ÍNDICE Declaración De Autenticidad Y Responsabilidad........................................................... III Agradecimiento ................................................................................................................ V Dedicatoria ...................................................................................................................... VI Resumen.........................................................................................................................VII Abstract ........................................................................................................................ VIII 1. INTRODUCCIÓN ........................................................................................................ 1 2.PLANTEAMIENTO DEL PROBLEMA ....................................................................... 2 2.1 Antecedentes ............................................................................................................... 2 2.2 Problema de investigación .......................................................................................... 3 2.3 Justificación de la investigación ................................................................................. 4 2.4 OBJETIVOS DE LA INVESTIGACIÓN ................................................................................ 5 2.4.1 Objetivo general ....................................................................................................... 5 2.4.2 Objetivos específicos ............................................................................................... 5 3. MARCO REFERENCIAL ............................................................................................ 6 3.1 Revisión de la literatura .............................................................................................. 6 3.1.1 Proyecto ................................................................................................................... 6 3.1.1.1 Tipos de Proyectos ................................................................................................ 6 3.1.1.1.1 Proyectos Clásicos ............................................................................................. 6 3.1.1.1.2 Proyectos Ágiles ................................................................................................ 6 3.1.1.1.2.1 Proyecto Informático ...................................................................................... 7 3.1.2 Administración de Proyectos ................................................................................... 8 3.1.3 Gestión de Proyectos................................................................................................ 8 3.1.3.1 Factores Críticos de Éxito ..................................................................................... 8

x 3.1.3.2 Gestión de Riesgos del Proyecto........................................................................... 9 3.1.3.3 Supervisión de Proyectos .................................................................................... 10 3.1.3.4 Jefe de Proyecto .................................................................................................. 10 3.1.3.5 Equipo del Proyecto ............................................................................................ 11 3.1.3.6 Tareas…. ............................................................................................................ 11 3.1.4 Lenguaje de Modelado Unificado (UML) ............................................................. 11 3.1.4.1 Diagrama de Casos de Uso ................................................................................. 12 3.1.4.2 Diagrama de Secuencia ....................................................................................... 12 3.1.4.3 Diagrama de Clases............................................................................................. 13 3.1.5 Arquitectura Cliente – Servidor ............................................................................. 13 3.1.6 Aplicación Web ..................................................................................................... 14 3.1.6.1 Cliente Web ........................................................................................................ 14 3.1.6.2 Protocolo HTTP .................................................................................................. 15 3.1.6.3 Servidor ............................................................................................................... 15 3.1.6.3.1 Apache ............................................................................................................. 15 3.1.6.4 HTML… ............................................................................................................. 15 3.1.6.5 PHP…… ............................................................................................................. 16 3.1.6.6 Hojas de Estilo .................................................................................................... 16 3.1.6.6.1 Materialize ....................................................................................................... 17 3.1.6.7 JavaScript ............................................................................................................ 17 3.1.6.7.1 jQuery .............................................................................................................. 17 3.1.6.7.2 AJAX .............................................................................................................. 18 3.1.6.8 Navicat .............................................................................................................. 18 3.1.6.9 XAMPP ............................................................................................................... 18 3.1.6.10 Frameworks....................................................................................................... 19

xi 3.1.7 Base de Datos ......................................................................................................... 19 3.1.7.1 Sistema Gestor de Base de Datos........................................................................ 19 3.1.7.1.1 MySQL ............................................................................................................ 20 3.1.7.1.2 MariaDB ......................................................................................................... 20 3.1.7.2

Oracle .............................................................................................................. 21

3.1.8 Modelos de procesos de software .......................................................................... 21 3.1.8.1 Métodos Tradicionales ........................................................................................ 21 3.1.8.1.1 Modelo cascada ................................................................................................ 21 3.1.8.1.2 Modelo Incremental ......................................................................................... 22 3.1.8.1.3 Modelo Espiral ................................................................................................. 22 3.1.8.2 Métodos Ágiles ................................................................................................... 23 3.1.8.2.1 Programación extrema (XP) ............................................................................ 23 3.1.8.2.2 Metodología Scrum .......................................................................................... 24 4. METODOLOGÍA DE LA INVESTIGACIÓN ........................................................... 25 4.1 Enfoque / Tipo de investigación ............................................................................... 25 4.1.1 Enfoque .................................................................................................................. 25 4.1.1.1 Enfoque Cuantitativo .......................................................................................... 25 4.1.2 Tipo de Investigación ............................................................................................. 25 4.2 Población / Muestra .................................................................................................. 26 4.2.1 Población................................................................................................................ 26 4.2.2 Muestra ................................................................................................................. 26 4.3 Técnicas e Instrumentos de recogida de datos .......................................................... 26 4.3.1 Encuesta ................................................................................................................. 27 4.3.2 Entrevista ............................................................................................................... 27 4.4 Técnicas de análisis de datos .................................................................................... 27

xii 5. RESULTADOS ........................................................................................................... 28 5.1 Discusión y análisis de los resultados ....................................................................... 28 5.1.1 Tabulación de encuesta realizada a los miembros del Departamento de Sistemas 28 5.1.2 Metodología de desarrollo de software .................................................................. 40 5.1.2.1 Etapas de Desarrollo de Software ....................................................................... 41 5.1.2.1.1 Análisis ............................................................................................................ 41 5.1.2.2 Diseño .............................................................................................................. 41 5.1.2.3 Codificación ........................................................................................................ 49 5.2 Conclusiones ............................................................................................................. 53 5.3 Recomendaciones ..................................................................................................... 54 LISTA DE REFERENCIAS ........................................................................................... 55 BIBLIOGRAFÍA ............................................................................................................ 55 GLOSARIO .................................................................................................................... 59 ANEXOS ........................................................................................................................ 61

xiii

ÍNDICE DE FIGURAS Figura 1 Diez Mandamientos de la Gestión de Proyectos Informáticos .................................... 9 Figura 2 Procesos para la Administración de Riesgos ............................................................. 10 Figura 3 Representación de una Clase ..................................................................................... 13 Figura 4. Arquitectura Cliente- Servidor de una aplicación web............................................. 14 Figura 5 Jerarquía de cascada de estilos .................................................................................. 17 Figura 6 Modelo Cascada ........................................................................................................ 22 Figura 7 Modelo incremental ................................................................................................... 22 Figura 8 Modelo Incremental................................................................................................... 23 Figura 9. Proceso de la programación extrema ........................................................................ 24 Figura 10 Metodología Scrum ................................................................................................. 24 Figura 11 Frecuencia de realización de Proyectos ................................................................... 28 Figura 12 Frecuencia de participación en Proyectos ............................................................... 29 Figura 13 Planificación de los Proyectos ................................................................................. 30 Figura 14 Porcentaje de Planificación de los Proyectos .......................................................... 31 Figura 15 Control de Avance del Proyecto .............................................................................. 32 Figura 16 Porcentaje de Culminación de Tareas ..................................................................... 33 Figura 17 Comunicación dentro del Proyecto ......................................................................... 34 Figura 18 Postergación de la Culminación de Proyectos......................................................... 35 Figura 19 Motivos de Postergación de Proyectos .................................................................... 36

xiv Figura 20 Proyectos Cancelados inesperadamente .................................................................. 37 Figura 21 Herramienta para Planificación de Proyectos.......................................................... 38 Figura 22 Herramienta de Gestión de Proyectos Personalizada .............................................. 39 Figura 23 Ejemplo de Caso de Uso.......................................................................................... 43 Figura 24 Ejemplo Diagrama de Secuencias ........................................................................... 44 Figura 25 Ejemplo Diagrama de Clases................................................................................... 45 Figura 26 Diseño Relacional de la Base de Datos ................................................................... 46 Figura 27 Interfaz de Iniciar Sesión ......................................................................................... 48 Figura 28 Interfaz Principal del Administrador ....................................................................... 48 Figura 29 Directorios de Archivos del Proyecto SGP ............................................................. 49 Figura 30 Ejemplo de Creación de Tabla ................................................................................ 50 Figura 31 Representación Clase ConexionBD ........................................................................ 51 Figura 32 Método para creación de Proyectos ......................................................................... 51

xv ÍNDICE DE TABLAS Tabla 1 Comparación de SGBD conocidos ............................................................................. 20 Tabla 2 Comparación de Tipos de Investigación ..................................................................... 25 Tabla 3 Frecuencia de realización de Proyectos ...................................................................... 28 Tabla 4 Frecuencia de participación en Proyectos ................................................................... 29 Tabla 5 Planificación de los Proyectos .................................................................................... 30 Tabla 6 Porcentaje de Planificación de los Proyectos ............................................................. 30 Tabla 7 Control del Avance del Proyecto ................................................................................ 31 Tabla 8 Porcentaje de Culminación de Tareas ......................................................................... 32 Tabla 9 Comunicación dentro de los Proyectos ....................................................................... 33 Tabla 10 Postergación de la Culminación de Proyectos .......................................................... 34 Tabla 11 Motivos de Postergación de Proyectos ..................................................................... 35 Tabla 12 Proyectos Cancelados inesperadamente ................................................................... 36 Tabla 13 Herramienta para Planificación de Proyectos ........................................................... 37 Tabla 14 Herramienta de Gestión de Proyectos Personalizada ............................................... 38 Tabla 15 Comparación Metodologías de Desarrollo ............................................................... 40 Tabla 16 Ejemplo de Tabla de Requerimiento ........................................................................ 42 Tabla 17 Comparación Sistemas Gestores de Base de Datos .................................................. 47

1. INTRODUCCIÓN Con el pasar del tiempo las aplicaciones informáticas han ido posicionándose en la sociedad, siendo actualmente una parte importante, fundamental y de mayor crecimiento en cualquier organización, puesto que éstas facilitan la optimización de procesos, tareas y servicios que brindan dichas empresas. Por este motivo el trabajo de titulación se desarrolló en el Departamento de Sistemas del CONCLISAN CIA. LTDA, ubicado en la ciudad de Santo Domingo, el cuál consistió en el desarrollo e implementación de un sistema de gestión de proyectos que permitirá controlar y dar seguimiento a los distintos proyectos que se lleven a cabo dentro del departamento de Sistemas de dicha institución. En la sección II Planteamiento del Problema se detalla los antecedentes que permitieron identificar el problema que nos conlleva a realizar este proyecto a través de los requisitos especificados por el área de sistemas de la institución, además se delimita el problema y su justificación seguida de los objetivos que se cumplirán con la implementación del presente proyecto. En la sección III Marco Referencial se especifica los principales conceptos que están involucrados en el desarrollo del software, es decir, las referencias bibliográficas que fundamentan el problema de investigación. En la sección IV Metodología de la Investigación se explica el tipo de investigación que se llevó a cabo en el proceso de desarrollo del proyecto, con los cuales se realizó la sección V Resultados, donde además se detalla la metodología de desarrollo de software seleccionada con cada una de sus fases.

2. PLANTEAMIENTO DEL PROBLEMA 2.1 Antecedentes CONCLISAN CIA. LTDA. institución privada ubicada en la Av. Quito 118 y Oranzonas del cantón Santo Domingo, provincia Santo Domingo de los Tsháchilas, brinda los servicios de atención médica por consulta externa, laboratorio clínico, emergencias, hospitalización, farmacia interna, restaurante entre otros. La visión del CONCLISAN CIA. LTDA. es: Ser líderes regionales en servicios de salud certificados, a través de la excelencia profesional con tecnología moderna y mejora continua. La misión del CONCLISAN CIA. LTDA. es: Ofrecer los mejores servicios para aliviar los problemas de salud con calidez y seguridad. En el departamento de Sistemas se realizan proyectos frecuentemente, en los cuales no se lleva un control y seguimiento digital puesto que se lo hace de manera manual y poco eficiente. El jefe de cada proyecto asignado realiza el cronograma respectivo y delega a sus colaboradores responsabilidades y se lo controla mediante reuniones de trabajo para ver el avance que llevan. Debido a que no cuentan con un software informático para realizar el control y seguimiento de los proyectos de manera ágil y rápida se desea crear el sistema de gestión de proyectos para de esta manera optimizar tiempo y recursos, puesto que así el departamento ahorrará el papel que se utiliza para la presentación de informes y de avance de sus tareas en los distintos proyectos con la implementación de una wiki colaborativa. En lo que respecta al tiempo también se optimizará, puesto que las notificaciones serán enviadas por el mismo sistema, además de un foro que les permitirá una comunicación más

3 rápida, evitando así tantas reuniones de trabajo que en ocasiones retrasan el avance de los proyectos y solo se las harían para casos puntuales cuando se deba.

2.2 Problema de investigación En CONCLISAN CIA. LTDA. el proceso para iniciar un proyecto conlleva mucho tiempo, puesto que tanto el jefe de proyecto como el director del departamento tienen que aprobarlo, para lo cual se realizan reuniones previas con propuestas iniciales hasta que el mismo sea aprobado. Además llevar un control de estos proyectos implica el gasto de recursos e insumos innecesarios para el departamento. El inconveniente principal que se abordó fue la automatización del proceso de control y seguimiento de los proyectos que se realizan dentro del departamento así como la comunicación de los participantes y el uso de insumos solo en ocasiones específicas y necesarias. Es por este motivo que se desea optimizar este proceso mediante el desarrollo del software de gestión de proyectos el cual permitirá facilitar el control y seguimiento de los proyectos que se realizarán en el departamento de Sistemas de la misma, tomando en cuenta los requisitos funcionales brindados por el responsable del departamento de la institución. El problema de investigación respondió a las siguientes preguntas de investigación: ¿El uso del sistema permitirá dar seguimiento a los proyectos que se están realizando en el departamento? ¿El uso de un sistema optimizará los recursos e insumos en el desarrollo de proyectos? ¿La disponibilidad de un foro dentro de la aplicación permitirá mejorar la comunicación entre los participantes de los distintos proyectos?

2.3 Justificación de la investigación En CONCLISAN CIA. LTDA. No existe un sistema que permita la gestión de los proyectos que se realizan, pero si cuenta con herramientas tecnológicas en las que se podrá implementar el mismo, estos motivos permiten que la realización de este proyecto sea factible. Con el desarrollo e implementación del sistema de Gestión de Proyectos se pretende optimizar el control y seguimiento de los mismos, logrando a la vez mejorar la comunicación entre los distintos participantes involucrados por medio de un foro interno, conjuntamente con un acceso a correo electrónico que permite el envío de mensajes importantes; también puede llevar un registro de todos los proyectos realizados por la institución, puesto que constará con un base de datos de la cual se podrá obtener el historial de los mismos. Otro beneficio que se obtiene con la realización de este sistema es que permite verificar el porcentaje de avance del proyecto y de cada una de las actividades de los miembros del equipo de trabajo del mismo; además cuenta con una wiki colaborativa la cual sirve como repositorio de los entregables del proyecto.

2.4 Objetivos de la investigación 2.4.1 Objetivo general Implementar un Sistema de Gestión de Proyectos para el control y seguimiento de los proyectos que se llevan a cabo en el departamento de Sistemas del CONCLISAN CIA. LTDA. 2.4.2 Objetivos específicos 

Realizar una investigación de campo para obtener la información necesaria que ayudará al desarrollo de la investigación.



Seleccionar las herramientas adecuadas para el desarrollo del sistema en base a sus necesidades.



Crear un sistema intuitivo y fácil de utilizar tomando en cuenta los requisitos funcionales y no funcionales.



Aplicar las buenas prácticas de programación en el desarrollo del sistema.



Comprobar el funcionamiento de cada módulo del sistema.



Mejorar la comunicación entre los distintos participantes de los proyectos.

3. MARCO REFERENCIAL 3.1 Revisión de la literatura 3.1.1 Proyecto Un proyecto es un conjunto de actividades planificadas y orientadas a cumplir un fin determinado, desarrolladas sistemáticamente por un grupo de personas, que posee una duración, es decir, un inicio y un final, además se lo realiza con recursos limitados y un presupuesto (Rodríguez, García, & Lamarca, 2007). El final de un proyecto “se alcanza cuando se logran los objetivos del proyecto o cuando se termina el proyecto porque sus objetivos no se cumplirán o no pueden ser cumplidos, o cuando ya no existe la necesidad que dio origen al proyecto.” (Maigua & López, 2012, pág. 12) 3.1.1.1 Tipos de Proyectos 3.1.1.1.1 Proyectos Clásicos Los proyectos clásicos son aquellos en los cuales se tienen claros el alcance y la forma en la que se van a realizar las actividades, “donde no se esperan cambios importantes a la definición del alcance y por lo tanto no se hace mucho nuevo descubrimiento, como ocurre con los proyectos convencionales”. (Hurtado, 2011, pág. 27) 3.1.1.1.2 Proyectos Ágiles Los Proyectos Ágiles son aquellos en los que el alcance del proyecto se logra a medida de su desarrollo y por ende se genera conocimiento nuevo, “como ocurre con los proyectos de construcción de software, o los proyectos para el desarrollo de una comunidad o los de investigación” (Hurtado, 2011, pág. 28)

7 3.1.1.1.2.1 Proyecto Informático “Un proyecto informático es una secuencia de actividades que se desarrollan durante un tiempo predeterminado y con recursos limitados, donde trabaja un equipo de personas, informáticos y no informáticos” (Rodríguez, García, & Lamarca, 2007, pág. 35). Para alcanzar un objetivo determinado y obtener resultados. Su principal diferencia con un proyecto general es que las actividades requieren conocimientos y habilidades en las áreas de Sistemas y Tecnologías de la Información (TI) Todo proyecto informático posee distintas fases para su realización, por esta razón varios autores y empresas las definen de diferentes maneras y muchas veces con diferentes nombres, pero se hace referencia a las mismas que mencionaremos a continuación: Aprobación, definición, planificación, ejecución, cierre. En la fase de aprobación, la organización determina las necesidades que pueden convertirse en un proyecto y analiza su viabilidad de realización, en base a eso se aprueba o no el proyecto para su posterior definición, que es la siguiente fase, donde se determinan detalladamente los requisitos y objetivos a alcanzar con el proyecto. En la fase de planificación, se dan las especificaciones del proyecto, es decir, la duración del mismo con su fecha de inicio y de finalización, quiénes trabajarán en su desarrollo indicando las actividades de cada uno, generalmente en esta fase se crean los cronogramas y se hace la distribución de recursos. En la fase de ejecución se da un seguimiento y replanificación de las actividades detalladas en la fase anterior al igual que la documentación de los cambios si existieran, es por eso que “la ejecución es un baño de realidad que solo se aprende con la experiencia, la repetición y retos progresivos” (Rodríguez, García, & Lamarca, 2007, pág. 39). Finalmente en la fase de cierre se pone en marcha el proyecto entregando su respectiva documentación de elaboración

8 y utilización, con el cumplimiento de los objetivos planteados, además se hace un plan de seguimiento del mismo para su corrección de fallas en un futuro, si las hubiera. 3.1.2 Administración de Proyectos “La administración de proyectos es la planeación, organización, coordinación, dirección y control para lograr el objetivo del proyecto” (Gido & Clements, 2012, pág. 14). Sus herramientas proporcionan al equipo de trabajo un control adecuado y a su vez flexibilidad para cumplir sus metas a tiempo y dentro del presupuesto establecido previamente. Una administración eficiente utiliza procesos de gestión en todas las etapas del ciclo de vida del proyecto, además “ahorra de manera eficiente los recursos y facilita la entrega del producto en tiempo y forma” (Lledó & Rivarola, 2007, pág. 6) 3.1.3 Gestión de Proyectos La gestión de proyectos es la aplicación de conocimiento, habilidades, herramientas y técnicas a las actividades necesarias que nos permiten planificar, organizar, gestionar y alcanzar los objetivos del proyecto, con el fin de cumplir con los requerimientos del mismo. “Además asegura que los proyectos se completan satisfactoriamente y se consiguen sus productos y resultados últimos, también nos permite hacerlo de manera que se pueda predecir y controlar su evolución y explicarlo satisfactoriamente al equipo de trabajo y al cliente.” (Rodríguez, García, & Lamarca, 2007, pág. 30) 3.1.3.1 Factores Críticos de Éxito Los factores críticos de éxito son las condiciones necesarias, ya sean individuales o en conjunto, para que ocurra el éxito del proyecto, además estos factores son subjetivos puesto que dependen de la organización que esté desarrollando el proyecto. (Rodríguez, García, & Lamarca, 2007).

9 Existe una gran variedad de factores críticos de éxito, pero los más importantes han sido agrupados en lo que se denomina “Los diez mandamientos de la gestión de proyectos informáticos”

Figura 1 Diez Mandamientos de la Gestión de Proyectos Informáticos Nota. Fuente: Rodríguez, J. R., García, M. J., & Lamarca, O. I. (2007). Gestión de proyectos informáticos: métodos, herramientas y casos. Barcelona: UOC.

“El éxito se mide por la calidad del producto y el proyecto, la oportunidad, el cumplimiento del presupuesto y el grado de satisfacción del cliente.”, mientras que “el éxito de un proyecto debe medirse en términos de completar el proyecto dentro de las restricciones de alcance, tiempo, costo, calidad, recursos y riesgo, tal y como se aprobó por los directores del proyecto.” (PMBOK, 2013, pág. 35) 3.1.3.2 Gestión de Riesgos del Proyecto El riesgo en un proyecto es un evento incierto, que si llega a ocurrir afectará de forma negativa o positiva los objetivos del mismo, al ser incierto, el riesgo no puede eliminarse, pero si se lo puede administrar. (Lledó & Rivarola, 2007)

10 La gestión de riesgos dentro de un proyecto es de gran ayuda, puesto que tiene como objetivo “aumentar la probabilidad y el impacto de los eventos positivos, así como de disminuir la probabilidad e impacto de los eventos negativos.” (PMBOK, 2013, pág. 309) Existen 6 procesos de gestión utilizados para la administración de riesgos.

Figura 2 Procesos para la Administración de Riesgos Nota. Fuente: Lledó, P., & Rivarola, G. (2007). Gestión de proyectos. Buenos Aires: Pearson Educación.

3.1.3.3 Supervisión de Proyectos La supervisión del proyecto es una actividad muy importante dentro del mismo, se encarga de seguir, revisar y comparar los logros y resultados obtenidos, frente a las estimaciones, los compromisos y planes del proyecto, los cuales ayudan a verificar si se sigue el plan de trabajo establecido o no, puesto que el reconocimiento temprano de los problemas es el primer paso para resolverlos. (Piattini, Calvo, Cervera, & Fenández, 2007) 3.1.3.4 Jefe de Proyecto El jefe de proyecto es una persona que tiene la responsabilidad del éxito o fracaso del proyecto, debido que está encargado de planificar, controlar y dirigir las actividades del mismo, la selección de éste es el primer paso para iniciar el proyecto. “El buen jefe de proyectos

11 comprende rápidamente el problema e implementa las soluciones correctas, manifestando una gran capacidad para adaptarse a los cambios.” (Lledó & Rivarola, 2007, pág. 11) “El jefe de proyecto tiene como actividad principal monitorear y controlar el trabajo realizado para obtener los productos, servicios o resultados para las cuales el proyecto fue emprendido” (PMBOK, 2013, pág. 8), además de dirigir al equipo del proyecto para que se cumplan los objetivos del mismo. 3.1.3.5 Equipo del Proyecto El equipo del proyecto está incluido principalmente por el Jefe de Proyecto junto con “el grupo de individuos que actúan conjuntamente en la realización del trabajo del proyecto para alcanzar sus objetivos” (PMBOK, 2013, pág. 35). Las personas que conforman el equipo del proyecto deben poseer conocimientos en un área específica o un conjunto de diversas habilidades específicas para llevar a cabo el trabajo del proyecto. La estructura y tamaño del equipo puede variar, pero siempre está presente el jefe quien lidera el equipo. (PMBOK, 2013) 3.1.3.6 Tareas Las tareas son actividades realizadas por personas, están limitadas por recursos escasos, necesitan ser planificadas y controladas, su característica principal es que son repetitivas y se mantienen en el tiempo, a diferencia de los proyectos que son únicos y temporales. (Lledó & Rivarola, 2007) 3.1.4 Lenguaje de Modelado Unificado (UML) UML es un lenguaje de propósito general que permite especificar, visualizar, construir y documentar los elementos que forman un sistema software, utilizado para comprender, diseñar,

12 configurar, mantener y controlar la información sobre tales sistemas. (Rumbaugh, Jacobson, & Booch, 2007) UML capta la información sobre la estructura estática y comportamiento dinámico del sistema, además puede ser utilizado con todos los métodos de desarrollo existentes, ya sean estos tradicionales o ágiles. 3.1.4.1 Diagrama de Casos de Uso Un caso de uso es la unidad de funcionalidad expresada como una transacción entre los actores y el sistema. Estos pueden describir a varios niveles de detalle, se pueden descomponer en partes y ser descritos en términos de otros casos de uso más simples. (Rumbaugh, Jacobson, & Booch, 2007) El diagrama de casos de usos es un método orientado a los usuarios que “permite modelar las funciones de un sistema en términos de eventos, quien inicia los eventos y de cómo responde el sistema estos eventos” (Fernández, 2006, pág. 131) 3.1.4.2 Diagrama de Secuencia Los diagramas de secuencia se utilizan para representar de forma detallada el comportamiento de los casos de usos, mostrando la interacción de un conjunto de mensajes como un gráfico de dos dimensiones, donde la dimensión vertical es el eje de tiempo y la dimensión horizontal representa los roles que participan en la secuencia. (Rumbaugh, Jacobson, & Booch, 2007) Cada rol del diagrama de secuencias es representado con una cabecera que contiene el nombre del mismo además de una línea de vida representada de forma vertical y dibujada como línea doble, estos roles se envían mensajes entre sí mostrados por medio de flechas desde la

13 línea de vida de un rol a la del otro, esto mensajes deben organizarse de forma cronológica hacia abajo. 3.1.4.3 Diagrama de Clases Los diagramas de clase son estructuras estáticas de alto nivel que representan las clases del sistema y sus relaciones entre ellas, su utilidad principal es mostrar lo que el sistema puede hacer además de mostrar cómo este puede ser construido. Las clases son abstracciones de objetos del mundo real y son representadas por un rectángulo dividido en tres partes, donde en la parte superior se especifica el nombre de la clase, en la intermedia van todos los atributos que la caracterizan, y en la parte inferior se detalla los métodos que son las actividades que esta puede realizar.

Figura 3 Representación de una Clase Nota: Fuente: http://i62.servimg.com/u/f62/15/22/42/16/110.jpg

3.1.5 Arquitectura Cliente – Servidor Cliente – Servidor es un tipo de arquitectura de red, que consiste en las peticiones realizadas por un usuario (cliente) hacia un servidor para recibir una respuesta esperada. El cliente y servidor pueden ser el mismo computador pero se realiza una separación lógica de acuerdo a las funciones que cada uno realiza.

14 3.1.6 Aplicación Web Una aplicación web es un tipo especial de aplicaciones cliente/servidor, codificada en un lenguaje de programación soportado por los navegadores web, se pueden distinguir dos lados dentro de la arquitectura de una aplicación web, por un lado está el cliente, que es donde el usuario se encuentra interactuando con la aplicación, y por otro el servidor, donde se encuentran los datos propios de la aplicación, además del protocolo por el cual se comunican. (Aranda, 2014). Las aplicaciones web pueden ser de acceso público o acceso restringido, además consumen pocos recursos del servidor, puesto que una vez atendido el cliente ya no es necesario mantener una comunicación entre el cliente y el servidor.

Figura 4. Arquitectura Cliente- Servidor de una aplicación web Nota. Fuente: Herrarte, P. (2012). Fundamentos de funcionamiento de una aplicación web. Recuperado de http://www.devjoker.com/contenidos/articulos/518/Fundamentos-de-funcionamiento-de-una-aplicacionweb.aspx

3.1.6.1 Cliente Web Un cliente web está formado básicamente por una navegador web el cual interpreta páginas codificadas en lenguajes de marcado que recibe de algún servidor, se denomina ligero, puesto que generalmente no accede directamente a base de datos, no ejecuta reglas de negocio complejas; sino que estas operaciones pesadas se trasladan a algún componente que es manejado por el servidor. (Roldán, Valderas, & Pastor, 2010)

15 3.1.6.2 Protocolo HTTP HTTP proviene de HyperText Transfer Protocol, que traducido al castellano es Protocolo de Transferencia de Hipertexto, es el encargado de transferir el código HTML de una página web al navegador, además establece la forma y modo en que se comunica el cliente y el servidor. (Rubiales, 2013) 3.1.6.3 Servidor Un servidor web es una máquina remota que recibe la petición HTTP por parte del cliente y devuelve código HTML generado por el servidor de aplicaciones. (Rubiales, 2013) “El servidor realiza conexiones bidireccionales y unidireccionales, síncronas o asíncronas con el cliente generando una respuesta en cualquier lenguaje o aplicación del lado del cliente.” (Talledo , 2015, pág. 48) 3.1.6.3.1 Apache Apache es un servidor web y uno de los más populares del mundo, que se debe, entre otras cosas a que es un software de alta calidad y de código abierto. Una de sus principales características es su extensibilidad basada en una gran capacidad de modulación de su código fuente, lo que ha facilitado la aparición de módulos de extensión. (Sánchez, 2012) Además apache es multiplataforma, es decir, puede utilizarse en cualquier tipo de sistema operativo, además es modular lo que significa que puede ser adaptado a diferentes entornos y necesidades. 3.1.6.4 HTML HTML proviene de HyperText Markup Language, que traducido al castellano significa Lenguaje de Marcado de Hypertexto. Este lenguaje permite presentar de forma estructurada el

16 texto y la información, y este se codifica mediante marcas o etiquetas, no solo puede mostrar texto sino que también permite insertar elementos multimedia. (Rubiales, 2013) 3.1.6.5 PHP PHP es un acrónimo de Hypertext Pre-Processor. Es un lenguaje de programación del lado del servidor concebido principalmente como una herramienta para el desarrollo de aplicaciones web, el cual permite generar páginas dinámicas bajo petición capaces de responder de manera inteligente a las demandas del cliente y que a la vez permitan automatizar una gran cantidad de tareas. “En otras palabras, PHP es un lenguaje interpretado de alto nivel, impregnado en páginas HTML y ejecutado en el servidor.” (Gutiérrez & Bravo, 2004, pág. 13) 3.1.6.6 Hojas de Estilo “Las hojas de estilo en cascada (CSS) son un mecanismo simple que describe como se mostrará un documento en la pantalla.” (Ramos & Ramos, 2011), se denomina en cascada porque aplica una jerarquía de importancia. CSS permite a los desarrolladores web controlar los estilos y formato de múltiples páginas o aplicaciones al mismo tiempo, es decir, cualquier cambio en el estilo afectará a todas las páginas vinculadas al mismo, este funciona a base de declaraciones sobre el estilo de los elementos. Existen tres versiones de CSS.

Figura 5 Jerarquía de cascada de estilos Nota. Fuente: Egea, Carlos (2007). Diseño web para tod@s II: creando una web accesible. (Pág. 21)

3.1.6.6.1 Materialize Materialize es un framework para desarrollo web moderno y responsivo basado en Material Design, está desarrollado en SASS y hace uso de las buenas prácticas en HTML, CSS y JavaScript. Materialize acelera el desarrollo proporcionando estilos por defecto, animaciones y transiciones permitiendo una experiencia más fluida a los desarrolladores; está enfocado al usuario y es fácil de trabajar gracias a la documentación detallada que posee, así como ejemplos específicos de código para ayudar a los nuevos usuarios a empezar. (Materialize, 2016) 3.1.6.7 JavaScript Es un lenguaje de programación interpretado, lo que significa que no es necesario compilarlo previamente a su ejecución. Será el propio navegador el que interprete el código y lo ejecute directamente, por lo tanto, podríamos decir que su entorno de ejecución es el navegador (Rubiales, 2013) 3.1.6.7.1 jQuery jQuery es un framework JavaScript del lado del cliente que tiene como principal objetivo simplificar el uso de comandos JavaScript, como lo indica su lema “Escribir menos para hacer más”. Es compatible con los diferentes navegadores existentes y se centra en la interacción entre el DOM, JavaScript, Ajax y HTML. (Lancker, 2014)

18 3.1.6.7.2 AJAX Ajax es un acrónimo de Asynchronous Javascript and XML, que permite el desarrollo de sitios web más dinámicos, puesto que su idea esencial es hacer una petición al servidor sin tener que recargar la página HTML. “Ajax usa la transferencia de datos asíncrona entre el navegador y el servidor web, permitiendo que las páginas web envíen pedazos de pequeñas informaciones del usuario en vez de páginas enteras.” (Arias, 2014, pág. 6) 3.1.6.8 Navicat Navicat Premium es un administrador de bases de datos de múltiples conexiones que le permite conectarse a MySQL, MariaDB, SQL Server, SQLite, Oracle y PostgreSQL simultáneamente en una sola aplicación, lo que hace que la administración de diferentes tipos de base de datos sea muy fácil. (Navicat, 2016) 3.1.6.9 XAMPP XAMPP es el entorno más popular de desarrollo con PHP, es una distribución de Apache completamente gratuita y fácil de instalar que contiene MariaDB, PHP y Perl. El paquete de instalación de XAMPP ha sido diseñado para ser increíblemente fácil de instalar y usar. (Apache Friends, 2016) XAMPP es básicamente un servidor local, el cual permite realizar pruebas de nuestras páginas web o aplicaciones con conexión a base de datos, desde nuestro ordenador personal sin necesidad de estar conectado a un servidor web o físico.

19 3.1.6.10 Frameworks “Un framework es un conjunto de bibliotecas, herramientas y normas a seguir que ayudan a desarrollar aplicaciones, están compuestos por varios segmentos o componentes que interactúan los unos con los otros.” (Lafosse, 2009, pág. 11) La utilización de frameworks ayuda a codificar aplicaciones de manera más eficaz, puesto que estos pueden ser adaptados a los proyectos evitando de esa manera tener que volver a crear código desde cero, es decir, permiten la reutilización de código. 3.1.7 Base de Datos “Una base de datos es una colección de información perteneciente a un mismo problema, que esta almacenada de forma organizada en ficheros, se encuentra organizada mediante tablas que almacenan información concerniente a algún objeto o suceso.” (López , Castellano, & Ospino, 2013, pág. 6) Las tablas se relacionan formando vínculos entre ellas, que ayudan a mantener la información de los diversos objetos de forma ordenada y coherente. Estas están formadas por filas y columnas, donde las columnas representan los campos y cada fila un registro. 3.1.7.1 Sistema Gestor de Base de Datos Un sistema gestor de base de datos (SGBD) o también conocido como sistema de administración de base de datos (DBMS) “es un conjunto de programas que maneja la estructura de la base de datos y controla el acceso a los datos guardados en ella” (Coronel, Morris, & Rob, 2011, pág. 7) , además “permite a los usuarios procesar, describir, administrar y recuperar los datos almacenados.” (Nevado, 2010, pág. 25)

20 A continuación se mencionan los SGBD más utilizados. Tabla 1 Comparación de SGBD conocidos

Product o

MS Access MS SQL Server IBM DB2 MySQL Oracle RDBMS

Número de usuarios Multiusuario Un Grupo usuari de Empres o trabaj a o

Tipo de Base de Datos Ubicación de Datos Centralizad a

Distribuid a

Uso de datos Operaciona l

Almacé n de Datos

XM L

*Soporta solo funciones XML. Los datos XML se guardan en grandes objetos de texto Nota. Fuente: Coronel, C., Morris, S., & Rob, P. (2011). Base de datos: diseño, implementación y administración. México: Cengage Learning Editores S.A. (pág. 10).

3.1.7.1.1 MySQL MySQL es un sistema de administración de base de datos relacional (RDBMS) capaz de almacenar una enorme cantidad de datos de gran variedad y de distribuirlos para cubrir las necesidades de cualquier tipo de organización, caracterizado por su facilidad de implementación (Deléglise, 2013). MySQL fue adquirido por Sun Microsystems, por lo que ofrece un licenciamiento Dual, permitiendo por un lado su uso al público bajo una licencia GNU GPL (General Public Licence), y para quienes quieran incorporarlo en productos privativos deben comprar la licencia específica que les permita su uso. 3.1.7.1.2 MariaDB MariaDB es un sistema gestor de base de datos de código abierto, que se está convirtiendo rápidamente en el reemplazo de MySQL, puesto que “posee nuevas características, como mejores pruebas, mejoras de rendimiento y corrección de errores que desafortunadamente no están disponibles en MySQL.” (Mavro, 2014)

21 En otras palabras, MariaDB es una copia de MySQL con licencia GPL, que añade nuevas funcionalidades y mejor rendimiento, además que permite migrar de MySQL a MariaDB sin mayores obstáculos, puesto que prácticamente utilizan los mismos comandos, y aprovechar las nuevas características incluidas. 3.1.7.2 Oracle “La base de datos Oracle tiene como principal característica seguir el modelo relacional además de evolucionar cada versión ofreciendo herramientas para una mejor gestión, proveyendo escalabilidad, seguridad y alto rendimiento para el almacenamiento de datos.” (Benítez & Arias, 2015, pág. 267) 3.1.8 Modelos de procesos de software Un modelo de procesos de software es una representación simplificada que busca generar estructura y orden, todos los modelos de proceso pueden incluir las actividades estructurales generales: comunicación, planeación, modelado, construcción y despliegue, pero cada una pone distinto énfasis en ella y define de forma diferente el flujo de proceso que invoca cada actividad estructural. (Presman, 2010) 3.1.8.1 Métodos Tradicionales Los métodos tradicionales centran su atención en llevar una documentación exhaustiva de todo el proyecto y en cumplir con un plan de proyecto, definido todo esto, en la fase inicial del desarrollo del proyecto. 3.1.8.1.1 Modelo cascada El modelo cascada, a veces llamado ciclo de vida clásico, sugiere un enfoque sistemático y secuencial para el desarrollo del software, que comienza con las especificación de los requerimientos por parte del cliente y avanza a través de planeación, modelado, construcción y despliegue, para concluir con el apoyo del software terminado. (Presman, 2010, pág. 34)

Figura 6 Modelo Cascada Nota. Fuente: Presman, R. (2010). Ingeniería de Software: Un enfoque práctico. México: Mc Graw Hill. (pág. 34).

3.1.8.1.2 Modelo Incremental El modelo incremental en similar al de cascada, con la diferencia de que este genera incrementos en cada iteración, por lo general los primeros incrementos incluye los requerimientos más importantes que necesita el cliente y en los siguientes incrementos se incorporan las funcionalidades faltantes del sistema, facilitando de esta manera los cambios que se realicen en el software.

Figura 7 Modelo incremental Nota. Fuente: Somemerville, I. (2011). Ingeniería de Software: México: Pearson Education. (pág. 33).

3.1.8.1.3 Modelo Espiral El modelo espiral es evolutivo, está impulsado por el riesgo, su característica principal radica en que es cíclico. Con este modelo el software se desarrolla en una serie de entregas evolutivas, donde las primeras iteraciones dan como resultado un modelo o prototipo y en las posteriores se producen versiones del sistema más completas. (Presman, 2010)

Figura 8 Modelo Incremental Nota. Fuente: Presman, R. (2010). Ingeniería de Software: Un enfoque práctico. México: Mc Graw Hill. (pág. 39).

3.1.8.2 Métodos Ágiles Los métodos ágiles se apoyan en el enfoque incremental aplicados a todas las etapas del ciclo de vida del software, además son adecuados para proyectos en los que los requerimientos varían durante el proceso de desarrollo. (Sommerville, 2011) 3.1.8.2.1 Programación extrema (XP) “La programación extrema usa un enfoque orientado a objetos como paradigma preferido de desarrollo y engloba un conjunto de reglas y prácticas que ocurren en el contexto de cuatro actividades estructurales: planeación, diseño, codificación y pruebas.” (Presman, 2010, pág. 62) Usar la metodología XP ayuda a que muchas versiones actuales de un sistema puedan desarrollarse mediante diferentes programadores, integrarse y ponerse a prueba en un día, además los requerimientos se expresan como escenarios, que se implementan directamente con una serie de tareas. (Sommerville, 2011, págs. 64,65)

Figura 9. Proceso de la programación extrema Nota. Fuente: Presman, R. (2010). Ingeniería de Software: Un enfoque práctico. México: Mc Graw Hill. (pág. 68).

3.1.8.2.2 Metodología Scrum Scrum es una de las metodologías ágiles más difundidas, “se basa en iteraciones cortas llamadas Srpints, estas tienen una duración de entre 1 y 4 semanas de las cuales cada una termina con un producto entregable” (Álvarez , Heras del Dedo, & Lasa , 2012, pág. 39), además estos Sprints se adaptan al problema a resolver y se define en tiempo real por el equipo de trabajo.

Figura 10 Metodología Scrum Nota. Fuente: Presman, R. (2010). Ingeniería de Software: Un enfoque práctico. México: Mc Graw Hill. (pág. 70)

4. METODOLOGÍA DE LA INVESTIGACIÓN 4.1 Enfoque / Tipo de investigación 4.1.1 Enfoque 4.1.1.1 Enfoque Cuantitativo El enfoque utilizado en el desarrollo de la investigación fue el cuantitativo, debido a que es orientado al proceso, es decir, todas las actividades que conllevan el desarrollo del sistema, “el enfoque cuantitativo busca brindar una explicación de los hechos que se estudian en el objeto de investigación, es decir, da respuesta al por qué de los fenómenos o causas de los eventos en estudio” (Borda Pérez, 2013, pág. 42) 4.1.2 Tipo de Investigación Tabla 2 Comparación de Tipos de Investigación CRITERIOS

VENTAJAS

INVESTIGACIÓN PURA  Centrada en la búsqueda de nuevos conocimientos y teorías  Contribuye a la adaptación de los procesos de los avances tecnológicos.



   

No se preocupa por el  campo de aplicación.  Busca la verdad antes que la utilidad de la investigación. DESVENTAJAS  Requiere la organización de todos los miembros de la investigación. Elaborado por: Diana Paladines – Jefferson Pantoja.

INVESTIGACIÓN APLICADA Centrada en la solución de problemas prácticos. Aplica la ciencia. Proponer transformar el conocimiento “puro” en conocimiento útil. Persigue fines directos e inmediatos.

Dependencia de Investigación Pura

 



 

INVESTIGACIÓN ACCIÓN Consiste en mejorar la practica Permite la generación de nuevos conocimientos al investigador y a los grupos involucrados. Obtiene el conocimiento de discusiones sobre experiencias específicas. No genera conocimiento. El resultado es más una interpretación que una explicación.

El tipo de investigación que se aplicó en el desarrollo de este trabajo de titulación fue la investigación aplicada, la cual posee una rigurosa base teórica que es utilizada por los investigadores para obtener los resultados requeridos.

26 El motivo por el que usamos este tipo de investigación es porque esta nos permite fundamentar de manera teórica el proyecto a realizar y aplicar los conocimientos adquiridos en el desarrollo del sistema que es la parte fundamental de este trabajo de titulación.

4.2 Población / Muestra 4.2.1 Población La población se considera “como el conjunto delimitado en el espacio y tiempo que definido, constituye el objeto de estudio.” (Comboni & Juárez, 2007, pág. 67) En el desarrollo de este proyecto la población fue el personal que conforma el departamento de Sistemas del CONCLISAN CIA. LTDA. es decir cuatro personas, puesto que son estas las que trabajan en los diferentes proyectos que sustentan el desarrollo del sistema. 4.2.2 Muestra La muestra es aquella parte del universo a la cual se limitó la observación. Para que la muestra sea válida se requiere que sea representativa, para ello es preciso que tenga la misma composición del universo, es decir, que presente las mismas proporciones las diferentes características de aquél. (Comboni & Juárez, 2007, pág. 68) La muestra utilizada en el desarrollo del proyecto, es el mismo valor de la población es decir el Departamento de Sistemas del CONCLISAN CIA LTDA., puesto que de momento el sistema se implementó únicamente en este departamento, el cual está compuesto por cuatro personas, por este motivo no se ha realizado el cálculo respectivo aplicando la fórmula.

4.3 Técnicas e Instrumentos de recogida de datos Para la obtención de la información necesaria para el desarrollo del sistema de gestión de proyectos, se utilizó la encuesta, que fue realizada a nuestra muestra definida anteriormente, además se utilizara una entrevista informal, puesto que únicamente la usamos para intercambio

27 de información importante sobre el sistema con la persona encargada de nuestro proyecto perteneciente a dicho departamento. 4.3.1 Técnicas de recogida de datos 4.3.1.1 Encuesta La encuesta es una búsqueda metódica de información que se apoya específicamente en preguntas y respuestas, estas preguntas son tipificadas y dirigidas a una muestra representativa, la cual permite averiguar estados de opinión o diversas cuestiones de hecho. 4.3.1.2 Entrevista La entrevista consiste en interrogar directamente a una persona que se considere fuente de información directa para el problema de investigación planteado. 4.3.2 Instrumentos de recogida de datos 4.3.2.1 Cuestionario “El cuestionario es un sistema de preguntas racionales, ordenadas de forma coherente, expresadas en un lenguaje sencillo y comprensible, que generalmente se responde de forma escrita la persona interrogada sin que sea necesaria la intervención del encuestador” (García , 2002, pág. 29) Este instrumento fue utilizado solo en la técnica de la encuesta para poder realizar un análisis con los resultados sobre la aceptación que tendría el sistema a implementar.

4.4 Técnicas de análisis de datos La técnica de análisis de datos a utilizar será la tabulación de las encuestas realizadas a nuestra muestra ya definida previamente.

5. RESULTADOS 5.1 Discusión y análisis de los resultados 5.1.1 Tabulación de encuesta realizada a los miembros del Departamento de Sistemas Pregunta 1: ¿Con qué frecuencia realizan proyectos en su lugar de trabajo? Tabla 3 Frecuencia de realización de Proyectos Detalle Mensual Trimestral Semestral Anual Total

Frecuencia Porcentaje 3 1 0 0 4

75% 25% 0% 0% 100%

Elaborado por: Jefferson Pantoja – Diana Paladines 3

75%

Mensual Trimestral Semestral

25%

Anual

Figura 11 Frecuencia de realización de Proyectos Nota. Fuente: Encuesta al Departamento de Sistemas del CONCLISAN CIA. LTDA

Análisis: Las 3 personas que representan el 75% de los encuestados respondieron que realizan proyectos de manera mensual, mientras que el 25% restante representado por una persona indico que se realizan de forma trimestral. Esto nos indica que el departamento de sistema realiza proyectos constantemente, por lo que el sistema a realizar será muy utilizado.

29 Pregunta 2: ¿Con qué frecuencia participa usted en los proyectos? Tabla 4 Frecuencia de participación en Proyectos Detalle

Frecuencia Porcentaje

Siempre Casi Siempre Algunas Veces Nunca Total

4 0 0 0 4

100% 0% 0% 0% 100%

Elaborado por: Jefferson Pantoja – Diana Paladines

100%

3 Siempre Casi Siempre

Algunas Veces Nunca

1 0%

Figura 12 Frecuencia de participación en Proyectos Nota. Fuente: Encuesta al Departamento de Sistemas del CONCLISAN CIA. LTDA

Análisis: Las 4 personas que representan el 100% de los encuestados respondieron que Siempre participan en los diferentes proyectos. Esto nos indica que todos los departamento constantemente forman parte de algún proyecto.

integrantes del

30 Pregunta 3: ¿Los proyectos en los que ha participado han sido planificados con anterioridad? Tabla 5 Planificación de los Proyectos Detalle

Frecuencia

Porcentaje

Si No Total

4 0 4

100% 0% 100%

Elaborado por: Jefferson Pantoja – Diana Paladines

100%

1 0% 0

Figura 13 Planificación de los Proyectos Nota. Fuente: Encuesta al Departamento de Sistemas del CONCLISAN CIA. LTDA

Análisis: Las 4 personas que representan el 100% de los encuestados respondieron que los proyectos en los que han participado han sido planificados con anterioridad. Esto nos indica que todos los proyectos realizados en el departamento son planificados antes de su desarrollo, por lo que el sistema a realizar debe ayudar a mejorar este proceso. Pregunta 4: ¿En qué porcentaje ha sido planificado el proyecto en el que usted ha participado? Tabla 6 Porcentaje de Planificación de los Proyectos Detalle

Frecuencia

Porcentaje

De 0% a 25% De 26% a 50% De 51% a 75% Completamente Total

0 1 1 2 4

0% 25% 25% 50% 100%

Elaborado por: Jefferson Pantoja – Diana Paladines

50%

De 0% a 25% 25%

25%

De 26% a 50%

De 51% a 75% Completamente

0% 0

Figura 14 Porcentaje de Planificación de los Proyectos Nota. Fuente: Encuesta al Departamento de Sistemas del CONCLISAN CIA. LTDA

Análisis: Las 2 personas que representan el 50% de los encuestados respondieron que la planificación de los proyectos en los que han participado es completa, el otro 25% representado por una persona indico que la planificación es del 51% a 75%, mientras que el 25% restante indico que es del 25% a 50%. Esto nos indica que aunque todos los proyectos se planifican con anterioridad, no todos cuentan con una planificación completa, factor que debería resolverse con el sistema. Pregunta 5: ¿Se ha llevado un control en el avance del proyecto en el que participado? Tabla 7 Control del Avance del Proyecto Detalle

Frecuencia

Porcentaje

Si No Total

4 0 4

100% 0% 100%

Elaborado por: Jefferson Pantoja – Diana Paladines

100%

1 0% 0

Figura 15 Control de Avance del Proyecto Nota. Fuente: Encuesta al Departamento de Sistemas del CONCLISAN CIA. LTDA

Análisis: Las 4 personas que representan el 100% de los encuestados respondieron que se lleva un control en el avance de los proyectos. Esto nos indica que el jefe de proyecto controla que todas las tareas que forman un proyecto sean cumplidas en el tiempo planificado. Pregunta 6: ¿En qué porcentaje considera usted que se ha culminado las tareas asignadas en el tiempo planificado? Tabla 8 Porcentaje de Culminación de Tareas Detalle

Frecuencia

Porcentaje

De 0% a 25% De 26% a 50% De 51% a 75% Completamente Total

0 0 3 1 4

0% 0% 75% 25% 100%

Elaborado por: Jefferson Pantoja – Diana Paladines

75%

De 0% a 25%

De 26% a 50% De 51% a 75%

25% 1

Completamente 0%

Figura 16 Porcentaje de Culminación de Tareas Nota. Fuente: Encuesta al Departamento de Sistemas del CONCLISAN CIA. LTDA

Análisis: Las 3 personas que representan el 75% de los encuestados respondieron que las tareas asignadas se completan de un 51% a 75% en el tiempo planificado del proyecto, mientras que el 25% restante representado por una persona indico que completamente. Esto nos indica que todas las tareas no se culminan en el tiempo planificado del proyecto y que de esta manera se podrá medir el rendimiento de los participantes.

Pregunta 7: ¿De qué forma se ha llevado la comunicación dentro de los proyectos en los que ha participado? Tabla 9 Comunicación dentro de los Proyectos Detalle Reuniones de Trabajo Entrevista con el Jefe de Proyecto Correo electrónico Otros Total

Frecuencia Porcentaje 2 0 0 2 4

50% 0% 0% 50% 100%

Elaborado por: Jefferson Pantoja – Diana Paladines

50%

50% Reuniones de Trabajo Entrevista con el Jefe de Proyecto

Correo electónico Otros 0%

Figura 17 Comunicación dentro del Proyecto Nota. Fuente: Encuesta al Departamento de Sistemas del CONCLISAN CIA. LTDA

Análisis: Las 2 personas que representan el 50% de los encuestados respondieron que la comunicación dentro del proyecto se realiza mediante reuniones de trabajo con todo el equipo, mientras que el 50% restante dijo que era mediante otros, que se refiere a todas las opciones anteriores. Esto nos indica que existe una comunicación entre todos los miembros del proyecto, la cual puede mejorarse con la implementación de un foro. Pregunta 8: ¿Se ha postergado alguna vez la fecha de culminación de los proyectos en los que ha participado? Tabla 10 Postergación de la Culminación de Proyectos Detalle

Frecuencia

Porcentaje

Si No Total

4 0 4

100% 0% 100%

Elaborado por: Jefferson Pantoja – Diana Paladines

100%

3 Si

1 0% 0

Figura 18 Postergación de la Culminación de Proyectos Nota. Fuente: Encuesta al Departamento de Sistemas del CONCLISAN CIA. LTDA

Análisis: Las 4 personas que representan el 100% de los encuestados respondieron que la fecha de culminación de los proyectos en los que han participado se ha postergado. Esto nos indica que no todos los proyectos culminan en el tiempo planificado, punto muy importante a tomar en cuenta en el desarrollo del sistema. Pregunta 9: ¿Cuál de los siguientes motivos ha sido para usted el más frecuente para la postergación de las fechas de finalización de los proyectos? Tabla 11 Motivos de Postergación de Proyectos Detalle

Frecuencia

Porcentaje

Falta de Presupuesto Falta de Recursos Humanos Falta de Recursos Tecnológicos Otros Total

1 0 2 1 4

25% 0% 50% 25% 100%

Elaborado por: Jefferson Pantoja – Diana Paladines

50%

Falta de Presupuesto 25%

25%

Falta de Recursos Humanos

Falta de Recursos Tecnológicos Otros

0% 0

Figura 19 Motivos de Postergación de Proyectos Nota. Fuente: Encuesta al Departamento de Sistemas del CONCLISAN CIA. LTDA

Análisis: Las 2 personas que representan el 50% de los encuestados respondieron que el motivo de postergación de las fecha de culminación del proyecto se debe a falta de recursos tecnológicos, refiriéndose a hardware y software necesario para el desarrollo del mismo; el otro 25% representado por una persona indico que es debido a falta de recursos presupuesto; mientras que el 25% restantes dijo que es debido a otros motivos. Esto nos indica que existen muchos factores que pueden derivar a que la finalización del proyecto planificado sea aplazada, lo cual debe tomarse muy encuesta en el sistema. Pregunta 10: ¿En los proyectos que ha participado han sido cancelados inesperadamente? Tabla 12 Proyectos Cancelados inesperadamente Detalle

Frecuencia

Porcentaje

Si No Total

0 4 4

0% 100% 100%

Elaborado por: Jefferson Pantoja – Diana Paladines

100%

1 0% 0

Figura 20 Proyectos Cancelados inesperadamente Nota. Fuente: Encuesta al Departamento de Sistemas del CONCLISAN CIA. LTDA

Análisis: Las 4 personas que representan el 100% de las encuestadas respondieron que los proyectos no han sido cancelados de manera inesperada. Esto nos indica que en el departamento los proyectos no son cancelados una vez que se haya iniciado su desarrollo. Pregunta 11: ¿Ha utilizado usted alguna herramienta que le ayude en la planificación de los proyectos en los que ha participado? Tabla 13 Herramienta para Planificación de Proyectos Detalle

Frecuencia

Porcentaje

Si No Total

1 3 4

25% 75% 100%

Elaborado por: Jefferson Pantoja – Diana Paladines

75%

2 Si No 25% 1

Figura 21 Herramienta para Planificación de Proyectos Nota. Fuente: Encuesta al Departamento de Sistemas del CONCLISAN CIA. LTDA

Análisis: Las 3 personas que representan el 75% de las encuestadas respondieron que no han utilizado una herramienta para la planificación del proyecto, mientras que el 25% restante representado por una persona indico que ha utilizado herramientas de planificación. Esto nos indica que no todos los miembros del departamento tienen experiencia en el uso de este tipo de herramientas, por tal motivo el sistema a desarrollar debe ser intuitivo y fácil de utilizar. Pregunta 12: ¿Le gustaría utilizar una herramienta de gestión de proyectos que satisfaga las dificultades presentadas? Tabla 14 Herramienta de Gestión de Proyectos Personalizada Detalle

Frecuencia

Porcentaje

Si No Total

4 0 4

100% 0% 100%

Elaborado por: Jefferson Pantoja – Diana Paladines

100%

1 0% 0

Figura 22 Herramienta de Gestión de Proyectos Personalizada Nota. Fuente: Encuesta al Departamento de Sistemas del CONCLISAN CIA. LTDA

Análisis: Las 4 personas que representan el 100% de los encuestados respondieron que les gustaría utilizar una herramienta de gestión de proyectos que satisfaga las dificultades presentadas. Esto nos indica que todos los miembros del departamento utilizaran el sistema y que tendrá una buena acogida.

40 5.1.2 Metodología de desarrollo de software Tabla 15 Comparación Metodologías de Desarrollo CRITERIOS

MODELO CASCADA   

VENTAJAS

 

Sencillez Requerimientos rígidos Necesita recursos mínimos Documentación en cada etapa Calidad alta del producto final



    

Los requerimientos  deben estar establecidos al inicio  del proyecto  Permite la realimentación al finalizar todo el DESVENTAJAS proceso  El cliente ve el producto en las etapas finales  Cambios resulta costosos Elaborado por: Diana Paladines – Jefferson Pantoja.

MODELO INCREMENTAL Reduce el tiempo de desarrollo parcial Entrega temprana de partes del sistema Fácil de implementar cambios El cliente se involucra más en el desarrollo Evita proyectos largos Requiere mucha planeación Requiere metas claras para conocer el estado del proyecto

METODOLOGIA XP      

Da lugar a una programación organizada Tasa de error muy pequeña Realiza pruebas constantes durante el proyecto Facilita cambios Útil para proyectos a corto plazo Requiere un rígido ajuste a los principios de XP

Para el desarrollo del proyecto se cuenta con todos los requisitos ya establecidos, aunque al ser un tema poco conocido por los investigadores no se tiene claro los procesos que se llevarán a cabo, es por eso que se ha elegido el modelo incremental como metodología de desarrollo gracias a sus múltiples ventajas, las cuales nos ayudan a interactuar con el encargado del departamento de sistemas del CONCLISAN CIA. LTDA., permitiendo mejorar y corregir los procesos en las siguientes iteraciones. Aunque esta metodología requiere la entrega de partes operativas del sistema en cada avance, nosotros utilizamos las iteraciones para corrección de procesos, puesto que al final se implementa el sistema completo.

41 5.1.2.1 Etapas de Desarrollo de Software 5.1.2.1.1 Análisis En esta etapa se realizó la entrevista con la persona encargada del proyecto en la institución para conocer las necesidades que impulsaron el desarrollo del Sistema de Gestión de Proyectos, las cuales nos permitieron establecer los requerimientos funcionales del sistema. Una vez analizados los requisitos se procedió a la elaboración del SRS (Especificación de Requerimientos de Software), basándonos en el estándar IEEE 830, donde se detallan los requerimientos funcionales y no funcionales del sistema. (Ver Anexo 1) El SRS final no fue afectado por los incrementos del

software, puesto que los

requerimientos definidos no cambiaron en el transcurso del desarrollo, solo se mejoraron ciertos procesos que no afectaron de manera específica el mismo, debido a que los requerimientos estaban detallados de forma general. 5.1.2.2 Diseño 

Tabla de Requerimientos En esta etapa a partir del SRS obtenido en la fase anterior, se procedió a analizar cada uno

de los procesos de los requisitos, con los cuales se construyeron las tablas de requerimientos funcionales y no funcionales de manera detallada. Las tablas obtenidas no fueron afectadas en gran magnitud por los incrementos del sistema realizado. A continuación se especifica una de ellas, las demás tablas se encuentran en el Anexo 2.

42 Tabla 16 Ejemplo de Tabla de Requerimiento Descripción del Caso de Uso Nombre Tipo Requerimiento Descripción

Crear Proyecto Requerimiento Funcional

Flujo Normal

Flujo Alternativo

Postcondiciones

RF14

El sistema debe permitir que el administrador cree todos los proyectos que se realizarán en la institución. Administrador

Actores Precondiciones

N° Requerimiento

Frecuencia

Ocasional

  

El usuario debe iniciar sesión El sistema debe tener registrado al menos un participante El sistema debe tener creado el rol Jefe de proyecto Acción del Actor Acción del Sistema 1. El usuario da clic en la opción 2. El sistema devuelve una interfaz Crear Proyecto ubicada en el solicitando el ingreso de todos los datos ítem Proyectos del menú correspondientes para la creación del principal del sistema. nuevo proyecto. 3. El usuario ingresa: 5. El sistema comprueba que todos los  Nombre del Proyecto campos estén llenos y guarda los datos  Presupuesto en la respectiva base de datos  Departamento 4. El usuario da clic en el botón Registrar Acción del Actor Acción del Sistema  El usuario no ingresa datos en  El sistema muestra un mensaje de los campos error.  El usuario ingresa datos que no cumplan con el formato establecido para el campo. Una vez finalizado el proceso de creación de proyecto, el sistema desplegará la interfaz para asignar el Jefe de Proyecto, detallado en el RF18

Fecha Creación Técnico Responsable

14-dic-2015

Fecha Implementación

29-feb-2016

Diana Paladines – Jefferson Pantoja

Elaborado por: Diana Paladines – Jefferson Pantoja Nota. Fuente: Anexo 2: Tabla de Requerimientos



Diagramas UML Las tablas especificadas anteriormente facilitaron la creación de los casos de uso, así como

el desarrollo de los diagramas de secuencia y de clases. (Ver Anexo 3)

43 A continuaciĂłn se detalla el Caso de Uso general con los procesos principales de los tres tipos usuarios de usuario del sistema: Administrador, Jefe de Proyecto y Participante.

Figura 23 Ejemplo de Caso de Uso Nota. Fuente: Anexo 3: Diagramas UML Elaborado por: Jefferson Pantoja â&#x20AC;&#x201C; Diana Paladines (2016)

44 A continuaciĂłn se detalla el diagrama de secuencias del usuario Administrador.

Figura 24 Ejemplo Diagrama de Secuencias Nota. Fuente: Anexo 3: Diagramas UML Elaborado por: Jefferson Pantoja â&#x20AC;&#x201C; Diana Paladines (2016)

45 A continuación se detalla el diagrama de clases con sus respectivos métodos y relaciones.

Figura 25 Ejemplo Diagrama de Clases Nota. Fuente: Anexo 3: Diagramas UML Elaborado por: Jefferson Pantoja – Diana Paladines (2016)



Diagrama de Base de Datos El diseño relacional de la base de datos se realizó a partir de las tablas de requerimientos,

así como también de los diagramas UML, detallados anteriormente. Para la parametrización de los nombres de las tablas y campos se utilizó la siguiente sintaxis: El nombre de las tablas inicia con los caracteres sgp (denominado así por las iniciales de Sistema Gestión de Proyectos) seguido de un guion bajo y los cuatro primeros caracteres del nombre de la tabla, en caso que esté formado por más de una palabra se utilizó las dos iniciales de cada palabra. Por ejemplo: “sgp_prre” haciendo referencia a la tabla proyectos recursos.

46 El nombre de los campos inicia con los tres primeros caracteres del nombre de la tabla seguido de un guion bajo y la los 4 primeros caracteres de la funcionalidad del campo, en caso de que esté formado por más de una palabra se utilizó las dos iniciales de cada palabra. Por ejemplo: “pro_fein” hace referencia al campo fecha de inicio de la tabla proyectos. El diccionario de datos se generó desde PhpMyAdmin, donde se detalla la funcionalidad de cada tabla y sus respectivos campos. (Ver Anexo 5). A continuación se muestra el diagrama de la base de datos de SGP:

Figura 26 Diseño Relacional de la Base de Datos Fuente: Sistema Gestor de Base de Datos MariaDB

A continuación se detalla una tabla comparativa de los sistemas gestores de base de datos que hemos considerado más importantes:

47 Tabla 17 Comparación Sistemas Gestores de Base de Datos CRITERIOS 

VENTAJAS

   

DESVENTAJAS

MARIADB Instalación e implementación simple Open source Nuevos motores de almacenamiento Compatible con MySQL No existen desventajas hasta el momento

 

  

MYSQL Velocidad al realizar operaciones Bajo costo en requerimientos para la elaboración de base de datos Facilidad de configuración e instalación Poca documentación de sus utilidades Poco intuitivo comparado con otros SGBD

 

  

ORACLE Sistema de gestión y control y centralizado Estandarización

Funcionalidad limitada Incompatibilidad complejidad Licencia de pago

Fuente: Elaborado por: Jefferson Pantoja – Diana Paladines (2016)

Basándonos en sus múltiples ventajas hemos elegido a MariaDB como el gestor de base de datos, además de ser este el utilizado en el CONCLISAN CIA. LTDA., así como su fácil utilización y compatibilidad con MySQL. 

Interfaz El desarrollo de las interfaces se realizó utilizando tonos del color azul, puesto que este es

el color representativo de CONCLISAN CIA. LTDA., conjuntamente con el color negro para la fuente de los títulos principales de cada interfaz. (Ver Anexo 7) A continuación se muestran capturas de la interfaz de inicio de sesión del sistema, así como también de la interfaz principal del usuario Administrador.

Figura 27 Interfaz de Iniciar Sesión Nota. Fuente: Anexo 7: Manual de Usuario Elaborado por: Jefferson Pantoja – Diana Paladines (2016)

Figura 28 Interfaz Principal del Administrador Nota. Fuente: Anexo 7: Manual de Usuario Elaborado por: Jefferson Pantoja – Diana Paladines (2016)

49 5.1.2.3 Codificación En esta etapa convertimos las tablas de requerimiento en código. Para esta etapa se utilizaron las herramientas PHP5, HTML5, CSS3, JavaScript, los cuales combinados permiten la obtención de un sistema amigable en entorne web, además el paradigma de programación utilizado fue orientado a objetos. A continuación se muestran los directorios de archivos que forman el proyecto SGP, donde se encuentran separados los archivos PHP, de los JavaScript y de las hojas de estilo.

Figura 29 Directorios de Archivos del Proyecto SGP Nota. Fuente: Sistema de Gestión de Proyectos Elaborado por: Jefferson Pantoja – Diana Paladines (2016)

50 La creación de las tablas de la base de datos se realizó por medio de comandos SQL. A continuación se detalla un ejemplo de la creación de una de las tablas de la base de datos del sistema.

Figura 30 Ejemplo de Creación de Tabla Nota. Fuente: Sistema de Gestión de Proyecto Elaborado por: Jefferson Pantoja – Diana Paladines (2016)

Se creó una clase por cada tabla, donde se definen los atributos y métodos a utilizar para la manipulación de los objetos instanciados de cada clase. Para realizar la conexión con la base de datos se creó una clase abstracta, que además contiene el método para ejecutar cualquier consulta SQL realizada en los diferentes métodos de las clases. A continuación mostraremos la representación de la clase ConexionBD:

Figura 31 Representación Clase ConexionBD Nota. Fuente: Sistema de Gestión de Proyectos Elaborado por: Jefferson Pantoja – Diana Paladines (2016)

A continuación mostramos el método utilizado para la creación de proyectos, perteneciente a la clase Proyecto.

Figura 32 Método para creación de Proyectos Nota. Fuente: Sistema de Gestión de Proyectos Elaborado por: Jefferson Pantoja – Diana Paladines (2016)

52 5.1.2.4 Pruebas En esta etapa se realizaron las pruebas del sistema de acuerdo a las iteraciones consideradas en el Cronograma de Actividades (Ver Anexo 8). Cada iteración fue revisada por el encargado del departamento de sistemas de CONCLISAN CIA. LTDA. conjuntamente con un miembro de este, donde cada recomendación de mejora de los procesos del sistema era registrada en una ficha de pruebas (Ver Anexo 10) la cual era firmada por cada una de las partes al finalizar la revisión y en la siguiente reunión se presentaban las mejoras realizadas seguidas de la nueva iteración. Una vez finalizadas todas las iteraciones para el desarrollo del sistema se procedió a realizar la implementación del mismo utilizando una máquina virtual en CENTOS proporcionada por la organización, donde se configuraron todas las herramientas necesarias para el funcionamiento del sistema, al cual se puede acceder únicamente desde los dispositivos de la CONCLISAN CIA. LTDA. específicamente el departamento de sistemas.

5.2 Conclusiones 

La utilización de herramientas Open Source como MariaDB, PHP, Apache en el

desarrollo del sistema beneficiaron el ahorro de recursos monetarios puesto que estas pueden sustituir las de tipo privadas sin ningún inconveniente y tienen las mismas funcionalidades. Además existe gran cantidad de documentación e información de las mismas lo cual nos permite dar solución a problemas de forma efectiva y en poco tiempo. 

El modelo Incremental de desarrollo de software nos permitió interactuar de manera

directa con el cliente para establecer de forma clara los procesos que se llevarán a cabo en el sistema. 

El sistema de gestión de proyectos ayuda a facilitar el control y seguimiento de los

mismos, permitiendo crear proyectos con sus respectivos participantes y estos con sus roles, además asignarles recursos y monitorear el avance de sus tareas. 

El uso de las buenas prácticas al momento de programar son indispensables porque

permiten dar al sistema escalabilidad, puesto que detallan los comentarios de cada segmento de código y de esta manera poder solucionar problemas en el futuro y aplicar una mejora continua al sistema. 

La implementación del foro en el sistema mejoró la comunicación de los participantes

registrados en el sistema mediante el intercambio de mensajes que ayudan a resolver algún problema presentado durante el desarrollo del proyecto sin la necesidad de convocar a reuniones.

5.3 Recomendaciones 

La elección de las herramientas para el desarrollo debe ser en base al alcance del sistema

puesto que muchas veces los softwares Open Source no siempre cumples a cabalidad este y el querer ahorrar puede traer malas consecuencias. 

Al momento de desarrollar el software se debe tener definido la metodología de

software que se va a usar, debido a que es una desventaja cambiar de metodología en las últimas etapas de desarrollo puesto que involucra costos de tiempo y dinero. 

El análisis y diseño de la base de datos debe ser claro y conciso puesto que es la parte

esencial del sistema para que exista un correcto manejo de los datos. 

Utilizar el navegador Google Chrome para la ejecución del sistema por su velocidad y

recursos que facilitan la navegación en sistemas de entorno web, además de que es compatible con las herramientas utilizadas, PHP, HTLM, JavaScript, CSS. 

La implementación del foro está pensada para abordar temas relacionados con los

proyectos y por tal motivo el mal uso de este puede afectar a que se emitan mensajes innecesarios para los participantes que están trabajando en alguno de los proyectos.

LISTA DE REFERENCIAS BIBLIOGRAFÍA Álvarez , A., Heras del Dedo, R., & Lasa , C. (2012). Manual Imprescindible Métodos Ágiles y Scrum. En A. Álvarez, R. Heras del Dedo, & C. Lasa, Manual Imprescindible Métodos Ágiles y Scrum (pág. 39). Madrid: Anaya Multimedia. Apache

Friends.

(25

Enero

2016).

XAMPP.

Obtenido

XAMPP:

https://www.apachefriends.org/es/index.html Aranda, J. (2014). Desarrollo y reutilización de componentes software y multimedia mediante lenguajes de guión. Madrid : IC Editorial. Arias, Á. (2014). Aprende a Programas Ajax y jQuery. Eisenbrauns. Benítez, M. Á., & Arias, Á. (2015). Curso de Introducción a la Administración de Base de Datos. Borda Pérez, M. (2013). El Proceso de Investigación: Visión general de su desarrollo. En M. Borda Pérez, El Proceso de Investigación: Visión general de su desarrollo (pág. 42). Barranquilla, Colombia : Universisad del Norte. Comboni, S., & Juárez, J. (2007). Introducción a las técnicas de investigación. En S. Comboni, & J. Juárez, Introducción a las técnicas de investigación (págs. 67, 68). México: Trillas. Coronel, C., Morris, S., & Rob, P. (2011). Base de datos: diseño, implementación y administración. En C. Coronel, S. Morris, & P. Rob, Base de datos: diseño, implementación y administración (pág. 7). México: Cengage Learning Editores S.A. Deléglise, D. (2013). MySQL 5: Guía de referencia del desarrollador. En D. Deléglise, MySQL 5: Guía de referencia del desarrollador (pág. 28). Cornellà de Llobregat, Barcelona: Ediciones ENI.

56 Fernández, V. (2006). Desarrollo de Sistemas de Información: Una Metodología basada en el Modelado. Barcelona: UPC. García , F. (2002). El cuestionario : recomendaciones metodológicas para el diseño de cuestionarios. En F. García, El cuestionario : recomendaciones metodológicas para el diseño de cuestionarios. (pág. 29). México: Limusa Noriega Edits. Gido, J., & Clements, J. (2012). Administración exitosa de Proyectos. En J. Gido, & J. Clements, Administración exitosa de Proyectos (pág. 14). Mason,OH: South-Western. Gutiérrez, A., & Bravo, G. (2004). PHP4 a través de ejemplos. En A. Gutiérrez, & G. Bravo, PHP4 a través de ejemplos (pág. 13). México: Alfaomega Ra-ma. Hurtado, F. (2011). Dirección de ¨Proyectos: Una Introducción con base en el marco del PMI. En F. Hurtado, Dirección de ¨Proyectos: Una Introducción con base en el marco del PMI (págs. 27,28). Bloomington: Palibrio. Lafosse, J. (2009). Scruts 2: El framework de desarrollo de aplicaciones Java EE. En J. Lafose, Scruts 2: El framework de desarrollo de aplicaciones Java EE (pág. 11). Barcelona: Ediciones ENI. Lancker, L. (2014). jQuery: El framework Javascript de la Web 2.0. Barcelona : Ediciones ENI. Lledó, P., & Rivarola, G. (2007). Gestión de proyectos. En P. Lledó, & G. Rivarola, Gestión de proyectos (pág. 11). Buenos Aires: Pearson Educacion. López , I., Castellano, M., & Ospino, J. (2013). Base de Datos. En I. López, M. J. Castellano, & J. Ospino, Base de Datos (pág. 6). México D.F.: Alfaomega.

57 Maigua, G., & López, E. (2012). Buenas prácticas en la dirección y gestión de proyectos informáticos. En G. Maigua, & E. López, Buenas prácticas en la dirección y gestión de proyectos informáticos (pág. 12). Tucumán: U.T.N. Materialize.

(27

Enero

2016).

Materialize.

Obtenido

Materialize:

http://materializecss.com/ Mavro, P. (2014). MariaDB high performance : familiarize yourself with the MariaDB system and build high-performance applications. Birmingham, England: Packt Publishing. Navicat. (27 de Enero de 2016). Navicat. Obtenido de Navicat: https://www.navicat.com/es/ Nevado, M. V. (2010). Introducción a las Bases de Datos Relacionales. En M. V. Nevado, Introducción a las Bases de Datos Relacionales (pág. 25). Madrid: Visión Libros. Piattini, M., Calvo, J., Cervera, J., & Fenández, L. (2007). Análisis y Diseño detallado de aplicaciones informáticas de gestión. RA-MA. Presman, R. (2010). Ingeniería de Software: Un enfoque práctico. En R. Presman, Ingeniería de Software: Un enfoque práctico (págs. 34,62). México: Mc Graw Hill. Project, I. M. (2013). Guía de los Fundamentos Para la Dirección de Proyectos (Guía del PMBOK). En I. M. Project, Guía de los Fundamentos Para la Dirección de Proyectos (Guía del PMBOK) (pág. 35). Newtown Square, Pensilvania: Project Management Institute. Ramos, A., & Ramos, M. J. (2011). Aplicaciones Web. En A. Ramos, & M. J. Ramos, Aplicaciones Web (pág. 55). Madrid: Parainfo. Rodríguez, J. R., García, M. J., & Lamarca, O. I. (2007). Gestión de proyectos informáticos: métodos, herramientas y casos. Barcelona: UOC.

58 Roldán, D., Valderas, P., & Pastor, Ó. (2010). Aplicaciones web : Un enfoque práctico. En D. Roldán, P. Valderas, & Ó. Pastor, Aplicaciones web : Un enfoque práctico. México D.F.: RA-MA. Rubiales, G. M. (2013). HTML5, CSS3 y JavaScript. En G. M. Rubiales, HTML5, CSS3 y JavaScript (págs. 38, 254). Madrid: Anaya Multimedia. Rumbaugh, J., Jacobson, I., & Booch, G. (2007). El lenguaje unificado de modelado: manual de referencia. Madrid: Pearson Addison Wesley. Sánchez, M. (2012). Manual de desarrollo web : Basado en ejercicios y supuestos prácticos. En M. Sánchez, Manual de desarrollo web : Basado en ejercicios y supuestos prácticos (págs. 9,10). Seatle: Lulu Com. Sommerville, I. (2011). Ingeniería de Software. En I. Sommerville, Ingeniería de Software (págs. 64,65). México : Pearson Educación. Talledo , J. (2015). Implantación de Aplicaciones Web en entornos Internet, Intranet y Extranet. Madrid: Paraninfo.

GLOSARIO 

CONCLISAN: Consorcio Clínica Santiago



Correo Electrónico: Es un servicio que permite el intercambio de mensajes a través de sistemas de comunicación electrónicos.



DBMS: DataBase Management System o Sistema de Administracion de Base de Datos es un conjunto de programas que se encargan de manejar la creación y todos los accesos a las bases de datos.



DDL: Lenguaje de Definición de Datos, utilizado para describir y definir los objetos de una base de datos, su estructura, relaciones y restricciones.



DML: Lenguaje de Manipulación de Datos, permite el manejo y procesamiento del contenido de una base de datos.



Foro: Es un tipo de reunión donde distintas personas conversan en torno a un tema de interés común. Es esencialmente, una técnica oral, realizada en grupos.



IEEE: Instituto de Ingeniería Eléctrica y Electrónica, asociación mundial de ingenieros dedicada a la estandarización y el desarrollo en áreas técnicas.



IIS: El Internet Information Service o simplemente IIS es el servidor web de Windows, que permite compartir información con usuarios en internet, intranet o extranet.



Internet: Se trata de un sistema de redes informáticas interconectadas mediante distintos medios de conexión, que ofrece una gran diversidad de servicios y recursos.



ISO: Organización Internacional para la Estandarización, es la que regula una serie de normas para fabricación, comercio y comunicación, en todas las ramas industriales.



Notificaciones electrónicas: Son aquellas comunicaciones que emite la administración pública y privada utilizando medios electrónicos y telemáticos, tales como el Internet y el correo electrónico.

60 

Paradigma de programación: Indica un método de realizar cómputos y la manera en que se deben estructurar y organizar las tareas que debe llevar a cabo un programa.



PDF: Portable Document Format o Formato de Documento Portable, es un formato de almacenamiento para documentos digitales independiente de plataformas de software o hardware.



Protocolo: Término que se emplea para denominar al conjunto de normas, reglas y pautas que sirven para guiar una conducta o acción.



SRS: Software Requirements Specification o Especificación de Requisitos de Software, está basado en el estándar IEEE830. Es un conjunto de recomendaciones para la especificación de requisitos de software, tiene como producto la documentación de los acuerdos entre el cliente y el grupo de desarrollo para el cumplimiento de las exigencias acordadas.



URL: Uniform Resource Locator o Localizador Uniforme de Recursos, secuencia de caracteres que sigue un estándar y que permite denominar recursos dentro del entorno de Internet para que puedan ser localizados.



Wiki: Es un concepto que se utiliza en el ámbito de Internet para referirse a las páginas web cuyos contenidos pueden ser editados por múltiples usuarios a través de cualquier navegador. Dichas páginas, por lo tanto, se desarrollan a partir de la colaboración de los internautas, quienes pueden agregar, modificar o eliminar información.

ANEXOS

Anexo 1. Especificaciรณn de Requisitos

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO

ESCUELA DE SISTEMAS

SISTEMA DE GESTIÓN DE PROYECTOS ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE VERSION 2.2

Integrantes: -

Diana Carolina Paladines Morales

Jefferson Fernando Pantoja Sánchez

HISTORIA DE REVISIONES

Fecha

Versión

Descripción Desarrollo e Implementación de un

16/11/2015

1.0

Desarrollo e Implementación de un 2.0

Desarrollo e Implementación de un 2.1

- Jefferson Pantoja

- Diana Paladines

Sistema de Gestión de Proyectos para la Clínica Santiago

05/01/2016

- Diana Paladines

Sistema de Gestión de Proyectos para la Clínica Santiago

30/11/2015

Autor

- Jefferson Pantoja

- Diana Paladines

Sistema de Gestión de Proyectos para la Clínica Santiago

- Jefferson Pantoja

Desarrollo e Implementación de un Sistema de Gestión de Proyectos para 11/08/2016

2.2

el Departamento de Sistemas del

- Diana Paladines

CONCLISAN CIA. LTDA en la

- Jefferson Pantoja

Provincia Santo Domingo de los Tsáchilas.

CONTENIDO 1.

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

PROPÓSITO .......................................................................................................... 1

1.2

ALCANCE ............................................................................................................ 1

1.3

DEFINICIONES, ACRÓNIMOS Y ABREVIATURAS ................................................... 2

1.5

VISIÓN GENERAL ................................................................................................ 2

DESCRIPCION GENERAL ..................................................................................... 3 2.1

PERSPECTIVA DEL PRODUCTO ............................................................................. 3

2.2

FUNCIONES DEL PRODUCTO ................................................................................ 3

2.3

CARACTERÍSTICAS DE LOS USUARIOS ................................................................. 4

2.4

RESTRICCIONES .................................................................................................. 4

2.5

SUPOSICIONES Y DEPENDENCIAS ........................................................................ 5

2.6

REQUERIMIENTOS FUTUROS ............................................................................... 5

REQUERIMIENTOS ESPECÍFICOS ...................................................................... 5 3.1

INTERFAZ ............................................................................................................ 5

3.2

REQUISITOS FUNCIONALES ................................................................................. 8

3.3

REQUISITOS NO FUNCIONALES ......................................................................... 11

1. INTRODUCCIÓN En el presente documento se explicarán y analizarán los requisitos del “Sistema de Gestión de Proyectos”, desarrollado para el “CONCLISAN CIA. LTDA.” ubicada en la ciudad de Santo Domingo. Se adopta la guía de requerimientos de software de la IEEE (Std. 830-1993).

1.1Propósito Este documento tiene como propósito dar a conocer el funcionamiento general del proyecto SGP (Sistema de Gestión de Proyectos) que está dirigido al Departamento de Sistemas de la “CONCLISAN CIA. LTDA” y a los estudiantes desarrolladores del proyecto.

1.2Alcance El desarrollo e implementación del Sistema de Gestión de Proyectos permitirá facilitar el control y seguimiento de los proyectos que se realizarán en el área de Sistemas de la CONCLISAN CIA. LTDA, mejorando la comunicación entre los distintos participantes involucrados por medio de notificaciones a través de correos personales sobre cambios en el mismo, reuniones, plazos de entrega, etc. Además el sistema contará con un foro interno para dejar comentarios, dar opiniones o solicitar ayuda sobre el proyecto. Otro beneficio al utilizar el sistema es que se podrá llevar un registro de todos los proyectos realizados por la institución ya que dispondrá de una base de datos de la cual se podrá obtener el historial de los mismos. La elaboración del sistema se basará solamente en los proyectos del Departamento de Sistemas, pero servirá para cualquier proyecto que desee realizar la institución. Los requerimientos de usuario son:  Crear los diferentes proyectos a realizar en el departamento.  Asignar un jefe de proyecto.  Crear tareas pertenecientes al proyecto y que estarán a cargo de algún miembro del equipo de trabajo del mismo.  Permitir que los miembros del departamento intercambien información relacionada con los proyectos.  Permitir que todos los miembros del equipo de trabajo del proyecto suban documentos relacionados con las tareas realizadas.

1.3Definiciones, Acrónimos y Abreviaturas  SGP – Sistema de Gestión de Proyectos  BD – Base de Datos  UML – Lenguaje de Modelado Unificado  PHP – Hypertext Preprocessor  IEEE – Institute of Electrical and Electronics Engineers  SRS – Especificación de Requisitos del Software

1.4 Referencias The IEEE standard for requirements documents. Norma de documento de requisitos más ampliamente conocido IEEE / ANSI 830-1.998 (IEEE, 1998) Project, I. M. (2013). Guía de los Fundamentos Para la Dirección de Proyectos (Guía del PMBOK). En I. M. Project, Newtown Square, Pensilvania: Project Management Institute.

1.5Visión General El documento está dividido en 3 secciones:  La sección 1 se enfoca en la explicación, objetivos, metas y descripción del documento.  La sección 2 se enfoca a la descripción general del sistema, donde la información está orientada al usuario potencial.  La sección 3 se enfoca en los requisitos específicos, donde se emplean términos técnicos orientados principalmente a los desarrolladores, programadores y administradores.

2. DESCRIPCION GENERAL 2.1Perspectiva del Producto El Sistema de Gestión de Proyectos permitirá mejorar el control y seguimiento de proyectos, mediante el manejo de información descriptiva del mismo, las tareas que formaran parte de este, los participantes involucrados con sus respectivos roles y presupuesto. Además el sistema contará con notificaciones, foros, calendarios con los tiempos de entrega previstos, etc.

2.2Funciones del Producto  Crear, modificar y cancelar proyectos  Registrar participantes al sistema.  Crear, activar y desactivar roles.  Crear, activar y desactivar recursos.  Ingresar y distribuir presupuesto.  Asignar y quitar recursos a utilizarse en el proyecto.  Asignar y quitar participantes a los proyectos con sus respectivos roles.  Ingresar, modificar y eliminar tareas que formaran parte del proyecto, con los tiempos previstos de duración.  Generar un cronograma de actividades con las tareas y tiempos ingresados, por medio de un calendario  Aplazar los tiempos previstos de finalización de proyectos y tareas.  Generar reportes de todos los proyectos realizados y el estado de los mismos de manera general y detallada.  Notificar mediante correo electrónico a los participantes del proyecto sobre cambios en el mismo, reuniones, etc.  Notificar a los usuarios el vencimiento de plazos de entrega mediante correo electrónico.  Aprobar solicitudes de extensión de plazos previstos en la finalización de proyecto y tareas.  Foro interno, donde los participantes del proyecto podrán interactuar entre sí.  Wiki colaborativo, donde los participantes del proyecto podrán subir contenido.  Exportación de reportes en PDF

2.3Características de los Usuarios El sistema contará con tres tipos de usuarios:  Administrador Usuario con gran conocimiento en el manejo de aplicaciones web. Dispondrá de todos los privilegios para manejar todo el sistema con responsabilidad. Entre sus principales actividades están crear los proyectos con su respectivo presupuesto, crear roles, crear recursos, registrar los participantes del mismo, además se encargará de elegir el jefe de los distintos proyectos creados y aprobar o denegar solicitudes de aplazamiento de fechas de finalización del proyecto o aumento del presupuesto del mismo.  Jefe de Proyecto Usuario con conocimiento en aplicaciones web. Será el encargado de planificar, controlar y dirigir las actividades de los distintos proyectos que tiene a cargo. Entre sus actividades está modificar información de los proyectos asignados, elegir a los participantes que formaran parte del mismo, asignar roles, ingresar sus respectivas tareas y control de tiempos del proyecto. Además podrá aprobar o denegar solicitudes de aplazamiento de fechas de finalización de las diferentes tareas asignadas a los participantes del proyecto.  Participante Usuario con conocimiento básico en el manejo del sistema, encargado de realizar las tareas asignadas por el jefe de proyecto. Pueden formar parte de diferentes proyectos con un rol distinto en cada uno. Los roles que forman este usuario pueden ser analistas, diseñadores, programadores, etc. Su principal función será alimentar a la wiki de la documentación complementaria del desarrollo de los proyectos.

2.4Restricciones  El sistema respecto a la seguridad deberá considerar el uso de cookies para limitar el acceso a usuarios no autorizados.  El sistema deberá estar conectado previamente a su base de datos.  El sistema bloqueará el proyecto una vez finalizado.  Los participantes desactivados en el sistema no podrán iniciar sesión

5  Los participantes no podrán acceder al sistema con un rol determinado una vez que este haya finalizado.  Las solicitudes de aplazamiento de fechas solo se podrán realizar una vez por cada proyecto o tarea respectivamente.

2.5Suposiciones y Dependencias Algunos factores que pueden afectar los requerimientos del sistema son:  Agregar nuevas funcionalidades a las ya definidas anteriormente  Posibilidad de cambiar de gestor de base de datos  Utilización de un lenguaje de programación diferente a PHP para la realización de requerimientos futuros en consenso de las partes.

2.6Requerimientos Futuros Es necesario en versiones futuras incluir proyectos de otras áreas que la institución requiera.

3. REQUERIMIENTOS ESPECÍFICOS En esta sección se tienen con más detalle los requerimientos específicos del sistema a desarrollar.

3.1Interfaz La interfaz gráfica del sistema deberá ser intuitiva, de manera que el usuario final identifique rápidamente los componentes y las secciones del sistema. Además deberá contar con los colores identificativos de la institución y ser compatible con los navegadores más comunes como Google Chrome, Firefox, Internet Explorer, Opera. INICIAR SESION La primera interfaz del sistema será la de Inicio de Sesión (Login)  El usuario deberá introducir un nombre de usuario y una contraseña previamente registrados.  La contraseña inicial será el número de cédula del participante, al iniciar sesión por primera vez debe ser cambiada por él mismo, deberá responder dos preguntas de seguridad, la contraseña podrá tener más de 10 caracteres, además puede ser formada por mayúsculas, minúsculas, números.

6  El nombre de usuario deberá ser formado por las iniciales del nombre y el apellido paterno completo.  En caso de que el usuario olvide su contraseña podrá obtener una temporal respondiendo correctamente una de las preguntas de seguridad. Todas las interfaces del sistema contaran con un encabezado y un menú ENCABEZADO El encabezado de la página será el nombre de la institución con su respectivo logo, seguido del nombre del sistema. MENÚ En la parte derecha del encabezado, se encontrará el menú principal de la página, de acuerdo al tipo de usuario. Todos los tipos de usuario tendrán un pequeño menú de Cerrar Sesión que contendrá:  Perfil → El usuario podrá acceder a su información personal y modificarla. o Datos Personales o Cambiar Contraseña  Rol → El usuario podrá cerrar sesión o cambiar el rol con el que ingresó al sistema. o Cambiar Rol → Aparece cuando el usuario tiene más de un rol asignado o Cerrar Sesión El menú del administrador tendrá más opciones que los otros usuarios  El menú para el Administrador contendrá: o Inicio o Participantes 

Registrar Participante



Editar Participante



Activar Participante



Ver Participantes

o Roles 

Crear Rol



Editar Rol



Activar Rol

7 

Ver Roles

o Recursos 

Crear Recurso



Editar Recurso



Activar Recurso



Ver Recursos

o Proyectos 

Crear Proyecto



Cancelar Proyecto



Solicitudes



Reporte General



Reporte Detallado

o Foro o Wiki o Correo  El menú para Jefe de Proyecto contendrá: o Inicio o Reportes 

General



Detallado

o Foro o Wiki o Correo Al seleccionar uno de los proyectos se desplegará un nuevo menú que contendrá: o Proyectos 

Agregar Recursos



Agregar Participantes



Agregar Tareas



Modificar Tareas



Modificar Presupuesto



Modificar Proyectos



Avance de Proyecto

8 

Cronograma



Quitar Recursos



Quitar Participantes



Cancelar Tareas



Extender Plazo

o Solicitudes o Reportes 

Participantes



Presupuesto

 El menú para participante contendrá: o Inicio o Reportes 

Proyectos Asignados

o Foro o Wiki o Correo Al seleccionar uno de los proyectos se desplegará un nuevo menú que contendrá: o Proyectos 

Cronograma



Extender Plazo



Avance de Tareas

o Reportes 

Tareas del Proyecto

3.2Requisitos Funcionales El sistema permitirá:  Crear, modificar y cancelar proyectos  Registrar participantes al sistema.  Crear, activar y desactivar roles.  Crear, activar y desactivar recursos.  Ingresar y distribuir presupuesto.  Asignar y quitar recursos a utilizarse en el proyecto.  Asignar y quitar participantes a los proyectos con sus respectivos roles.

9  Ingresar, modificar y eliminar tareas que formaran parte del proyecto, con los tiempos previstos de duración.  Generar un cronograma de actividades con las tareas y tiempos ingresados.  Aplazar los tiempos previstos de finalización de proyectos y tareas.  Generar reportes de todos los proyectos realizados y el estado de los mismos de manera general y detallada.  Notificar mediante correo electrónico a los participantes del proyecto sobre cambios en el mismo, reuniones, etc.  Notificar a los usuarios el vencimiento de plazos de entrega mediante correo electrónico.  Aprobar solicitudes de extensión de plazos previstos en la finalización de proyecto y tareas.  Exportación de reportes en PDF El sistema contará con:  Un foro interno, donde los participantes del proyecto podrán interactuar entre sí.  Un wiki colaborativo, donde los participantes del proyecto podrán subir contenido.  Un calendario con las fechas de las tareas por entregar marcadas.

El Administrador podrá:  Iniciar sesión  Cerrar sesión  Modificar perfil  Registrar, modificar, activar, editar y ver participantes  Crear, activar y edita roles  Crear, activar y editar recursos  Crear los proyectos  Asignar el rol jefe de proyecto a uno de los participantes o a sí mismo  Acceder a todos los proyectos  Cancelar Proyectos  Aprobar o denegar solicitudes de los distintos jefes de proyecto  Generar reportes  Participar en el foro

10  Enviar notificaciones por correo  Cancelar o postergar el proyecto El Jefe de proyecto podrá:  Iniciar sesión  Cerrar sesión  Modificar perfil  Completar información del proyecto  Asignar y quitar recursos al proyecto  Distribuir el presupuesto entre los recursos  Asignar y quitar participantes del proyecto  Asignar roles a los participantes  Asignar, modificar y cancelar tareas a los participantes del proyecto  Modificar proyecto  Aprobar Solicitudes de los participantes del proyecto  Subir contenido a la wiki  Generar cronograma de actividades  Finalizar proyecto  Generar reportes  Participar en el foro  Enviar notificaciones por correo El Participante podrá:  Iniciar sesión  Cerrar sesión  Modificar perfil  Actualizar avance de tareas  Generar reportes  Enviar notificaciones por correo  Aplazar la entrega de tareas  Subir contenido a las wiki  Participar en el foro

3.3Requisitos No Funcionales

 

Disponibilidad, el usuario podrá acceder a los datos en cualquier momento posible. Confidencialidad, la información del sistema está protegida de acceso no autorizado, únicamente podrán acceder los usuarios registrados y con permisos diferentes dependiendo el caso

 

Integridad de los datos Mantenibilidad

 Tiempos de respuesta cortos

 

Manual de usuario Manual funcional

Anexo 2. Tablas de Requerimientos

ÍNDICE DE TABLAS Tabla 1 Requerimiento Funcional 1: Iniciar Sesión .................................................................. 1 Tabla 2 Requerimiento Funcional 2: Cerrar Sesión ................................................................... 1 Tabla 3 Requerimiento Funcional 3: Cambiar Contraseña ........................................................ 2 Tabla 4 Requerimiento Funcional 4: Datos Personales ............................................................. 2 Tabla 5 Requerimiento Funcional 5: Registrar Participante ...................................................... 3 Tabla 6 Requerimiento Funcional 6: Desactivar Participante ................................................... 4 Tabla 7 Requerimiento Funcional 7: Activar Participante ........................................................ 5 Tabla 8 Requerimiento Funcional 8: Crear Rol ......................................................................... 5 Tabla 9 Requerimiento Funcional 9: Desactivar Rol ................................................................. 6 Tabla 10 Requerimiento Funcional 10: Activar Rol .................................................................. 7 Tabla 11 Requerimiento Funcional 11: Crear Recursos ............................................................ 7 Tabla 12 Requerimiento Funcional 12: Desactivar Recursos .................................................... 8 Tabla 13 Requerimiento Funcional 13: Activar Recurso .......................................................... 9 Tabla 14 Requerimiento Funcional 14: Crear Proyecto ............................................................ 9 Tabla 15 Requerimiento Funcional 15: Asignar Rol Jefe de Proyecto .................................... 10 Tabla 16 Requerimiento Funcional 16: Cancelar Proyecto ..................................................... 11 Tabla 17 Requerimiento Funcional 17: Proyectos Asignados ................................................. 11 Tabla 18 Requerimiento Funcional 18: Completar Datos del Proyecto .................................. 12 Tabla 19 Requerimiento Funcional 19: Asignar Recursos ...................................................... 13 Tabla 20 Requerimiento Funcional 20: Quitar Recursos ......................................................... 13

Tabla 21 Requerimiento Funcional 21: Distribuir Presupuesto ............................................... 14 Tabla 22 Requerimiento Funcional 22: Asignar Participantes al Proyecto ............................. 15 Tabla 23 Requerimiento Funcional 23: Asignar Roles a los Participantes .............................. 16 Tabla 24 Requerimiento Funcional 24: Tareas del Proyecto por Participante ........................ 17 Tabla 25 Requerimiento Funcional 25: Modificar Proyecto ................................................... 18 Tabla 26 Requerimiento Funcional 26: Modificar Tareas ....................................................... 19 Tabla 27 Requerimiento Funcional 27: Modificar Presupuesto .............................................. 20 Tabla 28 Requerimiento Funcional 28: Quitar Participantes del Proyecto .............................. 21 Tabla 29 Requerimiento Funcional 29: Eliminar Tareas ......................................................... 21 Tabla 30 Requerimiento Funcional 30: Extender Plazo del Proyecto ..................................... 22 Tabla 31 Requerimiento Funcional 31: Avance Proyecto ....................................................... 23 Tabla 32 Requerimiento Funcional 32: Proyectos Asignados ................................................. 24 Tabla 33 Requerimiento Funcional 33: Extender Plazo de las Tareas .................................... 24 Tabla 34 Requerimiento Funcional 34: Avance de Tareas ...................................................... 25 Tabla 35 Requerimiento Funcional 35: Aprobación de Solicitudes ........................................ 26 Tabla 36 Requerimiento Funcional 36: Reportes (Administrador) ......................................... 26 Tabla 37 Requerimiento Funcional 37: Reporte de Proyectos ................................................ 27 Tabla 38 Requerimiento Funcional 38: Cronograma del Proyecto ......................................... 28 Tabla 39 Requerimiento Funcional 39: Presupuesto ............................................................... 29 Tabla 40 Requerimiento Funcional 40: Tareas Asignadas ...................................................... 29 Tabla 41 Requerimiento Funcional 41: Olvidé Mi Contraseña ............................................... 30

Tabla 42 Requerimiento Funcional 42: Cambiar ContraseĂąa .................................................. 30 Tabla 43 Requerimiento No Funcional 1: Seguridad .............................................................. 32 Tabla 44 Requerimiento No Funcional 2: Disponibilidad ....................................................... 32 Tabla 45 Requerimiento No Funcional 3: Mantenibilidad ...................................................... 32 Tabla 46 Requerimiento No Funcional 4: Rendimiento .......................................................... 33

1 Tabla 18 Requerimiento Funcional 1: Iniciar Sesión Descripción del Caso De Uso Nombre Tipo Requerimiento Descripción Actores Precondiciones

Iniciar Sesión Requerimiento Funcional

El usuario debe estar registrado en el sistema.

Flujo Normal 4.

    Postcondiciones Fecha Creación

RF01

El sistema debe permitir el ingreso del nombre de usuario y contraseña para realizar las diferentes funciones de acuerdo al tipo de usuario.  Administrador  Jefe de Proyecto Siempre Frecuencia  Participante

1. 3.

Flujo Alternativo

N° Requerimiento



Acción Del Actor El usuario ingresa al sistema. El usuario para poder iniciar sesión ingresa su respectivo:  Usuario  Contraseña. El usuario da clic en el botón Login.

2. 5. 6.

Acción Del Sistema El sistema devuelve una interfaz solicitando el usuario y Contraseña El sistema verifica que el usuario exista y que la contraseña sea correcta El sistema despliega la interfaz principal de acuerdo al tipo de usuario

Acción Del Actor Acción Del Sistema El usuario no ingresa datos en los  El sistema muestra un mensaje de campos error El usuario ingresa usuario o contraseña incorrectos El usuario ingresa datos que no cumplen con el formato establecido Si el usuario ingresa correctamente su usuario y contraseña accederá a todas las herramientas del sistema de acuerdo al tipo de usuario. Si el usuario no recuerda su contraseña, puede cambiarla respondiendo una pregunta de seguridad detallada en RNF01 14-dic-2015

Fecha Implementación

25-ene-2016

Técnico Diana Paladines – Jefferson Pantoja Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

Tabla 19 Requerimiento Funcional 2: Cerrar Sesión Descripción del Caso De Uso Nombre Tipo Requerimiento Descripción Actores

Precondiciones Flujo Normal

Cerrar Sesión Requerimiento Funcional

N° Requerimiento

RF02

El sistema debe permitir al usuario cerrar sesión en cualquier momento.  Administrador  Jefe de Proyecto Siempre Frecuencia  Participante  El usuario debe estar registrado en el sistema.  El usuario debe haber iniciado sesión. Acción Del Actor Acción Del Sistema 1. El usuario da clic en la opción 2. El sistema limpia toda la información Cerrar Sesión del menú ubicado en de sesión del usuario. la parte superior de la interfaz. 3. El sistema despliega la interfaz de Iniciar sesión del sistema.

2 Postcondiciones

Al cerrar sesión el sistema volverá a la interfaz de Iniciar Sesión para que el usuario pueda acceder nuevamente al sistema. 14-dic-2015 27-ene-2016 Fecha Implementación

Fecha Creación Técnico Diana Paladines – Jefferson Pantoja Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

Tabla 20 Requerimiento Funcional 3: Cambiar Contraseña Descripción del Caso De Uso Nombre Tipo Requerimiento Descripción Actores Precondiciones

Flujo Normal

Flujo Alternativo

Postcondiciones Fecha Creación

Cambiar Contraseña Requerimiento Funcional

N° Requerimiento

RF03

El sistema debe permitir que cada usuario pueda modificar su contraseña cada vez que lo desee.  Administrador  Jefe de Proyecto Ocasional Frecuencia  Participante  El usuario debe estar registrado en el sistema.  El usuario debe iniciar sesión en el sistema. Acción del Actor Acción del Sistema 1. El usuario da clic en la opción 2. El sistema devuelve una interfaz Cambiar Contraseña dentro del solicitando su nueva contraseña ítem Perfil del menú ubicado en 5. El sistema verifica que la contraseña la parte superior de la interfaz. actual ingresada sea el correcta 3. El usuario ingresa 6. El sistema verifica que las dos  Contraseña Actual contraseña ingresadas coincidan y  Nueva Contraseña cumplan con el formato establecido  Verificar Contraseña 7. El sistema actualiza la nueva 4. El usuario da clic en el botón contraseña en su respectiva base de Guardar datos. Acción del Actor Acción del Sistema  El usuario no ingresa datos en los  El sistema muestra un mensaje de campos error  El usuario ingresa contraseña diferentes en los campos establecidos para la nueva contraseña  El usuario ingresa contraseña actual que no coincide con la registrada en la base de datos. Una vez finalizado el proceso de modificar la contraseña el sistema volverá a la página inicial. 14-dic-2015

Fecha Implementación

28-ene-2016

Técnico Diana Paladines – Jefferson Pantoja Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

Tabla 21 Requerimiento Funcional 4: Datos Personales Descripción del Caso De Uso Nombre Tipo Requerimiento

Datos Personales Requerimiento Funcional

N° Requerimiento

RF04

Descripción Actores Precondiciones

Flujo Normal

Flujo Alternativo

Postcondiciones Fecha Creación Técnico Responsable

El sistema debe permitir que cada tipo de usuario pueda modificar sus respectivos datos personales.  Administrador  Jefe de Proyecto Ocasional Frecuencia  Participante  El usuario debe estar registrado en el sistema  El usuario debe iniciar sesión en el sistema. Acción del Actor Acción del Sistema 1. El usuario da clic en la opción 2. El sistema devuelve una interfaz con Datos Personales dentro del ítem todos los datos del usuario Perfil del menú ubicado en la registrados previamente parte superior de la interfaz. 5. El sistema comprueba que todos los 3. El usuario podrá modificar: campos estén llenos y actualiza los  Nombres y Apellidos datos en la respectiva base de datos  Dirección  Teléfono 4. El usuario da clic en el botón Guardar Acción del Actor Acción del Sistema  El usuario ingresa datos que no  El sistema muestra un mensaje de cumplan con el formato error establecido para el campo.  El usuario deja campos obligatorios en blanco. Una vez finalizado el proceso de modificar los datos personales el sistema volverá a la página inicial. 14-dic-2015 Fecha Implementación 01-feb-2016 Diana Paladines – Jefferson Pantoja

Tabla 22 Requerimiento Funcional 5: Registrar Participante Descripción del Caso de Uso Nombre Tipo Requerimiento Descripción Actores Precondiciones

Flujo Normal

Flujo Alternativo

Registrar Participante Requerimiento Funcional

N° Requerimiento

RF05

El sistema debe permitir que el administrador registre los participantes que podrán formar parte de un proyecto, es decir, todos los empleados que forman parte de un determinado departamento de la institución. Administrador Ocasional Frecuencia  El usuario debe iniciar sesión en el sistema. Acción del Actor Acción del Sistema 1. El usuario da clic en la opción 2. El sistema devuelve una interfaz Registrar Participante ubicada en solicitando el ingreso de los datos el ítem Participantes del menú correspondientes para la creación de principal del sistema. un nuevo participante. 3. El usuario ingresa 4. El sistema genera automáticamente el  Número de Cédula usuario y contraseña del nuevo  Nombres participante registrado.  Apellidos 6. El sistema comprueba que todos los  Correo Electrónico campos estén llenos y guarda los  Dirección datos en la respectiva base de datos 5. Acción del Actor Acción del Sistema  El usuario no ingresa datos en los  El sistema muestra un mensaje de campos error

4 

Postcondiciones

El usuario ingresa número de cédula ya registrado anteriormente o no válido  El usuario ingresa datos que no cumplan con el formato establecido para el campo. Una vez finalizado el proceso de registro de participante, el sistema dará la opción de registrar un nuevo participante o volver a la página inicial. 14-dic-2015 03-feb-2016 Fecha Implementación

Fecha Creación Técnico Diana Paladines – Jefferson Pantoja Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

Tabla 23 Requerimiento Funcional 6: Desactivar Participante Descripción del Caso de Uso Nombre Tipo Requerimiento Descripción Actores Precondiciones

Flujo Normal

Flujo Alternativo

Postcondiciones

Desactivar Participante Requerimiento Funcional

N° Requerimiento

RF06

El sistema debe permitir que el administrador desactive a los participantes que ya no formen parte del departamento o de la institución. Administrador Ocasional Frecuencia  El usuario debe iniciar sesión en el sistema.  El participante a desactivar debe estar registrado en el sistema  El participante a desactivar no debe formar parte de ningún proyecto en curso  El participante a desactivar debe estar activado Acción del Actor Acción del Sistema 1. El usuario da clic en la opción 2. El sistema devuelve una interfaz con Desactivar Participante ubicada una barra de búsqueda para localizar en el ítem Participantes del menú el usuario a desactivar principal del sistema. 5. El sistema muestra una tabla con los 3. El administrador ingresa el datos del usuario buscado o de todos usuario a desactivar en el campo los usuarios activos del sistema buscar, o lo deja vacío 8. El sistema muestra un mensaje 4. El usuario da clic en el botón pidiendo la confirmación de la Buscar desactivación del participante 6. El usuario selecciona el participante a desactivar 7. El usuario da clic en el botón Desactivar 9. El usuario acepta la desactivación del participante Acción del Actor Acción del Sistema  El administrador ingresa en el  El sistema muestra un mensaje de campo buscar un usuario que no error esté registrado.  El usuario no selecciona ningún participante a eliminar. Una vez finalizado el proceso de desactivación, el sistema volverá a la página inicial. 14-dic-2015 07-feb-2016 Fecha Implementación Diana Paladines – Jefferson Pantoja

Fecha Creación Técnico Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

5 Tabla 24 Requerimiento Funcional 7: Activar Participante Descripción del Caso de Uso Nombre Tipo Requerimiento Descripción Actores Precondiciones

Flujo Normal

Flujo Alternativo

Activar Participante Requerimiento Funcional

N° Requerimiento

RF07

El sistema debe permitir que el administrador active a los participantes anteriormente desactivados. Administrador Ocasional Frecuencia  El usuario debe iniciar sesión en el sistema.  El participante a activar debe estar desactivado Acción del Actor Acción del Sistema 1. El usuario da clic en la opción 2. El sistema devuelve una interfaz con Activar Participante ubicada en una tabla donde se encuentran todos el ítem Participantes del menú los participantes que han sido principal del sistema. desactivados. 3. El usuario selecciona el 5. El sistema muestra un mensaje participante que desea activar. pidiendo la confirmación de la 4. El usuario da clic en el botón activación del participante Activar 6. El usuario acepta la activación del participante Acción del Actor Acción del Sistema El usuario no selecciona ningún  El sistema muestra un mensaje de participante. error Una vez finalizado el proceso de activación, el sistema volverá a la página inicial. 14-dic-2015 09-feb-2016 Fecha Implementación 

Postcondiciones Fecha Creación Técnico Diana Paladines – Jefferson Pantoja Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

Tabla 25 Requerimiento Funcional 8: Crear Rol Descripción del Caso de Uso Nombre Tipo Requerimiento Descripción Actores Precondiciones

Crear Rol Requerimiento Funcional

4. Flujo Alternativo

RF08

El sistema debe permitir que el administrador cree todos los roles que podrán tener los participantes del proyecto. Los roles del sistema variaran dependiendo el departamento al que pertenece el proyecto. Administrador Ocasional Frecuencia  El usuario debe iniciar sesión 1.

Flujo Normal

N° Requerimiento

Acción del Actor El usuario da clic en la opción Crear Rol ubicada en el ítem Roles del menú principal del sistema. El usuario ingresa:  Nombre del Rol  Departamento El usuario da clic en el botón Registrar Acción del Actor

Acción del Sistema El sistema devuelve una interfaz solicitando el ingreso de todos los datos correspondientes para la creación del nuevo rol. El sistema comprueba que todos los campos estén llenos y guarda los datos en la respectiva base de datos

Acción del Sistema

6 

Postcondiciones

El usuario no ingresa datos en los  El sistema muestra un mensaje de error. campos  El usuario ingresa un nombre de rol ya registrado  El usuario ingresa datos que no cumplan con el formato establecido para el campo. Una vez finalizado el proceso de creación de rol, el sistema dará la opción de crear un nuevo rol o volver a la página inicial.

14-dic-2015 Fecha Creación Fecha Implementación Técnico Diana Paladines – Jefferson Pantoja Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

15-feb-2016

Tabla 26 Requerimiento Funcional 9: Desactivar Rol Descripción del Caso de Uso Nombre Tipo Requerimiento Descripción

Desactivar Rol Requerimiento Funcional

Flujo Normal

Flujo Alternativo Postcondiciones

RF09

El sistema debe permitir que el administrador desactive los roles que no se utilizaran por un largo tiempo. Administrador

Actores

Precondiciones

N° Requerimiento

Frecuencia

   

Ocasional

El usuario debe iniciar sesión en el sistema El rol a desactivar debe estar creado en el sistema El rol a desactivar debe estar activado El rol a desactivar no debe estar asignado a un participante de un proyecto que aún no ha finalizado Acción del Actor Acción del Sistema 1. El usuario da clic en la opción 2. El sistema devuelve una interfaz con una Desactivar Rol ubicada en el tabla donde se encuentran todos los roles ítem Roles del menú principal del creados en el sistema sistema. 5. El sistema muestra un mensaje pidiendo 3. El usuario selecciona el rol que la confirmación de la desactivación desea desactivar 4. El usuario da clic en el botón Desactivar 6. El usuario acepta la desactivación del rol Acción del Actor Acción del Sistema  El usuario no selecciona ningún  El sistema muestra un mensaje de error rol Una vez finalizado el proceso de desactivación el sistema dará la opción de desactivar otro rol o volver a la página inicial. 14-dic-2015 17-feb-2016 Fecha Implementación

Fecha Creación Técnico Diana Paladines – Jefferson Pantoja Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

7 Tabla 27 Requerimiento Funcional 10: Activar Rol Descripción del Caso de Uso Nombre Tipo Requerimiento Descripción

Activar Rol Requerimiento Funcional

Flujo Normal

Flujo Alternativo Postcondiciones

RF10

El sistema debe permitir que el administrador active los roles anteriormente desactivados. Administrador

Actores Precondiciones

N° Requerimiento

 

Frecuencia

Ocasional

El usuario debe iniciar sesión en el sistema. El rol a activar debe estar desactivado

Acción del Actor Acción del Sistema 1. El usuario da clic en la opción 2. El sistema devuelve una interfaz con una Activar Rol ubicada en el ítem tabla donde se encuentran todos los roles Roles del menú principal del desactivados del sistema sistema. 5. El sistema muestra un mensaje pidiendo 3. El usuario selecciona el rol que la confirmación de la activación desea activar 4. El usuario da clic en el botón Activar 6. El usuario acepta la activación del rol Acción del Actor Acción del Sistema  El usuario no selecciona ningún  El sistema muestra un mensaje de error rol Una vez finalizado el proceso de activación, el sistema dará la opción de activar otro rol o volver a la página inicial. 14-dic-2015 19-feb-2016 Fecha Implementación

Fecha Creación Técnico Diana Paladines – Jefferson Pantoja Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

Tabla 28 Requerimiento Funcional 11: Crear Recursos Descripción del Caso de Uso Nombre Tipo Requerimiento Descripción

Crear Recursos Requerimiento Funcional

Administrador  1.

Flujo Normal

RF11

El sistema debe permitir que el administrador cree todos los recursos que se podrán utilizar en el desarrollo del proyecto.

Actores Precondiciones

N° Requerimiento

El usuario debe iniciar sesión Acción del Actor El usuario da clic en la opción Crear Recurso ubicada en el ítem Recursos del menú principal del sistema. El usuario ingresa:  Nombre del Recurso  Descripción  Departamento El usuario da clic en el botón Registrar

Frecuencia

Ocasional

Acción del Sistema El sistema devuelve una interfaz solicitando el ingreso de todos los datos correspondientes para la creación del nuevo recurso. El sistema comprueba que todos los campos estén llenos y guarda los datos en la respectiva base de datos

8 Acción del Actor Acción del Sistema El usuario no ingresa datos en los  El sistema muestra un mensaje de error. campos  El usuario ingresa un nombre de recurso ya registrado  El usuario ingresa datos que no cumplan con el formato establecido para el campo. Una vez finalizado el proceso de creación de recurso, el sistema dará la opción de crear un nuevo recurso o volver a la página inicial.  Flujo Alternativo

Postcondiciones

14-dic-2015 Fecha Creación Fecha Implementación Técnico Diana Paladines – Jefferson Pantoja Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

22-feb-2016

Tabla 29 Requerimiento Funcional 12: Desactivar Recursos Descripción del Caso de Uso Nombre Tipo Requerimiento Descripción

Desactivar Recursos Requerimiento Funcional

Flujo Normal

Flujo Alternativo Postcondiciones

RF12

El sistema debe permitir que el administrador desactive los recursos que no se utilizaran por un largo tiempo. Administrador

Actores Precondiciones

N° Requerimiento

Frecuencia

Ocasional

  

El usuario debe iniciar sesión en el sistema. El recurso a desactivar debe estar creado en el sistema El recurso a desactivar debe estar activado Acción del Actor Acción del Sistema 1. El usuario da clic en la opción 2. El sistema devuelve una interfaz con una Desactivar Recurso ubicada en el tabla donde se encuentran todos los ítem Recursos del menú principal recursos creados en el sistema del sistema. 5. El sistema muestra un mensaje pidiendo 3. El usuario selecciona el recurso la confirmación de la desactivación que desea desactivar 4. El usuario da clic en el botón Desactivar 6. El usuario acepta la desactivación del recurso Acción del Actor Acción del Sistema  El usuario no selecciona ningún  El sistema muestra un mensaje de error recurso Una vez finalizado el proceso de desactivación, el sistema dará la opción de desactivar otro recurso o volver a la página inicial.

14-dic-2015 Fecha Creación Fecha Implementación Técnico Diana Paladines – Jefferson Pantoja Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

24-feb-2016

9 Tabla 30 Requerimiento Funcional 13: Activar Recurso Descripción del Caso de Uso Nombre Tipo Requerimiento Descripción

Activar Recurso Requerimiento Funcional

RF13

El sistema debe permitir que el administrador active los recursos anteriormente desactivados. Administrador

Actores Precondiciones

N° Requerimiento

 

Frecuencia

Ocasional

El usuario debe iniciar sesión en el sistema. El recurso a activar debe estar desactivado

Acción del Actor Acción del Sistema El usuario da clic en la opción 2. El sistema devuelve una interfaz con una Activar Recursos ubicada en el tabla donde se encuentran todos los ítem Recursos del menú principal recursos desactivados del sistema del sistema. 5. El sistema muestra un mensaje pidiendo 3. El usuario selecciona el recurso la confirmación de la activación que desea activar 4. El usuario da clic en el botón Activar 6. El usuario acepta la activación del recurso Acción del Actor Acción del Sistema  El usuario no selecciona ningún  El sistema muestra un mensaje de error recurso Una vez finalizado el proceso de activación, el sistema dará la opción de activar otro recurso o volver a la página inicial. 14-dic-2015 26-feb-2016 Fecha Implementación 1.

Flujo Normal

Flujo Alternativo Postcondiciones

Fecha Creación Técnico Diana Paladines – Jefferson Pantoja Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

Tabla 31 Requerimiento Funcional 14: Crear Proyecto Descripción del Caso de Uso Nombre Tipo Requerimiento Descripción

Crear Proyecto Requerimiento Funcional

RF14

El sistema debe permitir que el administrador cree todos los proyectos que se realizarán en la institución. Administrador

Actores Precondiciones

N° Requerimiento

   2.

Flujo Normal 5.

Frecuencia

Ocasional

El usuario debe iniciar sesión El sistema debe tener registrado al menos un participante El sistema debe tener creado el rol Jefe de proyecto Acción del Actor Acción del Sistema El usuario da clic en la opción 3. El sistema devuelve una interfaz Crear Proyecto ubicada en el solicitando el ingreso de todos los datos ítem Proyectos del menú correspondientes para la creación del principal del sistema. nuevo proyecto. El usuario ingresa: 6. El sistema comprueba que todos los  Nombre del Proyecto campos estén llenos y guarda los datos  Presupuesto en la respectiva base de datos

10  Departamento El usuario da clic en el botón Registrar Acción del Actor Acción del Sistema  El usuario no ingresa datos en los  El sistema muestra un mensaje de error. campos  El usuario ingresa datos que no cumplan con el formato establecido para el campo. Una vez finalizado el proceso de creación de proyecto, el sistema desplegará la interfaz para asignar el Jefe de Proyecto, detallado en el RF18 6.

Flujo Alternativo

Postcondiciones Fecha Creación

14-dic-2015

Fecha Implementación

29-feb-2016

Técnico Diana Paladines – Jefferson Pantoja Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

Tabla 32 Requerimiento Funcional 15: Asignar Rol Jefe de Proyecto Descripción del Caso de Uso Nombre

Asignar Rol Jefe de Proyecto

Tipo Requerimiento

Requerimiento Funcional

Descripción Actores Precondiciones

Flujo Normal

Flujo Alternativo

Postcondiciones Fecha Creación

N° Requerimiento

RF15

El sistema debe permitir que el administrador pueda asignar el rol Jefe de Proyecto a uno de los participantes registrados. Administrador Ocasional Frecuencia  El usuario debe iniciar sesión  El sistema debe tener creado el rol Jefe de Proyecto  El sistema debe tener registrado al menos un participante  El sistema debe tener registrado al menos un proyecto Acción del Actor Acción del Sistema 1. El usuario da clic en el botón 2. El sistema devuelve una con una barra de Registrar de la interfaz Crear búsqueda para localizar el usuario Proyecto. 5. El sistema muestra una tabla con el 3. El administrador ingresa el usuario encontrado, o con todos los usuario a asignar el rol en el usuarios activos del sistema campo buscar, o lo deja vacío 8. El sistema muestra un mensaje 4. El usuario da clic en el botón confirmando la asignación del rol al Buscar participante 6. El usuario selecciona el participante al que se le va asignar el rol Jefe de Proyecto 7. El usuario da clic en el botón Aceptar 9. El usuario acepta la asignación del rol al participante Acción del Actor Acción del Sistema  El administrador ingresa en el  El sistema muestra un mensaje de error. campo buscar un usuario que no esté registrado  El usuario no selecciona ningún participante Una vez asignado el rol jefe de proyecto el sistema volverá a la página Crear Proyectos (RF14) 14-dic-2015

Fecha Implementación

02-mar-2016

11 Técnico Diana Paladines – Jefferson Pantoja Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

Tabla 33 Requerimiento Funcional 16: Cancelar Proyecto Descripción del Caso de Uso Nombre Tipo Requerimiento Descripción Actores Precondiciones

Flujo Normal

Flujo Alternativo Postcondiciones

Cancelar Proyecto Requerimiento Funcional

N° Requerimiento

RF16

El sistema debe permitir que el administrador cancele los proyectos que ya no se realizarán en la institución. Administrador Ocasional Frecuencia  El usuario debe iniciar sesión  El proyecto a cancelar debe estar creado en el sistema Acción del Actor Acción del Sistema 1. El usuario da clic en la opción 2. El sistema devuelve una interfaz con una Cancelar Proyecto ubicada en el tabla donde se encuentran todos los ítem Proyectos del menú proyectos existentes. principal del sistema. 5. El sistema devuelve una interfaz 3. El usuario selecciona el proyecto solicitando el motivo por el cual se va a que va a cancelar cancelar el proyecto. 4. El usuario da clic en el botón 8. El sistema muestra un mensaje Siguiente confirmando la cancelación del proyecto 6. El usuario ingresa el motivo de la cancelación del proyecto. 7. El usuario da clic en el botón Aceptar 9. El usuario acepta la cancelación del proyecto Acción del Actor Acción del Sistema  El usuario no selecciona ningún  El sistema muestra un mensaje de error. proyecto Una vez finalizado el proceso de cancelación de un proyecto, el sistema dará la opción de cancelar otro proyecto o volver a la página inicial. 14-dic-2015 03-mar-2016 Fecha Implementación

Fecha Creación Técnico Diana Paladines – Jefferson Pantoja Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

Tabla 34 Requerimiento Funcional 17: Proyectos Asignados Descripción del Caso de Uso Nombre Tipo Requerimiento Descripción

Proyectos Asignados Requerimiento Funcional

RF17

El sistema debe permitir que el jefe de proyecto genere reportes de todos los proyectos que tiene a su cargo.

Actores Precondiciones

N° Requerimiento

 

Jefe de Proyecto Frecuencia El usuario debe iniciar sesión El usuario debe tener al menos un proyecto asignado

Ocasional

1. Flujo Normal

Flujo Alternativo

Postcondiciones

Acción del Actor El usuario da clic en la opción Mis Proyectos ubicado en el ítem Reportes del menú principal del sistema. Acción del Actor El usuario da clic en el botón Descargar

Acción del Sistema El sistema devuelve una interfaz con una tabla donde se encuentran todos los proyectos asignados al usuario.

Acción del Sistema El sistema genera un reporte en PDF con todos los datos de los proyectos asignados al usuario. Una vez generado el reporte el usuario debe dar clic en el botón Inicio para regresar a la página principal del sistema 

14-dic-2015

Fecha Creación



Fecha Implementación

07-mar-2016

Técnico Diana Paladines – Jefferson Pantoja Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

Tabla 35 Requerimiento Funcional 18: Completar Datos del Proyecto Descripción del Caso de Uso Nombre

Completar Datos del Proyecto

Tipo Requerimiento

Requerimiento Funcional

Descripción

RF18

El sistema debe permitir que el jefe de proyecto pueda completar los datos de los proyectos a los que ha sido asignado. Este proceso se realizará únicamente cuando el usuario ingrese por primera vez a la información del proyecto. Jefe de Proyecto

Actores Precondiciones

N° Requerimiento

  1. 3. 5.

Flujo Normal

Frecuencia

Una Vez

El usuario debe iniciar sesión en el sistema. El usuario debe tener el proyecto asignado Acción del Actor Acción del Sistema El usuario ingresa al sistema 2. El sistema devuelve una interfaz con una El usuario selecciona el proyecto tabla donde se encontraran todos los al que desea completar los datos proyectos asignados al usuario El usuario deberá ingresar: 4. El sistema devuelve una interfaz  Alcance del Proyecto solicitando el ingreso de los datos  Tipo de Proyecto correspondientes para completar la  Fecha de Inicio información del proyecto seleccionado  Fecha de Finalización 7. El sistema comprueba que todos los El usuario da clic en el botón campos estén llenos y actualiza los datos Guardar en la respectiva base de datos

Acción del Actor Acción del Sistema El usuario no ingresa datos en los  El sistema muestra un mensaje de error campos  El usuario ingresa datos que no cumplan con el formato establecido para el campo. Una vez finalizado el proceso de completar datos del proyecto, el sistema desplegará la interfaz para asignar los recursos necesarios, detallado en el RF19 

Flujo Alternativo

Postcondiciones Fecha Creación

14-dic-2015

Fecha Implementación

Técnico Diana Paladines – Jefferson Pantoja Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

09-mar-2016

13 Tabla 36 Requerimiento Funcional 19: Asignar Recursos Descripción del Caso de Uso Nombre Tipo Requerimiento Descripción Actores Precondiciones

Flujo Normal

Flujo Alternativo

Postcondiciones Fecha Creación

Asignar Recursos Requerimiento Funcional

N° Requerimiento

RF19

El sistema debe permitir que el jefe de proyecto pueda asignar los recursos necesarios para el desarrollo de los proyectos que tiene a su cargo. Jefe de Proyecto

Ocasional Frecuencia  El usuario debe iniciar sesión en el sistema.  El usuario debe tener el proyecto asignado  La información del proyecto debe estar completa Acción del Actor Acción del Sistema 1. Si se encuentra en el proceso de 2. El sistema devuelve una interfaz con una completar información del tabla donde se encontraran todos los Proyecto El usuario da clic en el recursos creados en el sistema. botón Aceptar de la interfaz 5. El sistema muestra una nueva tabla con Completar Datos del Proyecto. los recursos que han sido asignados al Caso contrario, el usuario deberá proyecto seleccionar el proyecto al que le El proceso se repite desde el paso 3, va a agregar recursos, y dar clic hasta haber asignado todos los recursos en la opción Asignar Recursos deseados al proyecto. ubicada dentro del ítem 7. El sistema muestra un mensaje Proyectos del menú principal confirmando la asignación de los 3. El usuario selecciona el recurso recursos. que desea asignarle al proyecto. 4. El usuario da clic en el botón Agregar 6. El usuario da clic en el botón Aceptar 8. El usuario acepta la asignación de recursos al proyecto. Acción del Actor Acción del Sistema  El usuario no selecciona ningún  El sistema muestra un mensaje de error recurso Una vez finalizado el proceso de asignación de recursos al proyecto, el sistema desplegará la interfaz para distribuir el presupuesto asignado al proyecto entre los recursos, detallado en el RF21 14-dic-2015 14-mar-2016 Fecha Implementación

Técnico Diana Paladines – Jefferson Pantoja Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

Tabla 37 Requerimiento Funcional 20: Quitar Recursos Descripción del Caso de Uso Nombre Tipo Requerimiento Descripción Actores

Quitar Recursos Requerimiento Funcional

N° Requerimiento

RF20

El sistema debe permitir que el jefe de proyecto pueda quitar los recursos que no serán necesarios para el desarrollo de los proyectos que tiene a su cargo. Jefe de Proyecto

Frecuencia

Ocasional

Precondiciones

Flujo Normal

Flujo Alternativo Postcondiciones

   

El usuario debe iniciar sesión en el sistema. El usuario debe tener el proyecto asignado Los recursos a quitar deben estar asignados al proyecto El presupuesto de los recursos a quitar no deben estar utilizados Acción del Actor Acción del Sistema 1. El usuario selecciona el proyecto 2. El sistema devuelve una interfaz con la al que desea quitarle recursos. información del proyecto seleccionado, 3. El usuario da clic en la opción además de un menú de opciones. Quitar Recursos ubicada dentro 4. El sistema devuelve una interfaz con una del ítem Proyectos del menú tabla donde se encontraran todos los principal del proyecto. recursos asignados anteriormente al 5. El usuario selecciona el recurso proyecto. que desea quitarle al proyecto. 7. El sistema muestra un mensaje 6. El usuario da clic en el botón confirmando la asignación de los nuevos Quitar recursos. 8. El usuario acepta la asignación de recursos al proyecto. Nota: El proceso se repetirá desde el paso 5, hasta que el usuario haya quitado al proyecto todos los recursos deseados. Acción del Actor Acción del Sistema  El usuario no selecciona ningún  El sistema muestra un mensaje de error recurso Una vez finalizado el proceso de quitar recursos al proyecto el sistema volverá a la página principal del proyecto. 14-dic-2015

Fecha Creación

Fecha Implementación

16-mar-2016

Técnico Diana Paladines – Jefferson Pantoja Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

Tabla 38 Requerimiento Funcional 21: Distribuir Presupuesto Descripción del Caso de Uso Nombre Tipo Requerimiento Descripción

Distribuir Presupuesto Requerimiento Funcional

  

3. Flujo Normal

RF21

El sistema debe permitir que el jefe de proyecto pueda distribuir el presupuesto asignado al proyecto entre todos los recursos del mismo.

Actores Precondiciones

N° Requerimiento

Jefe de Proyecto Ocasional Frecuencia El usuario debe iniciar sesión en el sistema. El usuario debe tener el proyecto asignado El proyecto debe tener asignado al menos un recurso Acción del Actor Acción del Sistema Completar Datos del Proyecto El usuario da clic en el botón 2. El sistema devuelve una interfaz con una Aceptar de la interfaz Asignar tabla donde se encontraran todos los Recursos. recursos agregados al proyecto El usuario deberá ingresar el 5. El sistema comprueba que todos los costo necesario para cada recurso campos estén llenos y guarda los datos El usuario da clic en el botón en la respectiva base de datos Aceptar Recursos Nuevos El usuario da clic en el botón Aceptar de la interfaz Asignar Recursos.

El sistema devuelve una interfaz con dos opciones para distribuir presupuesto.

15 3.

4. 6.

7.  Flujo Alternativo

 

Postcondiciones 

El usuario deberá elegir entre: 5. El sistema devuelve una interfaz con una  Conservar Presupuesto tabla donde se encuentren los recursos  Reestablecer dependiendo la opción escogida Presupuesto 8. El sistema comprueba que todos los El usuario da clic en el botón campos estén llenos y guarda los datos Aceptar en la respectiva base de datos. El usuario ingresa los presupuestos  Si eligió Conservar presupuesto, deberá ingresar el presupuesto a los nuevos recursos añadidos  Si eligió Reestablecer Presupuesto, deberá ingresar a presupuesto a todos los recursos que aún no se han utilizado El usuario da clic en el botón Aceptar Acción del Actor Acción del Sistema El usuario no ingresa datos en los  El sistema muestra un mensaje de error campos El usuario ingresa datos que no cumplan con el formato establecido para el campo. Si se está completando la información del proyecto, una vez finalizado el proceso de distribución de presupuesto a los recursos del proyecto, el sistema desplegará la interfaz para asignar participantes al proyecto, detallado en el RF22 Caso contrario el sistema volverá a la página principal del proyecto. 14-dic-2015

Fecha Creación

Fecha Implementación

18-mar-2016

Técnico Diana Paladines – Jefferson Pantoja Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

Tabla 39 Requerimiento Funcional 22: Asignar Participantes al Proyecto Descripción del Caso de Uso Nombre Tipo Requerimiento Descripción

Asignar Participantes al Proyecto Requerimiento Funcional

Jefe de Proyecto    1.

Flujo Normal

RF22

El sistema debe permitir que el jefe de proyecto pueda asignar participantes a los proyectos que tiene a cargo.

Actores Precondiciones

N° Requerimiento

Frecuencia

Ocasional

El usuario debe iniciar sesión en el sistema. El usuario debe tener al menos un proyecto asignado El proyecto debe tener asignado recursos Acción del Actor Acción del Sistema Si se encuentra en el proceso de 2. El sistema devuelve una interfaz con una completar información del barra de búsqueda Proyecto el usuario da clic en el 5. El sistema muestra una tabla con el botón Aceptar de la interfaz usuario encontrado, o con todos los Distribuir Presupuesto. participantes activos del sistema Caso contrario, el usuario deberá seleccionar el proyecto al que le

Flujo Alternativo

Postcondiciones Fecha Creación

va a agregar participantes, y dar 8. El sistema muestra una nueva tabla con clic en la opción Asignar los participantes que han sido asignados Participantes ubicada dentro del al proyecto ítem Proyectos del menú El proceso se repite desde el paso 4, principal hasta haber asignado todos los 3. El jefe de proyecto ingresa el participantes deseados al proyecto. usuario del participante que 10. El sistema muestra un mensaje desea asignar, o lo deja vacío confirmando la asignación de los 4. El usuario da clic en el botón participantes al proyecto Buscar 6. El usuario selecciona el participante que va a añadir 7. El usuario da clic en el botón Agregar 9. El usuario da clic en el botón Aceptar 10. El usuario acepta la asignación de los participantes. Acción del Actor Acción del Sistema  El usuario no selecciona ningún  El sistema muestra un mensaje de error participante  Una vez finalizado el proceso de asignación de participantes al proyecto, el sistema desplegará la interfaz para asignar Roles a los participantes escogidos, detallado en el RF23 14-dic-2015 21-mar-2016 Fecha Implementación

Técnico Diana Paladines – Jefferson Pantoja Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

Tabla 40 Requerimiento Funcional 23: Asignar Roles a los Participantes Descripción del Caso de Uso Nombre Tipo Requerimiento Descripción

Asignar Roles a los Participantes Requerimiento Funcional

Flujo Normal

RF23

El sistema debe permitir que el jefe de proyecto pueda asignar roles a los participantes asignados a los proyectos que tiene a cargo. Jefe de Proyecto

Actores

Precondiciones

N° Requerimiento

   

Frecuencia

Ocasional

El usuario debe iniciar sesión El sistema debe tener creado los roles El usuario debe tener asignado al menos un proyecto El proyecto debe tener asignado al menos un participante Acción del Actor Acción del Sistema

17 1.

4. 6.

7. 9.

 Flujo Alternativo

  

Postcondiciones 

El usuario da clic en el botón 2. El sistema devuelve una interfaz con una Aceptar de la interfaz Asignar tabla donde se encuentran todos los roles Participantes al Proyecto. registrados en el sistema, dependiendo el El usuario selecciona el rol que departamento al que pertenece el va asignar a uno o varios proyecto participantes. 5. El sistema muestra una tabla con todos El usuario da clic en el botón los participantes asignados al proyecto Siguiente que aún no tienen un rol asignado. El usuario selecciona el o los 8. El sistema muestra un mensaje participantes a los que se le va confirmando la asignación del rol al asignar el rol seleccionado participante anteriormente El usuario da clic en el botón Nota: El proceso de asignación de roles se Aceptar repetirá a partir del paso 3, hasta que el El usuario acepta la asignación usuario haya asignado todos los roles a todos del rol al participante los participantes. Acción del Actor Acción del Sistema El usuario no selecciona ningún  El sistema muestra un mensaje de error. rol El usuario selecciona más de un rol El usuario no selecciona ningún participante Si se está completando la información del proyecto, una vez finalizado el proceso de asignación de roles a los participantes del proyecto, el sistema desplegará la interfaz para asignar tareas a los participantes escogidos, detallado en el RF24 Caso contrario el sistema volverá a la página principal del proyecto 14-dic-2015

Fecha Creación

Fecha Implementación

23-mar-2016

Técnico Diana Paladines – Jefferson Pantoja Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

Tabla 41 Requerimiento Funcional 24: Tareas del Proyecto por Participante Descripción del Caso de Uso Nombre Tipo Requerimiento Descripción

Tareas del Proyecto por Participante Requerimiento Funcional

Jefe de Proyecto    

Ocasional

Frecuencia

El usuario debe iniciar sesión El usuario debe tener asignado al menos un proyecto El proyecto debe tener asignado al menos un participante El participante debe tener asignado un rol Acción del Actor

Flujo Normal

RF24

El sistema debe permitir que el jefe de proyecto pueda ingresar todas las tareas a cada participante que formarán parte de cada proyecto que tiene a cargo.

Actores Precondiciones

N° Requerimiento

Si se encuentra en el proceso de completar información del Proyecto El usuario da clic en el botón Aceptar de la interfaz Asignar Roles a los Participantes. Caso contrario, el usuario deberá seleccionar el proyecto al que le va a agregar tareas, y dar clic en

Acción del Sistema 2.

El sistema devolverá una interfaz con una tabla donde se encontrarán todos los participantes asignados al proyecto seleccionado con su respectivo rol, a los que aún no se les ha añadido tareas El sistema devuelve una interfaz solicitando el ingreso de los datos

4. 6.

7.  Flujo Alternativo

  

Postcondiciones

la opción Asignar Tareas correspondientes para la creación de una ubicada dentro del ítem nueva tarea. Proyectos del menú principal 8. El sistema comprueba que todos los El usuario selecciona el campos estén llenos y guarda los datos participante al que desea en la respectiva base de datos agregarle tareas. El usuario da clic en el botón Siguiente El usuario ingresa:  Nombre de la Tarea  Descripción  Fecha de Inicio  Fecha de Finalización El usuario da clic en el botón Guardar Acción del Actor Acción del Sistema El usuario no ingresa datos en los  El sistema muestra un mensaje de error. campos El usuario ingresa datos que no cumplan con el formato establecido para el campo. El usuario selecciona a más de un participante Una vez finalizada la creación de una tarea, el sistema dará la opción de ingresar otra tarea al participante o seleccionar un nuevo participante al que se le va a agregar tareas (Paso 3) 14-dic-2015

Fecha Creación

Fecha Implementación

25-mar-2016

Técnico Diana Paladines – Jefferson Pantoja Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

Tabla 42 Requerimiento Funcional 25: Modificar Proyecto Descripción del Caso de Uso Nombre Tipo Requerimiento Descripción

Modificar Proyecto Requerimiento Funcional

RF25

El sistema debe permitir que el jefe de proyecto pueda modificar los datos de los proyectos a los que ha sido asignado.

Actores Precondiciones

N° Requerimiento

  

Jefe de Proyecto Frecuencia El usuario debe iniciar sesión en el sistema. El usuario debe tener el proyecto asignado Los datos del proyecto deben estar completos Acción del Actor

1. 3. Flujo Normal 5.

El usuario selecciona el proyecto que desea modificar. El usuario da clic en la opción Modificar Proyecto ubicada en el ítem Proyectos del menú. El usuario podrá modificar:  Nombre del Proyecto  Presupuesto  Alcance del Proyecto  Tipo de Proyecto

Ocasional

Acción del Sistema 2.

El sistema devuelve una interfaz con la información del proyecto seleccionado, además de un menú de opciones. El sistema devuelve una interfaz con todos los datos del proyecto registrados previamente El sistema comprueba que todos los campos estén llenos y actualiza los datos en la respectiva base de datos

19 6.

 Flujo Alternativo

 

Postcondiciones



Fecha Creación

El usuario da clic en el botón Guardar Acción del Actor Acción del Sistema El usuario no ingresa datos en los  El sistema muestra un mensaje de error campos El usuario ingresa datos que no cumplan con el formato establecido para el campo. Una vez finalizado el proceso de modificar datos del proyecto, el sistema dará la opción de modificar datos de otro proyecto o volver a la página principal. La modificación del presupuesto debe ser aprobada por el administrador del sistema, proceso detallado en el RF35 14-dic-2015 28-mar-2016 Fecha Implementación

Técnico Diana Paladines – Jefferson Pantoja Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

Tabla 43 Requerimiento Funcional 26: Modificar Tareas Descripción del Caso de Uso Nombre Tipo Requerimiento Descripción

Modificar Tareas Requerimiento Funcional

Flujo Normal

Flujo Alternativo

RF26

El sistema debe permitir que el jefe de proyecto pueda modificar datos de todas las tareas ya agregadas a un proyecto asignado al usuario. Jefe de Proyecto

Actores Precondiciones

N° Requerimiento

   

Frecuencia

Ocasional

El usuario debe iniciar sesión El usuario debe tener asignado al menos un proyecto El proyecto debe tener asignado al menos una tarea La tarea a modificar no debe estar finalizada Acción del Actor Acción del Sistema 1. El usuario selecciona el proyecto 2. El sistema devolverá una interfaz con la al que desea modificar las tareas. información del proyecto seleccionado, 3. El usuario da clic en la opción además de un menú de opciones. Modificar Tareas ubicada en el 4. El sistema devolverá una interfaz con ítem Proyectos del menú una tabla donde se encontrarán todos los principal del sistema. participantes asignados al proyecto 5. El usuario selecciona el seleccionado participante al que desea 7. El sistema devolverá una interfaz con modificar las tareas una tabla donde se encontrarán todas las 6. El usuario da clic en el botón tareas agregadas al participante Siguiente seleccionado 8. El usuario selecciona la tarea que 10. El sistema devolverá una interfaz con desea modificar todos los datos de la tarea seleccionada 9. El usuario da clic en el botón previamente Siguiente 13. El sistema comprueba que todos los 11. El usuario podrá modificar: campos estén llenos y guarda los datos  Nombre de la Tarea en la respectiva base de datos.  Descripción de la Tarea  Fecha de Finalización 12. El usuario da clic en el botón Guardar Acción del Actor Acción del Sistema

20 

Postcondiciones

El usuario no ingresa datos en los  El sistema muestra un mensaje de error. campos  El usuario ingresa datos que no cumplan con el formato establecido para el campo.  El usuario selecciona a más de un participante Una vez finalizado el proceso de modificar los datos de la tarea, el sistema dará la opción de modificar otra tarea o volver a la página inicial del proyecto

14-dic-2015 Fecha Creación Fecha Implementación Técnico Diana Paladines – Jefferson Pantoja Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

30-mar-2016

Tabla 44 Requerimiento Funcional 27: Modificar Presupuesto Descripción del Caso de Uso Nombre Tipo Requerimiento Descripción

Modificar Presupuesto Requerimiento Funcional

Flujo Normal

Flujo Alternativo

Postcondiciones Fecha Creación

RF27

El sistema debe permitir que el jefe de proyecto pueda modificar el presupuesto asignado a cada recurso de los proyectos a los que ha sido asignado. Jefe de Proyecto

Actores Precondiciones

N° Requerimiento

Frecuencia

Ocasional

   

El usuario debe iniciar sesión en el sistema. El usuario debe tener el proyecto asignado El proyecto debe tener recursos asignados Los recursos del proyecto deben tener asignados un presupuesto Acción del Actor Acción del Sistema 1. El usuario selecciona el proyecto 2. El sistema devuelve una interfaz con la que desea modificar. información del proyecto seleccionado, 3. El usuario da clic en la opción además de un menú de opciones. Modificar Presupuesto ubicada 4. El sistema devuelve una interfaz con en el ítem Proyectos del menú. todos los recursos asignados al proyecto 5. El usuario podrá modificar: con su respectivo presupuesto.  Presupuesto del Recurso 7. El sistema comprueba que todos los 6. El usuario da clic en el botón campos estén llenos y actualiza los datos Guardar en la respectiva base de datos Acción del Actor Acción del Sistema  El usuario no ingresa datos en los  El sistema muestra un mensaje de error campos  El usuario ingresa datos que no cumplan con el formato establecido para el campo. Una vez finalizado el proceso de modificar presupuesto del proyecto, el sistema volverá a la página principal del proyecto. 14-dic-2015

Fecha Implementación

Técnico Diana Paladines – Jefferson Pantoja Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

01-abr-2016

21 Tabla 45 Requerimiento Funcional 28: Quitar Participantes del Proyecto Descripción del Caso de Uso Nombre Tipo Requerimiento Descripción

Quitar Participantes del Proyecto Requerimiento Funcional

El sistema debe permitir que el jefe de proyecto elimine a los participantes que ya no formaran parte de alguno de los proyectos que tiene a cargo. Jefe de Proyecto

Actores Precondiciones

   1.

3. Flujo Normal 5. 6. 8.

Flujo Alternativo Postcondiciones

RF28

N° Requerimiento



Ocasional

Frecuencia

El usuario debe iniciar sesión en el sistema. El participante a eliminar debe estar asignado al proyecto El participante a eliminar no debe tener tareas sin terminar Acción del Actor Acción del Sistema El usuario selecciona el proyecto 2. El sistema devolverá una interfaz con la al que desea quitarle información del proyecto seleccionado, participantes. además de un menú de opciones. El usuario da clic en la opción 4. El sistema devolverá una interfaz con Quitar Participantes ubicada en una tabla donde se encontrarán todos los el ítem Proyecto del menú participantes asignados al proyecto principal del sistema. seleccionado. El jefe de proyecto selecciona el 7. El sistema muestra un mensaje pidiendo usuario a eliminar la confirmación de la eliminación del El usuario da clic en el botón participante del proyecto. Quitar El usuario acepta la eliminación del participante del proyecto. Acción del Actor Acción del Sistema El usuario no selecciona ningún  El sistema muestra un mensaje de error participante a eliminar.

Una vez finalizado el proceso de eliminación el sistema volverá a la página inicial.

14-dic-2015 Fecha Creación Fecha Implementación Técnico Diana Paladines – Jefferson Pantoja Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

04-abr-2016

Tabla 46 Requerimiento Funcional 29: Eliminar Tareas Descripción del Caso de Uso Nombre Tipo Requerimiento Descripción

Eliminar Tareas Requerimiento Funcional

El sistema debe permitir que el jefe de proyecto pueda eliminar todas las tareas que ya no formaran parte de un proyecto asignado al usuario. Jefe de Proyecto

Actores

Precondiciones

Flujo Normal

RF29

N° Requerimiento

    

Frecuencia

Ocasional

El usuario debe iniciar sesión El usuario debe tener asignado al menos un proyecto El proyecto debe tener asignado al menos un participante El participante del proyecto debe tener asignada al menos una tarea La tarea del participante no debe estar comenzada Acción del Actor

Acción del Sistema

22 1. 3.

5. 6. 8.

El usuario selecciona el proyecto al que desea eliminar las tareas. El usuario da clic en la opción Eliminar Tareas ubicada en el ítem Proyectos del menú principal del sistema. El usuario selecciona la tarea que desea eliminar El usuario da clic en el botón Eliminar El usuario acepta la confirmación de la eliminación de la tarea.

Postcondiciones

El sistema devolverá una interfaz con la información del proyecto seleccionado, además de un menú de opciones. El sistema devolverá una interfaz con una tabla donde se encontrarán todos las tareas del proyecto, con el participante asignado El sistema muestra un mensaje pidiendo la confirmación de la eliminación de las tareas.

Nota: El proceso se repetirá desde el paso 5 hasta que el usuario haya eliminado todas las tareas deseadas. Acción del Sistema  El sistema muestra un mensaje de error.

Acción del Actor El usuario no ingresa datos en los campos  El usuario ingresa datos que no cumplan con el formato establecido para el campo.  El usuario selecciona a más de un participante Una vez finalizado el proceso de eliminar tareas del proyecto, el sistema dará la opción volverá a la página inicial. 

Flujo Alternativo

14-dic-2015

Fecha Creación

Fecha Implementación

06-abr-2016

Técnico Diana Paladines – Jefferson Pantoja Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

Tabla 47 Requerimiento Funcional 30: Extender Plazo del Proyecto Descripción del Caso de Uso Nombre

Extender Plazo del Proyecto

Tipo Requerimiento

Requerimiento Funcional

Descripción Actores Precondiciones

N° Requerimiento

RF30

El sistema debe permitir que el jefe de proyecto pueda extender el plazo de finalización del proyecto, el cual debe ser aprobado por el administrador del sistema. Ocasional Jefe de Proyecto Frecuencia    1.

3. Flujo Normal 5.

El usuario debe iniciar sesión El usuario debe tener asignado al menos un proyecto Los datos del proyecto deben estar completos Acción del Actor Acción del Sistema El usuario selecciona el 2. El sistema devolverá una interfaz con la proyecto al que desea información del proyecto seleccionado, extender plazo. además de un menú de opciones. El usuario da clic en la opción 4. El sistema devolverá una interfaz con la Extender Plazo ubicada en el fecha de finalización ingresada ítem Proyectos del menú inicialmente principal del sistema. 7. El sistema comprobará que todos los El usuario modificará la campos estén llenos y actualizará los Fecha de Finalización del datos correspondientes en la respectiva Proyecto, además deberá base de datos. ingresar el motivo por el cual

Flujo Alternativo

 

Postcondiciones



Fecha Creación

solicita extender el plazo de finalización. El usuario da clic en el botón Guardar Acción del Actor Acción del Sistema El usuario quiere volver a  Mensaje de espera de aprobación si el extender el plazo de administrador aun no aprueba la solicitud finalización del proyecto de extensión del plazo Una vez solicitada la extensión de plazo para el proyecto, el usuario debe esperar que el administrador la apruebe. La solicitud de extensión de plazo para el para el proyecto debe ser aprobada por el administrador del sistema, proceso detallado en RF35 14-dic-2015 08-abr-2016 Fecha Implementación Diana Paladines – Jefferson Pantoja

Técnico Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

Tabla 48 Requerimiento Funcional 31: Avance Proyecto Descripción del Caso de Uso Nombre Tipo Requerimiento Descripción

Avance Proyecto Requerimiento Funcional RF31 N° Requerimiento El sistema debe permitir que el jefe de proyecto finalice todos los proyectos que tiene a su cargo. Jefe de Proyecto

Actores Precondiciones

Flujo Normal

Flujo Alternativo Postcondiciones

Frecuencia

  

Ocasional

El usuario debe iniciar sesión El usuario debe tener al menos un proyecto asignado El proyecto a finalizar debe tener un avance del 100% Acción del Actor Acción del Sistema 1. El usuario selecciona el 2. El sistema devuelve una interfaz con la proyecto del cual quiere ver el información del proyecto seleccionado, avance. además de un menú de opciones. 3. El usuario da clic en la opción 4. El sistema devuelve una interfaz con Avance Proyecto ubicado en el información del proyecto, además del ítem Proyectos del menú porcentaje de avance. principal del sistema. 6. El sistema devuelve un mensaje 5. El usuario da clic en el botón solicitando la confirmación de la Finalizar, en caso de que el finalización del proyecto. porcentaje de avance sea del 100%. 7. El usuario acepta la confirmación de la finalización del proyecto. Acción del Actor Acción del Sistema  El proyecto tiene un porcentaje  El sistema no activa el botón Finalizar de avance menor al 100%. Una vez terminado el proceso de finalizar un proyecto, el usuario debe dar clic en el botón Inicio para regresar a la página principal del sistema 14-dic-2015 11-abr-2016 Fecha Implementación

Fecha Creación Técnico Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

Diana Paladines – Jefferson Pantoja

24 Tabla 49 Requerimiento Funcional 32: Proyectos Asignados Descripción del Caso de Uso Nombre Tipo Requerimiento Descripción

Proyectos Asignados Requerimiento Funcional

Participante

Actores Precondiciones

Flujo Normal

Flujo Alternativo

Postcondiciones

RF32

N° Requerimiento

El sistema debe permitir que el participante genere reportes de todos los proyectos a los que ha sido asignado con su respectivo rol y tareas a cargo. Siempre

Frecuencia

 

El usuario debe haber iniciado sesión en el sistema. El usuario debe estar asignado a al menos un proyecto Acción del Actor Acción del Sistema 1. El usuario da clic en la opción 2. El sistema devolverá una interfaz con una Proyectos Asignados ubicada tabla donde se encontrarán los proyectos en el ítem Reportes del menú asignados al participante con su respectivo rol. principal del sistema.

Acción del Sistema El sistema genera un reporte en PDF con todos los datos de los proyectos a los q ha sido asignado el usuario. Una vez generado el reporte el usuario debe dar clic en el botón Inicio para regresar a la página principal del sistema 

Acción del Actor El usuario da clic en el botón Descargar

14-dic-2015

Fecha Creación



Fecha Implementación

13-abr-2016

Diana Paladines – Jefferson Pantoja

Técnico Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

Tabla 50 Requerimiento Funcional 33: Extender Plazo de las Tareas Descripción del Caso de Uso Nombre Tipo Requerimiento Descripción

Extender Plazo de las Tareas Requerimiento Funcional

Participante   

5. 7.

Ocasional

Frecuencia

El usuario debe iniciar sesión El usuario debe tener asignado al menos una tarea El usuario debe formar parte de un proyecto Acción del Actor

Flujo Normal

RF33

El sistema debe permitir que el participante pueda extender el plazo de finalización de las diferentes tareas asignadas, el cual debe ser aprobado por el jefe de proyecto.

Actores Precondiciones

N° Requerimiento

El usuario selecciona el proyecto al que desea consultar la tarea que le extenderá el plazo. El usuario da clic en la opción Extender Plazo ubicada en el ítem Proyectos del menú principal del sistema. El usuario selecciona la tarea a la cual desea extender el plazo El usuario modificará la Fecha de Finalización de la tarea,

Acción del Sistema 2.

El sistema devolverá una interfaz con la información del proyecto seleccionado, además de un menú de opciones. El sistema devolverá una interfaz con una tabla con todas las tareas del proyecto asignadas al usuario. El sistema devolverá una interfaz con la fecha de finalización ingresada inicialmente El sistema comprobará que todos los campos estén llenos y actualizará los datos

25 además del motivo por el cual correspondientes en la respectiva base de se solicita la extensión del datos. plazo de finalización. 8. El usuario da clic en el botón Guardar Acción del Actor Acción del Sistema  Mensaje de espera de  Mensaje de espera de aprobación si el Flujo Alternativo aprobación si el administrador administrador aun no aprueba la solicitud aun no aprueba la solicitud de de extensión del plazo extensión del plazo  Una vez solicitada la extensión de plazo para la tarea, el usuario debe esperar que el jefe de proyecto la apruebe. Postcondiciones  La solicitud de extensión de plazo para el para las tareas debe ser aprobada por el jefe del proyecto, proceso detallado en RF35. 14-dic-2015 15-abr-2016 Fecha Creación Fecha Implementación Diana Paladines – Jefferson Pantoja Técnico Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

Tabla 51 Requerimiento Funcional 34: Avance de Tareas Descripción del Caso de Uso Avance de Tareas Requerimiento Funcional RF34 N° Requerimiento El sistema debe permitir que el participante finalice todas las tareas que tiene a su Descripción cargo. Participante Ocasional Actores Frecuencia  El usuario debe haber ingresado al sistema.  El usuario debe tener asignada al menos una tarea Precondiciones  La tarea a finaliza debe tener un avance del 100% Acción del Actor Acción del Sistema 1. El usuario selecciona el 2. El sistema devuelve una interfaz con la proyecto al que desea ver el información del proyecto seleccionado, avance de tareas. además de un menú de opciones. 3. El usuario da clic en la opción 4. El sistema devuelve una interfaz con una Avance de Tareas ubicado en tabla con todas las tareas del proyecto el ítem Proyectos del menú asignadas al usuario. principal del sistema. 6. El sistema devuelve una interfaz con Flujo Normal 5. El usuario selecciona la tarea a información de la tarea, además del la cual quiere ver el avance porcentaje de avance. 7. El usuario da clic en el botón 8. El sistema devuelve un mensaje Finalizar, en caso de que el solicitando la confirmación de la porcentaje de avance sea del finalización de la tarea. 100%. 9. El usuario acepta la confirmación de la finalización de la tarea. Acción del Actor Acción del Sistema  El proyecto tiene un  El sistema no activa el botón Finalizar Flujo Alternativo porcentaje de avance menor al 100%. Una vez finalizada la tarea, el sistema dará la opción de subir información de la misma Postcondiciones en la wiki. 14-dic-2015 18-abr-2016 Fecha Creación Fecha Implementación Diana Paladines – Jefferson Pantoja Técnico Responsable Elaborado por: Jefferson Pantoja – Diana Paladines Nombre Tipo Requerimiento

26 Tabla 52 Requerimiento Funcional 35: Aprobación de Solicitudes Descripción del Caso de Uso Nombre Tipo Requerimiento Descripción

Actores Precondiciones

Aprobación de Solicitudes Requerimiento Funcional

El sistema debe permitir que el administrador apruebe solicitudes de cambios en los proyectos. Los cambios solicitados por el jefe de proyecto son aprobados por el administrador, mientras que los solicitados por los participantes son aprobados por el jefe de proyecto.  Administrador Ocasional Frecuencia  Jefe de Proyecto  El usuario debe iniciar sesión  El sistema debe tener al menos un proyecto creado 1.

3. Flujo Normal 4. 6. 8. Flujo Alternativo Postcondiciones

RF35

N° Requerimiento

Acción del Actor El usuario da clic en la opción Solicitudes dentro del ítem Proyectos del menú principal del sistema, El usuario deberá seleccionar la solicitud que desea analizar El usuario da clic en el botón Siguiente El usuario da clic en el botón Aprobar o Rechazar El usuario acepta la aprobación o rechazo de la solicitud.

Acción del Sistema El sistema devuelve una interfaz con una tabla donde se encuentran las diferentes solicitudes que necesitan su aprobación. El sistema devuelve una interfaz con la información detallada para la aprobación de la solicitud. El sistema muestra un mensaje confirmando la aceptación o rechazo de la solicitud.

Acción del Actor Acción del Sistema  El usuario no selecciona ningún  El sistema muestra un mensaje de error proyecto Una vez completada la aprobación o rechazo de la solicitud, el sistema dará la opción de analizar otra solicitud o regresar a la página principal del sistema. 14-dic-2015

Fecha Creación

Fecha Implementación

20-abr-2016

Técnico Diana Paladines – Jefferson Pantoja Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

Tabla 53 Requerimiento Funcional 36: Reportes (Administrador) Descripción del Caso de Uso Nombre Tipo Requerimiento Descripción

Reportes Requerimiento Funcional

Flujo Normal

RF36

El sistema debe permitir que el usuario genere reportes de los participantes, roles y recursos del sistema. Administrador

Actores Precondiciones

N° Requerimiento

 

Ocasional

Frecuencia

El usuario debe iniciar sesión El sistema debe tener al menos un participante registrado Acción del Actor

Acción del Sistema

27 1.

Flujo Alternativo Postcondiciones

El usuario da clic en la opción Ver dependiendo el reporte que desee, ubicada en el ítem:  Participantes  Roles  Recursos Acción del Actor El usuario da clic en el botón Descargar

El sistema devuelve una interfaz con una tabla donde se encuentran todos los participantes, roles o recursos, dependiendo el reporte generado.

Acción del Sistema El sistema genera un reporte en PDF con todos los datos de participantes, roles o recursos. Una vez generado el reporte el usuario debe dar clic en la opción Inicio del menú para regresar a la página principal del sistema 

14-dic-2015

Fecha Creación



Fecha Implementación

25-abr-2016

Técnico Diana Paladines – Jefferson Pantoja Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

Tabla 54 Requerimiento Funcional 37: Reporte de Proyectos Descripción del Caso de Uso Nombre Tipo Requerimiento Descripción Actores Precondiciones

Flujo Normal

Reporte de Proyectos Requerimiento Funcional

RF37

El sistema debe permitir que el administrador genere reportes de todos los proyectos creados en el sistema.    

Administrador Ocasional Frecuencia Jefe de Proyecto El usuario debe iniciar sesión El sistema debe tener al menos un proyecto creado Acción del Actor Acción del Sistema 1. El usuario da clic en la opción 2. El sistema devuelve una interfaz con las Reporte General dentro del ítem diferentes opciones para generar reporte de Proyectos del menú principal del los proyectos. sistema, 8. El sistema devuelve una interfaz con una 12. El usuario deberá elegir el tipo de tabla donde se encuentran todos los reporte que desea, estos pueden ser: proyectos existentes de acuerdo al tipo de  Proyectos en Curso reporte seleccionado  Proyectos Finalizados  Proyectos Cancelados  Proyectos Extendidos 13. El usuario selecciona el rango de fechas de los proyectos que desea generar el reporte. 14. El usuario da clic en el botón Generar 

Flujo Alternativo

N° Requerimiento

El usuario da clic en el botón Descargar

Acción del Actor



El sistema genera un reporte en PDF con todos los datos de los proyectos creados en el sistema. Acción del Sistema

28 1.

5. 

Postcondiciones

El usuario da clic en la opción Reporte Detallado dentro del ítem Proyectos del menú principal del sistema, El usuario deberá elegir el tipo de reporte que desea, estos pueden ser:  Proyectos en Curso  Proyectos Finalizados  Proyectos Cancelados  Proyectos Extendidos El usuario selecciona el rango de fechas de los proyectos que desea generar el reporte. El usuario da clic en el botón Generar El usuario da clic en el botón Descargar

El sistema devuelve una interfaz con las diferentes opciones para generar reporte de los proyectos. El sistema devuelve una interfaz con una tabla donde se encuentran todos los proyectos existentes de acuerdo al tipo de reporte seleccionado



El sistema genera un reporte en PDF con todos los datos de los proyectos creados en el sistema. Una vez generado el reporte el usuario debe dar clic en el botón Inicio para regresar a la página principal del sistema 14-dic-2015 02-may-2016 Fecha Implementación

Fecha Creación Técnico Diana Paladines – Jefferson Pantoja Responsable Elaborado por: Jefferson Pantoja – Diana Paladines Tabla 55 Requerimiento Funcional 38: Cronograma del Proyecto Descripción del Caso de Uso Nombre Tipo Requerimiento Descripción Actores

Precondiciones

Flujo Normal

Flujo Alternativo Postcondiciones Fecha Creación

Cronograma del Proyecto Requerimiento Funcional

N° Requerimiento

RF38

El sistema debe permitir que el jefe de proyecto y participante puedan generar el cronograma con todas las tareas para la elaboración del o los proyectos.  Jefe de Proyecto Ocasional Frecuencia  Participante  El usuario debe iniciar sesión  El usuario debe tener asignado al menos un proyecto  El proyecto debe tener asignado al menos una tarea  El proyecto debe tener asignado al menos un participante Acción del Actor Acción del Sistema 1. El usuario selecciona el proyecto al 2. El sistema devolverá una interfaz con la que desea generar el cronograma. información del proyecto seleccionado, 3. El usuario da clic en la opción además de un menú de opciones. Cronograma ubicada en el ítem 4. El sistema devolverá una interfaz con el Proyectos del menú principal del cronograma del proyecto seleccionado sistema. Acción del Actor Acción del Sistema  El usuario da clic en el botón  El sistema genera un cronograma en PDF. Descargar Una vez generado el cronograma el usuario debe dar clic en el botón Inicio para regresar a la página principal del sistema 14-dic-2015

Fecha Implementación

Técnico Diana Paladines – Jefferson Pantoja Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

04-may-2016

29 Tabla 56 Requerimiento Funcional 39: Presupuesto Descripción del Caso de Uso Nombre

Presupuesto (Reporte)

Tipo Requerimiento Descripción

Requerimiento Funcional

Flujo Normal

Flujo Alternativo Postcondiciones

RF39

El sistema debe permitir que el jefe de proyecto genere reportes detallando la distribución del presupuesto de los diferentes proyectos que tiene a su cargo. Jefe de Proyecto

Actores Precondiciones

N° Requerimiento

Ocasional

Frecuencia

  

El usuario debe iniciar sesión El usuario debe tener asignado al menos un proyecto El proyecto debe tener asignado al menos un participante Acción del Actor Acción del Sistema 1. El usuario selecciona el proyecto al 2. El sistema devolverá una interfaz con la que desea ver la distribución del información del proyecto seleccionado, presupuesto. además de un menú de opciones. 3. El usuario da clic en la opción 4. El sistema devuelve una interfaz con una Presupuesto ubicada en el ítem tabla donde se encuentran todos los Reportes del menú principal del participantes asignados al sistema. sistema. Acción del Actor Acción del Sistema  El usuario da clic en el botón  El sistema genera un reporte en PDF con Descargar todos los datos de la distribución de presupuesto. Una vez generado el reporte el usuario debe dar clic en la opción Inicio del menú para regresar a la página principal del sistema

14-dic-2015 Fecha Creación Fecha Implementación Técnico Diana Paladines – Jefferson Pantoja Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

06-may-2016

Tabla 57 Requerimiento Funcional 40: Tareas Asignadas Descripción del Caso de Uso Nombre

Tareas Asignadas

Tipo Requerimiento Descripción

Requerimiento Funcional

RF40

El sistema debe permitir que el participante genere reportes de todas las tareas a las que ha sido asignado anteriormente por el jefe de proyecto. Participante

Actores Precondiciones

N° Requerimiento

   1.

Flujo Normal 3.

Frecuencia El usuario debe haber iniciado sesión en el sistema. El usuario debe estar registrado en al menos un proyecto El usuario debe tener asignada al menos una tarea Acción del Actor El usuario selecciona el proyecto del que desea ver las tareas asignadas. El usuario da clic en la opción Tareas del Proyecto ubicada dentro del ítem Reportes del menú del sistema. Acción del Actor

Ocasional

Acción del Sistema El sistema devolverá un interfaz con información del proyecto seleccionado, además de un menú de opciones. El sistema devolverá una interfaz con una tabla con toda la información de las tareas asignadas al usuario. Acción del Sistema

Flujo Alternativo Postcondiciones



El sistema genera un reporte en PDF con todos los datos de los proyectos a los q ha sido asignado el usuario. Una vez generado el reporte el usuario debe dar clic en el botón Inicio para regresar a la página principal del sistema

Fecha Creación

El usuario da clic en el botón Descargar

14-dic-2015

Fecha Implementación

09-may-2016

Técnico Diana Paladines – Jefferson Pantoja Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

Tabla 58 Requerimiento Funcional 41: Olvidé Mi Contraseña Descripción del Caso de Uso Olvidé mi Contraseña Requerimiento Funcional RF41 N° Requerimiento El sistema debe asignar al usuario una contraseña temporal para que este pueda Descripción iniciar sesión en caso de olvidar la registrada anteriormente.  Administrador  Jefe de Proyecto Ocasional Actores Frecuencia  Participante  El usuario debe estar registrado en el sistema.  El usuario debe haber tratado de ingresar erróneamente al sistema al menos Precondiciones tres veces consecutivas. Acción del Actor Acción del Sistema 1. El usuario da clic en la 2. El sistema devuelve una interfaz opción Olvidé mi solicitando responder una pregunta de Contraseña ubicada debajo seguridad registrada anteriormente. del cuadro de texto de la 5. El sistema verifica que la respuesta Flujo Normal contraseña. ingresada sea correcta y despliega un 3. El usuario responde la mensaje, solicitándole al usuario revisar pregunta de seguridad que se en su correo la contraseña asignada. solicita. 4. El usuario da clic en el botón Enviar Acción del Actor Acción del Sistema  El usuario no ingresa datos  El sistema muestra un mensaje de error en los campos  El sistema muestra la siguiente Flujo Alternativo  El usuario responde pregunta de seguridad registrada. incorrectamente tres veces  El sistema solicita ingresar el número de consecutiva la pregunta cédula del usuario.  Una vez terminado el proceso de asignación de una nueva contraseña, el usuario podrá ingresar normalmente al sistema, como se detalla en RF01.  Una vez que el usuario ingrese al sistema con la contraseña asignada Postcondiciones temporalmente, y para la asignación de esta no recordó las respuestas de las preguntas de seguridad, se despliega la interfaz detallada en RNF02. 14-dic-2015 27-ene-2016 Fecha Creación Fecha Implementación Diana Paladines – Jefferson Pantoja Técnico Responsable Elaborado por: Jefferson Pantoja – Diana Paladines Nombre Tipo Requerimiento

Tabla 59 Requerimiento Funcional 42: Cambiar Contraseña Descripción del Caso de Uso Nombre Tipo Requerimiento

Cambiar Contraseña (Al Iniciar Sesión por Primera Vez) Requerimiento Funcional N° Requerimiento

RF42

31 El sistema debe permitir que cada usuario pueda modificar su contraseña la primera vez que inicie sesión.  Administrador Actores  Jefe de Proyecto Ocasional Frecuencia  Participante  El usuario debe estar registrado en el sistema. Precondiciones  El usuario debe iniciar sesión por primera vez. Flujo Normal Acción del Actor Acción del Sistema 1. El usuario ingresa por primera 2. El sistema devuelve una interfaz vez al sistema. solicitando una nueva contraseña y 3. El usuario ingresa dos preguntas de seguridad para  Nueva Contraseña poder recuperar su contraseña en el  Verificar Contraseña futuro Además el usuario responde dos 5. El sistema verifica que las dos preguntas de seguridad contraseña ingresadas coincidan y 4. El usuario da clic en el botón cumplan con el formato establecido guardar 6. El sistema actualiza la nueva contraseña y guarda las repuestas de las preguntas en su respectiva base de datos Flujo Alternativo Acción del Actor Acción del Sistema  El usuario no ingresa datos en  El sistema muestra un mensaje de los campos error  El usuario ingresa contraseña diferentes en los campos establecidos para la nueva contraseña  El usuario ingresa datos que no cumplen con el formato establecido  Una vez que el usuario cambie su contraseña este podrá acceder a todas las Postcondiciones herramientas del sistema de acuerdo al tipo de usuario. 14-dic-2015 29-ene-2016 Fecha Creación Fecha Implementación Diana Paladines – Jefferson Pantoja Técnico Responsable Elaborado por: Jefferson Pantoja – Diana Paladines Descripción

32 REQUERIMIENTOS NO FUNCIONALES Tabla 60 Requerimiento No Funcional 1: Seguridad Descripción del Caso de Uso Nombre Tipo Requerimiento

Descripción

Seguridad

N° Requerimiento

RNF01

Relacionado

RF01

Requerimiento No Funcional

El sistema debe permitir el uso de contraseña para todos los participantes, permitiendo el acceso al sistema únicamente a las personas registradas. Los participantes registrados en el sistema podrán acceder siempre y cuando estén activados Alta

Prioridad

Técnico Diana Paladines – Jefferson Pantoja Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

Tabla 61 Requerimiento No Funcional 2: Disponibilidad Descripción del Caso de Uso Nombre Tipo Requerimiento

Disponibilidad

N° Requerimiento

RNF02

Relacionado

Todos los RF

Requerimiento No Funcional

Descripción

La información del sistema, especialmente la de los proyectos, estará siempre disponible debido a que se encuentra almacenada en una base de datos, la cual se respaldará automáticamente cada 24 horas, permitiendo de esta forma recuperar la información rápidamente en caso de cualquier inconveniente.

Prioridad

Alta

Técnico Diana Paladines – Jefferson Pantoja Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

Tabla 62 Requerimiento No Funcional 3: Mantenibilidad Descripción del Caso de Uso Nombre Tipo Requerimiento

Mantenibilidad Requerimiento No Funcional

N° Requerimiento

RNF03

Relacionado

Todos los RF

Descripción

Los códigos de cada una de las tablas del sistema tendrán un inicio y un final definidos por el Administrador, los cuales podrán ser reiniciados cada cierto tiempo dependiendo de las políticas de la organización. La información almacenada podrá ser modificada teniendo en cuenta los privilegios de los usuarios.

Prioridad

Alta

Técnico Diana Paladines – Jefferson Pantoja Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

33 Tabla 63 Requerimiento No Funcional 4: Rendimiento Descripción del Caso de Uso Nombre Tipo Requerimiento

Rendimiento Requerimiento No Funcional

N° Requerimiento

RNF04

Relacionado

Todos los RF

Descripción

Los tiempos de respuesta para la presentación de la información del sistema son cortos debido a que la información está disponible en el servidor a la espera de la consulta por parte del cliente.

Prioridad

Alta

Técnico Diana Paladines – Jefferson Pantoja Responsable Elaborado por: Jefferson Pantoja – Diana Paladines

Anexo 3. Diagramas UML

ÍNDICE DE FIGURAS Figura 1 Diagrama de Caso de Uso de Interfaz general del Sistema ......................................... 1 Figura 2 Caso de Uso – Procesos del Administrador ................................................................ 2 Figura 3 Caso de Uso - Procesos del Jefe de Proyecto .............................................................. 3 Figura 4 Caso de Uso – Procesos del Participante ..................................................................... 3 Figura 5 Diagrama de Clases ..................................................................................................... 4 Figura 6 Diagrama de Secuencia de Administrador .................................................................. 5 Figura 7 Diagrama de Secuencia de Jefe de Proyecto ............................................................... 6 Figura 8 Diagrama de Secuencia de Participante ...................................................................... 7 Figura 9 Diagrama de Base de Datos ......................................................................................... 8

DIAGRAMAS DE CASO DE USO

Figura 33 Diagrama de Caso de Uso de Interfaz general del Sistema Fuente: Elaborado por Jefferson Pantoja â&#x20AC;&#x201C; Diana Paladines (2016)

Figura 34 Caso de Uso â&#x20AC;&#x201C; Procesos del Administrador Fuente: Elaborado por Jefferson Pantoja â&#x20AC;&#x201C; Diana Paladines (2016)

Figura 35 Caso de Uso - Procesos del Jefe de Proyecto Fuente: Elaborado por Jefferson Pantoja – Diana Paladines (2016)

Figura 36 Caso de Uso – Procesos del Participante Fuente: Elaborado por Jefferson Pantoja – Diana Paladines (2016)

DIAGRAMA DE CLASES

Figura 37 Diagrama de Clases Fuente: Elaborado por Jefferson Pantoja â&#x20AC;&#x201C; Diana Paladines (2016)

DIAGRAMAS DE SECUENCIA

Figura 38 Diagrama de Secuencia de Administrador Fuente: Elaborado por Jefferson Pantoja â&#x20AC;&#x201C; Diana Paladines (2016)

Figura 39 Diagrama de Secuencia de Jefe de Proyecto Fuente: Elaborado por Jefferson Pantoja â&#x20AC;&#x201C; Diana Paladines (2016)

Figura 40 Diagrama de Secuencia de Participante Fuente: Elaborado por Jefferson Pantoja â&#x20AC;&#x201C; Diana Paladines (2016)

DIAGRAMA DE BASE DE DATOS

Figura 41 Diagrama de Base de Datos Fuente: Elaborado por Jefferson Pantoja â&#x20AC;&#x201C; Diana Paladines (2016)

Anexo 4. Encuesta

1 ENCUESTA – SISTEMA DE GESTIÓN DE PROYECTOS La presente encuesta está dirigida al departamento de Sistemas de la Clínica Santiago con el objetivo de conocer la manera en que se desarrollan actualmente los diferentes proyectos de este departamento. Cabe mencionar que los datos obtenidos con la misma serán de uso académico. Todas las preguntas de esta encuesta deben ser respondidas marcando con una X solo una opción que usted considere adecuada. 1. ¿Con qué frecuencia realizan proyectos en su lugar de trabajo? Mensual

___

Trimestral

___

Semestral

___

Anual

___

2. ¿Con qué frecuencia participa usted en los proyectos? Siempre

___

Casi Siempre

___

Algunas Veces

___

Nunca

___

3. ¿Los proyectos en los que ha participado han sido planificados con anterioridad? Sí

___

Nota: Si su respuesta es NO pase a la pregunta N° 5 4. ¿En qué porcentaje ha sido planificado el proyecto en el que usted ha participado? De 0% a 25%

___

De 26% a 50%

___

De 51% a 75%

___

Completamente

___

5. ¿Se ha llevado un control en el avance del proyecto en el que ha participado? Sí

___

6. ¿En qué porcentaje considera usted que se ha culminado las tareas asignadas en el tiempo planificado? De 0% a 25%

___

De 26% a 50%

___

De 51% a 75%

___

Completamente

___

2 7. ¿De qué forma se ha llevado la comunicación dentro de los proyectos en los que ha participado? Reuniones de trabajo

___

Entrevista con el Jefe de proyecto

___

Correo electrónico

___

Otros

___

8. ¿Se ha postergado alguna vez la fecha de culminación de los proyectos en los que ha participado? Sí

___

9. ¿Cuál de los siguientes motivos ha sido para usted el más frecuente para la postergación de las fechas de finalización de los proyectos? Falta de Presupuesto

___

Falta de Recursos Humanos

___

Falta de Recursos Tecnológicos

___

Otros

___

10. ¿En los proyectos que ha participado han sido cancelados inesperadamente? Sí

___

11. ¿Ha utilizado usted alguna herramienta que le ayude en la planificación de los proyectos en los que ha participado? Sí

___

12. ¿Le gustaría utilizar una herramienta de gestión de proyectos que satisfaga las dificultadas presentadas? Sí

___

Anexo 5. Diccionario de Datos

CONSORCIO CLÍNICA SANTIAGO CIA. LTDA.

SISTEMA DE GESTIÓN DE PROYECTOS

DICCIONARIO DE DATOS SGP

Glosario: 

AI: Autoincremental



BIN: Binario



NN: Campo No Nulo



PK: Clave primaria



UN: Número con signos positivos



UQ: Campo único



ZF: Rellenar con ceros a la izquierda de los números

Campo cod_codi cod_nomb cod_abre cod_desc cod_fecr cod_fefi cod_nuin cod_nuac cod_nufi cod_esta

Campo dep_codi dep_nomb dep_esta

Campo doc_codi doc_nomb doc_tipo doc_tama doc_ruta doc_fecr tar_codi

Tipo de Dato INT(5) VARCHAR(50) VARCHAR(3) VARCHAR(50) DATE DATE INT(5) INT(5) INT(5) VARCHAR(25)

Tipo de Dato INT(5) VARCHAR(50) VARCHAR(25)

Tipo de Dato INT(5) VARCHAR(500) VARCHAR(6) INT(5) VARCHAR(500) DATETIME INT(5)

sgp_codi PK NN UQ BIN UN ZF AI Default X X X X X X X X X X X X X

sgp_depa PK NN UQ BIN UN ZF AI X X X X X X

sgp_docu PK NN UQ BIN UN ZF AI X X X X X X X X X

Descripción Identificador del código Nombre del código Abreviatura del código Descripción del código Fecha de creación del código Fecha de vencimiento del código Número inicial del código Número actual del código Número final del código Estado del código

Default

Descripción Identificador del departamento Nombre del departamento Estado del departamento

Descripción Código del documento Nombre del documento Extensión del documento Tamaño del documento Ruta donde está almacenado el documento Fecha de creación del registro Identificador de la tarea

Campo for_codi for_titu for_mens for_fech fer_resp for_iden for_ulre par_codi

Campo cli_nomb cli_logo

Campo rec_codi rec_nomb rec_desc rec_esta rec_fecr dep_codi

Tipo de Dato INT(5) VARCHAR(500) VARCHAR(1000) DATE INT(5) INT(5) DATE INT(5)

sgp_foro PK NN UQ BIN UN ZF AI X X X X X X X X X X X

Tipo de Dato VARCHAR(50) MEDIUMBLOB

sgp_clin PK NN UQ BIN UN ZF AI X X

Tipo de Dato INT(5) VARCHAR(25) VARCHAR(100) VARCHAR(25) DATETIME INT(5)

sgp_recu PK NN UQ BIN UN ZF AI X X X X X X X X X

Default

Descripción Identificador del tema del foro Título del tema Mensaje Fecha de inicio del tema Número de respuestas del tema Identificador del tema o respuesta Fecha de la última respuesta del tema Identificador del participante

Descripción Nombre de la organización Logo de la organización

Descripción Identificador del recurso Nombre del recurso Descripción del recurso Estado del recurso Fecha de creación del registro Identificador del departamento

Campo par_codi par_cedu par_nom1 par_nom2 par_ape1 par_ape2 par_corr par_dire par_tele par_carg par_usua par_cont par_espa par_esda par_fecr dep_codi

Campo rol_codi rol_nomb rol_esta rol_fecr dep_codi

Tipo de Dato INT(5) VARCHAR(10) VARCHAR(25) VARCHAR(25) VARCHAR(25) VARCHAR(25) VARCHAR(50) VARCHAR(50) VARCHAR(10) VARCHAR(25) VARCHAR(25) VARCHAR(25) VARCHAR(25) VARCHAR(1) DATETIME INT(5)

Tipo de Dato INT(5) VARCHAR(25) VARCHAR(25) DATETIME INT(5)

sgp_part PK NN UQ BIN UN ZF AI X X X X X X

Default

X X

X X X X X X X

sgp_rols PK NN UQ BIN UN ZF AI X X X X X X X X

Default

Descripción Identificador del participante Número de cédula del participante Primer nombre del participante Segundo nombre del participante Apellido paterno del participante Apellido materno del participante Correo electrónico del participante Dirección del participante Teléfono del participante Cargo del participante Usuario del participante Contraseña del participante Estado del participante Estado de los datos del participante Fecha de creación del registro Identificador del departamento

Descripción Identificador del rol Nombre del rol Estado del rol Fecha de creación del registro Identificador del departamento

Campo pro_codi pro_nomb pro_pres pro_alca pro_tipo pro_fein pro_fefi pro_espr pro_esda pro_prnu pro_ffex pro_fecr dep_codi

Campo pre_codi pre_preg

Campo sub_codi sub_desc sub_fecr tar_codi

Tipo de Dato INT(5) VARCHAR(100) FLOAT VARCHAR(500) VARCHAR(25) DATE DATE VARCHAR(25) VARCHAR(1) FLOAT DATE DATETIME INT(5)

sgp_proy PK NN UQ BIN UN ZF AI Default Descripción X X X Identificador del proyecto X Nombre del proyecto X Presupuesto del proyecto Alcance del proyecto Tipo de proyecto Fecha de inicio del proyecto Fecha de finalización del proyecto X Estado del proyecto X Estado de los datos del proyecto Presupuesto modificado del proyecto Fecha de finalización extendida del proyecto X Fecha de creación del registro X Identificador del departamento sgp_preg BIN UN ZF AI X

Tipo de Dato INT(5) VARCHAR(50)

PK NN UQ X X X X

Tipo de Dato INT(5) VARCHAR(500) DATETIME INT(5)

sgp_subt PK NN UQ BIN UN ZF AI X X X X X X

Default

Descripción Identificador de la pregunta Pregunta de seguridad

Default

Descripción Identificador de la subtarea Descripción de la subtarea Fecha de creación del registro Identificador de la tarea

Campo tar_codi tar_nomb tar_desc tar_fein tar_fefi tar_esta tar_esda tar_ffex tar_fecr par_codi pro_codi

Campo res_resp pre_codi par_codi

Campo par_codi pro_codi rol_codi ppr_esta

Tipo de Dato INT(5) VARCHAR(50) VARCHAR(100) DATE DATE VARCHAR(25) VARCHAR(1) DATE DATETIME INT(5) INT(5)

Tipo de Dato VARCHAR(100) INT(5) INT(5)

Tipo de Dato INT(5) INT(5) INT(5) VARCHAR(25)

sgp_tars PK NN UQ BIN UN ZF AI Default Descripción X X X Identificador de la tarea X Nombre de la tarea X Descripción de la tarea X Fecha de inicio de la tarea X Fecha de finalización de la tarea X Estado de la tarea X X Estado de los datos de la tarea Fecha de finalización extendida de la tarea X Fecha de creación del registro X Identificador del participante X Identificador del proyecto

PK X X

NN X X X

sgp_resp BIN UN ZF AI

sgp_papr PK NN UQ BIN UN ZF AI X X X X X X X

Default

Descripción Respuesta de la pregunta de seguridad Identificador de la pregunta Identificador del participante

Descripción Identificador del participante Identificador del proyecto Identificador del rol Estado del participante en un proyecto

Campo pro_codi rec_codi pre_pres ppr_esta

Campo sol_codi sol_nomb sol_obse sol_esta sol_fecr pro_codi

Campo sol_codi sol_nomb sol_obse sol_esta sol_fecr tar_codi

Tipo de Dato INT(5) INT(5) FLOAT VARCHAR(25)

sgp_prre PK NN UQ BIN UN ZF AI X X X X

Default

Tipo de Dato INT(5) VARCHAR(25) VARCHAR(500) VARCHAR(25) DATETIME INT(5)

sgp_sopr PK NN UQ BIN UN ZF AI X X X X X X X X

Tipo de Dato INT(5) VARCHAR(25) VARCHAR(500) VARCHAR(25) DATETIME INT(5)

sgp_sota PK NN UQ BIN UN ZF AI X X X X X X X X

Descripciรณn Identificador del proyecto Identificador del recurso Presupuesto del recurso Estado del recurso en el proyecto

Default

Descripciรณn Identificador de la solicitud Nombre de la solicitud Motivo de la solicitud Estado de la solicitud Fecha de creaciรณn del registro Identificador del proyecto

Default

Descripciรณn Identificador de la solicitud Nombre de la solicitud Motivo de la solicitud Estado de la solicitud Fecha de creaciรณn del registro Identificador de la tarea

CONSORCIO CLÍNICA SANTIAGO CIA. LTDA.

SISTEMA DE GESTIÓN DE PROYECTOS

MANUAL TÉCNICO SGP

ÍNDICE I.

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

II. FUNCIONES DEL SISTEMA .................................................................................. 2 2.1 INICIAR SESIÓN. ........................................................................................................... 2 2.2 PERFIL .......................................................................................................................... 3 2.2.1 Datos Personales ...................................................................................................... 4 2.2.2 Cambiar Contraseña ................................................................................................. 5 2.3 PARTICIPANTES ............................................................................................................ 6 2.3.1 Registrar Participante ............................................................................................... 6 2.3.2 Desactivar Participante ............................................................................................ 8 2.3.3 Activar Participante ................................................................................................. 9 2.3.4 Ver Participantes .................................................................................................... 10 2.4 ROLES ........................................................................................................................ 11 2.4.1 Crear Roles............................................................................................................. 11 2.4.2 Desactivar Roles .................................................................................................... 12 2.4.3 Activar Roles ......................................................................................................... 13 2.4.4 Ver Roles ............................................................................................................... 13 2.5 RECURSOS .................................................................................................................. 14 2.5.1 Crear Recursos ....................................................................................................... 14 2.5.2 Desactivar Recursos ............................................................................................... 14 2.5.3 Activar Recursos .................................................................................................... 15 2.5.4 Ver Recursos .......................................................................................................... 16

2.6 PROYECTOS ............................................................................................................... 17 2.6.1 Crear Proyectos ..................................................................................................... 17 2.6.2 Asignar Jefe de Proyecto ....................................................................................... 17 2.6.3 Cancelar Proyectos ................................................................................................ 19 2.6.4 Solicitudes ............................................................................................................. 19 2.6.5 Reporte General ..................................................................................................... 20 2.6.6 Reporte Detallado .................................................................................................. 21 2.7 FORO.. ....................................................................................................................... 22 2.7.1 Nuevo Tema .......................................................................................................... 22 2.7.2 Mensaje.................................................................................................................. 23 2.8 WIKI.. ........................................................................................................................ 24 2.9 CORREO ..................................................................................................................... 24

INTRODUCCIร N

El presente documento describe la funcionalidad del Sistema Gestiรณn de Proyectos, el cual estรก desarrollado en entorno web, permite al usuario interactuar con el mismo de manera fรกcil e intuitiva. El sistema permite crear nuevos usuarios, crear proyectos, asignar los respectivos participantes y estos a su vez reportar su avance de tareas de acuerdo a sus respectivos roles, ademรกs de contar con un foro y una wiki colaborativa.

II.

FUNCIONES DEL SISTEMA

SUPER USUARIO

2.1Iniciar Sesión. Al acceder al sistema se visualiza la siguiente pantalla en la cual se solicita al usuario ingresar los datos para autenticarlos e ingresar al sistema.

Pasos 1. Usuario: Ingresar correctamente el respectivo usuario 2. Contraseña: Ingresar correctamente la respectiva contraseña Si los datos están correctos se muestra la siguiente pantalla.

3 Excepciones: En caso de que el usuario olvide su contraseña, puede dar clic en “Olvidé Mi Contraseña” y se muestra la siguiente pantalla. Debe ingresar su usuario y dar clic en buscar.

Debe responder una pregunta de seguridad.

Una vez completado el sistema le asigna una contraseña por defecto, al ingresar de nuevo debe cambiar su contraseña.

2.2Perfil

Al acceder a perfil podrá modificar sus datos personales o la contraseña.

2.2.1 Datos Personales

Dar clic en datos personales y a continuación se despliegan los datos personales del usuario.

Dar clic sobre el ícono de lápiz se despliega el formulario de modificación de acuerdo al que haya elegido.

Al finalizar de modificar dar clic en el botón aceptar para guardar la información.

2.2.2 Cambiar Contraseña

Dar clic en Cambiar Contraseña y a continuación se despliegan el formulario de modificación.

Ingresar la contraseña actual y luego la nueva contraseña y su confirmación, finalmente dar clic en aceptar. En caso que las contraseñas no coincidan se muestra un mensaje de error. Luego de cambiar la contraseña debe responder las preguntas de seguridad.

2.3Participantes Al seleccionar “Participantes” del menú principal se despliega un submenú, el cual consta de: Registrar, Activar, Desactivar y Ver Participante.

2.3.1 Registrar Participante Dar clic en “Registrar Participante” y a continuación se despliega el formulario en el cual debe llenar los campos respectivos, el usuario y contraseña se generan solos, el

7 usuario está formado por la primera letra del nombre seguido del primer apellido y la contraseña generada es el número de cédula.

En caso de que no exista en el listado el departamento al que pertenece el nuevo participante dar clic en el ícono de “más” que se encuentra junto al campo departamento. Se despliega un formulario adicional dentro de la misma pantalla en el cual debe ingresar el nuevo departamento y dar clic en el botón CREAR.

2.3.2 Desactivar Participante Dar clic en Desactivar Participante y a continuación se despliega el formulario de búsqueda en el cual puede buscar de dos formas: a. Pulsando el botón con ícono de lupa: Se muestran todos los participantes en estado activo. Para desactivar un usuario, dar clic en el ícono de bote de basura.

Una vez seleccionado, aceptar el mensaje de confirmación

b. Ingresando el usuario: Ingresar el usuario que desea buscar y luego dar clic en el botón con ícono de lupa. Para desactivar un usuario, dar clic en el ícono de bote de basura.

Una vez seleccionado, aceptar el mensaje de confirmación

2.3.3 Activar Participante Dar clic en Activar Participante y a continuación se despliega el formulario de búsqueda en el cual puede buscar de dos formas: a. Pulsando el botón con ícono de lupa: Se muestran todos los participantes en estado activo. Para activar un usuario, dar clic en el ícono de visto.

10 b. Ingresando el usuario: Ingresar el usuario que desea buscar y luego dar clic en el botón con ícono de lupa. Para activar un usuario, dar clic en el ícono de visto.

Una vez seleccionado, aceptar el mensaje de confirmación

2.3.4 Ver Participantes Dar clic sobre Ver Participante y a continuación se despliega el reporte de los participantes en formato .pdf. Puede descargarlo dando clic sobre el ícono

2.4Roles Al seleccionar “Roles” del menú principal se despliega un submenú, el cual consta de: Crear, Activar, Desactivar y Ver Roles.

2.4.1 Crear Roles Dar clic en Crear Rol y a continuación se despliega el formulario en el cual debe llenar los campos respectivos: Nombre del Rol y seleccionar el Departamento.

En caso de que no haya en el listado el departamento, puede crearlo dando clic sobre el ícono de “+” y a continuación se despliega el formulario para el nuevo departamento. En el cual debe completar el campo respectivo y dar clic en Crear.

2.4.2 Desactivar Roles Dar clic en desactivar roles se despliega la tabla con los roles creados que se encuentran en estado activo, para desactivar debe dar clic en el Ăcono de bote de basura.

Para completar el proceso debe aceptar el mensaje de confirmaciĂłn.

2.4.3 Activar Roles Dar clic en Activar Roles se despliega la tabla con los roles creados que se encuentran en estado activo, para activar debe dar clic en el ícono de visto.

Para completar el proceso debe aceptar el mensaje de confirmación.

2.4.4 Ver Roles Dar clic sobre Ver Roles y a continuación se despliega el reporte de los roles en formato .pdf. Puede descargarlo dando clic sobre el ícono

2.5Recursos Al seleccionar “Recursos” del menú principal se despliega un submenú, el cual consta de: Crear, Activar, Desactivar y Ver Recurso.

2.5.1 Crear Recursos Dar clic en Crear Recursos y a continuación se despliega el formulario en el cual debe llenar los campos respectivos: Nombre del Recurso y seleccionar el Departamento y agregar una descripción.

2.5.2 Desactivar Recursos Dar clic en Desactivar Recursos, se despliega la tabla con los recursos creados que se encuentran en estado activo, para desactivar debe dar clic en el ícono de bote de basura.

Para completar el proceso debe aceptar el mensaje de confirmación.

Excepción: En caso de que el recurso esté en un proyecto que se encuentre en curso se muestra un mensaje de alerta que no puede ser desactivado.

2.5.3 Activar Recursos Dar clic en Activar Recursos se despliega la tabla con los recursos creados que se encuentran en estado activo, para activar debe dar clic en el ícono de visto.

16 Para completar el proceso debe aceptar el mensaje de confirmación.

2.5.4 Ver Recursos Dar clic sobre Ver Recursos y a continuación se despliega el reporte de los recursos en formato .pdf. Puede descargarlo dando clic sobre el ícono

2.6Proyectos Al seleccionar “Proyectos” del menú principal se despliega un submenú, el cual consta de: Crear, Cancelar, Solicitudes, Reporte General y Detallado de Proyectos.

2.6.1 Crear Proyectos Dar clic en Crear Proyectos y a continuación se despliega el formulario en el cual debe llenar los campos respectivos: Nombre del Proyecto, seleccionar el Departamento y designar el presupuesto.

2.6.2 Asignar Jefe de Proyecto Para asignar el jefe de proyecto puede hacerlo de dos formas:

18 a. Buscar el usuario

b. Seleccionar de la lista

Una vez seleccionado el Jefe de Proyecto dando clic en el ícono de “visto”, debe aceptar el mensaje de confirmación.

2.6.3 Cancelar Proyectos Dar clic en Cancelar Proyectos y a continuación se despliega la lista de todos los proyectos creados, en la cual debe elegir el proyecto a cancelar dando clic en el ícono de “visto”.

Una vez seleccionado el proyecto debe ingresar el motivo por el cual va a ser cancelado. Dar clic en aceptar para confirmar la cancelación de proyecto.

2.6.4 Solicitudes Dar clic en Solicitudes y a continuación se despliega las dos opciones, debe elegir una de ellas y dar clic en aceptar.

2.6.5 Reporte General Dar clic en Reporte General y a continuaciĂłn se despliega el formulario en el cual debe elegir el tipo de proyecto y el rango de fecha que desea generar.

Una vez elegido y llenado los campos se genera el reporte en pdf. Puede descargarlo dando clic sobre el Ăcono

2.6.6 Reporte Detallado Dar clic en Reporte Detallado y a continuaciĂłn se despliega el formulario en el cual debe elegir el tipo de proyecto y el rango de fecha que desea generar.

Una vez elegido y llenado los campos se genera el reporte en pdf. Puede descargarlo dando clic sobre el Ăcono

2.7Foro Al seleccionar “Foro” del menú principal se despliega la tabla que contiene los temas que se están tratando en el foro.

2.7.1 Nuevo Tema Dar clic en el ícono de “+”, se despliega el formulario de competición, debe completar los campos de: Título del nuevo tema y el respectivo mensaje.

2.7.2 Mensaje Seleccionar el tema en el que va a agregar el nuevo mensaje dando clic en el Ăcono de flecha de la tabla principal de foro.

Se despliega la tabla con el tema seleccionado y los mensajes que han colocado los demĂĄs participantes, ingresar el mensaje que desea y dar clic en el botĂłn enviar.

2.8Wiki Al seleccionar “Wiki” del menú principal se despliega las carpetas con los nombres de los proyectos para visualizar que documentación han subido los participantes. Debe Seleccionar la carpeta y dar clic sobre el archivo que desea abrir para que se descargue.

2.9Correo Dar clic sobre la opción Correo del menú principal y a continuación se despliega el formulario en el cual debe completar los datos requeridos y dar clic en enviar.

Anexo 7. Manual de Usuario

CONSORCIO CLÍNICA SANTIAGO CIA. LTDA.

SISTEMA DE GESTIÓN DE PROYECTOS

MANUAL DE USUARIO SGP

ÍNDICE I.

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

II. FUNCIONES DEL SISTEMA.................................................................................. 2 2.1 INICIAR SESIÓN. ........................................................................................................... 2 2.2 PERFIL ......................................................................................................................... 4 2.2.1 Datos Personales ...................................................................................................... 4 2.2.2 Cambiar Contraseña ................................................................................................ 6 USUARIO AVANZADO ................................................................................................. 7 2.3 INICIO .......................................................................................................................... 7 2.4 PROYECTOS ................................................................................................................. 8 2.4.1 Completar Datos ...................................................................................................... 8 2.4.2 Agregar Recursos .................................................................................................... 8 2.4.3 Distribuir Presupuesto ........................................................................................... 10 2.4.4 Asignar Participantes al Proyecto .......................................................................... 11 2.4.5 Asignar Roles a los Participantes .......................................................................... 12 2.4.6 Asignar Tareas a los Participantes ......................................................................... 13 2.4.7 Modificar Tareas.................................................................................................... 15 2.4.8 Quitar Recursos ..................................................................................................... 16 2.4.9 Quitar Participantes ............................................................................................... 17 2.4.10 Modificar Presupuesto ......................................................................................... 18 2.4.11 Modificar Proyecto .............................................................................................. 19 2.4.12 Extender Plazo ..................................................................................................... 19

2.4.13 Avance de Proyecto ............................................................................................. 20 2.4.14 Aprobar tareas...................................................................................................... 21 2.4.15 Finalizar Proyecto ................................................................................................ 21 2.4.16 Cronograma ......................................................................................................... 22 2.4.17 Solicitudes ........................................................................................................... 22 2.4.18 Reportes ............................................................................................................... 23 USUARIO BÁSICO ....................................................................................................... 25 2.5 Inicio…. .................................................................................................................... 25 2.6 Tareas….................................................................................................................... 25 2.6.1 Subtareas ................................................................................................................ 26 2.6.2 Crear Subtareas ...................................................................................................... 26 2.6.3 Avance de Tareas................................................................................................... 27 2.6.4 Cronograma ........................................................................................................... 28 2.6.5 Finalizar Tarea ....................................................................................................... 28 2.6.6 Extender Plazo ....................................................................................................... 29 2.7 FORO ........................................................................................................................ 30 2.7.1 Nuevo Tema .......................................................................................................... 30 2.7.2 Mensaje.................................................................................................................. 31 2.8 WIKI ......................................................................................................................... 32 2.9 CORREO .................................................................................................................. 32

III.

INTRODUCCIร N

El presente documento describe la funcionalidad del Sistema Gestiรณn de Proyectos, el cual estรก desarrollado en entorno web, permite al usuario interactuar con el mismo de manera fรกcil e intuitiva. El entorno de usuario avanzado permite completar datos del proyecto asignado, agregar participantes al respectivo proyecto y a su vez asignar tareas a los mismos, enviar notificaciones, solicitar aplazamiento del proyecto ademรกs tiene acceso al foro y la wiki. El entorno del usuario final permite ingresar el avance de sus tareas en los diferentes proyectos que se encuentre, solicitar aplazamiento de tareas y tiene acceso al foro y la wiki

IV.

FUNCIONES DEL SISTEMA

4.1Iniciar Sesión. Al acceder al sistema se visualiza la siguiente pantalla en la cual se solicita al usuario ingresar los datos para autenticarlos e ingresar al sistema.

Pasos 3. Usuario: Ingresar correctamente el respectivo usuario 4. Contraseña: Ingresar correctamente la respectiva contraseña Si el usuario tiene más de un rol debe elegir con qué rol desea ingresar.

3 La primera vez que inicie sesión el usuario se mostrará la siguiente pantalla en el cual se da la bienvenida y se pregunta si desea conservar la contraseña por defecto o cambiar por una nueva.

Excepciones: En caso de que el usuario olvide su contraseña, puede dar clic en “Olvidé Mi Contraseña” y se muestra la siguiente pantalla. Debe responder una pregunta de seguridad.

Una vez completado el sistema le asigna una contraseña por defecto, al ingresar de nuevo debe cambiar su contraseña.

4.2Perfil

Al acceder a perfil podrá modificar sus datos personales o la contraseña.

4.2.1 Datos Personales

Dar clic en datos personales y a continuación se despliegan los datos personales del usuario.

5 Dar clic sobre el ícono de lápiz se despliega el formulario de modificación de acuerdo al que haya elegido.

Al finalizar de modificar dar clic en el botón aceptar para guardar la información.

4.2.2 Cambiar Contraseña

Dar clic en Cambiar Contraseña y a continuación se despliegan el formulario de modificación.

USUARIO AVANZADO 4.3Inicio Al iniciar sesiรณn con el rol Jefe de Proyecto se muestra en el inicio todos los proyectos que tiene asignado dicho usuario.

4.4Proyectos 4.4.1 Completar Datos Dar clic en el nombre del Proyecto y a continuación se despliega el formulario en el cual debe llenar los campos respectivos, el alcance, el tipo y el presupuesto del proyecto y las respectivas fechas de inicio y culminación.

Una vez completado los campos dar clic en Guardar para pasar al siguiente paso.

4.4.2 Agregar Recursos Se muestra la tabla con los recursos que pertenecen al departamento que está designado el Proyecto. Debe elegir los que va a usar en su proyecto dando clic en el ícono de visto.

Una vez seleccionado, aceptar el mensaje de confirmación.

Una vez añadidos todos los recursos que desee al proyecto dar clic en el botón aceptar para pasar al siguiente paso.

4.4.3 Distribuir Presupuesto Se muestra la tabla con los recursos asignados en el paso anterior para designar la cantidad a cada recurso.

Nota: En caso de que al asignar el valor a cada recurso sobrepase el valor establecido al principio se mostrarรก un mensaje de error, para que pueda redistribuirlo.

4.4.4 Asignar Participantes al Proyecto Se muestra la tabla con los participantes disponibles del departamento para agregarlos, puede seleccionar directamente los que aparecen dando clic en el ícono de visto o a su vez puede buscar dentro de la tabla en el cuadro de texto que se muestra.

Una vez seleccionado, aceptar el mensaje de confirmación.

Una vez añadidos todos los participantes que desee al proyecto dar clic en el botón aceptar para pasar al siguiente paso. Nota: El Jefe del Proyecto puede elegirse a sí mismo y asignarse un rol adicional.

4.4.5 Asignar Roles a los Participantes Se muestra la tabla con los roles del departamento para agregarlos, debe seleccionar un rol y luego clic en el ícono de “ojo” y se despliega a la derecha los participantes agregados anteriormente para seleccionar a cuántos de ellos va a asignar el mismo rol.

Para seleccionar solo dar clic en el check del costado del participante.

Una vez seleccionados todos los participantes dar clic en Aceptar, para continuar con el siguiente rol. Al finalizar de asignar los roles a todos dar clic en el botón continuar

4.4.6 Asignar Tareas a los Participantes Se muestra la tabla con los participantes agregarlos al proyecto, para asignar las tareas debe seleccionar uno y luego clic en el ícono de “ojo”.

Se despliega el formulario para completar las tareas que vaya a asignar. Una vez que agregue todas las tareas al participante dar clic en volver para continuar con el siguiente.

Una vez completadas las tareas de cada participante dar clic en finalizar.

Nota: En caso de que desee agregar mĂĄs participantes, recursos o tareas puede acceder al menĂş y seguir el mismo procedimiento detallado anteriormente.

4.4.7 Modificar Tareas Dar clic en Proyectos y seleccionar la opciĂłn Modificar tareas, se despliega los participantes del proyecto. Debe seleccionar uno para continuar con el proceso.

Se despliega la tabla con las tareas del participante, debe seleccionarla para modificar.

Al seleccionar la tarea se despliega el formulario de modificaciรณn debe completar los campos requeridos.

4.4.8 Quitar Recursos Dar clic en Proyectos y seleccionar la opciรณn Quitar Recursos, se despliega los recursos del proyecto. Seleccionar el recurso a eliminar del proyecto. Y luego aceptar el mensaje de confirmaciรณn.

4.4.9 Quitar Participantes Dar clic en Proyectos y seleccionar la opciรณn Quitar Participantes, se despliega los participantes del proyecto. Seleccionar el participante a eliminar.

18 Una vez seleccionado el participante se despliega la siguiente pantalla en la cual debe asignar las tareas a otro participante

Seleccionado el participante a remplazarlo debe aceptar el mensaje de confirmación.

4.4.10 Modificar Presupuesto Dar clic en Proyectos y seleccionar la opción Modificar Presupuesto, se despliega el formulario con los recursos del proyecto. Editar los recursos deseados (Se envía una solicitud al Administrador del Sistema para su aprobación).

4.4.11 Modificar Proyecto Dar clic en Proyectos y seleccionar la opci贸n Modificar Proyecto, se despliega el formulario con los datos del proyecto. Debe seleccionar el campo a modificar y luego aceptar el mensaje de confirmaci贸n.

4.4.12 Extender Plazo Dar clic en Proyectos y seleccionar la opci贸n Extender Plazo, se despliega el formulario en el cual debe completar la fecha de plazo y el motivo por el cual lo solicita. Esta opci贸n solo se permite una vez en cada proyecto.

4.4.13 Avance de Proyecto Dar clic en Proyectos y seleccionar la opciรณn Avance de Proyecto, se despliega una tabla con todas las tareas de los participantes y el estado en que se encuentran para su posterior aprobaciรณn.

4.4.14 Aprobar tareas Una vez que los participantes han finalizado la tarea debe aprobarla para determinar que ya está finalizada y no tendrá más cambios.

4.4.15 Finalizar Proyecto Una vez que todas las tareas hayan sido aprobadas puede finalizar el proyecto dando clic en el botón “Finalizar” y luego aceptar el mensaje de confirmación.

4.4.16 Cronograma Seleccionar Cronograma del menĂş principal y se despliega el calendario con las tareas de cada participante en su inicio y fin.

4.4.17 Solicitudes Seleccionar solicitudes del menĂş principal y se despliegan las solicitudes de aplazamiento de fecha por parte de los participantes en caso de haberlas estas tambiĂŠn solo pueden hacerse una vez durante el curso del proyecto.

Seleccionar la solitud y a continuaciรณn se despliega el motivo por el cual se desea aplazar la tarea y la nueva fecha a finalizar. Puede Aceptar la solicitud o a su vez denegar la misma.

4.4.18 Reportes 4.4.18.1 Participantes Dar clic en Reportes y seleccionar Participantes y se genera el reporte en formato .pdf.

4.4.18.2 Presupuesto Dar clic en Reportes y seleccionar Presupuesto y se genera el reporte en formato .pdf.

Nota: Para generar los Reportes General y Detallado de los Proyectos se lo genera de la misma forma que los mencionados con anterioridad, solo que en estos debe seleccionar un Rango de Fechas y el tipo de proyecto.

USUARIO Bร SICO 4.5Inicio Al iniciar sesiรณn con el cualquier otro rol diferente a Jefe de Proyecto se muestra en el inicio todos los proyectos que tiene asignado dicho usuario.

4.6Tareas Al dar clic sobre el nombre del Proyecto se muestran todas las tareas que tiene asignadas.

4.6.1 Subtareas Para presentar o detallar avances de la tarea dar clic sobre la tarea y a continuación se muestra las subtareas. En este espacio puede agregar pequeños avances y a su vez subir documentos si lo desea que luego será mostrado en la Wiki.

4.6.2 Crear Subtareas Seleccionar el ícono de “+” dentro de subtareas.

27 Llenar los campos requeridos

4.6.3 Avance de Tareas

En caso de querer subir un documento en la sub tarea, seleccionar el ícono “subir” y proceder a hacerlo o a su vez puede ingresar más subtareas.

4.6.4 Cronograma Dar clic en la opción Cronograma del menú principal y a continuación se despliega el calendario con las tareas que tiene asignadas.

4.6.5 Finalizar Tarea Seleccionar “Finalizar Tarea” del menú principal a continuación se despliega la siguiente pantalla en la cual puede subir más documentos a la Wiki. Para finalizar la tarea dar clic en el botón finalizar.

29 Aceptar el mensaje de confirmaciĂłn

4.6.6 Extender Plazo Dar clic en Extender Plazo del menĂş principal y a continuaciĂłn se despliega el formulario en el cual debe completar los campos requeridos: motivo de aplazamiento y fecha.

4.7FORO Al seleccionar “Foro” del menú principal se despliega la tabla que contiene los temas que se están tratando en el foro.

4.7.1 Nuevo Tema Dar clic en el ícono de “+”, se despliega el formulario de competición, debe completar los campos de: Título del nuevo tema y el respectivo mensaje.

4.7.2 Mensaje Seleccionar el tema en el que va a agregar el nuevo mensaje dando clic en el Ăcono de flecha de la tabla principal de foro.

Se despliega la tabla con el tema seleccionado y los mensajes que ha colocado los demĂĄs participantes, ingresar el mensaje que desea y dar clic en el botĂłn enviar.

4.8WIKI Dar clic sobre Wiki y se desplegaran los documentos subidos dentro del proyecto

4.9CORREO Dar clic sobre la opción Correo del menú principal y a continuación se despliega el formulario en el cual debe completar los datos requeridos y dar clic en enviar.

Anexo 8. Cronograma

Anexo 9. Actas De Reuniones

Anexo 10. Actas de Pruebas del Sistema.

Anexo 11. Carta de Asignaciรณn de Proyecto

Anexo 12. Carta de Impacto