Gestion de Proyectos

SISTEMA DE GESTIÓN DE EVENTOS Y RED CONTACTOS DE LA DIRECCIÓN DE TECNOLOGÍA E INNOVACIÓN - UNHEVAL
Versión: 0.1
Planificación Fechar: 15/03/2019
Documento del plan de desarrollo de la plataforma WEB
“AÑO DEL DIÁLOGO Y LA RECONCILIACIÓN NACIONAL”

UNIVERSIDAD NACIONAL HERMILIO VALDIZAN
FACULTAD DE INGENIERÍA INDUSTRIAL Y DE SISTEMA
E.A.P. INGENIERÍA DE SISTEMAS
SISTEMA DE GESTIÓN DE EVENTOS Y RED CONTACTOS DE LA

DIRECCIÓN DE TECNOLOGÍA E INNOVACIÓN - UNHEVAL
PLAN DE DESARROLLO DE LA PLATAFORMA WEB
DOCENTE : Ing. Luis Meza Ordoñez
TESISTAS : Diaz Sanchez Cesar Anthonny

Surichaqui Huaranga Yordi
Vega Cayetano Jhony
SISTEMAS-UNHEVAL Página 1 de 27
Versión: 0.1
HUÁNUCO-PERÚ
2019
Historial de Revisiones
Fecha Versión Descripción Autor

2/07/2019 0.9 Versión preliminar  Diaz Sanchez Cesar Anthonny
como propuesta de  Surichaqui Huaranga Yordi
desarrollo del proyecto  Vega Cayetano Jhony
16/07/2019 1.0 Versión propuesta  Diaz Sanchez Cesar Anthonny
para aprobación al  Surichaqui Huaranga Yordi
final de la fase de  Vega Cayetano Jhony
inicio.
23/07/2019 2 Presentación del  Diaz Sanchez Cesar Anthonny
proyecto propuesto  Surichaqui Huaranga Yordi
Vega Cayetano Jhony
Versión: 0.1
CONTENIDO
1. Introducción........................................................................................................................................4
Fundamentación......................................................................................................................................5
Valores de trabajo...................................................................................................................................5
Propósito.................................................................................................................................................5
Alcance....................................................................................................................................................6
Resumen..................................................................................................................................................6
2. Vista General del Proyecto..................................................................................................................7
2.1. Propósito, Alcance y Objetivos....................................................................................................7
2.2. Suposiciones y Restricciones........................................................................................................9
2.3. Documentos del proyecto (SCRUM)............................................................................................9
 Plan de Desarrollo de la Plataforma WEB........................................................................................9
 Product backlog...............................................................................................................................9
 Sprint backlog................................................................................................................................10
 Burn down.....................................................................................................................................10
2.4. Reuniones en Scrum......................................................................................................................10
2.4.1. Daily Scrum............................................................................................................................11
2.4.2. Reunión de Planificación del Sprint.......................................................................................11
2.4.3. Reunión de Revisión del Sprint..............................................................................................11
2.4.4. Retrospectiva del Sprint.........................................................................................................11
2.4.5. Evolución del Plan de Desarrollo del Software.......................................................................11
3. Organización del Proyecto.................................................................................................................12
3.1. Participantes en el Proyecto:.....................................................................................................12
3.2. Interfaces Externas....................................................................................................................12
3.3. Roles y Responsabilidades.........................................................................................................12
4. Gestión del Proceso...........................................................................................................................13
4.1. Estimaciones del Proyecto.........................................................................................................13
4.2. Plan del Proyecto.......................................................................................................................13
4.2.A. Plan de las Fases................................................................................................................13
 Trabajo de desarrollo durante el Sprint.....................................................................................15
Versión: 0.1
 Revisión del Sprint.....................................................................................................................15

 Retrospectiva del Sprint.............................................................................................................16
4.3. Seguimiento y Control del Proyecto..........................................................................................18
5. Referencias........................................................................................................................................20
Versión: 0.1
SISTEMAS VIABLESla plataforma WEB

1. INTRODUCCIÓN
Este Plan de Desarrollo de la plataforma virtual de la DIRECCION DE TRANSFERENCIA E
INNOVACIÓN DEL VICERRECTORADO – UNHEVAL es una versión preliminar preparada para ser
incluida en la propuesta elaborada como respuesta al proyecto de trabajo de la asignatura
GESTION DE PROYECTOS de la Universidad Nacional Hermilio Valdizán. Este documento provee
una visión global del enfoque de desarrollo propuesto.
El proyecto está basado en una metodología ágil SCRUM es una metodología ágil y flexible para
gestionar el desarrollo de software, cuyo principal objetivo es maximizar el retorno de la
inversión para su empresa (ROI). Se basa en construir primero la funcionalidad de mayor valor
para el cliente y en los principios de inspección continua, adaptación, auto-gestión e innovación.
Esta metódica de trabajo promueve la innovación, motivación y compromiso del equipo que
forma parte del proyecto, por lo que los profesionales encuentran un ámbito propicio para
desarrollar sus capacidades.
Beneficios:
 Cumplimento de expectativas: El cliente establece sus expectativas indicando el valor que le

