informe usp 2015v2.2

UNIVERSIDAD SAN PEDRO VICERRECTORADO ACADÉMICO Oficina Central de Investigación Universitaria

UNIVERSIDAD SAN PEDRO

FACULTAD DE INGENIERÍA

ESCUELA ACADÉMICO PROFESIONAL DE

INGENIERÍA

INFORMÁTICA Y DE SISTEMAS

Informe “Sistema Web para el Control de Proyectos

para la Escuela de Ingeniería Informática y de Sistemas”

para Obtener el Grado de Bachiller en Ingeniería

Informática y Sistemas

AUTORES:

BARRETO LAVADO NAPOLEÓN

PEREDA QUIJANO MIGUEL

CHIMBOTE - JUNIO

2015


Índice PALABRAS CLAVE. ............................................................................................................. - 1 -

Titulo ....................................................................................................................................... - 2 -

RESUMEN ............................................................................................................................... - 3 -

ABSTRACT ............................................................................................................................. - 4 -

INTRODUCCIÓN .................................................................................................................. - 5 -

1. Antecedentes y fundamentación científica ................................................................ - 6 -

2. Justificación de la investigación ................................................................................. - 8 -

3. Problema ...................................................................................................................... - 8 -

4. Marco referencial ........................................................................................................ - 9 -

DESCRIPCION DE LA METODOLOGIA ........................................................................... - 12 -

METODOLOGÍAS AGILES EN ELDESARROLLO DEL SOFTWARE ........................ - 12 -

METODOLOGIA AGIL SCRUM ...................................................................................... - 14 -

Participantes y roles ........................................................................................................... - 16 -

Product Owner: ............................................................................................................. - 16 -

Scrum Master: ............................................................................................................... - 17 -

Scrum Team: ................................................................................................................. - 17 -

Usuario o cliente: ........................................................................................................... - 17 -

Elementos esenciales que constituyen la metodología Scrum: ........................................ - 17 -

Product Backlog .............................................................................................................. - 17 -

Daily Scrum Meeting ...................................................................................................... - 17 -

Actualizando el Sprint Backlog ....................................................................................... - 18 -

Revisión del Sprint .......................................................................................................... - 18 -

Retrospectiva del Sprint ................................................................................................. - 18 -

Ciclo de vida de la metodología ágil Scrum: .................................................................. - 19 -

BASE DE DATOS: MySQL ............................................................................................... - 20 -

Aplicaciones .................................................................................................................... - 21 -

Características ................................................................................................................. - 21 -

LENGUAJE DE PROGRAMACIÓN: PHP ....................................................................... - 22 -

Características ................................................................................................................. - 23 -

5. Hipótesis ..................................................................................................................... - 25 -

6. OBJETIVOS .............................................................................................................. - 25 -

6.1. OBJETIVO GENERAL ................................................................................... - 25 -


6.2. Objetivos Específicos. ....................................................................................... - 25 -

7. METODOLOGÍA DEL TRABAJO ............................................................................ - 26 -

APLICACIÓN DE LA METODOLOGÍA UTILIZANDO SCRUM ................................. - 26 -

REQUERIMIENTOS DEL SISTEMA ........................................................................... - 27 -

SPRINT Nº 001 .................................................................................................................. - 28 -

TAREA SPRINT 001 ..................................................................................................... - 28 -

TAREAS REALIZADAS EN EL SPRINT Nº 001 ......................................................... 29

SPRINT Nº 002 ....................................................................................................................... 31

TAREA SPRINT 001 ........................................................................................................ 31

Tareas Realizadas en el Sprint Nº 002 ............................................................................. 32

RESULTADOS ........................................................................................................................... 33

ANÁLISIS Y DISCUSIÓN ........................................................................................................ 34

CONCLUSIONES ...................................................................................................................... 35

RECOMENDACIONES ............................................................................................................. 36

REFERENCIAS .......................................................................................................................... 37

ANEXOS .................................................................................................................................... 38

- 1 -


PALABRAS CLAVE.

KEYWORDS:

TEMA SISTEMA

WEB

Especialidad Ingeniería Del

Software

Objetivo Desarrollo

Método Descriptivo

THEME SYSTEM

WEB

Speciality Software

Engineering

Objetive Development

Method Descriptive

- 2 -


Titulo

INFORME “SISTEMA WEB PARA CONTROL DE

PROYECTOS PARA LA ESCUELA DE

INGENIERÍA INFORMÁTICA Y SISTEMAS”

PARA OBTENER EL GRADO DE BACHILLER EN

INGENIERÍA INFORMÁTICA Y SISTEMAS

- 3 -


RESUMEN

El presente proyecto a realizar se desarrolla en el marco de los repositorios

virtuales para almacenar contenidos digitales que permitirán a los alumnos

y egresaos tener acceso al material digital que le servirá de apoyo para las

investigaciones que tengan a fututo.

Se presenta una propuesta de diseño de un sistema web para el control de

proyectos para la escuela de “Ingeniería informática y de sistemas” de

la universidad privada San Pedro y filiales.

Para lograr el éxito de este proyecto se trabajara bajo la metodología

SCRUM para gestionar el desarrollo del software.

El sistema web permitirá organizar, mantener los proyectos(tesis y

prácticas pre-universitaria ) que han sido aprobadas por dicha escuela,

como también hacer la consulta respectiva para la verificación que dichos

proyectos que están en curso no se repitan de los que ya están

documentados.

- 4 -


ABSTRACT

To carry out this project is developed within the framework of the virtual

repositories to store contained digital that they will enable students and

graduating you have access to the digital material that will serve as a

support for investigations that have a future.

A proposal of design of a web system for the control of projects to the

school's "Computer and systems engineering" of the Universidad Privada

San Pedro and subsidiaries-headquarters.

To achieve the success of this project work low SCRUM methodology for

managing software development.

The repository will allow organizing, keep projects (thesis and College

practices) that have been approved by the school, as also do the respective

query to verify that these projects that are underway are not repeated that

already are documented.

- 5 -


INTRODUCCIÓN

El uso creciente de la tecnología de la información en la actividad

institucional ha dado lugar a que las entidades de hoy en día, busquen

agilizar sus procesos haciéndolos más rápidos, flexibles y eficientes.

En la actualidad el manejo de la información se hace un tanto complejo

cuando de grandes bloques se trata. Lo cierto es que vivimos en una

