Tesis Pmbok

UNIVERSIDAD ALAS PERUANAS
FACULTAD DE INGENIERÍAS Y ARQUITECTURA

ESCUELA ACADÉMICO PROFESIONAL DE INGENIERÍA DE SISTEMAS E
INFORMÁTICA
TESIS
“SISTEMA INTELIGENTE PARA EL DIAGNOSTICO Y
TRATAMIENTO DE INFECCIONES BACTERIANAS DE PIEL,
APLICANDO PROCESAMIENTO DE IMÁGENES Y
RAZONAMIENTO BASADO EN CASOS BAJO PLATAFORMA
ANDROID”
PRESENTADA POR EL BACHILLER

JOAN MANUEL CHILO CHOQUEPUMA
PARA OPTAR EL TÍTULO PROFESIONAL DE

INGENIERO DE SISTEMAS E INFORMÁTICA
AREQUIPA - PERÚ
2016
Pág. i
A mis padres y hermanos; por la paciencia, comprensión y apoyo

incondicional que brindaron en todo momento.
A mis maestros quienes forjaron en mí su experiencia, sus

conocimientos y habilidades, siempre los tendré en cuenta.
Pág. ii
INTRODUCCIÓN
El presente proyecto tiene por objetivo desarrollar un sistema para el diagnóstico y

tratamiento de infecciones bacterianas de piel para ello se hará uso de 2 técnicas
informáticas: el procesamiento de imágenes para el reconocimiento del patrón de la
imagen de la mancha en la piel del paciente, y por otro lado el razonamiento basado en
casos para el proceso de determinación del tratamiento adecuado al paciente.
La información recolectada se obtuvo del médico pediatra Gonzalo Gutierrez Quispe

médico pediatra del hospital Goyeneche de nuestra ciudad, ya que las pruebas se harán
en problemas presentados en pacientes pediátricos, ya que son los que presentan la
mayor incidencia de problemas de infecciones de piel por causas bacterianas.
El proyecto contiene los siguientes capítulos:
En el capítulo I, se describen los aspectos generales de la empresa o institución donde

se realizará el Proyecto. Describimos todos los aspectos de las funciones, visión misión,
estrategias y roles de la misma.
En el capítulo II, se hace una reseña histórica y teórica, del procesamiento de imágenes
y del razonamiento basado en casos y de Project Management.
Pág. iii
El Capítulo III, en éste capítulo básicamente se realizan 2 aspectos: la planificación del

proyecto (aplicando todos los criterios señalados en el PMBOK), y el análisis y diseño
del sistema, además, obviamente, de la programación del sistema.
Pág. iv
ÍNDICE PRINCIPAL
Pág.
CAPÍTULO I: ANÁLISIS DE LA ORGANIZACIÓN ........................................................ 1
1.1. Datos generales de la institución: ................................................................... 1
1.1.1. Nombre de la Institución.............................................................................. 1
1.1.2. Rubro o Giro del Negocio ............................................................................ 1
1.1.3. Breve Historia.............................................................................................. 1
1.1.4. Organigrama actual ..................................................................................... 4
1.1.5. Descripción de las Áreas funcionales. ......................................................... 6
1.1.6. Descripción general del proceso de negocio. .............................................. 6
1.2. Fines de la Organización ................................................................................ 7
1.2.1 Visión .......................................................................................................... 7
1.2.2 Misión ......................................................................................................... 7
1.3. Análisis externo .............................................................................................. 7
1.3.1 Análisis del entorno general. ....................................................................... 7
A. Factores económicos .................................................................................. 7
B. Factores tecnológicos. ................................................................................ 7
C. Factores políticos. ....................................................................................... 7
D. Factores sociales. ....................................................................................... 8
E. Factores demográficos. ............................................................................... 8
1.3.2 Análisis del entorno competitivo. ................................................................. 8
1.3.3 Análisis de la posición competitiva - Factores claves de éxito ..................... 9
1.4. Análisis Interno ............................................................................................. 10
1.4.1 Recursos y capacidades ........................................................................... 10
A. Recursos tangibles. ................................................................................... 10
B. Recursos intangibles. ................................................................................ 10
C. Capacidades organizativas. ...................................................................... 10
D. Análisis de recursos y capacidades........................................................... 11
1.4.2 Análisis de la cadena de valor ................................................................... 11

Pág. v
A. Actividades primarias. ............................................................................... 11
B. Actividades de apoyo. ............................................................................... 12
1.5 Análisis Estratégico ...................................................................................... 14
1.5.1 Análisis FODA ........................................................................................... 14
A. Fortalezas. ................................................................................................ 14
B. Oportunidades........................................................................................... 14
C. Debilidades. .............................................................................................. 14
D. Amenazas ................................................................................................. 14
1.5.2 Matriz FODA ............................................................................................. 15
1.6 Descripción de la problemática ..................................................................... 16
1.6.1 Problemática ............................................................................................. 16
1.6.2 Objetivos ................................................................................................... 17
A. Objetivo General. ...................................................................................... 17
B. Objetivos específicos ................................................................................ 17
1.7 Resultados esperados .................................................................................. 17
CAPÍTULO II: MARCO TEÓRICO DEL NEGOCIO Y DEL PROYECTO ..................... 20
2.1 Marco teórico del Negocio ............................................................................ 20
2.1.1 Infecciones bacterianas de piel.............................................................. 20
2.1.2 Procesamiento Digital de Imágenes. ..................................................... 22
2.1.3 Razonamiento Basado en Casos ........................................................... 23
2.2 Marco Teórico del Proyecto. .................................................................. 27
2.2.1 Gestión del Proyecto. ............................................................................. 27
2.2.2 Ingeniería del Proyecto ........................................................................... 29
2.2.3 Soporte del Proyecto. ............................................................................. 32
2.2.4 Planificación de la calidad ...................................................................... 33
2.2.5 Identificación de Estándares y Métricas. ............................................... 35
2.2.6 Diseño de formatos de Aseguramiento de la Calidad. ......................... 36
CAPÍTULO III: INICIO Y PLANIFICACIÓN DEL PROYECTO ..................................... 40
3.1 Gestión del proyecto. .................................................................................... 40

Pág. vi
3.1.1 Iniciación ................................................................................................... 40
3.1.2 Planificación. ............................................................................................. 45
CONCLUSIONES .......................................................... Error! Bookmark not defined.
FUENTES DE INFORMACIÓN ...................................... Error! Bookmark not defined.

Pág. 1
CAPÍTULO I: ANÁLISIS DE LA ORGANIZACIÓN
1.1. Datos generales de la institución:

1.1.1. Nombre de la Institución
Hospital Goyeneche de la ciudad de Arequipa.
1.1.2. Rubro o Giro del Negocio
El Hospital Goyeneche de Arequipa es un Órgano dependiente e

integrante del Gobierno Regional de Arequipa, que cumple su Rol Social,
contribuyendo a solucionar los problemas de Salud de la población,
dentro del ámbito que le corresponde, brindando una Atención Integral de
Salud con calidad y eficiencia. Inaugurado solemnemente el 11 de febrero
de 1912, tuvo como padrino al Papa Pío X, y bajo la advocación de la
milagrosa imagen de Cristo Pobre, Patrón del Hospital, desde sus inicios
ha sido y será considerado por su incondicional ayuda sanitaria a la
población arequipeña y de toda la región sur del país.
1.1.3. Breve Historia.
El Ilustrísimo Arzobispo de Lima y Obispo de Arequipa Don José de

Sebastián de Goyeneche y Barreda, falleció en 1873, dejando una
donación consistente en 150,000 pesetas para la construcción de un
Hospital en el Departamento de Arequipa, el mismo que debería ser
entregado para su conducción y Administración a la Junta de
Beneficencia, Corporación o Entidad que estuviera a cargo de los
establecimientos de Piedad.
Debido a la guerra del Pacífico la obra no pudo empezarse

oportunamente, el Gobierno Tomo el legado del Arzobispo para cancelar
los gastos de dicho episodio. Posteriormente gestiones de la
Beneficencia Pública de Arequipa, lograron que el Estado reconozca la
deuda y los Duques de Gamio y de Goyeneche, el Conde de Huaqui y
Don José Sebastián de Goyeneche y Gamio incrementaron la donación
facilitando el cumplimiento del deseo del Arzobispo.
Pág. 2
El Presidente José Pardo colocó la primera piedra en 1904 y fue

inaugurado con toda solemnidad en 1912.
El hospital fue proyectado por Monseñor José Sebastián de Goyeneche,

Arzobispo de Lima, para cuya construcción dejó una considerable fortuna
en su testamento. Sin embargo el gobierno peruano se apoderó de esta
suma para costear la guerra con Chile, por lo que el legado no pudo
hacerse efectivo.
Fruto de ello, la familia Goyeneche, que quería cumplir con los deseos
del Arzobispo y dotar a Arequipa del mejor hospital de Hispanoamérica,
no escatimó esfuerzos ni gastos para construirlo de su propio peculio
particular.
Así, en los primeros años del siglo XX se inició la construcción de un

soberbio establecimiento rodeado de jardines y al que se dotó de los
medios e instrumental más modernos de la época, en su mayoría
encargados a las casas más conocidas y especializadas de Europa.
En 1921, dentro de los actos conmemorativos del I Centenario de la

Independencia del Perú, el pueblo de Arequipa, en agradecimiento por el
Hospital y otras muchas obras llevadas a cabo por la arequipeña familia
de Goyeneche, elevó, por suscripción popular, un gran monumento de
recuerdo y homenaje a esta familia, que fue construido e instalado
enfrente del Hospital.
El 12 de febrero de 1960 la hermosa capilla fue demolida. El Hospital

Goyeneche fue uno de los más dotados de Sudamérica, contaba con 780
camas y todas las especialidades. La segunda etapa se caracterizó por
contar con médicos graduados de San Fernando con estudios de
especialización en Europa, que impulsaron el desarrollo del Hospital y
Medicina en Arequipa. En 1967 la Sociedad de Beneficencia pública
cedió por 30 años la conducción del Hospital al Ministerio de Salud, en
1975 se crearon las Regiones de Salud para depender de ellas.
En la actualidad el Hospital Goyeneche es considerado un Hospital Nivel
III y es un órgano desconcentrado de la Dirección Regional de Salud-
Pág. 3
Arequipa y administrativamente depende del Gobierno Regional –

Arequipa.
Hoy en día, el Hospital Goyeneche brinda los servicios de Consulta

Externa y Hospitalización, Medicina, Pediatría, Obstetricia, Cirugía,
Oncología, Odontoestomatología, Enfermería, Emergencia, Patología,
Farmacia, Servicio Social, Diagnóstico de Imágenes y Nutrición.
Se construyeron pabellones de Medicina y Cirugía separados por

jardines, grandes salas de operaciones y pabellones de esterilización
dotados de grandes autoclaves. En total 19 pabellones, sin contar los
Servicios Generales, y sesenta jardines distribuidos entre los pabellones.
En 1922 se inauguró el pabellón de Infecto-Contagiosos, que fue dotado

también por la familia Goyeneche de un magnífico instrumental, el más
completo que se pudo conseguir y que fue encargado a uno de los
mejores establecimientos de París, la Casa Collin.
Presidía la entrada principal del Hospital una soberbia capilla de estilo

neogótico, verdadera obra de arte, de una severidad y sencillez
admirables. Su fachada principal estaba coronada por una imagen de la
Virgen del Consuelo, patrona de la Casa de Goyeneche, y un escudo de
armas de esta familia.
A ambos lados de la Capilla se levantan los pabellones de la

Administración y el Consultorio Menor. El ladrillo esmaltado cubre las
paredes de estos departamentos y dentro de ellos puede verse toda clase
de elementos modernos para el tratamiento de enfermos: las modernas
mesas de operaciones, la dotación de la sala de Maternidad con las
incubadoras más adelantadas.
Se instalaron los servicios generales con verdadera perfección y todos

los adelantos del momento: la cocina, lavandería, establo, panadería,
botica, farmacia, depósitos, camisería y otros departamentos en los que
no se omitió esfuerzo ni gasto.
Pág. 4
Se hicieron especiales esfuerzos en la profusión de aparatos de

desinfección en todo el hospital.
1.1.4. Organigrama actual

Pág. 5
GRÁFICO 1:
ORGANIGRAMA DEL HOSPITAL GOYENECHE
Fuente: Administración del Hospital Goyeneche

1.1.5. Descripción de las Áreas funcionales.
El Hospital Goyeneche, cuenta con diversas especialidades para la

atención de diversas enfermedades tanto físicas como mentales con
especialistas en cada área.
Se cuenta con un área de centro de referencia de enfermedades de

transmisión sexual, la cual brinda charlas y orientación sobre este tipo de
enfermedades.
Así mismo se cuenta con área de capacitación, en la cual, la institución

brinda cursos tanto para el personal de dicha institución como también
para público en general
1.1.6. Descripción general del proceso de negocio.
El Hospital debido a su naturaleza de atención en consulta externa y

hospitalaria, basa su giro de negocio en el proceso de atención el que se
describe a continuación.
 Dirigirse a la ventanilla de estadística y solicitar un turno para la

especialización en la que se desea hacer atender
 Si ya te hiciste atender anteriormente y tienes tu carné, déjalo para
que nosotros busquemos en el archivo la historia que te corresponde.
 Con el ticket de consulta, dirígete a la ventanilla de Caja y paga el
derecho de consulta. Una vez hecho el pago, dirígete al consultorio
respectivo.
 Si es la primera vez que te haces atender o perdiste tu carné, al
momento de pagar la consulta en caja, compra un carné y dirígete
nuevamente a la ventanilla de Estadística. Aquí llenaran el carné con
tus datos y aperturaremos una nueva historia clínica. Finalmente
dirígete al consultorio donde serás atendido.
 Los turnos se entregan de Lunes a Viernes de 5:30 a 12:00 y los
Sábados de 6:00 a 10:30
1.2. Fines de la Organización
1.2.1 Visión
Ser un Hospital líder al servicio de la población de los Departamentos del

sur del país, brindando atención integral de salud de alta especialización,
docencia e investigación; con tecnología modernas y personal altamente
especializado.
1.2.2 Misión
Prevenir y proteger de los riesgos y daños, recuperar la salud y rehabilitar

las capacidades de la población, en condiciones de equidad y plena
accesibilidad
1.3. Análisis externo
1.3.1 Análisis del entorno general.
A. Factores económicos
El hospital Goyeneche es el más antiguo de la ciudad de Arequipa,

cuenta con diversos tipos de servicios como: consulta externa y
hospitalización y como ya dijimos se encuentra bajo la potestad del
ministerio de salud, por ello mismo, los recursos económicos son
escasos, así como la asignación que otorga el gobierno.
B. Factores tecnológicos.
Debido al carácter de hospital público y al tener recursos escasos, los

factores tecnológicos con los que se cuenta, no son de última
generación y es limitado.
C. Factores políticos.
Se rige bajo la ley de salud en específico para hospitales públicos.

D. Factores sociales.
El sistema implica el soporte a la solución de un problema que afecta

a la población en general, todos estamos expuestos a sufrir
enfermedades de la piel que puede afectar nuestro entorno social e
incluso pueden llegar a problemas de cáncer.
E. Factores demográficos.
La tasa de mortalidad se incrementa debido a enfermedades como el

cáncer, nuestra localidad debido a sus características climatológicas,
es uno de los lugares donde existe mayor radiación solar.
“El Servicio Nacional de Meteorología e Hidrología (Senamhi) advirtió

que en Arequipa se registran temperaturas de 28 grados centígrados
y niveles de radiación ultravioleta que alcanzan valores de 15 puntos,
los que son considerados peligrosos para la población.”1
Aunque el factor demográfico no influye en el desarrollo de

enfermedades de piel, si es influenciada por la radiación por lo
anteriormente expuesto.
1.3.2 Análisis del entorno competitivo.
El entorno competitivo está compuesto por todos los hospitales, clínicas

privadas, centros de salud y postas, es claro que por centros de salud,
son los lugares donde se realizan exámenes y tratamientos
especializados en problemas e infecciones de la piel.
Por otro lado la alternativa de nuestro proyecto propone un soporte al

diagnóstico y en algunos casos, por problemas leves, un tratamiento
ambulatorio.
1 http://elcomercio.pe/peru/arequipa/arequipa-soporta-valores-extremos-radiacion-solar-259613
1.3.3 Análisis de la posición competitiva - Factores claves de éxito
Potenciación, descentralización y modernización de la organización,

funciones y procedimientos.
a. Poder de negociación de los clientes:

Debido a que el Hospital Goyeneche es una entidad del sector
público, tiene bastante acogida en los sectores sociales B, C, D
y E, y debido a la tecnificación que se puede lograr, también
puede tener influencia positiva en el sector A. Entonces, en ese
sentido, se establece una relación positiva con nuestros
pacientes.
b. Poder de negociación de los proveedores:
Nuestra competencia en cuanto a proveedores que prestan los
servicios de soporte al proceso de diagnóstico de infecciones
de piel, son las clínicas privadas y las empresas de desarrollo
dedicas a la industria de la salud, lamentablemente no se le da
mucha importancia a este sector lo que implica un bajo nivel
competitivo, y un mercado a la espera de obtener beneficios.
c. Amenaza de nuevo competidores entrantes:
Existen muchas empresas de desarrollo de software entrantes,
sin embargo están más dedicadas al desarrollo de sistemas y
páginas web empresariales, no se tiene información de alguna
que esté orientada a prestar servicios al sector salud y en
específico a las infecciones de piel.
d. Amenaza de productos sustitutos:
No existen, según la investigación que se ha realizado,
productos sustitutos que reemplacen al sistema propuesto; sin
embargo, en el mercado existen muchos productos para el
tratamiento de problemas de piel pero que requieren receta,
además tienen precios muy elevados.
e. Rivalidad entre competidores:
De acuerdo al análisis que se ha hecho de los factores
anteriores, se concluye en que se tiene una oportunidad, por la
nula o poca competencia que se observa.
1.4. Análisis Interno