aporta cada requisito / historia del proyecto, el equipo los estima y con esta información
el Product Owner establece su prioridad. De manera regular, en las demos de Sprint el Product
Owner comprueba que efectivamente los requisitos se han cumplido y transmite se feedback
al equipo.
 Flexibilidad a cambios: Alta capacidad de reacción ante los cambios de requerimientos
generados por necesidades del cliente o evoluciones del mercado. La metodología está
diseñada para adaptarse a los cambios de requerimientos que conllevan los proyectos
complejos.
 Reducción del Time to Market: El cliente puede empezar a utilizar las funcionalidades más
importantes del proyecto antes de que esté finalizado por completo.
 Mayor calidad del software: La metódica de trabajo y la necesidad de obtener una versión
funcional después de cada iteración, ayuda a la obtención de un software de calidad superior.
 Mayor productividad: Se consigue entre otras razones, gracias a la eliminación de la
burocracia y a la motivación del equipo que proporciona el hecho de que sean autónomos para
organizarse.
 Maximiza el retorno de la inversión (ROI): Producción de software únicamente con las
prestaciones que aportan mayor valor de negocio gracias a la priorización por retorno de
inversión.
 Predicciones de tiempos: Mediante esta metodología se conoce la velocidad media del equipo
por sprint (los llamados puntos historia), con lo que consecuentemente, es posible estimar
fácilmente para cuando se dispondrá de una determinada funcionalidad que todavía está en el
Backlog.
Versión: 0.1
 Reducción de riesgos: El hecho de llevar a cabo las funcionalidades de más valor en primer
lugar y de conocer la velocidad con que el equipo avanza en el proyecto, permite despejar
riesgos eficazmente de manera anticipada.
Fundamentación
Las principales razones del uso de un ciclo de desarrollo iterativo e incremental de tipo
scrum para la ejecución de este proyecto son:
 Sistema modular. Las características del “SISTEMA DE GESTIÓN DE EVENTOS Y RED
CONTACTOS DE LA DIRECCIÓN DE TECNOLOGÍA E INNOVACIÓN - UNHEVAL permiten
desarrollar una base funcional mínima y sobre ella ir incrementando las funcionalidades
o modificando el comportamiento o apariencia de las ya implementadas.
 Entregas frecuentes y continuas al cliente de los módulos terminados, de forma que
puede disponer de una funcionalidad básica en un tiempo mínimo y a partir de ahí un
incremento y mejora continua del sistema.
 Previsible inestabilidad de requisitos.
o Es posible que el sistema incorpore más funcionalidades de las inicialmente
identificadas.
o Es posible que durante la ejecución del proyecto se altere el orden en el que se
desean recibir los módulos o historias de usuario terminadas.
o Para el cliente resulta difícil precisar cuál será la dimensión completa del
sistema, y su crecimiento puede continuarse en el tiempo suspenderse o
detenerse.
Valores de trabajo
Los valores que deben ser practicados por todos los miembros involucrados en el desarrollo y
que hacen posible que la metodología Scrum tenga éxito son:
 Autonomía del equipo

 Respeto en el equipo
 Responsabilidad y auto-disciplina
 Foco en la tarea
 Información transparencia y visibilidad.
Propósito
El propósito del Plan de Desarrollo de Software es proporcionar la información necesaria
para controlar el proyecto. En él se describe el enfoque de desarrollo de la plataforma
WEB.
Los usuarios del Plan de Desarrollo de la plataforma WEB son:
 El jefe del proyecto lo utiliza para organizar la agenda y necesidades de recursos, y para
realizar su seguimiento.
Versión: 0.1
 Los miembros del equipo de desarrollo lo usan para entender lo qué deben hacer,
cuándo deben hacerlo y qué otras actividades dependen de ello.
Alcance
El Plan de Desarrollo de la plataforma WEB describe el plan global usado para el
desarrollo del “SISTEMA DE GESTIÓN DE EVENTOS Y RED CONTACTOS DE LA DIRECCIÓN
DE TECNOLOGÍA E INNOVACIÓN - UNHEVAL”. El detalle de las iteraciones individuales se
describe en los planes de cada iteración, documentos que se aportan en forma
separada. Durante el proceso de desarrollo en el artefacto “Visión” se definen las
características del producto a desarrollar, lo cual constituye la base para la planificación
de las iteraciones. Para la versión 0.1 del Plan de Desarrollo de la Plataforma WEB, nos
hemos basado en la captura de requisitos por medio del stakeholder representante de
la empresa para hacer una estimación aproximada, una vez comenzado el proyecto y
durante la fase de Inicio se generará la primera versión, el cual se utilizará para refinar
este documento. Posteriormente, el avance del proyecto y el seguimiento en cada una
de las iteraciones ocasionará el ajuste de este documento produciendo nuevas
versiones actualizadas.
Resumen
Después de esta introducción, el resto del documento está organizado en las siguientes
secciones:
Vista General del Proyecto:
 Proporciona una descripción del propósito, alcance y objetivos del proyecto,
estableciendo los artefactos que serán producidos y utilizados durante el
proyecto.
Organización del Proyecto:
 Describe la estructura organizacional del equipo de desarrollo.
