FORMA DE CULMINACION DE ESTUDIOS - UCA

Universidad Centroamericana

Facultad de Ciencia Tecnología y Ambiente

Ingeniería en Sistemas y Tecnologías de la Información

Desarrollo de un Sistema Web para la Gestión de la Información del Portafolio de

Proyectos de la Universidad Centroamericana UCA

(SGIPP-UCA)

Para optar al título de: Ingeniero(a) en Sistemas y Tecnologías de la Información

(Concentración: Sistemas de Información)

AUTOR:

Bra. Katherine Valeska Dumas Hernández (2007900008)

TUTOR:

Ing. Gerald Alfredo Sánchez Pineda

Managua, Nicaragua 2012

PÁGINA DE ACEPTACIÒN

Este Producto Creativo fue aprobado por el tribunal examinador de la Facultad de Ciencia, Tecnología y Ambiente de la Universidad Centroamericana como requisito para optar al título de Ingeniería en Sistemas y tecnologías de la información.

Lic. Carlos Iván Argüello Martínez

--------------------------------------------- Presidente del Tribunal

Ing. Eduardo Francisco Traña Rivera --------------------------------------------------

Secretario

Ing. Gerald Alfredo Sánchez Pineda ------------------------------------------------

Tutor

Bra. Katherine Valeska Dumas Hernández ----------------------------------------------------------

Egresada

FORMA DE CULMINACION DE ESTUDIOS

SGIPP-UCA

DEDICATORIA

A mí querida mamá Marissa por haberme educado con mucho esfuerzo,

dedicación y sacrificio, por ser comprensiva, porque siempre ha estado en todos

los momentos cuando la he necesitado y porque con su incansable sacrificio ha

hecho que alcance todo lo que me he propuesto en cada aspecto de mi vida.

A mi hermano Franklin por brindarme su cariño y buen humor.

A mi abuelita Elba por haberme brindado su apoyo y animarme a seguir adelante.

A ti Luis por estar a mi lado brindándome tu amor, apoyándome y dándome ánimo

para seguir, gracias por la preocupación, dedicación y afecto.

A mis profesores quienes compartieron sus conocimientos, valores y experiencias

conmigo a lo largo de estos cinco años, los cuales me han ayudado en el avance

de mi carrera y formado como una profesional integral.

Katherine Valeska Dumas Hernández


SGIPP-UCA

AGRADECIMIENTO A Dios por haberme permitido llegar hasta aquí, por darme la fortaleza necesaria

para poder alcanzar esta meta.

A mi tutor Gerald Alfredo Sánchez Pineda, por haberme guiado y apoyado en el

desarrollo de esta tesis.

A mis compañeros de clases, por haber compartido tantos momentos juntos y por

brindarme su amistad.

A todas las personas que han colaborado conmigo con su cariño y apoyo a lo

largo de todos estos años.

Katherine Valeska Dumas Hernández


SGIPP-UCA

RESUMEN

El presente trabajo tiene como propósito principal desarrollar un sistema web para

la gestión del portafolio de proyectos de la Universidad Centroamericana UCA,

que permita llevar el manejo rápido de toda la información de los proyectos que

lleva la Oficina de Proyectos, Consultorías y Servicios.

Este fue desarrollado bajo la metodología SCRUM y artefactos de RUP (Proceso

Unificado de Desarrollo de Software), la metodología plantea tres fases para la

llevar a cabo la ejecución del proyecto: Pregame, Gamephase y Postgame,

también para el aspecto gráfico se tomó en cuenta el Lenguaje de Modelado

Unificado (UML) que permite ver de manera sencilla la solución más adecuada

para el desarrollo del proyecto.


SGIPP-UCA

CONTENIDO

1. INTRODUCCIÓN

2. OBJETIVOS

2.1 Objetivo General

2.2 Objetivos Específicos

3. JUSTIFICACIÓN

4. MARCO TEÓRICO

5. DISEÑO METODOLÓGICO

5.1 La fase de Pregame

5.1.1 Planeación

5.1.2 Arquitectura / Diseño de Alto Nivel

5.2 La fase de Development o gamephase

5.3 La fase de PostGame:

5.4 Herramientas utilizadas durante la iteración de cada fase

5.5 Herramientas tecnológicas para el desarrollo del sistema

6. PRESENTACIÓN DE RESULTADOS

6.1 FASE DE PREGAME

6.1.1 Planeación

6.1.1.1 Requerimientos Funcionales

6.1.1.2 Requerimientos No Funcionales


6.1.2.1 Product Backlog

6.1.2.2 Sprint Plan y Sprint Backlog

6.1.2.3 Documento de especificación de casos de uso y diagramas

6.1.2.4 Documento de Arquitectura del sistema

6.2 FASE DE DEVELOPMENT O GAMEPHASE

6.2.1 Diccionario de Datos

6.2.2 Glosario de términos

6.3 FASE DE POSTGAME


SGIPP-UCA

7. CONCLUSIONES

8. RECOMENDACIONES

9. BIBLIOGRAFÍA

10. ANEXOS

10.1 Entrevistas

10.2 Desarrollo del Sistema

10.3 Documento de Casos de Uso

10.4 Documento de Arquitectura del Sistema

10.5 Diccionario de Datos

10.6 Glosario de Términos

10.7 Manual de Usuario


SGIPP-UCA

INDICE DE TABLAS

Tabla 1. Tareas de la fase pregame

Tabla 2. Tareas de la fase gamephase

Tabla 3. Historia de usuario numero 1






Tabla 9. Detalle de la Product Backlog

Tabla 10. Detalle del Sprint Plan

Tabla 11. especificación del Caso de Consultar Información del Proyectos

Tabla 12. especificación del caso de uso Generar Reporte

Tabla 13. especificación del Caso de Registrar Información de los Proyectos

Tabla 14. especificación del Caso de Modificar Proyectos

Tabla 15. especificación del Caso de Gestionar Área Temática

Tabla 16. especificación del Caso de Gestionar Usuario

Tabla 17. especificación del Caso de Gestionar Roles, permisos y opciones


SGIPP-UCA

1. INTRODUCCIÓN

El término de Portafolio se le atribuye a la agrupación de todos los programas o

proyectos manejados por una organización o empresa. Puede haber más de uno

dentro de la organización y a su vez estar constituidos de proyectos y programas

relacionados o no relacionados. Para realizar una gestión eficiente de toda la

información que genera cualquier tipo de proyecto, esto estará en dependencia de

que tanto acceso se tenga a la información de los mismos y que tan organizada se

encuentre.

El portafolio no es más que una herramienta de soporte a la toma de decisiones

usado por los ejecutivos para balancear de forma continua los riesgos y beneficios

de un portafolio. Debe proveer claridad en las variables y métricas que se usarán

para la evaluación del mismo.

En la actualidad toda organización cuenta con un grupo o un área en donde se

lleva el control de los proyectos, a como es el caso de La Oficina de Proyectos,

Consultorías y Servicios (OPCS) de la Universidad Centroamericana UCA, esta se

encarga de dar seguimiento a la formulación, ejecución, control y evaluación

financiera de los proyectos, consultorías y servicios, ofertados por las Facultades,

Centros e Institutos. (Politicas, normas y procedimientos para proyectos,

consultorias y servicios de la UCA).

Pero la falta de disponibilidad de la información de los proyectos ocasiona un

atraso al momento de ser brindada a diversos organismos, ya que dicha

información solo se encuentra en documentos físicos y hojas de Excel, lo que

ocasiona que el acceso rápido a esta sea un poco difícil provocando un aumento

notorio en los costos.

El proyecto que se pretende realizar es un sistema web que permita el rápido

acceso a la información, reduciendo los costos al realizar el proceso de


SGIPP-UCA

almacenamiento de toda la información generada por los proyectos que realiza la

OPCS de manera fácil.

La aplicación estará diseñada bajo una interfaz sencilla para que los usuarios

puedan ingresar la información de los nuevos proyectos, también se podrán

generar informes de los mismos, así como les permitirá descargar o subir

documentos digitales asociados a cada uno de los proyectos agregados en el

sistema.


SGIPP-UCA

2. OBJETIVOS

2.1 Objetivo General

Desarrollar un sistema web que gestione la información del portafolio de

proyectos que administra la OPCS, elaborado con herramientas para el

desarrollo de software, que permita realizar la automatización de los

procesos.

2.2 Objetivos Específicos

Identificar los requerimientos necesarios para el desarrollo del sistema

basados en el análisis de la información brindada por la OPCS.

Diseñar los prototipos de las interfaces web bajo los estándares de la

W3C, así como la arquitectura y procesos que realizará el sistema,

elaborados con herramientas de modelación.

Garantizar la disponibilidad del sistema en su versión alfa, para la

realización de pruebas y puesta en funcionamiento.


SGIPP-UCA

3. JUSTIFICACIÓN

La elaboración del presente proyecto surge de la necesidad de llevar el control de

la información generada por los proyectos y agilizar los procesos de búsqueda

necesarios en la administración de portafolio de proyectos que lleva la Universidad

Centroamericana UCA.

El sistema que se pretende desarrollar, estará diseñado con una base de datos

donde se cargará la información de todos los proyectos que la OPCS ha

administrado durante su tiempo de existencia y los que ejecutará en un futuro. La

aplicación estará diseñada para que los usuarios puedan ingresar la información

de los nuevos proyectos y presentará informes de los mismos, les permitirá

descargar o subir documentos digitales asociados a cada uno de los proyectos

ingresados en el sistema, así como documentación legal anexa de la Universidad.

El contar con un sistema que permita llevar el control de la información generada

por cada uno de los proyectos ejecutados por OPCS en la universidad, así como

la obtención de una documentación que respalde todo el proceso del mismo,

permitirá tener mejores resultados de cada uno de los proyectos que realice la

universidad, apoyado en la toma de decisiones adecuada.


SGIPP-UCA

4. MARCO TEÓRICO

Según lo que nos plantea, (The Standard for Portfolio Management, 2008); un

“Portafolio de Proyectos es una colección de proyectos/programas y otro tipo de

labor el cual es agrupado para facilitar el manejo efectivo del trabajo orientado a

conseguir las metas estratégicas de la organización”.

Este tiene como principal objetivo el de brindar a la organización la información

necesaria para la adecuada toma de decisiones, con respecto a la elaboración,

ejecución y seguimiento de proyectos. Por lo tanto se torna de vital importancia la

creación y gestión adecuada de los portafolios de proyectos, así como

departamentos u oficinas que manejen los mismos. Además se tiene que contar

con las herramientas necesarias para almacenar y manejar toda la información

que generan.

En el panorama actual las organizaciones recurren a las herramientas que las

TIC´s (Tecnologías de la Información) les brindan, ayudando en la agilización de

sus procesos y a tener un manejo más rápido de la información y servicios que

ofrecen, independientemente del giro del negocio al que se encuentran enfocados.

Entre las principales herramientas que se utilizan con este fin, tenemos los

sistemas de información.

Fernández (2006), plantea que un sistema de información es “un conjunto de

componentes que interaccionan entre sí para lograr un objetivo común: satisfacer

las necesidades de información de una empresa”. Estos permiten la recolección

de toda la información de la empresa, la que puede ser procesada, distribuida y

almacenada por el sistema, para luego ser mostrada al usuario.

Estos sistemas de información, son adaptados y clasificados según los

requerimientos de la empresa, Kendall & Kendall (2005) plantea que existen

diferentes tipos de sistemas de información, entre estos tenemos:


SGIPP-UCA

Sistemas de procesamiento de transacciones: funcionan al nivel operativo de

una organización.

Sistemas de automatización de la oficina y los sistemas de trabajo del

conocimiento: apoyan el trabajo al nivel del conocimiento.

Sistemas de información gerencial: son sistemas de información

computarizados cuyo propósito es contribuir a la correcta interacción entre los

usuarios y las computadoras.

Sistemas de apoyo a la toma de decisiones: se encuentran entre los sistemas

de alto nivel. Los sistemas expertos aplican el conocimiento de los encargados de

la toma de decisiones para solucionar problemas estructurados específicos.

Sistemas de apoyo a ejecutivos: se encuentran en el nivel estratégico de la

administración.

Independientemente del tipo de sistema de información que decida utilizar o

implementar la empresa, estos brindan una serie de beneficios tales como:

Acceso rápido a la información.

Generación de informes e indicadores, que ayudan a la toma acertada de

decisiones.

Posibilidad de planear y generar proyectos administrados y soportados en

sistemas de información que presentan elementos claros y sustentados.

Disminución de la pérdida de tiempo, recopilando y mostrando información

que ya está almacenada en bases de datos que se pueden compartir.

Facilidad para encontrar y manipular la información.

Permiten la comunicación de los departamentos.


SGIPP-UCA

Aumento de la productividad facilitando la búsqueda y generación de

información repetida.

El avance de la tecnología, así como las nuevas tendencias en internet, ha

provocado que las empresas ya no solo busquen sistemas que solucionen sus

necesidades a lo interno de la misma, sino que ahora han optado por sistemas en

la web, conocidos como aplicaciones web, a los cuales tienen acceso en cualquier

momento y lugar.

Lujan (2002), define las aplicaciones web como “un tipo especial de aplicación

