Ejemplo Formato IEEE 830

INGENIERIA DE SOFTWARE
CÓDIGO: 301404
Evaluación Final: Consolidación de la propuesta de software
Presentado a:
Pilar Alexandra Moreno
Tutor
Entregado por:
Sandra Paola Molina
Cód.: 52.913.263
Marco Tulio Palomo Avila
Cód.: 79405397
xxxxxxxxxxxx
Cód.: xxxx
xxxxxxxxxx
Cód.: xxxxxx
xxxxxxxxxxx
Cód.: xxxx
Grupo: 301404_6
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA - UNAD

DICIEMBRE DE 2018
BOGOTA
Tabla de contenido
Introducción ................................................................................................................................................ 3
Descripción del problema ........................................................................................................................... 4
Objetivos del proyecto ................................................................................................................................ 5
Descripción del proyecto de desarrollo de software................................................................................. 5
Planificación del proyecto ........................................................................................................................ 13
Capítulo I. Gestión de Alcance................................................................................................................. 13
1. La gestión del alcance ......................................................................................................................... 13
1.1.1 Recopilación de Requisitos ........................................................................................................ 13
1.1.2 Definición del alcance ................................................................................................................ 14
1.1.3 Creación EDT (WBS) Estructura desagregada del trabajo-Work Break Down ........................ 18
1.1.4 Control del Alcance ................................................................................................................... 18
1.1.5 Verificación del alcance ............................................................................................................. 19
Capítulo I I. Gestión del Tiempo ............................................................................................................. 19
2.2.1 Identificación de actividades ...................................................................................................... 19
2.2.2 Secuenciamiento de actividades................................................................................................. 21
2.2.3 Estimación de recursos de las actividades................................................................................. 22
2.2.4 Estimación duración de tiempo .................................................................................................. 22
2.2.5 Desarrollo cronograma (Project Schedule) ................................................................................ 23
2.2.6 Control del cronograma ............................................................................................................. 23
Capítulo I I I. Gestión de Costes .............................................................................................................. 23
Capítulo IV. Gestión de riesgos ............................................................................................................... 24
4.2 Planificar la gestión de riesgos.......................................................................................................... 25
4.3 Identificar los riesgos del proyecto ................................................................................................... 26
4.3.1 Lista de riesgos identificados ..................................................................................................... 26
4.4 Análisis Cualitativo ........................................................................................................................... 30
Tablas de riesgos ................................................................................................................................. 32
Planificación respuesta:....................................................................................................................... 39
Control de riesgos ............................................................................................................................... 46
Conclusiones .............................................................................................................................................. 56
Referencias bibliográficas ........................................................................................................................ 58
Introducción (1 página)
Descripción del problema
CLINICA COLOMBIANA DE OBESIDAD Y METABOLISMO S.A.S
La Clínica está conformada como Sociedad por Acciones Simplificadas -S.A.S., es una pequeña
empresa Prestadora de Servicios de Salud, con domicilio Principal en la ciudad de Bogotá, Carrera
13 No. 94ª-25 piso 2, edificio Centro Ejecutivo Castilla.
Esta clínica cuenta con 20 años de experiencia en prestar servicios de cirugía plástica, estética,
reconstructiva y tratamientos para la obesidad, que pone al servicio de sus usuarios las últimas
tecnologías, los más seguros procedimientos y el mejor talento humano, para mejorar su calidad
de vida. Pionera en el uso del rayo láser como una herramienta revolucionaria que ha modificado
por completo el concepto de cirugía plástica. Cuentan con un grupo de profesionales certificados
y calificados, en constante preparación y actualización de todos los procedimientos médico-
quirúrgicos, con el único objetivo de ofrecer una experiencia agradable al paciente, disminuir
riesgos, efectos secundarios, tiempo de recuperación, cicatrices y ofreciendo resultados más
naturales que una cirugía convencional.
El problema radica que la clínica a pesar de ser pioneros en el uso del rayo láser como una
herramienta revolucionaria que ha modificado por completo el concepto de cirugía plástica, aun
no se cuenta con una tecnología en donde indique la cantidad de lípidos a incorporar o quitar de
las áreas a intervenir del paciente, lo cual al realizar una lipolisis los cirujanos tienden a retirar
grasa del cuerpo que no deben atrofiando los tejidos y la grasa que se debe eliminar no se retira la
cantidad adecuada, en donde se queman tejidos que no deben de ser quemados como podrían ser
células buenas, vasos sanguíneos, lo cual conlleva a marcado dolor e inflamación prolongadas
secundario al trauma mecánico ejercido por el movimiento repetitivo en partes del cuerpo que no
deben intervenir, las complicaciones más frecuentes son las irregularidades en la piel, residuos de
los líquidos con células grasas muertas, las quemaduras y asimetrías, entre otra variedad de
situaciones irreversibles para el paciente y, en algunos casos, el desenlace puede ser la muerte.
Objetivos del proyecto
Objetivo general
Desarrollar el software de inteligencia artificial para la toma de decisiones del diagnóstico
preoperatorio del paciente de la Clínica Colombiana de obesidad y metabolismo S.A.S.
Objetivos específicos
 Realizar el levantamiento de información o de requerimientos para el diseño del software
 Elaborar el diseño del software de acuerdo a los requerimientos.
 Determinar las herramientas de hardware y software apropiados, de acuerdo al diseño.
 Desarrollar un prototipo del software funcional para pruebas y verificación de usuarios.
 Realizar ajuste y afinamiento de software de acuerdo al resultado de pruebas.
Descripción del proyecto de desarrollo de software
En este proyecto se plantea el estudio de aprovechamiento de la inteligencia artificial para dar
solución al problema encontrado en la clínica Colombiana de obesidad y metabolismo S.A.S.
aprovechando todo el material de las pruebas de análisis, radiografías, tomografías
computarizadas, con el fin que el software, logre determinar de una manera autómata, las
cantidades de lípidos a incorporar o quitar de las áreas a intervenir del paciente. Generando un
acertado diagnóstico clínico preoperatorio. Al cirujano y equipo.
Las características del prototipo se definen en la interacción con ingenieros, programadores, y la
Clínica Colombiana de obesidad y metabolismo s.a.s. para la construcción del diseño a ser
implementado. En una segunda etapa del proyecto se implementa el prototipo y se realizan pruebas
por parte del equipo.

El éxito del Proyecto radica en el empeño y la voluntad que se impartan en satisfacer las
necesidades que surjan, en especial las pertinentes al software y hardware. La estructuración
conceptual de este ambicioso Proyecto tiene que estar respaldada por la infraestructura y
tecnología más competitiva posible.
 Características
 Combina lo real y lo virtual
 Funciona en tiempo real
 Se registra en tres dimensiones
 Autoenfoque para evitar distorsión en la imagen mientras el escáner se encuentra
en movimiento
 Alta precisión en sus resultados.
software propuesto
El tipo de software que se implementara es de Inteligencia Artificial
 Justificación
Este desarrollo de software es conveniente para la clínica ya que es un beneficio para su
rendimiento en sus intervenciones de cirugía corporal y de esta manera minimizar los tiempos
de analices de los pacientes en el escáner brindando así al cirujano un mejor manejo del
paciente y de los equipos que intervienen en la cirugía láser
 ¿Porque?
Por ser una de las necesidades más convenientes para un mejor desempeño de la clínica siendo
más eficiente y dinámico a la hora de intervenir en las cirugías estéticas de los pacientes ya
que apoya al cirujano al saber las cantidades exactas de lípidos corporales.
 Importancia
Permiten al cirujano controlar las funciones más críticas en áreas de cirugía estética, al tener
precisión de las cantidades de lípidos a incorporar o quitar de las áreas a intervenir del paciente.
Con Software de inteligencia artificial, una clínica de estética corporal tiene beneficios como
integración de la información del paciente a intervenir, dándole agilidad en el proceso de estudio
científico corporal de cada paciente, permitiendo estandarizar y agilizar los procesos y tener una
mejora en la administración de las cirugías.
Este tipo de software de inteligencia artificial, permite integrar todas las áreas de la clínica que
intervienen en las cirugías estéticas de sus pacientes. Como: anestesiólogo, enfermeras, gestión
de las relaciones con los pacientes, banco e inventarios de sangre; para que así toda la clínica
trabaje mejor como una sola unidad.
Modelo de proceso de desarrollo para el software
 Metodología ágil