Gestión del Proceso
 Explica los costos y planificación estimada, define las fases e hitos del proyecto
y describe cómo se realizará su seguimiento.
Planes y Guías de aplicación
 Proporciona una vista global del proceso de desarrollo de software, incluyendo
métodos, herramientas y técnicas que serán utilizadas.
Versión: 0.1
2. VISTA GENERAL DEL PROYECTO

2.1. Propósito, Alcance y Objetivos
La Dirección de Transferencia e Innovación (DTI) es un órgano dependiente del Vicerrectorado
de Investigación, encargada de promover y gestionar relaciones e interacciones entre la
UNHEVAL y su entorno, particularmente, el sector empresarial, en el área de la investigación e
innovación tecnológica. Específicamente está encargada de transferir los resultados de los
trabajos de investigación y prestaciones de servicios con entidades públicas y privadas; organizar
información para empresas; publicaciones; proteger la propiedad intelectual y el registro de
patentes.
La Dirección de Transferencia e Innovación (DTI) está integrada por una jefatura y tres áreas:
a) Oferta Tecnológica.
b) Propiedad Intelectual, Patentes y Publicaciones.
c) Emprendimiento e Incubadora de Empresas.
 La Oficina de Oferta Tecnológica es la encargada de identificar, organizar y transferir

conocimiento producido como resultado de las investigaciones e innovación tecnológica a
empresas y la sociedad. Brinda asesoramiento al sector público y privado en temas de su
competencia. La Oficina de Oferta Tecnológica está a cargo de un Docente Ordinario de la
categoría de Principal o de Asociado, como Coordinador, y tiene las siguientes funciones:
a) Elaborar y proponer al Vicerrector de Investigación el reglamento de transferencia de

conocimientos y tecnología de la UNHEVAL;
b) Proponer convenios con el empresariado para la transferencia de conocimientos y
tecnología;
c) Visitar periódicamente al empresariado para ofertar la transferencia tecnológica;
d) Propiciar la transferencia de conocimientos y tecnología;
e) Asesorar a las empresas respecto a la transferencia de conocimientos y tecnología;
f) Elaborar y mantener actualizado una base de datos de transferencia de conocimientos y
tecnología de la UNHEVAL;
g) Otras que se establezcan en el Reglamento Interno de la Dirección de Gestión de
Transferencia e Innovación o las que se establezcan en las normas internas de la
UNHEVAL.
 La Oficina de Patentes, Propiedad Intelectual y Publicaciones tienen las siguientes funciones:

a) Elaborar el Reglamento de Patentes.
b) Gestionar ante el Instituto Nacional de Defensa de la Competencia y de la Protección de
la Propiedad Intelectual (INDECOPI) la patente de las invenciones presentadas por la
UNHEVAL, con el señalamiento de los autores, en concordancia con las normas que
rigen la Propiedad Intelectual;
Versión: 0.1
c) Reconocer la autoría de las publicaciones producto de investigaciones financiadas por la

UNHEVAL. En cuando al contenido patrimonial, la universidad suscribe un convenio con
el autor para la distribución de las utilidades en función de los aportes entregados. En
los demás aspectos vinculados a esta materia, se aplica la legislación vigente sobre
Derechos de Autor;
d) Establecer que las regalías que generan las invenciones registradas por la UNHEVAL se
realizan mediante convenios suscritos con los autores de las mismas, tomando en
consideración los aportes de cada una de las partes, otorgando a la universidad un
mínimo de 20% de participación;
e) Las investigaciones financiadas con fondos compartidos por la UNHEVAL y otras
instituciones públicas y privadas, reconocerán la autoría de las mismas a sus
realizadores y la autorización de publicación estará sujeta a los convenios específicos
previamente establecidos, según reglamento;
f) Realizar publicaciones que hayan sido producto de investigaciones financiadas por la
UNHEVAL en revistas institucionales, revistas indexadas, revistas virtuales de acceso
abierto y otros medios de comunicación e información pertinentes; reconocen la autoría
de las mismas a sus realizadores;
g) Elaborar una base de datos de patentes de la UNHEVAL;
 La Oficina de Emprendimiento e Incubadora de Empresas, promueve la iniciativa de los

