informe ppp

82
1 [Dictamen del asesor]

Upload: jahack

Post on 29-Dec-2015

51 views

Category:

Documents


0 download

DESCRIPTION

informe

TRANSCRIPT

1

[Dictamen del asesor]

2

[Certificado de prácticas emitido por la institución donde se Desarrollaron las PPP]

{El certificado deberá indicar claramente las fechas de inicio y fin de las prácticas, así como el área o funciones desarrolladas

3

4

DEDICATORIA

A Dios, que hace posible cada uno de

mis pasos que doy como persona y

profesional.

A mis Padres y hermana, quienes

me han inculcado el deseo de

superación bajo cualquier

circunstancia así como su amor y

apoyo incondicional.

A mis Docentes de la Facultad de

Ingeniería en informática y sistemas

quienes siempre están prestos a

apoyar a sus estudiantes.

5

AGRADECIMIENTO A:

Dios, por la vida que me da y las enseñanzas que dejó, cuidando seguir sus pasos.

A mis padres, por estar conmigo en todos los momentos de mi vida, alentándome a

seguir adelante

A los integrantes la Comisión de Prácticas Pre Profesionales: Ing. William George Paucar

Palomino por brindarme su apoyo y confianza.

Al Ing. Ronald Ibarra Zapata, por tener la gentileza de ser mi asesor y de brindarme todo

su apoyo y guía para el desarrollo de mi práctica pre profesional.

A todos los demás docentes de la Facultad de Ingeniería en Informática y Sistemas

quienes compartieron conmigo sus conocimientos durante 5 años de estudio.

A todos mis amigos y compañeros de la Facultad de Ingeniería en Informática y

Sistemas.

6

ÍNDICE

INTRODUCCIÓN ..................................................................................................................... 9

CAPÍTULO I .......................................................................................................................... 10

DE LA ORGANIZACIÓN ......................................................................................................... 10

1.1. DE LA INSTITUCIÓN ............................................................................................... 10

1.1.1. NOMBRE ....................................................................................................... 10

1.1.2. RESEÑA HISTÓRICA ....................................................................................... 10

1.1.3. DESCRIPCIÓN ................................................................................................ 10

1.1.4. UBICACIÓN GEOGRÁFICA............................................................................... 10

1.1.1. VISIÓN .......................................................................................................... 11

1.1.2. MISIÓN ......................................................................................................... 11

1.1.3. OBJETIVOS .................................................................................................... 11

1.1.4. ESTRUCTURA ORGÁNICA ............................................................................... 11

1.1.5. ORGANIGRAMA ESTRUCTURAL ...................................................................... 12

1.2. DE LA COMISIÓN DE PRÁCTICAS PRE PROFESIONALES ........................................... 13

1.2.1. RESEÑA HISTÓRICA ....................................................................................... 13

1.2.2. DESCRIPCIÓN ................................................................................................ 13

1.2.3. OBJETIVO ...................................................................................................... 13

1.2.4. ORGANIGRAMA DE LA COMISIÓN .................................................................. 13

CAPÍTULO II ..................................................................................................................... 14

MARCO TEÓRICO................................................................................................................. 14

2.1. ¿QUÉ SON LAS PRÁCTICAS PRE PROFESIONALES? .................................................. 14

2.2. INGENIERÍA DE SOFTWARE ................................................................................... 14

2.3. ¿QUÉ ES UN MODELO DE SOFTWARE? .................................................................. 15

2.4. ¿QUÉ ES UNA METODOLOGÍA DE SOFTWARE? ...................................................... 15

2.5. ¿QUÉ SON MODELOS ÁGILES DE PROCESOS DE SOFTWARE? .................................. 15

2.6. PROGRAMACIÓN EXTREMA O XP (EXTREME PROGRAMING) ................................. 16

2.6.1. FASES DE XP .................................................................................................. 18

2.6.2. VARIABLES DE XP .......................................................................................... 21

2.7. ¿QUÉ SON LAS TECNOLOGÍAS WEB? ...................................................................... 22

2.8. ¿QUÉ ES UNA PÁGINA WEB? ................................................................................. 22

2.9. ¿QUÉ ES UN SITIO WEB? ....................................................................................... 22

2.10. ¿QUÉ ES UNA INTRANET? .................................................................................. 23

7

2.11. ¿QUÉ ES UN SERVIDOR WEB? ............................................................................ 23

2.12. ¿QUÉ ES UN SERVIDOR WEB LOCAL? ................................................................. 23

2.13. ¿QUÉ ES UNA APLICACIÓN WEB? ....................................................................... 23

2.14. ¿QUÉ SON SERVICIOS WEB? .............................................................................. 24

2.15. ¿QUÉ ES UN ENTORNO DE DESARROLLO INTEGRADO? ....................................... 24

2.16. ¿QUÉ ES UN SERVIDOR DE APLICACIONES? ........................................................ 25

2.17. PLATAFORMA JAVA .......................................................................................... 25

2.18. JAVA EE ............................................................................................................ 26

2.19. ¿QUÉ ES UNA BASE DE DATOS? ......................................................................... 27

2.20. ¿QUÉ ES UN GESTOR DE BASE DE DATOS? ......................................................... 27

2.21. ¿QUÉ ES POSTGRESQL? ..................................................................................... 27

2.22. ¿QUÉ ES MODELADO DE BASE DE DATOS? ......................................................... 28

2.23. ¿QUÉ ES UN FRAMEWORK DE DESARROLLO? ..................................................... 28

2.24. ¿QUÉ ES JAVA PRIMEFACES? ............................................................................. 29

2.25. ¿QUÉ ES HIBERNATE? ........................................................................................ 29

CAPÍTULO III ........................................................................................................................ 31

ACTIVIDADES REALIZADAS ................................................................................................... 31

3.1 SITUACIÓN ACTUAL DE LA COMISIÓN DE PRÁCTICAS PRE PROFESIOANALES .......... 31

3.2 IDENTIFICACIÓN DEL PROBLEMA ........................................................................... 31

3.3 ANTECEDENTES .................................................................................................... 31

3.4 OBJETIVOS ........................................................................................................... 32

3.4.1. GENERAL ....................................................................................................... 32

3.4.2. ESPECÍFICOS .................................................................................................. 32

3.5 JUSTIFICACIÓN ..................................................................................................... 32

3.6 APLICACIÓN DEL MODELO DE DESARROLLO EXTREME PROGRAMING (XP) ............. 33

3.6.1. DESCRIPCIÓN DE LA ACTIVIDAD ASIGNADA. ................................................... 33

3.6.2. ¿POR QUÉ USAR EL MODELO DE DESARROLLO XP PARA LA CONSTRUCCIÓN DEL

SOFTWARE? ................................................................................................................. 33

3.6.3. PRÁCTICAS UTILIZADAS EN EL PROYECTO ....................................................... 33

3.7 FASE1: PLANEACIÓN ............................................................................................. 34

3.7.1 EQUIPO DE DESARROLLO: .............................................................................. 34

3.7.2 HISTORIAS DE USUARIO: ............................................................................... 35

3.7.3 ESTIMACIÓN DE ESFUERZO ASOCIADOS A LAS HISTORIAS DE USUARIOS ......... 38

3.7.4 PLAN DE ENTREGA ........................................................................................ 39

3.7.5 ANÁLISIS DE REQUISITOS MEDIANTE DIAGRAMAS DE PROCESOS ................... 40

3.7.6 DIAGRAMA DE CLASES................................................................................... 44

8

3.8 FASE 2: DISEÑO .................................................................................................... 46

3.8.1 ARQUITECTURA DEL SISTEMA ........................................................................ 46

3.8.2 DIAGRAMA DE ENTIDAD RELACIÓN ............................................................... 47

3.8.3 DICCIONARIO DE DATOS ................................................................................ 49

3.9 FASE3: CONSTRUCCIÓN ........................................................................................ 49

3.9.1 PROTOTIPOS GENERALES PARA EL DISEÑO Y CONSTRUCCIÓN ........................ 49

3.9.2 PRIMERA ITERACCIÓN ................................................................................... 51

3.9.3. SEGUNDA ITERACCIÓN .................................................................................. 53

3.9.4. TERCERA ITERACCIÓN .................................................................................... 55

3.9.5. CUARTA ITERACCIÓN ..................................................................................... 58

3.9.6. DIARIO DE ACTIVIDADES:............................................................................... 60

3.10 FASE4: PRUEBAS ................................................................................................... 66

3.10. RESUMEN DE LAS PRUEBAS: .............................................................................. 75

CONCLUSIONES ................................................................................................................... 76

RECOMENDACIONES ........................................................................................................... 78

BIBLIOGRAFÍA ..................................................................................................................... 79

ANEXOS .............................................................................................................................. 82

ANEXO 01. GASTOS ADMINISTRATIVOS DE LAS PRÁCTICAS

ANEXO 02. HISTORIAS DE USUARIO

ANEXO 03. TAREAS DE DESARROLLO DE HISTORIAS DE USUARIO

ANEXO 04. DICCIONARIO DE DATOS

ANEXO 05. LISTA DE MATERIALES

ANEXO 06. CRONOGRAMA DE ACTIVIDADES

ANEXO 07. CRONOGRAMA DE ACTIVIDADES POR HORAS

ANEXO 08. REGLAMENTO DE PRÁCTICAS PRE PROFESIONALES 2012

ANEXO 09 DOCUMENTOS DE LA COMISION DE PPP

ANEXO 10. MANUAL DE USUARIO

9

INTRODUCCIÓN

La Facultad de Ingeniería en Informática y Sistemas de la Universidad

Nacional Agraria de la Selva, cuenta con nueve comisiones permanentes del órgano de

apoyo a las actividades administrativas.

Una de las comisiones es la Comisión de Prácticas Pre Profesionales

encargada de planificar, coordinar y supervisar por medios adecuados la ejecución y la

correspondiente evaluación de las prácticas pre profesionales de los estudiantes.

La inexistencia de herramientas que permita automatizar la gestión y control

de las Prácticas Pre Profesionales, sumado a ello, la carga laboral, tanto académica como

administrativa de los integrantes de la comisión, hacen que el trabajo se dificulte.

El presente informe de Prácticas Pre Profesionales describe el desarrollo de

un software exclusivo para la Comisión de Prácticas Pre Profesionales denominado

“SPPP” versión 1.0, con el firme objetivo de apoyar a los procesos de registros y

controles de aquellos estudiantes que están realizando sus Prácticas Pre Profesionales

en la Facultad de Ingeniería en Informática y Sistemas.

El “SPPP” versión 1.0 está desarrollado siguiendo la metodología de

Programación Extrema la cual se sujeta a la investigación preliminar hecha a los

miembros de la comisión, al reglamento de Prácticas Pre Profesionales.

10

CAPÍTULO I

DE LA ORGANIZACIÓN 1.1. DE LA INSTITUCIÓN

1.1.1. NOMBRE

Facultad de Ingeniería en Informática y Sistemas (FIIS).

1.1.2. RESEÑA HISTÓRICA

La Facultad de Ingeniería en Informática y Sistemas. fue creada por

resolución Nº 003-99-AU-R-UNAS de fecha 04 de septiembre de 1999, considerando el

continuo cambio de los procesos empresariales y tecnológicos del mundo de hoy, que

hacen necesarios el reenfoque del pensamiento organizacional orientado al

pensamiento sistémico.

1.1.3. DESCRIPCIÓN

La FIIS, es una unidad fundamental de organización y formación académica y

profesional. Está integrada por sus profesores, graduados, estudiante y personal

administrativo que contribuye a la gestión académica. Tiene como finalidad la formación

profesional, la investigación, la proyección social, la producción de bienes y prestación

de servicios. Está constituido por el Departamento Académico de Ciencias, Informática y

Sistemas, Áreas Académicas, Laboratorios, Gabinetes, Comisiones y otros.

1.1.4. UBICACIÓN GEOGRÁFICA

Departamento :Huánuco

Provincia :Leoncio Prado

Distrito :Rupa Rupa

Dirección :Av. Universitaria s/n

Entidad :Facultad de Ingeniería en Informática y Sistemas Figura 01: Ubicación Geográfica

FUENTE: https://google.maps311

11

1.1.1. VISIÓN

“FIIS, líder en el desarrollo de la amazonia y la nación”.

1.1.2. MISIÓN

“Formar profesionales en informática y sistemas capaces de solucionar

problemas complejos aplicando el enfoque sistémico, preparados para dirigir funciones

para el desarrollo de sistemas integrales útiles y actuar éticamente en su interacción con

la sociedad”.

1.1.3. OBJETIVOS

Brindar una sólida formación en el área de ciencia y tecnología con alta

capacitación en las ciencias exactas, los procesos y sistemas

tecnológicos.

Incentivar el espíritu crítico de la realidad regional, nacional e

internacional.

Despertar la capacidad para desarrollarse independientemente.

Contribuir con soluciones a los problemas identificados en el entorno,

con el apoyo de la investigación y de la interacción social.

1.1.4. ESTRUCTURA ORGÁNICA

Órgano de dirección

Consejo de Facultad

Decanato

Órganos de apoyo

Secretaria de Facultad

Secretaria de DACIS

Extensionista

Comisiones Permanentes

- Comisión de Grados y Títulos

- Comisión de Evaluación y Capacitación Docente

- Comisión de Traslado y Seguimiento Curricular

- Comisión de Prácticas Pre Profesionales

- Comisión de Matricula/Horario/Consejería

- Comisión de Presupuesto

- Comisión de Actividades Culturales y Sociales

- Comisión de Investigación y Publicaciones

- Comisión de Proyección Universitaria

Órganos de Línea

Departamento Académico de Ciencias, Informática y Sistemas

- Jefe de Departamento Académico

12

1.1.5. ORGANIGRAMA ESTRUCTURAL

FIGURA 02:”Organigrama de la FIIS”

DECANO

SECRETARIA

UNIDAD DE EXTENSION

COMISIÓN DE

GRAD. Y TITULOS

COM. DE TRAS.

SEGUI. CURRI.

COMISIÓN DE PRESUPUESTO

COMISIÓN DE PRÁCTICAS. P. P.

COM. DE INVESTI.

Y PUBLICACIÓN

COM. ACT. CULT.

SOCIALES

COM. PROYEC. UNIVERSITARIA

COM. HORARI. Y MATRÍCULA

COM. DE EVAL. Y

CAP. DOCENTE

SECRETARIA

ÁREA DE

SISTEMAS

ÁREA DE COMPUT.

E INFORMÁTICA

ÁREAS DE

CIENCIAS BASICAS

DEPARTAMENTO ACADÉMICO DE CIENCIAS EN INFORMÁTICA Y

SISTEMAS

FUENTE: “Manual de Obligaciones y Funciones de la FIIS”

13

1.2. DE LA COMISIÓN DE PRÁCTICAS PRE PROFESIONALES

1.2.1. RESEÑA HISTÓRICA

Se crea la Comisión de Prácticas Pre Profesionales a propuesta del decano de

la FIIS, la misma que se ratifica o modifica en Consejo de Facultad y se oficializa

mediante la Resolución correspondiente. En lo sucesivo cuando se refiera a esta

comisión se escribirá las siglas CPPP.

1.2.2. DESCRIPCIÓN

La CPPP está integrado por cuatro (04) profesores de la FIIS: Presidente,

Secretario, y dos Vocales. La CPPP se encarga de planificar, coordinar y supervisar por

medios adecuados de la ejecución y la correspondiente evaluación de las Prácticas Pre

Profesionales.

La vigencia de la designación de miembros de la CPPP es de un año,

pudiendo extenderse por otro periodo.

Los integrantes deben ser docentes a tiempo completo y/o a dedicación

exclusiva de cualquier categoría.

1.2.3. OBJETIVO

Planificar, coordinar y supervisar por medios adecuados de la ejecución y la

correspondiente evaluación de las Prácticas Pre Profesionales.

1.2.4. ORGANIGRAMA DE LA COMISIÓN

FIGURA 03:”Organigrama de la comisión de PPP”

FUENTE: “Elaboración Propia”

DECANO

COMISIÓN DE

PPP

PRESIDENTE VOCALSECRETARIO

14

CAPÍTULO II

MARCO TEÓRICO

2.1. ¿QUÉ SON LAS PRÁCTICAS PRE PROFESIONALES?

Se entiende por Prácticas Pre Profesionales a las actividades que realiza el

estudiante, para aplicar y fortalecer los conocimientos adquiridos durante su formación

profesional, consolidando la base conceptual adquirida, haciendo investigación, análisis,

diseño e implementación de soluciones.

VER ANEXO 08.”REGLAMENTO DE PRÁCTICAS PRE PROFESIONALES FIIS

2012”

2.2. INGENIERÍA DE SOFTWARE1

Según Fritz Bauer en una conferencia fundamental definió que la ingeniería

del software es el establecimiento y uso de principios sólidos de la ingeniería para

obtener económicamente un software confiable y que funcione de modo eficiente en

máquinas reales.

Otras definiciones:

Ingeniería del Software es la aplicación práctica del conocimiento científico

al diseño y construcción de programas de computadora y a la documentación asociada

requerida para desarrollar, operar (funcionar) y mantenerlos. Se conoce también como

desarrollo de software o producción de software (Bohem, 1976).

La aplicación de un enfoque sistemático, disciplinado y cuantificable al

desarrollo, operación (funcionamiento) y mantenimiento del software; es decir, la

aplicación de ingeniería al software. (IEEE, 1993).

La ingeniería del software es una tecnología estratificada. Como se muestra

en la figura 3, cualquier enfoque de la ingeniería (incluido el de la ingeniería de

software) debe estar sustentado en un compromiso con la calidad.

FIGURA.04: Estratos de la ingeniería de software.

Fuente: Ingeniería del Software – Roger Pressman 6th.Ed.McGraw-Hill

La ingeniería de software abarca un proceso, métodos y herramientas.

1 Ingeniería del Software – Roger Pressman.6th.Ed.McGraw-Hill.pdf Pág.45

15

El Proceso.- Es el elemento que mantiene juntos los estratos de la tecnología

y que permite el desarrollo relacional y a tiempo del software de computadora. Así

mismo, forma parte de la base para el control de la gestión de los proyectos de software

y establece el contexto en el cual se aplican los métodos técnicos, se generan los

productos del trabajo (modelos, documentos, reportes, formatos, etc.), se establecen los

fundamentos, se asegura la calidad, y el cambio apropiadamente.

Los Métodos.- Proporcionan los “cómo” técnicos para construir software.

Abarcan un amplio espectro de tareas que incluyen la comunicación, el análisis de

requisitos, el modelo del diseño, la construcción del programa, la realización de pruebas

y el soporte.

Las Herramientas.- Proporcionan el soporte automatizado o semi-

automatizado para el proceso y los métodos. Cuando las herramientas se integran de

forma que la información que cree una de ellas pueda usarla otra, se dice que se

establecido un sistema para el soporte del desarrollo de software, que con frecuencia se

denomina ingeniería del software asistida por computadora.

2.3. ¿QUÉ ES UN MODELO DE SOFTWARE? 2

Un modelo es un esquema o una estructura que nos indica cuales son los

pasos a seguir dentro del ciclo de vida de una aplicación. Sin embargo no nos dice que

límites tiene cada uno de los pasos, ni que se debe cumplir para pasar de uno a otro, o al

siguiente.

2.4. ¿QUÉ ES UNA METODOLOGÍA DE SOFTWARE?3

Es un marco de trabajo usado para estructurar, planificar y controlar el

proceso de desarrollo en sistemas de información.

2.5. ¿QUÉ SON MODELOS ÁGILES DE PROCESOS DE SOFTWARE?4

Los modelos de proceso ágil se diseñaron para cumplir con los cuatros

aspectos claves de la ingeniería de software como son: la importancia de la organización

propia de los equipos, los cuales controlan el trabajo que realizan; comunicación y

colaboración entre los miembros del equipo y entre los profesionales y sus clientes; un

reconocimiento de que el cambio representa una oportunidad; y un especial cuidado en

la entrega rápida del software que satisfaga al cliente.

Existe un amplio espectro de modelos ágiles de proceso, cada uno en busca

de su aceptación dentro de la comunidad del desarrollo de software. Entre ellos

tenemos a la Programación Extrema (XP), Desarrollo adaptivo de software (DAS),

2 http://raulortega.blogspot.com/2006/12/para-los-lectores-de-este-blog-los.html-Software Libre 3 http://www.um.es/docencia/barzana/IAGP/Iagp2.html - Apuntes. Ingeniería del Software 4 Ingeniería del Software – Roger Pressman.6th.Ed.McGraw-Hill.pdf Pág.106

16

Método de desarrollo de sistemas dinámicos (MDSD), Melé, Cristal, Desarrollo

conducido por características (DCC), Modelo ágil (MA).

2.6. PROGRAMACIÓN EXTREMA O XP (EXTREME PROGRAMING)5

La Programación Extrema (XP) es posiblemente el método ágil más conocido

y ampliamente utilizado. El nombre fue acuñado por Beck (Beck.2000) debido a que el

enfoque fue desarrollado utilizando buenas prácticas reconocidas, como el desarrollo

iterativo, y con la participación del cliente en niveles <<extremos>>.

En la programación extrema, todos los requerimientos se expresan como

escenarios (llamados historias de usuario), los cuales se implementan directamente con

una serie de tareas.

Los programadores trabajan en parejas y desarrollan pruebas para cada

tarea antes de escribir código. Todas las pruebas deben ejecutarse satisfactoriamente

cuando el código nuevo se integra al sistema. Existe un pequeño espacio de tiempo

entre las entregas del sistema. La Figura 05. Ilustra el proceso del modelo XP para

producir un incremento del sistema que se está desarrollando.

La programación extrema implica varias prácticas, resumidas en el cuadro 1.

Que se ajustan a los principios de los métodos ágiles:

El desarrollo incremental se lleva a cabo a través de entregas del sistema

pequeñas y frecuentes y por medio de un enfoque para la descripción de

requerimientos basado en las historias de cliente o escenarios que pueden ser la base

para el proceso de planificación.

El interés en las personas, en vez de en los procesos, se lleva a cabo a través

de la programación en parejas, la propiedad colectiva del código del sistema, y un

proceso de desarrollo sostenible que no implique excesivas jornadas de trabajo.

El cambio se lleva a cabo a través de las entregas regulares del sistema, un

desarrollo previamente probado y la integración continua.

El mantenimiento de la simplicidad se lleva a cabo a través de la

refactorización constante para mejorar la calidad del código y la utilización de diseños

sencillos que no prevén cambios futuros en el sistema.

FIGURA 05.El ciclo de entrega en la programación extrema

Fuente: Programación extrema- Ingenieria.de.Software.-.Ian.Sommerville.7ma.Edicion

5 Programación extrema- Ingenieria.de.Software.-.Ian.Sommerville.7ma.Edicion.PRENTICE-HALL.Pág.373

Evaluar el sistemaDesarrollar, probar e

integrar el softw areEntregar el softw are

Planificar entregaDividir las historias en

tareas

Seleccionar las

historias de usuario

para esta entrega

17

Cuadro 01. Prácticas de la Programación Extrema.

PRINCIPIO O PRÁCTICA DESCRIPCIÓN

Planificación incremental

Los requerimientos se registran en tarjetas de historias y las historias a incluir en una entrega se determinan según el tiempo disponible y su propiedad relativa. Los desarrolladores dividen estas Historias en <<Tareas>> de desarrollo.

Entregas pequeñas

El mínimo conjunto útil de funcionalidad que proporcione valor de negocio se desarrolla primero. Las entregas del sistema son frecuentes e incrementalmente añaden funcionalidad a la primera entrega.

Metáforas Guiar todo el desarrollo con una historia simple y compartida de cómo funciona todo el sistema.

Diseño sencillo Sólo se lleva a cabo el diseño necesario para cumplir los requerimientos actuales.

Desarrollo previamente probado

Se utiliza un sistema de pruebas de unidad automatizado para escribir pruebas para nuevas funcionalidades antes de que éstas se implementen.

Refactorización

Se espera que todos los desarrolladores refactoricen el código continuamente tan pronto como encuentren posibles mejoras en el código. Esto conserva el código sencillo y mantenible.

Programas en parejas

Los desarrolladores trabajan en parejas, verificando cada uno el trabajo del otro y proporcionando la ayuda necesaria para hacer siempre un buen trabajo.

Propiedad colectiva

Las parejas de desarrolladores trabajan en todas las áreas del sistema, de modo que no desarrollen islas de conocimientos y todos los desarrolladores posean todo el código. Cualquiera puede cambiar cualquier cosa.

Semana de 40 horas Trabajar no más de 40 horas semanales como regla. Nunca trabajar horas extras durante dos semanas consecutivas.

Integración continua En cuanto acaba el trabajo en una tarea, se integra en el sistema entero. Después de la integración, se deben pasar al sistema todas las pruebas de unidad.

Cliente presente

Debe estar disponible al equipo de la XP un representante de los usuarios finales del sistema (el cliente) a tiempo completo. En un proceso de la programación extrema, el cliente es miembro del equipo de desarrollo y es responsable de formular al equipo los requerimientos del sistema para su implementación.

Usar Estándares de Codificación

Los programadores escriben todo el código de acuerdo con reglas que enfatizan la comunicación a través del mismo.

Fuente: Elaboración Propia.

18

2.6.1. FASES DE XP6

Según Roger Pressman en su libro 6th Edición sobre Ingeniería del Software

nos habla de 4 Fases: Planeación, diseño, codificación y pruebas. Un ejemplo claro se

muestra en la figura 06.

FIGURA 06. Proceso de la Programación Extrema

Fuente: Ingeniería del Software – Roger Pressman 6th.Ed.McGraw.

1° FASE: PLANIFICACIÓN DEL PROYECTO:

Historia de usuario:

El primer paso de cualquier proyecto que siga el modelo XP es definir las

historias de usuario con el cliente. Las historias de usuario tienen la misma finalidad que

los casos de uso pero con algunas diferencias: Constan de 3 o 4 líneas escritas por el

cliente en un lenguaje no técnico sin hacer mucho hincapié en los detalles; no se debe

hablar ni de posibles algoritmos para su implementación ni de diseños de base de datos

adecuados, etc. Son usadas para estimar tiempos de desarrollo de la parte de la

aplicación que describen. También se utilizan en la fase de pruebas, para verificar si el

programa cumple con lo que especifica la historia de usuario. Cuando llega la hora de

implementar una historia de usuario, el cliente y los desarrolladores se reúnen para

concretar y detallar lo que tiene que hacer dicha historia. El tiempo de desarrollo ideal

para una historia de usuario es entre 1 y 3 semanas. Un ejemplo de historia de usuario

se muestra en el cuadro 02.

6 http://wiki.monagas.udo.edu.ve/index.php/Metodolog%C3%ADas_SCRUM_y_XP#METODOLOG.C3.8DA_XP_.28EXTREME_PROGRAMMING.29 – Metodologías XP

diseño

planeación

codif icación

codif icación

incremento del sof tware

v alocidad calculada del

proy ecto

historias de usuario

v alores criterios de la

prueba de iteracción

plan de iteracción

soluciones pico

prototipos

programación en

pareja

prueba de unidad

Lanzamientoprueba de unidad

integración continua

19

Cuadro 02. Modelo propuesto para una historia de usuario

Historia de Usuario

Nombre Historia de Usuario:

Rol:

Valor: Iteración asignada:

Descripción:

Observación:

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

Las Historias de Usuario tienen tres aspectos:

Tarjeta: en ella se almacena suficiente información para identificar y detallar

la historia.

Conversación: cliente y programadores discuten la historia para ampliar los

detalles (verbalmente cuando sea posible, pero documentada cuando se requiera

confirmación).

Release Planning:

Después de tener ya definidas las historias de usuario es necesario crear un

plan de publicaciones, en inglés "Release plan", donde se indiquen las historias de

usuario que se crearán para cada versión del programa y las fechas en las que se

publicarán estas versiones. Un "Release plan" es una planificación donde los

desarrolladores y clientes establecen los tiempos de implementación ideales de las

historias de usuario, la prioridad con la que serán implementadas y las historias que

serán implementadas en cada versión del programa. (*Release plan: Planificación de

publicaciones).

Iteraciones:

Todo proyecto que siga la metodología XP se ha de dividir en iteraciones de

aproximadamente 3 semanas de duración. Al comienzo de cada iteración los clientes

deben seleccionar las historias de usuario definidas en el "Release planning" que serán

implementadas. También se seleccionan las historias de usuario que no pasaron el test

de aceptación que se realizó al terminar la iteración anterior. Estas historias de usuario

son divididas en tareas de entre 1 y 3 días de duración que se asignarán a los

programadores.

La Velocidad del Proyecto:

Es una medida que representa la rapidez con la que se desarrolla el

proyecto; estimarla es muy sencillo, basta con contar el número de historias de usuario

que se pueden implementar en una iteración; de esta forma, se sabrá el cupo de

historias que se pueden desarrollar en las distintas iteraciones. Usando la velocidad del

proyecto controlaremos que todas las tareas se puedan desarrollar en el tiempo del que

dispone la iteración. Es conveniente reevaluar esta medida cada 3 ó 4 iteraciones y si se

aprecia que no es adecuada hay que negociar con el cliente un nuevo "Release Plan".

20

Programación en Parejas:

La metodología XP aconseja la programación en parejas pues incrementa la

productividad y la calidad del software desarrollado.

El trabajo en pareja involucra a dos programadores trabajando en el mismo

equipo; mientras uno codifica haciendo hincapié en la calidad de la función o método

que está implementando, el otro analiza si ese método o función es adecuado y está

bien diseñado. De esta forma se consigue un código y diseño con gran calidad.

Reuniones Diarias:

Es necesario que los desarrolladores se reúnan diariamente y expongan sus

problemas, soluciones e ideas de forma conjunta. Las reuniones tienen que ser fluidas y

todo el mundo tiene que tener voz y voto.

2° FASE: Diseño.

Diseños Simples:

La metodología XP sugiere que hay que conseguir diseños simples y

sencillos. Hay que procurar hacerlo todo lo menos complicado posible para conseguir un

diseño fácilmente entendible e implementarle que a la larga costará menos tiempo y

esfuerzo desarrollar.

Glosarios de Términos:

Usar glosarios de términos y una correcta especificación de los nombres de

métodos y clases ayudará a comprender el diseño y facilitará sus posteriores

ampliaciones y la reutilización del código.

Riesgos:

Si surgen problemas potenciales durante el diseño, XP sugiere utilizar una

pareja de desarrolladores para que investiguen y reduzcan al máximo el riesgo que

supone ese problema.

Funcionabilidad extra:

Nunca se debe añadir funcionalidad extra al programa aunque se piense que

en un futuro será utilizada. Sólo el 10% de la misma es utilizada, lo que implica que el

desarrollo de funcionalidad extra es un desperdicio de recursos.

Refactorizar:

Refactorizar es mejorar y modificar la estructura y codificación de códigos ya

creados sin alterar su funcionalidad. Refactorizar supone revisar de nuevo estos códigos

para procurar optimizar su funcionamiento. Es muy común rehusar códigos ya creados

que contienen funcionalidades que no serán usadas y diseños obsoletos.

21

3° FASE: CODIFICACIÓN.

El cliente es una parte más del equipo de desarrollo; su presencia es

indispensable en las distintas fases de XP. A la hora de codificar una historia de usuario

su presencia es aún más necesaria. No olvidemos que los clientes son los que crean las

historias de usuario y negocian los tiempos en los que serán implementadas. Antes del

desarrollo de cada historia de usuario el cliente debe especificar detalladamente lo que

ésta hará y también tendrá que estar presente cuando se realicen los test que verifiquen

que la historia implementada cumple la funcionalidad especificada. Programar bajo

estándares mantiene el código consistente y facilita su comprensión y escalabilidad.

4° FASE: PRUEBAS.

Uno de los pilares de la metodología XP es el uso de test para comprobar el

funcionamiento de los códigos que vayamos implementando. El uso de los test en XP es

el siguiente:

Se deben crear las aplicaciones que realizarán los test con un entorno de

desarrollo específico para test.

Hay que someter a test las distintas clases del sistema omitiendo los

métodos más triviales.

Se deben crear los test que pasarán los códigos antes de implementarlos; en

el apartado anterior se explicó la importancia de crear antes los test que el código.

Un punto importante es crear test que no tengan ninguna dependencia del

código que en un futuro evaluará.

Como se comentó anteriormente los distintos test se deben subir al

repositorio de código acompañados del código que verifican.

Test de aceptación. Los test mencionados anteriormente sirven para evaluar

las distintas tareas en las que ha sido dividida una historia de usuario.

2.6.2. VARIABLES DE XP

Coste: Máquinas, especialistas y oficinas

Tiempo: Total y de Entregas

Calidad: Externa e Interna

Alcance: Intervención del cliente

22

2.7. ¿QUÉ SON LAS TECNOLOGÍAS WEB?

Un conjunto de soluciones y servicios que nos permite asesorar, crear y

consolidar proyectos de manera inteligente destacando:7

Navegadores web:8

Mozilla Firefox Konqueror sobre Linux Seamonkey

Google Chrome Lynx sobre linux Shiira

Galeon Opera Midori

Internet Explorer Safari Meleon

Servidores web:

CERN httpd Glassfish

Servidor HTTP Apache Tomcat

IIS Servidor HTTP Cherokee

Otras tecnologías:

JSP JSF

DHTML HIBERNATE

PHP .NET

2.8. ¿QUÉ ES UNA PÁGINA WEB?9

Empezando por su definición, consideramos una página web a un

documento disponible en Internet, o World Wide Web (www), codificado según sus

estándares y con un lenguaje específico conocido como HTML. Es algo a lo que estamos

acostumbrados a acceder si leemos este artículo pero no todos conocen realmente su

funcionamiento.

2.9. ¿QUÉ ES UN SITIO WEB?10

En inglés Website o Web Site, un sitio Web es un sitio (localización) en la

World Wide Web que contiene documentos (páginas web) organizados jerárquicamente

(generalmente documentos en formato html, php, asp, etc.). Cada documento (página

web) contiene texto y/o gráficos que aparecen como información digital en la pantalla

de un ordenador. Un sitio puede contener una combinación de gráficos, texto, audio,

vídeo, y otros materiales dinámicos o estáticos.

7 http://www.microscience.pe/20/tecnologia-web 8 http://norfipc.com/internet/navegadores-web.html 9 http://tendenciasweb.about.com/od/nociones-basicas/a/Que-Es-Una-Pagina-Web.htm 10 http://www.masadelante.com/faqs/sitio-web

23

Cada sitio web tiene una página de inicio (en inglés Home Page), que es el

primer documento que ve el usuario cuando entra en el sitio web poniendo el nombre

del dominio de ese sitio web en un navegador. El sitio normalmente tiene otros

documentos (páginas web) adicionales. Cada sitio pertenece y es gestionado y por un

individuo, una compañía o una organización.

2.10. ¿QUÉ ES UNA INTRANET?11

Es una red de ordenadores privada basada en los estándares de Internet.

Las Intranets utilizan tecnologías de Internet para enlazar los recursos

informativos de una organización, desde documentos de texto a documentos

multimedia, desde bases de datos legales a sistemas de gestión de documentos. Las

Intranets pueden incluir sistemas de seguridad para la red, tablones de anuncios y

motores de búsqueda.

2.11. ¿QUÉ ES UN SERVIDOR WEB?12

Almacena principalmente documentos HTML (son documentos a modo de

archivos con un formato especial para la visualización de páginas web en los

navegadores de los clientes), imágenes, videos, texto, presentaciones, y en general todo

tipo de información. Además se encarga de enviar estas informaciones a los clientes.

2.12. ¿QUÉ ES UN SERVIDOR WEB LOCAL?13

Un Servidor Web Local es aquel Servidor Web que reside en una red local al

equipo de referencia. El Servidor web Local puede estar instalado en cualquiera de los

equipos que forman parte de una red local. Es por tanto obvio, que todos los Servidores

Web, son locales a la red local en la que se encuentran, o como mínimo, locales al

sistema en el que están instalados.

2.13. ¿QUÉ ES UNA APLICACIÓN WEB?14

Una aplicación web es un conjunto de páginas que interactúan unas con

otras y con diversos recursos en un servidor web, incluidas bases de datos. Esta

interacción permite implementar características en su sitio como catálogos de

productos virtuales y administradores de noticias y contenidos. Adicionalmente podrá

realizar consultas a bases de datos, registrar e ingresar información, solicitudes, pedidos

y múltiples tipos de información en línea en tiempo real.

11 http://www.hosting-peru.net/que_es_intranet.html 12 http://www.aprenderaprogramar.com 13 http://www.antoniocalderonch.com/ique-es-un-servidor-local 14 http://www.suronline.net/nuevo_sitio/beneficios-funcionamiento-aplicaciones-web.asp

24

2.14. ¿QUÉ SON SERVICIOS WEB?

Los Servicios Web o Web Services son una API para permitir exponer

servicios a través de la Web. Permite que aplicaciones Web interactúen

dinámicamente con otras aplicaciones, utilizando para ello estándares abiertos

como XML (Extensible Markup Language), UDDI (Universal Description,

Discovery and Integration) y SOAP (Simple Object Access Protocol). Las funciones

que pueden ser realizadas por los web services pueden ir desde simples

intercambios de información hasta complicados procesos de negocios. Se puede

encapsular su lógica de negocio mediante web services y exponerlas para que los

clientes las consuman a través de la web.

2.15. ¿QUÉ ES UN ENTORNO DE DESARROLLO INTEGRADO?15

Los programas de desarrollo de software tienen como objetivo hacer que el

proceso de desarrollo lo más sencillo posible. Programas IDE incluyen un editor de

código fuente, compilador, y por lo general un depurador que todos trabajemos juntos

en la construcción de un programa de software. El IDE mantiene un registro de todos los

archivos relacionados con un proyecto y proporciona una interfaz central para escribir

código fuente, vincular archivos juntos y depurar el software.

Software de programación IDE también puede incluir un entorno de tiempo

de ejecución (RTE) para probar el software. Cuando un programa se ejecuta dentro de la

RTE, el software puede realizar un seguimiento de cada evento que tiene lugar dentro

de la aplicación que se está probando. Esto puede ser una herramienta muy buena para

depurar el programa. Debido a que el software IDE utiliza una interfaz central para

escribir el código y probar el programa, es fácil hacer cambios rápidos en el código,

compilarlo y ejecutar el programa de nuevo. La programación es todavía un trabajo

duro, pero el software IDE ayuda a que los procesos un poco más libre de problemas.

a) NETBEANS16