1.4.1 Recursos y capacidades
A. Recursos tangibles.
Los recursos tangibles con que se cuenta para la realización del
proyecto son los siguientes:
- Asesoría del médico especialista.
- Bibliografía especializada en el campo.
- Banco de casos registrados en las historias clínicas del hospital.
- Computadora.
- Impresora.
- Internet.
B. Recursos intangibles.
En relación a los recursos intangibles, se tienen los siguientes:
- Capacitación en el conocimiento proporcionado por el
especialista.
- Experiencia en desarrollo de sistemas.
- Experiencia en implementación en aplicaciones sobre ingeniería
del conocimiento.
- Voluntad de los pacientes para formar parte del estudio.
- Voluntad del especialista y del hospital para dar apoyo al
desarrollo del proyecto.
C. Capacidades organizativas.
Como ya se mencionó, una de las cualidades o características
destacables del hospital es la estructura organizativa, que obedece a
las necesidades de la población.
Sin embargo es bueno destacar que se cuenta con las siguientes
capacidades organizativas:
- Organización estructural del hospital.
- Asignación de personal especializado para la realización del
proyecto.
- Asignación formal de los documentos necesarios para hacer el
estudio (historias clínicas).
D. Análisis de recursos y capacidades.
De acuerdo al análisis que se ha realizado en función a los recursos
y capacidades, se observa que se tiene todo lo necesario para realizar
el proyecto, además se tiene el apoyo del hospital Goyeneche y el
conocimiento necesario para realizar el mismo.
1.4.2 Análisis de la cadena de valor
La cadena de valor empresarial, o cadena de valor, es un modelo teórico

que permite describir el desarrollo de las actividades de una organización
empresarial generando valor al cliente final, descrito y popularizado por
Michael Porter en su obra, Competitive Advantage: Creating and
Sustaining Superior Performance
Gráfico: La cadena de valor de Porter

Fuente: https://es.wikipedia.org/wiki/Cadena_de_valor
A. Actividades primarias.
Las actividades primarias en la cadena de valor son las actividades
implicadas en la creación física del producto (en este caso el sistema),
su venta y transferencia al comprador así como la asistencia posterior
a la venta. Análisis de sus categorías:
- Logística interna.
El hospital cuenta con ambientes adecuados para almacenar las
historias clínicas físicas, aunque sería recomendable que las
misas se almacenen de forma digital, además se cuenta con los
procesos y personal asignado al manejo de la documentación del
hospital.
- Operaciones.
La operación o proceso relacionado con el proyecto es la consulta
externa en la especialidad de dermatología, ésta especialidad sí
se tiene en el hospital y por tanto también se cuenta con el
personal idóneo.
- Logística externa.
El Hospital Goyeneche por ser una entidad pública, cuenta con
procesos formales, con una normativa y reglamento específico;
por tanto, el manejo de los procesos externos está debidamente
normado.
- Marketing y ventas.
En relación al marketing del producto que vamos a desarrollar, es
automático, pero ¿por qué?, es muy sencillo, estamos trabajando
en una entidad pública de alta demanda.
- Servicios.
Los servicios adicionales también están normados, de la misma
manera el proyecto debe contar con un proceso de soporte del
sistema.
B. Actividades de apoyo.
En la cadena de Valor de Michael Porter las actividades de apoyo son
las que sustentan a las actividades primarias y se apoyan entre sí,
proporcionando insumos comprados, tecnología, recursos humanos
y varias funciones de toda la empresa. En ese sentido analizamos las
actividades de apoyo:
- Infraestructura de la empresa (Hospital).
Debido a las características del proyecto y por el poco
presupuesto con que cuenta el hospital, pero además por el objeto
de estudio, el financiamiento del mismo estará a cargo del autor
del proyecto.
En función a la planificación, será realizada por el autor del
proyecto pero además se cuenta con el apoyo del sponsor del
proyecto (el cual se detalla en el acta de constitución del
proyecto).
Finalmente se debe aclarar que el Hospital Goyeneche cuenta
con una infraestructura física antigua, catalogada como
patrimonio cultural de la humanidad, sin embargo se tienen todos
los servicios y ambientes, además de infraestructura tecnológica
básica para sus procesos como registro de consultas externas,
programación de consulta externa, caja, contabilidad. Se puede
catalogar como positiva la infraestructura encontrada.
- Gestión de Recursos Humanos.
El Hospital tiene los procesos de contratación de personal y
asignación de funciones bien normadas, en relación al proyecto
también se planificará el proceso de gestión de recursos
humanos.
- Desarrollo Tecnológico.
Pese a las grandes limitaciones observadas, se realizan
investigaciones relacionadas con salud y la implementación de
tecnología es muy limitada, debido a eso, ésta es una gran
oportunidad de aportar a la institución.
- Aprovisionamiento.
Nuevamente se debe aclarar que por ser una entidad estatal, todo
éste proceso de aprovisionamiento esta normado. En cuanto a
nuestro proyecto, al aplicar el enfoque del PMBOK, también se
planificará todo el proceso de aprovisionamiento (equipo,
servicios, material).
1.5 Análisis Estratégico
1.5.1 Análisis FODA
A. Fortalezas.
 Cobertura a nivel regional.

 Organización disciplinada y jerarquizada, unidad comando.
 Personal especializado.
 Estructura Sistémica.
B. Oportunidades.
 Predisposición política y social para emprender cambios.

 Predisposición social para participar en la vida pública.
 Apertura de organismos internacionales a la cooperación.
 Disponibilidad de acceso a nuevas técnicas de gestión y
tecnología de punta.
 Reforma Constitucional.
C. Debilidades.
 Estructura rígida, organización centralista y poco participativa.

 Inadecuados Sistemas.
 Bajas remuneraciones y pobre sistema de bienestar.
 Burocratización.
 Cultura organizacional en proceso de consolidación.
 Recurso limitado y mal asignado.
 Normatividad incompleta y dispersa.
D. Amenazas
 Crisis socio económica.

 Incremento criminalidad.
 Desconfianza de población en Policía.
 Acelerado proceso urbanismo.
 Expansión pandillaje, TID, terrorismo y crimen menor.
 Limitaciones presupuestales.
 Acceso de delincuencia a tecnología.
 Poder corruptor de organizaciones criminales.
 Expectativas sociales insatisfechas
1.5.2 Matriz FODA

TABLA 1:
MATRIZ FODA
FORTALEZAS DEBILIDADES
F1 Personal especializado. D1 Cultura organizacional en
INTERNAS F2 Presencia sistémica. proceso de consolidación.
D2 Recurso limitado y mal
asignado.
EXTERNAS D3 Inteligencia operativa limitada.
OPORTUNIDADES E1(O1, F1): E6(O1, D1, D2, D3)
O1. Disponibilidad de acceso a Uso de Tecnología. Uso de tecnología.
nuevas técnicas de gestión y E2(O1, F1):
tecnología de punta. Capacitación permanente.
E3(O1, F2):
Inclusión de personal.
E4(O1, F2):
DESARROLLO DEL PROYECTO.
AMENAZAS E5(A1, F1, F2) E7(A1, D1)
A1 Acceso de delincuencia a Inclusión de todo el personal en Impacto negativo.
tecnología. capacitación. E8(A1, D2, D3)
Limitaciones de recursos.
Fuente: Elaboración Propia
 E1: Uso de Tecnología:
Utilización de tecnologías de la información y con la participación de personal
especializado.
 E2: Capacitación permanente:
Promover capacitación permanente y especializada al, además estas
capacitaciones tienen que estar orientadas a aprender nuevas técnicas,
procedimientos y métodos.
 E3: Inclusión de personal:
Incluir a todo el personal del área en los procesos, en las capacitaciones a
realizarse en el área.
 E4: DESARROLLO DEL PROYECTO:
Una estrategia importante es el desarrollo del proyecto propuesto debido a la
disponibilidad de la tecnología suficiente y de personal especializado
(especialista en dermatología, y en desarrollo de sistemas inteligentes).
 E5: Inclusión de todo el personal en capacitación:
Aprovechar la presencia del personal especializado y la participación del
personal femenino para capacitarlos y hacer frente a los delitos informáticos.
Se toma en cuenta al personal femenino, puesto que actualmente se cuenta
con ello, pero no es suficiente.
 E6: Uso de Tecnología de Punta:
Aprovechar el acceso a la tecnología de punta y técnicas de gestión para mitigar
las debilidades.
 E7: Impacto negativo:
Tomar conciencia que la delincuencia informática puede impactar
negativamente sobre la organización.
 E8: Limitaciones de Recursos Humanos:
Tomar conciencia de que la delincuencia informática se incrementa frente a la
limitación de recursos informáticos y operativos.
1.6 Descripción de la problemática

1.6.1 Problemática
El proyecto ha sido elegido al observar la complejidad que supone la

interpretación de las imágenes. Existen casos en que una misma imagen
es interpretada de una forma por un médico, y de otra por otro médico.
Este no es un problema relacionada con la calidad de los médicos, pues
existen muchas variantes que hacen que la imagen no sea del todo
confiable, por ejemplo puede ser que la misma no haya sido tomada en
la posición adecuada, esto provoca distorsión en la imagen.
1.6.2 Objetivos
A. Objetivo General.
Desarrollar un sistema informático que permita realizar el diagnóstico

y tratamiento de enfermedades de piel. Aplicando procesamiento de
imágenes y razonamiento basado en casos bajo plataforma Android.
B. Objetivos específicos
 Capturar la imagen del problema de piel.

 Registrar síntomas y características de la imagen de piel.
 Diagnosticar el problema de piel a partir de la base de casos, la
imagen y los síntomas.
 Aplicar un tratamiento a partir del sistema de razonamiento
basado en casos.
1.7 Resultados esperados
Los resultados esperados se han definido en base a los requisitos de los

interesados, en función al desarrollo del aplicativo, pero también en función al
proceso de desarrollo propuesto por el PMBOK. Estos se detallan a
continuación:
A. Entregables de Gestión.
Se hará entrega de todos los documentos de gestión como:
- El Project Charter. En el Acta de Constitución del Proyecto se incluirán

los aspectos generales sobre la realización del proyecto planteado.
- Los planes para la dirección de proyectos:
 Plan de gestión de alcance.
 Plan de gestión de tiempo.
 Plan de gestión de costos.
 Plan de gestión de calidad.
 Plan de gestión de las comunicaciones.
 Plan de gestión de recursos humanos.
 Plan de gestión de riesgos.
 Plan de gestión de adquisiciones.
 Plan de gestión de los interesados.
- Los KPIs, se incluirán los indicadores de control.
- Checklist de calidad, además se incluirán los checklist necesarios para
controlar cumplimiento de los procesos del proyecto.
- Lecciones aprendidas.
- Registro de incidencias.
B. Entregables de Ingeniería.
En relación a los entregables de ingeniería, se hará entrega de lo siguiente:
- Requisitos del sistema

- Modelamiento del Sistema (diagramas UML).
 Modelo de negocio.
 Diagrama de clases.
 Diagrama de casos de uso.
 Diagrama de secuencias.
 Diagrama de actividades.
 Diagrama de componentes.
- Módulo de tratamiento de imágenes.
- Modelamiento de la Base de Casos.
- Componente de Adquisición del conocimiento.
- Componente de toma de decisiones (módulo de razonamiento basado
en caso)
C. Entregables de Soporte.
Se hará entrega de:

- Capacitación al personal de la especialidad.
- Soporte al sistema (actualización).
- Manual de usuario del sistema.
CAPÍTULO II: MARCO TEÓRICO DEL NEGOCIO Y DEL PROYECTO
2.1 Marco teórico del Negocio
2.1.1 Infecciones bacterianas de piel.
La piel y sus anejos constituyen la principal barrera estructural de defensa del

organismo frente a agentes externos, estando formada por 3 capas:
epidermis, capa verdaderamente protectora, más superficial y avascular;
dermis, y tejido celular subcutáneo (TCS), capas más profundas y con riego
sanguíneo. Existe un constante equilibrio entre microorganismo y huésped,
de manera que la eliminación de ese equilibrio puede favorecer el desarrollo
de infección.
- Defensas del huésped. Integridad de la barrera cutánea (factor más

importante: dermatitis atópica, varicela o heridas, favorecen el desarrollo
de infección), flora saprofita (flora residente, especialmente
Staphylococcus coagulasa negativos, Propionebacterium o
Corynebacterium), ácidos grasos, inmunidad.
- Virulencia del microorganismo. Colonización cutánea por flora transitoria
(piel con solución de continuidad, contacto con personas colonizadas),
toxinas, etc.
Algunos factores que pueden alterar este equilibrio y favorecer las infecciones
cutáneas son la humedad, el aumento de temperatura, diversas
enfermedades o inmunosupresión, o el uso de antibióticos. Vamos a
referirnos a niños sin patología de base.
PATOGENIA.
Las manifestaciones cutáneas de una infección bacteriana pueden producirse
por varios mecanismos fundamentales:
- Infección local primaria con replicación in situ de la bacteria, como impétigo.
- Exotoxinas circulantes: síndrome de la piel escaldada estafilocócica.
- Mecanismos inmunológicos, como vasculitis en infección estreptocócica.
- Afectación de la piel como parte de un cuadro sistémico: sepsis
meningocócica.
- Manifestación de una coagulopatía intravascular diseminada, como ocurre
también en las sepsis meningocócia o en alguna infecciones por Rickettsia.
Cuadro: Tipo de infección cutánea y de partes blandas según ubicación

Fuente: http://www.aeped.es/sites/default/files/documentos/piel.pdf
Las infecciones de piel y partes blandas se definen según la localización de

las mismas independientemente del microorganismo que las produce. Así, las
infecciones de piel afectan a la epidermis, dermis o TCS, mientras que las
infecciones de partes blandas afectan a la fascia profunda o al músculo
DIAGNÓSTICO.
El diagnóstico de la mayoría de las infecciones cutáneas es clínico, dado que
muchas de estas infecciones presentan características patognomónicas. Sin
embargo, en ocasiones, bien por mala respuesta al tratamiento empírico o
recidiva, bien por la necesidad de un diagnóstico preciso ante cuadros
potencialmente graves (síndrome de Stevens-Johnson o ectima gangrenosa
en pacientes neutropénicos), pueden ser necesarios estudios microbiológicos
(tinción, cultivo y estudio de sensibilidad) o histológicos. Es importante valorar
la profundidad de la lesión, si existe necrosis asociada, signos de afectación
sistémica y la presencia de factores de riesgo de mala evolución. En pacientes
que presenten síntomas de afectación sistémica se debe realizar hemocultivo,
hemograma, y determinar equilibrio ácido base, proteína C reactiva, creatinina
y creatinina-fosfoquinasa. En poblaciones con alta incidencia de SAMR, la
recogida de muestras de la lesión o de un exudado nasal puede orientar el
diagnóstico y el tratamiento
2.1.2 Procesamiento Digital de Imágenes.
El procesamiento digital de imágenes es el conjunto de técnicas que se

aplican a las imágenes digitales con el objetivo de mejorar la calidad o facilitar
la búsqueda de información.
PROCESO DE FILTRADO.
Es el conjunto de técnicas englobadas dentro del preprocesamiento de
imágenes cuyo objetivo fundamental es obtener, a partir de una imagen
origen, otra final cuyo resultado sea más adecuado para una aplicación
específica mejorando ciertas características de la misma que posibilite
efectuar operaciones del procesado sobre ella.
Los principales objetivos que se persiguen con la aplicación de filtros son:
 Suavizar la imagen: reducir la cantidad de variaciones de intensidad entre

píxeles vecinos.
 Eliminar ruido: eliminar aquellos píxeles cuyo nivel de intensidad es muy
diferente al de sus vecinos y cuyo origen puede estar tanto en el proceso
de adquisición de la imagen como en el de transmisión.
 Realzar bordes: destacar los bordes que se localizan en una imagen.
 Detectar bordes: detectar los píxeles donde se produce un cambio brusco
en la función intensidad.
Por tanto, se consideran los filtros como operaciones que se aplican a los
píxeles de una imagen digital para optimizarla, enfatizar cierta información o
conseguir un efecto especial en ella.
El proceso de filtrado puede llevarse a cabo sobre los dominios de frecuencia

y/o espacio.
TRATAMIENTO DE IMAGEN POR PROCESAMIENTO DE PUNTO.

Se trata de la mejora de la imagen considerando los métodos de procesamiento
que se basan sólo en la intensidad de píxeles individuales. En lo que sigue
llamaremos r y s a la intensidad de los píxeles antes y después del procesado. A
continuación se presentan ejemplos de tratamiento de imagen por procesamiento
de punto utilizando el software de acceso libre:
 Negativos de imágenes: La idea de esta transformación es invertir el orden
de blanco al negro, de forma que la intensidad de la imagen de salida
disminuya conforme la intensidad de la imagen de entrada aumente.
Gráfico: Negativos de imágenes

Fuente:
https://es.wikipedia.org/wiki/Procesamiento_digital_de_im%C3%A1genes
 Aumento del contraste: La idea del aumento de contraste consiste en

incrementar el rango dinámico de los niveles de gris de la imagen que se está
procesando. La ubicación de los puntos (r1,s1) y (r2,s2) controla la forma de
la función de transformación.
Gráfico: Aumento de contraste

Fuente:
https://es.wikipedia.org/wiki/Procesamiento_digital_de_im%C3%A1gene
s
2.1.3 Razonamiento Basado en Casos