estudiantes para la creación de pequeñas y micro empresas de propiedad de los estudiantes,
brindando asesoría o facilidades en el uso de los equipos e instalaciones de la institución. Los
órganos directivos de la empresa, en un contexto formativo, deben estar integrados por
estudiantes. Estas empresas reciben asesoría técnica o empresarial de parte de los docentes de
la universidad y facilidades en el uso de los equipos e instalaciones, las operatividades de estas
acciones se realizan a través de las Facultades como parte de su actividad formativa; tiene las
siguientes funciones:
a) Elaborar el Plan Operativo Anual de la Oficina;
b) Elaborar y ejecutar un plan de capacitación a los estudiantes de la UNHEVAL respecto a
la creación de pequeñas y micro empresas.
c) Asesorar a los estudiantes para la creación de pequeñas y microempresas;
d) Proponer convenios de préstamos para la creación de pequeñas y micro empresas;
e) Monitorear el funcionamiento de las pequeñas y microempresas creadas por los
estudiantes; y
f) Otras que se establezcan en su Reglamento Interno o las que se señalan en las normas
internas de la UNHEVAL.
La DTI considera necesario el desarrollo de una plataforma WEB que le ayude a
gestionar sus eventos y red de contactos en la primera fase del desarrollo del proyecto
para que pueda a darse conocer y manejar de manera óptima las primeras fases de su
calendario de su plan anual.
El proyecto debe proporcionar una propuesta para el desarrollo de la plataforma WEB
todos los subsistemas implicados. Estos subsistemas se pueden diferenciar Según el plan
anual de actividades 2017 de la Dirección de Transferencia e Innovación (DTI) la
prioridad es:
Versión: 0.1
 Desarrollar módulo de gestión de contactos de las diferentes áreas.

 Desarrollar módulo de gestión de eventos.
 Crear un Plataforma WEB que contenga la página principal de presentación de
la dirección y otro lado un panel de administración.
2.2. Suposiciones y Restricciones

Las suposiciones y restricciones respecto del sistema, y que se derivan directamente de
las entrevistas con el stakeholders o partes interesadas de la DTI son:
a) Debe contemplarse las implicaciones de los siguientes puntos críticos:
 Compatibilidad de la solución con protocolos IPv6
 Caracteres multilingües
 Sistemas seguros: protección de información, seguridad en las trasmisiones de datos
(PKI), etc.
 Gestión de flujos de trabajo, seguridad de transacciones e intercambio de información
 Adaptación a la normativa de Protección de Datos
b) La automatización de la gestión interna del registro debe ajustarse a la legislación vigente y
considerar la previsión de la nueva legislación referente a los dominios de tercer nivel.
c) El subsistema “Información y atención de consultas a usuarios” debe diseñarse como
módulo independiente para ser utilizada posteriormente en otros departamentos de Red.es.
d) El “Procedimiento de conciliación con registradores” incluido en el subsistema “Gestión de
la tasa por asignación del recurso limitado de nombres y direcciones de internet” debe
diseñarse como módulo independiente para ser utilizada posteriormente en otros
departamentos de Red.es.
2.3. Documentos del proyecto (SCRUM)

A continuación, indicamos y describimos cada uno de los artefactos que serán generados y
utilizados por el proyecto y que constituyen los entregables. Esta lista constituye la
configuración del SCRUM desde la perspectiva de artefactos, y que proponemos para este
proyecto.
Es preciso destacar que de acuerdo a la filosofía de Scrum es una forma de trabajo colaborativo,
es una forma de organización en un entorno de cambio permanente. Surge en Japón en el
desarrollo de software donde los ciclos de desarrollo son muy grandes y existe el peligro de que
cuando un desarrollo esté terminado haya quedado desfasado, por ello se introduce la
metodología Scrum.
 Plan de Desarrollo de la Plataforma WEB

Es el presente documento.
Versión: 0.1
 Product backlog
El product backlog es un documento de alto nivel para todo el proyecto. Contiene
descripciones genéricas de todos los requerimientos, funcionalidades deseables, etc. priorizadas
según su valor para el negocio (business value). Es el qué va a ser construido. Es abierto y
cualquiera puede modificarlo.
 Sprint backlog
El sprint backlog es un documento detallado donde se describe el cómo el equipo va a
implementar los requisitos durante el siguiente sprint. Las tareas se dividen en horas con
ninguna tarea de duración superior a 16 horas. Si una tarea es mayor de 16 horas, deberá ser
rota en mayor detalle. Las tareas en el sprint backlog nunca son asignadas, son tomadas por los
miembros del equipo del modo que les parezca oportuno.
 Burn down
La burn down chart es una gráfica mostrada públicamente que mide la cantidad de requisitos
en el Backlog del proyecto pendientes al comienzo de cada Sprint. Dibujando una línea que
conecte los puntos de todos los Sprints completados, podremos ver el progreso del proyecto. Lo
normal es que esta línea sea descendente, hasta llegar al eje horizontal, momento en el cual el
proyecto se ha terminado.
Versión: 0.1
2.4. REUNIONES EN SCRUM
2.4.1. Daily Scrum
 La reunión comienza puntualmente a su hora.

 Todos los asistentes deben mantenerse de pie.
 La reunión debe ocurrir en la misma ubicación y a la misma hora todos los días.
 Durante la reunión, cada miembro del equipo contesta a tres preguntas:
1. ¿Qué has hecho desde ayer?

2. ¿Qué es lo que estás planeando hacer hoy?
3. ¿Has tenido algún problema que te haya impedido alcanzar tu objetivo?
2.4.2. Reunión de Planificación del Sprint
 Al inicio del ciclo Sprint (cada 15 o 30 días), una “Reunión de Planificación

del Sprint” se lleva a cabo.
Versión: 0.1
 Seleccionar qué trabajo se hará

 Ocho horas como límite
 Al final del ciclo Sprint, dos reuniones se llevarán a cabo: la “Reunión de
