Informe PPP

[Dictamen del asesor]
[Certificado de prcticas emitido por la institucin donde se Desarrollaron las PPP]

{El certificado deber indicar claramente las fechas de inicio y fin de las prcticas, as como el rea o funciones desarrolladas
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 superacin bajo cualquier circunstancia as como su amor y apoyo incondicional.
A mis Docentes de la Facultad de Ingeniera en informtica y sistemas quienes siempre estn prestos a apoyar a sus estudiantes.
AGRADECIMIENTO A:
Dios, por la vida que me da y las enseanzas que dej, cuidando seguir sus pasos.
A mis padres, por estar conmigo en todos los momentos de mi vida, alentndome a seguir adelante
A los integrantes la Comisin de Prcticas 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 gua para el desarrollo de mi prctica pre profesional.
A todos los dems docentes de la Facultad de Ingeniera en Informtica y Sistemas quienes compartieron conmigo sus conocimientos durante 5 aos de estudio.
A todos mis amigos y compaeros de la Facultad de Ingeniera en Informtica y Sistemas.
NDICE
INTRODUCCIN..................................................................................................................... 9 CAPTULO I .......................................................................................................................... 10 DE LA ORGANIZACIN ......................................................................................................... 10 1.1. DE LA INSTITUCIN ............................................................................................... 10 NOMBRE ....................................................................................................... 10 RESEA HISTRICA ....................................................................................... 10 DESCRIPCIN ................................................................................................ 10 UBICACIN GEOGRFICA............................................................................... 10 VISIN .......................................................................................................... 11 MISIN ......................................................................................................... 11 OBJETIVOS .................................................................................................... 11 ESTRUCTURA ORGNICA ............................................................................... 11 ORGANIGRAMA ESTRUCTURAL ...................................................................... 12
1.1.1. 1.1.2. 1.1.3. 1.1.4. 1.1.1. 1.1.2. 1.1.3. 1.1.4. 1.1.5. 1.2.
DE LA COMISIN DE PRCTICAS PRE PROFESIONALES ........................................... 13 RESEA HISTRICA ....................................................................................... 13 DESCRIPCIN ................................................................................................ 13 OBJETIVO ...................................................................................................... 13 ORGANIGRAMA DE LA COMISIN .................................................................. 13
1.2.1. 1.2.2. 1.2.3. 1.2.4.
CAPTULO II ..................................................................................................................... 14 MARCO TERICO................................................................................................................. 14 2.1. 2.2. 2.3. 2.4. 2.5. 2.6. QU SON LAS PRCTICAS PRE PROFESIONALES? .................................................. 14 INGENIERA DE SOFTWARE ................................................................................... 14 QU ES UN MODELO DE SOFTWARE? .................................................................. 15 QU ES UNA METODOLOGA DE SOFTWARE? ...................................................... 15 QU SON MODELOS GILES DE PROCESOS DE SOFTWARE? .................................. 15 PROGRAMACIN EXTREMA O XP (EXTREME PROGRAMING) ................................. 16 FASES DE XP .................................................................................................. 18 VARIABLES DE XP .......................................................................................... 21
2.6.1. 2.6.2. 2.7. 2.8. 2.9. 2.10.
QU SON LAS TECNOLOGAS WEB? ...................................................................... 22 QU ES UNA PGINA WEB? ................................................................................. 22 QU ES UN SITIO WEB? ....................................................................................... 22 QU ES UNA INTRANET? .................................................................................. 23
2.11. 2.12. 2.13. 2.14. 2.15. 2.16. 2.17. 2.18. 2.19. 2.20. 2.21. 2.22. 2.23. 2.24. 2.25.
QU ES UN SERVIDOR WEB? ............................................................................ 23 QU ES UN SERVIDOR WEB LOCAL? ................................................................. 23 QU ES UNA APLICACIN WEB? ....................................................................... 23 QU SON SERVICIOS WEB? .............................................................................. 24 QU ES UN ENTORNO DE DESARROLLO INTEGRADO? ....................................... 24 QU ES UN SERVIDOR DE APLICACIONES? ........................................................ 25 PLATAFORMA JAVA .......................................................................................... 25 JAVA EE ............................................................................................................ 26 QU ES UNA BASE DE DATOS? ......................................................................... 27 QU ES UN GESTOR DE BASE DE DATOS? ......................................................... 27 QU ES POSTGRESQL? ..................................................................................... 27 QU ES MODELADO DE BASE DE DATOS? ......................................................... 28 QU ES UN FRAMEWORK DE DESARROLLO? ..................................................... 28 QU ES JAVA PRIMEFACES? ............................................................................. 29 QU ES HIBERNATE? ........................................................................................ 29
CAPTULO III ........................................................................................................................ 31 ACTIVIDADES REALIZADAS ................................................................................................... 31 3.1 3.2 3.3 3.4 SITUACIN ACTUAL DE LA COMISIN DE PRCTICAS PRE PROFESIOANALES .......... 31 IDENTIFICACIN DEL PROBLEMA........................................................................... 31 ANTECEDENTES .................................................................................................... 31 OBJETIVOS ........................................................................................................... 32 GENERAL ....................................................................................................... 32 ESPECFICOS .................................................................................................. 32
3.4.1. 3.4.2. 3.5 3.6
JUSTIFICACIN ..................................................................................................... 32 APLICACIN DEL MODELO DE DESARROLLO EXTREME PROGRAMING (XP) ............. 33 DESCRIPCIN DE LA ACTIVIDAD ASIGNADA. ................................................... 33
3.6.1.
3.6.2. POR QU USAR EL MODELO DE DESARROLLO XP PARA LA CONSTRUCCIN DEL SOFTWARE? ................................................................................................................. 33 3.6.3. 3.7 PRCTICAS UTILIZADAS EN EL PROYECTO ....................................................... 33
FASE1: PLANEACIN ............................................................................................. 34 EQUIPO DE DESARROLLO: .............................................................................. 34 HISTORIAS DE USUARIO: ............................................................................... 35 ESTIMACIN DE ESFUERZO ASOCIADOS A LAS HISTORIAS DE USUARIOS......... 38 PLAN DE ENTREGA ........................................................................................ 39 ANLISIS DE REQUISITOS MEDIANTE DIAGRAMAS DE PROCESOS ................... 40 DIAGRAMA DE CLASES................................................................................... 44
3.7.1 3.7.2 3.7.3 3.7.4 3.7.5 3.7.6
3.8
FASE 2: DISEO .................................................................................................... 46 ARQUITECTURA DEL SISTEMA ........................................................................ 46 DIAGRAMA DE ENTIDAD RELACIN ............................................................... 47 DICCIONARIO DE DATOS ................................................................................ 49
3.8.1 3.8.2 3.8.3 3.9
FASE3: CONSTRUCCIN ........................................................................................ 49 PROTOTIPOS GENERALES PARA EL DISEO Y CONSTRUCCIN ........................ 49 PRIMERA ITERACCIN ................................................................................... 51 SEGUNDA ITERACCIN .................................................................................. 53 TERCERA ITERACCIN .................................................................................... 55 CUARTA ITERACCIN ..................................................................................... 58 DIARIO DE ACTIVIDADES:............................................................................... 60
3.9.1 3.9.2 3.9.3. 3.9.4. 3.9.5. 3.9.6. 3.10 3.10.
FASE4: PRUEBAS ................................................................................................... 66 RESUMEN DE LAS PRUEBAS: .............................................................................. 75
CONCLUSIONES ................................................................................................................... 76 RECOMENDACIONES ........................................................................................................... 78 BIBLIOGRAFA ..................................................................................................................... 79 ANEXOS .............................................................................................................................. 82
ANEXO 01. GASTOS ADMINISTRATIVOS DE LAS PRCTICAS 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 PRCTICAS PRE PROFESIONALES 2012 ANEXO 09 DOCUMENTOS DE LA COMISION DE PPP ANEXO 10. MANUAL DE USUARIO
INTRODUCCIN
La Facultad de Ingeniera en Informtica 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 Comisin de Prcticas Pre Profesionales encargada de planificar, coordinar y supervisar por medios adecuados la ejecucin y la correspondiente evaluacin de las prcticas pre profesionales de los estudiantes. La inexistencia de herramientas que permita automatizar la gestin y control de las Prcticas Pre Profesionales, sumado a ello, la carga laboral, tanto acadmica como administrativa de los integrantes de la comisin, hacen que el trabajo se dificulte. El presente informe de Prcticas Pre Profesionales describe el desarrollo de un software exclusivo para la Comisin de Prcticas Pre Profesionales denominado SPPP versin 1.0, con el firme objetivo de apoyar a los procesos de registros y controles de aquellos estudiantes que estn realizando sus Prcticas Pre Profesionales en la Facultad de Ingeniera en Informtica y Sistemas. El SPPP versin 1.0 est desarrollado siguiendo la metodologa de Programacin Extrema la cual se sujeta a la investigacin preliminar hecha a los miembros de la comisin, al reglamento de Prcticas Pre Profesionales.
CAPTULO I DE LA ORGANIZACIN
1.1. DE LA INSTITUCIN 1.1.1. NOMBRE Facultad de Ingeniera en Informtica y Sistemas (FIIS). 1.1.2. RESEA HISTRICA La Facultad de Ingeniera en Informtica y Sistemas. fue creada por resolucin N 003-99-AU-R-UNAS de fecha 04 de septiembre de 1999, considerando el continuo cambio de los procesos empresariales y tecnolgicos del mundo de hoy, que hacen necesarios el reenfoque del pensamiento organizacional orientado al pensamiento sistmico. 1.1.3. DESCRIPCIN La FIIS, es una unidad fundamental de organizacin y formacin acadmica y profesional. Est integrada por sus profesores, graduados, estudiante y personal administrativo que contribuye a la gestin acadmica. Tiene como finalidad la formacin profesional, la investigacin, la proyeccin social, la produccin de bienes y prestacin de servicios. Est constituido por el Departamento Acadmico de Ciencias, Informtica y Sistemas, reas Acadmicas, Laboratorios, Gabinetes, Comisiones y otros. 1.1.4. UBICACIN GEOGRFICA Departamento :Hunuco Provincia :Leoncio Prado Distrito :Rupa Rupa Direccin :Av. Universitaria s/n Entidad :Facultad de Ingeniera en Informtica y Sistemas
Figura 01: Ubicacin Geogrfica
FUENTE: https://google.maps311
10
1.1.1. VISIN FIIS, lder en el desarrollo de la amazonia y la nacin. 1.1.2. MISIN Formar profesionales en informtica y sistemas capaces de solucionar problemas complejos aplicando el enfoque sistmico, preparados para dirigir funciones para el desarrollo de sistemas integrales tiles y actuar ticamente en su interaccin con la sociedad. 1.1.3. OBJETIVOS Brindar una slida formacin en el rea de ciencia y tecnologa con alta capacitacin en las ciencias exactas, los procesos y sistemas tecnolgicos. Incentivar el espritu crtico 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 investigacin y de la interaccin social. 1.1.4. ESTRUCTURA ORGNICA rgano de direccin Consejo de Facultad Decanato rganos de apoyo Secretaria de Facultad Secretaria de DACIS Extensionista Comisiones Permanentes - Comisin de Grados y Ttulos - Comisin de Evaluacin y Capacitacin Docente - Comisin de Traslado y Seguimiento Curricular - Comisin de Prcticas Pre Profesionales - Comisin de Matricula/Horario/Consejera - Comisin de Presupuesto - Comisin de Actividades Culturales y Sociales - Comisin de Investigacin y Publicaciones - Comisin de Proyeccin Universitaria rganos de Lnea Departamento Acadmico de Ciencias, Informtica y Sistemas - Jefe de Departamento Acadmico 11
1.1.5. ORGANIGRAMA ESTRUCTURAL

FIGURA 02:Organigrama de la FIIS
DECANO
SECRETARIA
UNIDAD DE EXTENSION
COMISIN DE GRAD. Y TITULOS
COM. DE TRAS. SEGUI. CURRI.
COMISIN DE PRESUPUESTO
COMISIN DE PRCTICAS. P. P.
COM. DE INVESTI. Y PUBLICACIN
COM. ACT. CULT. SOCIALES
COM. PROYEC. UNIVERSITARIA
COM. HORARI. Y MATRCULA
COM. DE EVAL. Y CAP. DOCENTE
DEPARTAMENTO ACADMICO DE CIENCIAS EN INFORMTICA Y SISTEMAS
SECRETARIA
REAS DE CIENCIAS BASICAS
REA DE COMPUT. E INFORMTICA
REA DE SISTEMAS
FUENTE: Manual de Obligaciones y Funciones de la FIIS
12
1.2. DE LA COMISIN DE PRCTICAS PRE PROFESIONALES 1.2.1. RESEA HISTRICA Se crea la Comisin de Prcticas 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 Resolucin correspondiente. En lo sucesivo cuando se refiera a esta comisin se escribir las siglas CPPP. 1.2.2. DESCRIPCIN 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 ejecucin y la correspondiente evaluacin de las Prcticas Pre Profesionales. La vigencia de la designacin de miembros de la CPPP es de un ao, pudiendo extenderse por otro periodo. Los integrantes deben ser docentes a tiempo completo y/o a dedicacin exclusiva de cualquier categora. 1.2.3. OBJETIVO Planificar, coordinar y supervisar por medios adecuados de la ejecucin y la correspondiente evaluacin de las Prcticas Pre Profesionales. 1.2.4. ORGANIGRAMA DE LA COMISIN
FIGURA 03:Organigrama de la comisin de PPP
DECANO
COMISIN DE PPP
PRESIDENTE
SECRETARIO
VOCAL
FUENTE: Elaboracin Propia
13
CAPTULO II MARCO TERICO

2.1. QU SON LAS PRCTICAS PRE PROFESIONALES? Se entiende por Prcticas Pre Profesionales a las actividades que realiza el estudiante, para aplicar y fortalecer los conocimientos adquiridos durante su formacin profesional, consolidando la base conceptual adquirida, haciendo investigacin, anlisis, diseo e implementacin de soluciones. VER ANEXO 08.REGLAMENTO DE PRCTICAS PRE PROFESIONALES FIIS 2012 2.2. INGENIERA DE SOFTWARE1 Segn Fritz Bauer en una conferencia fundamental defini que la ingeniera del software es el establecimiento y uso de principios slidos de la ingeniera para obtener econmicamente un software confiable y que funcione de modo eficiente en mquinas reales. Otras definiciones: Ingeniera del Software es la aplicacin prctica del conocimiento cientfico al diseo y construccin de programas de computadora y a la documentacin asociada requerida para desarrollar, operar (funcionar) y mantenerlos. Se conoce tambin como desarrollo de software o produccin de software (Bohem, 1976). La aplicacin de un enfoque sistemtico, disciplinado y cuantificable al desarrollo, operacin (funcionamiento) y mantenimiento del software; es decir, la aplicacin de ingeniera al software. (IEEE, 1993). La ingeniera del software es una tecnologa estratificada. Como se muestra en la figura 3, cualquier enfoque de la ingeniera (incluido el de la ingeniera de software) debe estar sustentado en un compromiso con la calidad.
FIGURA.04: Estratos de la ingeniera de software.
Fuente: Ingeniera del Software Roger Pressman 6th.Ed.McGraw-Hill
La ingeniera de software abarca un proceso, mtodos y herramientas.
Ingeniera del Software Roger Pressman.6th.Ed.McGraw-Hill.pdf Pg.45
14
El Proceso.- Es el elemento que mantiene juntos los estratos de la tecnologa 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 gestin de los proyectos de software y establece el contexto en el cual se aplican los mtodos tcnicos, se generan los productos del trabajo (modelos, documentos, reportes, formatos, etc.), se establecen los fundamentos, se asegura la calidad, y el cambio apropiadamente. Los Mtodos.- Proporcionan los cmo tcnicos para construir software. Abarcan un amplio espectro de tareas que incluyen la comunicacin, el anlisis de requisitos, el modelo del diseo, la construccin del programa, la realizacin de pruebas y el soporte. Las Herramientas.- Proporcionan el soporte automatizado o semiautomatizado para el proceso y los mtodos. Cuando las herramientas se integran de forma que la informacin 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 ingeniera 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 aplicacin. Sin embargo no nos dice que lmites 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 METODOLOGA DE SOFTWARE?3 Es un marco de trabajo usado para estructurar, planificar y controlar el proceso de desarrollo en sistemas de informacin. 2.5. QU SON MODELOS GILES DE PROCESOS DE SOFTWARE?4 Los modelos de proceso gil se disearon para cumplir con los cuatros aspectos claves de la ingeniera de software como son: la importancia de la organizacin propia de los equipos, los cuales controlan el trabajo que realizan; comunicacin y colaboracin 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 rpida del software que satisfaga al cliente. Existe un amplio espectro de modelos giles de proceso, cada uno en busca de su aceptacin dentro de la comunidad del desarrollo de software. Entre ellos tenemos a la Programacin Extrema (XP), Desarrollo adaptivo de software (DAS),
2 3
http://raulortega.blogspot.com/2006/12/para-los-lectores-de-este-blog-los.html-Software Libre http://www.um.es/docencia/barzana/IAGP/Iagp2.html - Apuntes. Ingeniera del Software 4 Ingeniera del Software Roger Pressman.6th.Ed.McGraw-Hill.pdf Pg.106
15
Mtodo de desarrollo de sistemas dinmicos (MDSD), Mel, Cristal, Desarrollo conducido por caractersticas (DCC), Modelo gil (MA). 2.6. PROGRAMACIN EXTREMA O XP (EXTREME PROGRAMING)5 La Programacin Extrema (XP) es posiblemente el mtodo gil ms conocido y ampliamente utilizado. El nombre fue acuado por Beck (Beck.2000) debido a que el enfoque fue desarrollado utilizando buenas prcticas reconocidas, como el desarrollo iterativo, y con la participacin del cliente en niveles <<extremos>>. En la programacin 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 cdigo. Todas las pruebas deben ejecutarse satisfactoriamente cuando el cdigo nuevo se integra al sistema. Existe un pequeo 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 programacin extrema implica varias prcticas, resumidas en el cuadro 1. Que se ajustan a los principios de los mtodos giles: El desarrollo incremental se lleva a cabo a travs de entregas del sistema pequeas y frecuentes y por medio de un enfoque para la descripcin de requerimientos basado en las historias de cliente o escenarios que pueden ser la base para el proceso de planificacin. El inters en las personas, en vez de en los procesos, se lleva a cabo a travs de la programacin en parejas, la propiedad colectiva del cdigo del sistema, y un proceso de desarrollo sostenible que no implique excesivas jornadas de trabajo. El cambio se lleva a cabo a travs de las entregas regulares del sistema, un desarrollo previamente probado y la integracin continua. El mantenimiento de la simplicidad se lleva a cabo a travs de la refactorizacin constante para mejorar la calidad del cdigo y la utilizacin de diseos sencillos que no prevn cambios futuros en el sistema.
FIGURA 05.El ciclo de entrega en la programacin extrema
Seleccionar las historias de usuario para esta entrega
Dividir las historias en tareas
Planificar entrega
Evaluar el sistema
Entregar el softw are
Desarrollar, probar e integrar el softw are
Fuente: Programacin extrema- Ingenieria.de.Software.-.Ian.Sommerville.7ma.Edicion

5
Programacin extrema- Ingenieria.de.Software.-.Ian.Sommerville.7ma.Edicion.PRENTICE-HALL.Pg.373
16
Cuadro 01. Prcticas de la Programacin Extrema.
PRINCIPIO O PRCTICA Planificacin incremental
Entregas pequeas
Metforas Diseo sencillo Desarrollo previamente probado
Refactorizacin
Programas en parejas
Propiedad colectiva
Semana de 40 horas
Integracin continua
Cliente presente
Usar Estndares de Codificacin
DESCRIPCIN Los requerimientos se registran en tarjetas de historias y las historias a incluir en una entrega se determinan segn el tiempo disponible y su propiedad relativa. Los desarrolladores dividen estas Historias en <<Tareas>> de desarrollo. El mnimo conjunto til de funcionalidad que proporcione valor de negocio se desarrolla primero. Las entregas del sistema son frecuentes e incrementalmente aaden funcionalidad a la primera entrega. Guiar todo el desarrollo con una historia simple y compartida de cmo funciona todo el sistema. Slo se lleva a cabo el diseo necesario para cumplir los requerimientos actuales. Se utiliza un sistema de pruebas de unidad automatizado para escribir pruebas para nuevas funcionalidades antes de que stas se implementen. Se espera que todos los desarrolladores refactoricen el cdigo continuamente tan pronto como encuentren posibles mejoras en el cdigo. Esto conserva el cdigo sencillo y mantenible. Los desarrolladores trabajan en parejas, verificando cada uno el trabajo del otro y proporcionando la ayuda necesaria para hacer siempre un buen trabajo. 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 cdigo. Cualquiera puede cambiar cualquier cosa. Trabajar no ms de 40 horas semanales como regla. Nunca trabajar horas extras durante dos semanas consecutivas. En cuanto acaba el trabajo en una tarea, se integra en el sistema entero. Despus de la integracin, se deben pasar al sistema todas las pruebas de unidad. 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 programacin extrema, el cliente es miembro del equipo de desarrollo y es responsable de formular al equipo los requerimientos del sistema para su implementacin. Los programadores escriben todo el cdigo de acuerdo con reglas que enfatizan la comunicacin a travs del mismo.
Fuente: Elaboracin Propia.
17
2.6.1. FASES DE XP6 Segn Roger Pressman en su libro 6th Edicin sobre Ingeniera del Software nos habla de 4 Fases: Planeacin, diseo, codificacin y pruebas. Un ejemplo claro se muestra en la figura 06.
FIGURA 06. Proceso de la Programacin Extrema
soluciones pico prototipos
historias de usuario v alores criterios de la prueba de iteraccin plan de iteraccin
o dis e
ac in plane
n ic ac i c odif
programacin en pareja
n ic ac i c odif
Lanzamiento
incremento del sof tware v alocidad calculada del proy ecto
prueba de unidad
prueba de unidad integracin continua
Fuente: Ingeniera del Software Roger Pressman 6th.Ed.McGraw.
1 FASE: PLANIFICACIN 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 lneas escritas por el cliente en un lenguaje no tcnico sin hacer mucho hincapi en los detalles; no se debe hablar ni de posibles algoritmos para su implementacin ni de diseos de base de datos adecuados, etc. Son usadas para estimar tiempos de desarrollo de la parte de la aplicacin que describen. Tambin 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 renen 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.
http://wiki.monagas.udo.edu.ve/index.php/Metodolog%C3%ADas_SCRUM_y_XP#METODOLOG.C3.8DA_ XP_.28EXTREME_PROGRAMMING.29 Metodologas XP
18
Cuadro 02. Modelo propuesto para una historia de usuario Historia de Usuario Nombre Historia de Usuario: Rol: Valor: Descripcin:
Iteracin asignada:
Observacin: Fuente: http://www.xp.com/trabajos51/programacion-extrema/programacion-extrema2
Las Historias de Usuario tienen tres aspectos: Tarjeta: en ella se almacena suficiente informacin para identificar y detallar la historia. Conversacin: cliente y programadores discuten la historia para ampliar los detalles (verbalmente cuando sea posible, pero documentada cuando se requiera confirmacin). Release Planning: Despus de tener ya definidas las historias de usuario es necesario crear un plan de publicaciones, en ingls "Release plan", donde se indiquen las historias de usuario que se crearn para cada versin del programa y las fechas en las que se publicarn estas versiones. Un "Release plan" es una planificacin donde los desarrolladores y clientes establecen los tiempos de implementacin ideales de las historias de usuario, la prioridad con la que sern implementadas y las historias que sern implementadas en cada versin del programa. (*Release plan: Planificacin de publicaciones). Iteraciones: Todo proyecto que siga la metodologa XP se ha de dividir en iteraciones de aproximadamente 3 semanas de duracin. Al comienzo de cada iteracin los clientes deben seleccionar las historias de usuario definidas en el "Release planning" que sern implementadas. Tambin se seleccionan las historias de usuario que no pasaron el test de aceptacin que se realiz al terminar la iteracin anterior. Estas historias de usuario son divididas en tareas de entre 1 y 3 das de duracin que se asignarn 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 nmero de historias de usuario que se pueden implementar en una iteracin; 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 iteracin. 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".
19
Programacin en Parejas: La metodologa XP aconseja la programacin 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 funcin o mtodo que est implementando, el otro analiza si ese mtodo o funcin es adecuado y est bien diseado. De esta forma se consigue un cdigo y diseo con gran calidad. Reuniones Diarias: Es necesario que los desarrolladores se renan 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: Diseo. Diseos Simples: La metodologa XP sugiere que hay que conseguir diseos simples y sencillos. Hay que procurar hacerlo todo lo menos complicado posible para conseguir un diseo fcilmente entendible e implementarle que a la larga costar menos tiempo y esfuerzo desarrollar. Glosarios de Trminos: Usar glosarios de trminos y una correcta especificacin de los nombres de mtodos y clases ayudar a comprender el diseo y facilitar sus posteriores ampliaciones y la reutilizacin del cdigo. Riesgos: Si surgen problemas potenciales durante el diseo, XP sugiere utilizar una pareja de desarrolladores para que investiguen y reduzcan al mximo el riesgo que supone ese problema. Funcionabilidad extra: Nunca se debe aadir funcionalidad extra al programa aunque se piense que en un futuro ser utilizada. Slo 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 codificacin de cdigos ya creados sin alterar su funcionalidad. Refactorizar supone revisar de nuevo estos cdigos para procurar optimizar su funcionamiento. Es muy comn rehusar cdigos ya creados que contienen funcionalidades que no sern usadas y diseos obsoletos.
20
3 FASE: CODIFICACIN. El cliente es una parte ms 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 an ms necesaria. No olvidemos que los clientes son los que crean las historias de usuario y negocian los tiempos en los que sern implementadas. Antes del desarrollo de cada historia de usuario el cliente debe especificar detalladamente lo que sta har y tambin tendr que estar presente cuando se realicen los test que verifiquen que la historia implementada cumple la funcionalidad especificada. Programar bajo estndares mantiene el cdigo consistente y facilita su comprensin y escalabilidad. 4 FASE: PRUEBAS. Uno de los pilares de la metodologa XP es el uso de test para comprobar el funcionamiento de los cdigos que vayamos implementando. El uso de los test en XP es el siguiente: Se deben crear las aplicaciones que realizarn los test con un entorno de desarrollo especfico para test. Hay que someter a test las distintas clases del sistema omitiendo los mtodos ms triviales. Se deben crear los test que pasarn los cdigos antes de implementarlos; en el apartado anterior se explic la importancia de crear antes los test que el cdigo. Un punto importante es crear test que no tengan ninguna dependencia del cdigo que en un futuro evaluar. Como se coment anteriormente los distintos test se deben subir al repositorio de cdigo acompaados del cdigo que verifican. Test de aceptacin. 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: Mquinas, especialistas y oficinas Tiempo: Total y de Entregas Calidad: Externa e Interna Alcance: Intervencin del cliente
21
2.7. QU SON LAS TECNOLOGAS 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 Google Chrome Galeon Internet Explorer Servidores web: CERN httpd Glassfish Konqueror sobre Linux Lynx sobre linux Opera Safari Seamonkey Shiira Midori Meleon
Servidor HTTP Apache Tomcat IIS Otras tecnologas: JSP DHTML PHP JSF HIBERNATE .NET Servidor HTTP Cherokee
2.8. QU ES UNA PGINA WEB?9 Empezando por su definicin, consideramos una pgina web a un documento disponible en Internet, o World Wide Web (www), codificado segn sus estndares y con un lenguaje especfico conocido como HTML. Es algo a lo que estamos acostumbrados a acceder si leemos este artculo pero no todos conocen realmente su funcionamiento. 2.9. QU ES UN SITIO WEB?10 En ingls Website o Web Site, un sitio Web es un sitio (localizacin) en la World Wide Web que contiene documentos (pginas web) organizados jerrquicamente (generalmente documentos en formato html, php, asp, etc.). Cada documento (pgina web) contiene texto y/o grficos que aparecen como informacin digital en la pantalla de un ordenador. Un sitio puede contener una combinacin de grficos, texto, audio, vdeo, y otros materiales dinmicos o estticos.
7 8
http://www.microscience.pe/20/tecnologia-web 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
22
Cada sitio web tiene una pgina de inicio (en ingls 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 (pginas web) adicionales. Cada sitio pertenece y es gestionado y por un individuo, una compaa o una organizacin. 2.10. QU ES UNA INTRANET?11 Es una red de ordenadores privada basada en los estndares de Internet. Las Intranets utilizan tecnologas de Internet para enlazar los recursos informativos de una organizacin, desde documentos de texto a documentos multimedia, desde bases de datos legales a sistemas de gestin de documentos. Las Intranets pueden incluir sistemas de seguridad para la red, tablones de anuncios y motores de bsqueda. 2.11. QU ES UN SERVIDOR WEB?12 Almacena principalmente documentos HTML (son documentos a modo de archivos con un formato especial para la visualizacin de pginas web en los navegadores de los clientes), imgenes, videos, texto, presentaciones, y en general todo tipo de informacin. Adems 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 mnimo, locales al sistema en el que estn instalados. 2.13. QU ES UNA APLICACIN WEB?14 Una aplicacin web es un conjunto de pginas que interactan unas con otras y con diversos recursos en un servidor web, incluidas bases de datos. Esta interaccin permite implementar caractersticas en su sitio como catlogos de productos virtuales y administradores de noticias y contenidos. Adicionalmente podr realizar consultas a bases de datos, registrar e ingresar informacin, solicitudes, pedidos y mltiples tipos de informacin en lnea en tiempo real.
11 12
http://www.hosting-peru.net/que_es_intranet.html 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
23
2.14. QU SON SERVICIOS WEB? Los Servicios Web o Web Services son una API para permitir exponer servicios a travs de la Web. Permite que aplicaciones Web interacten dinmicamente con otras aplicaciones, utilizando para ello estndares 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 informacin hasta complicados procesos de negocios. Se puede encapsular su lgica de negocio mediante web services y exponerlas para que los clientes las consuman a travs 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 ms sencillo posible. Programas IDE incluyen un editor de cdigo fuente, compilador, y por lo general un depurador que todos trabajemos juntos en la construccin 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 cdigo fuente, vincular archivos juntos y depurar el software. Software de programacin IDE tambin puede incluir un entorno de tiempo de ejecucin (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 aplicacin 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 cdigo y probar el programa, es fcil hacer cambios rpidos en el cdigo, compilarlo y ejecutar el programa de nuevo. La programacin es todava un trabajo duro, pero el software IDE ayuda a que los procesos un poco ms libre de problemas. a) NETBEANS16 NetBeans es un proyecto exitoso de cdigo 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 cdigo abierto NetBeans en junio 2000 y contina siendo el patrocinador principal de los proyectos. Al da 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 programacin. Existe adems
15 16
http://www.techterms.com/definition/ide https://netbeans.org/index_es.html
24
un nmero importante de mdulos para extender el NetBeans IDE. NetBeans IDE es un producto libre y gratuito sin restricciones de uso. 7.4; 15 de octubre de 2013 ltima versin estable: Entorno de desarrollo integrado. Gnero: Java Programado en: Multiplataforma Sistema operativo: CDDL, GNU General Public License 2 Licencia: En desarrollo Estado actual: Multilinge Idiomas: 2.16. QU ES UN SERVIDOR DE APLICACIONES?17 Un servidor de aplicaciones se trata de un dispositivo de software que proporciona servicios de aplicacin a las computadoras cliente. Un servidor de aplicaciones gestiona las funciones de lgica de negocio y de acceso de datos a la aplicacin. Los principales beneficios son la centralizacin y la disminucin de la complejidad en el desarrollo de aplicaciones: a) GLASSFISH El trmino Glassfish, traducido al espaol sera 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 queran 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 propsito general, de alto nivel que utiliza el paradigma de orientacin a objetos. La Mquina Virtual. Los programas escritos en Java son compilados como archivos ejecutables de una mquina 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 pg. 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 pg. 25 disponible en ddd.uab.cat/pub/trerecpro/.../SerraManchadoDavidR-ETISa2009-10.pdf
25
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 artculos mviles pequeos. Java Standard Edition (Java SE). Es la edicin 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 diseado 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 diseado para resolver los problemas encontrados por las grandes empresas. Las aplicaciones empresariales no slo son tiles para las grandes corporaciones, organismos y gobiernos, sin embargo. Los beneficios de una aplicacin empresarial son tiles, incluso esenciales, para que los desarrolladores individuales y pequeas organizaciones en un mundo cada vez ms 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 pg. 26
26
A dems JEE tambin se encarga de proporcionar caractersticas para la gestin de: Seguridad Control de transacciones Gestin de componentes desplegados Control de concurrencia Uso y asignacin de recursos 2.19. QU ES UNA BASE DE DATOS?20 Una coleccin de informacin organizada de tal manera que un programa de computadora puede rpidamente seleccionar piezas deseadas de datos. 2.20. QU ES UN GESTOR DE BASE DE DATOS? Una coleccin de programas que le permite almacenar, modificar y extraer informacin de una base de datos. Hay muchos tipos diferentes de DBMS, que van desde pequeos 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 gestin de bases de datos objeto-relacional, distribuido bajo licencia BSD y con su cdigo fuente disponible libremente. Es el sistema de gestin de bases de datos de cdigo abierto ms potente del mercado y en sus ltimas versiones no tiene nada que envidiarle a otras bases de datos comerciales.
TABLA 01: Lmites de Postgres
FUENTE: http://www.postgresql.org.es/sobre_postgresql
20 21
http://www.webopedia.com/TERM/D/database.html http://www.postgresql.org.es/sobre_postgresql
27
2.22. QU ES MODELADO DE BASE DE DATOS?22 Es el proceso de realizar el modelo de entidad relacin fsico para ser exportado al lenguaje SQL. a) MICROOLAP MicroOLAP Database Designer for PostgreSQL es una herramienta CASE fcil con la interfaz grfica 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 dinmicos, web services (servicios web) y aplicaciones web. El propsito de este tipo de framework es permitir a los desarrolladores construir aplicaciones web y centrarse en los aspectos interesantes, aliviando la tpica tarea repetitiva asociada con patrones comunes de desarrollo web. La mayora de los frameworks de aplicaciones web proporcionan los tipos de funcionalidad bsica comn, 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 aplicacin web adems promueven la reutilizacin y conectividad de los componentes, as como la reutilizacin de cdigo, y la implementacin de bibliotecas para el acceso a base de datos.
FIGURA 07: Componentes JSF en la pgina de configuracin de Glassfish
FUENTE: SERRA MACHADO DAVID Estudio del servidor de aplicaciones Glassfish y de las aplicaciones J2EEpg. 182
JSF proporciona:24 Una clara separacin entre vista y modelo. Desarrollo basado en componente, no en peticiones. Las acciones del usuario se ligan muy fcilmente al cdigo en el servidor. Creacin de familias de componentes visuales para acelerar el desarrollo.
22 23
http://www.postgresql.org/about/news/1465/ http://elbauldelprogramador.com/articulos/los-10-mejores-frameworks-gratis-de-aplicaciones-web/ 24 http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/101
28
Ofrece mltiples posibilidades de eleccin entre distintos desarrollos. Hace que sea fcil de construir una interfaz de usuario a partir de un conjunto de componentes de interfaz de usuario reutilizables Simplifica la migracin de los datos de la aplicacin a y desde la interfaz de usuario Ayuda a administrar el estado de la interfaz de usuario a travs de las peticiones de servidor Proporciona un modelo simple para el cableado de los eventos generados por el cliente al cdigo de la aplicacin en el servidor Permite que los componentes de interfaz de usuario personalizada para construir fcilmente 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 instalacin 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 usndolo en unos pocos segundos. CARCTERSTICAS: Un interesante conjunto de componentes (editor HTML, autocompletado, grficas,) Soporte para Ajax, basndose en el estndar JSF 2.0 Ajax API Sin dependencias, ni configuraciones, adems de ser muy ligero (1802Kb en su versin 3.5) Soporte para interfaces de usuario sobre dispositivos mviles, nos provee de un kit para este menester. Mltiples temas de apariencia, listos para usar. Amplia difusin 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 mtodos setter y getter. QUERY Y LENGUAJE HQL: Existen diversas herramientas tiles para el uso de Hibernate que cubren todo el desarrollo desde nuestra aplicacin hasta nuestra base de datos y viceversa:
25 26
http://www.genbetadev.com/frameworks/primefaces-framework-sobre-jsf-2-0-primeros-pasos http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=hibernate
29
FIGURA 08: Componentes JSF en la pgina de configuracin de Glassfish
FUENTE: http://www.hibernate.org/102.html
Desde herramientas de modelado UML como por ejemplo con Poseidon podemos generar modelos entidad relacin 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 opcin 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.
30
CAPTULO III ACTIVIDADES REALIZADAS