sociedad donde sobresalen las instituciones que mejor manejan su

información y sus procesos. Es por eso que la universidad San Pedro al no

tener un sistema que le ayude a controlar los proyectos que se realizan en

el transcurso del año académico.

El diseño d este proyecto web surge principalmente por la necesidad de

almacenar y encontrar de forma fácil y segura la inmensa cantidad de

proyectos (tesis, proyecto pre-universitarios) que actualmente existe en

Internet. Además, las instituciones están generando un número elevado,

complejo y heterogéneo de contenidos digitales. También aparece como

respuesta a la falta de normalización de los contenidos.

- 6 -


1. Antecedentes y fundamentación científica

Trabajos previos y contemporáneos relacionados con el tema de investigación:

Díaz, N.(2013), universidad de Piura - Perú, “Aplicación de las

TICS en la Conservación y Difusión de Patrimonio Documental y

Bibliográfico, en la Biblioteca Nacional Del Perú”

Resumen

La Biblioteca Nacional del Perú es la institución del país, que resguarda

la mayor cantidad en número y variedad de patrimonio documen0074al

y bibliográfico. Sin embargo se enfrenta a dos problemas: conservación

y acceso; hay deterioro progresivo en los documentos, tanto por la

desintegración natural de los soportes como porque en su consulta sufre

daño por manipulación, pero también el acceso está limitado, ya sea por

restricciones en la consulta para evitar el deterioro o en el peor de los

casos, porque la población no puede acceder a los materiales, porque

muchos de estos tienen la condición de únicos, además de las

limitaciones que impone la distancia geográfica, las restricciones de

horario o la disponibilidad de tiempo, para aquellos que hacen uso

presencial de los servicios de consulta de documentos. Entonces, se

propone atender esta problemática y necesidad, recurriendo a las

herramientas que ofrecen las TICS, tanto desde el ámbito de la

digitalización, como de la difusión de los archivos electrónicos que se

producen, los que estarían concentrados y distribuidos mediante un

repositorio de acceso abierto, desde Internet. De por medio, se

establecen una serie de pautas para la creación y descripción de los

objetos que serán gestionados mediante el repositorio, que será

desarrollado sobre el software DSpace, producto adaptable a las

necesidades de la institución, con amplia aceptación en el ámbito de la

gestión del conocimiento a nivel mundial.

- 7 -


Chacón Candia, Felipe.(2012), en la cuidad de Chile, se realizó la

investigación denominada “Desarrollo de un Repositorio de

Artículos Científicos”

Resumen

El Departamento de Ciencias de la Computación de la Universidad de

Chile de ahora en adelante DCC - no disponía de una buena herramienta

donde los artículos científicos pudiesen ser publicados de manera

eficaz. Es por esto que la motivación principal era tener un espacio con

el cual se pudiera dar visibilidad a la publicación de papers de todo el

DCC. Básicamente, un espacio donde se pudiera subir estos

documentos a una plataforma web y realizar búsquedas por distintos

criterios. La solución desarrollada resultó ser un sistema web llamado

U-papers. Las características principales de este sistema lo convierten

en un repositorio en donde se almacena información valiosa de

publicaciones que permite realizar búsquedas. Actualmente es

accesible desde la siguiente dirección: http://upapers.dcc.uchile.cl.

Bueno de la Fuente, G. (2010), en la ciudad de Madrid en su

investigación con nombre “Modelo de repositorio institucional de

contenido educativo (RICE): la gestión de materiales digitales de

docencia y aprendizaje en la biblioteca universitaria”

Resumen

El objeto de la tesis es estudiar el papel de la biblioteca universitaria en

la gestión del material didáctico digital producido por la comunidad

académica, y analizar la necesidad de crear una colección institucional

digital que sirva a sus actividades de enseñanza y aprendizaje de una

manera eficiente y natural. El objetivo principal es el diseño de un

modelo para la gestión y preservación de estos materiales en el contexto

universitario, cuya misión sea fomentar el intercambio, la reutilización,

la distribución, la visibilidad y la preservación de la producción

intelectual universitaria en su dimensión educativa.

http://upapers.dcc.uchile.cl/

- 8 -


2. Justificación de la investigación

El proyecto que se plantea desarrollar en la universidad SAN PEDRO se

proyecta para asegurar la accesibilidad y recuperación del material digital

empleando la técnica de digitalización de documentos en soporte papel para

asegurar su conservación en el tiempo y evitar el deterioro del original. Para

que en estudios posteriores los alumnos pueden acceder al material digital y

ver las investigaciones ya realizadas y tomarlas como referencia, y esto evitara

la duplicidad de la investigación garantizando la accesibilidad también en el

futuro.

3. Problema

La universidad San Pedro es una universidad privada que fomenta el desarrollo

de la ciencia y la tecnología entre sus estudiantes. Cada año ay un promedio de

150 estudiantes y egresados que optan por realizar proyectos (ya sea prácticas

profesionales I y II como también tesis par optar por el título profesional), al

no tener un control de proyectos ya aprobados, se suelen duplicar por error

algunos proyectos lo que puede generar problemas con el transcurso de la

elaboración.

Actualmente solo se cuenta con proyectos de forma física que se le puede

proporcionar al estudiante más no ay un sistema web de fácil acceso que

permita obtener dichos proyectos que sean como guía de investigación a

futuros proyectos que realicen los estudiantes.

- 9 -


4. Marco referencial

RESEÑA HISTORICA

La Universidad San Pedro se crea el 25 de junio de 1988, mediante ley N°

24871, como una institución sin fines de lucro, al amparo de la ley N°23733,

consolidada por Decreto Legislativo N° 25969.

La Asociación Civil Promotora San Pedro conformada por personas

honorables como el Padre Lino Dolan, el Dr. Lucio Tito Soria, el Cnel.

Guillermo Vidal Rivadeneira, el CPC Hoover Chávez Velarde y la Q.F. Elena

Quiñones, designan por concurso a los miembros de la Comisión Organizadora

que estuvo conformado por el Dr. Juan García Cribilleros como Presidente, por

la Dra. Lidia Marina Lizarzaburu de Campos como Vicepresidente Académica

y por el Ph. D. José María Huamán Ruiz Vicepresidente Administrativo,

culminando la organización a fines de 1992.

El 3 de noviembre de 1993, la Asamblea Nacional de Rectores mediante

resolución N°648-93-ANR, otorga la autorización de funcionamiento