Revisión del Sprint” y la “Retrospectiva del Sprint”
2.4.3. Reunión de Revisión del Sprint
 Revisar el trabajo que fue completado y no completado.

 Presentar el trabajo a los interesados.
 El trabajo incompleto no puede ser demostrado.
 Cuatro horas como límite
2.4.4. Retrospectiva del Sprint

Después de cada sprint, se lleva a cabo una retrospectiva del sprint, en la cual todos los miembros
del equipo dejan sus impresiones sobre el sprint recién superado. El propósito de la retrospectiva es
realizar una mejora continua del proceso. Esta reunión tiene un tiempo fijo de cuatro horas.
Ventaja Desventaja
 Se trabaja en iteraciones  Es una metodología que difiere del
cortas resto
2.4.5.Evolución del Plan de Desarrollo del Software

El Plan de Desarrollo del Software se revisará semanalmente y se refinará antes del
comienzo de cada iteración.
3. ORGANIZACIÓN DEL PROYECTO

3.1. Participantes en el Proyecto:
De momento no se incluye el personal que designará Red y Server, Comité de Control y
Seguimiento, otros participantes que se estimen convenientes para proporcionar los
requisitos y validar el sistema. El resto del personal del proyecto (por la parte de la
empresa adjudicataria), sólo considerando las fases de Inicio y Elaboración, estará
formado por los siguientes puestos de trabajo y personal asociado
 Jefe de proyecto
 2 Analistas
 3 Tester
 3 Programadores
NOTA: Los Curriculums Vitae del personal del proyecto que ya ha comprometido su
Versión: 0.1
participación se adjuntan por separado.
3.2. Interfaces Externas

Se definirá los participantes del proyecto que proporcionarán los requisitos del sistema,
y entre ellos quiénes serán los encargados de evaluar los artefactos de acuerdo a cada
subsistema y según el plan establecido.
El equipo de desarrollo interactuará activamente con los participantes de CRN-
ASOCIADOS para especificación y validación de los artefactos generados.
3.3. Roles y Responsabilidades

A continuación, se describen las principales responsabilidades de cada uno de los puestos en el equipo
de desarrollo durante las fases de Inicio y Elaboración, de acuerdo con los roles que desempeñan en
SCRUM.
PUESTO RESPONSABILIDAD
Jefe de Proyecto Scrum master: Persona que lidera al equipo guiándolo
para que cumpla las reglas y procesos de la
metodología. Gestiona la reducción de impedimentos
del proyecto y trabaja con el Product Owner para
maximizar el ROI.
Analistas de Sistemas Team: Grupo de profesionales con los conocimientos
técnicos necesarios y que desarrollan el proyecto de
manera conjunta llevando a cabo las historias a las que
se comprometen al inicio de cada sprint.
Programadores Team: Grupo de profesionales con los conocimientos
se comprometen al inicio de cada sprint.
Testers Team: Grupo de profesionales con los conocimientos
se comprometen al inicio de cada sprint..
4. GESTIÓN DEL PROCESO

4.1. Estimaciones del Proyecto
El presupuesto del proyecto y los recursos involucrados se adjuntan en un documento separado (Ver
EXCEL).
4.2. Plan del Proyecto

En esta sección se presenta la organización en fases e iteraciones y el calendario del proyecto.
Versión: 0.1
4.2.A. Plan de las Fases
El desarrollo se llevará a cabo en base a fases con una o más iteraciones en cada una de ellas. La
siguiente tabla muestra una la distribución de tiempos y el número de iteraciones de cada fase (para
las fases de Construcción y Transición es sólo una aproximación muy preliminar)
Nro.
Fase Duración
Iteraciones
Fase de Inicio 1 2 semanas
Fase de Elaboración 1 3 semanas
Fase de 2 5 semanas
Construcción
Fase de Transición - -
Los hitos que marcan el final de cada fase se describen en la siguiente tabla.
Descripción Hito
Fase de Inicio En esta fase desarrollará los requisitos del producto desde la perspectiva del usuario, los
Versión: 0.1
cuales serán establecidos en el artefacto Visión. Los principales casos de uso serán
identificados y se hará un refinamiento del Plan de Desarrollo del Proyecto. La aceptación
del cliente / usuario del artefacto Visión y el Plan de Desarrollo marcan el final de esta
fase.
Fase de En esta fase se analizan los requisitos y se desarrolla un prototipo de arquitectura

