Informe USP 2015v2.2

UNIVERSIDAD SAN PEDRO
VICERRECTORADO ACADMICO
Oficina Central de Investigacin Universitaria

FACULTAD DE INGENIERA
ESCUELA ACADMICO PROFESIONAL DE
INGENIERA
INFORMTICA Y DE SISTEMAS
Informe Sistema Web para el Control de Proyectos

para la Escuela de Ingeniera Informtica y de Sistemas
para Obtener el Grado de Bachiller en Ingeniera
Informtica y Sistemas
AUTORES:
BARRETO LAVADO NAPOLEN
PEREDA QUIJANO MIGUEL
CHIMBOTE - JUNIO
2015

ndice
PALABRAS CLAVE. ............................................................................................................. - 1 Titulo ....................................................................................................................................... - 2 RESUMEN ............................................................................................................................... - 3 ABSTRACT ............................................................................................................................. - 4 INTRODUCCIN .................................................................................................................. - 5 1.
Antecedentes y fundamentacin cientfica ................................................................ - 6 -
2.
Justificacin de la investigacin ................................................................................. - 8 -
3.
Problema ...................................................................................................................... - 8 -
4.
Marco referencial ........................................................................................................ - 9 -
DESCRIPCION DE LA METODOLOGIA ........................................................................... - 12 METODOLOGAS 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 metodologa Scrum: ........................................ - 17 Product Backlog .............................................................................................................. - 17 Daily Scrum Meeting ...................................................................................................... - 17 Actualizando el Sprint Backlog ....................................................................................... - 18 Revisin del Sprint .......................................................................................................... - 18 Retrospectiva del Sprint ................................................................................................. - 18 Ciclo de vida de la metodologa gil Scrum: .................................................................. - 19 BASE DE DATOS: MySQL ............................................................................................... - 20 Aplicaciones .................................................................................................................... - 21 Caractersticas ................................................................................................................. - 21 LENGUAJE DE PROGRAMACIN: PHP ....................................................................... - 22 Caractersticas ................................................................................................................. - 23 5.
Hiptesis ..................................................................................................................... - 25 -
6.
OBJETIVOS .............................................................................................................. - 25 6.1.
OBJETIVO GENERAL ................................................................................... - 25 -

6.2.
7.
Objetivos Especficos. ....................................................................................... - 25 -
METODOLOGA DEL TRABAJO ............................................................................ - 26 APLICACIN DE LA METODOLOGA 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
ANLISIS Y DISCUSIN ........................................................................................................ 34
CONCLUSIONES ...................................................................................................................... 35
RECOMENDACIONES ............................................................................................................. 36
REFERENCIAS .......................................................................................................................... 37
ANEXOS .................................................................................................................................... 38

PALABRAS CLAVE.
TEMA
Especialidad
Objetivo
Mtodo
SISTEMA
WEB
Ingeniera Del
Software
Desarrollo
Descriptivo
KEYWORDS:
Objetive
SYSTEM
WEB
Software
Engineering
Development
Method
Descriptive
THEME
Speciality
-1-

Titulo
INFORME SISTEMA WEB PARA CONTROL DE
PROYECTOS PARA LA ESCUELA DE
INGENIERA INFORMTICA Y SISTEMAS
PARA OBTENER EL GRADO DE BACHILLER EN
INGENIERA INFORMTICA Y SISTEMAS
-2-

RESUMEN
El presente proyecto a realizar se desarrolla en el marco de los repositorios
virtuales para almacenar contenidos digitales que permitirn 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 diseo de un sistema web para el control de

proyectos para la escuela de Ingeniera informtica y de sistemas de
la universidad privada San Pedro y filiales.
Para lograr el xito de este proyecto se trabajara bajo la metodologa

SCRUM para gestionar el desarrollo del software.
El sistema web permitir organizar, mantener los proyectos(tesis y

prcticas pre-universitaria ) que han sido aprobadas por dicha escuela,
como tambin hacer la consulta respectiva para la verificacin que dichos
proyectos que estn en curso no se repitan de los que ya estn
documentados.
-3-

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.
-4-

INTRODUCCIN
El uso creciente de la tecnologa de la informacin en la actividad
institucional ha dado lugar a que las entidades de hoy en da, busquen
agilizar sus procesos hacindolos ms rpidos, flexibles y eficientes.
En la actualidad el manejo de la informacin 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
informacin 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 ao acadmico.
El diseo d este proyecto web surge principalmente por la necesidad de

almacenar y encontrar de forma fcil y segura la inmensa cantidad de
proyectos (tesis, proyecto pre-universitarios) que actualmente existe en
Internet. Adems, las instituciones estn generando un nmero elevado,
complejo y heterogneo de contenidos digitales. Tambin aparece como
respuesta a la falta de normalizacin de los contenidos.
-5-