3.1 SITUACIN ACTUAL DE LA COMISIN DE PRCTICAS PRE PROFESIOANALES El proceso de las Prcticas 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 ejecucin y la correspondiente evaluacin de las Prcticas 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, adems de cumplir con su carga acadmica establecida. Por lo tanto, el tiempo que dispone cada integrante de la comisin es muy corto y necesitan de un mecanismo o herramienta que les ayude en sus actividades dentro de la comisin, especialmente en la bsqueda de informacin y en tener disponibilidad inmediata de informacin. Se realizaron varios intentos por buscar un mecanismo que permita agilizar sus procedimientos pero que no lograron alcanzar el objetivo. 3.2 IDENTIFICACIN DEL PROBLEMA La inexistencia de un mecanismo o herramientas que permita agilizar los procedimientos de registro y control de las Prcticas Pre Profesionales, obteniendo como resultado datos e informacin 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 realizacin de dos software de Prcticas Pre Profesionales. El primero fue realizado por el ex estudiante de la FIIS, Percy Collantes Daz, con motivo de sus prcticas 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 programacin en la FIIS, tuvieron el inters de desarrollar un sistemas de prcticas pre profesional, que no se lleg a concluir satisfactoriamente, o no se quiso entregar la informacin requerida, tales como el cdigo o el informe del desarrollo para su correcta implementacin. Todos estos antecedentes, segn lo investigado, estuvieron realizados en programacin de escritorio.
31
El antecedente ms cercano es del ex alumno Mario Gamboa (2010), quien realiz el software para la comisin bajo el lenguaje de programacin PHP y Gestor de Base de datos Mysql. El cual a la vez nunca se us, desfasndose y archivndose, al observarlo y hacerlo funcionar se observ que no existe un plan de despliegue adems de tener el cdigo 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 comisin de Prcticas Pre Profesionales. 3.4 OBJETIVOS 3.4.1. GENERAL Desarrollar el sistema de Prcticas Pre Profesionales SPPP V1.0, con tecnologas web, para la Comisin de Prcticas Pre Profesionales en la Facultad de Ingeniera en Informtica y Sistemas. 3.4.2. ESPECFICOS 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 dems informacin histrica que maneja la Comisin de Prcticas Pre Profesionales. Disear una base de datos relacional y los prototipos de las interfaces. Construir el software segn las tareas planificadas. Realizar las pruebas funcionales de la aplicacin web de Prcticas Pre Profesionales con los integrantes de la CPPP. 3.5 JUSTIFICACIN Impacto Tecnolgico El desarrollo del software permitir: Almacenar toda la informacin de los usuarios en una base de datos, permitindoles a los usuarios estar actualizados e informados de las prcticas aceptadas, anuladas, asignacin de asesores, informes finales, supervisiones, sustentaciones, asignacin de jurados. Impacto Social Alto grado de aceptacin por parte de los Miembros de comisin de prcticas pre profesionales, que contarn con un software que no slo les permitir agilizar sino tambin coordinar las actividades de registro, bsquedas, seguimientos y control de fechas, contenidos, ampliaciones, supervisiones, anulaciones de prcticas, informes finales y sustentaciones, la independencia de la informacin de las prcticas pre profesionales, la disminucin de la carga laboral y de una mejor forma de trabajo. Los estudiantes, tambin se beneficiarn en el sentido de disponer de la informacin 32
referente a las prcticas pre profesionales, del avance y control de sus actividades, de la comunicacin eficiente con la comisin, con su asesor y con sus jurados. Impacto Econmico Menores costes en la utilizacin de materiales para el registro de las diferentes actividades de la Comisin de prcticas Pre Profesionales. 3.6 APLICACIN DEL MODELO DE DESARROLLO EXTREME PROGRAMING (XP) 3.6.1. DESCRIPCIN DE LA ACTIVIDAD ASIGNADA. Esta actividad consisti en aplicar las fases del modelo de desarrollo XP para la construccin del software de prcticas pre-profesionales. Para la construccin, se consider las fases de Planificacin, Diseo, Codificacin y Pruebas. 3.6.2. POR QU USAR EL MODELO DE DESARROLLO XP PARA LA CONSTRUCCIN DEL SOFTWARE? Se utilizar el modelo de desarrollo XP debido a las caractersticas del proyecto dado que los requerimientos no se encuentran previamente definidos por el usuario, adems son de naturaleza cambiante. Adems 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 cmo funcionar el software. 3.6.3. PRCTICAS UTILIZADAS EN EL PROYECTO a. Planificacin incremental: Se realiz mediante la observacin directa los cuales fueron plasmados en historias de los usuarios retroalimentando la informacin de manera seguida. b. Diseo sencillo: Se llev a cabo el diseo 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. Refactorizacin: se refactoriz el cdigo tan pronto se hall el error e. Integracin continua: Al trmino de cada da, se integraba el avance realizado al sistema principal obteniendo un nico sistema integral. f. Programacin en parejas: se conform un grupo de desarrollo en la Facultad de ingeniera en informtica y sistemas, los cuales estuvieron apoyando activamente, realizando la programacin en parejas. g. Propiedad Colectiva: Los miembros del equipo tienen todo el cdigo disponible bajo subversin en un repositorio en internet que es mercurial de google code y el cliente tortoiseHg.
33
FIGURA 09: Cliente TortoiseHg para actualizar el repositorio al termino de los cambios y actualizar los cambios.
FUENTE: cliente tortoiseHg
Estndares de codificacin: se manej la codificacin en reas para organizar el cdigo y hacer ms sencillo en mantenimiento.
FIGURA 10: cdigo en reas.
FUENTE: IDE Netbean
3.7 FASE1: PLANEACIN En esta fase comprende el anlisis para el cual se hizo conversaciones directas con el Secretario de la Comisin de Prcticas pre profesional y el diseo para la construccin 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 ANALISTA PROGRAMADOR ASESOR
NOMBRES Alberto Lucio, ACEVEDO ALIAGA Ing. Ronald, IBARRA ZAPATA

