SOFTWARE

PROJECT
MANAGEMENT
PLAN

SPMP para Simuscope

Esteban Hernández Losada

Emmanuel Neiza Salas
1 Historial de Cambios
Historial de Cambios
Versión Cambios efectuados Fecha de Actualización

v0.1.0 Se establece el documento y los numerales asociados al mismo Julio 29 de 2016

V1.0 Primera versión del documento enfocado a Planes de gestión del proyecto,
ciclos de vida y aplicación de elementos ya establecidos en la propuesta Agosto 9 de 2016
de trabajo de grado.
V2.0 Revisión de planes, actualización de herramientas y de bibliografía
Agosto 28 de 2016
asociada
V3.0 Corrección de herramientas debido a limitantes de GitHub Septiembre 22 de 2016

V4.0 Versión final del documento con los numerales completados según las Octubre 29 de 2016
necesidades del equipo de desarrollo
2 Prefacio
“Cuando uno trabaja en Ingeniería de Sistemas, también llamada Computación o Informática, a
menudo es difícil explicar su trabajo a una persona que no sabe del tema. Muchos se imaginan que
nuestra principal tarea es abrir computadores, cambiarle piezas, sacarle virus (cual médico de
cabecera) y otras tareas similares.” (Pavlich-Mariscal, 2013) El rol del ingeniero de sistemas no
se limita únicamente a las labores de programación y tareas que solo involucren aspectos de lógica
matemática o algoritmos. Por medio de este documento se puede mostrar como actividades de
carácter administrativo, gerencial y de planeación entran a jugar en el contexto de la ingeniería de
sistemas.

El Plan de Gestión de Proyecto de Software (SPMP) es un documento con el propósito de detallar

estándares, practicas, herramientas, planes y técnicas que fueron utilizadas por parte de Esteban
Hernández y Emmanuel Neiza en el desarrollo del prototipo del simulador virtual para
entrenamiento médico en laparoscopia con técnicas de ludificación, Simuscope.

La finalidad del documento principalmente es una guía para el equipo de desarrollo, además de ser
uno de los entregables donde se constata de una manera más profunda y explícita de los procesos,
tareas y actividades realizadas durante el desarrollo del proyecto hasta llegar al resultado final
como lo es el prototipo de Simuscope, también teniendo en cuenta elementos de planeación,
calendarización, estimación, gestión de riesgos, aseguramiento de calidad y control de versiones,
entre otros procesos relevantes y necesarios para cualquier desarrollo en el contexto de la
ingeniería de sistemas y aún más en la de software.
3 Tabla de Contenidos

1 Historial de Cambios ------------------------------------------------------------------------------------------------------ 1

2 Prefacio ----------------------------------------------------------------------------------------------------------------------- 2
3 Tabla de Contenidos ------------------------------------------------------------------------------------------------------ 3
4 Lista de Figuras ------------------------------------------------------------------------------------------------------------ 5
5 Lista de Tablas e Ilustraciones ------------------------------------------------------------------------------------------ 6
6 Vista General del Proyecto ---------------------------------------------------------------------------------------------- 7
6.1 Visión del Producto ------------------------------------------------------------------------------------------------- 7
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----------------------------------------------------------------------------------------------------------- 12
6.5 Resumen de Calendarización y Presupuesto ----------------------------------------------------------------- 13
6.6 Evolución del Plan -------------------------------------------------------------------------------------------------- 1
7 Glosario ---------------------------------------------------------------------------------------------------------------------- 2
8 Contexto del proyecto ---------------------------------------------------------------------------------------------------- 5
8.1 Modelo de Ciclo de Vida ----------------------------------------------------------------------------------------------- 5
8.1.1 Fase metodológica 1: Fase de Exploración ------------------------------------------------------------------- 6
8.1.2 Fase metodológica 2: Fase de desarrollo del prototipo ---------------------------------------------------- 7
8.1.3 Fase metodológica 3: Fase de Pruebas Final del Prototipo ----------------------------------------------- 7
8.2 Análisis de Alternativas y Justificación----------------------------------------------------------------------------- 8
8.3 Lenguajes y Herramientas ---------------------------------------------------------------------------------------- 22
8.3.1 Herramientas de Documentación y Control de Actividades -------------------------------------------- 22
8.3.2. Herramientas de Análisis, Diseño y Desarrollo ----------------------------------------------------------- 23
8.4 Plan de Aceptación del Producto ------------------------------------------------------------------------------- 26
8.5 Organización del Proyecto y Comunicación ----------------------------------------------------------------- 27
8.5.1 Interfaces Externas ------------------------------------------------------------------------------------------ 27
 8.5.2 Organigrama -------------------------------------------------------------------------------------------------- 28
9. Administración del Proyecto ---------------------------------------------------------------------------------------------- 30
9.1 Inicio del proyecto ------------------------------------------------------------------------------------------------- 30
9.1.1 Investigación de herramientas en fase de Concepción---------------------------------------------------- 30
9.1.2 Infraestructura ------------------------------------------------------------------------------------------------------ 31
9.2 Planes de Trabajo del Proyecto --------------------------------------------------------------------------------- 32
9.2.1 Descomposición de Actividades ------------------------------------------------------------------------- 32
10 . Monitoreo y Control del Proyecto ------------------------------------------------------------------------------- 33
10.1 Administración de Requerimientos ---------------------------------------------------------------------------- 33
10.2 Monitoreo y Control de Progreso ------------------------------------------------------------------------------ 35
10.3 Cierre del Proyecto------------------------------------------------------------------------------------------------- 36
11 Entrega del Producto-------------------------------------------------------------------------------------------------- 38
12 Procesos de Soporte --------------------------------------------------------------------------------------------------- 39
12.1 Plan Análisis y Administración de Riesgos ------------------------------------------------------------------ 39
12.2 Plan Administración de Configuración y Documentación ----------------------------------------------- 44
12.3 Plan de Control de Calidad--------------------------------------------------------------------------------------- 49
15. Referencias ------------------------------------------------------------------------------------------------------------------ 52
4 Lista de Figuras

Gráfico 1. Esquema de Ciclo de Vida en Espiral, Tomado de (Hashmi & Baik) ....................................... 10
Gráfico 2. Proceso de Aceptación de Riesgo y Resolución ......................................................................... 43
Gráfico 3. Proceso de control de calidad, tomado de (Sommervile, 2005)................................................. 49
Gráfico 4. Etapas de control de calidad, Adaptado de (Sommervile, 2005) ............................................... 51
5 Lista de Tablas e Ilustraciones

Ilustración 1. Disponibilidad Horaria del Equipo......................................................................................... 13

Ilustración 2. Estimación en Fase de Concepción ....................................................................................... 14
Ilustración 3. Estimacion en fase de Desarrollo .......................................................................................... 14
Ilustración 4. Estimación en fase de pruebas ............................................................................................. 15
Ilustración 5. Diagrama Gantt del Cronograma ............................................................................................ 0
Ilustración 6. Estimación del Presupuesto del Proyecto ............................................................................... 1
Ilustración 7. Proceso de Entrega Ágil Disciplinada. Tomado de (Amber, Scott W., 2013). ......................... 6
Ilustración 8. Esquema General de RUP tomado de (Zaragoza, s.f.) .......................................................... 11
Ilustración 9. Esquema de Modelo en V, tomado de (Bruegge & Dutoit , 2002) ....................................... 13
Ilustración 10. Esquema de Diente de Sierra, tomado de (Bruegge & Dutoit , 2002) ................................ 15
Ilustración 11. . Esquema de Modelo de Diente de Tiburón, tomado de (Bruegge & Dutoit , 2002) ........ 17
Ilustración 12. Esquema de SCRUM, tomado de (Deemer, Benefield, & Larman) ..................................... 21
Ilustración 13. Esquema de infraestructura del Proyecto de Simuscope ................................................... 31
6 Vista General del Proyecto

6.1 Visión del Producto

Se define la visión del producto utilizando la plantilla de aspectos de la plantilla de visión de RUP
(University of Houston), definiendo en alto nivel las necesidades y características requeridas para
Simuscope.

Desde su concepción, las cirugías mínimamente invasivas (MIS por sus siglas en inglés) se han
convertido en una completa revolución en lo que a aspectos quirúrgicos se refiere (Park & Lee,
2011). Desde su introducción práctica en las últimas dos décadas, ha representado un avance
sustancial en la forma como se realizan procedimientos médicos en pro de reducir el impacto que
tienen en el paciente al realizar incisiones más pequeñas y menos dolorosas (Mi, Hou, Yang, Xie,
& Bian, 2014). Esto ha hecho que este paradigma se haya ido convirtiendo en un procedimiento
predilecto para diversos tratamientos e intervenciones del tipo cardiovascular, intestinal o renal,
entre otras (Grantcharov et al., 2004).

Específicamente, el uso de la laparoscopia a través del orificio abdominal ha venido incrementado

en los últimos años (Nagendran, Gurusamy, Aggarwal, Loizidou, & Davidson, 2013). Este tipo de
cirugía utiliza un par de instrumentos especiales que solo tienen sus puntas visibles para la
manipulación y operación (Aggarwal, Moorthy, & Darzi, 2004) junto con una cámara con una
fuente de iluminación, a lo que se le denomina el laparoscopio. Estas herramientas sólo permiten
cinco grados de libertad lo cual limita los movimientos del cirujano (Quiñonez, 2010), requiriendo
un nivel de precisión y destreza especializado para realizar esta operación en particular y manipular
sus pinzas de forma efectiva.

Las técnicas de entrenamiento en los hospitales se limitaban al uso de muñecos o maniquíes que
simulan de manera parcial el cuerpo humano (Cooper & Taqueti, 2008) o bien, utilizar animales e
inclusive cadáveres para obtener las habilidades requeridas para efectuar de manera correcta un
procedimiento quirúrgico determinado (Mi et al., 2014), implicando costos elevados y dilemas
éticos que dificultan en gran medida a los centros de salud y universitarios en formar cirujanos
eficientes en sus labores. Cabe resaltar que el paradigma de aprendizaje tradicional de habilidades
quirúrgicas de la forma “ver, hacer y enseñar” (Gallagher et al., 2005) resulta sumamente costoso
en términos de tiempo al requerir de un cirujano entrenado para entrenar a los residentes.
Adicionalmente, para asegurar la efectividad de los procedimientos quirúrgicos, se necesita de un
proceso de formación para los cirujanos con el fin de explotar al máximo las ventajas y beneficios
que traen las cirugías mínimamente invasivas sobre las cirugías abiertas (Grantcharov et al., 2004),
evitando en lo posible limitantes físicas, económicas, legales y sociales que puedan llegar a
producirse, terminando en serias dificultades para un proceso de entrenamiento médico.

Debido a esto, se busca combinar tanto software como hardware para desarrollar un sistema
completo que brinde el apoyo necesario para la adquisición de habilidades, conocimientos y toma
de decisiones como preparación para el momento que se haga la operación correspondiente.
También, se enfocan estos esfuerzos con el fin de desarrollar sistemas que reduzcan los costos
financieros asociados, los tiempos de entrenamiento y formación, percepción de la dificultad y
optimización de otros parámetros y métricas que definan el nivel de experticia que adquiere el
estudiante (Gallagher et al., 2005).

Tomando en cuenta que la presente y las futuras generaciones de estudiantes de medicina poseen
ciertas habilidades gracias a la influencia de la informática y las aplicaciones digitales, añadiendo
el cómo estas tienen incidencia en las destrezas necesarias para realizar estas operaciones, se
vuelve fundamental el desarrollo de sistemas que tengan en cuenta analogías e interacciones que
resulten naturales para estas personas, por lo que entra a jugar la utilización de técnicas de
Ludificación (Kapp, 2012), las cuales ayudan a mejorar la experiencia del usuario en el uso de un
sistema, otorgando incentivos para el uso de los servicios que se ofrecen mientras se obtiene el
conocimiento y las habilidades durante este proceso. A medida que se abstrae el contenido en
forma de juego, adicionalmente, se obtiene una retroalimentación tanto del progreso en una
actividad como de los resultados finales de las actividades realizadas, evaluando las diferentes
métricas a tener en cuenta durante el entrenamiento, imitando los contenidos presentados en un
videojuego.

6.2 Propósito, Alcance y Objetivos

6.2.1 Propósito
A nivel de Prototipo

El propósito de este proyecto es crear el prototipo de un simulador virtual para entrenamiento

médico en laparoscopia de extracción de vesícula biliar o colecistectomía, buscando que sea un
sistema de bajo costo en relación a otras soluciones comerciales de la actualidad y aprovechar la
natividad digital de los usuarios para hacer uso de técnicas de ludificación que hagan del proceso
de aprendizaje uno más llevadero y motivante para cirujanos y residentes quirúrgicos.

A nivel de Proyecto

El propósito del proyecto de Simuscope es el de gestionar todas las actividades y prácticas como
un proceso formal de ingeniería de software, definiendo y siguiendo una serie de planes para
asegurar la generación de un producto de software de calidad como el resultado final del proceso
investigativo y formativo correspondiente a un trabajo de grado de ingeniería de sistemas.

6.2.2 Alcance
Como se ha establecido tanto en el contexto de la propuesta de trabajo de grado como desde la
modalidad escogida para el mismo (investigación) se busca desarrollar un prototipo del simulador
virtual que contenga los requerimientos más prioritarios asociados a los puntos clave y factores
diferenciadores que definen al mismo, enfocándose en aspectos de ludificación, integración con
dispositivos hápticos y retroalimentación tanto sensorial como visual. Si bien se definen otros
requerimientos que no están directamente asociados a estos aspectos, se determina que son
necesidades que se pueden desarrollar más adelante al no ser prioridad para los objetivos trazados
en el trabajo de grado.