El Razonamiento Basado en Casos, no es más que otro paradigma de
resolución de problemas, pero son precisamente las diferencias con el resto
de los acercamientos de la inteligencia artificial las que lo hacen tan especial.
En lugar de confiar únicamente en el conocimiento general del dominio del
problema, o realizar asociaciones a lo largo de relaciones entre descripciones
del problema y conclusiones, este paradigma es capaz de utilizar conocimiento
específico de experiencias previas, es decir, situaciones de un problema
concreto (casos). Un problema nuevo (al decir nuevo nos referimos a nunca
antes tratado) es resuelto cuando se encuentra un caso pasado similar y se
reutiliza en la situación del problema nuevo.
Una segunda diferencia, no por ello menos importante, es un acercamiento al
aprendizaje incremental, sostenido, ya que se guarda una experiencia nueva
cada vez que se resuelve un problema, pasando a estar disponible para futuros
problemas desde ese mismo momento.
Con las pocas nociones vistas hasta ahora ya podríamos aventurarnos a dar
una primera definición para el Razonamiento Basado en Casos: Resolver un
problema nuevo recordando una situación similar previa y reutilizando su
información y conocimiento.
Si bien el paradigma, como técnica de inteligencia artificial, es novedoso, el
Razonamiento Basado en Casos es bien conocido entre los psicólogos
muchos años
Pensemos en un médico que examinando un nuevo paciente recuerda un caso
parecido unas semanas atrás; encuentra una similitud importante de los
síntomas y decide asumir que posee la misma enfermad y le trata de la misma
manera, pues el tratamiento resultó efectivo en la ocasión anterior.
De la misma manera, a un broker de la bolsa le recomiendan una aparente
buena inversión pero ciertos síntomas del mercado le recuerdan que hace un
año con una situación parecida perdió mucho dinero y decide no invertir en
esta ocasión.
En los dos ejemplos anteriores, podemos observar como se ha recordado un
caso anterior para aplicarlo a un nuevo problema. En la terminología CBR,
podemos definir un caso como una situación de un problema. De esta manera,
una situación previamente experimentada, que ha sido capturada y aprendida
de manera que pueda ser reutilizada para resolver futuros problemas, se
denomina un caso previo, caso almacenado ó caso guardado. Así, un caso
nuevo ó un caso sin resolver no es más que la descripción de un problema
nuevo a resolver (donde “resolver” puede ser desde justificar o criticar una
solución propuesta, a interpretar el problema, generar un conjunto de
soluciones posibles ó generar expectativas de datos observados).
El Razonamiento Basado en Casos sugiere un modelo de razonamiento que
incorpora los aspectos ya mencionados de resolución de problemas,
entendimiento y aprendizaje e integra todo ello en meros procesos de
memoria. En resumen, estas son las premisas subyacentes al modelo:
La referencia a casos pasados es interesante y de gran utilidad para tratar
situaciones que -vuelven a darse-. La referencia a situaciones similares es
necesaria a menudo para tratar la complejidad de una nueva situación. Por
ello, recordar un caso para usarlo en un problema futuro (e integrar ambos) es,
necesariamente, un proceso de aprendizaje.
Debido a que las descripciones de los problemas son, a menudo, incompletas,
es necesario una etapa de entendimiento o interpretación., ya que no puede
llevarse a cabo un razonamiento, una resolución adecuada de una nueva
situación, si ésta no se entiende con cierta completitud. Se puede considerar
que esta etapa es a la vez un prerrequisito y una parte del ciclo de
razonamiento, pues el entendimiento de las situaciones mejora conforme
progresa el razonador. No obstante, cualquier forma de razonamiento necesita
que la situación sea elaborada con suficiente detalle y representada con
suficiente claridad y con el vocabulario apropiado para que el razonador
reconozca el conocimiento que necesita (sea conocimiento general o casos)
para razonar a partir de él.
La práctica demuestra que no suele existir un caso pasado exactamente igual
que un caso nuevo. Por ello, es muy usual el tener que adaptar la solución
pasada para que se ajuste a la nueva situación.
El aprendizaje es una consecuencia natural del razonamiento. Si se halla un
nuevo procedimiento en el curso de la resolución de un problema complejo y
su ejecución resulta positiva, entonces se aprende el nuevo procedimiento
para resolver esta nueva clase de situaciones.
La revisión de la solución propuesta y el análisis de la revisión son dos partes

necesarias para completar el ciclo de razonamiento/aprendizaje. Este análisis
de la revisión (habitualmente llevada a cabo por un agente externo, léase
humano) puede conllevar una reparación de posibles fallos.
Estas premisas sugieren que la calidad de un razonador basado en casos

depende de:
1. La experiencia que tiene.
2. La habilidad para entender situaciones nuevas en términos de experiencias
pasadas.
3. Su capacidad de adaptación.
4. Su capacidad de evaluación y reparación.
5. Su habilidad para integrar nuevas experiencias en su memoria
adecuadamente.
1.2. Tareas y sistemas representativos
Las aplicaciones CBR se clasifican principalmente en dos tipos: tareas de

clasificación y tareas de síntesis.
En las tareas de clasificación, un caso nuevo se empareja (matching en su
terminología original) con aquellos de la base de casos para determinar que
tipo, clase o caso es. La solución del caso que mejor ajusta es el que se
reutiliza.
La mayoría de las herramientas CBR disponible dan un soporte aceptable para
las tareas de clasificación, que suelen estar relacionadas con la recuperación
de casos. Existe una gran variedad de tareas de clasificación, como por
ejemplo:
Diagnosis: Médica o de fallos de equipos
Predicción: Pronóstico de fallos de equipos o actuación sobre el stock de un
mercado.
Valoración: análisis de riesgos para bancos o seguros o estimación de costes
de proyectos.
Control de procesos: Control de fabricación de equipos.
Planificación: Reutilización de planos de viaje ó planificadores de trabajo.
Las tareas de síntesis intentan crear una nueva solución combinando partes
de soluciones previas. Éstas son inherentemente complejas a causa de las
restricciones de los elementos usados durante la síntesis.
Los Sistemas CBR que realizan tareas de síntesis deben realizar adaptación
y son normalmente sistemas híbridos que combinan CBR con otras técnicas.
Algunas de las tareas que realizan estos sistemas son:
• Diseño: La creación de un nuevo artefacto adaptando elementos de otros
existentes.
• Planificación: La creación de nuevos planes a partir de otros previos.
• Configuración: La creación de nuevos planificadores a partir de otros previos.
Por norma general, los sistemas que implementan tareas de síntesis son más
difíciles de construir que los que implementan tareas de clasificación.
Pre Procesamiento de Imágenes.
Figura 1: Etapas del Procesamiento de Imágenes
2.2 Marco Teórico del Proyecto.

2.2.1 Gestión del Proyecto.
En la Guía del PMBOK® se mencionan cinco grupos de procesos de la

dirección de proyectos:
A. Procesos de inicio: se definen los objetivos del proyecto, se identifican

a los principales interesados, se nombra al DP y se autoriza
formalmente el inicio del proyecto.
B. Procesos de planificación: se define el alcance del proyecto, se refinan
los objetivos y se desarrolla el plan para la dirección del proyecto, que
será el curso de acción para un proyecto exitoso.
C. Procesos de ejecución: se integran todos los recursos a los fines de
implementar el plan para la dirección del proyecto.
D. Procesos de monitoreo y control: se supervisa el avance del proyecto
y se aplican acciones correctivas.
E. Procesos de cierre: se formaliza con el cliente la aceptación de los
entregables del proyecto.
En cada uno de estos cinco grupos de procesos existen varios procesos

particulares distribuidos entre las distintas áreas del conocimiento como se
resume en la tabla a continuación:
TABLA 2:
NÚMERO DE PROCESOS EN EL PMBOK 5
Fuente: Lledo Pablo, Director de Proyectos, 5ta. Edición, 2013
Cabe destacar que los grupos de procesos no son áreas independientes

entre sí, tampoco es necesario que termine un grupo al 100% para que
comience el próximo grupo, sino que existe una fuerte interrelación entre
todos los grupos de procesos como se esquematiza en el gráfico a
continuación.
GRÁFICO 2:
GRUPOS DE PROCESOS DEL PMBOK

Gráfico: Los Grupos de Procesos de la Gestión de Proyectos
Fuente: Lledo Pablo, Director de Proyectos, 5ta. Edición, 2013
Por ejemplo, no es necesario que terminen todos los procesos de inicio

para comenzar con los procesos de planificación. Tampoco podemos
pretender haber finalizado con la planificación para comenzar con la
ejecución, ya que el plan perfecto no existe. Serán las continuas lecciones
aprendidas de la ejecución, monitoreo y control las que seguirán
perfeccionando el plan de gestión.
Por su parte, los procesos de monitoreo y control se superponen con el

resto de los procesos, pues desde el inicio del proyecto debe haber
monitoreo y control. Por último, el grupo de procesos de cierre suele
superponerse con la planificación, ejecución, monitoreo y control.
2.2.2 Ingeniería del Proyecto
Rational Process Unified.
El Rational Unified Process o Proceso Unificado de Racional. Es un

proceso de ingeniería de software que suministra un enfoque para asignar
tareas y responsabilidades dentro de una organización de desarrollo. Su
objetivo es asegurar la producción de software de alta y de mayor calidad
para satisfacer las necesidades de los usuarios que tienen un cumplimiento
al final dentro de un límite de tiempo y presupuesto previsible. Es una
metodología de desarrollo iterativo que es enfocada hacia “diagramas de
los casos de uso, y manejo de los riesgos y el manejo de la arquitectura”
como tal.
El RUP mejora la productividad del equipo ya que permite que cada

miembro del grupo sin importar su responsabilidad específica pueda
acceder a la misma base de datos incluyendo sus conocimientos. Esto
hace que todos compartan el mismo lenguaje, la misma visión y el mismo
proceso acerca de cómo desarrollar un software.
En el ciclo de vida RUP veremos una implementación del desarrollo en

espiral. Con el ciclo de vida se establecen tareas en fases e iteraciones. El
RUP maneja el proceso en cuatro fases, dentro de las cuales se realizan
varias iteraciones en número variable:
Gráfico: Ciclo de vida de RUP

Fuente:
https://unpocodejava.files.wordpress.com/2012/05/image0025.png
Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan

hacia la comprensión del problema y la tecnología, la delimitación del
ámbito del proyecto, la eliminación de los riesgos críticos, y al
establecimiento de una base de inicio.
La metodología RUP es más apropiada para proyectos grandes (Aunque

también pequeños), dado que requiere un equipo de trabajo capaz de
administrar un proceso complejo en varias etapas. En proyectos pequeños,
es posible que no se puedan cubrir los costos de dedicación del equipo de
profesionales necesarios.
Unified Model Language
El lenguaje unificado de diagrama o notación (UML) sirve para especificar,

visualizar y documentar esquemas de sistemas de software orientado a
objetos. UML no es un método de desarrollo, lo que significa que no sirve
para determinar qué hacer en primer lugar o cómo diseñar el sistema, sino
que simplemente le ayuda a visualizar el diseño y a hacerlo más accesible
para otros. UML está controlado por el grupo de administración de objetos
(OMG) y es el estándar de descripción de esquemas de software.
UML está diseñado para su uso con software orientado a objetos, y tiene
un uso limitado en otro tipo de cuestiones de programación.
UML se compone de muchos elementos de esquematización que

representan las diferentes partes de un sistema de software. Los
elementos UML se utilizan para crear diagramas, que representa alguna
parte o punto de vista del sistema. UML soporta los siguientes tipos de
diagramas:
 Diagrama de casos de uso: que muestra a los actores (otros usuarios

del sistema), los casos de uso (las situaciones que se producen cuando
utilizan el sistema) y sus relaciones.
 Diagrama de clases que muestra las clases y la relaciones entre ellas.
 Diagrama de secuencia: muestra los objetos y sus múltiples relaciones
entre ellos.
 Diagrama de colaboración: que muestra objetos y sus relaciones,
destacando los objetos que participan en el intercambio de mensajes.
 Diagrama de estado: muestra estados, cambios de estado y eventos
en un objeto o en parte del sistema.
 Diagrama de actividad: que muestra actividades, así como los cambios
de una a otra actividad junto con los eventos que ocurren en ciertas
partes del sistema.
 Diagrama de componentes: que muestra los componentes de mayor
nivel de la programación (cosas como Kparts o Java Beans).
2.2.3 Soporte del Proyecto.
El soporte del proyecto se hace en base a las buenas prácticas propuestas

por el PMBOK:
Gráfico: Grupos de procesos del PMBOK

Fuente: Guía de los Fundamentos para la Dirección de Proyectos
(PMBOK 5)
 El grupo de procesos de iniciación. Aquellos procesos realizados para

definir un nuevo proyecto o una nueva fase de un proyecto ya existente,
mediante la obtención de la autorización para comenzar dicho proyecto o
fase. Pero además para poder identificar a nuestros interesados.
 El grupo de procesos de planificación. Aquellos procesos requeridos
para establecer el alcance del proyecto, refinar los objetivos y definir el
curso de acción necesario para alcanzar los objetivos para cuyo logro se
emprendió el proyecto.
 El grupo de procesos de ejecución. Aquellos procesos realizados para
completar el trabajo definido en el plan para la dirección del proyecto a fin
de cumplir con las especificaciones del mismo.
 El grupo de procesos de seguimiento y control. Aquellos procesos
requeridos para dar seguimiento, analizar y regular el progreso y el
desempeño del proyecto, para identificar áreas en las que el plan requiera
cambios y para iniciar los cambios correspondientes.
 El grupo de procesos de cierre. Aquellos procesos realizados para
finalizar todas las actividades a través de todos los grupos de procesos, a
fin de cerrar formalmente el proyecto o una fase del mismo.
2.2.4 Planificación de la calidad
La Gestión de la Calidad del Proyecto incluye los procesos y actividades

de la organización ejecutante que determinan responsabilidades, objetivos
y políticas de calidad a fin de que el proyecto satisfaga las necesidades por
la cuales fue emprendido. Implementa el sistema de gestión de calidad por
medio de políticas y procedimientos, con actividades de mejora continua
de los procesos llevados a cabo durante todo el proyecto, según
corresponda.
La Gestión de la Calidad del Proyecto trata sobre la gestión tanto de la

calidad del proyecto como del producto del proyecto. Se aplica a todos los
proyectos, independientemente de la naturaleza de su producto. Las
medidas y técnicas relativas a la calidad del producto son específicas al
tipo de producto generado por el proyecto.
El enfoque básico de la gestión de calidad pretende ser compatible con el

de la Organización Internacional de Normalización (ISO). También es
compatible con enfoques propietarios sobre la gestión de calidad, tales
como los recomendados por Deming, Juran, Crosby y otros, así como con
enfoques que no son propietarios, como la Gestión de la Calidad Total
(TQM), Six Sigma, Análisis de Modos de Fallo y Efectos, Revisiones del
Diseño, Opinión del Cliente, Costo de la Calidad (COQ) y Mejora Continua.
Gráfico: Descripción General de la Gestión de la Calidad del Proyecto
(PMBOK 5)
Planificar la Gestión de la Calidad es el proceso de identificar los requisitos

y/o estándares de calidad para el proyecto y sus entregables, así como de
documentar cómo el proyecto demostrará el cumplimiento con los mismos.
El beneficio clave de este proceso es que proporciona guía y dirección
sobre cómo se gestionará y validará la calidad a lo largo del proyecto.
Gráfico: Planificar la Gestión de la Calidad del Proyecto

(PMBOK 5)
La calidad “no” se incorpora al proyecto cuando se encuentra en marcha

mediante procesos de inspección. Por el contrario, la calidad se planifica,
se diseña y se incorpora antes de que comience la ejecución del proyecto.
Al momento de planificar la calidad es importante identificar las normas de
calidad relevantes. Por ejemplo, las normas ISO 21500 sobre Dirección de
Proyectos podrían ser muy útiles para no re-inventar la rueda.
2.2.5 Identificación de Estándares y Métricas.
Una métrica de calidad describe de manera específica un atributo del

producto o del proyecto, y la manera en que lo medirá el proceso de control
de calidad. Una medida es un valor real. La tolerancia define las
variaciones permitidas de las métricas. Si el objetivo de calidad es
mantenerse dentro del límite de ± 10% del presupuesto aprobado, por
ejemplo, la métrica específica puede consistir en medir el costo de cada
entregable y determinar el porcentaje de variación con respecto al
presupuesto aprobado para ese entregable. Las métricas de calidad se
emplean en los procesos de realizar el aseguramiento de calidad y de
controlar la calidad. Algunos ejemplos de métricas de calidad serían el
índice de puntualidad, el control del costo, la frecuencia de defectos, la tasa
de fallas, la disponibilidad, la confiabilidad y la cobertura de las pruebas.
ANÁLISIS DE LAS MEDICIONES Y MÉTRICAS.2

Uno de los problemas con la recogida de datos cuantitativos en el software
y en los proyectos de software es comprender lo que significan realmente
los datos. Es fácil malinterpretar los datos y hacer inferencias incorrectas.
Las mediciones se deben analizar cuidadosamente para comprender lo
que realmente significan.
Los procesos y productos para medir no están aislados de su entorno y los

cambios en ese entorno invalidan las comparaciones de los datos. Los
datos cuantitativos de las actividades humanas no siempre pueden
tomarse como valores de entrada.
PUNTOS CLAVE SOBRE LA IDENTIFICACION DE MÉTRICAS3
2 https://sites.google.com/site/gestiondeproyectossoftware/unidad-2-calidad-de-software/2-2-
estandares-y-metricas-de-calidad-en-la-ingenieria-de-sw
3 https://sites.google.com/site/gestiondeproyectossoftware/unidad-2-calidad-de-software/2-2-
estandares-y-metricas-de-calidad-en-la-ingenieria-de-sw
 La gestión de la calidad del software permite señalar si éste tiene un
escaso número de defectos y si alcanza los estándares requeridos de
mantenibilidad, fiabilidad, portabilidad, etcétera, las actividades de la
gestión de la calidad comprenden la garantía de la calidad que
establece los estándares para el desarrollo de software, la planificación
de la calidad y el control de la calidad que comprueba el software con
respecto a los estándares definidos.
 Los estándares de software son importantes para garantizar la calidad
puesto que representan una identificación de las “mejores prácticas”.
El proceso de control de calidad implica comprobar que el proceso del
software y el software a desarrollar concuerdan con estos estándares.
 Las revisiones de los productos a entregar por el proceso del software
