anÁlisis, diseÑo, desarrollo e implantaciÓn del mÓdulo de...

ANÁLISIS, DISEÑO, DESARROLLO E IMPLANTACIÓN DEL MÓDULO DE PROYECTOS EN LA PLATAFORMA ICARO DE LA OFICINA ASESORA DE

PLANEACIÓN Y CONTROL DE LA UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

AUTORES: IVAN DAVID GUALTERO SALAMANCA 20072020108 KATHERINE STELLA ZUBIETA VIVAS 20072020099

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA INGENIERÍA DE SISTEMAS

BOGOTÁ D.C. 2015

ANÁLISIS, DISEÑO, DESARROLLO E IMPLANTACIÓN DEL MÓDULO DE PROYECTOS EN LA PLATAFORMA ICARO DE LA OFICINA ASESORA DE

PLANEACIÓN Y CONTROL DE LA UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

AUTORES: IVAN DAVID GUALTERO SALAMANCA 20072020108 KATHERINE STELLA ZUBIETA VIVAS 20072020099

PROYECTO DE GRADO

DIRECTOR: ING. FERNANDO MARTÍNEZ RODRÍGUEZ MSc.

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA INGENIERÍA DE SISTEMAS

BOGOTÁ D.C. 2015

RESUMEN

En este documento se encontrará una descripción del problema sobre la administración y seguimiento de los proyectos de inversión de la Universidad Distrital Francisco José de Caldas y como se abordara la solución según las tecnologías y metodología utilizada por el sistema general de información Icaro del cual el MP (Módulo de Proyectos) hará parte. Inicialmente se presentará la definición general del problema a tratar proveniente de la información suministrada por la OAPC (Oficina Asesora de Planeación y Control) y los usuarios en los distintos roles del sistema actual, con el fin de identificar las necesidades del sistema, las reglas del negocio, la presentación y lógica que se debe mantener frente a los usuarios con el fin de generar la información base de la investigación y necesaria en las primeras fases de la metodología de desarrollo de software Open-Up de la OAS (Oficina Asesora de Sistemas ). En el transcurso de las fases de la metodología se encontrarán y generaran los requerimientos funcionales de la aplicación, el modelaje UML que describe visualmente al usuario la funcionalidad que obtendrá en el módulo de proyectos y a los desarrolladores la estructuración y comportamiento que el Modulo de proyectos debe lograr. Finalmente, con la implementación de los modelos se generará el código fuente del Módulo acompañado de la respectiva documentación técnica y de usuario y los soportes estipulados por la metodología Open-Up OAS.

INTRODUCCION Un aspecto primordial para la Universidad Distrital Francisco José de Caldas, es la forma de administrar sus proyectos de inversión, con el fin de mantener un control interno sobre el ciclo de vida y la distribución de sus recursos, sujetos a la evaluación y aprobación por parte de las diferentes dependencias hasta llegar al ente máximo de la Universidad: el Consejo Superior Universitario. Actualmente, la Universidad realiza los procesos de seguimiento a los proyectos en todas sus fases de forma poco sistematizada, lo que genera algunos retrasos en la entrega de informes a los usuarios interesados. Es por ello que se encuentra en construcción el Sistema de Información General para la planeación, gestión y seguimiento “Icaro” para la Universidad Distrital, donde uno de sus módulos estará enfocado a la administración y seguimiento del ciclo de vida de los proyectos de inversión, los cuales involucran los recursos financieros de la Institución. Con el fin de aplicar los conocimientos adquiridos en la carrera de Ingeniería de Sistemas y contribuir a la institución en la reducción de tiempo, manipulación manual y costos, se va a diseñar, desarrollar e implantar el módulo para la administración de los proyectos e implícitamente su BP (Banco de Proyectos) y por esta razón, se continuará con la arquitectura ya implementada en la plataforma existente para ofrecer seguridad, confiabilidad, eficiencia y escalabilidad en el manejo de la información a bajo costo. Se usará la metodología Open-Up de la Oficina Asesora de Sistemas de la Universidad Distrital Francisco José de Caldas para el desarrollo del módulo. Además será complementada con los conocimientos adquiridos en el transcurso de la carrera de Ingeniería de Sistemas, con lo que se espera brindar una herramienta a la institución para sistematizar y automatizar su proceso de administración de sus proyectos a bajo costo, intuitiva la usuario y eficiente. Además, se deja abierta la posibilidad de integrar nuevas funcionalidades, para ofrecer soluciones a otros requerimientos que presente la institución, para promover la utilización de herramientas de desarrollo de software libre como lo es el lenguaje Java y el motor de Base de Datos PostgreSQL, y aportar documentación sobre la combinación, implementación y funcionamiento de estas, para brindar una base de conocimientos guías para desarrollos futuros en diferentes contextos.

Contenido

RESUMEN INTRODUCCION 1 PLANTEAMIENTO DEL PROBLEMA ....................................................................................................8

1.1 DESCRIPCIÓN DEL PROBLEMA ...................................................................................................8

1.2 FORMULACIÓN DEL PROBLEMA ................................................................................................8

2 JUSTIFICACIÓN ..................................................................................................................................9

3 OBJETIVOS ...................................................................................................................................... 10

3.1 OBJETIVO GENERAL ................................................................................................................. 10

3.2 OBJETIVOS ESPECÍFICOS .......................................................................................................... 10

4 MARCO REFERENCIAL .................................................................................................................... 11

4.1 ANTECEDENTES O ESTADO DEL ARTE ..................................................................................... 11

4.1.1 Históricos ............................................................................................................................. 11

4.1.2 Legales .................................................................................................................................. 12

4.1.3 Herramientas similares ........................................................................................................ 16

4.2 MARCO TEÓRICO .................................................................................................................... 20

4.2.1 Icaro ..................................................................................................................................... 20

4.2.2 Proyecto ........................................................................................................................ 21

4.2.3 Proyecto de inversión .................................................................................................. 21

4.2.4 Proyecto de funcionamiento ...................................................................................... 22

4.2.5 Presupuesto ................................................................................................................. 22

4.2.6 Banco de proyectos .................................................................................................... 22

4.2.7 Plan Estratégico de Desarrollo 2007 – 2016 .......................................................... 23

4.2.8 Proyecto Universitario Institucional (PUI) ................................................................ 23

4.2.9 Plan de Desarrollo Distrital ........................................................................................ 24

4.2.10 Oficina Asesora De Planeación y Control (OAPC) ............................................... 24

4.2.11 Unidad Académica Administrativa (UAA) .............................................................. 24

4.2.12 OPENUP/OAS – metodología OPENUP según Oficina Asesora de Sistemas Universidad

Distrital - ........................................................................................................................................ 25

5 MARCO METODOLOGICO .............................................................................................................. 34

5.1 METODOLOGIA DE LA INVESTIGACION .................................................................................. 34

5.1.1 Tipo de estudio ....................................................................................................... 34

5.1.2 Método y/o diseño de la investigación ................................................................ 34

5.1.3 Participantes ........................................................................................................... 34

5.1.4 Instrumentos y equipos ......................................................................................... 37

5.1.5 Procedimiento ......................................................................................................... 37

5.2 METODOLOGIA DE LA INGENIERIA ......................................................................................... 38

5.2.1 DESCRIPCIÓN DE LA METODOLOGÍA EN CONTEXTO ........................................................... 38

5.2.1.1 Equipo de gestión ................................................................................................... 38

5.2.1.3 Equipo de desarrollo ................................................................................................. 39

5.2.1.4 Fases del proyecto.................................................................................................... 41

6 RESULTADOS Y DISCUSIÓN ............................................................................................................ 46

6.1 DESCRIPCIÓN DEL MÓDULO ................................................................................................... 46

6.2 Definición Del Producto A Obtener ............................................................................... 47

6.3 REQUERIMIENTOS ................................................................................................................... 50

6.3.1 Requerimientos Funcionales ...................................................................................... 50

6.3.2 Requerimientos No Funcionales ................................................................................ 54

6.3.3 Requerimientos De Interfaces De Usuario ............................................................... 54

6.3.4 Requerimientos De Persistencia ................................................................................ 54

6.4 MODELADO UML (UNIFIED MODELING LANGUAGE) ............................................................. 55

6.4.1 Notación De Identificadores........................................................................................ 55

6.4.2 Estructura planteada .................................................................................................... 55

6.4.3 Definición capa de atributos. ..................................................................................... 55

6.4.4 Definición capa de métodos. ...................................................................................... 56

6.4.5 Diagrama de Clases ................................................................................................... 56

6.4.6 Diccionario de clases ................................................................................................... 56

6.4.7 Casos De Uso ............................................................................................................... 56

6.4.8 Especificación De Casos Uso En Formato Expandido .......................................... 57

6.4.8.3 Escenario: Coordinador OCBPUD ......................................................................... 69

6.4.9 Bocetos Visuales De Interfaz Gráfica De Usuario .................................................. 77

6.5.1 Modelo Relacional De La Base De Datos ................................................................ 78

6.5.2 Diccionario de datos .................................................................................................... 80

6.8 CODIGO DEL DESARROLLO ...................................................................................................... 86

7. CONCLUSIONES ............................................................................................................................. 89

8. RECOMENDACIONES ..................................................................................................................... 90

9. BIBLIOGRAFIA Y CIBERGRAFÍA ..................................................................................................... 91

10. ANEXOS (CD) ............................................................................................................................... 93

8

1 PLANTEAMIENTO DEL PROBLEMA

1.1 DESCRIPCIÓN DEL PROBLEMA La ley 38 del 21 de abril de 1989 crea el banco de proyectos de inversión nacional y en el transcurso de los años ésta ha sido modificada gradualmente, es el caso del decreto 1363 del 12 de Julio de 2000, el cual reglamenta que todas las entidades públicas deben manejar su propio banco de proyectos en todos sus niveles y periódicamente deben entregar informes de la gestión de los mismos a través de la herramienta computacional desarrollada por el Departamento Nacional de Planeación, es por ello que la Universidad Distrital reporta sus informes ante el Distrito pero no posee una herramienta que le permita realizar el control y seguimiento interno en tiempo real de los proyectos en gestación y ejecución. Actualmente, los procesos de inscripción, registro, actualización, reportes y evaluación de los proyectos que forman parte del Banco de Proyectos de la Universidad, se realizan mediante archivos planos (formatos de word y excel) lo que hace que la manipulación de la información en las diferentes etapas del ciclo de vida de estos consuma un tiempo de respuesta el cual aunque es bueno puede mejorar. Los proyectos están articulados con las políticas del Plan Estratégico de Desarrollo de la Universidad; mensual y trimestralmente informes basados en los avances de los proyectos deben ser reportados tanto a la OAPC para controles y evaluaciones internas como para alimentar el aplicativo Distrital. Al estar manejados los proyectos en estos formatos, limita realizar un análisis en tiempo real del estado de avance de los proyectos, además del tiempo de respuesta en la búsqueda de información sobre ellos tanto a nivel individual como general. La Oficina Asesora de Planeación y Control tiene a cargo el desarrollo de los módulos correspondientes a sus funciones en la plataforma Icaro, uno de ellos es el módulo de Proyectos (MP), el cual permitirá sistematizar y automatizar los procesos de inscripción, registro, evaluación, seguimiento, control y monitoreo de los proyectos de inversión de la institución, brindando información de manera ágil, eficiente y segura en tiempo real.

1.2 FORMULACIÓN DEL PROBLEMA ¿Cómo optimizar el sistema de inscripción, actualización, monitoreo, seguimiento y evaluación en tiempo real, de manera ágil, eficiente y oportuna de los proyectos de inversión de la Universidad Distrital Francisco José de Caldas?

9

2 JUSTIFICACIÓN El análisis, diseño, desarrollo e implantación del Módulo de Proyectos para la plataforma Icaro de la OAPC, se hace para sistematizar y automatizar procesos y así ayudar a los responsables de cada nivel a registrar la información correspondiente y elaborar los respectivos registros de manera ágil, segura, eficiente y confiable, para evitar al máximo la manipulación manual de información, que en ocasiones conlleva a errores humanos. Además, reducir el tiempo de entrega, construcción y consolidación de reportes ante evaluadores y directivas para su aprobación y difusión. Con el objetivo de mejorar la eficiencia administrativa y dar un uso adecuado a los recursos públicos, se optimizará el BP para la administración de los proyectos de inversión de la Universidad Distrital a cargo de la OAPC, para esto se aplicarán los conocimientos adquiridos en las líneas de profundización elegidas en la carrera, y se realizará la entrega del módulo que beneficie a las personas que interactúen con éste, así como a la misma institución ya que el diseño permite la creación de nuevas funcionalidades que complemente el módulo. Cabe agregar que el MP le permitirá ahorrar tiempo y recursos tanto materiales como financieros a la institución, ya que éste tiene como base el software libre, lo cual brinda el beneficio de poder modificarlo, mediante integración de soluciones a nuevas necesidades de la institución a muy bajo costo, con gran aporte de información para análisis futuros y reutilizar los datos existentes provenientes de la integración de la información de las áreas de la institución, sin atarse al pago de licencias de alto costo de software privativo. Finalmente, para obtener un buen desempeño y rendimiento que responda a la necesidad, se generará la documentación sobre el modelo, integración e implementación del lenguaje de programación Java y el motor de Base de Datos PostgresSQL, se tomará en cuenta la documentación existente sobre estas tecnologías, proyectos relacionados, normatividad legal vigente, metodología de desarrollo de productos de software en la Universidad Distrital y los requerimientos básicos de la institución en el manejo y administración de los proyectos en cada una de sus fases.

10

3 OBJETIVOS

3.1 OBJETIVO GENERAL Analizar, diseñar, desarrollar e implantar el Módulo de Proyectos en la plataforma Icaro de la Oficina Asesora de Planeación y Control de la Universidad Distrital Francisco José de Caldas para automatizar el proceso de inscripción, gestión, actualización y seguimiento de los proyectos de inversión en el sistema.

3.2 OBJETIVOS ESPECÍFICOS Adoptar el método de trabajo del proceso de desarrollo Open-Up/OAS como marco

de trabajo en el análisis, diseño, desarrollo e implantación de productos de software al interior de la Universidad Distrital Francisco José de Caldas.

Construir el Banco de Proyectos de inversión de la Universidad Distrital.

Permitir la formulación y registro de proyectos de inversión en el banco de proyectos de la Universidad Distrital.

Permitir el seguimiento de los cambios en realizados sobre los proyectos de inversión del banco de proyectos de la Universidad Distrital.

Generar reportes en formato ficha EBI-D (Estadística Básica de Inversión Distrital) a nivel individual y de versión de cada proyecto.

Permitir realizar consultas en red de la información de los proyectos de inversión.

Brindar la documentación y capacitación necesaria a los usuarios del sistema para su uso.

Implantar el módulo de proyectos en la plataforma Icaro.

11

4 MARCO REFERENCIAL

4.1 ANTECEDENTES O ESTADO DEL ARTE

4.1.1 Históricos En la Universidad Distrital, la Oficina Asesora de Planeación y Control, continua como lo ha hecho por más de 10 años en la propuesta de aprobación del Banco de Proyectos de la Universidad Distrital, como el conjunto de actividades seleccionadas como viables, previamente evaluadas académica, técnica, financiera económica, social e institucional y ambientalmente, debidamente registradas y sistematizadas por el responsable de cada proyecto. El banco de proyectos responde a lo planteado en la Ley 152 de 1994 ley orgánica del plan de desarrollo o sistema de planeación nacional en donde se delimita los bancos de proyectos como instrumentos de planeación de las entidades públicas. De acuerdo a la ley 489 de 1998, se obliga a la implementación del Sistema de Desarrollo Administrativo (SISTEDA), para el seguimiento al cumplimiento de metas donde se integrará el Plan de Desarrollo Institucional, Banco de Proyectos y el presupuesto articulado con los proyectos en unos tiempos estipulados con el fin de hacer más eficiente la gestión pública a través de la articulación funcional de las entidades. En la Universidad Distrital éste proceso se realizaba mediante archivos planos tales como Excel y Word por medio de flujo gramas para generar reportes para las respectivas instancias encargadas de realizar el seguimiento, sin ningún tipo de unificación donde la manipulación y potestad estaba determinada por el funcionario a cargo. De aquí que, para establecer un control sobre el destino de los recursos, mediante el DECRETO 93 DE 2003 se establece que los proyectos misionales deben ser financiados por el ingreso proveniente de la estampilla. En el año 2001 la Administración Distrital inició el funcionamiento de un aplicativo llamado Sistema de Información de Seguimiento al Plan de Desarrollo (SEGPLAN), para el monitoreo de los lineamiento de los proyectos a las políticas del Plan de Desarrollo Distrital, donde la actualización de la información que alimenta el sistema se hace anualmente, los planes de acción contienen vigencias con un seguimiento mensual, pero la aplicación lo reporta trimestral. Este aplicativo incorpora actualmente a las 45 entidades distritales (Administración Central, Establecimientos Públicos y Empresas Industriales y Comerciales) y tiene como objetivo la implementación en las veinte localidades para articular el proceso de seguimiento de sus planes de desarrollo con el distrito.

12

El monitoreo se hace con base a las metas e indicadores previamente fijados en el plan de desarrollo, el cronograma y ejecución física y financiera de los proyectos de inversión y los planes de acción según el territorio y población beneficiada. El año 2004 se genera la NTCGP 1000:2004 que desarrolla lo ordenado en la Ley 872 de 2003 que obliga la implementación del sistema de gestión de calidad en las entidades públicas. Por esta razón se crea el Sistema de Gestión de Calidad de la Universidad Distrital (SIGUD) el cual está a cargo de la OAPC. En el año 2005 se formula la NTCGP MECI 1000:2005 que reglamenta la implementación del Modelo Estándar de Control Interno en las entidades públicas delimitado por la norma técnica, y en el 2008 se consolida SIGECALIDAD, donde la integración de estos dos, permite la armonización en el 2009 a través de SISTEDA para el seguimiento al cumplimiento de metas reglamentado por la Ley 152/94. Por lo tanto, la Universidad Distrital además de realizar los reportes al Distrito pretende tener un seguimiento interno sobre el ciclo de vida de sus proyectos, para articular las instancias y conocer el escenario futuro. La eficiencia de los proyectos y de la inversión que realice la Universidad, requiere un manejo óptimo que genere retornos positivos social y económicamente, para que esto suceda es necesario adecuar instrumentos de planeación estratégica, programación y ejecución presupuestal, el diseño y desarrollo de un sistema de seguimiento de los recursos que permitirá la evaluación de la gestión por productos, metas y resultados.