34
3.7.2 HISTORIAS DE USUARIO: Tras el dilogo con el Secretario de la comisin de Practicas Pre Profesionales, se logr identificar requisitos iniciales para el desarrollo de las historias de usuario, a continuacin se detalla en el cuadro 04:
Cuadro 04. Requisitos iniciales
N R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12
R13 R14 R15 R16 R17 R18
R19 R20 R21 R22 R23 R24 R25 R26 R27 R28
DESCRIPCIN Para acceder al sistema cada usuario deber contar con un nombre de usuario el tipo de comisin, una contrasea registrados en el sistema. El sistema debe ser capaz de registrar una comisin anualmente con el tipo de comisin. El Sistema debe ser capaz de registrar a los integrantes de cada comisin, esto anualmente. El Sistema debe ser capaz de registrar a usuarios con roles de alumno y comisin. Cada medio ao el sistema debe actualizar los datos de los alumnos otorgados por OCDA (Oficina de Coordinacin Acadmica)-UNAS. Cada medio ao el sistema debe actualizar los datos de los docentes otorgados por OCDA (Oficina de Coordinacin Acadmica)-UNAS. El Sistema debe registrar a los practicantes con 160 crditos aprobados, por tres meses como mnimo. El sistema debe registrar la organizacin y el rea de labor del practicante. El sistema debe registrar los proyectos de cada practicante. El sistema debe registrar las actividades desempeadas por el practicante. El Sistema debe registrar asesores a los practicantes registrados. 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 prctica registrada, conjuntamente con un formato de resolucin para la firma del decano. El Sistema debe asignar supervisiones a los practicantes hasta por dos veces El Sistema debe registrar proyectos que los practicantes van a realizar El Sistema debe registrar los informes al cabo de la finalizacin de practicas El Sistema debe registrar sustentaciones despus de presentar informe. El sistema debe asignar 4 jurados que sern docentes para una sustentacin 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 sustentacin, conjuntamente con un formato de resolucin para la firma del decano. El sistema debe ampliar las prcticas si as se solicitara a la comisin. El sistema debe ampliar la sustentacin en casos de falta de tiempo. El sistema debe registrar una nueva sustentacin por desaprobacin. El Sistema debe emitir reportes de los practicantes y su historial. El Sistema debe emitir reportes de los asesores. El Sistema debe emitir reportes de supervisiones. El Sistema debe emitir reportes jurados. El Sistema debe emitir reportes documentos de gestin El Sistema debe emitir reportes de sustentaciones El sistema debe tener una biblioteca digital con los informes de prcticas aprobadas
FUENTE: Elaboracin Propia.
35
Los usuarios involucrados en el desarrollo del proyecto se detallan en el cuadro 05:

Cuadro 05. Clientes del proyecto
Cargo Presidente Secretario Vocal Equipo XP
Nombre William Marchand George Paucar Wilmer Bermdez Alberto Acevedo

Seudnimo Usuario CPPP Usuario CPPP Usuario CPPP Administrador CPPP
Los privilegios asignados a los usuarios se detallan en el cuadro 06:

Cuadro 06. Privilegios de los Usuarios
Tipos de Usuario PPP Miembro CPPP Alumno CPPP Administradores CPPP
Privilegios Altos Bajos Altos
En base al cuadro 04, se procede a recolectar las historias de usuario por cada requisito inicial, en conversacin directa con el usuario, en este caso explcitamente, con el secretario de la comisin explicndole 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 das a la recoleccin de los requisitos, puesto que los miembros de la comisin no cuentan con el tiempo necesario para poder agilizar el procedimiento. A continuacin se muestra el formato que se utiliz para la recoleccin de historias de usuario. Para ver todas las historias ver ANEXO 02.
Cuadro 07. Historia ingresando al Sistema
Historia de usuario Rol : Secretario CPPP Nombre historia: Ingresando al sistema (Autentificacin) Puntos de valor: 2 Descripcin: yo como secretario de la comisin deseo ingresar al sistema para realizar mis actividades, el sistema debe pedirme al inicio ingresar con mi nombre, contrasea, tipo de usuario y comisin. Observaciones: los tipos de usuario son miembro de la comisin, alumno y administrador.
36
El formato de las historias de usuario en realidad se maneja de diferentes formas segn bibliografas 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 adems 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 vendran a ser algunas excepciones y comentarios. Una vez planteadas las historias de usuario inciales, se procede a desarrollar el sistema, que se explica ms adelante con ms detalle, una vez desarrollado se pasa a una evaluacin del sistema segn las historias de usuario, el cual tambin tuvo un formato para la documentacin de las observaciones en cuestin de modificaciones al sistema segn los establecido en el anlisis de los requerimientos.
37
3.7.3 ESTIMACIN DE ESFUERZO ASOCIADOS A LAS HISTORIAS DE USUARIOS