Esta metodología es imperativa a la participación activa de los usuarios, el equipo de desarrollo
debe tener la facultad para tomar decisiones, los requisitos evolucionan, pero la escala de
tiempo y fechas de entregas son fijas (control del alcance), captura los requisitos a un alto
nivel, ligero y visual (prototipos), desarrolla versiones pequeñas, incrementales e itere sobre
ellas, se enfoca en la entrega frecuente de productos, completa cada funcionalidad antes de
pasar a la siguiente, trabaja funcionalidades principales – principio de Pareto, las pruebas se
integran en todo el ciclo de vida del proyecto – prueba temprano y con frecuencia, hay un
enfoque de colaboración y cooperación entre todas las partes interesadas.
 Programación extrema (XP),
constituye un método adecuado para el desarrollo de sistemas, ha sido empleada
principalmente para el desarrollo de sistemas inteligentes que intentan emular ciertas

capacidades del hombre. Así como no somos capaces de entender cómo el hombre realiza
sus tareas, es imposible establecer una especificación detallada para el software que intente
emular el comportamiento humano. La clave del éxito de esta aproximación está en la
utilización de técnicas que permiten realizar iteraciones del sistema rápidamente.
Consiste entonces en diseñar, implementar y programar lo más rápido posible, hasta en
casos se recomienda saltar la documentación y los procedimientos tradicionales. Se
fundamenta en la capacidad del equipo para comunicarse entre sí y las ganas de aprender
de los errores propios inherentes en un programador. XP es un método para equipos
extremadamente pequeños que se centran en un solo cliente.
Los avances tecnológicos han obligado a la medicina a cambiar la forma tradicional de
realizar procedimientos, entre estos cambios se encuentra los procedimientos quirúrgicos,
ya que se ha convertido de vital importancia para evitar malos procedimientos, en este caso
es el problema que radica en la clínica a pesar de ser pioneros en el uso del rayo láser como
una herramienta revolucionaria que ha modificado por completo el concepto de cirugía
plástica, aun no se cuenta con una tecnología en donde indique la cantidad de grasa que
debe ser retirada en cada parte del cuerpo, lo cual al realizar una lipolisis los cirujanos
tienden a retirar grasa del cuerpo que no deben atrofiando los tejidos y la grasa que se debe
eliminar no se retira la cantidad adecuada.
Un software para que controle un escáner, en donde este software realice unos cálculos de
acuerdo a las imágenes y datos del paciente, en donde me indique la cantidad de grasa que
debe ser retirada en cada parte del cuerpo y esta grasa donde podría ser inyectada, en zonas
de la cara y del cuerpo en las que haga falta rellenar o dar forma, que permita poder
modificar, al milímetro, la silueta, tanto de hombres como de mujeres, para darle mayor
realce a los músculos o las zonas que se desee, para quedar lo más natural posible, donde
permita realizar una más delicada manipulación de la grasa y este procedimiento sea de
alta definición de contorno en abdomen y extremidades, resultando en una figura no
solamente mas esbelta sino también muy definida.
Con la información obtenida anteriormente se desarrollará la herramienta capaz de
combinar lo real y lo virtual, ésta será el módulo inicial. En donde el modelo de
programación será Programación Extrema (XP), ya que plantea una forma liviana y
adaptable del proceso, surgió en respuesta a una serie de problemas y necesidades que se
evidencian al llevar a cabo un proyecto de desarrollo de software, la finalidad es minimizar
las dificultades y errores que se presenten específicamente.
La utilidad de esta metodología es para:
 Cuando los clientes no tienen idea clara de los requerimientos y los van cambiando.
 Para proyectos de riesgo: fecha fija de entrega, algo nunca hecho por el grupo, algo
nunca hecho por la comunidad de desarrolladores.
 NO es apto para proyectos con mucho personal.
 Proyectos en que los requisitos tienen altas probabilidades de cambiar con el tiempo
(por ejemplo, porque el cliente no tiene claro lo que quiere, o porque el cambio de
requisitos está ligado al dominio del problema a resolver).
 El objetivo es entregar el software tal cual se necesita y en el momento en que se
necesita. Incidentalmente, los proyectos XP muestran mayor productividad
Donde se cumplirán con los siguientes principios:
 Como primera prioridad es satisfacer al cliente mediante la entrega temprana y continua de
software con valor.

 Aceptar que los requisitos cambien, incluso en etapas tardías del desarrollo, para
proporcionar ventaja competitiva al cliente.
 Entregar software funcional frecuentemente, entre dos semanas y dos meses, con
preferencia al periodo de tiempo más corto posible.
 Los responsables de negocio y los desarrolladores trabajen juntos de forma cotidiana
durante todo el proyecto.
 Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y
el apoyo que necesitan, y confiarles la ejecución del trabajo.
 El método más eficiente y efectivo de comunicar información al equipo de desarrollo y
entre sus miembros es la conversación cara a cara.
 El software funcionando es la medida principal de progreso.
 Los promotores, desarrolladores y usuarios deben ser capaces de mantener un ritmo
constante de forma indefinida.
 La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
Esta metodología trata de dar al cliente el software que él necesita y cuando lo necesita.
Por tanto, se debe responder muy rápido a las necesidades del cliente, incluso cuando los
cambios sean al final de ciclo de la programación.
 Roles XP
 Programador: El programador escribe las pruebas unitarias y produce el código del
sistema. Debe existir una comunicación y coordinación adecuada entre los programadores
y otros miembros del equipo.

 Cliente: El cliente escribe las historias de usuario y las pruebas funcionales para validar su
implementación. Además, asigna la prioridad a las historias de usuario y decide cuáles se
implementan en cada iteración centrándose en aportar mayor valor al negocio.
 Encargado de pruebas (Tester): El encargado de pruebas ayudara al cliente a escribir las
pruebas funcionales.
 Encargado de seguimiento (Tracker): El encargado de seguimiento proporciona
realimentación al equipo en el proceso XP. Su responsabilidad es verificar el grado de
acierto entre las estimaciones realizadas y el tiempo real dedicado, comunicando los
resultados para mejorar futuras estimaciones.
 Entrenador (Coach): Es responsable del proceso global. Es necesario que conozca a fondo
el proceso XP para proveer guías a los miembros del equipo de forma que se apliquen las
prácticas XP y se siga el proceso correctamente.
 Consultor: Es un miembro externo del equipo con un conocimiento específico en algún
tema necesario para el proyecto.
 Gestor (Big boss): Es el vínculo entre clientes y programadores, ayuda a que el equipo
trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de
coordinación.
 PROCESO XP
Un proyecto XP tiene éxito cuando el cliente selecciona el valor de negocio a implementar
basado en la habilidad del equipo para medir la funcionalidad que puede entregar a través
del tiempo. El ciclo de desarrollo consiste (a grandes rasgos) en los siguientes pasos:
 El cliente define el valor de negocio a implementar.
 El programador estima el esfuerzo necesario para su implementación.

 El cliente selecciona qué construir, de acuerdo con sus prioridades y las
restricciones de tiempo.
 El programador construye ese valor de negocio.
 Vuelve al paso 1.
En todas las iteraciones de este ciclo tanto el cliente como el programador aprenden. No se
debe presionar al programador a realizar más trabajo que el estimado, ya que se perderá
calidad en el software o no se cumplirán los plazos.
 El ciclo de vida de XP consiste de seis fases:.
 Fase I: Exploración
En esta fase, los clientes plantean a grandes rasgos las historias de usuario que son de
interés para la primera entrega del producto. Al mismo tiempo el equipo de desarrollo se
familiariza con las herramientas, tecnologías y prácticas que se utilizarán en el proyecto.
 Fase II: Planificación de la Entrega