4.1.2 Legales El Banco de Proyectos se fundamenta como un instrumento que posibilita la inversión que se financia con recursos institucionales, territoriales, nacionales e internacionales obedeciendo a criterios de eficiencia y rentabilidad social, así la Universidad no esté directamente afectada por la normativa expedida para tales propósitos, es importante soportarse en esta para sustentar la creación del Banco de Proyectos de la Universidad Distrital. La Normativa del Presupuesto General de la Nación en la Ley 38 del 21 de abril de 1989 crea el Banco de Proyectos de Inversión Nacional, asimismo Confía al DNP su diseño, montaje y operación (Art. 32) estableciendo que “en el plan operativo anual de inversiones -POAI- no se podrán incluir proyectos que no hagan parte del Banco de Proyectos de Inversión Nacional (Art. 31) define el Banco de Proyectos de Inversión Nacional (Art. 32). La estructura del Departamento de Planeación Nacional es modificado mediante el Decreto 2410 de octubre 20 de 1989. Creando y asignando funciones a las divisiones de metodologías (Art. 57) y de operación y sistemas (Art. 58) del Banco de Proyectos de Inversión Nacional, las cuales forman parte de la Unidad de Inversiones y Finanzas

13

Públicas. De igual manera el Art. 23 establece que la inversión financiera debe responder a criterios de eficiencia y eficacia.

Mediante la Ley Orgánica del Plan de Desarrollo (Ley 152 de 1994) se instituye que Las entidades territoriales pondrán en funcionamiento sus bancos de proyectos. El Presupuesto General de la Nación mediante el Decreto 841 del 20 de abril de 1990, y reglamentado por la Ley 38 de 1989, en lo referente al Banco de Proyectos de Inversión y otros aspectos generales, como el mismo Art. 3º reglamenta el Banco de Proyectos de Inversión Nacional, asigna al DNP la función de organizar y coordinar una Red Nacional de Bancos de Proyectos, conformada por los bancos de proyectos de inversión de los diferentes niveles territoriales del sector público, tanto centralizado como descentralizado, que reúnan los requisitos necesarios para participar (Art.. 6º.), definiendo y clasificando los proyectos de inversión (Art.. 2º.), de igual forma el Art.. 4º. Faculta al DNP delegar la función de calificación de viabilidad y registro de proyectos en otros organismos o entidades del orden sectorial o territorial, centralizado o descentralizado y define los aspectos de la evaluación (Art. 7º.). Así mismo establece procedimientos y normas sobre metodologías. Se refiere a la asesoría departamental, a los municipios y a la asesoría de los corpes (Art. 20 y 21). La Ley 152 del 15 de julio de 1994: "Ley Orgánica del Plan de Desarrollo". Establece que: Los principios, procedimientos y mecanismos para la elaboración, aprobación, ejecución, seguimiento, evaluación y control de los planes de desarrollo de la nación y de las entidades territoriales. Define el Banco de Programas y Proyectos de Inversión Nacional (Art. 27). Asigna al DNP la función de conceptuar sobre los programas de inversión preparados y evaluados por los Ministerios, Departamentos Administrativos, la Contraloría, la Procuraduría, la Veeduría, la Registraduría, la Fiscalía y las entidades del orden nacional, así como la función de registrarlos en el Banco de Programas y Proyectos de Inversión Nacional(Art.. 27). Asigna al DNP la obligación de mantener actualizada la información del Banco de Programas y Proyectos de Inversión Nacional (Art. 27). Prevé la armonización entre planes y presupuesto (Art. 28 y 44). Asigna al DANE, al DNP, a las entidades territoriales y a sus organismos de planeación, responsabilidades en materia de planeación, entre ellas, para las entidades territoriales la organización de bancos de programas y proyectos (para lo cual establece plazos perentorios) y, para el segundo, la organización de metodologías, criterios y procedimientos para la planeación, y una red nacional de bancos de proyectos (Art. 49). Establece que los programas y proyectos que presenten con base en el respectivo banco de proyectos, tendrán prioridad para acceder al sistema de cofinanciación y a los demás programas a ser ejecutados en los niveles territoriales. Dispone que la nación y las entidades territoriales, para efecto de la elaboración de los planes de inversión y con el propósito de garantizar coherencia y complementariedad en

14

su elaboración, deberá mantener actualizados bancos de programas y proyectos. (Art. 3 lit. 1).

Establece que las estrategias, programas y proyectos del plan de desarrollo deben ser factibles de realizar, según las metas propuestas y el tiempo disponible para alcanzarlas, teniendo en cuenta la capacidad de administración, ejecución y los recursos financieros a los cuales es posible acceder (Art.. 3, lit. 1). Para efectos de la ejecución de los planes de desarrollo prevé la elaboración de planes de acción y dispone que para tal efecto, así como para la programación del gasto, se tendría en cuenta los principios a que se refiere el Art. 3 de la misma ley (Art.. 26). Dispone que, en materia de elaboración, aprobación, ejecución, seguimiento y evaluación de los planes de desarrollo de las entidades territoriales, se aplicarán, en cuanto sean compatibles, las mismas reglas precisas en la ley 152/94 para el Plan Nacional de Desarrollo. (Art. 36). La Ley 38 de 1989, Orgánica de Presupuesto es modificada por la Ley 179 del 30 de diciembre de 1994: entre ellas: Modifica el Art. 31 de la Ley 38/89, disponiendo que no se podrá ejecutar ningún programa o proyecto que haga parte del Presupuesto General de la Nación hasta tanto no se encuentre evaluado por el órgano competente y registrado en el Banco Nacional de Programas y Proyectos (Art.. 23). Establece reglas para la cofinanciación y dispone que los proyectos de cofinanciación que se encuentren identificados en el decreto de liquidación del presupuesto o sus distribuciones serán evaluados y aprobados directamente por los órganos cofinanciadores (Art. 23). Modifica el nombre del banco de proyectos de inversión nacional por el Banco Nacional de Programas y Proyectos (Art. 55). Decreto 359 de febrero 22 de 1995: "Por el cual se reglamenta la Ley 179 de 1994". Esta norma regula el Programa Anual Mensualizado de Caja –PAC- y dispone en su artículo 41 que “Todo Programa o Proyecto que haga parte del Plan Operativo Anual de Inversiones deberá estar inscrito en el Banco Nacional de Programas y Proyectos”. Decreto 2150 del 5 de diciembre de 1995: "Por el cual se suprimen y reforman regulaciones, procedimientos o trámites innecesarios, existentes en la administración pública". Modifica los artículos 23, 24, 27, 28 del Decreto 2132 de 1992. Dispone que las Unidades Especiales de las Oficinas de Planeación de los Departamentos y Distritos (UDECO) se encargarán de calificar la viabilidad de los programas y proyectos de cofinanciación que presenten las mismas entidades territoriales y los municipios del respectivo departamento (Art. 69).

15

Dispone que el CONPES determinará los montos de los proyectos susceptibles de ser aprobados directamente por los Comités Departamentales y Distritales de cofinanciación. Establece mecanismos para la ejecución de recursos con el concurso de las entidades que administren los Fondos Departamentales y Distritales de Cofinanciación (Art. 71). Establece que los fondos de cofinanciación FIS y DRI, así como FINDETER en relación con los fondos de cofinanciación que administra, podrán manejar directamente los recursos del Sistema Nacional de Cofinanciación, o mediante contratos de Fiducia (Art. 68). Decreto 1363 del 12 de Julio de 2000: “Por el cual se modifica la estructura del Departamento Nacional de Planeación”. Asigna funciones a la Dirección de Inversiones y Finanzas Públicas, entre otras las siguientes:

Realizar La orientación Operativa y Asistencia técnica del Banco de Proyectos de

Inversión en todos los niveles, organismos y entidades públicas.

Elaborar, actualizar y distribuir los Manuales de Operación e Instalación de las herramientas computacionales desarrolladas por el Departamento Nacional de Planeación para el manejo de Banco de Programas y Proyectos.

Coordinar la incorporación de los planes de inversión pública de los programas sectoriales y los proyectos que presenten los Ministerios, Departamentos Administrativos, establecimientos públicos y entidades territoriales al DNP.

Coordinar flujos de información desde y hacia el BPIN de acuerdo con los calendarios establecidos en las reglamentaciones y en los manuales de operación del BPIN.

Capacitar en los asuntos relacionados con la operación del BPIN, para facilitar la formulación, seguimiento y evaluación de políticas y proyectos.

Asimismo a continuación se presenta la normatividad por la cual se crea y regula la Estampilla Universidad Distrital Francisco José de Caldas 50 años, que actualmente y en el corto plazo se presenta como la única fuente de financiamiento de los proyectos de inversión de la Universidad: Ley 648 del 22 de marzo de 2001: “Por la cual se autoriza la emisión de la estampilla Universidad Distrital Francisco José de Caldas 50 años”. Determina la distribución porcentual de los recursos recaudados, su utilización específica y el monto máximo total a recaudar calculado en precios constantes de 1998. Acuerdo 53 del 10 de enero de 2002 del Concejo de Bogotá: “Por medio del cual se ordena la Emisión de la Estampilla Universidad Distrital Francisco José de Caldas 50

16

años, en cumplimiento a lo dispuesto en la Ley 648 de 2001”. Ordena su emisión, condiciona su ejecución al cumplimiento de un Plan de Desempeño por parte de la Universidad. Ley 863 del 29 de diciembre de 2003: “Por la cual se establecen normas tributarias, aduaneras, fiscales y de control para estimular el crecimiento económico y el saneamiento de las finanzas públicas”. Modifica la distribución destinada al fondo de pensiones o pasivo pensional establecida en el Art. 2 de la Ley 648 de 2001, incrementándose al 20% del total del recaudo. (OFICINA ASESORA DE PLANEACIÓN Y CONTROL DE LA UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS, 2011 págs. 35-45)

4.1.3 Herramientas similares

En el mercado actualmente se encuentran productos referentes a la administración de proyectos de inversión y funcionamiento de las instituciones con ciertas variaciones y especificaciones, debido a que cada una maneja sus propias normas para el seguimiento del ciclo de vida de sus proyectos. Sobre la plataforma de Oracle existen varias empresas desarrolladoras de software que en su portafolio de servicios ofrecen productos para la administración de proyectos como los son: 4.1.3.1 ITIS a través de PeopleSoft & Siebel con la implementación y mantenimiento de soluciones de Inteligencia de Negocio (BI) y Orientadas al sector educativo (CS) para la administración de recursos. 4.1.3.2 SETI (Servicios Especializados de Tecnología e Informática S.A), la cual ofrece software a la medida implementando metodologías certificadas y la administración de Bases de Datos en las diferentes marcas. 4.1.3.3 GTS S.A (Global Technology Services) la cual tiene en su portafolio de proyectos en Sistemas de Información a SEGPLAN para el Distrito. 4.1.3.4 SEGPLAN Sistema de Información de Seguimiento al Plan de Desarrollo La Secretaría Distrital de Planeación asegura que el sistema llamado SEGPLAN es una herramienta que permitirá a la ciudadanía en general acceder a la información sobre acciones, proyectos, planes, políticas y avance en las metas, entre otros temas, que fijan la planeación de Bogotá, así como los resultados y gestión de los mismos. El nuevo SEGPLAN nace bajo la necesidad de hacer una actualización conceptual y tecnológica del sistema de información actual, acorde con los cambios y adelantos en los sistemas y en la lógica funcional de la ciudad, entidades y localidades. Además,

17

enmarcado en una política de Bogotá Humana de brindar herramientas para el ejercicio del control social y la transparencia en la gestión pública.

El SEGPLAN actual nació en el año 1999 por medio de un convenio interadministrativo con la Secretaría Distrital de Hacienda, que reemplazó al Sistema de Información de Proyectos de Entidades – SIPE- que había creado la SDP (en ese entonces Departamento Administrativo de Planeación Distrital – DAPD) desde el año 1996. Su funcionamiento empezó a partir del año 2000, lo que implica que ha estado en funcionamiento durante 5 Planes de Desarrollo, incluido el actual (2013).

En la figura 1 se puede visualizar el formulario correspondiente a la inscripción de proyectos de inversión en el aplicativo, el cual presenta los campos relacionados a la identificación y clasificación del proyecto y otros aspectos. Tomado de la Secretaria Distrital de Planeación (SECRETARIA DISTRITAL DE PLANEACIÓN, 2012 pág. 3).

Ilustración 1. Interface SEGPLAN formulario de inscripción de proyectos de inversión

18

A nivel Nacional, se cuenta con sistemas de información y herramientas de apoyo para la administración y seguimiento de los proyectos de inversión de recursos públicos. La Dirección de Inversiones y Finanzas Públicas - DIFP, del Departamento Nacional de Planeación - DNP, es responsable del Sistema Unificado de Inversiones y Finanzas Públicas – SUIFP, el cual integra los procesos asociados a cada una de las fases del ciclo de la inversión pública, acompañando los proyectos de inversión desde su formulación hasta la entrega de los productos, articulándolos con los programas de gobierno y las políticas públicas.

La figura 2 representa el modelo de procesos del sistema unificado de inversiones y finanzas públicas. Tomado del Departamento Nacional de Planeación (2010).

Los siguientes aplicativos informáticos son coordinados por la Subdirección de Proyectos e Información para la Inversión Pública - SPIIP. 4.1.3.5 SUIFP Sistema Unificado de Inversión y Finanzas Públicas Es un sistema de información que integra los procesos asociados a cada una de las fases del ciclo de la inversión pública, acompañando los proyectos de inversión desde su formulación hasta la entrega de los productos, articulándolos con los programas de gobierno y las políticas públicas.

Ilustración 2. Modelo de procesos SUIFP

19

4.1.3.6 MGA Metodología General Ajustada De acuerdo con la Ley 152 de 1994 y la Resolución 806 de 2005, la Metodología General Ajustada la deben utilizar las entidades nacionales, departamentales, distritales y municipales para la formulación y evaluación de proyectos de inversión pública. La MGA en Excel ha sido reemplazada por la MGA en base de datos, para formular cualquier proyecto de inversión pública. 4.1.3.7 SUIFP- BPIN Banco Nacional de Programas y Proyectos El banco de Programas y proyectos de Inversión es la instancia que liga la planeación con la programación y el seguimiento de programas y proyectos de inversión pública, por medio de sus componentes y funciones. Está integrado por los componentes legal e institucional, educación, capacitación y asistencia técnica, metodologías y sistemas y herramientas computacionales. 4.1.3.8 SUIFP-PP Programación Presupuestal Se centra en la asignación de recursos del Presupuesto General de la Nación (PGN) a cada proyecto, mediante la aplicación de criterios y trámites establecidos por la Ley. Busca la elaboración del Plan Operativo Anual de Inversión (POAI). 4.1.3.9 SUIFP-EP Ejecución Presupuestal Instrumento centrado en la elaboración y aprobación de solicitudes de trámites presupuestales relacionados con los proyectos de inversión pública. Garantizando la integración de los flujos de información de la formulación de los proyectos, el proceso de programación presupuestal y el seguimiento del avance físico financiero de proyectos. 4.1.3.10 SPI Seguimiento a Proyectos de Inversión El Sistema de Seguimiento de Proyectos de Inversión (SPI), es una herramienta que facilita la recolección y análisis continúo de información para identificar y valorar los posibles problemas y logros frente a los mismos y constituye la base para la adopción de medidas correctoras, con el fin de mejorar el diseño, aplicación y calidad de los resultados obtenidos. De igual forma, para tomar decisiones durante la implementación de una política, programa o proyecto, con base en una comparación entre los resultados esperados y el estado de avance de los mismos en materia de ejecución financiera, física y de gestión de los recursos. Así mismo, es una ventana directa para ver los logros y analizar la gestión de las entidades del Estado en materia de inversión pública.

20

4.1.3.11 SSEPI - Sistema de Seguimiento y Evaluación de Proyectos de Inversión de Entidades Territoriales El Sistema de seguimiento y evaluación de proyectos de inversión pública –SSEPI– se diseñó con el ánimo de facilitar las labores relacionadas con la programación y la gestión de la inversión en las entidades territoriales. Dichos usuarios se benefician no solo del apoyo que el sistema presta en la agilización de sus labores, sino de lo que éste produce como insumo para la toma de decisiones. (2010)

4.2 MARCO TEÓRICO

4.2.1 Icaro Es un Sistema de Información modular, desarrollado para ambiente web y con una interfaz gráfica para el acceso por parte de los usuarios, con el fin de ofrecer herramientas para la planeación, el seguimiento y el control de los procesos administrativos desarrollados en la Universidad Distrital Francisco José de Caldas con la dirección del Centro de Investigaciones y Desarrollo Científico y la colaboración de la Oficina Asesora de Planeación y Control y el acompañamiento del equipo operativo SIGUD. El logo de la plataforma Icaro se presenta en la figura 3, el cual fue tomado de La página web de la Universidad Distrital.

El proyecto del módulo de planeación en Icaro se inició en el 2012, se identificaron todas las fases de desarrollo y priorizaron las requeridas con urgencia. El módulo de planeación representa el sistema de planeación de la Universidad (Acuerdo 03, 1997 CSU). Actualmente este módulo se encuentra en desarrollo y fue necesario que fuera por etapas, priorizando lo concerniente a la planeación de funcionamiento y postergando el desarrollo en lo referente a Inversión.

Ilustración 3. Logo Icaro

21

Ahora bien, la necesidad de la Oficina Asesora de Planeación y Control se concentra en el desarrollo del módulo de Inversión, armonizado con el desarrollo actual del sistema de planeación en Icaro.

4.2.2 Proyecto

“Un proyecto es un esfuerzo que tiene un objetivo definido, consume recursos y opera bajo plazos, costos, riesgos, calidad y factor humano. Además, los proyectos son considerados generalmente como actividades que pueden ser únicas.... El desafío de hoy y de mañana es dirigir actividades que nunca han sido intentadas en el pasado y no pueden ser nunca repetidas en el futuro. [1, p. 13]

Generalmente los proyectos están compuestos en ciclos de 4 fases: Formulación: Etapa de planeación y consolidación de una idea en un proyecto concreto y real. Selección: Aplicación de criterios en los estudios de viabilidad, elegibilidad y priorización, se evalúa para verificar que es una solución adecuada y eficiente. Ejecución: Se instala la capacidad operativa, se da la concreción real y puesta en marcha del proyecto para que se convierta en acciones. Seguimiento y Evaluación: A través de la ejecución del proyecto se realiza una revisión periódica entre las metas propuestas y los logros alcanzados a fin de realizar correcciones pertinentes. [2, pp. 11-12]

4.2.3 Proyecto de inversión

Es una propuesta que surge como resultado de estudios que la sustentan y que está conformada por un conjunto determinado de acciones con el fin de lograr ciertos objetivos. El propósito del proyecto de inversión es poder generar ganancias o beneficios adicionales a los inversionistas que lo promueven y, como resultado de este, también se verán beneficiados los grupos o poblaciones a quienes va dirigido.