Cuadro 08. Historia Estimaciones de esfuerzo asociadas a las historias de usuario
N H1. H2. H3. H4. H5. H6. H7. H8. H9. H10 H11. H12. H13. H14. H15. H16. H17. H18. H19. H20. H21. H22. H23. H24. H25 H26
HISTORIAS DE USUARIO Ingresando al sistema (Autentificacin) Registrando una comisin Registrando integrantes Registrando usuarios Registrando practicantes Registrando Empresas Registrando Proyecto de prctica. Registrando Actividades del Practicante Registrando asesores Generando oficio de Asignacin de Asesores. Registrando supervisiones Registrar ampliacin de prcticas. Registrando informes Registrando sustentaciones Registrando jurados Generando oficio de Asignacin de Jurados. Registrando informes digitales finales aprobados. Reportando practicantes. Reportando historial de practicantes. Reportando ranking de asesores. Reportando documento para supervisiones. Reportando ranking de jurados. Reporte para doc. De Gestin. Reportando sustentaciones. Realizar Repositorio Digital Consumir datos de OCDA
ESFUERZO (Horas) 7 7 7 7 7 8 7 8 7 6 7 7 7 7 7 7 7 6 6 6 6 6 6 6 4 10
FECHA INICIO / FECHA FIN 07-10-2013 / 08-10-2013 08-10-2013 / 10-10-2013 10-10-2013 / 12-10-2013 12-10-2013 / 15-10-2013 15-10-2013 / 17-10-2013 17-10-2013 / 18-10-2013 19-10-2013 / 21-10-2013 23-10-2013 / 23-10-2013 24-10-2013 / 26-10-2013 26-10-2013 / 29-10-2013 28-30-2013 / 30-10-2013 30-11-2013 / 01-11-2013 01-11-2013 / 04-11-2013 04-11-2013 / 06-11-2013 06-11-2013 / 08-11-2013 08-11-2013 / 11-11-2013 11-11-2013 / 12-11-2013 13-11-2013 / 19-11-2013 15-11-2013 / 21-11-2013 18-11-2013 / 23-11-2013 20-11-2013 / 24-11-2013 21-11-2013 / 23-11-2013 23-11-2013 / 25-11-2013 25-11-2013 / 26-11-2013 02-12-2013/03-12-2013 03-12-2013/07-12-2013
38
3.7.4 PLAN DE ENTREGA

Cuadro 09. Prioridades, riesgo, esfuerzo e interacciones
N H1. H2. H3. H4. H5. H6. H7. H8. H9. H10. H11. H12. H13. H14. H15. H16. H17. H18. H19. H20. H21. H22. H23. H24. H25. H26.
Nombre Historia de Usuario Ingresando al sistema (Autentificacin) Registrando una comisin Registrando integrantes Registrando usuarios Registrando practicantes Registrando empresas Registrando proyecto de prctica. Registrando actividades del practicante Registrando asesores Generando oficio de asignacin de asesores. Registrando supervisiones Registrar ampliacin de prcticas. Registrando informes Registrando sustentaciones Registrando jurados Generando oficio de Asignacin de Jurados. Registrando informes digitales finales aprobados. Reportando practicantes. Reportando historial de practicantes. Reportando ranking de asesores. Reportando documento para supervisiones. Reportando ranking de jurados. Reporte para doc. De Gestin. Reportando sustentaciones. Generando Repositorio Digital Consumir datos de OCDA
P Alta Alta Alta Alta Alta Alta Alta Alta Alta Media Media Alta Alta Alta Media Alta Alta Media Media Media Media Media Media Media Media Media
R Alta Alta Alta Alta Alta Media Media Media Media Media Media Media Media Media Media Media Media Media Media Media Media Media Media Media Baja Media
E 7 7 7 7 7 8 7 8 7 6 7 7 7 7 7 7 7 6 6 6 6 6 6 6 4 10
I 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 4 4
LEYENDA P= Prioridad. R= Riesgo E= Esfuerzo (en Horas) I= Iteracin
39
3.7.5 ANLISIS DE REQUISITOS MEDIANTE DIAGRAMAS DE PROCESOS Para el entendimiento y concepcin 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 cmo se designa a los miembros de la comisin; cuenta con participantes como el decano, consejo de facultad y la comisin de prcticas pre profesionales, en las que el decano propone a la comisin y el consejo de facultad es el encargado de ratificar para emitir su resolucin, caso contrario se volver a proponer una comisin:
FIGURA 11: Designacin De La Comisin De Practicas Pre Profesionales
FUENTE: Software Bizagi Process Modeler
El proceso de la FIGURA 12. Muestra como es el trmite del alumno para realizar la gestin de su prctica pre profesional, para ello inicia realizando la solicitud a decanatura para la emisin de carta de presentacin, si el practicante es aceptado por la institucin procede a enviar a decanatura los requisitos para realizar prcticas y estas son derivadas a la comisin para su evaluacin y aceptacin correspondiente.
FIGURA 12: Tramite Para Realizar Prcticas Pre Profesionales
40
El proceso de la FIGURA 13. Inicia en la comisin de PPP, asignando un supervisor para la inspeccin a las actividades del practicante, al finalizar el supervisor debe emitir un informe con la visita realizada.
FIGURA 13: Supervisin de la practicas pre profesionales
El proceso de la FIGURA 14. Inicia con la solicitud de ampliacin del practicante, hacia la empresa, y esta evala la peticin emitiendo una carta mediante el practicante a la comisin para su dictamen final.
FIGURA 14: Ampliacin de las practicas pre profesionales
41
El proceso de la FIGURA 15. Muestra la recepcin para el informe final, la comisin debe evaluar si el informe recepcionado, est dentro del plazo mximo de un mes, despus de las prcticas finalizadas, si cumple el requisito el practicante presenta 4 ejemplares a la decanatura para su derivacin a la CPPP y distribucin a los jurados.
FIGURA 15: Entrega del informe final
El proceso de la FIGURA 16. Muestra la asignacin de jurados, la decanatura enva el informe de prcticas a la comisin y esta asigna a los jurados mediante un oficio a decanatura para su revalidacin con resolucin por parte de esta ltima.
FIGURA 16: Asignacin de jurados
42
El proceso de la FIGURA 17. Inicia con la publicacin del cronograma por parte de la CPPP y si es necesario, por la cantidad del volumen del informe, se ampla a una nueva fecha, sino se sigue la sustentacin para su evaluacin.
FIGURA 17: Sustentacin de prcticas pre profesionales
El proceso de la FIGURA 18. La institucin donde se realiza las practicas emite una ficha de evaluacin o certificado para la entrega a los jurados, el jurado inicia la evaluacin y el practicante recepciona las observaciones para la correccin de su informe, firmando el acta , caso de no haber observaciones se firma el acta y la comisin la recepciona para su registro.
FIGURA 18: Evaluacin de sustentacin
43
3.7.6 DIAGRAMA DE CLASES Un diagrama de clases es un tipo de diagrama esttico que describe la estructura de un sistema mostrando sus clases, orientados a objetos. De acuerdo con la recoleccin de informacin sobre el proceso de prcticas pre profesionales se procedi al diseo del diagrama de clases se realiz usando la herramienta Rational Rosse 7, tal se muestra en la FIGURA 19.
44
FIGURA 19: Diagrama de clases
FUENTE: Software Rational Rosse
45
3.8 FASE 2: DISEO| 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>> HttpClient WebBrowser
<<device>> ApplicationServer
<<execution Enviroment>> GlashFish 3.2.1
spp pWebPages.jar
spppController.jar
spp pDao.jar
spppModel.jar
spppServices.jar
<<execution Eviro ment>> GlassFish Server 3.1.2
spp pDaemon
IntegrationWebService WSDL
<<device>> DataBaseServer <<executionEviroment>> Postgre 9.2

spp pSchema
<<device>> OCDA_DataBaseServer
<<execution Enviroment>> Postgre 9.2
AcademicDB
FUENTE: Elaborado en Software Microsoft Visio 2013
46
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 RELACIN El esquema que se presenta en la FIGURA 21, se obtuvo del anlisis previo que se hizo en la FIGURA 19, este esquema es el denominado Entidad Relacin, la que muestra las relaciones entre las entidades, las tablas de color naranja son las correspondientes a la Comisin De Prcticas Pre Profesionales, las tablas verdes pertenecen a la Comisin De Grados Y Ttulos, mientras que las celestes son las tablas comunes para todos los sistemas integrados en la base de datos denominada BDFIIS.
47
FIGURA 21: Diagrama de Entidad Relacin
FUENTE: Software MicroOlap
48
3.8.3 DICCIONARIO DE DATOS En el Figura 19 se muestra la relacin de Tablas, se har un breve comentario sobre la finalidad de cada tabla dentro de nuestra Base de Datos.
CUADRO 10: Tabla Estado
Descripcin: Registra los estados de las diferentes entidades durante los procesos, de acuerdo a las comisiones que a la que pertenece. State Nombre Tipo Descripcin id int4 Llave primaria, no nulo y auto incremental. name varchar(50) Nombre de estados, comisin (modificado, ratificado). name_entity varchar(25) Nombre de la entidad a la que corresponde el estado. detail varchar(300) Detalle de los estados.
Fuente: Elaboracin propia.
3.9 FASE3: CONSTRUCCIN 3.9.1 PROTOTIPOS GENERALES PARA EL DISEO Y CONSTRUCCIN Previo a empezar la fase 3, se har prototipos generales de diseo para la construccin de las interfaces, puesto que el desarrollo se est haciendo con el api de primer faces, no es necesario pensar tanto en el diseo ms si corresponde a una definicin general y las especificaciones a tomar en cuenta en cada tarea ya que adems, por buenas prcticas de diseo, se debe hacer uso del menor nmero de interfaces posibles, estandarizando y organizando las interfaces para las operaciones de negocio. Para todas la interfaces se tendr el siguiente esquema. Un ttulo 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 diseo)
49
Para el ingreso al sistema segn la figura 23:

FIGURA 23: esquema de acceso al sistema
Para el registro en el sistema segn la figura 24:

FIGURA 24: esquema de acceso al sistema
Para las vistas y listados segn la figura 25:

FIGURA 25: Diseo de vistas y listados
50
Para los procesos de practicantes segn la figura 26:

FIGURA 26: diseo para los procesos del practicante
3.9.2 PRIMERA ITERACCIN Las historias realizadas en esta iteracin son las siguientes: Ingresando al sistema (Autentificacin) Registrando una comisin Registrando integrantes Registrando usuarios Registrando practicantes Registrando Empresas Registrando Proyecto de prctica. Registrando Actividades del Practicante Para llevar a cabo el desarrollo de la primera iteracin, se desglos a las historias de usuario, esto permitir que el desarrollo se lleve a cabo de manera incremental asegurando la implementacin de la historia. Las tareas tienen el siguiente formato:
CUADRO 11: Diseo de la interfaz de acceso al sistema
Tarea Nombre Historia: Ingresando al Sistema Nombre tarea: Diseo de la interfaz de acceso al sistema Tipo de tarea: Disear Esfuerzo(Hora): 1 Fecha inicio: 07/10/13 Fecha fin: 07/10/13 Programador responsable: Equipo XP Descripcin: la interfaz debe tener dos cajas de texto, para el nombre de usuario y contrasea, un botn de ingreso, siendo todo la ventana de acceso un modal o ventana emergente.
Fuente: Elaboracin propia
Para ms detalle de las tareas de usuario VER ANEXO 03. 51
FIGURA 16: Cuadro de actividades para iteracin 1
FUENTE: Elaboracin en MS Project 2013
Como se muestra en la figura 16. El desarrollo se dio en 58 horas durante 15 das, con un trabajo de programacin diaria de aproximadamente 3.86 horas diarias. Resultados:
Figura 17. Formulario de acceso al sistema.
Figura 18. Interfaz de administracin (registro de nueva comisin)
52
Figura 19. Formulario de Registro de prcticas.
En la Figura 17, 18,19, el cumplimiento de las tareas e historias de usuario. 3.9.3. SEGUNDA ITERACCIN Las tareas realizadas en esta iteracin son las siguientes: Registrando asesores Generando oficio de Asignacin de Asesores. Registrando supervisiones Registrando informes Registrando sustentaciones Registrando jurados Generando oficio de Asignacin de Jurados. Registrar ampliacin de prcticas. Registrar Registrando informes digitales finales aprobados. Para llevar a cabo el desarrollo de la primera iteracin, se desglos a las historias de usuario, esto permitir que el desarrollo se lleve a cabo de manera incremental asegurando la implementacin de la historia. Las tareas tienen el siguiente formato:
53
CUADRO 12: Diseo de la interfaz del registro de Asesores
Tarea Nombre Historia: Registrando Asesores Nombre tarea: Diseo de la interfaz del registro de Asesores Tipo de tarea: Disear Esfuerzo(Hora): 1 Fecha inicio: 24/10/13 Fecha fin: 24/10/13 Programador responsable: Equipo XP Descripcin: la ventana tendr un caja de opciones para los docentes con opciones de bsqueda, la fecha de asignacin y un campo con mascara para el numero de oficio.
Para ms detalle de las tareas de usuario VER ANEXO 03.