Elaboración (incluyendo las partes más relevantes y / o críticas del sistema). Al final de esta fase, todos
los casos de uso correspondientes a requisitos que serán implementados en la primera
release de la fase de Construcción deben estar analizados y diseñados (en el Modelo de
Análisis / Diseño). La revisión y aceptación del prototipo de la arquitectura del sistema
marca el final de esta fase. En nuestro caso particular, por no incluirse las fases siguientes,
la revisión y entrega de todos los artefactos hasta este punto de desarrollo también se
incluye como hito. La primera iteración tendrá como objetivo la identificación y
especificación de los principales casos de uso, así como su realización preliminar en el
Modelo de Análisis / Diseño, también permitirá hacer una revisión general del estado de
los artefactos hasta este punto y ajustar si es necesario la planificación para asegurar el
cumplimiento de los objetivos. Ambas iteraciones tendrán una duración de una semana.
Fase de Durante la fase de construcción se terminan de analizar y diseñar todos los casos de
Construcción uso, refinando el Modelo de Análisis / Diseño. El producto se construye en base a 2
iteraciones, cada una produciendo una release a la cual se le aplican las pruebas y se
valida con el cliente / usuario. Se comienza la elaboración de material de apoyo al
usuario. El hito que marca el fin de esta fase es la versión de la release 3.0, con la
capacidad operacional parcial del producto que se haya considerado como crítica, lista
para ser entregada a los usuarios para pruebas beta.
Fase de En esta fase se prepararán dos raleases para distribución, asegurando una
Transición implantación y cambio del sistema previo de manera adecuada, incluyendo el
entrenamiento de los usuarios. El hito que marca el fin de esta fase incluye, la entrega
de toda la documentación del proyecto con los manuales de instalación y todo el
material de apoyo al usuario, la finalización del entrenamiento de los usuarios y el
empaquetamiento del producto.
Calendario del Proyecto
Versión: 0.1
A continuación, se presenta un calendario de las principales tareas del proyecto incluyendo sólo las
fases de Inicio y Elaboración. Como se ha comentado, el proceso SCRUM.
 Trabajo de desarrollo durante el Sprint

Cuando el sprint está en curso, debemos asegurar que:

No se realizan cambios que afectan al objetivo del Sprint;

No disminuyen los objetivos de calidad, y

El Alcance podrá aclararse y re-negociarse entre el propietario del producto y el
Equipo de Desarrollo a medida que se va aprendiendo.
Cuando un Sprint es demasiado largo, la definición de lo que se está construyendo
puede cambiar, puede aumentar la complejidad y puede aumentar el riesgo. Los Sprints
permiten previsibilidad al garantizar la inspección y la adaptación de los avances hacia
una meta de por lo menos cada mes de calendario.
 Revisión del Sprint

Se lleva a cabo al final del Sprint, para inspeccionar el incremento y adaptar, si es
necesario, el Product Backlog. El Equipo Scrum y las partes interesadas colaboran
durante la revisión de lo que se hizo en el Sprint. Basado en ese y cualquier cambio en el
Product Backlog durante el Sprint, los asistentes trabajan en las próximas cosas que se
podrían hacer. Esta es una reunión informal, y la presentación del incremento está
destinada a obtener retroalimentación y fomentar la colaboración.
La revisión de Sprint incluye los siguientes elementos:
 Los asistentes son el Equipo Scrum y los interesados clave invitados por el
Dueño de Producto;
 El propietario del producto identifica lo que se ha "hecho" y lo que no se ha
"hecho";
 El equipo de desarrollo discute lo que anduvo bien durante el Sprint, qué
problemas hubo y cómo se resolvieron;
 El equipo de desarrollo demuestra el trabajo que se ha "hecho" y responde
preguntas sobre el Incremento;
 El propietario del producto analiza el estado actual del Product Backlog, y
estima fechas de finalización basado en el progreso hasta la fecha, y,
 Todo el grupo colabora en qué hacer a continuación, de modo que la revisión
del Sprint ofrece valiosos aportes a las subsiguientes reuniones de planificación
de Sprint.
 Se hace una revisión de cómo el mercado o el uso potencial del producto podría
haber cambiado lo que es de más valor para hacer a continuación; y,
 Se hace una revisión de la línea de tiempo, presupuesto, capacidades
potenciales y mercado para la próxima entrega prevista del producto
El resultado de la revisión del Sprint es un Product Backlog revisado que define los ítems
del Product Backlog de mayor valor o probables para el siguiente Sprint. El Product
Backlog también se puede ajustar en general para satisfacer las nuevas oportunidades.
Versión: 0.1
 Retrospectiva del Sprint

Es una oportunidad para el Equipo Scrum de inspeccionarse a sí mismo y crear un plan
de mejoras para ejecutar durante el siguiente sprint. El propósito de la retrospectiva de
Sprint es:
 Revisar cómo fue el último Sprint en lo que respecta a las personas, relaciones,
procesos y herramientas;
 Identificar y ordenar los temas principales que salieron bien y las potenciales
mejoras, y
 Crear un plan para la implementación de mejoras con respecto a cómo el
Equipo Scrum hace su trabajo.
Para este proyecto se ha establecido el siguiente calendario. La duración del proyecto será de 3 meses y
15 días calendario.
Versión: 0.1
Manual
Manual de
de usuario
usuario
Documnetacion
Documnetacion Manuales
Manuales
Manual
Manual de
de despliegue
despliegue
envio
envio de
de correo asincronos a
correo asincronos a
los
los usuarios.
usuarios.
Creacion
Creacion de
de eventos
eventos
.suscripcion
.suscripcion al
al evento
evento
Publicacion
Publicacion de
de eventos
eventos
Comentarios de los
Comentarios de los eventos.
eventos.
compartir
compartir los
los eventos en las
eventos en las
redes
redes sociales
sociales
SISTEMA
SISTEMA DE
DE GESTIÓN
GESTIÓN DE
DE Gestion
Gestion de
de Eventos
Eventos contador de visitas
contador de visitas yy likes.
likes.
EVENTOS Y RED
EVENTOS Y RED DE
DE
CONTACTOS
CONTACTOS DE
DE LA
LA DTI-
DTI-
UNHEVAL.
UNHEVAL.
Comentarios de los
Comentarios de los articulos
articulos
Crear
Crear articulo
articulo
Publicacion
Publicacion de
de articulos
articulos
Compartir los articulos