Los proyectos de inversión pública son todas aquellas iniciativas promovidas por entidades del gobierno y que tiene como objetivo solucionar problemas de índole social o económico. En este caso el inversionista es el Estado o sus instituciones que por la naturaleza de sus funciones deben desarrollar proyectos para bienestar de la población y no esperan recibir rendimientos en términos financieros, pero sí pretenden mejorar los indicadores o índices medibles desde el punto de vista social y económico, como por ejemplo, mejoramiento de la salud, la educación entre otros.

22

De acuerdo con lo anterior, la convivencia de ejecución de un proyecto de interés público está relacionado con el impacto que tiene en la sociedad y en la economía como un todo, lo cual se mide por medio de los beneficios y los costos sociales y económicos que, obviamente no son considerados en los proyectos de interés privado. [3, pp. 16-17]

4.2.4 Proyecto de funcionamiento

Es una propuesta que surge como resultado de estudios que la sustentan y que está enfocada en el cubrimiento de los costos fijos que representa el normal desarrollo de las actividades de la institución.

4.2.5 Presupuesto

“El presupuesto es una herramienta de planificación que, de una forma determinada, integra y coordina las áreas, actividades, departamentos y responsables de una organización y que expresa en términos monetarios los ingresos, gastos y recursos que se generan en un periodo determinado para cumplir con los objetivos fijados en la estrategia.” [4, p. 41]

4.2.6 Banco de proyectos

Es un instrumento dinámico de gestión pública para la planeación, orientado a resultados, que registra la información de los proyectos viables, técnica, financiera, económica, social, institucional y ambientalmente, susceptibles de ser financiados o cofinanciados con recursos públicos, y en el que se reportan periódicamente datos para el seguimiento y evaluación de los mismos. Apoya los procesos de planeación, presupuesto, seguimiento, control y evaluación de resultados de la inversión, promoviendo la asignación de recursos a proyectos y programas viables, prioritarios y elegibles que busquen mejorar los niveles de calidad de vida, además apoya los procesos de crecimiento y desarrollo, fomentando el cumplimiento de objetivos y logro de resultados con eficiencia, eficacia, efectividad, equidad, sostenibilidad y sustentabilidad. [5] El Banco de Proyectos de la Universidad Distrital Francisco José de Caldas se define como la instancia administrativa que registra información técnica, económica y financiera de los proyectos; la asignación presupuestal y las fuentes de financiamiento; y permite controlar y evaluar la ejecución física y presupuestal de los proyectos alineados con la planificación institucional.

23

Se concibe como un instrumento de gestión de la inversión, ya que en él se evalúan los proyectos viables (académica, técnica, financiera, económica, social, institucional y ambientalmente), susceptibles de ser financiados o cofinanciados con recursos del presupuesto propio, distrital, regional, nacional e internacional. No es una base de datos sobre proyectos institucionales, no es una dependencia de la oficina Asesora de Planeación y Control, no es un organismo de financiamiento, no es una oficina responsable de registrar proyectos. [2, pp. 17-18]

4.2.7 Plan Estratégico de Desarrollo 2007 – 2016

El Plan Estratégico de Desarrollo “Saberes, Conocimientos e Investigación de Alto Impacto para el Desarrollo Humano y Social” 2007-2016 de la Universidad Distrital Francisco José de Caldas es el resultado de un proceso participativo, orientado a definir las prioridades institucionales para su crecimiento y desarrollo, el compromiso de la Universidad Distrital con la sociedad y el impacto esperado en sus contextos de influencia.

Es un documento indicativo y flexible que debe constituirse en el dispositivo dinamizador de los procesos institucionales, debido a que se adecua a los retos y necesidades del entorno local, regional, nacional y mundial para el cumplimiento de la misión de la Universidad. Por lo tanto, se asume como ruta y horizonte para el desarrollo las funciones de docencia, investigación, innovación, creación y proyección social, referente vinculante para la planeación del gobierno distrital e instrumento de obligatorio cumplimiento para la administración universitaria en cuanto a la formulación de sus planes trianuales, de acción, operativos, al igual que marco para la evaluación permanente de los avances y limitaciones en su ejecución. El Plan Estratégico de Desarrollo 2007 – 2016 concibe la planificación estratégica como un proceso continuo, flexible, permanente y sostenible, mediante el cual se establecen políticas, y se definen estrategias y objetivos que se materializan en programas y proyectos, los cuales a partir del cumplimiento de metas trianuales, permitirán definir un derrotero de la acción universitaria en el horizonte del 2016. [6]

4.2.8 Proyecto Universitario Institucional (PUI)

Los proyectos universitarios son las unidades a través de las cuales se materializan y ejecutan las estrategias y programas establecidos en los planes estratégicos, presentan las siguientes características:

Son un mecanismo dinámico que refuerza el sentido a lo académico y administrativo.

24

Los proyectos deben enfatizar en los resultados esperados y su impacto en el desarrollo de la misión institucional.

La Misión Institucional se concreta en el Plan Estratégico de Desarrollo de la Universidad; por lo tanto los proyectos deben estar articulados en una relación matricial con las estrategias y programas que conforman el Plan.

El proyecto universitario surge de la selección de las alternativas más convenientes para dar solución a problemas o satisfacer necesidades que le permitan avanzar en la concreción de la misión institucional.

El sentido de conveniencia y priorización debe ser la respuesta a un estudio de viabilidad, elegibilidad o pertinencia financiera, económica y social institucional.

La identificación cualitativa y su cuantificación en términos de recursos humanos, técnicos, logísticos y financieros que sean requeridos para el proyecto, es información que debe ser suministrada, con el fin de que pueda ser evaluada y proyectada adecuadamente, tanto de manera individual como agregada para no exceder las capacidades institucionales.

Todo proyecto debe tener una cobertura, alcance y temporalidad definidos.

Los objetivos y resultados que estructuren el proyecto deben ser susceptibles de seguimiento y evaluación periódica, de acuerdo con los indicadores. [7, pp. 9-10]

4.2.9 Plan de Desarrollo Distrital

El Acuerdo número 489 del 12 de junio de 2012 por el cual se adopta el Plan Distrital de Desarrollo Económico, Social, Ambiental y de obras Públicas y el Plan Plurianual de Inversiones para Bogotá D.C. para el periodo 2012-2016, contiene los objetivos, las metas, estrategias y políticas que guiarán la articulación de las acciones del Gobierno Distrital, para elevar las condiciones de bienestar de la ciudadanía y sentar las bases de un cambio de enfoque de la acción pública. Esta identifica los factores prioritarios de intervención que permitan remover condiciones de segregación e inequidad relacionadas con las capacidades de las personas, la persistencia de situaciones de exclusión y riesgos ambientales y la apuesta por el fortalecimiento de la gestión pública para orientar y apoyar las aspiraciones colectivas de las ciudadanías bogotanas. [8, p. 1]

4.2.10 Oficina Asesora De Planeación y Control (OAPC)

Tiene por objetivo coordinar y orientar la formulación de Políticas, Planes, Programas y Proyectos, que brinda métodos, procesos y herramientas técnicas que permitan a la Institución cumplir con su misión institucional y responder adecuadamente a los cambios del entorno y el desarrollo de la universidad.

4.2.11 Unidad Académica Administrativa (UAA)

El ACUERDO 23 DE 1993 (Diciembre 21) en el capítulo 4 del Estatuto General de la Universidad Distrital Francisco José de Caldas, establece:

25

ARTÍCULO 40.DEFINICIÓN. El Departamento es la unidad académica y administrativa fundamental de la Universidad responsable directa de la investigación, la docencia y la extensión en una o varias áreas afines del saber para la cual agrupa los recursos humanos y físicos necesarios para desarrollar esas actividades. Son funciones de los Departamentos las definidas en el Reglamento Académico de la Universidad.

4.2.12 OPENUP/OAS – metodología OPENUP según Oficina Asesora de Sistemas Universidad Distrital - Es un proceso unificado (de aplicación general) y ágil (se centra en el desarrollo rápido de sistemas) que involucra un conjunto mínimo de prácticas que ayudan a los equipos de trabajo a ser más efectivos en el desarrollo de sistemas de software (u otros sistemas de ingeniería). El Proceso Unificado Abierto – llamado en adelante OpenUP, integra una filosofía pragmática y ágil que se centra en la naturaleza colaborativa del desarrollo de software. Es un proceso anti burocrático y agnóstico en cuanto a herramientas (IDE, lenguajes, sistemas operativos, etc.,) que puede ser usado tal como lo ha definido la fundación Eclipse – de donde procede el OpenUP, o que puede ser expandido y adaptado de acuerdo a las especificidades de cada proyecto.

El OpenUP/OAS dirige la organización del trabajo en los niveles personal, de equipo y de interesados. A nivel personal, los integrantes de un proyecto contribuyen con su trabajo con pequeños incrementos en funcionalidad – denominados micro incrementos, los cuales representan los resultados obtenidos en pocas horas o pocos días de trabajo. La solución evoluciona basada en dichos micro incrementos de tal forma que el progreso puede ser visualizado efectivamente cada día. Los integrantes del equipo de desarrollo de forma abierta comparten su progreso diario el cual incrementa la visibilidad en el trabajo, la confianza y el trabajo en equipo El OpenUP/OAS estructura el ciclo de vida de un proyecto en cuatro fases:

1. Inicio, 2. Elaboración, 3. Construcción y 4. Transición.

El ciclo de vida del proyecto provee a los interesados un mecanismo de supervisión y dirección para controlar los fundamentos del proyecto, su ámbito, la exposición a los riesgos, el aumento de valor y otros aspectos; en cada una de esta fases se lleva a cabo

26

una serie de subprocesos que son un conjunto de roles, tareas, artefactos y lineamientos que guían todo el proceso de desarrollo a través de las fases. La figura 4 fue adaptada de la Organización Eclipse (Eclipse.org, 2013), ésta describe los enfoques de la metodología OpenUP.

OpenUP/OAS es un proceso de desarrollo de software mínimo, completo y extensible. Está gobernado por cuatro principios nucleares. 1. Balancear prioridades para maximizar los beneficios que ofrece el proyecto a los interesados: Este principio promueve prácticas que permiten a los participantes de los proyectos desarrollar una solución que maximice los beneficios obtenidos por los participantes y que cumple con los requisitos y restricciones del proyecto.

Ilustración 4. Organización del trabajo y énfasis en el contenido en Open UP

27

2. Colaboración para sincronizar intereses y compartir conocimiento: Este principio promueve prácticas que impulsan un ambiente de equipo saludable, facilitan la colaboración y desarrollan un conocimiento compartido del proyecto. 3. Enfoque temprano en la arquitectura para minimizar riesgos y organizar el desarrollo: Este principio promueve prácticas que permiten que el equipo se centre en reducir al mínimo los riesgos y organizar el desarrollo. 4. Evolución continua y ágil para generar mejoras y obtener retroalimentación: Este principio promueve prácticas que permiten a los equipos de desarrollo obtener retroalimentación temprana y continua de los participantes del proyecto, permitiendo demostrarles incrementos progresivos en la funcionalidad. El proyecto en general se divide en iteraciones, las cuales son planificadas en un intervalo definido de tiempo que no superan las pocas semanas. El OpenUP/OAS tiene elementos que ayudan a los equipos de trabajo a enfocar los esfuerzos a través del ciclo de vida de cada iteración de tal forma que se puedan distribuir funcionalidades incrementales de una manera predecible una versión totalmente probada y funcional al final de cada iteración. Los objetivos que persiguen son: Promover la colaboración y compartir conocimientos alineando intereses del equipo

de trabajo y los usuarios. Ayudar al equipo a enfocarse en la arquitectura de forma rápida; de tal forma que se

minimicen los riesgos y se organice el desarrollo. Ayudar al equipo a balancear prioridades en conflicto para maximizar el valor

obtenido por los interesados en el proyecto. Ayudar al equipo en la evolución continua del producto para obtener retroalimentación

continua y fomentar el mejoramiento. Permitir a los administradores del proyecto realizar seguimientos a las avances

basados en metas e indicadores Permitir que los integrantes del equipo entiendan rápidamente como realizar el

trabajo para alcanzar los objetivos y metas proyectadas. El OpenUP/OAS es un proceso iterativo e incremental que se distribuye a través de cuatro fases: Inicio, Elaboración, Construcción y Transición. En las cuales se desarrollan transversalmente una serie de subprocesos entendiéndose estos últimos como un conjunto de actividades, personas (Roles), prácticas (Guías) y productos de trabajo (Artefactos) que orientan el desarrollo de software a través del tiempo. (OFICINA ASESORA DE SISTEMAS, 2012 pág. 3)

28

La figura 5 presenta el grado de importancia de los subprocesos en cada una de las fases de la metodología según la Oficina Asesora de Sistemas (OFICINA ASESORA DE SISTEMAS, 2012 pág. 2).

Cada fase puede tener tantas iteraciones como se requiera, dependiendo del grado de complejidad y desconocimiento del dominio, la tecnología a ser usada, la complejidad arquitectónica y el tamaño del proyecto, por nombrar algunos factores. Las funciones del equipo de trabajo que describe la tabla 1 fueron adaptadas del documento de la Oficina Asesora de Sistemas (OFICINA ASESORA DE SISTEMAS, 2012 págs. 9-10).

Ilustración 5. Desarrollo transversal subprocesos vs fases de OpenUP.

29

Tabla 1. Roles en OpenUP/OAS

ROL FUNCIÓN PRINCIPAL

Director del Proyecto Garantiza la continuidad del proyecto al gestionar los recursos necesarios y mantener el interés institucional en el proyecto.

Jefe de Proyecto Se encarga de la supervisión y dirección directa de las actividades y resultados de cada uno de los miembros del equipo de desarrollo.

Líder del Proyecto Lidera la planeación del proyecto, coordina interacciones con los interesados y conserva el equipo del proyecto enfocado en alcanzar los objetivos del proyecto

Analista Realiza tareas de relevamiento, análisis y diseño de los requerimientos y requisitos en el proyecto.

Arquitecto

Responsable de diseñar la arquitectura del software, la cual incluye tomar las principales decisiones técnicas que condicionan globalmente el diseño y la implementación del proyecto.

Realizador Es responsable de desarrollar una parte del sistema, incluyendo diseñar esta, para que se ajuste a la arquitectura

Inspector de Pruebas Identifica, define, implementa y dirige las pruebas necesarias, así como verificar y analizar sus resultados.

Auditor Coordinar las actividades del equipo de trabajo en cuanto a realización de auditorías, revisiones, instanciamientos de Planes de Calidad y de Mejoras, etc.

Ingeniero de Procesos

Es responsable de definir, evaluar y ajustar las directrices, guías, artefactos y procedimientos del proceso de desarrollo OpenUP de acuerdo a las necesidades y requerimientos que surjan al interior del proyecto, además verifica y evalúa el grado de cumplimiento y coherencia de aplicabilidad de las directrices y lineamientos del OpenUP/OAS en la planeación, ejecución y seguimiento del proyecto, entre otras.

Interesados Representa los grupos de interés cuyas necesidades deben ser satisfechas por el proyecto. Son fundamentales para la definición de requerimientos.

30

Fases OpenUP/OAS Las transiciones entre las fases del ciclo de vida de la metodología OpenUP según la organización Eclipse (Eclipse.org), se representan en la figura 6.

Ilustración 6. Ciclo de vida del proyecto en OpenUP

Fase de Inicio: Primera fase del proceso, donde los interesados y los integrantes del equipo de desarrollo, colaboran para determinar el ámbito del proyecto, sus objetivos y determinar si el proyecto es viable. Las iteraciones de esta fase enfocan el esfuerzo de trabajo en actividades y resultados presentados en la tabla 2, los cuales fueron adaptados del documento de la Oficina Asesora de Sistemas (OFICINA ASESORA DE SISTEMAS, 2012 págs. 4-5).

Tabla 2. Actividades y resultados de la fase de Inicio OpenUP/OAS

ACTIVIDAD RESULTADOS

Iniciar el proyecto Elaborar el documento Visión Elaborar el Plan General del Proyecto Elaborar el documento de Análisis de riesgo

Planear y gestionar la iteración

Elaborar el Plan de Iteración Elaborar el documento de evaluación de la iteración Elaborar el documento de valoración de resultados de la iteración

Identificar y refinar los requerimientos y requisitos

Elaborar la especificación de casos de uso Elaborar el documento de requisitos de soporte Elaborar el documento casos de prueba

Llegar a un acuerdo sobre el enfoque técnico

Elaborar el documento Bloc de Notas de la Arquitectura

31

Al final de esta fase, como mínimo, el proyecto:

Ha definido el ámbito. Tiene un estimado inicial de los costos y el cronograma. Ha definido y priorizado un conjunto inicial de requerimientos funcionales y no

funcionales. Ha identificado un conjunto de riesgos y haya propuesto las estrategias de mitigación. Ha identificado un conjunto de interesados. Ha creado un bosquejo de arquitectura.

Fase de Elaboración: La segunda fase dentro del ciclo de vida del proyecto, en ella los riesgos significativos que influyen en la arquitectura son identificados y considerados. En esta fase: • Se obtiene un entendimiento más detallado de los requerimientos y requisitos. • Se diseña, implementa, válida y establece la línea base de la arquitectura. • Se mitigan los riesgos esenciales. • Se produce un cronograma detallado. • Se realiza una mejor estimación de costos.

Las iteraciones de esta fase enfocan el esfuerzo de trabajo en las siguientes actividades y resultados (OFICINA ASESORA DE SISTEMAS, 2012 pág. 5) las cuales fueron adaptadas del documento de la Oficina Asesora de Sistemas (OFICINA ASESORA DE SISTEMAS, 2012 págs. 5-6) y se presentan en la tabla 3.

Tabla 3. Actividades y resultados de la fase de Elaboración OpenUP/OAS

ACTIVIDAD TAREAS/RESULTADOS

Planear y gestionar la iteración

Elaborar el Plan de Iteración. Elaborar el documento de evaluación de la iteración. Elaborar el documento de valoración de resultados de la iteración.

Identificar y refinar los requerimientos

Actualizar, depurar y aumentar el contenido de la especificación de casos de uso. Actualizar, depurar y aumentar el contenido del documento de Requerimientos de soporte. Actualizar, depurar y aumentar el contenido del documento Casos de prueba.

32

ACTIVIDAD TAREAS/RESULTADOS

Desarrollar la arquitectura Agregar las vistas de arquitectura al documento Bloc de Notas de la Arquitectura.

Desarrollar un incremento en la solución

Actualizar, depurar y aumentar el contenido del documento Especificación de Diseño. Actualizar, depurar y aumentar el contenido del documento Pruebas Hechas por el Realizador. Obtener el código fuente que realiza uno o varios elementos de diseño. Elaboración de una Construcción del Sistema que integre nuevos elementos (componentes desarrollados, clases, etc). Elaborar el artefacto Registro de Pruebas que contenga los resultados de la ejecución de las pruebas hechas por el realizador.