En esta fase el cliente establece la prioridad de cada historia de usuario, y
correspondientemente, los programadores realizan una estimación del esfuerzo necesario
de cada una de ellas. Se toman acuerdos sobre el contenido de la primera entrega y se
determina un cronograma en conjunto con el cliente.
La planificación se puede realizar basándose en el tiempo o el alcance. La velocidad del
proyecto es utilizada para establecer cuántas historias se pueden implementar antes de una
fecha determinada o cuánto tiempo tomará implementar un conjunto de historias.
 Fase III: Iteraciones
Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El Plan de
Entrega está compuesto por iteraciones de no más de tres semanas. En la primera iteración
se puede intentar establecer una arquitectura del sistema que pueda ser utilizada durante el
resto del proyecto.
 Fase IV: Producción
La fase de producción requiere de pruebas adicionales y revisiones de rendimiento antes
de que el sistema sea trasladado al entorno del cliente. Al mismo tiempo, se deben tomar
decisiones sobre la inclusión de nuevas características a la versión actual, debido a cambios
durante esta fase.
 Fase V: Mantenimiento
Mientras la primera versión se encuentra en producción, el proyecto XP debe mantener el
sistema en funcionamiento al mismo tiempo que desarrolla nuevas iteraciones. Para realizar
esto se requiere de tareas de soporte para el cliente.
Fase VI: Muerte del Proyecto
Es cuando el cliente no tiene más historias para ser incluidas en el sistema. Esto requiere
que se satisfagan las necesidades del cliente en otros aspectos como rendimiento y
confiabilidad del sistema. Se genera la documentación final del sistema y no se realizan
más cambios en la arquitectura.
Planificación del proyecto.
Capítulo I. Gestión de Alcance
1. La gestión del alcance
1.1.1 Recopilación de Requisitos
Link formato IEEE 830
https://drive.google.com/open?id=1E-8Cdxg_kPo4kIj44UrcWeh69ZyIqu9p
1.1.2 Definición del alcance
Objetivo General:
Desarrollar el software de inteligencia artificial para la toma de decisiones del diagnóstico
preoperatorio del paciente de la Clínica Colombiana de obesidad y metabolismo S.A.S.
Descripción alcance del producto
 Características
 Combina lo real y lo virtual
 Funciona en tiempo real
 Se registra en tres dimensiones
 Autoenfoque para evitar distorsión en la imagen mientras el escáner se encuentra
en movimiento
 Alta precisión en sus resultados
 Requisitos funcionales
 Antes de poder usar la aplicación el usuario debe autenticarse en la aplicación con un
nombre de usuario y contraseña
 Al autenticarse, los usuarios estarán organizados desde enfermeras (con el menor
nivel de privilegios), hasta jefe de sistemas (con el máximo nivel de privilegios),
pasando por Mantenimiento que será el nivel intermedio.
 Enfermeras: Proceso completo de detección de errores, no pueden añadir usuarios, no
pueden crear formatos y no pueden acceder al menú de opciones.
 Mantenimiento: Mantienen privilegios de enfermeras, pero también pueden crear
formatos y acceder a opciones. No pueden añadir usuarios nuevos.

 Jefe de sistemas: Mantienen privilegios de Mantenimiento, pero también pueden
añadir y borrar usuarios de la aplicación.
 Los usuarios jefes de sistemas pueden añadir otros usuarios y establecer su nivel y
contraseña.
 Abrir en un menú independiente las distintas opciones que se han pedido para que el
menú principal no esté recargado y para que solo los usuarios de nivel Mantenimiento
y jefe de sistemas puedan cambiar las opciones.
 La clínica escaneará mujeres y hombres con una velocidad de escaneo baja para que
el sistema revise detenidamente el paciente
 Desde el menú principal se podrá previsualizar el escaneo y escoger el área a escanear
 Desde el menú principal se podrá escanear los pacientes de manera fácil
 Todas las opciones seleccionadas en el programa para el escaneo podrán ser
guardadas en un documento de formato
 El algoritmo de comparación que se use tiene una serie de características
configurables, que es Umbral de similitud que funcionan juntos para saber cómo de
diferente debe ser lo encontrado respecto a lo esperado
 La imagen recién escaneada debe estar mostradas siempre para asegurarse que sea el
paciente al que le están realizando el estudio.
 En el menú de visualización de zonas debemos añadir un zoom en forma de imagen
dinámica al lateral para poder ver mejor al paciente.
 Requisitos no funcionales
 Carga de Internet
 Idioma
 Lenguaje de desarrollo
 Versión de S.O.
 El escáner deber poder escanear tejidos blandos
 Se autenticará al usuario mediante usuario y contraseña a indicar por el cliente.
Especificaciones:
 Se recomienda utilizar el software sobre sistemas operativos Windows
Fronteras del proyecto
Con este Software de inteligencia artificial, la clínica de estética corporal tendrá beneficios como
integración de la información del paciente a intervenir, dándole agilidad en el proceso de estudio
científico corporal de cada paciente, permitiendo estandarizar y agilizar los procesos y tener una
mejora en la administración de las cirugías.
Este tipo de software, permite integrar todas las áreas de la clínica que intervienen en las cirugías
estéticas de sus pacientes. Como: anestesiólogo, enfermeras, gestión de las relaciones con los
pacientes, banco e inventarios de sangre; para que así toda la clínica trabaje mejor como una sola
unidad.
Entregables del proyecto
 Dos discos con el software para la instalación.
 Guía de instalación.
 Guía de manejo del software
Criterios de aceptación de entregables
El software se considera entregado si:

 Se puede instalar el software en los equipos
 Se puede ingresar a la información del paciente
 La apariencia de la información del paciente es la definida por el administrador.
La guía de Instalación será aceptada si:
 Si explica cómo realizar la instalación del software
Guía de manejo de software será aceptada si:
 Si explica el manejo y las diferentes opciones del software
 Si explica cómo dar inicio al proceso de escaneo.
Limitaciones o restricciones del proyecto
 Se instalará el software en los equipos de la Clínica Colombiana de Obesidad y
Metabolismo.
 Este proyecto está pensado solo para los cirujanos plásticos de la Clínica.
 Este software solo será probado en los equipos de la Clínica.
 Este software será probado en equipos Windows 10
Asunciones del proyecto
 Este software se entregará en CD e instalado en los equipos que se destinen a este fin en el
momento de la entrega.
 El mantenimiento e instalaciones posteriores a la entrega del software estarán a cargo de la
Clínica Colombiana de Obesidad y Metabolismo.

1.1.3 Creación EDT (WBS) Estructura desagregada del trabajo-Work Break Down
Software para la
Clinica Colombiana
de Obesidad y
Metabolismo
1. REQUISITOS 4. PRRUEBAS 5.
2. DISEÑO 3. DESARROLLO IMPLEMENTACIÓN
Y ENTREGA
2.1 3.1 4.1

1.1 5.1
Diseño inicial Seleccion de Selección de
Análisis de Reporte de
programas de objetivos a
requisitos ejecución
desarrollo evaluar
1.2 5.2
Especificaciones 2.2 3.2 4.2 Pruebas
de generales Pruebas
Diseño tecnico Division modular
funcionamiento preliminares
1.3 3.3 5.3

2.3 4.3 Pruebas de
Requerimientos Creación de Formación al
Diseño final usuario
Funcionales prototipos personal
1.4
3.4
Requerimientos 4.4 Certificación 5.4
no Creación de técnica Acta de entrega
manuales
funcionales
1.1.4 Control del Alcance
Plan de control de cambios:
Si se necesita hacer algún cambio en el proyecto debe seguir el siguiente procedimiento.
Llenar un formato de cambios:
Solicitud de cambio
Solicitante: Fecha:
Cedula:
Cambio Justificación Procesos que afecta
Recibió:
Entregarlo al responsable del proyecto
Aprobación de cambio:
Para la aprobación de cualquier cambio se contará con el análisis por parte de.
 Directivos de la Clínica Colombiana de Obesidad y Metabolismo
 Los encargados del proyecto
 Los desarrolladores del proyecto