NetBeans es un proyecto exitoso de código abierto con una gran base de

usuarios, una comunidad en constante crecimiento, y con cerca de 100 socios (¡y

creciendo!) en todo el mundo. Sun MicroSystems fundó el proyecto de código abierto

NetBeans en junio 2000 y continúa siendo el patrocinador principal de los proyectos.

Al día de hoy hay disponibles dos productos: el NetBeans IDE y NetBeans

Platform.

NetBeans IDE es un entorno de desarrollo - una herramienta para que los

programadores puedan escribir, compilar, depurar y ejecutar programas. Está escrito en

Java - pero puede servir para cualquier otro lenguaje de programación. Existe además

15 http://www.techterms.com/definition/ide 16 https://netbeans.org/index_es.html

25

un número importante de módulos para extender el NetBeans IDE. NetBeans IDE es un

producto libre y gratuito sin restricciones de uso.

Última versión estable: 7.4; 15 de octubre de 2013

Género: Entorno de desarrollo integrado.

Programado en: Java

Sistema operativo: Multiplataforma

Licencia: CDDL, GNU General Public License 2

Estado actual: En desarrollo

Idiomas:

Multilingüe

2.16. ¿QUÉ ES UN SERVIDOR DE APLICACIONES?17

Un servidor de aplicaciones se trata de un dispositivo de software