cliente/servidor, donde tanto el cliente (el navegador, explorador o visualizador)

como el servidor (el servidor web) y el protocolo mediante el que se comunican

(HTTP) estan estandarizados”, sigue exponiendo que estas se encuentran

divididas en tres niveles diferentes que son de gran importancia para el adecuado

desarrollo de las mismas, estos son:

Nivel superior: permite la interacción con el usuario, comúnmente un navegador.

Nivel intermedio: permite la visualización de los datos, este es el servidor web.

Nivel inferior: proporciona los datos, comúnmente es la base de datos.

Las aplicaciones web (conocidas como webapp), brindan a los usuarios una serie

de ventajas, entre estas se mencionan:

Facilidad de acceso, desde cualquier ordenador sin necesidad de

instalación previa.

Proporciona niveles de seguridad al acceder.

Soporta la característica de multiusuario.

Permite más utilización gráfica (gráficos, imágenes, vídeos, etc.).

Para la adecuada creación de este tipo de aplicaciones, existen estándares que

según (World Wide Web Consortium (W3C), 2008), en su Guía Breve sobre


SGIPP-UCA

Estándares Web, define como “un conjunto de reglas normalizadas que describen

los requisitos que deben ser cumplidos por un producto, proceso o servicio, con el

objetivo de establecer un mecanismo base para permitir que distintos elementos

hardware o software que lo utilicen, sean compatibles entre sí.”

El W3C, es un consorcio fundado en 1994 encargado de potenciar los recursos

que brinda la Web, mediante el desarrollo de protocolos y estándares comunes

que promueven su evolución.

Este consorcio se encuentra compuesto por programadores, desarrolladores web,

usuarios y ejecutivos, que ayudan a definir el estándar adecuado de desarrollo de

la tecnología web.

Estos estándares son diseñados tomando en cuenta diferentes aspectos del

desarrollo, y se encuentran orientados de la siguiente manera:

Accesibilidad Web (WAI): la W3C ha publicado Web Content Accessibility

Guidelines (WCAG), ofrece diversas formas para crear aplicaciones web

accesibles, proporcionando una semántica adicional sobre los comportamientos

del usuario en la web.

Seguridad: La Web es una herramienta de gran alcance para las comunicaciones

y transacciones de todo tipo. Es importante tener en cuenta las implicaciones de

privacidad y seguridad de la web como parte del diseño de la tecnología. Por lo

tanto W3C plantea una serie de opciones para brindar al usuario la privacidad

necesaria así como proteccion de la información confidencial.

Internacionalización: El W3C ha publicado una guía donde muestra la utilizacion

de las etiquetas de idioma bidireccional de texto, que permite tener en la web

aplicaciones multilenguajes.

http://www.masadelante.com/faq-www.htm

http://translate.googleusercontent.com/translate_c?hl=es&langpair=en%7Ces&rurl=translate.google.com.ni&u=http://www.w3.org/standards/webdesign/i18n&usg=ALkJrhjoKeLWCdNMTUx0W3gSets_lAIZaQ


SGIPP-UCA

Audio y Vídeo: Presentan algunos de los formatos de audio W3C que permiten la

creación y presentaciones de videos que incluyen HTML, SVG y SMIL

(sincronización).

Protocolos: HTTP es el protocolo básico.

La utilizacion de estos estandares al desarrollar las aplicaciones, brinda tanto al

programador como al usuario una variedad de beneficios, entre estos se destacan

los siquientes:

Código más limpio: ayudan a tener un código limpio, válido, modular y

semánticamente correcto, ya que instan a la utilización de etiquetas, hojas

de estilos (css), que permiten una solución de problemas mucho mas

rápidos, así como facilita la re-utilización de código .

Compatibilidad para plataformas y navegadores: permiten que las

aplicaciones web sean compatibles con todo tipo de navegador.

Mejor aceptación: al cumplir con los estándares, se indexan y localizan los

sitios en los motores de búsqueda.

Simplificación del mantenimiento: al tener un código ordenado y el

contenido separado los cambios se realizan con mucha más facilidad.

Ahorrar ancho de banda: lo que reduce los gastos de alojamiento web.

Mayor rápidez de carga de las páginas.

El principal temor de las empresas al utilizar este tipo de herramientas,

aplicaciones web, es que al utilizarse poseen información sensible de la misma, y

la vulnerabilidad y amenazas que existen en la web son altas.

http://translate.googleusercontent.com/translate_c?hl=es&langpair=en%7Ces&rurl=translate.google.com.ni&u=http://www.w3.org/standards/webdesign/audiovideo&usg=ALkJrhhpGFCoSJrvPlAx-sw37sGeukvRPw

http://translate.googleusercontent.com/translate_c?hl=es&langpair=en%7Ces&rurl=translate.google.com.ni&u=http://www.w3.org/standards/webarch/protocols&usg=ALkJrhg8L5eieclV6GYRsRcA-rYZ5CLuQg


SGIPP-UCA

Stallings (2004), plantea que existen varios tipos de amenazas en la web,

clasificandolos en dos grupos : “ataques pasivos y ataques activos. Los pasivos

incluyen escuchas del tráfico de la red entre el navegador y el servidor y la

obtención de acceso a información de un sitio que se supone restringida. Los

ataques activos incluyen la suplantación de otro usuario, la alteración de mensajes

en el tránsito entre el cliente y el servidor y la modificación de información de un

sitio”.

Aparte de tomar en cuenta las recomendaciones que nos ofrece la W3C en

términos de seguridad y confidencialidad de la información, Bertolín, (2008),

establece que hay que tener sumo cuidado con los scripts cgi, que se vayan a

utilizar, hay que revisar las configuraciones de acceso al web serve, así como los

permisos y los directorios de datos.


SGIPP-UCA

5. DISEÑO METODOLÓGICO

Para llevar a cabo el desarrollo del Sistema para la Gestión de Información del

Portafolio de Proyectos SGIPP-UCA, se tomará en cuenta como base la

Metodología de Desarrollo SCRUM siguiendo todos los procesos que plantea la

misma, se utilizará Enterprise Architect para la diagramación y para la

documentación se tomarán artefactos que propone la Metodología de desarrollo

RUP.

El proceso de desarrollo se organizará en tres diferentes iteraciones, llamadas

sprints, que normalmente tendrán un tiempo entre dos y cuatro semanas de

duración, este es el tiempo recomendado por la metodología. Al principio de cada

sprint se establecerá una lista de requerimientos llamada product backlog.

Fases de Desarrollo del Proyecto:

Scrum propone tres fases: Pregame, Development y Postgame.

5.1 La fase de Pregame

5.1.1 Planeación

Se realizará la definición del sistema. Para esto se crea la lista Product Backlog a

partir del conocimiento que actualmente se tiene del sistema. En ella se expresan

los requerimientos.


El diseño de alto nivel del sistema se planificará a partir de los elementos

existentes en la Product Backlog.


SGIPP-UCA

Las tareas a ser realizadas serán las siguientes:

Nombre de la tarea Descripción

Crear la Product

Backlog List y controlar

su consistencia

En esta se encontrarán los requerimientos técnicos y del

negocio, funciones, errores a reparar, defectos, mejoras y

actualizaciones tecnológicas requeridas, así como los

requerimientos no funcionales del sistema

Creación del Sprint

Backlog

Se definirán los Sprint Backlog necesarios para la

ejecución del sistema.

Realización de la

arquitectura del sistema

(Diseño de alto nivel)

Aquí se realizarán la arquitectura del sistema, así como

los diagramas requeridos para la modelación del sistema

tales como casos de uso, estado, secuencia, clases,

componentes, el diagrama físico de la base de datos.

Tabla 1. Tareas de la fase pregame

Verificación: Deben estar realizadas todas las tareas.

Salida: Product Backlog List, Documento de Arquitectura del sistema, Diagramas

requeridos para la modelación del sistema tales como Casos de uso, Estado,

Secuencia, Clases, Etc. Una estimación de riesgo inicial, Un plan de proyecto,

demostrando fases e iteraciones.

5.2 La fase de Development o gamephase

En esta fase se realiza la revisión de los documentos obtenidos en la fase anterior,

se establecen las variables más importantes, como son tiempo, recursos,

requerimientos, tecnologías y herramientas de desarrollo.

Nombre de la tarea Descripción

Sprint Planning

La primera fase tiene como objetivo establecer que ítems de la

Product Backlog que serán realizados durante el nuevo Sprint.

En la segunda fase se decide como se van a alcanzar los


SGIPP-UCA

objetivos del Sprint.

Sprint

La fase de Sprint es donde el desarrollo de software se lleva a

cabo. Un Sprint consta de los siguientes sub-actividades:

Elaborar

Integrar

Revisar

Ajustar.

Tabla 2. Tareas de la fase gamephase

Verificación: Durante un sprint se puede acortar funcionalidad pero la fecha de

entrega debe ser respetada.

Salida: Incremento del producto, Un prototipo arquitectónico ejecutable al sistema

para su respectiva prueba.

5.3 La fase de PostGame:

Para ingresar a esta fase SCRUM propone que se debe llegar a un acuerdo

respecto a las variables del entorno por ejemplo que los requerimientos fueron

completados; todo esto se decidirá mediante la revisión de la Product Backlog. El

sistema está listo para ser liberado y es en esta etapa donde se realiza

integración, pruebas del sistema lanzamientos beta, documentación y manuales

de usuario listos.

5.4 Herramientas utilizadas durante la iteración de cada fase

El Product Backlog es un repositorio de requerimientos. Por lo general, los

requerimientos incluidos en este backlog son de alto nivel, evitan detallar

cuestiones técnicas o de implementación.

El sprint backlog se arma al principio de cada sprint, y reúne aquellos

requerimientos y actividades que el equipo deberá completar para cuando finalice

dicho sprint.


SGIPP-UCA

Como la metodología en si no genera documentación de soporte al desarrollo del

sistema, en cada sprint se generarán los siguientes documentos para dar soporte

al desarrollo del mismo:

5.4.1 Modelo de proceso de negocios/ Flujos de Trabajo

Se utilizarán diagramas de secuencia para modelar los Flujos de Trabajo

(workflows), estos serán soportados por el sistema desarrollado.

5.4.2 Modelo de Casos de Uso, secuencia y estado

El documento de modelo de Casos de Uso presenta la funcionalidad del sistema y

los actores que hacen uso de ella. Se representa mediante Diagramas de Casos

de Uso. Para los casos de uso que lo requieran, se realiza una descripción

detallada utilizando una tabla de plantilla, donde se incluyen: descripción, actores,

precondiciones, requisitos no-funcionales, flujo de eventos, flujo alterno,

postcondiciones, requerimientos especiales.

5.4.3 Modelo Arquitectura del software

Este modelo establece la realización de los casos de uso en clases y pasando

desde una representación en términos de análisis (sin incluir aspectos de

implementación) hacia una de diseño (incluyendo una orientación hacia el entorno

de implementación). Está constituido esencialmente por un Diagrama de Clases.

5.4.4 Glosario

Es un documento que define los principales términos usados en el proyecto.

Permite establecer una terminología consensuada.

5.4.5 Modelo físico / diccionario de datos


SGIPP-UCA

Previendo que la persistencia de la información del sistema será soportada por

una base de datos relacional, este modelo describe la representación física de las

tablas, con sus llaves, descripciones de campos (Diccionario de datos). Este

modelo permite la generación del script que permite crear las tablas en las bases

de datos en SQL Server 2008.

5.4.6 Manuales de Usuario

Corresponde a un conjunto de documentos y facilidades de uso del sistema, que

se desarrollan para acceso web, manuales en documentos doc. o pdf., se

recomiendan herramientas de acceso web ya que esto permite tener actualizados

los manuales, sin que se tengan que reimprimir los manuales a los usuarios.

5.5 Herramientas tecnológicas para el desarrollo del sistema

Para el desarrollo de SGIPP se utilizan las herramientas tecnológicas más

adecuadas, entre estas están:

5.5.1 SQL Server 2008

Es un servidor de base de datos que permite realizar diversos tipos de

operaciones que permiten el manejo adecuado de toda la información

almacenada, ofrece una facilidad de administración.

5.5.2 Visual Studio

Este es un entorno de desarrollo integrado (IDE), que facilita la creación de

soluciones o aplicaciones en diferentes tipos de lenguajes. Este IDE optimiza el

diseño, desarrollo e implementación de las aplicaciones desarrolladas.

5.5.3 ADO.NET

Este es un modelo basado en relaciones entre el esquema de la base de datos y

la aplicación, lo que permite a los desarrolladores crear aplicaciones de acceso a

datos de programación con un modelo de aplicación conceptual.


SGIPP-UCA

5.5.4 Lenguaje C#

Es un lenguaje orientado a objetos, simple, que está incluido en la plataforma

.NET.

5.5.5 Ajax Control Toolkit 4.0

Es el conjunto de herramientas especiales para las interfaces o la capa de

presentación de las aplicaciones que permite la creación de las mismas de

manera más rápida con un alto grado de calidad.


SGIPP-UCA

6. PRESENTACIÓN DE RESULTADOS

En esta sección se presentan los resultados obtenidos durante el proceso de

desarrollo de SGIPP, habiendo aplicado la metodología planteada en el marco

metodológico.