definitivo a la universidad y el uso de su plena autonomía académica,

económica y administrativa en base al Art. 18 de la Constitución Política del

Perú y Ley Universitaria.

Conformada la Asamblea Universitaria, el 17 de mayo de 1994, se elige el

primer Rector, Dr. Jorge Arturo Benites Robles, quien gobernó por dos

períodos con sus Vicerrectores Académico Dr. Arnulfo Becerra Alfaro y Dr.

Julio Becerra Rojas y el Mg. Javier Azparrent Taipe como Vicerrector

Administrativo.

La Universidad San Pedro desde su inicio ha venido cumpliendo un importante

rol protagónico en el desarrollo económico, social y cultural del norte del Perú,

logrando acreditar en el año 2003, a la Facultad de Medicina Humana, un

proceso que la constituyó como la primera universidad de provincias en

conseguir su acreditación en el país y la segunda a nivel nacional.

El 18 de mayo de 2004 prestó juramento como Rector el Dr. Jorge Morales

Chincha y en su condición de Vicerrector Académico el Ph. D. José María

Huamán Ruiz y Vicerrector Administrativo Dr. Víctor Berrospi Plascencia.

- 10 -


Durante este período la universidad logra reconocer y acreditar ante la

Asamblea Nacional de Rectores a sus cuatro filiales: Filial Lima, Filial Piura,

Filial La Libertad y Filial Cajamarca, labor que fue conducida por el

Vicerrector Académico.

La Asamblea Universitaria el 25 de enero de 2008 eligió al Ph. D. José María

Huamán Ruiz, como nuevo Rector de la USP, para el periodo 2008- 2013.

Durante esta gestión la Universidad San Pedro logra un alto desarrollo en lo

académico, se promueve la investigación científica y se intensifica la

proyección social hacia los sectores más necesitados, especialmente en el

campo de la salud a través del Policlínico Docente, al sector empresarial, se

desarrolló la internacionalización mediante convenios con importantes

Universidades extranjeras, y se posesiona como una institución inteligente y

con alta responsabilidad social.

El 25 de enero del 2013, la Asamblea Universitaria ratifica su confianza al Ph.

D. José María Huamán Ruiz y lo elige nuevamente como Rector para el período

2013-2018. El Dr. Huamán Ruiz es egresado de la Universidad Nacional

Federico Villarreal de la Facultad de Ciencias Sociales y Administrativas; hizo

estudios en una de las mejores universidades de Rusia donde obtiene el Titulo

de economista y el grado de Doctor en Filosofía (Ph. D.), también tiene el título

de Economista de la Universidad Nacional de San Marcos y está reconocido

por la UNESCO. En este nuevo período su tarea fundamental es llevar adelante

la autoevaluación y acreditar a las 21 carreras profesionales cumpliendo con

los estándares internacionales de calidad.

- 11 -


ORGANIGRAMA

- 12 -


DESCRIPCION DE LA METODOLOGIA

METODOLOGÍAS AGILES EN ELDESARROLLO DEL SOFTWARE

En febrero de 2001, tras una reunión celebrada en Utah-EEUU, nace el término

“ágil” aplicado al desarrollo de software. En esta reunión participan un grupo

de 17 expertos de la industria del software, incluyendo algunos de los creadores

o impulsores de metodologías de software. Su objetivo fue esbozar los valores

y principios que deberían permitir a los equipos desarrollar software

rápidamente y respondiendo a los cambios que puedan surgir a lo largo del

proyecto. Se pretendía ofrecer una alternativa a los procesos de desarrollo de

software tradicionales, caracterizados por ser rígidos y dirigidos por la

documentación que se genera en cada una de las actividades desarrolladas.

Tras esta reunión se creó The Agile Alliance, una organización, sin ánimo de

lucro, dedicada a promover los conceptos relacionados con el desarrollo ágil

de software y ayudar a las organizaciones para que adopten dichos conceptos.

El punto de partida es fue el Manifiesto Ágil, un documento que resume la

filosofía “ágil”.

El Manifiesto Ágil. Según el Manifiesto se valora:

Al individuo y las interacciones del equipo de desarrollo sobre el proceso

y las herramientas. La gente es el principal factor de éxito de un proyecto

software. Es más importante construir un buen equipo que construir el entorno.

Muchas veces se comete el error de construir primero el entorno y esperar que

el equipo se adapte automáticamente. Es mejor crear el equipo y que éste

configure su propio entorno de desarrollo en base a sus necesidades.

Desarrollar software que funciona más que conseguir una buena

documentación. La regla a seguir es “no producir documentos a menos que

sean necesarios de forma inmediata para tomar un decisión importante”. Estos

documentos deben ser cortos y centrarse en lo fundamental.

La colaboración con el cliente más que la negociación de un contrato. Se

propone que exista una interacción constante entre el cliente y el equipo de

- 13 -


desarrollo. Esta colaboración entre ambos será la que marque la marcha del

proyecto y asegure su éxito.

Responder a los cambios más que seguir estrictamente un plan. La

habilidad de responder a los cambios que puedan surgir a los largo del proyecto

(cambios en los requisitos, en la tecnología, en el equipo, etc.) determina

también el éxito o fracaso del mismo. Por lo tanto, la planificación no debe ser

estricta sino flexible y abierta.

Los valores anteriores inspiran los doce principios del manifiesto. Son

características que diferencian un proceso ágil de uno tradicional. Los dos primeros

principios son generales y resumen gran parte del espíritu ágil. El resto tienen que

ver con el proceso a seguir y con el equipo de desarrollo, en cuanto metas a seguir

y organización del mismo. Los principios son:

i. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas

de software que le aporte un valor.

ii. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente

tenga una ventaja competitiva.

iii. Entregar frecuentemente software que funcione desde un par de semanas a

un par de meses, con el menor intervalo de tiempo posible entre entregas.

iv. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo

del proyecto.

v. Construir el proyecto en torno a individuos motivados. Darles el entorno y el

apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo.

vi. El diálogo cara a cara es el método más eficiente y efectivo para comunicar

información dentro de un equipo de desarrollo.

vii. El software que funciona es la medida principal de progreso.

viii. Los procesos ágiles promueven un desarrollo sostenible. Los promotores,

desarrolladores y usuarios deberían ser capaces de mantener una paz

constante.

ix. La atención continua a la calidad técnica y al buen diseño mejora la