Compartir los articulos en las
en las
redes
redes sociales
sociales
Editar
Editar articulos
articulos
Registro
Registro de
de usuarios
usuarios
Modificacion de usuarios
Modificacion de usuarios
Red
Red de
de Contactos
Contactos CRUD
CRUD de
de contactos
contactos
Alta
Alta de
de usuarios
usuarios
Busqueda
Busqueda de
de usuarios
usuarios
Versión: 0.1
4.3. Seguimiento y Control del Proyecto
Gestión de Requisitos
En Scrum los requisitos se expresan como elementos del Product Backlog. El Product
Backlog es una lista viva de requisitos funcionales y no funcionales priorizados por su
valor para el cliente. Al decir que se trata de una lista viva, dejamos claro que los
requisitos que en ella aparecen y el orden de los mismos son cambiante a lo largo de la
vida del proyecto. En Scrum, los requisitos se van abordando en Sprints en el orden en
que aparecen en el Product Backlog.
Utilizar el Product Backlog como principal artefacto para la gestión de requisitos nos
permite atajar los problemas relacionados con la gestión de requisitos que antes hemos
descrito.
Aunque construir y mantener el Product Backlog es una tarea ardua, es mucho más
simple que hacer una captura de requisitos tradicional. El motivo es simple, solo hay que
expresar a grandes rasgos en que consiste el requisito, no es necesario un nivel de
detalle muy elevado. Solo es necesario el nivel de detalle suficiente que nos permita
estimar los requisitos y priorizarlos. Control de Plazos
El calendario del proyecto tendrá un seguimiento y evaluación semanal por el jefe de
proyecto y por el Comité de Seguimiento y Control.
Control de Calidad
La manera en que las metodologías ágiles permiten hacer proyectos con un alto nivel de
calidad, entendida como (1) la satisfacción de las expectativas del cliente, usuarios
finales o consumidores, (2) el comportamiento correcto del producto y (3) la garantía de
su mantenibilidad. Todo ello gracias a los principios de Lean (análisis del valor desde la
concepción del producto hasta su venta), a que Scrum en sí mismo es un proceso de
mejora continua y a que XP (eXtreme Programming) consta de prácticas de ingeniería
enfocadas a mantener una alta calidad interna que permite una velocidad de desarrollo
sostenible.
Conceptos de calidad
 El ciclo de mejora continua de Deming (PDCA)
 En el ciclo de mejora continua de Deming tiene las siguientes actividades [1]:
 [Plan] Planificar cómo conseguir unos objetivos.
 [Do] Ejecutar esta planificación.
 [Check] Verificar los resultados conseguidos.
 [Act] Definir acciones correctoras a realizar en el siguiente ciclo para mejorar los
resultados.
Gestión de Riesgos
La gestión del riesgo se refiere a reducir la probabilidad e impacto de los eventos
adversos en un proyecto. El desarrollo Ágil de software, debido a su carácter iterativo,
implícitamente hace que la gestión del riesgo forme parte del ciclo de vida del proyecto.
Los miembros de la comunidad Ágil discutieron si es necesaria la gestión del riesgo
explícita, la capacidad de Scrum para gestionar todos los tipos de riesgo y que debería
hacer la gestión de riesgos.
Michele Sliger sugiere que en el desarrollo de software Ágil el riesgo se gestiona todo el
tiempo: en parte en el Scrum diario, en las reuniones de planificación de cada iteración,
en las reuniones de planificación de release, y también en las reuniones de revisión y
retrospectiva. Sin embargo, ella sugiere un enfoque estructurado para la gestión de
riesgo. Los pasos incluyen:
 Identificación de riesgos - todo el equipo hace este ejercicio en forma iterativa. Los
resultados se registran en una pizarra blanca o en rotafolios.
 Análisis de Riesgos – en el análisis cualitativo se usa el juicio, la intuición y la experiencia

para determinar los riesgos y las posibles pérdidas. En proyectos ágiles los ciclos de
desarrollo son cortos y con constantes revisiones, lo que hace que esto sea posible y
eficaz. Esto es diferente en los proyectos tradicionales en los que el análisis cuantitativo
se realiza y los números se asignan a los daños que puedan producirse.
 Planificación de Respuesta al Riesgo - todo el equipo participa en el desarrollo de

opciones y acciones para reducir las amenazas.
 Control y Monitoreo del Riesgo – el riesgo es objeto de seguimiento, y al final de cada

iteración se discuten las estrategias de Control. Los riesgos también se monitorean
diariamente mediante el uso de radiadores de información.
Gestión de Configuración
Realizar a mano el control y seguimiento de las versiones del código fuente trae muchos
conflictos como ser:
 Tener muchas copias del mismo proyecto y luego olvidar cual es la copia que funciona.
 Si el dispositivo donde está guardado el proyecto deja de funcionar todo el esfuerzo