incumben a un equipo de personas los cuales comprobarán que se han
seguido los estándares de calidad, las revisiones son la técnica más
utilizada para valorar la calidad.
2.2.6 Diseño de formatos de Aseguramiento de la Calidad.
Realizar el Aseguramiento de Calidad es el proceso que consiste en

auditar los requisitos de calidad y los resultados obtenidos a partir de
medidas de control de calidad, a fin de garantizar que se utilicen
definiciones operacionales y normas de calidad adecuadas. A menudo, las
actividades de aseguramiento de calidad son supervisadas por un
departamento de aseguramiento de calidad o una organización similar.
Independientemente de la denominación de la unidad, el soporte de
aseguramiento de calidad puede proporcionarse al equipo del proyecto, a
la dirección de la organización ejecutante, al cliente o patrocinador, así
como a los demás interesados que no participan activamente en el trabajo
del proyecto.
Realizar el Aseguramiento de Calidad cubre también la mejora continua

del proceso, que es un medio iterativo de mejorar la calidad de todos los
procesos. La mejora continua del proceso reduce las actividades inútiles y
elimina aquéllas que no agregan valor al proyecto. Esto permite que los
procesos operen con niveles más altos de eficiencia y efectividad.
A continuación se presentan algunos formatos para el control de la calidad:

Cuadro: Plantilla para Métricas de Calidad
Fuente: http://www.dharmacon.net/
Cuadro: Plantilla para Auditoría de Calidad
Cuadro: Plantilla para Indicadores de Rendimiento del Proyecto
CAPÍTULO III: INICIO Y PLANIFICACIÓN DEL PROYECTO
3.1 Gestión del proyecto.

3.1.1 Iniciación
A. Acta de constitución del proyecto.
1) Objetivo del Acta de Constitución del Proyecto:
Aprobar el inicio del desarrollo del proyecto de Sistema Inteligente para el
diagnóstico y tratamiento de infecciones bacterianas de piel.
2) Descripción del Acta de Constitución del Proyecto:

PROJECT CHARTER – SISTEMA DE DIAGNOSTICO DE INFECCIONES DE PIEL
NOMBRE DEL PROYECTO
“SISTEMA INTELIGENTE PARA EL DIAGNOSTICO Y TRATAMIENTO DE INFECCIONES
BACTERIANAS DE PIEL, APLICANDO PROCESAMIENTO DE IMÁGENES Y
RAZONAMIENTO BASADO EN CASOS BAJO PLATAFORMA ANDROID”
DESCRIPCIÓN DEL PROBLEMA:
En los hogares, los padres de familia se enfrentan a diversos problemas que pueden afectar
la salud de los integrantes de la misma, uno de esos problemas son las infecciones de piel
los cuales podemos clasificar de la siguiente forma:
Algunas de estas infecciones, si no son tratadas a tiempo podrían desencadenar en

problemas renales, que definitivamente son problemas importantes.
Lamentablemente los niños son altamente vulnerables a éste tipo de infecciones y para
asegurarnos un tratamiento adecuado, el paciente debe ser atendido por un especialista, en
éste caso un Dermatólogo Pediatra. El problema que existe, es que la cantidad de
Dermatólogos Pediatras es mínima, o el acceso a ellos es difícil debido a los costos de
atención, por otro lado existe la indiferencia de muchos que dejamos de lado éste tipo de
problemas y no los tomamos en cuenta, hasta que ya es tarde. No olvidemos que nuestro
clima, debido a los altos índices de radiación, es una causa principal de estas afecciones, por
tanto el índice de personas con problemas de piel también es alto.
Debido a ello se hace la propuesta y se plantea implementarla como una aplicación móvil, de
forma que cualquier persona pueda acceder a éste servicio y a partir de la cámara tomar una
foto del área afectada y el sistema segmentara la imagen, luego a partir de reconocimiento de
patrones, identificara el tipo de mancha y realizará algunas preguntas, para finalmente
proponer un tratamiento de ser el caso, o sugerirá consultar con un especialista debido a la
complejidad del problema.
DEFINICIÓN DEL PRODUCTO DEL PROYECTO:
El proyecto consiste en desarrollar un Sistema Inteligente para Diagnóstico y Tratamiento de
infecciones bacterianas de piel, aplicando Procesamiento de Imágenes y Razonamiento
Basado en Casos. Se propone su implementación para dispositivos móviles con Android, a
partir de un servicio.
El proyecto se hará bajo las premisas propuestas por la guía de buenas prácticas para la
dirección de proyectos PMBOK versión 5.
Etapas de funcionamiento del Producto:
1) Se toma una foto del área afectada.
2) Procesamiento de Imágenes, que implica lo siguiente:
2.1) Digitalización de la imagen.
2.2) Determinación de bordes.
2.3) Segmentación de la mancha.
2.4) Reconocimiento de patrones. (Se reconoce el tipo de mancha)
3) Una vez identificado el tipo de mancha, se determina el tipo de enfermedad, y si fuera el
caso, se realiza una serie de preguntas para definir de forma más precisa el tipo de
afección.
4) Finalmente se propone un tratamiento (Razonamiento Basado en Casos), el motivo de
utilizar RBC es porque los tratamientos para los problemas de piel no siempre tienen el
100% de éxito, y esto se debe a algunas características adicionales de los pacientes, en
muchos casos el problema vuelve a presentarse pero de forma más agresiva. RBC
alimenta el conocimiento del sistema de forma que cada vez actúe de forma más experta.
DEFINICIÓN DE REQUISITOS DEL PROYECTO:
Se han definido una serie de requisitos iniciales, los cuales detallamos a continuación:
Requisitos Funcionales:
 Se debe capturar la imagen del área de la piel afectada.
 El sistema debe segmentar la imagen, separando el área afectada.
 Para poder realizar un buen diagnóstico, el sistema debe permitir elegir los síntomas que
siente el paciente.
 Debe aplicarse razonamiento basado en casos y en reglas para determinar el tipo de
afección de piel.
 Debe aplicarse el razonamiento basado en casos para poder definir el tratamiento
apropiado.
Requisitos No Funcionales:
 Desarrollar la aplicación para plataforma Android.
 Realizar el procesamiento del sistema utilizando Android Studio.
 Debe construirse una base de casos a partir de las historias clínicas del hospital.
OBJETIVOS DEL PROYECTO:
CONCEPTO OBJETIVOS CRITERIO DE ÉXITO
Determinar el alcance del Cumplir con el alcance
1. ALCANCE proyecto en función a los planificado.
requisitos de los interesados.
Programar el cronograma en Cumplir con el tiempo
2. TIEMPO función a las actividades y estimado para cada una de las
tareas. actividades.
Planificar el presupuesto de Cumplir con el costo
acuerdo a las actividades y los planificado
3. COSTO
recursos necesarios para el
proyecto.
FINALIDAD DEL PROYECTO:
Se busca poner a disposición de la población arequipeña una herramienta útil y muy necesaria
para poder diagnosticar y proponer un tratamiento adecuado para problemas de infecciones
bacterianas de piel.
JUSTIFICACIÓN DEL PROYECTO:
El proyecto se justifica pues Arequipa posee una de las radiaciones más grandes en el mundo
y se han vuelto comunes las infecciones de piel e incluso problemas de cáncer de piel, lo que
afecta de manera grave a nuestra población, entonces existe la necesidad de contar con una
aplicación utilizada en los hospitales, pero también de forma personal que nos ayude a
determinar si existen problemas de piel desde la comodidad de nuestras casas.
Adicionalmente como profesionales en Ingeniería de Sistemas e Informática, proponer
técnicas apropiadas para las soluciones de problemas en el manejo de la información y el
conocimiento, significa nuestro desarrollo como profesionales.
DESIGNACIÓN DEL PROJECT MANAGER DEL PROYECTO.
NOMBRE Joan Chilo Choquepuma NIVELES DE AUTORIDAD
REPORTA A Exigir el cumplimiento de los
SUPERVISA A entregables.
ENTREGABLES DEL PROYECTO
Los entregables del proyecto son los siguientes:
 Documento de Gestión de Proyectos, planes de gestión del proyecto.
 Informe de rendimiento del proyecto.
 Plantillas necesarias para los procesos subsidiarios de la gestión del proyecto.
 Lecciones aprendidas.
 Sistema Inteligente para diagnóstico y tratamiento de infecciones de piel.
 Base de conocimientos.
 Manual de usuario.
CRONOGRAMA DE HITOS DEL PROYECTO.
HITO O EVENTO SIGNIFICATIVO FECHA PROGRAMADA
Acta constitución proyecto (Project Charter) 24 de marzo del 2017
Planes de gestión del proyecto. 26 de julio del 2017
Plantillas de gestión de proyectos. 1 de setiembre del 2017
Diseño del sistema (UML) 20 de octubre del 2017
Base de conocimientos 27 de octubre del 2017
Sistema Inteligente 7 de diciembre del 2017
ORGANIZACIONES O GRUPOS ORGANIZACIONALES QUE INTERVIENEN EN EL
PROYECTO.
ORGANIZACIÓN O GRUPO ORGANIZACIONAL ROL QUE DESEMPEÑA
Apoyo al proceso de construcción del
Área de medicina dermatológica
sistema.
Autoriza el uso de los recursos del hospital
Área administrativa del Hospital
y del acceso a sus instalaciones y a la
Goyeneche.
información.
Apoyan con información relacionada con la
Pacientes del hospital.
afección que presentan.
Brindan información y conocimiento
Médicos especialistas.
relacionado con el tema del proyecto.
PRINCIPALES AMENAZAS DEL PROYECTO
 Falta de compromiso del personal del hospital.
 Limitaciones en el acceso a la información del hospital.
 Limitaciones en los casos necesarios para alimentar la base de casos.
 Complejidad de análisis de los problemas de piel, y su implementación informática.
 Limitaciones de los equipos móviles para el procesamiento de imágenes e
implementación de sistemas de razonamiento basado en casos.
 Limitaciones de conocimiento en sistemas inteligentes.
PRINCIPALES OPORTUNIDADES DEL PROYECTO.
 Existencia de frameworks para el procesamiento digital de imágenes.
 Sencillez en la implementación del sistema de razonamiento basado en casos.
 Existencia de casos con toda la información y el conocimiento necesarios y bien
estructurados, para la implementación de la base de casos.
 Contar con médicos especialistas con conocimiento de informática, específicamente en
el aspecto de la implementación de nuestro sistema.
 Infraestructura tecnológica del alto rendimiento y suficiente para la implementación del
sistema.
PRESUPUESTO PRELIMINAR DEL PROYECTO.
CONCEPTO MONTO
 Personal: Planillas de los sueldos y S/. 10000,00
salarios(fijos)
 Equipo S/. 2000,00
 Servicios S/. 1000,00
 Suministros S/. 500,00
TOTAL S/. 13500,00
SPONSOR QUE AUTORIZA EL PROYECTO
NOMBRE EMPRESA CARGO FECHA
Gonzalo Gutiérrez Q. Hospital Goyeneche Médico 24/03/2017
3.1.2 Planificación.
A. Alcance - Plan de Gestión del Alcance.

El plan de gestión del alcance del proyecto es una herramienta de
planificación que describe cómo el equipo definirá el alcance del
proyecto.
Comienzan con el análisis de la información contenida en el acta

de constitución del proyecto.
PLAN DE GESTION DE ALCANCE

NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO
“SISTEMA INTELIGENTE PARA EL
DIAGNOSTICO Y TRATAMIENTO DE
INFECCIONES BACTERIANAS DE
PIEL, APLICANDO PROCESAMIENTO TUPIEL@TUSALUD
DE IMÁGENES Y RAZONAMIENTO
BASADO EN CASOS BAJO
PLATAFORMA ANDROID”
PROCESO DE DEFINICION DEL ALCANCE
Para poder definir adecuadamente el alcance del proyecto se seguirán los
siguientes pasos:
 Análisis del Project Charter.
 Análisis de la documentación de requisitos.
 Juicio de expertos para analizar, relacionar, resumir, concretar el alcance
del proyecto.
 Listar el alcance del proyecto en base a la información analizada y
recabada.
PROCESO DE ELABORACION DEL EDT
La EDT se construirá de acuerdo a los siguientes criterios y pasos:
 Se utilizará la definición del alcance y la documentación de requisitos.
 Utilizando la técnica de descomposición se determinaran los paquetes de
trabajo y se construirá una estructura jerárquica a partir de ello.
 Se necesitará del aporte del experto o especialista en función a los
componentes del EDT.
PLAN DE GESTION DE ALCANCE
 Se incluirán los procesos de gestión y la metodología de desarrollo de
software como elementos de la EDT.
PROCESO PARA ELABORACION DEL DICCIONARIO EDT
Para elaborar el diccionario EDT se realizarán las siguientes acciones:
 Identificar los paquetes de trabajo de la EDT.
 Definición de los responsables del paquete de trabajo.
 Definición de las fechas importantes del paquete de trabajo.
 Definición de los riesgos y oportunidades del paquete de trabajo.
 Se determinará los criterios de aceptación del paquete de trabajo.
PROCESO PARA LA VERIFICACION DEL ALCANCE
Verificar el alcance incluye revisar los entregables con el cliente o el patrocinador
para asegurarse de que se han completado satisfactoriamente y para obtener de
ellos su aceptación formal.
En ese sentido para la realización de ésta tarea se realizarán las siguientes
acciones:
 Se revisará junto con el sponsor y los interesados correspondientes la
documentación de requisitos, la matriz de trazabilidad y los entregables
validados.
 Se realizará la inspección de los entregables.
 Se llenará un checklist donde se detalle el cumplimiento de los requisitos
o no.
PROCESO PARA CONTROL DEL ALCANCE
Controlar el Alcance es el proceso por el que se monitorea el estado del alcance
del proyecto y del producto, y se gestionan cambios a la línea base del alcance.
El control del alcance del proyecto asegura que todos los cambios solicitados o
las acciones preventivas o correctivas recomendadas se procesen a través del
proceso Realizar el Control Integrado de Cambios.
Para ello se realizarán las siguientes acciones:
 Recepción de la solicitud de cambio.
 Se realizará el análisis de variación del cambio.
 Se formalizará la solicitud de cambio al comité de cambios.
 Se actualizarán los planes de gestión involucrados.
1. Alcances del Producto.
El alcance del producto está conformado por los entregables

propios del sistema.
 Modelo de negocio.
 Diagramas UML del sistema.
 Diseño e implementación de la Base de Casos.
 Módulo de captura de imagen del área afectada de la piel.
 Registro de síntomas de la afección a la piel.
 Módulo de diagnóstico del problema de infección bacteriana
de piel.
 Módulo de tratamiento.
2. Alcances del Proyecto.
a. Entregables.
 El Plan para la dirección del proyecto.

 Plan de Gestión de Alcance.
 Plan de Gestión de Tiempo.
 Plan de Gestión de Costos.
 Plan de Gestión de Calidad.
 Plan de Gestión de RRHH.
 Plan de Gestión de Comunicaciones.
 Plan de Gestión de Riesgos.
 Plan de Gestión de Adquisiciones.
 Plan de Gestión de Interesados.
 Formatos o Plantillas de Gestión.
 Registro de Avance del Proyecto.
 Informes de desempeño del proyecto (KPIs).
 Registro de Lecciones Aprendidas.
B. PLAN DE GESTION DE REQUISITOS
PLAN DE GESTION DE REQUISITOS

ACTIVIDADES DE REQUISITOS
Para levantar los requisitos se han planificado realizar entrevistas con los
interesados directos (usuarios del sistema), así como el sponsor y los clientes,
para poder identificar los requisitos funcionales, no funcionales y de calidad.
Los requisitos estarán clasificados por interesado y por tipo de requisito:
funcionales, no funcionales y de calidad.
ACTIVIDADES DE GESTIÓN DE CONFIGURACION
Para las actividades de cambios en el producto se realizará el siguiente proceso:
 Recepcionar la solicitud de cambio.
 Analizar la solicitud de cambio.
 Formalizar el pedido de cambio.
 Elevar el informe de cambio al comité de cambio.
 Actualizar los documentos que resultaron impactados por el cambio
(planes de gestión afectados).
PROCESO DE PRIORIZACION DE REQUISITOS
Los requisitos se priorizarán de acuerdo al nivel de importancia en el producto
final, vale decir que los requisitos funcionales de los usuarios serán los de mayor
prioridad, seguidos de los requisitos del sponsor y de los interesados indirectos.
MÉTRICAS DEL PRODUCTO
Las métricas de calidad se implementarán en base a los requisitos de calidad de
los interesados, y del especialista en desarrollo de software se utilizarán como
propuesta las métricas de McCall.
ESTRUCTURA DE TRAZABILIDAD
La matriz de trazabilidad incluirá la siguiente información:
PLAN DE GESTION DE REQUISITOS
 Código del requisito.
 Propietario del requisito.
 Objeto del requisito.
 Estado.
 Fuente del Requisito.
 Objetivos.
 Paquete de trabajo.
C. DOCUMENTACION DE REQUISITOS
DOCUMENTACION DE REQUISITOS
NECESIDAD DEL NEGOCIO U OPORTUNIDAD A APROVECHAR
 Aprovechar la tecnología móvil en beneficio de la población.
 Obtener experiencia sobre la gestión de proyectos.
OBJETIVOS DEL NEGOCIO Y DEL PROYECTO
 Planificar el desarrollo del proyecto.
 Identificar los requisitos.
 Modelar la herramienta aplicando UML.
 Desarrollar la herramienta, haciendo uso de un componente de
razonamiento basado en reglas.
 Probar la herramienta.
REQUISITOS FUNCIONALES
Stakeholder Prioridad Requisito
otorgada Código Descripción
Médico Cargar la imagen del área
Muy Alta R01 afectada de la piel.
especialista
Médico Digitalización de la imagen a
Muy Alta R02 mapa de bits.
especialista
Médico Segmentación de la imagen de
Muy Alta R03 la piel del área afectada.
especialista
Médico Reconocimiento del patrón de la