Si se considera pertinente el cambio se realizará los ajustes al proyecto para que estos cambios
sean adaptados a: EDT, Cronograma y presupuesto.
Una vez ajustado el cambio se comunicará para que puedan ser realizadas las modificaciones.
1.1.5 Verificación del alcance
Una vez realizado el proyecto se verificará que se ha cumplido con los objetivos propuestos así:
VERIFICACIÓN DEL ALCANCE

Criterios a verificar cumplió No cumplió A mejorar
Se puede ingresar a los datos del paciente
Se puede guardar los datos tomados
Se puede ajustar los datos
La apariencia de las imágenes tomadas son
claras
Se cuenta con los manuales
Los manuales son claros para el usuario
Capítulo I I. Gestión del Tiempo
2.2.1 Identificación de actividades

 Análisis de requisitos.
 Especificaciones de funcionamiento
 Requerimientos funcionales
 Requerimientos no funcionales
 Diseño inicial
 Diseño técnico
 Diseño final
 Selección de programas de desarrollo
 División modular
 Creación de prototipos
 Creación de manuales
 Selección de objetivos a evaluar
 Pruebas generales
 Pruebas de usuario
 Certificación técnica
 Reporte de ejecución
 Pruebas preliminares
 Formación al personal
 Acta de entrega
2.2.2 Secuenciamiento de actividades
Con el método PDM
Especificaciones
Análisis de Requerimientos Requerimientos
de
requisitos funcionales no funcionales
funcionamiento
Diseño Inicial Diseño técnico Diseño final
Selección de División Creación Creación de

programas de modular de Manuales
desarrollo prototipos
INICIO FIN
Selección de Pruebas Pruebas de Certificación

objetivos a generales usuario técnica
evaluar Garantía
Reporte de
ejecución Pruebas Formación al Acta de
preliminares personal entrega
2.2.3 Estimación de recursos de las actividades
Nombre del Tipo Disponibilidad Necesidad

recurso
Director del Humano 1 1
proyecto
Diseñador Humano 1 1
Programador Humano 1 2
Analista Humano 1 1
Instalaciones Físico 1 1
Computadores Equipo 4 4
Licencias Físico 4 4
Sistema operativo Físico 4 4
Windows 10
2.2.4 Estimación duración de tiempo
El proyecto está estimado para elaborarse en 15 semanas, en donde está compuesto por 5 etapas
cada una se realizara de a tres semanas, dentro de cada etapa se ejecutara las siguientes
actividades correspondientes.
2.2.5 Desarrollo cronograma (Project Schedule)
2.2.6 Control del cronograma
Para poder realizar el control del cronograma se hará seguimientos semanales con el fin de realizar
ajustes y mejoras en las actividades que lo requieran.
Se debe informar al responsable del calendario sobre el adelanto de actividades para reorganizarlo
en caso de retrasos en el proceso de desarrollo.
Actividad Duración Duración Comienzo Comienzo Fin Fin % Observ

programada real programado real progra real aciones
(días) (días) mado ejecuta
do
Capítulo I I I. Gestión de Costes

Nombre de la Costo fijo Acumulació Costo total Previsto Variación Real Restante
tares n de costos
fijos
Problema $0 Prorrateo $0,0 $0,0 $0,0 $0,0 $0,0
propuesto
Levantamient $2.000.000 Prorrateo $2.000.000 $0,0 $2.000.000 $0,0 $2.000.000
o de
Información
Tipo de $0,0 Prorrateo $0,0 $0,0 $0,0 $0,0 $0,0
software
Modelo de $0,0 Prorrateo $0,0 $0,0 $0,0 $0,0 $0,0
desarrollo
Descripción $0,0 Prorrateo $0,0 $0,0 $0,0 $0,0 $0,0
general del
proyecto
Elaboración $500.000 Prorrateo $500.000 $0,0 $500.000 $0,0 $500.000
de la gestión
de Alcance
de la gestión
de tiempo
de la gestión
de costos
Elección de $0,0 Prorrateo $0,0 $0,0 $0,0 $0,0 $0,0
herramientas
de diseño
Diseño del $8.000.000 Prorrateo $8.000.000 $0,0 $8.000.000 $0,0 $8.000.000
Software
Construcción $20.000.00 Prorrateo $20.000.00 $0,0 $20.000.00 $0,0 $20.000.000
del software 0 0 0
Construcción $200.000 Prorrateo $200.000 $0,0 $200.000 $0,0 $200.000
de manuales
Prueba y $6.000.000 Prorrateo $6.000.000 $0,0 $6.000.000 $0,0 $6.000.000
ajustes
Entrega de $0,0 Prorrateo $0,0 $0,0 $0,0 $0,0 $0,0
software
Costo total 37.700.000
Capítulo IV. Gestión de riesgos
La Gestión de los Riesgos del Proyecto de software de ingeniería artificial para la Clínica
Colombiana de Obesidad y Metabolismo S.A.S incluirá los procesos relacionados con la
planificación de la gestión de riesgos. Así como, la identificación, análisis y la planificación de
respuestas a los mismos. Estos procesos se actualizan durante el ciclo de vida del Proyecto.
Los objetivos de la Gestión de los Riesgos del Proyecto de software de ingeniería artificial son:
1. Disminuir la probabilidad y el impacto de los eventos negativos.
2. Aumentar la probabilidad y el impacto de los eventos positivos.

3. Realizar estrategias de respuesta ante las contingencias que se puedan presentar en la
ejecución del proyecto.
Para la gestión de riesgos del proyecto software de inteligencia artificial para la Clínica Colombiana
de Obesidad y Metabolismo S.A.S se implementará la siguiente metodología con los procesos de
identificación, análisis cualitativo, plan de respuesta y control y seguimiento de los riesgos,
sustentada en la guía del PMBOK. Ver en la ilustración 1.
4.2
Planificar la gestión de riesgos
Ilustración 1 Diagrama de planificación del riesgo
Según Project Management Institute (2013) La Gestión de los Riesgos del Proyecto incluye los
procesos para llevar a cabo la planificación de la gestión de riesgos, así como la identificación,
análisis, planificación de respuesta y control de los riesgos de un proyecto. Los objetivos de la
gestión de los riesgos del proyecto consisten en aumentar la probabilidad y el impacto de los eventos
positivos, y disminuir la probabilidad y el impacto de los eventos negativos en el proyecto (p.309)

Planificar la Gestión de Riesgos
Consiste en definir cómo realizar las actividades de gestión de los riesgos para un Proyecto.
Identificar los Riesgos

Consiste en determinar los riesgos que pueden afectar el Proyecto y documentar sus características
Realizar el Análisis Cualitativo de Riesgos

Consiste en priorizar los riesgos para realizar otros Evaluando y combinando la probabilidad de ocurrencia
análisis o acciones posteriores y el impacto de dichos riesgos
Realizar el Análisis Cuantitativo de Riesgos
Consiste en analizar numéricamente el efecto de los riesgos identificados sobre los objetivos generales del Proyecto.
Planificar la Respuesta a los Riesgos
Consiste en desarrollar opciones y acciones para mejorar las oportunidades y reducir las amenazas a los objetivos del Proyecto.
Monitorear y Controlar los Riesgos

Esto permite identificar nuevos riesgos y evaluar la efectividad
Consiste en implementar planes de respuesta a los riesgos.
del proceso contra riesgos a través del Proyecto.
Ilustración 2 Procesos de la Gestión de los Riesgos del Proyecto
4.3 Identificar los riesgos del proyecto
Según Project Management Institute (2013) Identificar los Riesgos es el proceso de determinar los
riesgos que pueden afectar al proyecto y documentar sus características. El beneficio clave de este
proceso es la documentación de los riesgos existentes y el conocimiento y la capacidad que confiere
al equipo del proyecto para anticipar eventos (p.318)
4.3.1 Lista de riesgos identificados