Como parte del componente investigativo del trabajo de grado, se determina las razones de estos
elementos clave y son parte del propósito final a evaluar en la fase de pruebas si realmente estos
elementos resultan relevantes frente a las otras soluciones existentes, interpretando los resultados
y llegando a una serie de conclusiones finales correspondientes a la investigación realizada.

6.2.3 Objetivos
Teniendo en cuenta los lineamientos que enmarcan el trabajo de grado, se tiene un primer objetivo
general que se alinea a la pregunta generadora desde la propuesta de trabajo de grado, en este caso:
¿Cómo utilizar la tecnología de la realidad virtual para desarrollar un sistema de entrenamiento
médico en laparoscopia, haciendo uso de técnicas de ludificación?, así como una serie de objetivos
específicos que se definen metas específicas que se deben cumplir para alcanzar el objetivo
general, además de definir los resultados esperados y procesos acordes a un proceso de ingeniería
de software formal.
 6.2.3.1 Objetivo General
 Desarrollar un prototipo de realidad virtual para dar una alternativa de aprendizaje
para los practicantes médicos que se entrenan en laparoscopia, buscando que sea un
sistema de bajo costo y que haga uso de técnicas de ludificación.

6.2.3.2 Objetivos Específicos

 Definir un conjunto concreto de requerimientos y su categorización, que reflejen las
necesidades y restricciones encontradas para el desarrollo del sistema.
 Diseñar el simulador virtual para el entrenamiento quirúrgico en laparoscopia,
teniendo en cuenta los requerimientos y componentes necesarios para su
implementación.
 Implementar un prototipo de un sistema de entrenamiento médico en laparoscopia
de bajo costo, teniendo en cuenta los requerimientos y artefactos de diseño.
 Validar el prototipo en cuanto al cumplimiento de requerimientos y aplicando
pruebas de sus componentes y de todo el sistema.
 Evaluar el impacto del prototipo a partir de la retroalimentación obtenida de los
usuarios que prueben el sistema.

6.3 Supuestos y Restricciones

Los supuestos que se manejarán para Simuscope se relacionan con aquellos detalles y hechos que
se dan por sentado, hechos que deben darse para que el desarrollo del proyecto no se vea afectado.
Estos son los supuestos que se deben tener en cuenta para lograr este propósito:

 Las fechas de entrega y de sustentación suministradas no van a verse alteradas en el

transcurso del semestre.
 El prototipo final funcionará únicamente en el equipo asignado en la sala del grupo de
investigación Takina en el edificio ático.
 Los usuarios de pruebas no poseen ningún tipo de discapacidad visual o cognitiva que les
dificulte utilizar el sistema.
 Los usuarios de pruebas deben estar relacionados a un contexto de medicina o de realidad
virtual para utilizar el prototipo final.
  Los programas utilizados como pilares del prototipo no serán cambiados una vez sean
escogidos en la etapa de concepción.

Las restricciones son limitantes en alguno de los aspectos relevantes para el desarrollo del
proyecto, además de limitantes para los usuarios potenciales:

 El prototipo debe contar con motores gráficos, simulación virtual, soporte para dispositivos
externos hápticos para integrar una solución de simulación virtual para entrenamiento
médico.
 El sistema debe manejar un paradigma orientado a objetos en C/C++.
 El sistema debe hacer uso de los órganos provistos por el trabajo de grado del Ingeniero
Pablo Quiñones, en formato VTK.
 Solo se cuenta con un dispositivo háptico en la universidad, así como un único equipo de
cómputo asignado capaz de hacer uso de este dispositivo. Adicionalmente, los equipos de
cómputo tienen recursos de memoria dinámica y procesadores gráficos sumamente
limitados para la mayoría de motores gráficos y físicos.

6.4 Entregables
Se definen entregables como aquellos documentos y archivos complementarios a la memoria de
trabajo de grado y que complementan y muestran el proceso de desarrollo llevado a cabo para
alcanzar los objetivos trazados en el mismo (ver Administración de Configuraciones). Cabe
resaltar que estos documentos se irán desarrollando a medida que se avancen en las iteraciones,
por lo cual no se establece una fecha objetivo de los mismos exceptuando la fecha final de entrega
del proyecto de grado (15 de noviembre), aunque si se busca que en cada iteración se vaya
evolucionando o cambiando elementos del mismo.

 Software Project Management Plan (SPMP línea base): Siguiendo los estándares IEEE
[Std. 1058-1998] (IEEE Standards Board, 1998) para la elaboración de este. Dado que el
objetivo del proyecto no está enfocado tanto en los procesos del desarrollo formal del
 software como si lo haría una modalidad de Aplicación Práctica, la profundidad sobre los
procesos y los componentes de este son más acotados.
 User Stories: A través de la recopilación de un conjunto de User Stories se busca hacer una
definición rápida y simple sobre los objetivos de los diferentes involucrados en el proyecto
y las tareas que se busca cumplir con el prototipo final. Este documento en particular sirve
como primera aproximación a las necesidades y restricciones que posee Simuscope.
 Software Requirement Specification (SRS línea base): Según el estándar IEEE [Std. IEEE
830] (IEEE Standards Board, 1998) que especifica el SRS, se tendrá en cuenta para la
realización de dicho documento, enfocándose principalmente en la clasificación,
especificación y seguimiento de los requerimientos hasta su cumplimiento parcial o total.
 Software Design Document (SDD línea base): Basados en el estándar IEEE [Std. 1016-
2009] (IEEE Standards Board, 2009), se realizará entrega de este documento siguiendo con
los siguientes criterios principales de evaluación.
 Memoria de Trabajo de Grado: Documento final donde se condensan y se explican todos
los elementos que componen el proyecto orientados a la investigación y a los procesos de
generación de conocimiento, así como detallando más la justificación del sistema y sus
componentes desde la teoría y como son llevados a la práctica, evaluando su impacto final.

6.5 Resumen de Calendarización y Presupuesto

Durante el desarrollo del trabajo de grado se realiza una estimación en términos de horas, en donde
se toma la cantidad de horas que el grupo de trabajo dedicará cada día de la semana al proyecto
de grado. En total se va a dedicar 70 horas semanales las cuales se distribuirán de la siguiente
manera:

Ilustración 1. Disponibilidad Horaria del Equipo

Esta estimación se realizará a lo largo de 24 semanas lo cual daría un total de 1680 horas para la
realización del trabajo de grado. Para cada una de las fases metodológicas se definió una cantidad
de actividades las cuales se les asigna una cantidad de horas para su realización y cumplimiento
para el simulador a desarrollar. La distribución de las horas de cada una de las fases se puede
observar a continuación:

Ilustración 2. Estimación en Fase de Concepción

Ilustración 3. Estimacion en fase de Desarrollo

 Ilustración 4. Estimación en fase de pruebas

Se recuerda que, dado que se está utilizando un ciclo de vida basado en Entrega Ágil Disciplinada,
las actividades de la fase de desarrollo del proyecto se realizarán de manera iterativa e incremental,
por lo que se planean iteraciones de 3 semanas durante 15 semanas que se presupuestan para esta
fase. En el siguiente diagrama Gantt se pueden ver la asignación en fechas de las actividades
definidas anteriormente, resaltando nuevamente que las actividades de la fase de desarrollo se
repetirán mientras se realice esta etapa del proyecto, por lo que en el diagrama aparecen como si
se desarrollaran durante toda la fase.
Ilustración 5. Diagrama Gantt del Cronograma
El presupuesto por su parte se definirá con equipos con los que contamos y cómo se deprecia
el equipo a través del tiempo. También la valoración de horas-hombre en términos salariales
de cada uno de los miembros del equipo de trabajo.

El presupuesto para este trabajo de grado, se divide en 3 secciones las cuales son: Recursos
Humanos, Gastos de Hardware y Gastos generales. Cabe resaltar que dentro de los costos no
se incluyen el software libre que se utilizara en el proyecto ya que es gratuito al igual que los
dispositivos hápticos que serán proporcionados por la Pontificia Universidad Javeriana.

Ilustración 6. Estimación del Presupuesto del Proyecto

6.6 Evolución del Plan

Entendiendo que el Plan de Gestión de Proyecto de Software (SPMP) es parte de los
entregables (ver Entregables) y por tanto un ítem de configuración (ver Plan de
Administración de Configuraciones y Documentación), este documento estará regido por las
políticas de control de versiones y configuraciones. Es decir, que una vez establecido este
plan, en caso de requerirse cambios o modificaciones, se requerirá seguir los lineamientos
del control de versiones, para finalmente almacenarlo en el repositorio de documentos en
Google Drive, donde se puede manejar un historial de cambios de los documentos incluyendo
a este. Dado que el equipo de trabajo consiste en solo dos personas, resulta en un trabajo
innecesario realizar documentos explícitos para peticiones de cambio, por lo cual se decide
reducir la formalidad de este proceso al dejarlo solo con los formatos de control de versiones
dejando explícitos los cambios para una revisión si se considera necesaria.
7 Glosario
Proyecto: Serie de procesos y actividades para desarrollar un nuevo producto o mejorar uno
ya existente. (IEEE Standards Board, 2010). En este caso el proyecto será correspondiente al
Proyecto de Grado de Ingeniería de Sistemas correspondiente a los integrantes del equipo de
desarrollo del mismo.

Producto: Un conjunto completo de software y documentación respectiva. (IEEE Standards

Board, 2010) Para el contexto del Proyecto de Grado, el producto corresponderá al prototipo
y documentación asociada a Simuscope como simulador virtual para entrenamiento médico
en laparoscopia con técnicas de ludificación.

Equipo de Desarrollo: Corresponde a los integrantes del grupo del trabajo de grado: Esteban
Hernández y Emmanuel Neiza.

Documento: Unidad de información identificada de manera única para uso humano, como
reporte, especificación, manual o libro, ya esté en forma física o digital. (IEEE Standards
Board, 2010) Esta clasificación incluye los principales entregables (ver Entregables).

Cirugía: Operación médica que puede: buscar reducir o prevenir el dolor de un paciente;
reducir los efectos de un síntoma de una enfermedad; mejorar las funciones de alguna parte
del cuerpo del paciente; o bien, realizar la búsqueda de un problema en particular que pueda
tener este (U.S. National Library of Medicine, 2014).

Cirujano: Médico dedicado a la realización de cirugías y que ya posee experiencia en ese

campo.

Residente: Médico graduado que se encuentra en proceso entrenamiento para una

especialidad en particular. Un residente quirúrgico se encuentra en formación para poder
volverse cirujano.

Entrenamiento médico/quirúrgico: Proceso mediante el cual un residente o un cirujano (en

el contexto de este proyecto) busca prepararse para la realización de un procedimiento
quirúrgico determinado, determinando tanto el conocimiento como las destrezas requeridas
para hacerlo.

Cirugía Mínimamente Invasiva: Tipo de cirugía orientada a evitar los mayores efectos
secundarios de la operación, buscando realizar incisiones y cortes menos pronunciados para
aportar en el tiempo de recuperación del paciente, así como en aspectos estéticos.

Colecistectomía: Cirugía que consiste en la extirpación de la vesícula biliar, proceso que

requiere separarlo del hígado para sacarlo del organismo del paciente.

Laparoscopia: Técnica de cirugía mínimamente invasiva que consiste en solo realizar 3

incisiones en el abdomen del paciente, donde en una de estas se introduce una cámara con
fuente de iluminación propia denominada laparoscopio. En las otras dos incisiones se
introducen las herramientas quirúrgicas con las que cuenta el cirujano para cortar, manipular,
grapar o cauterizar tejidos u órganos durante la operación

Ludificación: Enfoque de desarrollo de procesos que busca mejorar el rendimiento y la

capacidad de aprendizaje de los involucrados por medio de analogías de juegos, buscando
que las personas asimilen mejor el contenido del proceso. En el caso de software, la
ludificación busca hacer similitudes a resultados e incentivos propios de los videojuegos para
hacer que los usuarios finales posean una motivación adicional al momento de utilizar un
sistema o una aplicación.

Dispositivo Háptico: Artefacto de Hardware que busca realizar una retroalimentación

sensorial con quien lo utiliza. En el contexto del entrenamiento quirúrgico, los dispositivos
hápticos pueden asociarse con la retroalimentación visual para simular la sensación de tocar
ciertos órganos.

Realidad Virtual: Espacio definido a través de una máquina o una interfaz programa que
genera o sintetiza entornos que poseen comportamientos, objetos y relaciones que definen un
mundo con reglas establecidas programáticamente. Por lo general, en la realidad virtual se
busca simular el mundo real, objetos y procesos del mismo para que la persona inmersa en
la virtualidad interactúe en este espacio, con estos objetos sujeto a los comportamientos
definidos, teniendo en cuenta que aspectos como físicas, formas, tamaños, deformaciones y
colores se pueden alterar en esta realidad para algún propósito en particular.

Simulador Virtual: Herramienta de software y hardware que simula una realidad virtual en
particular, generalmente orientado a recrear actividades del mundo real para que el usuario
sienta la experiencia de realizarla como si fuera en el mundo real.

Cauterización: Acción en la cirugía que consiste en quemar tejido, generalmente para cerrar
cortes o heridas.

Corte/Incisión: Acción en la cirugía que consiste en separar órganos o tejidos usando un

escalpelo o una tijera.

Manipulación: Acción en la cirugía que consiste en tomar un órgano o tejido, o al menos una
parte de este, para moverlo en el espacio.
8 Contexto del proyecto

8.1 Modelo de Ciclo de Vida