que proporciona servicios de aplicación a las computadoras cliente. Un servidor de

aplicaciones gestiona las funciones de lógica de negocio y de acceso de datos a la

aplicación. Los principales beneficios son la centralización y la disminución de la

complejidad en el desarrollo de aplicaciones:

a) GLASSFISH

El término Glassfish, traducido al español sería algo parecido como “Pez de

Cristal”, es el nombre de un pez que realmente existe y vive en el agua

dulce; su cuerpo es transparente, por lo que sus huesos son visibles. El

nombre fue elegido debido a la transparencia que los creadores querían darle al

proyecto, que utiliza una licencia Open Source, concretamente la licencia Common

Development and Distribution License (CDDL) v1.0 y la GNU Public License (GPL) v2.

2.17. PLATAFORMA JAVA18

La plataforma Java es el entorno de software basado en Java que se ejecuta

sobre otras plataformas y su software puede ser usado sobre varios sistemas operativos

y hardware. Está formada por tres componentes:

• Lenguaje. Es un lenguaje de propósito general, de alto nivel que

utiliza el paradigma de orientación a objetos.

• La Máquina Virtual. Los programas escritos en Java son

compilados como archivos ejecutables de una máquina virtual llamada Java Virtual

Machine (JVM), esto permite que los programas ejecutables puedan ejecutarse

en distintas arquitecturas.

17 SERRA MACHADO DAVID – “Estudio del servidor de aplicaciones Glassfish y de las aplicaciones J2EE“ pág. 182 disponible en ddd.uab.cat/pub/trerecpro/.../SerraManchadoDavidR-ETISa2009-10.pdf 18 SERRA MACHADO DAVID – “Estudio del servidor de aplicaciones Glassfish y de las aplicaciones J2EE“ pág. 25 disponible en ddd.uab.cat/pub/trerecpro/.../SerraManchadoDavidR-ETISa2009-10.pdf

26

• Las Bibliotecas. El conjunto de bibliotecas del lenguaje es conocido como

la Java Aplication Programming Interface (Java API) y es un conjunto de componentes

que proporcionan diferentes herramientas para el desarrollo.

Para la plataforma Java existen diferentes ediciones:

• Java Micro Edition (Java ME). Desarrollo para artículos móviles pequeños.

• Java Standard Edition (Java SE). Es la edición que se emplea en computadoras

personales (desktops y laptops).

• Java Enterprise Edition (Java SE). Desarrollo orientado a aplicaciones empresariales.

2.18. JAVA EE19

La plataforma Java EE está diseñado para ayudar a los desarrolladores a

crear a gran escala, de varios niveles, las aplicaciones de red escalable y confiable y

segura. Un nombre abreviado para estas aplicaciones es “aplicaciones empresariales”,

llamado así debido a que estas aplicaciones se han diseñado para resolver los problemas

encontrados por las grandes empresas. Las aplicaciones empresariales no sólo son útiles

para las grandes corporaciones, organismos y gobiernos, sin embargo. Los beneficios de

una aplicación empresarial son útiles, incluso esenciales, para que los desarrolladores

individuales y pequeñas organizaciones en un mundo cada vez más interconectado.

FIGURA 06: “Arquitectura JEE”

FUENTE: http://www3.gobiernodecanarias.org/medusa/ecoblog/fsalpaz/

19 SERRA MACHADO DAVID – “Estudio del servidor de aplicaciones Glassfish y de las aplicaciones J2EE“ pág. 26

27

A demás JEE también se encarga de proporcionar características para la

gestión de:

Seguridad

Control de transacciones

Gestión de componentes desplegados

Control de concurrencia

Uso y asignación de recursos

2.19. ¿QUÉ ES UNA BASE DE DATOS?20

Una colección de información organizada de tal manera que un programa de

computadora puede rápidamente seleccionar piezas deseadas de datos.

2.20. ¿QUÉ ES UN GESTOR DE BASE DE DATOS?

Una colección de programas que le permite almacenar, modificar y extraer

información de una base de datos. Hay muchos tipos diferentes de DBMS, que van

desde pequeños sistemas que se ejecutan en los ordenadores personales a grandes

sistemas que se ejecutan en los mainframes.

2.21. ¿QUÉ ES POSTGRESQL?21

PostgreSQL es un sistema de gestión de bases de datos objeto-relacional,

distribuido bajo licencia BSD y con su código fuente disponible libremente. Es el sistema

de gestión de bases de datos de código abierto más potente del mercado y en sus

últimas versiones no tiene nada que envidiarle a otras bases de datos comerciales.

TABLA 01: Límites de Postgres

FUENTE: http://www.postgresql.org.es/sobre_postgresql

20 http://www.webopedia.com/TERM/D/database.html 21 http://www.postgresql.org.es/sobre_postgresql

28

2.22. ¿QUÉ ES MODELADO DE BASE DE DATOS?22

Es el proceso de realizar el modelo de entidad relación físico para ser

exportado al lenguaje SQL.

a) MICROOLAP