1. Antecedentes y fundamentacin cientfica

Trabajos previos y contemporneos relacionados con el tema de investigacin:
Daz, N.(2013), universidad de Piura - Per, Aplicacin de las

TICS en la Conservacin y Difusin de Patrimonio Documental y
Bibliogrfico, en la Biblioteca Nacional Del Per
Resumen
La Biblioteca Nacional del Per es la institucin del pas, que resguarda
la mayor cantidad en nmero y variedad de patrimonio documen0074al
y bibliogrfico. Sin embargo se enfrenta a dos problemas: conservacin
y acceso; hay deterioro progresivo en los documentos, tanto por la
desintegracin natural de los soportes como porque en su consulta sufre
dao por manipulacin, pero tambin el acceso est limitado, ya sea por
restricciones en la consulta para evitar el deterioro o en el peor de los
casos, porque la poblacin no puede acceder a los materiales, porque
muchos de estos tienen la condicin de nicos, adems de las
limitaciones que impone la distancia geogrfica, 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 problemtica y necesidad, recurriendo a las
herramientas que ofrecen las TICS, tanto desde el mbito de la
digitalizacin, como de la difusin de los archivos electrnicos que se
producen, los que estaran concentrados y distribuidos mediante un
repositorio de acceso abierto, desde Internet. De por medio, se
establecen una serie de pautas para la creacin y descripcin de los
objetos que sern gestionados mediante el repositorio, que ser
desarrollado sobre el software DSpace, producto adaptable a las
necesidades de la institucin, con amplia aceptacin en el mbito de la
gestin del conocimiento a nivel mundial.
-6-

Chacn Candia, Felipe.(2012), en la cuidad de Chile, se realiz la

investigacin denominada Desarrollo de un Repositorio de
Artculos Cientficos
Resumen
El Departamento de Ciencias de la Computacin de la Universidad de
Chile de ahora en adelante DCC - no dispona de una buena herramienta
donde los artculos cientficos pudiesen ser publicados de manera
eficaz. Es por esto que la motivacin principal era tener un espacio con
el cual se pudiera dar visibilidad a la publicacin de papers de todo el
DCC. Bsicamente, un espacio donde se pudiera subir estos
documentos a una plataforma web y realizar bsquedas por distintos
criterios. La solucin desarrollada result ser un sistema web llamado
U-papers. Las caractersticas principales de este sistema lo convierten
en un repositorio en donde se almacena informacin valiosa de
publicaciones que permite realizar bsquedas. Actualmente es
accesible desde la siguiente direccin: http://upapers.dcc.uchile.cl.
Bueno de la Fuente, G. (2010), en la ciudad de Madrid en su

investigacin con nombre Modelo de repositorio institucional de
contenido educativo (RICE): la gestin 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 gestin del material didctico digital producido por la comunidad
acadmica, y analizar la necesidad de crear una coleccin institucional
digital que sirva a sus actividades de enseanza y aprendizaje de una
manera eficiente y natural. El objetivo principal es el diseo de un
modelo para la gestin y preservacin de estos materiales en el contexto
universitario, cuya misin sea fomentar el intercambio, la reutilizacin,
la distribucin, la visibilidad y la preservacin de la produccin
intelectual universitaria en su dimensin educativa.
-7-

2. Justificacin de la investigacin
El proyecto que se plantea desarrollar en la universidad SAN PEDRO se