La metodología del trabajo de grado estará basada en el paradigma de Entrega Ágil
Disciplinada (DAD por sus siglas en inglés). Se escoge este ciclo de vida en primer lugar por
estar orientado al aprendizaje y capacitación (learning-oriented), lo cual permite poder
realizar una etapa de capacitación antes de desarrollar el sistema. También es un ciclo de vida
orientado a cumplimiento de objetivos de manera incremental e iterativa, además de hacer
una constante valoración de riesgos, lo cual resulta conveniente teniendo en cuenta la
incertidumbre que posee el proyecto (Amber, Scott W., 2013).

Se escoge esta metodología principalmente por la generación de soluciones consumibles,

definidas como elementos del sistema que pueden ser fácilmente entendidos, adoptados,
apoyados y con capacidad de evolución para alcanzar los objetivos trazados para el sistema
mismo (Amber, Scott W., 2013). Estas soluciones consumibles se orientan al usuario, por lo
cual se puede tener una retroalimentación temprana por parte de los interesados, teniendo
una participación activa por parte de médicos y estudiantes de cirugía.

Dado que plantea un ciclo de vida de manera iterativa e incremental, las actividades de la
fase metodológica se volverán a hacer, agregando contenidos y complejidad en cada uno de
los entregables, efectuando correcciones y modificaciones donde haga falta, buscando
cumplir progresivamente cada uno de los objetivos y los requerimientos definidos.

Para efectos de este proyecto se definen tres fases metodológicas que se ajustan a la
metodología de D.A.D, teniendo una serie de objetivos definidos para cada caso:

Ilustración 7. Proceso de Entrega Ágil Disciplinada. Tomado de (Amber, Scott W., 2013).

8.1.1 Fase metodológica 1: Fase de Exploración

En esta fase se trabajará sobre la revisión, selección, desarrollo e integración de las distintas
herramientas a utilizar para la realización del sistema, de manera exploratoria para entender
su funcionamiento y utilidad dentro del proyecto. Las actividades que se llevarán a cabo para
cumplir esta fase metodológica son:

1. Estudio a profundidad de las herramientas, librerías y motores gráficos a utilizar para

el desarrollo del prototipo.

2. Revisión de posibles alternativas

3. Desarrollo de experimentos con las herramientas para determinar sus ventajas y

desventajas

4. Selección del motor gráfico a utilizar.

5. Selección de la herramienta de desarrollo de entornos virtuales.

6. Selección de librerías para el uso de dispositivos hápticos.

7. Selección de librerías y herramientas de procesamiento de imágenes médicas

8. Desarrollo de ejercicios de prueba para el uso de cada herramienta y librería

escogida de manera individual.
 9. Desarrollo de ejercicios de prueba para el uso de las herramientas y librerías de
manera integrada como un solo sistema.

8.1.2 Fase metodológica 2: Fase de desarrollo del prototipo

Para esta fase se realizarán tareas de planeación, definición de los requerimientos, diseño,
implementación y pruebas del prototipo a desarrollar al igual que el diseño global del
sistema y las metodologías a usar para la implementación del simulador. Se resalta que en
esta etapa se realizan pruebas con el fin de asegurar el cumplimiento de requerimientos y
atributos de calidad, mas no para evaluar el impacto del prototipo, pues esto corresponde en
la fase metodológica 3.

Las actividades que se llevarán a cabo para cumplir esta fase metodológica son:

1. Planeación del proyecto y de la iteración actual: Ejecución de planes asociados al

SPMP
2. Recolección, Especificación y Priorización de requerimientos para la elaboración del
prototipo.
3. Diseño y arquitectura de los componentes principales del sistema para la elaboración
del prototipo.
4. Configuración de las librerías externas, módulos de interacción, el dispositivo háptico
y herramientas para el desarrollo del prototipo.
5. Implementación del prototipo basado en las funcionalidades, diseño y arquitectura
determinados anteriormente.
6. Pruebas de software sobre el prototipo, unitarias, integración y de aceptación.

8.1.3 Fase metodológica 3: Fase de Pruebas Final del Prototipo

En esta fase se realizará las distintas pruebas sobre el prototipo al igual que se hará una
versión a presentar al personal médico para poder tener su retroalimentación acerca del
sistema y generar las conclusiones finales basados en las respuestas recopiladas por quienes
prueban el prototipo.
Las actividades que se llevarán a cabo para cumplir esta fase metodológica son:

1. Pruebas de validación y desempeño del prototipo

2. Sesión de pruebas del prototipo desarrollado con el personal médico
3. Conclusiones acerca de la percepción del prototipo, evaluación en términos de
usabilidad y del cumplimiento de los requerimientos.

8.2 Análisis de Alternativas y Justificación

Dado que se han decidido una serie de prácticas y modelos de ciclos de vida con los cuales
se va a desarrollar el proyecto Simuscope, fue necesario considerar otros modelos de ciclos
de vida para poder evaluar su utilidad o no dentro del grupo de desarrollo. Los siguientes
ciclos de vida fueron revisados y descartados pues no se ajustaban a lo requerido por el grupo
de trabajo.

Teniendo en cuenta los diversos modelos de ciclo de vida existentes, se decide utilizar
parcialmente aspectos de 3 que se consideran que se acoplan a las necesidades y habilidades
del grupo de desarrollo del producto de software.
Modelo en Espiral

Este modelo es un modelo basado en la identificación, prevención y mitigación de riesgos.

También realiza división del proyecto en pequeñas tareas o actividades repartidas en cuatro
áreas o cuadrantes que se realizaran cada que se cumpla un ciclo (Hashmi & Baik)
(Sommervile, 2005) y se ven reflejado en el Gráfico 1:

Gráfico 1. Esquema de Ciclo de Vida en Espiral, Tomado de (Hashmi & Baik)

1. Determinar Objetivos; identificar restricciones del proceso y del producto; identificar

riesgos y planeación de alternativas.
2. Evaluar y reducir los riesgos, evaluar alternativas para mitigar los riesgos, lo cual
puede incluir desarrollo de prototipos para mitigar el riesgo de requerimientos
inconclusos o dudosos. (Sommervile, 2005)
3. Validación prototipos, artefactos o elementos parciales del sistema asociados a los
riesgos.
4. Planeación de la siguiente fase o iteración, implicando “una revisión que involucra
los desarrolladores, clientes y usuarios” (Bruegge & Dutoit , 2002)

Si bien la división de trabajo mediante ciclos podría ajustarse a las fases metodológicas
definidas anteriormente, la metodología de Entrega Ágil Disciplinada resulta más viable para
un proyecto de carácter investigativo al manejar una etapa de concepción o inicio donde se
pueden definir de manera general las necesidades y problemáticas a tratar para luego
enfocarse en los mecanismos para solucionarla e ir actualizando elementos como
requerimientos, historias de usuario, arquitectura, diseño, entre otros. Varios de los aspectos
más importantes del modelo en espiral están inmersos ya en el ciclo de vida de D.A.D.

Modelo Rational Unified Process (RUP)

El Rational Unified Process (RUP) es un modelo que tiene una forma disciplinada de asignar
tareas y responsabilidades en una empresa de desarrollo en donde describe una clase de los
procesos que son iterativos e incrementales. Los procesos de RUP se centran en estimar tareas
y horarios del plan midiendo la velocidad de las iteraciones. La principal ventaja de RUP es
que se basa en las mejores prácticas que han sido probadas con anterioridad.

Dentro de las actividades más características del ciclo de vida de RUP se encuentran las
siguientes (Larman, Iterative, Evolutionary and Agile Models, 2004) (Rational - The
Software Development Company, 1998):

 Levantamiento exhaustivo de requerimientos.

 Detectar defectos en las fases iniciales.
 Reducir el número de cambios tanto como sea posible.
 Realizar el Análisis y diseño, tan completo como sea posible.
 Diseño genérico, intenta anticiparse a futuras necesidades.

Si bien en este caso se dividen el ciclo de vida en cuatro fases muy similares a las de D.A.D.
(Rational - The Software Development Company, 1998), en D.A.D. la fase de Desarrollo
evita cierta confusión que se presenta entre las fases de RUP de elaboración y construcción,
enfocando las actividades una vez se ha iniciado el proyecto en la elaboración de cada
solución consumible, aspecto que RUP no trata al menos de manera explícita. El hecho de
hacer una aproximación de soluciones consumibles que van creciendo iteración a iteración
permite entre otras mitigar riesgos de manera temprana, tener respaldos de versiones que
guardan funcionalidades que otras podrían no tener y al estar orientado más al cliente permite
recibir rápidamente retroalimentaciones tempranas de los resultados, teniendo en cuenta que
al ser un proyecto de un área del conocimiento ajena al equipo de desarrollo implica un riesgo
adicional.

Ilustración 8. Esquema General de RUP tomado de (Zaragoza, s.f.)

Modelo en Cascada:

El modelo en cascada consiste en desarrollar fases secuencialmente, describiendo las etapas

fundamentales para el desarrollo de software (Sommervile, 2005) (Bruegge & Dutoit , 2002):

 Análisis y definición de requerimientos: Definir en detalle las funcionalidades y

aspectos esenciales que debe tener el sistema.
 Diseño del sistema: Donde se describe la estructura del sistema y se hace una
abstracción conceptual del mismo.
 Implementación y pruebas: Donde se realiza el software como un conjunto de
unidades de programas.
 Integración: Todos los módulos se unen como un sistema único y se prueba como una
sola unidad para asegurar que cumpla los requerimientos.
 Mantenimiento: lograr la permanencia del sistema a través del tiempo y corrección
de errores no descubiertos anteriormente.

El esquema de cascada obliga que no se pueda avanzar de una etapa sin que se haya
completado en su totalidad la etapa previa, pues se considera como una secuencia estricta de
análisis de requerimientos, diseño y fases de desarrollo (Larman & Basili, Iterative and
Incremental Development: A Brief Story, 2003). Esto implica que una vez finalizada una
etapa, no se puede retroceder y es poco flexible en el momento de tratar con cambios o errores
inesperados que no fueron tenidos en cuenta en etapas anteriores.

Modelo en V

El Modelo en V es una variante del modelo en cascada que “hace explícita la dependencia
entre actividades de desarrollo y las de verificación [...] hace explícita la noción de nivel de
abstracción”. (Bruegge & Dutoit , 2002)

Pese a tener varias etapas de validación, posee la misma falencia del esquema en cascada de
no poder retroceder en el proceso, pues “asumen que después de que una actividad se termina
y se revisa, el producto de trabajo asociado puede tomarse como línea base” (Bruegge &

Dutoit , 2002), asunciones que sólo servirán si hay completa certeza que los requerimientos
no se van a ver modificados ni corregidos durante el resto de etapas.

En la ilustración 9, se ve el esquema del modelo en V, donde cada actividad anterior a la

implementación se ve verificada y revisada por las actividades posteriores a la
implementación, haciendo pruebas que aumentan en su nivel de complejidad. Sin embargo,
Ilustración 9. Esquema de Modelo en V, tomado de (Bruegge & Dutoit , 2002)
sigue teniendo un esquema demasiado rígido como el de cascada, pues en caso de encontrarse
un fallo posterior a la implementación, habría que retomar hasta las etapas iniciales.

Modelo de diente de sierra:

“El modelo de diente de sierra muestra las percepciones del sistema por parte del usuario y
el desarrollador de software en diferentes niveles de abstracción a lo largo del tiempo”.
(Bruegge & Dutoit , 2002)

El principal problema que se pretende atacar con este ciclo de vida es que los requerimientos
de software son normalmente dinámicos y podrían cambiar en forma drástica durante todo el
desarrollo del proyecto y si se siguen otros ciclos de vida como cascada o modelo en V donde
la primera vez que el usuario interactúa con el sistema es solo hasta el final del proyecto se
corre el gran riesgo de que lo que se le entrega al usuario no es lo que él esperaba (no se
satisfacen los requerimientos) ya que los usuarios y los implementadores tienen diferentes
maneras de comprender los sistemas de software.

Para lograr esto el modelo dientes de sierra incluye una serie de actividades que usualmente
están enfocadas a presentar prototipos del estado actual del sistema al usuario con el fin de
que este último pueda evaluar cada prototipo, informar a los desarrolladores que se podría
cambiar, agregar o que definitivamente se debe eliminar del prototipo ya que no es lo que se
quiere del sistema final. Esto con el fin de corregir a tiempo problemas de requerimientos
que cambian con el tiempo, logrando así una retroalimentación por parte del usuario en las
distintas etapas del desarrollo del proyecto y haciendo que el cliente se involucre en su nivel
de abstracción obteniendo un nivel de confianza mayor en cuanto a que el sistema final se
parezca a lo que el usuario quiere. De aquí obtiene este ciclo de vida su nombre ya que cada
demostración de prototipo al cliente da como resultado un “diente”. En el Gráfico 7. Se puede
ver este esquema de dientes y la división del nivel de abstracción del desarrollador y el
cliente.

Durante el desarrollo del sistema el usuario permanece en el nivel de los requerimientos, qué
quiere del sistema y cómo lo quiere, mientras que los desarrolladores se enfocan en la
factibilidad, si es posible lograr lo que el usuario quiere y como sería posible lograrlo.
Entonces al inicio del proyecto los desarrolladores y el usuario están en el mismo nivel de
abstracción, es decir, se acuerdan los requerimientos iniciales del sistema; luego los
desarrolladores basándose en estos requerimientos elaboran un diseño tentativo del sistema
el cual implementan en un prototipo, muy sencillo si se quiere, que podrían ser simples
secuencia de las pantallas desde el punto de vista de los casos de uso, se muestra este
prototipo al usuario quien evaluará si satisface los requerimientos inicialmente acordados.

Ilustración 10. Esquema de Diente de Sierra, tomado de (Bruegge & Dutoit , 2002)