habrá sido en vano.
 Si estás trabajando con un equipo donde todos modifican el código, será un dolor de
cabeza integrar el código de cada uno al proyecto principal.
Por ello el desarrollo de software es una tarea que requiere de buenas prácticas y
herramientas adecuadas que permitan a un equipo o persona realizar la construcción
del software de la mejor manera teniendo el control de las versiones del código fuente.
5. REFERENCIAS
 PMBOK 5ta edición - PMP Felipe Melendez Sedipro San Marcos.

 Recusos ENPROJECTMANAGEMENT
(http://www.recursosenprojectmanagement.com )
ANEXOS:
El plan de proyecto también está incluido dentro del EXCEL.
Work Breakdown Structure - WBS
sistema de gestion de eventos y red de contactos de la DTI-

UNHEVAL.
Gestion de
Documnetacion
Eventos
Publicacion de Publicacion de
Manual de Manual de envio de correo Creacion de .suscripcion al Comentarios de compartir los contador de Comentarios de Compartir los Regist
asincronos a los eventos en las Crear articulo articulos en las Editar articulos
usuario despliegue eventos evento los eventos. visitas y likes. los articulos usua
usuarios. redes sociales redes sociales
SISTEMA DE GESTIOS DE EVENTOS Y RED DE CONTACTOS

DIRECCION DE TECNOLOGIA E INNOVACION - UNHEVA
ORGANIGRAMA DTI

Gestion de Proyectos

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Gestion de Proyectos

Загружено:

Авторское право:

Доступные форматы

SISTEMA DE GESTIÓN DE EVENTOS Y RED CONTACTOS DE LA DIRECCIÓN DE TECNOLOGÍA E INNOVACIÓN - UNHEVAL

“AÑO DEL DIÁLOGO Y LA RECONCILIACIÓN NACIONAL”

SISTEMA DE GESTIÓN DE EVENTOS Y RED CONTACTOS DE LA

PLAN DE DESARROLLO DE LA PLATAFORMA WEB

DOCENTE : Ing. Luis Meza Ordoñez

TESISTAS : Diaz Sanchez Cesar Anthonny

Vega Cayetano Jhony

Fecha Versión Descripción Autor

 Revisión del Sprint.....................................................................................................................15

SISTEMAS VIABLESla plataforma WEB

 Cumplimento de expectativas: El cliente establece sus expectativas indicando el valor que le

 Autonomía del equipo

2. VISTA GENERAL DEL PROYECTO

 La Oficina de Oferta Tecnológica es la encargada de identificar, organizar y transferir

a) Elaborar y proponer al Vicerrector de Investigación el reglamento de transferencia de

 La Oficina de Patentes, Propiedad Intelectual y Publicaciones tienen las siguientes funciones:

c) Reconocer la autoría de las publicaciones producto de investigaciones financiadas por la

 La Oficina de Emprendimiento e Incubadora de Empresas, promueve la iniciativa de los

 Desarrollar módulo de gestión de contactos de las diferentes áreas.

2.2. Suposiciones y Restricciones

2.3. Documentos del proyecto (SCRUM)

 Plan de Desarrollo de la Plataforma WEB

2.4. REUNIONES EN SCRUM

2.4.1. Daily Scrum

 La reunión comienza puntualmente a su hora.

1. ¿Qué has hecho desde ayer?

2.4.2. Reunión de Planificación del Sprint

 Al inicio del ciclo Sprint (cada 15 o 30 días), una “Reunión de Planificación

 Seleccionar qué trabajo se hará

2.4.3. Reunión de Revisión del Sprint

 Revisar el trabajo que fue completado y no completado.

2.4.4. Retrospectiva del Sprint

2.4.5.Evolución del Plan de Desarrollo del Software

3. ORGANIZACIÓN DEL PROYECTO

participación se adjuntan por separado.

3.2. Interfaces Externas

3.3. Roles y Responsabilidades

4. GESTIÓN DEL PROCESO

4.2. Plan del Proyecto

4.2.A. Plan de las Fases

Fase de Inicio 1 2 semanas

Fase de Elaboración 1 3 semanas

Fase de En esta fase se analizan los requisitos y se desarrolla un prototipo de arquitectura

Calendario del Proyecto

 Trabajo de desarrollo durante el Sprint

 Revisión del Sprint

 Retrospectiva del Sprint

Compartir los articulos

 Análisis de Riesgos – en el análisis cualitativo se usa el juicio, la intuición y la experiencia

 Planificación de Respuesta al Riesgo - todo el equipo participa en el desarrollo de

 Control y Monitoreo del Riesgo – el riesgo es objeto de seguimiento, y al final de cada

 PMBOK 5ta edición - PMP Felipe Melendez Sedipro San Marcos.

Work Breakdown Structure - WBS

sistema de gestion de eventos y red de contactos de la DTI-

SISTEMA DE GESTIOS DE EVENTOS Y RED DE CONTACTOS

Вам также может понравиться