Como se muestra en la figura 20. El desarrollo se dio en 62 horas durante 17 das, con un trabajo de programacin diaria de aproximadamente 3.64 horas diarias. Resultados:
Figura 21. Formulario de registro de asesor.
54
Figura 22. Interfaz de administracin (registro de nueva comisin)
Figura 23. Formulario de Registro de asignacin de jurados y las validaciones.
3.9.4. TERCERA ITERACCIN Las historias realizadas en esta iteracin 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 Gestin. Reportando sustentaciones.
55
Para llevar a cabo el desarrollo de la primera iteracin, se desglos a las historias de usuario, esto permitir que el desarrollo se lleve a cabo de manera incremental asegurando la implementacin de la historia. Las tareas tienen el siguiente formato:
CUADRO 13: Diseo de la interfaz de la Generacin de Reporte de los Practicantes
Tarea Nombre historia: Reportando Practicantes Nombre tarea: Diseo de la interfaz de la Generacin de Reporte de los Practicantes Tipo de tarea: Disear Esfuerzo(horas): 2.5 Fecha inicio: 13/11/13 Fecha fin: 13/11/13 Programador responsable: Equipo XP Descripcin: el reporte debe tener un encabezado con el nombre de la comisin y Facultad, debe mostrar en una grilla los detalles como nombres, asesor, fecha inicio prcticas, fecha final de prcticas.

Como se muestra en la Figura 24. El desarrollo de la tercera iteracin se dio en 42 horas durante 12 das, con un trabajo de programacin diaria de aproximadamente 2.47 horas diarias.
56
Resultados:
Figura 25: Diseo de los reportes en Ireport5.
Figura 26: Interfaz de los reportes con parmetros mediante modales
57
Figura 27: Salida de los reportes en formato pdf.
3.9.5. CUARTA ITERACCIN 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 iteracin, se desglos a las historias de usuario, esto permitir que el desarrollo se lleve a cabo de manera incremental asegurando la implementacin de la historia. Las tareas tienen el siguiente formato:
CUADRO 14: Diseo de la interfaz de la Generacin de Reporte de los Practicantes
Tarea Nombre historia: Reportando Practicantes Nombre tarea: Diseo de la interfaz de la Generacin de Reporte de los Practicantes Tipo de tarea: Disear Esfuerzo(horas): 2.5 Fecha inicio: 13/11/13 Fecha fin: 13/11/13 Programador responsable: Equipo XP Descripcin: el reporte debe tener un encabezado con el nombre de la comisin y Facultad, debe mostrar en una grilla los detalles como nombres, asesor, fecha inicio prcticas, fecha final de prcticas.
58