De este modelo no se tomará ninguna característica para Simuscope, puesto que aunque tiene
una buena comunicación con el cliente en cuanto a sus requerimientos, mostrándole los
prototipos cada vez que estén para que este pueda evaluar, se encuentra que el desarrollo de
prototipos incrementales y en un esquema iterativo resulta mucho mejor para el control de
riesgos y calidad.

Modelo de diente de tiburón:

“El modelo de diente de tiburón es un refinamiento del modelo de diente de sierra. Además
de las demostraciones al cliente también se introducen revisiones y demostraciones para la
gerencia.” (Bruegge & Dutoit , 2002)

Este modelo no solo se centra en los comentarios y revisiones por parte del cliente sino que
también tiene en cuenta los comentarios y observaciones por parte de la gerencia o quien
dirija el proyecto. Aquí existen dos tipos de dientes lo “grandes” enfocados hacia el usuario
y los “pequeños” enfocados al director del proyecto (gerencia). En el Gráfico 8, se puede ver
como se ven el nivel de gerencia y el nivel de cliente donde el primero genera unos dientes
más pequeños a comparación de los que hay cuando se interactúa con el cliente.

Ilustración 11. . Esquema de Modelo de Diente de Tiburón, tomado de (Bruegge & Dutoit , 2002)

Dado que es una variante más elaborada del diente de sierra, se descarta para Simuscope
Social. Primero, ya que se opta por usar un esquema soluciones consumibles en las que se
pueda ir evaluando avances reales del prototipo final. Segundo, dado que no hay roles de
carácter gerencial al no ser un producto final que se lleve al mercado sino un prototipo
orientado a resultados de investigación para evaluar la viabilidad de un sistema en un
contexto determinado, este modelo no se ajustaría a las necesidades del proyecto..

Desarrollo Evolutivo

“El desarrollo evolutivo se basa en la idea de desarrollar una implementación inicial,

exponiéndola a los comentarios del usuario y refinándola a través de las diferentes versiones
hasta que se desarrolla un sistema adecuado” (Sommervile, 2005)

Existen dos tipos de desarrollo evolutivo:

 Desarrollo Exploratorio: Se desarrolla primero las partes del sistema que se

comprenden mejor y a continuación el sistema evoluciona con nuevos atributos
propuestos por el cliente, es decir, las partes del sistema que no se comprenden a la
perfección. El objetivo principal es el de trabajar con el cliente investigando los
requerimientos que desea y entregar con base en ello un sistema que cumpla estos
requerimientos establecidos. (Sommervile, 2005) (SoftPanorama, s.f.)
 Prototipos desechables: Este prototipo se centra inicialmente con los requerimientos
menos claros del cliente para luego si desarrollar los requerimientos que son claros,
con el objetivo de desarrollar una definición mejorada de los requerimientos del
sistema. (SoftPanorama, s.f.)

El desarrollo evolutivo tiene una gran ventaja la cual es que la especificación se desarrolla
de forma creciente. Sin embargo, posee dos grandes problemas:

 No hay un proceso visible: Al realizar entregas regularmente para medir el progreso

no es rentable producir documentos que reflejen cada versión del sistema.
 Generalmente poseen una estructura deficiente

Los cambios corrompen la estructura del software, es decir cada vez que se le quiera
introducir un cambio será con el tiempo una tarea más difícil y costosa. El desarrollo
evolutivo para sistemas de tamaño medio y pequeño es el mejor. Pero, entre más grande sea
el tamaño del sistema y además, entre mayor sea el periodo de vida, surgirán problemas con
este modelo de desarrollo.

Para el contexto de Simuscope, se decide no utilizar este modelo de ciclo de vida, pues ya
habiendo entendido claramente el objetivo del prototipo y siendo aprobado desde la
Propuesta de Trabajo de grado, se ve poco útil desarrollar un modelo a base de fallos como
el de prototipos desechables, cuando se tiene el desarrollo de soluciones consumibles que
aseguran que se cumplan una serie de requerimientos y comportamientos requeridos por parte
de los usuarios e interesados finales.

Extreme Programming (XP)

Es el más destacado de los métodos ágiles de desarrollo de software, centrada en potenciar

las relaciones interpersonales como clave para el éxito en desarrollo de software,
promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores,
y propiciando un buen clima de trabajo. (Wells, 2013)

XP se basa en realimentación continua entre el cliente y el equipo de desarrollo,

comunicación fluida entre todos los participantes, simplicidad en las soluciones
implementadas y coraje para enfrentar los cambios. XP se considera adecuada para proyectos
con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo técnico.
(Universidad Union Bolivariana, s.f.)

Las principales prácticas en programación extrema son: (Wells, 2013)

Planeación:

 Historias de usuario
 Plan de entregas
 Plan de iteraciones
 Reuniones diarias cara a cara

Diseño:

 Simplicidad
 Soluciones “Spike” (pequeños programas de prueba)
 Recodificación y reutilización de código.
 Metáforas

Desarrollo de código

 Disponibilidad del cliente

 Uso de estándares
 Programación dirigida por las pruebas
 Programación en pares
 Ritmo sostenido

Pruebas

 Pruebas unitarias
 Detección y corrección de errores
 Pruebas de aceptación

XP por ser una metodología ágil, utiliza como sustenta el Manifiesto de los métodos ágiles
(Agile Alliance, 2015), donde las actividades se enfocan más en la producción de
funcionalidades y código, entregando software funcional constantemente a los clientes.
Adicionalmente, la comunicación será cara a cara diariamente para trabajar desde los
requerimientos hasta el código (Wells, 2013).

Estas prácticas donde requieren iteraciones muy rápidas y con una interacción constante con
el cliente hacen que esta metodología ágil no pueda ser practicada, teniendo en cuenta que la
complejidad técnica y los componentes investigativos del proyecto requieren de la búsqueda
de información en el campo de la medicina así como en el desarrollo de simulación médica,
aspectos que requieren un desarrollo más detallado.

SCRUM

SCRUM hace parte de los modelos de ciclo de vida de desarrollo ágil, el cual pone en énfasis
el desarrollo y construcción del software funcional, más allá de centrarse en las robustas
especificaciones como se podría ver en un modelo como el de cascada.

Ilustración 12. Esquema de SCRUM, tomado de (Deemer, Benefield, & Larman)

“Scrum es un marco de trabajo iterativo e incremental para el desarrollo de proyectos,

productos y aplicaciones. Estructura el desarrollo en ciclos de trabajo llamados Sprints. Son
iteraciones de 1 a 4 semanas, y se van sucediendo una detrás de otra. […]Todos los días el
equipo se reúne brevemente para informar del progreso, y actualizan unas gráficas sencillas
que les orientan sobre el trabajo restante.” (Deemer, Benefield, & Larman)

En la ilustración 12 se muestra el esquema general de SCRUM, donde el elemento principal

del esquema son los Sprints que son un conjunto de actividades a realizar de 1 a 4 semanas
por el equipo y vigiladas diariamente por el Scrum Master y después de cada Sprint se valida
el cumplimiento de cada incremento o potencial entregable. El Scrum Master es el único de
los miembros que lidia con los inconvenientes del mundo exterior, es decir, con los clientes.

Aunque SCRUM ofrece un marco de trabajo para el desarrollo de software bastante

organizado, permitiendo retroalimentar información constantemente y generar desarrollo
incremental constante durante cada Sprint, el hecho de requerir una revisión demasiado
detallada y requiriendo realizar una reunión diaria sobre el estado de las tareas asignadas
durante el tiempo del sprint convierte en este modelo difícil de practicar por parte del equipo
de trabajo al solo consistir de dos personas que no cubrirían por completo los roles requeridos
para este ciclo de vida, así como la necesidad de generar una serie de entregables y
documentos intermedios que terminarían por repercutir en el tiempo de desarrollo del
prototipo y la elaboración de la documentación que realmente es relevante en el contexto el
proyecto de grado.

8.3 Lenguajes y Herramientas

8.3.1 Herramientas de Documentación y Control de Actividades

Para la gestión y documentación del proyecto, así como otras herramientas para soportar
edición y estilizado de imágenes, se hace necesario utilizar gran variedad de herramientas
para controlar la organización de los documentos importantes y su correspondiente
actualización, por parte de los responsables para mantener al día el calendario del proyecto,
además de herramientas de apoyo para la ejecución de actividades.

A través de Google Forms: Encuestas y formularios fáciles de crear para todo el mundo
(Google Inc., s.f.), esta aplicación vinculada con la cuenta de correo en Gmail (Google Inc.,
s.f.), se busca recopilar encuestas y datos relevantes en la fase de pruebas finales de quienes
hagan uso de la aplicación final, a través de una heurística de evaluación.

Para la organización de tareas, el grupo de trabajo hará uso de Asana (Asana, s.f.) , donde
estarán consignadas tareas para los miembros del equipo y podrán ser revisados por
cualquiera de los miembros de manera general. Junto con Asana, se va a utilizar Instagantt
para los esquemas de planeación de procesos, tareas y actividades del proyecto, la cual se
integra con las actividades asignadas dentro de Asana, permitiendo una completa integración
entre ambas herramientas para tener una mejor visión del calendario y duración de las
actividades. (Asana, 2015). Junto con Asana se usa Trello como complemento para asignar
tareas mucho más puntuales dentro de cada iteración, determinando el flujo y avance de las
mismas, facilitando el seguimiento de los avances por cada iteración.

Todos los documentos, tanto presentaciones como plantillas pertinentes para el grupo, serán
realizados en Microsoft Office (Versión 2010 en adelante) (Microsoft, s.f.) o Google Docs
(editor online) (Google Inc., s.f.) , herramientas que nos permite desarrollar de manera
estética y uniforme, cumpliendo con las configuraciones determinadas, además de un manejo
concurrente en el caso de la última.

8.3.2. Herramientas de Análisis, Diseño y Desarrollo

Las herramientas que elegimos para el desarrollo del proyecto son aquellas que permitan el
desarrollo de actividades de análisis, diseño e implementación de un producto de software:

Enterprise Architect (versión 9.0.0.908 en adelante): Es una herramienta para diseño y

modelado basado en el lenguaje UML (lenguaje unificado de modelado) (Rumbaugh, Booch,
& Jacobson, 2000), fue desarrollada por la empresa Sparx Systems. Con un gran conjunto de
características como trazabilidad y buen rendimiento (Sparx Systems, s.f.), permite construir
modelos que son necesarios para el desarrollo de nuevos sistemas como el de SnoutPoint.
Adicionalmente permite en la construcción de modelos generar archivos con su respectiva
documentación (Sparx Systems, s.f.).

El manejo de esta herramienta le corresponderá al equipo de análisis y diseño. Se escoge esta

herramienta debido a la experiencia adquirida en asignaturas previas, lo que implica que hay
un entorno familiarizado de trabajo. Además, dichas habilidades adquiridas por los miembros
del equipo a lo largo de la carrera permiten explotar la herramienta para un manejo eficiente
de la información involucrada en el desarrollo de este proyecto.

Bizagi process modeler (versión 2.9) (Bizagi, 2015): Es un software gratuito que sirve como
modelador de procesos de negocio, fue desarrollado y ha sido distribuido por la compañía
Bizagi Limited. Entre las características de esta herramienta están el poder realizar diagramas
de procesos de tipo BPMN, además de poder documentarlos y simular su funcionalidad,
además de permitir generar esquemas de procesos y actividades de una manera más
entendible para el equipo de desarrollo. Esta herramienta fue elegida ya que cuenta con
elementos útiles para ajustarse a las necesidades del proyecto y del producto que estamos
desarrollando.

Además, el equipo de análisis y diseño ya tiene experiencia con este programa desde cursos
anteriores, ya que anteriormente se vio involucrado en el modelado de procesos; visto en el
curso Sistemas de Información, donde se aprendió sobre la importancia de la buena
definición de los procesos de impacto en un proyecto y/o negocio, todo esto modelado a
través de prácticas funcionalidades que son brindadas por esta herramienta.

Unreal Engine 4 (Versión 4.12.5): Suite completa de desarrollo de juegos, hecha por
desarrolladores de juegos para desarrolladores de juegos, permitiendo crear juegos desde 2D,
pasando por videojuegos en 3D para consolas hasta sistemas de realidad virtual. Programable
en C++ y con ayudas visuales para el flujo de comportamientos e información mediante
Blueprints. Liberado como software libre a mediados de 2016, resulta una solución para el
desarrollo de sistemas de realidad virtual a bajo costo al ser gratuito, mientras se cree una
cuenta en Epic Games y se cuente con una cuenta de GitHub.

Visual Studio Community (versión 2015): Un entorno de desarrollo de aplicaciones y

soluciones de software en Windows, para C++ y C#, además de contar con librerías y
aditamentos que le permiten trabajar sobre Unreal Engine 4, facilitando la compilación y la
depuración de codigo, así como la interpretación de Blueprints a código fuente de C++.

Visual Studio Community (versión 2013):

Open Haptics SDK:

Blender (versión 2.7.0): Herramienta gratuita y de código abierto de modelado de objetos

tridimensionales, dándole soporte a procesos de rigging, animación, simulación, renderizado,
composiciones y soporte a diversos formatos de mallas tridimensionales.

GitHub (GitHub Enterprise, 2015): Es una plataforma de sistema de control de versiones

distribuido que ofrece el almacenamiento de código y documento mediante un repositorio
basado en Git. Gracias a que GitHub no posee limitantes en la cantidad de colaboradores,
permite que los 7 miembros de SnoutPoint Networks puedan subir, bajar, eliminar o
actualizar elementos al repositorio del grupo. Se elige un esquema distribuido por la facilidad
que tiene de manejar ramificaciones, además de hacer que todos los miembros tengan una
copia total del repositorio, lo cual da un respaldo en caso de fallas o si no hay internet. (Git,
2014)