Durante la ejecución del proyecto se obtuvieron diversos documentos o artefactos

que sirvieron como base para la respectiva ejecución de las siguientes fases.

Dichos documentos se detallan en cada fase correspondiente.

6.1 FASE DE PREGAME

6.1.1 Planeación

En esta fase se realizaron dos entrevistas con la encargada de la administración

de la OPCS Mba. Widad Raquel Arauz Garcia, las que sirvieron para determinar

las funciones del sistemas, los requerimientos funcionales (Anexo 10.1) y los no

funcionales, así como los tipos de usuarios y la seguridad que tendrá el sistema,

dichas especificaciones serán detalladas a continuación:

Funciones del producto

Este llevará el control de toda la información relacionada con los diferentes

proyectos que se manejan en la OPCS.

Características del usuario

El sistema será manejado por tres tipos de usuarios:

Administrador de la OPCS: Este podrá realizar todas las funciones

relacionadas con la administración de la información de los proyectos

así como la creación de usuarios, roles y asignación de permisos.


SGIPP-UCA

Administrador del Sistema: Este podrá gestionar roles, usuarios y

permisos.

Consultor de proyectos: este solo podrá visualizar la información de

los proyectos.

Problema del usuario

No se tiene acceso adecuado y rápido a toda la información de los

diferentes proyectos que ejecutan en la OPCS.

Dicha información no se encuentra digitalizada, la mayor parte se

encuentran en documentos físicos lo que dificulta en gran manera el manejo

de la misma, así como la presentación de los resultados durante las

reuniones.

Objetivo del usuario

Solucionar su problema utilizando un sistema ágil, cómodo, eficiente y

eficaz. Que le permita tener acceso a toda la información de los proyectos

en el momento que lo necesiten.

6.1.1.1 Requerimientos Funcionales

Tabla de Requerimientos del Sistema

Los requerimientos del sistema fueron tomados de las historias de usuario que se

encuentran en el documento de desarrollo del proyecto (anexo 10.2), las que

fueron tomadas a partir de las entrevistas realizadas con el usuario.


SGIPP-UCA

ID 1 Gestión de proyectos

Descripción

El sistema deberá gestionar toda la información que generen los proyectos

Pruebas de Aceptación

• Identificar todos los datos contenidos en la base de datos del sistema. Nivel de sistema: • Revisar cada uno de los campos para revisar que la información se carga correctamente.


ID 2 Búsqueda de Proyectos

Descripción

Los Proyectos estarán organizados por diferentes áreas temáticas


• Organizar los proyectos por diferentes áreas temáticas. Nivel de sistema: • Se comprobará la creación de las áreas temáticas así como la organización de los proyectos.


ID 3 Anexos

Descripción

Se debe de permitir la carga de archivos digitales en diferentes tipos de formatos


• Se cargan archivos con información de los proyectos estos serán de diferentes extensiones: .pdf, .doc, .xls, Nivel de sistema: •Se comprobará el funcionamiento a la hora de cargar estos tipos de archivos



SGIPP-UCA

ID 4 Eliminación de la información

Descripción

El sistema no debe de permitir que un proyectos ya registrado sea eliminado de

forma manual por el usuario


• El sistema no debe permitir eliminar ningún dato. Nivel de sistema: • Se comprobará el funcionamiento de estas acciones.


ID 5 Manejo de la información

Descripción

Se permitirá la actualización y modificación de cada dato guardado de los proyectos


• El sistema solo permite la actualización y modificación de los datos, no se permite eliminar. Nivel de sistema: • Se comprobará el funcionamiento de estas acciones.


ID 6 Usuarios

Descripción

El sistema será utilizado por dos tipos de usuario administrador OPCS y consultor, pero también habrá un administrador del

sistema.


• Identificar y listar cada actor y las funciones y datos a los que tiene acceso. • Crear pruebas para cada actor y verificar los permisos creando órdenes especificas. • Modificar el actor y repetir las pruebas para los mismos usuarios. Nivel de sistema: • Se comprobará el funcionamiento del sistema de autenticación de la aplicación, basado en las diferentes sesiones de usuario.



SGIPP-UCA

6.1.1.2 Requerimientos No Funcionales

Perfiles De Usuario

De acuerdo al tipo de usuario que acceda al sistema se le asignarán los

diferentes permisos para manipular el mismo.

- Administrador OPCS: este usuario tiene un acceso y manipulación total del

sistema

- Consultor: tiene un acceso restringido al sistema, solo se le permitirá consultar y

descargar archivos asociados a cada proyecto, no modificarlos.

-Administrador SGIPP: este realizará el control de todo lo relacionado con la

seguridad del sistema, usuario, roles y permisos.

Fiabilidad

La Robustez de la plataforma Microsoft brinda características fiables al Sistema

pos ser una plataforma de desarrollo segura y robusta.

Mantenibilidad

Las tareas de mantenimiento del sistema serán realizados por el desarrollador del

sistema o en su defecto será realizado por el usuario Administrador. El sistema

permitirá que las instalaciones y reinstalaciones sea una tarea sencilla y rápida.

Portabilidad

SGIPP está desarrollado en Visual Studio .Net y lenguaje de programación C#

bajo la plataforma de Microsoft que es muy robusta, además es utilizado en el


SGIPP-UCA

Sistema Operativo Windows XP, Windows Vista o Windows Seven, y es

compatible con los navegadores Mozilla Firefox, Internet Explorer y Google

Chrome.

La metodología base propone que en la primera fase se lleven a cabo la creación

de las historias de usuario, la Product Backlog y la creación de los sprint. Para

obtener estos productos se utilizó la herramienta que la metodología propone en

formato Excel, a continuación se detallan cada uno de estos:


En esta etapa, que es parte de la fase pregame en donde se obtienen los

documentos base del sistema, entre estos tenemos:

6.1.2.1 Product Backlog

Esta contiene las historias de usuario listas para ser programadas en los sprint

backlog; en la tabla (9) tenemos el detalle de la misma.

ID Historia

Nombre de la Historia

Estado Prioridad Comentario

1 El sistema deberá gestionar toda la información que generen los proyectos

Planeado Alta Aquí se encontraran todos los datos específicos de los proyectos

2 Los Proyectos estarán organizados por diferentes áreas temáticas

Planeado Media Esto facilitara las búsquedas de los proyectos

3 Se debe de permitir la carga de archivos digitales en diferentes tipos de formatos

Planeado Media Permitirá un manejo de archivos más eficiente


SGIPP-UCA

4 El sistema no debe de permitir que un proyectos ya registrado sea eliminado de forma manual por el usuario

Planeado Alta Solo se cambiará de estado al proyecto pero no será eliminado por completo de la base de datos

5 Se permitirá la actualización y modificación de cada dato guardado de los proyectos

Planeado Media

6 El sistema será utilizado por dos tipos de usuario administrador OPCS y consultor, pero también habrá un administrador del sistema.

Planeado Alta Manejo de sesiones y vistas de los proyectos por usuarios

Tabla 9. Detalle de la Product Backlog

6.1.2.2 Sprint Plan y Sprint Backlog

Tomando en cuenta la Product Backlog se genera el sprint plan y el detalle de los

sprint, estos son detallados a continuación, y muestran el diagrama de las

actividades necesarias para la realización exitosa del sistema.

Sprint Inicio Días Final Estado Objetivo

1 19/09/2011 24 20/10/2011 Liberado Planeación (Fase Pregame: Planeación, Arquitectura / Diseño de Alto Nivel)

2 21/10/2011 24 23/11/2011 Liberado Desarrollo (Game Phase )

3 24/11/2011 9 06/12/2011 Liberado Revisión (PostGame)

Tabla 10. Detalle del Sprint Plan


SGIPP-UCA

Los sprint backlog generados durante el desarrollo del proyecto se encuentran

detallados junto con sus respectivos gráficos en el documento de desarrollo del

proyecto (ver anexo 10.2).

6.1.2.3 Documento de especificación de casos de uso y diagramas

Tomando como base el análisis de las entrevistas realizadas a la encargada de la

OPCS, se definieron las especificaciones de casos de uso, junto con sus

respectivos diagramas de casos de uso y diagramas de secuencia, estado y

colaboración..

El Documento de especificación de casos de uso y diagramas (Anexo 10.3) está

estructurado de la siguiente manera:

Introducción

o Propósito

o Alcance

o Referencias

Representación Arquitectural

Actores del Sistema

o Detalle de actores

Diagramas de Caso de uso Nivel 0



Especificaciones de caso de uso

Diagramas de secuencia

Diagramas de estado

Diagramas de colaboración


SGIPP-UCA

6.1.2.4 Documento de Arquitectura del sistema

Como parte de proceso que conlleva la fase de pregame se obtiene el documento

de arquitectura del sistema, este representa la estructura del mismo (sistema),

ayudando a realizar diversos análisis que orienten el proceso de desarrollo y toma

de decisiones durante la ejecución.

Está basado en la metodología RUP (Rational Unified Process) para el documento

(Anexo 10.4) pero las especificaciones tomadas para su desarrollo fueron en base

a las historias de usuarios que se generan a partir de la metodología SCRUM

(apartado número 6.1.1.1 del documento), las entrevistas realizadas al usuario, así

como recomendaciones de ambas metodologías.

6.2 FASE DE DEVELOPMENT O GAMEPHASE

En esta etapa que corresponde al desarrollo del sistema se han obtenido con

anterioridad los artefactos correspondientes a la fase de pregame, a continuación

se realizó la revisión del product backlog y de cada uno de los documentos

generados.

Basado en los resultados se procedió a realizar el diseño de las interfaces y la

programación del sistema de acuerdo a lo establecido en el sprint número dos. A

como ya se mencionó en capítulos anteriores, fue desarrollado en el lenguaje C#,

utilizando el framework Visual Studio 2010 y tomando en cuenta las

recomendaciones de la W3C.

Durante el proceso de la fase development también se elaboraron el diccionario de

datos y el glosario de términos.


SGIPP-UCA

6.2.1 Diccionario de Datos

Este proporciona información detallada de cada una de las tablas y campos de la

base de datos del sistema, en este se encuentran los aspectos principales de la

base de datos, los esquemas y las tablas pertenecientes a dichos esquemas, las

relaciones que existen y el diagrama entidad relación. Ver (anexo10.5).

6.2.2 Glosario de términos

Este proporciona una lista de palabras con sus conceptos para ayudar al usuario

a comprender los términos empleados en el desarrollo del sistema. Ver anexo

(anexo 10.6), este presenta una abreve introducción y la manera en la cual se

encuentran organizadas las palabras que fueron agregadas.

6.3 FASE DE POSTGAME

Al cumplir con las actividades detalladas en el sprint dos se procede a realizar la

liberación del sistema en su versión alfa para las pruebas funcionales del mismo y

comprobar que todo lo establecido él la product backlog se cumplió a cabalidad.

A como establece el sprint número tres se realiza el manual de usuario (anexo

10.7) este contiene el detalle de todos los elementos y navegación del sistema.

Este contiene los pasos a seguir para ejecutar cada una de las funciones del

sistema. Es una guía para el usuario final que sirve para aclarar las dudas a la

hora de manipular el sistema.


SGIPP-UCA

7. CONCLUSIONES

Luego de haber ejecutado cada una de las fases de las que constaba el proyecto,

puede concluirse que:

Se desarrolló satisfactoriamente el Sistema web para la gestión de la información

del portafolio de proyectos de la Universidad Centroamericana UCA (SGIPP-UCA)

en su versión alfa.

Mediante las diferentes entrevistas con la encarga de la OPCS se logró identificar

y determinar los requerimientos necesarios para el desarrollo del sistema.

Durante el proceso de desarrollo y codificación del sistema se logro diseñar los

prototipos de las interfaces del sistema, tomando como base cada uno de los

artefactos generados durante el análisis.

Se realizo la liberación de SGIPP en su versión alfa, esto se logro mediante las

herramientas de desarrollo (Visual Studio 2010), así como también se realizaron

las respectivas pruebas validando el correcto funcionamiento de los procesos.


SGIPP-UCA

8. RECOMENDACIONES

Se recomienda que en un futuro, el sistema sea migrado a la plataforma de

implementación y lenguaje de programación de la organización.

En caso de surgir nuevos requerimientos que alteren todo el funcionamiento del

sistema se recomienda realizar nuevamente el mismo, partiendo de toda la

documentación presentada.

También se recomienda tomar en cuenta que si ocurren cambios en los procesos

del giro del negocio se adapte el sistema a estas modificaciones, así como realizar

las adaptaciones del sistema si surgiera alguna falla.


SGIPP-UCA

9. BIBLIOGRAFÍA

Alarcón, V. F. (2006). Desarrollo de Sistemas de Información: Una metodología

basada en el modelado. Barcelona: Edicions de la Universitat Politecnica de

Catalunya.

Bertolín, J. A. (2008). SEGURIDAD DE LA INFORMACIÓN. Redes, Informática y

Sistemas de Información. Madrid, España: Paraninfo Cengage Learning.

KENNETH E. KENDALL, J. E. (2005). ANÁLISIS Y DISEÑO- SEXTA EDICION.

México: PEARSON EDUCACIÓN.

Mora, S. L. (2002). Programación de aplicaciones web: historia, principios básicos