MicroOLAP Database Designer for PostgreSQL es una herramienta CASE fácil

con la interfaz gráfica intuitiva que le permite construir una estructura de base de datos

clara y eficaz visualmente, ve el cuadro completo (diagrama) que representa todas las

tablas, las referencias entre ellos, vistas, procedimientos almacenados y otros objetos.

2.23. ¿QUÉ ES UN FRAMEWORK DE DESARROLLO?23

Un framework de aplicaciones web es un tipo de framework que permite el

desarrollo de sitios web dinámicos, web services (servicios web) y aplicaciones web. El

propósito de este tipo de framework es permitir a los desarrolladores construir

aplicaciones web y centrarse en los aspectos interesantes, aliviando la típica tarea

repetitiva asociada con patrones comunes de desarrollo web. La mayoría de los

frameworks de aplicaciones web proporcionan los tipos de funcionalidad básica común,

tales como sistemas de templates (plantillas), manejo de sesiones de usuario, interfaces

comunes con el disco o el almacenamiento en base de datos de contenido cacheado, y

persistencia de datos. Normalmente, los frameworks de aplicación web además

promueven la reutilización y conectividad de los componentes, así como la reutilización

de código, y la implementación de bibliotecas para el acceso a base de datos.

FIGURA 07: Componentes JSF en la página de configuración de Glassfish

FUENTE:” SERRA MACHADO DAVID – “Estudio del servidor de aplicaciones Glassfish

y de las aplicaciones J2EE“pág. 182

JSF proporciona:24

Una clara separación entre vista y modelo.

Desarrollo basado en componente, no en peticiones.

Las acciones del usuario se ligan muy fácilmente al código en el servidor.

Creación de familias de componentes visuales para acelerar el desarrollo.

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

29

Ofrece múltiples posibilidades de elección entre distintos desarrollos.

Hace que sea fácil de construir una interfaz de usuario a partir de un conjunto de

componentes de interfaz de usuario reutilizables

Simplifica la migración de los datos de la aplicación a y desde la interfaz de usuario

Ayuda a administrar el estado de la interfaz de usuario a través de las peticiones de

servidor

Proporciona un modelo simple para el cableado de los eventos generados por el

cliente al código de la aplicación en el servidor

Permite que los componentes de interfaz de usuario personalizada para construir

fácilmente y reutilizarse

2.24. ¿QUÉ ES JAVA PRIMEFACES?25

Es un framework complemento a los componentes de Java Server Faces, El

punto fuerte de PrimeFaces es la sencillez de instalación y lo poco pesado que es. El

mantenerlo liviano, sin complicaciones a la hora de instalarlo, es decir, sin dependencias

ni configuraciones, hace que podamos estar usándolo en unos pocos segundos.

CARÁCTERÍSTICAS:

Un interesante conjunto de componentes (editor HTML,

autocompletado, gráficas,…)

Soporte para Ajax, basándose en el estándar JSF 2.0 Ajax API

Sin dependencias, ni configuraciones, además de ser muy ligero (1802Kb

en su versión 3.5)

Soporte para interfaces de usuario sobre dispositivos móviles, nos

provee de un kit para este menester.

Múltiples temas de apariencia, listos para usar.

Amplia difusión del framework, con lo cual existe una comunidad que

respalda al proyecto.

2.25. ¿QUÉ ES HIBERNATE?26

Hibernate funciona asociando a cada tabla de la base de datos un Plain Old

Java Object (POJO, a veces llamado Plain Ordinary Java Object). Un POJO es similar a

una Java Bean, con propiedades accesibles mediante métodos setter y getter.

QUERY Y LENGUAJE HQL: Existen diversas herramientas útiles para el uso de Hibernate que cubren

todo el desarrollo desde nuestra aplicación hasta nuestra base de datos y viceversa:

25 http://www.genbetadev.com/frameworks/primefaces-framework-sobre-jsf-2-0-primeros-pasos 26 http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=hibernate

30

FIGURA 08: Componentes JSF en la página de configuración de Glassfish

FUENTE: http://www.hibernate.org/102.html

Desde herramientas de modelado UML como por ejemplo con Poseidon

podemos generar modelos entidad relación que son traducidos por AndroMDA a

POJO's y mediante XDoclet se generan los ficheros HBM. Todas estas tareas se

automatizan mediante el uso de ANT.

Otra opción es crear la base de datos con una herramienta de modelado y a

partir de la base de datos una vez creada usar Middlegen para generar los ficheros HBM

y a partir de estos los POJO's mediante hbm2java.

31

CAPÍTULO III

ACTIVIDADES REALIZADAS

3.1 SITUACIÓN ACTUAL DE LA COMISIÓN DE PRÁCTICAS PRE PROFESIOANALES

El proceso de las Prácticas Pre Profesionales en la FIIS es administrada por la

CPPP, compuesta por cuatro (04) integrantes que son los encargados de planificar,

coordinar y supervisar la ejecución y la correspondiente evaluación de las Prácticas Pre

Profesionales.

Actualmente las funciones de la CPPP que son ejecutadas por sus

integrantes que no solo tienen esta carga administrativa, sino muchas otras dentro de la

universidad, además de cumplir con su carga académica establecida.

Por lo tanto, el tiempo que dispone cada integrante de la comisión es muy

corto y necesitan de un mecanismo o herramienta que les ayude en sus actividades

dentro de la comisión, especialmente en la búsqueda de información y en tener

disponibilidad inmediata de información.

Se realizaron varios intentos por buscar un mecanismo que permita agilizar

sus procedimientos pero que no lograron alcanzar el objetivo.

3.2 IDENTIFICACIÓN DEL PROBLEMA

La inexistencia de un mecanismo o herramientas que permita agilizar los

procedimientos de registro y control de las Prácticas Pre Profesionales, obteniendo

como resultado datos e información no disponible al momento sobre el estado de los

practicante y sus actividades realizadas a la fecha.

3.3 ANTECEDENTES

El trabajo manual que realiza la CPPP quiso ser automatizado por varios

estudiantes de la FIIS. En la memoria de los docentes de dicha facultad existe la

realización de dos software de Prácticas Pre Profesionales.

El primero fue realizado por el ex estudiante de la FIIS, Percy Collantes Díaz,

con motivo de sus prácticas pre profesionales, el cual no ha sido encontrando ni en los

archivos de la facultad, el ex estudiante Collantes no hizo entrega del informe final

corregido del trabajo realizado.

El segundo, se recuerda que, un grupo de estudiantes que llevaron cursos de

programación en la FIIS, tuvieron el interés de desarrollar un sistemas de prácticas pre

profesional, que no se llegó a concluir satisfactoriamente, o no se quiso entregar la

información requerida, tales como el código o el informe del desarrollo para su correcta

implementación.

Todos estos antecedentes, según lo investigado, estuvieron realizados en

programación de escritorio.

32

El antecedente más cercano es del ex alumno Mariño Gamboa (2010), quien

realizó el software para la comisión bajo el lenguaje de programación PHP y Gestor de

Base de datos Mysql. El cual a la vez nunca se usó, desfasándose y archivándose, al

observarlo y hacerlo funcionar se observó que no existe un plan de despliegue además

de tener el código desordenado y poco entendible para su mantenimiento.

El docente de la FIIS Ing. Ronald Ibarra Zapata, diseñó un modelo de base de

datos para la comisión de Prácticas Pre Profesionales.

3.4 OBJETIVOS

3.4.1. GENERAL

Desarrollar el sistema de Prácticas Pre Profesionales “SPPP” V1.0, con

tecnologías web, para la Comisión de Prácticas Pre Profesionales en la Facultad de

Ingeniería en Informática y Sistemas.

3.4.2. ESPECÍFICOS

Obtener los requisitos de los usuarios atreves de las historias de usuario.

Planificar el desarrollo del software mediante el despliegue de las

historias de usuario en tareas, realizando un plan de entrega.

Analizar los datos, documentos, y demás información histórica que

maneja la Comisión de Prácticas Pre Profesionales.

Diseñar una base de datos relacional y los prototipos de las interfaces.

Construir el software según las tareas planificadas.

Realizar las pruebas funcionales de la aplicación web de Prácticas Pre

Profesionales con los integrantes de la CPPP.

3.5 JUSTIFICACIÓN

Impacto Tecnológico

El desarrollo del software permitirá:

Almacenar toda la información de los usuarios en una base de datos,

permitiéndoles a los usuarios estar actualizados e informados de las prácticas

aceptadas, anuladas, asignación de asesores, informes finales, supervisiones,

sustentaciones, asignación de jurados.

Impacto Social

Alto grado de aceptación por parte de los Miembros de comisión de

prácticas pre profesionales, que contarán con un software que no sólo les permitirá

agilizar sino también coordinar las actividades de registro, búsquedas, seguimientos y

control de fechas, contenidos, ampliaciones, supervisiones, anulaciones de prácticas,

informes finales y sustentaciones, la independencia de la información de las prácticas

pre profesionales, la disminución de la carga laboral y de una mejor forma de trabajo.

Los estudiantes, también se beneficiarán en el sentido de disponer de la información

33

referente a las prácticas pre profesionales, del avance y control de sus actividades, de la

comunicación eficiente con la comisión, con su asesor y con sus jurados.

Impacto Económico

Menores costes en la utilización de materiales para el registro de las

diferentes actividades de la Comisión de prácticas Pre Profesionales.

3.6 APLICACIÓN DEL MODELO DE DESARROLLO EXTREME PROGRAMING (XP)

3.6.1. DESCRIPCIÓN DE LA ACTIVIDAD ASIGNADA.

Esta actividad consistió en aplicar las fases del modelo de desarrollo XP para

la construcción del software de prácticas pre-profesionales. Para la construcción, se

consideró las fases de Planificación, Diseño, Codificación y Pruebas.

3.6.2. ¿POR QUÉ USAR EL MODELO DE DESARROLLO XP PARA LA CONSTRUCCIÓN

DEL SOFTWARE?

Se utilizará el modelo de desarrollo XP debido a las características del

proyecto dado que los requerimientos no se encuentran previamente definidos por el

usuario, además son de naturaleza cambiante. Además se necesitará interactuar con el

usuario a medida que se construya el software, realizando entregables en corto tiempo

para así dar al usuario una idea de cómo funcionará el software.

3.6.3. PRÁCTICAS UTILIZADAS EN EL PROYECTO

a. Planificación incremental: Se realizó mediante la observación directa

los cuales fueron plasmados en historias de los usuarios

retroalimentando la información de manera seguida.

b. Diseño sencillo: Se llevó a cabo el diseño de los formularios necesarios

para cumplir los requerimientos actuales.

c. Desarrollo previamente probado: Se utilizó un sistema de pruebas de

unidad para escribir pruebas para nuevas funcionalidades antes de que

éstas se implementen.

d. Refactorización: se refactorizó el código tan pronto se halló el error

e. Integración continua: Al término de cada día, se integraba el avance

realizado al sistema principal obteniendo un único sistema integral.

f. Programación en parejas: se conformó un grupo de desarrollo en la

Facultad de ingeniería en informática y sistemas, los cuales estuvieron

apoyando activamente, realizando la programación en parejas.

g. Propiedad Colectiva: Los miembros del equipo tienen todo el código

disponible bajo subversión en un repositorio en internet que es

mercurial de google code y el cliente tortoiseHg.

34

FIGURA 09: Cliente TortoiseHg para actualizar el repositorio al termino de los cambios y actualizar los cambios.

FUENTE: cliente tortoiseHg

Estándares de codificación: se manejó la codificación en áreas para

organizar el código y hacer más sencillo en mantenimiento.

FIGURA 10: código en áreas.

FUENTE: IDE Netbean

3.7 FASE1: PLANEACIÓN

En esta fase comprende el análisis para el cual se hizo conversaciones

directas con el Secretario de la Comisión de Prácticas pre profesional y el diseño para la

construcción del software.

3.7.1 EQUIPO DE DESARROLLO:

El equipo XP de desarrollo que ha llevado a cabo este proyecto es el

siguiente: Cuadro 03. Equipo XP

CARGO NOMBRES

ANALISTA – PROGRAMADOR Alberto Lucio, ACEVEDO ALIAGA

ASESOR Ing. Ronald, IBARRA ZAPATA

FUENTE: Elaboración Propia

35

3.7.2 HISTORIAS DE USUARIO:

Tras el diálogo con el Secretario de la comisión de Practicas Pre

Profesionales, se logró identificar requisitos iniciales para el desarrollo de las historias

de usuario, a continuación se detalla en el cuadro 04: Cuadro 04. Requisitos iniciales

N DESCRIPCIÓN

R1 Para acceder al sistema cada usuario deberá contar con un nombre de usuario el tipo de comisión, una contraseña registrados en el sistema.

R2 El sistema debe ser capaz de registrar una comisión anualmente con el tipo de comisión.

R3 El Sistema debe ser capaz de registrar a los integrantes de cada comisión, esto anualmente.

R4 El Sistema debe ser capaz de registrar a usuarios con roles de alumno y comisión.

R5 Cada medio año el sistema debe actualizar los datos de los alumnos otorgados por OCDA (Oficina de Coordinación Académica)-UNAS.

R6 Cada medio año el sistema debe actualizar los datos de los docentes otorgados por OCDA (Oficina de Coordinación Académica)-UNAS.

R7 El Sistema debe registrar a los practicantes con 160 créditos aprobados, por tres meses como mínimo.

R8 El sistema debe registrar la organización y el área de labor del practicante.

R9 El sistema debe registrar los proyectos de cada practicante.

R10 El sistema debe registrar las actividades desempeñadas por el practicante.

R11 El Sistema debe registrar asesores a los practicantes registrados.

R12 El sistema debe generar un formato de oficio digital y enviar al correo de secretaria del decano y al docente asignado como asesor, con los datos de la práctica registrada, conjuntamente con un formato de resolución para la firma del decano.

R13 El Sistema debe asignar supervisiones a los practicantes hasta por dos veces

R14 El Sistema debe registrar proyectos que los practicantes van a realizar

R15 El Sistema debe registrar los informes al cabo de la finalización de practicas

R16 El Sistema debe registrar sustentaciones después de presentar informe.

R17 El sistema debe asignar 4 jurados que serán docentes para una sustentación

R18 El sistema debe generar un formato de oficio digital y enviar al correo de secretaria del decano y al docente asignado como jurado, con los datos de la sustentación, conjuntamente con un formato de resolución para la firma del decano.

R19 El sistema debe ampliar las prácticas si así se solicitara a la comisión.

R20 El sistema debe ampliar la sustentación en casos de falta de tiempo.

R21 El sistema debe registrar una nueva sustentación por desaprobación.

R22 El Sistema debe emitir reportes de los practicantes y su historial.

R23 El Sistema debe emitir reportes de los asesores.

R24 El Sistema debe emitir reportes de supervisiones.

R25 El Sistema debe emitir reportes jurados.

R26 El Sistema debe emitir reportes documentos de gestión

R27 El Sistema debe emitir reportes de sustentaciones

R28 El sistema debe tener una biblioteca digital con los informes de prácticas aprobadas