ID Lista de riesgos
1 Desconocimiento del software a utilizar en la construcción de la aplicación.
2 Pérdidas de información por fallas de Hardware o Software.
3 Insatisfacción por parte del Cliente de la interfaz usuaria.
4 Necesidad de cambiar la herramienta de desarrollo durante el proyecto.
5 Mala estimación de costos de desarrollo de la aplicación.
6 Falta de recursos de hardware específicos (impresora, entre otros).
7 Número de usuarios del producto
8 Grado de seguridad en la estimación del tamaño
9 Tamaño de la base de datos creada o empleada por el producto
10 Tamaño estimado del producto en número de programas, archivos y
transacciones
11 Costos asociados por retraso en la entrega
12 Costos asociados con un producto
defectuoso
13 Limitaciones gubernamentales en la construcción del producto
14 Número de clientes que usarán este producto
15 Entiende el cliente el proceso del software
16 Problemas de comunicación entre los integrantes del equipo.
17 Falta de disponibilidad de un integrante del equipo de trabajo.
18 Inexperiencia en desarrollo de proyectos de software por parte de los
desarrolladores.
19 Falta de disponibilidad por parte del Cliente para participar en reuniones con los
desarrolladores.
20 Mal dimensionamiento del problema (el problema es más grande de lo
pensado).
21 Sobredimensionamiento de las capacidades de las herramientas a utilizar.
22 Cambio en los requerimientos.
23 Mala calendarización (estimación de plazos).
24 Falta de disponibilidad de la metodóloga en enseñanza y aprendizaje.
25 Escaso entendimiento del proceso del software por parte del Cliente.
26 Problemas de salud de algún integrante del equipo de trabajo.
27 Conflictos al interior del equipo de trabajo.
28 Abandono por parte del diseñador de apoyo en el desarrollo del proyecto.
29 Abandono definitivo por parte de algún integrante del equipo.
30 Plan de capacitación insuficiente
31 Cambio de requisitos
32 Escatimar en la calidad
33 Diseño inadecuado
34 Diferencias con los clientes
35 Cronogramas imposibles de cumplir
36 No hay una persona responsable de todo el proyecto
37 Pobre control de los cambios de diseño
38 Problemas con los miembros del equipo
39 Pobre control de los cambios de clientes

40 Prioridades del proyecto en conflicto
41 Planeamiento y control no integrados
42 Oficina de proyectos mal organizada
43 Cambios tecnológicos
44 Riesgos derivados de los procesos de diseño
ID Externos
45 Impredecibles
46 Requisitos regulatorios inesperados
47 Desastres naturales
48 Vandalismo, sabotaje o efectos secundarios impredecibles
ID Predecibles
49 Riesgos del mercado u operacionales
50 Riesgo social
51 Riesgo ambiental
52 Medios de comunicación
53 Inflación
54 Fluctuaciones en la divisa
ID Técnicos
55 Falta de recursos de Hardware específicos (impresora, entre otros).
56 Sobredimensionamiento de las capacidades de las herramientas a utilizar.
57 Plan de capacitación insuficiente
58 Cambios tecnológicos
59 Riesgos derivados de los procesos de diseño

ID Legal
60 Uso no autorizado de marcas y licencias
61 Demandas por ruptura de contrato
62 Problemas con la fuerza laboral o el lugar de trabajo
63 Legislación
4.4 Análisis Cualitativo
Para este proceso se toma como entrada la lista de riesgos identificados y se analiza en cada una de
las fases. Se utiliza la tabla de probabilidad con cinco niveles, esta ubica el riesgo en un nivel de
ocurrencia, los cuales son raro, improbable, posible, probable, casi seguro, como se muestra en la
siguiente tabla:
Tabla 1. Niveles de Probabilidad
NIVEL DESCRIPTOR DESCRIPCION
1 Raro El evento puede ocurrir sólo en circunstancias excepcionales.
2 Improbable El evento puede ocurrir en algún momento.
3 Posible El evento podría ocurrir en algún momento
4 Probable El evento probablemente ocurrirá en la mayoría de las
circunstancias.
5 Casi seguro Se espera que en evento ocurra en la mayoría de las
circunstancias.
Fuente. Basado en la guía del PMBOK
Para medir el nivel de impacto causado por los riesgos en el momento de llegarse a realizarse, los
cuales pueden afectar directamente los objetivos del proyecto, como alcance, tiempo, costo y
calidad. Para esta establecer esta medida se utiliza la tabla de impactos donde se especifican cuatro
niveles Despreciable, Marginal, Crítico, Catastrófico, estos se muestran en la siguiente tabla.
Tabla 2. Niveles de impacto
NIVEL DESCRIPTOR DESCRIPCION
1 Despreciable Si el hecho llegara a presentarse, tendría consecuencias o
efectos mínimos.
2 Marginal Si el hecho llegara a presentarse, tendría bajo impacto.
3 Critico Si el hecho llegara a presentarse, tendría alto impacto.
4 Catastrófico Si el hecho llegara a presentarse, tendría desastrosas
consecuencias.
Para calificar cada uno de los riesgos identificados se realiza la matriz de probabilidad e impacto,
en esta se refleja la multiplicación del valor numérico del nivel de probabilidad de ocurrencia del
riesgo por el nivel numérico del impacto del riesgo sobre los objetivos, este resultado es el que
determina el nivel del riesgo.
Tabla 3. Probabilidad e Impacto.
IMPACTO
PROBABILIDAD Catastrófico
Despreciable 1 Marginal 2 Crítico 3
4
Raro 1
Improbable 2
Posible 3
Probable 4
Casi seguro 5
Con base en el resultado de la matriz de probabilidad e impacto, se propone una escala numérica la
cual permite clasificar el riesgo según su nivel, estos pueden ser muy bajo, bajo, medio, alto, y muy
alto.
Tabla 4. Nivel de Riesgo
NIVEL DE RIESGO PROBABILIDAD X IMPACTO
Muy Alto >80
Alto 51- 80
Medio 31-50
Bajo 11- 30
Muy Bajo <10
Categorías
Tamaño del producto (TP)
Impacto en la organización (IO)
Tipo de cliente (TC)
Proceso de producción (PP)
Entorno de desarrollo (ED)
Tecnología (T)
Experiencia técnica (ET) Tablas de riesgos
RIESGOS CATEGORIA PROBABILIDAD IMPACTO

1 Desconocimiento del software a
utilizar en la construcción de la ET 45% 3
aplicación.
2 Pérdidas de información por

IO 30% 3
fallas de Hardware o Software.
3 Insatisfacción por parte del

TC 25% 2
Cliente de la interfaz usuaria.
4 Necesidad de cambiar la
herramienta de desarrollo durante ED 55% 3
el proyecto.
5 Mala estimación de costos de

PP 65% 4
desarrollo de la aplicación.
6 Falta de recursos de hardware
específicos (impresora, entre T 20% 2
otros).
7 Número de usuarios del producto TP 45% 3
8 Grado de seguridad en la
TP 46% 3
estimación del tamaño
9 Tamaño de la base de datos
creada o empleada por el TP 60% 4
producto
10 Tamaño estimado del producto en
número de programas, archivos y TP 40% 3
transacciones
11 Costos asociados por retraso en la

IO 65% 4
entrega
12 Costos asociados con un producto

IO 65% 4
defectuoso
13 Limitaciones gubernamentales en
IO 50% 3
la construcción del producto
14 Número de clientes que usarán

IO 45% 3
este producto
15 Entiende el cliente el proceso del

TC 25% 2
software
16 Problemas de comunicación
ED 25% 2
entre los integrantes del equipo.
17 Falta de disponibilidad de un
ED 25% 2
integrante del equipo de trabajo.
18 Inexperiencia en desarrollo de
proyectos de software por parte ET 25% 2
de los desarrolladores.
19 Falta de disponibilidad por parte
del Cliente para participar en TC 35% 3
reuniones con los desarrolladores.

20 Mal dimensionamiento del
problema (el problema es más TP 55% 4
grande de lo pensado).
21 Sobredimensionamiento de las
capacidades de las herramientas a T 48% 3
utilizar.
22 Cambio en los requerimientos. PP 70% 4
23 Mala calendarización
PP 50% 3
(estimación de plazos).
24 Falta de disponibilidad de la
metodóloga en enseñanza y ED 45% 3
aprendizaje.
25 Escaso entendimiento del proceso