Amazon Drive: Dado que Github tiene limitantes importantes en cuando al máximo de
memoria soportada por archivo, se determina que para guardar los archivos más pesados y
que no puedan ser almacenados aquí, sean puestos en este repositorio en la nube. También
se consideró que cada solución consumible fuera subida aquí como soporte de
versionamiento adicional a Github.

8.4 Plan de Aceptación del Producto

Para cualquier proyecto de ingeniería es necesario seguir ciertas actividades, dependiendo la
complejidad, algunas de las actividades que incluyen: (Sommervile, 2005)

 Obtención de requerimientos
 Análisis
 Diseño del Sistema
 Diseño de objetos
 Implementación

Adicionalmente, teniendo en cuenta los parámetros del Proyecto de Grado, los aspectos de
aceptación requieren la elaboración del documento final de la memoria de trabajo de grado,
así como el prototipo funcional del sistema desarrollado, en este caso, Simuscope. Los
detalles del desarrollo después de la aprobación de la propuesta de grado también son
necesarios para constatar el desarrollo formal del ciclo de vida y las actividades contenidas
en la propuesta como resultado final de un proceso forma de desarrollo de software propio
de la ingeniería de sistemas.

La aprobación del prototipo y lo que representa en primer lugar dependerá en gran medida
de las experiencias, comentarios y resultados obtenidos por parte de quienes prueben el
prototipo final, pues son el insumo principal que define el impacto que tiene el sistema,
además de ser los datos con los cuales se realiza la interpretación de las conclusiones sobre
el mismo. Las respuestas obtenidas mediante una heurística de evaluación a manera de
encuesta determinaran el grado de éxito en cada uno de los componentes macro que definen
la solución (Retroalimentación Sensorial, Simulación Virtual, Simulación de
Colecistectomía, Retroalimentación Visual, Ludificación e Interfaces naturales).

La aprobación del producto también dependerá tanto del Tutor de Trabajo de Grado asi como
los jurados del mismo, pues son quienes otorgan la calificación final del proyecto,
determinando el grado de aprobación o no del sistema y los resultados que el proyecto y la
investigación han arrojado y cómo estos se han interpretado.

8.5 Organización del Proyecto y Comunicación

8.5.1 Interfaces Externas

Se tiene en cuenta que para el proyecto de Grado existen personas asociadas al mismo sean
interlocutores o interesados en el mismo. En el caso de este proyecto se encuentra el asesor
del Trabajo de Grado, los jurados del trabajo de grado y el personal de la universidad.

Asesor de Trabajo de Grado

El asesor de este trabajo de grado es el profesor Leonardo Florez Valencia, profesor del
departamento de Ingeniería de Sistemas de la Pontificia Universidad Javeriana. Como Tutor
del proyecto de grado nos brinda la retroalimentación necesaria semanalmente de las
actividades realizadas durante el desarrollo del prototipo, así como dar recomendaciones o
sugerencias sobre el proceso. Adicionalmente es el encargado de dar la calificación
correspondiente al 60% del trabajo de grado, por lo cual también cumple un rol similar a la
de un cliente final de todo el proyecto, incluyendo el prototipo de Simuscope y sus resultados.

Jurados de Trabajo de Grado

Los jurados del trabajo de grado son los encargados de evaluar desde una perspectiva más
externa todo el proyecto de grado, teniendo en cuenta que algunos no necesariamente son
expertos en el área de evaluación del sistema, por lo cual todas las ideas y conceptos
expuestos a ellos deben ser lo más entendibles posibles sin entrar en tecnicismos mayores.
Ellos por su parte otorgan la calificación del 40% restante del trabajo de grado

Usuarios Potenciales

El proyecto de grado está orientado a usuarios que estén interesados en el entrenamiento

quirúrgico en laparoscopia, así como centros de salud, universidades y hospitales que deseen
capacitar a sus usuarios en esta técnica de cirugía mínimamente invasiva. También en este
grupo se pueden encontrar estudiantes de otras carreras a nivel de pregrado, maestría o
doctorado que puedan estar interesado en el potencial de Simuscope para otros desarrollos o
para extender su utilidad a otros contextos.

Personal de la universidad

Para avanzar en las actividades del proyecto, concertar reuniones y realizar pruebas en los
equipos de la Universidad Javeriana, es necesaria la intermediación de los encargados de las
bibliotecas y las salas de cómputo dentro de la Pontificia Universidad Javeriana.

Teniendo en cuenta que el dispositivo Háptico y la sala de programación de Takina se

encuentran dentro del Edificio Ático, el cual funciona como una entidad externa a la
Universidad, requiere la interacción con los encargados de estas salas tanto a nivel de Ático
como a nivel del departamento de Ingeniería de sistemas, principalmente de los ingenieros
Hernando Hurtado y Cesar Bustacara.

8.5.2 Organigrama
Para el contexto de este proyecto que se compone de dos personas, resulta un tanto excesivo
hacer una asignación de roles teniendo en cuenta que las habilidades y conocimiento de
ambos se encuentra a la par, el contexto del proyecto implica aspectos de investigación en
un área del conocimiento que es ajena a ambos como es la parte médica o el desarrollo de
entornos virtuales. En ese orden de ideas, ambos miembros del equipo de trabajo están al
mismo nivel en términos de jerarquía, desarrollando ambos a la par actividades tanto de
requerimientos, documentación, diseño, programación y pruebas, haciendo revisiones
cruzadas cuando haga falta.

En cuanto a canales de comunicación se definen diferentes formas de efectuar la

comunicación dentro del grupo, cada uno determinado propósito para el desarrollo de las
diferentes actividades dentro del grupo de trabajo:

 Sesiones de Trabajo Lunes, Miércoles y Sábados: Presencialmente se busca

poder trabajar presencialmente y en las salas de la universidad durante estos días
mínimo. El trabajo independiente se realizaría en los otros días de la semana,
aunque en los días de trabajo presencial se trata también de compartir soluciones o
 inconvenientes de manera rápida con el fin de agilizar el desarrollo del sistema.
También resulta conveniente que las reuniones con el tutor de trabajo de grado
sean los miércoles en la tarde.
 Notificaciones de tareas en Asana/Trello: Como medio para constatar y dejar un
registro adicional de las tareas y actividades a realizar de cada miembro del grupo,
se utiliza Asana (ver Lenguajes y Herramientas) para generar recordatorios y
notificaciones a cada persona, pues cada que se asigna una actividad, la persona a
quien se le asigna recibe un mensaje por correo electrónico dando aviso de esta.
 Chat de Facebook: Como un canal más informal dado que el equipo de trabajo
son solo dos personas, por lo cual no se requiere de canales o filtros por roles. En
este chat se comentan las cosas que no se hayan alcanzado a comentar en los días
de actividad presencial

Aunque haya una asignación clara de actividades, no significa que cada persona estará
haciendo lo suyo de manera aislada. Teniendo en cuenta el modelo de trabajo de Bazar
desarrollada por Torvalds y luego descrita por Raymond (Raymond, 2010), donde el grupo
está “colmado de individuos con propósitos y enfoques dispares” (Raymond, 2010), por lo
cual se busca un desarrollo orientado más a la colaboración y revisiones cruzadas donde
ambos miembros del equipo estarán desarrollando actividades similares y solucionando
dudas entre sí.
9. Administración del Proyecto

9.1 Inicio del proyecto

Una vez se haya aprobado la propuesta de trabajo de grado se dará inicio al proyecto tal y
como se ha contemplado mediante el ciclo de vida de este proyecto, así como en la propuesta
de trabajo de grado, iniciando con la fase de concepción del proyecto.

9.1.1 Investigación de herramientas en fase de Concepción

Como primer punto a tratar es la de buscar las diferentes herramientas existentes para
conformar un entorno de desarrollo que tenga en cuenta dispositivos hápticos, entornos
virtuales, visualización tridimensional, soporte para mallas 3D provenientes de VTK, manejo
de físicas o soporte de librerías de físicas y deformaciones.

También por aspectos de programación orientada a objetos y de rendimiento se busca que el

desarrollo sea en C++, además de buscar darle soporte en sistemas operativos distintos a los
Windows, en lugar de C# que es una solución que queda acotada a Windows al menos en el
desarrollo y requiere otros mecanismos para darle soporte a Linux por ejemplo.

Se hace un compromiso a través de este documento en cuanto a la capacitarse con el fin para
implementar el prototipo. Esto incluye herramientas de capacitación como cursos, tutoriales,
lecturas y videos que permitan entender los lenguajes de programación, herramientas en las
que se desarrollan y ejercicios que permitan poner en práctica los conocimientos adquiridos,
enfocándose en las utilidades que le puedan aportar valor al producto final, enfocándose en
la consecución de objetivos a través del proceso de desarrollo de software.
9.1.2 Infraestructura
En cuanto a la infraestructura, cabe aclarar que a nivel de equipos se tiene la siguiente
estructura de la ilustración 13:

Pontificia
Hogar de cada Universidad
Integrante Simuscope Javeriana
Sala Takina

Ilustración 13. Esquema de infraestructura del Proyecto de Simuscope

Hogar de cada Integrante: dado que la uno de los canales de comunicación se realiza
mediante un chat, que los archivos se gestionan mediante repositorios remotos y se
puede trabajar en paralelo con aplicaciones como Google Docs, se considera entonces
la casa de cada miembro como parte de la infraestructura.
Pontificia Universidad Javeriana: teniendo en cuenta que gran parte del trabajo,
control, gestión y planeación se realiza en las reuniones semanales, se considera la
Universidad como parte de la infraestructura del equipo al ser parte de los espacios
donde se encuentran los equipos para el desarrollo del proyecto, además de ser el
espacio donde se encuentran tanto los miembros del equipo como las interfaces
externas del proyecto.
 9.2 Planes de Trabajo del Proyecto

9.2.1 Descomposición de Actividades

Para la estructura de descomposición de tareas o WBS (IEEE Standards Board, 2010) (IEEE
Standards Board, 2009) (Project Management Docs, s.f.) , se determina que se van a realizar
5 incrementos que pueden durar de 3, aunque si se determina que se han presentado retrasos
importantes, se determina que se extienda al menos una semana más a esta iteración, que si
bien esto repercute en la etapa de pruebas, se requiere para asegurar el alcance de los
objetivos finales.

Como se ha mencionado en el ciclo de vida en Entrega Ágil Disciplinada, en cada incremento

efectuará tareas repetitivas donde cada uno de los entregables finales determinados (ver
Modelo de Ciclo de Vida), además de ejecutar actividades de evaluación y valoración de
riesgos, definición de alternativas, revisiones de los entregables, integración de prototipos al
sistema total y retroalimentación con el asesor de trabajo de grado. Sin embargo, se definen
una serie de actividades clave para cada incremento, al existir una dependencia entre las
actividades, dado que se requiere realizar la del incremento actual para avanzar al siguiente.

Primer Incremento (23 de Julio)

Definición final de Herramientas a utilizar Configuración de entorno de desarrollo

Segundo Incremento (11 de Agosto)

Caracterización de Gestos y Avance en los entregables y la Evaluación de Motores fisicos y
laparoscopia memoria de trabajo de grado deformaciones

Tercer Incremento (1 de Septiembre)

Simulación visual de la cirugía y mapeo de gestos. Integracion de motores fisicos

Cuarto Incremento (26 de Septiembre)

Integración con el dispositivo háptico Implementación de elementos de luficación

Quinto Incremento(15 de Octubre)

Implementación completa de la simulación virtual Retroalimentación Háptica
10 . Monitoreo y Control del Proyecto

10.1 Administración de Requerimientos

Objetivo

La administración de Requerimientos se realiza para un producto en particular, en este caso

será Simuscope como el prototipo de un simulador virtual de entrenamiento médico con
técnicas de ludificación (IEEE Standards Board, 1998); con el objetivo de saber cómo se
crearán los requerimientos, saber quién lo administrará y finalmente, cómo se administrará a
lo largo del proyecto. “Los requerimientos son una especificación de lo que debe ser
implementado. Estos son descripciones de cómo el sistema se debe comportar, de las
propiedades y atributos del mismo. Deben ser una restricción del proceso de desarrollo del
sistema” (Sommervile, 2005)

Encargados

El equipo de desarrollo estará encargado de la administración de requerimientos, teniendo en

cuenta que la perspectiva de uno de los integrantes del equipo puede ser distinta a la del otro,
se pueden encontrar requerimientos diversos entre ambos. Se tiene en cuenta que el proceso
de gestión de requerimientos requiere de varias actividades que se irán haciendo iteración a
iteración.

1. Planeación.
2. Levantamiento de requerimientos.
3. Especificación de requerimientos.
4. Validación y Verificación de requerimientos.

Frecuencia

Dentro de la administración de requerimientos, cada etapa especificada en el párrafo anterior

tiene una frecuencia definida, puesto que algunas actividades son de carácter iterativo y
requieren ser realizadas en repetidas ocasiones, comparado con otras que solo se realizan una
sola vez, como es el caso de planeación. Para levantamiento y especificación se evalúa cada
inicio de iteración los requerimientos actuales, teniendo en cuenta la experiencia obtenida en
la pasada iteración, con el fin de priorizar adecuadamente los existentes, eliminar los que no
sean necesarios o levantar otros que ahora sean relevantes y que probablemente antes no
fueran tan evidentes.

Puesta en Marcha

La administración de requerimientos se ejecutará en el momento en que se deba contemplar

el documento de especificación de requerimientos de software (SRS), es decir a partir del
segundo incremento, por lo tanto, cualquier actividad relacionada con los requerimientos
deberá remontarse al documento SRS. Como consecuencia, los requerimientos tienen un
orden específico para su creación y ejecución en el documento SRS que es el siguiente:

1. Planeación: La planeación tiene como objetivo determinar cuáles son las actividades
a realizar para realizar un proceso de ingeniería de requerimientos.
2. Levantamiento: Tiene como objetivo determinar la manera de cómo se construirán
los requerimientos del proyecto.
3. Especificación: Tiene como objetivo dejar explícita todas las características del
requerimiento para que pueda ser utilizado y comprendido por todo el equipo de
desarrollo, facilitar su ubicación y su impacto en el proyecto y artefactos
desarrollados dentro de este, además de llevar un control y seguimiento de su avance.
4. Validación: Tiene como objetivo asegurarse de que se posee el requerimiento
correcto ajustándose al mundo real, con su proceso definido.
5. Verificación: El objetivo es entender si está solucionando de manera correcta el
problema y se hace de manera secuencial e iterativa.

Cabe resaltar que en la especificación de requerimientos de software (SRS) se detalla más a

fondo en que consiste cada ítem anteriormente nombrado (Ver Anexos: SRS) pero además,
que para cada requerimiento se debe o debió realizar cada uno de los puntos anteriores
dependiendo del estado del requerimiento.

Finalmente es válido aclarar que para que un requerimiento se haya levantado y especificado
debió cumplir con ciertas características como las siguientes mencionadas:
  Atómico  Verificable
 Correctos  Modificable
 No Ambiguos  Trazable
 Completos  Asociados a Versión
 Consistente  No Redundante
 Importancia  Precisos

10.2 Monitoreo y Control de Progreso

Para lograr el resultado deseado en un proyecto y la satisfacción del cliente se debe efectuar
un seguimiento durante todo el desarrollo del proyecto. Para no perder el objetivo principal
del proyecto, es muy importante hacer un monitoreo y un control de la solución consumible
que se va desarrollando en cada iteración, determinando si se está cumpliendo con los
requerimientos especificados, evaluar los problemas que se presenten y que tanto estos
afectan en términos de tiempo y esfuerzo. (Ver Modelo de Ciclo de vida).

Monitoreo de progreso se refiere a realizar verificaciones constantes para asegurarse que el

avance del proyecto va de acuerdo a lo planificado realizándose de manera regular y
consistente, logrando así poder saber los diferentes aspectos del proyecto. Por otro lado,
Control de progreso se refiere a realizar acciones correctivas cuando algo no este andado
bien en el proyecto, tomando decisiones que generalmente se encuentran asociadas a la
gestión de riesgos del proyecto.

En cada una de las iteraciones se realizará un monitoreo y control en los aspectos importantes
del proyecto:

o Control del tiempo utilizado para de desarrollo de tareas asignadas: Teniendo en

cuenta que en cada iteración se realizan tareas en general repetitivas propias del ciclo
de vida de desarrollo de software, se hace más énfasis en el desarrollo de las
actividades características esperadas en cada incremento (Ver Descomposición de
Actividades). De esta manera, se hace un seguimiento más detallado a las actividades
cruciales en el proceso de desarrollo de la solución consumible, iteración a iteración.
La verificación de las actividades se centra principalmente en evaluar el avance de la
tarea estimando que estas solo deben realizarse en la iteración que tienen asignada,
 por lo cual si se debe asignar nuevamente en la siguiente se considera que se está
presentando un atraso.

o Monitoreo del tiempo utilizado para completar cualquier tarea asignada. Cada
una de las tareas serán evaluadas por ambos miembros del equipo de trabajo,
determinando en qué momento se han presentado atrasos y las razones de los mismos.
Al ser solo dos personas las que trabajan en el desarrollo del prototipo resulta un tanto
excesivo hacer peticiones para modificaciones ya que se considera que por medio de
la gestión del control de versiones y el manejo de comunicación entre los integrantes
y las interfaces externas (cuando se requiera) es suficiente para monitorizar el tiempo
que toma realizar tareas, así como la toma de decisiones al momento de presentarse
cualquier inconveniente ajustado además con los riesgos.

10.3 Cierre del Proyecto

Las actividades para realizar el cierre del proyecto ocurren al momento de finalizar la fase de
pruebas finales del prototipo, correspondiente a la tercera fase metodológica del ciclo de vida
de la Entrega Ágil Disciplinada correspondiente a este proyecto:

Verificar la calidad de los diferentes entregables: Se debe comprobar el contenido de

cada una de las secciones de los documentos entregados, revisando que cada sección
esté completa y no se presenten errores de ortografía, redacción ni formato. Además
de rectificar que el documento cumple con los estándares básicos del plan de calidad
para documentos (ver Plan de Calidad), haciendo una gestión efectiva de
referenciación bibliográfica, con el fin de no incurrir en un plagio, más aun en un
proceso de tal magnitud como es un trabajo de grado.(Pontificia Universidad
Javeriana, 2013).

Revisar que los documentos se encuentren debidamente alojados en el espacio

asignado para el trabajo de grado: Asegurarse que en pegasus.javeriana.edu.co
estarán alojados todos los entregables asociados al proyecto y rectificando que se
tenga acceso a los mismos a través de la página web.
Preparar presentación para la sustentación: No todo el trabajo del proyecto se limita
a entregar documentación y código fuente asociado, sino además exponer sobre todo
el proceso que se llevó a cabo para desarrollar el simulador virtual, bajo que
parámetros, con qué métodos de verificación y con cuáles resultados obtenidos, todo
esto de una manera clara y coherente con las actividades y procesos llevados a cabo
durante el proyecto de grado. Exponer estos puntos en la sustentación frente a los
jurados es una actividad que se debe realizar una vez finalizado todo el proceso del
proyecto.
Realizar correcciones pertinentes después de la sustentación: Solo hay 5 días
calendario para actualizar los documentos asociados al trabajo de grado y realizar
todas las correcciones pertinentes del proyecto.
11 Entrega del Producto

En un proceso de desarrollo de software es importante entregar al cliente, no sólo un prototipo

funcional, sino también la documentación del mismo. Es de gran valor tanto para quienes
estén interesados en utilizar este proyecto más adelante como para los mismos integrantes
del proyecto de grado, que se dé a conocer el proceso formal de ingeniería de software para
hacer este desarrollo en particular, demostrando los procesos seguidos para asegurar la
calidad y que sea aceptado por las diferentes interfaces externas presentes en el proyecto (ver
Plan de aceptación del producto). Adicional a esto, que al momento de entregar la última
solución consumible que vendría siendo el prototipo final, toda la documentación asociada
puede también servir para próximos trabajos asociados en evitar los problemas e
inconvenientes que se puedan tener en un nuevo desarrollo.

A través de la plataforma de trabajos de grados de Pegasus (pegasus.javeriana.edu.co) se deja

accesible el producto final y los entregables asociados del mismo, a las diferentes interfaces
externas del proyecto y a los potenciales interesados, con el fin que pueda ser revisado y
reutilizado para otros proyectos o para su uso como herramienta de entrenamiento médico
para hospitales y centros educativos de manera preliminar, resaltando nuevamente que el
producto final consiste en un prototipo que condensa los conceptos planteados en términos
generales más en el desarrollo del sistema completo (ver Entregables).

Proceso de transición

Como un proyecto de trabajo de grado orientado a que se pueda reutilizar a futuro en nuevos
procesos de investigación y desarrollo de herramientas de entrenamiento médico en cirugías
mínimamente invasivas, el proceso de transición consistirá más en dejar disponible la
herramienta de prototipo en conjunto con toda su documentación y manuales asociados para
poder ir aprovechando las nuevas versiones que vayan saliendo de cada uno de los programas
que componen el sistema, con el fin de mantener todos los elementos que lo componen
vigentes en el tiempo. Entra en consideración de por ser el proyecto que bien es la carta de
presentación de los integrantes, también se prestará un soporte si es requerido, así como el
soporte existente de las interfaces externas sobre la continuidad del proyecto.
12 Procesos de Soporte

12.1 Plan Análisis y Administración de Riesgos

Objetivo del Plan

El plan de análisis y administración de riesgos se realiza para poder identificar y mitigar

continuamente todos los posibles problemas e inconvenientes que puedan ocurrir durante el
desarrollo del proyecto, así como su análisis, medidas evaluar la gravedad de los riesgos y
por último, la acción apropiada que se debe tomar para reducir o evitar el impacto. (IEEE
Standards Board, 2011)

Encargado del Plan

Ambos integrantes del equipo de desarrollo de Simuscope estarán encargados de gestionar

los riesgos del proyecto, teniendo en cuenta que las perspectivas y contextos de ambos son
distintas y están sujetos a diferentes restricciones y problemas que dan origen a nuevos
riesgos. Se tiene en cuenta que para este caso se manejan dos procesos en particular para
gestionar los riesgos:

1. Monitoreo y control de nuevos riesgos.

2. Administración del riesgo.

La primera etapa es el continuo monitoreo de cada uno de los integrantes en analizar si se

presenta algún riesgo que pueda perjudicar de alguna manera el proyecto, mientras que la
segunda consiste en que una vez se ha localizado o descubierto un riesgo para el desarrollo
del proyecto, se haga todo el proceso de categorización, valoración y toma de decisiones de
cómo lidiar con este nuevo riesgo. En la administración de riesgos también cabe el hecho de
hacer nuevas valoraciones o cambios a los riesgos existentes e inclusive, terminar por
eliminarlos si se ha considerado que no son relevantes al momento de re-evaluarlos.
Frecuencia del Plan

Como se detalló en el encargado del plan hay un continuo monitoreo y control de riesgos.
Por lo tanto, en cada sesión de trabajo presencial, así como las reuniones con el tutor del
proyecto de grado, se comentan los problemas e incidentes que se han presentado,
determinando el grado de inconveniencia que representa para el proyecto y determinando
finalmente si representa o no un riesgo para el desarrollo del proyecto. De esta manera, habrá
un control continuo sobre riesgos nuevos que puedan surgir.

Puesta en Marcha

Si bien se puede controlar parcialmente cada uno de los riesgos que se conozcan de entrada
en el desarrollo de un proyecto, hay otros que son inevitables y que se debe decidir si hay se
puede mitigar el impacto que poseen o si simplemente se debe aceptar que sucedan. Ante la
ocurrencia de amenazas que afecten el normal desarrollo del proyecto, estar en capacidad de
saber cómo lidiar con el riesgo es necesario para que en un futuro no se convierta en un
problema mayor que requiera un sobreesfuerzo para poder solucionar sus efectos.
(Wallmüler) Los puntos a tener en cuenta en el proceso de la administración del riesgo es:

 Realizar un monitoreo continuo del riesgo

 Realizar un análisis debido del riesgo
 Realizar un tratamiento debido al riesgo presentado
 Evaluar el proceso de la administración del riesgo presentado (IEEE Standards Board,
2011)

Inicialmente, como se relata en la frecuencia del plan, cada reunión presencial se comentan
los problemas que van surgiendo durante el desarrollo, esto con el fin de saber que
inconvenientes se presentaron o incluso se pueden presentar en un futuro. (Wallmüler) Dado
el caso en el que se presentó algún inconveniente se discutirá entre todos como mitigar el
inconveniente presentado, en caso de que no se haya presentado ningún inconveniente se
analiza si hay algún inconveniente que se pueda presentar en el futuro, esto con el fin de
poder adelantarnos a los problemas antes de que surjan.
En caso de que se haya presentado algún inconveniente, en la reunión grupal se realizarán
las siguientes preguntas para analizar el riesgo del inconveniente presentado en el grupo de
trabajo:

 ¿Es un inconveniente que se puede evitar de una manera sencilla?

 ¿Qué tanto riesgo involucra para el proyecto, es decir, según la lista de riesgos (ver
Anexos: Lista de Riesgos adaptada de (Central Federal Lands Highways)), qué tanto
podría afectar el desarrollo del proyecto?
 La estimación y valoración del riesgo se efectuará de manera cualitativa, definiendo
escalas de valor basados en la probabilidad que ocurra el riesgo, contratado con el
impacto que pueda llegar a tener en el proyecto.
o Tanto Probabilidad como Impacto se clasifican dese Muy Bajo (MB), Bajo
(B), Medio (M), Alto (A) y Muy Alto(MA).
o La matriz de riesgos muestra que tan perjudicial es el riesgo, dependiendo del
sector donde se ubique en la matriz, servirá como medio para priorizar en
cuales se trabajará más.

Valoración Cuantitativa del Riesgo

Matriz de Riesgo (Para priorizar

Probabilidad Impacto el riesgo dado su prioridad e
impacto)

MA
A
Probabilidad

M
Muy Bajo Muy Alto B
MB X
MB B M A MA
Impacto
Tabla 1. Segmento de la Lista de riesgos. (ver Anexo: Lista de Riesgos)
 o Se definen 4 posibles estrategias de resolución:
 Aceptar que es asumir el impacto del riesgo y no hacer nada para evitarlo.
Generalmente esto ocurre cuando el impacto es inevitable por razones de
fuerza mayor y no hay mecanismos para evitarlo.
 Mitigar que es reducir el impacto del riesgo en el proyecto. El riesgo no
se puede evitar, pero se busca que el grado de afectación sea reducido.
 Transferir que es pasar el problema causado por el riesgo a un tercero para
que lo solucione. Esta se considera que será poco frecuente de ocurrir pero
se tiene en consideración.
 Prevenir que es reducir la probabilidad de ocurrencia del riesgo.

 Cuando se estima el porcentaje de riesgo se entra a analizar cómo solucionarlo. Si el

riesgo es igual a una categoría B (Bajo- Color Verde), a la persona que se le presentó el
inconveniente se acepta el riesgo, dado que el grado de afectación no es lo
suficientemente significativo para tomar medidas preventivas para este y se considera
que es de fácil solución.
 Si el riesgo representa una categoría M (Medio-Amarillo) o A (Alto-Naranja), se define