Probar la Solución Construida

Elaborar el artefacto Script de Prueba. Elaborar el artefacto Registro de Pruebas que contenga los resultados de la ejecución de las pruebas.

Gestionar las peticiones de cambio

Actualizar, depurar y aumentar el contenido del documento Lista de Unidades de Trabajo

Fase de Construcción:

Esta es la tercera fase del proceso, se enfoca en detallar los requisitos y requerimientos, diseñar, implementar y probar el grueso del software y completar el desarrollo del sistema basado en la arquitectura. 1. Se describen los requisitos y requerimientos restantes 2. Se completan en detalles los diseños, la implementación y las pruebas del software. 3. Se libera la primera versión operativa del software (beta) del sistema. Las actividades de esta fase son: 1. Planificación y gestión de la iteración 2. Identificar y refinar requisitos y requerimientos 3. Desarrollar un incremento de solución 4. Probar la solución construida

33

Fase de Transición: Es la cuarta fase del proceso. Se enfoca en la transición del producto de software a la plataforma tecnológica del cliente logrando que los interesados convengan que el desarrollo del producto cumple con los requerimientos planteados. Los objetivos de esta fase son lograr: La prueba beta válida que satisfaga las expectativas del usuario. Esto típicamente

requiere algunas actividades de afinamiento, tales como depuración de errores y mejora del desempeño y la usabilidad.

El consentimiento de los interesados en que el desarrollo está completo. Esto puede involucrar varios niveles de pruebas para la aceptación del producto, incluyendo pruebas formales e informales y pruebas beta.

Mejorar el desempeño en futuros proyectos a través de lecciones aprendidas. Documentar las lecciones aprendidas y mejorar el ambiente de los procesos y las

Herramientas para el proyecto. (OFICINA ASESORA DE SISTEMAS, 2012 pág. 6) Las fases en que se desarrolló el proyecto fueron 4 siguiendo el orden de la metodología OPENUP-OAS pero subdividiendo en etapas para realizar procesos que requerían un trabajo más exhaustivo.

34

5 MARCO METODOLOGICO

5.1 METODOLOGIA DE LA INVESTIGACION En esta sección se describe la metodología OpenUP – OAS utilizada en el desarrollo del proyecto, es decir se contextualiza el proceso.

5.1.1 Tipo de estudio

Este proyecto es de tipo de desarrollo tecnológico dado que, se busca materializar el módulo de proyectos de la Universidad Distrital en la plataforma Icaro, éste se realiza sobre el Banco de Proyectos existente de la Universidad Distrital, el cual se encarga del seguimiento al ciclo de vida de cada proyecto de inversión. La captura de la información es realizada en un periodo de tiempo aproximado a un mes, con ayuda de la Oficina Asesora de Planeación y Control de la Universidad Distrital Francisco José de Caldas ubicada en el edificio administrativo en la Carrera 7 N. 40-53 Piso 8 en la ciudad de Bogotá, la cual dispuso la información normativa y legal, para la recopilación y estructuración del proyecto de grado, el cual fue realizado de manera longitudinal dado que el estudio de las variables depende del ciclo de vida de los proyectos.

5.1.2 Método y/o diseño de la investigación

La metodología usada para el levantamiento de la información que sustente el trabajo de grado es netamente cualitativa ya que se desarrolla el por qué y el cómo se tomó una decisión, basados en las observaciones, dado que se hace necesario recoger información mediante encuestas con preguntas puntuales para cada persona encargada del área, reuniones con las personas interesadas en el resultado con el fin de retroalimentar por medio de comentarios, sugerencias y correcciones el desarrollo del módulo de proyectos.

5.1.3 Participantes

La Unidad Académica Administrativa evalúa y selecciona la iniciativa del proyecto, al tener en cuenta el Plan Estratégico de Desarrollo de la Universidad y los programas a desarrollar dentro de la misma dependencia y designa al gerente del proyecto; éste debe elaborar el perfil, formular el proyecto en la metodología que considere pertinente para presentarlo ante la UAA; quienes evaluarán los proyectos que son considerados convenientes para el cumplimiento de los programas de sus áreas académicas o administrativas. Si el proyecto es aceptado, éste es enviado en un formato establecido por la Oficina Coordinadora del Banco de Proyectos de la Universidad Distrital (OCBPUD), para su revisión y por ende, el proyecto tendrá el estado de inscrito.

35

La OCBPUD que se encuentra embebida en la Oficina Asesora de Planeación y Control, asiste a las dependencias en la presentación de los proyectos bajo los parámetros establecidos en cuanto a la forma y contenido, con especial énfasis en la pertinencia de los proyectos frente a la concreción de las estrategias y programas planteados por la administración central de la Universidad. En este sentido la oficina emite concepto en cuanto a contenido y forma del proyecto y la pertinencia del mismo. Si el proyecto no cumple con requisitos de forma, contenido y pertinencia será devuelto a la UAA para que se hagan las respectivas correcciones. Si el concepto por parte de la Oficina es favorable o se han efectuado efectivamente las correcciones, el proyecto es registrado en el BPUD en el formato establecido que le dará el estado de registrado, lo cual garantizará la evaluación ex-ante. La OAPC, revisa los proyectos presentados, establece correspondencia entre los mismos y envía a la instancia correspondiente (personal competente en el área, según la complejidad del proyecto se asignará un evaluador con competencias específicas en el área del proyecto) para la evaluación pertinente. La selección de los proyectos trae implícito el análisis de tres dimensiones: viabilidad (concepto meramente técnico que tiene que ver con las características propias del proyecto y la capacidad de sus promotores para ejecutarlo con éxito), elegibilidad (establece en qué medida el proyecto contribuye al cumplimiento de la misión institucional y su coherencia con el Plan Estratégico de desarrollo) y prioridad (proceso de jerarquización de proyectos en función de su relevancia y pertinencia social e institucional frente a las políticas establecidas) que se consideran indispensables para una correcta evaluación de proyectos y toma de decisiones. El evaluador o comité tendrá un tiempo prudencial para examinar los proyectos con base en los criterios anteriormente citados. Una vez los proyectos que han sido considerados elegibles por los evaluadores, son enviados por la OAPC a la Instancia Estratégica (Rectoría o Consejo Superior Universitario) con el propósito de ser sujetos de priorización en función de su relevancia frente a las políticas establecidas. Los proyectos deben ser ajustados en función de la asignación de recursos otorgada, con base en el presupuesto, el resultado de esta etapa será el alcance, presupuesto y cronograma línea base, que se utilizará para hacer el seguimiento y evaluación al proyecto. Posteriormente, el gerente del proyecto inicia el desarrollo del mismo con base en los recursos asignados para tal fin. El gerente del proyecto tiene como función la planeación, coordinación, dirección, y control de las actividades, recursos y procesos necesarios para lograr el objetivo que propone el proyecto. Además de velar por la generación de un ambiente adecuado a

36

través de la motivación permanente a su equipo de trabajo, el cumplimiento de las normas, procesos y procedimientos propios de la institución, debe mantener una comunicación efectiva entre agentes del proyecto y la institución mediante la producción de informes de avance mensual y trimestral en el formato sugerido por la OAPC y lo debe enviar a la OCBPUD donde se evaluará su avance en los términos programados y deseables. Dichos informes deberán complementarse con un archivo adjunto donde se describan: dificultades en la gestación, retrasos y soluciones planteadas, población beneficiada, fotografías, imágenes, gráficos, cuadros explicativos y demás aspectos que sea pertinente reportar. Si se asignó un interventor, se le envían copias de los informes de avance para que verifique los alcances y emita un concepto sobre la conveniencia de seguir o no con el proyecto. Éste a su vez produce un informe y lo remite a la OAPC. Si en algún momento el gerente del proyecto realiza cambios en el alcance, presupuesto o tiempo deben ser solicitados para ser evaluados y aprobados por la UAA correspondiente, éstos cambios son informados a la OAPC, si el cambio es aprobado se deberá hacer la respectiva reserva presupuestal y el rediseño de los alcances, a lo cual se continuará el seguimiento. Si es necesario hacer ajustes o modificaciones a nivel presupuestal, esta se debe corresponder con el ciclo presupuestal. Con base en las evaluaciones de seguimiento de las dependencias ejecutoras del proyecto se puede evaluar la conveniencia o no de continuar con el proyecto, al poseer como referencia el informe de avance técnico y financiero, esta decisión también puede ser tomada por las instancias estratégicas apoyadas en conceptos o informes que emita la OAPC. La etapa final de todo proyecto es su cierre, donde éste puede suceder debido a la terminación normal del proyecto o por recomendación de las instancias evaluadoras cuando el proyecto no ha generado los resultados esperados. Este cierre se hace constar por medio de un acta de liquidación. Una vez el proyecto ha finalizado, la OAPC y el personal participante del proyecto proceden a realizar una evaluación final, al tener como punto de referencia los objetivos propuestos, logros alcanzados y los problemas que se presentaron en el desarrollo del proyecto. Esta evaluación se hace con base en las dimensiones técnicas, administrativas, financieras y económicas. El Público en general puede consultar los proyectos aprobados que se encuentran registrados y la documentación disponible.

37

5.1.4 Instrumentos y equipos

Para el desarrollo del proyecto el equipo de trabajo cuenta con la siguiente descripción de equipos:

Computador Portátil 1: DD: 350 GB Memoria Ram: 4 GB Sistemas Operativos: Windows 7 Ultimate 64 bits / Ubuntu 12.04 LTS 32 bits Procesador: Intel® Pentium® Dual CPU T3400 de 2.16 GHz

• Computador Portatil 2:

Modelo: Toshiba Satellite L745 DD: 640 GB Memoria Ram 4 GB Sistemas Operativos: Windows 7 Home Premium 64 bits / Ubuntu 12.04 LTS 32 bits Procesador: Intel® Core™ i5-2450M CPU @ 2.50Ghz

5.1.4.1 Entrevistas y reuniones

Para conocer las necesidades y describir mejor los requerimientos del sistema se llevarán a cabo entrevistas, y reuniones extraordinarias con el fin de obtener información necesaria sobre aspectos legales, tecnológicos, de funcionamiento y demás a los que haya lugar durante el desarrollo y que necesiten supervisión por parte del grupo desarrollador del OAPC.

5.1.4.2 Encuesta

Con el fin de agrupar y medir información sobre la percepción en los procesos de registro, evaluación, seguimiento, difusión e interacción de usuarios con el sistema actual del Banco de Proyectos de la Universidad Distrital se diseñó el formato que se encuentra en la sección de anexos 10.2.1.

5.1.5 Procedimiento

38

Para el desarrollo del Módulo de proyectos para la plataforma Icaro se empleó la metodología OPENUP-OAS con el fin de cumplir las normas de construcción de software para la Universidad Distrital Francisco José de Caldas.

5.2 METODOLOGIA DE LA INGENIERIA En esta sección se describe la metodología OpenUp utilizada en el desarrollo del proyecto, la cual fue adoptada por recomendación debido a que el producto final está dirigido a la Universidad Distrital Francisco José de Caldas.

5.2.1 DESCRIPCIÓN DE LA METODOLOGÍA EN CONTEXTO Para la construcción del módulo de proyectos se continuará con la utilización de la metodología para el desarrollo de software Open-Up/OAS, ya que la plataforma Icaro está desarrollada con esta y se pretende continuar del mismo modo. Así pues, los roles asignados dentro de esta metodología para ser asumidos en el proyecto se asignan en los siguientes grupos descritos en las tablas 4, 5 y 6.

5.2.1.1 Equipo de gestión

Tabla 4. Roles para el Equipo de Gestión

ROL PERSONA A CARGO

Director de Proyecto Katherine Zubieta

Jefe de Proyecto David Gualtero

Líder de Proyecto David Gualtero, Katherine Zubieta

Ingeniero de procesos David Gualtero, Katherine Zubieta

5.2.1.2 Equipo de soporte

Tabla 5. Roles Equipo de Soporte

ROL PERSONA A CARGO

Inspector de pruebas David Gualtero

Auditor (líder de calidad) Katherine Zubieta

39

Interesados OCBPUD y OAPC

5.2.1.3 Equipo de desarrollo

Tabla 6. Roles Equipo de Desarrollo

ROL PERSONA A CARGO

Desarrollador David Gualtero, Katherine Zubieta

Analista David Gualtero, Katherine Zubieta

Arquitecto David Gualtero, Katherine Zubieta

Bajo el método de trabajo del proceso de desarrollo OpenUP/OAS como marco de trabajo Institucional en el análisis, diseño, desarrollo e implantación de productos de software al interior de la Universidad Distrital Francisco José de Caldas, este proyecto va a manejar durante cada fase los artefactos descritos en la tabla 7 de acuerdo a las especificaciones de la Oficina Asesora de Sistemas. [9, pp. 10 - 11]

Tabla 7. Descripción artefactos Open Up/OAS

NOMBRE DESCRIPCIÓN

Plan General del Proyecto

Define los parámetros para realizar el direccionamiento y seguimiento al proyecto. Especifica los objetivos de alto nivel de las iteraciones y sus correspondientes hitos.

Plan de Iteración Comunica los objetivos, la asignación de tareas y los criterios de evaluación para una iteración dada.

Unidades de Trabajo Diarias Contiene una lista de los trabajos programados diariamente y que responden a los objetivos definidos en la Iteración y en el proyecto.

Cierre de iteración Este documento registra los resultados de una iteración.

Visión

Contiene los lineamientos de los requerimientos nucleares visionados del sistema, especificado las necesidades y características claves de los Interesados.

Requisitos de soporte Captura requisitos en el ámbito del sistema que no hayan sido capturados en escenarios o casos de uso, incluye requisitos sobre atributos de calidad y de

40

desempeño global.

Casos de Uso Captura la secuencia de acciones que un sistema realiza y que genera un resultado observable que es de valor para aquellos que interactúan con el sistema.

NOMBRE DESCRIPCIÓN

Glosario Define términos importantes usados en el proyecto.

Listado de requerimientos y requisitos

En este documento se registran los requerimientos y requisitos que surjan a lo largo del proyecto, y sirve para priorizar y organizar las tareas, objetivos y metas del mismo.

Acta de Trabajo Registra los acuerdos o compromisos definidos entre los interesados y el equipo de desarrollo.

Plan de Riesgos Contiene la identificación, valoración, relevancia, prevención, mitigación, control y respuesta a posibles riesgos que se generen en un proyecto de software.

Bloc de notas de la Arquitectura

Contiene las decisiones, razonamientos, asunciones, explicaciones e implicaciones sobre la arquitectura en formación.

Documento de Diseño

Documenta las especificaciones técnicas en cuanto al diseño del software y se complementa con diagramas de clases, diagramas de colaboración, diagramas de secuencia entre otros.

Control de Cambios

Es utilizado para documentar las solicitudes de cambio de los diferentes subprocesos que surgen al interior del proyecto por parte de los interesados o miembros del equipo del proyecto.

Caso de prueba

Son la especificación de un conjunto de pruebas de entradas, condiciones de ejecución y resultados esperados, los cuales son identificados para el propósito de realizar una evaluación de un aspecto particular en un escenario específico.

Registro de Pruebas Recolecta los resultados de la ejecución de una o más pruebas en un ciclo completo de pruebas.

Programa de Auditoría Documento que registra la planificación de un conjunto de auditorías para un periodo de tiempo determinado y dirigidas hacia un propósito específico.

41

Plan de Auditoría

Documento que describe las actividades y los detalles acordados de una auditoría entre el equipo auditor y los auditores. Este plan de auditoría debe ir de la mano de una lista de verificación que permita evidenciar los aspectos que serán evaluados vs preguntas o evidencias que permitan su inspección.

NOMBRE DESCRIPCIÓN

Lista de Verificación Esta lista hace una relación de los aspectos a evaluar con respecto a los criterios de evaluación definidos en el plan de auditoría.

Informe de Auditorias

Recoge todos los hallazgos detectados de la auditoría y el soporte documental para sustentar el dictamen emitido. Este informe resume investigaciones, análisis y muestra conclusiones y recomendaciones.

Plan de Mejoramiento Auditorias

Documento que registra las acciones correctivas y preventivas que mitigan los hallazgos encontrados por los auditores frente a los aspectos a evaluar y que están definidos en una lista de verificación.

5.2.1.4 Fases del proyecto

De acuerdo a las fases de la metodología y la necesidad de cubrir y concretar aspectos importantes con el cliente final del producto, se realizaron algunas de las fases por etapas, con el fin partir a la siguiente etapa de desarrollo teniendo una base concreta de información y requerimientos, para evitar tener cambios drásticos en fases siguientes del desarrollo.

Fase de Inicio

El equipo de trabajo junto con los interesados determinaron el objetivo del ciclo de vida del proyecto, ello enmarca el ámbito del proyecto, sus objetivos y la viabilidad del mismo, se entendió qué se va a desarrollar, se identificó la clave principal del funcionamiento del sistema, se determinó como mínimo una solución posible para obtener los resultados esperados basados en una arquitectura y se comprendió cuáles son los costos asociados al desarrollo del proyecto según las especificaciones. Todo esto fué plasmado principalmente en los artefactos de Visión, Plan General del Proyecto, Glosario, Plan de Riesgo, Bloc de Notas de la Arquitectura y el plan y cierre de la iteración. Para lograr una comprensión de la necesidad, vocabulario y entendimiento del contexto fue necesaria una adquisición previa de conocimientos sobre el tema, a través de material textual oral proporcionado por personal de la OAPC.

42

Etapa 1: Identificación y descripción de la necesidad Para la recolección de la información se realizó una revisión bibliográfica de las cartillas que contienen la información legal y normativa del ciclo de vida de los proyectos, las cuales fueron proporcionadas por la OAPC. Además se realizaron reuniones con los encargados del desarrollo de la plataforma Icaro y el director de la OAPC en donde se establecerán normas para el desarrollo y funcionamiento del MP.

Etapa 2: Capturar la información para generar la especificación de requerimientos Se reunió la información legal, normativa y en especial la funcional del Banco de Proyectos de la Universidad Distrital, con el fin de generar una definición contextualizada y detallada del producto a obtener, cumpliendo la metodología OpenUP/OAS. Seguidamente, con base en esta información, se consolidaron los requerimientos de interfaces de usuario (describe las especificaciones para cada escenario de los usuarios del sistema), persistencia (describe las necesidades y especificaciones para la conexión y manejo de la persistencia de los datos en la Base de Datos), funcionales (describe las restricciones asociadas al funcionamiento del sistema en la interacción con el entorno y estado, es decir, qué debe hacer el sistema) y no funcionales (restricciones sobre el paso de posibles soluciones, es decir, cómo debe ser el sistema). Así mismo, la descripción de aspectos tecnológicos (hardware y software) y costos involucrados para la documentación e implementación son de importancia en este punto

Fase de Elaboración