y clientes web. San Vicente: Editorial Club Universitario.

Díaz, J. P. (s.f.). Gestión y Administración de proyectos. Recuperado el 26 de junio

de 2011 de 2011.

http://www.ciecem.uhu.es/centrodocumentacion/documentos/seminario/ponencias/

Gestio nProyectosPepe_Pino.pdfJosé Manuel Alonso, W. O. (14 de Marzo de

2005). Estándares Web del W3C. Recuperado el 2011 de 06 de 27, de

http://www.w3c.es/Presentaciones/2005/0314-estandares-JA/

Microsoft Corporation. (2011). ADO:NET Entity Framework. Recuperado el 26 de

octubre de 2011, de http://msdn.microsoft.com/en-us/library/bb399572.aspx

MSDN Microsoft. (2011). Introducción a Visual Studio. Recuperado el 26 de octubre de 2011, de http://msdn.microsoft.com/es-

es/library/fx6bk1f4%28v=VS.80%29.aspx

Nielsen, P. (2009). Microsoft SQL Server 2008 Bilble. Indianapolis: Wiley Publishing, Inc.

http://msdn.microsoft.com/en-us/library/bb399572.aspx

http://msdn.microsoft.com/es-es/library/fx6bk1f4%28v=VS.80%29.aspx

http://msdn.microsoft.com/es-es/library/fx6bk1f4%28v=VS.80%29.aspx


SGIPP-UCA

Pública, F. (s.f.). Manual de Seguridad en Redes. Recuperado el 08 de septiembre

de 2001, de http://www.arcert.gov.ar/webs/manual/manual_de_seguridad.pdf

Stallings, W. (2004). Fundamentos de seguridad en redes, Aplicaciones y

Estándares. Madrid: Pearson Educación.

Schmuller, J. (2000). Aprendiendo UML en 24 horas. México: Pearson Educación.

Quigley, K. H. (2011). SCRUM PROJECT MANAGEMENT. United States of America: CRC Press Taylor & Francis Group. Sparx Systems. (2007).Plataforma de Modelado Visual. Recuperado el 26 de

octubre de 2011, de http://www.sparxsystems.com/products/ea/

W3C ® Working Draft. (28 de Octubre de 2004). XML Schema Part 2: Datatypes

Second Edition. Recuperado el 27 de agosto de 2011, de

http://www.w3.org/TR/xmlschema-2/

W3C. (04 de 10 de 2008). Guía Breve sobre Estándares Web. Recuperado el 08

de 09 de 2011, de http://www.w3c.es/divulgacion/guiasbreves/Estándares

W3C Recommendation, W. D. (28 de Octubre de 2004). XML Schema Part 1:

Structures Second Edition. Recuperado el 06 de septiembre del 2011, de

http://www.w3.org/TR/xmlschema-1/

W3C, W. W. (2010). W3C España. Recuperado el 07 de septiembre de 2011, de

http://www.w3.org/

Universidad Centroamericana UCA, D. M. (2008). Politicas, Normas y

Procedimientos para Proyectos, Consultorias y Servicios. Managua, Nicaragua.


SGIPP-UCA

10. ANEXOS

10.1 Entrevistas

Entrevista 1

1. ¿Cuáles son los principales proceso que lleva a cabo la oficina?

La Oficina de Proyectos, Consultorías y Servicios (OPCS), y es la encargada de

dar seguimiento a la formulación, ejecución, control y evaluación financiera tanto

de los proyectos, consultorías y servicios que ofertan las diferentes entidades y

facultades de la universidad.

2. ¿Estos procesos siguen alguna normativa o metodología definida por la

Universidad o el área?

Si existe una normativa que fue publicada en el 2008 y tiene por nombre “Políticas,

Normas y Procedimientos para Proyectos, Consultorias y Servicios”, esta brinda

cada una de las normas necesarias en la administración y ejecución de todos los

procesos que se realizan en la oficina.

3. ¿Cuántas personas están involucradas actualmente en la realización de

las actividades?

Dos personas que se encuentran en la oficina, y hay apoyo por parte de las

entidades.

4. ¿Cuáles son los procesos principales que el sistema deberá

automatizar?

El sistema deberá de presentar y guardar la información de todos los proyectos

que se han ejecutado desde que se puso en operación la oficina, este debe de


SGIPP-UCA

permitir el cargar y descargar archivos digitales y debe de generar reportes de los

proyectos.

5. ¿El sistema solo llevará el control de los proyectos?

Si, no es necesario que se lleve control del resto de servicios que maneja la

oficina.

6. ¿Poseen un registro digital de los proyectos que han sido ejecutados?

No todavía, toda la información se encuentra en documentos físicos, se esta

empezando a guardar la información en hojas de Excel, pero no son muchos los

proyectos que se han digitalizado.

7. ¿Quiénes tendrán acceso al sistema? o ¿Cuáles son los usuarios

principales del sistema? y ¿Qué procesos realizarán?

El administrador de la oficina: Esta realizará la gestión de toda la información del

sistema, realizar búsquedas en el sistema, cargar y descargar archivos, y generar

los reportes de los proyectos.

Las personas que consultan la información: estos podrán realizar consultas y ver

la información general de los proyectos, cargar y descargar archivos así como

imprimir reportes.

De los anterior se determina que el sistema tendrá tres usuarios, el Administrador

de la OPCS, el administrador de SGIPP que gestionará todo lo relacionado con

usuarios, roles y permisos (aunque estas actividades pueden ser realizadas por la

misma administradora de la OPCS, se recomienda que a nivel de sistema se

manejen por separado) y el usuario consultor.


SGIPP-UCA

8. Con respecto a las búsquedas de los proyectos ¿Existe algún proceso

especifico en que se realizarán?

Si, las búsquedas serán realizadas por área temática, como por ejemplo:

proyectos orientados a “Medio Ambiente”. Y como será diversas áreas temáticas

agregó que también podrán ser gestionadas.

9. ¿Los proyectos podrán ser eliminados?

No, el sistema no debe de permitir que elimine ningún dato de proyectos, usuarios,

etc.

10. ¿Cuál es la información que se generan de los proyectos?

Nombre del Proyecto

Síntesis del proyecto

Facultad o entidad a la que pertenece el proyecto

Contacto de la entidad o facultad

Contraparte

Cuenta contable

Cuanta bancaria

Periodo de ejecución

Costo total

Aporte de la universidad

Aporte del financiante

Desembolsos

Anexos


SGIPP-UCA

Entrevista 2

1. ¿Todos los usuarios serán capaces de ver los proyectos, o existirán

permisos especiales para la visualización de los mismos?

No, deben de tener restricciones por usuario esto va en dependencia de la

facultad o entidad y del tipo de usuario.

2. ¿Existe alguna restricción en cuanto al formato y presentación de los

reportes?

Se definirán formatos específicos para los reportes en las etapas posteriores del

desarrollo del sistema.

3. ¿Se permitirá que los reportes puedan ser exportados a diferentes

formatos?

Se deberá permitir exportar los reportes al formato PDF o DOC.

4. Si el reporte es generado manualmente, ¿cuál es el proceso que se sigue

para elaborarlo?

El sistema debe tener la opción de generar un reporte en donde estará toda la

información de los proyectos.

5. Los archivos anexos ¿Tendrán algún formato especifico?

Se deben permitir cargar archivos en formato Excel, Word o PDF como

principales, pero deberá permitir otros tipos de archivos.


SGIPP-UCA

10.2 Desarrollo del Sistema




Desarrollo de un Sistema web para la gestión de la información del portafolio de

proyectos de la Universidad Centroamericana UCA

(SGIPP-UCA)

Desarrollo del Sistema

AUTOR:

Katherine Valeska Dumas Hernández (2007900008)


SGIPP-UCA

Historial de Revisiones

Fecha Versión Descripción Autor

28-10-2011 1.0 Herramientas de SCRUM Katherine Valeska

Dumas Hernández

08-11-2011 1.1 Revisión y actualización de

tablas

Katherine Valeska

Dumas Hernández

06-12-11 1.2 Revisión y actualización de

tablas

Katherine Valeska

Dumas Hernández


SGIPP-UCA

Tabla de Contenido

1. Introducción

2. Historias De Usuario

3. Lista de Product Backlog

4. Sprint 1

5. Sprint 2

6. Sprint 3


SGIPP-UCA

DEFINICIÓN DEL PROYECTO

1. Introducción

El presente documento brinda los resultados obtenidos al utilizar las herramientas

suministradas por SCRUM para el desarrollo del proyecto.

2. Historias De Usuario

Estas fueron tomadas a partir de las entrevistas realizadas con el usuario.

ID 1 Gestión de proyectos

Descripción



• Identificar todos los datos contenidos en la base de datos del sistema. Nivel de sistema: • Revisar cada uno de los campos para revisar que la información se carga correctamente.

Historia de usuario numero 1

ID 2 Búsqueda de proyectos

Descripción

Los Proyectos estarán organizados por diferentes áreas temáticas


• Organizar los proyectos por diferentes áreas temáticas. Nivel de sistema: • Se comprobará la creación de las áreas temáticas así como la organización de los proyectos.



SGIPP-UCA

ID 3 Anexos

Descripción

Se debe de permitir la carga de archivos digitales en diferentes tipos de formatos


• Se cargan archivos con información de los proyectos estos serán de diferentes extensiones: .pdf, .doc, .xls, Nivel de sistema: • Se probara el funcionamiento a la hora de cargar archivos


ID 4 Eliminación de información

Descripción

El sistema no debe de permitir que un proyectos ya registrado sea eliminado de

forma manual por el usuario


• El sistema no debe permitir eliminar ningún dato. Nivel de sistema: • Se comprobará el funcionamiento de estas acciones.


ID 5 Manejo de la información

Descripción

Se permitirá la actualización y modificación de cada dato guardado de los proyectos


• El sistema solo permite la actualización y modificación de los datos, no se permite eliminar. Nivel de sistema: • Se comprobará el funcionamiento de estas acciones.


ID 6 Usuarios

Descripción

El sistema será utilizado por dos tipos de usuario administrador OPCS y consultor,


SGIPP-UCA

pero también habrá un administrador del sistema.


• Identificar y listar cada actor y las funciones y datos a los que tiene acceso. • Crear pruebas para cada actor y verificar los permisos creando órdenes especificas. • Modificar el actor y repetir las pruebas para los mismos usuarios. Nivel de sistema: • Se comprobará el funcionamiento del sistema de autenticación de la aplicación, basado en las diferentes sesiones de usuario.


3. Lista de Product Backlog

ID Historia

Nombre de la Historia

Estado Prioridad Comentario

1


Planeado

Alta

Aquí se encontraran todos los datos específicos de los proyectos

2 Los Proyectos estarán organizados por diferentes áreas temáticas

Planeado Media Esto facilitara las búsquedas de los proyectos

3 Se debe de permitir la carga de archivos digitales en diferentes tipos de formatos

Planeado Media Permitirá un manejo de archivos más eficiente

4 El sistema no debe de permitir que un proyectos ya registrado sea eliminado de forma manual por el usuario

Planeado Alta Solo se cambiará de estado al proyecto pero no será eliminado por completo de la base de datos

5 Se permitirá la actualización y modificación de cada dato guardado de los proyectos

Planeado Media

6 El sistema será Planeado Alta Manejo de sesiones y vistas de los


SGIPP-UCA

utilizado por dos tipos de usuario administrador OPCS y consultor, pero también habrá un administrador del sistema.

proyectos por usuarios


SGIPP-UCA

4. Sprint 1


SGIPP-UCA

4.1 Gráficos


SGIPP-UCA


SGIPP-UCA

5. Sprint 2


SGIPP-UCA

5.1 Gráficos


SGIPP-UCA


SGIPP-UCA

6. Sprint 3


SGIPP-UCA

6.1 Gráficos


SGIPP-UCA


SGIPP-UCA

10.3 Documento de Casos de Uso






(SGIPP-UCA)

Documento de Casos de Uso y Diagramas

AUTOR:



SGIPP-UCA



28-10-2011 1.0 Creación y descripción de

Casos de Uso

Katherine Valeska

Dumas Hernández

08-11-2011 1.1 Actualización de diagramas Katherine Valeska

Dumas


Dumas


SGIPP-UCA

Tabla de Contenidos

1. Introducción

1.1 Propósito 1.2 Alcance 1.3 Referencias

2. Representación Arquitectural

3. Actores del Sistema

3.1 Detalles de Actores 4. Diagramas de Casos de Uso

4.1 Diagrama de caso de uso Nivel 0 4.2 Diagramas Nivel 1

Figura (5) Diagrama de caso de uso Consultor: 4.3 Diagramas de casos de uso Nivel 2

Figura (6) Diagrama de caso de uso Gestionar área temática: Figura (7) Diagrama de caso de uso Gestionar proyectos

5. Especificaciones de los casos de uso.

5.1 Tabla (2) especificación del Caso de Consultar Información del Proyectos 5.2 Tabla (3) especificación del caso de uso Generar Reporte 5.3 Tabla (4) especificación del Caso de Registrar Información de los Proyectos 5.4 Tabla (5) especificación del Caso de Modificar Proyectos 5.5 Tabla (6) especificación del Caso de Gestionar Área Temática 5.6 Tabla (8) especificación del Caso de Gestionar Usuario 5.7 Tabla (9) especificación del Caso de Gestionar Roles