un plan para prevenir la ocurrencia de ese riesgo, ya que posee una probabilidad de ocurrir
que todavía es manejable por el equipo de desarrollo y que es fácil de evitar si siguen
ciertos pasos de manera rigurosa.
 E (Extremo-Rojo), por tener una alta probabilidad de ocurrencia y además un impacto
significativo en el proyecto, se estima que va a ocurrir aun cuando se haga prevención,
por lo cual se prefiere mitigar el impacto que genere este riesgo, que es reducir mediante
planes de contingencia, los daños que pueda provocar la materialización de este riesgo.
 En caso que las estrategias de M, A o E fallen, se tendrá que aceptar el riesgo. Entonces,
se le asignará cualquier recurso necesario a todo el equipo o área de trabajo donde se
presentó el inconveniente para que de esta manera ayuden a contrarrestar trabajando
todos en una sinergia, así podrán atacar el inconveniente de una manera mucho más
rápida y podrán mitigar sus consecuencias.
 Se detalló gráficamente como es el proceso de administración de riesgos explicado anteriormente siendo posible encontrarlo en
la siguiente referencia:

Gráfico 2. Proceso de Aceptación de Riesgo y Resolución

 12.2 Plan Administración de Configuración y Documentación
La administración de la configuración del software es la disciplina de administrar y controlar
los cambios en la evolución de los sistemas de software. (Bruegge & Dutoit , 2002). Si bien
es un proyecto en el cual no muchas personas están alterando un mismo artefacto o un mismo
módulo al tiempo, se especifica que estas actividades buscan que la generación de
documentos y demás entregables posean una revisión de calidad, iteración a iteración.
Añadido a esto, está el plan de documentación, que especifica todos los documentos que se
van a construir, así como los lineamientos y estándares en los cuales van a estar basados.
(IEEE Standards Board, 1998)

Objetivo del Plan

El plan de administración de configuración y documentación busca llevar seguimiento del

estado y estructura de los documentos, así como el control de versiones del mismo y aspectos
como ortografía, cohesión, presentación y estilo, entre otros. Se tendrán en cuenta
procedimientos para efectuar el control de versiones, definición de ítems de configuración y
formatos para asegurar la consistencia y cohesión entre los entregables.

Encargados del Plan

El control de esta administración dependerá de ambos miembros del equipo de desarrollo, lo

que permitirá que se efectúe una revisión más profunda y con una menor probabilidad de no
corregir un posible error por tratarse de todo un equipo y no solo integrante del grupo.
Nuevamente, al tener habilidades y perspectivas distintas, un integrante puede encontrar
errores donde otro no lo haya hecho.

Las políticas de desarrollo de documentos y control de configuraciones serán aplicadas por

todos los miembros del equipo de desarrollo, pues cada uno de los ítems de configuración
debe seguir los lineamientos planteados para que así se cumplan aspectos mínimos definidos
en el control de calidad (ver Plan de Control de Calidad), además de servir para realizar
trazabilidad de las acciones que se han realizado sobre el documento, los cambios que ha
sufrido y quien los ha realizado, teniendo también control de los respaldos de los documentos
realizados..

Frecuencia del Plan

Entendiendo que este proceso es de soporte y maneja elementos de calidad y de organización

de los entregables con el fin de reducir la probabilidad que ciertos riesgos se conviertan en
una realidad, además de asegurar el cumplimiento de los requerimientos y lineamientos de
calidad del proyecto. Estos planes se efectuarán cada que se generen cambios en los ítems de
configuración definidos en este documento, la mayoría de estos, entregables y recursos clave
para el desarrollo correcto del proyecto, todo con el fin de no efectuar cambios que puedan
resultar contraproducentes para el desarrollo de otras actividades o provocar y propagar
errores que requieran correcciones que reduzcan el tiempo con el que se dispone para otras
actividades.

Puesta en Marcha

Teniendo en cuenta que el grupo de desarrollo del proyecto son solo dos personas, se opta
por una estrategia de revisiones cruzadas, esto con el fin de realizar revisiones de los
entregables de una manera más objetiva, teniendo en cuenta que las habilidades y la
percepción que tienen los miembros pueden hacer que se encuentren errores que el otro no
haya detectado, además de facilitar una retroalimentación de los avances obtenidos.

Política de Versionamiento

Se define que la política de versionamiento se hará añadiendo a los documentos el sufijo

vA.B.C., donde A es el número de entregas (“distribuciones que ha tenido el ítem de
configuración fuera de la organización, por ejemplo, al cliente” (IEEE Standards Board,
1998)) que ha tenido ese documento; B el número de versiones (“identificador que se le da a
un ítem de configuración cuando capacidades funcionales le son añadidas, modificadas o
borradas” (IEEE Standards Board, 1998)) que ha tenido ese ítem de configuración y C el
número de revisiones (“asociado con la noción de arreglo de bugs, que consiste en la
corrección de errores en el diseño lógico pero que no tienen repercusión en la funcionalidad
documentada pues los requerimientos no han sido modificados” (IEEE Standards Board,
1998)).

Para la gestión de documentos distintos al código fuente se utilizará Google Drive como
repositorio de estos documentos, con el fin de facilitar el trabajo concurrente y revisar de
manera visual los cambios efectuados en cada documento tratado. Estos documentos también
se irán almacenando en el repositorio en Github, de tal manera de guardar un respaldo de los
documentos en sus versiones anteriores

También será usado el etiquetado que proveen herramientas de Git para el repositorio de
GitHub, actualizando los códigos fuente de la implementación de prototipos y permitiendo a
los desarrolladores visualizar los cambios hechos en cualquier código, guardando respaldo
de versiones anteriores para evitar posibles errores que afecten el desarrollo del sistema. Sin
embargo, se encuentra que GitHub posee una serie de limitantes en el tamaño del espacio

Estructura de presentación de prototipo

Estructura de documentos

Cualquier documento o plantilla realizada dentro debe cumplir las siguientes condiciones:

 Fuente: Times New Roman 12 Puntos, Interlineado de 1,5.

 Referencias con formato APA.
 Marca de Agua con el logotipo de Simuscope excepto en la memoria de trabajo de
grado.
 Diseño de página con una paleta de colores y fuentes predeterminadas para los
documentos y otras plantillas.
 Índice de Gráficos si el documento los posee.
 Índice de Tablas si el documento las posee.
 Márgenes de 2,54 cm en cada extremo. (Si es un documento Word)
 Si es un entregable, adicionalmente cuenta con una tabla inicial de historial y cambios
como se puede ver en la tabla, donde se aplican las políticas de versionamiento.
 Historial de Cambios
Versión (v A.B.C) Cambios efectuados Fecha de Actualización Encargado
v D.E.F  DD/MM/AAAA Equipo

Tabla 2. Plantilla de Historial de Cambios

Adicional a esto, todos los documentos y plantillas deberán estar guardados con el prefijo
“(Simuscope) – NombreDocumento”, para poder identificar claramente que son documentos
realizados por el grupo de desarrollo de Simuscope.

Ítems de Configuración

Los ítems de configuración, a los cuales se les aplicará las anteriores políticas de
versionamiento, son aquellos que sean entregables, pues permite hacer trazabilidad de los
cambios que han sufrido los documentos, así como cuantas veces han sido entregados al
cliente:

 Software Planning Management Plan (SPMP)

 User Stories
 Software Requirement Specification (SRS) y modelos asociados.
 Software Design Document (SDD) y modelos asociados
 Manuales de uso e instalación
 Fichas de pruebas del sistema
 Código fuente y elementos de la solución consumible
 Memorias del trabajo de grad

En caso de requerir hacer modificaciones de los ítems, se debe informar al otro miembro del
equipo, con el fin de hacer la revisión cruzada y evaluar la validez de los cambios efectuados,
esto para asegurar la calidad de los entregables, además de dejar documentada cualquier
anomalía encontrada.
Documentos Entregables distintos a la solución consumible

Para controlar los cambios que puedan sufrir algunos de estos documentos durante esta etapa
de desarrollo, se decide utilizar una rama de desarrollo para generar adelantos y cambios del
documento, evitando llegar a modificar o sobrescribir la línea base del documento a entregar.

Aprovechando que los documentos poseen subdivisiones, se trabajan de manera modular y

separada, como otros documentos independientes. Al ser documentos, se les aplican todas
las revisiones mencionadas en la estructura del documento, para aprobar o no su integración
con el ítem de configuración que le corresponda.

Una vez han sido aprobados, se realiza su integración, se aplican las políticas de
versionamiento reflejadas en el historial de cambios y posteriormente en la etiqueta del
documento una vez sea actualizado en el repositorio.

Código Fuente y Solución consumible

Para controlar los cambios que puedan sufrir los documentos en cuanto a códigos fuente, se
decide utilizar una rama de desarrollo, donde se generará los cambios de estos. Estas se irán
desarrollando por escenarios y requerimientos, donde se generan progresivamente y luego se
integran una vez hayan pasado todas las pruebas definidas para tales requerimientos.

Los miembros del equipo de desarrollo y pruebas deberán aplicar las mismas políticas de
versionamiento que se venían haciendo con documentos. El código fuente posee su propia
plantilla de control para aprobar su integración al sistema total y dependiendo si deben hacer
correcciones, si fue aprobado o si es una entrega para el cliente, su versión se modificará
según las políticas previamente definidas
 12.3 Plan de Control de Calidad

El grupo de trabajo realizará un correspondiente plan de calidad, garantizando a los clientes

que el trabajo entregado cumple con las métricas del proceso (ver Métricas y proceso de
medición). El control de calidad se realizará en su forma más básica, basándonos en la
verificación, validación y revisiones. Ian Sommerville (Sommervile, 2005) sugiere que el
proceso se lleve a cabo de la siguiente manera como muestra el gráfico 19:

Gráfico 3. Proceso de control de calidad, tomado de (Sommervile, 2005)

Verificación: “El papel de la verificación comprende comprobar que el software está de

acuerdo con su especificación. Se comprueba que el sistema cumple los requerimientos
funcionales y no funcionales que se le han especificado.” (University of Cantabria (Spain),
2011)

Validación: “La validación es un proceso más general. Se debe asegurar que el software
cumple las expectativas del cliente. Va más allá de comprobar si el sistema está acorde con
su especificación, para probar que el software hace lo que el usuario espera a diferencia de
lo que se ha especificado.” (University of Cantabria (Spain), 2011)
A partir de esto, el equipo de desarrollo se pondrá en los zapatos del cliente, (“take off your
engenineering hat and put on your mangament hat” (Fledderman)) y realizarán pruebas de
casos que se le podrían presentar al cliente al momento de usar el producto, y estas serán
demostradas al gerente.

Para evitar toda clase de problemas, se decide utilizar el ejemplo de producción mostrado por
Sommerville, por medio del Gráfico 3, donde se muestran las etapas que se llevan a cabo
para realizar el control de calidad.

La etapa de creación es la generación de un artefacto desde ceros, por lo cual es bastante

probable que ocurran errores. Se realizan varios borradores que se van refinando hasta que
se tiene un texto base para seguir a la etapa de producción, donde se hacen los últimos ajustes
en términos de reglas, lineamientos, estilo, entre otros y finalmente se efectúa la impresión
(si se está hablando de documentación o manuales por ejemplo), aunque esto también puede
verse como el lanzamiento de un artefacto a los clientes o el paso por los diferentes
mecanismos de control para acoplar a un documento uno de sus fragmentos (ver Monitoreo
y Control de Proyecto).
 Gráfico 4. Etapas de control de calidad, Adaptado de (Sommervile, 2005)

Para cada uno de los entregables generados simplemente seguirá un esquema de revisión
cruzada entre los miembros del equipo del proyecto de Simuscope para la revisión
del mismo, favoreciendo así el tiempo de trabajo (limitado por cierto) para la solución
consumible sin dejar de lado la calidad del desarrollo, documentación y procesos de
soporte asociados.
15. Referencias
About Tech. (s.f.). Recuperado el 2015 de Marzo de 4, de A List of Social Networks for Pet Lovers:
http://webtrends.about.com/od/socialnetworks/tp/pet-social-networks.htm

Adobe. (s.f.). Recuperado el 11 de Marzo de 2015, de Adobe Creative Suite 6 - Products:

http://www.adobe.com/products/catalog/cs6._sl_id-
contentfilter_sl_catalog_sl_software_sl_creativesuite6.html

Adobe Systems. (s.f.). Obtenido de Brackets: An open source text editor that understands web design:
http://brackets.io/

Agile Alliance. (Enero de 2015). The Twelve Principles of Agile Software. Obtenido de The Agile Manifesto:
http://www.agilealliance.org/the-alliance/the-agile-manifesto/the-twelve-principles-of-agile-
software/

Asana. (s.f.). Recuperado el 21 de Febrero de 2015, de Asana - Product: https://asana.com/product

Asana. (Marzo de 2015). Obtenido de Instagantt - Gantt Charts for Asana : http://www.instagantt.com/

Atlassian. (s.f.). Recuperado el 26 de Febrero de 2015, de BitBucket - Prices: https://bitbucket.org/plans

Atlassian. (2015). Obtenido de SourceTree - Free Git and Mercurial Client:

http://www.sourcetreeapp.com/

Banerjee, G. (2001). Use Case Points - An estimation Approach. Obtenido de Use Case Point - A estimation
approach: http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/use_case_points.pdf

Bizagi. (Enero de 2015). Obtenido de Bizagi Process Modeler: http://www.bizagi.com/es/bpm-suite-

es/productos/modeler

Bogue, R. (25 de Abril de 2005). TechRepublic. Recuperado el 2015 de Marzo de 4, de Use S.M.A.R.T. goals
to launch management by objectives plan: http://www.techrepublic.com/article/use-smart-
goals-to-launch-management-by-objectives-plan/