proyecta para asegurar la accesibilidad y recuperacin del material digital
empleando la tcnica de digitalizacin de documentos en soporte papel para
asegurar su conservacin 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 investigacin garantizando la accesibilidad tambin en el
futuro.
3. Problema
La universidad San Pedro es una universidad privada que fomenta el desarrollo
de la ciencia y la tecnologa entre sus estudiantes. Cada ao ay un promedio de
150 estudiantes y egresados que optan por realizar proyectos (ya sea prcticas
profesionales I y II como tambin tesis par optar por el ttulo 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
elaboracin.
Actualmente solo se cuenta con proyectos de forma fsica que se le puede
proporcionar al estudiante ms no ay un sistema web de fcil acceso que
permita obtener dichos proyectos que sean como gua de investigacin a
futuros proyectos que realicen los estudiantes.
-8-

4. Marco referencial
RESEA HISTORICA
La Universidad San Pedro se crea el 25 de junio de 1988, mediante ley N
24871, como una institucin sin fines de lucro, al amparo de la ley N23733,
consolidada por Decreto Legislativo N 25969.
La Asociacin 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 Chvez Velarde y la Q.F. Elena
Quiones, designan por concurso a los miembros de la Comisin Organizadora
que estuvo conformado por el Dr. Juan Garca Cribilleros como Presidente, por
la Dra. Lidia Marina Lizarzaburu de Campos como Vicepresidente Acadmica
y por el Ph. D. Jos Mara Huamn Ruiz Vicepresidente Administrativo,
culminando la organizacin a fines de 1992.
El 3 de noviembre de 1993, la Asamblea Nacional de Rectores mediante
resolucin N648-93-ANR, otorga la autorizacin de funcionamiento
definitivo a la universidad y el uso de su plena autonoma acadmica,
econmica y administrativa en base al Art. 18 de la Constitucin Poltica 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
perodos con sus Vicerrectores Acadmico 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 protagnico en el desarrollo econmico, social y cultural del norte del Per,
logrando acreditar en el ao 2003, a la Facultad de Medicina Humana, un
proceso que la constituy como la primera universidad de provincias en
conseguir su acreditacin en el pas y la segunda a nivel nacional.
El 18 de mayo de 2004 prest juramento como Rector el Dr. Jorge Morales
Chincha y en su condicin de Vicerrector Acadmico el Ph. D. Jos Mara
Huamn Ruiz y Vicerrector Administrativo Dr. Vctor Berrospi Plascencia.
-9-

Durante este perodo 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 Acadmico.
La Asamblea Universitaria el 25 de enero de 2008 eligi al Ph. D. Jos Mara
Huamn Ruiz, como nuevo Rector de la USP, para el periodo 2008- 2013.
Durante esta gestin la Universidad San Pedro logra un alto desarrollo en lo
acadmico, se promueve la investigacin cientfica y se intensifica la
proyeccin social hacia los sectores ms necesitados, especialmente en el
campo de la salud a travs del Policlnico Docente, al sector empresarial, se
desarroll la internacionalizacin mediante convenios con importantes
Universidades extranjeras, y se posesiona como una institucin inteligente y
con alta responsabilidad social.
El 25 de enero del 2013, la Asamblea Universitaria ratifica su confianza al Ph.
D. Jos Mara Huamn Ruiz y lo elige nuevamente como Rector para el perodo
2013-2018. El Dr. Huamn 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 Filosofa (Ph. D.), tambin tiene el ttulo
de Economista de la Universidad Nacional de San Marcos y est reconocido
por la UNESCO. En este nuevo perodo su tarea fundamental es llevar adelante
la autoevaluacin y acreditar a las 21 carreras profesionales cumpliendo con
los estndares internacionales de calidad.
- 10 -

ORGANIGRAMA
- 11 -

DESCRIPCION DE LA METODOLOGIA
METODOLOGAS AGILES EN ELDESARROLLO DEL SOFTWARE
En febrero de 2001, tras una reunin celebrada en Utah-EEUU, nace el trmino
gil aplicado al desarrollo de software. En esta reunin participan un grupo
de 17 expertos de la industria del software, incluyendo algunos de los creadores
o impulsores de metodologas de software. Su objetivo fue esbozar los valores
y principios que deberan permitir a los equipos desarrollar software
rpidamente y respondiendo a los cambios que puedan surgir a lo largo del
proyecto. Se pretenda ofrecer una alternativa a los procesos de desarrollo de
software tradicionales, caracterizados por ser rgidos y dirigidos por la
documentacin que se genera en cada una de las actividades desarrolladas.
Tras esta reunin se cre The Agile Alliance, una organizacin, 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
filosofa gil.
El Manifiesto gil. Segn 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 ms 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 automticamente. Es mejor crear el equipo y que ste
configure su propio entorno de desarrollo en base a sus necesidades.
Desarrollar software que funciona ms que conseguir una buena

documentacin. La regla a seguir es no producir documentos a menos que
sean necesarios de forma inmediata para tomar un decisin importante. Estos
documentos deben ser cortos y centrarse en lo fundamental.
La colaboracin con el cliente ms que la negociacin de un contrato. Se

propone que exista una interaccin constante entre el cliente y el equipo de
- 12 -

desarrollo. Esta colaboracin entre ambos ser la que marque la marcha del
proyecto y asegure su xito.
Responder a los cambios ms 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 tecnologa, en el equipo, etc.) determina
tambin el xito o fracaso del mismo. Por lo tanto, la planificacin no debe ser
estricta sino flexible y abierta.
Los valores anteriores inspiran los doce principios del manifiesto. Son
caractersticas que diferencian un proceso gil de uno tradicional. Los dos primeros
principios son generales y resumen gran parte del espritu gil. El resto tienen que
ver con el proceso a seguir y con el equipo de desarrollo, en cuanto metas a seguir
y organizacin 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 dilogo cara a cara es el mtodo ms eficiente y efectivo para comunicar

informacin 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 deberan ser capaces de mantener una paz
constante.
ix.
La atencin continua a la calidad tcnica y al buen diseo mejora la

agilidad.
- 13 -

x.
La simplicidad es esencial.
xi.
Las mejores arquitecturas, requisitos y diseos surgen de los equipos