IO 45% 3
del software por parte del Cliente.
26 Problemas de salud de algún

ED 25% 2
integrante del equipo de trabajo.
27 Conflictos al interior del equipo

ED 25% 2
de trabajo.
28 Abandono por parte del diseñador
de apoyo en el desarrollo del ED 25% 2
proyecto.
29 Abandono definitivo por parte de

ED 50% 3
algún integrante del equipo.
30 Plan de capacitación insuficiente ED 25% 2
31 Cambio de requisitos PP 70% 4
32 Escatimar en la calidad PP 60% 4
33 Diseño inadecuado ET 70% 4
34 Diferencias con los clientes PP 60% 4
35 Cronogramas imposibles de
ED 70% 4
cumplir
36 No hay una persona responsable

IO 75% 4
de todo el proyecto
37 Pobre control de los cambios de

ET 55% 4
diseño
38 Problemas con los miembros del

ED 25% 2
equipo
39 Pobre control de los cambios de

ET 35% 3
clientes
40 Prioridades del proyecto en

IO 50% 3
conflicto
41 Planeamiento y control no
PP 70% 4
integrados
42 Oficina de proyectos mal

ED 35% 3
organizada
43 Cambios tecnológicos T 60% 4

44 Riesgos derivados de los
ET 50% 3
procesos de diseño
ID Externos
45 Impredecibles IO 70% 4
46 Requisitos regulatorios
IO 70% 4
inesperados
47 Desastres naturales IO 70% 4
48 Vandalismo, sabotaje o efectos

IO 70% 4
secundarios impredecibles
ID Predecibles
49 Riesgos del mercado u

IO 50% 3
operacionales
50 Riesgo social IO 50% 3
51 Riesgo ambiental IO 50% 3
52 Medios de comunicación IO 35% 3
53 Inflación IO 40% 3
54 Fluctuaciones en la divisa IO 40% 3
ID Técnicos
55 Falta de recursos de Hardware
específicos (impresora, entre T 35% 3
otros).
56 Sobredimensionamiento de las
capacidades de las herramientas T 45% 3
a utilizar.
57 Plan de capacitación insuficiente T 45% 3
58 Cambios tecnológicos T 60% 4
59 Riesgos derivados de los

T 70% 4
procesos de diseño
ID Legal
60 Uso no autorizado de marcas y

IO 50% 3
licencias
61 Demandas por ruptura de

IO 70% 4
contrato
62 Problemas con la fuerza laboral o

IO 25% 2
el lugar de trabajo
63 Legislación IO 30% 2
Planificación respuesta:
Riesgos Eliminación, transferencia, mitigación, aceptación, observaciones
RIESGOS Elimi Transf Mitig Acepta OBSERVACIONES
nació erencia ación ción
1 Desconocimiento del software a x La aplicación requiere herramientas de
utilizar en la construcción de la programación que los integrantes del
aplicación. equipo de desarrollo conocen poco, lo que
dificulta y demora el correcto desarrollo
del proyecto, además de obligar a incurrir
en costos adicionales para asistir a cursos
2 Pérdidas de información por fallas de x La experiencia dice que siempre y en el
Hardware o Software. momento menos esperado, algo falla

(disquetes, computador, entre otros.) lo que
podría atentar contra el normal desarrollo
del proyecto, e incluso obligar a una
replanificación.
3 Insatisfacción por parte del Cliente x Todo el análisis que gira en torno a la
de la interfaz usuaria. calidad y la satisfacción se basa en las
percepciones del cliente acerca del
servicio. el concepto básico es el de
"servicio percibido" tal como se analiza en
el modelo de las brechas sobre la calidad
en el servicio.
4 Necesidad de cambiar la herramienta x Cambio de herramientas de desarrollo por
de desarrollo durante el proyecto. no cumplir con la funcionalidad necesaria
para la aplicación, obligaría a realizar el

estudio de una herramienta nueva, lo que
implica una replanificación.
6 Falta de recursos de hardware x La ocurrencia del riesgo es probable, o el
específicos (impresora, entre otros). impacto en el proyecto es considerable,
pero no determinante
11 Costos asociados por retraso en la x se generan por corregir defectos de los
entrega productos
12 Costos asociados con un producto x Son los costos causados por defectos en el
Defectuoso producto que no reunieron las
especificaciones de calidad y suceden antes
de entregarle un producto al cliente.
18 Inexperiencia en desarrollo de x El hecho de tener poca experiencia en el
proyectos de software por parte de desarrollo de productos de software, afecta
los desarrolladores. en cada etapa del proceso, ya que las
actividades a seguir necesitan de práctica

para avanzar con confianza y obtener un
resultado exitoso en los plazos estimados.
19 Falta de disponibilidad por parte del x La falta de disponibilidad del Cliente
Cliente para participar en reuniones afecta el desarrollo normal del proyecto, ya
con los desarrolladores. que es una persona fundamental para llevar
a cabo la comprobación de los
requerimientos del producto de software.
20 Mal dimensionamiento del problema x Este problema puede ser causa de una mala
(el problema es más grande de lo comunicación con el Cliente y de la escasa
pensado). experiencia en el uso de herramientas de
dimensionamiento de problemas, lo que
provoca que los desarrolladores asignen
recursos que posteriormente no sean
suficientes para cubrir las tareas requeridas
al abordar el problema real.

22 Cambio en los requerimientos. x Para un proceso de desarrollo de software
lo más importante es la especificación de
requerimientos, ya que si esta se modifica,
cambia la solución del problema, y si en el
proyecto el Cliente manifestará cambios en
sus necesidades, obligaría a cambiar toda
la planificación del proyecto.
23 Mala calendarización (estimación de x El hecho de no cumplir cualquiera de los
plazos). plazos genera inevitablemente atrasos en la
entrega final y afecta el objetivo del
proyecto
28 Abandono por parte del diseñador de x El alejamiento o abandono del diseñador,
apoyo en el desarrollo del proyecto. influye negativamente en el desarrollo del
proyecto, debido a que no se encontrará
para responder las dudas que se susciten.

29 Abandono definitivo por parte de x El abandono de algún integrante del
algún integrante del equipo. equipo, afecta enormemente el desarrollo
del proyecto, debido a que alteraría en
forma abrupta la planificación de tareas.

Riesgos más prioritarios
ID Riesgo Prioridad
1 Desconocimiento del software a utilizar en la construcción de la 3
aplicación.
2 Pérdidas de información por fallas de Hardware o Software. 3
3 Insatisfacción por parte del Cliente de la interfaz usuaria. 2
4 Necesidad de cambiar la herramienta de desarrollo durante el proyecto. 3
11 Costos asociados por retraso en la entrega 4
12 Costos asociados con un producto 4
Defectuoso
18 Inexperiencia en desarrollo de proyectos de software por parte de los 2
desarrolladores.
19 Falta de disponibilidad por parte del Cliente para participar en reuniones 3
con los desarrolladores.
20 Mal dimensionamiento del problema (el problema es más grande de lo 4
pensado).
22 Cambio en los requerimientos. 4
23 Mala calendarización (estimación de plazos). 3
28 Abandono por parte del diseñador de apoyo en el desarrollo del 2
proyecto.
29 Abandono definitivo por parte de algún integrante del equipo. 3
Tabla de Riesgos más Prioritarios
Priorización de los Riesgos:
Riesgos para controlar, para los cuales se generarán los planes de mitigación (evitar que
ocurra el riesgo) y contingencia (acciones a seguir si el riesgo se materializa)
correspondientes, con el fin de poder controlar la ocurrencia de los riesgos que podrían
provocar un retraso en el tiempo de duración del proyecto, poner en peligro el desarrollo de
éste o llevarlo al fracaso.
Control de riesgos
ID: 1 Hoja de control de riesgo Fecha de identificación:
d/m/a
Prioridad: 3 Descripción: Desconocimiento del software a utilizar en la
Probabilidad: construcción de la aplicación
45%
Impacto: Medio
Período: Detectado por: Clasificación:
Construcción y Asignado a:
Adaptación
Contexto: La aplicación requiere herramientas de programación que los integrantes del
equipo de desarrollo conocen poco, lo que dificulta y demora el correcto desarrollo del
proyecto, además de obligar a incurrir en costos adicionales para asistir a cursos