Como se muestra en la Figura 28. El desarrollo de la cuarta iteracin se dio en 14 horas durante 4 das, con un trabajo de programacin diaria de aproximadamente 3.5 horas diarias. Resultados:
Figura 29: Interfaz del repositorio Digital de los informes de PPP.
59
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 Tiempo (Da/Me Actividad realizada Observaciones (horas) s/Ao) 21/08/13 Fase de comunicacin con el 1.5 Planteamientos de secretario de la CPPP(Entrevista desarrollo de software directa) 22/08/13 Levantamiento y revisin del 30 Desarrollado en PHP y sistema de prcticas preMysql, limitados a profesionales v1.0 (2010) Internet Explorer, cdigo desordenado, sin ningn framework de desarrollo, desactualizado en cuanto al nuevo reglamento de PPP 2012. 28/08/13 Consultas a docentes de la 5 Propuestas de desarrollo especialidad(Ing. Ronald Ibarra, de software Ing. Brian Soto) lineamientos de desarrollo de software segn CTICUNAS. 60
Fecha Tiempo (Da/Me Actividad realizada Observaciones (horas) s/Ao) 02/09/13 Reunin con el secretario de la 1 Definicin y alcance del CPPP proyecto de prcticas pre profesionales. 03/09/13 Exploracin de actividades de la 4 Familiarizacin con las comisin. actividades de la CPPP 04/09/13 Revisin de los materiales 5 Reconocimiento de utilizados por la CPPP documentos, libros de acta, reglamento 2012. 06/09/13 Recoleccin de historias de 15 Entrevistas observaciones usuarios y anlisis documental. 16/09/13 Modelado BPMN, para el 5 Uso de software BPMN correcto enfoque de las historias Bizagi Process Modeler. a los procesos de negocio. 17/09/13 Reunin con el secretario de la 1 Definicin de las CPPP actividades de las P.P.P 18/09/13 Diseo del diagrama de clases 7 Uso de la Herramiento Rational Rosse 23/09/13 Diseo de la base de datos 5 Diseo de diagrama de entidad relacin en MicroOLAP for Postgres. 24/09/13 Reunin con el secretario de la 1 Recomendaciones sobre la CPPP base de datos 25/09/13 Rediseo de la base de datos 3 Recreacin de la base de datos 26/09/13 Diseo del diagrama de 4 Uso de la herramiento arquitectura Visio 2010 27/09/13 Definicin de las historias de 4 Apoyo del secretario de la usuario CPPP. 30/09/13 Definicin des iteraciones 3 Establecimiento de las historias de usuario por iteracin Desarrollo de la historia 7 Diseo, codificacin y 07/10/13 Ingresando al sistema validacin. (Autentificacin). 08/10/13 Revisin la historia Ingresando al 0.5 Revisin de la sistema (Autentificacin). funcionalidad 08/10/13 Correccin de errores detectados 0.5 Validando la historia de usuario 08/10/13 Desarrollo de la historia 7 Diseo, codificacin y Registrando una comisin. validacin. 10/10/13 Revisin de la historia 0.5 Revisin de la Registrando una comisin. funcionalidad 10/10/13 Correccin de errores detectados. 0.5 Validando la historia de usuario 61
Fecha (Da/Me Actividad realizada s/Ao) 10/10/13 Desarrollo de la historia Registrando integrantes. 12/10/13 Revisin de la historia Registrando integrantes. 12/10/13 Correccin de errores destacados
Tiempo (horas) 7 0.5 0.5
Observaciones Diseo, codificacin validacin. Revisin de funcionalidad Validando la historia usuario Diseo, codificacin validacin. Revisin de funcionalidad Validando la historia usuario Diseo, codificacin validacin. Revisin de funcionalidad Validando la historia usuario Diseo, codificacin validacin. Revisin de funcionalidad Validando la historia usuario Diseo, codificacin validacin. Revisin de funcionalidad y la de y la de y la de y la de y
12/10/13 Desarrollo de la historia 7 Registrando usuarios. 15/09/13 Revisin de la historia 0.5 Registrando usuarios. 15/09/13 Correccin de errores destacados 0.5 15/09/13 Desarrollo de la historia 7 Registrando practicantes. 17/10/13 Revisin de la historia 0.5 Registrando practicantes. 17/10/13 Correccin de errores destacados 0.5 17/10/13 Desarrollo de la historia 8 Registrando Empresas. 18/10/13 Revisin de la historia 0.5 Registrando Empresas. 18/10/13 Correccin de errores destacados 0.5 19/10/13 Desarrollo de la historia 7 Registrando Proyecto de prctica. 21/10/13 Revisin de la historia 0.5 Registrando Proyecto de prctica. 21/10/13 Correccin de errores destacados 0.5 21/10/13 Desarrollo de la historia 8 Registrando Actividades del Practicante. 23/10/13 Revisin de la historia 0.5 Registrando Actividades del Practicante. 23/10/13 Correccin de errores destacados 0.5 24/10/13 Desarrollo de la Registrando asesores. 26/10/13 Revisin de la Registrando asesores historia 7 historia 0.5 62
la
Validando la historia de usuario Diseo, codificacin y validacin. Revisin de funcionalidad la
Validando la historia de usuario Diseo, codificacin y validacin. Revisin de la funcionalidad
Fecha (Da/Me Actividad realizada s/Ao) 26/10/13 Correccin de errores destacados
Tiempo (horas) 0.5
Observaciones Validando la historia de usuario Diseo, codificacin y validacin. Revisin de funcionalidad Validando la historia usuario Diseo, codificacin validacin. Revisin de funcionalidad Validando la historia usuario Diseo, codificacin validacin. Revisin de funcionalidad Validando la historia usuario Diseo, codificacin validacin. Revisin de funcionalidad Validando la historia usuario Diseo, codificacin validacin. Revisin de funcionalidad Validando la historia usuario Diseo, codificacin validacin. Revisin de funcionalidad la
26/10/13 Desarrollo de la historia 6 Generando oficio de Asignacin de Asesores. Revisin de la historia 0.5 28/10/13 Generando oficio de Asignacin de Asesores. 28/10/13 Correccin de errores destacados 0.5 28/10/13 Desarrollo de la historia 7 Registrando supervisiones. 30/10/13 Revisin de la historia 0.5 Registrando supervisiones. 30/10/13 Correccin de errores destacados 0.5 30/10/13 Desarrollo de la historia 7 Registrando informes. 01/11/13 Revisin de la historia 0.5 Registrando informes. 01/11/13 Correccin de errores destacados 0.5 01/11/13 Desarrollo de la historia 7 Registrando sustentaciones. 04/11/13 Revisin de la historia 0.5 Registrando sustentaciones. 04/11/13 Correccin de errores destacados 0.5 04/11/13 Desarrollo de la historia 7 Registrando jurados. 06/11/13 Revisin de la historia 0.5 Registrando jurados. 06/11/13 Correccin de errores destacados 0.5 06/11/13 Desarrollo de la historia 6 Generando oficio de Asignacin de Jurados. 08/11/13 Revisin de la historia 0.5 Generando oficio de Asignacin de Jurados. 08/11/13 Correccin de errores destacados 0.5 08/11/13 Desarrollo Registrar de la historia 7 ampliacin de 63
de y la de y la de y la de y la de y
la
Validando la historia de usuario Diseo, codificacin y validacin.
Fecha (Da/Me s/Ao)
Actividad realizada
Tiempo (horas)
Observaciones
prcticas. 11/11/13 Revisin de la historia Registrar 0.5 ampliacin de prcticas. 11/11/13 Correccin de errores destacados 0.5 11/11/13 Desarrollo de la historia 7 Registrar informes finales aprobados. 12/11/13 Revisin de la historia Registrar 0.5 informes finales aprobados digitales. 12/11/13 Correccin de errores destacados 0.5 13/11/13 Desarrollo de la historia 6 Reportando practicantes. 15/11/13 Revisin de la historia 0.5 Reportando practicantes. 15/11/13 Correccin de errores destacados 0.5 15/11/13 Desarrollo de la historia 6 Reportando historial de practicantes. 18/11/13 Revisin de la historia 0.5 Reportando historial de practicantes. 18/11/13 Correccin de errores destacados 0.5 18/11/13 Desarrollo de la historia 6 Reportando ranking de asesores. 20/11/13 Revisin de la historia 0.5 Reportando ranking de asesores. 20/11/13 Correccin de errores destacados 0.5 20/11/13 Desarrollo de la historia 6 Reportando documento para supervisiones. 21/11/13 Revisin de la historia 0.5 Reportando documento para supervisiones. 21/11/13 Correccin de errores destacados 0.5 22/11/13 Desarrollo de la historia 6 64
Revisin de la funcionalidad Validando la historia de usuario Diseo, codificacin y validacin. Revisin de funcionalidad la
Validando la historia de usuario Diseo, codificacin y validacin. Revisin de la funcionalidad Validando la historia de usuario Diseo, codificacin y validacin. Revisin de funcionalidad la
Validando la historia de usuario Diseo, codificacin y
Fecha (Da/Me s/Ao)
Actividad realizada
Tiempo (horas)
Observaciones validacin. Revisin de la funcionalidad Validando la historia de usuario Diseo, codificacin y validacin. Revisin de la funcionalidad Validando la historia de usuario Diseo, codificacin y validacin. Revisin de la funcionalidad Validando la historia de usuario Diseo, codificacin y validacin. Revisin de la funcionalidad Validando la historia de usuario Diseo, codificacin y validacin. Revisin de la funcionalidad Validando la historia de usuario Prueba finales a cargo del presidente de la CPPP Coordinacin de las actividades adicionales Entrega del informe final
Reportando ranking de jurados. 23/11/13 Revisin de la historia 0.5 Reportando ranking de jurados. 23/11/13 Correccin de errores destacados 0.5 23/11/13 Desarrollo de la historia Reporte 6 para Doc. De Gestin. 24/11/13 Revisin de la historia Reporte 0.5 para Doc. De Gestin. 24/11/13 Correccin de errores destacados 0.5 25/11/13 Desarrollo de la historia 6 Reportando sustentaciones. 26/11/13 Revisin de la historia 0.5 Reportando sustentaciones. 26/11/13 Correccin de errores destacados 0.5 30/11/13 Generando un repositorio Digital 03/12/13 Revisin de Generando un repositorio Digital 03/12/13 Correccin de errores de Generando un repositorio Digital 03/12/13 Desarrollo de la historia Consumir datos de OCDA. 06/12/13 Revisin de la historia Consumir datos de OCDA. 06/12/13 Correccin de errores destacados 06/12/13 Revisin general de funcionalidad del sistema Reunin del equipo XP 11/12/13 Entrega final del proyecto 4 0.5 0.5 10 0.5 0.5
la 10 1 0
65
3.10 FASE4: PRUEBAS Las pruebas funcionales que se realizaron a la aplicacin se encuentran separados por cada historia de usuario, se especifica el modo de utilizacin de la aplicacin y los posibles estados de error que pueden darse, as como los mensajes de aviso/error/confirmacin que debe emitir la aplicacin 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 Cndor Fernandez,Diccson Muos Villalobos, Jos Derlin Malpartida Arvalo, Nigel
Entorno:
Se desarroll las pruebas en una mquina servidor de prueba (con ip 192.168.1.224), en el cual se arm una pequea 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 Hernn -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
Introduccin correcta
Condicin de ejecucin
Entrada Resultado esperado
Conformidad (C)
Fuente: MODELO DE DESARROLLO AGIL- Schenone Marcelo Hernn -2004
El tiempo de pruebas que se realizo fue de 10 horas durante 3 das. A continuacin se muestra el resultado del trabajo realizado.
Figura 32: Pruebas de funcionalidad.
Fuente: Imagen tomada en el entorno de prueba
66
CUADRO 18: PRUEBA DE LA PRIMERA ITERACCIN
HISTO INTRODUCCION CORRECTA RIA H1. El usuario debe ingresar los campos de usuario, contrasea, eligiendo su tipo de comisin y dar clic en el botn ingresar. H2. El usuario administrador debe ingresar la fecha de inicio y final de la gestin de la comisin, cuidando que la fecha final sea mayor que la fecha inicial por un ao. El nmero de resolucin debe ser la misma con la que se cre la comisin por disposicin del decano. El motivo de la creacin no es obligatorio. Una vez llenado los campos hacer clic en el botn Guardar. 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 botn Guardar.
CONDICIN DE EJECUCIN Conexin del sistema a la base de datos PostgreSQL
ENTRADA
RESULTADO ESPERADO
La interfaz de acceso al sistema contiene dos campos de texto, uno para el Nombre del Usuario y el otro para la Contrasea y un botn Entrar. Conexin del La interfaz tiene cuatro campos, sistema a la base un botn Guardar y otro para de datos cancelar. PostgreSQL El usuario administrador ingresar la fecha de inicio y fin de la gestin, el nmero de la resolucin de su creacin y el motivo por el cual fue creado (este ltimo es opcional). Luego hacer clic el botn Guardar para registrar la comisin.
Si el usuario se identifica con xito la aplicacin ingresar al men principal, contrario debe aparecer mensaje de error datos incorrectos vuelva a intentar por favor Si los datos son ingresados son correctos el sistema mostrar un mensaje de xito indicando Gestin guardado con xito y en caso contrario mostrar un mensaje de alerta indicando Introducir los datos que faltan
H3.
Conexin del sistema a la base de datos PostgreSQL
La interfaz tiene 4 campos de texto autocompletables con bsqueda, 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 validacin.
67
H4.
H5.
El nombre y contrasea 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 botn Guardar El usuario SPPP debe buscar por el cdigo al alumno consultando a la webservices de OCDA para su validacin de 160 crditos aprobados.
La interfaz cuenta con 2 campos de texto y un checklist, de los cuales uno es para elegir a los integrantes o alumnos de comisin, por medio de la web services de OCDA. El segundo campo para introducir su contrasea y por ltimo en el chekclist debe seleccionar el tipo de usuario. Clic en Guardar. La interfaz cuenta un texto para escribir el cdigo y con un botn para validar. El usuario SPPP debe ingresar el cdigo con el requisito de los 00(dos ceros) al inicio y luego clic en validar y aceptar la bsqueda de la ventana emergente para confirmar validacin. La interfaz cuanta con un cuadro desplegable de opciones con bsqueda incluida, un botn para aumentar empresas por medio de una ventana desplegable la cual cuenta con 10 campos y un botn guardar. La interfaz est dentro del 68
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 validacin.
Si encuentra al estudiante, debe escribir en los datos del practicante como nombre apellidos y crditos aprobados, en caso contrario aparecer un mensaje alumno no encontrado en OCDA
H6.
H7.
El usuario SPPP debe desplegar las opciones de empresa para la prctica, en caso de no encontrarlas debe hacer clic en el botn registro de empresas, el cual se mostrara en una pantalla emergente y finalmente clic en guardar. El usuario SPPP debe registrar
Si se encuentra a la empresa se debe continuar con el registro de prcticas ,caso contrario aumentar una empresa, seleccionarla y validar seleccin no vaca con un mensaje de error Empresa: Error de validacin.se necesita un valor En caso de llenar los campos el
Conexin del
los campos e ttulo de proyecto, sistema a la base resumen, pudindose explayar de datos en detalle. PostgreSQL
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 botn que genere una ventana emergente por ser varias las funciones.
registro de nuevos practicantes, cuenta con dos reas de texto y son de carcter obligatorio por ser de inters para continuar con el registro de una prctica. La interfaz cuanta con una caja de texto para las funciones, para registrar una nueva funcin debe seleccionar en el botn a lado derecho del campo de texto y hacer clic en Guardar.
sistema le permitir registrar al practicante en caso contrario validara con el siguiente error Titulo : Error de validacin Resumen: Error de validacin.- necesita un valor De asignar funciones correctamente le permitir guardar con xito las prcticas, en caso de no llenar ninguna funcin se saldr el siguiente error Funciones: Error de validacin
69
CUADRO 19: PRUEBA DE LA SEGUNDA ITERACCIN
HISTORIA H9.
INTRODUCCION CORRECTA 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 hipervnculo de Asignar asesor, seleccionar al docente, la fecha de asignacin, el nmero de oficio y el nombre del decano. 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. 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 hipervnculo de supervisin de prctica por docente. El usuario SPPP debe ir al men
CONDICION DE ENTRADA EJECUCION Conexin del sistema La interfaz cuenta con un campo de a la base de datos opciones para seleccionar le grado PostgreSQL del docente, un campo de texto con bsqueda para el asesor, un campo de fecha con un calendario y un campo ms para el nombre del decano por ultimo clic en guardar. Conexin del sistema La interfaz muestra un cuadro con a la base de datos el resumen de los datos del PostgreSQL practicante, en el nombre del asesor aparece un hipervnculo hacer clic para generar oficio.
RESULTADO ESPERADO
Al llenar todos los campos de manera correcta nos saldr un mensaje de confirmacin 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 validacin
H10.
Al hacer clic en el hipervnculo se debe abrir una nueva pestaa, el cual muestre el oficio por el cual el practicante fue asignado el asesor y la respectiva autorizacin.
H11.
H12.
Conexin del sistema La interfaz cuenta con un campo de a la base de datos texto con bsqueda para el asesor, PostgreSQL un campo de fecha con un calendario, un campo enmascarado con el nmero de oficio y un rea de texto para el detalle de la supervisin. Conexin del sistema La interfaz cuanta con una ventana
Al llenar todos los campos de manera correcta nos saldr un mensaje de confirmacin supervisin guardado con xito, caso contrario nos debe aparecer un mensaje de error para los campos nulos. Que diga Error nombre del campo :Error de validacin En caso que el practicante ya super las
70
principal, buscar al practicante luego ir a opciones (figura de la tuerca) y clic en Ampliar prctica.
a la base de datos PostgreSQL
H13.
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 hipervnculo de entrega de informe de practicante. 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 hipervnculo de asignacin de jurados.
emergente que describe al practicante y el historial de sus ampliaciones adems de mostrar un campo seleccinale con el nmero de meses a ampliar y una breve descripcin. 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.
dos ampliaciones como mximo no debe salir la opcin de ampliacin, caso contrario debe ampliar satisfactoriamente con el mensaje Prcticas ampliadas. 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 validacin.
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
La interfaz tiene 4 opciones para elegir los grados de los jurados y 4 campos de texto autocompletables con bsqueda para elegir a los docentes, en la parte superior cuanta la fecha, lugar y hora que se les est asignado a la sustentacin luego debe hacer clic en guardar. 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 sustentacin para
Si las introducciones son correctas y no hay ningn campo en blanco el mensaje ser Jurados y sustentacin asignada, caso contrario saldr el campo con el error que ocurri.
Si las introducciones fueron correctas se registrar la evaluacin con xito caso contrario saldr el campo con el error que ocurri.
71
H16.
H17.
hipervnculo de calificar resultados de sustentacin. 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 asignacin de jurados. 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 hipervnculo de registrar informe final aprobado.
las posteriores correcciones luego debe hacer clic en guardar. Conexin del sistema La interfaz muestra un cuadro con a la base de datos el resumen de los datos del PostgreSQL practicante, en el nombre del asesor aparece un hipervnculo hacer clic para generar oficio.
Al hacer clic en el hipervnculo se debe abrir una nueva pestaa, el cual muestre el oficio por el cual el practicante fue asignado el asesor y la respectiva autorizacin.
La interfaz cuenta con un botn para seleccionar el origen del archivo en formato .pdf con un mximo de 30MB(MegaBytes)
.Al hacer clic en el botn 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
72
CUADRO 20: PRUEBA DE LA TERCERA ITERACCIN
HISTORIA
INTRODUCCION CORRECTA El usuario del SPPP debe ir al men reportes y hacer clic en la opcin practicantes.
H18.
CONDICION DE EJECUCION Conexin del sistema a la base de datos PostgreSQL
ENTRADA La interfaz muestra una ventana emergente para el ingreso de dos parmetros que sern las fechas en la que se requiera el reporte del practicante. La interfaz muestra una ventana emergente para el ingreso de un parmetro que es el cdigo del practicante. La interfaz muestra una ventana emergente para el ingreso de dos parmetros que sern las fechas en la que se requiera el reporte del ranking de asesores. La interfaz muestra una ventana emergente para el ingreso de un parmetro que es el cdigo del practicante.
RESULTADO ESPERADO
H19.
El usuario del SPPP debe ir al men reportes y hacer clic en la opcin historial de practicantes.
H20.
El usuario del SPPP debe ir al men reportes y hacer clic en la opcin ranking de asesores.
Al ingresar correctamente los datos de las fechas para ver el reporte se mostrar una nueva pestaa 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. Al ingresar correctamente los datos de las fechas para ver el reporte se mostrar una nueva pestaa con el reporte esperado y las opciones para convertir a diferentes formatos o imprimir directamente. Al ingresar correctamente los datos de las fechas para ver el reporte se mostrar una nueva pestaa 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 opcin Documento para supervisiones
Al ingresar correctamente los datos de las fechas para ver el reporte se mostrar una nueva pestaa con el reporte esperado y las opciones para convertir a diferentes formatos o imprimir directamente.
73
H22.
El usuario del SPPP debe ir al men reportes y hacer clic en la opcin ranking de jurados.
H23.
El usuario del SPPP debe ir al men reportes y hacer clic en la opcin documentos de gestin.
H24.
El usuario del SPPP debe ir al men reportes y hacer clic en la opcin reporte de sustentaciones.
La interfaz muestra una ventana emergente para el ingreso de dos parmetros que sern las fechas en la que se requiera el reporte del ranking de jurados. Conexin del sistema a La interfaz muestra una la base de datos ventana con las PostgreSQL opciones de los formatos de documentos a imprimir mostrndose en una nueva pestaa del navegador. Conexin del sistema a La interfaz muestra una la base de datos ventana emergente PostgreSQL para el ingreso de dos parmetros que sern las fechas en la que se requiera el reporte de las sustentaciones.
74
CUADRO 21: PRUEBA DE LA CUARTA ITERACCIN
HISTORIA
INTRODUCCION CORRECTA 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 hipervnculo de registrar informe final aprobado.
H25.
CONDICIN DE ENTRADA EJECUCIN Conexin del sistema a La interfaz muestra una ventana con tres la base de datos botones, uno para buscar el archivo en la PostgreSQL. maquina local, otro para subirlo y otro para guardarlo registrando la fecha y las observaciones. Adems el formato ser .pdf y el peso mximo 30MB. Se debe actualizar el men biblioteca con el nuevo archivo subido. Conexin al Local Apache. servidor Cuenta con un botn en la parte de registrar nuevo practicante, para validar en OCDA los datos del cdigo ingresado, adems el cdigo es validado con 2 ceros delante. Ejemplo 0020090318.
RESULTADO ESPERADO
H26.
Consumir datos de OCDA
Si se cumpli el con formato y el tamao 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. Si la conexin es satisfactoria traer los datos del alumno como nombres y crditos 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 das 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.
75
CONCLUSIONES
1. Se logr desarrollar el sistema de Prcticas pre profesionales SPPP V1.0, con el uso del modelo XP (Programacin Extrema) con la tecnologa Java Web, haciendo uso de frameworks de desarrollo, aplicando el modelo de Vista Controlador, PrimeFaces en la capa de presentacin, Hibernate en la capa de modelo y Spring para la Inyeccin de dependencias, en un periodo de 96 das. 2. Se logr recolectar las 26 historias de usuarios en un total de 22 das, el trabajo de campo se hizo inter diario por la misma carga laboral de los docentes miembros de la comisin. 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 anlisis de los documentos de gestin, normativo y mediante observacin directa, entrevistas informales, se logr como resultado, disear 8 procesos. 5. Se logr construir la base de datos, bajo el gestor PostgresQL 9.2. de la comisin de prcticas pre profesionales, con lenguaje de escritura en ingls, adems de ello est sirviendo para la integracin con las dems comisiones para tener una base de datos integral para la Facultad de ingeniera en informtica y Sistemas. 6. Se construy el software en base a las tareas planificadas con tecnologas 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 estn desfasadas, adems de no alinearse a lo que se quiere conseguir a fututo mediante estandarizacin de lenguajes de desarrollo propuestos por CTIC-UNAS, se procedi a la construccin desde un inicio ajustando al nuevo reglamento 2013
76
9. El SPPP versin 1.0 est desarrollado para satisfacer las necesidades funcionales de la Comisin de Prcticas Pre Profesionales de la Facultad de Ingeniera en Informtica y Sistemas por las siguientes razones: a. b. c. d. e. f. Creacin y administracin de Comisiones. Creacin y administracin de Integrantes de una comisin. Creacin y administracin de Usuarios del SPPP versin 1.0 para una comisin. Creacin y supervisin textual de los Practicantes. Asignacin de asesores, jurados y fechas de sustentaciones a los practicantes. Diversos reportes de los practicantes, ranking de asesores, informes, jurados, sustentaciones, repositorio digital. g. Diversos documentos digitales de autorizacin de prcticas y asignacin de asesor, designacin de jurados, jurado de sustentacin, ficha de inscripcin, actas de sustentacin, remisin de informes finales y dictamen de ampliacin. h. Usabilidad, confiabilidad, mantenibilidad y eficiencia. 10. Se utiliz con un sistema de control de versiones que est en lnea en google.code esto sirvi para actualizar remotamente en un solo almacn central, cada cambio que se haca.
77
RECOMENDACIONES
1. Que se oficialice el uso del software por parte de la comisin mediante resolucin de consejo de Facultad. 2. Habilitar un servidor de aplicaciones, configurar, instalar, implementar y complementar el SPPP versin 1.0 en el Centro de Tecnologa de Informacin y Comunicacin-UNAS para su funcionamiento. Si es posible asignar estas tareas a otro estudiante con motivo de sus Prcticas Pre Profesionales. 3. Antes del despliegue realizar nuevas pruebas funcionales con la presencia de los miembros de la comisin y alumnos, para mayor conformidad. 4. Realizar una capacitacin en el manejo de las funcionalidades del SPPP versin 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 algn documento fsico o virtual para luego solicitar el desarrollo del SPPP versin 2.0. 6. Que se siga esta lnea de desarrollo para la integracin de las comisiones as como el sistema de trmite documentario de la Facultad de ingeniera en informtica 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 creacin 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 prctica.
78
BIBLIOGRAFA
1. Dr. Wilson Castillo Soto, E. (2001). Normas Tcnicas para la Redaccin y Presentacin de Documentos Cientficos. Tingo Mara, Per. 47 p. 2. CORTIZO PREZ, J., EXPSITO 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 lnea : http://www.javascriptya.com.ar/. 4. INGENIERA DEL SOFTWARE Roger Pressman.6th.Ed.McGraw-Hill.pdf Pg.45 5. PROGRAMACIN 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. PGINA OFICIAL DE PRIMEFACES http://www.primefaces.org/showcase/ui/csvBasic.jsf disponible en lnea
7. INGENIERA DEL SOFTWARE Roger Pressman.6th.Ed.McGraw-Hill.pdf Pg.106 8. PROGRAMACIN EXTREMAIngenieria.de.Software.Ian.Sommerville.7ma.Edicion.PRENTICE-HALL.Pg.373 9. SERRA MACHADO DAVID Estudio del servidor de aplicaciones Glassfish y de las aplicaciones J2EEpg. 182 disponible. [En lnea]: ddd.uab.cat/pub/trerecpro/.../SerraManchadoDavidR-ETISa2009-10.pdf 10. PAGINA OFICIAL DE POSTGRESQL http://www.postgresql.org.es/sobre_postgresql disponible [En lnea]:
11. PGINA OFICIAL DE POSTGRESQL disponible [En lnea]: https://www.java.net/
79
OTRAS ACTIVIDADES REALIZADAS DURANTE LA PRCTICA PRE PROFESIONAL.