organizados por s mismos.
xii.
En intervalos regulares, el equipo reflexiona respecto a cmo llegar a ser

ms efectivo, y segn esto ajusta su comportamiento.
METODOLOGIA AGIL SCRUM
Scrum es un marco de trabajo para la gestin gil de proyectos, usado para
entregar incrementos con alto valor al cliente en forma iterativa. Scrum se
orienta hacia la auto-organizacin, el empoderamiento de los equipos para
entregar incrementos del producto. Tambin se orienta al cliente o dueo del
producto, para darle al grupo una lista de caractersticas deseadas para el
sistema como mecanismo de priorizacin la orientacin al negocio. Scrum es
un mtodo 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 metodolgicas 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 mtodo independiente, es un complemento de otros mtodos como como
XP o el Proceso Unificado. Como mtodo, Scrum enfatiza valores y prcticas
de gestin, y no incluye prcticas para los requisitos, implementacin y dems
aspectos tcnicos. La idea de Scrum es que no se controla el orden de ejecucin
de las actividades fundamentales, as requisitos, diseo cdigo y test, puede
darse en forma casi concurrente como lo muestra la siguiente figura.
- 14 -

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 propsito especfico 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 metodologa 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 das. 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 das los miembros del equipo se renen (Scrum diario)
con el lder del equipo (Master Scrum) para contestar las tres preguntas
referidas al progreso del proyecto.
- 15 -

El desarrollo gil de software son mtodos de ingeniera del software basado

en el desarrollo iterativo e incremental, donde los requisitos y soluciones
evolucionan mediante la colaboracin de grupos auto organizado y
multidisciplinario.
Scrum, una manera de hacer las cosas procurando centrarse en el producto y
no en la documentacin asociada, no se exige documentar nada para iniciar el
proyecto.
Es una metodologa flexible, nos permite ir adaptando el producto conforme
vamos descubriendo cosas que no habamos 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 prcticamente
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 detrs de otra. Los Sprints son de duracin 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 cdigo 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
- 16 -

las funcionalidades del producto, ponindolas en una lista priorizada,

decidiendo cuales deberan 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 metodologa 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 autonoma y responsabilidad.
Usuario o cliente:
Beneficiaros finales del producto.
Elementos esenciales que constituyen la metodologa 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 aplicacin. 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 das a una hora prefijada. Todo el Scrum Team
y el Scrum Master asisten a la reunin. El Scrum Team informar a los dems
sobre el progreso y los obstculos;
- 17 -

Que han hecho desde la ltima reunin.

Que tienen planificado hacer antes de la siguiente reunin.
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 reunin de seguimiento,
otro ciclo de inspeccin y adaptacin.
Actualizando el Sprint Backlog
Todos los das el Scrum Team actualiza sus estimaciones de la cantidad de
trabajo que queda para terminar sus tareas actuales en la Pila de Sprint.
Revisin del Sprint
El Scrum Team revisa el Sprint junto con el Product Owner, es una actividad
de inspeccin y adaptacin 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 cmo va el Product Owner y el mercado.
El Scrum Master es responsable de saber la Definicin de Hecho que fue
definida durante la Planificacin del Sprint Backlog, y durante esta reunin es
responsable de decir al Product Owner si alguno de los elementos
implementados por el Scrum Team no cumple esta definicin. 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 cdigo 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 podra mejorar aplicar un nmero
- 18 -

pequeo de cambios en el siguiente Sprint, y se compromete a revisar los

resultados en la retrospectiva del prximo Sprint.
Ciclo de vida de la metodologa gil Scrum:
- 19 -

BASE DE DATOS: MySQL
MySQL es un sistema de gestin de bases de datos relacional, multihilo y

multiusuario con ms de seis millones de instalaciones.1 MySQL AB desde enero
de 2008 una subsidiaria de Sun Microsystems y sta a su vez de Oracle Corporacin
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 especfica 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 pblica y los derechos de autor del cdigo estn en poder del autor
individual, MySQL es patrocinado por una empresa privada, que posee el copyright
de la mayor parte del cdigo. Esto es lo que posibilita el esquema de licenciamiento
anteriormente mencionado. Adems de la venta de licencias privativas, la compaa
ofrece soporte y servicios. Para sus operaciones contratan trabajadores alrededor del
mundo que colaboran va Internet. MySQL AB fue fundado por David Axmark, Allan
Larsson y Michael Widenius.
- 20 -

