Professional Documents
Culture Documents
Tutor
ING. DAMIAN BARRIOS CASTILLOS
CONTENIDO
RESUMEN
1. PROBLEMA DE INVESTIGACION
1.1 PLANTEAMIENTO DEL PROBLEMA
1.2 FORMULACION DEL PROBLEMA
1.3 JUSTIFICACION
1.4 OBJETIVOS
1.4.1 Objetivo general
1.4.2 Objetivos especficos
2. MARCO DE REFERENCIA
2.1 MARCO HISTORICO
2.2 INVESTIGACIONES PREVIAS
2.3 MARCO TERICO
2.3.1 Scrum
2.3.2 Sistemas de informacin
2.3.3 Lenguajes de Programacin
2.3.4 Html (HyperText Markup Language)
2.3.5 Php (PHP HyperText Pre-processor)
2.3.6 Base de datos
2.3.7 JavaScript
2.3.8 Metodologa Tradicional
2.4 MARCO CONCEPTUAL
3. DISEO METODOLOGICO
3.1 TIPO DE INVESTIGACION
3.2 DISEO ADOPTADO
3.3 ENFOQUE DE LA METODOLOGIA
3.4 TECNICAS DE RECOLECCION DE LA INFORMACION
3.4.1 Fuentes primarias
3.4.2 Fuentes secundarias
3.5 VARIABLES
3.6 OPERACIONALIZACION DE VARIABLES
3.7 PROCESAMIENTO DE LA INFORMACION
3.8 RECURSOS TECNOLOGICOS
3.8.1 El Paradigma de Programacin
3.8.2 Herramienta de Desarrollo de Software
3.8.3 Herramientas Software
3.8.4 Herramientas de Diseo
3.8.5 Herramientas Hardware
4. RESULTADOS
4.1 API: PUNTO DE PARTIDA COMO FUENTE DE SERVICIOS
4.2 REQUERIMIENTOS
4.2.1 Product Backlog
4.3 ITERACIONES DE IMPLEMENTACION DE LOS PRODUCTOS
4.3.1 Exposicin del Product Backlog
4.3.2 Resolucin del Sprint Backlog
4.3.4 Revisin del Sprint
4.4 DISEO Y DESARROLLO DE INTERFACES
4.5 EJECUCION DE PRUEBAS
III
VIII
2
2
4
4
6
6
6
7
7
8
9
9
14
15
16
17
18
19
20
20
22
22
22
22
23
23
24
24
25
26
26
26
27
27
28
28
29
29
34
35
38
38
39
42
53
77
CONCLUSIONES
REFERENCIAS
80
81
IV
LISTA DE TABLAS
25
43
43
43
43
44
44
44
44
45
46
46
47
47
48
49
50
50
51
52
53
53
LISTA DE FIGURAS
VI
13
30
31
36
40
41
48
54
55
56
57
57
58
59
60
61
61
62
63
64
64
65
66
67
68
68
69
70
71
72
73
74
75
75
76
77
LISTA DE ANEXOS
83
84
VII
RESUMEN
VIII
INTRODUCCION
Con la aparicin de la computacin digital, inicio el periodo de ms desarrollo
tecnolgico
jams
visto
por
la
humanidad:
viajes
espaciales,
telecomunicaciones, Internet, entre otros. Un elemento de importancia en este
desarrollo de tecnologas lo ha constituido el software, el cual facilita el manejo
del hardware.
El software, definido como un conjunto de instrucciones que controlan la
realizacin de tarea de un hardware, puede dividirse en varias categoras
basadas en el tipo de trabajo que realizan. Las dos categoras primarias de
software son, los Sistemas Operativos que controlan los trabajos del
computador como el mantenimiento de los archivos del disco y la
administracin de la pantalla, y el software de aplicacin que dirige las distintas
tareas para las que se utilizan el computador como edicin de textos, gestin
de bases de datos y similares.
Los desarrollos de hardware y software han sido muy dinmicos a la vez que
requieren de procesos cada vez ms complejos de produccin. Seguir una
metodologa no apropiada para el desarrollo puede llevar a consumir
demasiados recursos de tiempo o dinero, a la vez que se corre el riesgo de no
llenar las expectativas que tena el cliente con respecto al producto o
desarrolladores insatisfechos con el mismo. Encontrar y seguir la metodologa
adecuada para el tipo de desarrollo, marca el xito del software.
La utilizacin de las llamadas metodologas tradicionales en el desarrollo de
software (Cascada, RUP, entre otras), caracterizadas por la implementacin
de etapas secuenciales ejecutadas unas despus de otras, guiadas por una
planificacin rgida, con lo que pretende controlar todo el proceso (planificacin,
diseo, implementacin, evaluacin), son aplicadas cada vez menos en
ambientes de desarrollo de software. En contraposicin, las metodologas
agiles han despertado un creciente inters, que las ha llevado a campos
diferentes al de la ingeniera de software.
Dentro de las diferentes propuestas de mejora al desarrollo secuencial se
encuentra Scrum. ste es una tcnica de desarrollo caracterizada por integrar
caractersticas de las metodologas giles a los que se aaden la
implementacin de iteraciones denominadas Sprint, que deja como resultado
un incremento ejecutable que se pueden mostrar al cliente y reuniones diarias
de 15 minutos a los largo del ciclo del Sprint, que permite al equipo
autorregularse, coordinarse e integrarse.
El inters del presente proyecto gira entorno a desarrollos logrados siguiendo
metodologas de desarrollo gil: especficamente Scrum. A lo largo del trabajo
se muestra la implementacin y resultados logrados a partir de esta
metodologa de trabajo, dentro de la elaboracin de frontend de las
aplicaciones (desarrollo de controladores e interfaces graficas de usuario) de
procesos acadmicos en la Universidad de San Buenaventura Cartagena.
1. PROBLEMA DE INVESTIGACION
Chapin, N., Hale, J.E., Khan, K.M., Ramil, J. and Tan, W. Types of software evolution and software
maintenance. Journal of Software Maintenance and Evolution: research and practice. 2001. pp. 3-30.
1
Grupo ISSI. Metodologas giles en el Desarrollo de Software. Editorial Alicante. Espaa, 12 de
Noviembre de 2003. pp. 9-16.
2
Grupo ISSI. Metodologas giles en el Desarrollo de Software. Editorial Alicante. Espaa, 12 de
Noviembre de 2003. pp. 9-16.
1.2
1.3
JUSTIFICACION
1.4 OBJETIVOS
1.4.2 Objetivos especficos. Identificar los servicios que ofrece la API diseada
por el CEV, buscando a partir de esto, tener una mayor apropiacin de los
recursos que sta provee.
Identificar los requerimientos que delimitan las funcionalidades de la segunda
fase.
Describir el proceso gua que lleva la metodologa Scrum en el desarrollo de los
productos de la fase dos.
Disear y desarrollar las interfaces de usuario que siguiendo la metodologa
Scrum, respondan a los diferentes requerimientos surgidos en los procesos
propios de la fase dos, logrando que sean amenas, intuitivas y prcticas
Disear y ejecutar pruebas que permiten evaluar los prototipos funcionales
desarrollados, detectando puntos de falla que stos puedan tener.
Elaborar un manual de implementacin que refleje en detalle el desarrollo de
aplicaciones utilizando la metodologa SCRUM a partir de los casos de xito
del CEV.
2. MARCO DE REFERENCIA
2.1
MARCO HISTORICO
Scrum fue mostrada por primera vez a mediados de los ochenta como nueva
prctica de produccin alcanzado por empresas de desarrollo tecnolgico como
Fuji-Xerox, Canon, Honda, Nec, Epson, Brother, 3M y Hewlett-Packard, y que
fue estudiada por Hirotaka Takeuchi e Ikujijo Nonaka. Con el artculo titulado
The New Product Development Game, Ikujiro & Takeuchi dieron continuacin
a otro artculo escrito con Kenichi Imai, llamado Managing the New Product
Development Process: How Japanese Companies Learn and Unlearn. En
estos expusieron una nueva prctica en el desarrollo de productos tecnolgicos
desplegada en Japn, resaltando el solapamiento de las fases de desarrollo
como su principal caracterstica, en contraste con los mtodos clsicos, los
cuales emplean desarrollos secuenciales, pero que en la prctica son en
realidad secuenciales con solapamiento.
En 1991 Peter DeGrace y Leslie Stahl hacen referencia al proceso mencionado
por Takeuchi y Nonaka con el trmino Scrum en su libro Wicked Problems,
Righteous Solutions (A problemas malvados, soluciones virtuosas), vocablo
que fue tomado del juego del rugby para describir procesos adaptativos, autoorganizativos y sin elementos innecesarios, y que ya haba sido utilizado por
estos ltimos.
A partir del trabajo realizado por Hirotaka Takeuchi e Ikujijo Nonaka, Jeff
Sutherland aplicara los principios de Scrum al desarrollo de Software en 1993
en Easel Corporation (actual Ascential Software Corporation), publicando en
1996 junto con Ken Schwaber, las prcticas que empleaba como vlidas para
gestionar el desarrollo de software OOPSLA 96 (Schwaber & Sutherland,
1996).
Paralelo a este proceso, a mediados de los 90, se dio la definicin de
desarrollo gil de software como una forma de contravenir hasta ese momento
las metodologas clsicas, las cuales se consideraban excesivamente pesadas
y rgidas por su carcter normativo y dependencia fuerte de las planificaciones
detalladas. Fue as como en 2001 miembros destacados de la comunidad de
software, creadores e impulsores de las nuevas metodologas de desarrollo, de
los cuales hacan parte Schwaber y Sutherland, bautizaron la nueva corriente
de metodologas de desarrollo como Metodologas Agiles.
En el mismo ao 2001 fue constituida la Alianza agil, una organizacin sin
animo de lucro que promueve el desarrollo gil de aplicaciones y del que
Scrum hace parte como modelo para gestionar el desarrollo de software.
Amaro C., Sarah y Jorge C. Valverde; Metodologas Agiles. Universidad Nacional de Trujillo. Trujillo,
Per, 2007.
6
Palacio, Juan. Flexibilidad con Scrum. Disponible en http://www.lulu.com, consultado el 23 de marzo
de 2012.
7
Ibd., pp. 18.
10
Amaro C., Sarah y Jorge C. Valverde; Metodologas Agiles. Universidad Nacional de Trujillo. Trujillo,
Per, 2007.
9
Ibd., pp. 26.
10
PALACIOS, Juan ; El Modelo Scrum PDF 2006; Pg.2, , Capitulo 1. Disponible en
http://www.navegapolis.net/files/s/NST-010_01.pdf. Consultado el 18 de Marzo de 2012
11
Ibd.
11
Es decir, tareas
12
YAZY ,Sergio Adrin . Una experiencia prctica de Scrum a travs del aprendizaje basado en proyectos
mediado por TIC en un equipo distribuido PDF 2010 -2011; pp. 20 . Disponible en
http://gredos.usal.es/jspui/bitstream/10366/100082/1/TFM_YazyiSergio_Master.pdf. Consultado el 22
de Marzo de 2012.
12
13
17
STAIR, Ralph y George W. Reynolds. Principios de Sistemas de Informacin. Mxico, 2000, Editorial
Thomson, p 4 - 5.
14
15
19
16
17
18
22
19
20
21
3. DISEO METODOLOGICO
Ibd., p. 188
Ibd., p. 190
25
Ibd., p. 191
24
22
3.5 VARIABLES
En la metodologa cualitativa, los datos recogidos necesitan ser traducidos en
categoras con el fin de poder realizar comparaciones y posibles contrastes, de
manera que se pueda organizar conceptualmente los datos y presentar la
informacin siguiendo algn tipo de patrn o regularidad emergente. La
categorizacin (es decir, cerrar o establecer las categoras) facilita la
clasificacin de los datos registrados, y por consiguiente, propicia una
importante simplificacin26. Teniendo en cuenta lo anterior se determinan las
siguientes variables:
Aplicacin Software
Procesos acadmicos
Base de datos
Scrum
26
24
VARIABLE
Aplicacin
Software
Procesos
acadmicos
Base de
Datos
Scrum
DEFINICION
DIMENSION
Es un programa diseado Anlisis
para
automatizar
una
determinada tarea. Consta
de
una
serie
de Diseo
instrucciones lgicas y en
orden con el fin de cumplir Implementacin
un objetivo.
INDICADORES
Suficiente
Insuficiente
Simple
Complejo
Suficiente
Insuficiente
Administrativos
Los procesos acadmicos
son todos aquellos trmites
relacionados con la vida Acadmicos
acadmica
de
los
estudiantes referidos a los
procesos
de
matrcula,
pagos,
evaluacin
de
docentes, consulta de notas
y horarios.
Simple
Complejo
Simple
Complejo
Almacenamiento
Es un conjunto de datos
almacenados
sistemticamente para su
uso posterior, permitiendo Consulta
operaciones
como
actualizacin, borrado y
adicin de datos, adems
de
las
operaciones
fundamentales de consulta
Satisfactorio
Insatisfactorio
Satisfactorio
Insatisfactorio
25
Satisfactorio
Insatisfactorio
27
ORTEGA MONTALVO, Nohora y otro. Desarrollo de un aplicativo web para apoyar el anlisis
estructural del proceso prospectivo en las organizaciones. Universidad de San Buenaventura Cartagena,
Colombia.
26
3.8.3
28
Ibd.
27
Procesador de 2.8GHz.
2GB DDR2 de Memoria RAM.
250GB de espacio en disco.
Sistema operativo Microsoft Windows XP, Vista 7.
28
4 RESULTADOS
29
Gua Arquitectura N-Capas Orientada al Dominio - Microsoft Architecture (1a Edicin Noviembre
2010)
30
Ibd.
29
Ibd.
30
4.2 REQUERIMIENTOS
Como ya se manifest anteriormente, la informacin pertinente para el correcto
desarrollo de ste proyecto se obtuvo a travs de la asesora continua del
Coordinador Tecnolgico del CEV Javier Garca Altamiranda, el cual actu
como gestor de la idea de implementar Scrum y su posterior orientador en el
desarrollo del mismo, buscando mejorar el ndice de desarrollo de software.
Cabe tambin aclarar que se ha seguido las caractersticas principales de
Scrum como son las iteraciones de trabajo o Sprint y las reuniones diarias de
15 minutos. A partir de esto el Ingeniero Javier Garca ha realizado cambios en
el uso de artefactos as como ha seguido el consejo de incorporar otros como
lo es el del Juego de Pker utilizado para la asignacin de horas a las
actividades y que es propio de otra metodologa gil de desarrollo, ms
concretamente, Xtreme Programing.
La informacin acerca de la lgica de negocio se consign en las historias de
usuario; la elaboracin de stas se realiz a lo largo del desarrollo del proyecto,
en reuniones que integraron al Ingeniero Javier Garca y a la ingeniera Tulia
Ziga Quintana como representante de la Universidad, siendo el primero el
Representante del Cliente (Product Owner) y el Scrum Manager, dos roles bien
definidos dentro de Scrum.
34
36
37
4.3.1 Exposicin del Product Backlog. Una vez establecido el Product Backlog,
se realiz la primera reunin con todos los integrantes del proyecto (Product
Owner, Scrum Master y Scrum Team); su duracin de 8 horas en promedio fue
dividid en dos partes: en la primera de 4 horas, el Product Owner describi
todas las funcionalidades del producto o tambin llamadas Historia de Usuario.
Durante la primera parte de la reunin se definieron por parte del Product
Owner, los elementos de alta prioridad.
38
Una vez decidido el tiempo por cada actividad y el tiempo disponible para el
trabajo del Sprint, se crearon los memos en donde se colocaba el nombre de la
actividad y el tiempo dedicado a la misma, colocndose en el Sprint Backlog.
El Sprint Bagklog era una herramienta que permita de forma visual, realizar
seguimiento y control a las tareas que iban circulando por las columnas de No
empezado, pasando por En Progreso y terminando en Completado.
para que fuese l quien tomase las medidas al respecto. Se proceda como
viene a continuacin:
4.3.4 Revisin del Sprint. Cuando termin el Sprint se hace la revisin del
mismo. El Scrum master y a la vez representante del Cliente no slo revisaba
el entregable del producto o los demos sino tambin la calidad del trabajo, de
forma que no se pudiese disimular los cdigos desordenados, sin probar y de
mala calidad.
La revisin del Sprint tambin implicaba que el equipo hablase sobre lo que
funciona y lo que no, y se acordaban que cambios se queran intentar. Se
dejaba claro qu fue bien y qu se puede mejorar, buscando causas y
previnindolas en el prximo Sprint.
Llegado este punto, se iniciaba la planeacin del siguiente Sprint, siendo
definido la fecha y lugar durante la revisin del Sprint. En este punto el Product
Owner poda actualizar la pila del Product Backlog con cambios o nuevas
actividades. El Product Owner y el equipo estaban listos para empezar otro
ciclo de Sprint, por lo cual no haba tiempo de descanso, manteniendo un ritmo
sostenible y razonable.
Con lo descrito hasta el momento se ha detallado el proceso que se sigui para
el desarrollo del primer Sprint y fue repetitivo en el desarrollo de los siguientes
Sprint hasta la obtencin de los productos finales: Portal de Docentes,
Seguimiento de Prcticas, Portal Estudiante, Portal Egresados y Portal de
Elecciones. En total se realizaron 5 Sprint o iteraciones que se detallan a
continuacin:
42
Sub-Actividades
Obtencin de
Requerimientos
Comentario
Ninguno
Realizar Certificados
Prioridad
Tiempo
Media
4 Horas
Sub-Actividades
Definir que
certificados se
sistematizan
Definir procesos de
certificados
Estudiar Firma
Digital
Comentario
Ninguno
Media
4 Horas
Ninguno
Baja
2 Horas
Ninguno
Sub-Actividades
Definir Proceso
Comentario
Ninguno
Sub-Actividades
Diseo de UI
Controlador de
Envo de Correo
UI envo de correo
Alta
6 Horas
Media
2 Horas
Comentario
Mostrar Cdigo,
nombre y apellido,
y agregar botn
enviar
Enviar por SMPT,
sendmail, phpmail
WYSIWYG, array,
destinatario POST
43
Sub-Actividades
Agregar el estado
del Estudiante
Diseo UI
Baja
4 Horas
Comentario
Creacin HBM,
entidades API,
entidades PHP
Agregar atributo
estado
Sub-Actividades
Agregar Docente
a la UI
Comentario
Ninguno
Sub-Actividades
Cambiar Nombre
al Mdulo
Agrupar
Aprobadas por
semestre
Agrupar Cursos
Pendientes por
Semestre
Agrupar Pensum
del Programa
Comentario
Ninguno
Media
3 Horas
Ninguno
Media
3 Horas
Ninguna
Media
3 Horas
Ninguna
Sub-Actividades
Sincronizar cortes
con programacin
acadmica
Obtener periodo
acadmico por
GET
Media
2 Horas
Comentario
Tener en cuenta el
nuevo reglamento
institucional
Ninguna
Urgente
6 Horas
Ninguno
Colocar como no
editables los
campos
pertinentes
Media
4 Horas
Implementar
formulario de
Historial Laboral
como MODAL
Implementar
formulario de
Historial
Acadmico como
MODAL
Implementar
formulario de
Estudios de
Idiomas como
MODAL
Baja
2 Horas
5 Siempre
editable datos
personales
6 Cuando no
existan datos
del nombre del
padre y de la
madre, ser
editables
Ninguno
Baja
2 Horas
Ninguno
Baja
2 Horas
Ninguno
Sub-Actividades
Definicin de
Procesos
Comentario
Ninguna
Sub-Actividades
Crear Solicitud de
Practicas
Prcticas Empresariales
Prioridad
Tiempo
Medio
2 Horas
Crear Mdulo de
Gestin de
Empresas
Crear Mdulo de
Finalizacin de
Practicas
Crear Mdulo de
Valoracin de
Practicante
Crear Mdulo para
Responder
Practicante
Medio
2 Horas
Comentario
Posterior a la
creacin de la
solicitud, se debe
enviar un Mail al
responsable
(Coordinador de
Practicas)
Ninguna
Medio
5 Horas
Ninguna
Baja
4 Horas
Valoracin de Inicial
y Valoracin Final
Media
5 Horas
Media
5 Horas
Este es el mdulo
en el que el
Coordinador decide
en donde se
realizar las
prcticas de
acuerdo con las
solicitudes.
Ninguna
46
Persistencia de Acaweb
Prioridad
Tiempo
Urgente
11 Horas
Sub-Actividades
Realizar Active
Record Factory
Realizar
Adecuacin del
Modelo
Urgente
Comentario
Ninguna
3 Horas
Ninguna
Sub-Actividades
Agregar entidad
Reconocimientos
Agregar Encuesta
a la BD
Baja
1 Hora
Realizar UI
Actualizacin de
Datos de
Egresados
Urgente
4 Horas
Agregar
Funcionalidad al
Mdulo
Urgente
6 Horas
Comentario
Agregar en API,
Acaweb y Base de
Datos
Ninguna
Sub-Actividades
Cambios en los
script en general
Inscripciones en
lnea provisional
Imprevistas Sprint 2
Prioridad
Tiempo
Urgente
4 Horas
Urgente
8 Horas
47
Comentario
Revisar todos los
scripts que utiliza la
pgina y verificar
algunos errores
presentes
Realizar un portal
provisional de
Inscripciones en
lnea para los
nuevos estudiantes
Implementar un
sistema de
validaciones
gramaticales
Urgente
8 Horas
Mejorar problemas
presentados al
entrar a los
portales desde
Internet Explorer
Urgente
6 Horas
Implementar un
sistema para evitar
que los usuarios
introduzcan letras,
smbolos o nmeros
cuando no son
permitidos.
(Validacin de todos
los campos)
Garantizar un
funcionamiento
adecuado en
Internet Explorer de
todos las
aplicaciones y
servicios que se
estn desarrollando
48
Sub-Actividades
Realizar
Diagrama de
Actividades
Realizar UI de la
matrcula en lnea
Matrcula en lnea
Prioridad
Tiempo
Media
4 Horas
Comentario
Ninguna
Media
4 Horas
Ninguna
Obtencin de Prematrcula
Urgente
3 Horas
Agregar Auditoria
Medio
3 Horas
Calcular la pre-matrcula
del estudiante de
acuerdo al semestre, las
materias que ha perdido
y al reglamente
Ninguna
49
Agregar y validar
Cursos
Urgente
8 Horas
Ninguna
Revisar
Seguridad
Urgente
8 horas
Ninguna
Obtener Cursos
Habilitados
Urgente
6 Horas
Ninguna
Guardar Matricula
Urgente
7 Horas
Ninguna
Sub-Actividades
Obtener
Calendario de los
cortes (API)
Funcionalidad del
Mdulo
Portal Docentes
Prioridad
Tiempo
Urgente
3 Horas
Comentario
Ninguna
Urgente
4 Horas
Ninguna
Mis Cursos
Medio
3 Horas
Crear UI
Urgente
4 Horas
Visualizar
estudiantes y sus
respectivos
correos
electrnicos por
curso.
Ninguna
Horario
Bajo
3 Horas
Ninguna
Realizar
Actualizacin de
Datos
Medio
4 Horas
Es Similar a la de
estudiantes y
egresados, pero
con datos nicos
para los docentes
Sub-Actividades
Estandarizacin
de los widgets
Refactor
Prioridad
Tiempo
Medio
5 Horas
Realizar cambios
necesarios para
la
interoperabilidad
entre los
navegadores web
Urgente
10 Horas
Reestructurar
Tamao de los
campos de texto
Redisear las
pestaas
Bajo
3 Horas
Bajo
3 Horas
Editar formulario
de envi de
correo
Medio
5 Horas
Comentario
Pestaas,
botones, campos
de texto, entre
otros.
Debe funcionar en
Internet Explorer
(7 - ms reciente),
Firefox (3 ms
reciente) y Google
Chrome. Revisar
CSS, JS y
atributos
especiales.
Implementar
varios tamaos y
estandarizarlos.
Ninguna
Agregar la
posibilidad de
agregar ms o
eliminar usuarios
mientras se
construye el
correo.
Generador de
PDF con la cita
de la entrevista
Generador de
PDF con la cita
para la prueba
Psicotcnica
Agregar
Funcionalidad al
Mdulo
Medio
3 Horas
Ninguna
Medio
3 Horas
Medio
5 Horas
Realizar
validaciones
adicionales
Medio
3 Horas
Posibilidad
de completar
parcialmente
el proceso de
inscripcin.
6
Envo de
Correo
electrnico al
terminar la
inscripcin.
Para garantizar
an ms la
funcionalidad en
los distintos
navegadores.
Sub-Actividades
Comentario
Modificaciones
en la
actualizacin de
egresados
Medio
3 Horas
Surgieron unos
inconvenientes a la
hora de guardar los
hijos de los
egresados
55
56
58
59
60
62
63
64
65
66
67
69
70
71
72
73
74
Las interfaces del portal de inscripciones en linea las cuales son utilizadas en la
actualidad para efectuar el proceso de insripcion de los estudiantes que van a
ingresar a la universidad, en este portal se pueden observar las siguiente
vistas:
Formulario de inscripcin. (Ver la siguiente Figura)
76
probaba a detalle todos los aspectos que correspondan al diseo que se deba
implementar, as como los patrones y recursos que deben seguirse para el
desarrollo de las mismas, cabe aclarar que todos estos aspectos y detalles
eran discutidos en la reunin del sprint. Una vez terminada la prueba que se
efectuaba, el Scrum Master determinaba si la actividad estaba cien por ciento
terminada y se poda proseguir a colocar la actividad como finalizada.
Es relevante mencionar alguna de las pruebas que tuvieron complicaciones o
fueron destacadas durante el desarrollo de la implementacin de la
metodologa Scrum, entre las actividades que ms se destacan se encuentran
las siguientes:
Crear Mdulo de Gestin de empresas, esta actividad fue particular
debido a que la prueba fue planeada para ser realizada en el Sprint 2
pero por razones ya explicadas no se pudo realizar. La prueba que se
realiz consisti en verificar si efectivamente se cre el mdulo que
gestionara las empresas; el mdulo comprenda las acciones CRUD
(Create, Read, Update, Delete por sus siglas en ingls) bsicas que
deban ser usados al momento de gestionar las empresas, se realiz
una prueba para verificar si efectivamente se realizaban las acciones
que deba.
Crear Mdulo de Finalizacin de prcticas, igual que la anterior, esta
actividad se destaca debido a que se contempl la prueba al finalizar el
Sprint 2 y no se llev acabo. La prueba en esta actividad consista en
que efectivamente el mdulo se creara segn lo planeado, pero adems,
que segn los parmetros que exige la universidad, esta deba cumplir
con unas exigencias especficas, relacionadas con la fecha en la que se
poda efectuar la finalizacin de las prcticas y que usuario poda
realizar la finalizacin.
Crear Mdulo de Valoracin de Practicante, esta actividad consisti
en examen que debe diligenciar cada practicante al inicio de las
prcticas y al finalizar las mismas. Se verific que el mdulo cumpliera
con las exigencias que se tenan planteadas respecto a las fechas en las
cuales se deban realizar estas valoraciones.
Otra actividad que vale la pena mencionar en esta seccin es, Realizar
cambios necesarios para la interoperabilidad entre los navegadores
web, que consisti en garantizar que en todos los navegadores web se
vieran las interfaces de usuario de la misma manera. Lgicamente, la
prueba consisti en revisar interfaz por interfaz en cada uno de los
navegadores web, cabe mencionar que esta prueba tard algo de
tiempo adicional, porque se tenan que verificar todas las interfaces en
los 4 navegadores ms usados por los usuarios de internet, los cuales
son (Safari, Internet Explorer, Mozilla Firefox y Google Chrome).
Una de las pruebas ms importantes que realizaron fue la de las
actividades que contemplan las Elecciones Estudiantiles, puesto que de
esas interfaces dependa el hecho de que no hubieran fraudes en las
78
79
CONCLUSIONES
80
REFERENCIAS
Humans And
81
82
1 2 3 4
1 2 3 4
83
2012
MARZO
ABRIL
MAYO
1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
Anexo B. Presupuesto
RUBROS
Gastos de
personal
Equipos y
software
Materiales y
suministros
Servicios
tcnicos
Otros gastos
TOTALES
CEV
DESCRIPCIN
4 Tutores
3 Estudiantes
iMac 21
Mac Pro con Cinema
Display
Computador HP Quad Core
Papelera
Tner de impresora
Servicio de Computo 600h
5000h
Imprevistos
Especie
Efectivo
$ 2450.000.oo
$ 6335.500.oo
-
$ 7132.000.oo
$ 1835.000.oo
-
$ 200.000.oo
$ 100.000.oo
$ 8000.000.oo
$ 19417.000.oo
$ 1000.000.oo
$ 7635.500.oo
84
FUENTE
Estudiantes
$ 27052.500.oo