En esta fase el equipo de trabajo obtuvo más detalles de los requerimientos del sistema, para definir la arquitectura del ciclo de vida del proyecto, para esto se diseñó, implementó y probó la arquitectura planteada en la fase de inicio, para mitigar los riesgos potenciales con el fin de generar un calendario preciso y una estimación de costos. El registro de estos datos se hizo principalmente en los artefactos del Plan de Riesgo, Bloc de Notas de la Arquitectura, Listado de Requerimientos y Requisitos, el Plan General del Proyecto y el plan y cierre de la iteración.

Etapa 1: Modelado UML Se plantearon los módulos del diagrama general de casos de uso, y se realizó la especificación en formato expandido para un detalle a profundidad (nombre, actores, tipo,

43

descripción, pre y post condiciones), acompañados por su respectivo diagrama de actividades que representan gráficamente el proceso a seguir en cada caso. Posterior a esto, se diseñaron los bocetos visuales de interfaz gráfica de usuario, con el fin de definir y orientar sobre los componentes gráficos a utilizar según los CSS existentes. Ahora bien, para realizar el Diagrama estructural como primera medida se definió la notación de identificadores a utilizar. Luego se listaron las clases/objetos candidatos, y se refinó dicha lista, para obtener las clases que conformaron el diseño estructural. Además se hizo un análisis sobre el comportamiento de dichas clases seleccionadas con el fin de determinar estructuras presentes: interfaces, especializaciones, agregación, composición y asociaciones. Finalmente, se pudo proceder a definir los atributos y métodos de las clases e integrarlos en una única estructura según la lógica del sistema, lo cual se conoce como diagrama estructural. Con base en el resultado obtenido, se analizó si era necesaria la implementación de ciertos patrones de diseño que permitieran un mejor desempeño del sistema, eso significaba un pequeño ajuste al diseño. El diagrama estructural resultante está acompañado del diccionario de clases el cual, es un listado de las características lógicas de atributos y métodos, con el fin de dar precisión sobre los datos que se manejan en el sistema para evitar malas interpretaciones o ambigüedades, además una descripción de la razón de existencia de la clase. Etapa 2: Diseño de la Base de Datos (BD) Con la información obtenida y la especificación de requerimientos, se planteó el modelo conceptual para obtener el modelo de entidad relación: Primero se tuvo que hacer una lista de las entidades candidatas, luego una lista con los supuestos dados y no dados (condiciones) y realizar la matriz de entidades en la que se plasman las entidades, relaciones entre sí y la cardinalidad de dichas relaciones. (Ésta matriz trata de refinar o detectar relaciones no halladas anteriormente). Con base al diagrama entidad relación, se especificó el estándar de nombres a manejar en la base de datos; el siguiente paso fue la transformación al modelo relacional y de allí al modelo de tablas para normalizar la base de datos y así eliminar algunos problemas de redundancia, que permitían la optimización mediante un análisis costo-beneficio vs diseño de la Base de Datos. Una vez terminado el modelo de la Base de Datos se realizó el diccionario de datos de la misma.

44

Finalmente, la implementación se hizo mediante la traducción del modelo a sentencias DDL (Data Definition Language, Lenguaje de Definición de Datos) y se realizaron verificaciones mediante pruebas.

Fase de construcción

El equipo de desarrollo generó los diagramas UML y su código fuente para las funciones definidas durante la etapa de diseño y se obtuvo la capacidad operativa inicial. Se tuvo que desarrollar el producto completo de forma iterativa con el fin de que estuviera listo para las pruebas individuales de cada subconjunto de la aplicación y garantizar que se implementaría de acuerdo con las especificaciones. Seguidamente se pudo realizar la transición a los interesados. Los artefactos que se modificaron principalmente en esta fase son los Modelos UML, el Desarrollo del Código fuente, la especificación de los casos de prueba, los resultados de casos de prueba y el plan y cierre de iteración. La implementación del código fuente del MP se realizó con los productos generados por las fases anteriores, en especial las etapas 1 y 2 de la fase de elaboración. Además, se adelantaron las pruebas respectivas para validar el sistema y garantizar el correcto funcionamiento y desempeño de cada parte desarrollada.

Fase de Transición

El equipo de desarrollo probó una versión beta para validar que la liberación del producto cumpliera las expectativas de los usuarios al realizar una integración completa con la plataforma Icaro, y garantizar que el software cumplía con las especificaciones que se plantearon en la lista de requerimientos y requisitos, y hubo lugar a procedimientos correctivos (mantenimiento correctivo) y las actualizaciones secundarias de software (mantenimiento continuo). Además, se generó la documentación correspondiente sobre el manejo y descripción del MP para los usuarios finales, programadores, y a su vez los registros en los artefactos correspondientes tales como el plan y cierre de iteración y la gestión documental. Se construyó un manual de usuario, el cual se enfocó en guiar en la navegación e interacción con el sistema a los usuarios según sus roles, para explicar las opciones disponibles, procesos y estados implícitos de los proyectos en el BPUD. Además, también se construyó el manual técnico, el cual contiene las especificaciones técnicas de la aplicación, para que sea de conocimiento a la hora de realizar mantenimientos o modificaciones al sistema y se cuente con una documentación de calidad.

45

Por último se realizó la integración del módulo de proyectos dentro de la plataforma Icaro, se hicieron las pruebas de desempeño y funcionamiento que garantizaron la combinación y correcto funcionamiento del MP para que sea utilizada por los usuarios finales.

46

6 RESULTADOS Y DISCUSIÓN

6.1 DESCRIPCIÓN DEL MÓDULO

El módulo de proyectos de inversión para el banco de proyectos de la Universidad Distrital es una herramienta para la administración de proyectos de inversión. El módulo tiene tres tipos de roles: Coordinador, es el encargado de cargar documentos informativos, revisar y aprobar el registro de proyectos, hacer el seguimiento de los mismos, realizar los cambios en los procesos de mantenimiento del negocio (habilitar modificaciones a proyectos, aprobar registros, rechazar registros de proyectos.). Gerente, responsable de la información de cada proyecto a cargo ante la universidad, quien además de presentar y ajustar la información de la inscripción y/o modificación de un proyecto, debe gestionar ante la oficina coordinadora del banco de proyectos de la universidad (Coordinador) los cambios cuando haya lugar. Así, el módulo podrá manipular la información individual y agrupada de todos los proyectos con el fin de presentar la información al Coordinador para que éste identifique que proyectos están al día y/o pendientes con el proceso de registro y generar los reportes correspondientes. Finalmente un rol Público que será para todas las personas que quieran consultar la información de los proyectos representada en la ficha EBI-D y documentación informativa disponible sin necesidad de tener un usuario para loguearse en el módulo. Clases principales identificadas para la solución del problema son:

Dependencia: ente o área de la universidad la cual formula el proyecto de

inversión a desarrollar perteneciente a su campo de acción.

Coordinador: es el representante de la Dependencia, y quien estará como

responsable de la ejecución del proyecto de inversión.

Proyecto de inversión: es la propuesta que presenta el Coordinador, supervisado

por la Dependencia con el propósito de cumplir ciertos objetivos ante la sociedad y

la misma Universidad.

47

Metas: Los resultados medibles, concretos, realizables y verificables que se

esperan obtener con la ejecución del proyecto.

Indicadores: Variables o relaciones entre variables que ayudan a caracterizar la

situación o a medir los cambios presentados en ella después de un tiempo o

periodo determinado.

Costo: valor económico que se requiere para cumplir una actividad.

Objetivo: enunciado donde se plasman lo que se considera posible alcanzar,

respecto al problema.

Fuente de financiamiento: especificación de los recursos para el desarrollo del

proyecto.

Eje, Programa y Proyecto: la forma en que el proyecto se inserta en la estructura

del plan estratégico de desarrollo 2007-2016 por el momento.

Plan Distrital: conformado por un eje, un programa y un proyecto.

Política, Estrategia y Programa_Es: la forma en que el proyecto se inserta en la

estructura del plan trienal de la universidad. Son dependientes.

Plan Trienal: Conformado por una política, una estrategia y un programa

6.2 Definición Del Producto A Obtener

El módulo de proyectos está embebido en la plataforma Icaro, su funcionamiento será similar a lo ya implementado, siguiendo los estándares del Distrito y la Universidad Distrital. Para acceder se debe dirigir al sitio web: http://chronos.udistrital.edu.co:8095/Icaro/ Se podrá acceder al Módulo del Banco de Proyectos de tres formas:

1. Coordinador de la Oficina de Proyectos (sesión de Coordinador). 2. Gerente de proyecto de inversión (Sesión de Gerente de proyecto). 3. Público general (sin loguearse).

Cada caso habrá diferentes opciones disponibles y otras similares debido a las características y alcance de cada faceta. El Coordinador del módulo una vez se halla logueado en su panel principal tendrá el número total de alertas correspondientes a los eventos nuevos, tales como proyectos de

http://chronos.udistrital.edu.co:8095/Icaro/

48

inversión registrados y listos para su revisión, actualización de información de los proyectos cuando esto haya sido autorizado y cuando cada proyecto haya sido cargado con la información de avance del mismo mensualmente. Se considera importante que el aspecto de notificaciones se presente como una portada inicial, ya que resalta los últimos eventos que han sucedido en el módulo y que no han sido revisados. Para tener acceso a la descripción detallada de cada evento, se hace mediante el la opción <NOTIFICACIONES > en el menú izquierdo, éste presentará el listado de los eventos en el mismo orden en que se originaron el cual tiene los siguientes campos:

N°: Número acumulado de la notificación (Enumeración). Nombre del Proyecto: Nombre del proyecto dueño de la notificación. Descripción: Asunto a tratar dentro de la notificación. Fecha de publicación: Fecha de creación de la notificación. Ver: Hipervínculo para abrir y poder visualizar la notificación.

Ahora bien, como Coordinador podrá controlar (habilitar/deshabilitar) los tiempos en los cuales ocurren los sucesos en el módulo como son: habilitar modificaciones de los proyectos registrados cuando éste cambio haya sido solicitado por escrito ante la oficina del Banco de Proyectos de la Universidad, asignar códigos BPUD a los proyectos, registrar proyectos, cargar y actualizar documentos e información para los gerentes de proyectos y público en general que accedan al módulo. Esto mediante la sección < ADMINISTRAR > del menú izquierdo. Una opción disponible para los tres tipos de usuarios (con algunas variaciones en cada caso) es la de < CONSULTAR > la cual permite mediante los filtros disponibles realizar una búsqueda de proyectos de inversión. En la sección principal aparecerán las opciones disponibles para que el usuario ingrese el filtro de búsqueda de proyectos: Tipo: Por default el campo se encuentra en blanco, esperando la selección del usuario; Académico, Soporte Institucional o Bienestar Universitario Estado: Por default el campo se encuentra en blanco, esperando la selección del usuario, una vez el usuario despliega la lista se presentará las opciones INSCRITO, REGISTRADO, TERMINADO, SUSPENDIDO, *MIS PROYECTOS (sólo disponible para los usuarios Gerentes de proyectos, esta opción filtra por los proyectos asociados al Usuario), que indican el estado de los proyectos por el cual se quiere filtrar. Resultado por página: Indica el número de proyectos a mostrar por cada página como resultado de la búsqueda según los filtros indicados. 10, 25, 50 y 100

49

Seguido de los filtros de búsqueda, en la parte inferior de la sección se encontrará el resultado de la búsqueda, el cual tiene los siguientes campos.

N°: Número acumulado de los proyectos como resultado de la búsqueda (Enumeración)

Código: ID del proyecto asociado. Nombre: Nombre del proyecto. Dependencia: Nombre de la dependencia proponente del proyecto asociado. Ver descripción detallada: Hipervínculo para abrir y poder visualizar la

información en el formato de la ficha EBI-D del proyecto. La opción < DOCUMENTOS> del menú izquierdo estará disponible para los tres usuarios. Al elegirla, en la sección principal aparecerá el listado de los documentos y formatos disponibles para el usuario, éste listado tiene los siguientes campos:

N°: Número acumulado de los documentos (Enumeración). Nombre: Nombre del documento. Fecha de publicación: Fecha desde la cual el documento se encuentra

disponible en el sitio. Ver: Hipervínculo para abrir y poder visualizar el documento en formato PDF .

Una vez allí, el usuario puede elegir descargarlo. Por otra parte, para el rol/usuario Gerente de proyecto también se considera importante que el aspecto de notificaciones se presente como una portada inicial, ya que resalta los últimos eventos que han sucedido en el proyecto o proyectos a cargo y que no han sido revisados. Para tener acceso a la descripción detallada de cada evento, se hace mediante el la opción <NOTIFICACIONES > en el menú izquierdo, éste presentará el listado de los eventos en el mismo orden en que se originaron con los siguientes campos:

N°: Número acumulado de la notificación (Enumeración). Nombre del Proyecto: Nombre del proyecto dueño de la notificación. Descripción: Asunto a tratar dentro de la notificación. Fecha de publicación: Fecha de creación de la notificación. Ver: Hipervínculo para abrir y poder visualizar la notificación.

Además de la opción anteriormente descrita, este rol también cuenta con la sección < CONSULTAR> para obtener la información de <DOCUEMENTOS> con funcionamiento descrito en el rol de Coordinador con sus variaciones. Para realizar la inscripción de un proyecto se hace mediante la opción < INSCRIBIR > de la sección PROYECTO del menú izquierdo, en el panel principal aparecerá el listado de los proyectos que tiene pendiente por terminar, o la opción para ir a crear el registro de un nuevo Proyecto. Este proceso está dividido en varias secciones, y se podrá guardar en el último formulario para que el gerente pueda continuar con el proceso en otro momento y asegurar que la información se mantenga hasta ese punto.

50

Las secciones se manejan en el siguiente orden:

Identificación y clasificación.

Descripción.

Ubicación

Fuentes de financiamiento.

Metas, indicadores

Relación de Objetivos y metas

Costos.

Las cuales corresponden a las identificadas del archivo de Excel FORMATO SUGERIDO PARA LA PRESENTACIÓN DE PROYECTOS, suministrado por la Oficina Coordinadora de Banco de Proyectos de la Universidad Distrital, el orden en que se presenta tiene una variación al del documento, con el fin de facilitar la manipulación de la información en su almacenamiento.

6.3 REQUERIMIENTOS Los requerimientos para un sistema son descripciones de los que le sistema debe hacer: el servicio que ofrece y las restricciones de su operación. Tales requerimientos reflejan las necesidades de los clientes por sistema que atienda cierto propósito, como sería controlar un dispositivo, colocar un pedido o buscar información. [1].

6.3.1 Requerimientos Funcionales

Los requerimientos funcionales para un sistema refieren lo que el sistema debe hacer. Tales requerimientos dependen del tipo de software que se esté desarrollando, de los usuarios esperados del software y del enfoque general que adopta la organización cuando se escriben los requerimientos. Al expresarse como requerimientos del usuario, los requerimientos funcionales se describen por lo general de forma abstracta que entiendan los usuarios del sistema. Sin embargo, requerimientos funcionales más específicos del sistema detallan las funciones del sistema, sus entradas y salidas, sus excepciones, etcétera. [1].

NÚMERO DEL REQUISITO: 001

NOMBRE DEL REQUISITO: REQ001_REGISTRAR INFORMACIÓN

TIPO: PRIMARIO

RESTRICCIÓN: La naturaleza de los datos debe corresponder al los campos solicitados en los formularios.

REQUISITO: El sistema debe mantener la información consignada en las diferentes secciones del proyecto, sin importar que no todos los campos hayan sido diligenciados.

51

PRIORIDAD ALTA: X MEDIA: BAJA:

DESCRIPCIÓN: El modulo debe permitir registrar y mantener la información del proyecto de inversión durante el periodo de tiempo que requiera el gerente para realizar el registro completo de la inscripción del proyecto, Según los formatos y estándares del Distrito y la Universidad.


NOMBRE DEL REQUISITO: REQ002_REGISTRAR PROYECTO DE INVERSION

TIPO: PRIMARIO

RESTRICCIÓN: La información sobre la descripción del proyecto de inversión formulado debe cumplir con los estándares e intereses de la Universidad y el Distrito.

REQUISITO: Únicamente el Coordinador de la oficina del banco de proyectos puede cambiar el estado de un proyecto de inversión (Inscrito a Registrado).


DESCRIPCIÓN: El modulo debe permitirle al Coordinador cambiar el estado de un proyecto, de Inscrito a Registrado, con el fin de dar el aval e inicio de ejecución de un Proyecto de inversión que estuviera inscrito en el banco de proyectos y cumple con los estándares y requisitos exigidos.


NOMBRE DEL REQUISITO: REQ003_HABILITAR EDICION PROYECTO DE INVERSIÓN REGISTRADO

TIPO: SECUNDARIO

RESTRICCIÓN: Debe existir el proyecto de inversión con estado registrado en el sistema y haberse realizado la solicitud por escrito de los campos requeridos a modificar.

REQUISITO: Habilitar para edición los campos solicitados para un proyectos de inversión que hayan sido avalados y estén disponibles para edición.

PRIORIDAD ALTA: MEDIA: X BAJA:

DESCRIPCIÓN: El Gerente de proyecto mediante solicitud escrita pedirá habilitar la edición de campos descriptores del proyecto de inversión, de aceptarse la solicitud, el Coordinador del Banco de Proyectos de inversión deberá habilitar los campos aprobados para edición de dicho proyecto de inversión.


NOMBRE DEL REQUISITO: REQ004_EDITAR PROYECTO DE INVERSIÓN REGISTRADO

TIPO: SECUNDARIO

RESTRICCIÓN: Deben estar habilitados para edición los campos del proyecto de inversión y deberá diligenciarse información en dichos campos.

REQUISITO: Realizar los cambios de información en los campos habilitados para edición de la información de un proyecto de inversión.

52


DESCRIPCIÓN: El Gerente de proyecto realizará la actualización de la información consignada inicialmente en el proyecto de inversión registrado, en los campos habilitados para edición.


NOMBRE DEL REQUISITO: REQ005_ADMINISTRAR DOCUMENTOS

TIPO: SECUNDARIO

RESTRICCIÓN: N/A. REQUISITO: Cargar archivos y tenerlos disponibles para ser consultados por los usuarios. Eliminar los archivos disponibles para los usuarios.

PRIORIDAD ALTA: MEDIA: BAJA: X

DESCRIPCIÓN: La herramienta debe permitirle al Coordinador cargar documentos para estar disponibles a los Gerentes de proyecto y público general. También debe permitir eliminarlos.


NOMBRE DEL REQUISITO: REQ006_ASIGNAR CODIGO BPUD

TIPO: PRIMARIO

RESTRICCIÓN: Debe haberse registrado el proyecto de inversión para poder asignar el código BPUD.

REQUISITO: Asignar el código BPUD al proyecto de inversión registrado en Icaro.