Plan de Mitigación: Aprender a utilizar estas herramientas mediante cursos, lecturas e
investigación en general.
Plan de Contingencia: Conseguir asesoramiento en lenguajes de programación y
replanificar tareas
Gatillador: no conocer las herramientas de programación al comenzar el desarrollo del
proyecto
Estado: Presente
Aprobado por: Fecha de cierre: Información de cierre:
d/m/a
Prioridad: 3 Descripción: Pérdidas de información por fallas de hardware o por
Probabilidad: software
Impacto:
Período: Todo el Detectado por: Clasificación:
proyecto Asignado a:
Contexto: La experiencia dice que siempre y en el momento menos esperado, algo falla
(disquetes, computador, entre otros.) lo que podría atentar contra el normal desarrollo del
proyecto, e incluso obligar a una replanificación.
Plan de Mitigación: Hacer respaldos de información en forma periódica
Plan de Contingencia: Asesoramiento de personal experto en recuperación de archivos.
Replanificación de tareas en caso de pérdidas importantes.

Gatillador: Cualquier dificultad técnica, como por ejemplo, que falle el equipo, que un
disquete se dañe, que se corte la luz sin haber grabado la información
Estado: Latente
d/m/a
Prioridad: 2 Descripción: Insatisfacción por parte del Cliente de la interfaz
Probabilidad: usuaria
Impacto:
Período: Etapa Detectado por: Clasificación:
evaluación del Cliente Asignado a:
Contexto: El Cliente tiene una alto nivel de exigencia con respecto al diseño de la
interfaz de usuario, lo que hace probable que ésta no sea de su agrado.
Plan de Mitigación: Construcción de prototipo inicial y planificación de reuniones
periódicas para mantener comunicación constante con el Cliente. Además de conseguir
asesorías de un diseñador gráfico.
Plan de Contingencia: Se realizan los cambios correspondientes.
Gatillador: El Cliente manifiesta descontento con respecto a la interfaz usuaria.
Estado: Latente

d/m/año
Prioridad: 3 Descripción: Necesidad de cambiar la herramienta de desarrollo
Probabilidad: durante el proyecto.
Impacto:
Período: Detectado por: Clasificación:
Ingeniería y Asignado a:
Construcción
Contexto: Cambio de herramientas de desarrollo por no cumplir con la funcionalidad
necesaria para la aplicación, obligaría a realizar el estudio de una herramienta nueva, lo
que implica una replanificación.
Plan de Mitigación: Investigar y seleccionar una nueva herramienta de desarrollo, y
capacitar en caso de ser necesario
Plan de Contingencia: Cambiar de herramienta, replanificar el proyecto y asignar
nuevas responsabilidades y tareas.
Gatillador: La herramienta elegida no sirve para desarrollar la solución planificada.
Estado: Latente
d/m/a
Prioridad: 2
Probabilidad: Descripción: Inexperiencia en desarrollo de proyectos de software
25% por parte de los desarrolladores.
Impacto: bajo
Contexto: El hecho de tener poca experiencia en el desarrollo de productos de software,
afecta en cada etapa del proceso, ya que las actividades a seguir necesitan de práctica
para avanzar con confianza y obtener un resultado exitoso en los plazos estimados.
Plan de Mitigación: Realizar cursos en áreas en que los desarrolladores necesiten mayor
apoyo
Plan de Contingencia: Reformular las tareas y buscar apoyo en proyectos anteriores
Gatillador: Mala realización de una tarea durante el proceso de desarrollo
Estado: Latente
d/m/a
Prioridad: 6 Descripción: Falta de disponibilidad por parte del Cliente para
Probabilidad: participaren reuniones con los desarrolladores
Impacto:
Contexto: La falta de disponibilidad del Cliente afecta el desarrollo normal del
proyecto, ya que es una persona fundamental para llevar a cabo la comprobación de los
requerimientos del producto de software.
Plan de Mitigación: Hacer una buena planificación de las reuniones para obtener en
poco tiempo, la información necesaria y relevante para el normal desarrollo del
proyecto.
Plan de Contingencia: Establecer medios de comunicación en caso de ausencia física del
Cliente (teléfono y e-mail)
Gatillador: Viaje del Cliente o cualquier causa de ausencia (enfermedad, reunión de
trabajo)
Estado: Latente
d/m/a
Prioridad: 3 Descripción: Mal dimensionamiento del problema (el problemas es
Probabilidad: 0.7 más grande de lo pensado)
Impacto: MA
Contexto: Este problema puede ser causa de un mala comunicación con el Cliente y de
la escasa experiencia en el uso de herramientas de dimensionamiento de problemas, lo
que provoca que los desarrolladores asignen recursos que posteriormente no sean
suficientes para cubrir las tareas requeridas al abordar el problema real.
Plan de Mitigación: Planificar reuniones para lograr una buena comunicación con el
Cliente (entrevistas), construyendo minutas con los acuerdos y compromisos logrados, y
dando buen uso a las herramientas de dimensionamiento (Puntos de función,
COCOMO).
Plan de Contingencia: Establecer nuevos acuerdos con el Cliente y acotar el campo de
acción.
Gatillador: Incumplimiento de hitos o plazos establecidos en la Carta Gantt
Estado: Latente
d/m/a
Prioridad: 4 Descripción: Cambio en los requerimientos
Probabilidad: 0.6
Impacto: MA
Contexto: Para un proceso de desarrollo de software lo más importante es la
especificación de requerimientos, ya que si esta se modifica, cambia la solución del
problema, y si en el proyecto el Cliente manifestará cambios en sus necesidades,
obligaría a cambiar toda la planificación del proyecto.
Plan de Mitigación: Llegar a acuerdos firmados mediante entregas formales en los
cuales queden estipulados los requerimientos y los objetivos a cumplir. Todo esto debe
quedar planificado desde un comienzo.
Plan de Contingencia: Se muestran los documentos firmados al Cliente y se llega a un
acuerdo en el cual ambas partes (desarrollador y Cliente) queden conformes.
Gatillador: Cambio inesperado de las necesidades e ideas del Cliente con respecto a la
solución del problema.
Estado: Latente
d/m/a
Prioridad: 2 Descripción: Mala calendarización (estimación de plazos)
Probabilidad: 0.9
Impacto: MA
Contexto: El hecho de no cumplir cualquiera de los plazos genera inevitablemente
atrasos en la entrega final y afecta el objetivo del proyecto

Plan de Mitigación: Control y vigilancia al equipo de trabajo para el cumplimiento de
los plazos estimados, mediante reuniones de coordinación y una buena planificación y
evaluación de funciones y tareas.
Plan de Contingencia: Replanificación de tareas
Gatillador: Incumplimiento de un hito en lo estipulado en la carta Gantt
Estado: Latente
d/m/a
Prioridad: 5 Descripción: Alejamiento o abandono por parte del diseñador de
Probabilidad: 0.5 apoyo en el desarrollo del proyecto
Impacto: MA
Contexto: El alejamiento o abandono del diseñador, influye negativamente en el
desarrollo del proyecto, debido a que no e encontrará para responder las dudas que se
susciten.
Plan de Mitigación: Hacer una buena planificación de las reuniones para obtener la
información necesaria y relevante para el normal desarrollo del proyecto.
Plan de Contingencia: Establecer medios de comunicación en caso de ausencia física del
diseñador (teléfono y e-mail).
Gatillador: Viaje o cualquier causa de ausencia (enfermedad, reunión de trabajo)