Muy Alta R04 imagen de la piel del área
especialista afectada.
Médico Diagnóstico del problema de
Muy Alta R05 piel
especialista
Médico Determinar el tratamiento al

Muy Alta R06 problema de piel por infección
especialista bacteriana.
Médico El sistema debe registrar
Muy Alta R07 síntomas o características
especialista observadas en la zona dañada.
Se debe tener acceso a las
Team Project Muy Alta R08 historias clínicas para
implementar la base de casos.
Debe cumplir con la
Sponsor Alta R09 documentación necesaria
según el PMBOK.
Debe ajustarse la interfaz del
Sponsor Media R10 sistema al prototipo de interfaz
anexado al final del documento.
REQUISITOS NO FUNCIONALES
Sponsor, Implementar un módulo de
Alta RNF01 seguridad para el acceso.
médico
Sponsor, El sistema debe ser rápido en
Alta RNF02 sus respuestas.
médico
Sponsor, El sistema debe ser de fácil uso.
Alta RNF03
médico
REQUISITOS DE CALIDAD
Sponsor, Cumplir con el alcance
planificado
médico, Alta RC01
pacientes.
Cumplir con el cronograma
Sponsor Alta RC02
planificado
Cumplir con el presupuesto
Sponsor Alta RC03
planificado
Sponsor, Cumplir con los criterios de
Alta RC04 calidad planificados.
médico.
Informar adecuadamente sobre
Sponsor Alta RC05
el rendimiento del proyecto.
REGLAS DEL NEGOCIO:
 Debe existir comunicación constante entre los asesores del proyecto y el
encargado del mismo.
 Revisión constante de los entregables del proyecto según el PMBOK para la
gestión del mismo.
 Evaluación de parte del asesor y del stakeholder representante de usuarios
sobre los resultados del proyecto y del producto, independientemente.
A. ESTRUCTURA DE DESGLOSE DEL TRABAJO

B. Diccionario de la EDT
DICCIONARIO EDT – SISTEMA DE DIAGNÓSTICO Y TRATAMIENTO DE INFECCIONES DE

PIEL

DIAGNOSTICO Y TRATAMIENTO
DE INFECCIONES BACTERIANAS
DE PIEL, APLICANDO
PROCESAMIENTO DE IMÁGENES
TUPIEL@TUSALUD
Y RAZONAMIENTO BASADO EN
CASOS BAJO PLATAFORMA
ANDROID”
CÓDIGO DEL PAQUETE DE TRABAJO NOMBRE DEL ENTREGABLE
1.1 Acta de Constitución del Proyecto
Es el documento que da inicio al proyecto, elaborado por el
DESCRIPCIÓN DEL PAQUETE DE
sponsor con la colaboración del Director de Proyectos, el mismo
TRABAJO
que debe contar con la aprobación del Sponsor.
Fecha Inicio 6/03/2017
FECHAS PROGRAMADAS Fecha Fin 24/03/2017
Hitos Importantes 24/03/2017
 Visto bueno del Sponsor.
CRITERIOS DE ACEPTACIÓN  Firma del Sponsor
 Firma del Director del Proyecto.
SUPUESTOS  Se tiene una idea clara de las características del proyecto.
 No existe compromiso completo de parte de los interesados
RIESGOS
en el proyecto.

DE PIEL, APLICANDO
TUPIEL@TUSALUD
ANDROID”
1.2 Planificación
Se elabora realiza la planificación del proyecto y se elaboran
DESCRIPCIÓN DEL ENTREGABLE
todos los planes de gestión subsidiarios.
FECHAS PROGRAMADAS Fecha Fin
Hitos Importantes
 Visto bueno del sponsor.
CRITERIOS DE ACEPTACIÓN  Visto bueno de los interesados.
 Visto bueno del Director de Proyectos.
SUPUESTOS  Se tiene una idea clara de las características del proyecto.
RIESGOS
en el proyecto.

DE PIEL, APLICANDO
TUPIEL@TUSALUD
ANDROID”
1.4 Informe de Desempeño del Proyecto
Se realiza una revisión del cumplimiento de los estándares de
calidad, del alcance, del tiempo y de los costos del proyecto a
partir de los índices de calidad y se elabora el informe
correspondiente.
Hitos Importantes
CRITERIOS DE ACEPTACIÓN  Visto bueno del Team Project.
 Se cuenta con todas las facilidades para levantar
SUPUESTOS
información acerca del avance del proyecto.
RIESGOS
en el proyecto.

DE PIEL, APLICANDO
TUPIEL@TUSALUD
ANDROID”
2.1 Requisitos del sistema
Se determina en forma detallada todos los requisitos del sistema
DESCRIPCIÓN DEL ENTREGABLE desde el punto de vista de los usuarios finales y del equipo de
desarrollo
Hitos Importantes
CRITERIOS DE ACEPTACIÓN
 Visto bueno de los usuarios.
 Se cuenta con la participación y colaboración de los
SUPUESTOS
interesados.
RIESGOS
en el proyecto.

DE PIEL, APLICANDO
TUPIEL@TUSALUD
ANDROID”
2.2 Diagrama de Casos de Uso de Negocio
Se diseña el modelo de negocio acerca de cómo se realiza el
diagnóstico y tratamiento de las enfermedades bacterianas de
piel para poder tener una idea clara de cómo se debe realizar el
sistema.
Hitos Importantes
 Se cuenta con la participación de los interesados, en
SUPUESTOS
específico del especialista.
RIESGOS
en el proyecto.

DE PIEL, APLICANDO
TUPIEL@TUSALUD
ANDROID”
3.1 Modelamiento UML del sistema
Se diseñan todos los diagramas UML necesarios para la
implementación del sistema.
Hitos Importantes
 Visto bueno del Analista de Sistemas.
CRITERIOS DE ACEPTACIÓN
 Se cuenta con el conocimiento y experiencia necesarios
SUPUESTOS
para el diseño del sistema.
 No existe compromiso completo de parte del equipo de
RIESGOS
proyecto

DE PIEL, APLICANDO
TUPIEL@TUSALUD
ANDROID”
4 Sistema Inteligente
Es el sistema implementado, el cual será entregado por etapas
de acuerdo al avance del proyecto.
Fecha Fin
Hitos Importantes - Base de casos.
FECHAS PROGRAMADAS - Módulo de seguridad.
- Módulo de Captura de imagen.
- Módulo de diagnóstico.
- Módulo de Tratamiento.
 Visto bueno de los interesados.
 Se cuenta con la disponibilidad para poder evaluar la
SUPUESTOS
calidad y alcance del sistema.
RIESGOS
en el proyecto.
C. Matriz de Trazabilidad de Requisitos.

Pág. 57
MATRIZ DE TRAZABILIDAD DE REQUISITOS

Alcance del
Necesidades, oportunidades, metas y objetivos proyecto/
Cod. Descripción Propietario Fuente Prioridad Objetivos del proyecto
del negocio entregable del
wbs
Cargar la imagen del área Diagnóstico y tratamiento de las imágenes de zonas
RF01 Méd.Esp. Entrevista Muy Alta Cumplir con el alcance Sistema
afectada de la piel. afectadas.
Digitalización de la imagen a Diagnóstico y tratamiento de las imágenes de zonas
RF02 mapa de bits. Méd.Esp. Entrevista Muy Alta Cumplir con el alcance Sistema
afectadas.
Segmentación de la imagen de la Diagnóstico y tratamiento de las imágenes de zonas
RF03 piel del área afectada. Méd.Esp. Entrevista Muy Alta Cumplir con el alcance Sistema
afectadas.
Reconocimiento del patrón de la
imagen de la piel del área Méd.Esp. Diagnóstico y tratamiento de las imágenes de zonas
RF04 Entrevista Muy Alta Cumplir con el alcance Sistema
afectada. afectadas.
Diagnóstico del problema de piel Diagnóstico y tratamiento de las imágenes de zonas

RF05 Méd.Esp. Entrevista Muy Alta Cumplir con el alcance Sistema
afectadas.
Determinar el tratamiento al
problema de piel por infección Méd.Esp. Diagnóstico y tratamiento de las imágenes de zonas
bacteriana. afectadas.
El sistema debe registrar

síntomas o características Méd.Esp. Diagnóstico y tratamiento de las imágenes de zonas
observadas en la zona dañada. afectadas.
Se debe tener acceso a las

historias clínicas para Méd.Esp. Diagnóstico y tratamiento de las imágenes de zonas
implementar la base de casos. afectadas.
Debe cumplir con la

documentación necesaria según Méd.Esp. Diagnóstico y tratamiento de las imágenes de zonas
el PMBOK. afectadas.
Debe ajustarse la interfaz del

Diagnóstico y tratamiento de las imágenes de zonas
RF10 sistema al prototipo de interfaz Méd.Esp. Entrevista Muy Alta Cumplir con el alcance Sistema
afectadas.
anexado al final del documento.
Pág. 58
Alcance del
Necesidades, oportunidades, metas y objetivos proyecto/
Cod. Descripción Propietario Fuente Prioridad Objetivos del proyecto
del negocio entregable del
wbs
Implementar un módulo de
RNF01 seguridad para el acceso. Méd. Esp. Entrevista Muy Alta Establecer seguridad de acceso al sistema Cumplir con el alcance Sistema
El sistema debe ser rápido en sus
RNF2 respuestas. Méd. Esp. Entrevista Muy Alta Agilizar procesos. Cumplir con el alcance Sistema
El sistema debe ser de fácil uso.
RNF03 Méd. Esp. Entrevista Muy Alta Facilitar el uso por parte de los usuarios. Cumplir con el alcance Sistema
Cumplir con el alcance
RC01 planificado Sponsor Entrevista Muy Alta Satisfacer al sponsor. Cumplir con el alcance Alcance
Cumplir con el cronograma
RC02 planificado Sponsor Entrevista Muy Alta Satisfacer al sponsor. Cumplir con el alcance Cronograma
Cumplir con el presupuesto
RC03 planificado Sponsor Entrevista Muy Alta Satisfacer al sponsor. Cumplir con el alcance Costos
Cumplir con los criterios de
RC04 calidad planificados. Sponsor Entrevista Muy Alta Satisfacer al sponsor. Cumplir con el alcance Calidad
Informar adecuadamente sobre
RC05 el rendimiento del proyecto. Sponsor Entrevista Muy Alta Satisfacer al sponsor. Cumplir con el alcance Calidad
Donde:
RF: Requisito funcional.
RNF: Requisitos no funcional.
RC: Requisitos de calidad.
Pág. 59
D. Tiempo - Plan de Gestión del Tiempo
1. Cronograma del Proyecto

Pág. 60
Pág. 61
Pág. 62
Pág. 63
LISTA DE ACTIVIDADES Y SU DURACION:
Nombre de tarea Duración Comienzo Fin

SISTEMA INTELIGENTE DE DIAGNOSTICO Y
lun jue
TRATAMIENTO DE INFECCIONES BACTERIANAS DE 204 días
06/03/17 14/12/17
PIEL
lun jue
Gestión del Proyecto 204 días
06/03/17 14/12/17
lun vie
Inicio 15 días
06/03/17 24/03/17
lun vie
Elaboracion del Project Charter 10 días
06/03/17 17/03/17
lun vie
Identificación de los interesados 5 días
20/03/17 24/03/17
vie vie
Aprobación y firma del Project Charter 0 días
24/03/17 24/03/17
lun mar
Planificación 57 días
27/03/17 13/06/17
lun vie
Elaborar el plan de gestion de alcance 10 días
27/03/17 07/04/17
lun vie
Elaborar el plan de gestion de tiempo 5 días
10/04/17 14/04/17
lun vie
Elaborar el plan de gestion de costos 5 días
17/04/17 21/04/17
lun vie
Elaborar el plan de gestion de calidad 5 días
24/04/17 28/04/17
lun jue
Elaborar el plan de gestion de recursos humanos 4 días
01/05/17 04/05/17
vie mié
Elaborar el plan de gestion de las comunicaciones 4 días
05/05/17 10/05/17
jue mié
Elaborar el plan de gestion de riesgos 10 días
11/05/17 24/05/17
jue mar
Elaborar el plan de gestion de adquisiciones 4 días
25/05/17 30/05/17
mié mar
Elaborar el plan de gestion de interesados 10 días
31/05/17 13/06/17
mar mar
Entrega de los planes de gestión del proyecto 0 días
13/06/17 13/06/17
lun vie
Control y Seguimiento 180 días
20/03/17 24/11/17
lun vie
Elaborar el registro de incidencias 180 días
20/03/17 24/11/17
lun vie
Elaborar el informe de rendimiento del proyecto 180 días
20/03/17 24/11/17
Pág. 64

lun vie
Validación de los planes de gestión 180 días
20/03/17 24/11/17
Validacion y entrega de los informes de control y vie vie
0 días
seguimiento 24/11/17 24/11/17
lun jue
Cierre 204 días
06/03/17 14/12/17
lun vie
Elaborar el registro de lecciones aprendidas 180 días
06/03/17 10/11/17
mié jue
Elaborar el acta de cierre del proyecto 2 días
13/12/17 14/12/17
jue jue
Firma del acta de cierre del proyecto 0 días
14/12/17 14/12/17
mié jue
Análisis 22 días
14/06/17 13/07/17
mié mar
Determinación de Requisitos 15 días
14/06/17 04/07/17
mié mar
Levantamiento de requisitos 5 días
14/06/17 20/06/17
mié mar
Sistematización de los requisitos y clasificarlos 10 días
21/06/17 04/07/17
mar mar
Validación de requisitos del sistema 0 días
04/07/17 04/07/17
mié jue
Modelo de Negocio 7 días
05/07/17 13/07/17
mié mar
Observación y entrevista de los procesos del negocio 5 días
05/07/17 11/07/17
Elaboración del modelo de negocio (Casos de uso de mié jue
2 días
negocio) 12/07/17 13/07/17
jue jue
Entrega del modelo de negocio 0 días
13/07/17 13/07/17
vie vie
Diseño 36 días
14/07/17 01/09/17
vie mié
Diagramas UML 14 días
14/07/17 02/08/17
vie vie
Elaboración del Diagrama de Clases 1 día
14/07/17 14/07/17
lun jue
Elaboración del Diagrama de Casos de Uso 4 días
17/07/17 20/07/17
vie mié
Elaboración del Diagrama de Secuencias 4 días
21/07/17 26/07/17
jue mar
Elaboración del Diagrama de Actividades 4 días
27/07/17 01/08/17
mié mié
Elaboración del Diagrama de Componentes 1 día
02/08/17 02/08/17
mié mié
Validación y entrega del modelado del sistema 0 días
02/08/17 02/08/17
Pág. 65

jue mié
Diseño de la base de casos 15 días
03/08/17 23/08/17
Análisis de las historias clínicas sobre casos de jue mié
10 días
infecciones de piel 03/08/17 16/08/17
jue mié
Modelado de la base de casos 5 días
17/08/17 23/08/17
mié mié
Validación y entrega de la base de casos modelada 0 días
23/08/17 23/08/17
jue vie
Diseño de las interfaces 7 días
24/08/17 01/09/17
jue vie
Diseño de la estructura del sistema 2 días
24/08/17 25/08/17
lun vie
Diseño de las interfaces de los diferentes módulos 5 días
28/08/17 01/09/17
vie vie
Validación y entrega del diseño de las interfaces 0 días
01/09/17 01/09/17
lun jue
Programación 69 días
04/09/17 07/12/17
lun mar
Implementación del sistema de seguridad de acceso 2 días
04/09/17 05/09/17
mié mar
Implementación de la base de casos 15 días
06/09/17 26/09/17
Revisión de la base de casos y construcción de la mié mar
5 días
misma 06/09/17 12/09/17
mié mar
Registro de casos en la base de casos 10 días
13/09/17 26/09/17
mar mar
Validación y entrega de la base de casos 0 días
26/09/17 26/09/17
Módulo de Diagnostico (Procesamiento de Imágenes y mié mar
35 días
RBC) 27/09/17 14/11/17
Implem. de la carga de la imagen y segmentación del mié mar
10 días
área afectada 27/09/17 10/10/17
Implem. del módulo de registro de síntomas y mié mar
5 días
características de la zona 11/10/17 17/10/17
Implementación del RBC para diagnóstico de la mié mar
15 días
infección 18/10/17 07/11/17
Implementación de la base de casos sobre mié mar
5 días
diagnósticos para la retroalimentación 08/11/17 14/11/17
mar mar
Validación y entrega del módulo de diagnostico 0 días
14/11/17 14/11/17
mié jue
Módulo de Tratamiento (RBC de tratamiento) 17 días
15/11/17 07/12/17
Implementación del módulo de toma de decisiones mié mar
10 días
para el tratamiento 15/11/17 28/11/17
Implementación del módulo de registro de resultados mié jue
2 días
del tratamiento 29/11/17 30/11/17
Pág. 66

Implementación del módulo de retroalimentación de vie jue
5 días
la base de casos 01/12/17 07/12/17
jue jue
Validación y entrega del módulo de tratamiento 0 días
07/12/17 07/12/17
vie mar
Soporte 3 días
08/12/17 12/12/17
vie lun
Capacitación al usuario 2 días
08/12/17 11/12/17
vie vie
Preparación del curso de capacitación 1 día
08/12/17 08/12/17
lun lun
Elaboración del material 1 día
11/12/17 11/12/17
lun lun
Aplicación de la capacitación 0 días
11/12/17 11/12/17
mar mar
Manual de Usuario 1 día
12/12/17 12/12/17
mar mar
Elaboración del manual de usuario 1 día
12/12/17 12/12/17
mar mar
Validación y entrega del manual de usuario 0 días
12/12/17 12/12/17
HITOS DEL PROYECTO.