DESCRIPCIÓN: Asignar el código que genera el registro del proyecto de inversión en SEGPLAN u otro sistema, para unificar los proyectos a nivel interno de la universidad y del Distrito.


NOMBRE DEL REQUISITO: REQ007_GENERAR REPORTES DEL PROYECTO DE INVERSION

TIPO: PRIMARIO

RESTRICCIÓN: Según el estado de los proyectos de inversión se podrá generar el reporte formato ficha EBI-D de la versión del proyecto

REQUISITO: Generar el reporte estructura ficha EBI-D


DESCRIPCIÓN: La herramienta debe permitir generar los distintos reportes para los proyectos de inversión existentes.

53


NOMBRE DEL REQUISITO: REQ008_GENERAR NOTIFICACIONES

TIPO: SECUNDARIO

RESTRICCIÓN: N/A. REQUISITO: Registrar observaciones a un proyecto de inversión cuando se ha realizado un cambio sobre este y debe informarse a al coordinador o al gerente del proyecto según el caso.


DESCRIPCIÓN: Cuando el coordinador aprueba una solicitud de registro de un proyecto, o los cambios sobre un proyecto que estaba en edición o rechaza la solicitud de revisión, habilita un proyecto para edición, asignan código BPUD se genera una notificación al responsable de la información de dicho proyecto la cual debe estar disponible en todo momento para este. Si un gerente de proyecto solicita una inscripción o revisión de proyecto se genera la notificación dirigida al coordinador de OAPC.


NOMBRE DEL REQUISITO: REQ009_CONSULTAR DOCUMENTACION

TIPO: SECUNDARIO

RESTRICCIÓN: N/A. REQUISITO: N/A


DESCRIPCIÓN: Cualquiera de los usuarios del módulo puede tener acceso a los documentos habilitados para el rol correspondiente, visualizarlos y/o descargarlos.


NOMBRE DEL REQUISITO: REQ010_GENERAR VERSIONAMIENTO DE LOS PROYECTOS

TIPO: SECUNDARIO

RESTRICCIÓN: N/A. REQUISITO: El coordinador de la OAPC acepta los cambios realizados sobre un proyecto previamente registrado y que se encontraba habilitado para edición.


DESCRIPCIÓN: La aprobación de la información registrada para un proyecto de inversión que se encontraba en edición y había realizado la solicitud de revisión genera automáticamente una nueva versión de dicho proyecto lo que permite mantener un seguimiento de los cambios sobre el proyecto.

54

6.3.2 Requerimientos No Funcionales

Los requerimientos no funcionales, como lo indica su nombre, son requerimientos que no se relacionan directamente con los servicios específicos que el sistema entrega a sus usuarios. Pueden relacionarse con propiedades emergentes del sistema, como fiabilidad, tiempo de respuesta y uso de almacenamiento. De forma alternativa pueden definir restricciones sobre la implementación del sistema, como las capacidades de los dispositivos I/O o las representaciones de datos usados en las interfaces con otros sistemas.

Los requerimientos no funcionales surgen a través de necesidades del usuario, debido a restricciones presupuestales de la organización, necesidad de interoperabilidad con otro software o sistemas de hardware, o factores externos como regulaciones de seguridad o legislación sobre privacidad. [1].

La persistencia de los datos del módulo se hace mediante DAOS dentro de la base de datos Postgres para tratar la información como objetos.

La interfaz de usuario implementa las especificaciones de la plataforma Icaro existente agregando algunas características tecnológicas que permiten mejorar el envió y tratamiento de la información.

6.3.3 Requerimientos De Interfaces De Usuario

La interfaz gráfica de usuario, sigue las normas ya implementadas en la plataforma

Icaro, además está orientada para que su uso sea intuitivo para el usuario. La

comunicación con el usuario es importante, por esto el módulo notifica al usuario cada

vez que existan cambios en los proyectos inscritos, registrados y/o en ejecución en su

poder.

Un aspecto primordial es poder dar informe del contenido y estado de ejecución de los

proyectos de forma fácil, veraz y oportuna, ya que uno de los mayores propósitos de la

herramienta es la de generar los reportes solicitados con la información actualizada a la

fecha.

6.3.4 Requerimientos De Persistencia

Es necesario el uso de un gestor de bases de datos, para realizar el manejo de la persistencia del módulo. La persistencia de datos se realiza mediante el uso de Daos cada vez que se realiza una acción CRUD en el módulo para tratar la información.

55

6.4 MODELADO UML (UNIFIED MODELING LANGUAGE) El UML, el lenguaje unificado de modelado, es un estándar para visualizar, especificar, construir y documentar los diferentes componentes de un sistema de información, el cual involucra una gran cantidad de software y desarrollos fundamentados en paradigmas de la programación orientada a objetos. UML es un lenguaje notacional simbólico, que cubre todas las vistas necesarias para el desarrollo de un sistema de información, así como todas las fases del proceso de desarrollo de software, del análisis y diseño de la implementación. [2]

6.4.1 Notación De Identificadores

Acorde a la mayoría de lenguajes de programación y recomendaciones, para el desarrollo del código de la aplicación, usaremos la notación dromedary Case, la cual consiste en escribir los identificadores de las clases en minúscula, pero cuando se conforman por dos o más palabras la inicial de las siguientes palabras debe ir en mayúscula. (Ejemplo: moduloInversion). Cabe recordar que la primera letra del nombre de las clases es en mayúscula.

6.4.2 Estructura planteada

Al revisar la definición del problema del módulo de proyecto de inversión, se encuentran los siguientes sustantivos que conformarán las clases en el diseño estructural, además se presentan con la notación de identificadores que se trabajará: Costo Dependencia Eje Estrategia Fuente_Financiamiento Indicador

Meta Objetivo Plan distrital Política Programa Programa_Es

Proyecto Proyecto_Inversion Version Persona Componente Plan trienal

6.4.3 Definición capa de atributos.

Las clases concretas presentan atributos que representan la abstracción de características especiales de los objetos del mundo real y necesario para la emulación del comportamiento de los mismos. Los atributos para cada una de las clases se pueden consultar en el diccionario de Clases. Anexo 10.2.2.

56

6.4.4 Definición capa de métodos.

Toda clase implementa los métodos básicos: set y get para manipular cada uno de sus atributos u objetos, además también tienen otros métodos para realizar determinados procedimientos que involucran una secuencia lógica un poco compleja, e implican recursividad. Los métodos de cada clase se pueden consultar en el diccionario de clases, anexo 10.2.2.

6.4.5 Diagrama de Clases

El diagrama de clases recoge todos los conceptos significativos en el dominio de la aplicación, o dicho de otra manera, define cuál es la información (los “datos”) que necesita conocer (y guardar) el software con el fin de dar respuesta a las peticiones del usuario. El diagrama de clases es la visión estática del sistema. [3] El diagrama de Clases se puede consultar en el anexo 10.2.3.

6.4.6 Diccionario de clases

El diccionario de clases contiene una listado de las características de atributos y métodos, con el fin de dar precisión sobre los datos que se manejan en el sistema evitando malas interpretaciones o ambigüedades, además una descripción de la razón de existencia de las clases. El diccionario se puede consultar en el anexo 10.2.2.

6.4.7 Casos De Uso

Los casos de usos son una técnica que se basa en escenarios para la obtención de requerimientos funcionales ya que documenta una secuencia de interacción completa entre el software y un actor o más cuando el usuario requiere un servicio del sistema. Dicha interacción debe ser una función autónoma dentro del software. A continuación se presentan los tres casos de interacción según los actores en el módulo

57

Ilustración 7. Casos de uso para cada rol del Módulo de proyectos

.

6.4.8 Especificación De Casos Uso En Formato Expandido

A continuación se presentan los casos de uso junto con cada formato expandido correspondiente para cada rol, los diagramas de actividades se encuentran en el anexo 10.2.5.

6.4.8.1 Escenario: Actor público

Ilustración 8. Casos de uso rol público

Nombre Caso de uso

Configurar Módulo

Actores Público

Tipo Configuración

Propósito Presentar al usuario las opciones del módulo de inversión correspondientes al perfil/rol asociado.

uc Público

System Boundary

Configurar Módulo

Publico

Consultar

Documentación

Generar Reporte

«extend»

«extend»

58

Descripción Este caso de uso es iniciado por el usuario para configurar y visualizar las opciones del módulo de inversión correspondientes al rol/perfil asociado al usuario público.

Precondiciones Encontrarse en la plataforma Icaro y haber seleccionado la opción <<Módulo de inversión>> del menú principal.

Curso básico de eventos

Actor Sistema

Público Público

Al seleccionar la opción <<Módulo de Inversión>> en el menú principal el sistema verificará si el usuario ya ha iniciado sesión (está logueado) en la plataforma, de no ser así, configura y presenta el menú correspondiente al usuario. En el menú aparecerán las opciones para CONSULTA de <<Proyectos>> y <<Documentación>> y se muestra en el panel principal la imagen de bienvenida al módulo Para CONSULTA:

Si el usuario elige la opción << Proyectos>> se inicia el sub-flujo (S-1) el cual le permitirá buscar proyectos de inversión registrados en la base de datos.

Si el usuario elige la opción <<Documentación>> se inicia el sub-flujo (S-2) el cual listará los documentos informativos sobre el módulo que el usuario tenga disponibles para consultar.

Sub-flujos (S-1) Consultar y generar reporte ficha EBI-D para un proyecto de inversión. (S-2) Consultar y descargar la documentación general.

Excepciones Ninguna.

Pos-condiciones Se despliega en el menú principal las opciones correspondientes al perfil/rol. Se despliega la imagen de bienvenida al módulo.

Nombre Caso de uso

Generar Reporte

Actores Público

Tipo Consulta

Propósito Presentar la información del proyecto de inversión consultado en formato ficha EBI-D de una versión disponible de un proyecto

Descripción Este caso de uso es iniciado por el usuario, le permite elegir la versión del proyecto de inversión elegido para visualizar, además podrá descargar el reporte en formato PDF.

Precondiciones Deben existir proyectos de inversión.


Actor Sistema

Público Al elegir la opción <<Proyectos>> de la sección CONSULTA del

59

Público Público Público Público

menú izquierdo se presenta en el panel principal el filtro para realizar la búsqueda del proyecto de inversión (P-1) del cual se quiere visualizar la información. En el primer filtro podrá elegir el tipo de proyecto: Académico, Bienestar Institucional o Soporte Institucional, en el segundo filtro uno de los estados (Inscrito, Registrado, Suspendido, Mis Proyectos), si lo desea puede ampliar número de proyectos listados como resultado de la búsqueda en el tercer filtro (10, 25, 50 y 100).

Al elegir la opción Inscrito, la búsqueda se enfocará en los proyectos de inversión cuyo estado sea Inscrito, es decir aun no haya sido aprobado para registro por parte de la Oficina Coordinadora del Banco de Proyectos de la Universidad Distrital.

Al elegir la opción Registrado, la búsqueda se enfocará en los proyectos de inversión cuyo estado sea Registrado, es decir ya ha sido aprobado el registro por parte de la Oficina Coordinadora del Banco de Proyectos de la Universidad Distrital y puede estar en ejecución.

La opción Mis Proyectos aunque aparece en el filtro, no retornará ningún resultado puesto que esta opción solo estará activa para los Gerentes de proyectos

Al elegir la opción <<Filtro>> si existen proyectos de inversión que coincidan con los parámetros de la búsqueda aparecerán listados se mostrará el código del proyecto de inversión, el nombre del proyecto y el nombre del responsable o gerente de proyecto junto a cada proyecto listado un icono que los llevará a la siguiente parte del proceso. Al hacer clic sobre el icono junto al proyecto del cual se desea consultar la información, aparecerá en el panel principal la información correspondiente a la versión actual del proyecto en el formato de la ficha EBI-D, si el proyecto ha tenido cambios a través del ciclo de vida, es decir más de una versión, podrá consultarse la versión que haya tenido el proyecto hasta la fecha seleccionándola en la parte superior del reporte y dando clic en la opción <<Consultar>>. Una vez realizado lo anterior se deberá visualizar la información del proyecto de inversión correspondiente a la versión elegida. Opción <<PDF>>: Genera el PDF de la información visualizada y permite descargarla.

60

Sub-flujos Ninguno.


Pos-condiciones Se visualiza la información del proyecto en su versión más reciente en el formato ficha EBI-D.

Nombre Caso de uso

Consultar documentación

Actores Público

Tipo Consulta

Propósito Presentar y permitir descargar al usuario la documentación existente en el módulo.

Descripción Este caso de uso es iniciado por el usuario Público, con el fin de visualizar y permitirle elegir descargar los documentos disponibles para su rol/perfil en el módulo

Precondiciones Ser un usuario no logueado en la plataforma Icaro.


Actor Sistema

Público Público

Al haber seleccionado la opción <<Documentación>> en el menú principal el sistema lista en el panel principal los documentos disponibles ordenados de forma descendente por fecha, seguido por el nombre del documento y un icono para ser consultados y descargados por el usuario. Al hacer clic sobre el icono de pdf en cualquiera de los documentos listados, se podrá visualizar el contenido del mismo si es una archivo PDF, de lo contrario se iniciará el proceso de descarga.

Sub-flujos Ninguno

Excepciones (E-1) No existen documentos disponibles.

Pos-condiciones Se visualizarán los documentos disponibles para el usuario.

61

6.4.8.2 Escenario: Gerente de proyecto

Ilustración 9. Casos de uso para el rol Gerente de proyecto

Nombre Caso de uso

Configurar Módulo

Actores Gerente de proyecto, Publico

Tipo Configuración


Descripción Este caso de uso es iniciado por el usuario para configurar y visualizar las opciones del módulo de inversión correspondientes al rol/perfil asociado al usuario Gerente de proyecto.


62


Actor Sistema

Gerente de proyecto Gerente de proyecto Gerente de proyecto

Al seleccionar la opción <<Módulo de Inversión>> en el menú principal el sistema verificará si el usuario ya ha iniciado sesión (está logueado) en la plataforma, de ser así y si es un Gerente de proyecto, se configura y presenta el menú correspondiente al usuario. En el menú aparecerán las secciones CONSULTAR y PROYECTO. Las opciones <<Notificaciones>>, <<Proyectos>> y <<Documentación>> se encuentran en la sección CONSULTAR, en PROYECTO <<Inscribir>> y <<Modificar>>, por último se muestra el mensaje de bienvenida al módulo en el panel principal. Para CONSULTAR:

Si el usuario elige la opción <<Notificaciones>> se inicia el sub-flujo (S-1) el cual le permitirá visualizar las notificaciones que tiene pendientes por revisar.

Si el usuario elige la opción <<Proyectos >> se inicia el sub-flujo (S-2) el cual le permitirá buscar proyectos de inversión registrados en la base de datos.

Si el usuario elige la opción <<Documentación>> se inicia el sub-flujo (S-3) el cual listará los documentos infamativos sobre el módulo que el usuario tenga disponibles para consultar.

Para PROYECTO:

Si el usuario elige la opción <<Inscribir>> se inicia el sub-flujo (S-4) el cual le permitirá inscribir, registrar proyectos.

Si el usuario elige la opción <<Modificar>> se inicia el sub-flujo (S-5) el cual le permitirá modificar proyectos.

Sub-flujos (S-1) Consular notificaciones pendientes por revisar. (S-2) Buscar proyectos de inversión registrados. (S-3) Consultar y descargar la documentación general. (S-4) Inscribir y registrar proyectos. (S-5) Modificar proyectos.


Pos-condiciones Se despliega en el menú principal las opciones correspondientes al perfil/rol. Se presenta el en el panel principal la bienvenida al módulo de proyectos de inversión.

63

Nombre Caso de uso

Consultar documentación

Actores Gerente del Proyecto

Tipo Consulta

Propósito Presentar y permitir descargar al usuario la documentación existente en el módulo.

Descripción Este caso de uso es iniciado por el usuario Gerente, con el fin de visualizar y permitirle elegir descargar los documentos disponibles para su rol/perfil en el módulo

Precondiciones Ser un usuario en la plataforma Icaro con un rol de Gerente.


Actor Sistema

Gerente del Proyecto Gerente del Proyecto

Al haber seleccionado la opción <<Documentación>> en el menú principal, se lista en el panel principal los documentos disponibles ordenados de forma descendente por fecha, seguido por el nombre del documento y un icono para ser consultados y descargados por el usuario. Al hacer clic sobre el icono de pdf en cualquiera de los documentos listados, se podrá visualizar el contenido del mismo si es una archivo PDF, de lo contrario se iniciará el proceso de descarga.

Sub-flujos Ninguno

Excepciones (E-1) No existen documentos disponibles.

Pos-condiciones Se visualizarán los documentos disponibles para el usuario.

Nombre Caso de uso

Generar Reporte

Actores Gerente de proyecto

Tipo Consulta

Propósito Presentar la información del proyecto de inversión consultado en formato ficha EBI-D

Descripción Este caso de uso es iniciado por el usuario, le permite elegir la versión del proyecto de inversión elegido, además podrá descargar el reporte en formato PDF.

Precondiciones Deben existir proyectos de inversión en ejecución.


Actor Sistema

Gerente del Proyecto Gerente del Proyecto

Al elegir la opción <<Proyectos>> de la sección CONSULTA del menú izquierdo se presenta en el panel principal el filtro para realizar la búsqueda del proyecto de inversión (P-1) del cual se quiere visualizar la información. En el primer filtro podrá elegir el tipo de proyecto: Académico, Bienestar Institucional o Soporte Institucional, en el segundo filtro uno de los estados (Inscrito, Registrado, Suspendido, Mis

64

Gerente del Proyecto Gerente del Proyecto Gerente del Proyecto Gerente del Proyecto

Proyectos), si lo desea puede ampliar número de proyectos listados como resultado de la búsqueda en el tercer filtro (10, 25, 50 y 100).



La opción Mis Proyectos, la búsqueda se enfocara en los proyectos en los cuales el usuario este como responsable de la información.


Sub-flujos Ninguno.


Pos-condiciones Se visualizará un proyecto de inversión en formato ficha EBI-D

65

Nombre Caso de uso

Consultar Notificación


Tipo Consulta

Propósito Presentar en el panel principal el listado de las notificaciones de los proyectos a cargo los cuales han tenido alguna actualización, cambio de estado u observación por parte del coordinador de la OCBPUD.

Descripción Este caso de uso es iniciado por el usuario, le permite visualizar la descripción de sobre la actualización realizada por la OCBPUD sobre los proyectos a su cargo.

Precondiciones El coordinador de la OCBPUD debe haber realizado algún cambio y/o actualización en un proyecto del gerente para enviarle una notificación.


Actor Sistema

Gerente de proyecto Gerente de proyecto