Aplicaciones
MySQL es muy utilizado en aplicaciones web, como Drupal o phpBB, en
plataformas (Linux/Windows-Apache-MySQL-PHP/Perl/Python), y por como
aplicacin web est muy ligada a PHP, que a menudo aparece en combinacin
con MySQL.
MySQL es una base de datos muy rpida en la lectura cuando utiliza el motor
no transaccional MyISAM, pero puede provocar problemas de integridad en
entornos de alta concurrencia en la modificacin. En aplicaciones web hay baja
concurrencia en la modificacin 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 programacin.
Caractersticas
Inicialmente, MySQL careca 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 pginas web con contenido
dinmico, justamente por su simplicidad.
Poco a poco los elementos de los que careca MySQL estn siendo
incorporados tanto por desarrollos internos, como por desarrolladores de
software libre. Entre las caractersticas 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 seleccin de mecanismos de almacenamiento que
ofrecen diferentes velocidades de operacin, soporte fsico,
capacidad, distribucin geogrfica, transacciones...
Transacciones y claves forneas.
Conectividad segura.
- 21 -

Replicacin.
Bsqueda de indexacin de campos de texto.
LENGUAJE DE PROGRAMACIN: PHP
PHP
es
un lenguaje creado
por
una
gran comunidad de
personas.
El sistema fue desarrollado originalmente en el ao 1994 por Rasmus Lerdorf

como un CGI escrito en C que permita la interpretacin de un nmero 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 pginas. Dada la aceptacin 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, sera la primera versin compacta del lenguaje: PHP/FI.
Todas estas mejoras sentaron las bases de PHP versin 3. Actualmente PHP se
encuentra en su versin 4, que utiliza el motor Zend, desarrollado con mayor
meditacin para cubrir las necesidades actuales y solucionar algunos
inconvenientes de la anterior versin.
- 22 -

Algunas mejoras de esta nueva versin son su rapidez -gracias a que primero
se compila y luego se ejecuta, mientras que antes se ejecutaba mientras se
interpretaba el cdigo-, su mayor independencia del servidor web -creando
versiones de PHP nativas para ms plataformas- y un API ms elaborado y con
ms funciones.
Caractersticas
Orientado al desarrollo de aplicaciones web dinmicas con acceso a
informacin almacenada en una base de datos.
Es considerado un lenguaje fcil de aprender, ya que en su desarrollo se
simplificaron distintas especificaciones, como es el caso de la definicin de las
variables primitivas, ejemplo que se hace evidente en el uso de php arrays.
El cdigo fuente escrito en PHP es invisible al navegador web y al cliente, ya
que es el servidor el que se encarga de ejecutar el cdigo y enviar su resultado
HTML al navegador. Esto hace que la programacin en PHP sea segura y
confiable. Capacidad de conexin con la mayora 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 mdulos (llamados ext's o
extensiones).
Posee una amplia documentacin en su sitio web oficial, entre la cual se destaca
que todas las funciones del sistema estn explicadas y ejemplificadas en un
nico archivo de ayuda.
Es libre, por lo que se presenta como una alternativa de fcil acceso para todos.
Permite aplicar tcnicas de programacin orientada a objetos. Incluso
aplicaciones como Zend framework, empresa que desarrolla PHP, estn
totalmente desarrolladas mediante esta metodologa.
No requiere definicin de tipos de variables aunque sus variables se pueden
evaluar tambin por el tipo que estn manejando en tiempo de ejecucin.
Tiene manejo de excepciones (desde PHP5).
- 23 -

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

la hora de programar, aun hacindolo, el programador puede aplicar en su
trabajo cualquier tcnica de programacin o de desarrollo que le permita
escribir cdigo ordenado, estructurado y manejable. Un ejemplo de esto son
los desarrollos que en PHP se han hecho del patrn de diseo Modelo Vista
Controlador (MVC), que permiten separar el tratamiento y acceso a los datos,
la lgica 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.
- 24 -

5. Hiptesis
En la presente trabajo no se formular una hiptesis, ya que solo se har un
diagnstico en la investigacin, por lo tanto se dice que la hiptesis es
implcita. Es decir la Hiptesis se puede considerar, pero no es necesario
demostrarlo debido al tipo de Investigacin que estamos desarrollando.
6. OBJETIVOS
6.1.
OBJETIVO GENERAL
Desarrollar un Sistema Web para el Control de Proyectos para la
Escuela de Ingeniera Informtica y de Sistemas
6.2.
Objetivos Especficos.
Recopilar la informacin que permitan identificar los

requerimientos del sistema.
Crear un espacio que facilite la gestin y difusin de los

contenidos digitales generados por carrera de ingeniera
informtica y de sistemas de la comunidad San Pedrana.
Desarrollar los modelos (prototipos) de datos mediante las

herramientas adecuadas para el diseo del sistema. Generando
la funcionalidad de cada entregable en el proceso.
Salva guardar la informacin mediantes altos controles de

seguridad
Disponer los proyectos en archivos pdf para que sirvan de base

en investigaciones posteriores
- 25 -

7. METODOLOGA DEL TRABAJO

