Post on 29-Dec-2015
description
2
[Certificado de prácticas emitido por la institución donde se Desarrollaron las PPP]
{El certificado deberá indicar claramente las fechas de inicio y fin de las prácticas, así como el área o funciones desarrolladas
4
DEDICATORIA
A Dios, que hace posible cada uno de
mis pasos que doy como persona y
profesional.
A mis Padres y hermana, quienes
me han inculcado el deseo de
superación bajo cualquier
circunstancia así como su amor y
apoyo incondicional.
A mis Docentes de la Facultad de
Ingeniería en informática y sistemas
quienes siempre están prestos a
apoyar a sus estudiantes.
5
AGRADECIMIENTO A:
Dios, por la vida que me da y las enseñanzas que dejó, cuidando seguir sus pasos.
A mis padres, por estar conmigo en todos los momentos de mi vida, alentándome a
seguir adelante
A los integrantes la Comisión de Prácticas Pre Profesionales: Ing. William George Paucar
Palomino por brindarme su apoyo y confianza.
Al Ing. Ronald Ibarra Zapata, por tener la gentileza de ser mi asesor y de brindarme todo
su apoyo y guía para el desarrollo de mi práctica pre profesional.
A todos los demás docentes de la Facultad de Ingeniería en Informática y Sistemas
quienes compartieron conmigo sus conocimientos durante 5 años de estudio.
A todos mis amigos y compañeros de la Facultad de Ingeniería en Informática y
Sistemas.
6
ÍNDICE
INTRODUCCIÓN ..................................................................................................................... 9
CAPÍTULO I .......................................................................................................................... 10
DE LA ORGANIZACIÓN ......................................................................................................... 10
1.1. DE LA INSTITUCIÓN ............................................................................................... 10
1.1.1. NOMBRE ....................................................................................................... 10
1.1.2. RESEÑA HISTÓRICA ....................................................................................... 10
1.1.3. DESCRIPCIÓN ................................................................................................ 10
1.1.4. UBICACIÓN GEOGRÁFICA............................................................................... 10
1.1.1. VISIÓN .......................................................................................................... 11
1.1.2. MISIÓN ......................................................................................................... 11
1.1.3. OBJETIVOS .................................................................................................... 11
1.1.4. ESTRUCTURA ORGÁNICA ............................................................................... 11
1.1.5. ORGANIGRAMA ESTRUCTURAL ...................................................................... 12
1.2. DE LA COMISIÓN DE PRÁCTICAS PRE PROFESIONALES ........................................... 13
1.2.1. RESEÑA HISTÓRICA ....................................................................................... 13
1.2.2. DESCRIPCIÓN ................................................................................................ 13
1.2.3. OBJETIVO ...................................................................................................... 13
1.2.4. ORGANIGRAMA DE LA COMISIÓN .................................................................. 13
CAPÍTULO II ..................................................................................................................... 14
MARCO TEÓRICO................................................................................................................. 14
2.1. ¿QUÉ SON LAS PRÁCTICAS PRE PROFESIONALES? .................................................. 14
2.2. INGENIERÍA DE SOFTWARE ................................................................................... 14
2.3. ¿QUÉ ES UN MODELO DE SOFTWARE? .................................................................. 15
2.4. ¿QUÉ ES UNA METODOLOGÍA DE SOFTWARE? ...................................................... 15
2.5. ¿QUÉ SON MODELOS ÁGILES DE PROCESOS DE SOFTWARE? .................................. 15
2.6. PROGRAMACIÓN EXTREMA O XP (EXTREME PROGRAMING) ................................. 16
2.6.1. FASES DE XP .................................................................................................. 18
2.6.2. VARIABLES DE XP .......................................................................................... 21
2.7. ¿QUÉ SON LAS TECNOLOGÍAS WEB? ...................................................................... 22
2.8. ¿QUÉ ES UNA PÁGINA WEB? ................................................................................. 22
2.9. ¿QUÉ ES UN SITIO WEB? ....................................................................................... 22
2.10. ¿QUÉ ES UNA INTRANET? .................................................................................. 23
7
2.11. ¿QUÉ ES UN SERVIDOR WEB? ............................................................................ 23
2.12. ¿QUÉ ES UN SERVIDOR WEB LOCAL? ................................................................. 23
2.13. ¿QUÉ ES UNA APLICACIÓN WEB? ....................................................................... 23
2.14. ¿QUÉ SON SERVICIOS WEB? .............................................................................. 24
2.15. ¿QUÉ ES UN ENTORNO DE DESARROLLO INTEGRADO? ....................................... 24
2.16. ¿QUÉ ES UN SERVIDOR DE APLICACIONES? ........................................................ 25
2.17. PLATAFORMA JAVA .......................................................................................... 25
2.18. JAVA EE ............................................................................................................ 26
2.19. ¿QUÉ ES UNA BASE DE DATOS? ......................................................................... 27
2.20. ¿QUÉ ES UN GESTOR DE BASE DE DATOS? ......................................................... 27
2.21. ¿QUÉ ES POSTGRESQL? ..................................................................................... 27
2.22. ¿QUÉ ES MODELADO DE BASE DE DATOS? ......................................................... 28
2.23. ¿QUÉ ES UN FRAMEWORK DE DESARROLLO? ..................................................... 28
2.24. ¿QUÉ ES JAVA PRIMEFACES? ............................................................................. 29
2.25. ¿QUÉ ES HIBERNATE? ........................................................................................ 29
CAPÍTULO III ........................................................................................................................ 31
ACTIVIDADES REALIZADAS ................................................................................................... 31
3.1 SITUACIÓN ACTUAL DE LA COMISIÓN DE PRÁCTICAS PRE PROFESIOANALES .......... 31
3.2 IDENTIFICACIÓN DEL PROBLEMA ........................................................................... 31
3.3 ANTECEDENTES .................................................................................................... 31
3.4 OBJETIVOS ........................................................................................................... 32
3.4.1. GENERAL ....................................................................................................... 32
3.4.2. ESPECÍFICOS .................................................................................................. 32
3.5 JUSTIFICACIÓN ..................................................................................................... 32
3.6 APLICACIÓN DEL MODELO DE DESARROLLO EXTREME PROGRAMING (XP) ............. 33
3.6.1. DESCRIPCIÓN DE LA ACTIVIDAD ASIGNADA. ................................................... 33
3.6.2. ¿POR QUÉ USAR EL MODELO DE DESARROLLO XP PARA LA CONSTRUCCIÓN DEL
SOFTWARE? ................................................................................................................. 33
3.6.3. PRÁCTICAS UTILIZADAS EN EL PROYECTO ....................................................... 33
3.7 FASE1: PLANEACIÓN ............................................................................................. 34
3.7.1 EQUIPO DE DESARROLLO: .............................................................................. 34
3.7.2 HISTORIAS DE USUARIO: ............................................................................... 35
3.7.3 ESTIMACIÓN DE ESFUERZO ASOCIADOS A LAS HISTORIAS DE USUARIOS ......... 38
3.7.4 PLAN DE ENTREGA ........................................................................................ 39
3.7.5 ANÁLISIS DE REQUISITOS MEDIANTE DIAGRAMAS DE PROCESOS ................... 40
3.7.6 DIAGRAMA DE CLASES................................................................................... 44
8
3.8 FASE 2: DISEÑO .................................................................................................... 46
3.8.1 ARQUITECTURA DEL SISTEMA ........................................................................ 46
3.8.2 DIAGRAMA DE ENTIDAD RELACIÓN ............................................................... 47
3.8.3 DICCIONARIO DE DATOS ................................................................................ 49
3.9 FASE3: CONSTRUCCIÓN ........................................................................................ 49
3.9.1 PROTOTIPOS GENERALES PARA EL DISEÑO Y CONSTRUCCIÓN ........................ 49
3.9.2 PRIMERA ITERACCIÓN ................................................................................... 51
3.9.3. SEGUNDA ITERACCIÓN .................................................................................. 53
3.9.4. TERCERA ITERACCIÓN .................................................................................... 55
3.9.5. CUARTA ITERACCIÓN ..................................................................................... 58
3.9.6. DIARIO DE ACTIVIDADES:............................................................................... 60
3.10 FASE4: PRUEBAS ................................................................................................... 66
3.10. RESUMEN DE LAS PRUEBAS: .............................................................................. 75
CONCLUSIONES ................................................................................................................... 76
RECOMENDACIONES ........................................................................................................... 78
BIBLIOGRAFÍA ..................................................................................................................... 79
ANEXOS .............................................................................................................................. 82
ANEXO 01. GASTOS ADMINISTRATIVOS DE LAS PRÁCTICAS
ANEXO 02. HISTORIAS DE USUARIO
ANEXO 03. TAREAS DE DESARROLLO DE HISTORIAS DE USUARIO
ANEXO 04. DICCIONARIO DE DATOS
ANEXO 05. LISTA DE MATERIALES
ANEXO 06. CRONOGRAMA DE ACTIVIDADES
ANEXO 07. CRONOGRAMA DE ACTIVIDADES POR HORAS
ANEXO 08. REGLAMENTO DE PRÁCTICAS PRE PROFESIONALES 2012
ANEXO 09 DOCUMENTOS DE LA COMISION DE PPP
ANEXO 10. MANUAL DE USUARIO
9
INTRODUCCIÓN
La Facultad de Ingeniería en Informática y Sistemas de la Universidad
Nacional Agraria de la Selva, cuenta con nueve comisiones permanentes del órgano de
apoyo a las actividades administrativas.
Una de las comisiones es la Comisión de Prácticas Pre Profesionales
encargada de planificar, coordinar y supervisar por medios adecuados la ejecución y la
correspondiente evaluación de las prácticas pre profesionales de los estudiantes.
La inexistencia de herramientas que permita automatizar la gestión y control
de las Prácticas Pre Profesionales, sumado a ello, la carga laboral, tanto académica como
administrativa de los integrantes de la comisión, hacen que el trabajo se dificulte.
El presente informe de Prácticas Pre Profesionales describe el desarrollo de
un software exclusivo para la Comisión de Prácticas Pre Profesionales denominado
“SPPP” versión 1.0, con el firme objetivo de apoyar a los procesos de registros y
controles de aquellos estudiantes que están realizando sus Prácticas Pre Profesionales
en la Facultad de Ingeniería en Informática y Sistemas.
El “SPPP” versión 1.0 está desarrollado siguiendo la metodología de
Programación Extrema la cual se sujeta a la investigación preliminar hecha a los
miembros de la comisión, al reglamento de Prácticas Pre Profesionales.
10
CAPÍTULO I
DE LA ORGANIZACIÓN 1.1. DE LA INSTITUCIÓN
1.1.1. NOMBRE
Facultad de Ingeniería en Informática y Sistemas (FIIS).
1.1.2. RESEÑA HISTÓRICA
La Facultad de Ingeniería en Informática y Sistemas. fue creada por
resolución Nº 003-99-AU-R-UNAS de fecha 04 de septiembre de 1999, considerando el
continuo cambio de los procesos empresariales y tecnológicos del mundo de hoy, que
hacen necesarios el reenfoque del pensamiento organizacional orientado al
pensamiento sistémico.
1.1.3. DESCRIPCIÓN
La FIIS, es una unidad fundamental de organización y formación académica y
profesional. Está integrada por sus profesores, graduados, estudiante y personal
administrativo que contribuye a la gestión académica. Tiene como finalidad la formación
profesional, la investigación, la proyección social, la producción de bienes y prestación
de servicios. Está constituido por el Departamento Académico de Ciencias, Informática y
Sistemas, Áreas Académicas, Laboratorios, Gabinetes, Comisiones y otros.
1.1.4. UBICACIÓN GEOGRÁFICA
Departamento :Huánuco
Provincia :Leoncio Prado
Distrito :Rupa Rupa
Dirección :Av. Universitaria s/n
Entidad :Facultad de Ingeniería en Informática y Sistemas Figura 01: Ubicación Geográfica
FUENTE: https://google.maps311
11
1.1.1. VISIÓN
“FIIS, líder en el desarrollo de la amazonia y la nación”.
1.1.2. MISIÓN
“Formar profesionales en informática y sistemas capaces de solucionar
problemas complejos aplicando el enfoque sistémico, preparados para dirigir funciones
para el desarrollo de sistemas integrales útiles y actuar éticamente en su interacción con
la sociedad”.
1.1.3. OBJETIVOS
Brindar una sólida formación en el área de ciencia y tecnología con alta
capacitación en las ciencias exactas, los procesos y sistemas
tecnológicos.
Incentivar el espíritu crítico de la realidad regional, nacional e
internacional.
Despertar la capacidad para desarrollarse independientemente.
Contribuir con soluciones a los problemas identificados en el entorno,
con el apoyo de la investigación y de la interacción social.
1.1.4. ESTRUCTURA ORGÁNICA
Órgano de dirección
Consejo de Facultad
Decanato
Órganos de apoyo
Secretaria de Facultad
Secretaria de DACIS
Extensionista
Comisiones Permanentes
- Comisión de Grados y Títulos
- Comisión de Evaluación y Capacitación Docente
- Comisión de Traslado y Seguimiento Curricular
- Comisión de Prácticas Pre Profesionales
- Comisión de Matricula/Horario/Consejería
- Comisión de Presupuesto
- Comisión de Actividades Culturales y Sociales
- Comisión de Investigación y Publicaciones
- Comisión de Proyección Universitaria
Órganos de Línea
Departamento Académico de Ciencias, Informática y Sistemas
- Jefe de Departamento Académico
12
1.1.5. ORGANIGRAMA ESTRUCTURAL
FIGURA 02:”Organigrama de la FIIS”
DECANO
SECRETARIA
UNIDAD DE EXTENSION
COMISIÓN DE
GRAD. Y TITULOS
COM. DE TRAS.
SEGUI. CURRI.
COMISIÓN DE PRESUPUESTO
COMISIÓN DE PRÁCTICAS. P. P.
COM. DE INVESTI.
Y PUBLICACIÓN
COM. ACT. CULT.
SOCIALES
COM. PROYEC. UNIVERSITARIA
COM. HORARI. Y MATRÍCULA
COM. DE EVAL. Y
CAP. DOCENTE
SECRETARIA
ÁREA DE
SISTEMAS
ÁREA DE COMPUT.
E INFORMÁTICA
ÁREAS DE
CIENCIAS BASICAS
DEPARTAMENTO ACADÉMICO DE CIENCIAS EN INFORMÁTICA Y
SISTEMAS
FUENTE: “Manual de Obligaciones y Funciones de la FIIS”
13
1.2. DE LA COMISIÓN DE PRÁCTICAS PRE PROFESIONALES
1.2.1. RESEÑA HISTÓRICA
Se crea la Comisión de Prácticas Pre Profesionales a propuesta del decano de
la FIIS, la misma que se ratifica o modifica en Consejo de Facultad y se oficializa
mediante la Resolución correspondiente. En lo sucesivo cuando se refiera a esta
comisión se escribirá las siglas CPPP.
1.2.2. DESCRIPCIÓN
La CPPP está integrado por cuatro (04) profesores de la FIIS: Presidente,
Secretario, y dos Vocales. La CPPP se encarga de planificar, coordinar y supervisar por
medios adecuados de la ejecución y la correspondiente evaluación de las Prácticas Pre
Profesionales.
La vigencia de la designación de miembros de la CPPP es de un año,
pudiendo extenderse por otro periodo.
Los integrantes deben ser docentes a tiempo completo y/o a dedicación
exclusiva de cualquier categoría.
1.2.3. OBJETIVO
Planificar, coordinar y supervisar por medios adecuados de la ejecución y la
correspondiente evaluación de las Prácticas Pre Profesionales.
1.2.4. ORGANIGRAMA DE LA COMISIÓN
FIGURA 03:”Organigrama de la comisión de PPP”
FUENTE: “Elaboración Propia”
DECANO
COMISIÓN DE
PPP
PRESIDENTE VOCALSECRETARIO
14
CAPÍTULO II
MARCO TEÓRICO
2.1. ¿QUÉ SON LAS PRÁCTICAS PRE PROFESIONALES?
Se entiende por Prácticas Pre Profesionales a las actividades que realiza el
estudiante, para aplicar y fortalecer los conocimientos adquiridos durante su formación
profesional, consolidando la base conceptual adquirida, haciendo investigación, análisis,
diseño e implementación de soluciones.
VER ANEXO 08.”REGLAMENTO DE PRÁCTICAS PRE PROFESIONALES FIIS
2012”
2.2. INGENIERÍA DE SOFTWARE1
Según Fritz Bauer en una conferencia fundamental definió que la ingeniería
del software es el establecimiento y uso de principios sólidos de la ingeniería para
obtener económicamente un software confiable y que funcione de modo eficiente en
máquinas reales.
Otras definiciones:
Ingeniería del Software es la aplicación práctica del conocimiento científico
al diseño y construcción de programas de computadora y a la documentación asociada
requerida para desarrollar, operar (funcionar) y mantenerlos. Se conoce también como
desarrollo de software o producción de software (Bohem, 1976).
La aplicación de un enfoque sistemático, disciplinado y cuantificable al
desarrollo, operación (funcionamiento) y mantenimiento del software; es decir, la
aplicación de ingeniería al software. (IEEE, 1993).
La ingeniería del software es una tecnología estratificada. Como se muestra
en la figura 3, cualquier enfoque de la ingeniería (incluido el de la ingeniería de
software) debe estar sustentado en un compromiso con la calidad.
FIGURA.04: Estratos de la ingeniería de software.
Fuente: Ingeniería del Software – Roger Pressman 6th.Ed.McGraw-Hill
La ingeniería de software abarca un proceso, métodos y herramientas.
1 Ingeniería del Software – Roger Pressman.6th.Ed.McGraw-Hill.pdf Pág.45
15
El Proceso.- Es el elemento que mantiene juntos los estratos de la tecnología
y que permite el desarrollo relacional y a tiempo del software de computadora. Así
mismo, forma parte de la base para el control de la gestión de los proyectos de software
y establece el contexto en el cual se aplican los métodos técnicos, se generan los
productos del trabajo (modelos, documentos, reportes, formatos, etc.), se establecen los
fundamentos, se asegura la calidad, y el cambio apropiadamente.
Los Métodos.- Proporcionan los “cómo” técnicos para construir software.
Abarcan un amplio espectro de tareas que incluyen la comunicación, el análisis de
requisitos, el modelo del diseño, la construcción del programa, la realización de pruebas
y el soporte.
Las Herramientas.- Proporcionan el soporte automatizado o semi-
automatizado para el proceso y los métodos. Cuando las herramientas se integran de
forma que la información que cree una de ellas pueda usarla otra, se dice que se
establecido un sistema para el soporte del desarrollo de software, que con frecuencia se
denomina ingeniería del software asistida por computadora.
2.3. ¿QUÉ ES UN MODELO DE SOFTWARE? 2
Un modelo es un esquema o una estructura que nos indica cuales son los
pasos a seguir dentro del ciclo de vida de una aplicación. Sin embargo no nos dice que
límites tiene cada uno de los pasos, ni que se debe cumplir para pasar de uno a otro, o al
siguiente.
2.4. ¿QUÉ ES UNA METODOLOGÍA DE SOFTWARE?3
Es un marco de trabajo usado para estructurar, planificar y controlar el
proceso de desarrollo en sistemas de información.
2.5. ¿QUÉ SON MODELOS ÁGILES DE PROCESOS DE SOFTWARE?4
Los modelos de proceso ágil se diseñaron para cumplir con los cuatros
aspectos claves de la ingeniería de software como son: la importancia de la organización
propia de los equipos, los cuales controlan el trabajo que realizan; comunicación y
colaboración entre los miembros del equipo y entre los profesionales y sus clientes; un
reconocimiento de que el cambio representa una oportunidad; y un especial cuidado en
la entrega rápida del software que satisfaga al cliente.
Existe un amplio espectro de modelos ágiles de proceso, cada uno en busca
de su aceptación dentro de la comunidad del desarrollo de software. Entre ellos
tenemos a la Programación Extrema (XP), Desarrollo adaptivo de software (DAS),
2 http://raulortega.blogspot.com/2006/12/para-los-lectores-de-este-blog-los.html-Software Libre 3 http://www.um.es/docencia/barzana/IAGP/Iagp2.html - Apuntes. Ingeniería del Software 4 Ingeniería del Software – Roger Pressman.6th.Ed.McGraw-Hill.pdf Pág.106
16
Método de desarrollo de sistemas dinámicos (MDSD), Melé, Cristal, Desarrollo
conducido por características (DCC), Modelo ágil (MA).
2.6. PROGRAMACIÓN EXTREMA O XP (EXTREME PROGRAMING)5
La Programación Extrema (XP) es posiblemente el método ágil más conocido
y ampliamente utilizado. El nombre fue acuñado por Beck (Beck.2000) debido a que el
enfoque fue desarrollado utilizando buenas prácticas reconocidas, como el desarrollo
iterativo, y con la participación del cliente en niveles <<extremos>>.
En la programación extrema, todos los requerimientos se expresan como
escenarios (llamados historias de usuario), los cuales se implementan directamente con
una serie de tareas.
Los programadores trabajan en parejas y desarrollan pruebas para cada
tarea antes de escribir código. Todas las pruebas deben ejecutarse satisfactoriamente
cuando el código nuevo se integra al sistema. Existe un pequeño espacio de tiempo
entre las entregas del sistema. La Figura 05. Ilustra el proceso del modelo XP para
producir un incremento del sistema que se está desarrollando.
La programación extrema implica varias prácticas, resumidas en el cuadro 1.
Que se ajustan a los principios de los métodos ágiles:
El desarrollo incremental se lleva a cabo a través de entregas del sistema
pequeñas y frecuentes y por medio de un enfoque para la descripción de
requerimientos basado en las historias de cliente o escenarios que pueden ser la base
para el proceso de planificación.
El interés en las personas, en vez de en los procesos, se lleva a cabo a través
de la programación en parejas, la propiedad colectiva del código del sistema, y un
proceso de desarrollo sostenible que no implique excesivas jornadas de trabajo.
El cambio se lleva a cabo a través de las entregas regulares del sistema, un
desarrollo previamente probado y la integración continua.
El mantenimiento de la simplicidad se lleva a cabo a través de la
refactorización constante para mejorar la calidad del código y la utilización de diseños
sencillos que no prevén cambios futuros en el sistema.
FIGURA 05.El ciclo de entrega en la programación extrema
Fuente: Programación extrema- Ingenieria.de.Software.-.Ian.Sommerville.7ma.Edicion
5 Programación extrema- Ingenieria.de.Software.-.Ian.Sommerville.7ma.Edicion.PRENTICE-HALL.Pág.373
Evaluar el sistemaDesarrollar, probar e
integrar el softw areEntregar el softw are
Planificar entregaDividir las historias en
tareas
Seleccionar las
historias de usuario
para esta entrega
17
Cuadro 01. Prácticas de la Programación Extrema.
PRINCIPIO O PRÁCTICA DESCRIPCIÓN
Planificación incremental
Los requerimientos se registran en tarjetas de historias y las historias a incluir en una entrega se determinan según el tiempo disponible y su propiedad relativa. Los desarrolladores dividen estas Historias en <<Tareas>> de desarrollo.
Entregas pequeñas
El mínimo conjunto útil de funcionalidad que proporcione valor de negocio se desarrolla primero. Las entregas del sistema son frecuentes e incrementalmente añaden funcionalidad a la primera entrega.
Metáforas Guiar todo el desarrollo con una historia simple y compartida de cómo funciona todo el sistema.
Diseño sencillo Sólo se lleva a cabo el diseño necesario para cumplir los requerimientos actuales.
Desarrollo previamente probado
Se utiliza un sistema de pruebas de unidad automatizado para escribir pruebas para nuevas funcionalidades antes de que éstas se implementen.
Refactorización
Se espera que todos los desarrolladores refactoricen el código continuamente tan pronto como encuentren posibles mejoras en el código. Esto conserva el código sencillo y mantenible.
Programas en parejas
Los desarrolladores trabajan en parejas, verificando cada uno el trabajo del otro y proporcionando la ayuda necesaria para hacer siempre un buen trabajo.
Propiedad colectiva
Las parejas de desarrolladores trabajan en todas las áreas del sistema, de modo que no desarrollen islas de conocimientos y todos los desarrolladores posean todo el código. Cualquiera puede cambiar cualquier cosa.
Semana de 40 horas Trabajar no más de 40 horas semanales como regla. Nunca trabajar horas extras durante dos semanas consecutivas.
Integración continua En cuanto acaba el trabajo en una tarea, se integra en el sistema entero. Después de la integración, se deben pasar al sistema todas las pruebas de unidad.
Cliente presente
Debe estar disponible al equipo de la XP un representante de los usuarios finales del sistema (el cliente) a tiempo completo. En un proceso de la programación extrema, el cliente es miembro del equipo de desarrollo y es responsable de formular al equipo los requerimientos del sistema para su implementación.
Usar Estándares de Codificación
Los programadores escriben todo el código de acuerdo con reglas que enfatizan la comunicación a través del mismo.
Fuente: Elaboración Propia.
18
2.6.1. FASES DE XP6
Según Roger Pressman en su libro 6th Edición sobre Ingeniería del Software
nos habla de 4 Fases: Planeación, diseño, codificación y pruebas. Un ejemplo claro se
muestra en la figura 06.
FIGURA 06. Proceso de la Programación Extrema
Fuente: Ingeniería del Software – Roger Pressman 6th.Ed.McGraw.
1° FASE: PLANIFICACIÓN DEL PROYECTO:
Historia de usuario:
El primer paso de cualquier proyecto que siga el modelo XP es definir las
historias de usuario con el cliente. Las historias de usuario tienen la misma finalidad que
los casos de uso pero con algunas diferencias: Constan de 3 o 4 líneas escritas por el
cliente en un lenguaje no técnico sin hacer mucho hincapié en los detalles; no se debe
hablar ni de posibles algoritmos para su implementación ni de diseños de base de datos
adecuados, etc. Son usadas para estimar tiempos de desarrollo de la parte de la
aplicación que describen. También se utilizan en la fase de pruebas, para verificar si el
programa cumple con lo que especifica la historia de usuario. Cuando llega la hora de
implementar una historia de usuario, el cliente y los desarrolladores se reúnen para
concretar y detallar lo que tiene que hacer dicha historia. El tiempo de desarrollo ideal
para una historia de usuario es entre 1 y 3 semanas. Un ejemplo de historia de usuario
se muestra en el cuadro 02.
6 http://wiki.monagas.udo.edu.ve/index.php/Metodolog%C3%ADas_SCRUM_y_XP#METODOLOG.C3.8DA_XP_.28EXTREME_PROGRAMMING.29 – Metodologías XP
diseño
planeación
codif icación
codif icación
incremento del sof tware
v alocidad calculada del
proy ecto
historias de usuario
v alores criterios de la
prueba de iteracción
plan de iteracción
soluciones pico
prototipos
programación en
pareja
prueba de unidad
Lanzamientoprueba de unidad
integración continua
19
Cuadro 02. Modelo propuesto para una historia de usuario
Historia de Usuario
Nombre Historia de Usuario:
Rol:
Valor: Iteración asignada:
Descripción:
Observación:
Fuente: http://www.xp.com/trabajos51/programacion-extrema/programacion-extrema2
Las Historias de Usuario tienen tres aspectos:
Tarjeta: en ella se almacena suficiente información para identificar y detallar
la historia.
Conversación: cliente y programadores discuten la historia para ampliar los
detalles (verbalmente cuando sea posible, pero documentada cuando se requiera
confirmación).
Release Planning:
Después de tener ya definidas las historias de usuario es necesario crear un
plan de publicaciones, en inglés "Release plan", donde se indiquen las historias de
usuario que se crearán para cada versión del programa y las fechas en las que se
publicarán estas versiones. Un "Release plan" es una planificación donde los
desarrolladores y clientes establecen los tiempos de implementación ideales de las
historias de usuario, la prioridad con la que serán implementadas y las historias que
serán implementadas en cada versión del programa. (*Release plan: Planificación de
publicaciones).
Iteraciones:
Todo proyecto que siga la metodología XP se ha de dividir en iteraciones de
aproximadamente 3 semanas de duración. Al comienzo de cada iteración los clientes
deben seleccionar las historias de usuario definidas en el "Release planning" que serán
implementadas. También se seleccionan las historias de usuario que no pasaron el test
de aceptación que se realizó al terminar la iteración anterior. Estas historias de usuario
son divididas en tareas de entre 1 y 3 días de duración que se asignarán a los
programadores.
La Velocidad del Proyecto:
Es una medida que representa la rapidez con la que se desarrolla el
proyecto; estimarla es muy sencillo, basta con contar el número de historias de usuario
que se pueden implementar en una iteración; de esta forma, se sabrá el cupo de
historias que se pueden desarrollar en las distintas iteraciones. Usando la velocidad del
proyecto controlaremos que todas las tareas se puedan desarrollar en el tiempo del que
dispone la iteración. Es conveniente reevaluar esta medida cada 3 ó 4 iteraciones y si se
aprecia que no es adecuada hay que negociar con el cliente un nuevo "Release Plan".
20
Programación en Parejas:
La metodología XP aconseja la programación en parejas pues incrementa la
productividad y la calidad del software desarrollado.
El trabajo en pareja involucra a dos programadores trabajando en el mismo
equipo; mientras uno codifica haciendo hincapié en la calidad de la función o método
que está implementando, el otro analiza si ese método o función es adecuado y está
bien diseñado. De esta forma se consigue un código y diseño con gran calidad.
Reuniones Diarias:
Es necesario que los desarrolladores se reúnan diariamente y expongan sus
problemas, soluciones e ideas de forma conjunta. Las reuniones tienen que ser fluidas y
todo el mundo tiene que tener voz y voto.
2° FASE: Diseño.
Diseños Simples:
La metodología XP sugiere que hay que conseguir diseños simples y
sencillos. Hay que procurar hacerlo todo lo menos complicado posible para conseguir un
diseño fácilmente entendible e implementarle que a la larga costará menos tiempo y
esfuerzo desarrollar.
Glosarios de Términos:
Usar glosarios de términos y una correcta especificación de los nombres de
métodos y clases ayudará a comprender el diseño y facilitará sus posteriores
ampliaciones y la reutilización del código.
Riesgos:
Si surgen problemas potenciales durante el diseño, XP sugiere utilizar una
pareja de desarrolladores para que investiguen y reduzcan al máximo el riesgo que
supone ese problema.
Funcionabilidad extra:
Nunca se debe añadir funcionalidad extra al programa aunque se piense que
en un futuro será utilizada. Sólo el 10% de la misma es utilizada, lo que implica que el
desarrollo de funcionalidad extra es un desperdicio de recursos.
Refactorizar:
Refactorizar es mejorar y modificar la estructura y codificación de códigos ya
creados sin alterar su funcionalidad. Refactorizar supone revisar de nuevo estos códigos
para procurar optimizar su funcionamiento. Es muy común rehusar códigos ya creados
que contienen funcionalidades que no serán usadas y diseños obsoletos.
21
3° FASE: CODIFICACIÓN.
El cliente es una parte más del equipo de desarrollo; su presencia es
indispensable en las distintas fases de XP. A la hora de codificar una historia de usuario
su presencia es aún más necesaria. No olvidemos que los clientes son los que crean las
historias de usuario y negocian los tiempos en los que serán implementadas. Antes del
desarrollo de cada historia de usuario el cliente debe especificar detalladamente lo que
ésta hará y también tendrá que estar presente cuando se realicen los test que verifiquen
que la historia implementada cumple la funcionalidad especificada. Programar bajo
estándares mantiene el código consistente y facilita su comprensión y escalabilidad.
4° FASE: PRUEBAS.
Uno de los pilares de la metodología XP es el uso de test para comprobar el
funcionamiento de los códigos que vayamos implementando. El uso de los test en XP es
el siguiente:
Se deben crear las aplicaciones que realizarán los test con un entorno de
desarrollo específico para test.
Hay que someter a test las distintas clases del sistema omitiendo los
métodos más triviales.
Se deben crear los test que pasarán los códigos antes de implementarlos; en
el apartado anterior se explicó la importancia de crear antes los test que el código.
Un punto importante es crear test que no tengan ninguna dependencia del
código que en un futuro evaluará.
Como se comentó anteriormente los distintos test se deben subir al
repositorio de código acompañados del código que verifican.
Test de aceptación. Los test mencionados anteriormente sirven para evaluar
las distintas tareas en las que ha sido dividida una historia de usuario.
2.6.2. VARIABLES DE XP
Coste: Máquinas, especialistas y oficinas
Tiempo: Total y de Entregas
Calidad: Externa e Interna
Alcance: Intervención del cliente
22
2.7. ¿QUÉ SON LAS TECNOLOGÍAS WEB?
Un conjunto de soluciones y servicios que nos permite asesorar, crear y
consolidar proyectos de manera inteligente destacando:7
Navegadores web:8
Mozilla Firefox Konqueror sobre Linux Seamonkey
Google Chrome Lynx sobre linux Shiira
Galeon Opera Midori
Internet Explorer Safari Meleon
Servidores web:
CERN httpd Glassfish
Servidor HTTP Apache Tomcat
IIS Servidor HTTP Cherokee
Otras tecnologías:
JSP JSF
DHTML HIBERNATE
PHP .NET
2.8. ¿QUÉ ES UNA PÁGINA WEB?9
Empezando por su definición, consideramos una página web a un
documento disponible en Internet, o World Wide Web (www), codificado según sus
estándares y con un lenguaje específico conocido como HTML. Es algo a lo que estamos
acostumbrados a acceder si leemos este artículo pero no todos conocen realmente su
funcionamiento.
2.9. ¿QUÉ ES UN SITIO WEB?10
En inglés Website o Web Site, un sitio Web es un sitio (localización) en la
World Wide Web que contiene documentos (páginas web) organizados jerárquicamente
(generalmente documentos en formato html, php, asp, etc.). Cada documento (página
web) contiene texto y/o gráficos que aparecen como información digital en la pantalla
de un ordenador. Un sitio puede contener una combinación de gráficos, texto, audio,
vídeo, y otros materiales dinámicos o estáticos.
7 http://www.microscience.pe/20/tecnologia-web 8 http://norfipc.com/internet/navegadores-web.html 9 http://tendenciasweb.about.com/od/nociones-basicas/a/Que-Es-Una-Pagina-Web.htm 10 http://www.masadelante.com/faqs/sitio-web
23
Cada sitio web tiene una página de inicio (en inglés Home Page), que es el
primer documento que ve el usuario cuando entra en el sitio web poniendo el nombre
del dominio de ese sitio web en un navegador. El sitio normalmente tiene otros
documentos (páginas web) adicionales. Cada sitio pertenece y es gestionado y por un
individuo, una compañía o una organización.
2.10. ¿QUÉ ES UNA INTRANET?11
Es una red de ordenadores privada basada en los estándares de Internet.
Las Intranets utilizan tecnologías de Internet para enlazar los recursos
informativos de una organización, desde documentos de texto a documentos
multimedia, desde bases de datos legales a sistemas de gestión de documentos. Las
Intranets pueden incluir sistemas de seguridad para la red, tablones de anuncios y
motores de búsqueda.
2.11. ¿QUÉ ES UN SERVIDOR WEB?12
Almacena principalmente documentos HTML (son documentos a modo de
archivos con un formato especial para la visualización de páginas web en los
navegadores de los clientes), imágenes, videos, texto, presentaciones, y en general todo
tipo de información. Además se encarga de enviar estas informaciones a los clientes.
2.12. ¿QUÉ ES UN SERVIDOR WEB LOCAL?13
Un Servidor Web Local es aquel Servidor Web que reside en una red local al
equipo de referencia. El Servidor web Local puede estar instalado en cualquiera de los
equipos que forman parte de una red local. Es por tanto obvio, que todos los Servidores
Web, son locales a la red local en la que se encuentran, o como mínimo, locales al
sistema en el que están instalados.
2.13. ¿QUÉ ES UNA APLICACIÓN WEB?14
Una aplicación web es un conjunto de páginas que interactúan unas con
otras y con diversos recursos en un servidor web, incluidas bases de datos. Esta
interacción permite implementar características en su sitio como catálogos de
productos virtuales y administradores de noticias y contenidos. Adicionalmente podrá
realizar consultas a bases de datos, registrar e ingresar información, solicitudes, pedidos
y múltiples tipos de información en línea en tiempo real.
11 http://www.hosting-peru.net/que_es_intranet.html 12 http://www.aprenderaprogramar.com 13 http://www.antoniocalderonch.com/ique-es-un-servidor-local 14 http://www.suronline.net/nuevo_sitio/beneficios-funcionamiento-aplicaciones-web.asp
24
2.14. ¿QUÉ SON SERVICIOS WEB?
Los Servicios Web o Web Services son una API para permitir exponer
servicios a través de la Web. Permite que aplicaciones Web interactúen
dinámicamente con otras aplicaciones, utilizando para ello estándares abiertos
como XML (Extensible Markup Language), UDDI (Universal Description,
Discovery and Integration) y SOAP (Simple Object Access Protocol). Las funciones
que pueden ser realizadas por los web services pueden ir desde simples
intercambios de información hasta complicados procesos de negocios. Se puede
encapsular su lógica de negocio mediante web services y exponerlas para que los
clientes las consuman a través de la web.
2.15. ¿QUÉ ES UN ENTORNO DE DESARROLLO INTEGRADO?15
Los programas de desarrollo de software tienen como objetivo hacer que el
proceso de desarrollo lo más sencillo posible. Programas IDE incluyen un editor de
código fuente, compilador, y por lo general un depurador que todos trabajemos juntos
en la construcción de un programa de software. El IDE mantiene un registro de todos los
archivos relacionados con un proyecto y proporciona una interfaz central para escribir
código fuente, vincular archivos juntos y depurar el software.
Software de programación IDE también puede incluir un entorno de tiempo
de ejecución (RTE) para probar el software. Cuando un programa se ejecuta dentro de la
RTE, el software puede realizar un seguimiento de cada evento que tiene lugar dentro
de la aplicación que se está probando. Esto puede ser una herramienta muy buena para
depurar el programa. Debido a que el software IDE utiliza una interfaz central para
escribir el código y probar el programa, es fácil hacer cambios rápidos en el código,
compilarlo y ejecutar el programa de nuevo. La programación es todavía un trabajo
duro, pero el software IDE ayuda a que los procesos un poco más libre de problemas.
a) NETBEANS16
NetBeans es un proyecto exitoso de código abierto con una gran base de
usuarios, una comunidad en constante crecimiento, y con cerca de 100 socios (¡y
creciendo!) en todo el mundo. Sun MicroSystems fundó el proyecto de código abierto
NetBeans en junio 2000 y continúa siendo el patrocinador principal de los proyectos.
Al día de hoy hay disponibles dos productos: el NetBeans IDE y NetBeans
Platform.
NetBeans IDE es un entorno de desarrollo - una herramienta para que los
programadores puedan escribir, compilar, depurar y ejecutar programas. Está escrito en
Java - pero puede servir para cualquier otro lenguaje de programación. Existe además
15 http://www.techterms.com/definition/ide 16 https://netbeans.org/index_es.html
25
un número importante de módulos para extender el NetBeans IDE. NetBeans IDE es un
producto libre y gratuito sin restricciones de uso.
Última versión estable: 7.4; 15 de octubre de 2013
Género: Entorno de desarrollo integrado.
Programado en: Java
Sistema operativo: Multiplataforma
Licencia: CDDL, GNU General Public License 2
Estado actual: En desarrollo
Idiomas:
Multilingüe
2.16. ¿QUÉ ES UN SERVIDOR DE APLICACIONES?17
Un servidor de aplicaciones se trata de un dispositivo de software
que proporciona servicios de aplicación a las computadoras cliente. Un servidor de
aplicaciones gestiona las funciones de lógica de negocio y de acceso de datos a la
aplicación. Los principales beneficios son la centralización y la disminución de la
complejidad en el desarrollo de aplicaciones:
a) GLASSFISH
El término Glassfish, traducido al español sería algo parecido como “Pez de
Cristal”, es el nombre de un pez que realmente existe y vive en el agua
dulce; su cuerpo es transparente, por lo que sus huesos son visibles. El
nombre fue elegido debido a la transparencia que los creadores querían darle al
proyecto, que utiliza una licencia Open Source, concretamente la licencia Common
Development and Distribution License (CDDL) v1.0 y la GNU Public License (GPL) v2.
2.17. PLATAFORMA JAVA18
La plataforma Java es el entorno de software basado en Java que se ejecuta
sobre otras plataformas y su software puede ser usado sobre varios sistemas operativos
y hardware. Está formada por tres componentes:
• Lenguaje. Es un lenguaje de propósito general, de alto nivel que
utiliza el paradigma de orientación a objetos.
• La Máquina Virtual. Los programas escritos en Java son
compilados como archivos ejecutables de una máquina virtual llamada Java Virtual
Machine (JVM), esto permite que los programas ejecutables puedan ejecutarse
en distintas arquitecturas.
17 SERRA MACHADO DAVID – “Estudio del servidor de aplicaciones Glassfish y de las aplicaciones J2EE“ pág. 182 disponible en ddd.uab.cat/pub/trerecpro/.../SerraManchadoDavidR-ETISa2009-10.pdf 18 SERRA MACHADO DAVID – “Estudio del servidor de aplicaciones Glassfish y de las aplicaciones J2EE“ pág. 25 disponible en ddd.uab.cat/pub/trerecpro/.../SerraManchadoDavidR-ETISa2009-10.pdf
26
• Las Bibliotecas. El conjunto de bibliotecas del lenguaje es conocido como
la Java Aplication Programming Interface (Java API) y es un conjunto de componentes
que proporcionan diferentes herramientas para el desarrollo.
Para la plataforma Java existen diferentes ediciones:
• Java Micro Edition (Java ME). Desarrollo para artículos móviles pequeños.
• Java Standard Edition (Java SE). Es la edición que se emplea en computadoras
personales (desktops y laptops).
• Java Enterprise Edition (Java SE). Desarrollo orientado a aplicaciones empresariales.
2.18. JAVA EE19
La plataforma Java EE está diseñado para ayudar a los desarrolladores a
crear a gran escala, de varios niveles, las aplicaciones de red escalable y confiable y
segura. Un nombre abreviado para estas aplicaciones es “aplicaciones empresariales”,
llamado así debido a que estas aplicaciones se han diseñado para resolver los problemas
encontrados por las grandes empresas. Las aplicaciones empresariales no sólo son útiles
para las grandes corporaciones, organismos y gobiernos, sin embargo. Los beneficios de
una aplicación empresarial son útiles, incluso esenciales, para que los desarrolladores
individuales y pequeñas organizaciones en un mundo cada vez más interconectado.
FIGURA 06: “Arquitectura JEE”
FUENTE: http://www3.gobiernodecanarias.org/medusa/ecoblog/fsalpaz/
19 SERRA MACHADO DAVID – “Estudio del servidor de aplicaciones Glassfish y de las aplicaciones J2EE“ pág. 26
27
A demás JEE también se encarga de proporcionar características para la
gestión de:
Seguridad
Control de transacciones
Gestión de componentes desplegados
Control de concurrencia
Uso y asignación de recursos
2.19. ¿QUÉ ES UNA BASE DE DATOS?20
Una colección de información organizada de tal manera que un programa de
computadora puede rápidamente seleccionar piezas deseadas de datos.
2.20. ¿QUÉ ES UN GESTOR DE BASE DE DATOS?
Una colección de programas que le permite almacenar, modificar y extraer
información de una base de datos. Hay muchos tipos diferentes de DBMS, que van
desde pequeños sistemas que se ejecutan en los ordenadores personales a grandes
sistemas que se ejecutan en los mainframes.
2.21. ¿QUÉ ES POSTGRESQL?21
PostgreSQL es un sistema de gestión de bases de datos objeto-relacional,
distribuido bajo licencia BSD y con su código fuente disponible libremente. Es el sistema
de gestión de bases de datos de código abierto más potente del mercado y en sus
últimas versiones no tiene nada que envidiarle a otras bases de datos comerciales.
TABLA 01: Límites de Postgres
FUENTE: http://www.postgresql.org.es/sobre_postgresql
20 http://www.webopedia.com/TERM/D/database.html 21 http://www.postgresql.org.es/sobre_postgresql
28
2.22. ¿QUÉ ES MODELADO DE BASE DE DATOS?22
Es el proceso de realizar el modelo de entidad relación físico para ser
exportado al lenguaje SQL.
a) MICROOLAP
MicroOLAP Database Designer for PostgreSQL es una herramienta CASE fácil
con la interfaz gráfica intuitiva que le permite construir una estructura de base de datos
clara y eficaz visualmente, ve el cuadro completo (diagrama) que representa todas las
tablas, las referencias entre ellos, vistas, procedimientos almacenados y otros objetos.
2.23. ¿QUÉ ES UN FRAMEWORK DE DESARROLLO?23
Un framework de aplicaciones web es un tipo de framework que permite el
desarrollo de sitios web dinámicos, web services (servicios web) y aplicaciones web. El
propósito de este tipo de framework es permitir a los desarrolladores construir
aplicaciones web y centrarse en los aspectos interesantes, aliviando la típica tarea
repetitiva asociada con patrones comunes de desarrollo web. La mayoría de los
frameworks de aplicaciones web proporcionan los tipos de funcionalidad básica común,
tales como sistemas de templates (plantillas), manejo de sesiones de usuario, interfaces
comunes con el disco o el almacenamiento en base de datos de contenido cacheado, y
persistencia de datos. Normalmente, los frameworks de aplicación web además
promueven la reutilización y conectividad de los componentes, así como la reutilización
de código, y la implementación de bibliotecas para el acceso a base de datos.
FIGURA 07: Componentes JSF en la página de configuración de Glassfish
FUENTE:” SERRA MACHADO DAVID – “Estudio del servidor de aplicaciones Glassfish
y de las aplicaciones J2EE“pág. 182
JSF proporciona:24
Una clara separación entre vista y modelo.
Desarrollo basado en componente, no en peticiones.
Las acciones del usuario se ligan muy fácilmente al código en el servidor.
Creación de familias de componentes visuales para acelerar el desarrollo.
22 http://www.postgresql.org/about/news/1465/ 23 http://elbauldelprogramador.com/articulos/los-10-mejores-frameworks-gratis-de-aplicaciones-web/ 24 http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/101
29
Ofrece múltiples posibilidades de elección entre distintos desarrollos.
Hace que sea fácil de construir una interfaz de usuario a partir de un conjunto de
componentes de interfaz de usuario reutilizables
Simplifica la migración de los datos de la aplicación a y desde la interfaz de usuario
Ayuda a administrar el estado de la interfaz de usuario a través de las peticiones de
servidor
Proporciona un modelo simple para el cableado de los eventos generados por el
cliente al código de la aplicación en el servidor
Permite que los componentes de interfaz de usuario personalizada para construir
fácilmente y reutilizarse
2.24. ¿QUÉ ES JAVA PRIMEFACES?25
Es un framework complemento a los componentes de Java Server Faces, El
punto fuerte de PrimeFaces es la sencillez de instalación y lo poco pesado que es. El
mantenerlo liviano, sin complicaciones a la hora de instalarlo, es decir, sin dependencias
ni configuraciones, hace que podamos estar usándolo en unos pocos segundos.
CARÁCTERÍSTICAS:
Un interesante conjunto de componentes (editor HTML,
autocompletado, gráficas,…)
Soporte para Ajax, basándose en el estándar JSF 2.0 Ajax API
Sin dependencias, ni configuraciones, además de ser muy ligero (1802Kb
en su versión 3.5)
Soporte para interfaces de usuario sobre dispositivos móviles, nos
provee de un kit para este menester.
Múltiples temas de apariencia, listos para usar.
Amplia difusión del framework, con lo cual existe una comunidad que
respalda al proyecto.
2.25. ¿QUÉ ES HIBERNATE?26
Hibernate funciona asociando a cada tabla de la base de datos un Plain Old
Java Object (POJO, a veces llamado Plain Ordinary Java Object). Un POJO es similar a
una Java Bean, con propiedades accesibles mediante métodos setter y getter.
QUERY Y LENGUAJE HQL: Existen diversas herramientas útiles para el uso de Hibernate que cubren
todo el desarrollo desde nuestra aplicación hasta nuestra base de datos y viceversa:
25 http://www.genbetadev.com/frameworks/primefaces-framework-sobre-jsf-2-0-primeros-pasos 26 http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=hibernate
30
FIGURA 08: Componentes JSF en la página de configuración de Glassfish
FUENTE: http://www.hibernate.org/102.html
Desde herramientas de modelado UML como por ejemplo con Poseidon
podemos generar modelos entidad relación que son traducidos por AndroMDA a
POJO's y mediante XDoclet se generan los ficheros HBM. Todas estas tareas se
automatizan mediante el uso de ANT.
Otra opción es crear la base de datos con una herramienta de modelado y a
partir de la base de datos una vez creada usar Middlegen para generar los ficheros HBM
y a partir de estos los POJO's mediante hbm2java.
31
CAPÍTULO III
ACTIVIDADES REALIZADAS
3.1 SITUACIÓN ACTUAL DE LA COMISIÓN DE PRÁCTICAS PRE PROFESIOANALES
El proceso de las Prácticas Pre Profesionales en la FIIS es administrada por la
CPPP, compuesta por cuatro (04) integrantes que son los encargados de planificar,
coordinar y supervisar la ejecución y la correspondiente evaluación de las Prácticas Pre
Profesionales.
Actualmente las funciones de la CPPP que son ejecutadas por sus
integrantes que no solo tienen esta carga administrativa, sino muchas otras dentro de la
universidad, además de cumplir con su carga académica establecida.
Por lo tanto, el tiempo que dispone cada integrante de la comisión es muy
corto y necesitan de un mecanismo o herramienta que les ayude en sus actividades
dentro de la comisión, especialmente en la búsqueda de información y en tener
disponibilidad inmediata de información.
Se realizaron varios intentos por buscar un mecanismo que permita agilizar
sus procedimientos pero que no lograron alcanzar el objetivo.
3.2 IDENTIFICACIÓN DEL PROBLEMA
La inexistencia de un mecanismo o herramientas que permita agilizar los
procedimientos de registro y control de las Prácticas Pre Profesionales, obteniendo
como resultado datos e información no disponible al momento sobre el estado de los
practicante y sus actividades realizadas a la fecha.
3.3 ANTECEDENTES
El trabajo manual que realiza la CPPP quiso ser automatizado por varios
estudiantes de la FIIS. En la memoria de los docentes de dicha facultad existe la
realización de dos software de Prácticas Pre Profesionales.
El primero fue realizado por el ex estudiante de la FIIS, Percy Collantes Díaz,
con motivo de sus prácticas pre profesionales, el cual no ha sido encontrando ni en los
archivos de la facultad, el ex estudiante Collantes no hizo entrega del informe final
corregido del trabajo realizado.
El segundo, se recuerda que, un grupo de estudiantes que llevaron cursos de
programación en la FIIS, tuvieron el interés de desarrollar un sistemas de prácticas pre
profesional, que no se llegó a concluir satisfactoriamente, o no se quiso entregar la
información requerida, tales como el código o el informe del desarrollo para su correcta
implementación.
Todos estos antecedentes, según lo investigado, estuvieron realizados en
programación de escritorio.
32
El antecedente más cercano es del ex alumno Mariño Gamboa (2010), quien
realizó el software para la comisión bajo el lenguaje de programación PHP y Gestor de
Base de datos Mysql. El cual a la vez nunca se usó, desfasándose y archivándose, al
observarlo y hacerlo funcionar se observó que no existe un plan de despliegue además
de tener el código desordenado y poco entendible para su mantenimiento.
El docente de la FIIS Ing. Ronald Ibarra Zapata, diseñó un modelo de base de
datos para la comisión de Prácticas Pre Profesionales.
3.4 OBJETIVOS
3.4.1. GENERAL
Desarrollar el sistema de Prácticas Pre Profesionales “SPPP” V1.0, con
tecnologías web, para la Comisión de Prácticas Pre Profesionales en la Facultad de
Ingeniería en Informática y Sistemas.
3.4.2. ESPECÍFICOS
Obtener los requisitos de los usuarios atreves de las historias de usuario.
Planificar el desarrollo del software mediante el despliegue de las
historias de usuario en tareas, realizando un plan de entrega.
Analizar los datos, documentos, y demás información histórica que
maneja la Comisión de Prácticas Pre Profesionales.
Diseñar una base de datos relacional y los prototipos de las interfaces.
Construir el software según las tareas planificadas.
Realizar las pruebas funcionales de la aplicación web de Prácticas Pre
Profesionales con los integrantes de la CPPP.
3.5 JUSTIFICACIÓN
Impacto Tecnológico
El desarrollo del software permitirá:
Almacenar toda la información de los usuarios en una base de datos,
permitiéndoles a los usuarios estar actualizados e informados de las prácticas
aceptadas, anuladas, asignación de asesores, informes finales, supervisiones,
sustentaciones, asignación de jurados.
Impacto Social
Alto grado de aceptación por parte de los Miembros de comisión de
prácticas pre profesionales, que contarán con un software que no sólo les permitirá
agilizar sino también coordinar las actividades de registro, búsquedas, seguimientos y
control de fechas, contenidos, ampliaciones, supervisiones, anulaciones de prácticas,
informes finales y sustentaciones, la independencia de la información de las prácticas
pre profesionales, la disminución de la carga laboral y de una mejor forma de trabajo.
Los estudiantes, también se beneficiarán en el sentido de disponer de la información
33
referente a las prácticas pre profesionales, del avance y control de sus actividades, de la
comunicación eficiente con la comisión, con su asesor y con sus jurados.
Impacto Económico
Menores costes en la utilización de materiales para el registro de las
diferentes actividades de la Comisión de prácticas Pre Profesionales.
3.6 APLICACIÓN DEL MODELO DE DESARROLLO EXTREME PROGRAMING (XP)
3.6.1. DESCRIPCIÓN DE LA ACTIVIDAD ASIGNADA.
Esta actividad consistió en aplicar las fases del modelo de desarrollo XP para
la construcción del software de prácticas pre-profesionales. Para la construcción, se
consideró las fases de Planificación, Diseño, Codificación y Pruebas.
3.6.2. ¿POR QUÉ USAR EL MODELO DE DESARROLLO XP PARA LA CONSTRUCCIÓN
DEL SOFTWARE?
Se utilizará el modelo de desarrollo XP debido a las características del
proyecto dado que los requerimientos no se encuentran previamente definidos por el
usuario, además son de naturaleza cambiante. Además se necesitará interactuar con el
usuario a medida que se construya el software, realizando entregables en corto tiempo
para así dar al usuario una idea de cómo funcionará el software.
3.6.3. PRÁCTICAS UTILIZADAS EN EL PROYECTO
a. Planificación incremental: Se realizó mediante la observación directa
los cuales fueron plasmados en historias de los usuarios
retroalimentando la información de manera seguida.
b. Diseño sencillo: Se llevó a cabo el diseño de los formularios necesarios
para cumplir los requerimientos actuales.
c. Desarrollo previamente probado: Se utilizó un sistema de pruebas de
unidad para escribir pruebas para nuevas funcionalidades antes de que
éstas se implementen.
d. Refactorización: se refactorizó el código tan pronto se halló el error
e. Integración continua: Al término de cada día, se integraba el avance
realizado al sistema principal obteniendo un único sistema integral.
f. Programación en parejas: se conformó un grupo de desarrollo en la
Facultad de ingeniería en informática y sistemas, los cuales estuvieron
apoyando activamente, realizando la programación en parejas.
g. Propiedad Colectiva: Los miembros del equipo tienen todo el código
disponible bajo subversión en un repositorio en internet que es
mercurial de google code y el cliente tortoiseHg.
34
FIGURA 09: Cliente TortoiseHg para actualizar el repositorio al termino de los cambios y actualizar los cambios.
FUENTE: cliente tortoiseHg
Estándares de codificación: se manejó la codificación en áreas para
organizar el código y hacer más sencillo en mantenimiento.
FIGURA 10: código en áreas.
FUENTE: IDE Netbean
3.7 FASE1: PLANEACIÓN
En esta fase comprende el análisis para el cual se hizo conversaciones
directas con el Secretario de la Comisión de Prácticas pre profesional y el diseño para la
construcción del software.
3.7.1 EQUIPO DE DESARROLLO:
El equipo XP de desarrollo que ha llevado a cabo este proyecto es el
siguiente: Cuadro 03. Equipo XP
CARGO NOMBRES
ANALISTA – PROGRAMADOR Alberto Lucio, ACEVEDO ALIAGA
ASESOR Ing. Ronald, IBARRA ZAPATA
FUENTE: Elaboración Propia
35
3.7.2 HISTORIAS DE USUARIO:
Tras el diálogo con el Secretario de la comisión de Practicas Pre
Profesionales, se logró identificar requisitos iniciales para el desarrollo de las historias
de usuario, a continuación se detalla en el cuadro 04: Cuadro 04. Requisitos iniciales
N DESCRIPCIÓN
R1 Para acceder al sistema cada usuario deberá contar con un nombre de usuario el tipo de comisión, una contraseña registrados en el sistema.
R2 El sistema debe ser capaz de registrar una comisión anualmente con el tipo de comisión.
R3 El Sistema debe ser capaz de registrar a los integrantes de cada comisión, esto anualmente.
R4 El Sistema debe ser capaz de registrar a usuarios con roles de alumno y comisión.
R5 Cada medio año el sistema debe actualizar los datos de los alumnos otorgados por OCDA (Oficina de Coordinación Académica)-UNAS.
R6 Cada medio año el sistema debe actualizar los datos de los docentes otorgados por OCDA (Oficina de Coordinación Académica)-UNAS.
R7 El Sistema debe registrar a los practicantes con 160 créditos aprobados, por tres meses como mínimo.
R8 El sistema debe registrar la organización y el área de labor del practicante.
R9 El sistema debe registrar los proyectos de cada practicante.
R10 El sistema debe registrar las actividades desempeñadas por el practicante.
R11 El Sistema debe registrar asesores a los practicantes registrados.
R12 El sistema debe generar un formato de oficio digital y enviar al correo de secretaria del decano y al docente asignado como asesor, con los datos de la práctica registrada, conjuntamente con un formato de resolución para la firma del decano.
R13 El Sistema debe asignar supervisiones a los practicantes hasta por dos veces
R14 El Sistema debe registrar proyectos que los practicantes van a realizar
R15 El Sistema debe registrar los informes al cabo de la finalización de practicas
R16 El Sistema debe registrar sustentaciones después de presentar informe.
R17 El sistema debe asignar 4 jurados que serán docentes para una sustentación
R18 El sistema debe generar un formato de oficio digital y enviar al correo de secretaria del decano y al docente asignado como jurado, con los datos de la sustentación, conjuntamente con un formato de resolución para la firma del decano.
R19 El sistema debe ampliar las prácticas si así se solicitara a la comisión.
R20 El sistema debe ampliar la sustentación en casos de falta de tiempo.
R21 El sistema debe registrar una nueva sustentación por desaprobación.
R22 El Sistema debe emitir reportes de los practicantes y su historial.
R23 El Sistema debe emitir reportes de los asesores.
R24 El Sistema debe emitir reportes de supervisiones.
R25 El Sistema debe emitir reportes jurados.
R26 El Sistema debe emitir reportes documentos de gestión
R27 El Sistema debe emitir reportes de sustentaciones
R28 El sistema debe tener una biblioteca digital con los informes de prácticas aprobadas
FUENTE: Elaboración Propia.
36
Los usuarios involucrados en el desarrollo del proyecto se detallan en el
cuadro 05: Cuadro 05. Clientes del proyecto
Cargo Nombre Seudónimo
Presidente William Marchand Usuario CPPP
Secretario George Paucar Usuario CPPP
Vocal Wilmer Bermúdez Usuario CPPP
Equipo XP Alberto Acevedo Administrador CPPP
FUENTE: Elaboración Propia.
Los privilegios asignados a los usuarios se detallan en el cuadro 06: Cuadro 06. Privilegios de los Usuarios
Tipos de Usuario PPP Privilegios
Miembro CPPP Altos
Alumno CPPP Bajos
Administradores CPPP Altos
FUENTE: Elaboración Propia
En base al cuadro 04, se procede a recolectar las historias de usuario por
cada requisito inicial, en conversación directa con el usuario, en este caso
explícitamente, con el secretario de la comisión explicándole que cada historia o
requisito tiene puntos de valor en una escala de 1-5, esto es cuan significante es para el
requisito.
Se dedicó 22 días a la recolección de los requisitos, puesto que los miembros
de la comisión no cuentan con el tiempo necesario para poder agilizar el procedimiento.
A continuación se muestra el formato que se utilizó para la recolección de historias de
usuario. Para ver todas las historias ver ANEXO 02.
Cuadro 07. Historia “ingresando al Sistema”
FUENTE: Elaboración Propia
Historia de usuario
Rol : Secretario CPPP
Nombre historia: Ingresando al sistema (Autentificación)
Puntos de valor: 2
Descripción: yo como secretario de la comisión deseo ingresar al sistema para
realizar mis actividades, el sistema debe pedirme al inicio ingresar con mi
nombre, contraseña, tipo de usuario y comisión.
Observaciones: los tipos de usuario son miembro de la comisión, alumno y
administrador.
37
El formato de las historias de usuario en realidad se maneja de diferentes
formas según bibliografías consultadas, para este caso se decidió seguir este formato
personalizado por darnos un mejor alcance a los requisitos que se quiere definir.
En el rol se define el papel del usuario que define la historia, seguido por el
nombre de la historia además el usuario valora en cuanto por ciento del total es
importante este requisito para él, definido como puntos de valor, en los adjuntos se
hace referencia a documentos, formatos, fichas entre otras que nos pudiese servir para
entender mejor el requisito, finalizando con observaciones que vendrían a ser algunas
excepciones y comentarios.
Una vez planteadas las historias de usuario iníciales, se procede a desarrollar
el sistema, que se explica más adelante con más detalle, una vez desarrollado se pasa a
una evaluación del sistema según las historias de usuario, el cual también tuvo un
formato para la documentación de las observaciones en cuestión de modificaciones al
sistema según los establecido en el análisis de los requerimientos.
38
3.7.3 ESTIMACIÓN DE ESFUERZO ASOCIADOS A LAS HISTORIAS DE USUARIOS Cuadro 08. Historia “Estimaciones de esfuerzo asociadas a las historias de usuario”
FUENTE: Elaboración Propia.
N° HISTORIAS DE USUARIO ESFUERZO
(Horas) FECHA INICIO / FECHA FIN
H1. Ingresando al sistema
(Autentificación) 7 07-10-2013 / 08-10-2013
H2. Registrando una comisión 7 08-10-2013 / 10-10-2013
H3. Registrando integrantes 7 10-10-2013 / 12-10-2013
H4. Registrando usuarios 7 12-10-2013 / 15-10-2013
H5. Registrando practicantes 7 15-10-2013 / 17-10-2013
H6. Registrando Empresas 8 17-10-2013 / 18-10-2013
H7. Registrando Proyecto de práctica. 7 19-10-2013 / 21-10-2013
H8. Registrando Actividades del
Practicante 8 23-10-2013 / 23-10-2013
H9. Registrando asesores 7 24-10-2013 / 26-10-2013
H10 Generando oficio de Asignación de
Asesores. 6 26-10-2013 / 29-10-2013
H11. Registrando supervisiones 7 28-30-2013 / 30-10-2013
H12. Registrar ampliación de prácticas. 7 30-11-2013 / 01-11-2013
H13. Registrando informes 7 01-11-2013 / 04-11-2013
H14. Registrando sustentaciones 7 04-11-2013 / 06-11-2013
H15. Registrando jurados 7 06-11-2013 / 08-11-2013
H16. Generando oficio de Asignación de
Jurados. 7 08-11-2013 / 11-11-2013
H17. Registrando informes digitales finales
aprobados. 7 11-11-2013 / 12-11-2013
H18. Reportando practicantes. 6 13-11-2013 / 19-11-2013
H19. Reportando historial de practicantes. 6 15-11-2013 / 21-11-2013
H20. Reportando ranking de asesores. 6 18-11-2013 / 23-11-2013
H21. Reportando documento para
supervisiones. 6 20-11-2013 / 24-11-2013
H22. Reportando ranking de jurados. 6 21-11-2013 / 23-11-2013
H23. Reporte para doc. De Gestión. 6 23-11-2013 / 25-11-2013
H24. Reportando sustentaciones. 6 25-11-2013 / 26-11-2013
H25 Realizar Repositorio Digital 4 02-12-2013/03-12-2013
H26 Consumir datos de OCDA 10 03-12-2013/07-12-2013
39
3.7.4 PLAN DE ENTREGA
Cuadro 09. “Prioridades, riesgo, esfuerzo e interacciones”
FUENTE: Elaboración Propia.
LEYENDA
P= Prioridad.
R= Riesgo
E= Esfuerzo (en Horas)
I= Iteración
N° Nombre Historia de Usuario P R E I
H1. Ingresando al sistema (Autentificación) Alta Alta 7 1
H2. Registrando una comisión Alta Alta 7 1
H3. Registrando integrantes Alta Alta 7 1
H4. Registrando usuarios Alta Alta 7 1
H5. Registrando practicantes Alta Alta 7 1
H6. Registrando empresas Alta Media 8 1
H7. Registrando proyecto de práctica. Alta Media 7 1
H8. Registrando actividades del practicante Alta Media 8 1
H9. Registrando asesores Alta Media 7 2
H10. Generando oficio de asignación de asesores. Media Media 6 2
H11. Registrando supervisiones Media Media 7 2
H12. Registrar ampliación de prácticas. Alta Media 7 2
H13. Registrando informes Alta Media 7 2
H14. Registrando sustentaciones Alta Media 7 2
H15. Registrando jurados Media Media 7 2
H16. Generando oficio de Asignación de Jurados. Alta Media 7 2
H17. Registrando informes digitales finales
aprobados.
Alta Media 7
2
H18. Reportando practicantes. Media Media 6 3
H19. Reportando historial de practicantes. Media Media 6 3
H20. Reportando ranking de asesores. Media Media 6 3
H21. Reportando documento para supervisiones. Media Media 6 3
H22. Reportando ranking de jurados. Media Media 6 3
H23. Reporte para doc. De Gestión. Media Media 6 3
H24. Reportando sustentaciones. Media Media 6 3
H25. Generando Repositorio Digital Media Baja 4 4
H26. Consumir datos de OCDA Media Media 10 4
40
3.7.5 ANÁLISIS DE REQUISITOS MEDIANTE DIAGRAMAS DE PROCESOS
Para el entendimiento y concepción de los requisitos se procese a realizar
diagramas de proceso de negocio (BPMN) para el cual se utilizó el software Bizagi
Process Modeler, tomando como referencia el ANEXO 08.
El proceso de la FIGURA 11. Muestra cómo se designa a los miembros de la
comisión; cuenta con participantes como el decano, consejo de facultad y la comisión de
prácticas pre profesionales, en las que el decano propone a la comisión y el consejo de
facultad es el encargado de ratificar para emitir su resolución, caso contrario se volverá
a proponer una comisión:
FIGURA 11: “Designación De La Comisión De Practicas Pre Profesionales”
FUENTE: Software Bizagi Process Modeler
El proceso de la FIGURA 12. Muestra como es el trámite del alumno para
realizar la gestión de su práctica pre profesional, para ello inicia realizando la solicitud a
decanatura para la emisión de carta de presentación, si el practicante es aceptado por la
institución procede a enviar a decanatura los requisitos para realizar prácticas y estas
son derivadas a la comisión para su evaluación y aceptación correspondiente.
FIGURA 12: “Tramite Para Realizar Prácticas Pre Profesionales”
FUENTE: Software Bizagi Process Modeler
41
El proceso de la FIGURA 13. Inicia en la comisión de PPP, asignando un
supervisor para la inspección a las actividades del practicante, al finalizar el supervisor
debe emitir un informe con la visita realizada.
FIGURA 13: “Supervisión de la practicas pre profesionales”
FUENTE: Software Bizagi Process Modeler
El proceso de la FIGURA 14. Inicia con la solicitud de ampliación del
practicante, hacia la empresa, y esta evalúa la petición emitiendo una carta mediante el
practicante a la comisión para su dictamen final.
FIGURA 14: “Ampliación de las practicas pre profesionales”
FUENTE: Software Bizagi Process Modeler
42
El proceso de la FIGURA 15. Muestra la recepción para el informe final, la
comisión debe evaluar si el informe recepcionado, está dentro del plazo máximo de un
mes, después de las prácticas finalizadas, si cumple el requisito el practicante presenta 4
ejemplares a la decanatura para su derivación a la CPPP y distribución a los jurados.
FIGURA 15: “Entrega del informe final”
FUENTE: Software Bizagi Process Modeler
El proceso de la FIGURA 16. Muestra la asignación de jurados, la decanatura
envía el informe de prácticas a la comisión y esta asigna a los jurados mediante un oficio
a decanatura para su revalidación con resolución por parte de esta última.
FIGURA 16: “Asignación de jurados”
FUENTE: Software Bizagi Process Modeler
43
El proceso de la FIGURA 17. Inicia con la publicación del cronograma por
parte de la CPPP y si es necesario, por la cantidad del volumen del informe, se amplía a
una nueva fecha, sino se sigue la sustentación para su evaluación.
FIGURA 17: “Sustentación de prácticas pre profesionales”
FUENTE: Software Bizagi Process Modeler
El proceso de la FIGURA 18. La institución donde se realiza las practicas
emite una ficha de evaluación o certificado para la entrega a los jurados, el jurado inicia
la evaluación y el practicante recepciona las observaciones para la corrección de su
informe, firmando el acta , caso de no haber observaciones se firma el acta y la comisión
la recepciona para su registro.
FIGURA 18: “Evaluación de sustentación”
FUENTE: Software Bizagi Process Modeler
44
3.7.6 DIAGRAMA DE CLASES
Un diagrama de clases es un tipo de diagrama estático que describe la
estructura de un sistema mostrando sus clases, orientados a objetos.
De acuerdo con la recolección de información sobre el proceso de prácticas
pre profesionales se procedió al diseño del diagrama de clases se realizó usando la
herramienta Rational Rosse 7, tal se muestra en la FIGURA 19.
46
3.8 FASE 2: DISEÑO|
3.8.1 ARQUITECTURA DEL SISTEMA
Se muestra la arquitectura del sistema mediante un diagrama de Despliegue
es un tipo de diagrama del Lenguaje Unificado de Modelado que se utiliza para modelar
el hardware utilizado en las implementaciones de sistemas y las relaciones entre sus
componentes.
FIGURA 20: “Diagrama de despliegue”
<<device>>ApplicationServer
<<device>>DataBaseServer
<<device>>HttpClient
<<executionEnviroment>>GlashFish 3.2.1
WebBrowser
<<executionEviroment>>Postgre 9.2
spppSchema
spppServices.jar
spppModel.jar
spppController.jar
spppWebPages.jar
spppDao.jar
<<device>>OCDA_DataBaseServer
<<executionEnviroment>>Postgre 9.2
AcademicDB
<<executionEviroment>>GlassFish Server 3.1.2
IntegrationWebService WSDL
spppDaemon
FUENTE: Elaborado en Software Microsoft Visio 2013
47
En el diagrama nos muestra el cliente desde un navegador y el acceso a los
paquetes dentro del servidor web (Glassfish 3.1.2) y como este servidor está
relacionado con la base de datos interna (Postgres 9.2) y otra desde OCDA mediante
Servicios Web.
3.8.2 DIAGRAMA DE ENTIDAD RELACIÓN
El esquema que se presenta en la FIGURA 21, se obtuvo del análisis previo
que se hizo en la FIGURA 19, este esquema es el denominado Entidad Relación, la que
muestra las relaciones entre las entidades, las tablas de color naranja son las
correspondientes a la Comisión De Prácticas Pre Profesionales, las tablas verdes
pertenecen a la Comisión De Grados Y Títulos, mientras que las celestes son las tablas
comunes para todos los sistemas integrados en la base de datos denominada BDFIIS.
49
3.8.3 DICCIONARIO DE DATOS
En el Figura 19 se muestra la relación de Tablas, se hará un breve
comentario sobre la finalidad de cada tabla dentro de nuestra Base de Datos.
CUADRO 10: “Tabla Estado”
Descripción: Registra los estados de las diferentes entidades durante los
procesos, de acuerdo a las comisiones que a la que pertenece.
State
Nombre Tipo Descripción
id int4 Llave primaria, no nulo y auto incremental. name varchar(50) Nombre de estados, comisión (modificado,
ratificado).
name_entity varchar(25) Nombre de la entidad a la que corresponde el estado.
detail varchar(300) Detalle de los estados. Fuente: Elaboración propia.
3.9 FASE3: CONSTRUCCIÓN
3.9.1 PROTOTIPOS GENERALES PARA EL DISEÑO Y CONSTRUCCIÓN
Previo a empezar la fase 3, se hará prototipos generales de diseño para la
construcción de las interfaces, puesto que el desarrollo se está haciendo con el api de
primer faces, no es necesario pensar tanto en el diseño más si corresponde a una
definición general y las especificaciones a tomar en cuenta en cada tarea ya que
además, por buenas prácticas de diseño, se debe hacer uso del menor número de
interfaces posibles, estandarizando y organizando las interfaces para las operaciones de
negocio.
Para todas la interfaces se tendrá el siguiente esquema.
Un título General en el encabezado.
Un menú general en la parte izquierda de la pantalla.
Un espacio en el centro, donde se muestre todas las interfaces de
usuario. FIGURA 22: “esquema de interfaz”
FUENTE: Software Pencil (para diseño)
50
Para el ingreso al sistema según la figura 23: FIGURA 23: “esquema de acceso al sistema”
FUENTE: Software Pencil (para diseño)
Para el registro en el sistema según la figura 24: FIGURA 24: “esquema de acceso al sistema”
FUENTE: Software Pencil (para diseño)
Para las vistas y listados según la figura 25:
FIGURA 25: “Diseño de vistas y listados”
FUENTE: Software Pencil (para diseño)
51
Para los procesos de practicantes según la figura 26: FIGURA 26: “diseño para los procesos del practicante”
FUENTE: Software Pencil (para diseño)
3.9.2 PRIMERA ITERACCIÓN
Las historias realizadas en esta iteración son las siguientes:
Ingresando al sistema (Autentificación)
Registrando una comisión
Registrando integrantes
Registrando usuarios
Registrando practicantes
Registrando Empresas
Registrando Proyecto de práctica.
Registrando Actividades del Practicante
Para llevar a cabo el desarrollo de la primera iteración, se desglosó a las
historias de usuario, esto permitirá que el desarrollo se lleve a cabo de manera
incremental asegurando la implementación de la historia.
Las tareas tienen el siguiente formato:
CUADRO 11: “Diseño de la interfaz de acceso al sistema”
Tarea
Nombre Historia: Ingresando al Sistema
Nombre tarea: Diseño de la interfaz de acceso al sistema
Tipo de tarea: Diseñar Esfuerzo(Hora): 1
Fecha inicio: 07/10/13 Fecha fin: 07/10/13
Programador responsable: Equipo XP
Descripción: la interfaz debe tener dos cajas de texto, para el nombre de usuario
y contraseña, un botón de ingreso, siendo todo la ventana de acceso un modal o
ventana emergente.
Fuente: Elaboración propia
Para más detalle de las tareas de usuario VER ANEXO 03.
52
FIGURA 16: “Cuadro de actividades para iteración 1”
FUENTE: Elaboración en MS Project 2013
Como se muestra en la figura 16. El desarrollo se dio en 58 horas durante 15
días, con un trabajo de programación diaria de aproximadamente 3.86 horas diarias.
Resultados:
Figura 17. Formulario de acceso al sistema.
Figura 18. Interfaz de administración (registro de nueva comisión)
53
Figura 19. Formulario de Registro de prácticas.
En la Figura 17, 18,19, el cumplimiento de las tareas e historias de usuario.
3.9.3. SEGUNDA ITERACCIÓN
Las tareas realizadas en esta iteración son las siguientes:
Registrando asesores
Generando oficio de Asignación de Asesores.
Registrando supervisiones
Registrando informes
Registrando sustentaciones
Registrando jurados
Generando oficio de Asignación de Jurados.
Registrar ampliación de prácticas.
Registrar Registrando informes digitales finales aprobados.
Para llevar a cabo el desarrollo de la primera iteración, se desglosó a las
historias de usuario, esto permitirá que el desarrollo se lleve a cabo de manera
incremental asegurando la implementación de la historia.
Las tareas tienen el siguiente formato:
54
CUADRO 12: “Diseño de la interfaz del registro de Asesores”
Tarea
Nombre Historia: Registrando Asesores
Nombre tarea: Diseño de la interfaz del registro de Asesores
Tipo de tarea: Diseñar Esfuerzo(Hora): 1
Fecha inicio: 24/10/13 Fecha fin: 24/10/13
Programador responsable: Equipo XP
Descripción: la ventana tendrá un caja de opciones para los docentes con
opciones de búsqueda, la fecha de asignación y un campo con mascara para el
numero de oficio.
Fuente: Elaboración propia
Para más detalle de las tareas de usuario VER ANEXO 03.
FIGURA 20: “Cuadro de actividades para iteración 2”
FUENTE: Elaboración en MS Project 2013
Como se muestra en la figura 20. El desarrollo se dio en 62 horas durante 17
días, con un trabajo de programación diaria de aproximadamente 3.64 horas diarias.
Resultados:
Figura 21. Formulario de registro de asesor.
55
Figura 22. Interfaz de administración (registro de nueva comisión)
Figura 23. Formulario de Registro de asignación de jurados y las validaciones.
3.9.4. TERCERA ITERACCIÓN
Las historias realizadas en esta iteración son las siguientes:
Reportando practicantes.
Reportando historial de practicantes.
Reportando ranking de asesores.
Reportando documento para supervisiones.
Reportando ranking de jurados.
Reporte para los documentos de Gestión.
Reportando sustentaciones.
56
Para llevar a cabo el desarrollo de la primera iteración, se desglosó a las
historias de usuario, esto permitirá que el desarrollo se lleve a cabo de manera
incremental asegurando la implementación de la historia.
Las tareas tienen el siguiente formato:
CUADRO 13: “Diseño de la interfaz de la Generación de Reporte de los Practicantes”
Tarea
Nombre historia: Reportando Practicantes
Nombre tarea: Diseño de la interfaz de la Generación de Reporte de los Practicantes
Tipo de tarea: Diseñar Esfuerzo(horas): 2.5
Fecha inicio: 13/11/13 Fecha fin: 13/11/13
Programador responsable: Equipo XP
Descripción: el reporte debe tener un encabezado con el nombre de la comisión y Facultad, debe mostrar en una grilla los detalles como nombres, asesor, fecha inicio prácticas, fecha final de prácticas.
Fuente: Elaboración propia
Para más detalle de las tareas de usuario VER ANEXO 03.
FIGURA 24: “Cuadro de actividades para iteración 3”
FUENTE: Elaboración en MS Project 2013
Como se muestra en la Figura 24. El desarrollo de la tercera iteración se dio
en 42 horas durante 12 días, con un trabajo de programación diaria de
aproximadamente 2.47 horas diarias.
57
Resultados:
Figura 25: Diseño de los reportes en Ireport5.
Figura 26: Interfaz de los reportes con parámetros mediante modales
58
Figura 27: Salida de los reportes en formato pdf.
3.9.5. CUARTA ITERACCIÓN
Las historias realizadas en esta historia son las siguientes
Generar repositorio digital.
Consumir datos de OCDA.
Para llevar a cabo el desarrollo de la primera iteración, se desglosó a las
historias de usuario, esto permitirá que el desarrollo se lleve a cabo de manera
incremental asegurando la implementación de la historia.
Las tareas tienen el siguiente formato:
CUADRO 14: “Diseño de la interfaz de la Generación de Reporte de los Practicantes”
Tarea
Nombre historia: Reportando Practicantes
Nombre tarea: Diseño de la interfaz de la Generación de Reporte de los
Practicantes
Tipo de tarea: Diseñar Esfuerzo(horas): 2.5
Fecha inicio: 13/11/13 Fecha fin: 13/11/13
Programador responsable: Equipo XP
Descripción: el reporte debe tener un encabezado con el nombre de la comisión y
Facultad, debe mostrar en una grilla los detalles como nombres, asesor, fecha
inicio prácticas, fecha final de prácticas.
Fuente: Elaboración propia
59
Para más detalle de las tareas de usuario VER ANEXO 03.
FIGURA 28: “Cuadro de actividades para iteración 4”
FUENTE: Elaboración en MS Project 2013
Como se muestra en la Figura 28. El desarrollo de la cuarta iteración se dio
en 14 horas durante 4 días, con un trabajo de programación diaria de aproximadamente
3.5 horas diarias.
Resultados:
Figura 29: Interfaz del repositorio Digital de los informes de PPP.
60
Figura 30: Interfaz que busca los datos en Ocda.
Figura 31: Datos de Ocda retornados con éxito.
3.9.6. DIARIO DE ACTIVIDADES: CUADRO 16: “Diario de Actividades”
Fecha (Día/Mes/Año)
Actividad realizada Tiempo (horas)
Observaciones
21/08/13 Fase de comunicación con el secretario de la CPPP(Entrevista directa)
1.5 Planteamientos de desarrollo de software
22/08/13 Levantamiento y revisión del sistema de prácticas pre-profesionales v1.0 (2010)
30 Desarrollado en PHP y Mysql, limitados a Internet Explorer, código desordenado, sin ningún framework de desarrollo, desactualizado en cuanto al nuevo reglamento de PPP 2012.
28/08/13 Consultas a docentes de la especialidad(Ing. Ronald Ibarra, Ing. Brian Soto)
5 Propuestas de desarrollo de software – lineamientos de desarrollo de software según CTIC-UNAS.
61
Fecha (Día/Mes/Año)
Actividad realizada Tiempo (horas)
Observaciones
02/09/13 Reunión con el secretario de la CPPP
1 Definición y alcance del proyecto de prácticas pre profesionales.
03/09/13 Exploración de actividades de la comisión.
4 Familiarización con las actividades de la CPPP
04/09/13 Revisión de los materiales utilizados por la CPPP
5 Reconocimiento de documentos, libros de acta, reglamento 2012.
06/09/13 Recolección de historias de usuarios
15 Entrevistas observaciones y análisis documental.
16/09/13 Modelado BPMN, para el correcto enfoque de las historias a los procesos de negocio.
5 Uso de software BPMN Bizagi Process Modeler.
17/09/13 Reunión con el secretario de la CPPP
1 Definición de las actividades de las P.P.P
18/09/13 Diseño del diagrama de clases 7 Uso de la Herramiento Rational Rosse
23/09/13 Diseño de la base de datos 5 Diseño de diagrama de entidad relación en MicroOLAP for Postgres.
24/09/13 Reunión con el secretario de la CPPP
1 Recomendaciones sobre la base de datos
25/09/13 Rediseño de la base de datos 3 Recreación de la base de datos
26/09/13 Diseño del diagrama de arquitectura
4 Uso de la herramiento Visio 2010
27/09/13 Definición de las historias de usuario
4 Apoyo del secretario de la CPPP.
30/09/13 Definición des iteraciones 3 Establecimiento de las historias de usuario por iteración
07/10/13
Desarrollo de la historia “Ingresando al sistema (Autentificación)”.
7 Diseño, codificación y validación.
08/10/13 Revisión la historia “Ingresando al sistema (Autentificación)”.
0.5 Revisión de la funcionalidad
08/10/13 Corrección de errores detectados 0.5 Validando la historia de usuario
08/10/13 Desarrollo de la historia “Registrando una comisión”.
7 Diseño, codificación y validación.
10/10/13 Revisión de la historia “Registrando una comisión”.
0.5 Revisión de la funcionalidad
10/10/13 Corrección de errores detectados. 0.5 Validando la historia de usuario
62
Fecha (Día/Mes/Año)
Actividad realizada Tiempo (horas)
Observaciones
10/10/13 Desarrollo de la historia “Registrando integrantes”.
7 Diseño, codificación y validación.
12/10/13 Revisión de la historia “Registrando integrantes”.
0.5 Revisión de la funcionalidad
12/10/13 Corrección de errores destacados 0.5 Validando la historia de usuario
12/10/13 Desarrollo de la historia “Registrando usuarios”.
7 Diseño, codificación y validación.
15/09/13 Revisión de la historia “Registrando usuarios”.
0.5 Revisión de la funcionalidad
15/09/13 Corrección de errores destacados 0.5 Validando la historia de usuario
15/09/13 Desarrollo de la historia “Registrando practicantes”.
7 Diseño, codificación y validación.
17/10/13 Revisión de la historia “Registrando practicantes”.
0.5 Revisión de la funcionalidad
17/10/13 Corrección de errores destacados 0.5 Validando la historia de usuario
17/10/13 Desarrollo de la historia “Registrando Empresas”.
8 Diseño, codificación y validación.
18/10/13 Revisión de la historia “Registrando Empresas”.
0.5 Revisión de la funcionalidad
18/10/13 Corrección de errores destacados 0.5 Validando la historia de usuario
19/10/13 Desarrollo de la historia “Registrando Proyecto de práctica”.
7 Diseño, codificación y validación.
21/10/13 Revisión de la historia “Registrando Proyecto de práctica”.
0.5 Revisión de la funcionalidad
21/10/13 Corrección de errores destacados 0.5 Validando la historia de usuario
21/10/13 Desarrollo de la historia “Registrando Actividades del Practicante”.
8 Diseño, codificación y validación.
23/10/13 Revisión de la historia “Registrando Actividades del Practicante”.
0.5 Revisión de la funcionalidad
23/10/13 Corrección de errores destacados 0.5 Validando la historia de usuario
24/10/13 Desarrollo de la historia “Registrando asesores”.
7 Diseño, codificación y validación.
26/10/13 Revisión de la historia “Registrando asesores”
0.5 Revisión de la funcionalidad
63
Fecha (Día/Mes/Año)
Actividad realizada Tiempo (horas)
Observaciones
26/10/13 Corrección de errores destacados 0.5 Validando la historia de usuario
26/10/13 Desarrollo de la historia “Generando oficio de Asignación de Asesores”.
6 Diseño, codificación y validación.
28/10/13
Revisión de la historia “Generando oficio de Asignación de Asesores”.
0.5 Revisión de la funcionalidad
28/10/13 Corrección de errores destacados 0.5 Validando la historia de usuario
28/10/13 Desarrollo de la historia “Registrando supervisiones”.
7 Diseño, codificación y validación.
30/10/13 Revisión de la historia “Registrando supervisiones”.
0.5 Revisión de la funcionalidad
30/10/13 Corrección de errores destacados 0.5 Validando la historia de usuario
30/10/13 Desarrollo de la historia “Registrando informes”.
7 Diseño, codificación y validación.
01/11/13
Revisión de la historia “Registrando informes”.
0.5 Revisión de la funcionalidad
01/11/13 Corrección de errores destacados 0.5 Validando la historia de usuario
01/11/13 Desarrollo de la historia “Registrando sustentaciones”.
7 Diseño, codificación y validación.
04/11/13 Revisión de la historia “Registrando sustentaciones”.
0.5 Revisión de la funcionalidad
04/11/13 Corrección de errores destacados 0.5 Validando la historia de usuario
04/11/13 Desarrollo de la historia “Registrando jurados”.
7 Diseño, codificación y validación.
06/11/13 Revisión de la historia “Registrando jurados”.
0.5 Revisión de la funcionalidad
06/11/13 Corrección de errores destacados 0.5 Validando la historia de usuario
06/11/13 Desarrollo de la historia “Generando oficio de Asignación de Jurados”.
6 Diseño, codificación y validación.
08/11/13 Revisión de la historia “Generando oficio de Asignación de Jurados”.
0.5 Revisión de la funcionalidad
08/11/13 Corrección de errores destacados 0.5 Validando la historia de usuario
08/11/13 Desarrollo de la historia “Registrar ampliación de
7 Diseño, codificación y validación.
64
Fecha (Día/Mes/Año)
Actividad realizada Tiempo (horas)
Observaciones
prácticas”.
11/11/13 Revisión de la historia “Registrar ampliación de prácticas”.
0.5 Revisión de la funcionalidad
11/11/13 Corrección de errores destacados 0.5 Validando la historia de usuario
11/11/13 Desarrollo de la historia “Registrar informes finales aprobados”.
7 Diseño, codificación y validación.
12/11/13 Revisión de la historia “Registrar informes finales aprobados digitales”.
0.5 Revisión de la funcionalidad
12/11/13 Corrección de errores destacados 0.5 Validando la historia de usuario
13/11/13 Desarrollo de la historia “Reportando practicantes”.
6 Diseño, codificación y validación.
15/11/13 Revisión de la historia “Reportando practicantes”.
0.5 Revisión de la funcionalidad
15/11/13 Corrección de errores destacados 0.5 Validando la historia de usuario
15/11/13 Desarrollo de la historia “Reportando historial de practicantes”.
6 Diseño, codificación y validación.
18/11/13 Revisión de la historia “Reportando historial de practicantes”.
0.5 Revisión de la funcionalidad
18/11/13 Corrección de errores destacados 0.5 Validando la historia de usuario
18/11/13 Desarrollo de la historia “Reportando ranking de asesores”.
6 Diseño, codificación y validación.
20/11/13 Revisión de la historia “Reportando ranking de asesores”.
0.5 Revisión de la funcionalidad
20/11/13 Corrección de errores destacados 0.5 Validando la historia de usuario
20/11/13 Desarrollo de la historia “Reportando documento para supervisiones”.
6 Diseño, codificación y validación.
21/11/13 Revisión de la historia “Reportando documento para supervisiones”.
0.5 Revisión de la funcionalidad
21/11/13 Corrección de errores destacados 0.5 Validando la historia de usuario
22/11/13 Desarrollo de la historia 6 Diseño, codificación y
65
Fecha (Día/Mes/Año)
Actividad realizada Tiempo (horas)
Observaciones
“Reportando ranking de jurados”. validación.
23/11/13 Revisión de la historia “Reportando ranking de jurados”.
0.5 Revisión de la funcionalidad
23/11/13 Corrección de errores destacados 0.5 Validando la historia de usuario
23/11/13 Desarrollo de la historia “Reporte para Doc. De Gestión”.
6 Diseño, codificación y validación.
24/11/13 Revisión de la historia “Reporte para Doc. De Gestión”.
0.5 Revisión de la funcionalidad
24/11/13 Corrección de errores destacados 0.5 Validando la historia de usuario
25/11/13 Desarrollo de la historia “Reportando sustentaciones”.
6 Diseño, codificación y validación.
26/11/13 Revisión de la historia “Reportando sustentaciones”.
0.5 Revisión de la funcionalidad
26/11/13 Corrección de errores destacados 0.5 Validando la historia de usuario
30/11/13 Generando un repositorio Digital 4 Diseño, codificación y validación.
03/12/13 Revisión de Generando un repositorio Digital
0.5 Revisión de la funcionalidad
03/12/13 Corrección de errores de Generando un repositorio Digital
0.5 Validando la historia de usuario
03/12/13 Desarrollo de la historia “Consumir datos de OCDA”.
10 Diseño, codificación y validación.
06/12/13 Revisión de la historia “Consumir datos de OCDA”.
0.5 Revisión de la funcionalidad
06/12/13 Corrección de errores destacados 0.5 Validando la historia de usuario
06/12/13 Revisión general de la funcionalidad del sistema
10 Prueba finales a cargo del presidente de la CPPP
Reunión del equipo XP 1 Coordinación de las actividades adicionales
11/12/13 Entrega final del proyecto 0 Entrega del informe final Fuente: Elaboración propia
66
3.10 FASE4: PRUEBAS
Las pruebas funcionales que se realizaron a la aplicación se encuentran
separados por cada historia de usuario, se especifica el modo de utilización de la
aplicación y los posibles estados de error que pueden darse, así como los mensajes de
aviso/error/confirmación que debe emitir la aplicación en estos casos.
Participantes:
Para las pruebas funcionales se contó con el apoyo de del equipo de
estudiantes de desarrollo de software de la FIIS – UNAS, “TIMI world” conformado por
Cóndor Fernandez,Diccson
Muños Villalobos, José Derlin
Malpartida Arévalo, Nigel
Entorno:
Se desarrolló las pruebas en una máquina servidor de prueba (con ip
192.168.1.224), en el cual se armó una pequeña red LAN, para las pruebas por parte de
los participantes.
Participantes:
Formato:
El formato que se utilizó para las pruebas, fue tomado de una tesis de grado
“MODELO DE DESARROLLO AGIL”- Schenone Marcelo Hernán -2004, la cual se trató de
adecuar a las historias de usuario. Y quedo definida como se muestra en el cuadro 17.
CUADRO 17: “Diario de Actividades”
Historia Introducción
correcta
Condición de
ejecución
Entrada Resultado
esperado
Conformidad
(C)
Fuente: “MODELO DE DESARROLLO AGIL”- Schenone Marcelo Hernán -2004
El tiempo de pruebas que se realizo fue de 10 horas durante 3 días. A
continuación se muestra el resultado del trabajo realizado.
Figura 32: Pruebas de funcionalidad.
Fuente: Imagen tomada en el entorno de prueba
67
CUADRO 18: PRUEBA DE LA PRIMERA ITERACCIÓN
HISTORIA
INTRODUCCION CORRECTA CONDICIÓN DE EJECUCIÓN
ENTRADA RESULTADO ESPERADO C
H1. El usuario debe ingresar los campos de usuario, contraseña, eligiendo su tipo de comisión y dar clic en el botón ingresar.
Conexión del sistema a la base de datos PostgreSQL
La interfaz de acceso al sistema contiene dos campos de texto, uno para el Nombre del Usuario y el otro para la Contraseña y un botón Entrar.
Si el usuario se identifica con éxito la aplicación ingresará al menú principal, contrario debe aparecer mensaje de error “datos incorrectos vuelva a intentar por favor”
H2. El usuario administrador debe ingresar la fecha de inicio y final de la gestión de la comisión, cuidando que la fecha final sea mayor que la fecha inicial por un año. El número de resolución debe ser la misma con la que se creó la comisión por disposición del decano. El motivo de la creación no es obligatorio. Una vez llenado los campos hacer clic en el botón Guardar.
Conexión del sistema a la base de datos PostgreSQL
La interfaz tiene cuatro campos, un botón Guardar y otro para cancelar. El usuario administrador ingresará la fecha de inicio y fin de la gestión, el número de la resolución de su creación y el motivo por el cual fue creado (este último es opcional). Luego hacer clic el botón Guardar para registrar la comisión.
Si los datos son ingresados son correctos el sistema mostrará un mensaje de éxito indicando “Gestión guardado con éxito” y en caso contrario mostrará un mensaje de alerta indicando “Introducir los datos que faltan”
H3. El usuario Administrador debe seleccionar el grado e ingresar el nombre del nuevo integrante, para cada cargo. Una vez llenado los campos presionar en el botón Guardar.
Conexión del sistema a la base de datos PostgreSQL
La interfaz tiene 4 campos de texto autocompletables con búsqueda, y unas opciones para elegir el grado, luego debe hacer clic en guardar.
Si los datos ingresados por el usuario Administrador son correctos el sistema mostrará un mensaje de éxito indicando “Guardado con éxito” y en caso contrario mostrará un mensaje de alerta indicando “Error de validación”.
68
H4. El nombre y contraseña del usuario es autogenerado con tan solo buscar a un integrante ya registrado. El usuario Administrador debe de buscar de entre los integrantes y alumnos que quiere hacerles usuario del sistema. Una vez llenado los campos presionar en el botón Guardar
Conexión del sistema a la base de datos PostgreSQL
La interfaz cuenta con 2 campos de texto y un checklist, de los cuales uno es para elegir a los integrantes o alumnos de comisión, por medio de la web services de OCDA. El segundo campo para introducir su contraseña y por último en el chekclist debe seleccionar el tipo de usuario. Clic en Guardar.
Si los datos ingresados por el usuario Administrador son correctos el sistema mostrará un mensaje de éxito indicando “Guardado con éxito” y en caso contrario mostrará un mensaje de alerta indicando “Error de validación”.
H5. El usuario SPPP debe buscar por el código al alumno consultando a la webservices de OCDA para su validación de 160 créditos aprobados.
Conexión del sistema a la base de datos PostgreSQL
La interfaz cuenta un texto para escribir el código y con un botón para validar. El usuario SPPP debe ingresar el código con el requisito de los 00(dos ceros) al inicio y luego clic en validar y aceptar la búsqueda de la ventana emergente para confirmar validación.
Si encuentra al estudiante, debe escribir en los datos del practicante como nombre apellidos y créditos aprobados, en caso contrario aparecerá un mensaje “alumno no encontrado en OCDA”
H6. El usuario SPPP debe desplegar las opciones de empresa para la práctica, en caso de no encontrarlas debe hacer clic en el botón registro de empresas, el cual se mostrara en una pantalla emergente y finalmente clic en guardar.
Conexión del sistema a la base de datos PostgreSQL
La interfaz cuanta con un cuadro desplegable de opciones con búsqueda incluida, un botón para aumentar empresas por medio de una ventana desplegable la cual cuenta con 10 campos y un botón guardar.
Si se encuentra a la empresa se debe continuar con el registro de prácticas ,caso contrario aumentar una empresa, seleccionarla y validar selección no vacía con un mensaje de error “Empresa: Error de validación.-se necesita un valor”
H7. El usuario SPPP debe registrar Conexión del La interfaz está dentro del En caso de llenar los campos el
69
los campos e título de proyecto, resumen, pudiéndose explayar en detalle.
sistema a la base de datos PostgreSQL
registro de nuevos practicantes, cuenta con dos áreas de texto y son de carácter obligatorio por ser de interés para continuar con el registro de una práctica.
sistema le permitirá registrar al practicante en caso contrario validara con el siguiente error “Titulo : Error de validación” “Resumen: Error de validación.- necesita un valor”
H8. El usuario SPPP debe registrar las funciones del practicante, la cual será atreves de un campo de texto para visualizar las funciones y para agregar un botón que genere una ventana emergente por ser varias las funciones.
Conexión del sistema a la base de datos PostgreSQL
La interfaz cuanta con una caja de texto para las funciones, para registrar una nueva función debe seleccionar en el botón a lado derecho del campo de texto y hacer clic en Guardar.
De asignar funciones correctamente le permitirá guardar con éxito las prácticas, en caso de no llenar ninguna función se saldrá el siguiente error “Funciones: Error de validación”
70
CUADRO 19: PRUEBA DE LA SEGUNDA ITERACCIÓN
HISTORIA INTRODUCCION CORRECTA CONDICION DE
EJECUCION
ENTRADA RESULTADO ESPERADO C
H9. El usuario SPPP debe ir al menú
principal buscar al practicante y
en opciones (figura de la tuerca)
y hacer clic en Procesar, luego
clic en le hipervínculo de
“Asignar asesor”, seleccionar al
docente, la fecha de asignación,
el número de oficio y el nombre
del decano.
Conexión del sistema
a la base de datos
PostgreSQL
La interfaz cuenta con un campo de
opciones para seleccionar le grado
del docente, un campo de texto
con búsqueda para el asesor, un
campo de fecha con un calendario
y un campo más para el nombre
del decano por ultimo clic en
guardar.
Al llenar todos los campos de manera
correcta nos saldrá un mensaje de
confirmación “asesor guardado con
éxito”, caso contrario nos debe aparecer
un mensaje de error para los campos
nulos. Que diga “Error nombre del campo
:Error de validación”
H10. El usuario SPPP debe ir al menú
principal, buscar al practicante
luego ir a opciones (figura de la
tuerca) y clic en detalles, se
mostrara una ventana y hacer
clic en el nombre del asesor
para generar su oficio.
Conexión del sistema
a la base de datos
PostgreSQL
La interfaz muestra un cuadro con
el resumen de los datos del
practicante, en el nombre del
asesor aparece un hipervínculo
hacer clic para generar oficio.
Al hacer clic en el hipervínculo se debe
abrir una nueva pestaña, el cual muestre
el oficio por el cual el practicante fue
asignado el asesor y la respectiva
autorización.
H11. El usuario SPPP debe ir al menú
principal buscar al practicante y
en opciones (figura de la tuerca)
y clic en procesar, se mostrara
una ventana y hacer clic en el
hipervínculo de “supervisión de
práctica por docente”.
Conexión del sistema
a la base de datos
PostgreSQL
La interfaz cuenta con un campo de
texto con búsqueda para el asesor,
un campo de fecha con un
calendario, un campo enmascarado
con el número de oficio y un área
de texto para el detalle de la
supervisión.
Al llenar todos los campos de manera
correcta nos saldrá un mensaje de
confirmación “supervisión guardado con
éxito”, caso contrario nos debe aparecer
un mensaje de error para los campos
nulos. Que diga “Error nombre del campo
:Error de validación”
H12. El usuario SPPP debe ir al menú Conexión del sistema La interfaz cuanta con una ventana En caso que el practicante ya superó las
71
principal, buscar al practicante
luego ir a opciones (figura de la
tuerca) y clic en Ampliar
práctica.
a la base de datos PostgreSQL
emergente que describe al
practicante y el historial de sus
ampliaciones además de mostrar
un campo selecciónale con el
número de meses a ampliar y una
breve descripción.
dos ampliaciones como máximo no debe
salir la opción de ampliación, caso
contrario debe ampliar
satisfactoriamente con el mensaje
Prácticas ampliadas.
H13. El usuario SPPP debe ir al menú
principal buscar al practicante y
en opciones (figura de la tuerca)
y clic en procesar, se mostrará
una ventana y hacer clic en el
hipervínculo de “entrega de
informe de practicante”.
Conexión del sistema a la base de datos PostgreSQL
La interfaz cuenta con dos entradas
de texto, las cuales son para
registrar la fecha de entrega y
algunas observaciones si es que las
hubiese.
La ventana fecha será presentada con un
calendario para elegir la fecha, si el
ingreso de la fecha es correcta saldrá un
mensaje “Informe Registrado” caso
contrario “Fecha: Error de validación”.
H14. El usuario SPPP debe ir al menú
principal buscar al practicante y
en opciones (figura de la tuerca)
y clic en procesar, se mostrará
una ventana y hacer clic en el
hipervínculo de “asignación de
jurados”.
Conexión del sistema a la base de datos PostgreSQL
La interfaz tiene 4 opciones para
elegir los grados de los jurados y 4
campos de texto
autocompletables con búsqueda
para elegir a los docentes, en la
parte superior cuanta la fecha,
lugar y hora que se les está
asignado a la sustentación luego
debe hacer clic en guardar.
Si las introducciones son correctas y no
hay ningún campo en blanco el mensaje
será “Jurados y sustentación asignada”,
caso contrario saldrá el campo con el
error que ocurrió.
H15. El usuario SPPP debe ir al menú
principal buscar al practicante y
en opciones (figura de la tuerca)
y clic en procesar, se mostrará
una ventana y hacer clic en el
Conexión del sistema a la base de datos PostgreSQL
La interfaz cuenta con dos campos,
una para asignarle la nota que
obtuvo el sustentante, el rango es
de 0 a 20, y las observaciones que
hubo durante la sustentación para
Si las introducciones fueron correctas se
registrará la evaluación con éxito caso
contrario saldrá el campo con el error
que ocurrió.
72
hipervínculo de “calificar
resultados de sustentación”.
las posteriores correcciones luego
debe hacer clic en guardar.
H16. El usuario SPPP debe ir al menú
principal, buscar al practicante
luego ir a opciones (figura de la
tuerca) y clic en detalles, se
mostrara una ventana y hacer
clic en su estado. Para ver el
oficio de asignación de jurados.
Conexión del sistema
a la base de datos
PostgreSQL
La interfaz muestra un cuadro con
el resumen de los datos del
practicante, en el nombre del
asesor aparece un hipervínculo
hacer clic para generar oficio.
Al hacer clic en el hipervínculo se debe
abrir una nueva pestaña, el cual muestre
el oficio por el cual el practicante fue
asignado el asesor y la respectiva
autorización.
H17. El usuario SPPP debe ir al menú
principal buscar al practicante y
en opciones (figura de la tuerca)
y clic en procesar, se mostrara
una ventana y hacer clic en el
hipervínculo de “registrar
informe final aprobado”.
Conexión del sistema a la base de datos PostgreSQL
La interfaz cuenta con un botón
para seleccionar el origen del
archivo en formato .pdf con un
máximo de 30MB(MegaBytes)
.Al hacer clic en el botón para elegir el
informe debe subir al repositorio de
mostrando el porcentaje de subido y
hacer clic en guardar debe salir en
mensaje “Informe subido con Éxito” caso
contrario un error. “intente de nuevo”
73
CUADRO 20: PRUEBA DE LA TERCERA ITERACCIÓN
HISTORIA INTRODUCCION CORRECTA CONDICION DE
EJECUCION ENTRADA RESULTADO ESPERADO
C
H18. El usuario del SPPP debe ir al menú
reportes y hacer clic en la opción
“practicantes”.
Conexión del sistema a la base de datos PostgreSQL
La interfaz muestra una
ventana emergente
para el ingreso de dos
parámetros que serán
las fechas en la que se
requiera el reporte del
practicante.
Al ingresar correctamente los datos de las
fechas para ver el reporte se mostrará una
nueva pestaña con el reporte de los
practicantes y datos como nombres, asesor,
fecha de inicio y fecha de fin y las opciones
para convertir a diferentes formatos o
imprimir directamente.
H19. El usuario del SPPP debe ir al menú
reportes y hacer clic en la opción
“historial de practicantes”.
Conexión del sistema a la base de datos PostgreSQL
La interfaz muestra una
ventana emergente
para el ingreso de un
parámetro que es el
código del practicante.
Al ingresar correctamente los datos de las
fechas para ver el reporte se mostrará una
nueva pestaña con el reporte esperado y las
opciones para convertir a diferentes
formatos o imprimir directamente.
H20. El usuario del SPPP debe ir al menú
reportes y hacer clic en la opción
“ranking de asesores”.
Conexión del sistema a la base de datos PostgreSQL
La interfaz muestra una
ventana emergente
para el ingreso de dos
parámetros que serán
las fechas en la que se
requiera el reporte del
ranking de asesores.
Al ingresar correctamente los datos de las
fechas para ver el reporte se mostrará una
nueva pestaña con el reporte esperado y las
opciones para convertir a diferentes
formatos o imprimir directamente.
H21. El usuario del SPPP debe ir al menú
reportes y hacer clic en la opción
“Documento para supervisiones”
Conexión del sistema a la base de datos PostgreSQL
La interfaz muestra una
ventana emergente
para el ingreso de un
parámetro que es el
código del practicante.
Al ingresar correctamente los datos de las
fechas para ver el reporte se mostrará una
nueva pestaña con el reporte esperado y las
opciones para convertir a diferentes
formatos o imprimir directamente.
74
H22. El usuario del SPPP debe ir al menú
reportes y hacer clic en la opción
“ranking de jurados”.
Conexión del sistema a la base de datos PostgreSQL
La interfaz muestra una
ventana emergente
para el ingreso de dos
parámetros que serán
las fechas en la que se
requiera el reporte del
ranking de jurados.
Al ingresar correctamente los datos de las
fechas para ver el reporte se mostrará una
nueva pestaña con el reporte esperado y las
opciones para convertir a diferentes
formatos o imprimir directamente.
H23. El usuario del SPPP debe ir al menú
reportes y hacer clic en la opción
“documentos de gestión”.
Conexión del sistema a la base de datos PostgreSQL
La interfaz muestra una
ventana con las
opciones de los
formatos de
documentos a imprimir
mostrándose en una
nueva pestaña del
navegador.
Al ingresar correctamente los datos de las
fechas para ver el reporte se mostrará una
nueva pestaña con el reporte esperado y las
opciones para convertir a diferentes
formatos o imprimir directamente.
H24. El usuario del SPPP debe ir al menú
reportes y hacer clic en la opción
“reporte de sustentaciones”.
Conexión del sistema a
la base de datos
PostgreSQL
La interfaz muestra una
ventana emergente
para el ingreso de dos
parámetros que serán
las fechas en la que se
requiera el reporte de
las sustentaciones.
Al ingresar correctamente los datos de las
fechas para ver el reporte se mostrará una
nueva pestaña con el reporte esperado y las
opciones para convertir a diferentes
formatos o imprimir directamente.
75
CUADRO 21: PRUEBA DE LA CUARTA ITERACCIÓN
HISTORIA INTRODUCCION CORRECTA CONDICIÓN DE
EJECUCIÓN
ENTRADA RESULTADO ESPERADO C
H25. El usuario SPPP debe ir al menú
principal buscar al practicante y en
opciones (figura de la tuerca) y clic en
procesar, se mostrara una ventana y
hacer clic en el hipervínculo de
“registrar informe final aprobado”.
Conexión del sistema a
la base de datos
PostgreSQL.
La interfaz muestra una ventana con tres
botones, uno para buscar el archivo en la
maquina local, otro para subirlo y otro
para guardarlo registrando la fecha y las
observaciones. Además el formato será
.pdf y el peso máximo 30MB.
Se debe actualizar el menú biblioteca con
el nuevo archivo subido.
Si se cumplió el con
formato y el tamaño del
archivo debe subir al
repositorio y actualizar el
registro de informes,
verificado en la parte de
menú, Biblioteca. Caso
contrario saldrá mensajes
de error.
H26. Consumir datos de OCDA Conexión al servidor
Local Apache.
Cuenta con un botón en la parte de
registrar nuevo practicante, para validar
en OCDA los datos del código ingresado,
además el código es validado con 2 ceros
delante. Ejemplo 0020090318.
Si la conexión es
satisfactoria traerá los
datos del alumno como
nombres y créditos
aprobados, para su
registro en caso contrario
nos mostrara un mensaje
de error.
3.10. RESUMEN DE LAS PRUEBAS:
Las pruebas fueron desarrolladas durante 10 horas por 3 días en total; se realizaron siguiendo las historias de usuario por
iteraciones y se pudo comprobar que todas la funcionalidades, analizadas y vistas desde mi punto de vista como futuro profesional, son
correctamente y rinde en los escenarios requeridos.
76
CONCLUSIONES
1. Se logró desarrollar el sistema de Prácticas pre profesionales “SPPP” V1.0, con el
uso del modelo XP (Programación Extrema) con la tecnología Java Web, haciendo
uso de frameworks de desarrollo, aplicando el modelo de Vista Controlador,
PrimeFaces en la capa de presentación, Hibernate en la capa de modelo y Spring
para la Inyección de dependencias, en un periodo de 96 días.
2. Se logró recolectar las 26 historias de usuarios en un total de 22 días, el trabajo de
campo se hizo inter diario por la misma carga laboral de los docentes miembros de
la comisión.
3. Al obtener las historias de usuario se logró planificar el desarrollo de un total de 78
tareas realizables con un esfuerzo estimado de 176 horas.
4. Se hizo el análisis de los documentos de gestión, normativo y mediante observación
directa, entrevistas informales, se logró como resultado, diseñar 8 procesos.
5. Se logró construir la base de datos, bajo el gestor PostgresQL 9.2. de la comisión de
prácticas pre profesionales, con lenguaje de escritura en inglés, además de ello está
sirviendo para la integración con las demás comisiones para tener una base de
datos integral para la Facultad de ingeniería en informática y Sistemas.
6. Se construyó el software en base a las tareas planificadas con tecnologías java Web,
utilizando Apis para agilizar el desarrollo, obteniendo como resultado un prototipo
con 14 vistas, 36 modelos.
7. Se realizó con éxito las pruebas del software, obteniendo muy buenos resultados en
cuanto a la consistencia mediante las historias de usuario planificadas.
8. Se contó con un sistema de referencia el cual, se pretendió reanudar, el hecho
observar que los componentes y herramientas utilizadas ya están desfasadas,
además de no alinearse a lo que se quiere conseguir a fututo mediante
estandarización de lenguajes de desarrollo propuestos por CTIC-UNAS, se procedió
a la construcción desde un inicio ajustando al nuevo reglamento 2013
77
9. El “SPPP” versión 1.0 está desarrollado para satisfacer las necesidades funcionales
de la Comisión de Prácticas Pre Profesionales de la Facultad de Ingeniería en
Informática y Sistemas por las siguientes razones:
a. Creación y administración de Comisiones.
b. Creación y administración de Integrantes de una comisión.
c. Creación y administración de Usuarios del “SPPP” versión 1.0 para una comisión.
d. Creación y supervisión textual de los Practicantes.
e. Asignación de asesores, jurados y fechas de sustentaciones a los practicantes.
f. Diversos reportes de los practicantes, ranking de asesores, informes, jurados,
sustentaciones, repositorio digital.
g. Diversos documentos digitales de autorización de prácticas y asignación de
asesor, designación de jurados, jurado de sustentación, ficha de inscripción,
actas de sustentación, remisión de informes finales y dictamen de ampliación.
h. Usabilidad, confiabilidad, mantenibilidad y eficiencia.
10. Se utilizó con un sistema de control de versiones que está en línea en google.code
esto sirvió para actualizar remotamente en un solo almacén central, cada cambio
que se hacía.
78
RECOMENDACIONES
1. Que se oficialice el uso del software por parte de la comisión mediante resolución
de consejo de Facultad.
2. Habilitar un servidor de aplicaciones, configurar, instalar, implementar y
complementar el “SPPP” versión 1.0 en el Centro de Tecnología de Información y
Comunicación-UNAS para su funcionamiento. Si es posible asignar estas tareas a
otro estudiante con motivo de sus Prácticas Pre Profesionales.
3. Antes del despliegue realizar nuevas pruebas funcionales con la presencia de los
miembros de la comisión y alumnos, para mayor conformidad.
4. Realizar una capacitación en el manejo de las funcionalidades del “SPPP” versión 1.0
para el administrador y los usuarios.
5. Utilizar el sistema una vez instalado y aprovechar las funcionalidades que brinda. En
caso de no cumplir al 100% un requerimiento o aparecer en nuevos requerimientos
o algunas inconsistencias, no cometer el error de almacenarlo y olvidar sino tratar
de anotarlos en algún documento físico o virtual para luego solicitar el desarrollo
del “SPPP” versión 2.0.
6. Que se siga esta línea de desarrollo para la integración de las comisiones así como el
sistema de trámite documentario de la Facultad de ingeniería en informática y
sistemas, ya que se dio el primer paso para realizar lo comentado, ahora depende
de las autoridades dar la continuidad del caso.
7. Para fines de apoyo del proyecto se utilizó el modelo de desarrollo XP, aun así está
orientado a grupos de desarrollo, y se recomienda como posible tema de tesis la
creación de un modelo de desarrollo orientado a los programadores individuales, ya
que no todas las sugerencias de XP ni otros modelos son útiles para casos como
esta práctica.
79
BIBLIOGRAFÍA
1. Dr. Wilson Castillo Soto, E. (2001). Normas Técnicas para la Redacción y Presentación
de Documentos Científicos. Tingo María, Perú. 47 p.
2. CORTIZO PÉREZ, J., EXPÓSITO GIL, D. Y RUIZ LEYVA, M. (2010). eXtreme Programming.
97 p. Disponible en: http://www.esp.uem.es/jccortizo/xp.pdf. Accesado el 20 de
Enero del 2010.
3. JAVASCRIPTYA (2009). Curso. Disponible en línea : http://www.javascriptya.com.ar/.
4. INGENIERÍA DEL SOFTWARE – Roger Pressman.6th.Ed.McGraw-Hill.pdf Pág.45
5. PROGRAMACIÓN EXTREMA (2010). 15 p. Disponible en:
http://eisc.univalle.edu.co/materias/WWW/material/lecturas/xp.pdf. Accesado el 20
de Enero del 2010.
6. PÁGINA OFICIAL DE PRIMEFACES disponible en línea
http://www.primefaces.org/showcase/ui/csvBasic.jsf
7. INGENIERÍA DEL SOFTWARE – Roger Pressman.6th.Ed.McGraw-Hill.pdf Pág.106
8. PROGRAMACIÓN EXTREMA-
Ingenieria.de.Software.Ian.Sommerville.7ma.Edicion.PRENTICE-HALL.Pág.373
9. SERRA MACHADO DAVID – “Estudio del servidor de aplicaciones Glassfish y de las
aplicaciones J2EE“pág. 182 disponible. [En línea]:
ddd.uab.cat/pub/trerecpro/.../SerraManchadoDavidR-ETISa2009-10.pdf
10. PAGINA OFICIAL DE POSTGRESQL disponible [En línea]:
http://www.postgresql.org.es/sobre_postgresql
11. PÁGINA OFICIAL DE POSTGRESQL disponible [En línea]: https://www.java.net/
80
OTRAS ACTIVIDADES REALIZADAS DURANTE LA PRÁCTICA PRE
PROFESIONAL.
1. Configuración y administración del controlador de dominio en Windows server
2008R2 del laboratorio de sistemas.
Esta actividad se realizó previo acuerdo con del Jefe del laboratorio Ing. George
Paucar Palomino, por motivos de control a los usuarios tanto alumnos y
docentes.
Se definió las políticas a configurar por ejemplo: que los usuarios no puedan
insertar dispositivos periféricos a las maquinas como medida a la infección
descontrolada de virus.
81
2. Administración del servicio de File Share en Windows server 2008R2.
Para complementar el servicio de controlador de dominio y como solución a la
política del acceso a dispositivos periféricos, se propuso la configuración de
archivos compartidos mapeados en cada computadora de los usuarios del
laboratorio de sistemas, asi puedan compartir archivos sin necesidad del usb.
3. Configuración y administración del servidor proxi squid en Centos 6.4.
Tras la llegada del internet al laboratorio de sistemas no se tuvo control del
acceso a las páginas, por lo que se generó un desorden, en consecuencia se
propuso la configuración de un servidor proxi squid en Linux (Centos 6.4), que
sirvió para controlar el acceso a páginas sociales, juegos, videos entre otros.
4. Administración de la Red e internet del laboratorio de sistemas.
Se administró la red interna del laboratorio asegurando conectividad para el servicio
continuo del laboratorio, además el acceso a los usuario inalámbricos que no estaban en
el dominio, mediante control por filtrado MAC.
5. Apoyo en la administración general del laboratorio de sistemas.
Apoyo en la atención de los servicios del laboratorio de Sistemas a los docentes y
alumnos de la Facultad de ingeniería en informática y sistemas.