agilidad.

- 14 -


x. La simplicidad es esencial.

xi. Las mejores arquitecturas, requisitos y diseños surgen de los equipos

organizados por sí mismos.

xii. En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser

más efectivo, y según esto ajusta su comportamiento.

METODOLOGIA AGIL SCRUM

Scrum es un marco de trabajo para la gestión ágil de proyectos, usado para

entregar incrementos con alto valor al cliente en forma iterativa. Scrum se

orienta hacia la auto-organización, el empoderamiento de los equipos para

entregar incrementos del producto. También se orienta al cliente o dueño del

producto, para darle al grupo una lista de características deseadas para el

sistema como mecanismo de priorización la orientación al negocio. Scrum es

un método inicialmente aplicado por JeSutherland, formalizado por Ken

Schwaber [56] y renado y extendido por ellos, aplicando principios de procesos

de control industrial, junto con experiencias metodológicas de Microsoft,

Borland y Hewlett-Packard. Schwaber se dio cuenta que un proceso necesita

aceptar el cambio, en lugar de esperar predictibilidad. Scrum no está concebido

como método independiente, es un complemento de otros métodos como como

XP o el Proceso Unificado. Como método, Scrum enfatiza valores y prácticas

de gestión, y no incluye prácticas para los requisitos, implementación y demás

aspectos técnicos. La idea de Scrum es que no se controla el orden de ejecución

de las actividades fundamentales, así requisitos, diseño código y test, puede

darse en forma casi concurrente como lo muestra la siguiente figura.

- 15 -


El marco de trabajo Scrum consiste en el Equipo Scrum, en sus Roles,

Momentos, artefactos y reglas asociadas. Cada uno de estos elementos dentro

del marco de trabajo de Scrum es útil a un propósito específico y es esencial

para el éxito de Scrum y para su uso. Las reglas de Scrum vinculan a los

momentos, roles y artefactos, rigiendo las relaciones e interacciones entre

ellos.

Scrum es una metodología de desarrollo de productos incrementales y

evolutivos. Los requisitos se identifican y se listan en un lugar definido llamado

el back log del producto. Las iteraciones, llamadas Sprint, normalmente duran

30 días. En cada sprint el grupo de desarrollo selecciona del backlog un

conjunto de ítems de mayor prioridad, y los desarrolla de tal forma que el

backlog se convierte en el artefacto base de la medida de progreso del proyecto.

Durante el sprint el equipo trabaja en sus tareas sin modificarlas con nuevos

requisitos. Todos los días los miembros del equipo se reúnen (Scrum diario)

con el líder del equipo (Master Scrum) para contestar las tres preguntas

referidas al progreso del proyecto.

- 16 -


El desarrollo ágil de software son métodos de ingeniería del software basado

en el desarrollo iterativo e incremental, donde los requisitos y soluciones

evolucionan mediante la colaboración de grupos auto organizado y

multidisciplinario.

Scrum, una manera de hacer las cosas procurando centrarse en el producto y

no en la documentación asociada, no se exige documentar nada para iniciar el

proyecto.

Es una metodología flexible, nos permite ir adaptando el producto conforme

vamos descubriendo cosas que no habíamos entendido bien o que no estaban

bien definidas.

Scrum prioriza disponer de algo tangible casi desde el primer momento de

manera que el cliente pueda tener una referencia sobre la que indicarnos si

vamos por buen camino, la idea principal es: “Ponerse a trabajar prácticamente

desde el primer momento”.

Scrum es un marco de trabajo iterativo e incremental para el desarrollo de

proyectos, productos y aplicaciones. Estructura el desarrollo en ciclos de

trabajo llamados Sprints. Son iteraciones de 1 a 4 semanas, y se van sucediendo

una detrás de otra. Los Sprints son de duración fija. Al comienzo de cada

Sprint, un equipo multi-funcional selecciona los elementos (requisitos del

cliente) de una lista priorizada. Al final del Sprint, el equipo lo revisa con los

interesados en el proyecto. Scrum pone el énfasis en productos que funcionen

al final del Sprint; en el caso del software significa que el código esté integrado,

completamente probado y potencialmente para entregar.

Participantes y roles

Product Owner:

Esta persona representa a los interesados en el producto final, es decir al cliente.

Conoce y marca las prioridades del proyecto. Es el responsable de identificar

- 17 -


las funcionalidades del producto, poniéndolas en una lista priorizada,

decidiendo cuales deberían ir al principio de la lista para el siguiente Sprint,

repriorizando y refinando continuamente la lista.

Scrum Master:

Su tarea es eliminar impedimentos, procurar que no haya colisiones, asegura el

seguimiento de la metodología guiando las reuniones y ayudando al equipo en

cualquier problema.

Scrum Team:

Personal responsable de implementar la funcionalidad o funcionalidades

elegidas por el Product Owner. El equipo es “auto organizado”

(autogestionado), con un alto grado de autonomía y responsabilidad.

Usuario o cliente:

Beneficiaros finales del producto.

Elementos esenciales que constituyen la metodología Scrum:

Product Backlog

Es el equivalente a los requisitos del sistema o del usuario, se toma el proyecto

original, y se definir las tareas que lo componen. De esta manera obtendremos

una lista con las funcionalidades de la aplicación. Un vez tengamos esto le

asignaremos prioridades a cada tarea.

Daily Scrum Meeting

Una vez empezado el Sprint, se realizaran unas reuniones cortas (15 minutos o

menos) que se celebraran todos los días a una hora prefijada. Todo el Scrum Team

y el Scrum Master asisten a la reunión. El Scrum Team informará a los demás

sobre el progreso y los obstáculos;

- 18 -


Que han hecho desde la última reunión.

Que tienen planificado hacer antes de la siguiente reunión.

Cualquier bloqueo o impedimento que tengan.

El Scrum Master se responsabiliza de ayudar a los miembros del Scrum Team que

tenga bloqueos o dificultades. El Scrum Diario en una reunión de seguimiento,

otro ciclo de inspección y adaptación.

Actualizando el Sprint Backlog

Todos los días el Scrum Team actualiza sus estimaciones de la cantidad de

trabajo que queda para terminar sus tareas actuales en la Pila de Sprint.

Revisión del Sprint

El Scrum Team revisa el Sprint junto con el Product Owner, es una actividad

de inspección y adaptación del producto. Es la oportunidad de que el Product