6. Diagramas de secuencia

6.1 Diagrama consultar proyectos 6.2 Diagrama: Diagrama Generar Reportes 6.3 Diagrama: Diagrama gestionar área temática 6.4 Diagrama: Diagrama gestionar roles 6.5 Diagrama: Diagrama Gestionar usuario 6.6 Diagrama: Diagrama modificar proyectos 6.7 Diagrama: Diagrama registrar proyectos

7. Diagramas de estados

7.1 Diagrama: consultar proyecto 7.2 Diagrama: crear usuario 7.3 Diagrama: generar reporte 7.4 Diagrama: gestionar área temática


SGIPP-UCA

7.5 Diagrama: gestionar roles 7.6 Diagrama: modificar proyecto 7.7 Diagrama : registrar proyecto

8. Diagramas de colaboración


SGIPP-UCA

1. Introducción

1.1 Propósito

El propósito de la realización de este documento es de expresar y definir

claramente los casos de uso del sistema. Estos casos de uso fueron

especificados de acuerdo a la product backlog y las entrevistas realizadas al

usuario final.

1.2 Alcance

Estos casos de uso sirven para plantear las funcionalidades deseada del

sistema, por lo que cada uno tendrá una descripción, se tendrán las

especificaciones de todos los actores con los que se involucra SGIPP, sus

requerimientos asociados, una precondición, una pos condición, el escenario

de éxito y los escenarios alternos.

1.3 Referencias

Este documento explica los Casos de Uso en un grado más detallado que en

el documento de Arquitectura del sistema.

2. Representación Arquitectural

Para representar los Casos de Uso se utilizará el Diagrama de Casos de Uso

en notación UML, y realizados con la herramienta Enterprise Architect.

3. Actores del Sistema

La figura (1) muestra el diagrama de los actores del sistema. Estos serán los que

interactuarán con el sistema y las funcionalidades del mismo.


SGIPP-UCA

Figura 1. Diagrama de Actores.

3.1 Detalles de Actores

La Tabla (1) explica cada uno de los actores presentados en la Figura (1) que

corresponden a los usuarios del sistema.

Actor Descripción

Administrador de la OPCS Es el encargado de la OPCS, y podrá

realizar todas funciones relacionados

con la administración de la información

de los proyectos así como la creación

usuarios, roles y asignación de

permisos.

Administrador del Sistema Podrá ser el encargado de la OPCS o

cualquier otra persona ajena a esta

oficina, se encargará de gestionar roles,

usuarios y permisos.

Consultor de proyectos Es cualquier persona de las distintas

facultades de la UCA o financiante de

un proyecto, este solo podrá visualizar

la información de los proyectos.


SGIPP-UCA

4. Diagramas de Casos de Uso

En este apartado del documento se presentan los diferentes casos de usos en tres

niveles: 0,1 y 2 con una breve descripción de que representan.

4.1 Diagrama de caso de uso Nivel 0

Este diagrama corresponde al caso de uso general del sistema a como lo muestra

la figura (2). Representa los actores que podrán interactuar con el sistema.

Figura 2. Diagrama general del sistema

uc Caso de Uso 0 SGIPP


SGIPP-UCA

4.2 Diagramas Nivel 1

Figura (3) Diagrama de caso de uso Administrador de la OPCS: Este representa

cada una de las funcionalidades que podrá realizar el administrador de la OPCS

en el sistema.

Figura 3. Diagrama de Casos Administrador de la OPCS.


SGIPP-UCA

Figura (4) Diagrama de caso de uso Administrador SGIPP: este representa cada

una de las funcionalidades que podrá realizar el Administrador de SGIPP.

Figura 4. Diagrama de Casos de Uso Administrador SGIPP


SGIPP-UCA

Figura (5) Diagrama de caso de uso Consultor: Este diagrama representa las

funcionalidades que puede realizar el actor consultor en el sistema.

Figura 5. Diagrama Caso de Uso Consultor.

4.3 Diagramas de casos de uso Nivel 2

En esta etapa se detallan a un nivel más alto los casos de uso y aquí se presenta

a mayor escala la lógica del sistema.

Figura (6) Diagrama de caso de uso Gestionar área temática: en este diagrama se representa todas las funcionalidades que tienen que ver con la gestión del área temática en el sistema.


SGIPP-UCA

Figura 6. Diagrama de Caso de Uso “Gestionar Área Temática”.

Figura (7) Diagrama de caso de uso Gestionar proyectos: en este diagrama se representan todos los procesos que se realizan en la gestión de proyectos.

Figura 7. Diagrama de Caso de Uso “Gestionar Proyectos”.


SGIPP-UCA

Figura (8) Diagrama de caso de uso Registrar proyectos: en este diagrama se representan todos los procesos que se realizan en el registro de un proyectos.

Figura (8) Diagrama de caso de uso Registrar proyectos

5. Especificaciones de los casos de uso.

5.1 Tabla (11) especificación del Caso de Consultar Información del

Proyectos

ESPECIFICACIÓN DE CASO DE USO: Consultar Información Proyectos

Actores Consultor, Administrador OPCS

Propósito Visualizar toda la información de los proyectos guardada en el

sistema.

Descripción Permite la visualización de todos los datos del portafolio de proyecto

Precondiciones Usuario Autenticado como Consultor


SGIPP-UCA

Flujo Básico - Buscar la información del proyecto por fecha o nombre

- Elegir el proyecto que busca

Flujos

Alternativos

Búsqueda por área temática

- Realizar búsqueda por área temática

- Elegir el proyecto que busca

Post-condiciones No Aplica

5.2 Tabla (12) especificación del caso de uso Generar Reporte

ESPECIFICACIÓN DE CASO DE USO: Generar Reporte

Actores Consultor, Administrador OPCS

Propósito Imprimir la información de los proyectos guardada en el sistema.

Descripción Permite la impresión de toda la información relacionada del proyecto, así

como los anexos si existieren.

Precondiciones Usuario Autenticado

Flujo Básico - Buscar el proyecto que necesita

- Generar reporte de los datos que necesite

Flujos

Alternativos

- No hay

Post-condiciones Registros Impresos

5.3 Tabla (13) especificación del Caso de Registrar Información de los

Proyectos

ESPECIFICACIÓN DE CASO DE USO: Registrar Proyectos

Actores Administrador de la OPCS

Propósito Realizar el registro exitoso de los proyectos ejecutados por la OPCS.


SGIPP-UCA

Descripción Permite realizar el registro de los datos de cada uno de los proyectos

ejecutados por la OPSC, así como la selección del área temática a la

que pertenece y los documentos anexos del mismo, y la asignación de

los usuarios que podrán visualizar dicho proyecto.

Precondiciones Usuario Autenticado como Administrador

Flujo Básico - Ingresar los datos necesarios del nuevo proyecto

- Establecer el área temática al que pertenece el proyecto

- Agregar usuario que tendrá acceso a visualizar el proyecto.

Flujos

Alternativos

Cargar documentos Anexos

- Subir documentos anexos correspondientes al proyecto si los tiene.

Post-

condiciones

No Aplica

5.4 Tabla (14) especificación del Caso de Modificar Proyectos

ESPECIFICACIÓN DE CASO DE USO: Modificar Proyectos


Propósito Realizar las modificaciones necesarias de la información de los

proyectos ejecutados por la OPCS.

Descripción Permite realizar el cambio de los datos de cada uno de los proyectos

ejecutados por la OPSC.


Flujo Básico - Buscar el proyecto que será modificado.

- Modificar la información.

- Guardar los cambios.

Flujos

Alternativos

Cargar documentos Anexos

- Subir documentos anexos si fuera necesario.



SGIPP-UCA

5.5 Tabla (15) especificación del Caso de Gestionar Área Temática

ESPECIFICACIÓN DE CASO DE USO: Gestionar Área Temática


Propósito Realizar la creación, modificación y eliminación de las diferentes

áreas temáticas en las que se encuentran organizados los

proyectos ejecutados por la OPCS

Descripción Permite agregar, eliminar y modificar la información relacionada a

las diferentes áreas temáticas en los que estarán ubicados los

proyectos para una búsqueda más rápida.


Flujo Básico - Ingresar la nueva área temática

- Agregar los datos

- Guardar área temática

Flujos Alternativos Modificar área temática

- Buscar área temática

- Modificar la información del área a cambiar

- Guardar los cambios

Eliminar área temática

- Buscar área temática

- Eliminar área temática

Se pueden cancelar cualquiera de las opciones


5.6 Tabla (16) especificación del Caso de Gestionar Usuario

ESPECIFICACIÓN DE CASO DE USO: Gestionar Usuario

Actores Administrador SGIPP, Administrador de la OPCS

Propósito Realizar el registro, modificación y eliminación de los usuarios de SGIPP


SGIPP-UCA

Descripción Permite registrar, eliminar y modificar toda la información relacionada a

los usuarios que interactúan con el sistema.


Flujo Básico - Registrar usuario

- Ingresar la información del usuario

- Asignar rol

Flujos

Alternativos

Modificar usuario

- Buscar usuario

- Modificar la información


Eliminar usuario

- Buscar usuario

- Eliminar



5.7 Tabla (17) especificación del Caso de Gestionar Roles, permisos y

opciones

ESPECIFICACIÓN DE CASO DE USO: Gestionar Roles

Actores Administrador SGIPP, Administrador de la OPCS

Propósito Realizar la creación, modificación y eliminación de los roles

permitidos en SGIPP, así como la asignación de permisos y

opciones

Descripción Permite crear, eliminar y modificar toda la información

relacionada a los roles permitidos en el sistema, así como la

asignación de permisos.



SGIPP-UCA

Flujo Básico - Crear rol

- Asignar permisos y opciones

Flujos

Alternativos

Modificar rol

- Buscar rol

- Modificar permisos y opciones


Eliminar rol

- Buscar rol

- Eliminar


Post-

condiciones

No Aplica


SGIPP-UCA

6. Diagramas de secuencia

6.1 Diagrama consultar proyectos


SGIPP-UCA

6.2 Diagrama: Diagrama Generar Reportes


SGIPP-UCA

6.3 Diagrama: Diagrama gestionar área temática


SGIPP-UCA

6.4 Diagrama: Diagrama gestionar roles


SGIPP-UCA

6.5 Diagrama: Diagrama Gestionar usuario


SGIPP-UCA

6.6 Diagrama: Diagrama modificar proyectos


SGIPP-UCA

6.7 Diagrama: Diagrama registrar proyectos


SGIPP-UCA

7. Diagramas de estados

7.1 Diagrama: consultar proyecto

stm Consultar Proyecto


SGIPP-UCA

7.2 Diagrama: crear usuario

stm Crear Usuario

7.3 Diagrama: generar reporte

stm Generar Reportes

buscar proyecto

inicio

imprimiento reportev izualizando reporteesperando orden

generando reporte

definiento items de

búsqueda selecionando proyecto

Final

[Proyecto selecionado]

/generar reporte/modificar items de búsqueda

/seleccionar proyecto

/definir nuevo items de búsqueda

/búsqueda en

curso

/cancelación

/vizualizar reporte

/definir items para búsqueda

/imprimir reporte

/activar buscar proyecto


SGIPP-UCA

7.4 Diagrama: gestionar área temática

stm Gestionar Area Temática


SGIPP-UCA

7.5 Diagrama: gestionar roles

stm Gestionar Roles


SGIPP-UCA

7.6 Diagrama: modificar proyecto stm Modificar Proyect...

7.7 Diagrama : registrar proyecto

stm Registrar Proyecto


SGIPP-UCA

8. Diagramas de colaboración

8.1 Diagrama: Generar Reportes

sd Generar Reportes

8.2 Diagrama: Consultar Proyecto

sd Consultar Proyecto

:GUI

Control

Base de Datos

Usuario

Bandeja Area

Temática

Proyectos

1: AutenticarUsuario()

1.1: MenuOpciones()

1.2: VeridicarDatosUsuario()

2: BuscarProyecto()

2.1: ConcultaSQL()

2.2: LimpiarFormulario()

2.3: DatosValidos()

2.4: Lista=SolicitarAreaTemática()

2.5: Lista= DesplegarAreaTemática()

2.6: ListaAreasTemáticas()

3: SeleccinarAreatematica()

3.1: ListaDeProyectos()

3.2: Lista=SolicitarListaProyectos()

3.3: ListaProyectos()

3.4: ListaProyectos()

4: SeleccionarProyecto()

4.1: DesplegarProyecto()

5: Salir()


SGIPP-UCA

8.3 Diagrama: Registrar Proyecto

sd Registrar Proyecto


SGIPP-UCA

8.4 Diagrama: Gestionar usuario

sd Gestionar Usuario

Administrador SGIPP

:GUI

Bandeja Usuario

Control Base de Datos

1: OpcionGestionarUsuario()

1.1: CapturarSeleccion ()

2: CrearUsuario() 2.1: DesplegarDatos()

2.2: RegistrarDatos()

3: Guardar()

3.1: RegistrarNuevoUsuario()

3.2: RegistrarUsuario()

3.3: ExecuteCreate(SQL)