a. Tipo y Diseo de investigacin:
De acuerdo a los objetivos planteados y la orientacin del
presente trabajo de investigacin, el tipo de investigacin es
Descriptiva.
b. Poblacin Muestra
La poblacin est conformada por el personal docente, los
alumnos de la universidad San Pedro y pblico en general.
c. Tcnicas e instrumentos de investigacin

TCNICAS
DESCRIPVIO
INSTRUMENTOS
Observacin
A travs de ella podremos recolectar

informacin
Tcnica de obtencin de
informacin mediante el
dilogo mantenido en un
encuentro formal y planeado,
entre una o ms personas
entrevistadora
ficha de observacin
Entrevista
Gua de entrevista
APLICACIN DE LA METODOLOGA UTILIZANDO SCRUM

ROLES DE USUARIO
- 26 -

PRODUC OWNER
NOMBRE
DEL ROL
REPRESENTANTES
CARACTERSTICAS
Director de la
Escuela
SCRUM
DEVELOPER
SCRUM
MASTER
Asesor
Grupos de
Desarrollo
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 desempeado
por el Development Team y asegurarse que
entienden los elementos del Backlog al nivel
necesario.
responsable de hacer que el equipo aplique
las buenas prcticas
Gua los Daily Scrum con el equipo de
trabajo
responsable de solucionar cualquier duda o
problema que pueda surgir en las reuniones
y en la aplicacin de Scrum
Auto-organizados, son capaces de entregar
una versin 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.
REQUERIMIENTOS DEL SISTEMA

ID
Descripcin
Prioridad
BL 001
Diseo plataforma virtual
Alta
BL 002
Diseo de acceso a la aplicacin Web
Alta
BL 003
Acceso de usuario no registrado
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
Media
- 27 -

SPRINT N 001
ID
DESCRIPCIN
PRIORIDAD
R1
Diseo plataforma virtual
Alta
R2
Diseo de acceso a la aplicacin 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 estimacin de cada una de ellas.
TAREA SPRINT 001
ID
T001
T002
T003
T004
T005
T006
Tarea
Desarrollo de la base de
datos
Diseo de la plataforma de
inicio
Responsable
Barreto Lavado N
Pereda Quijano M
Barreto Lavado N
Pereda Quijano M
Barreto Lavado N
Diseo de login
Pereda Quijano M
Diseo de interfaz de
Barreto Lavado N
registro de usuario
Pereda Quijano M
Barreto Lavado N
Conexin al a base de datos
Pereda Quijano M
Programacin de registro de
Barreto Lavado N
usuario
Pereda Quijano M
TOTAL DE HORAS
- 28 -
Estimacin
8 horas
4 horas
4 horas
4 horas
3 horas
4 horas
25horas

TAREAS REALIZADAS EN EL SPRINT N 001

Sprint
Inicio
Duracin
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
Horas de Trabajo Pendientes
25
17
Tip
o
Est
ado
ID
Tarea
Responsable
T001
Desarrollo de la base de datos
Barreto Lavado N
Pereda Quijano M
Prototipo
terminado
T002
Diseo de la plataforma de inicio
Barreto Lavado N
Pereda Quijano M
Prototipo
terminado
T003
Diseo de login y Funcionalidad
Barreto Lavado N
Pereda Quijano M
Prototipo
terminado
T004
Diseo de interfaz de registro de usuario
Barreto Lavado N
Pereda Quijano M
Prototipo
terminado
T005
Conexin e integracion a la base de datos
Barreto Lavado N
Pereda Quijano M
Prototipo
terminado
T006
Programacin de registro de usuario
Barreto Lavado N
Pereda Quijano M
Prototipo
terminado
29
Esfuerzo

Esfuerzo del Sprint N 01

30
25
20
15
25
10
17
9
5
Tarear del Sprint N 01

7
6
4
3
1
0
01-may
08-may
15-may
22-may
27-abr
04-may
11-may
18-may
30
18-MAY
17-MAY
16-MAY
15-MAY
14-MAY
13-MAY
12-MAY
11-MAY
10-MAY
09-MAY
08-MAY
07-MAY
06-MAY
05-MAY
04-MAY
03-MAY
02-MAY
01-MAY
30-ABR
29-ABR
28-ABR
27-ABR

SPRINT N 002
Id
R4
R5
R6
Descripcin
Registro de nuevo Usuario
Administrar proyecto
Usuario con acceso al sistema
R7
Prioridad
Alta
Alta
Alta
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 estimacin de cada una de ellas.
TAREA SPRINT 001