FUENTE: Elaboración Propia.

36

Los usuarios involucrados en el desarrollo del proyecto se detallan en el

cuadro 05: Cuadro 05. Clientes del proyecto

Cargo Nombre Seudónimo

Presidente William Marchand Usuario CPPP

Secretario George Paucar Usuario CPPP

Vocal Wilmer Bermúdez Usuario CPPP

Equipo XP Alberto Acevedo Administrador CPPP

FUENTE: Elaboración Propia.

Los privilegios asignados a los usuarios se detallan en el cuadro 06: Cuadro 06. Privilegios de los Usuarios

Tipos de Usuario PPP Privilegios

Miembro CPPP Altos

Alumno CPPP Bajos

Administradores CPPP Altos

FUENTE: Elaboración Propia

En base al cuadro 04, se procede a recolectar las historias de usuario por

cada requisito inicial, en conversación directa con el usuario, en este caso

explícitamente, con el secretario de la comisión explicándole que cada historia o

requisito tiene puntos de valor en una escala de 1-5, esto es cuan significante es para el

requisito.

Se dedicó 22 días a la recolección de los requisitos, puesto que los miembros

de la comisión no cuentan con el tiempo necesario para poder agilizar el procedimiento.

A continuación se muestra el formato que se utilizó para la recolección de historias de

usuario. Para ver todas las historias ver ANEXO 02.

Cuadro 07. Historia “ingresando al Sistema”

FUENTE: Elaboración Propia

Historia de usuario

Rol : Secretario CPPP

Nombre historia: Ingresando al sistema (Autentificación)

Puntos de valor: 2

Descripción: yo como secretario de la comisión deseo ingresar al sistema para

realizar mis actividades, el sistema debe pedirme al inicio ingresar con mi

nombre, contraseña, tipo de usuario y comisión.

Observaciones: los tipos de usuario son miembro de la comisión, alumno y

administrador.

37

El formato de las historias de usuario en realidad se maneja de diferentes

formas según bibliografías consultadas, para este caso se decidió seguir este formato

personalizado por darnos un mejor alcance a los requisitos que se quiere definir.

En el rol se define el papel del usuario que define la historia, seguido por el

nombre de la historia además el usuario valora en cuanto por ciento del total es

importante este requisito para él, definido como puntos de valor, en los adjuntos se

hace referencia a documentos, formatos, fichas entre otras que nos pudiese servir para

entender mejor el requisito, finalizando con observaciones que vendrían a ser algunas

excepciones y comentarios.

Una vez planteadas las historias de usuario iníciales, se procede a desarrollar

el sistema, que se explica más adelante con más detalle, una vez desarrollado se pasa a

una evaluación del sistema según las historias de usuario, el cual también tuvo un

formato para la documentación de las observaciones en cuestión de modificaciones al

sistema según los establecido en el análisis de los requerimientos.

38

3.7.3 ESTIMACIÓN DE ESFUERZO ASOCIADOS A LAS HISTORIAS DE USUARIOS Cuadro 08. Historia “Estimaciones de esfuerzo asociadas a las historias de usuario”

FUENTE: Elaboración Propia.

N° HISTORIAS DE USUARIO ESFUERZO

(Horas) FECHA INICIO / FECHA FIN

H1. Ingresando al sistema

(Autentificación) 7 07-10-2013 / 08-10-2013

H2. Registrando una comisión 7 08-10-2013 / 10-10-2013

H3. Registrando integrantes 7 10-10-2013 / 12-10-2013

H4. Registrando usuarios 7 12-10-2013 / 15-10-2013

H5. Registrando practicantes 7 15-10-2013 / 17-10-2013

H6. Registrando Empresas 8 17-10-2013 / 18-10-2013

H7. Registrando Proyecto de práctica. 7 19-10-2013 / 21-10-2013

H8. Registrando Actividades del

Practicante 8 23-10-2013 / 23-10-2013

H9. Registrando asesores 7 24-10-2013 / 26-10-2013

H10 Generando oficio de Asignación de

Asesores. 6 26-10-2013 / 29-10-2013

H11. Registrando supervisiones 7 28-30-2013 / 30-10-2013

H12. Registrar ampliación de prácticas. 7 30-11-2013 / 01-11-2013

H13. Registrando informes 7 01-11-2013 / 04-11-2013

H14. Registrando sustentaciones 7 04-11-2013 / 06-11-2013

H15. Registrando jurados 7 06-11-2013 / 08-11-2013

H16. Generando oficio de Asignación de

Jurados. 7 08-11-2013 / 11-11-2013

H17. Registrando informes digitales finales

aprobados. 7 11-11-2013 / 12-11-2013

H18. Reportando practicantes. 6 13-11-2013 / 19-11-2013

H19. Reportando historial de practicantes. 6 15-11-2013 / 21-11-2013

H20. Reportando ranking de asesores. 6 18-11-2013 / 23-11-2013

H21. Reportando documento para

supervisiones. 6 20-11-2013 / 24-11-2013

H22. Reportando ranking de jurados. 6 21-11-2013 / 23-11-2013

H23. Reporte para doc. De Gestión. 6 23-11-2013 / 25-11-2013

H24. Reportando sustentaciones. 6 25-11-2013 / 26-11-2013

H25 Realizar Repositorio Digital 4 02-12-2013/03-12-2013

H26 Consumir datos de OCDA 10 03-12-2013/07-12-2013

39

3.7.4 PLAN DE ENTREGA

Cuadro 09. “Prioridades, riesgo, esfuerzo e interacciones”

FUENTE: Elaboración Propia.

LEYENDA

P= Prioridad.

R= Riesgo

E= Esfuerzo (en Horas)

I= Iteración

N° Nombre Historia de Usuario P R E I

H1. Ingresando al sistema (Autentificación) Alta Alta 7 1

H2. Registrando una comisión Alta Alta 7 1

H3. Registrando integrantes Alta Alta 7 1

H4. Registrando usuarios Alta Alta 7 1

H5. Registrando practicantes Alta Alta 7 1

H6. Registrando empresas Alta Media 8 1

H7. Registrando proyecto de práctica. Alta Media 7 1

H8. Registrando actividades del practicante Alta Media 8 1

H9. Registrando asesores Alta Media 7 2

H10. Generando oficio de asignación de asesores. Media Media 6 2

H11. Registrando supervisiones Media Media 7 2

H12. Registrar ampliación de prácticas. Alta Media 7 2

H13. Registrando informes Alta Media 7 2

H14. Registrando sustentaciones Alta Media 7 2

H15. Registrando jurados Media Media 7 2

H16. Generando oficio de Asignación de Jurados. Alta Media 7 2

H17. Registrando informes digitales finales

aprobados.

Alta Media 7

2

H18. Reportando practicantes. Media Media 6 3

H19. Reportando historial de practicantes. Media Media 6 3

H20. Reportando ranking de asesores. Media Media 6 3

H21. Reportando documento para supervisiones. Media Media 6 3

H22. Reportando ranking de jurados. Media Media 6 3

H23. Reporte para doc. De Gestión. Media Media 6 3

H24. Reportando sustentaciones. Media Media 6 3

H25. Generando Repositorio Digital Media Baja 4 4

H26. Consumir datos de OCDA Media Media 10 4

40

3.7.5 ANÁLISIS DE REQUISITOS MEDIANTE DIAGRAMAS DE PROCESOS

Para el entendimiento y concepción de los requisitos se procese a realizar

diagramas de proceso de negocio (BPMN) para el cual se utilizó el software Bizagi

Process Modeler, tomando como referencia el ANEXO 08.

El proceso de la FIGURA 11. Muestra cómo se designa a los miembros de la

comisión; cuenta con participantes como el decano, consejo de facultad y la comisión de

prácticas pre profesionales, en las que el decano propone a la comisión y el consejo de

facultad es el encargado de ratificar para emitir su resolución, caso contrario se volverá

a proponer una comisión:

FIGURA 11: “Designación De La Comisión De Practicas Pre Profesionales”

FUENTE: Software Bizagi Process Modeler

El proceso de la FIGURA 12. Muestra como es el trámite del alumno para

realizar la gestión de su práctica pre profesional, para ello inicia realizando la solicitud a

decanatura para la emisión de carta de presentación, si el practicante es aceptado por la

institución procede a enviar a decanatura los requisitos para realizar prácticas y estas

son derivadas a la comisión para su evaluación y aceptación correspondiente.

FIGURA 12: “Tramite Para Realizar Prácticas Pre Profesionales”

FUENTE: Software Bizagi Process Modeler

41

El proceso de la FIGURA 13. Inicia en la comisión de PPP, asignando un

supervisor para la inspección a las actividades del practicante, al finalizar el supervisor

debe emitir un informe con la visita realizada.

FIGURA 13: “Supervisión de la practicas pre profesionales”

FUENTE: Software Bizagi Process Modeler

El proceso de la FIGURA 14. Inicia con la solicitud de ampliación del

practicante, hacia la empresa, y esta evalúa la petición emitiendo una carta mediante el

practicante a la comisión para su dictamen final.

FIGURA 14: “Ampliación de las practicas pre profesionales”

FUENTE: Software Bizagi Process Modeler

42

El proceso de la FIGURA 15. Muestra la recepción para el informe final, la

comisión debe evaluar si el informe recepcionado, está dentro del plazo máximo de un

mes, después de las prácticas finalizadas, si cumple el requisito el practicante presenta 4

ejemplares a la decanatura para su derivación a la CPPP y distribución a los jurados.

FIGURA 15: “Entrega del informe final”

FUENTE: Software Bizagi Process Modeler

El proceso de la FIGURA 16. Muestra la asignación de jurados, la decanatura

envía el informe de prácticas a la comisión y esta asigna a los jurados mediante un oficio

a decanatura para su revalidación con resolución por parte de esta última.

FIGURA 16: “Asignación de jurados”

FUENTE: Software Bizagi Process Modeler

43

El proceso de la FIGURA 17. Inicia con la publicación del cronograma por

parte de la CPPP y si es necesario, por la cantidad del volumen del informe, se amplía a

una nueva fecha, sino se sigue la sustentación para su evaluación.

FIGURA 17: “Sustentación de prácticas pre profesionales”

FUENTE: Software Bizagi Process Modeler

El proceso de la FIGURA 18. La institución donde se realiza las practicas

emite una ficha de evaluación o certificado para la entrega a los jurados, el jurado inicia

la evaluación y el practicante recepciona las observaciones para la corrección de su

informe, firmando el acta , caso de no haber observaciones se firma el acta y la comisión

la recepciona para su registro.

FIGURA 18: “Evaluación de sustentación”

FUENTE: Software Bizagi Process Modeler

44

3.7.6 DIAGRAMA DE CLASES

Un diagrama de clases es un tipo de diagrama estático que describe la

estructura de un sistema mostrando sus clases, orientados a objetos.

De acuerdo con la recolección de información sobre el proceso de prácticas

pre profesionales se procedió al diseño del diagrama de clases se realizó usando la

herramienta Rational Rosse 7, tal se muestra en la FIGURA 19.

45

FIGURA 19: “Diagrama de clases”

FUENTE: Software Rational Rosse

46

3.8 FASE 2: DISEÑO|

3.8.1 ARQUITECTURA DEL SISTEMA

Se muestra la arquitectura del sistema mediante un diagrama de Despliegue

es un tipo de diagrama del Lenguaje Unificado de Modelado que se utiliza para modelar

el hardware utilizado en las implementaciones de sistemas y las relaciones entre sus

componentes.

FIGURA 20: “Diagrama de despliegue”

<<device>>ApplicationServer

<<device>>DataBaseServer

<<device>>HttpClient

<<executionEnviroment>>GlashFish 3.2.1

WebBrowser

<<executionEviroment>>Postgre 9.2

spppSchema

spppServices.jar

spppModel.jar

spppController.jar

spppWebPages.jar

spppDao.jar

<<device>>OCDA_DataBaseServer

<<executionEnviroment>>Postgre 9.2

AcademicDB

<<executionEviroment>>GlassFish Server 3.1.2

IntegrationWebService WSDL

spppDaemon

FUENTE: Elaborado en Software Microsoft Visio 2013

47

En el diagrama nos muestra el cliente desde un navegador y el acceso a los

paquetes dentro del servidor web (Glassfish 3.1.2) y como este servidor está

relacionado con la base de datos interna (Postgres 9.2) y otra desde OCDA mediante

Servicios Web.

3.8.2 DIAGRAMA DE ENTIDAD RELACIÓN

El esquema que se presenta en la FIGURA 21, se obtuvo del análisis previo

que se hizo en la FIGURA 19, este esquema es el denominado Entidad Relación, la que

muestra las relaciones entre las entidades, las tablas de color naranja son las

correspondientes a la Comisión De Prácticas Pre Profesionales, las tablas verdes

pertenecen a la Comisión De Grados Y Títulos, mientras que las celestes son las tablas

comunes para todos los sistemas integrados en la base de datos denominada BDFIIS.

48

FIGURA 21: “Diagrama de Entidad Relación”

FUENTE: Software MicroOlap

49

3.8.3 DICCIONARIO DE DATOS

En el Figura 19 se muestra la relación de Tablas, se hará un breve

comentario sobre la finalidad de cada tabla dentro de nuestra Base de Datos.

CUADRO 10: “Tabla Estado”

Descripción: Registra los estados de las diferentes entidades durante los

procesos, de acuerdo a las comisiones que a la que pertenece.

State

Nombre Tipo Descripción

id int4 Llave primaria, no nulo y auto incremental. name varchar(50) Nombre de estados, comisión (modificado,

ratificado).

name_entity varchar(25) Nombre de la entidad a la que corresponde el estado.

detail varchar(300) Detalle de los estados. Fuente: Elaboración propia.

3.9 FASE3: CONSTRUCCIÓN

3.9.1 PROTOTIPOS GENERALES PARA EL DISEÑO Y CONSTRUCCIÓN

Previo a empezar la fase 3, se hará prototipos generales de diseño para la

construcción de las interfaces, puesto que el desarrollo se está haciendo con el api de

primer faces, no es necesario pensar tanto en el diseño más si corresponde a una

definición general y las especificaciones a tomar en cuenta en cada tarea ya que

además, por buenas prácticas de diseño, se debe hacer uso del menor número de

interfaces posibles, estandarizando y organizando las interfaces para las operaciones de

negocio.

Para todas la interfaces se tendrá el siguiente esquema.

Un título General en el encabezado.

Un menú general en la parte izquierda de la pantalla.

Un espacio en el centro, donde se muestre todas las interfaces de

usuario. FIGURA 22: “esquema de interfaz”

FUENTE: Software Pencil (para diseño)

50

Para el ingreso al sistema según la figura 23: FIGURA 23: “esquema de acceso al sistema”

FUENTE: Software Pencil (para diseño)

Para el registro en el sistema según la figura 24: FIGURA 24: “esquema de acceso al sistema”

FUENTE: Software Pencil (para diseño)

Para las vistas y listados según la figura 25:

FIGURA 25: “Diseño de vistas y listados”