Owner vea lo que está pasando con el producto y con el Scrum Team; y la

oportunidad del Scrum Team de saber cómo va el Product Owner y el mercado.

El Scrum Master es responsable de saber la “Definición de Hecho” que fue

definida durante la Planificación del Sprint Backlog, y durante esta reunión es

responsable de decir al Product Owner si alguno de los elementos

implementados por el Scrum Team no cumple esta definición. De esta forma,

hay una mayor visibilidad de la calidad del trabajo; los equipos no pueden

simular la calidad presentando software que parece que funciona bien, pero que

está implementado con código desordenado, sin probar y de mala calidad.

Retrospectiva del Sprint

Implica inspeccionar y adaptar el proceso. Es una oportunidad para que el

Scrum Team hable sobre lo que funciona y lo que no, y acuerden que cambios

quieren intentar. “Qué fue bien” y “Qué se podría mejorar” aplicar un número

- 19 -


pequeño de cambios en el siguiente Sprint, y se compromete a revisar los

resultados en la retrospectiva del próximo Sprint.

Ciclo de vida de la metodología ágil Scrum:

- 20 -


BASE DE DATOS: MySQL

MySQL es un sistema de gestión de bases de datos relacional, multihilo y

multiusuario con más de seis millones de instalaciones.1 MySQL AB —desde enero

de 2008 una subsidiaria de Sun Microsystems y ésta a su vez de Oracle Corporación

desde abril de 2009— desarrolla MySQL como software libre en un esquema de

licenciamiento dual.

Por un lado se ofrece bajo la GNU GPL para cualquier uso compatible con esta

licencia, pero para aquellas empresas que quieran incorporarlo en productos

privativos deben comprar a la empresa una licencia específica que les permita este

uso. Está desarrollado en su mayor parte en ANSI C.

Al contrario de proyectos como Apache, donde el software es desarrollado por una

comunidad pública y los derechos de autor del código están en poder del autor

individual, MySQL es patrocinado por una empresa privada, que posee el copyright

de la mayor parte del código. Esto es lo que posibilita el esquema de licenciamiento

anteriormente mencionado. Además de la venta de licencias privativas, la compañía

ofrece soporte y servicios. Para sus operaciones contratan trabajadores alrededor del

mundo que colaboran vía Internet. MySQL AB fue fundado por David Axmark, Allan

Larsson y Michael Widenius.

- 21 -


Aplicaciones

MySQL es muy utilizado en aplicaciones web, como Drupal o phpBB, en

plataformas (Linux/Windows-Apache-MySQL-PHP/Perl/Python), y por como

aplicación web está muy ligada a PHP, que a menudo aparece en combinación

con MySQL.

MySQL es una base de datos muy rápida en la lectura cuando utiliza el motor

no transaccional MyISAM, pero puede provocar problemas de integridad en

entornos de alta concurrencia en la modificación. En aplicaciones web hay baja

concurrencia en la modificación de datos y en cambio el entorno es intensivo

en lectura de datos, lo que hace a MySQL ideal para este tipo de aplicaciones.

Sea cual sea el entorno en el que va a utilizar MySQL, es importante

monitorizar de antemano el rendimiento para detectar y corregir errores tanto

de SQL como de programación.

Características

Inicialmente, MySQL carecía de elementos considerados esenciales en las

bases de datos relacionales, tales como integridad referencial y transacciones.

A pesar de ello, atrajo a los desarrolladores de páginas web con contenido

dinámico, justamente por su simplicidad.

Poco a poco los elementos de los que carecía MySQL están siendo

incorporados tanto por desarrollos internos, como por desarrolladores de

software libre. Entre las características disponibles en las últimas versiones se

puede destacar:

Amplio subconjunto del lenguaje SQL. Algunas extensiones son

incluidas igualmente.

Disponibilidad en gran cantidad de plataformas y sistemas.

Posibilidad de selección de mecanismos de almacenamiento que

ofrecen diferentes velocidades de operación, soporte físico,

capacidad, distribución geográfica, transacciones...

Transacciones y claves foráneas.

Conectividad segura.

- 22 -


Replicación.

Búsqueda de indexación de campos de texto.

LENGUAJE DE PROGRAMACIÓN: PHP

PHP es un lenguaje creado por una gran comunidad de personas.

El sistema fue desarrollado originalmente en el año 1994 por Rasmus Lerdorf

como un CGI escrito en C que permitía la interpretación de un número limitado

de comandos.

El sistema fue denominado Personal Home Page Tools y adquirió relativo

éxito gracias a que otras personas pidieron a Rasmus que les permitiese utilizar

sus programas en sus propias páginas. Dada la aceptación del primer PHP y de

manera adicional, su creador diseñó un sistema para procesar formularios al

que le atribuyó el nombre de FI (Form Interpreter) y el conjunto de estas

dos herramientas, sería la primera versión compacta del lenguaje: PHP/FI.

Todas estas mejoras sentaron las bases de PHP versión 3. Actualmente PHP se

encuentra en su versión 4, que utiliza el motor Zend, desarrollado con mayor

meditación para cubrir las necesidades actuales y solucionar algunos

inconvenientes de la anterior versión.

- 23 -


Algunas mejoras de esta nueva versión son su rapidez -gracias a que primero

se compila y luego se ejecuta, mientras que antes se ejecutaba mientras se

interpretaba el código-, su mayor independencia del servidor web -creando

versiones de PHP nativas para más plataformas- y un API más elaborado y con

más funciones.

Características

Orientado al desarrollo de aplicaciones web dinámicas con acceso a

información almacenada en una base de datos.

Es considerado un lenguaje fácil de aprender, ya que en su desarrollo se

simplificaron distintas especificaciones, como es el caso de la definición de las

variables primitivas, ejemplo que se hace evidente en el uso de php arrays.

El código fuente escrito en PHP es invisible al navegador web y al cliente, ya

que es el servidor el que se encarga de ejecutar el código y enviar su resultado

HTML al navegador. Esto hace que la programación en PHP sea segura y

confiable. Capacidad de conexión con la mayoría de los motores de base de

datos que se utilizan en la actualidad, destaca su conectividad con MySQL y

PostgreSQL.

Capacidad de expandir su potencial utilizando módulos (llamados ext's o

extensiones).

Posee una amplia documentación en su sitio web oficial, entre la cual se destaca

que todas las funciones del sistema están explicadas y ejemplificadas en un

único archivo de ayuda.