Nombre de tarea Fecha
Aprobación y firma del Project Charter vie 24/03/17
Entrega de los planes de gestión del proyecto mar 13/06/17
Validación y entrega de los informes de control y seguimiento vie 24/11/17
Firma del acta de cierre del proyecto jue 14/12/17
Validación de requisitos del sistema mar 04/07/17
Entrega del modelo de negocio jue 13/07/17
Validación y entrega del modelado del sistema mié 02/08/17
Validación y entrega de la base de casos modelada mié 23/08/17
Validación y entrega del diseño de las interfaces vie 01/09/17
Validación y entrega de la base de casos mar 26/09/17
Validación y entrega del módulo de diagnostico mar 14/11/17
Validación y entrega del módulo de tratamiento jue 07/12/17
Aplicación de la capacitación lun 11/12/17
Validación y entrega del manual de usuario mar 12/12/17
Pág. 67
2.1.1 PLAN DE GESTIÓN DE COSTOS.
RECURSOS DEL PROYECTO:
PRESUPUESTO DEL PROYECTO.
Nombre de tarea Costo

Gestión del Proyecto S/. 13,016.00
Inicio S/. 900.80
Elaboracion del Project Charter S/. 600.80
Identificación de los interesados S/. 300.00
Aprobación y firma del Project Charter S/. 0.00
Planificación S/. 3,427.20
Elaborar el plan de gestion de alcance S/. 600.80
Elaborar el plan de gestion de tiempo S/. 300.80
Elaborar el plan de gestion de costos S/. 300.80
Elaborar el plan de gestion de calidad S/. 300.80
Elaborar el plan de gestion de recursos humanos S/. 240.80
Elaborar el plan de gestion de las comunicaciones S/. 240.80
Elaborar el plan de gestion de riesgos S/. 600.80
Elaborar el plan de gestion de adquisiciones S/. 240.80
Elaborar el plan de gestion de interesados S/. 600.80
Entrega de los planes de gestión del proyecto S/. 0.00
Control y Seguimiento S/. 6,480.00
Elaborar el registro de incidencias S/. 2,160.00
Elaborar el informe de rendimiento del proyecto S/. 2,160.00
Pág. 68

Validación de los planes de gestión S/. 2,160.00
Validacion y entrega de los informes de control y seguimiento S/. 0.00
Cierre S/. 2,208.00
Elaborar el registro de lecciones aprendidas S/. 2,160.00
Elaborar el acta de cierre del proyecto S/. 48.00
Firma del acta de cierre del proyecto S/. 0.00
Análisis S/. 534.00
Determinación de Requisitos S/. 450.00
Levantamiento de requisitos S/. 150.00
Sistematizacion de los requisitos y clasificarlos S/. 300.00
Validacion de requisitos del sistema S/. 0.00
Modelo de Negocio S/. 84.00
Observación y entrevista de los procesos del negocio S/. 60.00
Elaboración del modelo de negocio (Casos de uso de negocio) S/. 24.00
Entrega del modelo de negocio S/. 0.00
Diseño S/. 1,230.00
Diagramas UML S/. 420.00
Elaboracion del Diagrama de Clases S/. 30.00
Elaboracion del Diagrama de Casos de Uso S/. 120.00
Elaboracion del Diagrama de Secuencias S/. 120.00
Elaboracion del Diagrama de Actividades S/. 120.00
Elaboracion del Diagrama de Componentes S/. 30.00
Validación y entrega del modelado del sistema S/. 0.00
Diseño de la base de casos S/. 600.00
Analisis de las historias clínicas sobre casos de infecciones de piel S/. 400.00
Modelado de la base de casos S/. 200.00
Validacion y entrega de la base de casos modelada S/. 0.00
Diseño de las interfaces S/. 210.00
Diseño de la estructura del sistema S/. 60.00
Diseño de las interfaces de los diferentes módulos S/. 150.00
Validacion y entrega del diseño de las interfaces S/. 0.00
Programación S/. 1,400.00
Implementacion del sistema de seguridad de acceso S/. 60.00
Implementación de la base de casos S/. 300.00
Revisión de la base de casos y construcción de la misma S/. 100.00
Registro de casos en la base de casos S/. 200.00
Validacion y entrega de la base de casos S/. 0.00
Módulo de Diagnostico (Procesamiento de Imágenes y RBC) S/. 700.00
Implem. de la carga de la imagen y segmentacion del área afectada S/. 200.00
Implem. del modulo de registro de síntomas y características de la zona S/. 100.00
Pág. 69

Implementación del RBC para diagnóstico de la infección S/. 300.00
Implementación de la base de casos sobre diagnosticos para la retroalimentacion S/. 100.00
Validacion y entrega del módulo de diagnostico S/. 0.00
Módulo de Tratamiento (RBC de tratamiento) S/. 340.00
Implementación del módulo de toma de decisiones para el tratamiento S/. 200.00
Implementación del módulo de registro de resultados del tratamiento S/. 40.00
Implementación del módulo de retroalimentación de la base de casos S/. 100.00
Validacion y entrega del modulo de tratamiento S/. 0.00
Soporte S/. 90.00
Capacitación al usuario S/. 60.00
Preparación del curso de capacitación S/. 30.00
Elaboración del material S/. 30.00
Aplicación de la capacitación S/. 0.00
Manual de Usuario S/. 30.00
Elaboración del manual de usuario S/. 30.00
Validación y entrega del manual de usuario S/. 0.00
COSTO DEL PROYECTO S/. 16,270.00
COSTOS DE CONTINGENCIAS (Calculado a partir de los riesgos) S/. 4,120.00
COSTOS DE GESTION (10% SOBRE EL TOTAL) S/. 2039.00
COSTO TOTAL DEL PROYECTO S/. 22,429.00
2.1.2 PLAN DE GESTIÓN DE CALIDAD.
La intención de la Dirección de Proyectos, así como del sponsor y el testeador,

quienes son los encargados de hacer el seguimiento y el aseguramiento de la
calidad del proyecto y del producto, es conseguir un producto eficientemente
elaborado que cumpla con los requisitos de los interesados, así como que cumpla
con estándares de calidad (métricas), de forma que cada actividad sea bien
realizada y que cada entregable éste muy bien elaborado sin errores.
Esencialmente se busca que el producto cumpla con los alcances definidos, así
como que el tiempo planificado sea cumplido y el costo total del proyecto no sea
excedido.
Pág. 70
Para ello se hará una distribución de roles a través de la elaboración de todo el

proyecto, de forma que haya un encargado al menos que verifique que se cumpla
lo planificado.
2.1.2.1 Métricas de Calidad.
A continuación presentamos los criterios de aceptación y las métricas propuestas

para cada componente del proyecto, en cuanto a las métricas utilizadas se propone
las métricas de calidad de McCall:
Factor de Calidad Aplicación de los Alcances del Proyecto

Definición Verificar el cumplimiento del alcance definido en el
proyecto, es importante en la medida que se podrá
verificar si el producto o servicio realizado cumple
con los planificados.
Propósito de la Métrica Se verifica si se cumple con los alcances definidos
en el proyecto, así como los requisitos
especificados por los interesados o involucrados
en el proyecto
Definición Operacional Los miembros involucrado en ésta métrica son: el
Sponsor, el Project Manager y el Testeador,
durante las diferentes fases de desarrollo del
proyecto, ellos serán quienes supervisarán y
verificarán el cumplimiento de los alcances a lo
largo de todo el proceso.
Método de Medición Se utilizará un checklist para registrar el
cumplimiento de los alcances.
Resultado Deseado Cumplir con todos los alcances definidos en el
proyecto.
Responsable del Factor de Sponsor, Project Manager, y Tester
Calidad
Pág. 71
Factor de Calidad Cumplimiento de los plazos establecidos en el

cronograma
Definición Se verificara el cumplimiento de los tiempos
planificados para cada etapa en el cronograma.
Propósito de la Métrica Observar problemas de cumplimiento de tiempos,
para tomar acciones correctivas, registrar el
incidente, poner en marcha el plan de
contingencia.
Definición Operacional El miembro del equipo encargado supervisara el
cumplimiento de los tiempos programados en el
cronograma de actividades, luego se comunicara
de los incidentes, y se tomara acción sobre el
mismo, de forma que se pueda poner en práctica
el plan de contingencia o mitigación
Método de Medición Checklist para registro de cumplimiento de los
plazos, diagrama de red.
Resultado Deseado Culminar las tareas en los plazos determinados en
el plan de gestión del proyecto.
Responsable del Factor de Project Manager, y Tester
Calidad
Factor de Calidad Cumplimiento de los recursos económicos

asignados
Definición Se verificara que se haya cumplido con la
aplicación del presupuesto asignado.
Propósito de la Métrica Identificar problemas de falta de recursos
económicos de forma que se puedan tomar las
medidas correctivas aplicando el plan de
contingencia propuesto, minimizar las amenazas,
mitigar los riesgos.
Definición Operacional El miembro encargado (Project Manager) es el
que se encargara de supervisar y controlar el
presupuesto asignado, acorde a lo planificado, y
Pág. 72
registrar los incidentes presentados de forma que

se pueda tomar acción sobre los mismos.
Método de Medición Se utilizara la plantilla del Presupuesto en el
Tiempo curva S.
Resultado Deseado Cumplir con el presupuesto asignado.
Responsable del Factor de Project Manager.
Calidad
Factor de Calidad Facilidad de Uso

Definición Esta referido a la posibilidad de manipular los
módulos del sistema de forma sencilla.
Propósito de la Métrica Verificar la sencillez de uso del sistema por parte
de los usuarios finales. En caso de presentarse
problemas de complejidad de la aplicación se
realizará un rediseño de la interfaz acorde a las
exigencias del usuario.
Definición Operacional El tester y el jefe de proyecto realizan un checklist
para verificar si el manejo del sistema es sencillo
de manejar para el usuario final.
Método de Medición Se contara el número de opciones que el usuario
ha descubierto y/o utilizado, contra el número total
de opciones implementadas en los módulos del
sistema.
𝑁𝑂𝑈
𝐼𝐹𝑈 =
𝑁𝑂𝐼
Donde:
IFU: Índice de Facilidad de Uso

NOU: Numero de opciones utilizadas por el
usuario.
NOI: Numero de opciones implementadas.
Pág. 73
Validación: IFU>0,90
Resultado Deseado Sencillo manejo del sistema

Responsable del Factor de Project Manager, y Tester
Calidad
Factor de Calidad Seguridad

Definición Seguridad de acceso y de la información del
sistema
Propósito de la Métrica Verificar que el acceso al sistema y a la
información reservada del mismo este bien
resguardada, que solamente el usuario pueda
realizar los cambios, y procesos necesarios.
Definición Operacional El tester verifica a través de pruebas la seguridad
de acceso al sistema, así como la seguridad de
acceso a los datos.
Método de Medición Se realiza un checklist para verificar que el acceso
a los datos y al sistema no es posible.
𝑁𝐴𝑅
𝐼𝑆𝐸 = 1 −
𝑁𝐴𝑃
Donde:
IED – Índice de Seguridad de Acceso al sistema.

NAR: Numero de acceso no permitidos
observados.
NAP: Numero de accesos permitidos.
Validación: ISE=1
Resultado Deseado Confidencialidad de acceso al sistema y a los

datos.
Pág. 74
Responsable del Factor de Tester

Calidad
Factor de Calidad Confiabilidad

Definición Está relacionado con la veracidad de los
resultados.
Propósito de la Métrica Verificar que los datos devueltos por el sistema
sean los correctos, que no haya errores en los
resultados, o al menos reducir el margen de error
al momento de realizar el diagnóstico de la
infeccion de piel.
Definición Operacional El tester y el sponsor verifican que los resultados
devueltos por el sistema son los correctos.
Método de Medición Se aplicara la observación y se registrará las
características observadas al momento de utilizar
el sistema.
𝑁𝐴𝑁𝐼
𝐼𝐶𝑁 = 1 −
𝑁𝑇𝐴
Donde:
ICN Índice de Confiabilidad

NANI: Numero de Alcances no Implementados
NTA: Número total de alcances de interesados
Validación: ICN=0
Resultado Deseado Resultados precisos

Calidad
Factor de Calidad Escalabilidad

Definición Es la propiedad deseable de un sistema, que
indica su habilidad para reaccionar y adaptarse sin
Pág. 75
perder calidad, o bien manejar el crecimiento

continuo de trabajo de manera fluida, o bien para
estar preparado para hacerse más grande sin
perder calidad en los servicios ofrecidos
Propósito de la Métrica Verificar la flexibilidad del sistema para adaptarse
a los cambios.
Definición Operacional El tester se encargará de agregar más data o
imágenes con cierto margen de error de forma que
se observe la funcionalidad del sistema frente a
esta acción.
el sistema.
𝑁𝑀𝑅
𝐼𝑆𝐶 =
𝑁𝑇𝑀
Donde:
ISC – Índice de Escalabilidad

NMR: Numero de módulos reutilizados.
NTM: Número total de módulos
Validación: ISC>1
Resultado Deseado El sistema debe ser flexible a los cambios

Calidad
Factor de Calidad Rapidez

Definición Es la propiedad de realizar un proceso en el menor
tiempo posible.
Propósito de la Métrica Verificar que los resultados sean devueltos en un
tiempo corto, sin exageraciones. En caso de
Pág. 76
encontrarse errores en la velocidad (lentitud), se

tomará las acciones para corregir esta situación.
Definición Operacional El encargado se encarga de medir la velocidad de
respuesta del sistema en el registro de paciente y
sobre todo en el proceso de diagnóstico de la
presencia de infeccion de piel.
el sistema.
𝑇𝑅
𝐼𝑅𝐴 =
𝑇𝐸
Donde:
IRA – Índice de Rapidez

TR: Tiempo real de proceso
TE: Tiempo esperado.
Validación: IRA<1
Resultado Deseado El tiempo de respuesta debe ser corto.

Calidad
Factor de Calidad Estandarización de Datos

Definición Verificar si los datos utilizados están conformados
por algún estándar
Propósito de la Métrica Uniformizar la estructura de la notación utilizada
para nombrar a cada uno de los datos, variable del
sistema.
Definición Operacional El analista deberá proponer un estándar a utilizar
para la elaboración del sistema.
Método de Medición Se verificará el uso del estándar propuesto:
Pág. 77
𝑁𝐷𝐸
𝐼𝐸𝐷 = 1 −
𝑁𝑇𝐷
Donde:
IED – Índice de Estandarización de datos

NDE: Numero de Datos Estandarizados
correctamente
NTD: Numero de Datos.
Validación: IED=1
Resultado Deseado Estandarizar el total de datos utilizados en el
sistema
Calidad
Factor de Calidad Modularidad

Definición Es la implementación de módulos específicos que
cumplan una determina operación.
Propósito de la Métrica Verificar la utilización de módulos de propósito
específico, que faciliten el desarrollo y
entendimiento de la funcionalidad del sistema.
Definición Operacional El tester se encarga de medir la correcta
implementación de módulos de propósito
específico, luego de que el programador realice la
implementación propuesta por el analista de
sistemas.
el sistema.
𝑁𝑀𝐼
𝐼𝑀𝑂 =
𝑁𝑇𝑀𝑃
Donde:
Pág. 78
IMO: Índice de Modularidad

NMI: Numero de módulos implementados
NTMP: Número máximo de módulos
implementables.
Validación: IMO>0,75
Resultado Deseado Maximizar la utilización de módulos en la

construcción del código del sistema
Calidad
Factor de Calidad Consistencia

Definición Correcto funcionamiento de cada una de las
funciones del sistema, libre de errores voluntarios
o involuntarios.
Propósito de la Métrica Verificar la inexistencia de errores de entrada,
proceso o salida de datos.
Definición Operacional El programador paralelamente a la programación
verifica el correcto funcionamiento del sistema,
comprobando que no haya errores en la entrada
de datos, en el proceso de cálculo, y en las
salidas. El tester verifica al finalizar el módulo si
todo funciona correctamente.
el sistema.
𝑁𝐸𝐸 + 𝑁𝐸𝑃 + 𝑁𝐸𝑆

𝐼𝐶𝑂 = 1 −
𝑁𝑇𝑀𝑃
Donde:
ICO: Índice de Consistencia

Pág. 79
NEE: Numero de errores de entrada

NEP: Numero de errores de proceso
NES: Numero de errores de salida
Validación: ICO=1
Resultado Deseado Eliminar todo tipo de error de funcionalidad del

sistema
Calidad
2.1.2.2 Matriz de Actividades de Calidad.
ESTÁNDAR DE CALIDAD ACTIVIDADES DE ACTIVIDADES DE

ENTREGABLE
APLICABLE PREVENCIÓN CONTROL
 Contenido acorde a las  Realizar un estudio  Supervisión del
exigencias del sponsor. minucioso de las contenido de
Project Charter
características del producto Project Charter.
y del proyecto.
 Alcance acordes a las exigencias  El levantamiento de los  Supervisar el
de los interesados. requisitos debe ser realizado cumplimiento de la
Plan de Gestión de forma precisa, teniendo documentación de
del Alcance del en cuenta las necesidades los requisitos, y
Proyecto de los interesados, y verificar la correcta
estructurar el EDT de forma estructura del EDT
apropiada.
 Cumplimiento de los plazos  Revisar en forma constante  Verificar mediante
planificados el cumplimiento de los un diagrama y un
Plan de Gestión plazos. checklist el
de Tiempo cumplimiento de los
tiempos en cada
actividad.
Pág. 80

ENTREGABLE
 Cumplimiento del presupuesto  Distribuir el presupuesto en  Controlar la
planificado. el momento y la cantidad distribución del
Presupuesto del
prevista. presupuesto en
Proyecto
cada etapa del
proyecto
 Plantear las métricas apropiadas  Proponer métricas acordes  Validar las métricas
Plan de Gestión a cada etapa del proyecto con cada etapa del propuestas a cada
de Calidad desarrollo del proyecto. etapa y/o actividad
del proyecto.
 Personal profesional calificado.  Seleccionar personal con  Revisar las hojas de
 Personal responsable. experiencia en desarrollo de vida y contrastar el