Bruegge, B., & Dutoit , A. H. (2002). Ingeniería de Software orientado a objetos. En Ingenieria de Software
Orientado a Objetos (págs. 458-490). Prentice Hall.

Bueno, C. B. (2012). Recuperado el 7 de Marzo de 2015, de Ingeniería de Software:

http://ocw.unican.es/ensenanzas-tecnicas/ingenieria-del-software-ii/materiales/tema6-
gestionTiempo.pdf

Capitulo Javeriano ACM. (Febrero de 2015). Obtenido de Ruby on Rails:

http://acm.javeriana.edu.co/2015/02/ruby-on-rails/
Central Federal Lands Highways. (s.f.). Recuperado el 1 de Marzo de 2015, de Central Federal Lands
Highway Division's Project Planning and Controls Guide:
http://www.cflhd.gov/resources/pm/PPCGuide/

Ceria, S. (s.f.). Universidad de Buenos Aires. Obtenido de Casos de Uso - Un método práctico para explorar
requerimientos: http://www-2.dc.uba.ar/materias/isoft1/2001_2/apuntes/CasosDeUso.pdf

Cockburn, A. (Octubre de 2008). Obtenido de Basic Use Case Template:

http://alistair.cockburn.us/Basic+use+case+template

Cockburn, A. (2008, Mayo). Using Both Incremental and Iterative Development. In Using Both Incremental
and Iterative Development (pp. 28-30). The Journal of Defense Software Engineering.

Construx Software. (2002). CxOne Best Practices: Lifecycle Model Selection.

Corel. (s.f.). Obtenido de Corel Draw Suite x7: http://www.coreldraw.com/la/product/diseno-grafico-

creativo/

Deemer, P., Benefield, G., & Larman, C. (s.f.). Información Básica de SCRUM (The SCRUM Primer). En
Información Básica de SCRUM (The SCRUM Primer) (págs. 3-6). Scrum Training Institute.

Dell. (s.f.). Recuperado el 11 de Marzo de 2015, de Toad Data Modeler:

http://software.dell.com/products/toad-data-modeler/

dotPDN. (Diciembre de 2014). Obtenido de Paint.Net: http://www.getpaint.net/index.html

Dropbox. (s.f.). Obtenido de Descargar Dropbox: https://www.dropbox.com/install

Eclipse. (s.f.). Recuperado el 2 de Marzo de 2015, de Eclipse BPMN Modeler: http://eclipse.org/bpmn2-

modeler/

FacePets. (s.f.). Recuperado el 1 de Marzo de 2015, de FacePets: http://www.facepets.es/

Fledderman, C. (s.f.). Engineering Ethics.

Git. (2014). Obtenido de About Git - Distributed is the new Centralized: http://git-
scm.com/about/distributed

GitHub Enterprise. (2015). Obtenido de About GitHub: https://github.com/about

Google Inc. (s.f.). Recuperado el 7 de Marzo de 2015, de Introducción a Google Drive:

https://support.google.com/drive/answer/2424384?hl=es

Google Inc. (s.f.). Recuperado el 7 de Marzo de 2015, de Introducción a Google Docs.:

https://support.google.com/docs/answer/49008?hl=es

Google Inc. (s.f.). Apps for Work - Formularios y Encuestas. Recuperado el 28 de Febrero de 2015, de
http://goo.gl/aKzJaZ
Graphics Springs. (s.f.). Recuperado el 21 de Febrero de 2015, de Create your own logo for free:
https://www.graphicsprings.com/

Hashmi, S. I., & Baik, J. (s.f.). Software Quality Assurance in XP and Spiral - A Comparative Study. Fifth
International Conference on Computational Science and Applications, (págs. 3-5). Daejeon.

Hipp, D. R. (Abril de 2015). Obtenido de SQLite - Copyright: http://www.sqlite.org/copyright.html

Huffington Post. (Agosto de 2014). Obtenido de 3 Reasons Why Social Media Age Restrictions Matter:
http://www.huffingtonpost.com/diana-graber/3-reasons-why-social-media-age-restrictions-
matter_b_5935924.html

IEEE Standards Board. (1998). IEEE Guide to Software Configuration Management. IEEE Standards Board.

IEEE Standards Board. (1998). Recommended practice for Software Requirements Specifications. IEEE
Standards Board.

IEEE Standards Board. (1998). Standard for Software Project Management Plan.

IEEE Standards Board. (2009). Software Design Description. IEEE Standars Boards.

IEEE Standards Board. (2009). Systems and software engineering — Life cycle processes — Project
management. IEEE Standards Board.

IEEE Standards Board. (2010). Systems and software engineering — Vocabulary. IEEE Standards Board.
International Standards Organization.

IEEE Standards Board. (2011). Standadr for Software Life Cycle Processes - Risk Management. IEEE
Standards Board.

Kusumoto, S., Matukawa, F., & Inoue, K. (s.f.). Estimating Effort by Use Case Points: Method, Tool and
Case Study. 10th International Symposium on Software Metrics, (págs. 1-8). Osaka.

Larman, C. (2004). Iterative, Evolutionary and Agile Models. En UML and Patterns (págs. 13-21).

Larman, C., & Basili, V. (2003). Iterative and Incremental Development: A Brief Story. IEEE Computer
Society, 1-10.

Lider de Proyecto. (s.f.). Recuperado el 1 de Marzo de 2015, de Estimación de Costos de Software:

http://www.liderdeproyecto.com/articulos/estimacion_costos_de_software.html

Merriam Webster. (s.f.). Obtenido de An Encyclopædia Britannica Company : Social Network:

http://www.merriam-webster.com/dictionary/social%20network

Microsoft. (s.f.). Recuperado el 21 de Febrero de 2015, de Microsoft Office:

http://products.office.com/ES/
Microsoft. (s.f.). Recuperado el 10 de Marzo de 2015, de Microsoft OneDrive:
https://onedrive.live.com/about/es-es/

Ministerio de Educación de Colombia. (s.f.). Obtenido de Sistema de Créditos Académicos:

http://www.mineducacion.gov.co/1621/article-87727.html

Ministerio de Tecnologías de la Información y Comunicaciones. (2013). Estudio de Salarios del Sector TI en

Colombia 2013. MinTic, Bogotá.

Navaro Castaño, D. (2011). Evaluación de Proyectos. Obtenido de Evaluación de Proyectos - Valor Presente
Neto.

Navarro Castaño, D. (2011). Universidad Nacional de Colombia Sede Manizales. Recuperado el 08 de

Marzo de 2015, de
http://www.virtual.unal.edu.co/cursos/sedes/manizales/4010045/Lecciones/Cap%2010/10-1-
2.htm

Oracle. (s.f.). Recuperado el 9 de Marzo de 2015, de Top Reasons for Using MySQL:
http://www.mysql.com/why-mysql/topreasons.html

Osorio Suárez, W. (11 de Agosto de 2010). Gerencie. Recuperado el 08 de Marzo de 2015, de

http://www.gerencie.com/vida-util-de-los-activos.html

Osorio, W. (13 de Junio de 2010). Gerencie. Recuperado el 08 de Marzo de 2015, de

http://www.gerencie.com/fuentes-de-capital-de-trabajo.html

Pavlich, J., & Torres, M. (Enero de 2015). Obtenido de Página de Miguel Torres -Ingenieria de Software -
Programa del Curso: http://sophia.javeriana.edu.co/~metorres/

Pavlich, J., & Torres, M. (s.f.). Descripción de Diseño de Software - Plantilla.

Pavlich, J., & Torres, M. (s.f.). Plan de Administración de Proyecto de Software.

Pavlich, J., & Torres, M. (s.f.). Rúbrica de Calificación de Ingeniería de Software. Obtenido de Rúbrica de
Calificación .

Pavlich-Mariscal, J. (Febrero de 2013). Obtenido de Blog de Jaime Pavlich-Mariscal - La Ingeniería de

Sistemas en palabras simples: http://jpavlich.blogspot.com/2013/02/la-ingenieria-de-sistemas-
en-palabras.html

PHP Frameworks. (s.f.). Recuperado el 11 de Marzo de 2015, de PHP Frameworks:

http://software.dell.com/products/toad-data-modeler/

Pontificia Universidad Javeriana. (Octubre de 2013). Obtenido de Reglamento Estudiantil de la Pontificia

Universidad Javeriana:
 http://www.javeriana.edu.co/Facultades/comunicacion_lenguaje/DOCS/Reglamentodeestudian
tes.pdf

Project Management Docs. (s.f.). Recuperado el 6 de Marzo de 2015, de Work Breakdown Structure:
http://www.projectmanagementdocs.com/project-planning-templates/work-breakdown-
structure-wbs.html

Project Management Institute. (s.f.). Obtenido de Roles, Responsibilities, And Skills In Program
Management: http://www.pmi.org/learning/roles-responsibilities-skills-program-management-
6799

Rails Core Team. (s.f.). Recuperado el 20 de Febrero de 2015, de Ruby on Rails: El desarrollo web que no
molesta: http://www.rubyonrails.org.es/

Rails Core Team. (2015). Recuperado el 20 de Febrero de 2015, de Ruby on Rails - Show, don't tell: Seeing
is believing: http://rubyonrails.org/screencasts/

Rational - The Software Development Company. (1998). Rational Unified Process - Best Practices for
Software Development Teams. Obtenido de Rational Unified Process: Best Practices for Software
Development Teams:
 https://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestp
ractices_TP026B.pdf

Raymond, E. S. (Febrero de 2010). Obtenido de The Cathedral and The Bazaar:

http://catb.org/esr/writings/cathedral-bazaar/cathedral-bazaar/index.html#catbmain

Restrepo Rivera, T. (18 de Febrero de 2015). Portafolio. Recuperado el 08 de Marzo de 2015, de

http://www.portafolio.co/economia/impuestos-2015-colombia

Rumbaugh, J., Booch, G., & Jacobson, I. (2000). Lenguaje Unificado de Modelado: Manual de Referencia.
(Segunda ed.). Addison Wesley. Obtenido de Lenguaj.

Shapiro, J. (2001). Elaboracion de un presupuesto. Recuperado el 08 de Marzo de 2015, de

http://www.civicus.org/new/media/Elaboracion%20de%20un%20propuesto%20Part%201.pdf

Skinner, J. (Julio de 2013). Obtenido de Sublime: The Text Editor you'll fall in love with:
http://www.sublimetext.com/

SoftPanorama. (s.f.). Recuperado el 2015 de Marzo de 6, de Software Life Cycle Models:

http://www.softpanorama.org/SE/software_life_cycle_models.shtml

Sommervile, I. (2005). Ingenieria de Software. En Ingenieria de Software (págs. 61-69). Pearson.

Sparx Systems. (s.f.). Recuperado el 6 de 3 de 2014, de Typical Project Roles:

http://www.sparxsystems.com/enterprise_architect_user_guide/9.2/getting_started/profession
alroles.html

Sparx Systems. (s.f.). Obtenido de Enterprise Architech: http://www.sparxsystems.com/products/ea/

Star Office. (s.f.). Recuperado el 11 de Marzo de 2015, de StarOffice Legacy Download:

http://www.staroffice.com/get.php

Star UML. (s.f.). Recuperado el 11 de Marzo de 2015, de Star UML download: http://staruml.io/

Together. (s.f.). Recuperado el 2 de Marzo de 2015, de Borland - Visual Modeling Software:

http://www.borland.com/Products/Requirements-Management/Together

Udemy Blog. (11 de Marzo de 2015). Obtenido de Una comparación entre los Sistemas Gestores de Bases
de Datos Relacionales más Populares: https://blog.udemy.com/es/oracle-vs-mysql-vs-sql-server-
una-comparacion-entre-los-sistemas-gestores-de-bases-de-datos-relacionales-mas-populares/

Universidad de La Laguna. (s.f.). Recuperado el 10 de Marzo de 2015, de La lista de referencias (Normas

IEEE): http://www.ull.es/view/institucional/bbtk/Referencias_Normas_IEEE/es

Universidad Union Bolivariana. (s.f.). Recuperado el 2015 de Marzo de 5, de XP- Extreme Programming:
http://ingenieriadesoftware.mex.tl/52753_XP---Extreme-Programing.html
University of Cantabria (Spain). (2011). Obtenido de Ingeniería de Software - Verificación y Validación:
http://www.ctr.unican.es/asignaturas/Ingenieria_Software_4_F/Doc/M7_09_VerificacionValida
cion-2011.pdf

University of Houston. (s.f.). Recuperado el 4 de Marzo de 2015, de RUP - Vision Artifact (Small Projects):
http://sce.uhcl.edu/helm/rationalunifiedprocess/webtmpl/templates/req/rup_vision_sp.htm

Universo Mascotas - Colombia. (s.f.). Recuperado el 1 de Marzo de 2015, de UNIVERSO MASCOTAS:

http://www.universomascotas.co/

Vaquiro C., J. D. (29 de Marzo de 2013). PYMES FUTURO, Asesoría y Consultoría para PYMES. Recuperado
el 08 de Marzo de 2015, de http://www.pymesfuturo.com/vpneto.htm

Wallmüler, D. (s.f.). Recuperado el 11 de Marzo de 2015, de Risk Management for IT and Software
Projects: http://www.itq.ch/pdf/RM__ITProjekteV211.pdf

Wells, D. (2013). Obtenido de Extreme Programming: A gentle introduction:

http://www.extremeprogramming.org/

World Wide Web Consortium . (Octubre de 2014). Obtenido de HTML5 - W3C Recommendation 28
October 2014: http://www.w3.org/TR/html/

Zaragoza, M. d. (s.f.). Obtenido de Desarrollando aplicaciones informáticas :

http://www.utvm.edu.mx/OrganoInformativo/orgJul07/RUP.htm