Es libre, por lo que se presenta como una alternativa de fácil acceso para todos.

Permite aplicar técnicas de programación orientada a objetos. Incluso

aplicaciones como Zend framework, empresa que desarrolla PHP, están

totalmente desarrolladas mediante esta metodología.

No requiere definición de tipos de variables aunque sus variables se pueden

evaluar también por el tipo que estén manejando en tiempo de ejecución.

Tiene manejo de excepciones (desde PHP5).

- 24 -


Si bien PHP no obliga a quien lo usa a seguir una determinada metodología a

la hora de programar, aun haciéndolo, el programador puede aplicar en su

trabajo cualquier técnica de programación o de desarrollo que le permita

escribir código ordenado, estructurado y manejable. Un ejemplo de esto son

los desarrollos que en PHP se han hecho del patrón de diseño Modelo Vista

Controlador (MVC), que permiten separar el tratamiento y acceso a los datos,

la lógica de control y la interfaz de usuario en tres componentes

independientes.

Debido a su flexibilidad ha tenido una gran acogida como lenguaje base para

las aplicaciones WEB de manejo de contenido, y es su uso principal.

- 25 -


5. Hipótesis

En la presente trabajo no se formulará una hipótesis, ya que solo se hará un

diagnóstico en la investigación, por lo tanto se dice que la hipótesis es

implícita. Es decir la Hipótesis se puede considerar, pero no es necesario

demostrarlo debido al tipo de Investigación que estamos desarrollando.

6. OBJETIVOS

6.1. OBJETIVO GENERAL

Desarrollar un Sistema Web para el Control de Proyectos para la

Escuela de Ingeniería Informática y de Sistemas

6.2. Objetivos Específicos.

Recopilar la información que permitan identificar los

requerimientos del sistema.

Crear un espacio que facilite la gestión y difusión de los

contenidos digitales generados por carrera de ingeniería

informática y de sistemas de la comunidad San Pedrana.

Desarrollar los modelos (prototipos) de datos mediante las

herramientas adecuadas para el diseño del sistema. Generando

la funcionalidad de cada entregable en el proceso.

Salva guardar la información mediantes altos controles de

seguridad

Disponer los proyectos en archivos pdf para que sirvan de base

en investigaciones posteriores

- 26 -


7. METODOLOGÍA DEL TRABAJO

a. Tipo y Diseño de investigación:

De acuerdo a los objetivos planteados y la orientación del

presente trabajo de investigación, el tipo de investigación es

Descriptiva.

b. Población – Muestra

La población está conformada por el personal docente, los

alumnos de la universidad San Pedro y público en general.

c. Técnicas e instrumentos de investigación

TÉCNICAS DESCRIPVIO INSTRUMENTOS

Observación A través de ella podremos recolectar

información

ficha de observación

Entrevista Técnica de obtención de

información mediante el

diálogo mantenido en un

encuentro formal y planeado,

entre una o más personas

entrevistadora

Guía de entrevista

APLICACIÓN DE LA METODOLOGÍA UTILIZANDO SCRUM

ROLES DE USUARIO

- 27 -


REQUERIMIENTOS DEL SISTEMA

ID Descripción Prioridad

BL 001 Diseño plataforma virtual Alta

BL 002 Diseño de acceso a la aplicación Web Alta

BL 003 Acceso de usuario no registrado Media

BL 004 Registro de nuevo Usuario Alta

BL 005 Administrar proyecto Alta

BL 006 Usuario con acceso al sistema Alta

BL 007 Generar reportes Alta

NOMBRE

DEL ROL REPRESENTANTES CARACTERÍSTICAS

PR

OD

UC

OW

NE

R

Director de la

Escuela

Expresar claramente los elementos del

Backlog.

Priorizar los elementos del Backlog para

alcanzar los objetivos de la mejor manera

posible.

Asegurar el valor del trabajo desempeñado

por el Development Team y asegurarse que

entienden los elementos del Backlog al nivel

necesario.

SC

RU

M

MA

ST

ER

Asesor

responsable de hacer que el equipo aplique

las buenas prácticas

Guía los Daily Scrum con el equipo de

trabajo

responsable de solucionar cualquier duda o

problema que pueda surgir en las reuniones

y en la aplicación de Scrum

SC

RU

M

DE

VE

LO

PE

R

Grupos de

Desarrollo

Auto-organizados, son capaces de entregar

una versión funcional del producto a partir

del correcto entendimiento de los elementos

del Product Backlog.

Multifuncionales, como equipo deben

poseer todas las habilidades necesarias para

finalizar adecuadamente un Sprint.

- 28 -


SPRINT Nº 001

ID DESCRIPCIÓN PRIORIDAD

R1 Diseño plataforma virtual Alta

R2 Diseño de acceso a la aplicación Web Alta

R3 Acceso de usuario no registrado Alta

Una vez determinado el Sprint Backlog, se define las tareas necesarias para poder

completar cada uno de los requisitos seleccionados. En la siguiente tabla se detalla las

tareas, los responsables y la estimación de cada una de ellas.

TAREA SPRINT 001

ID Tarea Responsable Estimación

T001 Desarrollo de la base de

datos

Barreto Lavado N

Pereda Quijano M 8 horas

T002 Diseño de la plataforma de

inicio

Barreto Lavado N


T003 Diseño de login Barreto Lavado N


T004 Diseño de interfaz de

registro de usuario

Barreto Lavado N


T005 Conexión al a base de datos Barreto Lavado N


T006 Programación de registro de

usuario

Barreto Lavado N


TOTAL DE HORAS 25horas

29


TAREAS REALIZADAS EN EL SPRINT Nº 001

Sprint Inicio Duración

1 27-abr-15 4 sem 1semena 2semana 3semana 4semana

27 abril

01 mayo

4mayo

08 mayo

11 mayo

15 mayo

18 mayo

22 mayo

Tareas Pendientes 6 5 3 2

Horas de Trabajo Pendientes 25 17 9 5

ID Tarea Responsable Tip

o

Est

ado Esfuerzo

T001 Desarrollo de la base de datos Barreto Lavado N

Pereda Quijano M Prototipo terminado 8

T002 Diseño de la plataforma de inicio Barreto Lavado N

Pereda Quijano M Prototipo terminado 4 4

T003 Diseño de login y Funcionalidad Barreto Lavado N


T004 Diseño de interfaz de registro de usuario Barreto Lavado N