Plan de Recursos
sistemas. mismo.
Humanos
 Seleccionar personal con
recomendaciones.
Plan de Gestión  Distribución de las  Identificar de forma precisa  Definir canales de
de las comunicaciones. los roles y comunicación.
Comunicaciones responsabilidades.
 Precisión  Identificar de forma  Controlar de forma
apropiada y minuciosa, permanente la
Plan de Gestión desde el inicio del proyecto, activación de los
de Riesgos todos los riesgos que riesgos y llevar a
podrían presentarse. cabo el plan de
contingencia.
 Eficiencia  Planificar las adquisiciones  Poner en práctica el
Plan de Gestión de forma precisa, acorde a plan de contigencia
de Adquisiciones las necesidades del para adquisiciones
proyecto. adicionales.
 Confiabilidad.  Estar en contacto  El tester revisara de
 Escalabilidad permanente con el forma permanente
interesado de forma que se que el diseño del
Modelo Lógico plasmen las necesidades modelo lógico de la
del Sistema relacionadas con el base de datos y de
funcionamiento del sistema, las interfaces este
así como el diseño de las acorde a las
interfaces y de la data.
Pág. 81

ENTREGABLE
necesidades del
interesado.
 Seguridad  Recopilar la documentación  El tester y el jefe de
 Escalabilidad y data necesaria para la BD. proyecto se
 Estandarización de datos encargan de revisar
si el diseño,
Base de Datos
elaboración e
implementación de
la base de datos
sean las correctas.
 Seguridad  Revisar en forma paulatina el  Hacer checklist para
 Eficiencia cumplimiento de las métricas registrar el
 Rapidez planteadas. cumplimiento de las
Módulo del
 Facilidad de Uso  Realizar las pruebas métricas propuestas
Administrador
 Escalabilidad correspondientes para para el sistema.
 Modularidad validar el cumplimiento de
 Consistencia las métricas.
 Seguridad  Revisar en forma paulatina el  Hacer checklist para

 Eficiencia cumplimiento de las métricas registrar el
 Rapidez planteadas. cumplimiento de las
Módulo del
 Facilidad de Uso  Realizar las pruebas métricas propuestas
Postulante
 Escalabilidad correspondientes para para el sistema.
 Modularidad validar el cumplimiento de
 Consistencia las métricas.
2.1.2.3 Formatos para el Seguimiento del Control de Calidad del Sistema.
A continuación presentamos las plantillas utilizadas para el control de las métricas

de calidad del sistema
A) Project Charter.
Pág. 82
Sponsor Project Manager

Componente
Si No Si No
Definición del Proyecto
Alcance del Proyecto
Lista de Stakeholders
Requisitos de Alto Nivel
Cronograma de Hitos
Costo del Proyecto
Riesgos del Proyecto
B) Planes de Gestión del Proyecto:
Sponsor Project Manager Tester

Componente
Si No Si No Si No
Plan de Gestión del Alcance
del Proyecto
Identificar la Lista de
Requisitos del Proyecto
Determinar el Alcance del
Proyecto
Elaborar la Estructura de
Desglose de Trabajo
Plan de Gestión de Tiempo
Identificación de las
Actividades del Proyecto
Elaboración del Cronograma
Presupuesto del Proyecto
Estimación de Costos
Elaboración del Presupuesto
Plan de Gestión de Calidad
Establecer las Métricas de
Calidad
Elaborar la Matriz de Calidad
Plan de Recursos Humanos
Pág. 83
Sponsor Project Manager Tester

Componente
Si No Si No Si No
Organizar el Equipo de
Proyecto
Definición de los Roles y
Responsabilidades
Determinar las adquisiciones y
Carga de Personal
Plan de Gestión de las
Comunicaciones
Elaborar la Matriz de
Comunicaciones del Proyecto
Plan de Gestión de Riesgos
Identificación de Riesgos
Elaborar el Plan de Respuesta
a Riesgos
Plan de Gestión de
Adquisiciones
Elaborar la Matriz de
Adquisiciones del Proyecto
C) Modelo Lógico del Sistema:
Métrica Valor del Índice Aceptado No Aceptado

Confiabilidad
Escalabilidad
D) Base de Datos:

Seguridad
Escalabilidad
Pág. 84
Estandarización de Datos
E) Módulo del Administrador

Seguridad
Eficiencia
Rapidez
Facilidad de Uso
Escalabilidad
Modularidad
Consistencia
F) Módulo del Usuario-Postulante

Seguridad
Eficiencia
Rapidez
Facilidad de Uso
Escalabilidad
Modularidad
Consistencia
2.1.3 PLAN DE GESTIÓN DE RECURSOS HUMANOS.
2.1.3.1 Organización del Proyecto.

Pág. 85
Project
Manager
Programador del Testeador

Analista del Sistema
Sistema
2.1.3.2 Definición de los Roles y Responsabilidades del Personal
 Analista del Sistema: Es el encargado principalmente de realizar el análisis del

sistema, pero además puede colaborar en el proceso de planificación del
proyecto.
 Programador del Sistema: Es quien se encargará de la programación del
sistema, considerando lo propuesto por el Project Manager y el analista del
sistema, además será en encargado de la elaboración del manual de usuario.
 Testeador: Su función radica en la verificación del cumplimiento de los criterios
de calidad, así como de los criterios de aceptación, además es el especialista
quien da en visto bueno a todo lo que involucra el desarrollo del sistema.
2.1.3.3 Matriz de Asignación de Responsabilidades.
ENTREGABLE SPONSOR PROJECT MANAGER PROGRAMADOR TESTER

Project Charter X
Plan de Gestión del Alcance del
X
Proyecto
Plan de Gestión de Tiempo X
Presupuesto del Proyecto X
Plan de Gestión de Calidad X
Plan de Recursos Humanos X
Pág. 86
ENTREGABLE SPONSOR PROJECT MANAGER PROGRAMADOR TESTER

Plan de Gestión de las
X
Comunicaciones
Plan de Gestión de Riesgos X
Plan de Gestión de Adquisiciones X
Modelo Lógico del Sistema X X X
Base de Datos X X X
Módulos del Administrador y del
X X X
Postulante.
Informe de Desempeño del
X X
Proyecto
Acta de Cierre del Proyecto X X
2.1.3.4 Cuadro de Adquisiciones del Personal.
ROL ANALISTA PROGRAMADOR TESTER

Evaluación de la Hoja de Evaluación de la Evaluación de la
Vida Hoja de Vida Hoja de Vida
TIPO DE ADQUISICION
Examen de calificación Examen de Examen de
calificación calificación
- Experiencia en - Experiencia - Experiencia
Desarrollo de como DBA en Desarrollo
Proyectos de - Experiencia en de Proyectos
Software programación de Software
COMPETENCIAS NECESARIAS
- Experiencia en de sistemas - Experiencia
Implementación de en aplicación
Base de Datos. de métricas
de McCall
FUENTE DE ADQUISICION Concurso Concurso Concurso
MODALIDA DE ADQUISICION Contrato CAS Contrato CAS Contrato CAS
LOCAL DE TRABAJO Consultorio Consultorio Consultorio
Pág. 87
ROL ANALISTA PROGRAMADOR TESTER

FECHA DE INICIO DE 27 de Mayo del 27 de Mayo del
RECLUTAMIENTO 27de Mayo del 2017 2017 2017
COSTO DE RECLUTAMIENTO 50 50 50
2.1.4 PLAN DE GESTIÓN DE LAS COMUNICACIONES.
 Procedimiento para Tratar Polémicas:
Cuando se presente alguna polémica o problema de comunicación, se elevará

un informe al Project Manager indicando el problema. Seguidamente de
convocará a una reunión de las partes para uniformizar criterios y reiterar las
responsabilidades y jerarquías.
 Guía de Eventos de Comunicación:
De ser necesario, se hará una reunión al cabo de cada proceso de entrega de

información, establecido en la Matriz de Comunicaciones del Proyecto, en dicha
reunión se establecerán acuerdos, uniformizaran criterios, y se tomarán
decisiones. Los acuerdos tomados así como el detalle serán registrados en un
Acta de Reunión.
2.1.4.1 Matriz de Comunicación del Proyecto.
Nivel Responsab Frec. De

Metodolog
INFORMACIÓN CONTENIDO FORMATO Detall le de Recep. Comuni
ía Medio
e Comunicar c.
Determinación
del tipo de Jefe de
Sponsor
proyecto Project RRHH, Documento Una sola
Formulación del Proyecto Alto Project
Identificación de Charter Asistente Digital vez
Manager
Stakeholders de RRHH
Requisitos del
Pág. 88

Metodolog
ía Medio
e Comunicar c.
Proyecto/Produc
to
Identificación de
Stakeholders
Plan de Sponsor
Determinación Muy Project Documento Una sola
Alcance del Proyecto Gestión de Equipo de
de Requisitos Alto Manager Digital vez
Alcance Proyecto
Elaboración del
EDT
Identificación de
las Actividades Plan de Sponsor
Muy Project Documento Una sola
Cronograma del Proyecto Secuenciamient Gestión del Equipo de
Alto Manager Digital vez
o de las Cronograma Proyecto
actividades
Estimación de Plan de
Muy Project Documento Una sola
Presupuesto del Proyecto los Costos del Gestión de Sponsor
Alto Manager Digital vez
Proyecto Costos
Definición de las
métricas de
Plan de Programad
Criterios de Calidad del calidad Muy Project Documento Una sola
Gestión de or
Proyecto Planificación de Alto Manager Digital vez
Calidad Tester
la matriz de
calidad
Definición de los Plan de
Determinación de las Roles y Gestión de Muy Project Equipo de Documento Una sola
Responsabilidades Responsabilidad Recursos Alto Manager Proyecto Digital vez
es Humanos
Plan de
Matriz de Gestión de las Project Equipo de Documento Una sola
Criterios de Comunicación Alto
Comunicaciones Comunicacion Manager Proyecto Digital vez
es
Matriz de Plan de Sponsor,
Definición de Riesgos y Líneas Muy Project Documento Una sola
Respuesta a Gestión de Tester,
de Acción Alto Manager Digital vez
Riesgos Riesgos Analista
Pág. 89

Metodolog
ía Medio
e Comunicar c.
Plan de 1 vez a
Lista de Adquisiciones del Matriz de Muy Project Documento
Gestión de Sponsor la
Proyecto Adquisiciones Alto Manager Digital
Adquisiciones semana
Diseño de la
Arquitectura del
Sistema
Diseño del Informe de Informe
Tester 1 vez a
Diseño del Modelo Lógico del Modelo del Avance del Muy formal
Analista Programad la
Sistema Sistema Modelo del Alto Documento
or semana
Diseño de la Sistema digital
Base de Datos
Diseño de las
Interfaces
Diagrama de Informe
Tester 1 vez a
Entidad-Relación Informe de Muy formal
Estructura de la Base de Datos Analista Programad la
Diccionario de Avance Alto Documento
or semana
Datos digital
Elaboración del
Sistema, 1 vez a
Informe de Muy Programado Documento
Avance del Sistema módulos, Tester la
Avance Alto r Digital
pruebas e semana
integración
Estado del
Alcance
Estado de los Checklist de
Costos cumplimiento 1 vez a
Informe de Desempeño del Muy Project Documento
Estado del de los Tester la
Proyecto Alto Manager Digital
Cronograma parámetros de semana
Estado de calidad
Calidad del
Proyecto
Acuerdo de
Project Una sola
Acta de cierre del proyecto finalización del Informe Alto Sponsor Acta
Manager vez
proyecto
2.1.5 PLAN DE GESTIÓN DE RIESGOS.

Pág. 90
METODOLOGIA DE GESTION DE RIESGOS

PROCESO DESCRIPCION HERRAMIENTAS FUENTES DE INFORMACION
Planificación de Elaborar un plan de gestión PMBOK Sponsor y usuario.
Gestión de los de los riesgos Project Manager y equipo del
Riesgo proyecto
Identificación y Identificar que riesgos Tormenta de ideas y Sponsor y usuario.
Evaluación pueden afectar al proyecto categorización de riesgos. Project Manager y equipo del
Cualitativa de y documentar sus Definición de probabilidad proyecto
Riesgos características e impacto.
Evaluar probabilidad e Matriz de probabilidad e
impacto Impacto
Establecer ranking de
importancia
Planificación de Definir respuestas de Estrategias para riesgos Sponsor y usuarios.
Respuestas a los riesgos Planificar ejecución negativos o Amenazas Project Manager y equipo de
Riesgos de respuestas Estrategia de respuesta proyecto
para contingencia Archivos históricos de
proyectos
Seguimiento y Verificar la ocurrencia de Reevaluación de los riesgos Sponsor y usuario.
Control del Riesgo riesgos. Reuniones sobre el estado Project Manager y equipo del
Supervisar y verificar la del proyecto proyecto
ejecución de respuestas.
Verificar aparición de
nuevos riesgos.
ROLES Y RESPONSABILIDAD DE GESTION DE RIESGOS

PROCESO ROLES PERSONAS RESPONSABILIDADES
Planificación de Equipo de Gestión de Project Manager Dirigir actividades, responsable
Gestión de los Riesgos directo
Riesgo Proveer definiciones Ejecutar
Actividad
Identificación y Equipo de Gestión de Project Manager Dirigir actividades, responsable
Evaluación Riesgos directo
Cualitativa de Proveer definiciones Ejecutar
Riesgos Actividad
Planificación de Equipo de Gestión de Project Manager Dirigir actividades, responsable
Respuestas a los Riesgos directo
Riesgos Proveer definiciones Ejecutar
Actividad
Seguimiento y Equipo de Gestión de Project Manager Dirigir actividades, responsable
Control del riesgo Riesgos directo
Proveer definiciones Ejecutar
Actividad
Pág. 91
METODOLOGIA DE GESTION DE RIESGOS

PROCESO DESCRIPCION HERRAMIENTAS FUENTES DE INFORMACION
PERIODICIDAD DE LA GESTION DE RIESGOS

PROCESO MOMENTO DE EJECUCION ENTREGABLE DEL WBS PERIODICIDAD DE
EJECUCION
Planificación de Al inicio del proyecto 1.2.Plan para la dirección del Una vez
Gestión de los proyecto
Riesgo 1.2.7.Plan de gestión de riesgos
Identificación y Al inicio del proyecto 1.2.Plan para la dirección del Una vez
Evaluación En cada reunión del equipo proyecto Semanal
Cualitativa de del proyecto 1.2.7.Plan de gestión de riesgos
Riesgos Reuniones de coordinación
Planificación de Al inicio del proyecto 1.2.Plan para la dirección del Una vez
Respuestas a los En cada reunión del equipo proyecto Semanal
Riesgos del proyecto 1.2.7.Plan de gestión de riesgos
Reuniones de coordinación
Seguimiento y En cada fase del proyecto Reuniones de coordinación Una vez
Control del Riesgo Semanal
FORMATOS DE LA GESTION DE RIESGOS

Planificación de Gestión de Riesgos Plan de gestión de riesgos
Identificación y Evaluación Cualitativa de Riesgos Identificación y evaluación Cualitativa de riesgos
Planificación de Respuesta a los Riesgos Plan de respuesta a riesgos
Seguimiento y Control del Riesgo Informe de monitoreo de Riesgo
Solicitud de cambio
Acción correctiva
2.1.6 IDENTIFICACIÓN Y EVALUACIÓN CUALITATIVA DE RIESGOS
RIESGOS
• El sponsor no cuenta con el tiempo ni disponibilidad para asesorar el
proyecto.
• Los interesados con saben con precisión lo que es un sistema de
información.
• El costo es elevado e impagable.
• El tiempo es extremadamente largo.
• Los interesados no han precisado con exactitud sus requisitos.
Pág. 92
• Existen errores en la EDT