FUENTE: Software Pencil (para diseño)

51

Para los procesos de practicantes según la figura 26: FIGURA 26: “diseño para los procesos del practicante”

FUENTE: Software Pencil (para diseño)

3.9.2 PRIMERA ITERACCIÓN

Las historias realizadas en esta iteración son las siguientes:

Ingresando al sistema (Autentificación)

Registrando una comisión

Registrando integrantes

Registrando usuarios

Registrando practicantes

Registrando Empresas

Registrando Proyecto de práctica.

Registrando Actividades del Practicante

Para llevar a cabo el desarrollo de la primera iteración, se desglosó a las

historias de usuario, esto permitirá que el desarrollo se lleve a cabo de manera

incremental asegurando la implementación de la historia.

Las tareas tienen el siguiente formato:

CUADRO 11: “Diseño de la interfaz de acceso al sistema”

Tarea

Nombre Historia: Ingresando al Sistema

Nombre tarea: Diseño de la interfaz de acceso al sistema

Tipo de tarea: Diseñar Esfuerzo(Hora): 1

Fecha inicio: 07/10/13 Fecha fin: 07/10/13

Programador responsable: Equipo XP

Descripción: la interfaz debe tener dos cajas de texto, para el nombre de usuario

y contraseña, un botón de ingreso, siendo todo la ventana de acceso un modal o

ventana emergente.

Fuente: Elaboración propia

Para más detalle de las tareas de usuario VER ANEXO 03.

52

FIGURA 16: “Cuadro de actividades para iteración 1”

FUENTE: Elaboración en MS Project 2013

Como se muestra en la figura 16. El desarrollo se dio en 58 horas durante 15

días, con un trabajo de programación diaria de aproximadamente 3.86 horas diarias.

Resultados:

Figura 17. Formulario de acceso al sistema.

Figura 18. Interfaz de administración (registro de nueva comisión)

53

Figura 19. Formulario de Registro de prácticas.

En la Figura 17, 18,19, el cumplimiento de las tareas e historias de usuario.

3.9.3. SEGUNDA ITERACCIÓN

Las tareas realizadas en esta iteración son las siguientes:

Registrando asesores

Generando oficio de Asignación de Asesores.

Registrando supervisiones

Registrando informes

Registrando sustentaciones

Registrando jurados

Generando oficio de Asignación de Jurados.

Registrar ampliación de prácticas.

Registrar Registrando informes digitales finales aprobados.

Para llevar a cabo el desarrollo de la primera iteración, se desglosó a las

historias de usuario, esto permitirá que el desarrollo se lleve a cabo de manera

incremental asegurando la implementación de la historia.

Las tareas tienen el siguiente formato:

54

CUADRO 12: “Diseño de la interfaz del registro de Asesores”

Tarea

Nombre Historia: Registrando Asesores

Nombre tarea: Diseño de la interfaz del registro de Asesores

Tipo de tarea: Diseñar Esfuerzo(Hora): 1

Fecha inicio: 24/10/13 Fecha fin: 24/10/13

Programador responsable: Equipo XP

Descripción: la ventana tendrá un caja de opciones para los docentes con

opciones de búsqueda, la fecha de asignación y un campo con mascara para el

numero de oficio.

Fuente: Elaboración propia

Para más detalle de las tareas de usuario VER ANEXO 03.

FIGURA 20: “Cuadro de actividades para iteración 2”

FUENTE: Elaboración en MS Project 2013

Como se muestra en la figura 20. El desarrollo se dio en 62 horas durante 17

días, con un trabajo de programación diaria de aproximadamente 3.64 horas diarias.

Resultados:

Figura 21. Formulario de registro de asesor.

55

Figura 22. Interfaz de administración (registro de nueva comisión)

Figura 23. Formulario de Registro de asignación de jurados y las validaciones.

3.9.4. TERCERA ITERACCIÓN

Las historias realizadas en esta iteración son las siguientes:

Reportando practicantes.

Reportando historial de practicantes.

Reportando ranking de asesores.

Reportando documento para supervisiones.

Reportando ranking de jurados.

Reporte para los documentos de Gestión.

Reportando sustentaciones.

56

Para llevar a cabo el desarrollo de la primera iteración, se desglosó a las

historias de usuario, esto permitirá que el desarrollo se lleve a cabo de manera

incremental asegurando la implementación de la historia.

Las tareas tienen el siguiente formato:

CUADRO 13: “Diseño de la interfaz de la Generación de Reporte de los Practicantes”

Tarea

Nombre historia: Reportando Practicantes

Nombre tarea: Diseño de la interfaz de la Generación de Reporte de los Practicantes

Tipo de tarea: Diseñar Esfuerzo(horas): 2.5

Fecha inicio: 13/11/13 Fecha fin: 13/11/13

Programador responsable: Equipo XP

Descripción: el reporte debe tener un encabezado con el nombre de la comisión y Facultad, debe mostrar en una grilla los detalles como nombres, asesor, fecha inicio prácticas, fecha final de prácticas.

Fuente: Elaboración propia

Para más detalle de las tareas de usuario VER ANEXO 03.

FIGURA 24: “Cuadro de actividades para iteración 3”

FUENTE: Elaboración en MS Project 2013

Como se muestra en la Figura 24. El desarrollo de la tercera iteración se dio

en 42 horas durante 12 días, con un trabajo de programación diaria de

aproximadamente 2.47 horas diarias.

57

Resultados:

Figura 25: Diseño de los reportes en Ireport5.

Figura 26: Interfaz de los reportes con parámetros mediante modales

58

Figura 27: Salida de los reportes en formato pdf.

3.9.5. CUARTA ITERACCIÓN

Las historias realizadas en esta historia son las siguientes

Generar repositorio digital.

Consumir datos de OCDA.

Para llevar a cabo el desarrollo de la primera iteración, se desglosó a las

historias de usuario, esto permitirá que el desarrollo se lleve a cabo de manera

incremental asegurando la implementación de la historia.

Las tareas tienen el siguiente formato:

CUADRO 14: “Diseño de la interfaz de la Generación de Reporte de los Practicantes”

Tarea

Nombre historia: Reportando Practicantes

Nombre tarea: Diseño de la interfaz de la Generación de Reporte de los

Practicantes

Tipo de tarea: Diseñar Esfuerzo(horas): 2.5

Fecha inicio: 13/11/13 Fecha fin: 13/11/13

Programador responsable: Equipo XP

Descripción: el reporte debe tener un encabezado con el nombre de la comisión y

Facultad, debe mostrar en una grilla los detalles como nombres, asesor, fecha

inicio prácticas, fecha final de prácticas.

Fuente: Elaboración propia

59

Para más detalle de las tareas de usuario VER ANEXO 03.

FIGURA 28: “Cuadro de actividades para iteración 4”

FUENTE: Elaboración en MS Project 2013

Como se muestra en la Figura 28. El desarrollo de la cuarta iteración se dio

en 14 horas durante 4 días, con un trabajo de programación diaria de aproximadamente

3.5 horas diarias.

Resultados:

Figura 29: Interfaz del repositorio Digital de los informes de PPP.

60

Figura 30: Interfaz que busca los datos en Ocda.

Figura 31: Datos de Ocda retornados con éxito.

3.9.6. DIARIO DE ACTIVIDADES: CUADRO 16: “Diario de Actividades”

Fecha (Día/Mes/Año)

Actividad realizada Tiempo (horas)

Observaciones

21/08/13 Fase de comunicación con el secretario de la CPPP(Entrevista directa)

1.5 Planteamientos de desarrollo de software

22/08/13 Levantamiento y revisión del sistema de prácticas pre-profesionales v1.0 (2010)

30 Desarrollado en PHP y Mysql, limitados a Internet Explorer, código desordenado, sin ningún framework de desarrollo, desactualizado en cuanto al nuevo reglamento de PPP 2012.

28/08/13 Consultas a docentes de la especialidad(Ing. Ronald Ibarra, Ing. Brian Soto)

5 Propuestas de desarrollo de software – lineamientos de desarrollo de software según CTIC-UNAS.

61

Fecha (Día/Mes/Año)

Actividad realizada Tiempo (horas)

Observaciones

02/09/13 Reunión con el secretario de la CPPP

1 Definición y alcance del proyecto de prácticas pre profesionales.

03/09/13 Exploración de actividades de la comisión.

4 Familiarización con las actividades de la CPPP

04/09/13 Revisión de los materiales utilizados por la CPPP

5 Reconocimiento de documentos, libros de acta, reglamento 2012.

06/09/13 Recolección de historias de usuarios

15 Entrevistas observaciones y análisis documental.

16/09/13 Modelado BPMN, para el correcto enfoque de las historias a los procesos de negocio.

5 Uso de software BPMN Bizagi Process Modeler.

17/09/13 Reunión con el secretario de la CPPP

1 Definición de las actividades de las P.P.P

18/09/13 Diseño del diagrama de clases 7 Uso de la Herramiento Rational Rosse

23/09/13 Diseño de la base de datos 5 Diseño de diagrama de entidad relación en MicroOLAP for Postgres.

24/09/13 Reunión con el secretario de la CPPP

1 Recomendaciones sobre la base de datos

25/09/13 Rediseño de la base de datos 3 Recreación de la base de datos

26/09/13 Diseño del diagrama de arquitectura

4 Uso de la herramiento Visio 2010

27/09/13 Definición de las historias de usuario

4 Apoyo del secretario de la CPPP.

30/09/13 Definición des iteraciones 3 Establecimiento de las historias de usuario por iteración

07/10/13

Desarrollo de la historia “Ingresando al sistema (Autentificación)”.

7 Diseño, codificación y validación.

08/10/13 Revisión la historia “Ingresando al sistema (Autentificación)”.

0.5 Revisión de la funcionalidad

08/10/13 Corrección de errores detectados 0.5 Validando la historia de usuario

08/10/13 Desarrollo de la historia “Registrando una comisión”.

7 Diseño, codificación y validación.

10/10/13 Revisión de la historia “Registrando una comisión”.

0.5 Revisión de la funcionalidad

10/10/13 Corrección de errores detectados. 0.5 Validando la historia de usuario

62

Fecha (Día/Mes/Año)

Actividad realizada Tiempo (horas)

Observaciones

10/10/13 Desarrollo de la historia “Registrando integrantes”.

7 Diseño, codificación y validación.

12/10/13 Revisión de la historia “Registrando integrantes”.

0.5 Revisión de la funcionalidad

12/10/13 Corrección de errores destacados 0.5 Validando la historia de usuario

12/10/13 Desarrollo de la historia “Registrando usuarios”.

7 Diseño, codificación y validación.

15/09/13 Revisión de la historia “Registrando usuarios”.

0.5 Revisión de la funcionalidad

15/09/13 Corrección de errores destacados 0.5 Validando la historia de usuario

15/09/13 Desarrollo de la historia “Registrando practicantes”.

7 Diseño, codificación y validación.

17/10/13 Revisión de la historia “Registrando practicantes”.

0.5 Revisión de la funcionalidad

17/10/13 Corrección de errores destacados 0.5 Validando la historia de usuario

17/10/13 Desarrollo de la historia “Registrando Empresas”.

8 Diseño, codificación y validación.

18/10/13 Revisión de la historia “Registrando Empresas”.

0.5 Revisión de la funcionalidad

18/10/13 Corrección de errores destacados 0.5 Validando la historia de usuario

19/10/13 Desarrollo de la historia “Registrando Proyecto de práctica”.

7 Diseño, codificación y validación.

21/10/13 Revisión de la historia “Registrando Proyecto de práctica”.

0.5 Revisión de la funcionalidad

21/10/13 Corrección de errores destacados 0.5 Validando la historia de usuario

21/10/13 Desarrollo de la historia “Registrando Actividades del Practicante”.

8 Diseño, codificación y validación.

23/10/13 Revisión de la historia “Registrando Actividades del Practicante”.

0.5 Revisión de la funcionalidad

23/10/13 Corrección de errores destacados 0.5 Validando la historia de usuario

24/10/13 Desarrollo de la historia “Registrando asesores”.

7 Diseño, codificación y validación.

26/10/13 Revisión de la historia “Registrando asesores”

0.5 Revisión de la funcionalidad

63

Fecha (Día/Mes/Año)

Actividad realizada Tiempo (horas)

Observaciones

26/10/13 Corrección de errores destacados 0.5 Validando la historia de usuario

26/10/13 Desarrollo de la historia “Generando oficio de Asignación de Asesores”.

6 Diseño, codificación y validación.

28/10/13

Revisión de la historia “Generando oficio de Asignación de Asesores”.

0.5 Revisión de la funcionalidad

28/10/13 Corrección de errores destacados 0.5 Validando la historia de usuario

28/10/13 Desarrollo de la historia “Registrando supervisiones”.

7 Diseño, codificación y validación.

30/10/13 Revisión de la historia “Registrando supervisiones”.

0.5 Revisión de la funcionalidad

30/10/13 Corrección de errores destacados 0.5 Validando la historia de usuario

30/10/13 Desarrollo de la historia “Registrando informes”.

7 Diseño, codificación y validación.

01/11/13

Revisión de la historia “Registrando informes”.

0.5 Revisión de la funcionalidad

01/11/13 Corrección de errores destacados 0.5 Validando la historia de usuario

01/11/13 Desarrollo de la historia “Registrando sustentaciones”.

7 Diseño, codificación y validación.

04/11/13 Revisión de la historia “Registrando sustentaciones”.

0.5 Revisión de la funcionalidad

04/11/13 Corrección de errores destacados 0.5 Validando la historia de usuario

04/11/13 Desarrollo de la historia “Registrando jurados”.

7 Diseño, codificación y validación.

06/11/13 Revisión de la historia “Registrando jurados”.

0.5 Revisión de la funcionalidad

06/11/13 Corrección de errores destacados 0.5 Validando la historia de usuario

06/11/13 Desarrollo de la historia “Generando oficio de Asignación de Jurados”.

6 Diseño, codificación y validación.

08/11/13 Revisión de la historia “Generando oficio de Asignación de Jurados”.

0.5 Revisión de la funcionalidad

08/11/13 Corrección de errores destacados 0.5 Validando la historia de usuario

08/11/13 Desarrollo de la historia “Registrar ampliación de

7 Diseño, codificación y validación.

64

Fecha (Día/Mes/Año)

Actividad realizada Tiempo (horas)

Observaciones

prácticas”.

11/11/13 Revisión de la historia “Registrar ampliación de prácticas”.

0.5 Revisión de la funcionalidad

11/11/13 Corrección de errores destacados 0.5 Validando la historia de usuario

11/11/13 Desarrollo de la historia “Registrar informes finales aprobados”.

7 Diseño, codificación y validación.

12/11/13 Revisión de la historia “Registrar informes finales aprobados digitales”.

0.5 Revisión de la funcionalidad

12/11/13 Corrección de errores destacados 0.5 Validando la historia de usuario

13/11/13 Desarrollo de la historia “Reportando practicantes”.

6 Diseño, codificación y validación.

15/11/13 Revisión de la historia “Reportando practicantes”.

0.5 Revisión de la funcionalidad