ID
T001
T002
T003
T004
T005
T006
T007
T008
Tarea
Responsable
Barreto Lavado N
Mejorar(rediseo) de la interfaz principal
Pereda Quijano M
Barreto Lavado N
Rediseo de la Base de Datos
Pereda Quijano M
Barreto Lavado N
Diseo de la arquitectura de la prototipo 2.0
Pereda Quijano M
Barreto Lavado N
Diseo de la interfaz de insertar, modificar y eliminar
Pereda Quijano M
Programacin del mdulo insertar, modificar y Barreto Lavado N
eliminar datos del proyecto
Pereda Quijano M
Barreto Lavado N
Programacin de la generacin del comprobante
Pereda Quijano M
Barreto Lavado N
Programacin de validaciones de datos en formularios
Pereda Quijano M
Barreto Lavado N
Pruebas de versin
Pereda Quijano M
TOTAL DE HORAS
31
Estimacin
8 horas
4 horas
20 horas
4 horas
16oras
5horas
22horas
4horas
83horas

Tareas Realizadas en el Sprint N 002

Sprint
Inicio
Duracin
1semena 2semana
3semana
4semana
27 abril 4 mayo
01 mayo 08 mayo
11 mayo
15 mayo
18 mayo
22 mayo
Tareas Pendientes
Horas de Trabajo Pendientes
83
17
2 27-abr-15
ID
Tarea
T001
Mejorar(rediseo) de la interfaz principal
T002
T003
T004
T005
T006
T007
T008
4 sem
Responsable
Barreto Lavado N
Pereda Quijano M
Barreto Lavado N
Rediseo de la Base de Datos
Pereda Quijano M
Barreto Lavado N
Diseo de la arquitectura de la prototipo 2.0
Pereda Quijano M
Barreto Lavado N
Diseo de la interfaz de insertar, modificar y eliminar
Pereda Quijano M
Programacin del mdulo insertar, modificar y eliminar Barreto Lavado N
datos del proyecto
Pereda Quijano M
Barreto Lavado N
Programacin de la generacin del comprobante
Pereda Quijano M
Barreto Lavado N
Programacin de validaciones de datos en formularios
Pereda Quijano M
Barreto Lavado N
Pruebas de versin
Pereda Quijano M
32
Tipo
Estado
Esfuerzo
Prototipo
terminado
Prototipo
terminado
Prototipo
terminado
20
20
20
Prototipo
terminado
Prototipo
terminado
16
16
16
16
Prototipo
terminado
Prototipo
terminado
22
22
22
22
Prototipo
terminado

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 aplicacin 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 aplicacin
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
validacin.
4. Satisfaccion del Cliente y los Desarrollares
33

Las medidas de satisfaccin por nuestra partes como desarrolladores

fue optima, realizados al finalizar cada sprint, en los que todos los
componentes del proyecto deban valorar el grado con el que el sprint
se haba ajustado a sus necesidades.
A medida que aument el conocimiento y se fue adquiriendo
experiencia en la metodologa y en el dominio de aplicacin del
producto a evolucionar se fueron solventando las incertidumbres
iniciales aumentando nuestra safistacin.
ANLISIS Y DISCUSIN
En nuestro anlisis llegamos a ver que la mayora de la investigaciones que realizan
en el campo con respecto a este tema est orientado en la utilizacin y adaptabilidad
de software o marcos de trabajo ya preestablecidos como son los ms conocidos EPrint, y DSpace, en comparacin 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
34

CONCLUSIONES
La aplicacin se ha quedado en una versin demo, que no refleja al
100% nuestro objetivo final por las diferentes dificultades encontradas
durante la ejecucin del proyecto. Por otro lado hemos obtenido una
formacin y visin de las metodologas 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 metodologas agiles y el porqu
plantearse utilizarlas al inicio de un proyecto. En este caso debido a la
naturaleza de nuestro proyecto
La metodologa Scrum aplica tcnica agiles como el desarrollo dirigido
por pruebas, a la vez que permite tener la distribucin adecuada de las
actividades de trabajo, centrndose en actividades prioritarias logrando
que sea una aplicacin sencilla.
La investigacin de las metodologas Agiles Scrum permite conocer el

proceso, fases, artefactos, prcticas, actividades, roles, reuniones y
herramientas que poseen cada una de ellas, enfocadas al desarrollo.
En base a las caractersticas, encontramos que la metodologa SCRUM

se enfoca en la gestin 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.
35

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 ms recomendable por que ayuda a

realizar entregable despus 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 ms costoso que hacerlo en el siguiente sprint. Facilitando que
el sistema sea ms funcional y contribuir con xito al proyecto.
Se sugiere a los desarrolladores de estudiar la metodologa para conocer

todo el proceso que posee y su terminologa, antes de ser puesta en
prctica.
La primera vez que se comienza a utilizar Scrum, es un poco
complicado disear cdigo de calidad dentro del sistema, por el hecho
que no se conoce las limitaciones y las fortalezas que te ofrece la
metodologa. 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 cdigo mucho ms sencillo para que al
momento de la prueba pasen, esto nos asegura que se escriba el cdigo