Pereda Quijano M Prototipo terminado 4 4 4

T005 Conexión e integracion a la base de datos Barreto Lavado N

Pereda Quijano M Prototipo terminado 3 3 3 3

T006 Programación de registro de usuario Barreto Lavado N


30


25

17

95

0

5

10

15

20

25

30

27

-AB

R

28

-AB

R

29

-AB

R

30

-AB

R

01

-MA

Y

02

-MA

Y

03

-MA

Y

04

-MA

Y

05

-MA

Y

06

-MA

Y

07

-MA

Y

08

-MA

Y

09

-MA

Y

10

-MA

Y

11

-MA

Y

12

-MA

Y

13

-MA

Y

14

-MA

Y

15

-MA

Y

16

-MA

Y

17

-MA

Y

18

-MA

Y

Esfuerzo del Sprint Nº 01

6

5

3

2

0

1

2

3

4

5

6

7

01-may 08-may 15-may 22-may

27-abr 04-may 11-may 18-may

Tarear del Sprint Nº 01

31


SPRINT Nº 002 Id Descripción Prioridad

R4 Registro de nuevo Usuario Alta

R5 Administrar proyecto Alta

R6 Usuario con acceso al sistema Alta

R7 Generar reportes Alta

Una vez determinado el Sprint Backlog, se define las tareas necesarias para poder

completar cada uno de los requisitos seleccionados. En la siguiente tabla se detalla

las tareas, los responsables y la estimación de cada una de ellas.

TAREA SPRINT 001

ID Tarea Responsable Estimación

T001 Mejorar(rediseño) de la interfaz principal Barreto Lavado N


T002 Rediseño de la Base de Datos Barreto Lavado N


T003 Diseño de la arquitectura de la prototipo 2.0 Barreto Lavado N


T004 Diseño de la interfaz de insertar, modificar y eliminar Barreto Lavado N


T005 Programación del módulo insertar, modificar y

eliminar datos del proyecto

Barreto Lavado N

Pereda Quijano M 16oras

T006 Programación de la generación del comprobante Barreto Lavado N

Pereda Quijano M 5horas

T007 Programación de validaciones de datos en formularios Barreto Lavado N


T008 Pruebas de versión Barreto Lavado N


TOTAL DE HORAS 83horas

32


Tareas Realizadas en el Sprint Nº 002

Sprint Inicio Duración

2 27-abr-15 4 sem 1semena 2semana 3semana 4semana

27 abril

01 mayo

4 mayo

08 mayo

11 mayo

15 mayo

18 mayo

22 mayo

Tareas Pendientes 8 5 3 2

Horas de Trabajo Pendientes 83 17 9 5

ID Tarea Responsable Tipo Estado Esfuerzo

T001 Mejorar(rediseño) de la interfaz principal Barreto Lavado N

Pereda Quijano M Prototipo terminado 8

T002 Rediseño de la Base de Datos Barreto Lavado N


T003 Diseño de la arquitectura de la prototipo 2.0 Barreto Lavado N


T004 Diseño de la interfaz de insertar, modificar y eliminar Barreto Lavado N


T005 Programación del módulo insertar, modificar y eliminar

datos del proyecto

Barreto Lavado N


T006 Programación de la generación del comprobante Barreto Lavado N


T007 Programación de validaciones de datos en formularios Barreto Lavado N


T008 Pruebas de versión Barreto Lavado N


33


RESULTADOS

El objetivo sera mostrar el alcance en las diferentes opciones que han guiado

la investigacion, y como se vino estimando el progreso de la aplicación con la

metodologia ágil Scrum

1. Caracterisiticas del producto durante su evolucion

Que debido a la transcendencia del proyecto el sprint nº 01 no se llego

a concluir completemente, quedando pendiente algunas tareas que se

retomaron en el siguiente sprint nº 02, esto debio que no se habia

descrito a mayor detalle algunas actividades que no correspoderian al

srpint.

Otro de los apectos es que no se tomo el esfuerzo requerido al proyecto

en el sprint nº 01, por que no se conocia las bases sintacticas de la

metdologia.

Dentro del Sprint nº 02 hubo un retrazo para su inicio por tener

actividades pendientes que realizar del sprint anterior, teniendo que

agustar el tiempo para poder cumplir con el objetivo de la funcionalidad

y operatividad de la aplicación

2. Evolucion del Product Backlog

Hubo un restringimeinto en cuanto al esfuerso invertido (tiempo en

horas) para cada sprint para cumplir al final la integreacion de los

mismos en la distribucion de las actvidades

3. Aspecto de Agilidad en el Desarrollo

Demando la determinacion de la adaptacion a la metodologia por la

cantidad de tareas que estaria conformada cada sprint, que se validara

cada entregable para evitan algunos errores de codificacion. Lo que se

planteo entonces fue desarrollar el producto y simultameamente con la

validación.

4. Satisfaccion del Cliente y los Desarrollares

34


Las medidas de satisfacción por nuestra partes como desarrolladores

fue optima, realizados al finalizar cada sprint, en los que todos los

componentes del proyecto debían valorar el grado con el que el sprint

se había ajustado a sus necesidades.

A medida que aumentó el conocimiento y se fue adquiriendo

experiencia en la metodología y en el dominio de aplicación del

producto a evolucionar se fueron solventando las incertidumbres

iniciales aumentando nuestra safistación.

ANÁLISIS Y DISCUSIÓN En nuestro análisis llegamos a ver que la mayoría de la investigaciones que realizan

en el campo con respecto a este tema está orientado en la utilización y adaptabilidad

de software o marcos de trabajo ya preestablecidos como son los más conocidos E-

Print, y DSpace, en comparación con nosotros tomamos la iniciativa de desarrollar

nuestro propios entornos de trabajo que llevo tener algunas desventajas con respecto

a los mencionados por tener toda una infraestructura

35


CONCLUSIONES

La aplicación se ha quedado en una versión demo, que no refleja al

100% nuestro objetivo final por las diferentes dificultades encontradas

durante la ejecución del proyecto. Por otro lado hemos obtenido una

formación y visión de las metodologías ágiles entendiendo los valores

que defiende y sus indicaciones, gracias a la puesta en marcha de las

mismas en un proyecto real.

Para terminar destacar que la experiencia ha sido satisfactoria, sacando

en claro muchos aspectos de las metodologías agiles y el porqué