15/11/13 Corrección de errores destacados 0.5 Validando la historia de usuario

15/11/13 Desarrollo de la historia “Reportando historial de practicantes”.

6 Diseño, codificación y validación.

18/11/13 Revisión de la historia “Reportando historial de practicantes”.

0.5 Revisión de la funcionalidad

18/11/13 Corrección de errores destacados 0.5 Validando la historia de usuario

18/11/13 Desarrollo de la historia “Reportando ranking de asesores”.

6 Diseño, codificación y validación.

20/11/13 Revisión de la historia “Reportando ranking de asesores”.

0.5 Revisión de la funcionalidad

20/11/13 Corrección de errores destacados 0.5 Validando la historia de usuario

20/11/13 Desarrollo de la historia “Reportando documento para supervisiones”.

6 Diseño, codificación y validación.

21/11/13 Revisión de la historia “Reportando documento para supervisiones”.

0.5 Revisión de la funcionalidad

21/11/13 Corrección de errores destacados 0.5 Validando la historia de usuario

22/11/13 Desarrollo de la historia 6 Diseño, codificación y

65

Fecha (Día/Mes/Año)

Actividad realizada Tiempo (horas)

Observaciones

“Reportando ranking de jurados”. validación.

23/11/13 Revisión de la historia “Reportando ranking de jurados”.

0.5 Revisión de la funcionalidad

23/11/13 Corrección de errores destacados 0.5 Validando la historia de usuario

23/11/13 Desarrollo de la historia “Reporte para Doc. De Gestión”.

6 Diseño, codificación y validación.

24/11/13 Revisión de la historia “Reporte para Doc. De Gestión”.

0.5 Revisión de la funcionalidad

24/11/13 Corrección de errores destacados 0.5 Validando la historia de usuario

25/11/13 Desarrollo de la historia “Reportando sustentaciones”.

6 Diseño, codificación y validación.

26/11/13 Revisión de la historia “Reportando sustentaciones”.

0.5 Revisión de la funcionalidad

26/11/13 Corrección de errores destacados 0.5 Validando la historia de usuario

30/11/13 Generando un repositorio Digital 4 Diseño, codificación y validación.

03/12/13 Revisión de Generando un repositorio Digital

0.5 Revisión de la funcionalidad

03/12/13 Corrección de errores de Generando un repositorio Digital

0.5 Validando la historia de usuario

03/12/13 Desarrollo de la historia “Consumir datos de OCDA”.

10 Diseño, codificación y validación.

06/12/13 Revisión de la historia “Consumir datos de OCDA”.

0.5 Revisión de la funcionalidad

06/12/13 Corrección de errores destacados 0.5 Validando la historia de usuario

06/12/13 Revisión general de la funcionalidad del sistema

10 Prueba finales a cargo del presidente de la CPPP

Reunión del equipo XP 1 Coordinación de las actividades adicionales

11/12/13 Entrega final del proyecto 0 Entrega del informe final Fuente: Elaboración propia

66

3.10 FASE4: PRUEBAS

Las pruebas funcionales que se realizaron a la aplicación se encuentran

separados por cada historia de usuario, se especifica el modo de utilización de la

aplicación y los posibles estados de error que pueden darse, así como los mensajes de

aviso/error/confirmación que debe emitir la aplicación en estos casos.

Participantes:

Para las pruebas funcionales se contó con el apoyo de del equipo de

estudiantes de desarrollo de software de la FIIS – UNAS, “TIMI world” conformado por

Cóndor Fernandez,Diccson

Muños Villalobos, José Derlin

Malpartida Arévalo, Nigel

Entorno:

Se desarrolló las pruebas en una máquina servidor de prueba (con ip

192.168.1.224), en el cual se armó una pequeña red LAN, para las pruebas por parte de

los participantes.

Participantes:

Formato:

El formato que se utilizó para las pruebas, fue tomado de una tesis de grado

“MODELO DE DESARROLLO AGIL”- Schenone Marcelo Hernán -2004, la cual se trató de

adecuar a las historias de usuario. Y quedo definida como se muestra en el cuadro 17.

CUADRO 17: “Diario de Actividades”

Historia Introducción

correcta

Condición de

ejecución

Entrada Resultado

esperado

Conformidad

(C)

Fuente: “MODELO DE DESARROLLO AGIL”- Schenone Marcelo Hernán -2004

El tiempo de pruebas que se realizo fue de 10 horas durante 3 días. A

continuación se muestra el resultado del trabajo realizado.

Figura 32: Pruebas de funcionalidad.

Fuente: Imagen tomada en el entorno de prueba

67

CUADRO 18: PRUEBA DE LA PRIMERA ITERACCIÓN

HISTORIA

INTRODUCCION CORRECTA CONDICIÓN DE EJECUCIÓN

ENTRADA RESULTADO ESPERADO C

H1. El usuario debe ingresar los campos de usuario, contraseña, eligiendo su tipo de comisión y dar clic en el botón ingresar.

Conexión del sistema a la base de datos PostgreSQL

La interfaz de acceso al sistema contiene dos campos de texto, uno para el Nombre del Usuario y el otro para la Contraseña y un botón Entrar.

Si el usuario se identifica con éxito la aplicación ingresará al menú principal, contrario debe aparecer mensaje de error “datos incorrectos vuelva a intentar por favor”

H2. El usuario administrador debe ingresar la fecha de inicio y final de la gestión de la comisión, cuidando que la fecha final sea mayor que la fecha inicial por un año. El número de resolución debe ser la misma con la que se creó la comisión por disposición del decano. El motivo de la creación no es obligatorio. Una vez llenado los campos hacer clic en el botón Guardar.

Conexión del sistema a la base de datos PostgreSQL

La interfaz tiene cuatro campos, un botón Guardar y otro para cancelar. El usuario administrador ingresará la fecha de inicio y fin de la gestión, el número de la resolución de su creación y el motivo por el cual fue creado (este último es opcional). Luego hacer clic el botón Guardar para registrar la comisión.

Si los datos son ingresados son correctos el sistema mostrará un mensaje de éxito indicando “Gestión guardado con éxito” y en caso contrario mostrará un mensaje de alerta indicando “Introducir los datos que faltan”

H3. El usuario Administrador debe seleccionar el grado e ingresar el nombre del nuevo integrante, para cada cargo. Una vez llenado los campos presionar en el botón Guardar.

Conexión del sistema a la base de datos PostgreSQL

La interfaz tiene 4 campos de texto autocompletables con búsqueda, y unas opciones para elegir el grado, luego debe hacer clic en guardar.

Si los datos ingresados por el usuario Administrador son correctos el sistema mostrará un mensaje de éxito indicando “Guardado con éxito” y en caso contrario mostrará un mensaje de alerta indicando “Error de validación”.

68

H4. El nombre y contraseña del usuario es autogenerado con tan solo buscar a un integrante ya registrado. El usuario Administrador debe de buscar de entre los integrantes y alumnos que quiere hacerles usuario del sistema. Una vez llenado los campos presionar en el botón Guardar

Conexión del sistema a la base de datos PostgreSQL

La interfaz cuenta con 2 campos de texto y un checklist, de los cuales uno es para elegir a los integrantes o alumnos de comisión, por medio de la web services de OCDA. El segundo campo para introducir su contraseña y por último en el chekclist debe seleccionar el tipo de usuario. Clic en Guardar.

Si los datos ingresados por el usuario Administrador son correctos el sistema mostrará un mensaje de éxito indicando “Guardado con éxito” y en caso contrario mostrará un mensaje de alerta indicando “Error de validación”.

H5. El usuario SPPP debe buscar por el código al alumno consultando a la webservices de OCDA para su validación de 160 créditos aprobados.

Conexión del sistema a la base de datos PostgreSQL

La interfaz cuenta un texto para escribir el código y con un botón para validar. El usuario SPPP debe ingresar el código con el requisito de los 00(dos ceros) al inicio y luego clic en validar y aceptar la búsqueda de la ventana emergente para confirmar validación.

Si encuentra al estudiante, debe escribir en los datos del practicante como nombre apellidos y créditos aprobados, en caso contrario aparecerá un mensaje “alumno no encontrado en OCDA”

H6. El usuario SPPP debe desplegar las opciones de empresa para la práctica, en caso de no encontrarlas debe hacer clic en el botón registro de empresas, el cual se mostrara en una pantalla emergente y finalmente clic en guardar.

Conexión del sistema a la base de datos PostgreSQL

La interfaz cuanta con un cuadro desplegable de opciones con búsqueda incluida, un botón para aumentar empresas por medio de una ventana desplegable la cual cuenta con 10 campos y un botón guardar.

Si se encuentra a la empresa se debe continuar con el registro de prácticas ,caso contrario aumentar una empresa, seleccionarla y validar selección no vacía con un mensaje de error “Empresa: Error de validación.-se necesita un valor”

H7. El usuario SPPP debe registrar Conexión del La interfaz está dentro del En caso de llenar los campos el

69

los campos e título de proyecto, resumen, pudiéndose explayar en detalle.

sistema a la base de datos PostgreSQL

registro de nuevos practicantes, cuenta con dos áreas de texto y son de carácter obligatorio por ser de interés para continuar con el registro de una práctica.

sistema le permitirá registrar al practicante en caso contrario validara con el siguiente error “Titulo : Error de validación” “Resumen: Error de validación.- necesita un valor”

H8. El usuario SPPP debe registrar las funciones del practicante, la cual será atreves de un campo de texto para visualizar las funciones y para agregar un botón que genere una ventana emergente por ser varias las funciones.

Conexión del sistema a la base de datos PostgreSQL

La interfaz cuanta con una caja de texto para las funciones, para registrar una nueva función debe seleccionar en el botón a lado derecho del campo de texto y hacer clic en Guardar.

De asignar funciones correctamente le permitirá guardar con éxito las prácticas, en caso de no llenar ninguna función se saldrá el siguiente error “Funciones: Error de validación”

70

CUADRO 19: PRUEBA DE LA SEGUNDA ITERACCIÓN

HISTORIA INTRODUCCION CORRECTA CONDICION DE

EJECUCION

ENTRADA RESULTADO ESPERADO C

H9. El usuario SPPP debe ir al menú

principal buscar al practicante y

en opciones (figura de la tuerca)

y hacer clic en Procesar, luego

clic en le hipervínculo de

“Asignar asesor”, seleccionar al

docente, la fecha de asignación,

el número de oficio y el nombre

del decano.

Conexión del sistema

a la base de datos

PostgreSQL

La interfaz cuenta con un campo de

opciones para seleccionar le grado

del docente, un campo de texto

con búsqueda para el asesor, un

campo de fecha con un calendario

y un campo más para el nombre

del decano por ultimo clic en

guardar.

Al llenar todos los campos de manera

correcta nos saldrá un mensaje de

confirmación “asesor guardado con

éxito”, caso contrario nos debe aparecer

un mensaje de error para los campos

nulos. Que diga “Error nombre del campo

:Error de validación”

H10. El usuario SPPP debe ir al menú

principal, buscar al practicante

luego ir a opciones (figura de la

tuerca) y clic en detalles, se

mostrara una ventana y hacer

clic en el nombre del asesor

para generar su oficio.

Conexión del sistema

a la base de datos

PostgreSQL

La interfaz muestra un cuadro con

el resumen de los datos del

practicante, en el nombre del

asesor aparece un hipervínculo

hacer clic para generar oficio.

Al hacer clic en el hipervínculo se debe

abrir una nueva pestaña, el cual muestre

el oficio por el cual el practicante fue

asignado el asesor y la respectiva

autorización.

H11. El usuario SPPP debe ir al menú

principal buscar al practicante y

en opciones (figura de la tuerca)

y clic en procesar, se mostrara

una ventana y hacer clic en el

hipervínculo de “supervisión de

práctica por docente”.

Conexión del sistema

a la base de datos

PostgreSQL

La interfaz cuenta con un campo de

texto con búsqueda para el asesor,

un campo de fecha con un

calendario, un campo enmascarado

con el número de oficio y un área

de texto para el detalle de la

supervisión.

Al llenar todos los campos de manera

correcta nos saldrá un mensaje de

confirmación “supervisión guardado con

éxito”, caso contrario nos debe aparecer

un mensaje de error para los campos

nulos. Que diga “Error nombre del campo

:Error de validación”

H12. El usuario SPPP debe ir al menú Conexión del sistema La interfaz cuanta con una ventana En caso que el practicante ya superó las

71

principal, buscar al practicante

luego ir a opciones (figura de la

tuerca) y clic en Ampliar

práctica.

a la base de datos PostgreSQL

emergente que describe al

practicante y el historial de sus

ampliaciones además de mostrar

un campo selecciónale con el

número de meses a ampliar y una

breve descripción.

dos ampliaciones como máximo no debe

salir la opción de ampliación, caso

contrario debe ampliar

satisfactoriamente con el mensaje

Prácticas ampliadas.

H13. El usuario SPPP debe ir al menú

principal buscar al practicante y

en opciones (figura de la tuerca)

y clic en procesar, se mostrará

una ventana y hacer clic en el

hipervínculo de “entrega de

informe de practicante”.

Conexión del sistema a la base de datos PostgreSQL

La interfaz cuenta con dos entradas

de texto, las cuales son para

registrar la fecha de entrega y

algunas observaciones si es que las

hubiese.

La ventana fecha será presentada con un

calendario para elegir la fecha, si el

ingreso de la fecha es correcta saldrá un

mensaje “Informe Registrado” caso

contrario “Fecha: Error de validación”.

H14. El usuario SPPP debe ir al menú

principal buscar al practicante y

en opciones (figura de la tuerca)

y clic en procesar, se mostrará

una ventana y hacer clic en el

hipervínculo de “asignación de

jurados”.

Conexión del sistema a la base de datos PostgreSQL

La interfaz tiene 4 opciones para

elegir los grados de los jurados y 4

campos de texto

autocompletables con búsqueda

para elegir a los docentes, en la

parte superior cuanta la fecha,

lugar y hora que se les está

asignado a la sustentación luego

debe hacer clic en guardar.

Si las introducciones son correctas y no

hay ningún campo en blanco el mensaje

será “Jurados y sustentación asignada”,

caso contrario saldrá el campo con el

error que ocurrió.

H15. El usuario SPPP debe ir al menú

principal buscar al practicante y

en opciones (figura de la tuerca)

y clic en procesar, se mostrará

una ventana y hacer clic en el

Conexión del sistema a la base de datos PostgreSQL

La interfaz cuenta con dos campos,

una para asignarle la nota que

obtuvo el sustentante, el rango es

de 0 a 20, y las observaciones que

hubo durante la sustentación para

Si las introducciones fueron correctas se

registrará la evaluación con éxito caso

contrario saldrá el campo con el error

que ocurrió.

72

hipervínculo de “calificar

resultados de sustentación”.

las posteriores correcciones luego

debe hacer clic en guardar.

H16. El usuario SPPP debe ir al menú

principal, buscar al practicante

luego ir a opciones (figura de la

tuerca) y clic en detalles, se

mostrara una ventana y hacer