Al elegir del menú la opción <<Notificaciones>> de la parte sección CONSULTAR se presenta en el panel principal la descripción de la notificación del proyecto o cambio de vigencia realizado por el coordinador ordenadas de forma descendente por la fecha en la que se generó. A demás podrá detallar la notificación dando click en la opción <<Ver>> de cada notificación. Opción <<Ver>>: El sistema despliega una ventana emergente la cual permite visualizar la información asociada a la notificación seleccionada.

Sub-flujos Ninguno.


Pos-condiciones El usuario habrá visualizado el motivo de la alerta generada para los proyectos a cargo.

Nombre Caso de uso

Inscribir Proyecto

Actores Gerente de proyecto de proyecto

Tipo Inclusión

Propósito Registrar la información de un proyecto de inversión en el banco de proyectos de la Universidad Distrital.

Descripción Este caso de uso es iniciado por el usuario, le permite visualizar las secciones y campos de la información que debe ingresar para realizar la inscripción del proyecto de inversión.

Precondiciones Ninguna.


Actor Sistema

Gerente de proyecto

Al seleccionar del menú principal la opción <<Inscribir>> de la sección PROYECTO se muestra en el panel principal una lista de proyectos pendientes por terminar de registrar información si existen, con la opción <<Terminar>> también se presentará en el

66

Gerente de proyecto Gerente de proyecto Gerente de proyecto Gerente de proyecto Gerente de proyecto

panel principal la opción de <<Nuevo Proyecto>> para empezar el registro de un nuevo proyecto de inversión. Si no existen proyectos pendientes por terminar de registrar se presentará inmediatamente el formulario de inscripción de proyectos con las secciones respectivas para ingresar la información. Opción <<Terminar>>: Al haber seleccionado un proyecto de inversión de los listados, se presentará en el panel principal el formulario de inscripción de proyecto con la información almacenada en cada una de las secciones del proyecto para continuar de diligenciar y finalizar la inscripción. Opción <<Nuevo Proyecto>>: Esta opción está en la interfaz es el icono del más que esta al final de la hoja. Se presenta el formulario de inscripción de proyectos, con los campos vacios en las respectivas secciones. Una vez el usuario ha terminado de ingresar la información en los campos de las secciones del formulario: Identificación y Clasificación, Descripción, ubicación del proyecto, Fuentes de Financiamiento, Metas e indicadores y Costos y al estar en el formulario final que presenta un resumen, puede elegir alguna de las opciones: <<Guardar>> o <<Inscribir>>. Opción <<Guardar>>: Si los campos mínimos obligatorios (Nombre del proyecto) fueron diligenciados, y no existe otro proyecto con el mismo nombre en el banco de proyectos, se almacena en la base de datos la información del Proyecto de inversión para continuar con el registro en otro momento y se asigna el estado de “En proceso”. Opción <<Inscribir>> Si todos los campos de las distintas secciones del formulario de Inscripción fueron diligenciadas el usuario podrá hacer la inscripción del proyecto, el sistema validará si no existe un proyecto en la bases de datos con el mismo nombre, si no existe entonces la información es registrada en la base de datos y es asignado al proyecto de inversión el estado de “Inscrito”. Adicionalmente se generará la notificación hacia el Coordinador de la OCBPUD solicitando el registro del proyecto con la opción

Sub-flujos Ninguno.

Excepciones (E-1) Campos obligatorios en blanco. (E-2) El nombre del proyecto de inversión ya se encuentra registrado en la base de datos. (E-3) El tipo de dato no corresponde al esperado en el campo.

67

Pos-condiciones Se habrá almacenado en la base de datos un proyecto de inversión con estado “En proceso” o “Inscrito”. Se habrá generado una notificación al Coordinador de OAPC si se ha inscrito un proyecto.

Nombre Caso de uso

Modificar proyecto


Tipo Inclusión

Propósito Permite al gerente de proyecto modificar la información registrada en campos de las secciones del formulario del proyecto, el proyecto estará habilitado para edición si ha sido autorizado por el Coordinador de la OCBPUD.

Descripción Este caso de uso es iniciado por el usuario, le permite visualizar las secciones y campos de la información que debe ingresar para realizar la modificación del proyecto de inversión.

Precondiciones El proyecto debe estar habilitado para la edición de información en los campos.


Actor Sistema

Gerente de proyecto Gerente de proyecto Gerente de proyecto