Estado: Latente
d/m/a
Prioridad: 3 Descripción: Abandono definitivo por parte de algún integrante del
Probabilidad: equipo
Impacto:
Contexto: El abandono de algún integrante del equipo, afecta enormemente el desarrollo
del proyecto, debido a que alteraría en forma abrupta la planificación de tareas.
Plan de Mitigación: Desarrollar una fuerte motivación y compromiso por parte de todos
los integrantes del equipo, para así cumplir con el objetivo de terminar el proyecto.
Plan de Contingencia: Hacer una replanificación de asignación de tareas.
Gatillador: Cualquier causa de ausencia (enfermedad, abandono)
Estado: Latente

Conclusiones
Respuesta Marco Tulio Palomo:
Como estudiante logre ver la importancia que tiene la planificación en la toma de decisiones
primordiales para el desarrollo del documento de planificación del software de inteligencia
artificial, me sirvió para realizar varias las diferentes tareas repartidas o escogidas, por cada
una de sus integrantes, a lo largo de su desarrollo, con lo cual se logra cumplir con los
objetivos y metas propuestas para su elaboración y entrega.
A lo largo del curso aprendí, que un proyecto de ingeniería de software consiste en la
ordenación de un conjunto de actividades relacionadas entre sí, en primer lugar encontré la
fase de exploración en donde logre implementar la descripción del problema a resolver el
tipo de software, la metodología a utilizar, en la segunda fase el diagnostico se procedió a
realizar el planteamiento formal del proyecto y del problema a resolver, y en la tercera fase
la planificación conlleva asignar la organización para su correcto desarrollo, porque reduce
la incertidumbre, minimiza los riesgos y ayuda a generar compromiso y motivación para
poder realizarlo dentro de los límites de un presupuesto y tiempos establecidos.
Con la elaboración de este proyecto fue muy constructivo en mi estrategia de aprendizaje
y estrategia de trabajo como futura Ingeniera de Sistemas que seré, ya que trabaje sobre un
tema real, que seleccione de acuerdo a mi interés.
El Aprendizaje Basado en el Proyecto implico formar un equipo integrado por personas con
diferentes perfiles, estas diferencias ofrecieron grandes oportunidades para el aprendizaje y
preparación como estudiante para trabajar en un ambiente y en una economía diversas y
globales. Para que los resultados de trabajo del equipo de trabajo,
En donde bajo el aprendizaje basado en el proyecto fuese exitoso, se requirió de un diseño
instruccional definido, definición de roles y fundamentos de diseño de proyectos.

El Proyecto fue un modelo de aprendizaje en el que como estudiantes planeamos,
implementamos y evaluamos el proyecto que tuvo aplicación en el mundo real más allá del
aula de clase, donde adquirí una formación avanzada, de carácter especializado y
multidisciplinar, orientado a la especialización profesional en el contexto del Desarrollo del
Software.
Con la planificación del proyecto de desarrollo de software adquirí un concepto integrador
de las diversas áreas del conocimiento, ayudo desarrollar relaciones de trabajo con personas
de diversa índole, promovió el trabajo disciplinar, la capacidad de investigación, las
herramientas y la metodología para aprender cosas nuevas de manera eficaz.

Referencias bibliográficas
Project Management Institute. (2013). GUÍA DE LOS FUNDAMENTOS PARA LA

DIRECCIÓN DE PROYECTOS (Guía del PMBOK). Newtown Square, Pensilvania:
Project Management Institute, Inc.
Canós, J., Penadés, M. C., y Letelier, P. (2003). Metodologías Ágiles en el Desarrollo
de Software. Presented at the VIII Jornadas de Ingeniería de Software y Bases de
Datos. [s.l.]. Recuperado el 16 de julio de 2011, de
http://201.249.238.203/portalopei/images/descargas/medesoft.pdf
Métricas de calidad y un modelo costo. beneficio ajustados a un caso real de la industria del
software [en línea] Argentina: Departamento de Informática Universidad
Nacional de San Luis. Recuperado el 16 de julio de 2011, de
http://www.costossoftware.com.

Ejemplo Formato IEEE 830

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Ejemplo Formato IEEE 830

Загружено:

Авторское право:

Доступные форматы

INGENIERIA DE SOFTWARE

Evaluación Final: Consolidación de la propuesta de software

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA - UNAD

CLINICA COLOMBIANA DE OBESIDAD Y METABOLISMO S.A.S

13 No. 94ª-25 piso 2, edificio Centro Ejecutivo Castilla.

y calificados, en constante preparación y actualización de todos los procedimientos médico-

riesgos, efectos secundarios, tiempo de recuperación, cicatrices y ofreciendo resultados más

naturales que una cirugía convencional.

Objetivos del proyecto

Desarrollar el software de inteligencia artificial para la toma de decisiones del diagnóstico

preoperatorio del paciente de la Clínica Colombiana de obesidad y metabolismo S.A.S.

 Realizar el levantamiento de información o de requerimientos para el diseño del software

 Elaborar el diseño del software de acuerdo a los requerimientos.

 Determinar las herramientas de hardware y software apropiados, de acuerdo al diseño.

 Desarrollar un prototipo del software funcional para pruebas y verificación de usuarios.

 Realizar ajuste y afinamiento de software de acuerdo al resultado de pruebas.

Descripción del proyecto de desarrollo de software

En este proyecto se plantea el estudio de aprovechamiento de la inteligencia artificial para dar

solución al problema encontrado en la clínica Colombiana de obesidad y metabolismo S.A.S.

aprovechando todo el material de las pruebas de análisis, radiografías, tomografías

acertado diagnóstico clínico preoperatorio. Al cirujano y equipo.

Las características del prototipo se definen en la interacción con ingenieros, programadores, y la

por parte del equipo.

necesidades que surjan, en especial las pertinentes al software y hardware. La estructuración

tecnología más competitiva posible.

 Combina lo real y lo virtual

 Funciona en tiempo real

 Se registra en tres dimensiones

 Autoenfoque para evitar distorsión en la imagen mientras el escáner se encuentra

 Alta precisión en sus resultados.

El tipo de software que se implementara es de Inteligencia Artificial

Este desarrollo de software es conveniente para la clínica ya que es un beneficio para su

paciente y de los equipos que intervienen en la cirugía láser

que apoya al cirujano al saber las cantidades exactas de lípidos corporales.

integración de la información del paciente a intervenir, dándole agilidad en el proceso de estudio

mejora en la administración de las cirugías.

trabaje mejor como una sola unidad.

Modelo de proceso de desarrollo para el software

Esta metodología es imperativa a la participación activa de los usuarios, el equipo de desarrollo

ellas, se enfoca en la entrega frecuente de productos, completa cada funcionalidad antes de

pasar a la siguiente, trabaja funcionalidades principales – principio de Pareto, las pruebas se

enfoque de colaboración y cooperación entre todas las partes interesadas.

 Programación extrema (XP),

constituye un método adecuado para el desarrollo de sistemas, ha sido empleada

principalmente para el desarrollo de sistemas inteligentes que intentan emular ciertas

emular el comportamiento humano. La clave del éxito de esta aproximación está en la

utilización de técnicas que permiten realizar iteraciones del sistema rápidamente.

Consiste entonces en diseñar, implementar y programar lo más rápido posible, hasta en

casos se recomienda saltar la documentación y los procedimientos tradicionales. Se

de los errores propios inherentes en un programador. XP es un método para equipos

extremadamente pequeños que se centran en un solo cliente.

Los avances tecnológicos han obligado a la medicina a cambiar la forma tradicional de

realizar procedimientos, entre estos cambios se encuentra los procedimientos quirúrgicos,

una herramienta revolucionaria que ha modificado por completo el concepto de cirugía

eliminar no se retira la cantidad adecuada.

alta definición de contorno en abdomen y extremidades, resultando en una figura no

solamente mas esbelta sino también muy definida.

Con la información obtenida anteriormente se desarrollará la herramienta capaz de

combinar lo real y lo virtual, ésta será el módulo inicial. En donde el modelo de

evidencian al llevar a cabo un proyecto de desarrollo de software, la finalidad es minimizar

las dificultades y errores que se presenten específicamente.

La utilidad de esta metodología es para:

nunca hecho por la comunidad de desarrolladores.