SPMP - pegasus.javeriana.edu.copegasus.javeriana.edu.co/~CIS1530AP02/.../SPMP.docx · Web...
79
25-11-2015 SPMP Software Project Management Plan LAURA DANIELA CHACÓN HERNÁNDEZ LAURA TATIANA GÓMEZ REINA LAURA VANESSA LÓPEZ CASTRILLÓN
Transcript of SPMP - pegasus.javeriana.edu.copegasus.javeriana.edu.co/~CIS1530AP02/.../SPMP.docx · Web...
25-11-2015SPMP
Software Project Management Plan
LAURA DANIELA CHACÓN HERNÁNDEZLAURA TATIANA GÓMEZ REINALAURA VANESSA LÓPEZ CASTRILLÓN
1
1. Historial de Cambios
Fecha Versión Sección Caracteristicas de Cambio
14 de septiembre 0.1 6
Se realizó el prefacio y se definieron objetivos, propósito, alcance, calendarización, presupuesto y glosario.
21 de septiembre 0.2 8.1 Se realizó el ciclo de vida
22 de septiembre 0.3 8.2 - 8.3 Se realizó la investigación de los lenguajes y herramientas y el plan de aceptación del software
23 de septiembre 0.4 8.4Se realizó la sección acerca de interfaces internas y externas y roles
23 de septiembre 0.5 9.1 Se realizó la sección acerca de Métodos y herramientas de estimación
25 de septiembre 0.6 9.2 - 9.3
Se especificó acerca del Inicio del Proyecto y planes de trabajo del proyecto, Corrección Calendarización y presupuesto sección 6
26 de septiembre 0.7 10.1 -10.2
Se elaboró la sección donde se habla de del monitoreo y control del progreso y el cierre del proyecto
27 de septiembre 0.8 11 - 12.1Se explicó el Ambiente de trabajo y los requisitos primordiales para la entrega del producto
28 de septiembre 0.9 12.2
Se especificó el Análisis y administración de riesgos Corrección sección 8.2, Bibliografía, además se ordenó el trabajo
29 de septiembre 1 12.3 - 12.4 - 12.5Se añadieron las secciones descritas y se ajustaron detalles
Tabla 1.1.1 Historial de Cambios
2
2. Prefacio
La Pontificia Universidad Javeriana cuenta con veintisiete puntos de alimentación distribuidos
en el campus universitario, destinados a proveer servicios que satisfagan las necesidades de
los estudiantes y administrativos. Sin embargo, la falta de conocimiento de los servicios y
productos ofrecidos trae como consecuencia una menor demanda de lo esperado, debido a
que la comunidad universitaria prefiere el uso de servicios externos.
Por lo anterior, en este proyecto se tiene como objetivo realizar un sistema de recomendación,
en el cual se informará a la comunidad universitaria acerca de los servicios de alimentación que
ofrece la Universidad, con esto se piensa mejorar la interacción de los usuarios con estos.
Este documento presenta el desarrollo del Software Project Management que aborda la vista
general del proyecto en donde se definirán los objetivos y el alcance de este. Posteriormente se
analiza el contexto del proyecto, en el que se exponen los lenguajes, herramientas y el modelo
del ciclo de vida a seguir. Más adelante se muestran los planes para la administración del
proyecto en donde se encontrará descomposición del mismo en actividades. Para finalizar, se
expone el tema de monitoreo, control del proyecto en el cual se detallan las métricas, el control
de riesgo y calidad el proyecto a realizar.
3
3. Tabla de Contenidos
1. Historial de Cambios...............................................................................................2
2. Prefacio....................................................................................................................3
3. Tabla de Contenidos...............................................................................................4
4. Lista de Figuras.......................................................................................................7
5. Lista de Tablas.........................................................................................................8
6. Vista general del proyecto......................................................................................9
6.1 Visión del producto.......................................................................................................9
6.2 Propósito, alcance y objetivos....................................................................................9
6.2.1 Propósito.............................................................................................................................. 9
6.2.2 Alcance................................................................................................................................ 9
6.2.3 Objetivos............................................................................................................................ 10
6.3 Supuestos y restricciones.........................................................................................11
6.4 Entregables..................................................................................................................11
6.5 Resumen de calendarización y supuestos...............................................................12
6.5.1 Calendarización y presupuesto..........................................................................................12
7. Glosario..................................................................................................................14
8. Contexto del proyecto...........................................................................................15
8.1 Modelo de ciclo de vida..............................................................................................15
8.1.1 Análisis alternativas y justificación.....................................................................................18
8.2 Lenguajes y herramientas..........................................................................................18
8.2.1 Análisis de alternativas y justificación................................................................................22
8.3 Plan de aceptación del producto...............................................................................25
4
8.3.1 Objetivos............................................................................................................................ 25
8.3.2 Responsables....................................................................................................................25
8.3.3 Recursos Requeridos.........................................................................................................25
8.3.4 Puesta en marcha..............................................................................................................25
8.4 Organización del proyecto y comunicación.............................................................26
8.4.1 Interfaces externas.............................................................................................................26
8.4.2 Organigrama y descripción de roles...................................................................................27
9. Administración del proyecto................................................................................30
9.1 Métodos y herramientas de estimación....................................................................30
9.1.1 Estimación Horas personal................................................................................................31
9.1.2 Estimación Recursos.........................................................................................................33
9.2 Inicio del proyecto......................................................................................................33
9.2.1 Entrenamiento del personal...............................................................................................33
9.2.2 Infraestructura....................................................................................................................34
9.3 Planes de trabajo del proyecto..................................................................................35
9.3.1 Descomposición de actividades.........................................................................................35
9.3.2 Calendarización................................................................................................................. 38
9.3.3 Asignación de recursos......................................................................................................39
9.3.4 Asignación de presupuesto y justificación..........................................................................41
10. Monitoreo y Control del Proyecto........................................................................43
10.1 Monitoreo y Control del Progreso.............................................................................43
10.2 Cierre del proyecto.....................................................................................................44
11. Entrega del producto............................................................................................45
12. Procesos de soporte.............................................................................................46
5
12.1 Ambiente de trabajo....................................................................................................46
12.1.1 Reglas de conductas..........................................................................................................47
12.2 Análisis y administración de riesgos........................................................................47
12.3 Administración de configuración y documentación...............................................49
12.4 Métricas y proceso de medición................................................................................50
12.4.1 Documentos.......................................................................................................................50
12.4.2 Código fuente.....................................................................................................................51
12.5 Control de calidad.......................................................................................................51
12.5.1 Documentos.......................................................................................................................52
12.5.2 Código fuente.....................................................................................................................52
13. Anexos....................................................................................................................53
14. Bibliografía.............................................................................................................54
6
4. Lista de Figuras
Figura 6.2.3.1 Entregables........................................................................................................................ 13
Figura 6.5.1.1 Ciclo de vida ASD [10]........................................................................................................16
Figura 6.5.1.2 Descripción BPMN de alto nivel actividades por iteración..................................................18
Figura 8.4.1.1. Interfaces externas: personas...........................................................................................28
Figura 8.4.1.2. Interfaces externas: entidades...........................................................................................28
Figura 8.4.2.1. Roles de L3....................................................................................................................... 29
Figura 8.4.2.2. Organigrama de L3............................................................................................................30
Figura 9.3.2.1Fase Análisis de Entorno.....................................................................................................39
Figura 9.3.2.2 Fase Desarrollo del Modelo Adaptativo..............................................................................40
Figura 9.3.2.3 Fase Diseño de Algoritmos.................................................................................................40
Figura 9.3.2.4 Fase Desarrollo del aplicativo.............................................................................................40
Figura 9.3.2.5 Fase Aplicabilidad...............................................................................................................40
Figura 12.1.1.1 Proceso de gestión de riesgos.........................................................................................50
7
5. Lista de Tablas
Tabla 1.1.1 Historial de Cambios................................................................................................................. 2
Tabla 6.5.1 Calendario.............................................................................................................................. 13
Tabla 8.2.1 Herramientas y Lenguajes......................................................................................................22
Tabla 9.1.1Presupuesto estimación horas trabajadores............................................................................32
Tabla 9.1.2 Presupuesto estimación hardware..........................................................................................33
Tabla 9.1.3 Presupuesto estimación servicios...........................................................................................33
Tabla 9.3.1 Descomposición de Actividades L3........................................................................................38
Tabla 9.3.2 Asignación de Recursos.........................................................................................................41
Tabla 12.2.1 Matriz de Tolerancia de Riesgos [46]....................................................................................48
8
6. Vista general del proyecto
Esta sección provee una perspectiva de la visión, alcance y objetivos del proyecto. Además, se
enumeran los supuestos y restricciones que se tienen en cuenta, junto con los entregables
necesarios para el desarrollo del sistema, las fechas estipuladas para la entrega de estos y la
metodología utilizada para la actualización del presente documento.
6.1 Visión del producto.
El sistema L3, proveerá un sistema de recomendación a los estudiantes de la Pontificia
Universidad Javeriana que se encuentran interesados en hacer uso de los servicios de
alimentación proveídos por la Universidad.
Este producto apoyará a los estudiantes en la toma de decisiones acerca de su alimentación
dentro del campus, puesto que el sistema realizará una distribución eficiente del presupuesto
de éstos en un periodo de tiempo determinado, recomendando productos, promociones y
cafeterías de manera personalizada.
6.2 Propósito, alcance y objetivos
Este apartado presenta la finalidad y límites presentes tanto en el proyecto como en el sistema
a desarrollar.
6.2.1 Propósito
El propósito del proyecto es realizar un sistema personalizado de servicios alimentarios en un
campus universitario, aplicado a la Pontificia Universidad Javeriana.
El sistema que será entregado realizará recomendaciones que se adaptarán a los gustos y
necesidades de los estudiantes de la Universidad, de manera que se tenga un mayor
conocimiento de los productos y servicios que se proveen, haciendo un uso eficiente del
presupuesto con el que se cuenta.
6.2.2 Alcance
El sistema a desarrollar, denominado L3, contará con los siguientes servicios:
9
Administración de presupuesto: el sistema L3 proveerá el servicio para administrar el
presupuesto de un estudiante. El servicio operará a partir de la periodicidad con que el
usuario registre su presupuesto para alimentación. El sistema recomendará productos
según las características del usuario.
Adicionalmente, el sistema notificará promociones vigentes de las cafeterías y
restaurantes afines al perfil del usuario. Vale la pena notar que también se usará
información contextual (localización, horario y otras según la disponibilidad de la misma)
con el fin de enriquecer el servicio.
Informar cafeterías: el sistema L3 proveerá el servicio para informar la cafetería más
cercana al usuario, donde cercana se define como:
o Distancia
Medida de longitud
Medida de tiempo
Medida de esfuerzo
o Afinidad
Productos ofrecidos
Ocupación
Espacio
o Tiempo
Atención/Servicio
6.2.3 Objetivos
6.2.3.1 Objetivo general
Desarrollar un sistema de recomendación de servicios alimentarios en un entorno universitario.
6.2.3.2 Objetivos Específicos
Caracterizar las necesidades del usuario final en cuanto a los servicios alimentarios de
la universidad.
Crear el modelo de adaptación para el usuario final teniendo en cuenta los servicios ali-
mentarios.
10
Diseñar los algoritmos de los servicios alimentarios considerando aspectos de persona-
lización, movilidad y optimización de recursos.
Desarrollar el sistema de recomendación de servicios alimentarios, basado en los algo-
ritmos diseñados.
Validar el sistema de recomendación a través de un prototipo funcional.
6.3 Supuestos y restricciones
El proyecto debe ser realizado en 16 semanas.
El producto debe ser entregado el día 25 de noviembre del año 2015.
Los usuarios de la aplicación a desarrollar deben tener el correo institucional de la
Pontificia Universidad Javeriana activo.
La aplicación será construida para dispositivos móviles Android con versión mínima de
4.0.
Los servicios presentados a Servicios de Alimentación inicialmente no serán
modificados a lo largo del desarrollo del proyecto.
No se cuenta con inversión de capital para el desarrollo del proyecto, debido a esto, las
herramientas para la implementación del mismo serán de software libre.
La información usada será proveída por Servicios de Alimentación.
6.4 Entregables
Los documentos que se entregarán durante el desarrollo del proyecto son los siguientes:
11
Figura 6.2.3.1 Entregables
6.5 Resumen de calendarización y supuestos
En esta sección se describirán las actividades y se especificara la fecha de cada una de las
entregas, además se proyectara el estimado del costo del proyecto.
6.5.1 Calendarización y presupuesto
En este proyecto, L3 tiene 5 fases principales en las cuales se debe hacer una entrega formal,
dichas fases son descritas en la tabla 6.5.1.1:
Análisis de la problemática actual
Fase 1. Análisis de entorno
Modelo adaptativo del sistemaListado de servicios a implementarEnriquecimiento de servicios
Fase 2. Desarrollo del modelo de adaptación y servicios
Algoritmo de ruta óptimaAlgoritmo de optimización de recursosAlgoritmo de georeferenciaciónAlgoritmo de tiempos
Fase 3. Diseño de algoritmos
SPMPSRSSADReporte de pruebas
Fase 4. Desarrollo del aplicativo
Informe de la satisfacción de los usuarios finales
Fase 5. Aplicabilidad
12
ACTIVIDAD COMIENZO FIN COSTO$2.588.670
Observación de cafeterías enhorarios de gran afluencia de
Viernes 27/02/2015 Viernes 13/03/2015
Observación de restaurantesen horarios de gran afluencia
Viernes 20/03/2015 Viernes 03/04/2015
Realización de encuestaspara conocer el perfil de
Miercoles 08/04/2015 Miercoles 22/04/2015
Realización de entrevistaspara conocer el perfil de
Jueves 9/04/2015 Lunes 13/04/2015
Identificación de trabajosrelacionados
Jueves 16/02/2015 Jueves 23/02/2015
$2.478.514Identificación de los serviciosque serán ofrecidos por el
Lunes 27/07/2015 Viernes 31/08/2015
Identificación de los algoritmosque ayudarán a implementar
Lunes 3/08/2015 Viernes 7/08/2015
Planteamiento el perfil deusuario
Lunes 10/08/2015 Martes 18/08/2015
Planteamiento el perfil decontexto
Miercoles 19/08/2015 Miercoles 26/08/2015
Generación el modelo deadaptación de acuerdo a los
Viernes 28/08/2015 Miercoles 04/09/2015
$1.900.194Búsqueda de algoritmos queresuelvan problemas similares
Lunes 7/09/2015 Sabado 12/09/2015
Adaptación de algoritmos alproblema propuema propuesto
Lunes 14/09/2015 Miercoles 20/09/2015
Descripción de las reglas autilizar en el enriquecimiento
Lunes 21/09/2015 Miercoles 22/09/2015
Realización del pseudocódigode los algoritmos a
Jueves 24/09/2015 Viernes 16/10/2015
$14.113.758Levantamiento derequerimientos
Lunes 7/09/2015 Sabado 12/09/2015
Diseño de la arquitectura Lunes 14/09/2015 Miercoles 23/09/2015
Implementación del prototipo Jueves 24/09/2015 Viernes 16/10/2015
Verificación del prototipo porpruebas unitarias
Lunes 19/10/2015 Viernes 23/10/2015
$7.008.685,68Entrega del prototipo ausuarios finales
Lunes 26/10/2015 Lunes 26/10/2015
Revisión de la acogida de laaplicación
Martes 27/10/2015 Jueves 26/11/2015
Revisión de la frecuencia deuso de la aplicación
Martes 27/10/2015 Jueves 26/11/2015
Revisión reporte de errores delos usuarios
Martes 27/10/2015 Jueves 26/11/2015
Validación del sistema pormedio de las anteriores
Martes 27/10/2015 Jueves 26/11/2015
Determinar el grado de satisfacción Viernes 27/11/2015 Viernes 27/11/2015
Transportes Estudiantes $918.000TOTAL $29.007.821
FASE ANALISIS DE ENTORNO
DESARROLLO DEL MODELO DE ADAPTACIÓN Y SERVICIOS
DISEÑO DE ALGORITMOS
DESARROLLO DEL APLICATIVO
APLICABILIDAD
Tabla 6.5.2 Calendario
Se estimó un costo del proyecto tomando en cuenta las cinco fases del cronograma, los
recursos a utilizar, las horas por persona, y el tiempo que se va a emplear en este,
teniendo un costo total de: $ 29.007.821. Para ver una descripción detallada de costos por
actividad (Véase 9.1 Métodos y Herramientas de Estimación).
13
7. Glosario
Aplicación Móvil: Es un software descargable adaptado para uso exclusivo de un dispositivo
móvil [1].
Android: Es un sistema operativo para Smartphones y tabletas [2].
SAD: Software Architecture Document. Es un documento que proporciona una descripción
arquitectónica del sistema, usando vistas diferentes para representar distintos aspectos que se
requieren para capturar y transportar las decisiones significativas que han sido hechas sobre el
sistema [3].
SPMP: Software Project Management Plan. Es el documento de control para la gestión de un
proyecto de software, define los procesos técnicos y administrativos necesarios para desarrollar
satisfactoriamente un producto de software [4].
SRS: Specification Software Requirements. Son especificaciones para un producto del software
en particular. Son definidas la funcionalidad, las interfaces externas, desempeño, atributos y
restricciones de diseño del producto [5].
BPMN: Bussiness Process Modeling Notation. Es una notación gráfica que describe la lógica
de los paso de un proceso de negocio. Esta notación ha sido especialmente diseñada para
coordinar la secuencia de los procesos y los mensajes que fluyen. [6]
Diagrama de Gantt: Es una herramienta que le permite al usuario modelar la planificación de
las tareas necesarias para la realización de un proyecto. [7]
Prototipo: Un prototipo es un modelo (representación, demostración o simulación) fácilmente
ampliable y modificable de un sistema planificado, probablemente incluyendo su interfaz y su
funcionalidad de entradas y salidas. [8]
UML: Es un lenguaje que le ayuda a especificar, visualizar y documentar esquemas de
sistemas de software, incluyendo su estructura y diseño de manera que cumplan con todos sus
requisitos. [9]
14
8. Contexto del proyecto
8.1 Modelo de ciclo de vida
En este proyecto se aplicará la metodología ágil ASD (Adaptive Software Development), la cual
incorpora el principio de la adaptación continua, es decir tiene como finalidad adaptarse al
cambio y no luchar contra él. J. Highsmith propone tres fases, que hacen del ciclo de vida un
ciclo dinámico, las cuales son especulación, colaboración y aprendizaje.
Figura 6.5.1.2 Ciclo de vida ASD [10]
Especulación: en esta primera fase se establecen los principales objetivos y metas del
proyecto, además de comprender las limitaciones con las que este operará, sin embargo, lo
establecido podrá cambiar a lo largo de las diferentes iteraciones, ya que la planeación que se
realiza es temporal, es decir da espacio a la exploración, puesto que como menciona el autor
“un equipo que especula no abandona la planificación, sino reconoce la realidad de la
incertidumbre”. Según lo anterior en esta fase no solo se plantean la misión y objetivos, sino
también se es consciente de los problemas que puedan ocurrir a lo largo del desarrollo de éste.
Adicionalmente, se definen el número de iteraciones que tendrá el proyecto, el tema a tratar y
el conjunto de características demostrables que se entregarán a los clientes [11].
Colaboración: en la fase de colaboración se tiene claridad de que las aplicaciones complejas
no se construyen sino evolucionan, además estas manejan un gran volumen de información,
por esta razón, se requiere un grupo que tenga la capacidad de trabajar de forma conjunta para
producir resultados, compartir conocimientos, o tomar decisiones. Para que de esta manera se
logre liberar la funcionalidad planificada en la etapa de especulación. [10]
15
La importancia de esta etapa se debe establece en la relación entre las personas del grupo, las
cuales deben estar suficientemente fuertes y claras para que se pueda arreglar cualquier
circunstancia compleja que se presente: emergencias. [12]
Aprendizaje: la última etapa del ciclo de vida de ASD, hace hincapié en la necesidad de
reconocer los errores, mediante las revisiones de calidad que se hacen al software que se está
desarrollando desde perspectivas del cliente y perspectivas de los expertos. Estas revisiones
son la base de los nuevos ciclos, que se centran en demostrar la funcionalidad del software
desarrollado durante el ciclo. Adicionalmente, las revisiones se deben hacer después de cada
iteración en vez de esperar hasta el final del proyecto. [11] [10]
Un ciclo de vida ASD tiene seis características:
Desarrollo iterativa
Basada en la funcionalidad
Desarrollo acotado temporalmente
Enfocada a la misión
Tolerante a cambios
Guiado por los riesgos
El ciclo de vida de ASD se centra en los resultados, no en las tareas, y los resultados se
identifican como funciones de la aplicación. Las características son las funcionalidades que el
cliente proporciona para planificar lo que se va a desarrollar durante una iteración. [10]
Por otro lado, ASD plantea los siguientes roles y responsabilidades, un “patrocinador ejecutivo”,
el cual es nombrado como la persona con la responsabilidad general del software que se está
desarrollando y los participantes de la sesión de desarrollo de la aplicación conjunta. Pero los
roles en si están basados en la cultura del trabajo en equipo y la importancia de la colaboración
entre cada uno. [11]
Para el caso en particular del proyecto, se manejarán las tres etapas del ciclo de vida de ASD
planteadas por J. Highsmith, explicadas anteriormente. Estas etapas se pueden llevar a cabo
en una o más iteraciones. Cada iteración es un ciclo completo de desarrollo que resulta en la
terminación de un prototipo del sistema de recomendación final. Adicionalmente, cada fase
tiene un proceso de retroalimentación en su cierre. Las fases con su conjunto de tareas
traducidas al proyecto a realizar son:
Fase de especulación
16
o Servicios del sistema de recomendación
o Calendario
o Cantidad de iteraciones
Fase de colaboración
o SRS
Entendimiento de los requerimientos.
Prototipo de Arquitectura.
o Inicio del Desarrollo, prototipo Inicial
o SAD
o Memoria Trabajo de grado
Fase de Aprendizaje
o Revisiones de calidad
Las actividades que se realizarán en cada iteración, según las fases anteriormente
mencionadas se pueden observar en la Figura 8.1.2, del mismo modo los diferentes
documentos que se realizarán con respecto a cada actividad para poder asegurar las buenas
prácticas para el proyecto y tener un soporte físico del trabajo que se está realizando.
17
Figura 6.5.1.3 Descripción BPMN de alto nivel actividades por iteración
8.1.1 Análisis alternativas y justificación
El anterior modelo fue elegido por L3 debido a un estudio y una investigación con respecto a
otros ciclos de vida, dentro de los cuales está el modelo en espiral, el cual tiene un enfoque
importante en el análisis de riesgos y es similar al iterativo incremental, pero se decidió escoger
el iterativo incremental ya que en este lo importante es la parte de priorización de
requerimientos y siempre, después de cada incremento se valida y actualiza la lista de
requerimientos del proyecto.
Por otra parte, los modelos de ciclo de vida secuencial como Cascada, Diente de Sierra y
Diente de Tiburón [13] también se descartaron ya que estos modelos de ciclo de vida no tienen
una retroalimentación continua y no se puede pasar a fases futuras sin haber terminado las
fases previas.
Adicionalmente, el modelo en v resuelve algunos de los problemas que tiene el modelo en
cascada ya que se reconoce la relación entre cada una de las actividades de desarrollo y la
verificación [7]. Sin embargo, el problema con este modelo es que se debe esperar hasta el
final de una fase para que esta pueda ser validada [14]. Por con siguiente, si existiría una
retroalimentación o un cambio en los requerimientos por parte de los clientes, se necesitaría
mucho esfuerzo y recursos para implantar las modificaciones.
18
Con lo anterior, L3 decidió implementar un ciclo de vida iterativo incremental, y una
metodología ágil, ya que el desarrollo del sistema de recomendación se realizará con un grupo
pequeño integrado por tres estudiantes, con un plazo reducido y requisitos basados en nuevas
tecnologías, que son características de las metodologías agiles. Además como se quiere
desarrollar un sistema adaptado a las necesidades del cliente, se necesita una constante
retroalimentación de su perspectiva en relación con el desarrollo que se está implementando.
8.2 Lenguajes y herramientas.
En la tabla 8.2.1 se presentan los distintos lenguajes y herramientas que L3 utilizará en el
transcurso del proyecto:
I
D
Herramient
a/LenguajeVersión Clasificación
Tipo de
licenciaDescripción Referencia
1 Github 3.0.4.0
Almacenami
ento de
archivos
Gratuit
a
Es una plataforma de
desarrollo colaborativo de
software para alojar proyectos
usando el sistema de control
de versiones Git. El código se
almacena de forma pública, no
sólo ofrece alojamiento del
código si no muchas más
posibilidades asociadas a los
repos como son, forks, issues,
pull requests, diffs, etc.
[15]
2 Whatsapp2.12.25
0
Comunicació
n
Gratuit
a
Es una aplicación de
mensajería multiplataforma que
te permite enviar y recibir
mensajes sin pagar por SMS.
[16]
3 Microsoft
Office
15.0.45
69.150
6
Desarrollo Paga Es una suite de oficina que
abarca e interrelaciona
aplicaciones de
escritorio, servidores y servicio
[17]
19
s para los sistemas
operativos Microsoft Windows y
Mac OS X.
4Enterprise
Architect
12.0.12
15.11Diseño Paga
Es una herramientas
comprensible de diseño y
análisis UML, cubriendo el
desarrollo de software desde el
paso de los requerimientos a
través de las etapas del
análisis, modelos de diseño,
pruebas y mantenimiento
[18]
5Google
Chrome
45.0.24
54.85Desarrollo
Gratuit
a
Chrome es un navegador web
rápido, seguro y fácil de usar
creado para la Web actual.
[19]
6 Dropbox 3.8.8
Almacenami
ento de
archivos
Gratuit
a
Es un servicio que preserva la
seguridad de los archivos, los
mantiene sincronizados y
permite compartir estos
fácilmente.
[20]
7
Oracle
Data base
11g
11.2.0Base de
datos
Gratuit
a
Es una base de datos diseñada
para Grid Computing, ofrece un
rendimiento y una escalabilidad
excepcionales en servidores
Windows, Linux y UNIX, y
aporta un rápido rendimiento
de la inversión porque permite
pasar de un solo servidor a
Grid Computing sin modificar ni
una sola línea de código.
[21]
8 Eclipse 4.5Programació
n
Gratuit
a
Es una plataforma de
desarrollo de código abierto
basada en Java. Por si misma,
es simplemente un marco de
trabajo y un conjunto de
servicios para la construcción
[22]
20
del entorno de desarrollo de los
componentes de entrada.
Afortunadamente, Eclipse tiene
un conjunto de complementos,
incluidas las Herramientas de
Desarrollo de Java (JDT).
9 PhoneGap 5.1.1Programació
n
Gratuit
a
Es un framework libre y de
código abierto que permite
crear aplicaciones móviles
utilizando APIs web
estandarizados para las
plataformas moviles.
[23]
1
0Ionic 1.1
Programació
n
Gratuit
a
Es un framework gratuito y
open source para el desarrollo
de aplicaciones híbridas
(nativas y móviles) basadas en
HTML5, CSS y JS. Está
construido con Sass y
optimizado con AngularJS.
[24]
1
1Android 4.0
Programació
n
Gratuit
a
Es la plataforma para
smartphones más popular que
se ha posicionado como la
mejor en el mercado móvil
compitiendo con Apple y otros
fabricantes de dispositivos.
Con un diseño delgado,
notificaciones dinámicas,
tareas múltiples y una tienda
de aplicaciones de rápido
crecimiento, Android está
expandiendo la manera en la
que usamos los dispositivos
móviles.
[25] [2]
1
2Java 7.0.790
Programació
n
Gratuit
a Java es una tecnología que se
usa para el desarrollo de
[26]
21
aplicaciones que convierten a
la Web en un elemento más
interesante y útil. Java no es lo
mismo que javascript, que se
trata de una tecnología sencilla
que se usa para crear páginas
web y solamente se ejecuta en
el explorador.
1
3HTML
HTML
5
Programació
n
Gratuit
a
Se trata de una nueva versión
de HTML, con nuevos
elementos, atributos y
comportamientos.
Contiene un conjunto más
amplio de tecnologías que
permite a los sitios Web y a las
aplicaciones ser más diversas
y de gran alcance.
[27]
1
4CSS CSS3
Programació
n
Gratuit
a
Es un lenguaje de hojas de
estilos creado para controlar el
aspecto o presentación de los
documentos electrónicos
definidos con HTML y XHTML.
CSS es la mejor forma de
separar los contenidos y su
presentación y es
imprescindible para crear
páginas web complejas.
[28]
1
5
Java Script 1.8.5 Programació
n
Gratuit
a
Es un lenguaje ligero e
interpretado, orientado a
objetos con funciones de
primera clase, más conocido
como el lenguaje de script para
páginas web. Es un lenguaje
script multi-paradigma, basado
en prototipos, dinámico,
soporta estilos de
[29]
22
programación funcional,
orientada a objetos e
imperativa.Tabla 8.2.3 Herramientas y Lenguajes
8.2.1 Análisis de alternativas y justificación
Herramientas de organización: En primer lugar se pensó utilizar la herramienta de google
drive, ya que allí se puede hacer uso de los documentos de Google los cuales permiten editar
en simultáneo en internet y hacer comentarios. Sin embargo, el equipo de trabajo decidió
utilizar Microsoft Word para la creación y revisión de documentos pues facilita el uso de
hipervínculos entre documentos y el manejo de referencias.
Adicionalmente, las herramientas elegidas para la comunicación entre la organización fueron
Facebook y Whatsapp ya que todas las integrantes del grupo utilizaban estas herramientas con
anterioridad, y dentro de estas dos herramientas se pudo establecer un grupo en donde se
podía facilitar la comunicación.
Diseño: La herramienta utilizada para el diseño será Enterprise Architect ya que es una
herramienta que se maneja en la Pontificia Universidad Javeriana, además es fácil de usar,
entender y manejar frente a otras como JUDE [30] , que es un herramienta personalizable pero
tiene licencia propia , y el grupo de trabajo no pagaría por esta herramienta teniendo a
disposición Enterprise, aunque JUDE cuente con una distribución Freeware, esta es limitada, y
no brinda la funcionalidad que se requiere para el proyecto. Por otro lado esta BOUML [30] que
es una herramienta libre que soporta los principales lenguajes orientados a objetos, pero, poco
intuitiva lo que implica una curva de aprendizaje muy grande.
En conclusión, Enterprise Architect es la herramienta más opcionada, debido a que las
licencias son proporcionadas por la Pontificia Universidad Javeriana, además las integrantes de
L3 llevan varios años trabajando con esta.
Versionamiento: Las herramienta contemplada para manejar el progreso y revisión de código
en el proyecto será Github, debido a que se quiere trabajar con un sistema de versionamiento
distribuido, ya que cada integrante podrá trabajar simultáneamente en el código teniendo el
repositorio local y sin necesidad de tener conexión a internet de forma permanente.
23
Mercurial y Monotone, al igual que git, son sistemas de versionamiento distribuido que tienen
muchas cosas en común y se diferencian por pequeños detalles que muchas veces no son
perceptibles para el usuario. Monotone [31] tiene un diseño orientado a la integridad
comprometiendo desempeño, esto hace que sea lento en muchos casos ya que hace muchas
revisiones para validar la integridad y aunque ya se han hecho algunas optimizaciones para
mejorar esto, sigue siendo más lento a comparación de Git y Mercurial. En cuanto a Mercurial
[32] se encontró que el manejo de branches es más complicado que en Git ya que en Mercurial
una rama (branch) está embebida dentro de un commit mientras que en Git es únicamente un
apuntador al commit lo cual hace más fácil su manejo.
Por último se decidió usar Github por 2 razones principales: primero las tres integrantes del
grupo ya tenían algunos conocimientos previos sobre este sistema y segundo por la facilidad
que provee Github [33], herramienta web que tiene varias características para que el flujo de
trabajo en equipo sea colaborativo y permita revisiones cruzadas como los pull request y la
capacidad de hacer comentarios antes de unir los cambios a la rama principal (master branch).
Servidor y base de Datos: Como servidor del proyecto, L3 creara su propio servidor ya que es
un requisito del trabajo de grado, además se tendrán ventajas en cuanto a limitaciones de
publicaciones de cualquier tipo de contenido, ya que todo se hace forma local, adicionalmente,
no es necesario subir a la web cada vez que se modifica algo. Al igual que en el caso
anterior, al ser propio el servidor web, todo el contenido se guardará de forma local y estará
disponible al momento de ser modificado para todos los usuarios que quieran acceder al
contenido. Este servidor se realizará en eclipse, debido a que es una herramienta con la cual
se tiene experiencia.
En cuanto a la base de datos se utilizará Oracle data base 11g de base de datos objeto-
relacional más usado a nivel mundial, además, puede ejecutarse en todas las plataformas,
desde una Pc hasta un supercomputador, Igualmente, Oracle soporta todas las funciones que
se esperan de un servidor, y una funcionalidad importante es que permite el uso de particiones
para la mejora de la eficiencia, de replicación y la administración de bases de datos
distribuidas. No se eligió Mysql ya que como el desarrollo del trabajo se realizará de forma
grupal se necesita tener información acerca de inserción, actualización o borrado que un
usuario realizó sobre una determinada tabla, y Oracle [34] maneja una tabla histórica con dicha
información, además La base de datos Oracle es una herramienta muy confiable y segura,
tiene opciones de auditoria, backup y aplicaciones para la toma de decisiones que la
diferencian de sus competidores libres y propietarios. En ocasiones es mejor sacrificar los
recursos (memoria, disco) para obtener a cambio integridad en los datos. El problema del open
24
source (Mysql) ha sido siempre la falta de soporte técnico garantizado al cual acudir si los
manuales y ayuda en línea no son suficientes, y tener soporte es de gran importancia para el
desarrollo del software. [34]
Desarrollo: Una de las alternativas para desarrollar la aplicación móvil L3 para Android era
Android Studio, esta es una herramienta diseñada específicamente para el desarrollo móvil en
Android, aunque maneja ventajas debido a su complemento de Junit que posiblemente podría
ayudar en las pruebas unitarias del software; las integrantes prefirieron el IDE Eclipse para
programar con el lenguaje Java, Debido a que la curva de aprendizaje con la primera
herramienta era demasiada costosa en cuento a tiempo.
Por otro lado, existían herramientas como Android NDK, esta se usa para situaciones muy
específicas donde el uso de código nativo como C/C++ es necesario para garantizar un alto
rendimiento cuando el uso de CPU es intenso tales como simulaciones, procesamiento de
señales o motores de juego. [35] [36]
8.3 Plan de aceptación del producto
El plan de aceptación precisa la forma en la cual se va a evaluar el producto, además se
especifican los requisitos que deben cumplirse para la entrega del producto final [37].
8.3.1 Objetivos
Definir los criterios para la aceptación o rechazo de prototipos del producto final.
Definir las técnicas y herramientas utilizadas para la revisión y aceptación del producto.
Definir los ítems de calidad para los documentos que serán entregados.
8.3.2 Responsables
Los responsables de este proceso de calidad serán las tres integrantes del equipo de trabajo.
8.3.3 Recursos Requeridos
Para el correcto desarrollo de este plan se hacen necesarias las herramientas y los lenguajes
planteados en la sección 8.2 Lenguajes y herramientas.
25
8.3.4 Puesta en marcha
El plan de aceptación se compone de dos partes, los criterios de aceptación del software y los
criterios de aceptación de los documentos del producto. Este plan se encuentra relacionado
con las secciones de 12.5 Control de calidad y de 12.4 Métricas y Proceso de medición [38] [39].
Aquí se definieron los ítems generales de calidad del código que L3 manejará para la revisión
del prototipo final, estos son los siguientes:
Desempeño: Hace referencia a la velocidad de respuesta que espera el cliente que
presenten las diferentes funcionalidades de la aplicación.
Mantenibilidad: En este ítem se revisa la relación que tiene el código con el diseño
planteado así como la documentación, organización y las pruebas unitarias realizadas
para los módulos que hacen parte de la aplicación.
Funcionalidad: Este punto está ligado a los requerimientos y casos de uso definidos en
el diseño del problema, así por cada prototipo entregado se debe revisar si cumple con
los requerimientos que se implementarían en la iteración dada.
De la misma manera, para los documentos entregables se seguirá el proceso de métricas para
documentos que se definirá en la sección 12.4 Métricas y Proceso de medición, adicionalmente
se definieron los siguientes criterios para la aceptación de estos, los cuales fueron definidos por
coordinación de trabajo de grado [40]:
Consistencia
Completitud
Suficiencia
Investigación
Argumentación
Referenciación
Calidad de Fuentes
Amplitud
Claridad
Estos criterios serán medidos con una calificación cuantitativa de 0 a 5 donde 5 significa
excelente por parte de la directora y los jurados del trabajo de grado.
26
8.4 Organización del proyecto y comunicación
En la presente sección se detallarán las entidades externas e internas a L3, todas interesadas
en que sea posible culminar el proyecto de manera satisfactoria.
8.4.1 Interfaces externas
A lo largo del desarrollo del proyecto L3 deberá interactuar con diferentes entidades y personas
externas al equipo de trabajo. Las entidades relacionadas se encargan de facilitar servicios y
espacios para la realización del proyecto y por otro las personas están interesadas en el
correcto desarrollo del trabajo de grado. Cada una de las personas y entidades externas se
encuentran relacionadas en la tablas 8.4.1.1 y 8.4.2.2, respectivamente.
27
Nombre Descripción Rol Comunicación Datos
Ángela Carrillo
Profesora titular de la Pontificia Universidad Javeriana. Es la directora del presente trabajo de grado.
Está encaragada de realizar seguimiento, revisiones y correcciones a los diferentes entregables del proyecto y por último evaluar al equipo de trabajo.
Se realizarán reuniones semanales para llevar a cabo el seguimiento correspondiente y se podrá contactar también por correo electrónico.
E- mail: [email protected] Tel: 320 8320 Ext. 5392
Ricardo Rugeles
Ingeniero de proyectos de la dirección de tecnologías de información de la Pontificia Universidad Javeriana.Es asesor del presente trabajo de grado.
Está encargado de realizar seguimiento, revisiones y correcciones a los diferentes entregables del proyecto.
Se realizarán reuniones semanales para llevar a cabo el seguimiento correspondiente y se podrá contactar también por correo electrónico.
E- mail: [email protected] Tel: 320 8320 Ext. 3305
Guillermo Cristancho
Es Analista del Departamento de Ingeniería de Sistemas de la Pontificia Universidad Javeriana
Es quien provee el espacio necesario en algún servidor de la PUJ para que sea posible realizar la página web del proyecto
La comunicación con él es por medio del formulario suministrado por la coordinación de trabajo de grado o por correo
E- mail: [email protected]
Figura 8.4.1.4 Interfaces externas: personas
Nombre Descripción y Relación
Biblioteca Alfonso Borrero Cabal, S.J.
Allí se realizarán las reuniones del equipo de trabajo. Por otro lado, la biblioteca proveerá recursos tanto físicos como digitales para la consulta de referencia.
Figura 8.4.1.2. Interfaces externas: entidades
8.4.2 Organigrama y descripción de roles
L3 está conformado por tres estudiantes de Ingeniería de Sistemas de décimo semestre,
inscritas en la asignatura Trabajo de Grado ISistemas.
De acuerdo al ciclo de vida elegido para el desarrollo de la aplicación L3 (Véase 8.1 Modelo de
Ciclo de Vida), hay un único rol definido, el patrocinador ejecutivo, el cual es nombrado en el
28
equipo de trabajo como la persona con la responsabilidad general del software, es decir es el
responsable ante los demás del funcionamiento del prototipo, adicionalmente es quien debe
liderar y guiar al equipo hacia la misión y visión del proyecto [11]. Este rol le fue asignado a
Laura Vanessa López Castrillón.
A pesar de ese único rol definido, L3 tendrá líderes en cada área para una mayor organización
y control del avance del proyecto. De esta manera, según el interés de cada una le fue
asignada un área, esta asignación se puede visualizar en la figura 8.4.2.1 junto con las tareas
designadas a cada área. Esto no significa que cada estudiante debe realizar sola esas tareas,
puesto que el ciclo de vida seleccionado está basado en la colaboración, lo que quiere decir
que entre las tres estudiantes serán desarrolladas las diferentes actividades de cada área.
Figura 8.4.2.5. Roles de L3
Según lo mencionado anteriormente, el organigrama de L3 se definió en la figura 8.4.2.2,
donde es posible visualizar que el patrocinador ejecutivo será quien deba llevar el mayor y más
general seguimiento del avance del proyecto. Adicionalmente, estarán los líderes, encargados
del seguimiento y avance del área asignada a este, para así guiar al equipo de trabajo al
término satisfactorio de las diferentes tareas.
Líder de arquitectura - Laura Gómez
Las tareas del área de arquitectura se relacionan con el levantamiento de requerimientos y los diferentes diseños necesarios para la elaboración del prototipo, entre los cuales se encuentran el diseño de alto y bajo nivel, diseño de algoritmos, diseño de perfiles de usuario y contexto y por último el diseño del modelo de adaptación.
Líder de programación - Laura Chacón
El área de programación está encaragada de la programación del producto, de la documenación del código y elaboración de manuales.
Líder de pruebas - Laura López
Esta área se encarga de las pruebas del prototipo tanto funcionales como las de aceptación de la comunidad, para así comprobar el correcto funcionamiento de este o descubrir errores que deben ser corregidos.
29
Figura 8.4.2.6. Organigrama de L3
Patrocinador ejecutivo
Laura López
Líder de arquitectura
Laura Gómez
Equipo de trabajo
Laura LópezLaura Chacón
Líder de programaciónLaura Chacón
Equipo de trabajo
Laura LópezLaura Gómez
Líder de pruebas
Laura López
Equipo de trabajo
Laura ChacónLaura Gómez
30
9. Administración del proyecto
9.1 Métodos y herramientas de estimación
El objetivo de este plan es definir los métodos y herramientas que se utilizarán para estimar
tanto el costo como el tiempo que tomará realizar el sistema L3, de tal forma que sea posible
adaptar tales estimaciones a los cambios que se presenten durante el desarrollo del proyecto.
Las tres integrantes de L3 serán las responsables de elaborar el plan de estimación,
igualmente de realizar modificaciones si es el caso, teniendo en cuenta que el proyecto se
encuentra en un entorno cambiante.
Para realizar la estimación del proyecto se hará uso de la herramienta Microsoft Excel para
consignar los datos y unidades estimadas para cada parte específica del proyecto y así hallar
un estimado del costo y el tiempo del sistema L3.
Por otro lado para la correcta estimación, L3 se basó en los métodos de estimación agiles
Wide-Band Delphi y Planning Poker para hacer un proceso intuitivo donde las integrantes del
grupo estimarán las partes del proyecto que van a realizar dependiendo de sus roles y
realizando una retroalimentación para buscar corregir errores de estimación [41].
Wide-Band Delphi [42] el cual se deriva del método Delphi y ha sido usado en diferentes tipos
de industrias. Este proceso ha sido exitoso pues se escogen algunas personas del equipo los
cuales representan ramas importantes del proyecto y se reúnen para hacer correcciones entre
los integrantes y así se tiene retroalimentación temprana que permite identificar errores.
Este método es útil para este proyecto pues es un grupo pequeño de tres personas las cuales
tienen asignadas roles que representan las partes importantes del proyecto (ver sección 8.4.2
Organigrama y Descripción de Roles), así en este caso todos los integrantes del grupo aportan
para crear la estimación del proyecto. Luego de discutir los estimativos de cada experto se
integran y se hace retro alimentación para mejorar puntos específicos y corregir errores. Este
método se divide en los siguientes pasos:
Elección de equipo
Reunión inicial
Preparación individual
Reunión de estimación
31
Reunir Tareas
Revisar Resultados
Planning Poker [43] es un método de estimación donde se utilizan unas cartas que se les dan a
cada persona con una secuencia determinada que representa una unidad con la que el equipo
va a realizar la estimación. Se discuten las características del proyecto con el dueño del
producto y cada persona elige una carta para indicar la estimación que cree que se le debe
asignar a dicha característica. Si todos eligen el mismo valor este es el que se le asigna, si esto
no ocurre las personas discuten este problema y se vuelven a seleccionar las cartas.
Teniendo en cuenta estas dos metodologías para la estimación en proyectos agiles, el grupo
decidió tomar algunos conceptos que son útiles para este caso en específico.
En la estimación del proyecto todos los integrantes del grupo intervendrán para dar sus
opiniones sobre unas tareas que se definirán como principales en la realización del producto y
su documentación, así mismo darán retroalimentación a este estimativo para que se acerque
todo lo posible a la realidad.
9.1.1 Estimación Horas personal
Para tomar la decisión de esta estimación de horas por tarea se tendrá en cuenta la
complejidad de dicha tarea así como el tamaño que se espera.
El estimativo de cada tarea será consignado en unidades de horas de trabajo por integrante
que representan el tiempo necesario para cumplir esta tarea de forma exitosa y se asignara un
valor por hora de trabajo. El presupuesto de cada actividad se mide tomando en cuenta el
promedio salarial de un estudiante de Ingeniería de Sistemas que está cursando los últimos
semestres, esto debido a que ningún integrante posee aún el título que los define como
profesionales. Este proceso fue acordado por todos los integrantes del grupo para calcular los
valores asociados al presupuesto y la contabilidad.
Para poder calcular la referencia, se justifica sectorialmente el promedio salarial a la capital
colombiana. Se encontraron los siguientes valores [44] que poseen la siguiente estructura
“Rango = Promedio”:
$1.000.000 a $1.500.000 = $ 1.250.000 COP
$1.250.000 a $1.500.000 = $ 1.375.000 COP
$ 1.650.000 a $ 2.000.000 = $ 1.825.000 COP
$1.500.000 a $2.000.000 = $ 1.750.000 COP
32
$1.200.000 a $1.500.000 = $ 1.350.000 COP
Tomando en cuenta todos estos valores, que se basan en un salario de tiempo completo
(asumido en treinta horas en promedio aunque la ley no lo defina y depende de cada
empleador [45] [40] ), se tiene que el promedio de horas para cualquier contrato es un valor
cercano a las treinta y dos horas semanales, por lo tanto el salario mensual promedio de cada
uno de los integrantes equivaldrá a ciento veintiocho horas laborales.
32*4 = 128 horas mensuales.
Promedio salarial = $ 1.610.000 COP
Por lo tanto el promedio por hora será:
$ 1.610.000 COP / 128 horas mensuales = 12.578,125 COP por hora aprox.
$ 13.000COP.
En el Excel estimación costo proyecto se detallan las horas que se invierten en las tareas de
cada actividad, así como la cantidad de personas involucradas en estas, reflejando un
promedio por costo. La fórmula del costo consiste en usar el precio por hora determinado,
multiplicado por horas de desarrollo y este valor a su vez multiplicado por el número de
integrantes involucrados.
Adicionalmente, en la estimación de horas del personal se debe tener en cuenta el costo del
transporte teniendo en cuenta que cada de las tres integrantes debe utilizar el sistema masivo
de transporte dos veces al día durante el semestre.
Cantidad Costo TotalTransporte 510 $ 1.800 $ 918.000
Horas Estudiantes 2040 $ 13.640 $ 27.825.000
Capital de Trabajadores
Tabla 9.1.4Presupuesto estimación horas trabajadores
33
9.1.2 Estimación Recursos
En este apartado se detallan los recursos que son necesarios para el desarrollo del aplicativo,
los cuales se describen a continuación.
Cantidad Costo Costo/ Hora Horas de uso TotalComputador 3 1.249.000$ 29$ 2040 $ 58.173
Servidor 1 102.456$ 12$ 3600 $ 42.105Dispositivo Móvil
Samsung Galaxy S41 1.359.900$ 31$ 3600 $ 111.773
Hardware
Tabla 9.1.5 Presupuesto estimación hardware
Aunque los computadores son proveídos por la Pontificia Universidad Javeriana, el costo total
de estos se cuantifica en términos de su depreciación por horas de uso. De la misma manera,
el servidor donde se tendrá la aplicación será proveído por la universidad y también fue
estimado de acuerdo a la depreciación. Finalmente, para probar el funcionamiento de la
aplicación será necesario el uso de un dispositivo móvil al que se le aplicó el mismo
procedimiento para calcular su costo.
Cantidad Costo Costo/ Hora Horas de uso TotalLicencia Microsoft
Office 20131 149.999$ 3$ 2040 $ 6.986
Licencia Enterprise Architect
1 477.600$ 54,52$ 2040 $ 111.222
Servicios
Tabla 9.1.6 Presupuesto estimación servicios
En la tabla 9.1.3 se especifican los costos totales de los servicios necesarios para la correcta
implementación del software; es decir las diferentes licencias que junto con los computadores
también serán provistas por la universidad así que del mismo modo el costo se cuantifica de
acuerdo a la amortización de cada una de ellas durante los 5 meses de uso.
9.2 Inicio del proyecto
9.2.1 Entrenamiento del personal
El objetivo principal de este proceso es apropiarse de las nuevas herramientas que serán
necesarias para el correcto desarrollo del software, se tendrá un tiempo de tres semanas en
donde cada integrante de L3, estudiará individualmente cada una de las herramientas. Luego
34
se realizará una reunión donde se puedan resolver dudas. Si por alguna razón ninguna de las
integrantes tiene solución a algún cuestionamiento, se planeará una reunión con el asesor del
trabajo de grado.
Este plan se realizará antes de comenzar con el desarrollo del producto y si una herramienta
por algún motivo, dejase de ser funcional debe ser retirada del plan de entrenamiento del
personal.
9.2.2 Infraestructura
Dentro de la infraestructura que soporta el proyecto L3 se encuentran las instalaciones físicas,
herramientas de software definidas anteriormente (ver sección 8.2 Lenguajes y Herramientas) e
infraestructura de hardware necesaria para desarrollar de forma exitosa el software.
9.2.2.1 Instalaciones
El proyecto se desarrollará principalmente en las instalaciones de la Pontificia Universidad
Javeriana para el trabajo grupal y las reuniones semanales, adicionalmente para el trabajo
individual las instalaciones que se utilizarán serán las casas de cada una de las integrantes de
L3.
9.2.2.2 Entorno de desarrollo
El entorno de desarrollo está definido en la sección de Lenguajes y Herramientas (Véase
sección 8.2 Lenguajes y herramientas)
9.2.2.3 Servidor
La arquitectura cliente/servidor será alojada en uno de los computadores de la Pontificia
Universidad Javeriana que será solicitado por el productor ejecutivo de L3, por medio de un
correo electrónico al Ingeniero Hernando Hurtado del departamento de Ingeniería de Sistemas
al inicio del desarrollo del producto.
9.2.2.4 Equipos
En la tabla 9.2.2.4 se especificarán las características de los computadores que serán
utilizados por cada integrante del grupo.
35
Integrante Procesador Memoria RAM
Sistema Operativo
Disco Duro Otros
Daniela Chacón Amd x4-3400 2 GB Windows 8 500 GB Amd 5630
Laura Gómez Amd Phenom X4 2 GB Windows XP 1000 GB Zotac GT 210
Laura López Intel Celeron T3450
4 GB Windows 10 500 GB Intel HD 4000
Tabla 9.2.2.4.1 Equipos de los integrantes de L3
Adicionalmente, para el desarrollo del proyecto se trabajará sobre un dispositivo móvil, Galaxy
S4.
9.3 Planes de trabajo del proyecto
9.3.1 Descomposición de actividades
El proyecto tiene cinco entregas principales, que contienen actividades diferentes que se deben
realizar para completarlas. En la siguiente figura se muestran las actividades a realizar en cada
una de las fases.
36
ACTIVIDAD TAREA
Recorrer cada una de las cafeterías e ir anotando una aproximación de afluencia de asistencia en esta,
adicionalmente tomar fotografía del lugar
Recopilar en un documento la afluencia promedio de personas en las horas que se establecieron.
Recorrer cada una de los restaurantes e ir anotando una aproximación de afluencia de asistencia en estos,
adicionalmente tomar fotografía del lugar
Recopilar en un documento la afluencia promedio de personas en las horas que se establecieron.
Crear encuesta Online
Realizar análisis estadístico de las encuestas
Planificar entrevista
Realizar entrevista
Buscar referencias sobre el tema Definir modelo de ciclo de vida
Definir roles y responsabilidades Definir herramientas de trabajo
Definir servicios que podrían implementarse
Reunión integrantes y directora para plantear los servicios que se presentarán a los servicios de alimentación
Reunión servicios de alimentación
Proponer algoritmos que ayuden a la implementación de los servicios identificados
Reunión integrantes y directora para especificar la dificultad de los algorimos propuestos
Definir cada ítem de gustos, restricciones, hábitos , preferencias e intereses
Reunión integrantes y directora para revisar el perfil de usuario
Corregir según comentarios el perfil de Usuario
Reunión integrantes y directora para revisar correcciones
Definir cada ítem que conformará el perfil de contextoReunión integrantes y directora para revisar el perfil de
contexto
Corregir según comentarios el perfil de contexto
Reunión integrantes y directora para revisar correcciones
Relacionar los perfiles con la información que se tendrá disponible
Acotar los perfiles Definir los caminos de decisión para cada ítem de los
perfiles Reunión integrantes y directora para revisar el modelo de
adaptaciónCorregir el modelo de adaptación
DESARROLLO DEL MODELO DE ADAPTACIÓN Y SERVICIOS
ANALISIS DE ENTORNO
Generación el modelo de adaptación de acuerdo a los perfiles de usuario y
contexto ya planteados
Identificación de los algoritmos que ayudarán a implementar los servicios
definidos
DISEÑO DE ALGORITMOS
Observación de cafeterías en horario de gran afluencia de público
Observación de restaurantes en horario de gran afluencia de público
Realización de encuestas para conocer el perfil de usuario del usuario final.
Realización de entrevistas para conocer el perfil de usuario del usuario final
Identificación de los servicios que serán ofrecidos por el sistema
Identificación de trabajos relacionados
Planteamiento el perfil de usuario
Planteamiento el perfil de contexto
37
Buscar algoritmos de ruta óptima ,optimización de tiempos, maximización de recursos ,Georeferenciación
Encontrar ventajas y desventajas de cada algoritmo encontrado
Elegir algoritmos con los cuales se va a trabajar
Relacionar los algoritmos con cada servicio que será proveido por L3.
Buscar tipos de enriquecimiento de servicios
Encontrar ventajas y desventajas de los tipos de enriquecimiento
Elegir la manera en la cual se va a enriquecer la aplicación.
Adaptar el algoritmo o algoritmos de ruta óptima a el servicio de L3
Adaptar el algoritmo o algoritmos de optimización de tiempos a el servicio de L3
Adaptar el algoritmo o algoritmos de rmaximización de recursos a el servicio L3
Adaptar el algoritmo o algoritmos de georeferenciación a el servicio de L3
Definir los requerimientos funcionalesDefinir los requerimientos no funcionales
Definir requerimientos adaptativosPriorizar Requerimientos
Realizar diagrama de casos de uso Reunión integrantes y directora para revisar
requerimientos y casos de uso Corrección requerimientos y casos de uso
Realizar documento SRS
Reunión integrantes y directora para revisar SRS
Realiza corrección de SRSRealizar diagrama de contexto
Realizar diagrama overviewRealizar Escenarios de calidad
Realizar vista lógica Realizar vista de implementación
Realizar vista de despliegue Realizar documento SAD
Reunión integrantes y directora para revisar SAD
Realizar corrección de SADApropiarse con las herramientas que se van a utilizar
Realizar paratipoDefinir roles en la implementación del modelo-vista-
controladorDesarrollar primer servicio
Reunión integrantes y directora para revisar avance de software
Desarrollar segundo servicio Reunión integrantes y directora para revisar avance de
softwareDesarrollar tercer servicio
Reunión integrantes y directora para revisar avance de software
Desarrollar cuarto servicio Reunión integrantes y directora para revisar avance de
softwareMejorar diseño de la aplicación
Probar primer servicio Probar segundo servicio
Probar tercer servicio Probar cuarto servicio
Probar aplicación en conjunto
DESARROLLO DEL APLICATIVO
Descripción de las reglas a utilizar en el enriquecimiento de servicios
Realización del pseudocódigo de los algoritmos a implementar
Búsqueda de algoritmos que resuelvan problemas similares
Adaptación de algoritmos al problema propuema propuesto
DISEÑO DE ALGORITMOS
Implementación del prototipo
Verificación del prototipo por pruebas unitarias
Levantamiento de requerimientos
Diseño de la arquitectura
38
Presentar la aplicación a la comunidadRealizar publicidad mediante medios electrónicos
Revisión de la acogida de la aplicación Revisar estadisticas de descarga de la aplicación
Revisión de la frecuencia de uso de la aplicación Revisión de la frecuencia de uso de la aplicación
Identificar errores comunes Buscar soluciones a los errores encontrados
Implementar las correcciones al prototipoProbar nuevamente el servicio uno
Probar segundo servicioProbar tercer servicio Probar cuarto servicio
Probar aplicación en conjunto Revisar comentarios acerca de la aplicación
Realizar una encuesta online Realizar analisis estadistico de encuesta
Determinar posibles soluciones a comentarios negativos
APLICABILIDAD
Determinar el grado de satisfacción
Entrega del prototipo a usuarios finales
Revisión reporte de errores de los usuarios
Validación del sistema por medio de las anteriores revisiones
Tabla 9.3.7 Descomposición de Actividades L3
9.3.2 Calendarización
El cronograma que se seguirá para el desarrollo de L3 está basado en el modelo de ciclo de
vida, además de las fechas establecidas por la facultad para la entrega del trabajo de grado,
especificado en la (Sección 6.5.1 Calendarización y presupuesto ).
A continuación se presentará un diagrama conjunto de Gantt con las actividades, el tiempo
mostrado en el ‘eje x’ y las relaciones de precedencia se indican con líneas entre actividades.
Para la primera fase metodológica se presupuestó un tiempo de dos meses. Esta fase ya ha
sido terminada para el desarrollo de la propuesta de trabajo de grado; puesto que esta fase es
fundamental para la obtención de la problemática que será solucionada. Se tomaron
actividades de dos semanas aproximadamente; algunas de estas realizándose en paralelo.
Figura 9.3.2.7Fase Análisis de Entorno
En esta fase, se presupuestó un tiempo 37 días, realizando actividades secuencialmente. Cada
actividad tomará un tiempo aproximado de una semana.
39
Figura 9.3.2.8 Fase Desarrollo del Modelo Adaptativo
Esta tercera fase se tiene estimada terminarla en 3 semanas, en esta fase se tendrán como
resultado final los diferentes algoritmos a implementar para la solución de los problemas
propuetos
Figura 9.3.2.9 Fase Diseño de Algoritmos
Para la realización de la cuarta fase, se estimó un tiempo aproximado de 45 días; realizando
nuevamente actividades secuenciales. Como se puede observar, la actividad que tiene una
duración más larga es la implementación del prototipo; puesto que es la actividad que cuenta
con un mayor riesgo.
Figura 9.3.2.10 Fase Desarrollo del aplicativo
Finalmente, en la fase de aplicabilidad de realizarán actividades en paralelo, con base en las
estadísticas de usuario que arroje la aplicación. El tiempo estimado para la terminación de esta
fase es de un mes.
Figura 9.3.2.11 Fase Aplicabilidad
9.3.3 Asignación de recursos
El propósito de esta sección es categorizar y organizar las actividades de cada uno de los
integrantes del proyecto, además de ello es presentar los recursos con los que se cuentan para
poder llevar dichas actividades a buen término.
Para la asignación de recursos se realizará una reunión con las integrantes del grupo, donde se
analizarán los recursos necesarios en cada fase, además de realizar una relación entre cada
40
uno de los roles y el cronograma para poder calcular quién necesita ciertos recursos y quién no
los necesita, como también su disponibilidad.
La asignación de estos recursos (sean materiales, intelectuales o de tiempo) pueden
encontrarse en la tabla 9.3.3 Asignación de recursos.
41
ACTIVIDAD RESPONSABLE RECURSO
Observación de cafeterías en horarios de gran afluencia de público Equipo L3
Computador, Microsoft Office (Word), Dropbox, Whatsapp
Observación de restaurantes en horarios de gran afluencia de público Equipo L3
Computador, Microsoft Office (Word), Dropbox, Whatsapp
Realización de encuestas para conocer el perfil de usuario del usuario final
Equipo L3 Computador, Microsoft Office (Word), Dropbox, Whatsapp,Google Chrome
Realización de entrevistas para conocer el perfil de usuario del usuario final
Equipo L3 Computador, Microsoft Office (Word), Dropbox, Whatsapp,Google Chrome
Identificación de trabajos relacionados Equipo L3 Computador, Microsoft Office (Word), Dropbox, Whatsapp,Google Chrome
Identificación de los servicios que serán ofrecidos por el sistema Equipo L3 Computador , Reunión Cliente ,Lista de Riesgos , Dropbox
Identificación de los algoritmos que ayudarán a implementar los servicios definidos
Equipo L3 Google Chrome, Word , Dropbox, Reunión Clientes, Reunión Equipo
Planteamiento el perfil de usuarioLider de
Arquitectura
Enterprise, Dropbox, Reunión Equipo, Reunión Clientes, Whatsapp ,
Computador
Planteamiento el perfil de contextoLider de
Arquitectura
Enterprise, Dropbox, Reunión Equipo, Reunión Clientes, Whatsapp ,
Computador
Generación el modelo de adaptación de acuerdo a los perfiles de usuario y contexto ya planteados
Lider de Arquitectura
Enterprise, Dropbox, Reunión Equipo, Reunión Clientes, Whatsapp , Computador, Documento de
diagnostico primera fase
Búsqueda de algoritmos que resuelvan problemas similares Equipo L3
Google Chrome, Word , Dropbox, Reunión Clientes, Reunión Equipo
Adaptación de algoritmos al problema propuema propuesto
Patrocinador Ejecutivo
Google Chrome, Word , Dropbox, Reunión Clientes, Reunión Equipo,
Eclipse, Java, Github
Descripción de las reglas a utilizar en el enriquecimiento de servicios
Patrocinador Ejecutivo
Google Chrome, Word , Dropbox, Reunión Clientes, Reunión Equipo,
Modelo de adaptaciónRealización del pseudocódigo de los algoritmos a
implementarPatrocinador
Ejecutivo Google Chrome, Word , Dropbox,
Eclipse, Java, Github
Levantamiento de requerimientos Equipo L3 Excel, Dropbox, Documento
Diagnostico fase inicial Diseño de la arquitectura Lider Arquitectura Enterprise,Dropbox, Github, word
Implementación del prototipoLider Programación
HTML5, Css,Oracle Database11 g, Phonegap, Ionic,Android,Javascript ,
Github
Verificación del prototipo por pruebas unitariasLider Programación
HTML5, Css,Oracle Database11 g, Phonegap, Ionic,Android,Javascript ,
Github
Entrega del prototipo a usuarios finales Equipo L3 Google chrome, Word , Dropbox, Prototipo, Reunión Clientes
Revisión de la acogida de la aplicación Equipo L3 Google Chrome, ExcelRevisión de la frecuencia de uso de la aplicación Equipo L3 Google Chrome, Excel
Revisión reporte de errores de los usuarios Equipo L3 Google Chrome, Excel
Validación del sistema por medio de las anteriores revisiones Equipo L3
HTML5, Css,Oracle Database11 g, Phonegap, Ionic,Android,Javascript ,
GithubDeterminar el grado de satisfacción Equipo L3 Google Chrome, Excel, Word
FASE ANALISIS DE ENTORNO
DESARROLLO DEL MODELO DE ADAPTACIÓN Y SERVICIOS
DISEÑO DE ALGORITMOS
DESARROLLO DEL APLICATIVO
APLICABILIDAD
Tabla 9.3.8 Asignación de Recursos
9.3.4 Asignación de presupuesto y justificación
42
El presupuesto para el desarrollo de la aplicación L3 se calcula a partir de la cantidad de horas
y los recursos humanos necesarios para realizar cada tarea existente en el cronograma del
proyecto (Véase Sección 6.5.1 Calendarización y presupuesto).
La hora que se paga a cada recurso humano es la misma sin importar su rol y se establece en
$13.000 COP el cual es el salario promedio de un practicante de ingeniería de sistemas, como
se explica en la Sección 9.1.1 Estimación horas personal.
Dado que esto es un proyecto estudiantil, la asignación del presupuesto es basado en un
supuesto, pero se asemeja a lo que en la realidad debería ser una estimación del costo. El
costo total del proyecto así como la especificación de costos por tarea se encuentra en el
anexo de presupuesto (ver Anexo Estimación costo proyecto).
43
10. Monitoreo y Control del Proyecto.
10.1 Monitoreo y Control del Progreso
Esta sección tiene como objetivo describir actividades para reportar el progreso individual, el
del proyecto y también describir actividades para el control de cronograma que fue propuesto
inicialmente.
Para reportar el avance del proyecto, se realizarán reuniones semanales con la directora de
grado para darle un reporte acerca de este, en esta reunión se le informarán las actividades
que fueron realizadas durante la semana, se revisarán, se recibirá una retroalimentación para
el mejoramiento de la calidad por parte de la directora y se decidirán las actividades a realizar
para la siguiente semana, estas actividades serán más o menos dependiendo de la opinión de
la directora. Por otro lado, el patrocinador ejecutivo será quien revise el cronograma
periódicamente para determinar si hay retrasos significativos en el avance del proyecto, para
así tomar medidas correctivas.
Adicionalmente, el patrocinador ejecutivo a medida que los entregables del proyecto sean
realizados y aceptados por la directora, diligenciará la plantilla de entregables (Véase plantilla
de entregables) con el fin de que las integrantes tengan claridad de los entregables terminados
y faltantes y el porcentaje de avance de estos.
Cada integrante entregará un reporte de avance individual (Véase plantilla avance individual)
por semana al patrocinador ejecutivo, donde estarán registradas las diferentes actividades
realizadas.
En caso de que luego de la revisión del calendario, por parte del patrocinador ejecutivo, se
puedan evidenciar retrasos en las actividades asignadas a una persona, el patrocinador deberá
reasignar la actividad a otra integrante del grupo que se encuentre con la menor carga de
trabajo en ese momento, si por alguna razón las otras integrantes ya tienen suficiente carga,
será necesario que la actividad sea desarrollada por 2 estudiantes para agilizar la finalización
de la tarea. Por otro lado, si el patrocinador al revisar el reporte individual evidencia que una de
las integrantes tiene un bajo rendimiento en su desempeño, deberá dialogar con ella para
buscar soluciones a esto.
44
10.2 Cierre del proyecto
En este apartado se describirán el conjunto de actividades que se desarrollarán para el cierre
del proyecto. Para cerrar el proyecto será necesario crear una página web en el espacio
asignado, donde quedarán registrados los documentos exigidos por la Coordinación de trabajo
de grado del departamento de ingeniería de sistemas, entre los cuales se encuentran:
Propuesta de Trabajo de Grado (formato .doc y .pdf)
Memoria (en formato .doc y .pdf)
Anexos
Bibliografía
Póster
Video de uso del software
Adicionalmente, la página web contendrá información sobre el trabajo de grado, como la
modalidad, grupo, código, descripción, objetivos, autores, director, título y datos de contacto de
los participantes.
Posterior a la entrega del trabajo de grado, se deberá hacer una sustentación de este frente a
los jurados que sean asignados y la directora del trabajo y será evaluado por ellos. Si los
jurados creen pertinente que L3 realice correcciones al trabajo, estas deberán ser entregadas
cinco días calendario para entregar estas a la directora de trabajo.
Para finalizar, L3 deberá elaborar un CD con los documentos solicitados por la biblioteca para
ser entregados a esta, se tendrá como plazo máximo la segunda semana del siguiente periodo
académico.
45
11. Entrega del producto
Antes de hacer una entrega formal al cliente se debe ejecutar el plan de aceptación. El
responsable de la entrega del producto final será el Productor ejecutivo y se llevará a cabo el
25 de Noviembre de 2015 en el que el grupo de trabajo subirá el trabajo finalizado a Pegasus.
La entrega se hará online, mediante una página web que contendrá los siguientes entregables:
Análisis de la problemática actual
Modelo adaptativo del sistema
Listado de servicios a implementar
Algoritmo de ruta óptima
Algoritmo de optimización de tiempos
Algoritmo de maximización de recursos
Algoritmo de georreferenciación
Documento de enriquecimiento de servicios
SPMP
SRS
SAD
Reporte de pruebas
Informe de satisfacción de los usuarios finales
Prototipo
46
12. Procesos de soporte
12.1 Ambiente de trabajo
El equipo de trabajo (L3) está regido primeramente por los estándares éticos y morales; los
cuales se han declarado en comunión y presencia de los demás miembros mediante una
democracia. Las normas permiten el buen ambiente de trabajo y sobre todo una facilidad en la
comunicación. Estas normas también describen las sanciones y los correctivos establecidos
para el miembro del grupo que no cumpla sus responsabilidades, además también se incluyen
un galardón (premiación) por la buena conducta y el total cumplimiento de todas ellas. La más
importante de las reglas es la que enuncia la existencia de un sistema democrático el cual
faculta a cada uno de los miembros de votar sobre decisiones importantes dentro del proyecto
o dentro del grupo (cambios de roles, cambio de plataformas de comunicación, entre otras).
Para que estas votaciones se lleven a cabo, la totalidad del grupo debe estar presente, y para
que estas votaciones se tengan en cuenta todos los integrantes deben estar a favor de la
decisión discutida en el momento, en caso de abstención mayoritaria se replanteará el
problema y se buscará diferentes soluciones.
Las reuniones se definieron tres veces por semana los días miércoles con la directora y los
días martes y jueves con las integrantes del grupo a las 10 a.m. en la entrada de la Biblioteca
(sujeto a cambios a través de votación)
47
12.1.1 Reglas de conducta
No se aceptan palabras soeces dentro del grupo de trabajo, en tal caso de que haya
una agresión verbal se analizará entre las integrantes.
En caso de que un integrante no pueda asistir a una reunión pactada, debe avisar con
un plazo mínimo de 24 horas y con su motivo justificado.
El margen de llegada a una reunión es de máximo 15 minutos.
En caso de que un integrante llegue tarde a una reunión tendrá una multa económica
que deberá pagar a las personas que lleguen puntual, el valor será de $ 2.000 pesos.
Después de cada entrega, se hará un control de eficiencia y calidad de cada integrante.
No se acepta que ningún miembro del grupo abandone una tarea que se le ha sido
asignado sin una razón válida.
Queda prohibido consumir bebidas alcohólicas (o estar bajo sus efectos) durante el
desarrollo de las tareas grupales o reuniones.
Totalmente prohibido realizar copia intencional de un (o varios) documentos que hagan
perder validez el proyecto (en otras palabras plagio), en tal caso que alguno de los
miembros sorprenda a otro miembro infringiendo esta norma se debe realizar una
reunión entre las integrantes para aclarar lo sucedido.
12.2 Análisis y administración de riesgos
En esta particular sección se describirán los temas relacionados a los riesgos. Iniciando con
una métrica subjetiva para cada riesgo y relatando la forma de análisis de dicho riesgo, a
continuación se comenta la forma de hallar soluciones o al menos un apaciguamiento para
minimizar su impacto al proyecto.
Con el fin de cuantificar los posibles riesgos en la realización del trabajo de grado, estos son
cuantificados dando como resultado el análisis de probabilidad de ocurrencia y valoración de
impacto.
48
La cuantificación de los riegos se realiza bajo los siguientes parámetros [46]:
Probabilidad de Ocurrencia:
Raro: < 20%
Improbable: 20% - 40%
Posible: 40% - 60%
Probable: 60% - 80%
Muy Probable: > 80%
Valoración de impacto:
Insignificante
Menor
Moderado
Crítico
Catastrófico
Luego de asignar a cada uno de los riesgos una probabilidad de ocurrencia y una valoración de
impacto de acuerdo a lo anterior, este será clasificado de acuerdo a la tabla 12.2.1 y tendrán
una tolerancia.
Insignificante Menor Moderado Crítico CatastróficoRaro Elevada Elevada Elevada Elevada Media
Improbable Elevada Elevada Media Media Media
Posible Elevada Elevada Media Media Baja
Probable Elevada Media Media Baja Baja
Muy probable Elevada Media Baja Baja Baja
ToleranciaImpacto
Prob
abili
dad
Tabla 12.2.9 Matriz de Tolerancia de Riesgos [46]
La estrategia que se tendrá como grupo se basa en no tratar con todos los riesgos, sino
priorizar los riesgos más peligrosos para el proyecto, una vez que se hayan escogido los
riesgos, se les hará un análisis más detallado en una reunión con el equipo con el fin de decidir
el plan de mitigación, el plan de contingencia [47] y la frecuencia con la que se monitoreará
cada riesgo.
El análisis de riesgos estará a cargo de todas las integrantes, la planeación y supervisión de
riesgos estará a cargo del productor ejecutivo.
49
A continuación se presenta un modelo visual que muestra detalladamente el proceso del
tratamiento y administración de riesgos, este proceso se realizará en la preparación de cada
entregable y después de las fechas pactadas para estos.
El modelo en si es reiterativo, pues aunque existen infinidad de riesgos, su reiteración reafirma
la existencia de brechas que pueden afectar el proyecto de múltiples maneras.
Figura 12.2.1: proceso de gestión de riesgos
Para este proceso acordado por L3, se usará principalmente una sola plantilla donde se irá
modificando según los riesgos que van apareciendo en el desarrollo del proyecto,
adicionalmente, antes de realizar la modificación se supervisa el riesgo, mediante una reunión
con el equipo.
12.3 Administración de configuración y documentación
Esta sección tiene como objetivo establecer normas para el manejo del repositorio y el control
del versionamiento, para que sea posible llevar un control de los documentos y de los
respectivos cambios en cada uno de ellos.
Para el almacenamiento de los documentos se usará Dropbox [20], donde habrá una carpeta
por cada actividad, dentro de estas carpetas cada integrante deberá subir los documentos
relacionados a la actividad correspondiente.
Si aplica, el nombre de los documentos debe tener el siguiente formato:
Figura 12.1.1.12 Proceso de gestión de riesgos
50
<Número de sección>.<Nombre de sección>
En caso de que sea un documento completo será:
<Nombre del documento> <Fecha>
En caso de que sea algún diagrama o imagen:
<Nombre diagrama> <Fecha>
Finalmente, para el almacenamiento del código fuente su utilizará Github [15], donde la líder de
programación deberá crear una rama principal llamada Master Branch y cada cambio que se
realice debe hacerse por medio de otra rama. Esto tiene como ventaja que no se afectan los
archivos de otras ramas, simplemente los que se pueden ver afectados por el respectivo
cambio. Para que las integrantes puedan cargar documentos al repositorio deben enviar una
solicitud al líder de programación, encargado de aceptar el cambio requerido, en caso de que
sea el mismo líder quien haga el cambio, este será aceptado por el patrocinador ejecutivo.
El proceso de subir códido fuente empezará cuando alguna de las integrantes de L3 elabore un
avance o funcionalidad del sistema, posteriormente se le hará la revisión de calidad, en caso de
que la satisfaga, se podrá enviar la solicitus para que el archivo pueda ser cargado en el
branch, solicitud que aceptará el líder de programación.
Para el manejo de cambios en algún archivo del proyecto, la persona que quiera hacerlo
deberá registrarlo en la plantilla (Véase plantilla de cambios), dando una descripción del cambio
y la respectiva justificación de este. El documento donde se registren estos datos deberá ser
consultado periódicamente por el equipo de trabajo, para estar al tanto de estos.
12.4 Métricas y proceso de medición.
Este apartado tiene como objetivo definir diferentes patrones de medición, los cuales le servirán
a L3 para medir los distintos entregables que se tienen a lo largo del proyecto.
12.4.1 Documentos
Para evaluar la calidad de los documentos se tendrán en cuenta cinco aspectos [48], a los que
se les asignará una calificación de 1 a 5, donde 1 es deficiente y 5 es excelente
51
Foco: El documento presenta consistencia en cuanto a quién va dirigido y el objetivo de
este. Además, el texto contiene ideas claras que llevan al propósito por el cual se
escribe este.
Contenido: la información presentada en el documento corresponde al tema designado
para la creación de este, de igual manera las ideas están debidamente desarrolladas y
son relevantes para el foco del texto.
Organización: Este documento debe contar con un orden lógico entre palabras,
oraciones y párrafos, manteniendo una secuencia que debe permanecer.
Estilo: se debe contar con un lenguaje preciso para el propósito de cada texto, Si el
documento presenta palabras técnicas estas deben estar acorde con el contenido del
texto, para que de esta manera el escrito sea coherente.
Convenciones: Este aspecto tendrá en cuenta dos pilares importantes la grafía
(ortografía de las letras, mayúsculas y puntuación) y la gramática.
12.4.2 Código fuente
Cuando se hagan revisiones del código se medirán las siguientes características:
Esfuerzo: Horas dedicadas a la creación del código Cantidad de errores Líneas de código
Para evaluar el código de acuerdo a las características ya nombradas se hará uso de las
siguientes fórmulas (Véase control de calidad).
Calidad: La calidad del código se determinará de acuerdo a la densidad de errores, con
la siguiente fórmula
Densidad deerrores=Cantidad de erroresL í neas dec ódigo CITATION Pan03¿9226[49]
Productividad: Se medirá el esfuerzo de cada programador a través de la siguiente
fórmula
Productividad=L í neas dec ódigoEsfuerzo CITATION Pan03 ¿9226[49]
12.5 Control de calidad
Esta sección describe el proceso que se llevará a cabo para que sea posible garantizar la
calidad de los diferentes entregables del proyecto.
52
Cada entregable deberá ser revisado por alguien distinto de la persona que lo realizó, es decir
al acabar una actividad asignada, otra integrante del grupo deberá revisar el entregable de
acuerdo a las plantillas ya nombradas (Véase 12.4 Métricas y Proceso de Medición).
12.5.1 Documentos
Para realizar control de calidad de los documentos se llevará a cabo el proceso descrito en las
figuras 12.5.2 y 12.5.3 haciendo uso de la plantilla (Véase plantilla calidad de documentos). En
primer lugar, la integrante que termine una actividad deberá entregarla a la integrante con
menos carga de trabajo en dicho momento, esto será determinado por el patrocinador
ejecutivo, dicho integrante realizará una revisión de las métricas ya propuestas para la
evaluación de los documentos (Véase 12.4 Métricas y Proceso de Medición). En caso de que el
documento no cumpla con los criterios establecidos en la plantilla, se le deberá avisar a quien
lo hizo para que realice las modificaciones necesarias.
12.5.2 Código fuente
Para realizar la revisión del código fuente se hará de la misma manera como fue descrito en la
sección anterior. Es decir al terminar una parte del código será entregado a la integrante con
menor carga de trabajo.
Dado el caso de que el código no tenga errores de compilación y esté completo, se llenará la
plantilla de calidad de código (Véase plantilla calidad de código fuente), por otro lado también
será necesario revisar el código teniendo como base los diagramas de diseño realizados
anteriormente, es decir que los dos concuerden. Finalmente, se realizarán pruebas unitarias de
un componente funcional mínimo.
Si el código fuente no cumple con los parámetros de calidad anteriormente mencionados, este
será devuelto para realizar las correcciones necesarias y poder desarrollar un producto de
calidad que satisfaga los requerimientos. Este proceso es descrito en las figuras 12.5.4 y 12.5.5
53
Bibliografía
54
[1] J. Cuello y J. Vittone, Diseñando apps para móviles, Barcelona, 2015.
[2] Android, «Android,» 2015. [En línea]. Available: http://www.android.com/history/. [Último acceso: 20 05 2015].
[3] IEEE, Estandar 1471.
[4] IEEE, Standard for Software Project Management Plans.
[5] IEEE, Std 830-1998.
[6] Bizagi, «Bizagi,» 2002. [En línea]. Available: http://www.bizagi.com/esp/descargas/BPMNbyExample.pdf. [Último acceso: 12 Septiembre 2014].
[7] U. T. d. l. Salle, «Universidad Tecnológica de la Salle,» [En línea]. Available: http://www.ulsa.edu.ni/publicaciones/-V-Anio/Plan-Sabatino-III-Trimestre/Administracion-Plantas-Industriales/DiagramaGANTT.pdf. [Último acceso: 12 Septiembre 2014].
[8] W. Maner, «Sidar,» 1997. [En línea]. Available: http://www.sidar.org/recur/desdi/traduc/es/visitable/maner/Prototipado.htm. [Último acceso: 12 Septiembre 2014].
[9] I. Object Management Group, «Object Management Group, Inc.,» 10 Septiembre 2014. [En línea]. Available: http://www.omg.org/gettingstarted/what_is_uml.htm. [Último acceso: 12 Septiembre 2014].
[10] D. C. Marcos, «Universidad Nacional del centro de la provincia de Buenos Aires,» 27 Agosto 2008. [En línea]. Available: http://www.exa.unicen.edu.ar/catedras/agilem/cap23asd.pdf. [Último acceso: 1 Septiembre 2015].
[11] O. S. J. R. &. J. W. Pekka Abrahamssom, Agile software development methods, Espoo: Otamedia OY, 2002.
[12] M. G. G. P. F. V. P. Yannira Arancibia, «Ingeniería de Software Informe de Metodología,» Universidad de TALCA, Talca, 2007.
55
[13] I. Sommerville, de Ingenieria del Software, Pearson , 2005, p. 67.
[14] «Software Engineering Institute,» 2 Noviembre 2013. [En línea]. Available: https://insights.sei.cmu.edu/sei_blog/2013/11/using-v-models-for-testing.html. [Último acceso: 1 Septiembre 2015].
[15] Github, «Empezando - Acerca del control de versiones,» [En línea]. Available: http://git-scm.com/book/es/Empezando-Acerca-del-control-de-versiones. [Último acceso: 28 8 2014].
[16] «Whatsapp,» 2015. [En línea]. Available: https://www.whatsapp.com/contact/. [Último acceso: 1 Septiembre 2015].
[17] Microsoft, «Microsoft Office 365,» 2015. [En línea]. Available: http://www.microsoftstore.com/store/mslatam/es_MX/cat/ThemeID.30633200/categoryID.67634800?Icid=HomePage_Latam_ES_Hero1_OfficeSave2months_lifestyle_32015. [Último acceso: 06 05 2015].
[18] «Sparx Systems,» Sparx Systems Pty Ltd., 2000. [En línea]. Available: http://www.sparxsystems.com.au/products/ea/. [Último acceso: 1 Septiembre 2015].
[19] «Google Chrome,» Google, 2001. [En línea]. Available: https://www.google.es/chrome/browser/desktop/index.html. [Último acceso: 4 Septiembre 2015].
[20] «Dropbox,» 2001. [En línea]. Available: https://www.dropbox.com/. [Último acceso: 4 Septiembre 2015].
[21] «Oracle,» [En línea]. Available: http://www.oracle.com/es/solutions/midsize/oracle-products/database/index.html. [Último acceso: 5 Septiembre 2015].
[22] «Eclipse,» [En línea]. Available: http://www.ibm.com/developerworks/ssa/library/os-ecov/. [Último acceso: 5 Septiembre 2015].
[23] «PhoneGap,» Adobe Systems Inc, [En línea]. Available: http://phonegap.com/. [Último acceso: 5 Septiembre 2015].
56
[24] «IonicFramework,» Drifty, 2013. [En línea]. Available: http://ionicframework.com/. [Último acceso: 5 Septiembre 2015].
[25] «Lenovo,» Lenovo, 2013. [En línea]. Available: http://www.lenovo.com/co/es/PC-Life-faqs/what-is-android/. [Último acceso: 5 Septiembre 2015].
[26] «Java,» Oracle, [En línea]. Available: https://www.java.com/es/about/whatis_java.jsp. [Último acceso: 5 Septiembre 2015].
[27] «MDN 10 years,» Mozilla, 2005. [En línea]. Available: https://developer.mozilla.org/es/docs/HTML/HTML5. [Último acceso: 5 Septiembre 2015].
[28] J. E. Pérez, de Introducción a CSS, Madrid, Libros Web, 2008.
[29] «MDN 10 years,» Mozilla, 2005. [En línea]. Available: https://developer.mozilla.org/es/docs/Web/JavaScript. [Último acceso: 4 Septiembre 2015].
[30] J. J. C. V. A. B. A. G. Jorge Enrique Otalora Luna, «ESTUDIO COMPARATIVO DE LAS HERRAMIENTAS,» Desarrollo Sostenible y Tecnología, vol. 11, 2009.
[31] «Hammer Principle,» 2003. [En línea]. Available: http://hammerprinciple.com/versioncontrol/items/monotone/git.. [Último acceso: 6 Septiembre 20015].
[32] B. O'Sullivan, Mercurial, O'Reilly , 2009.
[33] J. Loeliger, Version Control With Git, O'Reilly Media, 2012.
[34] I. D. J. B. Proaño, «DATAprix,» 5 Mayo 2006. [En línea]. Available: http://www.dataprix.com/files/analisis-comparativo_MySQL-Oracle.pdf. [Último acceso: 7 Septiembre 2015].
[35] J. Rex, «Airpar,» [En línea]. Available: https://www.airpair.com/android/android-studio-vs-eclipse. [Último acceso: 8 Agosto 2015].
57
[36] DeveloperAndroid, «DeveloperAndroid,» [En línea]. Available: http://developer.android.com/index.html. [Último acceso: 8 Agosto 2015].
[37] I. Sommerville, Software Engineering, Pearson; 9 edition, 2010.
[38] C. E. ,. B. A. S. Reiner Dumke, Best Practices in Software Measurement, Springer, 2004.
[39] S. T. M. G. B.B. Agarwal, Software Engineering And Testing: An Introduction, Jones & Bartlett Publishers, 2009.
[40] P. U. Javeriana, «Pontificia Universidad Javeriana,» [En línea]. Available: Pontificia Universidad Javeriana. [Último acceso: 14 Septiembre 2015].
[41] R. U. Process, Best Practices for Software, T. software development company Rational.
[42] R. R. M. Ricardo Velasco Preciado, «¿Cómo redactar propósitos?,» de Diplomado estrategias didácticas para la enseñanza de competencias informáticas básicas, Santiago de Chile, 2010.
[43] S. &. S. E. S. Committee, «Systems and software engineering- Life cycle processes—Risk management,» IEEE Computer Society, nº ISO/IEC 16085, 2006.
[44] O. Empleo, «OpciónEmpleo,» [En línea]. Available: http://www.opcionempleo.com.co/empleo-salario-estudiante-ingeniero-sistemas.html. [Último acceso: 10 Septiembre 2015].
[45] C. L. d. Ayuda, «LawInfo,» [En línea]. Available: http://abogados.lawinfo.com/es/preguntas-frecuentes/horas-y-salarios/federal/-cu-ntas-horas-constituyen-un-empleo-de-tiemp.html. [Último acceso: 13 Septiembre 2015].
[46] R. Pressman, Ingeniería del Software un enfoque práctico, McGraw Hill, 2010.
[47] NASA, NASA Systems Engineering Handbook, Washington D.C: National Aeronautics and Space Administration, 2007.
[48] F. Morales Ardaya, «Evaluar la escritura, sí... Pero ¿Qué y cómo evaluar?,» Acción pedagógica, vol. 13, nº 1, pp. 38-48, 2003.
58
[49] R. Pandian, Software Metrics: A Guide to Planning, Analysis, and Application, Auerbach Publications, 2003.
59