Al haber seleccionado la opción <<Modificar>> de la sección PROYECTO, se presentará en el panel principal la lista de los proyectos de inversión registrados de los cuales el usuario es gerente y que además han sido autorizados por el Coordinador de la OCBPUD para ser editados. De existir proyectos que cumplen las anteriores condiciones, aparecerá habilitada la opción <<Modificar>>. Opción <<Modificar >>: Si el usuario ha seleccionado un proyecto listado para edición, en el panel principal aparecerá el formulario de inscripción del proyecto de inversión con la información que fue registrado. El usuario podrá navegar entre las diferentes secciones del proyecto (Identificación y Clasificación, Descripción, Fuentes de Financiamiento, Localización, Metas e Indicadores, para visualizar la información y además, poder modificar la información contenida en los campos que fueron autorizados para edición. Al final del formulario el usuario encontrar las opciones <<Inscribir>> y <<Guardar>>. Opción <<Guardar>>: Si los campos mínimos obligatorios (Nombre del proyecto) fueron diligenciados, y no existe otro proyecto con el mismo nombre en el banco de proyectos o con código interno al actual igual, se almacena en la base de datos la información del Proyecto de inversión para continuar con la modificación en otro momento.

68

Gerente de proyecto

Opción <<Inscribir>> Si todos los campos de las distintas secciones del formulario de Inscripción fueron diligenciadas el usuario podrá hacer la inscripción del proyecto, el sistema validará si no existe un proyecto en la bases de datos con el mismo nombre o con código interno al actual igual, entonces la información es registrada en la base de datos. Adicionalmente se generará la notificación hacia el Coordinador de la OCBPUD solicitando la revisión de los cambios realizados al proyecto.

Sub-flujos Ninguno.

Excepciones (E-1) Campos obligatorios en blanco. (E-2) Tipo de dato no coincide con el esperado. (E-3) Ya existe un proyecto con el mismo nombre en la base de datos.

Pos-condiciones Se habrá actualizado la información de los campos permitidos para edición en un proyecto de inversión Se desactiva la edición de la versión del proyecto.

69

6.4.8.3 Escenario: Coordinador OCBPUD

Ilustración 10. Casos de uso para el rol Coordinador OAPC

70

Nombre Caso de uso

Configurar Módulo

Actores Coordinador OCBPUD

Tipo Configuración


Descripción Este caso de uso es iniciado por el usuario para configurar y visualizar las opciones del módulo de inversión correspondiente al rol/perfil asociado al usuario Coordinador OCBPUD.



Actor Sistema

Coordinador OCBPUD Coordinador OCBPUD Coordinador OCBPUD

Al seleccionar la opción <<Módulo de Inversión>> en el menú principal el sistema verificará si el usuario ya ha iniciado sesión (está logueado) en la plataforma, de ser así y si es un Gerente de proyecto, se configura y presenta el menú correspondiente al usuario. En el menú se presentara las secciones CONSULTA y ADMINISTRAR. Las opciones para la sección CONSULTA son <<Notificaciones>>, <<Proyectos>>, para la sección ADMINISTRAR son <<Asignar Código BPUD>>, <<Activar Edición de un Proyecto>> y <<Cargar Documentos>>, finalmente se muestra el mensaje de bienvenida al módulo. Para CONSULTA:

Si el usuario elige la opción <<Notificaciones>> se inicia el sub-flujo (S-1) el cual le permitirá visualizar las notificaciones que tiene pendientes por revisar.

Si el usuario elige la opción <<Proyectos >> se inicia el sub-flujo (S-2) el cual le permitirá buscar proyectos de inversión registrados en la base de datos.

Para ADMINISTRAR:

Si el usuario elige la opción << Registrar Proyecto>> se inicia el sub-flujo (S-3) el cual le permitirá revisar un a uno los formularios de inscripción con la información de proyecto que ha solicitado al revisión y decidir si aprueba o rechaza dicha información.

Si el usuario elige la opción <<Asignar Código BPUD>> se inicia el sub-flujo (S-4) el cual le permitirá asignar el código generado por SEGPLAN u otro identificador a un proyecto de inversión dentro de la universidad.

71

Si el usuario elige la opción <<Activar Edición de un Proyecto>> se inicia el sub-flujo (S-5) el cual le permitirá activar algunos campos en la definición de un proyecto para que sean editados por el gerente.

Si el usuario elige la opción << Administrar Documentos >> se inicia el sub-flujo (S-6) el cual le permitirá cargar o eliminar los documentos para cada uno de los roles que utilizan el sistema.

Sub-flujos (S-1) Consular notificaciones pendientes por revisar. (S-2) Buscar proyectos de inversión registrados. (S-3) Revisión de Proyectos. (S-4) Asignar código BPUD. (S-5) Activar edición de un Proyecto. (S-6) Carga de Documentación.


Pos-condiciones Se despliega en el menú principal las opciones correspondientes al perfil/rol. Se presenta el en el panel central la bienvenida al módulo de planeación.

Nombre Caso de uso

Generar Reporte


Tipo Consulta

Propósito Presentar la información del proyecto de inversión consultado en el formato ficha EBI-D de una versión del proyecto.

Descripción Este caso de uso es iniciado por el usuario, le permite elegir la versión de información del proyecto de inversión elegido visualizar, además podrá descargar el reporte en formato PDF.

Precondiciones Deben existir proyectos de inversión en ejecución.


Actor Sistema

Coordinador OCBPUD Coordinador OCBPUD

Al elegir la opción <<Proyectos>> de la sección CONSULTA del menú izquierdo se presenta en el panel principal el filtro para realizar la búsqueda del proyecto de inversión (P-1) del cual se quiere visualizar la información. En el primer filtro podrá elegir el tipo de proyecto: Académico, Bienestar Institucional o Soporte Institucional, en el segundo filtro uno de los estados (Inscrito, Registrado, Suspendido, Mis Proyectos), si lo desea puede ampliar número de proyectos

72

Coordinador OCBPUD Coordinador OCBPUD Coordinador OCBPUD Coordinador OCBPUD

listados como resultado de la búsqueda en el tercer filtro (10, 25, 50 y 100).



La opción Mis Proyectos aunque aparece en el filtro, no retornará ningún resultado puesto que esta opción solo estará activa para los Gerentes de proyectos


Sub-flujos Ninguno.


Pos-condiciones Se visualizará la información de una versión de un proyecto de inversión.

73

Nombre Caso de uso

Consultar Notificación


Tipo Consulta/ actualización

Propósito Presentar en el panel principal el listado de notificaciones sobre los proyectos de inversión que hayan tenido alguna actualización por parte del gerente de proyecto respectivo.

Descripción Este caso de uso es iniciado por el usuario, le permite visualizar la descripción de las actualizaciones realizadas por el gerente de proyecto en un proyecto de inversión.

Precondiciones El gerente debe haber realizado algún cambio y/o actualización en un proyecto del gerente para enviarle una notificación.


Actor Sistema

Coordinador OCBPUD Coordinador OCBPUD

Al elegir del menú la opción <<Notificaciones>> de la sección CONSULTAR se presenta en el panel principal la descripción de la notificación del proyecto o cambio de vigencia realizado por el coordinador ordenadas de forma descendente por la fecha en la que se generó. A demás podrá detallar la notificación dando clic en la opción <<Ver>> de cada notificación. Opción <<Ver>>: El sistema despliega una ventana emergente en la cual complementa la información asociada a la notificación seleccionada.

Sub-flujos Ninguno.


Pos-condiciones El usuario habrá visualizado el motivo de la alerta generada para los proyectos de inversión.

Nombre Caso de uso

Registrar Proyecto


Tipo Inclusión

Propósito Cambiar el estado Inscrito de un proyecto de inversión a Registrado

Descripción Este caso de uso es iniciado por el usuario con el fin de aceptar la propuesta de un proyecto de inversión según la información consignada en el formulario de inscripción. Este cambio de estado permite poder ingresar mensualmente el reporte de avance.

Precondiciones Deben existir proyectos de inversión inscritos que hayan solicitado el registro.

74


Actor Sistema

Coordinador OCBPUD Coordinador OCBPUD Coordinador OCBPUD Coordinador OCBPUD Coordinador OCBPUD

Al elegir la opción <<Registrar proyecto>> de la sección ADMINISTRAR del menú principal, se listaran en el panel principal los proyectos de inversión con estado Inscrito que han solicitado la aprobación de la oficina coordinadora del banco de proyectos para pasar a estado Registrado. Al elegir el proyecto de inversión de los listados aparecerá en el panel principal la información de dicho proyecto, podrá navegar por los formularios de inscripción y al finalizar visualizar un resumen del mismo y campo para registrar los comentarios y observaciones al respecto y las opciones <<Registrar>> y <<Rechazar>> Si se desea registrar comentarios, observaciones o alguna inquietud para orientar o comunicar, la información se debe registrar en el campo en blanco disponible indicado. Al hacer clic en la opción <<Registrar>> se realizará el cambio de estado del proyecto de inversión de Inscrito a Registrado y si existen Observaciones se notificará el contenido al gerente responsable del proyecto de inversión. Al hacer clic en la opción <<Rechazar>> no se realizará ningún cambio de estado del proyecto de inversión, y deberá existir información en el campo de Observaciones para notificar el contenido al gerente responsable del proyecto de inversión lo cual corresponde al motivo del rechazo del registro del proyecto. Además, el sistema generará la notificación sobre la actualización del proyecto de inversión la cual estará disponible únicamente para el gerente del proyecto de inversión asociado.

Sub-flujos Ninguno.

Excepciones (E-1) La campo información suministrada no tiene un formato válido o esta vacio.

Pos-condiciones El proyecto de inversión habrá cambiado de estado inscrito a registrado, o habrá sido rechazada la solicitud.

Nombre Caso de uso

Habilitar Edición


Tipo Configuración

Propósito Permitir al coordinador del modulo de proyectos de inversión habilitar para edición un proyecto de inversión registrado.

Descripción Este caso de uso es iniciado por el usuario con el objetivo se seleccionar y configurar los campos y/o secciones del formulario

75

de inscripción de un proyecto de inversión ya registrado en el módulo.

Precondiciones Ninguna.


Actor Sistema

Coordinador OCBPUD Coordinador OCBPUD Coordinador OCBPUD

Al elegir la opción <<Activar Edición de un Proyecto>> en la sección ADMINISTRAR del menú izquierdo, en el panel principal aparecerá un campo (Código BPUD Del Proyecto) para ingresar el código del BPUD del proyecto de inversión para realizar la búsqueda en el sistema. Al dar clic en la opción <<Validar>> se realizará la búsqueda en el sistema del proyecto de inversión asociado a dicho código de BPUD, si existe coincidencia en el sistema, en el segundo campo Nombre Proyecto se mostrará el nombre del proyecto de inversión perteneciente a dicho código de BPUD. De retornar una coincidencia en el paso anterior, al dar clic en la opción <<Modificar>> se realiza el registro en la base de datos la versión editable para dicho proyecto. Además, el sistema generará la notificación sobre la habilitación de edición del proyecto de inversión la cual estará disponible únicamente para el gerente del proyecto de inversión asociado.

Sub-flujos Ninguno.

Excepciones (E-1) No existen un proyecto con el código BPUD asociado

Pos-condiciones Se habrán habilitado campos o secciones para edición de un proyecto de inversión y se habrá enviado la notificación al gerente del proyecto asociado.

Nombre Caso de uso

Asignar Código BPUD


Tipo Inclusión

Propósito Permitir al usuario asignar a un proyecto de inversión el código que SEGPLAN asignó a dicho proyecto o por otro motivo.

Descripción Este caso de uso es iniciado por el Coordinador OCBPUD, con el fin de asignar el código de BPUD al proyecto de inversión para que haya correspondencia entre el Módulo de proyectos de la plataforma Icaro y SEGPLAN u otro sistema.

Precondiciones Deben existir un proyecto registrado.

76


Actor Sistema


Al elegir la opción <<Registrar Código BPUD >> en la sección ADMINISTRAR del menú principal, aparecerá en el panel principal tres campos para presentar la información del proyecto al cual se va modificar el Código de BPUD. Ingresar el código interno del proyecto en el primer campo Código Interno Del Proyecto. Al elegir la opción <<Consultar>> el sistema buscará los proyectos con estado registrado cuyo código interno sea el ingresado por el usuario en el primer campo. Si existe coincidencia, se presentará el nombre del proyecto de inversión en el segundo campo y si ya tiene un código de BPUD asignado, éste se presentará en el tercer campo. Una vez el sistema haya retornado el resultado de la consulta, se habilitará para ingresar el código de BPUD en el campo Código BPUD. Al elegir la opción <<Guardar>> si existe coincidencia del código interno de un proyecto de inversión con el ingresado en el primer campo y con el nombre que fue presentado como resultado de la validación, se actualizará a dicho registro el Código se BPUD para el proyecto de inversión. Además, el sistema generará la notificación sobre la actualización del proyecto de inversión la cual estará disponible únicamente para el gerente del proyecto de inversión asociado.

Sub-flujos Ninguna.

Excepciones (E-1) No existe un proyecto asociado al código interno y nombre del proyecto de inversión.

Pos-condiciones El proyecto de inversión tendrá asignado el mismo código que fue generado por SEGPLAN u otro sistema.

Nombre Caso de uso

Administrar Documentación


Tipo Inclusión

Propósito Permitir al usuario eliminar y cargar documentos para ser publicados y estar disponibles para los usuarios del módulo de proyectos de inversión.

Descripción Este caso de uso es iniciado por el usuario, le permite administrar (eliminar y cargar) los documentos para estar disponibles en el módulo de proyectos de inversión para cada uno de los tipos de usuarios.

Precondiciones Ser coordinador y haber elegido la opción <<Documentos>>.

77


Actor Sistema


Si ha elegido la opción <<Administrar Documentos>> de la sección ADMINISTRAR del menú izquierdo, en el panel principal aparecerá el listado de los documentos publicados disponibles en el módulo de proyectos, subdivididos por los grupos a los que va dirigidos (Público, Gerentes de proyectos y Coordinador), para cada grupo se presentan las opciones Seleccionar, Agregar, Consultar y Eliminar. Si elige la opción <<Seleccionar>>, emergerá una ventana en la cual podrá navegar por el directorio del equipo para buscar y elegir el archivo a cargar, una vez haya seleccionado el archivo, podrá visualizar el nombre junto al botón <<Seleccionar>> Al elegir la opción <<Agregar>> el documento deberá cargarse a la lista de documentos del grupo respectivo que aparece en el panel principal. Si elige la opción <<Eliminar>> perteneciente a cada documento, éste debería eliminarse de la lista del grupo. Si elige la opción <<Consultar>> se visualizará el documento correspondiente.

Sub-flujos Ninguno

Excepciones (E-1) Error al cargar el archivo

Pos-condiciones Se habrán cargado o eliminado documentos para los distintos tipo de usuario (Público, Gerente de proyecto y Coordinador).

6.4.9 Bocetos Visuales De Interfaz Gráfica De Usuario

La interfaz de usuario es la parte más importante de cualquier sistema computacional. Por qué? Es el sistema para la mayoría de los usuarios. Puede ser vista, puede ser escuchada y puede ser tocada. Los pilares del código de software son invisibles, escondidos detrás de las pantallas, teclados. y el mouse. El objetivo del diseño de la interfaz es simple: hacer el trabajo con un computador fácil, productivo y divertido. [4]

Los formularios desarrollados tienen la presentación acorde a la plataforma utilizando los

estilos (colores, formatos, imágenes) ya definidos por Icaro.

Los bocetos de las interfaces de usuario del modulo de proyectos implantado pueden ser consultados en el anexo 10.2.6.

78

6.5 MODELO DE PERSISTENCIA

Otro aspecto importante es la persistencia de las instancias de las clases, esto es, las modalidades bajo las cuales los objetos se hacen persistentes (se insertan en la base de datos). Y bajo las que eventualmente pueden eliminarse (quitarse de la base de datos). Hay dos enfoques básicos:

1. La persistencia es una característica implícita de todas instancias de las clases. La creación de una instancia (típicamente por mediación de una operación new) tiene el efecto de insertar el objeto en la base de datos. Por tanto, la creación del objeto automáticamente implica su supervivencia.

2. La persistencia es una característica ortogonal. La creación de una instancia no tiene el efecto de insertarla instancia en la base de datos. Una instancia se crea durante la ejecución de un programa y se elimina al terminar éste, a meno0s que se haya hecho persistente es asociar un nombre dado por el usuario a la instancia, o insertar la instancia en una colección de objetos persistentes. [5]

6.5.1 Modelo Relacional De La Base De Datos

Una dependencia agrega (puede tener) uno o muchos coordinadores, quienes agregan

(pueden tener) uno o varios proyectos de inversión, donde el proyecto está compuesto

por:

Identificación la información que identifica a cada proyecto como lo es el nombre, subprefecto si tiene, tipo de proyecto, dependencia de Origen, Informaron de las dependencias proponentes y ejecutoras junto con las personas responsables (proponente del proyecto y responsable de la información del proyecto respectivamente), periodo para la ejecución del proyecto.

Plan Distrital: Contiene la información del nombre del plan Distrital, el eje u objetivo, el programa y le nombre del proyecto prioritario asociado, esta información varia con cada periodo de gobierno de la Alcaldía de Bogotá DC.

Plan Trienal: contiene la información de la estrategia, política y programa de la universidad en cada periodo de años.

Descripción: contiene la información de identificación del problema, aspectos relevantes del proyecto, los beneficios que se originarán con la ejecución del proyecto y la información de la línea base del proyecto.

Población: describe, caracteriza y cuantifica los grupos de personas/ comunidades que se verán beneficiados con el proyecto.

Localización: describe la ubicación de los lugares donde se llevará a cabo la ejecución del proyecto.

79

Fuentes de Financiamiento: almacena las cifras de los aportes con los que se cuenta o espera contar para la ejecución del proyecto.

Objetivos: Cada proyecto tiene un objetivo general y éste a su vez contiene uno o muchos objetivos específicos, además, cada objetivo tiene una meta a cumplir y ésta es medida de acuerdo al indicador asociado a la misma .

Costos: valores correspondientes a cada componente de gastos en los que se incurrirá para la ejecución del proyecto.

Versión: cada proyecto tiene una versión inicial, cuando se realizan cambios donde se requiere dejar registro de estas modificaciones se crea una nueva versión, los cual permite realizar un seguimiento sobre la evolución del proyecto.

El Modelo Entidad Relación y Modelo Relacional de la base de datos del módulo de proyectos pueden ser consultados en el anexo 10.2.7.

80

6.5.2 Diccionario de datos

En la base de datos se utilizar el siguiente estándar de nombres:

móludo_descripción Donde el módulo indica el tipo de dato; descripción es el nombre y estos están separados por un _. Estos descriptores se trabajan en minúscula para seguir la norma ya utilizada en la BD de Icaro. Nomenclatura: k_: Llave primaria n_: Descripción v_: Valor numérico permite decimales q_: cantidad entera o_: Otro f_: Fecha

El diccionario de datos para el módulo de proyectos puede ser consultado en el anexo 10.2.8

6.6 ESTRUCTURA DEL DESARROLLO

Para el desarrollo del módulo de inversión se ha respetado la arquitectura planteada por la plataforma Icaro. Por esta razón la estructura es la siguiente: Para la capa de entrada o Front-End se tienen dos carpetas principales que son: jsMPI y jspMPI.

81

Ilustración 12 Estructura Front-End

Sobre el directorio raíz se encuentran los archivos index principales del módulo. En la carpeta otrosJSP están los bocetos de la interfaz para la etapa de ejecución de un proyecto. En la carpeta jsMPI están todos los archivos JavaScript (.js) que se encargan del dinamismo, la captura y presentación desde y hacia los formularios del módulo.

Ilustración 13 Estructura Carpeta jsMPI

82

Dentro de la carpeta jspMPI están los formularios de presentación al usuario desarrollados sobre java (.jsp).

Ilustración 14 Estructura Carpeta jspMPI

83

En la capa de lógica el directorio principal del desarrollo se llama mpinversion, bajo este directorio se encuentran cinco carpetas estas son auxiliares, db, obj, properties y servlet, las cuales mantienen la estructura existente en el módulo.

Ilustración 15 Estructura Carpeta mpinversion

Dentro de la carpeta auxiliares se encuentran las clases que apoyan al modúlo a nivel del manejo de notificaciones, documentos y fechas.

Ilustración 26 Estructura Carpeta mpinversion.auxiliares

En la carpeta db esta la clase que ayuda a mantener una única conexión a la base de datos. Adicionalmente esta la carpeta sesión.

84

Ilustración 17 Estructura Carpeta mpinversion.db

En la carpeta sesión se encuentran todas las clases que ayudan a mapear la información desde y hacia la base de datos, para cada uno de los objetos del proyecto.

Ilustración 18 Estructura Carpeta mpinversion.db.sesion

Dentro de la carpeta properties esta un archivo .properties el cual tiene todas las sentencias sql necesarias para accerder a la base de datos.

Ilustración 19 Estructura Carpeta mpinversion.properties

En la carpeta Servlet están las clases encargadas de recibir y responder las peticiones desde la capa de entrada, manipulando y almacenando la información.

85

Ilustración 20 Estructura Carpeta mpinversion.servlet

Finalmente en la carpeta obj están las clases que modelan el comportamiento de la información ingresada al módulo.

Ilustración 21 Estructura Carpeta mpinversion.obj

86

6.8 CODIGO DEL DESARROLLO Los diferentes objetos creados para el módulo de proyectos (jsps, clases java, properties, javascripts y javadoc) se encuentran en el CD. Se genera el Diagrama de Componentes en cual puede ser consultado en el anexo 10.2.9. La representación gráfica de la secuencia del funcionamiento del código (diagramas de secuencia) puede ser consultada en el anexo 10.2.10. Finalmente se generó el manual de usuario y el manual técnico del módulo de proyectos los cuales se encuentran en el anexo 10.2.12.

87

6.8 CICLO DE VIDA DE UN PROYECTO Para el manejo del proyecto dentro del módulo se adicionaron dos estados a los ya existentes, con el fin de identificar la trayectoria de la información entre los roles del Gerente y Coordinador. Los estados que puede tener un proyecto son los siguientes:

Ilustración 22 Ciclo de vida de un proyecto En Proceso: En este estado la información del proyecto estará almacenada en la base de datos, pero solo será visible para el responsable de la información bajo el rol de Gerente. Si el proyecto se mantiene dentro de este estado la información no se versionará.

88

Inscrito: En este estado la información del proyecto estará almacenada y disponible para cualquiera de los tres roles. Estando en este estado la información será versionada. Revisado: En este estado la información ha sido revisada por el rol del Coordinador y este considera que se deben realizar ajustes de la misma. La información del proyecto solo será visible para el responsable de la información bajo el rol del Gerente. Estando en este estado la información será versionada. Registrado: En este estado la información ha sido revisada y validada por el rol del Coordinador y este considera que el proyecto puede ejecutarse. La información del proyecto es visible para cualquiera de los tres roles. Estando en este estado la información será versionada. Suspendido: Este estado está considerado en el ciclo de vida de un proyecto durante su ejecución y se presenta cuando existen problemas dentro de la ejecución del mismo y esta deba frenarse. Este estado no se considero para el desarrollo actual del módulo. Terminado: Este estado está considerado en el ciclo de vida de un proyecto durante su ejecución y se presenta cuando este ha cumplido a cabalidad todos sus objetivos, metas y actividades asociadas para su ejecución. Este estado no se considero para el desarrollo actual del módulo. A continuación se relaciona los permisos de cada rol dentro del cambio de estado de un proyecto durante su ciclo de vida.

Tabla 8 Permisos cambio de estado

Rol

Estado

Actual Siguiente

Ge

ren

te

--- En Proceso

Inscrito

En Proceso En Proceso

Inscrito

Revisado Inscrito

En Proceso

Co

ord

inad

or

Inscrito Revisado

Registrado

Registrado

Suspendido

Terminado

Revisado

Suspendido Registrado

89

7. CONCLUSIONES El módulo de proyectos es el resultado de la automatización de los procesos manuales existentes para la administración de los mismos, cuyo valor agregado es el manejo de versiones, con el fin de facilitar el seguimiento a los cambios de información que puede llegar a tener cada proyecto del módulo. Debido a que el producto final es la extensión de un software existe en la Universidad Distrital Francisco José de Caldas, el uso de la metodología Open-Up OAS fue requisito para generar la documentación del ciclo de vida del software y permitir visualizar al equipo asesor de la OAPC el avance de la ejecución del proyecto.

Aunque durante la etapa de desarrollo se mantuvo la estructura original de Icaro, eliminar el código javascript embebido en los jsp, brinda al módulo de proyectos una independencia entre la Interfaz y el controlador de la misma, además la implementación de objetos Json para el envío de información entre las capas Front-end y Servlets simplificó la manipulación de la información.

Cabe incluir que la reutilización de clases para el manejo de la persistencia en la base de datos fue de gran ayuda porque la estructura que se maneja es bastante dinámica y permite operar los diferentes tipos de datos de la información enviada para ser procesada.

En consecuencia de la automatización de los procesos y el manejo de versiones de los proyectos del módulo es posible generar el reporte de cada versión el cual puede ser descargado en formato PDF, así mismo, el módulo le permite al Coordinador de la OAPC poner a disposición documentos informativos para cada rol.

Con el análisis, diseño, construcción e implantación del módulo de proyectos en la plataforma Icaro se entrega a la Oficina Asesora de Planeación y Control de la Universidad Distrital Francisco José de Caldas, una herramienta con la cual gestionar su Banco de Proyectos, manteniendo una vía de comunicación entre los actores principales.

90

8. RECOMENDACIONES El desarrollo del módulo de proyectos para la plataforma Icaro fue pensado y desarrollado para agregar nuevas funcionalidades gradualmente según las necesidades de los principales interesados, es por ello que se debe partir de la documentación y objetos entregados como base para articular las nuevas características.

91

9. BIBLIOGRAFIA Y CIBERGRAFÍA

[1] L. J. AMENDOLA, Estrategias y tácticas en la dirección y gestión de proyectos., Valencia, España: Universidad politécnica de valencia., 2006, p. 218.

[2] OFICINA ASESORA DE PLANEACIÓN Y CONTROL DE LA UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS, Banco de Proyectos de la Universidad Distrital (BPUD), Bogotá D.C., 2011, p. 45.

[3] S. FERNANDEZ ESPINOZA, Los proyectos de inversión: evaluación financiera., Costa Rica: Editorial Tecnológica de Costa Rica, 2007, p. 306.

[4] L. MUÑIZ GONZALEZ, CONTROL PRESUPUESTARIO: Planificación, elaboración, implantación y seguimiento del presupuesto., 1 ed ed., Barcelona, España: PROFIT, 2009, p. 225.

[5] DEPARTAMENTO NACIONAL DE PLANEACIÓN DNP, Manual de procedimientos del Banco de Programas y Proyectos de Inversión Nacional, BPIN., Bogotá D.C., 2006.

[6] UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS, «Plan Estratégico de Desarrollo “Saberes, Conocimientos e Investigación de Alto Impacto para el Desarrollo Humano y Social” 2007-2016.,» Bogota D.C., 2008.

[7] OFICINA ASESORA DE PLANEACIÓN Y CONTROL DE LA UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS, Banco de Proyectos de la Universidad Distrital (BPUD), Bogotá D.C., 2011, p. 42.

[8] ALCALDÍA MAYOR DE BOGOTÁ DC, «Plan de Desarrollo 2012-2016.,» Bogotá D.C., 2012.

[9] U. D. F. J. D. C. OFICINA ASESORA DE SISTEMAS, «Guía Rápida Proceso de Desarrollo OPENUP/OAS,» de PROCESO DE DESARROLLO OPEN UP/OAS, 0.0.0.7 ed., Bogotá D.C., 2012, p. 11.

[10]

I. Sommerville, Ingeniería de Software, Mexico: PEARSON, 2011.

[11]

J. D. FERNÉNDEZ LEDESMA, SISTEMAS ORGANIZACIONALES. TEORÍA Y PRÁCTICA, Bogotá: Universidad Cooperativa de Colombia EDUCC, 2005.

[12]

E. BERTINO y L. MARTINO, Sistemas de Bases de Datos Orientadas a Objetos: Conceptos y Arquitecturas, Wilmington: Addison-Wesley Iberoamericana S.A., 1995.

[13]

M. J. MARCO GALINDO, J. M. MARCO SIMÓ, J. PRIETO BLÁZQUEZ y R. SEGRET SALA, Escanenado la Informática, Barcelona, Espña: UOC, 2010.

[14]

W. O. Galitz, The Essential Guide to User Interface Design: An Introduction to GUI Design Principles and Techniques, Indianápolis,EEUU: Wiley Publishing Inc., 2007.

[15]

«DEPARTAMENTO NACIONAL DE PLANEACIÓN,» 2010. [En línea]. Available: https://www.dnp.gov.co/Programas/Inversionesyfinanzaspúblicas/2SistemasdeInformación.aspx. [Último acceso: 9 Julio 2013].

[16]

Eclipse.org, «Eclipse,» [En línea]. Available: http://epf.eclipse.org/wikis/openupsp/openup_basic/deliveryprocesses/ openup_basic_process,_0uyGoMlgEdmt3adZL5Dmdw.html . [Último acceso: 20 Junio 2013].

92

[17]

Eclipse.org, «OpenUP,» 20 Junio 2013. [En línea]. Available: http://epf.eclipse.org/wikis/openup/ .

[18]

«PORTAL ALCALDÍA MAYOR DE BOGOTÁ D.C.,» 4 Abril 2013. [En línea]. Available: http://portal.alcaldiabogota.gov.co/article/ciudadanía-podrá-acceder-al-sistema-de-seguimiento-de-inversión-pública-de-bogotá. [Último acceso: 9 Julio 2013].

[19]

«UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS,» [En línea]. Available: http://comunidad.udistrital.edu.co/sigud/icaro/. [Último acceso: 4 Junio 2013].

[20]

B. AUMAILLE, J2EE desarrollo de aplicaciones web, Barcelona, España: ENI, 2002, p. 357 .

[21]

G. BUENO y J. DORADO, Gestión, procesado y análisis de imágenes biomédicas, Castilla, España: Universidad de Castilla La Mancha, 2007., p. 153.

[22]

K. DOUGLAS y S. P. DOUGLAS, PostgreSQL: A Comprehensive Guide to Building, Programming, and Administering PostgresSQL Database, Estados Unidos de América, 2003, p. 790.

[23]

S. GÁLVEZ ROJAS y I. GARCÍA SUCINO, Java a tope: JavaMail en ejemplos., Electrónica ed., Málaga, España: Dpto. de Lenguajes y Ciencias de la Computación E.T.S. de Ingeniería Informática Universidad de Málaga., p. 103 .

[24]

A. WEITZENFELD, Ingeniería de software orientada a objetos con UML, Java en Internet, Madrid: THOMSON, 2005, p. 678 .

[25]

SECRETARIA DISTRITAL DE PLANEACIÓN, «SEGPLAN -MANUAL DE USUARIO: Inscripción, registro y actualización de proyectos.,» Bogotá D.C., 2012.

[26]

L. V. LANCKE, CSS en DHTML: JavaScript aplicado a hojas de estilo, París: ENI, 2005, p. 479 .

[27]

E. QUERO CATALINAS, A. GARCÍA ROMÁN y J. PEÑA RODRÍGUEZ, Mantenimiento de portales de la Información: explotación de sistemas informáticos, Madrid: Paraninfo, 2007, p. 409 .

[28]

U. D. F. J. D. C. OFICINA ASESORA DE SISTEMAS, «Ciclo de Vida del Proceso de Desarrollo,» de PROCESO DE DESARROLLO OPEN UP/OAS, Bogotá D.C, 2012, p. 23.

[29]

U. D. F. J. D. C. OFICINA ASESORA DE SISTEMAS, «Generalidades del proceso de desarrollo,» de PROCESO DE DESARROLLO OPEN UP/OAS, Bogotá D.C., 2012, p. 15.

93

10. ANEXOS (CD) 10.1 Artefactos del proyecto según la metodología Open-Up OAS entregados generados por el desarrollo del Módulo de proyectos:

Plan General del Proyecto

Plan de Iteración

Unidades de Trabajo

Cierre de iteración

Visión

Requisitos de soporte

Casos de Uso

Glosario

Listado de requerimientos y requisitos

Acta de Trabajo

Plan de Riesgos

Control de Cambios

Caso de prueba

Registro de Pruebas

10.2 Encuestas, Diagramas UML y bocetos visuales de interface de usuario 10.2.1 Encuestas

10.2.2 Diccionario de Clases

10.2.3 Diagrama de Clases

10.2.4 Diagramas Casos de Uso

10.2.5 Diagrama de Actividades

10.2.6 Interface de usuario (JSP)

10.2.7 Modelos de Base de Datos

10.2.8 Diccionario de Datos

10.2.9 Diagrama de Componentes

10.2.10 Diagramas de Secuencia

10.2.11 Diagrama de Estados

10.2.12 Manuales técnico y de Usuario

10.2.13 Actualización Lineamientos sugeridos para la formulación de proyectos

10.2.14 Mapa Mental Modulo de Proyectos

anÁlisis, diseÑo, desarrollo e implantaciÓn del mÓdulo de...

Documents