necesario para cubrir los requisitos del sprint, y que cumplan los
criterios del cliente.
36

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

Cientifica: Incluye evalucin y administracin de proyectos de
Investigacin. Mexico: Limusa.
Martnez Ruiz, H. (2012). Metodologia de Investigacion . Mexico D,
F: Cengage Learning, inc
Cid, Mndez & Sandobal. (2011) Investigacin. Fundamentos y
Metologa. Mexico: Pearson Educacin.
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
Chacn Candia, F. (2012) Desarrollo de un repositorio de artculos
cientficos. (Tesis de grado, Univerdidad de Chile). Recuperado de
http://repositorio.uchile.cl/bitstream/handle/2250/111328/cfchacon_fc.pdf?sequence=1&isAllowed=y
Choque Domenique, Z. (2014) Evaluacin del repositorio institucional
de la biblioteca digital de la comunicacin 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
Otn 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) Metodologas agiles: Scrum y tcnicas de
estimacin gil. Consultado el 5 de abril del 2015.
http://jorgemanrubia.net/blog/wp-content/uploads/2009/06/2009-06CharlaPreparaticAgil.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/wpcontent/uploads/2008/02/scrum-y-xp-desde-las-trincheras.pdf
37

ANEXOS
Listar Proyectos
Ingreso de Cuenta Usuario
Listar proyectos por tema
38

Listar proyectos por autor
Listar proyectos por titulo
39

Muestra de Registro de Docentes
Llenado de registro del docente
40

Registro de Proyectos
Base de Datos
41

Registro de Alumnos
42

Informe USP 2015v2.2

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Informe USP 2015v2.2

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD SAN PEDRO

UNIVERSIDAD SAN PEDRO

Informe Sistema Web para el Control de Proyectos

UNIVERSIDAD SAN PEDRO

Antecedentes y fundamentacin cientfica ................................................................ - 6 -

Justificacin de la investigacin ................................................................................. - 8 -

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

OBJETIVOS .............................................................................................................. - 25 6.1.

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

UNIVERSIDAD SAN PEDRO

Objetivos Especficos. ....................................................................................... - 25 -

UNIVERSIDAD SAN PEDRO

UNIVERSIDAD SAN PEDRO

UNIVERSIDAD SAN PEDRO

Se presenta una propuesta de diseo de un sistema web para el control de

Para lograr el xito de este proyecto se trabajara bajo la metodologa

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

UNIVERSIDAD SAN PEDRO

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

UNIVERSIDAD SAN PEDRO

En la actualidad el manejo de la informacin se hace un tanto complejo

El diseo d este proyecto web surge principalmente por la necesidad de

UNIVERSIDAD SAN PEDRO

1. Antecedentes y fundamentacin cientfica

Daz, N.(2013), universidad de Piura - Per, Aplicacin de las

UNIVERSIDAD SAN PEDRO

Chacn Candia, Felipe.(2012), en la cuidad de Chile, se realiz la

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

UNIVERSIDAD SAN PEDRO

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

UNIVERSIDAD SAN PEDRO

UNIVERSIDAD SAN PEDRO

Durante este perodo la universidad logra reconocer y acreditar ante la

UNIVERSIDAD SAN PEDRO

UNIVERSIDAD SAN PEDRO

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

Desarrollar software que funciona ms que conseguir una buena

La colaboracin con el cliente ms que la negociacin de un contrato. Se

UNIVERSIDAD SAN PEDRO

Responder a los cambios ms que seguir estrictamente un plan. La

La prioridad es satisfacer al cliente mediante tempranas y continuas entregas

Entregar frecuentemente software que funcione desde un par de semanas a

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

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

El dilogo cara a cara es el mtodo ms eficiente y efectivo para comunicar

El software que funciona es la medida principal de progreso.

Los procesos giles promueven un desarrollo sostenible. Los promotores,

La atencin continua a la calidad tcnica y al buen diseo mejora la

UNIVERSIDAD SAN PEDRO

Las mejores arquitecturas, requisitos y diseos surgen de los equipos

En intervalos regulares, el equipo reflexiona respecto a cmo llegar a ser

UNIVERSIDAD SAN PEDRO

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

UNIVERSIDAD SAN PEDRO

El desarrollo gil de software son mtodos de ingeniera del software basado

UNIVERSIDAD SAN PEDRO

las funcionalidades del producto, ponindolas en una lista priorizada,

Elementos esenciales que constituyen la metodologa Scrum:

UNIVERSIDAD SAN PEDRO

Que han hecho desde la ltima reunin.

UNIVERSIDAD SAN PEDRO

pequeo de cambios en el siguiente Sprint, y se compromete a revisar los

UNIVERSIDAD SAN PEDRO

BASE DE DATOS: MySQL