• Existen actividades innecesarias y otras que no han sido definidas.
• El cronograma no está elaborado de acuerdo a lo esperado por el sponsor.
• Reelaborar las métricas de calidad por error de apreciación o de
aplicabilidad.
• El personal no cumple con las expectativas del Project manager y del
proyecto.
• Falta de comunicación de las tareas asignadas.
• Falta de un plan de mitigación o contingencia.
• Modelado mal elaborado.
• Mala estructura de BD.
• Diseño de interfaces no acordes al usuario.
• No existe servidor de datos ni PC adecuada.
• Errores en la base de datos.
• Presencia de errores de programación y de datos.
• Presencia de fallas y errores en algunos puntos del proyecto
• No se cumplen con el alcance, cronograma o presupuesto del proyecto.
REGISTRO DE RIESGOS
CÓDIGO TITULO DESCRIPCIÓN CONSECUENCIA
R01 El tiempo de los Se da el caso que el Sponsor no Podrá causar atrasos al
principales tenga tiempo para dar momento de recopilar
involucrados es información, la cual información.
insuficiente. necesitamos durante el
proyecto.
R02 Los involucrados no Se da el caso en que los Podrá causar el atrasar la
colaboran de forma involucrados no brindan la toma de requerimientos.
eficiente en el información necesaria, que es
proceso de importante para realizar el
desarrollo del proyecto.
proyecto.
R03 El tiempo Se da el caso donde no se Podrá causar un gran retraso
programado para la cumple los tiempos en el proyecto.
elaboración del establecidos para el proyecto.
Pág. 93
proyecto es
insuficiente.
R04 El costo estimado Se da el caso cuando los costos Podrá causar
es inferior a lo real. no han sido bien estimados
R05 Los miembros del Se da el caso cuando los Podrá causar errores durante
equipo de proyecto miembros del equipo enfrentan la planificación del proyecto
no cuentan con la por primera vez un proyecto.
suficiente
capacidad para
resolver problemas
complejos.
R06 Diseños erróneos Se da en el caso que al realizar Podrá causar retraso en el
actividades de implementación proyecto ante la necesidad
puede encontrarse que el de volver a considerar el
diseño carece del suficiente diseño trazado.
nivel de detalle o está mal
enfocado
Pág. 94
VALOR VALOR
PROBABILIDAD IMPACTO
NUMÉRICO NUMÉRICO
Muy Improbable 0.1 Muy bajo 0.05
Relativamente 0.3 Bajo 0.10 TIPO DE PROBABILIDAD
Probable RIESGOS X IMPACTO
Probable 0.5 Moderado 0.20 Muy Alto Mayor a 0.50
Muy probable 0.7 Alto 0.40 Alto Menor a 0.50
Casi Certeza 0.9 Muy alto 0.80 Moderado Menor a 0.30
Bajo Menor a 0.10
Muy Bajo Menor a 0.05
ESTIM
ACIÓN
ESTIMACIÓ PROB X
CÓDIG DE OBJETIVO TIPO DE
TITULO CAUSA RAÍZ N DE IMPACT
O PROB AFECTADO RIESGO
IMPACTO O
ABILID
AD
R01 El tiempo de los Podrá causar atrasos al 0.5 Alcance 0.20 0.1 Alto
principales momento de recopilar Tiempo 0.40 0.2
involucrados es información. Costo 0.20 0.1
insuficiente. Calidad 0.05 0.025
Probabilidad X impacto 0.425
Pág. 95
R02 Los involucrados no Podrá causar el atrasar la 0.1 Alcance 0.20 0.02 Bajo
colaboran de forma toma de requerimientos. Tiempo 0.40 0.04
eficiente en el Costo 0.20 0.02
proceso de Calidad 0.05 0.005
desarrollo del Probabilidad X impacto 0.085
proyecto.
R03 El tiempo Podrá causar un gran 0.3 Alcance 0.40 0.12 Muy Alto
programado para la retraso en el proyecto. Tiempo 0.80 0.24
elaboración del Costo 0.80 0.24
proyecto es Calidad 0.05 0.015
insuficiente. Probabilidad X impacto 0.615
R04 El costo estimado es Podrá causar 0.1 Alcance 0.10 0.01 Bajo
inferior a lo real. Tiempo 0.20 0.02
Costo 0.20 0.02
Calidad 0.05 0.005
Probabilidad X impacto 0.055
R05 Los miembros del Podrá causar errores 0.3 Alcance 0.80 0.24 Muy Alto
equipo de proyecto durante la planificación Tiempo 0.40 0.12
no cuentan con la del proyecto Costo 0.40 0.12
suficiente capacidad Calidad 0.20 0.06
para resolver Probabilidad X impacto 0.54
Pág. 96
problemas
complejos.
R06 Diseños erróneos Podrá causar retraso en 0.3 Alcance 0.40 0.12 Alto
el proyecto ante la Tiempo 0.80 0.24
necesidad de volver a Costo 0.40 0.12
considerar el diseño Calidad 0.10 0.03
trazado. Probabilidad X impacto 0.51
Pág. 97
2.1.7 PLAN DE RESPUESTA A RIESGOS
PLAN DE
PROB. POR
IMPACTO
TITULO DEL DESCRIPCION DEL CAUSA TIPO DE RESPUESTA AL
CODIGO
CONTINGEN-
RIESGO RIESGO RAIZ RIESGOS RIESGO
CIA
El tiempo de Se da el caso que el

los Sponsor no tenga Reestructurar
Informe elevado al
principales tiempo para dar Exceso el Plan de
R01 0.425 Alto sponsor sobre falta de
involucrados información, la cual Laboral Costos y
compromiso
es necesitamos durante Tiempo
insuficiente. el proyecto.
Los
Se da el caso en que
involucrados
los involucrados no Exceso
no colaboran Reestructurar
brindan la Laboral, Informe elevado al
de forma el Plan de
R02 información Falta de 0.085 Bajo sponsor sobre falta de
eficiente en Costos y
necesaria, que es compromis compromiso
el proceso de Tiempo
importante para o
desarrollo del
realizar el proyecto.
proyecto.
Incrementar
El tiempo la jornada
programado Programar horas laboral en 2
Se da el caso donde
para la Demora en extras para el horas diarias,
no se cumple los
R03 elaboración los 0.615 Muy Alto cumplimiento de los y de ser
tiempos establecidos
del proyecto procesos compromisos necesario
para el proyecto.
es asumidos sábados y
insuficiente. domingos
también.
El costo Se da el caso
Mala
estimado es cuando los costos no Asumir el costo, por
R04 estima-ción 0.055 Bajo -
inferior a lo han sido bien error en estimación
de costos
real. estimados
Los Se da el caso Falta de
Incrementar
R05 miembros del cuando los miembros profesiona- 0.54 Muy Alto Capacitar al personal
la jornada
equipo de del equipo enfrentan les
Pág. 98
proyecto no por primera vez un calificados, laboral a 10

cuentan con proyecto. Limitado horas
la suficiente Presupues-
capacidad to
para resolver
problemas
complejos.
Se da en el caso que
al realizar
actividades de Deficiencia Reunirse con
implementación en la los
Diseños
R06 puede encontrarse definición 0.51 Alto Reestructurar diseños interesados
erróneos
que el diseño carece de los para redefinir
del suficiente nivel requisitos diseños
de detalle o está mal
enfocado
ANEXOS
1. Estrategia para riesgos negativos o amenazas
2. Estrategia de respuesta para contingencias
E Evitar
T Transferir
M Mitigar
A Aceptar
RIESGOS DEL PROYECTO
ID DESCRIPCIÓN AMENAZAS PLAN DE CONTINGENCIA
R01 El tiempo de los principales E: Calendarizar

involucrados es insuficiente. reuniones.
T: Informe al Sponsor
M: Establecer reuniones Reestructurar el Plan de Costos y Tiempo
con los interesados
A: Horarios definidos por
los interesados.
Pág. 99
R02 Los involucrados no colaboran de E: Calendarizar

forma eficiente en el proceso de reuniones.
desarrollo del proyecto. T: Informe al Sponsor
M: Establecer reuniones Reestructurar el Plan de Costos y Tiempo
con los interesados
A: Horarios definidos por
los interesados.
R03 El tiempo programado para la E: Control permanente
Incrementar la jornada laboral en 2 horas
elaboración del proyecto es T: Plan de contingencia
diarias, y de ser necesario sábados y
insuficiente. M: Evitar demoras
domingos también.
A:
R04 El costo estimado es inferior a lo E: Realizar una
real. estimación de costos
minuciosa
T: Informe al sponsor -
M: Buscar otros
proveedores
A: Aceptar.
R05 Los miembros del equipo de E: Realizar concursos
proyecto no cuentan con la publico
Incrementar la jornada laboral a 10 horas
suficiente capacidad para resolver T: -
Capacitar al personal en temas de Visión
problemas complejos. M: Evaluar experiencia
Artificial, durante las 2 horas adicionales
profesional
A: Capacitar personal
R06 Diseños erróneos E: Definir diseños con
ayuda de los interesados.
T: - Reunirse con los interesados para redefinir
M: Reunirse con diseños
interesados
A: Reajustar diseños
Esencialmente se adquiere el personal de proyecto, y papel como suministro, en

cuanto al equipo, el consultorio cuenta con una PC, la cual será utilizada
exclusivamente para el desarrollo del proyecto.
Pág. 100
Se ha considerado un valor de depreciación, lo que puede apreciarse en la tabla de

presupuesto del proyecto.
2.1.8 MATRIZ DE ADQUISICIONES DEL PROYECTO.
PRODUCTO O SERVICIO A CODIGO TIPO DE PROCEDIMI RESPONSA FECHA

ADQUIRIR EDT CONTRATO ENTO BLE ADQUISICION
Concurso Project
ANALISTA 1.3 CAS 20 De Mayo
Público Manager
Concurso Project
PROGRAMADOR 1.3 CAS 12 de Agosto
Público Manager
Concurso Project
TESTER 1.3 CAS 20 de Mayo
Público Manager
Compra Compra Project
PAPEL 1 4 de Marzo
Contado Directa Manager
Valor de
Compra Project
COMPUTADORA 1 Depreciación 4 de Marzo
Directa Manager
por uso
2.1.9 PLAN DE GESTIÓN DE INTERESADOS.
El proceso de identificación de interesados, se realizó haciendo una investigación in

situ, el proceso fue el siguiente:
- Entrevista con los usuarios: aplicando una entrevista para lograr definir el alcance
general del proyecto.
- Entrevista con médico especialista: al igual que en el caso anterior
- Revisión documental: se hizo el levantamiento de las necesidades generales de los
usuarios directos, el mismo que ha sido revisado para tener una idea clara del
sistema a desarrollar.
Pág. 101
Stakeholders
Externos
Usuarios del sistema
Stakeholders Project Manager
del Equipo de Analista de Sistemas
Proyecto (Team Tester
Members) Programador de Sistemas
2.1.9.1 Stakeholders Externos:
- Usuarios del sistema:

Son las personas que se registran en el sistema a través de su dispositivo móvil y
que hacen uso del sistema para la detección de los problemas de piel.
2.1.9.2 Stakeholders Internos:
- Médicos.
El médico especialista es que nos asesorara en el desarrollo del proyecto y quien
nos brindara toda la información y conocimiento para poder desarrollar el sistema.
2.1.9.3 Stakeholders del Equipo de Proyecto:
- Project Manager
Definitivamente el Project Manager, es uno de los interesados más importantes, no
olvidemos que éste es su trabajo, y que además debe estar enterado o conocer en
forma clara como se realizan todos los procesos académicos en la institución. Él es
quien al final organizará, dirigirá y controlará la realización del proyecto.
- Analista de Sistemas
De igual forma, el analista al conformar o ser parte del Team Project (equipo de
proyecto), es uno de los principales interesados, porque de él depende cómo se
modelará el sistema, la planificación del mismo, los diseños de las interfaces, de la
base de datos y de las clases. El entregable del analista del sistemas, es un
Pág. 102
documento que será utilizado por los programadores, quienes son los que al final
implementarán el sistema.
- Programador de Sistemas
Los programadores, que como se mencionó, son los que construirán físicamente el
sistema.
- Tester
Es el encargado de realizar el seguimiento al desarrollo del sistema, de forma que
se asegure la calidad del producto final, además es el responsable de dar el visto
bueno al sistema elaborado, de acuerdo a los estándares de calidad definidos en el
plan de gestión de calidad.
2.1.9.4 Clasificación de Interesados: Matriz Influencia Vs Poder
Éste es una de las técnicas utilizadas para clasificar a los interesados. A

continuación mostramos un cuadro donde se especifica la estrategia a aplicar para
los stakeholders según su influencia y poder:
PODER SOBRE EL PROYECTO

BAJO ALTO
INFLUENCIA SOBRE EL PROYECTO
ESTRATEGIA ESTRATEGIA
ALTA
Trabajar con ellos Trabajar para él
ESTRATEGIA ESTRATEGIA
BAJA
Mantenerlos informados Mantenerlos informados

con un mínimo esfuerzo y nunca ignorarlos
Según ésta clasificación, ahora se muestra la clasificación específica de cada

stakeholder:
Pág. 103
INFLUENCIA PODER
BAJA ALTA BAJO ALTO
X X
Stakeholders Externos Usuarios
X X
Stakeholders Internos Médico especialista
X X
Project Manager X X
Stakeholders Internos Analista de Sistemas X X
(Team Members) Tester X X
Programador de Sistemas X X
2.1.9.5 Clasificación de Interesados: Matriz Interés Vs Poder
Ahora presentamos 2 cuadros: uno indicando las estrategias aplicadas para cada
stakeholder, y la otra indicando en específico el interés y el poder de los interesados:
Pág. 104
INTERÉS PODER
EN CONTRA NORMAL A FAVOR BAJO MEDIO ALTO
X X
Stakeholders Externos Usuarios
X X
X X
Stakeholders Internos Médico especialista
X X
Project Manager X X
Stakeholders Internos Analista de Sistemas X X
(Team Members) Tester X X
Programador de Sistemas X X
2.1.9.6 Clasificación de Interesados: Matriz Influencia Vs Impacto
En este caso, la influencia está relacionada al nivel de involucramiento con el

proyecto, y el impacto sobre la capacidad de realizar cambios trascendentes sobre
el proyecto, entonces las estrategias dependen del tipo de stakeholder.
IMPACTO SOBRE EL PROYECTO

BAJO ALTO
INFLUENCIA SOBRE EL PROYECTO
ALTA
BAJA
Pág. 105
Nivel de Análisis (High, Medium, Low)

Stakeholder Rol
Interés Impacto Influencia
Usuarios Postula al sistema de preselección de personal. High Low Low
Médico especialista El encargado formal de la selección de personal High High High
Project Manager Desarrolla el proyecto de sistemas High High High
Analista de Sistemas Modela el proyecto de sistemas High High Medium
Tester Supervisa la construcción del sistema High High Medium
Programador de Sistemas Programa el sistema High High Medium
Pág. 106
2.1.9.7 Registro de Stakeholders y Estrategia de Gestión.
Stakeholder Rol Riesgo Acción (Estrategia)

 Realiza las consultas sobre los problemas de piel y registra su  No sabe usar el
Usuarios  Diseñar una interfaz sencilla y amigable.
información sistema
 Mantener constante contacto con él, en horarios adecuados a
Médico especialista  Asesora al proyecto con su experiencia y conocimiento.  Falta de tiempo.
su gestión.
 Limitada
Analista de Sistemas  Modela el proyecto de sistemas  Realizar una selección de personal calificado.
experiencia.
 Limitada
Tester  Implementa y administra la base de datos  Realizar una selección de personal calificado.
experiencia.
Programador de  Limitada
 Programa el sistema  Realizar una selección de personal calificado.
Sistemas experiencia.
Pág. 107
ANEXO 1 – MATRIZ DE ADQUISICIONES

Pág. 108
ANEXO 2 – INFORME DE RENDIMIENTO DEL PROYECTO

Pág. 109
ANEXO 3 – SOLICITUDES DE CAMBIO

Pág. 110
ANEXO 4 – LECCIONES APRENDIDAS

Tesis Pmbok

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Tesis Pmbok

Transféré par

Droits d'auteur :

Formats disponibles

UNIVERSIDAD ALAS PERUANAS

FACULTAD DE INGENIERÍAS Y ARQUITECTURA

PRESENTADA POR EL BACHILLER

PARA OPTAR EL TÍTULO PROFESIONAL DE

A mis padres y hermanos; por la paciencia, comprensión y apoyo

A mis maestros quienes forjaron en mí su experiencia, sus

El presente proyecto tiene por objetivo desarrollar un sistema para el diagnóstico y

La información recolectada se obtuvo del médico pediatra Gonzalo Gutierrez Quispe

El proyecto contiene los siguientes capítulos:

En el capítulo I, se describen los aspectos generales de la empresa o institución donde

El Capítulo III, en éste capítulo básicamente se realizan 2 aspectos: la planificación del

CAPÍTULO I: ANÁLISIS DE LA ORGANIZACIÓN ........................................................ 1

1.1. Datos generales de la institución: ................................................................... 1

1.1.1. Nombre de la Institución.............................................................................. 1

1.1.2. Rubro o Giro del Negocio ............................................................................ 1

1.1.3. Breve Historia.............................................................................................. 1

1.1.4. Organigrama actual ..................................................................................... 4

1.1.5. Descripción de las Áreas funcionales. ......................................................... 6

1.1.6. Descripción general del proceso de negocio. .............................................. 6

1.2. Fines de la Organización ................................................................................ 7

1.2.1 Visión .......................................................................................................... 7

1.2.2 Misión ......................................................................................................... 7

1.3. Análisis externo .............................................................................................. 7

1.3.1 Análisis del entorno general. ....................................................................... 7

A. Factores económicos .................................................................................. 7

B. Factores tecnológicos. ................................................................................ 7

C. Factores políticos. ....................................................................................... 7

D. Factores sociales. ....................................................................................... 8

E. Factores demográficos. ............................................................................... 8

1.3.2 Análisis del entorno competitivo. ................................................................. 8

1.3.3 Análisis de la posición competitiva - Factores claves de éxito ..................... 9

1.4. Análisis Interno ............................................................................................. 10

1.4.1 Recursos y capacidades ........................................................................... 10

A. Recursos tangibles. ................................................................................... 10

B. Recursos intangibles. ................................................................................ 10

C. Capacidades organizativas. ...................................................................... 10

D. Análisis de recursos y capacidades........................................................... 11

1.4.2 Análisis de la cadena de valor ................................................................... 11

A. Actividades primarias. ............................................................................... 11

B. Actividades de apoyo. ............................................................................... 12

1.5 Análisis Estratégico ...................................................................................... 14

1.5.1 Análisis FODA ........................................................................................... 14

1.5.2 Matriz FODA ............................................................................................. 15

1.6 Descripción de la problemática ..................................................................... 16

1.6.1 Problemática ............................................................................................. 16

1.6.2 Objetivos ................................................................................................... 17

A. Objetivo General. ...................................................................................... 17

B. Objetivos específicos ................................................................................ 17

1.7 Resultados esperados .................................................................................. 17

CAPÍTULO II: MARCO TEÓRICO DEL NEGOCIO Y DEL PROYECTO ..................... 20

2.1 Marco teórico del Negocio ............................................................................ 20

2.1.1 Infecciones bacterianas de piel.............................................................. 20

2.1.2 Procesamiento Digital de Imágenes. ..................................................... 22

2.1.3 Razonamiento Basado en Casos ........................................................... 23

2.2 Marco Teórico del Proyecto. .................................................................. 27

2.2.1 Gestión del Proyecto. ............................................................................. 27

2.2.2 Ingeniería del Proyecto ........................................................................... 29

2.2.3 Soporte del Proyecto. ............................................................................. 32

2.2.4 Planificación de la calidad ...................................................................... 33

2.2.5 Identificación de Estándares y Métricas. ............................................... 35

2.2.6 Diseño de formatos de Aseguramiento de la Calidad. ......................... 36

CAPÍTULO III: INICIO Y PLANIFICACIÓN DEL PROYECTO ..................................... 40

3.1 Gestión del proyecto. .................................................................................... 40