plantearse utilizarlas al inicio de un proyecto. En este caso debido a la

naturaleza de nuestro proyecto

La metodología Scrum aplica técnica agiles como el desarrollo dirigido

por pruebas, a la vez que permite tener la distribución adecuada de las

actividades de trabajo, centrándose en actividades prioritarias logrando

que sea una aplicación sencilla.

La investigación de las metodologías Agiles Scrum permite conocer el

proceso, fases, artefactos, prácticas, actividades, roles, reuniones y

herramientas que poseen cada una de ellas, enfocadas al desarrollo.

En base a las características, encontramos que la metodología SCRUM

se enfoca en la gestión del proyecto aportando a las organizaciones el

mayor valor posible a corto plazo, con resultados de calidad que

responden a las necesidades reales del negocio.

36


RECOMENDACIONES

Scrum como proceso de desarrollo de sistemas permite un

involucramiento del cliente en el proceso ayudando a desarrollar un

sistema que se ajuste a las necesidades del cliente, reduciendo así

desarrollar sistemas que no cumplas con las necesidades del cliente.

El uso del sistema permitirá tener un control de los proyectos ya

desarrollados.

Al trabajar con scrum es mucho más recomendable por que ayuda a

realizar entregable después de cada sprint, y esto le permitirá al cliente

corregir errores en marcha evitando de esta manera generar el cambio

del error detectado que esperar al final del desarrollo donde resultará

mucho más costoso que hacerlo en el siguiente sprint. Facilitando que

el sistema sea más funcional y contribuir con éxito al proyecto.

Se sugiere a los desarrolladores de estudiar la metodología para conocer

todo el proceso que posee y su terminología, antes de ser puesta en

práctica.

La primera vez que se comienza a utilizar Scrum, es un poco

complicado diseñar código de calidad dentro del sistema, por el hecho

que no se conoce las limitaciones y las fortalezas que te ofrece la

metodología. En este caso Scrum, cuenta con sprints. Que cada uno de

ellos dispone de actividades que se desarrolla, con el grupo de trabajo

Permite desarrollar un código mucho más sencillo para que al

momento de la prueba pasen, esto nos asegura que se escriba el código

necesario para cubrir los requisitos del sprint, y que cumplan los

criterios del cliente.

37


REFERENCIAS

Tamayo y Tamayo, M. (2004). EL proceso de la Investigacion

Cientifica: Incluye evalución y administración de proyectos de

Investigación. Mexico: Limusa.

Martínez Ruiz, H. (2012). Metodologia de Investigacion . Mexico D,

F: Cengage Learning, inc

Cid, Méndez & Sandobal. (2011) Investigación. Fundamentos y

Metología. Mexico: Pearson Educación.

Charnelli, Maria E. (2014) Integrando repositorios digitales de recursos

educativos abiertos con plataformas virtuales de aprendizaje. (Tesina

Licenciatura en informatica, Universidad Nacional de la Plata).

Recuperado de

http://sedici.unlp.edu.ar/bitstream/handle/10915/33999/Documento_c

ompleto__.pdf?sequence=1

Chacón Candia, F. (2012) Desarrollo de un repositorio de artículos

científicos. (Tesis de grado, Univerdidad de Chile). Recuperado de

http://repositorio.uchile.cl/bitstream/handle/2250/111328/cf-

chacon_fc.pdf?sequence=1&isAllowed=y

Choque Domenique, Z. (2014) Evaluación del repositorio institucional

de la biblioteca digital de la comunicación andina, utilizando la

metodologia de Fushini.(Tesis de Licenciatura, UNMS). Recuperado

de

http://ateneo.unmsm.edu.pe/ateneo/bitstream/123456789/4305/1/Choq

ue_Domenique_Zoila_Ana_2014.pdf

Otón Tortosa, S. (2006) Propuesta de una arquitectura software basada

en servicios para la implementacion de repositorios de objetos de

aprendisaje distribuidos. (Tesis doctoral, Universidad de Alcalá)

Manrubia Diez, Jorge (2009) Metodologías agiles: Scrum y técnicas de

estimación ágil. Consultado el 5 de abril del 2015.

http://jorgemanrubia.net/blog/wp-content/uploads/2009/06/2009-06-

CharlaPreparaticAgil.pdf

Palacio, Juan (2006) El modelo Scrum. Consultapd el 5 de abril del

2015 de http://www.navegapolis.net/files/s/NST-010_01.pdf

Kniberg, Henrik (2007) Scrum y XP desde las trincheras como

hacemos Scrum. Recuperado de http://www.proyectalis.com/wp-

content/uploads/2008/02/scrum-y-xp-desde-las-trincheras.pdf

http://sedici.unlp.edu.ar/bitstream/handle/10915/33999/Documento_completo__.pdf?sequence=1

http://sedici.unlp.edu.ar/bitstream/handle/10915/33999/Documento_completo__.pdf?sequence=1

http://repositorio.uchile.cl/bitstream/handle/2250/111328/cf-chacon_fc.pdf?sequence=1&isAllowed=y

http://repositorio.uchile.cl/bitstream/handle/2250/111328/cf-chacon_fc.pdf?sequence=1&isAllowed=y

http://ateneo.unmsm.edu.pe/ateneo/bitstream/123456789/4305/1/Choque_Domenique_Zoila_Ana_2014.pdf

http://ateneo.unmsm.edu.pe/ateneo/bitstream/123456789/4305/1/Choque_Domenique_Zoila_Ana_2014.pdf

http://jorgemanrubia.net/blog/wp-content/uploads/2009/06/2009-06-CharlaPreparaticAgil.pdf

http://jorgemanrubia.net/blog/wp-content/uploads/2009/06/2009-06-CharlaPreparaticAgil.pdf

http://www.navegapolis.net/files/s/NST-010_01.pdf

http://www.proyectalis.com/wp-content/uploads/2008/02/scrum-y-xp-desde-las-trincheras.pdf

http://www.proyectalis.com/wp-content/uploads/2008/02/scrum-y-xp-desde-las-trincheras.pdf

38


ANEXOS

Listar Proyectos

Ingreso de Cuenta Usuario

Listar proyectos por tema

39


Listar proyectos por autor

Listar proyectos por titulo

40


Muestra de Registro de Docentes

Llenado de registro del docente

41


Registro de Proyectos

Base de Datos

42


Registro de Alumnos

informe usp 2015v2.2

Documents