3.4: Aceptar()

3.5: Aceptar()

4: Salir()

5: ModificarUsuario() 5.1: DesplegarLista(Usuario)

5.2: DesplegarLista()

5.3: ModificarRegistros()

5.4: GuardarDatos(Usuario)

5.5: GuardarDatos()

5.6: ExecuteUpdate(SQL)

5.7: Aceptar()

5.8: Aceptar()

6: Salir()

7: EliminarUsuario()

7.1: DesplegarLista(Usuario)


7.3: EliminarRol()

7.4: EliminarRol()

7.5: EliminarDatos()

7.6: ExecuteDelete(SQL)

7.7: Aceptar()

7.8: Aceptar()

8: Salir()


SGIPP-UCA

8.5 Diagrama: Modificar proyecto

sd Modificar Proye...


SGIPP-UCA

8.6 Diagrama: Gestionar Roles

sd Gestionar Roles


SGIPP-UCA

8.7 Diagrama: Gestionar Área Temática

sd Gestionar Area Temática

Administrador OPCS

:GUI

Control Base de Datos

Bandeja Area Tematica

1: OpccionGestionarAreaTemática()

1.1: CapturarSelección()

2: CrearAreaTemática()

2.1: DesplegarDatos()

2.2: IngresarDatos()

3: Guardar()

3.1: AgregarAreaTemática()

3.2: RegistararAreaTemática()

3.3: ExecuteCreate(SQL)

3.4: Aceptar()

3.5: Aceptar()

4: ActualizarAreaTemática()

4.1: Lista=DesplegarListaAreaTemática()


4.3: ModificarDatosAreaTemática()

4.4: Guardar()

4.5: ActualizarDatos()

4.6: ExecuteUpdate(SQL)

4.7: Aceptar()

4.8: Aceptar()

5: EliminarAreaTemática()


5.2: Lista=DesplegarListaAreaTemática()

5.3: Eliminar()

5.4: EliminarDato()

5.5: EliminarAreaTemática()

5.6: ExecuteDelete(SQL)

5.7: Eliminado()5.8: Eliminado()

6: Salir()


SGIPP-UCA

10.4 Documento de Arquitectura del Sistema






(SGIPP-UCA)

Documento de Arquitectura del Sistema

AUTOR:



SGIPP-UCA



28-10-2011 1.0 Descripción de toda la

arquitectura y funcionalidades

del sistema

Katherine Valeska

Dumas Hernández

08-11-2011 1.1 Cambios en la arquitectura y

diagramas

Katherine Valeska

Dumas Hernández


Dumas Hernández


SGIPP-UCA

Tabla de contenido

1. Introducción

1.1 Propósito

1.2 Alcance

1.3 Visión General del documento

2. Representación de la arquitectura

3. Metas y Restricciones de la arquitectura

3.1 Metas

3.2 Restricciones del Sistema

4. Vista de Casos de Uso

5. Realizaciones de Casos de Uso

5.1 Caso de uso Administrador de la OPCS

5.2 Caso de Uso Administrador SGIPP

6. Vista Lógica

6.1 Descripción

6.2 Diseño en Capas

7. Vista de Proceso

7.1 Diagrama de clases

7.2 Diagrama Físico de la Base de Datos

8 Vista de Despliegue

9 Vista de Componentes

Descripción


SGIPP-UCA

1. Introducción

Uno de los documentos más importantes en el desarrollo de un sistema es el

documento de Arquitectura del sistema, este representa la estructura del mismo

ayudando a realizar diversos análisis que orienten el proceso de desarrollo y toma

de decisiones durante la ejecución.

El siguiente documento está basado en la plantilla que proporciona la metodología

RUP (Rational Unified Process) pero las especificaciones incluidas para su

desarrollo fueron tomadas de las historias de usuarios que se generan a partir de

la metodología SCRUM, las entrevistas realizadas al usuario, así como

recomendaciones de ambas metodologías.

1.1 Propósito

Este documento proporciona una descripción de la arquitectura del sistema.

1.2 Alcance

Este documento presenta la arquitectura en la cual estará basado SGIPP.

1.3 Visión General del documento

En secciones de este documento se detalla la arquitectura de SGIPP. Para ello se

presenta de manera clara los casos de uso del sistema, empleando un lenguaje

sencillo.


SGIPP-UCA

2. Representación de la arquitectura

La Arquitectura a utilizar será la de tres capas. Está la capa de presentación, es la

que comúnmente ve el usuario, la capa de negocio, aquí es donde se reciben las

peticiones del usuario mediante las reglas que se establecen del negocio, y la

capa de datos, que es en donde residen los datos y se lleva el control de los

mismo en este caso la base de datos.

3. Metas y Restricciones de la arquitectura

La meta principal de la arquitectura del sistema es el brindar los aspectos que

influirán en la etapa de Pregame.

Se tomarán en cuenta las siguientes metas y restricciones para el diseño de la

arquitectura del sistema:

3.1 Metas

1. El sistema deberá gestionar toda la información que generen los proyectos.

2. Los Proyectos estarán organizados por diferentes áreas temáticas.

3. Se permitirá la actualización y modificación de cada dato guardado de los

proyectos.

4. Se debe de permitir la carga de archivos digitales en diferentes tipos de

formatos.

5. El sistema será utilizado por dos tipos de usuario administrador OPCS y

consultor, pero también habrá un administrador del sistema.


SGIPP-UCA

3.2 Restricciones del Sistema

1. Necesariamente el sistema usará como motor de Base de Datos SQL

Server 2008.

2. El sistema estará desarrollado en Visual Studio 2010 y en lenguaje C#.

4. Vista de Casos de Uso

Los diagramas de casos de usos representa la forma en cómo un cliente opera el

sistema, además brinda al equipo de desarrollo realizar todas las funcionalidades

del sistema.

Cada caso de uso tiene una descripción que especifica la funcionalidad que se

incorporará al sistema propuesto.

En este apartado se mostraran los casos de uso más significativos del sistema, las

especificaciones a mas detalle se encuentran en el documento de definición de

casos de usos.


SGIPP-UCA

5. Realizaciones de Casos de Uso

5.1 Caso de uso Administrador de la OPCS

Fig. 1: Casos del uso Administrador OPCS


SGIPP-UCA

Generar Reportes

El propósito de este caso de uso es generar los reportes de los proyectos.

Gestionar de proyectos

El propósito de este caso de uso es permitir registrar, consultar y modificar toda la

información de los proyectos, así como los diferentes procesos que se pueden

llevar a cabo.

Gestionar área temática

El propósito de este caso de uso es permitir crear, modificar y eliminar las áreas

temáticas que permitirán la búsqueda de los proyectos.


SGIPP-UCA

5.2 Caso de Uso Administrador SGIPP

Fig. 2: Casos del uso Administrador SGIPP


SGIPP-UCA

Gestionar usuario

El propósito de este caso de uso es crear, eliminar y modificar las cuentas de

usuarios que tendrán acceso al sistema.

Gestionar Roles

El propósito de este caso de uso es crear, modificar, eliminar y asignar permisos

que serán otorgados a las cuentas de usuario.

6. Vista Lógica

6.1 Descripción

La vista lógica del sistema SGIPP está compuesta de tres paquetes: Interfaz de

usuario, lógica del negocio, y el acceso a datos.

Interfaz de usuario, contiene la parte visual del sistema, estos son los formularios

que utiliza el usuario para comunicarse con el sistema.

Interfaz de

Usuario

El paquete Lógica del Negocio contiene las normas que permiten llevar a cabo los

servicios del negocio.

Lógica del

Negocio

El Acceso de Datos contiene las conexiones que el sistema utiliza para manejar

los objetos con la Base de Datos.


SGIPP-UCA

Acceso a

Datos

6.2 Diseño en Capas

En la siguiente figura podemos observar la distribución de cada uno de los

paquetes en las capas del sistema.

Figura .3: Diagrama de Distribución de Capas del Sistema


SGIPP-UCA

7. Vista de Proceso

7.1 Diagrama de clases

Figura 4: Vista del Diagrama de Clases

dm sgipp

permisos::opciones

*PK id_opcion: int

nombre: varchar(max)

ruta: varchar(max)

«PK»

+ PK__opciones__EFAF42587D439ABD(int)

permisos::permisos

«column»

*PK Id_permiso: int

tipo_permiso: varchar(max)

fecha: datetime = (getdate())

estado: bit = ((1))

«PK»

+ PK_pERMISOS_Permisos(int)

permisos::roles

«column»

*PK id_rol: int

nombre_rol: varchar(max)


estado: bit = ((1))

«PK»

+ PK_roles_roles(int)

permisos::roles_x_permisos

«column»

*PK id_roles_x_permisos: int

*FK id_permiso: int

*FK id_rol: int

estado: bit = ((1))

*FK id_opcion: int


«PK»

+ PK__roles_x___3213E83F44FF419A(int)

«FK»

+ roles_x_permisos_fk2(int )

+ roles_x_permisos_fk3(int )

+ roles_x_permisos_fk(int )

permisos::usuario

«column»

*PK id_usuario: int


apellidos: varchar(max)

login: varchar

password: varchar


estado: bit = ((1))

*FK id_rol: int

«PK»

+ PK_usuario_usuario(int)

«FK»

+ usuario_fk(int )

permisos::usuario_proyecto

«column»

*PK id_usuario_x_proyecto: int

*FK id_proyecto: int

*FK id_usuario: int


estado: bit = ((1))

«PK»

+ PK_usuario_proyecto_usuario_proyecto(int)

«unique»

+ UQ_usuario_proyecto_id_usuario_proyecto(int)

«FK»

+ usuario_proyecto_fk2(int )

+ usuario_proyecto_fk(int )

proyectos::anexo_proyecto

«column»

*PK id_anexo: int

FK id_proyecto: int

ruta: varchar(max)


estado: bit = ((1))

nombre_anexo: varchar(max)

«PK»

+ PK_anexo_proy_anexo_proyecto(int)

«unique»

+ UQ_anexo_proy_id_anexo_proyecto(int)

«FK»

+ anexo_proyecto_fk(int )

proyectos::areas_tematicas

«column»

*PK id_area_tematica: int

nombre_area: varchar(max)


estado: bit = ((1))

«PK»

+ PK_areas_tematicas_areas_tematicas(int)

«unique»

+ UQ_areas_tematicas_id_area_tematica_areas_tematicas(int)

proyectos::bancos

«column»

*PK id_banco: int


descripcion: varchar(max)


estado: bit = ((1))

«PK»

+ PK__bancos__70BD164236B12243(int )

proyectos::contactos

«column»

*PK id_contacto: int

nombres: varchar(max)


telefono: varchar(max)

celular: varchar(max)

email: varchar(max)

direccion: varchar(max)


estado: bit = ((1))

«PK»

+ PK__contacto__099A52B82E1BDC42(int)

proyectos::contraparte

«column»

*PK id_contraparte: int

nombres: varchar(max)


telefono: varchar(max)

celular: varchar(max)

email: varchar(max)

direccion: varchar(max)


estado: bit = ((1))

«PK»

+ PK__contacto__3213E83F239E4DCF_contraparte(int)

proyectos::cuenta_contable

«column»

*PK id_cuenta_contable: int

codigo: varchar



estado: bit = ((1))

«PK»

+ PK__cuenta_c__3213E83F30F848ED(int)

«unique»

+ UQ__cuenta_c__40F9A20633D4B598(varchar)

proyectos::cuentas_bancarias

«column»

*PK id_cuenta_bancaria: int


codigo: varchar(max)

FK id_banco: int


estado: bit = ((1))

«PK»

+ PK__cuentas___2004CD98398D8EEE(int )

«FK»

+ cuentas_bancarias_fk(int )

proyectos::facultades

«column»

*PK id_facultad: int


descripcion: varchar(max)


estado: bit = ((1))

«PK»

+ PK__facultad__B583ABCE3D5E1FD2(int)

proyectos::objetiv os

«column»

*PK id_objetivo: int

objetivo: varchar(max)

*FK id_proyecto: int

estado: bit = ((1))


«PK»

+ PK__objetivo__380EF46073BA3083(int)

«FK»

+ objetivos_fk(int)

proyectos::proyectos

«column»

*PK id_proyecto: int

*FK id_area_tematica: int

nombre_pro: varchar(max)

sistesis_pro: varchar(max)

FK id_facultad: int

FK id_contacto: int

FK id_contraparte: int

FK id_cuenta_contable: int

FK id_cuenta_bancaria: int

periodo: int

costo_total: float

aporte_uca: float

aporte_financiante: float

desembolsos: int

anexos: bit


estado: bit = ((1))

«PK»

+ PK_Proyectos_ proyectos(int )

«FK»

+ Proyectos_fk(int )

+ Proyectos_ contactos_fk(int )

+ Proyectos_ fk4(int )

+ Proyectos_fk2(int )




SGIPP-UCA

Es el diagrama principal donde se determina el análisis y diseño de la aplicación.

En este diagrama se presentan las clases del sistema con sus relaciones.


SGIPP-UCA

7.2 Diagrama Físico de la Base de Datos

8 Vista de Despliegue

El Diagrama de Despliegue muestra de manera gráfica los nodos que conforman