clic en su estado. Para ver el

oficio de asignación de jurados.

Conexión del sistema

a la base de datos

PostgreSQL

La interfaz muestra un cuadro con

el resumen de los datos del

practicante, en el nombre del

asesor aparece un hipervínculo

hacer clic para generar oficio.

Al hacer clic en el hipervínculo se debe

abrir una nueva pestaña, el cual muestre

el oficio por el cual el practicante fue

asignado el asesor y la respectiva

autorización.

H17. El usuario SPPP debe ir al menú

principal buscar al practicante y

en opciones (figura de la tuerca)

y clic en procesar, se mostrara

una ventana y hacer clic en el

hipervínculo de “registrar

informe final aprobado”.

Conexión del sistema a la base de datos PostgreSQL

La interfaz cuenta con un botón

para seleccionar el origen del

archivo en formato .pdf con un

máximo de 30MB(MegaBytes)

.Al hacer clic en el botón para elegir el

informe debe subir al repositorio de

mostrando el porcentaje de subido y

hacer clic en guardar debe salir en

mensaje “Informe subido con Éxito” caso

contrario un error. “intente de nuevo”

73

CUADRO 20: PRUEBA DE LA TERCERA ITERACCIÓN

HISTORIA INTRODUCCION CORRECTA CONDICION DE

EJECUCION ENTRADA RESULTADO ESPERADO

C

H18. El usuario del SPPP debe ir al menú

reportes y hacer clic en la opción

“practicantes”.

Conexión del sistema a la base de datos PostgreSQL

La interfaz muestra una

ventana emergente

para el ingreso de dos

parámetros que serán

las fechas en la que se

requiera el reporte del

practicante.

Al ingresar correctamente los datos de las

fechas para ver el reporte se mostrará una

nueva pestaña con el reporte de los

practicantes y datos como nombres, asesor,

fecha de inicio y fecha de fin y las opciones

para convertir a diferentes formatos o

imprimir directamente.

H19. El usuario del SPPP debe ir al menú

reportes y hacer clic en la opción

“historial de practicantes”.

Conexión del sistema a la base de datos PostgreSQL

La interfaz muestra una

ventana emergente

para el ingreso de un

parámetro que es el

código del practicante.

Al ingresar correctamente los datos de las

fechas para ver el reporte se mostrará una

nueva pestaña con el reporte esperado y las

opciones para convertir a diferentes

formatos o imprimir directamente.

H20. El usuario del SPPP debe ir al menú

reportes y hacer clic en la opción

“ranking de asesores”.

Conexión del sistema a la base de datos PostgreSQL

La interfaz muestra una

ventana emergente

para el ingreso de dos

parámetros que serán

las fechas en la que se

requiera el reporte del

ranking de asesores.

Al ingresar correctamente los datos de las

fechas para ver el reporte se mostrará una

nueva pestaña con el reporte esperado y las

opciones para convertir a diferentes

formatos o imprimir directamente.

H21. El usuario del SPPP debe ir al menú

reportes y hacer clic en la opción

“Documento para supervisiones”

Conexión del sistema a la base de datos PostgreSQL

La interfaz muestra una

ventana emergente

para el ingreso de un

parámetro que es el

código del practicante.

Al ingresar correctamente los datos de las

fechas para ver el reporte se mostrará una

nueva pestaña con el reporte esperado y las

opciones para convertir a diferentes

formatos o imprimir directamente.

74

H22. El usuario del SPPP debe ir al menú

reportes y hacer clic en la opción

“ranking de jurados”.

Conexión del sistema a la base de datos PostgreSQL

La interfaz muestra una

ventana emergente

para el ingreso de dos

parámetros que serán

las fechas en la que se

requiera el reporte del

ranking de jurados.

Al ingresar correctamente los datos de las

fechas para ver el reporte se mostrará una

nueva pestaña con el reporte esperado y las

opciones para convertir a diferentes

formatos o imprimir directamente.

H23. El usuario del SPPP debe ir al menú

reportes y hacer clic en la opción

“documentos de gestión”.

Conexión del sistema a la base de datos PostgreSQL

La interfaz muestra una

ventana con las

opciones de los

formatos de

documentos a imprimir

mostrándose en una

nueva pestaña del

navegador.

Al ingresar correctamente los datos de las

fechas para ver el reporte se mostrará una

nueva pestaña con el reporte esperado y las

opciones para convertir a diferentes

formatos o imprimir directamente.

H24. El usuario del SPPP debe ir al menú

reportes y hacer clic en la opción

“reporte de sustentaciones”.

Conexión del sistema a

la base de datos

PostgreSQL

La interfaz muestra una

ventana emergente

para el ingreso de dos

parámetros que serán

las fechas en la que se

requiera el reporte de

las sustentaciones.

Al ingresar correctamente los datos de las

fechas para ver el reporte se mostrará una

nueva pestaña con el reporte esperado y las

opciones para convertir a diferentes

formatos o imprimir directamente.

75

CUADRO 21: PRUEBA DE LA CUARTA ITERACCIÓN

HISTORIA INTRODUCCION CORRECTA CONDICIÓN DE

EJECUCIÓN

ENTRADA RESULTADO ESPERADO C

H25. El usuario SPPP debe ir al menú

principal buscar al practicante y en

opciones (figura de la tuerca) y clic en

procesar, se mostrara una ventana y

hacer clic en el hipervínculo de

“registrar informe final aprobado”.

Conexión del sistema a

la base de datos

PostgreSQL.

La interfaz muestra una ventana con tres

botones, uno para buscar el archivo en la

maquina local, otro para subirlo y otro

para guardarlo registrando la fecha y las

observaciones. Además el formato será

.pdf y el peso máximo 30MB.

Se debe actualizar el menú biblioteca con

el nuevo archivo subido.

Si se cumplió el con

formato y el tamaño del

archivo debe subir al

repositorio y actualizar el

registro de informes,

verificado en la parte de

menú, Biblioteca. Caso

contrario saldrá mensajes

de error.

H26. Consumir datos de OCDA Conexión al servidor

Local Apache.

Cuenta con un botón en la parte de

registrar nuevo practicante, para validar

en OCDA los datos del código ingresado,

además el código es validado con 2 ceros

delante. Ejemplo 0020090318.

Si la conexión es

satisfactoria traerá los

datos del alumno como

nombres y créditos

aprobados, para su

registro en caso contrario

nos mostrara un mensaje

de error.

3.10. RESUMEN DE LAS PRUEBAS:

Las pruebas fueron desarrolladas durante 10 horas por 3 días en total; se realizaron siguiendo las historias de usuario por

iteraciones y se pudo comprobar que todas la funcionalidades, analizadas y vistas desde mi punto de vista como futuro profesional, son

correctamente y rinde en los escenarios requeridos.

76

CONCLUSIONES

1. Se logró desarrollar el sistema de Prácticas pre profesionales “SPPP” V1.0, con el

uso del modelo XP (Programación Extrema) con la tecnología Java Web, haciendo

uso de frameworks de desarrollo, aplicando el modelo de Vista Controlador,

PrimeFaces en la capa de presentación, Hibernate en la capa de modelo y Spring

para la Inyección de dependencias, en un periodo de 96 días.

2. Se logró recolectar las 26 historias de usuarios en un total de 22 días, el trabajo de

campo se hizo inter diario por la misma carga laboral de los docentes miembros de

la comisión.

3. Al obtener las historias de usuario se logró planificar el desarrollo de un total de 78

tareas realizables con un esfuerzo estimado de 176 horas.

4. Se hizo el análisis de los documentos de gestión, normativo y mediante observación

directa, entrevistas informales, se logró como resultado, diseñar 8 procesos.

5. Se logró construir la base de datos, bajo el gestor PostgresQL 9.2. de la comisión de

prácticas pre profesionales, con lenguaje de escritura en inglés, además de ello está

sirviendo para la integración con las demás comisiones para tener una base de

datos integral para la Facultad de ingeniería en informática y Sistemas.

6. Se construyó el software en base a las tareas planificadas con tecnologías java Web,

utilizando Apis para agilizar el desarrollo, obteniendo como resultado un prototipo

con 14 vistas, 36 modelos.

7. Se realizó con éxito las pruebas del software, obteniendo muy buenos resultados en

cuanto a la consistencia mediante las historias de usuario planificadas.

8. Se contó con un sistema de referencia el cual, se pretendió reanudar, el hecho

observar que los componentes y herramientas utilizadas ya están desfasadas,

además de no alinearse a lo que se quiere conseguir a fututo mediante

estandarización de lenguajes de desarrollo propuestos por CTIC-UNAS, se procedió

a la construcción desde un inicio ajustando al nuevo reglamento 2013

77

9. El “SPPP” versión 1.0 está desarrollado para satisfacer las necesidades funcionales

de la Comisión de Prácticas Pre Profesionales de la Facultad de Ingeniería en

Informática y Sistemas por las siguientes razones:

a. Creación y administración de Comisiones.

b. Creación y administración de Integrantes de una comisión.

c. Creación y administración de Usuarios del “SPPP” versión 1.0 para una comisión.

d. Creación y supervisión textual de los Practicantes.

e. Asignación de asesores, jurados y fechas de sustentaciones a los practicantes.

f. Diversos reportes de los practicantes, ranking de asesores, informes, jurados,

sustentaciones, repositorio digital.

g. Diversos documentos digitales de autorización de prácticas y asignación de

asesor, designación de jurados, jurado de sustentación, ficha de inscripción,

actas de sustentación, remisión de informes finales y dictamen de ampliación.

h. Usabilidad, confiabilidad, mantenibilidad y eficiencia.

10. Se utilizó con un sistema de control de versiones que está en línea en google.code

esto sirvió para actualizar remotamente en un solo almacén central, cada cambio

que se hacía.

78

RECOMENDACIONES

1. Que se oficialice el uso del software por parte de la comisión mediante resolución

de consejo de Facultad.

2. Habilitar un servidor de aplicaciones, configurar, instalar, implementar y

complementar el “SPPP” versión 1.0 en el Centro de Tecnología de Información y

Comunicación-UNAS para su funcionamiento. Si es posible asignar estas tareas a

otro estudiante con motivo de sus Prácticas Pre Profesionales.

3. Antes del despliegue realizar nuevas pruebas funcionales con la presencia de los

miembros de la comisión y alumnos, para mayor conformidad.

4. Realizar una capacitación en el manejo de las funcionalidades del “SPPP” versión 1.0

para el administrador y los usuarios.

5. Utilizar el sistema una vez instalado y aprovechar las funcionalidades que brinda. En

caso de no cumplir al 100% un requerimiento o aparecer en nuevos requerimientos

o algunas inconsistencias, no cometer el error de almacenarlo y olvidar sino tratar

de anotarlos en algún documento físico o virtual para luego solicitar el desarrollo

del “SPPP” versión 2.0.

6. Que se siga esta línea de desarrollo para la integración de las comisiones así como el

sistema de trámite documentario de la Facultad de ingeniería en informática y

sistemas, ya que se dio el primer paso para realizar lo comentado, ahora depende

de las autoridades dar la continuidad del caso.

7. Para fines de apoyo del proyecto se utilizó el modelo de desarrollo XP, aun así está

orientado a grupos de desarrollo, y se recomienda como posible tema de tesis la

creación de un modelo de desarrollo orientado a los programadores individuales, ya

que no todas las sugerencias de XP ni otros modelos son útiles para casos como

esta práctica.

79

BIBLIOGRAFÍA

1. Dr. Wilson Castillo Soto, E. (2001). Normas Técnicas para la Redacción y Presentación

de Documentos Científicos. Tingo María, Perú. 47 p.

2. CORTIZO PÉREZ, J., EXPÓSITO GIL, D. Y RUIZ LEYVA, M. (2010). eXtreme Programming.

97 p. Disponible en: http://www.esp.uem.es/jccortizo/xp.pdf. Accesado el 20 de

Enero del 2010.

3. JAVASCRIPTYA (2009). Curso. Disponible en línea : http://www.javascriptya.com.ar/.

4. INGENIERÍA DEL SOFTWARE – Roger Pressman.6th.Ed.McGraw-Hill.pdf Pág.45

5. PROGRAMACIÓN EXTREMA (2010). 15 p. Disponible en:

http://eisc.univalle.edu.co/materias/WWW/material/lecturas/xp.pdf. Accesado el 20

de Enero del 2010.

6. PÁGINA OFICIAL DE PRIMEFACES disponible en línea

http://www.primefaces.org/showcase/ui/csvBasic.jsf

7. INGENIERÍA DEL SOFTWARE – Roger Pressman.6th.Ed.McGraw-Hill.pdf Pág.106

8. PROGRAMACIÓN EXTREMA-

Ingenieria.de.Software.Ian.Sommerville.7ma.Edicion.PRENTICE-HALL.Pág.373

9. SERRA MACHADO DAVID – “Estudio del servidor de aplicaciones Glassfish y de las

aplicaciones J2EE“pág. 182 disponible. [En línea]:

ddd.uab.cat/pub/trerecpro/.../SerraManchadoDavidR-ETISa2009-10.pdf

10. PAGINA OFICIAL DE POSTGRESQL disponible [En línea]:

http://www.postgresql.org.es/sobre_postgresql

11. PÁGINA OFICIAL DE POSTGRESQL disponible [En línea]: https://www.java.net/

80

OTRAS ACTIVIDADES REALIZADAS DURANTE LA PRÁCTICA PRE

PROFESIONAL.

1. Configuración y administración del controlador de dominio en Windows server

2008R2 del laboratorio de sistemas.

Esta actividad se realizó previo acuerdo con del Jefe del laboratorio Ing. George

Paucar Palomino, por motivos de control a los usuarios tanto alumnos y

docentes.

Se definió las políticas a configurar por ejemplo: que los usuarios no puedan

insertar dispositivos periféricos a las maquinas como medida a la infección

descontrolada de virus.

81

2. Administración del servicio de File Share en Windows server 2008R2.

Para complementar el servicio de controlador de dominio y como solución a la

política del acceso a dispositivos periféricos, se propuso la configuración de

archivos compartidos mapeados en cada computadora de los usuarios del

laboratorio de sistemas, asi puedan compartir archivos sin necesidad del usb.

3. Configuración y administración del servidor proxi squid en Centos 6.4.

Tras la llegada del internet al laboratorio de sistemas no se tuvo control del

acceso a las páginas, por lo que se generó un desorden, en consecuencia se

propuso la configuración de un servidor proxi squid en Linux (Centos 6.4), que

sirvió para controlar el acceso a páginas sociales, juegos, videos entre otros.

4. Administración de la Red e internet del laboratorio de sistemas.

Se administró la red interna del laboratorio asegurando conectividad para el servicio

continuo del laboratorio, además el acceso a los usuario inalámbricos que no estaban en

el dominio, mediante control por filtrado MAC.

5. Apoyo en la administración general del laboratorio de sistemas.

Apoyo en la atención de los servicios del laboratorio de Sistemas a los docentes y

alumnos de la Facultad de ingeniería en informática y sistemas.

82

ANEXOS