1. Configuracin y administracin 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 polticas a configurar por ejemplo: que los usuarios no puedan insertar dispositivos perifricos a las maquinas como medida a la infeccin descontrolada de virus.
80
2. Administracin del servicio de File Share en Windows server 2008R2. Para complementar el servicio de controlador de dominio y como solucin a la poltica del acceso a dispositivos perifricos, se propuso la configuracin de archivos compartidos mapeados en cada computadora de los usuarios del laboratorio de sistemas, asi puedan compartir archivos sin necesidad del usb. 3. Configuracin y administracin 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 pginas, por lo que se gener un desorden, en consecuencia se propuso la configuracin de un servidor proxi squid en Linux (Centos 6.4), que sirvi para controlar el acceso a pginas sociales, juegos, videos entre otros. 4. Administracin de la Red e internet del laboratorio de sistemas.
Se administr la red interna del laboratorio asegurando conectividad para el servicio continuo del laboratorio, adems el acceso a los usuario inalmbricos que no estaban en el dominio, mediante control por filtrado MAC.
5. Apoyo en la administracin general del laboratorio de sistemas. Apoyo en la atencin de los servicios del laboratorio de Sistemas a los docentes y alumnos de la Facultad de ingeniera en informtica y sistemas.
81
ANEXOS
82

Informe PPP

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Informe PPP

Hochgeladen von

Copyright:

Verfügbare Formate

[Dictamen del asesor]

[Certificado de prcticas emitido por la institucin donde se Desarrollaron las PPP]

A todos mis amigos y compaeros de la Facultad de Ingeniera en Informtica y Sistemas.

1.2.1. 1.2.2. 1.2.3. 1.2.4.

2.6.1. 2.6.2. 2.7. 2.8. 2.9. 2.10.

3.4.1. 3.4.2. 3.5 3.6

3.7.1 3.7.2 3.7.3 3.7.4 3.7.5 3.7.6

3.8.1 3.8.2 3.8.3 3.9

3.9.1 3.9.2 3.9.3. 3.9.4. 3.9.5. 3.9.6. 3.10 3.10.

FASE4: PRUEBAS ................................................................................................... 66 RESUMEN DE LAS PRUEBAS: .............................................................................. 75

1.1.5. ORGANIGRAMA ESTRUCTURAL

COMISIN DE GRAD. Y TITULOS

COM. DE TRAS. SEGUI. CURRI.

COM. DE INVESTI. Y PUBLICACIN

COM. ACT. CULT. SOCIALES

COM. PROYEC. UNIVERSITARIA

COM. HORARI. Y MATRCULA

COM. DE EVAL. Y CAP. DOCENTE

DEPARTAMENTO ACADMICO DE CIENCIAS EN INFORMTICA Y SISTEMAS

REAS DE CIENCIAS BASICAS

REA DE COMPUT. E INFORMTICA

FUENTE: Manual de Obligaciones y Funciones de la FIIS

FUENTE: Elaboracin Propia

CAPTULO II MARCO TERICO

Fuente: Ingeniera del Software Roger Pressman 6th.Ed.McGraw-Hill

La ingeniera de software abarca un proceso, mtodos y herramientas.

Ingeniera del Software Roger Pressman.6th.Ed.McGraw-Hill.pdf Pg.45

Dividir las historias en tareas

Entregar el softw are

Desarrollar, probar e integrar el softw are

Fuente: Programacin extrema- Ingenieria.de.Software.-.Ian.Sommerville.7ma.Edicion

Programacin extrema- Ingenieria.de.Software.-.Ian.Sommerville.7ma.Edicion.PRENTICE-HALL.Pg.373

Cuadro 01. Prcticas de la Programacin Extrema.

PRINCIPIO O PRCTICA Planificacin incremental

Metforas Diseo sencillo Desarrollo previamente probado

Usar Estndares de Codificacin

historias de usuario v alores criterios de la prueba de iteraccin plan de iteraccin

prueba de unidad integracin continua

Fuente: Ingeniera del Software Roger Pressman 6th.Ed.McGraw.

http://wiki.monagas.udo.edu.ve/index.php/Metodolog%C3%ADas_SCRUM_y_XP#METODOLOG.C3.8DA_ XP_.28EXTREME_PROGRAMMING.29 Metodologas XP

Observacin: Fuente: http://www.xp.com/trabajos51/programacion-extrema/programacion-extrema2

http://www.microscience.pe/20/tecnologia-web 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

http://www.hosting-peru.net/que_es_intranet.html 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

http://www.postgresql.org/about/news/1465/ http://elbauldelprogramador.com/articulos/los-10-mejores-frameworks-gratis-de-aplicaciones-web/ 24 http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/101

FIGURA 08: Componentes JSF en la pgina de configuracin de Glassfish

CAPTULO III ACTIVIDADES REALIZADAS

FUENTE: cliente tortoiseHg

FUENTE: IDE Netbean

CARGO ANALISTA PROGRAMADOR ASESOR

NOMBRES Alberto Lucio, ACEVEDO ALIAGA Ing. Ronald, IBARRA ZAPATA

N R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12

R13 R14 R15 R16 R17 R18

Los usuarios involucrados en el desarrollo del proyecto se detallan en el cuadro 05:

Cargo Presidente Secretario Vocal Equipo XP

Nombre William Marchand George Paucar Wilmer Bermdez Alberto Acevedo

Seudnimo Usuario CPPP Usuario CPPP Usuario CPPP Administrador CPPP

Los privilegios asignados a los usuarios se detallan en el cuadro 06:

Tipos de Usuario PPP Miembro CPPP Alumno CPPP Administradores CPPP

Privilegios Altos Bajos Altos

FUENTE: Elaboracin Propia

3.7.3 ESTIMACIN DE ESFUERZO ASOCIADOS A LAS HISTORIAS DE USUARIOS

FUENTE: Elaboracin Propia.

3.7.4 PLAN DE ENTREGA