el sistema, además los describe indicando la localización de las tareas en los

nodos físicos. Cada nodo representa un recurso de ejecución como una

computadora o servidor y se encuentra conectado con otros mediante un enlace

de comunicación. En este caso, la red será de tipo LAN.

cmp Diagrama de Despliegue

Switch«device»

Switch

Serv idor de

Aplicaciones

«device»

Adaptador

Etherne t

TCP-IPLAN

Figura 5: Diagrama de Despliegue del Sistema.

9 Vista de Componentes


SGIPP-UCA

Descripción

Esta contiene cada uno de los componentes de los que consta SGIPP

cmp diagrama de componentes

Interfaz de usuario

(Paginas aspx)

Lógica del negocio

Dataset (dssgipp)

Conección SQL Server 2008

Base de datos

(SGIPP)

Figura 7: Diagrama de Componentes del Sistema.


SGIPP-UCA

10.5 Diccionario de Datos






(SGIPP-UCA)

Diccionario de Datos

AUTOR:



SGIPP-UCA

Tabla de contenido


Introducción

Base de Datos SGIPP

Esquema Permisos con el detalle de las tablas

Esquema Permisos

Tabla “opciones”

Tabla “permisos”

Taba “roles”

Tabla “roles_x_permisos”

Tabla “usuario”

Tabla “usuario_proyecto”

Esquema Proyectos con el detalle de las tablas

Proyectos

Tabla “anexo_proyecto”

Tabla “areas_tematicas”

Taba “contactos”

Tabla “contraparte”

Tabla “cuenta_contable”

Tabla “cuentas_bancarias”

Tabla “facultades”

Tabla “objetivos”

Tabla “proyectos”


SGIPP-UCA


Introducción

El presente documento describe las Normas y Especificaciones de la Base de

Datos SGIPP para la posterior integración al del Sistema.

Este contiene cada una de las especificaciones de las tablas y los campos.

Base de Datos SGIPP

Tipo: Paquete

Detalle: Creado el 02/11/2011. Modificado el 02//11/2011.

Notas: Base de datos del sistema

Esquema Permisos con el detalle de las tablas

Esquema Permisos

Tipo: Paquete

Paquete: SGIPP

Detalle: Creado el 02/11/2011. Modificado el 04/11/2011.

Notas: Esquema de las tablas que manejan todo lo relacionado a la

seguridad del sistema

Tabla “opciones”

Database: SQL Server 2008,

StereoTipo: «table»,

Paquete: permisos

Detalles: Creado el 12/12/2011. Modificado el 18/12/2011.

Descripción: Tabla que contiene el detalle de las opciones que podrán manejar los

usuarios en el sistema.


SGIPP-UCA

Atributos

PK Nombre Tipo Not Null Unique Descripción

True id_opcion int True True Identificador del catalogo

de opciones.

False nombre varchar(max) False False Nombre de la opción

guardada en el catálogo.

False ruta varchar(max) False False Ruta en la que se

encuentra guardado el

archivo físico de la

opción.

Relaciones

Atributos Asociación Descripción

(id_opcion =

id_opcion)

0..* roles_x_permisos.roles_x_permisos_fk2

1

opciones.PK__opciones__EFAF42587D439AB

D

Tabla “permisos”

Database: SQL Server 2008,

StereoTipo: «table»

Paquete: permisos


Descripción: Tabla que contiene los permisos que tendrán los usuarios para

manejar las opciones del sistema. Entre estos están: Crear, leer,

editar, eliminar y usuarios por proyectos.


SGIPP-UCA

Atributos


True Id_permiso int True True Identificador del permiso.

False tipo_permiso varchar(max) False False Nombre del tipo de

permiso.

False fecha datetime False False Fecha de creación del

registro.

False estado bit False False Estado del registro, este

puede ser activo 1, o

inactivo 0.

Relaciones


(id_permiso =

Id_permiso)

0..* roles_x_permisos.roles_x_permisos_fk3

1 permisos.PK_pERMISOS_Permisos

Taba “roles”

Database: SQL Server 2008


Paquete: permisos


Descripción: Tabla de los roles existentes en el sistema.

Atributos


True id_rol int True True Identificador del rol

creado.


SGIPP-UCA

False nombre_rol varchar

(max)

False False Nombre del rol registrado.

False fecha datetim

e

False False Fecha de creación del

registro.



inactivo 0.

Relaciones


(id_rol = id_rol) 0..* usuario.usuario_fk

1 roles.PK_roles_roles

(id_rol = id_rol) 0..* roles_x_permisos.roles_x_permisos_fk


Tabla “roles_x_permisos”



Paquete: permisos


Descripción: Tabla de los permisos asignados a cada rol en el sistema.

Atributos


True id_roles_x_per

misos

int True True Identificador del registro

creado.


SGIPP-UCA

False id_permiso int True False Identificador de la tabla de

permisos.

False id_rol int True False Identificador de la tabla de

roles.


puede ser activo 1, o inactivo

0.

False id_opcion int True False Identificador de la tabla de

opciones del sistema.


registro.

Relaciones


(id_rol = id_rol) 0..* roles_x_permisos.roles_x_permisos_fk


(id_permiso = Id_permiso) 0..* roles_x_permisos.roles_x_permisos_fk3

1 permisos.PK_pERMISOS_Permisos

(id_opcion = id_opcion) 0..* roles_x_permisos.roles_x_permisos_fk2

1

opciones.PK__opciones__EFAF42587D

439ABD

Tabla “usuario”



Paquete: permisos


SGIPP-UCA


Descripción: Tabla de registros de los usuarios que tienen acceso al sistema.

Atributos


True id_usuario int True True Identificador del registro de

usuario.

False nombre varchar(

max)

False False Primer y segundo nombre del

usuario.

False apellidos varchar(

max)

False False Primer y segundo apellido del

usuario.

False login varchar False False Nick Nombre o login del

usuario en el sistema.

False password varchar False False Contraseña del usuario para

ingresar al sistema.

False fecha datetim

e

False False Fecha de creación del

registro.


puede ser activo 1, o inactivo

0.

False id_rol int True False Identifiacador de la tabla roles.

Relaciones


(id_usuario =

id_usuario)

0..* usuario_proyecto.usuario_proyecto_fk2

1 usuario.PK_usuario_usuario

(id_rol = id_rol) 0..* usuario.usuario_fk


SGIPP-UCA


Tabla “usuario_proyecto”



Paquete: permisos


Descripción: Tabla de registros de los usuarios asignados a un proyecto.

Atributos


True id_usuario_x_

proyecto

int True True Identificador del registro de

usuario por proyecto.

False id_proyecto int True False Identificador de la tabla

proyectos.

False id_usuario int True False Identificador de la tabla

usuario.


registro.



inactivo 0.

Relaciones


(id_usuario =

id_usuario)

0..* usuario_proyecto.usuario_proyecto_fk2

1 usuario.PK_usuario_usuario

(id_proyecto = 0..* usuario_proyecto.usuario_proyecto_fk


SGIPP-UCA

id_proyecto) 1 proyectos.PK_Proyectos_proyectos

Esquema Proyectos con el detalle de las tablas

Proyectos

Tipo: Paquete

Paquete: SGIPP

Detalle: Creado el 02/11/2011. Modificado el 04/11/2011.

Notas: Esquema que contiene las tablas principales del sistema.

Tabla “anexo_proyecto”



Paquete: proyectos


Descripción: Tabla o catálogo de los registros de los documentos anexos a cada

uno de los proyectos.

Atributos


True id_anexo int True True Identificador del

registro de anexos.

False id_proyecto int False False Identificador de la

tabla de proyectos.

False ruta varchar(max) False False Ruta física donde se

guarda el documento

anexo al proyecto.


SGIPP-UCA


registro.

False estado bit False False Estado del registro,

este puede ser activo

1, o inactivo 0.

False nombre_anex

o

varchar(max) False False Nombre del

documento anexo.

Relaciones


(id_proyecto =

id_proyecto)

0..* anexo_proyecto.anexo_proyecto_fk

1 proyectos.PK_Proyectos_proyectos

Tabla “areas_tematicas”



Paquete: proyectos


Descripción: Tabla o catálogo que contiene las áreas temáticas, que facilitará la

búsqueda de los proyectos por categorías.

Atributos


True id_area_temat

ica

int True True Identificador del

registro

almacenado.

False nombre_area varchar(max) False False Nombre

correspondiente

al área


SGIPP-UCA

temática.

False fecha datetime False False Fecha de

creación del

registro.

False estado bit False False Estado del

registro, este

puede ser activo

1, o inactivo 0.

Relaciones


0..* proyectos.Proyectos_fk

1areas_tematicas.UQ_areas_tematicas_id_ar

ea_tematica_areas_temat...

Tabla “bancos”



Paquete: proyectos


Descripción: Tabla o catálogos de bancos.

Atributos


True id_banco int True True Identificador del

registro de bancos.

False nombre varchar(max) False False Nombre del banco.

False descripcion varchar(max) False False Breve descripción del


SGIPP-UCA

banco.


registro.



1, o inactivo 0.

Relaciones


(id_banco = id_banco) 0..*cuentas_bancarias.cuentas_bancarias_fk

1bancos.PK__bancos__70BD164236B12243

Taba “contactos”



Paquete: proyectos


Descripción: Tabla o catálogo donde se encuentran almacenamos todos los

contactos asociados al proyecto.

Atributos


True id_contacto int True True Identificador del

registro de contacto.

False nombres varchar(max) False False Primer y segundo

nombre del contacto.

False apellidos varchar(max) False False Primer y segundo

apellido del contacto.


SGIPP-UCA

False telefono varchar(max) False False Número de télefono

convencional del

contacto, ya sea de la

oficina o de la casa de

habitación.

False celular varchar(max) False False Número celular del

contacto.

False email varchar(max) False False Dirección del correo

electronico del

contacto.

False direccion varchar(max) False False Dirección donde

localizar al contacto.


registro.



1, o inactivo 0.

Relaciones


(id_contacto =

id_contacto)

0..* proyectos.Proyectos_contactos_fk

1contactos.PK__contacto__099A52B82E1BD

C42

Tabla “contraparte”



Paquete: proyectos



SGIPP-UCA

Descripción: Tabla o catálogo donde se encuentran almacenamos todos los datos

de la contraparte asociada al proyecto.

Atributos


True id_contraparte int True True Identificador del registro de

contacto.

False nombres varchar(max) False False Primer y segundo nombre

de la contraparte.

False apellidos varchar(max) False False Primer y segundo apellido

de la contraparte

False telefono varchar(max) False False Número de teléfono

convencional de la

contraparte, ya sea de la

oficina o de la casa de

habitación.

False celular varchar(max) False False Número celular de la

contraparte.

False email varchar(max) False False Dirección del correo

electrónico de la

contraparte.

False direccion varchar(max) False False Dirección donde localizar al

contacto.


registro.



inactivo 0.


SGIPP-UCA

Relaciones


(id_contraparte =

id_contraparte)

0..* proyectos.Proyectos_fk4

1contraparte.PK__contacto__3213E83F239E4

DCF_contraparte

Tabla “cuenta_contable”



Paquete: proyectos


Descripción: Tabla o catálogo de los registros de las cuentas contables de los

proyectos.

Atributos


True id_cuenta_con

table


registro de cuentas

contables.

False codigo varchar False True Número o código de la

cuenta contable

asociada al proyecto.

False nombre varchar(max) False False Nombre de la cuenta

contable.


registro.




SGIPP-UCA

1, o inactivo 0.

Relaciones


(id_cuenta_contable =

id_cuenta_contable)


1cuenta_contable.PK__cuenta_c__3213E83F

30F848ED

Tabla “cuentas_bancarias”



Paquete: proyectos


Descripción: Tabla o catálogo de las cuentas bancarias asociadas a cada

proyecto registrado.

Atributos


True id_cuenta_ban

caria


registro de la cuenta

bancaria.

False nombre varchar(max) False False Nombre de la cuenta

bancaria.

False codigo varchar(max) False False Número o código de la

cuenta bancaria.

False id_banco int False False Identificador de la

tabla bancos.


registro.


SGIPP-UCA



1, o inactivo 0.

Relaciones


(id_cuenta_bancaria =

id_cuenta_bancaria)


1

cuentas_bancarias.PK__cuentas___2004CD9

8398D8EEE

(id_banco = id_banco) 0..*

cuentas_bancarias.cuentas_bancarias_

fk

1

bancos.PK__bancos__70BD164236B1

2243

Tabla “facultades”



Paquete: proyectos


Descripción: Tabla o catálogo de las facultades o entidades relacionadas a la

ejecución o creación de un proyecto.

Atributos


True id_facultad int True True Identificador del

registro de las


SGIPP-UCA

faculatades o

entidades.

False nombre varchar(max) False False Nombre de la facultad

o entidad.

False descripcion varchar(max) False False Breve descripción de

la facultad o entidad.


registro.



1, o inactivo 0.

Relaciones


(id_facultad =

id_facultad)


1

facultades.PK__facultad__B583ABCE3

D5E1FD2

Tabla “objetivos”



Paquete: proyectos


Descripción: Tabla o catálogo donde se almacenan los objetivos por cada

proyecto.


SGIPP-UCA

Atributos


