Embed Size (px)
Citation preview
SOFTWAR
E
PROJECT
MANAGE
MENT
PLAN
SPMP para
Simuscope
Esteban Hernández
Losada
Emmanuel Neiza Salas
1 Historial de CambiosHistorial 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 de trabajo de grado.
Agosto 9 de 2016
V2.0 Revisión de planes, actualización de herramientas y de bibliografía
asociadaAgosto 28 de 2016
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
necesidades del equipo de desarrollo
Octubre 29 de 2016
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).......................................10Gráfico 2. Proceso de Aceptación de Riesgo y Resolución.........................................................................43Gráfico 3. Proceso de control de calidad, tomado de (Sommervile, 2005)................................................49Grá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........................................................................................13Ilustración 2. Estimación en Fase de Concepción......................................................................................14Ilustración 3. Estimacion en fase de Desarrollo.........................................................................................14Ilustración 4. Estimación en fase de pruebas.............................................................................................15Ilustración 5. Diagrama Gantt del Cronograma...........................................................................................0Ilustración 6. Estimación del Presupuesto del Proyecto..............................................................................1Ilustración 7. Proceso de Entrega Ágil Disciplinada. Tomado de (Amber, Scott W., 2013)..........................6Ilustración 8. Esquema General de RUP tomado de (Zaragoza, s.f.)..........................................................11Ilustración 9. Esquema de Modelo en V, tomado de (Bruegge & Dutoit , 2002).......................................13Ilustración 10. Esquema de Diente de Sierra, tomado de (Bruegge & Dutoit , 2002)................................15Ilustración 11. . Esquema de Modelo de Diente de Tiburón, tomado de (Bruegge & Dutoit , 2002).........17Ilustración 12. Esquema de SCRUM, tomado de (Deemer, Benefield, & Larman).....................................21Ilustració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 objeti -
vo 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 entrena-
miento 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 ob-
jetivo general, además de definir los resultados esperados y procesos acordes a un proceso de in-
genierí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 in-
vestigació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 es-
cogidos en la etapa de concepción.
Las restricciones son limitantes en alguno de los aspectos relevantes para el desarrollo del pro-
yecto, además de limitantes para los usuarios potenciales:
El prototipo debe contar con motores gráficos, simulación virtual, soporte para dispositi-
vos 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 limi-
tados 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 so-
ftware 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 par-
ticular sirve como primera aproximación a las necesidades y restricciones que posee Si-
muscope.
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, espe-
cificació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 fi-
nal.
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 4. Estimación en fase de pruebas
Ilustración 3. Estimacion en fase de Desarrollo
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ónEn 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 des-
ventajas
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 escogi-
da de manera individual.
9. Desarrollo de ejercicios de prueba para el uso de las herramientas y librerías de ma-
nera 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 siste-
ma 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 atribu-
tos 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 elabora-
ción del prototipo.
4. Configuración de las librerías externas, módulos de interacción, el dispositivo hápti-
co 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 ver-
sió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 prue-
ban 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 usa-
bilidad y del cumplimiento de los requerimientos.
8.2 Análisis de Alternativas y JustificaciónDado 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 De-
sarrollo evita cierta confusión que se presenta entre las fases de RUP de elaboración y cons-
trucció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 he-
cho 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 versio-
nes 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, tenien-
do en cuenta que al ser un proyecto de un área del conocimiento ajena al equipo de desarro-
llo 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,
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.
Ilustración 9. Esquema de Modelo en V, tomado de (Bruegge & Dutoit , 2002)
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 deta-
lles del desarrollo después de la aprobación de la propuesta de grado también son necesa-
rios 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 pro-
totipo final, pues son el insumo principal que define el impacto que tiene el sistema, ade-
má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 en-
cuesta 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, de-
terminando el grado de aprobación o no del sistema y los resultados que el proyecto y la in-
vestigació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 con-
formar un entorno de desarrollo que tenga en cuenta dispositivos hápticos, entornos virtua-
les, 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, tu-
toriales, lecturas y videos que permitan entender los lenguajes de programación, herramien-
tas 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, en-
focá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:
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 reali-
za mediante un chat, que los archivos se gestionan mediante repositorios remotos y
se puede trabajar en paralelo con aplicaciones como Google Docs, se considera en-
tonces la casa de cada miembro como parte de la infraestructura.
Pontificia Universidad Javeriana: teniendo en cuenta que gran parte del trabajo, con-
trol, 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 ex-
ternas del proyecto.
Simuscope
Pontificia Universidad
JaverianaSala Takina
Hogar de cada
Integrante
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.
Quinto Incremento(15 de Octubre)Implementación completa de la simulación virtual Retroalimentación Háptica
Cuarto Incremento (26 de Septiembre)Integración con el dispositivo háptico Implementación de elementos de luficación
Tercer Incremento (1 de Septiembre)Simulación visual de la cirugía y mapeo de gestos. Integracion de motores fisicos
Segundo Incremento (11 de Agosto)Caracterización de Gestos y laparoscopia
Avance en los entregables y la memoria de trabajo de grado
Evaluación de Motores fisicos y deformaciones
Primer Incremento (23 de Julio)Definición final de Herramientas a utilizar Configuración de entorno de desarrollo
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 im-
plementado. Estos son descripciones de cómo el sistema se debe comportar, de las propie-
dades y atributos del mismo. Deben ser una restricción del proceso de desarrollo del siste-
ma” (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 ante-
rior 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 obte-
nida 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 activida-
des 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 re-
querimiento para que pueda ser utilizado y comprendido por todo el equipo de desa-
rrollo, 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 co-
rrecto 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 de-
pendiendo del estado del requerimiento.
Finalmente es válido aclarar que para que un requerimiento se haya levantado y especifica-
do debió cumplir con ciertas características como las siguientes mencionadas:
Atómico
Correctos
No Ambiguos
Completos
Consistente
Importancia
Verificable
Modificable
Trazable
Asociados a Versión
No Redundante
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 sec-
ció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 Jave-
riana, 2013).
Revisar que los documentos se encuentren debidamente alojados en el espacio asig-
nado 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 ac-
ceso 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 calen-
dario 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 ries-
gos. Se tiene en cuenta que para este caso se manejan dos procesos en particular para ges-
tionar 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, determi-
nando el grado de inconveniencia que representa para el proyecto y determinando finalmen-
te 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 inconve-
nientes 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 in-
conveniente presentado, en caso de que no se haya presentado ningún inconveniente se ana-
liza 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é tan-
to 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.
Tabla 1. Segmento de la Lista de riesgos. (ver Anexo: Lista de Riesgos)
Probabilidad Impacto
MA A M B
MB XMB B M A MA
Impacto
Prob
abilid
ad
Matriz de Riesgo (Para priorizar el riesgo dado su prioridad e
impacto)
Muy Bajo Muy Alto
Valoración Cuantitativa del Riesgo
o Se definen 4 posibles estrategias de resolución:
Aceptar que es asumir el impacto del riesgo y no hacer nada para evitar-
lo. 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 ocu-
rrir 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 suficiente-
mente 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 ocu-
rrir que todavía es manejable por el equipo de desarrollo y que es fácil de evitar si si-
guen 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 median-
te planes de contingencia, los daños que pueda provocar la materialización de este ries-
go.
En caso que las estrategias de M, A o E fallen, se tendrá que aceptar el riesgo. Enton-
ces, 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 do-
cumentos 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 cam-
bios como se puede ver en la tabla, donde se aplican las políticas de versionamiento.
Tabla 2. Plantilla de Historial de Cambios
Historial de Cambios
Versión (v A.B.C) Cambios efectuados Fecha de Actualización Encargado
v D.E.F DD/MM/AAAA Equipo
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 versiona-
miento, 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 efec-
tuados, esto para asegurar la calidad de los entregables, además de dejar documentada cual-
quier anomalía encontrada.
Documentos Entregables distintos a la solución consumible
Para controlar los cambios que puedan sufrir algunos de estos documentos durante esta eta-
pa 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 en-
tregar.
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 versiona-
miento 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 ha-
cer correcciones, si fue aprobado o si es una entrega para el cliente, su versión se modifica-
rá 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 veri-
ficación, validación y revisiones. Ian Sommerville (Sommervile, 2005) sugiere que el pro-
ceso 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 ajus-
tes en términos de reglas, lineamientos, estilo, entre otros y finalmente se efectúa la impre-
sió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 solu-
ción consumible sin dejar de lado la calidad del desarrollo, documentación y proce-
sos 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/Reglamentodeestudiantes.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_bestpractices_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/professionalroles.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_VerificacionValidacion-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