True id_objetivo int True True Identificador del

objetivo

False objetivo varchar(max) False False Texto del objetivo.

False id_proyecto int True False Identificador del

proyecto asociado de

la tala proyectos.



1, o inactivo 0.


registro.

Relaciones


(id_proyecto =

id_proyecto)

0..* objetivos.objetivos_fk


Tabla “proyectos”



Paquete: proyectos


Descripción: Tabla que contiene todos los datos relacionados a la creación de un

proyecto.


SGIPP-UCA

Atributos


True id_proyecto int True True Identificador del

proyecto registrado.

False id_area_temat

ica

int True False Identificador de la

tabla de áreas

temáticas.

False nombre_pro varchar(max) False False Nombre del proyecto

registrado.

False sistesis_pro varchar(max) False False Síntesis o resumen

del proyecto.

False id_facultad int False False Identificador de la

facultad a la que

pertenece el proyecto.

False id_contacto int False False Identificador del

registro del contacto

del proyecto.

False id_contraparte int False False Identificador de la

contraparte asociada

al proyecto.

False id_cuenta_con

table

int False False Identificador de la

cuenta contable

asignada al proyecto.

False id_cuenta_ban

caria

int False False Identificador de la

cuenta bancaria

asignada al proyecto.

False periodo int False False Periodo de ejecución

del proyecto esto


SGIPP-UCA

dado en meses.

False costo_total float False False Costo total para llevar

a cabo el proyecto.

False aporte_uca float False False Aporte que realiza la

universidad al costo

total del proyecto.

False aporte_financi

ante

float False False Aporte que realiza la

entidad financiante al

costo total del

proyecto.

False desembolsos int False False Desembolsos

realizados durante

todo el periodo de

ejecución del

proyecto.

False anexos bit False False Documentos anexos

del proyecto.


registro.



1, o inactivo 0.

Relaciones


(id_facultad =

id_facultad)


1

facultades.PK__facultad__B583ABCE3


SGIPP-UCA

D5E1FD2

(id_cuenta_bancaria =

id_cuenta_bancaria)


1

cuentas_bancarias.PK__cuentas___20

04CD98398D8EEE

(id_cuenta_contable =

id_cuenta_contable)


1

cuenta_contable.PK__cuenta_c__3213

E83F30F848ED

(id_contraparte =

id_contraparte)


1

contraparte.PK__contacto__3213E83F2

39E4DCF_contraparte

(id_contacto =

id_contacto)

0..* proyectos.Proyectos_contactos_fk

1

contactos.PK__contacto__099A52B82E

1BDC42

0..* proyectos.Proyectos_fk

1

areas_tematicas.UQ_areas_tematicas_i

d_area_tematica_areas_temat...

(id_proyecto =

id_proyecto)

0..* objetivos.objetivos_fk


(id_proyecto =

id_proyecto)

0..* anexo_proyecto.anexo_proyecto_fk


(id_proyecto =

id_proyecto)

0..* usuario_proyecto.usuario_proyecto_fk



SGIPP-UCA

10.6 Glosario de Términos






(SGIPP-UCA)

Glosario de Términos

AUTOR:



SGIPP-UCA



08-11-2011 1.0 Glosario de Términos del

Sistema

Katherine Valeska

Dumas Hernández


SGIPP-UCA

Tabla de Contenido

GLOSARIO DE TARMINOS

Aplicación

Base de Datos

Contraseña

OPCS

Product Backlog

RUP

SCRUM

SGIPP-UCA

Sprints

webapp

workflows


SGIPP-UCA

GLOSARIO DE TERMINOS

Introducción

Este documento es una lista de conceptos detallados en forma de diccionario, este

se incluyen términos o palabras con su respectivo significado. Este fue creado con

el propósito de brindar un mejor entendimiento del sistema.

Algunos de los términos fueron tomados de estándares internacionales y otros

fueron adaptados a partir de esos estándares.

Glosario

Este se encuentra dividido en orden alfabético y contiene la palabra y su

significado en términos simples.

A

Aplicación Conjunto de programas informáticos que incluyen las funcionalidades definidas para la ejecución de las tareas inherentes a un área dentro de una Organización.

B Base de Datos Conjunto de datos pertenecientes a un mismo contexto y

almacenados sistemáticamente para su posterior uso. C Contraseña Conjunto finito de caracteres limitados que forman una

palabra secreta que sirve a un usuario para acceder a un determinado recurso.

E Enterprise Architect Herramienta que permite el modelado del sistema mediante

la diagramación. O OPCS Oficina de Proyectos, Consultorías y Servicios de la UCA P Product Backlog Herramienta de la metodología SCRUM que permite llevar

el control mediante las historias del usuario para obtener los requisitos del sistema


SGIPP-UCA

R RUP Metodología de desarrollo tradicional Rational Unified

Process S SCRUM Metodología de desarrollo ágil, en la cual se encuentra

basado el sistema.

SGIPP-UCA Sistema para la Gestión de Información del Portafolio de

Proyecto de la Universidad Centroamericana UCA Sprints Herramienta de metodología SCRUM que permite llevar el

control de las actividades del proyecto durante cada iteración.

W webapp Web application o webapp. Es una aplicación web o

cualquier aplicación que es accedida vía web por una red. workflows

El Flujo de trabajo (WorkFlow en inglés) es el estudio de los aspectos operacionales de una actividad


SGIPP-UCA

10.7 Manual de Usuario






(SGIPP-UCA)

Manual de Usuario

AUTOR:



SGIPP-UCA



06-11-2011 1.0 Manual de descripciones para el

usuario

Katherine Valeska

Dumas Hernández

10-01-2012 1.2 Actualización Katherine Valeska

Dumas Hernández


SGIPP-UCA

Tabla de Contenido

Opciones del Sistema

Botones de navegación estándares

Ingreso al sistema mediante el login.

Catálogos de proyectos (Opciones básicas)

Vista General Vista Nuevos Registros

Gestión de proyectos

Vista Principal Vista de Informacion de proyectos Vista de registrar o editar proyectos Vista agregar o ver objetivos Vista de descargar o cargar anexos Vista de asignar usuarios por proyecto Vista de reportes

Gestión de roles y permisos


SGIPP-UCA

MANUAL DE USUARIO

Introducción

El objetivo de este documento es el mostrar al usuario las funcionalidades del

sistema partiendo de cada unos de los controles que se incluyen en las pantallas.

Opciones del Sistema

El presente Manual está organizado de acuerdo a la secuencia de ingreso a las

pantallas del sistema de la siguiente manera:

1. Botones de navegación estándar.

2. Ingreso al sistema mediante el login.

2. Catálogos de proyectos (Opciones básicas)

3. Gestión de proyectos

4. Gestión de roles y permisos

Botones de navegación estándares

------ Agregar Registro o Nuevo Registro

------ Indica una búsqueda

------ Indica cancelar o regresar a la página anterior

------ Eliminar un registro

------ Guardar el registro

----- Información de un registro

----- Actualizar y recargar la pagina

---- Editar registros


SGIPP-UCA

Ingreso al sistema mediante el login.

Ventana principal del sistema

Figura 1. Vista Principal

En esta pantalla el usuario debe digitar el nombre del usuario y su clave luego

presionar sobre el botón entrar tal como se muestra en la figura siguiente.

Figura 2. Login


SGIPP-UCA

Posteriormente carga la pantalla de opciones o menú, aquí se encuentran todas

los catálogos y opciones a los que tiene permiso el usuario logueado. Esto se

muestra en la imagen siguiente. Así como el nombre del usuario y el botón de

cerrar sesión (esto se mantiene en todos los formularios).

Figura 3. Pantalla de menú u opciones

Catálogos de proyectos (Opciones básicas)

Vista General

Las opciones:

Áreas temáticas

Bancos

Contactos

Contraparte

Menú de opciones


SGIPP-UCA

Cuenta contable

Cuenta Bancaria

Facultades

Usuarios

Roles

Son formularios que tienen las mismas características que se describen a

continuación.

Figura 4. Ventana de Catálogos

Los detalles de navegación, así como los botones son estándares para todos los

formularios de la aplicación.

La pantalla muestra en la parte superior las opciones y actividades que se pueden

realizar en los catalogos. Entre estas se encuentran:


SGIPP-UCA

1- El botón carga la vista de ingresar registros nuevos.

2- El botón que permite recargar la pagina y actualizar los

datos automáticamente después de realizada una búsqueda.

3- Luego tenemos la barra de búsqueda esta va a ser de acuerdo a los

parámetros que establezca el usuario

4- A la par de la barra de búsqueda se encuentra el botón de imprimir

este sirve para imprimir una captura de los datos que

existen.

5- Debajo de la barra de opciones tenemos la vista de los datos que existen

dependiendo de qué catalogo se esté cargando Figura (5).

Figura 5. Vista de los datos

Elimin

ar

Editar


SGIPP-UCA

Este también contiene los botones de eliminar y editar el registro al que se

seleccione. En la parte inferior derecha está la barra de navegación para la

paginación.

Vista Nuevos Registros

Figura 6. Vista de nuevos registros.

En la vista de nuevo registro se muestran los controles de la siguiente manera. En

la tabla están los datos que pertenecen al catalogo que se vaya a guardar luego

están los botones de guardar registro y cancelar .

(Esta vista es la misma para editar el registro con la diferencia que en los cuadros

de texto se muestran los datos pertenecientes al registro)

Número de

registros visibles

por página

Numero de

páginas totales

Navegación


SGIPP-UCA

Gestión de proyectos

Vista Principal

En esta pantalla se muestran todas actividades que se pueden realizar en la

gestión de la información de un

proyecto.

Figura 7. Vista General de Proyectos

Vista de Informacion de proyectos

La figura (8) muestra la vista de ver información se cargan las siguientes opciones:

Ver información de

los proyectos

Editar

Eliminar

Objetivos del

proyecto

Anexos del

proyecto

Usuarios

Asignado al

proyecto

Usuarios

Asignado al

proyecto

Imprimir

Reporte del

proyecto


SGIPP-UCA

Figura 8. Vista de información de proyectos

Al dar click al botón de información se muestran unas pestañas con toda la

información que corresponde al proyecto seleccionado, asi como el botón

que regresa a la pagina principal de proyectos.

Figura 9. Pestañas de información de un proyecto.

Vista de registrar o editar proyectos

Dar click en nuevo y editar se cargan las siguientes pestañas


SGIPP-UCA

Figura 10. Nuevo Registro de proyecto

Vista agregar o ver objetivos

Cuando se selección la opción de objetivos se cargan de la siguiente manera

Figura 11. Objetivos

El nombre del proyecto, una caja de texto donde se agrega el objetivo se guarda el

objetivo así como puede realizarse la impresión del reporte, este también tiene el

botón de eliminar y el botón que me regresa a la página de proyectos.

Vista de descargar o cargar anexos

Al dar click en el botón de anexos se cargan los siguientes controles:

Botón para

agregar un

objetivo


SGIPP-UCA

Figura 12. Anexos

En esta pantalla se carga el nombre del proyecto al que se le añadirán anexos,

una caja de texto donde se pone el nombre del archivo, luego se encuentra la

barra para seleccionar el archivo desde los documentos en la computadora

posteriormente a la derecha está el botón de cargar archivo al servidor, este

guarda el archivo.

Después se cargan los datos de los anexos existentes, este tienen su botón para

eliminar anexo y para descargar el archivo a la computadora. Así como su botón

de atrás e imprimir reporte.

Vista de asignar usuarios por proyecto

Al dar click al botón de usuarios asignados a los proyectos, se carga la siguiente

vista de controles:

Botón para

cargar

archivos

Botón para

descargar

archivos

Barra para

seleccionar el

archivo que

será cargado


SGIPP-UCA

Figura 13. Usuarios por proyecto

Esta contiene el nombre del proyecto al que le serán asignados los usuarios que

podrán tener acceso a él, luego está la lista de usuarios registrados en el sistema,

al seleccionar el usuario se le da click al botón de guardar registro. También

contiene el botón de imprimir reporte, cancelar y atrás.

Vista de reportes

Al dar click en el botón de imprimir reporte, se genera una vista previa de dicho

reporte, que contiene toda la información relacionada a un proyecto.

Gestión de roles y permisos

Figura 14. Roles, permisos y opciones del sistema

Usuarios

registrados en

el sistema

Botón para

guardar

registro

Anadir o editar

permisos y opciones

por usuario


SGIPP-UCA

En la pantalla de gestión de roles y permisos se carga toda la información de

roles, permisos y opciones que pueden ser otorgados a un usuario del sistema, al

dar click en el botón de permisos se carga la siguiente vista:

Figura 15. Registro de roles y opciones

En esta vista se cargan el nombre del rol al que se le asignaran los permisos,

después tenemos la lista de vistas, catálogos u opciones del sistema y al lado

derecho los permisos (leer, crear, eliminar, editar y asignar usuarios a los

proyectos) que puede tener cada catálogo. Se encuentra el botón de agregar

registro, imprimir, eliminar y atrás.

Opciones

del

sistema

Permisos

que puede

tener cada

opción

FORMA DE CULMINACION DE ESTUDIOS - UCA

Documents

Transcript of FORMA DE CULMINACION DE ESTUDIOS - UCA