UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL PROPUESTA DE ... · horas de paciencia. Gracias mi...

UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI)

PROPUESTA DE METODOLOGÍA PARA LA ADMINISTRACIÓN DE PROYECTOS DE DESARROLLO DE SOFTWARE EN LA UNIDAD DE

TECNOLOGÍAS DE INFORMACIÓN Y COMUNICACIÓN DEL HOSPITAL DOCTOR RAFAEL ÁNGEL CALDERÓN GUARDIA

ING. ROY CÉSPEDES GARBANZO

PROYECTO FINAL DE GRADUACION PRESENTADO COMO REQUISITO PARCIAL PARA OPTAR POR EL TITULO DE MASTER EN ADMINISTRACION

DE PROYECTOS

San José, Costa Rica

Febrero 2010

i

UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI)

Este Proyecto Final de Graduación fue aprobado por la Universidad como

requisito parcial para optar al grado de Máster en Administración de Proyectos

__________________________ Msc. Fabio Muñoz Jiménez

PROFESOR TUTOR

_________________________ Msc. Adriana Ruiz Suárez

LECTOR No.1

__________________________ Msc. Fausto Fernández

LECTOR No.2

________________________ Ing. Roy Céspedes Garbanzo

SUSTENTANTE

ii

DEDICATORIA

Dedico mi Proyecto Final de Graduación a mi Señor Dios todopoderoso, grande solo tú mi Señor, quién me ha dado el tiempo y la vida para poder realizarlo. A mi familia, mi esposa Kattia, mis hijas Catalina y María Paula, les amo. A mi madre que aunque ya hace un tiempo no se encuentra conmigo, me dejo la enseñanza de trabajo y empeño. Mami te amo mucho. A mi Papá, hermanas y sobrinos. A todo el resto de mi familia que siempre han estado conmigo. Y no me puedo olvidar de mis queridos suegros, que me han alentado y ayudado en mi desarrollo como profesional.

No te quejes, si sufres. Se pule la piedra que se estima, la que vale. ¿Te duele? Déjate tallar, con agradecimiento,

porque Dios te ha tomado en sus manos como un diamante No se trabaja así un guijarro vulgar.

Josemaría Escrivá de Balaguer

iii

RECONOCIMIENTOS

Le doy gracias a Dios, por la inteligencia y sabiduría, por la provisión que nunca falto y mis lagares siempre estuvieron llenos. Gracias Padre de los cielos. Ka, agradecido y comprometido contigo por el esfuerzo dedicado y las horas de paciencia. Gracias mi amor. Catalina y María Paula, gracias por su comprensión los sábados que tenían actividades y no las puede acompañar o no pudieron ir. Mis chiquitas les agradezco y las amo montones. A toda mi familia que de uno u otra forma me ayudaron, aunque a veces se burlaron y tenían sus dudas, siempre me escucharon y sé que se regocijan conmigo de mi logro. A los Profesores de la UCI, personal administrativo, en especial al Profesor Fabio Muñoz por toda la ayuda brindada a mi persona, salgo realmente muy satisfecho con mi aprendizaje. A todos aquellos que piensan que no los tome en cuenta, este apartado es para ustedes, muchas gracias.

ÍNDICE

iv

HOJA DE APROBACION ii DEDICATORIA iii AGRADECIMIENTO iv INDICE v INDICE DE ILUSTRACIONES viii INDICE CUADROS viii RESUMEN EJECUTIVO ix 1. INTRODUCCIÓN ............................................................................................. 1

1.1. Antecedentes ............................................................................................ 1

1.2. Problemática ............................................................................................. 5

1.3. Justificación del problema ......................................................................... 5

1.4. Supuestos ................................................................................................. 6

1.5. Restricciones ............................................................................................ 7

1.6. Objetivo general ........................................................................................ 7

1.7. Objetivos específicos ................................................................................ 7

2. MARCO TEÓRICO .......................................................................................... 9

2.1. Marco referencial o institucional ............................................................... 9

2.1.1. Reseña histórica ................................................................................................... 9

2.2. Teoría de Administración de Proyectos .................................................. 18

2.2.1. Proyecto ............................................................................................................. 18 2.2.2. Administración de Proyectos ............................................................................... 20 2.2.3. Áreas del Conocimiento de la Administración de Proyectos ................................. 20 2.2.4. Ciclo de vida de un proyecto ............................................................................... 22 2.2.5. Procesos en la Administración de Proyectos ....................................................... 22

2.3. Áreas del Conocimiento relacionadas con el PFG ..................................... 25

2.3.1. Gestión de Integración ........................................................................................ 25 2.3.2. Gestión de Alcance ............................................................................................. 26 2.3.3. Gestión del Tiempo ............................................................................................. 27 2.3.4. Gestión de Calidad.............................................................................................. 27 2.3.5. Gestión de Recursos Humanos ........................................................................... 28 2.3.6. Gestión de Comunicaciones ................................................................................ 29 2.3.7. Gestión de Riesgo .............................................................................................. 30

2.4. Rational Unified Process (RUP) .............................................................. 31

2.4.1. Historia ............................................................................................................... 31 2.4.2. Características esenciales................................................................................... 32 2.4.3. Otras prácticas .................................................................................................... 35 2.4.3.1. Gestión de requisitos .......................................................................................... 36 2.4.3.2. Desarrollo de software iterativo ........................................................................... 36 2.4.3.3. Desarrollo basado en componentes .................................................................... 36 2.4.3.4. Modelado visual .................................................................................................. 36 2.4.3.5. Verificación continua de la calidad ....................................................................... 36 2.4.3.6. Gestión de los cambios ....................................................................................... 37 2.4.4. Ejes de la RUP.................................................................................................... 37

2.5. PMBOK y RUP ....................................................................................... 44

2.6. Plan de Capacitación del CENDEISS ..................................................... 48

2.6.1. Aspectos introductorios ....................................................................................... 49 2.6.2. Objetivos y Metas del Plan de Capacitación ........................................................ 49

v

2.6.3. Operacionalización del Plan ................................................................................ 49 2.6.4. Logística de la capacitación ................................................................................ 50 2.6.5. Materiales para el desarrollo de la capacitación................................................... 51 2.6.6. Evaluación del plan de capacitación .................................................................... 51 2.6.7. Financiamiento de las actividades educativas. .................................................... 52

3. MARCO METODOLÓGICO ........................................................................... 53

3.1 Fuentes de información .......................................................................... 53

3.1.1. Fuentes primarias ............................................................................................... 53 3.1.2. Fuentes secundarias ........................................................................................... 54

3.2 Técnicas de investigación ....................................................................... 54

3.2.1. Investigación documental .................................................................................... 54 3.2.2. Investigación de campo ...................................................................................... 54 3.2.3. Investigación mixta.............................................................................................. 56

3.3 Método de investigación. ........................................................................ 56

3.3.1. Método analítico-sintético .................................................................................... 57 3.3.2. Métodos particulares y específicos ...................................................................... 57 3.3.3. Método de observación ....................................................................................... 57

4. DESARROLLO .............................................................................................. 65

4.1 Objetivo Específico Número 1 ................................................................ 66

4.1.1. Área de Gestión de Integración ........................................................................... 68 4.1.2. Área de Gestión del Alcance ............................................................................... 69 4.1.3. Área de Gestión de Tiempo ................................................................................. 70 4.1.4. Área de Gestión de Calidad ................................................................................ 71 4.1.5. Área de Gestión de Recurso Humano ................................................................. 72 4.1.6. Área de Gestión de Comunicación ...................................................................... 73 4.1.7. Área de Gestión de Riesgos ................................................................................ 74



4.3.1. Fase de Iniciación ............................................................................................... 79 4.3.1.1. Actividades, roles y artefactos de la fase de iniciación ............................................ 81 4.3.1.1.1. Estudiar un nuevo proyecto .................................................................................. 81 4.3.1.1.2. Priorizar el portafolio de proyectos ........................................................................ 81 4.3.1.1.3. Gestión de Integración ......................................................................................... 82 4.3.1.1.4. Gestión del Alcance ............................................................................................. 84 4.3.1.1.5. Gestión del Tiempo .............................................................................................. 85 4.3.1.1.6. Gestión de Riesgos .............................................................................................. 86 4.3.1.1.7. Gestión de Comunicaciones ................................................................................. 87 4.3.1.1.8. Gestión de Recursos Humanos ............................................................................ 87 4.3.2. Fase de elaboración ............................................................................................ 88 4.3.2.1. Actividades, roles y artefactos de la fase de elaboración ......................................... 89 4.3.2.1.1. Análisis de requerimientos .................................................................................... 89 4.3.2.1.2. Analizar comportamiento ...................................................................................... 90 4.3.2.1.3. Diseñar componentes........................................................................................... 91 4.3.2.1.4. Diseñar base de datos.......................................................................................... 91 4.3.2.1.5. Administrar ejecución ........................................................................................... 92 4.3.2.1.6. Monitorear y controlar el proyecto......................................................................... 92 4.3.2.1.7. Preparar ambientes para el desarrollo .................................................................. 92 4.3.3. Fase de construcción .......................................................................................... 93 4.3.3.1. Actividades, roles y artefactos de la fase de construcción ........................................ 94 4.3.3.1.1 Implementar componentes .............................................................................. 94 4.3.3.1.2 Probar y Evaluar ............................................................................................. 94

vi

4.3.3.1.3 Administrar cambios ....................................................................................... 95 4.3.3.1.4 Administrar ejecución ...................................................................................... 95 4.3.3.1.5 Monitorear y controlar el proyecto ................................................................... 95 4.3.4. Fase de transición ............................................................................................... 95 4.3.4.1. Actividades, roles y artefactos de la fase de transición ........................................ 96 4.3.4.1.1. Realizar pruebas de aceptación ...................................................................... 96 4.3.4.1.2. Administrar cambios ....................................................................................... 97 4.3.4.1.3. Desarrollar el material de apoyo ...................................................................... 97 4.3.4.1.4. Realizar la puesta en marcha .......................................................................... 98 4.3.4.1.5. Liberar versión ................................................................................................ 98 4.3.4.1.6. Administrar ejecución ...................................................................................... 99 4.3.4.1.7. Monitoreo y control de proyectos..................................................................... 99


4.4.1. Gestión de capacitación .................................................................................... 100 4.4.2. Conformación del equipo de trabajo .................................................................. 101 4.4.3. El Financiamiento de las Actividades Educativas ............................................... 101 4.4.4. Diagnóstico de necesidades del Recurso Humano ............................................ 102 4.4.5. El Plan de Capacitación y Formación ................................................................ 103

5. CONCLUSIONES ........................................................................................ 112

6. RECOMENDACIONES ................................................................................ 115

7. BIBLIOGRAFIA ............................................................................................ 118

8. ANEXOS ...................................................................................................... 120

8.1. Anexo n.o 1: Acta del proyecto .............................................................. 120

8.2. Anexo n.o 2: EDT .................................................................................. 121

8.3. Anexo n.o 3: Cronograma ..................................................................... 122

8.4. Anexo n.o 4: Carta de Aceptación del Proyecto .................................... 123

8.5. Anexo nº 5. Acta de reunión ................................................................. 125

8.6. Anexo n.o 6: Plantilla para la carta de constitución del proyecto ........... 127

8.7. Anexo n.o 7: Plantilla para desarrollar el control de cambios ................ 133

8.8. Anexo n.o 8: Plantilla para reporte de avance ....................................... 139

8.9. Anexo n.o 9: Plan de Métricas ............................................................... 143

8.10. Anexo n.o 10: Cronograma ................................................................ 145

8.11. Anexo n.o 11: Lista de asuntos .......................................................... 146

8.12. Anexo n.o 12: Orden de trabajo ......................................................... 147

8.13. Anexo n.o 13: Informe del estado del proyecto .................................. 149

8.14. Anexo nº 14. Plan del proyecto ......................................................... 153

8.15. Anexo n.o 15: Estructura detallada de trabajo ................................... 162

8.16. Anexo n.o 16: Plantilla para recopilar requerimientos ........................ 163

8.17. Anexo n.o 17: Gestión de riesgos ...................................................... 169

8.18. Anexo n.o 18: Gestión de comunicación ............................................ 180

8.19. Anexo n.o 19: Documento de arquitectura de software ..................... 186

8.20. Anexo n.o 20: Plantilla de caso de uso .............................................. 195

8.21. Anexo n.o 21: Documento de diseño técnico del software ................ 199

8.22. Anexo n.o 22: Documento para casos de pruebas ............................ 205

8.23. Anexo 23. Plantilla Minuta de Aceptación ......................................... 211

8.24. Anexo n.o 24: Documento de implementación del proyecto .............. 212

vii

8.25. Anexo n.o 25: Comunicado de liberación de versión ......................... 217

ÍNDICE DE ILUSTRACIONES

Figura n.o 1: Área de atracción directa del hospital Dr. R. A. Calderón Guardia.(UTIC,2004) ......................................................................................................... 11

Figura n.o 2: Áreas de atracción indirecta del hospital Dr. R. A. Calderón Guardia.(UTIC,2004) ......................................................................................................... 12

Figura n.o 3: Relaciones de Coordinación de la UTIC.(CCSS,1997) ........................ 13

Figura n.o 4: Área Estructura organizacional hospital Dr. R. A. Calderón Guardia.(CCSS,1997) ....................................................................................................... 16

Figura n.o 5: Área Estructura programática UTIC.(CCSS,1997) ................................ 17

Figura n.o 6: Historia de RUP. (P. Letelier,2003) .......................................................... 32

Figura n.o 7: Los Casos de Uso integran el trabajo. (P. Letelier,2003) ..................... 33

Figura n.o 8: Evolución de la arquitectura del sistema. (P. Letelier,2003) ................ 34

Figura n.o 9: Una iteración RUP. (P. Letelier, 2003) .................................................... 35

Figura n.o 10: Eje Horizontal. (P. Letelier, 2003) .......................................................... 37

Figura n.o 11: Fases e hitos en RUP. (P. Letelier, 2003) ............................................ 38

Figura n.o 12: Eje vertical. (P. Letelier, 2003) ............................................................... 40

Figura n.o 13: Relación entre roles, actividades, artefactos. (P. Letelier, 2003) ..... 41

Figura n.o 14: Fases del proceso de desarrollo de Software ...................................... 78

Figura n.o 15: Flujo de trabajo para la fase de iniciación ....................................... 80 Figura n.º 16: Flujo de trabajo para la fase de elaboración ................................... 89 Figura n.o 17: Flujo de trabajo para la fase de construcción ....................................... 93

Figura n.o 18: Flujo de trabajo para la fase de transición ............................................ 96

viii

ÍNDICE DE CUADROS

Cuadro n.o 1: Misión y visión (Fuente: Página web C.C.S.S, Página intranet del hospital Calderón Guardia) ............................................................................................... 14

Cuadro n.o 2: Procesos y descripción Gestión de Integración ................................... 25

Cuadro n.o 3: Procesos y descripción Gestión de Alcance ......................................... 26

Cuadro n.º 4: Procesos y descripción Gestión del Tiempo ......................................... 27

Cuadro n.o 5: Procesos y Descripción Gestión de Calidad ......................................... 28

Cuadro n.o 6: Procesos y Descripción Gestión de Recursos Humanos ................... 29

Cuadro n.º 7: Procesos y Descripción Gestión de Comunicaciones ......................... 29

Cuadro n.º 8: Procesos y Descripción Gestión de Riesgos ........................................ 30

Cuadro n.o 9: Operacionalización de Objetivos ............................................................ 49

Cuadro n.o 10: Resumen para el Desarrollo del Marco Metodológico ...................... 63

Cuadro n.o 11: Fortalezas y debilidades entre el PMBOK y la RUP .......................... 46

Cuadro 12: Fase de Iniciación - Estudiar un nuevo proyecto ..................................... 81

Cuadro 13: Fase de Iniciación - Priorizar el portafolio tecnológico ............................ 82

Cuadro 14. Fase de Iniciación – Gestión de Integración ............................................. 82

Cuadro 15: Fase de Iniciación – Gestión del Alcance ................................................. 84

Cuadro 16: Fase de Iniciación – Gestión del Tiempo .................................................. 86

Cuadro 17: Fase de Iniciación – Gestión de Riesgos .................................................. 86

Cuadro 18: Fase de Iniciación – Gestión de Comunicaciones ................................... 87

Cuadro 19: Fase de Iniciación – Gestión de Recursos Humanos ............................. 88

Cuadro 20: Fase de Elaboración – Análisis de requerimientos ................................. 90

Cuadro 21: Fase de Elaboración - Analizar comportamiento ..................................... 90

Cuadro 22Fase de Elaboración - Diseñar componentes ............................................. 91

Cuadro 23: Fase de Elaboración - Diseñar base de datos ......................................... 91

Cuadro 24: Fase de Elaboración - Preparar ambientes para el desarrollo .............. 92

Cuadro 25: Fase de Construcción - Implementar componentes ................................ 94

Cuadro 26: Fase de Construcción - Probar y evaluar .................................................. 95

Cuadro 27: Fase de Transición - Realizar pruebas de aceptación ............................ 97

Cuadro 28: Fase de Transición - Desarrollar material de apoyo ............................... 97

Cuadro 29: Fase de Transición - Realizar la puesta en marcha ................................ 98

Cuadro 30: Fase de Transición – Liberar versión ......................................................... 98

ix

ÍNDICE DE ABREVIACIONES

CCSS …………………………………………….Caja Costarricense de Seguro Social

CENDEISS… …………..Centro de Desarrollo Estratégico e Información en Salud y

Seguridad Social

CGI ……………………………………………………….Centro de Gestión Informática

EDT…………………………………………………….Estructura Detallada del Trabajo

PFG……………………………………………………….Proyecto Final de Graduación

PMBOK ……………………….La Guía de los fundamentos de la dirección de proyectos

(Project Management Body of Knowledge)

PMI ………Instituto de Administración de Proyectos (Project Management nstitute)

RUP …………………………………………………………Proceso Unificado Racional

TI……………………………………………………………..Tecnologías de Información

UML……………………..Lenguaje Unificado de Modelado (Unified Model Languge)

UTIC ……… Unidad de Tecnologías de Información y Comunicación del Hospital

XP Programación extrema

x

RESUMEN EJECUTIVO

Este proyecto final de graduación surgió ante la necesidad y carencia de una metodología adecuada para el desarrollo de proyectos de software internos en la Unidad de Tecnologías de Información y Comunicación del Hospital Dr. R. A. Calderón Guardia. Es de conocimiento general que uno de los activos más importante para las empresas o instituciones es la información; por lo tanto, es necesario que la administración de la información esté bien protegida, que conserve su integridad y que se encuentre disponible en forma ágil, oportuna y segura para los usuarios que necesiten trabajar con ella. Por tales motivos, es muy importante que el manejo de los proyectos, con las etapas de análisis y desarrollo de los sistemas informáticos sean elaborados y estructurados; de forma tal que la administración y manejo de los datos contribuyan a mejorar la atención de los usuarios de los servicios del hospital. Esto acontece por la particularidad que tiene la industria de desarrollo de software, en donde se producen y se seguirán produciendo cambios muy vertiginosos. De la programación estructurada se ha pasado a la programación orientada a objetos y web; de lenguajes de programación en cobol, se pasó a desarrollar en C++ o java. Se preguntará amigo lector, si ya existen en el mercado de la industria de desarrollo de software metodologías específicas que guían paso a paso en la elaboración de un proyecto de sistemas de información ¿por qué entonces crear una metodología para el desarrollo de software y no adquirir una ya creada? y ¿por qué unir las mejores prácticas de la administración de proyectos y la RUP? El objetivo principal de este trabajo de PFG es proponer una metodología ajustada, al diario quehacer en el desarrollo de sistemas de información de la UTIC. Esta propuesta metodológica, que una vez establecida brinde una mejor experiencia en la administración de proyectos ofreciendo resultados más efectivos. Para el PFG se estudiaron y analizaron las áreas del conocimiento y sus procesos aquellos que más convenían a la hora de mezclarlos con la metodología de desarrollo de software RUP. La UTIC cuenta con 6 analistas programadores que desarrollan todo el software interno para el Hospital Dr. R.A. Calderón Guardia, con miras a llevar el desarrollo informático del hospital a otros centros de salud de la CCSS. Es una batalla contra el tiempo porque en todo lo que lleva la UTIC creada, no ha existido el complemento ideal para desarrollar los sistemas con una metodología que se

xi

ajuste a la administración de proyectos de software y una exigencia por parte de la CCSS., para la exportación de los proyectos de software. Con el fin de elaborar una metodología personalizada a la UTIC, como primer objetivo para definir las áreas del conocimiento y los grupos del proceso que aplican a la Unidad de Tecnología de Información y Comunicación en el desarrollo de su software interno se realizaron cuestionarios a los funcionarios que laboran en dicha área. Posteriormente, se realizó un análisis de la metodología de desarrollo de software Rational Unified Process (RUP) para integrarla en la propuesta para la administración y desarrollo de proyectos de software interno en la Unidad de Tecnología de Información y Comunicación. El análisis anterior permitió contar con una idea clara para elaborar la metodología. Se determinó que los analistas programadores de la UTIC, ejercen las labores de un administrador de proyectos de una manera empírica, pues no poseen el conocimiento de lo que esto implica a la hora de administrar proyectos, y carecen de toda la experticia para tal tarea y de herramientas que ayuden en su diario quehacer. A todo esto se les ha endosado actividades muy particulares, que vienen a contraindicar todo lo que una metodología de desarrollo propone; es por ello que se diseñó una metodología en donde se contempla el diseño de plantillas para el uso de los analistas programadores, esto permitirá trabajar de una manera estructurada y estandarizada para todo analista programador que desarrolle sistemas en la UTIC. Además se recomienda una estrategia de capacitación para la metodología de acuerdo con los lineamientos Institucionales y del CENDEISS. Dentro de la conclusiones principales están el integrar la RUP con los grupos de procesos y áreas del conocimiento para contar con una metodología de desarrollo de software y poder alcanzar los objetivos del proyecto, el tiempo y alcance y el grado de satisfacción del cliente en cuanto a las necesidades planteadas. La responsabilidad del trabajo asignado, el asegurar un estándar de desarrollo de software al utilizar las plantillas diseñadas en la metodología y poder presentar ante la C.C.S.S. proyectos de software que sean declarados exportables a otros centros de salud. Dentro de las recomendaciones principales están el indicar a la Jefatura de la UTIC, promover el uso de la metodología de desarrollo de software, buscando la estandarización en el desarrollo de proyectos de software y la creación de una base de datos histórica para recapitular las lecciones aprendidas de los proyectos anteriores y poder aplicarlos en nuevos proyectos. Como producto final con este documento se ordenó la casa con una metodología que se utilizará en todos los proyectos de desarrollo interno de sistemas que se realicen buscando siempre la finalidad del alcance, tiempo, costo y calidad en los proyectos.

1

1. INTRODUCCIÓN

1.1. Antecedentes

La CCSS como ente facilitador de los servicios de salud de Costa Rica, tiene el

cargo de coordinar y ejecutar programas de prevención, curación y tratamiento,

abarcando tanto a la población costarricense como a la población inmigrante que

reside en nuestro país.

En 1973 por medio de la Ley Nº 5349, se aprobó el traspaso a la CCSS de los

hospitales administrados por el Consejo Técnico de Asistencia Médico Social y

financiados con fondos provenientes de la Junta de Protección Social y el Estado.

Actualmente, el sistema de salud cuenta con 29 hospitales.

Uno de esos hospitales es el hospital Dr. Rafael Ángel Calderón Guardia el cual

inicia su historia a finales de 1944, la CCSS compró el edificio que se conocía

como “Casa Cuna” o “La Casa de la Madre y el Niño”. Para 1945 se transformó

en la consulta externa de la CCSS en San José, bajo la dirección del Dr. Carlos

Sáenz Mata. Los pacientes eran internados en el hospital San Juan de Dios en el

salón Echeverría, donde la CCSS tenía 40 camas alquiladas y le pagaba a los

médicos de ese hospital por los servicios que les prestaban a sus pacientes.

Para fines de 1945 y en vista de la gran demanda de servicios, se le hicieron

varias reparaciones y ampliaciones al edificio y así nació el primer hospital de la

CCSS conocido como el Policlínico y más adelante como Hospital Central y fue el

único hospital de administración propia del Seguro Social.

Tiempo después le fue dado el nombre de Hospital Dr. Rafael Ángel Calderón

Guardia y así se le conoce hasta la fecha. Para el año 1972, la crisis de los

2

servicios hospitalarios en el área metropolitana era tan seria, que se decide dividir

la misma en tres sectores y con un hospital a la cabeza de cada uno de ellos, el

México, el San Juan y el Calderón Guardia. En la administración del entonces

presidente de la República Lic. Daniel Oduber Quirós, se da la aprobación por

parte de la Junta Directiva de la CCSS de los planos y la construcción de la Torre

Médica actual de más de 17 mil metros cuadrados. Al concluir la obra se contaba

con 522 camas, con lo cual el hospital Dr. Rafael Angel Calderón Guardia pese a

tener menos camas que los otros hospitales nacionales y menos trabajadores, da

el mayor número de consultas anuales, 558 mil, con un índice ocupacional de 88%

y es el hospital de más egresos del país.

Actualmente el hospital brinda una serie de servicios en materia de salud, entre

estos están:

• Servicios de Hospitalización.

• Servicios de Consulta Externa.

• Servicio de consulta a Emergencias.

• Servicio de consulta a Odontología.

• Servicios de apoyo al diagnóstico y tratamiento clínico.

• Servicios administrativos.

Para el año de 1998 se crean los Centros de Gestión Informática (en adelante

CGI), obedeciendo a las políticas de desconcentración de hospitales nacionales

según la ley n.o 7852 y de la gestión operativa de la función informática

institucional. La ley pretende que las decisiones se tomen más cerca de la acción,

otorgar mayor autoridad y responsabilidad a los niveles desconcentrados y

mejorar la eficacia en la prestación de los servicios.

Es una unidad de trabajo operativa de línea que apoya la gestión informática,

mediante la ejecución de estudios de necesidades, elaboración de planes en

3

sistemas de información, desarrollo de proyectos, introducción de nuevas

tecnologías y la administración de equipos y redes dentro de su ámbito de

competencia.

Los CGI están organizados y desarrollan su gestión en los niveles: Gerencial,

Hospitales Nacionales Desconcentrados, Regional y Local. Son responsables

técnicamente de los sistemas de información y procesos informáticos propios de

cada uno de ellos, coordinando lo correspondiente con otros centros similares, con

la Dirección de Informática, y con el Consejo en Sistemas de Información de su

ámbito de acción, para la integración con los sistemas locales, regionales o

institucionales.

La autoridad conferida en sus actuaciones con los usuarios finales es de carácter

técnico funcional, y su responsabilidad es el desarrollo y mantenimiento de los

sistemas y aplicaciones con recursos técnicos propios o la contratación de

servicios, la administración de base de datos y la asesoría correspondiente para la

adquisición de hardware y software.

Desde su misma creación en 1998, elCGI del Hospital Dr. R.A. Calderón Guardia

no tuvo un comienzo glorioso, con tan solo tres persona, sin experiencia en el

campo del manejo de centros de computo, sin presupuesto y con una mirada

indredula por parte del personal del hospital. Avanzando en el tiempo se realizan

las primeras planificaciones para desarrollar un sistema de información que

catapultura al hospital a lugares de máxima altura en la tecnología de ayuda en la

atención del paciente. Se da la creación del modelo de datos, el diccionario de

datos y los primeros servicios que se van a incorporar en el nuevo desarrollo

informático. Los proyectos no tenian una esquematización, ni seguían un estandar

de programación de software, cada funcionario desarrollaba según su criterio y de

manera informal se coordinaba el aspecto de las ventanas de mantenimiento y los

4

iconos más representativos. Lo que más interesaba era terminar el proyecto,

cuando, solo lo más rapido posible. Se asignaron a los funcionarios sin contar con

herramientas de diseño o plantillas para llevar una secuencia de actividades y así

desarrollar el software. Ni siquiera los diagramas de flujo o las pruebas de

escritorios se desarrollaban. De una vez se creaban las tablas de la base de

datos, que en muchas ocaciones se debian corregir o borrar. Una vez hecha las

tablas se procedia a desarrollar código, con solo la idea y la intuición del

funcionario y de esta manera tratar de satisfacer las necesidades del usuario. No

se tenian planteamientos claros de requerimientos, las reuniones con los usuarios

se desarrollaban bajo una informalidad, se apersona el funcionario del CGI al

departamento para ver si el usuario le podía atender. Para las necesidades de

hardware, se hacia una estimación de cuantos equipos debia contar el proyecto.

Para hacer la compra la Jefatura solo preguntaba cuantos equipos se ocupaban,

cuantos puntos de red, cuantas unidades de potencia y cuantas impresoras. Todo

lo anterior no quedaba documentado, teniendo en ocaciones que hacer memoria

para acordarse cual fue la cifra que se dio anteriomente.

Al pasar de los tiempos y hasta el día de hoy la manera de trabjo es la misma, un

ambiente de desarrollo de sistemas desordenado, de descontrol y en ocaciones de

incertidumbre porque los proyectos aunque son complejos y sencibles para la

población médica, no se apegan a una metodología que permita trabajar de una

forma sistematica, controlada y ordenada y que cumpla con los estandares y

normativas que la C.C.S.S. está exigiendo para los sistemas que se desarrollan en

sus dependencias.

En el año 2006 la antes Dirección de Tecnologías de Información de la CCSS,

ente rector de los CGI cambia su estructura como departamento y pasa a ser la

Subgerencia de Tecnologías de Información y Comunicación, como se conoce en

la actualidad. Al darse este cambio, todos los CGI de la CCSS tiene un cambio en

5

su nombre, Unidad de Tecnologías de Información y Comunicación (en adelante

UTIC).

1.2. Problemática

La Unidad de Tecnologias de Información y Comunicación del Hospital Dr. Rafael

Angel Calderón Guardia carece de una metología de desarrollo de proyectos de

software, provocando que los proyectos sean desordenados, no controlables y sin

alcanzar la satisfacción del usuario. De igual manera por esta carencia no cuenta

con referencias históricas basados en resultados de proyectos anteriores que le

permitan determinar el tiempo, costo y alcance de una forma más precisa y hacer

estimaciones más exactas. Lo cual ocasiona el no poder exportar los sistemas de

información a otros hospitales del sector público. Se trabaja de forma artesanal, la

cual consiste en el desarrollo de software según el criterio e intuición del analista

al cual se le asigna el proyecto, lo que a menudo requiere de esfuerzos heroicos

para llegar a buen puerto, con los consecuentes desfases de fechas y coste, y el

más que probable desgaste del personal del equipo de proyecto. Además se

evidencia una falta de experiencia en la administración de proyectos por parte de

los analistas de la Unidad de Tecnologías de Información y Comunicación, aunque

en sus labores diarias tienen inmersas tareas de manejo de proyectos.

Las recientes auditorias efectuadas a la Unidad de Tecnologías de Información y

Comunicación (de ahora en adelante mencionada UTIC), refleja con un impacto

alarmente en sus recomendaciones que la UTIC tiene que adoptar una

metodología de desarrollo de software que en la actualidad no se tiene.

1.3. Justificación del problema

La propuesta de la metodología de la administración y desarrollo de software

interno pretende que los desarrollos de sistemas de información del Hospital Dr.

Rafael Angel Calderón Guardia, cuenten con una estructura que les permita llevar

6

a cabo con éxito su finalización y su futura implementación en otros hospitales

públicos.

La dificultad propia del desarrollo de software y su impacto en el hospital, han

puesto de manifiesto las desventajas y en muchos casos la necesidad de aplicar

una metodología formal para llevar a cabo los proyectos desarrollados

internamente en la UTIC.

Es necesario establecer un enfoque disciplinado y sistemático para desarrollar un

proyecto de software y con esto incrementar la calidad del mismo a través de una

mayor transparencia y control, lo cual se refleja en un proceso formal para tener

un desarrollo de software con el menor número de fallos, en el tiempo establecido,

con resultados predecibles permitiendo obtener el producto final de alta calidad y

que satisfaga las necesidades y expectativas del cliente.

Con respecto a la metodología de desarrollo de software en el año 2008, la Caja

Costarricense de Seguro Social adquirió licencias de la metodología de desarrollo

de software Rational Unified Process (en adelante RUP), por este motivo no se

analizan otras metodologías de desarrollo de software como Programación

extremo (en adelante XP) entre otras, porque la C.C.S.S. está capacitando al

personal de análisis y desarrollo y otorgando la metodología a las Unidades de

Tecnologías de Información y Comunicación.

1.4. Supuestos

Para el desarrollo de este proyecto se consideran los siguientes supuestos:

• Se cuenta con la autorización de la Jefatura de la Unidad de Tecnologias de

Información y Comunicación para el desarrollo del proyecto.

7

• Accesibilidad de información como normativas, directrices y estándares que

rigen a las Unidades de Tecnologías de Información y Comunicación en la

CCSS.

• Disponibilidad del personal de la Unidad de Tecnologias de Información y

Comunicación para las consultas necesarias para realizar la propuesta de

diseño de la metodología.

1.5. Restricciones

Para el desarrollo de esta investigación es importante mencionar las siguientes

restricciones:

• El tiempo que se cuenta para desarrollar la propuesta de la metodología es

relativamente corto.

• Cambio de jefatura por presentar problemas de enfermedad grave.

• La entrega de licencias de la metodología RUP por parte de la C.C.S.S.

1.6. Objetivo general

Elaborar una propuesta de una metodología para la administración y desarrollo de

proyectos de software interno en la Unidad de Tecnologías de Información y

Comunicaciones del Hospital Doctor Rafael Ángel Calderón Guardia con el fin de

contar con una herramienta que permita estandarizar el desarrollo de estos

proyectos.

1.7. Objetivos específicos

� Definir las áreas del conocimiento y grupos de procesos, con el fin de

aplicarlos en la propuesta de administración y desarrollo de proyectos de

software interno de la Unidad de Tecnologías de Información y

Comunicaciones del Hospital Dr. Rafael Ángel Calderón Guardia.

8

� Analizar la metodología de desarrollo de software Rational Unified

Process (RUP), con el fin de integrarla en la propuesta de administración

y desarrollo de proyectos de software interno de la Unidad de

Tecnologías de Información y Comunicaciones del Hospital Dr. Rafael

Ángel Calderón Guardia.

� Elaborar una metodología de administración y desarrollo de proyectos de

software interno, con el fin de aplicarla en los proyectos de la Unidad de

Tecnologías de Información y Comunicaciones del Hospital Dr. Rafael

Ángel Calderón Guardia.

� Recomendar una estrategia de capacitación para la metodología de

administración y desarrollo de software interno, para inducir al uso de

dicha metodología en los funcionarios de la Unidad de Tecnologías de

Información y Comunicación.

9

2. MARCO TEÓRICO

2.1. Marco referencial o institucional

2.1.1. Reseña histórica

La idea de establecer un Seguro Social comenzó a surgir en el siglo XIX, cuando

algunos costarricenses al viajar a Europa observaron el modelo que se utilizaba en

ese entonces y el impacto causado en la sociedad. En el año 1941 en aquel

tiempo presidente de la República, Dr. Rafael Ángel Calderón Guardia, decide

enviar al Dr. Guillermo Padilla Castro a Chile para que investigue el

funcionamiento de los seguros sociales de ese país y así, realizar una propuesta

para su creación en Costa Rica.

Para el mes de septiembre de 1941 se remite a la Asamblea Legislativa el

proyecto de ley para la creación del Seguro Social costarricense, el cual fue

aprobado el 1 de noviembre de 1941.

En 1973 por medio de la Ley n.º 5349, se aprobó el traspaso a la CCSS de los

hospitales administrados por el Consejo Técnico de Asistencia Médico Social y

financiados con fondos provenientes de la Junta de Protección Social y el Estado.

Actualmente el sistema de salud cuenta con 29 hospitales de administración

propia y uno de ellos es el Hospital Dr. Rafael Ángel Calderón Guardia. A fines de

1944, la CCSS compró el edificio que se conocía como “Casa Cuna” o “La Casa

de la Madre y el Niño”. Para 1945 se transformó en la consulta externa de la

CCSS en San José, bajo la dirección del Dr. Carlos Sáenz Mata; los pacientes

eran internados en el Hospital San Juan de Dios en el salón Echeverría, donde la

CCSS tenía 40 camas alquiladas y le pagaba a los médicos de ese hospital por los

servicios que les prestaban a sus pacientes.

10

Las ampliaciones y remodelaciones no se hicieron esperar, y así fue creciendo el

hospital pasando de 29 camas a 100 hasta llegar en 1960 a 350 camas. Todos los

días, se ampliaban áreas, se abrían consultorios, se remodelaban las salas de

operaciones, etc.

Tiempo después le fue dado el nombre de Hospital Dr. Rafael Ángel Calderón

Guardia y así se le conoce hasta la fecha. Para el año 1972, la crisis de los

servicios hospitalarios en el área metropolitana era tan seria, que se decide dividir

la misma en tres sectores y con un hospital a la cabeza de cada uno de ellos: el

México, el San Juan y el Calderón Guardia. En la administración del entonces

presidente de la República Lic. Daniel Oduber Quirós, se da la aprobación por

parte de la Junta Directiva de la CCSS de los planos y la construcción de la Torre

Médica actual de más de 17 mil metros cuadrados.

Al concluir la obra se contaba con 522 camas, con lo cual el hospital Dr. Rafael

Angel Calderón Guardia pese a tener menos camas que los otros hospitales

nacionales y menos trabajadores, da el mayor número de consultas anuales: 558

mil, con un índice ocupacional de 88% y es el hospital de más egresos del país.

2.1.1.1. Antecedentes

La seguridad social consiste en dar bienestar para todos los asegurados y sus

familias con una calidad de vida que no se afectará por circunstancias

desfavorables. La Caja Costarricense de Seguro Social es la institución pública

encargada de la seguridad social en Costa Rica.

La CCSS coordina y ejecuta programas tanto de prevención como vacunación,

información, fumigación y de curación como cirugías, radioterapia, farmacia,

abarcando a gran parte de la población costarricense y a partir de los años 90’s a

la población inmigrante que reside en el país. Ayuda a prevenir los riesgos que

11

presenten los individuos o sus familias y su rehabilitación adaptándose de la mejor

manera posible a esta situación.

El Hospital Dr. Rafael Ángel Calderón Guardia es un hospital de tercer nivel,

clasificado así por la atención enfermedades y procedimientos quirúrgicos de alta

complejidad, que se divide en grandes áreas para la atención de los pacientes.

En la figura n.º 1, se muestra la zona de atracción directa de los pacientes por

lugar de residencia del hospital.

Figura n.o 1: Área de atracción directa del hospital Dr. R. A. Calderón Guardia.(UTIC,2004)

En la figura n.º 2, se muestra la zona de atracción indirecta de los pacientes por

lugar de residencia del hospital.

�� ÁÁrreeaa ddee aattrraacccciióónn ddiirreeccttaa::

La Unión

Vásquez de Coronado

Goicoechea Montes de Oca Curridabat

Central

Moravia

San José Área de atracción

San Juan de Dios

12

Figura n.o 2: Áreas de atracción indirecta del hospital Dr. R. A. Calderón

Guardia.(UTIC,2004)

Como parte de las Áreas Administrativas, la UTIC se desempeña como una

unidad de apoyo médico y administrativo en todo lo relacionado con las

Tecnologías de Información. La autoridad conferida en sus actuaciones con los

usuarios finales es de carácter técnico funcional; su responsabilidad es el

desarrollo y mantenimiento de los sistemas y aplicaciones con recursos técnicos

propios o con la contratación de servicios, la administración de base de datos y la

asesoría correspondiente para la adquisición de hardware y software.

La UTIC para realizar una gestión eficiente, debe establecer mecanismos de

coordinación y comunicación a nivel interno y externo como se indican en la figura

n.º 3, que garanticen la integridad y efectividad en la operación del hardware y

software.

ÁREAS DE ATRACCIÓN INDIRECTA

Concepción (Cartago) = 20 kms. Limón (provincia total) = 110 kms. Sarapiquí (Heredia) = 60 kms.

San José

4h 3h 2h 1h 30m

13

Figura n.o 3: Relaciones de Coordinación de la UTIC.(CCSS,1997)

14

2.1.1.2. Misión y visión

Cuadro n.o 1: Misión y visión (Fuente: Página web C.C.S.S, Página intranet del hospital Calderón Guardia)

Institución Misión Visión

CCSS Proporcionar los servicios de salud en forma integral al individuo, la familia y la comunidad, y otorgar la protección económica, social y de pensiones, conforme la legislación vigente, a la población costarricense.

Seremos una Institución articulada, líder en la prestación de los servicios integrales de salud, de pensiones y prestaciones sociales en respuesta a los problemas y necesidades de la población, con servicios oportunos, de calidad y en armonía con el ambiente humano.

Hospital Dr. R. A. Calderón Guardia

Ofrecer servicios de salud eficientes y humanizados para satisfacer al cliente, en armonía con los avances tecnológicos, promoviendo la investigación y educación continuas para el desarrollo del personal, a fin de mejorar la atención integral de la salud en el país.

Ser un hospital líder y exitoso en la atención integral de la salud, garantizando un servicio humanizado, oportuno y de calidad para lograr la satisfacción del cliente.

UTIC Ofrecer al Sector Salud un Sistema de Información en Salud que cumpla con las necesidades propias del Centro de Salud y sus obligaciones con el Compromiso de Gestión. La implementación de los Módulos conforme a las necesidades de cada uno de los servicios haciendo que el Sistema integre a cada uno de ellos para mejorar la atención integral de la salud en el país.

Ser un Centro de Gestión de Informática líder y exitoso en el desarrollo de un Sistema de Información en Salud, que permita a nuestro Hospital cumplir con la atención integral de la salud, garantizando un servicio humanizado, oportuno y de calidad para lograr la satisfacción del cliente.

15

2.1.1.3. Estructura organizativa

El Hospital Dr. Rafael Ángel Calderón Guardia, es uno de los tres hospitales

nacionales de alta complejidad en el manejo de los diagnósticos de enfermedad.

Como se muestra en la figura n.º 4, el hospital en su división estructural se

identifica la parte de atención médica, los servicios de apoyo al diagnóstico médico

y los servicios administrativos, incluyendo la UTIC el cual es el servicio base para

el desarrollo del Proyecto Final de Graduación.

16

Figura n.o 4: Área Estructura organizacional hospital Dr. R. A. Calderón Guardia.(CCSS,1997)

Estructura OrganizativaHospital Dr. Rafael Angel Calderón Guardia

Junta de Salud Hospitalaria.

Consejo Técnico Comité local Emergencias y Desastres

Comité local de Infecciones Intrahospitalarias Comité Local. Colera

Comité Académico Local Comisión General

Asesoría Legal Sub. Dirección

Contraloría de Servicios Biblioteca Médica

Secretarias Registros Médicos y Estadistica

Ingeniería y Mantenimiento Oficina de Recursos Humanos

Transportes Verf. Derech. Centr. telInform, y Sonido

Bienes Muebles Presupuesto y Costos

Compras Directas y Caja Chica Servicios de Vigilancia

Proveduría Servico de Limpieza

Despensa de Viveres Centro de Gestiónde Informática

Servicios Religiosos

Administración del Hospital

Servicios Administrativos y de Apoyo Administrativo

Sección Médica

Consulta Especializada OdontologíaGeneral y Específica

Consulta Emergencias

Neonatología Perinatología

Sección Gineco-Obstetricia. Sección Cirugía

Servicios Clínicos Quirúrgicos

Farmacia Radiología

Enfermería Medicina Nuclear

Anatomía Patológica Trabajo Social

Nutrición Laboratorio Clínico

Laboratorio de Hormonas Laboratorio de Hematología

Servicio de Apoyo Clínico

Dirección del Hospital. Universidades Públicas y Privadas

Gerencia de División Médica

17

2.1.1.4 Estructura programática

Figura n.o 5: Área Estructura programática UTIC.(CCSS,1997)

18

La estructura programática es un instrumento que permite visualizar los procesos

operativos de las Unidades de Tecnologías de Información y Comunicaciones,

mediante la descripción de los programas, los subprogramas y las actividades a

ejecutar. En la estructura programática se establecen cuatro programas

sustantivos: la formulación de proyectos, el desarrollo de sistemas, el soporte

técnico y la asistencia a usuarios.

Aunque en la figura nº 5 se describe el área de formulación de proyectos y las

actividades que se tienen que efectuar, en la realidad esto no se está aplicando

para la UTIC del Hospital. En la estructura si bien es cierto se muestran

actividades que cumplir para la formulación de proyectos, no existe una

metodología que ayude en la administración de los proyectos. Nunca ha existido

un marco de referencia que contemple todos estos aspectos, por el contrario con

el presente trabajo se quiere fomentar el uso de esta estructura programática, con

los cambios necesarios para poder hacer frente a las nuevas tendencias de

programación y a la forma de proceder al trabajo con proyectos.

De igual manera existe un área de desarrollo de sistemas, con sus respectivas

actividades, pero no es la realidad de la UTIC, estas funciones no están

debidamente coordinadas con el personal de la UTIC y no hay una metodología de

desarrollo de software que contribuya en las labores de los analistas

programadores.

2.2. Teoría de Administración de Proyectos

2.2.1. Proyecto

El concepto de proyecto está relacionado de acuerdo con el ámbito de desarrollo y

la perspectiva que adopte la persona que realiza un determinado trabajo.

19

Una definición de proyecto es: "Un proyecto no es ni más ni menos que la

búsqueda de una solución inteligente al planteamiento de un problema tendiente a

resolver, entre tantas, una necesidad humana. Cualquiera sea la idea que se

pretende implementar, cualquiera la inversión, cualquiera la metodología o la

tecnología por aplicar, ella conlleva necesariamente la búsqueda de proposiciones

coherentes destinadas a resolver las necesidades de la persona humana en todos

sus alcances: alimentación, salud, educación, vivienda, religión, defensa, cultura,

recreación, etcétera”. (Sapag & Sapag,1989, p4)

Otra definición de proyecto es “Un proyecto es un esfuerzo temporal que se lleva a

cabo para crear un producto, servicio o resultado único. La naturaleza temporal de

los proyectos indica un principio y un final definidos”. (PMI, 2008, p 11)

Los proyectos están orientados hacia objetivos claros y accesibles, que se

ejecutan de forma coordinada con un conjunto de actividades y tareas

interrelacionadas. Todas las actividades tienen un principio y un fin y por lo

general no son repetitivas. Como requisito importante todo proyecto necesita el

compromiso y la participación de sus integrantes.

El realizar un proyecto posibilita el saber qué hacer y el rumbo que se debe tomar,

trazando un mapa que reduce la imprevisión, el riesgo de los inversionistas e

identifica la viabilidad para realizar el proyecto.

Por todo lo expuesto anteriormente, se tiene presente utilizar la Administración de

Proyectos para alcanzar los objetivos planteados en este proyecto de final de

graduación.

20

2.2.2. Administración de Proyectos

Según la siguiente definición de la Administración de proyectos es “la aplicación

de conocimientos, habilidades, herramientas y técnicas a las actividades del

proyecto para cumplir con los requisitos del mismo.” (PMI, 2008, p 12)

Esto se basa en una planeación, organización, dirección y control de los recursos,

para dar un marcado énfasis y una atención especial para conducir las actividades

no repetitivas con el propósito de lograr un objetivo a corto plazo.

La Administración de Proyectos ofrece nuevas alternativas a las organizaciones

que se enfrentan a constantes cambios tecnológicos, en la introducción de nuevos

productos al mercado y a las cambiantes exigencias de los consumidores

haciendo que los métodos administrativos convencionales sean inadecuados.

Procura siempre el aprovechamiento al máximo de los recursos, mediante una

utilización eficiente.

Todo proceso debe estar alineado y conectado de una manera adecuada con los

demás procesos y esto es parte de la tarea integradora de la administración de

Proyectos.

2.2.3. Áreas del Conocimiento de la Administración de Proyectos

A continuación se detallan las nueve áreas del conocimiento de la Administración

de Proyectos mencionados en el PMBOK:

1. La gestión de la integración tiene como objetivo asegurar que las diferentes

partes del proyecto están correctamente coordinadas. Esto incluye el

desarrollo del plan del proyecto, el plan de ejecución y el control de los

cambios que puedan producirse.

21

2. La gestión del alcance se ocupa de que el proyecto lleve a cabo todo el

trabajo necesario —y solamente el trabajo necesario—, para cumplir los

objetivos marcados al inicio. Para ello se debe definir y planear el alcance

del proyecto, para después verificar que se está cumpliendo y

eventualmente cambiarlo.

3. La gestión del tiempo tiene como objetivo asegurar que el proyecto se lleve

a cabo en los plazos previstos. Para ello hay que definir la secuencia de

actividades a realizar, así como su duración y coordinación.

4. La gestión del coste tiene como objetivo que el proyecto se complete con el

presupuesto inicialmente aprobado. Esto lleva consigo la planificación de

los recursos necesarios, la estimación del coste de esto y el control de los

costes.

5. La gestión de la calidad tiene como objetivo que el proyecto satisfaga las

necesidades para las que fue inicialmente diseñado. Para ello se debe

planear, asegurar y controlar la calidad del proyecto en todo momento,

respecto a esas necesidades.

6. La gestión de recursos humanos tiene como objetivo la utilización más

eficiente posible de las personas que participan en el proyecto, y entre sus

actividades están el plan organizacional, la contratación de nuevos

empleados y el desarrollo de los equipos.

7. La gestión de la comunicación tiene como objetivo asegurar la correcta

generación, colección, diseminación, almacenamiento y eliminación de la

información del proyecto, en unos plazos determinado.

8. La gestión de riesgos tiene como objetivos identificar, analizar y dar

respuesta a los riesgos que amenacen la marcha del proyecto. Estos

riesgos tienen que estar correctamente identificados y cuantificados, así

como los mecanismos de respuesta pertinentes.

9. La gestión de suministros se encarga de adquirir los bienes y servicios

externos a la organización que lleva a cabo el proyecto. Esto incluye la

22

correcta planificación de pedidos y proveedores y la gestión de los

contratos.

2.2.4. Ciclo de vida de un proyecto

Se define el ciclo de vida como “un conjunto de fases del mismo, generalmente

secuenciales y en ocasiones superpuestas, cuyo nombre y número se determinan

por las necesidades de gestión y control de la organización u organizaciones que

participan en el proyecto, la naturaleza propia del proyecto y su área de

aplicación.” (PMI, 2008, p 22).

La estructuración en fases proporciona una forma básica para el control, dirección

y planeación, al dividir el proyecto en subconjuntos lógicos. Una fase se concluye

y cierra con una revisión de los entregables, los cuales brindan respuesta a los

objetivos planteados en el proyecto.

2.2.5. Procesos en la Administración de Proyectos

Se define proceso como “Un proceso es un conjunto de acciones y actividades

interrelacionadas realizadas para obtener un producto, resultado o servicio

predefinido. Cada proceso se caracteriza por sus entradas, por las herramientas y

técnicas que pueden aplicarse y por las salida que se obtienen.” (PMI, 2008, p 40)

Los procesos del proyecto son ejecutados por el equipo de proyecto y se dividen

en dos categorías:

• Los procesos de dirección de proyectos, se asegura que el proyecto avance

durante toda su existencia.

23

• Los procesos orientados al producto, especifican y crean el producto, ya

antes identificado en el ciclo de vida del proyecto.

Los grupos de procesos de la Administración de Proyectos se agrupan en cinco

áreas que se describen a continuación:

2.2.5.1. Procesos de Iniciación

El proceso de iniciación se define como “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.” (PMI, 2008, p

41)

Dentro de las actividades del proceso de iniciación se identifican los alcances del

proyecto, se destinan los recursos financieros iniciales, se reconocen los

interesados internos y externos; se conjunta todo lo anterior en el charter del

proyecto o acta de constitución del proyecto. Cuando se da la aprobación del

charter del proyecto se considera que el proyecto está oficialmente aprobado.

2.2.5.2. Procesos de Planificación

El proceso de Planificación se define como “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.”

(PMI, 2008, p 41)

En este grupo de procesos se define y planifica cada una de las dimensiones del

proyecto. El producto es un plan que está sujeto a la incorporación progresiva de

detalles según se va ejecutando y dando seguimiento. Estas incorporaciones

progresivas van a venir en las medidas preventivas y correctivas que se tomen a

lo largo del proyecto como los cambios en el alcance. En el plan debe estipularse

24

cuál va a ser el proceso para el manejo de cambio. El proceso junto con la

métricas debe ser observado con constancia para evitar que el proyecto caiga en

el punto de no retorno donde se pierda el control del proyecto.

2.2.5.3. Proceso de Ejecución

El proceso de ejecución se define como “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.” (PMI 2008, p 42)

El propósito de este grupo de procesos es completar el trabajo definido en el plan

de proyecto. La coordinación de los recursos y la comunicación a la gente la cual

espera información sobre el producto que se está generando, el cual en muchas

ocasiones es diferente a lo que la gente está esperando.

2.2.5.4. Proceso de Seguimiento y Control

El proceso de seguimiento y control se define como “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.” (PMI, 2008, p 42)

Se mide el desempeño del proyecto de una manera sistemática y regular, con el

fin de identificar cambios que se den en el plan de dirección de proyectos.

2.2.5.5. Proceso de Cierre

El proceso de cierre se define como “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.” (PMI, 2008, p 42)

Se verifica que todos los entregables fueron completados, inspeccionados y

aceptados y listos para la aceptación final del proyecto por el patrocinador.

25

2.3. Áreas del Conocimiento relacionadas con el PFG

A continuación se detallan las áreas del conocimiento que se utilizarán para la

realización de la metodología propuesta en el PFG.

2.3.1. Gestión de Integración

Incluye los procesos y actividades necesarios para identificar, definir, combinar,

unificar, y coordinar los diversos procesos y actividades de la dirección de

proyectos. Mostrando los procesos de la gestión de integración a continuación en

el cuadro n.º 2.

Cuadro n.o 2: Procesos y descripción Gestión de Integración

Proceso Descripción

Desarrollar el Acta de Constitución del Proyecto

Es el proceso que consiste en desarrollar un documento que autoriza formalmente un proyecto o una fase y documentar los requisitos iniciales que satisfacen las necesidades y expectativas de los interesados.

Desarrollar el Plan para la Dirección del Proyecto

Es el proceso que consiste en documentar las acciones necesarias para definir, preparar, integrar y coordinar todos los planes subsidiarios.

Dirigir y Gestionar la Ejecución del Proyecto

Es el proceso que consiste en ejecutar el trabajo definido en el plan para la dirección del proyecto para cumplir con los objetivos del mismo.

Monitorear y Controlar el Trabajo del Proyecto

Es el proceso que consiste en monitorear, revisar y regular el avance a fin de cumplir con los objetivos de desempeño definidos en el plan para la dirección del proyecto.

Realizar el Control Integrado de Cambios

Es el proceso que consiste en revisar todas las solicitudes de cambio, y en aprobar y gestionar los cambios en los entregables, en los activos de los procesos de la organización, en los documentos del proyecto y en el plan para la dirección del proyecto.

26


Cerrar Proyecto o Fase

Es el proceso que consiste en finalizar todas las actividades en todos los grupos de procesos de dirección de proyectos para completar formalmente el proyecto o una fase del mismo.

2.3.2. Gestión de Alcance

La gestión del alcance incluye todo y únicamente todo lo necesario que requiere el

trabajo para completarlo con éxito. Mostrando los procesos de la gestión de

alcance a continuación en el cuadro n.º 3.

Cuadro n.o 3: Procesos y descripción Gestión de Alcance


Recopilar requisitos

Es el proceso que consiste en definir y documentar las necesidades de los interesados a fin de cumplir con los objetivos del proyecto.

Definir el alcance Es el proceso que consiste en desarrollar una descripción detallada del proyecto y del producto.

Crear la EDT

Es el proceso que consiste en subdividir los entregables y el trabajo del proyecto en componentes más pequeños y más fáciles de manejar.

Verificar el alcance Es el proceso que consiste en formalizar la aceptación de los entregables del proyecto que se han completado.

Controlar el alcance

Es el proceso que consiste en monitorear el estado del alcance del proyecto y del producto, y en gestionar cambios a la línea base del alcance.

27

2.3.3. Gestión del Tiempo

Son los procesos requeridos para administrar la finalización del proyecto a tiempo.

Mostrando los procesos de la gestión de integración a continuación en el cuadro

n.º 4.

Cuadro n.º 4: Procesos y descripción Gestión del Tiempo


Definir las actividades Es el proceso que consiste en identificar las acciones específicas a ser realizadas para elaborar los entregables del proyecto.

Secuenciar las actividades Es el proceso que consiste en identificar y documentar las interrelaciones entre las actividades del proyecto.

Estimar los recursos de las actividades

Es el proceso que consiste en estimar el tipo y las cantidades de materiales, personas, equipos o suministros requeridos para ejecutar cada actividad.

Estimar la duración de las actividades

Es el proceso que consiste en establecer aproximadamente la cantidad de períodos de trabajo necesarios para finalizar cada actividad con los recursos estimados.

Desarrollar el cronograma

Es el proceso que consiste en analizar la secuencia de las actividades, su duración, los requisitos de recursos y las restricciones del cronograma para crear el cronograma del proyecto.

Controlar el cronograma

Es el proceso por el que se da seguimiento al estado del proyecto para actualizar el avance del mismo y gestionar cambios a la línea base del cronograma.

2.3.4. Gestión de Calidad

La Gestión de Calidad de un proyecto está formada por tres procesos que se

encargan de definir todas las actividades para determinar las políticas, los

28

objetivos y las responsabilidades relativos a la calidad, de modo que el proyecto

satisfaga las necesidades por las cuales se realizará.

Los tres procesos que abarca la Gestión de Calidad se detallan a continuación en

el cuadro n.º 5.

Cuadro n.o 5: Procesos y Descripción Gestión de Calidad


Planificar la calidad Es el proceso por el cual se identifican los requisitos de calidad y/o normas para el proyecto y el producto, documentando la manera en que el proyecto demostrará el cumplimiento con los mismos.

Realizar el Aseguramiento de Calidad

Es el proceso que consiste en auditar los requisitos de calidad y los resultados de las medidas de control de calidad, para asegurar que se utilicen las normas de calidad apropiadas y las definiciones operacionales.

Realizar el control de calidad Es el proceso por el que se monitorean y registran los resultados de la ejecución de actividades de control de calidad, a fin de evaluar el desempeño y recomendar cambios necesarios.

2.3.5. Gestión de Recursos Humanos

La Gestión de los Recursos Humanos del proyecto incluye los procesos que

organizan y dirigen el equipo del proyecto. Si bien es común hablar de asignación

de roles y responsabilidades, los miembros del equipo deberían participar en gran

parte de la planificación y toma de decisiones del proyecto. La participación

temprana de los miembros del equipo aporta experiencia durante el proceso de

planificación y fortalece el compromiso con el proyecto. Mostrados a continuación

en el cuadro n.º 6.

29

Cuadro n.o 6: Procesos y Descripción Gestión de Recursos Humanos


Desarrollar el Plan de Recursos Humanos

Es el proceso por el cual se identifican y documentan los roles dentro de un proyecto, las responsabilidades, las habilidades requeridas y las relaciones de comunicación, y se crea el plan para la dirección de personal.

Adquirir el equipo del proyecto Es el proceso por el cual se confirman los recursos humanos disponibles y se forma el equipo necesario para completar las asignaciones del proyecto.

Desarrollar el equipo del proyecto

Es el proceso que consiste en mejorar las competencias, la interacción de los miembros del equipo y el ambiente general del equipo para lograr un mejor desempeño del proyecto.

Dirigir el equipo del proyecto Es el proceso que consiste en dar seguimiento al desempeño de los miembros del equipo, proporcionar retroalimentación, resolver problemas y gestionar cambios a fin de optimizar el desempeño del proyecto.

2.3.6. Gestión de Comunicaciones

La Gestión de Comunicaciones permite asegurar la generación, recogida,

distribución, almacenamiento, recuperación y destino final de la información del

proyecto en tiempo y forma. Los procesos de la Gestión de Comunicaciones se

muestran a continuación en el cuadro n.º 7.

Cuadro n.º 7: Procesos y Descripción Gestión de Comunicaciones


Identificar a los Interesados Es el proceso que consiste en identificar a todas las personas u organizaciones impactadas por el proyecto, y documentar información relevante relativa a sus intereses, participación e impacto en el éxito del mismo.

30


Planificar las Comunicaciones Es el proceso para determinar las necesidades de información a los interesados en el proyecto y definir cómo abordar las comunicaciones con ellos en el proyecto.

Distribuir la Información Es el proceso de poner la información relevante a disposición de los interesados en el proyecto, de acuerdo con el plan establecido.

Gestionar las Expectativas de los Interesados

Es el proceso de comunicarse y trabajar en conjunto con los interesados para satisfacer sus necesidades y abordar los problemas conforme se presentan

Informar el Desempeño Es el proceso de recopilación y distribución de la información sobre el desempeño, incluyendo los informes de estado, las mediciones del avance y las proyecciones.

2.3.7. Gestión de Riesgo

La Gestión de los Riesgos del Proyecto incluye los procesos relacionados con la

planificación de la gestión de riesgos, la identificación y el análisis de los mismos,

las respuestas a los riesgos, y su seguimiento y control.

Todo ello se realiza para conseguir aumentar la probabilidad y el impacto de los

eventos positivos y disminuir, obviamente, la de los eventos adversos para el

proyecto. Los procesos de la gestión de riesgo se muestran a continuación en el

cuadro n.º 8.

Cuadro n.º 8: Procesos y Descripción Gestión de Riesgos


Planificar la Gestión de Riesgos Es el proceso por el cual se define cómo realizar las actividades de gestión de los riesgos para un proyecto.

Identificar los riesgos Es el proceso por el cual se determinan los

31


riesgos que pueden afectar el proyecto y se documentan sus características.

Realizar el Análisis Cualitativo de Riesgos.

Es el proceso que consiste en priorizar los riesgos para realizar otros análisis o acciones posteriores, evaluando y combinando la probabilidad de ocurrencia y el impacto de dichos riesgos.

Realizar el Análisis Cuantitativo de Riesgos.

Es el proceso que consiste en analizar numéricamente el efecto de los riesgos identificados sobre los objetivos generales del proyecto.

Planificar la Respuesta a los Riesgos

Es el proceso por el cual se implementan planes de respuesta a los riesgos.

2.4. Rational Unified Process (RUP)

2.4.1. Historia

Sus comienzos datan del año de 1967 con la Metodología Ericsson (Ericsson

Approach) elaborada por Ivar Jacobson introdujo el concepto de Caso de Uso.

Entre los años de 1987 a 1995 Jacobson fundó la compañía Objectory AB y lanza

el proceso de desarrollo Objectory (abreviación de Object Factory).

Posteriormente en 1995 Rational Software Corporation adquiere Objectory AB.

Entre 1995 y 1997 se desarrolla Rational Objectory Process (ROP), surge del

Enfoque Rational (Rational Approach) con UML como lenguaje de modelado.

En junio de 1998, Rational Software a la cabeza de Grady Booch, Ivar Jacobson y

James Rumbaugh, desarrollan e incorporan diversos elementos para expandir

ROP, destacándose especialmente el flujo de trabajo conocido como modelado

del negocio. Tomando forma el modelo de Rational Unified Process.

La figura n.º 6 ilustra la historia del modelo Rational Unified Process (en adelante

RUP)

Figura

2.4.2. Características esenciales

El proceso de software propuesto por RUP tiene tres características

está dirigido por los Casos de Uso, está centrado en la arquitectura, y es iterativo

e incremental.

2.4.2.1. Proceso dirigido por Casos de Uso

Kruchten(2000) define un Caso de Uso “como un fragmento de funcionalidad del

sistema que proporcion

Se utiliza una técnica de captura de requisitos que fuerza a pensar en términos de

importancia para el usuario y no sólo e

contemplar.

Es una herramienta para especificar los

diseño, lo implementan y prueban. Los Casos de Uso constituyen un elemento

integrador y una guía del

Figura n.o 6: Historia de RUP. (P. Letelier,2003)

Características esenciales

El proceso de software propuesto por RUP tiene tres características


Proceso dirigido por Casos de Uso

define un Caso de Uso “como un fragmento de funcionalidad del

sistema que proporciona al usuario un valor añadido.”(pp. 42-50)


importancia para el usuario y no sólo en términos de funciones que serí

Es una herramienta para especificar los requisitos del sistema que guían su


integrador y una guía del trabajo como se muestra en la figura

32

. (P. Letelier,2003)

El proceso de software propuesto por RUP tiene tres características esenciales:


define un Caso de Uso “como un fragmento de funcionalidad del

50)


n términos de funciones que sería bueno

requisitos del sistema que guían su


n.º 7.

Figura n.o 7: Los Casos de Uso integran el trab

Basándose en los Casos de Uso se crean los modelos de análisis y diseño, luego

la implementación que los lleva a cabo, y se verifica que efectivamente el producto

implemente adecuadamente cada Caso de Uso. Todos los modelos deben e

sincronizados con el modelo de Casos de Uso.

2.4.2.2. Proceso centrado en la arquitectura

Kruchten(1995), define e

arquitectura de un sistema es la organización o estructura de sus partes más

relevantes, lo que permite tener una visión

(desarrolladores y usuarios) y una perspectiva clara del sistema completo,

necesaria para control

La arquitectura involucra los aspectos estáticos y dinámicos más significativos del

sistema, está relacionada con la toma de decisiones que indican cómo tiene que

ser construido el sistema y ayuda a determinar en qué orden.

permite que el constructor tenga una imagen completa no detallada, antes de

iniciar la construcción. Debe considerar a los elementos de calidad del sistema,

rendimiento, reutilización y capacidad de evolución por lo que debe ser flexible

: Los Casos de Uso integran el trabajo. (P. Letelier,2003)



implemente adecuadamente cada Caso de Uso. Todos los modelos deben e

sincronizados con el modelo de Casos de Uso.

Proceso centrado en la arquitectura

), define el proceso centrado en la arquitectura como


relevantes, lo que permite tener una visión común entre todos los involucrados


necesaria para controlar el desarrollo.” (pp. 42-50)



ser construido el sistema y ayuda a determinar en qué orden.




33

. (P. Letelier,2003)



implemente adecuadamente cada Caso de Uso. Todos los modelos deben estar

l proceso centrado en la arquitectura como “La


común entre todos los involucrados




ser construido el sistema y ayuda a determinar en qué orden. La arquitectura




34

durante todo el proceso de desarrollo y pretender no verse muy impactada ante

cambios posteriores durante la construcción y el mantenimiento.

Los Casos de Uso deben encajar en la arquitectura cuando se llevan a cabo y la

arquitectura debe permitir el desarrollo de todos los Casos de Uso requeridos,

actualmente y en el futuro. Esto provoca que tanto arquitectura como Casos de

Uso deban evolucionar en paralelo durante todo el proceso de desarrollo de

software.

En la figura n.º 8 se muestra la evolución de la arquitectura durante las fases de

RUP. En las fases iniciales se consolidan la arquitectura por medio de líneas base

y se realizan modificaciones dependiendo de las necesidades del proyecto. En las

fases finales la arquitectura es más robusta que en las fases iniciales del proyecto.

.º

Figura n.o 8: Evolución de la arquitectura del sistema. (P. Letelier,2003)

2.4.2.3. Proceso iterativo e incremental

Jacaboson, Booch y Rumbaugh (2000) señalan que “el equilibrio correcto entre los

Casos de Uso y la arquitectura es algo muy parecido al equilibrio de la forma y la

Architecture

Inception Elaboration Construction Transition

tiempo

ArchitectureArchitecture

Inception Elaboration Construction Transition

tiempo

Inicio Elaboración Construcción Transición

Arquitectura

35

función en el desarrollo del producto, lo cual se consigue con el tiempo.” (p. 7). La

RUP propone tener un proceso iterativo e incremental en donde el trabajo se

divide en partes más pequeñas o mini proyectos. Con lo cual se da un el equilibrio

entre Casos de Uso y arquitectura durante cada mini proyecto, así también

durante todo el proceso de desarrollo.

Una iteración puede realizarse por medio de una cascada y en la cual pasa por los

flujos fundamentales de requisitos, análisis, diseño, implementación y pruebas,

también existe una planificación de la iteración, un análisis de la iteración y

algunas actividades específicas de la iteración. Al finalizar se realiza una

integración de los resultados con lo obtenido de las iteraciones anteriores, como

se muestra en la figura nº 9.

Figura n.o 9: Una iteración RUP. (P. Letelier, 2003)

2.4.3. Otras prácticas

RUP identifica 6 mejores práctica con las que define una forma efectiva de trabajar

para los equipos de desarrollo de software.

36

2.4.3.1. Gestión de requisitos

RUP brinda una guía para encontrar, organizar, documentar, y seguir los cambios

de los requisitos funcionales y restricciones. Utiliza una notación de Caso de Uso y

escenarios para representar los requisitos.

2.4.3.2. Desarrollo de software iterativo

Desarrollo del producto mediante iteraciones con hitos bien definidos, en las

cuales se repiten las actividades pero con distinto énfasis, según la fase del

proyecto.

2.4.3.3. Desarrollo basado en componentes

La creación de sistemas intensivos en software requiere dividir el sistema en

componentes con interfaces bien definidas, que posteriormente serán

ensamblados para generar el sistema. Esta característica en un proceso de

desarrollo permite que el sistema se vaya creando a medida que se obtienen o se

desarrollan sus componentes.

2.4.3.4. Modelado visual

Lenguaje Unificado de Modelado (en adelante UML), es un lenguaje para

visualizar, especificar, construir y documentar los artefactos de un sistema

software. Utilizar herramientas de modelado visual facilita la gestión de dichos

modelos, permitiendo ocultar o exponer detalles cuando sea necesario. UML

ofrece un estándar para describir un “plano” del sistema (modelo), incluyendo

aspectos conceptuales tales como procesos de negocio y funciones del sistema.

El modelado visual también ayuda a mantener la consistencia entre los artefactos

del sistema: requisitos, diseños e implementaciones.

2.4.3.5. Verificación continua de la calidad

Verificar la calidad de todos los artefactos en varios puntos durante el proceso de

desarrollo, especialmente al final de cada iteración. En esta verificación las

pruebas juegan un papel fundamental y se integran a lo largo de todo el proceso.

37

2.4.3.6. Gestión de los cambios

El cambio es un factor de riesgo crítico en los proyectos de software. Los

artefactos software cambian no sólo debido a acciones de mantenimiento

posteriores a la entrega del producto, sino que durante el proceso de desarrollo,

especialmente importantes por su posible impacto son los cambios en los

requisitos.

2.4.4. Ejes de la RUP

2.4.4.1. Eje horizontal - Estructura Dinámica del proceso. Fases e iteraciones

Representa el tiempo y es considerado el eje de los aspectos dinámicos del

proceso. Indica las características del ciclo de vida del proceso expresado en

términos de fases, iteraciones e hitos. Se puede observar en la figura n.º 10, que

RUP consta de cuatro fases: Inicio, Elaboración, Construcción y Transición. Como

se mencionó anteriormente cada fase se subdivide a la vez en iteraciones.

Figura n.o 10: Eje Horizontal. (P. Letelier, 2003)

38

RUP se repite a lo largo de una serie de ciclos que constituyen la vida de un

producto. Cada ciclo concluye con una generación del producto para los clientes.

Cada ciclo consta de cuatro fases: Inicio, Elaboración, Construcción y Transición.

Cada fase se subdivide a la vez en iteraciones, el número de iteraciones en cada

fase es variable. Las fases se concluye con un hito bien definido, un punto en el

tiempo en el cual se deben tomar ciertas decisiones críticas y alcanzar las metas

clave antes de pasar a la siguiente fase, Las fases y sus respectivos hitos se

ilustran en la figura n.º 11.

Figura n.o 11: Fases e hitos en RUP. (P. Letelier, 2003) 2.4.4.1.1. Inicio

Durante la fase de inicio se define el modelo del negocio y el alcance del proyecto.

Se identifican todos los actores y Casos de Uso, y se diseñan los Casos de Uso

más esenciales (aproximadamente el 20% del modelo completo). Se desarrolla, un

plan de negocio para determinar qué recursos deben ser asignados al proyecto.

2.4.4.1.2. Elaboración

El propósito de la fase de elaboración es analizar el dominio del problema,

establecer los cimientos de la arquitectura, desarrollar el plan del proyecto y

eliminar los mayores riesgos.

39

En esta fase se construye un prototipo de la arquitectura, que debe evolucionar en

iteraciones sucesivas hasta convertirse en el sistema final. Este prototipo debe

contener los Casos de Uso críticos identificados en la fase de inicio. También debe

demostrarse que se han evitado los riesgos más graves.

2.4.4.1.3. Construcción

La finalidad principal de esta fase es alcanzar la capacidad operacional del

producto de forma incremental a través de las sucesivas iteraciones. Durante esta

fase todos los componentes, características y requisitos deben ser

implementados, integrados y probados en su totalidad, obteniendo una versión

aceptable del producto.

2.4.4.1.4. Transición

La finalidad de la fase de transición es poner el producto en manos de los usuarios

finales, para lo que se requiere desarrollar nuevas versiones actualizadas del

producto, completar la documentación, entrenar al usuario en el manejo del

producto, y en general tareas relacionadas con el ajuste, configuración, instalación

y facilidad de uso del producto.

2.4.4.2. Eje vertical - Estructura estática del pr oceso.

Representa los aspectos estáticos del proceso. Describe el proceso en términos

de componentes de proceso, disciplinas, flujos de trabajo, actividades, artefactos y

roles. Como se muestra en la figura n.º 12

Figura

En la figura n.º 13 se muestra el

quién hace qué, cómo y cuándo. RUP define cuatro elementos los roles, que

responden a la pregunta ¿Quién?, las actividades que responden a la pregunta

¿Cómo?, los productos, que responden a la pregunta ¿Qué? y los flujos de trabajo

de las disciplinas que responde a la pregunta ¿Cuándo

Figura n.o 12: Eje vertical. (P. Letelier, 2003)

se muestra el proceso como el desarrollo de software define


a la pregunta ¿Quién?, las actividades que responden a la pregunta


de las disciplinas que responde a la pregunta ¿Cuándo?.

40

. (P. Letelier, 2003)

esarrollo de software define


a la pregunta ¿Quién?, las actividades que responden a la pregunta


41

Figura n.o 13: Relación entre roles, actividades, artefactos. (P. Letelier, 2003)

2.4.4.2.1. Roles

Un rol define el comportamiento y responsabilidades de un individuo, o de un

grupo de individuos trabajando juntos como un equipo. Una persona puede

desempeñar diversos roles, así como un mismo rol puede ser representado por

varias personas.

2.4.4.2.2. Actividades

Una actividad en concreto es una unidad de trabajo que una persona que

desempeñe un rol puede ser solicitado a que realice. Las actividades tienen un

objetivo concreto, normalmente expresado en términos de crear o actualizar algún

producto.

2.4.4.2.3. Artefactos

Un producto o artefacto es un trozo de información que es producido, modificado o

usado durante el proceso de desarrollo de software. Los productos son los

resultados tangibles del proyecto, las cosas que va creando y usando hasta

obtener el producto final.

42

2.4.4.2.4. Flujos de trabajo

Con la enumeración de roles, actividades y artefactos no se define un proceso,

necesitamos contar con una secuencia de actividades realizadas por los diferentes

roles, así como la relación entre los mismos. Un flujo de trabajo es una relación de

actividades que nos producen unos resultados observables. A continuación se

dará una explicación de cada flujo de trabajo.

2.4.4.2.5. Modelado del negocio

Con este flujo de trabajo pretendemos llegar a un mejor entendimiento de la

organización donde se va a implantar el producto.

Para lograr estos objetivos, el modelo de negocio describe como desarrollar una

visión de la nueva organización, basado en esta visión se definen procesos, roles

y responsabilidades de la organización por medio de un modelo de Casos de Uso

del negocio y un Modelo de Objetos del Negocio. Complementario a estos

modelos, se desarrollan otras especificaciones tales como un Glosario.

2.4.4.2.6. Requisitos

Es uno de los flujos de trabajo más importante, donde se establece que tiene que

hacer exactamente el sistema que se desarrolla. En esta línea los requisitos son el

contrato que se debe cumplir, de modo que los usuarios finales tienen que

comprender y aceptar los requisitos que especifiquemos.

Los requisitos se dividen en dos grupos. Los requisitos funcionales representan la

funcionalidad del sistema. Se modelan mediante diagramas de Casos de Uso. Los

requisitos no funcionales representan aquellos atributos que debe exhibir el

sistema, pero que no son una funcionalidad específica. Por ejemplo requisitos de

facilidad de uso, fiabilidad, eficiencia, portabilidad, etc.

43

2.4.4.2.7. Análisis y Diseño

El objetivo de este flujo de trabajo es traducir los requisitos a una especificación

que describe cómo implementar el sistema en donde el análisis consiste en

obtener una visión del sistema que se preocupa de ver qué hace, de modo que

sólo se interesa por los requisitos funcionales y el diseño es un refinamiento del

análisis que tiene en cuenta los requisitos no funcionales, en definitiva cómo

cumple el sistema sus objetivos.

2.4.4.2.8. Implementación

En este flujo de trabajo se implementan las clases y objetos en código fuente,

binarios, ejecutables y demás. El resultado final de este flujo de trabajo es un

sistema ejecutable.

2.4.4.2.9. Pruebas

Se evalúa la calidad del producto que está en desarrollo. Las actividades de este

flujo comienzan pronto en el proyecto con el plan de prueba, o incluso antes con

alguna evaluación durante la fase de inicio, y continuará durante todo el proyecto.

El desarrollo del flujo de trabajo consistirá en planificar que es lo que hay que

probar, diseñar cómo se va a hacer, implementar lo necesario para llevarlos a

cabo, ejecutarlos en los niveles necesarios y obtener los resultados, de forma que

la información obtenida nos sirva para ir refinando el producto a desarrollar.

2.4.4.2.10. Despliegue

El objetivo de este flujo de trabajo es producir con éxito distribuciones del producto

y distribuirlo a los usuarios. Se desarrolla con mayor intensidad en la fase de

transición, y asegura una aceptación y adaptación sin complicaciones del software

por parte de los usuarios. Su ejecución inicia en fases anteriores, para preparar el

44

camino, sobre todo con actividades de planificación, en la elaboración del manual

de usuario y tutoriales.

2.4.4.2.11. Gestión del proyecto

La Gestión del proyecto es el arte de lograr un balance al gestionar objetivos,

riesgos y restricciones para desarrollar un producto que sea acorde a los

requisitos de los clientes y los usuarios.

2.4.4.2.12. Configuración y control de cambios

La finalidad de este flujo de trabajo es mantener la integridad de todos los

artefactos que se crean en el proceso, así como de mantener información del

proceso evolutivo que han seguido.

2.4.4.2.13. Entorno

La finalidad de este flujo de trabajo es dar soporte al proyecto con las adecuadas

herramientas, procesos y métodos. Brinda una especificación de las herramientas

que se van a necesitar en cada momento, así como definir la instancia concreta

del proceso que se va a seguir.

2.5. PMBOK y RUP

El PMBOK es definido como el conjunto de conocimientos que se utilizan para

administrar cualquier tipo de proyecto y la RUP es definida como el conjunto de

conocimientos para el desarrollo solo de proyectos de software y que se adapta al

contexto y necesidades de cada organización. Con lo cual las hacen metodologías

diferentes e independientes.

El PMBOK entra en las áreas que la RUP no tiene, tales como la gestión de

recursos humanos, gestión de comunicación y gestión de costos. Tal y como se

45

explica en el reporte CHAOS realizado por The Standish Group de 1994, en donde

se estudió a grandes, medianas y pequeñas empresas de las cuales se consultan

a 365 gerentes de Tecnologías de Información (en adelante TI) con una muestra

de 8380 aplicaciones en Estados Unidos. En las cuales no utilizaban ni la

metodología RUP, ni las mejores prácticas del PMBOK, y se obtienen los

siguientes resultados, solo el 16,2% de los proyectos de desarrollo de software

tienen éxito. El 31.1% de los proyectos de TI son cancelados antes de terminar y

el 52.7% del costo de los proyectos se vieron sobrepasados en su costo original.

En un segundo reporte del año 2004, The Standish Group analiza 40.000

proyectos a esa fecha, dando como resultado un incremento en los proyectos

exitosos de 34%. El porcentaje de proyectos que fueron cancelados bajó a un

15%. Y los proyectos que sobrepasaron su costo bajó en un 43%. El porqué de

este buen rendimiento en el desarrollo de proyectos de software en 10 años, se

debe a la utilización e integración de la metodología RUP y el PMBOK. Éstos

ayudaron en la mejora de los proyectos de desarrollo de software a un 100%

debido al proceso iterativo manejado por la RUP y al manejo de proyectos

profesional desarrollado por el PMBOK.

El cuadro siguiente muestra las debilidades y fortalezas del PMBOK y la RUP,

según se estudió en la presentación Integrando en PMBOK al Proceso Unificado

de Desarrollo de Software en Proyectos de Tecnologías de Información

(http://www.scribd.com/doc/3366004/PMBOK-y-RUP-PMI-Peru-Congreso-2007vf),

Conceptos de RUP( http://www.scribd.com/doc/7844685/CONCEPTOS-DE-RUP)

y IS, RUP y UML en el Contexto de ADOO

http://sophia.javeriana.edu.co/~lcdiaz/ADOO2008-1/IngSoftwareEnADOO(IS-RUP-

UML).pdf, en donde queda justificado el porqué es necesario integrar estas dos

metodologías al utilizar de cada una de ellas sus mejores prácticas para el

desarrollo de proyectos de software.

46

Cuadro n.o 9: Fortalezas y debilidades entre el PMBOK y la RUP

PMBOK RUP

Fortalezas

1. La guía de PMBOK es un marco y un estándar.

2. Está orientada a procesos. 3. Indica el conocimiento

necesario para el manejo del ciclo de vida de cualquier proyecto, programa y portafolio a través de sus procesos.

4. Define para cada proceso sus insumos, herramientas, técnicas y reportes necesarios.

5. Define un cuerpo de conocimientos en el que cualquier industria puede construir las mejores prácticas específicas para su área de aplicación.

1. Busca implementar las mejores prácticas en Ingeniería de Software.

2. Los artefactos y los roles de los participantes del proyecto se encuentran bien definidos.

3. Permite desarrollar productos de software con calidad, porque permite controlar de manera transparente todo el proceso de desarrollo

4. La RUP es un conjunto de metodologías adaptables al contexto y necesidades de cada organización.

Debilidades

1. Complejo para los proyectos pequeños.

2. Por su condición genérica tiene que ser adaptado a la industria del área de aplicación, tamaño y alcance de proyecto, el tiempo y el presupuesto y la calidad.

3. No fue creado solo para proyectos de software.

1. Proporciona un marco para manejar proyectos orientados al software.

2. No maneja la gestión del recursos humano.

3. No maneja la gestión de la comunicación.

4. No maneja la gestión de costos. 5. Debido a su estructura se vuelve

difícil, tanto para aprender como para administrar.

6. El profundizar en las reglas para su uso, puede desviar el objetivo en la entrega del software.

7. Se gasta mucho tiempo en tratar de adaptar la RUP acuerdo a cada proyecto.

8. El adquirir el soporte para el proceso se encuentra en rangos altos de costos.

Dado que la UTIC busca obtener proyectos de desarrollo de software exitosos, el

complementar estas dos metodologías viene a solventar la deficiencia en cuanto al

47

manejo de proyectos y a la forma de crear software, tomando en consideración lo

anterior está integración ayudara a la UTIC en:

1. Que el utilizar el PMBOK con la RUP integradas permitirá desarrollar

proyectos de software no solo de calidad y bien documentados, si no que

estos se podrán realizar en el tiempo alcance y costo definido.

2. Ambas metodologías permiten un desarrollo iterativo e incremental,

permitiendo que los usuarios directos puedan ver productos en un corto

plazo.

3. Estas dos metodologías son adaptables tanto a las necesidades de la

organización, como a la adaptabilidad entre ellas.

4. Las dos metodologías tienen muy bien definido los roles de cada persona

en la organización, el que, el cómo y el cuándo. Permitiendo un mayor

control de las actividades asignadas.

5. La RUP permite desarrollar aplicaciones sacando el máximo provecho de

las nuevas tecnologías, mejorando la calidad, el rendimiento, la

reutilización, la seguridad y el mantenimiento del software mediante una

gestión sistemática de los riesgos.

6. El software que se produce cumple con las necesidades de los usuarios,

con la recolección específica de los requisitos, con el cumplimiento del

cronograma y costo establecido, aumenta el desempeño y la productividad

del equipo de trabajo, proporcionando mejores prácticas de desarrollo de

software a todos sus miembros.

48

7. Da un mejor proceso de desarrollo práctico, considerando amplias guías,

plantillas y ejemplos para todas las actividades críticas. Otorga el uso de

guías para el manejo de áreas tales como modelado de negocios,

desarrollo de arquitectura Web, elaboración de pruebas y control de

calidad.

8. Pone el equipo de desarrollo de software en unión y mejora la

comunicación entre los miembros ya que da una base de conocimientos, un

lenguaje de modelado y una guía de cómo desarrollar un proyecto de

software.

9. Optimiza la experiencia en la producción de cada miembro del equipo al

poner al alcance la madurez derivada de los proyectos ya realizados.

10. Garantiza que los proyectos abordados sean ejecutados en su totalidad y

evita las posibles desviaciones importantes respecto al cronograma y por

ende a los plazos de entrega.

11. El hacer una definición acertada del alcance del sistema en un inicio, hace

innecesarias el parcheo del software parciales posteriores.

2.6. Plan de Capacitación del CENDEISS

Para elaborar un plan de capacitación debe contener al menos los siguientes

apartados:

49

2.6.1. Aspectos introductorios

Se trata de presentar el documento elaborado dentro de un marco institucional de

referencia, indicando el para qué se realiza, los componentes que posee, la

estructura del documento y otras consideraciones del grupo de trabajo que realiza

el documento.

2.6.2. Objetivos y Metas del Plan de Capacitación

Se deben considerar aspectos relacionados con el “qué”, “cómo” y “para qué” de

los objetivos, que sugiere la mayoría de la bibliografía en el área de investigación

en cuanto a la construcción de adecuados objetivos de trabajo.

2.6.3. Operacionalización del Plan

Se procede a visualizar las actividades críticas y todos los recursos necesarios

para la ejecución de cada uno de los objetivos que constituyen el plan. Para cada

objetivo enunciado, se toman en consideración aspectos tales como:

• Actividades críticas

• Responsable

• Fecha de Inicio

• Fecha Fin

• Medios Requeridos

• Meta

• Indicador de cumplimiento

• Responsable.

En el cuadro n.o 9 se muestra manera de llenado para la operacionalidad de los

objetivos.

Cuadro n.o 10: Operacionalización de Objetivos

50

Objetivo del Plan

Actividades según Objetivo

Meta Indicador de Cumplimiento

Fecha Inicio

Fecha Fin

Recursos Requeridos Respon-sable Aula Material Multimedia

Alimen tación

2.6.4. Logística de la capacitación

Es importante tomar en cuenta los siguientes aspectos fundamentales para cada

una de las actividades educativas de la metodología. Deben enumerarse al menos

los siguientes aspectos:

• Nombre de la Actividad.

• Posibilidad local, regional o central para ejecución de evento: Se

intentará clasificar aquellas actividades de capacitación que se planeen

desarrollar desde el mismo Centro de Trabajo, con recursos y

coordinación propia. También se separa aquellas actividades que son

de coordinación regional y aquellas que serán desarrolladas a nivel de

Oficinas Centrales o CENDEISS.

• Requerimientos de material didáctico: ¿La actividad requiere el

desarrollo o reproducción de material didáctico?

• Participantes esperados: Indicar el número de funcionarios que van a

participar en cada una de las actividades educativas.

• Requerimientos de espacio físico: Indicar requerimiento de aula, espacio

y mobiliario.

• Requerimientos de equipo de Multimedia: ¿es necesario el equipo de

cómputo y equipo de proyección?

• Requerimientos de viáticos: ¿es necesario tramitar viáticos?

• Requerimiento de Aval Educativo. Por sus características la

capacitación requiere aval educativo del CENDEISSS.

51

• Otras: Espacio abierto para cualquier otra consideración dentro del

detalle.

2.6.5. Materiales para el desarrollo de la capacita ción.

Para cada una de las actividades educativas que se pretenden desarrollar y

considerar la necesidad de material didáctico. Debe responder preguntas como:

• ¿Se requiere material didáctico?.

• ¿El material debe desarrollarse antes de la capacitación?

• ¿El material existe y debe ser reproducido?.

• ¿El material será aportado por el desarrollador de la capacitación?.

El propósito de este detalle es conocer aspectos relevantes al contenido escrito

necesario para el desarrollo de las actividades de capacitación. También

fundamenta la estimación de los costos, ya que en muchos casos el material debe

reproducirse, comprarse o dedicar horas profesionales para su construcción o

consolidación.

2.6.6. Evaluación del plan de capacitación

Se recomienda una evaluación basada en los objetivos, en la que el grupo

responsable de la administración del plan de capacitación pueda, según el avance,

en la consecución de los productos esperados y según cada objetivo, tener

información pertinente y veraz para la toma de decisiones relacionadas con el

éxito, fracaso o replanteamiento de las acciones plasmadas en el plan de

capacitación.

Dentro de la evaluación del plan pueden considerarse indicadores como:

• Número de actividades desarrolladas.

• Número de participantes capacitados.

• Horas efectivas de capacitación.

• Grupos ocupacionales capacitados.

52

• Tipos de actividad educativa (aprovechamiento, participación,

asistencia).

• Otros.

2.6.7. Financiamiento de las actividades educativas .

Desarrollar un resumen de los costos y el financiamiento de las actividades

educativas, contestando las siguientes preguntas:

• ¿Cuáles son los costos de la actividad educativa?

• ¿Es necesario buscar financiamiento adicional para el desarrollo de los

eventos?

• ¿La actividad de capacitación se desarrollará a través de la cuenta

presupuestaria de la CCSS denominada 2131 Actividades de Capacitación?

• ¿Será necesario la afectación de otras cuentas presupuestas?

53

3. MARCO METODOLÓGICO

A continuación se presenta el marco metodológico el cual describe cada uno de

los métodos, técnicas y herramientas que se utilizaron en la elaboración del PFG.

En el Anexo nº 2 se puede observar la Estructura Detallada del Trabajo con las

diferentes tareas y entregables y el Anexo nº3 se muestra el cronograma con las

fechas asignadas para elaborar el presente Proyecto Final de Graduación

3.1 Fuentes de información

Según Grande & Abascal (2007) las fuentes de información las define como “el

conjunto de fuentes de conocimientos necesarios para comprender situaciones,

tomar decisiones o evaluar las ya tomadas.” (p 53). Las fuentes de información se

dividen en dos, fuentes primarias y fuentes secundarias, las cuales se detallan a

continuación:

3.1.1. Fuentes primarias

Según Hernández y otros (2003) definen las fuentes primarias como aquellas que

“Constituyen el objeto de la investigación bibliográfica o revisión de la literatura y

proporcionan datos de primera mano” (p. 23).

Las fuentes primarias utilizadas para este trabajo son instrumentos como

encuestas efectuadas al personal analista programador de la UTIC; la entrevista a

la jefatura de la UTIC y al personal de sistemas de información del Banco Central

de Costa Rica por el juicio experto, relacionado con el tema que se desarrolla en el

PFG y la observación del trabajo en la UTIC.

54

3.1.2. Fuentes secundarias

Según Hernández y otros (2003) definen las fuentes primarias como aquellas que

“son compilaciones, resúmenes y listados de referencias publicadas en el área de

conocimiento en particular (son listados de fuentes primarias). Es decir,

reprocesan información de primera mano” (p. 23).

Las fuentes secundarias utilizadas para este proyecto son los libros, tesis e

información de páginas en Internet relacionadas con el tema de la investigación,

normas y reglamentos de la Contraloría General de la República y las normas y

reglamentos de la Caja Costarricense de Seguro Social.

3.2 Técnicas de investigación

Las técnicas son las herramientas metodológicas de la investigación, éstas

permiten instrumentar los distintos procesos específicos de la investigación,

dirigiendo las actividades hacia la consecución de los objetivos formulados.

3.2.1. Investigación documental

Según Eyssautier (2006) la investigación documental es “una investigación que se

efectúa a través de consulta en los documentos, pudiendo ser revistas, libros,

diarios, informes, anuarios o cualquier otro registro que da testimonio de un hecho

o fenómeno.” (p 116)

3.2.2. Investigación de campo

Según Eyssautier (2006) la investigación de campo es “aquella que se realiza

directamente con la fuente de información y en el lugar y tiempo en que ocurren

los fenómenos objeto de estudio.” (p 116)

Tres tipos de investigación de campo que se utilizarán en el PFG son: estudios

exploratorios, estudios explicativos y estudios descriptivos. Esta clasificación es

55

muy importante, debido a que según el tipo de estudio de que se trate varía la

estrategia de investigación. El diseño, los datos que se recolectan, la manera de

obtenerlos, el muestreo y otros componentes del proceso de investigación son

distintos en estudios exploratorios, descriptivos y explicativos. En la práctica,

cualquier estudio puede incluir elementos de más de una de estas cuatro clases

de investigación.

• Exploratorio

Según Pinal (2006) en el método exploratorio se “Recopilan información de un

tema poco estudiado, realizando investigación de campo”. (p. 14)

Los estudios exploratorios se efectúan, normalmente, cuando el objetivo es

examinar un tema o problema de investigación poco estudiado o que no ha sido

abordado antes. Es decir, cuando la revisión de la literatura reveló que únicamente

hay guías no investigadas e ideas vagamente relacionadas con el problema de

estudio.

• Descriptivo

Según Pinal (2006) en el método descriptivo se “Identifican variables, es decir,

atributos o conceptos aún no estudiados que serán descritos o medidos. Muestran

cómo son, cómo se manifiestan, en qué condiciones.” (p. 14)

El propósito del investigador es describir situaciones y eventos, describiendo cómo

es y cómo se manifiesta determinado fenómeno. Los estudios descriptivos buscan

especificar las propiedades importantes de personas, grupos, -comunidades o

cualquier otro fenómeno que sea sometido a análisis.

56

• Explicativos

Según Pinal (2006) en el método explicativo se “relacionan dos o más variables

(las llamadas <<independientes>> y <<dependientes>>, con el fin de explicar por

qué ocurren los fenómenos, es decir, encontrar las causas y las condiciones en

que ocurren.” (p. 14)

Los estudios explicativos van más allá de la descripción de conceptos o

fenómenos o del establecimiento de relaciones entre conceptos; están dirigidos a

responder a las causas de los eventos físicos o sociales. Como su nombre lo

indica, su interés se centra en explicar por qué ocurre un fenómeno y en qué

condiciones se da éste, o por qué dos o más variables están relacionadas.

3.2.3. Investigación mixta

Según Eyssautier (2006) la investigación mixta es “aquella que se basa tanto en

datos primarios de campo como secundarios documentales” (p. 117)

Se realizará una investigación mixta para el PFG en desarrollo, es decir se hará

una investigación de libros, artículos en Internet, normas y procedimientos

establecidos por la Contraloría General de la República y la CCSS. En la

investigación de campo se realizará el trabajo combinando los tres tipos de

investigación de campo antes mencionadas.

3.3 Método de investigación.

Los métodos de investigación son las herramientas metodológicas de la

investigación, éstas permiten instrumentar los distintos procesos específicos de la

investigación, dirigiendo las actividades hacia la consecución de los objetivos

formulados.

57

3.3.1. Método analítico-sintético

Según Eyssautier (2006) el método analítico-sintético “descompone una unidad en

sus elementos más simples, examina cada uno de ellos por separado, volviendo a

agrupar las partes para considerarlas en conjunto.” (p. 98)

3.3.2. Métodos particulares y específicos

Según Pineda (2004) “La existencia de métodos particulares obedece a la gran

diversidad de las ciencias, que para desarrollarse, requieren estos métodos

propios de las mismas.” (p. 53).

Según Pineda (2004) “los métodos específicos son aquellos que se utilizan dentro

del proceso de investigación científica y que, en algunos casos, pueden ser

también empleados de manera interdisciplinaria.” (p. 54)

3.3.3. Método de observación

Según Pineda (2004) el método de observación es “observar es la acción de mirar

detenidamente una cosa para asimilar en detalle la naturaleza investigada, su

conjunto de datos, hechos y fenómenos.” (p. 54).

Como se indico anteriormente, la metodología RUP fue adquirida desde al año

2009 por parte de la C.C.S.S., y la cual puede ser facilitada para la aplicarla en las

diferentes dependencias. Está metodología viene a ayudar en la parte del manejo

de desarrollo de software interno de la UTIC, no así el manejo del proyecto como

tal y por ende se iba a seguir presentando en parte el problema antes mencionado

y que se tiene en la UTIC.

58

Para comparar y analizar las metodologías RUP y PMBOK se coordina charla con

la empresa Infosgorup con el tema sobre RUP, generalidades y beneficios con

otras metodologías.

Se investiga en la literatura e internet sobre el beneficio de utilizar la RUP y el

PMBOK en una misma metodología.

En el cuadro n.o 10 se representan cada uno de los objetivos el proyecto, así como

sus principales contenidos para su realización.

63

Cuadro n.o 11: Resumen para el Desarrollo del Marco Metodológico

Objetivos Fuentes de información Métodos de Investigación Herramientas Entregables

Primarias Secundarias Analítico -Sintético

Observación

Definir las áreas del conocimiento y grupos de procesos, con el fin de aplicarlos en la propuesta de administración y desarrollo de proyectos de software interno de la Unidad de Tecnología de Información y Comunicación del Hospital Dr. Rafael Ángel Calderón Guardia.

Personal de Sistemas del Banco Central de Costa Rica

Libros. Artículos en Internet. Normas y regulaciones de la Contraloría General de la República. Desarrollo de sistemas de la CCSS.

Estudiar las áreas del conocimiento.

Se realizará entrevista

Juicio experto

Documento con las áreas del conocimiento y grupos de procesos seleccionados para aplicar a la metodología

Analizar la metodología de desarrollo de software Rational Unified Process (RUP), con el fin de integrarla en la propuesta de administración y desarrollo de proyectos de software interno de la Unidad de Tecnología de Información y Comunicación del Hospital Dr. Rafael Ángel Calderón Guardia.

Personal de Sistemas del Banco Central de Costa Rica

Igual al anterior. Estudiar las mejores prácticas de las áreas del conocimientos y estudiar las mejores prácticas de la RUP

Se realizará entrevista y encuesta para obtener las mejores prácticas de las áreas del conocimiento y la RUP

Entrevista Juicio experto

Documento con las mejo-res prácticas de las áreas de conocimiento y la metodología RUP.

Elaborar una metodología de administración y desarrollo de proyectos de software interno, con el fin de aplicarla en los proyectos de la Unidad de Tecnologías de Información y Comunicaciones del Hospital Dr. Rafael Ángel Calderón Guardia.

Personal de analistas de UTIC. Jefe de UTIC.

Igual al anterior. Integrar áreas del conocimiento con la RUP. Diseñar plantillas.

Se determinará criterio para establecer el diseño de una metodología de desarrollo de software.

Encuesta Entrevista

Plantillas y metodología.

Recomendar una estrategia de capacitación para la metodología de administración y desarrollo de software interno, para inducir al uso de dicha metodología en los funcionarios de la Unidad de Tecnologías de Información y Comunicación.

Personal de analistas de UTIC. Jefe de UTIC.

Igual al anterior. Se obtendrá información sobre la estrategia de capacitación

Encuesta Documento con la recomendación de la estrategia de capacitación

65

4. DESARROLLO

La dificultad propia del desarrollo de software, y su impacto en el negocio, han

puesto de manifiesto las ventajas y la necesidad de aplicar una metodología

formal para llevar a cabo los proyectos de este tipo.

El objetivo es convertir el desarrollo de software en un proceso formal, con

resultados predecibles, que permitan obtener un producto final de alta calidad, que

satisfaga las necesidades y expectativas del cliente. Se quiere dejar el modo de

trabajar desordenado y atrasado, que a menudo requiere de esfuerzos heroicos

para llegar a buen puerto, con los consecuentes desfases de fechas, costos y

malos entendidos con el usuario final, y el más probable desgaste del personal

desarrollador de aplicaciones de la UTIC.

La cantidad de proyectos que tiene la UTIC en ejecución y administración, y el

aumento en la cantidad de nuevos proyectos por desarrollar, ocasiona una

relación dispareja entre los analistas desarrolladores versus proyectos de la UTIC,

lo cual conlleva a depender más de iniciativas individuales que de la construcción

e implementación de técnicas y metodologías basadas en experiencias pasadas y

mejores prácticas, lo cual restringe la visibilidad del estado de los proyectos y la

capacidad para predecir las consecuencias de los mismos, limitando así la

optimización del potencial de la UTIC.

A nivel mundial el manejo en las culturas corporativas tiende cada vez más a un

modelo orientado a proyectos. Esta orientación no es fácil y no se trata de un

proceso evolutivo sino más bien revolucionario dado que requiere de fuertes

cambios en la estructura y cultura organizacional de la UTIC, por lo tanto todo

proyecto es crítico para el éxito de cualquier organización y esto no deja de lado a

la UTIC.

66

4.1 Objetivo Específico Número 1

Definir las áreas del conocimiento y grupos de proc esos, con el fin de

aplicarlos en la propuesta de administración y desa rrollo de proyectos de

software interno en la Unidad de Tecnología de Info rmación y

Comunicaciones del Hospital Dr. Rafael Ángel Calder ón Guardia.

Parece inconcebible que aunque se mencione en este trabajo, que la UTIC tiene

una gran cantidad de sistemas para hospitales más desarrollados de las

dependencias de la CCSS, no cuente con una metodología formal para el

desarrollo de proyectos, sino que se cuenta con diversas formas de trabajo por

parte de los analistas según fueron enseñados en su educación superior. De esta

manera, no hay una forma de determinar el estado de los proyectos en desarrollo

ni tampoco el tiempo estimado que el analista de sistemas durara realizando ese

proyecto.

La forma de establecer el alcance del proyecto actualmente no se determina de

una forma estándar, se basa en la intuición y es por lo que el usuario le pide al

analista que desarrolle ya sea por medio de formularios y realizando una

observación del proceso, pero nunca se acuerda entre las partes que abarcará el

proyecto.

El tiempo que va a durar un proyecto no se sabe. De igual manera la jefatura no

tiene el control de los tiempos de los proyectos, lo que produce una mala

distribución de las cargas de trabajo de los funcionarios y un descontento y

problemas entre los mismos.

Tampoco existe una documentación formal ni tampoco se cuenta con controles de

los entregables que los analistas programadores deban realizar. Por lo cual, todo

queda a criterio de cada funcionario, con la problemática que en la actualidad la

67

Auditoría Interna de la CCSS exige que en el control interno de cada

departamento se definan los procesos y las tareas que se llevan a cabo. Es decir,

que para el desarrollo de sistemas se tienen que documentar los procesos, los

riesgos, continuidad y la documentación de cada una de ellas.

Al definir las áreas del conocimiento y los grupos de procesos que se van a aplicar

para la metodología de desarrollo de software de la UTIC, se va a ordenar el

proceso de desarrollado teniendo como consecuencia que se va a mitigar los

riesgos que se puedan presentar a la hora de desarrollar un proyecto y se quiere

llegar a cumplir con el alcance y el tiempo de los proyectos.

Para definir las áreas del conocimiento que llevara la nueva metodología de

desarrollo en la Unidad de Tecnología de Información y Comunicación, se

procedió a realizar cuestionarios a 6 funcionarios que laboran en dicha área como

analistas-programadores de sistemas, esto con el fin de determinar la situación

actual y evaluar a la luz de este modelo el problema expuesto al inicio de la

investigación.

De acuerdo con las respuestas de los funcionarios de la UTIC, éstas arrojaron

resultados negativos, demostrando que la forma de desarrollar un proyecto de

software es desordenado y problemático, obteniendo datos base para la propuesta

metodológica de esta investigación y por lo tanto queda claro cuales Área del

Conocimiento son necesarias para utilizarlas en la nueva metodología.

Dentro de esta evaluación no se tomó en consideración el Área de Gestión de

Adquisiciones dado que el desarrollo de software es interno, además tampoco se

tomó en consideración el Área de Gestión de Costes debido a que los salarios de

los funcionarios ya se encuentran contemplados en el presupuesto del Hospital.

68

Es importante mencionar que los grupos de procesos como son: inicio,

planificación, ejecución, seguimiento y control y cierre son considerados básicos y

obligatorios y están considerados en las plantillas que se diseñaron para tales

efectos. La UTIC está totalmente abandonada a su suerte y a la disposición de las

diferentes formas de trabajo de los Analistas programadores. La falta de

planificación en los proyectos es evidente y sobre los mismos no hay un control,

haciendo que no se cuenten con una ejecución ordenada y sistemática del

proyecto; además tampoco se cuenta con procesos de cierre y con entregables

definidos que vienen en contraposición con lo que se indica en las buenas

prácticas de la administración de proyectos, es decir, en tiempo, alcance, costo y

satisfacción del usuario.

4.1.1. Área de Gestión de Integración

El área de gestión de integración permite considerar el proyecto como un todo, es

decir, todos los componentes de las áreas de algún modo se deben relacionar.

Como se mencionó anteriormente, en la actualidad la UTIC no cuenta con una

metodología que permita unificar, consolidar y articular para concluir el proyecto y,

así cumplir satisfactoriamente con los requisitos expuestos de los usuarios del

Hospital.

Al incorporar el Área la Gestión de Integración en la metodología propuesta se va

a solventar la falta de unificación, consolidación y articulación para la conclusión

del proyecto. Esta área se considera importante de incluir en la metodología ya

que permite formalizar el inicio del proyecto, otorgar las facultades necesarias al

responsable del proyecto, también facilita al líder del proyecto y a su equipo a

comprender mejor las necesidades del negocio, el porqué del proyecto y sus

riesgos.

Procesos:

• Desarrollar el plan de gestión del proyecto.

69

• Dirigir y gestionar la ejecución del proyecto.

• Supervisar y controlar el trabajo del proyecto.

• Control integrado de cambios.

• Cerrar el proyecto.

Para los procesos de esta área se estaría elaborando las siguientes herramientas:

• el acta de constitución de proyectos,

• el enunciado del alcance del proyecto preliminar y

• el cierre administrativo del proyecto.

4.1.2. Área de Gestión del Alcance

El alcance del proyecto siempre debe estar en el nivel de comprensión de todos

los decisores del proyecto. En general, un alcance debe ser cuidadosamente

medido dándose el tiempo de graduarlo, no sólo con base a las características

técnicas, sino también a las características políticas, culturales y psicológicas que

a veces son mucho más importantes. Siempre hay que recordar que el diseño de

un alcance orientado al éxito del proyecto, no necesariamente coincidirá con un

alcance de excelencia técnica muy alta, aunque podría coincidir.

En la UTIC no se cuenta con una definición clara y exacta para lograr delimitar el

alcance del proyecto, provocando que el software que se desarrolle internamente

no alcance las expectativas del usuario prolongándose por un periodo

indeterminado de horas de trabajo del funcionario haciendo un círculo vicioso de

cambios por parte de los mismos.

El desarrollar esta área facilita la confirmación de los entregables del proyecto y

sus criterios de aceptación, antes de definir completamente el alcance. Para que el

cliente, patrocinador y el equipo del proyecto confirmen como serán los

entregables finales del proyecto.

70

Procesos:

• Planificación del alcance,

• Verificación del alcance.

• Control del alcance.

Con las siguientes herramientas:

• Carta constitución del Proyecto

• Estructura detallada del trabajo (en adelante EDT).

• Informe del estado del Proyecto

4.1.3. Área de Gestión de Tiempo

En esta área se encuentran los procesos requeridos para asegurar que el proyecto

termine de acuerdo con el cronograma. Tiene como objetivo asegurar que el

proyecto se lleve a cabo en los plazos previstos. Para ello hay que definir la

secuencia de actividades a realizar, así como su duración y coordinación.

En la UTIC no se cuenta con una identificación de actividades que deben ser

realizadas para los diferentes entregables del proyecto, ni tampoco una

secuencias de la realización de esas actividades. No se da una estimación de los

recursos y por ende, no se tiene una visibilidad de la duración de los proyectos

que se desarrollan, generando un descontrol por parte de la jefatura y

coordinadores de analistas al no saber en qué actividades y el tiempo que está

consumiendo un analista programador en un proyecto.

El desarrollar y controlar el cronograma permite coordinar, programar y confirmar

la viabilidad de las entregas parciales y definitivas. Además permite conocer los

tiempos de inicio y fin de cada actividad, así como la ruta crítica.

71

Procesos:

• Establecimiento de la secuencia de las actividades.

• Estimación de recursos de las actividades.

• Estimación de la duración de las actividades.

• Desarrollo del cronograma.

• Control del cronograma.


• Cronograma de las actividades.

• Informe del estado del Proyecto

• Reporte de avance del Proyecto

4.1.4. Área de Gestión de Calidad

El Área de Gestión de Calidad tiene como objetivo que el proyecto satisfaga las

necesidades para las que fue inicialmente diseñado. Para ello se debe planear,

asegurar y controlar la calidad del proyecto en todo momento, respecto a esas

necesidades.

La UTIC no cuenta con normas de calidad para los proyectos de software que se

han desarrollado, generando que no se pueda determinar en cada proyecto si

cumplió la expectativa para lo cual fue concebido.

Esta área permite enfocarse en la previsión, asegurando la calidad desde la

planeación, el diseño, hasta el cierre del proyecto.

Procesos:

72

• Planificación de calidad.

• Realizar el aseguramiento de calidad.

• Realizar control de calidad.


• Requerimientos del Proyecto

• Documento de arquitectura de software

• Documento de diseño técnico de software

• Documento para caso de prueba del proyecto

• Minuta de aceptación de pruebas

4.1.5. Área de Gestión de Recurso Humano

Tiene como objetivo la utilización más eficiente posible de las personas que

participan en el proyecto, y entre sus actividades están el plan organizacional, la

contratación de nuevos empleados y el desarrollo de los equipos.

Para esta área en la UTIC no se cuenta con una asignación de roles y

responsabilidades para el desarrollo de los proyectos de software; esto hace que

los analistas desarrollados del área en ocasiones tengan una sobrecarga de

trabajo de los dos o más proyectos a la vez. Aunado a esto, se asignan los

funcionarios a los proyectos sin tomar en consideración si estos funcionarios

cuentan con la expertiz requerida para desarrollar el software en determinado

lenguaje de programación y además no se le da formación necesaria para mejorar

las competencias.

Dentro de las ventajas de aplicar esta área es que permite alinear los esfuerzos

del equipo en la misma dirección. Haciendo una distribución efectiva del trabajo y

las funciones con base en la estructura detallada del trabajo (de ahora en adelante

EDT).

73

Procesos:

• Adquirir el equipo del proyecto.

• Desarrollar el equipo del proyecto.

• Gestionar el equipo del proyecto.


• Gestión de Recursos Humanos.

4.1.6. Área de Gestión de Comunicación

El Área de Gestión de Comunicación tiene como objetivo asegurar la correcta

generación, colección, diseminación, almacenamiento y eliminación de la

información del proyecto, en unos plazos determinado.

Para esta área en la UTIC los enlaces de comunicación no están establecidos,

esto porque no se genera ni se distribuye en forma y tiempo las comunicaciones

pertinentes entre los involucrados del proyecto que se están desarrollando

rompiendo así los enlaces antes mencionados de comunicación e impidiendo una

comunicación exitosa.

Esta área permitirá mayor certidumbre en el manejo de la información, asegurando

los reportes veraces, oportunos, completos y relevantes.

Procesos:

• Planificación de las comunicaciones.

• Distribución de la información.

• Informar el rendimiento.

• Gestionar a los interesados..

74


• Gestión de Comunicación del Proyecto.

4.1.7. Área de Gestión de Riesgos

La recomendación de los expertos en gestión de riesgos es la siguiente: antes de

asumir un trabajo ya sea corto o largo, se debe evaluar qué puede hacer que este

trabajo no tenga éxito y qué puede ayudar a que tenga éxito. Una vez que se ha

hecho una lista se debe priorizar cuáles de estos aspectos son las más probables

y los que mayor impacto podrían causar, y para aquéllos que salgan con mayores

cifras debe generarse respuestas.

Explorar los impactos prácticos de la gestión de riesgo en nuestro desempeño en

tiempos de crisis, debería ser una de las primeras medidas a tomar para

protegernos, y una de las herramientas más útiles para tener éxito en un entorno

difícil.

La UTIC actualmente no cuenta con una gestión de riesgo lo que aumenta la

probabilidad de no satisfacer el alcance, el tiempo y costo del proyecto

ocasionando la insatisfacción de los usuarios del Hospital.

Esta área permite al Gerente del proyecto y al equipo, prever y actuar con

oportunidad para evitar los problemas potenciales. Al tener una gestión de riesgos

se aumenta la probabilidad para el impacto de eventos positivos y la disminución

de eventos negativos para el proyecto.

Procesos:

• Planificación de la gestión de riesgos.

• Identificación de riesgos.

75

• Análisis cualitativo de riesgos.

• Análisis cuantitativo de riesgos.

• Planificación de la respuesta a los riesgos.

• Seguimiento y control de riesgos.


• Plan de Gestión de riesgos.


Analizar la metodología de desarrollo de software R ational Unified Process

(RUP), con el fin de integrarla en la propuesta de administración y desarrollo

de proyectos de software interno en la Unidad de Te cnología de Información

y Comunicaciones del Hospital Dr. Rafael Ángel Cald erón Guardia.

En el año 2009 la C.C.S.S. adquirió licencias de RUP para el desarrollo de sus

sistemas, esto permite el poder solicitar licencias por parte de las UTIC.

En el desarrollo de este objetivo se analiza las mejores prácticas para el desarrollo

de software RUP para integrarla a la propuesta de desarrollo de software interno.

Actualmente, la efectividad en el uso de las tecnologías se encuentra ligada al

éxito de las organizaciones que han encontrado oportunidad para su crecimiento.

El desarrollo de software se ha convertido en un proceso clave ya que tiene un

impacto directo en el desarrollo y calidad de productos o servicios que brinda la

organización.

El desarrollo y evolución de software se ve permanentemente impactado, por un

lado, esto se debe a la cantidad de requerimientos que tiene la organización, y por

76

el otro, por los cambios y variedad tecnológica en aplicaciones disponibles,

ambientes operativos, plataformas, infraestructura de redes, ambientes de

desarrollo y lenguajes de programación, haciendo que cada día el desarrollo y

evolución de software quiera lograr productos de mayor calidad y en menor

tiempo.

Por estas razones, muchas organizaciones han decidido invertir en mejorar sus

procesos de desarrollo y evolución de software, obteniendo como resultado

inmediato un excelente retorno al lograr mayor calidad en sus productos y

disminuir sus tiempos y costos de desarrollo.

Muchos de los proyectos han sido abandonados porque no se terminan a tiempo o

porque superan los presupuestos asignados. La mayoría de proyectos han sido

concluidos pero no cumplen con lo que la empresa necesita y apenas se instala el

nuevo producto ya hay que hacerle cambios. Otros proyectos se prometen para

una fecha pero son entregados fácilmente con años de retraso.

Las disciplinas de RUP están claramente relacionadas a las 6 mejores prácticas

de las fases antes mencionadas, pero más de cerca representa roles de los

miembros o subgrupos dentro del equipo de desarrollo completo. Estas disciplinas

son:

1. Modelado del negocio

2. Requerimientos.

3. Análisis y diseño

4. Implementación

5. Prueba

6. Despliegue

7. Manejo de proyecto

8. Ambiente

77

9. Configuración y manejo del cambio

Dentro de la RUP se establecen disciplinas que se expresan en término de roles

(quien realiza que), siendo el concepto central del proceso, define el

comportamiento y responsabilidad de un individuo quien al fin y al cabo es

responsable de actividades y artefactos. Es necesario tener presente que los roles

no son individuos. Los miembros individuales de cada procesos pueden

desempañar diferentes roles y un rol puede ser desempeñado por varios

individuos.

Las actividades (como ellos realizan estas tareas), es una tarea de la cual un rol

es responsable y quizás pueda ser consultado para realizarlo. Una actividad es

una unidad de trabajo que desempeña el rol descrito, en la actividad se definen los

pasos necesarios para alcanzar satisfactoriamente los resultados esperados con

su ejecución. La actividad tiene un propósito claro, usualmente expresado en

términos de creación o actualización de algunos artefactos, tales como un modelo,

una clase, un plan. Cada una de las actividades es asignada a un rol específico.

Esto describe los pasos requeridos para crear o actualizar uno o más artefactos.

Los artefactos (que alcanza la actividad), es una entrada y/o una salida de una

actividad. Son también conocidos como entregables o productos de trabajo tanto

finales como intermedios que son producidos y usados durante un proyecto. Los

artefactos son usados para capturar y transportar información del proyecto. Otros

elementos suplen a estos tres elementos principales, tales como concepto, pautas

de trabajo, informes, pautas de artefactos, plantillas y puntos de comprobación.

78


Elaborar una metodología de administración y desarr ollo de proyectos de

software interno, con el fin de aplicarla en los pr oyectos de la Unidad de

Tecnologías de Información y Comunicaciones del Hos pital Dr. Rafael Ángel

Calderón Guardia.

En una charla sobre RUP dada a los funcionarios de la UTIC, se realizó la

pregunta a un experto sobre el beneficio de combinar la RUP con la metodología

PMBOK, el experto manifestó una aprobación muy convincente y dio referencias

de muchas empresas que adoptaron las dos metodologías en los departamentos

de Tecnología de Información, con muy buenos rendimientos.

Dadas estas referencias y a la investigación realizada en la literatura e internet

sobre el beneficio de utilizar la RUP y el PMBOK en una misma metodología, se

toma la decisión de combinarlos y aplicarlos para estandarizar los procesos y

documentos entregables generados, durante el desarrollo de los proyectos de

software interno de la UTIC. Además provee un enfoque disciplinado para asignar

tareas y responsabilidades dentro de la UTIC. Tal como lo indica RUP, el proceso

de desarrollo de software ha sido dividido por cuatro fases, que se ejecutan de

manera secuencial; dichas fases se denominan Iniciación, elaboración,

construcción y transición. Tal y como lo muestra la figura n.o 14

Figura n.o 14: Fases del proceso de desarrollo de Software

En cada fase se incorporan las áreas del conocimiento del PMBOK antes

analizadas en esta tesis, con el fin de ordenar un flujo de trabajo secuencialmente

79

y que se dé una serie de procedimientos. Por su parte, cada procedimiento está

compuesto por una serie de actividades que consumen y generan artefactos, que

son los productos tangibles del proceso como por ejemplo, los casos de uso, el

código fuente, etc., para efectos de la metodología propuesta y debido al alcance

definido para la investigación, solo se mencionarán los artefactos documentales

generados por cada actividad.

Se diseñan una serie de plantillas para ser utilizadas en la metodología y cada una

de estas plantillas, van a ser ilustradas con un ejemplo de un proyecto que ya está

en ejecución, esto se hace para dar una mayor claridad en la forma del llenado de

la plantillas.

4.3.1. Fase de Iniciación

Durante la fase de iniciación se establecen todas las actividades que definen el

modelo, alcance del proyecto, la visión operativa, se identifican todos los actores y

se diseñan los Casos de Uso. Se desarrolla, un plan de negocio para determinar

qué recursos deben ser asignados al proyecto y se establecen las pautas

necesarias para el desarrollo del proyecto, todo esto es relacionado a la RUP. Se

integran en esta fase de Iniciación propia de RUP, las áreas del conocimiento

necesarias para el complemento en las áreas que no tiene RUP y que benefician

en la administración de proyectos, como son la gestión de integración, gestión del

alcance, gestión del tiempo, gestión de comunicaciones y gestión de recursos

humanos, con el buscar la integración y así elaborar una metodología

combinando las dos metodologías La figura n.º 15, muestra la representación

gráfica del flujo de trabajo que se plantea para la etapa de iniciación.

80

Figura n.o 15: Flujo de trabajo para la fase de iniciación

81

4.3.1.1. Actividades, roles y artefactos de la fas e de iniciación

4.3.1.1.1. Estudiar un nuevo proyecto

Este procedimiento forma parte de la disciplina de Administración de Proyectos de

RUP y ha sido modificado para ésta metodología. El objetivo de este

procedimiento es el estudiar un proyecto de la propuesta inicial a un punto en el

cual se pueda tomar una decisión razonada sobre continuar o abandonar el

desarrollar el proyecto. Se adopta la plantilla de carta de Aceptación del proyecto

que fue de estudio durante la Maestría de Administración de proyectos, por ser

una plantilla flexible y en donde se encuentra la información necesaria para el

entregable que se solicita.

Cuadro 12: Fase de Iniciación - Estudiar un nuevo p royecto

Actividades ejecutadas en el procedimiento

Descripción de la actividad Artefactos

documentales de salida

Estudiar un nuevo proyecto

Estudiar la factibilidad de aceptar el desarrollo de un proyecto nuevo. El responsable de ésta actividad es el Jefe de la UTIC.

-Carta de Aceptación del proyecto (Ver anexo 4)

4.3.1.1.2. Priorizar el portafolio de proyectos

Este procedimiento es propuesto por la Jefatura de la UTIC, por no contar el

departamento con un portafolio de proyectos. El propósito de este procedimiento

es de tener un inventario de los proyectos y darles una prioridad, es un proceso de

gestión que ayudará a la UTIC a clasificar cada proyecto de acuerdo con

determinados criterios, como valor estratégico, el impacto sobre los recursos,

costos, entre otros. La idea es desarrollar proyectos que ofrezcan beneficios para

el hospital. Se adopta la plantilla de Actas de reunión, creadas para el PFG por

funcionarios de la UTIC y en donde se encuentra la información necesaria para el

entregable que se solicita.

82

Cuadro 13: Fase de Iniciación - Priorizar el portaf olio tecnológico




Priorizar el portafolio de sistemas

Esta actividad pretende dar prioridad a los proyectos que ofrecen beneficios para el hospital. Coordinar reunión con el coordinador de Analistas para el análisis de la prioridad a otorgar y la disposición de analistas para el desarrollo del proyecto. Confeccionar y enviar las actas de la reunión. El responsable de ésta actividad es el Jefe de la UTIC y Coordinador de Analistas

-Actas de reunión (Ver anexo 5)

4.3.1.1.3. Gestión de Integración

Este procedimiento forma parte de las áreas del conocimiento del PMBOK y ha

sido modificado para ésta metodología. El objetivo de este procedimiento es el de

llevar la idea de un proyecto nuevo, a documentar los requisitos iníciales que

satisfacen las necesidades y expectativas de los interesados. Se diseñan las

plantillas tomando en consideración el proyecto de Desarrollo de un sistema para

la gestión de artículos deportivos y elementos necesarios para manejar plantillas

de RUP y plantillas que se utilizaron de estudio durante la Maestría de

Administración de proyectos.

Cuadro 14. Fase de Iniciación – Gestión de Integrac ión




Identificar y formular proyecto

Identificar y formalizar un proyecto dentro del hospital con el fin de que exista un entendimiento común entre sus involucrados acerca del alcance del proyecto. El producto principal es la Carta de Constitución del Proyecto, la cual define aspectos que identifican el proyecto y permite establecer el compromiso de la organización mediante su autorización. El responsable de esta actividad es el Coordinador de Analistas

-Carta de constitución del proyecto (Ver plantilla en el anexo n.o 6)

83

y Analista encargado del Proyecto. Desarrollar plan de control y aceptación de cambios

El propósito de tener un proceso de control de cambios estándar y documentado es para asegurar que los cambios se hagan dentro del proyecto de una manera consistente y qué los afectados están informados del estado del proyecto. El responsable de esta actividad es el Analista encargado del proyecto.

-Desarrollar el control de cambios (Ver plantilla en el anexo n.o 7)

Reportar avance de tareas

Esta tarea trata de informar al Jefe de la UTIC sobre el avance en las tareas asignadas a cada uno de los miembros del equipo, con el propósito de establecer el progreso de las tareas. El responsable de efectuar esta actividad es el Analista encargado del proyecto

-Reporte de avance (Ver anexo n.o 8)

Actualizar avance de tareas

Esta actividad se desarrolla en cualquier momento en que un Miembro de Equipo reporte un avance en una tarea que tenga asignada. En el momento en que el Administrador del Proyecto recibe la notificación de que un Miembro del Equipo del proyecto ha completado una tarea, debe validar la calidad de la entrega que la tarea produce. El responsable de ejecutar esta tarea es el Analista programador y el Jefe de la UTIC

-Métricas del proyecto (Ver anexo n.o 9) -Cronograma del proyecto (Ver anexo n.o 10)

Revisar el progreso del proyecto

El propósito de esta actividad es revisar con el equipo del proyecto el progreso alcanzado en el mismo, entregas próximas, actividades cumplidas, atención de riesgos del proyecto. El responsable es el Coordinador de analistas programadores.

-Lista de asuntos(Ver anexo n.o 11) -Métricas del proyecto(Ver anexo n.o 9)

Actualizar programación de tareas de trabajo

Esta actividad se realiza con el fin de distribuir las tareas con base en la programación del proyecto. El responsable de esta actividad es el Coordinador de analistas.

-Orden de trabajo(Ver anexo n.o 12)

Informar el estado del proyecto

El propósito de esta actividad es informar las actualizaciones regulares acerca del estado del proyecto para hacerlas de conocimiento del Supervisor del Proyecto. El responsable de realizar esta actividad es el Coordinador de

-Informe de estado del proyecto (Ver plantilla en el anexo n.o 13)

84

analistas. Supervisar el estado del proyecto

Supervisar el progreso del proyecto a fin de que se cumplan los objetivos establecidos. El responsable de realizar esta actividad es el Jefe de la UTIC.

Esta actividad no genera artefactos documentales

4.3.1.1.4. Gestión del Alcance



incluir todo y únicamente todo lo necesario que requiere el proyecto para

completarlo con éxito. Se diseñan las plantillas tomando en consideración el

proyecto de Desarrollo de un sistema para la gestión de artículos deportivos y

elementos necesarios para manejar plantillas de RUP y plantillas que se utilizaron

de estudio durante la Maestría de Administración de proyectos.

Cuadro 15: Fase de Iniciación – Gestión del Alcance




Elaborar el plan de proyecto

El propósito de esta actividad es elaborar el Plan de Proyecto así como planes adjuntos a éste. El responsable de esta actividad es el Coordinador de Analistas.

-Plan de proyecto (Ver anexo n.o 14)

Elaborar la Estructura detallada del trabajo (en adelante EDT)

Esta actividad sirve para elaborar el proyecto en paquetes para su monitoreo y avance. El responsable de esta actividad es el Analista encargado del Proyecto.

EDT (Ver anexo n.o

15)

Definir el control de cambios

El documento generado en esta actividad, debe ser utilizado a fin de darle solución a los cambios que se presentan dentro del proyecto. El responsable de esta actividad es el Coordinador de Analistas.


Definir el monitoreo y control del proyecto

Esta actividad busca definir procesos de monitoreo y control, ya que permite tener información acerca del estado del proyecto, de los recursos y de las situaciones que podrían necesitar ser


85

modificadas. El responsable de esta actividad es el Coordinador de Analistas.

Desarrollar la plantilla de requerimientos

El propósito de esta actividad es desarrollar la plantilla para documentar requerimientos, sus atributos, y las guías de trazabilidad y administración de los requerimientos del producto. El responsable de esta actividad es el Analista del sistema.

-Plantilla para recopilar requerimientos (Ver plantilla en el anexo n.o 16)

Seleccionar y configurar el ambiente de la administración de la configuración

El propósito de esta actividad es configurar un ambiente donde el producto pueda ser desarrollado y construido. Esto se hace en dos partes: primero estableciendo el ambiente de hardware, y segundo estableciendo el ambiente de desarrollo del software.

Configurar el ambiente de Administración de la Configuración involucra asignar recursos de máquina (servidores y espacio en disco) e instalar las herramientas de administración de la configuración.

Configurar el ambiente de desarrollo involucra crear repositorios, establecer la estructura de directorios del producto e importar cualquier archivo existente. El ambiente inicial sirve como una línea base para un posterior trabajo de desarrollo. El responsable de esta actividad es el Administrador de la Base de Datos

-Orden de trabajo(Ver anexo 12)

Aprobar el plan de proyecto

Esta actividad genera la aprobación del plan del proyecto. El responsable de esta actividad es el Jefe de la UTIC.


4.3.1.1.5. Gestión del Tiempo



asegurar que el proyecto se lleve a cabo en los plazos previstos. Para ello hay que

definir la secuencia de actividades a realizar, así como su duración y coordinación.

86

Se adoptan las plantillas que se utilizaron de estudio durante la Maestría de

Administración de proyectos por ser una plantilla flexible y en donde se encuentra

la información necesaria para el entregable que se solicita.

Cuadro 16: Fase de Iniciación – Gestión del Tiempo




Desarrollar el cronograma del proyecto

Esta actividad debe realizarse para establecer los tiempos de las diferentes actividades involucradas en el proyecto. El responsable de esta actividad es el Coordinador de Analistas y Analista encargado del Proyecto

-Cronograma (Ver anexo n.o 10)

4.3.1.1.6. Gestión de Riesgos



identificar, analizar y dar respuesta a los riesgos que amenacen la marcha del

proyecto. Estos riesgos tienen que estar correctamente identificados y

cuantificados, así como los mecanismos de respuesta pertinentes. Se adoptan las

plantillas que se utilizaron de estudio durante la Maestría de Administración de

proyectos por ser una plantilla flexible y en donde se encuentra la información

necesaria para el entregable que se solicita.

Cuadro 17: Fase de Iniciación – Gestión de Riesgos




Desarrollar el plan de administración de riesgos

En esta actividad se definen los lineamientos para desarrollar un plan para la administración de riesgos. El responsable de esta actividad es el Coordinador de Analistas y el Analista encargado del Proyecto.

-Gestión de riesgos (Ver anexo n.o 17)

87

4.3.1.1.7. Gestión de Comunicaciones



asegurar la correcta generación, recolección, diseminación, almacenamiento y

eliminación de la información del proyecto, en plazos determinados a los

interesados del proyecto. Se adoptan las plantillas que se utilizaron de estudio

durante la Maestría de Administración de proyectos por ser una plantilla flexible y

en donde se encuentra la información necesaria para el entregable que se solicita.

Cuadro 18: Fase de Iniciación – Gestión de Comunica ciones




Desarrollar el plan de comunicación

Durante esta actividad se elaboran la estrategia de comunicación de mensajes (avances, problemas, entre otros.) del proyecto a todos los afectados identificados previamente. El responsable de esta actividad es el Coordinador de Analistas y el Analista encargado del Proyecto.

-Gestión de Comunicación (Ver anexo n.o 18)

4.3.1.1.8. Gestión de Recursos Humanos



la utilización más eficiente posible de las personas que participan en el proyecto.

Se adoptan las plantillas que se utilizaron de estudio durante la Maestría de

Administración de proyectos por ser una plantilla flexible y en donde se encuentra

la información necesaria para el entregable que se solicita.

88

Cuadro 19: Fase de Iniciación – Gestión de Recursos Humanos




Elaborar la asignación del recurso humano

El propósito de esta actividad es establecer la estructura organizacional para el desarrollo del proyecto, así como asignar al personal para las diferentes tareas a realizar. El responsable de esta actividad es el Coordinador de Analistas


4.3.2. Fase de elaboración

En la fase de elaboración, los procesos se enfocan hacia la comprensión del

problema y la tecnología, la delimitación del ámbito del proyecto; se abarcan más

los procesos de requerimientos y análisis y diseño. La figura n. º 16, muestra la

propuesta para el flujo de trabajo de la fase de elaboración.

89

Figura n.º 16: Flujo de trabajo para la fase de elaboración

4.3.2.1. Actividades, roles y artefactos de la fase de elaboración

4.3.2.1.1. Análisis de requerimientos

Este procedimiento forma parte de la disciplina de Requerimientos de RUP y ha

sido modificado para ésta metodología. El objetivo de este procedimiento es

obtener y recolectar información de los usuarios del proyecto para comprender

cuáles son sus necesidades. Se diseñan las plantillas tomando en consideración

un ejemplo que utiliza elementos necesarios para el desarrollo de software

90

utilizando RUP y plantillas que se utilizaron de estudio durante la Maestría de

Administración de proyectos.

Cuadro 20: Fase de Elaboración – Análisis de requer imientos




Crear vocabulario común

El propósito de esta actividad es definir un vocabulario común para ser utilizado por los casos de uso y el proyecto. El responsable de esta actividad es el Analista del Sistema.

- Plan de proyecto(Ver anexo n.o 14)

Obtener las necesidades de los usuarios

Esta actividad permite obtener y priorizar los requerimientos para los diferentes usuarios del proyecto. El responsable de esta actividad es el Analista del Sistema

-Plantilla de requerimientos (Ver plantilla en el anexo n.o 16)

4.3.2.1.2. Analizar comportamiento

Este procedimiento forma parte de la disciplina de Análisis y diseño de RUP y ha


identificar clases de análisis necesarias para satisfacer el comportamiento

requerido. Se diseñan las plantillas tomando en consideración el proyecto de

Desarrollo de un sistema para la gestión de artículos deportivos y elementos

necesarios para manejar plantillas de RUP.

Cuadro 21: Fase de Elaboración - Analizar comportam iento




Desarrollar arquitectura

El objetivo de esta actividad es definir los patrones de arquitectura. El responsable de esta actividad es el Analistas y encargado de base de datos.

Documento de arquitectura de software. (Ver anexo n.o 19)

Desarrollar Caso de Uso

El propósito de esta actividad es identificar las clases que ejecutan el flujo de eventos de un caso de uso. Analista encargado del proyecto.

Plantilla casos de uso ( ver plantilla en el anexo n.o 20)

91

4.3.2.1.3. Diseñar componentes


sido modificado para ésta metodología. El objetivo de este procedimiento es el

diseño del código fuente del sistema. Se diseñan las plantillas tomando en

consideración el proyecto de Desarrollo de un sistema para la gestión de artículos

deportivos y elementos necesarios para manejar plantillas de RUP.

Cuadro 22Fase de Elaboración - Diseñar componentes




Diseñar componentes

El propósito de esta actividad está orientado al diseño de los componentes del sistema La realización de esta actividad es responsabilidad del analista programador.

Documento de arquitectura de software. (Ver anexo n.o 19)

4.3.2.1.4. Diseñar base de datos


sido modificado para esta metodología. Los objetivos de este procedimiento es el

diseño de las estructuras de base de datos. Se diseñan las plantillas tomando en

consideración el proyecto de Desarrollo de un sistema para la gestión de artículos

deportivos y elementos necesarios para manejar plantillas de RUP.

Cuadro 23: Fase de Elaboración - Diseñar base de da tos




Diseñar base de datos

El propósito de esta actividad está orientado a asegurar que la información persistente se almacena consistente y eficientemente y definir el comportamiento que debe ser implementado en la base de datos. La realización de esta actividad es responsabilidad del encargado de base de datos.

Documento de diseño técnico del software(Ver anexo 21)

Desarrollar migración de

Definir los lineamientos a seguir para que la información sea trasladada desde la base de

Documento de diseño técnico

92

datos de desarrollo a producción

datos de desarrollo a la base de datos de producción, asegurar que la información se almacena consistente y eficientemente. La realización de ésta actividad es responsabilidad del encargado de base de datos.

del software (ver anexo 21)

Revisar el diseño

Verificar que el diseño de base de datos satisface los estándares de modelo de datos. El responsable de ésta actividad es el encargado de base de datos.


4.3.2.1.5. Administrar ejecución

Ver detalles en la sección 4.3.1.1.3. Fase de iniciación Gestión de Integración

4.3.2.1.6. Monitorear y controlar el proyecto


4.3.2.1.7. Preparar ambientes para el desarrollo

Este procedimiento forma parte de la disciplina de Ambiente de RUP y ha sido

modificado para esta metodología. El objetivo de este procedimiento es el de

instalar, configurar, preparar y personalizar las herramientas a usar dentro del

desarrollo del proyecto.

Cuadro 24: Fase de Elaboración - Preparar ambientes para el desarrollo




Instalar software Esta actividad aplicará a todo software que deba ser instalado para sustentar la realización del proyecto. La realización de ésta actividad es responsabilidad del encargado de soporte técnico.


Instalar hardware Esta actividad establece los equipos necesarios para sustentar la realización del proyecto. La realización de ésta actividad es responsabilidad del encargado de soporte técnico


Verificar instalación y configuración de

Verificar que las herramientas puedan ser usadas para desarrollar el sistema. La realización de ésta actividad es


93

hardware y software

responsabilidad del encargado de soporte técnico

4.3.3. Fase de construcción

Durante la fase de construcción los procesos se enfocan hacia el desarrollo y

pruebas del software. La figura n.º 17 muestra la propuesta para el flujo de trabajo

de la fase de construcción.

Figura n.o 17: Flujo de trabajo para la fase de construcción

94

4.3.3.1. Actividades, roles y artefactos de la fase de construcción

4.3.3.1.1 Implementar componentes

Este procedimiento forma parte de la disciplina de Implementación de RUP y ha

sido modificado para ésta metodología. Los analistas programadores tienen la

tarea de desarrollar el código fuente y realizar pruebas de desempeño del sistema.

Cuadro 25: Fase de Construcción - Implementar compo nentes




Implementar componente

El propósito de esta actividad es producir el código fuente de acuerdo con el documento de diseño. La realización de esta actividad es responsabilidad del analista programador


Revisar y ejecutar pruebas del código

Esta actividad trata de verificar el código fuente. También ejecutar las pruebas para comprobar el desempeño del sistema en desarrollo. El responsable de esta actividad es el analista programador


Reparar fallos El propósito de esta actividad es reparar los defectos detectados durante la etapa de pruebas. El responsable de esta actividad es el analista programador


4.3.3.1.2 Probar y Evaluar

Este procedimiento forma parte de la disciplina de Pruebas de RUP y ha sido

modificado para esta metodología. El propósito de este procedimiento es evaluar y

valorar la calidad del producto, buscando y documentando los fallos encontrados.

Se diseñan las plantillas tomando en consideración el proyecto de Desarrollo de

un sistema para la gestión de artículos deportivos y elementos necesarios para

manejar plantillas de RUP.

95

Cuadro 26: Fase de Construcción - Probar y evaluar




Ejecutar casos de prueba

El propósito de esta actividad es implementar pruebas significativas que provean la validación del producto requerido. La realización de esta actividad es responsabilidad del Analista programador

Documento para casos de pruebas (Ver anexo n.o 22)

Analizar fallas en las pruebas

Esta actividad pretende analizar las fallas que ocurrieron durante la implementación y ejecución de las pruebas. El responsable de esta actividad es el Analista programador

Esa actividad no genera artefactos documentales

4.3.3.1.3 Administrar cambios


4.3.3.1.4 Administrar ejecución


4.3.3.1.5 Monitorear y controlar el proyecto


4.3.4. Fase de transición

El principal objetivo de la fase de transición es garantizar que se cuenta con un

producto preparado para entregar a los usuarios del hospital quienes, revisan y

aprueban todos los entregables del proyecto. La figura n.o 18 muestra la propuesta

para el flujo de trabajo de la fase de transición.

96

Figura n.o 18: Flujo de trabajo para la fase de transición

4.3.4.1. Actividades, roles y artefactos de la fase de transición

4.3.4.1.1. Realizar pruebas de aceptación

Este procedimiento forma parte de la disciplina de Puesta en marcha de RUP y ha

sido modificado para esta metodología. El propósito de este procedimiento es

asegurar que el producto es aceptable para el usuario final, previo a su liberación

final. Se diseñan las plantillas tomando en consideración el proyecto de Desarrollo

97

de un sistema para la gestión de artículos deportivos y elementos necesarios para

manejar plantillas de RUP.

Cuadro 27: Fase de Transición - Realizar pruebas de aceptación




Ejecutar y revisar las pruebas de aceptación

El propósito de esta actividad es asegurar que el producto desarrollado cumpla con los criterios de aceptación. El responsable de que esta actividad se ejecute es el Encargado de calidad.

Minuta de aceptación (Ver anexo 23)

4.3.4.1.2. Administrar cambios


4.3.4.1.3. Desarrollar el material de apoyo


sido modificado para ésta propuesta. El propósito de este procedimiento es

producir la documentación y recursos pertinentes para implementar el software a

los usuarios.

El material a entregar debe ayudar al usuario final para instalar, operar, usar y

mantener el sistema entregado. También se debe incluir el material de

entrenamiento.

Cuadro 28: Fase de Transición - Desarrollar materia l de apoyo




Desarrollar material de apoyo

El propósito de esta actividad es crear o modificar los materiales de apoyo para los usuarios, en ayuda a los cursos que se imparten para la implementación del sistema. El responsable de que esta actividad se ejecute es el Capacitador del curso

Material de apoyo como presentaciones power point, manuales de usuario, entre otros.

98

4.3.4.1.4. Realizar la puesta en marcha


sido modificado para ésta metodología. El propósito de este procedimiento es

planear la Puesta en Marcha del producto. El planeamiento de la Puesta en

Marcha necesita tener en cuenta cuándo y cómo el producto estará disponible al

usuario final. Se diseñan las plantillas tomando en consideración el proyecto de

Desarrollo de un sistema para la gestión de artículos deportivos y elementos

necesarios para manejar plantillas de RUP.

Cuadro 29: Fase de Transición - Realizar la puesta en marcha




Desarrollar el documento de implementación del proyecto

Se documenta cómo y cuándo el producto está disponible para los usuarios. El responsable de que esta actividad es el Analista programador y capacitador.

Documento de implementación del proyecto (Ver anexo n.o 24)

4.3.4.1.5. Liberar versión


sido modificado para esta metodología. El propósito de este procedimiento es

generar, controlar y sincronizar la evolución del conjunto de productos que

componen el sistema. Se diseñan las plantillas tomando en consideración el

proyecto de Desarrollo de un sistema para la gestión de artículos deportivos y

elementos necesarios para manejar plantillas de RUP.

Cuadro 30: Fase de Transición – Liberar versión




Registrar versión del software

Esta actividad pretende actualizar e introducir la nueva versión operacional. El responsable de esta actividad es el Analista programador


Generar comunicado de

Esta actividad es desarrollada para las nuevas liberaciones de versiones o

Comunicado de liberación (Ver anexo

99

liberación de software

aquellas que contengan alguna modificación. El responsable de que esta actividad es el Analista programador

n.o 25)

4.3.4.1.6. Administrar ejecución


4.3.4.1.7. Monitoreo y control de proyectos



Recomendar una estrategia de capacitación para la m etodología de

administración y desarrollo de software interno, pa ra inducir al uso de dicha

metodología en los funcionarios de la Unidad de Tec nologías de Información

y Comunicación.

En el año 2007 la Junta Directiva de la CCSS aprobó la Política de Capacitación y

Formación del Recurso en la sesión n.º 8202, del 15 de noviembre del 2007 y el

Reglamento de Capacitación y Formación aprobado en la sesión n.º 8159 del 21

de junio 2007.

La nueva Política Institucional ha señalado un cambio en la gestión de las

actividades académicas. Con esta nueva modalidad los diferentes Centros de

Trabajo podrán detectar sus propias necesidades de conocimiento, el planificar la

manera de tener un capital humano capacitado para su gestión y maximizar los

recursos económicos locales asignados para formación y capacitación.

Para la presente recomendación de capacitación se toman los siguientes aspectos

de importancia del documento Gestión de los procesos de Capacitación y

Formación en la Caja Costarricense de Seguro Social, desarrollado por el Centro

100

de Desarrollo Estratégico e Información en Salud y Seguridad Social (de ahora en

adelante CENDEISSS) y que pretende ser un instrumento para facilitar a los

Centros de Trabajo el cumplimiento de la nueva normativa. Esta normativa

permitirá para llevar a cabo la capacitación de la metodología a los funcionaros de

la UTIC y cuenta con cinco apartados.

4.4.1. Gestión de capacitación

El documento indica que la gestión de la capacitación considera el conjunto de

procesos y actos que están relacionados con el diagnóstico, planificación,

desarrollo y evaluación de actividades educativas llevadas a cabo en el ámbito de

la promoción de los recursos humanos y consta de cuatro etapas:

- Análisis de las necesidades de conocimiento: se realiza para conocer los

aspectos cognitivos que deben ser incorporados en los trabajadores de

una Institución. El producto de esta etapa es el Diagnóstico de

Necesidades de Conocimiento del Centro de Trabajo.

- Planificación de la capacitación o la formación: relacionada con la

capacidad de los Centros de Trabajo para identificar si las necesidades

de conocimiento identificadas en la etapa anterior, deben o pueden ser

resueltas a través de la capacitación o la formación. El producto de esta

etapa es el Plan de Capacitación del Centro de Trabajo.

- Desarrollo y control de las acciones de capacitación: interviene la

capacidad logística de los grupos responsables de la capacitación, para

desarrollar, supervisar y retroalimentar las actividades educativas que se

ejecutan en un Centro de Trabajo. El producto de esta etapa es el

conjunto de acciones implementadas en el ámbito de la capacitación.

- Evaluación de resultados e impacto de la capacitación: etapa final en la

que se estima el mérito del desarrollo de las acciones realizadas en el

ámbito de la capacitación o la formación de recursos humanos. El

101

producto de esta etapa es la Evaluación de Resultados e Impacto del

Plan de Capacitación.

4.4.2. Conformación del equipo de trabajo

Otro aspecto importante a considerar del documento de Gestión de los procesos

de Capacitación y Formación en la Caja Costarricense de Seguro Social es la

creación de la Comisión Local de Educación Permanente, la cual tiene como

objetivo principal el asesorar a la Dirección de cada Centro de Trabajo en materia

de la gestión de capacitación del recurso humano.

Las funciones son de:

• Diagnóstico

• Planeamiento

• Desarrollo

• Evaluación

4.4.3. El Financiamiento de las Actividades Educat ivas

Como lo indica el documento desarrollado por el CENDEISS para los procesos de

capacitación, el financiamiento puede ser realizado por todos los Centros de

Trabajo, que posean unidad programática en el ámbito presupuestario.

Se debe utilizar por parte de la UTIC, la cuenta presupuestaria 2131 denominada

Actividades de Capacitación. Según el Instructivo para la Formulación

Presupuestaria 2008, el detalle de esta cuenta es el siguiente: (…) 2131

Actividades de Capacitación: Gastos por servicios inherentes a la organización y

participación en eventos de formación. (2008, p25).

• Actividades educativas generadas con recursos del m ismo Centro de

Trabajo : Las actividades de capacitación deben estar incluidas en el Plan

102

Anual Operativo y en el Plan de Capacitación Local. Estas actividades son

planeadas, desarrolladas y evaluadas con recursos del mismo Centro de

Trabajo. Se dividen a su vez, en tres grupos:

o Actividades con recursos del Centro de Trabajo

o Actividades con recursos de la CCSS

o Actividades contratadas a Proveedores Externos de Capacitación

Para efectos del financiamiento de la capacitación para la metodología se

recomienda utilizar las actividades con recursos del Centro de Trabajo y en la cual

el organizador del evento, planea y desarrolla la actividad de capacitación

aprovechando la experiencia y conocimiento de un funcionario del mismo Centro

de Trabajo, se debe considerar el material didáctico o alimentación para la

capacitación, ya que debe estar considerada en el presupuesto de la UTIC.

4.4.4. Diagnóstico de necesidades del Recurso Huma no

Se hace mención de este aspecto del documento realizado por el CENDEISS,

para conocimiento general ya que es necesario elaborar la información para el

plan de capacitación local. Este se realiza para identificar posibles requerimientos

de instrucción en los funcionarios, ya sea por desactualización o incorporación de

nuevas políticas, técnicas o tecnología a los procesos de trabajo. Para este

apartado cabe mencionar que las necesidades para el recurso humano de la

UTIC, se establecen en el conocimiento de la presente metodología y uso.

El Reglamento de Capacitación de la CCSS, la define como (Art 2) “una actividad

educativa por medio de la cual un funcionario adquiere o refuerza sus

competencias para mejorar su desempeño de acuerdo con el cargo que ocupa

(…)”.

103

4.4.5. El Plan de Capacitación y Formación

El plan de capacitación permite determinar, ordenar, calendarizar y ponderar las

actividades educativas necesarias para cumplir con los objetivos propuestos en el

plan de capacitación.

Un plan de capacitación ordenado, sistematizado y bien dirigido, aumenta la

efectividad de la inversión en capacitación y asegura que los recursos se invertirán

según las necesidades atendidas por las autoridades locales, respecto al

conocimiento que deben poseer los funcionarios.

Es importante de considerar que todo plan de capacitación debe tener una

estrecha relación con el plan estratégico de la UTIC y éste a su vez ser parte

integral de las acciones que hace la CCSS para avanzar en la consecución de las

metas reflejadas en la misión y visión del centro.

El Plan de Capacitación debe tener en cuenta las necesidades de capacitación

que el funcionario podrá resolver de forma individual y las necesidades de

capacitación que podrán atenderse con recursos locales.

104

UTIC Unidad de Tecnologías de Información y Comunicación


P L A N D E C A P A C I T A C I Ó N M E T O D O L O G Í A D E D E S A R R O L L O D E S O F T W A R E I N T E R N O

105

Historial de revisión

Fecha Versión Descripción Autor

03/02/2010 1.0 Capacitación Metodología de desarrollo

Ing. Roy Céspedes Garbanzo

1. Introducción

Se realiza la capacitación del personal de análisis y desarrollo de la UTIC en la

metodología de desarrollo de software interno. Dentro de los temas a tratar están:

enseñar los fundamentos de la Administración de Proyectos, los fundamentos de

la RUP y las plantillas ha desarrollar para los proyectos.

2. Descripción del programa de capacitación

El programa que a continuación se describe tiene un enfoque eminentemente

práctico, ya que con él se persigue desarrollar en un grupo de profesionales de la

computación, las habilidades que les permita incrementar el desempeño en el

desarrollo de programas. Sin embargo, lo anterior no debe ir en detrimento de que

se les transfiera los conocimientos teóricos necesarios para cimentar

adecuadamente su gestión en esta materia.

2.1. Objetivos del programa de capacitación

2.1.1. Objetivo General

Capacitar al personal de Analistas desarrolladores en la metodología de

desarrollo de software interno del hospital Dr. R. A. Calderón Guardia.

2.1.2. Objetivos específicos

• Enseñar los fundamentos de la Administración de Proyectos

106

• Enseñar los fundamentos de la Rup

• Enseñar la metodología de desarrollo de software enfatizando en las

fases de inicio, elaboración, construcción y transición.

2.2. Población meta

6 funcionarios entre Ingenieros y Licenciados en Informática que desarrollan

software en la UTIC

2.3. Tipo de curso

Curso-taller

2.4. Descripción general del evento

1. El tiempo de duración del curso es de siete días hábiles

2. El tiempo establecido por día es de seis horas efectivas de lecciones,

con dos períodos de treinta minutos para el refrigerio de mañana y tarde

y 60 minutos para el almuerzo

3. El horario que se establece por día es de 07:30 de la mañana a las

16:30 de la tarde.

4. La capacitación se va a impartir en la sala de sesiones de la UTIC en el

hospital Dr. R.A. Calderón Guardia.

5. Temario general:

o Fundamentos de la Administración de Proyectos.

o Fundamentos de la RUP.

o Enseñanza de la metodología de desarrollo de software interno.

2.4.1. Metodología del curso

El curso se impartirá bajo una metodología teórico - practica

107

2.4.2. Nivel de los docentes

Nivel académico del docente, Bachiller en Ingeniería de sistemas de

Información

Capacitación a cargo del Ing. Roy Céspedes Garbanzo

2.4.3. Nivel y reconocimiento del curso

Nivel de aprovechamiento

Certificado de aprovechamiento

2.5. Metodología de evaluación

No se hará evaluación

Programación

TALLER DE CAPACITACIÓN Modelo de desarrollo de software interno

Día: 1 Sesión: 1 Tema/Actividad

07:30 am a 08:00 am Inauguración y presentación del curso

08:00 am a 9:00 am Aspectos generales de la Administración de Proyectos

09:00 am a 09:30 am Refrigerio

09:30 am a 12:00 md Aspectos generales de las áreas del conocimiento y grupos de procesos

12:00 md a 13:00 pm Almuerzo


13:00 pm a 14:30 pm Aspectos generales de la RUP

14:30 pm a 15:00 pm Refrigerio

108


15:00 pm a 16:30 pm Aspectos generales de la RUP


07:30 am a 08:00 am Aspectos generales Fase de iniciación

08:00 am a 9:00 am -Estudiar un nuevo proyecto/Práctica de llenado de la plantilla


09:30 am a 10:30 am Priorizar el portafolio/Práctica llenado del acta de reunión

10:30 md a 12:00 md Gestión de Integración/Práctica de llenado de plantillas



13:00 pm a 16:00 pm Gestión de Integración/Práctica de llenado de plantillas


15:00 pm a 16:30 pm Gestión de Integración/Práctica de llenado de plantillas


07:30 am a 09:00 am Gestión del Alcance/Práctica de llenado de plantillas


09:30 am a 12:00 md Gestión del Alcance/Práctica de llenado de plantillas



13:00 pm a 14:30 pm Gestión del Alcance/Práctica de llenado de plantillas

109



15:00 pm a 16:30 pm Gestión del Alcance/Práctica de llenado de plantillas


07:30 am a 09:00 am Gestión del Tiempo/Práctica de llenado de plantillas


09:30 am a 12:00 md Gestión del Tiempo/Práctica con Microsoft Project



13:00 pm a 14:30 pm Gestión del Riesgo/Llenado Plan de Gestión del Riesgo


15:00 pm a 16:30 pm Gestión del Riesgo/Llenado Plan de Gestión del Riesgo


07:30 am a 09:00 am Gestión de Comunicaciones/Práctica de llenado de plantillas


09:30 am a 12:00 md Gestión de Recursos Humanos/



13:00 pm a 14:30 pm Aspectos generales Fase de Elaboración Análisis de requerimientos/ Práctica de llenado de plantillas


110


15:00 pm a 16:30 pm Analizar Comportamiento/ Práctica de llenado de plantillas Diseñar componentes/ Práctica de llenado de plantillas Diseñar base de datos/ Práctica de llenado de plantillas Preparar ambiente para el desarrollo/ Práctica de llenado de plantillas


07:30 am a 08:00 am Aspectos generales Fase de Construcción

08:30 am a 09:00 Implementar componentes


09:30 am a 12:00 md Probar y Evaluar



13:00 pm a 13:30 pm Aspectos generales Fase de Transición


15:00 pm a 16:30 pm Realizar pruebas de aceptación/ Práctica de llenado de plantillas


07:30 am a 08:00 am Desarrollar material de apoyo

08:00 am a 09:00 Realizar puesta en marcha/Práctica de llenado de plantilla


09:30 am a 12:00 md Liberar versión



13:00 pm a 14:30 pm Preguntas Sugerencias de mejoras a la metodología

111



15:00 pm a 16:30 pm Cierre de la capacitación

112

5. CONCLUSIONES

En cuanto a las áreas del conocimiento y grupos de procesos que van a ser

aplicados, en la gestión de administración y desarrollo de proyectos de software

interno en la Unidad de Tecnología de Información y Comunicación se determina

que:

1. Con la utilización de la carpeta de portafolios de proyectos se logrará

obtener un repositorio con las lecciones aprendidas en proyectos

desarrollados con la utilización de la nueva metodología, esto ayudará a la

capacidad de la UTIC en cuanto al estudio de proyectos nuevos a

desarrollar, priorizar proyectos y delegar a los analistas desarrolladores

proyectos nuevos.

2. Para la UTIC contar con un plan de Gestión en la Administración de

Proyectos es muy beneficioso por qué se logra cumplir con los objetivos

previsto, en el tiempo y el alcance, que son máximas para lograr un

proyecto exitoso.

3. Utilizando las áreas del conocimiento y los grupos de procesos, el personal

de la UTIC establece un cronograma de trabajo, que orienta las tareas a

realizar y éstas se pueden monitorear y controlar.

4. Aplicando el monitoreo y control que ofrecen las áreas del conocimiento y

grupo de procesos por parte del Jefe de la UTIC, asegura el tener una

visión más amplia de los proyectos que se realizan en el departamento y su

grado de avance; de esta forma permitirá actuar de forma expedita en la

toma de decisiones si se tiene un proyecto que presenta dificultades.

En cuanto al análisis de la metodología de desarrollo de software Rational Unified

Process (RUP), para integrarla en la propuesta para la administración y desarrollo

de proyectos de software interno en la Unidad de Tecnología de Información y

Comunicación se determina que:

113

1. El combinar la metodología de desarrollo de software RUP y las

áreas del conocimiento y grupos de procesos eleva el porcentaje de

satisfacción del cliente en un proyecto de desarrollo de software

2. El integrar la RUP como metodología de desarrollo de software hace

que se tengan que entregar artefactos de los cuales hay

responsables de su elaboración, lo cual trae consigo un compromiso

y delegación y así se sabe quién hace qué, cómo y cuándo.

En cuanto a elaborar la metodología de la administración y desarrollo de proyectos

de software interno para la ejecución de los proyectos en la Unidad de

Tecnologías de Información y Comunicaciones del Hospital Dr. Rafael Ángel

Calderón Guardia se determina que:

1. La utilización de la metodología diseñada asegura un estándar de

desarrollo de software interno para los analistas programadores de la

UTIC.

2. La creación de plantillas guía al personal de la UTIC en el desarrollo

los artefactos documentales que se deben presentar para el

desarrollo del proyecto de software, teniendo un proyecto totalmente

documentado.

3. El contar con una metodología de desarrollo de software hace que

los proyectos desarrollados por la UTIC, sean declarados como

exportables a otras unidades de la C.C.S.S.

En cuanto a recomendar una estrategia de capacitación para la metodología de

administración y desarrollo de software interno, para inducir al uso de dicha

metodología en los funcionarios de la Unidad de Tecnologías de Información y

Comunicación se determina que:

114

1. El preparar una estrategia de capacitación para los analistas

programadores viene en beneficio del poder poner en práctica la

metodología y no ser rechazada por el personal de la UTIC.

2. Es indispensable tomar en cuenta la normativa de la C.C.S.S. en

cuanto a los procesos de capacitación, para no ser rechazados por el

CENDEISS y evaluados negativamente por la auditoría interna.

115

6. RECOMENDACIONES

De acuerdo con las áreas del conocimiento y grupos de procesos que van a ser

aplicados en la gestión de administración y desarrollo de proyectos de software

interno, en la Unidad de Tecnología de Información y Comunicación se

recomienda que:

1. Se recomienda a la Jefatura de la UTIC, promover el uso de las áreas

del conocimiento y grupos de procesos elegidos para la gestión de

administración y desarrollo de proyectos de software interno.

2. Se recomienda a la Jefatura de la UTIC, promover el uso continuo de la

metodología para su orientación en aplicar las mejores prácticas, que

brindan las áreas del conocimiento y grupos de procesos en el

monitoreo y control de los proyectos.

En cuanto al análisis de la metodología de desarrollo de software Rational Unified

Process (RUP), para integrarla en la propuesta para la administración y desarrollo

de proyectos de software interno en la Unidad de Tecnología de Información y

Comunicación se determina:

1. A la Jefatura de la UTIC, promover el uso de la metodología de

desarrollo de software RUP a los funcionarios de la UTIC.

2. A la Jefatura de la UTIC y al Coordinador de Analistas, continuar con

la mejora de los procesos de la RUP gradualmente, de manera que

se pueden ir incrementando el aprovechamiento de la metodología

en el desarrollo de proyectos de software.

3. Al Coordinador de Analistas y a los Analistas del Hospital, utilizar

para el desarrollo de proyectos de software interno de las cuatros

116

fases definidas por la RUP, como son iniciación, elaboración,

construcción y transición.

En cuanto a elaborar la metodología de la administración y desarrollo de proyectos

de software interno para la ejecución de los proyectos en la Unidad de

Tecnologías de Información y Comunicaciones del Hospital Dr. Rafael Ángel

Calderón Guardia se recomienda:

1. A la Jefatura de la UTIC, promover el utilizar la metodología diseñada

para la estandarización en el desarrollo de proyectos de software

internos por parte de los funcionarios de la UTIC.

2. Al Personal de la UTIC, continuar con el ciclo de vida iterativo propuesto

en el manejo de la RUP.

3. A la Jefatura de la UTIC, crear una base de datos histórica para

recapitular las lecciones aprendidas de los proyectos anteriores y poder

aplicarlos en nuevos proyectos.

4. Al coordinador de Analistas, utilizar las plantillas de métricas para llevar

estadísticas que ayuden en la toma de decisiones.

5. A los Analistas desarrolladores, disminuir la brecha que existe en la

actualidad en el desarrollo de software por parte de los funcionarios de

la UTIC y la metodología diseñada para el desarrollo de proyectos de

software internos.

En cuanto a recomendar una estrategia de capacitación para la metodología de

administración y desarrollo de software interno, para inducir al uso de dicha

metodología en los funcionarios de la Unidad de Tecnologías de Información y

Comunicación se determina:

117

1. A la Jefatura de la UTIC, brindar el apoyo necesario para la

capacitación de los analistas programadores para poner en práctica

la metodología y no ser rechazada por el personal de la UTIC.

2. A la Jefatura de la UTIC, tomar en cuenta la normativa de la C.C.S.S.

en cuanto a los procesos de capacitación, para no ser rechazados

por el CENDEISS y evaluados negativamente por la auditoría

interna.

118

7. BIBLIOGRAFIA

• Caja Costarricense de Seguro Social, Reseña historica (en línea). Consultado el 19 de setiembre de 2009. Disponible en http://www.ccss.sa.cr/html/organizacion/organizacion.html y luego http://www.ccss.sa.cr/html/organizacion/c_organizacional/c_org_06.html.

• Caja Costarricense de Seguro Social, Política Institucional de Capacitación y Formación de Recursos Humanos. Aprobada en Junta Directiva CCSS. Artículo 7. Sesión Nº 7937. 03 de Marzo de 2005.

• Caja Costarricense de Seguro Social,Reglamento a las Políticas de Capacitación y Formación de la CCSS. Aprobado en Junta Directiva CCSS. Artículo 20. Sesión 8161. 21 de Junio de 2007.

• Caja Costarricense de Seguro Social, Gerencia División Financiera. Dirección de Presupuesto. Instructivo para la formulación presupuestaria 2008. Diciembre, 2007

• Conceptos de RUP (en línea). Consultado 28 de noviembre de 2009 http://www.scribd.com/doc/7844685/CONCEPTOS-DE-RUP

• Eyssautier, M. Metodlogía de la investigación: desarrllo de la inteligencia. Editorial Thomson 5 ª. Edición, 2006.

• Gestión de Proyectos: Integrando el PMBOK al Proceso Unificado de

Desarrollo de Software en Proyectos de TI (en línea). Consultado el 26 de noviembre de 2009. Disponible en http://kasyles.blogspot.com/2008/10/integrando-el-pmbok-al-proceso.html

• Grande, I, Abascal, E. Fundamentos y técnicas de investigación comercial. Editorial ESIC, 9ª. Edición, 2007.

• Hernandez Sampieri, Roberto,Fernández Collado Carlos; Baptista Lucio

Pilar. Metodología de la Investigación. Mc Graw Hill, 4ª .2003

• Hospital Dr. Rafael Angel Calderón Guardia, Historia. Consultado el 19 de setiembre de 2009. Disponible en la intranet http://172.1.48.148/hdrcg/ y luego http://172.1.48.148/hdrcg/Historia.aspx

119

• Hospital Dr. Rafael Angel Calderón Guardia, Manual de la Organización. Consultado el 21 de setiembre de 2009. Disponible en la intranet (en línea) en http://172.1.48.148/hdrcg/Informatica.aspx \\172.1.48.148\docs\Informatica\Manual_Organizacional.ppt

• IS, RUP y UML en elContexto de ADOO (en línea). Consultado 28 de noviembre de 2009 http://sophia.javeriana.edu.co/~lcdiaz/ADOO2008-/IngSoftwareEnADOO(IS-RUP-UML).pdf

• Jacaboson, I., Booch, G., Rumbaugh J., El Proceso Unificado de Desarrollo de Software, 2000 Addison Wesley

• Kruchten, P. Architectural Blueprints—The “4+1” View Model of Software

Architecture. IEEE Software 12 (6), November 1995

• Pinal, k. Apuntes de Metodología y redacción. Guía para la elaboración de un proyecto de tesis. D.R. Publicaciones Cruz o.,S.A. 1ª, 2006.

• Pineda, M. Lenguaje y expresión 2: lectura y redacción, con textos

periodísticos, científicos y literarios. Editorial Pearson educación, 2004.

• PMBOK-y-RUP-PMI-Peru-Congreso-2007vf. Congreso Nacional de Gerencia de Proyectos PMI 2007 (en línea). Consultado el 02 de diciembre de 2009. Disponible en http://www.scribd.co999m/doc/3366004/PMBOK-y-RUP-PMI-Peru-Congreso-2007vf

• Project Management Institute. Guía de los Fundamentos de la Dirección de Proyecto, Project Management Institute, Inc.4 ª, 2008

• Sapag, N., Sapag, R. Preparación y Evaluación de Proyectos, McGraw-Hill

Latinoamericana, S.A. 2ª, 1989.

• Tecnología y Sinergix: Plantillas RUP (en línea).Consultado el 27 de noviembre de 2009. Disponible en http://synergix.wordpress.com/tag/plantillas-rup/

• Universidad Politecnica de Valencia: Proyecto de desarrollo de software (en línea). Consultado 27 de noviembre de 2009. Disponible en http://users.dsic.upv.es/asignaturas/facultad/lsi/ejemplorup/

120

8. ANEXOS

8.1. Anexo n. o 1: Acta del proyecto

ACTA DEL PROYECTO

Fecha Nombre de Proyecto

08 de setiembre 2009

Propuesta de metodología para la administración y desarrollo de proyectos de software interno en la Unidad de Tecnologías de Información y Comunicaciones del Hospital Doctor Rafael Ángel Calderón Guardia

Areas de conocimiento / procesos: Area de aplicación (Sector / Actividad):

Alcance,Tiempo, Riesgos, RRHH, Comunicación, Integración, Planificación, Seguimiento y control y Cierre.

Sector Salud

Fecha de inicio del proyecto Fecha tentativa de finalización del proyecto

12 de setiembre 2009 01 de Febreo 2010 Objetivos del proyecto (general y específicos)

Objetivo general

Desarrollar una propuesta de metodología para la administración y desarrollo de proyectos de software interno en la Unidad de Tecnologías de Información y Comunicaciones del Hospital Doctor Rafael Ángel Calderón Guardia para contar con una herramienta que permita estandarizar el desarrollo de estos proyectos.

Objetivos específicos

• Definir las áreas del conocimiento y grupos de procesos, con el fin de aplicarlos en la propuesta de administración y desarrollo de proyectos de software interno de la Unidad de Tecnologías de Información y Comunicaciones del Hospital Dr. Rafael Ángel Calderón Guardia.

• Analizar la metodología de desarrollo de software Rational Unified Process (RUP), con el fin de integrarla en la propuesta de administración y desarrollo de proyectos de software interno de la Unidad de Tecnologías de Información y Comunicaciones del Hospital Dr. Rafael Ángel Calderón Guardia.

• Elaborar una metodología de administración y desarrollo de proyectos de software interno, con el fin de aplicarla en los proyectos de la Unidad de Tecnologías de Información y Comunicaciones del Hospital Dr. Rafael Ángel Calderón Guardia.

• Recomendar una estrategia de capacitación para la metodología de administración y desarrollo de software interno, para inducir al uso de dicha metodología en los funcionarios de la Unidad de Tecnologías de Información y Comunicación.

Justificación o propósito del proyecto (Aporte y resultados esperados)

La Unidad de Tecnologias de Información y Comunicación del Hospital Dr. Rafael Angel Calderón Guardia, tiene el sistema de información más avanzado desarrollado por sus funcionarios para hospitales del sector público. Sin embargo carece de una metología de desarrollo de proyectos de software, ocasionando el no poder entregar el

121

sistema de información a otros hospitales del sector público.

La propuesta de la metodología de la administración y desarrollo de software interno pretende que los desarrollos de sistema de información del Hospital Dr. Rafael Angel Calderón Guardia, cuenten con una estructura que les permita llevar a cabo con éxito su finalización. y su futura implementación en otros hospitales públicos.

Descripción del producto o servicio que generará el proyecto – Entregables finales del proyecto

El entregable final del proyecto es generar una propuesta de una metodología para la administración y desarrollo de software interno en la Unidad de Tecnologías de Información y Comunicación del Hospital Dr. Rafael Angel Calderón y en el transcurso del desarrollo del proyecto los principales entregables son:

1. Informe con las áreas del conocimiento y grupos de procesos que van a ser aplicados en la gestión de la administración y desarrollo de proyectos de software interno en la Unidad de Tecnología de Información y Comunicación.

2. Informe con el análisis de la metodología de desarrollo de software Rational Unified Process, para aplicarla en la metodología de administración y desarrollo de software interno en la Unidad de Tecnología de Información y Comunicación.

3. Metodología para la administración y desarrollo de proyectos de software interno en la Unidad de Tecnologías de Información y Comunicaciones del Hospital Dr. Rafael Ángel Calderón Guardia.

4. Documento con la recomendación de la estrategia para la implementación de la metodologia de administración y desarrollo de software interno.

Supuestos

1. Se cuenta con la autorización de la Jefatura de la Unidad de Tecnologias de Información y Comunicación para el desarrollo.

2. Accesibilidad de información como normativas, directrices y estándares que rigen a las Unidades de Tecnologías de Información y Comunicación en la CCSS.

3. Disponibilidad del personal de la Unidad de Tecnologias de Información y Comunicación para las consultas necesarias en la propuesta de diseño de la metodología.

Restricciones

1. El tiempo que se cuenta para desarrollar la propuesta de la metodología es relativamente corto. 2. Cambio de jefatura por presentar problemas de enfermedad grave.

Información histórica relevante

No se encuentran documentados esfuerzo similares de metologías de administración y desarrollo de software interno en la Unidad de Tecnologías de Información y Comunicación. Identificación de grupos de interés (Stakeholders)

Cliente(s) directo(s): Funcionarios de la Unidad de Tecnologias de Información y Comunicación Cliente(s) indirecto(s): Personal del Hospital Dr. Rafael Angel Calderón Guardia Elaborado por:

Ing. Roy Céspedes Garbanzo Firma:

Aprobado por: Lic. Manuel Alvarez

Firma:

121

8.2. Anexo n. o 2: EDT

122

8.3. Anexo n. o 3: Cronograma

123

8.4. Anexo n. o 4: Carta de Aceptación del Proyecto

Lugar, Fecha

DECISION DE INICIO

Proyecto: xxxxxxxxxxxxx Justificación. [Una justificación de la procedencia del proyecto, con indicación expresa de la necesidad a satisfacer, considerando para ello los planes de largo y mediano plazo, el Plan Nacional de Desarrollo, el Plan Anual Operativo, según corresponda.]

Descripción del objeto [La descripción del objeto, las especificaciones, requerimientos y características de los bienes, obras o servicios que se requieran, en caso de que puedan existir diferentes opciones técnicas para satisfacer la necesidad, acreditar las razones por las cuales se escoge una determinada solución.]

Duración estimada del proyecto El tiempo estimado: 2.1. XXXX 2.2. XXXX Recursos humanos y materiales [Indicación expresa de los recursos humanos y materiales de que dispone o llegará a disponer para la realización del proyecto.]

Encargado general del proyecto Se designa a XFuncionariosXXXX, XXcargoXX como encargado general del proyecto, quien tendrá a su cargo la ejecución, el control y seguimiento de las siguientes actividades: El funcionario competente valorará el cumplimiento de los anteriores requisitos, dispondrá la confección de un cronograma con tareas y responsables de su ejecución y velará por el debido cumplimiento del proyecto que llegue a realizarse; e informará cualquier ajuste en los tiempos del cronograma o incumplimiento trascendente de éste, a fin de que se adopten las medidas pertinentes, de lo cual deberá mantener informado en todo momento al Jefe de la UTIC.]

Atentamente,

Unidad de Tecnologías de Información Y Comunicación

xxxxxxx

Jefe

Copia: Expediente 2

124

San José, 03 de febrero de 2010

DECISION DE INICIO

Proyecto: Nutrición Justificación. El proyecto de Nutrición es necesario por la obsolescencia del programa NUT 2000, que trabaja en una computadora con un sistema operativo Windows 2000. Descripción del objeto Desarrollar un sistema de información que lleve el control de la programación de menús de alimentación y el control de contratos de adquisición de alimentos Duración estimada del proyecto El tiempo estimado: 12 meses 2.1. Programación de menús 2.2. Control de contratos Recursos humanos y materiales 1 ingeniero analista desarrollador 1 técnica en nutrición Se cuenta con computadoras, por lo cual no hay petición para compra de equipo Encargado general del proyecto Se designa a Roy Céspedes Garbanzo, Analista Programador como encargado general del proyecto, quien tendrá a su cargo la ejecución, el control y seguimiento de las siguientes actividades: El funcionario competente valorará el cumplimiento de los anteriores requisitos, dispondrá la confección de un cronograma con tareas y responsables de su ejecución y velará por el debido cumplimiento del proyecto que llegue a realizarse; e informará cualquier ajuste en los tiempos del cronograma o incumplimiento trascendente de éste, a fin de que se adopten las medidas pertinentes, de lo cual deberá mantener informado en todo momento al Jefe de la UTIC.]

Atentamente,


Armando Oporta Serrano

Jefe

Copia: Expediente 2

125

8.5. Anexo nº 5. Acta de reunión

Acta nº [Indicar el número de Acta.]

FECHA: [Indicar la fecha]

HORA: [Indicar la hora.]

LUGAR: [Indicar el lugar en donde se realiza la reunión.]

PRESENTES [Liste las personas presentes en la reunión.]

AUSENTES [Liste las personas ausentes en la reunión.]

TARDES [Liste las personas que se presentaron tarde a la reunión.]

Agenda

Tema: [Describir el porqué de la reunión.]

DISCUSION

[Describir los temas que se discuten y los aportes de cada persona.]

ACCIONES RESPONSABLE FECHA LIMITE

[Que trabajo se debe realizar para las decisiones que se tomaron.] [Indicar quién es el encargado del trabajo.]

[Indicar la fecha de plazo para realizar el trabajo.]

OBSERVACIONES: [Indique que observaciones se dan durante la reunión.]

FIRMAS

[Espacio para las firmas de los asistentes a la reunión]

126

Acta nº 1 FECHA: 03-02-2010 HORA: 09:00 LUGAR: UTIC

PRESENTES Ing. Roy Céspedes Garbanzo, Ana María Jiménez

AUSENTES

TARDES

Agenda

Tema: Ingredientes

DISCUSION

Código de los ingredientes y sus precios

ACCIONES RESPONSABLE FECHA LIMITE

Desarrollar tabla para los ingredientes Ing. Roy Céspedes 02-03-2010

OBSERVACIONES:

FIRMAS

127

8.6. Anexo n. o 6: Plantilla para la carta de constitución del pro yecto



C A R T A D E C O N S T I T U C I Ó N D E L P R O Y E C T O < N O M B R E D E L P R O Y E C T O >

128

1. Historial de revisión

Fecha Versión Descripción Autor Aprobador

2. Definición

Es el documento que define formalmente la existencia de un proyecto y su alcance

dentro de la organización, y permite a su vez autorizar su ejecución. Este

documento es desarrollado en la etapa inicial del proyecto, como respuesta a la

identificación de problemas, oportunidades y requerimientos del proyecto.

129

ACTA DEL PROYECTO

Fecha Nombre de Proyecto [Genere en este punto el índice del documento.] [Anote el nombre propuesto para el proyecto. Procure que sea corto pero entendible, ya

que este será el nombre que aparezca en toda la documentación relacionada con el proyecto.]

Servicio Area de aplicación Describa el Servicio dueño del proyecto de software

Describa el área del servicio que se va aplicar el software

Fecha de inicio del proyecto Fecha tentativa de finalización del proyecto Describa la fecha de inicio Describa la fecha tentativa de finalización del proyecto Objetivos del proyecto (general y específicos)

Objetivo general [Redacte el objetivo general del proyecto siguiendo la estructura Verbo en infinitivo+entrega principal del proyecto+tiempo (fecha límite)+costo(monetario o en esfuerzo).

Objetivos específicos [Redacte los objetivos específicos del proyecto siguiendo la estructura Verbo en infinitivo+entrega principal del proyecto+tiempo (fecha límite)+costo(monetario o en esfuerzo).

Justificación o propósito del proyecto (Aporte y resultados esperados) [Describa con detalle qué problema resuelve el proyecto propuesto y cómo el tener el producto final que entregaría el proyecto soluciona ese problema. Denote los beneficios importantes que se esperan del proyecto.]

Descripción del producto o servicio que generará el proyecto – Entregables finales del proyecto [Realice una descripción puntualizada del producto final del proyecto y sus respectivos entregables, servicios o funcionalidades. Ejemplo: herramienta tecnológica, manuales, plan de capacitación, plan de riesgos.

Supuestos [Describa cualquier supuesto sobre el que se esté basando en este proyecto, quizás relacionado con la tecnología, los recursos, el alcance, expectativas o situaciones que se consideran dadas para el proyecto.]

• [Descripción del supuesto 1] • [Descripción del supuesto 2]

Restricciones [Describa cualquier supuesto sobre el que se esté basando en este proyecto, quizás relacionado con la tecnología, los recursos, el alcance, expectativas o situaciones que se consideran dadas para el proyecto.]

• [Descripción del supuesto 1] • [Descripción del supuesto 2]

Información histórica relevante [Describa si previo al desarrollo del proyecto ya se había realizado esfuerzos similares en proyectos anteriores]

Identificación de grupos de interés (Stakeholders) [Descripción de los clientes directos e indirectos.]

Cliente(s) directo(s): Cliente(s) indirecto(s):

Elaborado por: Describir quién elabora la carta

Firma:

Aprobado por: Describir quién aprueba la carta

Firma:

130



C A R T A D E C O N S T I T U C I Ó N D E L P R O Y E C T O N U T R I C I Ó N

131



02-02-2010 1.0 Desarrollo Ing. Roy Céspedes

4. Definición

Es el documento que define formalmente la existencia de un proyecto y su alcance

dentro de la organización, y permite a su vez autorizar su ejecución. Este

documento es desarrollado en la etapa inicial del proyecto, como respuesta a la

identificación de problemas, oportunidades y requerimientos del proyecto.

132

ACTA DEL PROYECTO

Fecha Nombre de Proyecto 02-02-2010

Nutrición

Servicio Area de aplicación Servicio de Nutrición Área de Programación de menús

Fecha de inicio del proyecto Fecha tentativa de finalización del proyecto 02/02/2010 30/08/2010 Objetivos del proyecto (general y específicos)

Objetivo general Implementar el sistema de programación de menús

Objetivos específicos 1. Realizar diagnóstico de necesidades para la implementación del expediente electrónico en las unidades seleccionadas. 2. Gestión de la infraestructura física necesaria 3. Realizar la instalación y puesta del software en los equipos de cómputo. 4. Sensibilizar al personal directivo y personal médico operativo, en cuanto a la necesidad de la implementación del

sistema para simplificar procesos, ahorro de tiempo de todo el personal involucrado y ahorro en papelería, mejorando la calidad de los datos y la disponibilidad de la información, para garantizar una mejor calidad.

5. Capacitación al personal operativo para la utilización práctica y adecuada del expediente electrónico. 6. Supervisar la utilización del sistema y el funcionamiento adecuado por medio de visitas periódicas.

Justificación o propósito del proyecto (Aporte y resultados esperados)

Descripción del producto o servicio que generará el proyecto – Entregables finales del proyecto 1. Programación de menús 2. Capacitación al personal interesado

Supuestos 1. Se contará con el personal informático necesario para desarrollar el proyecto. 2. Se contará con el presupuesto necesario para desarrollar el proyecto.

Restricciones

Información histórica relevante Se toma como punto de partida el sistema en modo carácter del NUT2000

Identificación de grupos de interés (Stakeholders)

Cliente(s) directo(s): 1. Funcionarios del Àrea de Programación de menús

Cliente(s) indirecto(s): 2. Funcionarios de Salones de pacientes hospitalizados

Elaborado por: Roy Céspedes Garbanzo

Firma:

Aprobado por: Roy Céspedes Garbanzo

Firma:

133

8.7. Anexo n. o 7: Plantilla para desarrollar el control de cambio s



C O N T R O L D E C A M B I O S D E L P R O Y E C T O < N O M B R E D E L P R O Y E C T O >

134



2. Definición

El documento de control de cambios define formalmente como será el flujo para la

aceptación y solución de los cambios que se pidan para el proyecto, estos

cambios representan tanto los cambios en el procedimiento del proyecto, así como

los cambios en el desarrollo propio del desarrollo del software. Este documento es

desarrollado en la etapa inicial del proyecto, para dar una estandarización de

cómo tratar los cambios del proyecto a desarrollar, sin embargo su utilización se

puede dar en cualquier fase del proyecto.

3. Proceso para la aceptación de la plantilla para un cambio en el

proyecto.

2.1 Plantilla de petición de cambio llenada y firmada.

3.1 Entregar la plantilla en recepción de la UTIC.

4.1 Entregar la plantilla a Coordinador de Analistas desarrolladores.

5.1 Revisión de petición de cambio por parte del Coordinador de Analistas

desarrolladores y el Analista encargado del proyecto

6.1 Desarrollar carta de comunicación para el usuario, con la aceptación del

cambio o la no aceptación del cambio con los motivos del rechazo.

135

Petición de cambios

Fecha Nombre de proyecto

[Describa la fecha.]

[Anote el nombre del proyecto.]



Descripción del cambio Describir en forma clara, cual es el cambio solicitado.

• Para el proyecto identificar cual es el proceso o actividad que se pide el cambio. • Para el código del software, indicar puntualmente cual es el proceso en la aplicación que está fallando y el error que se meustra, si

es que lo hay. Nombre del cliente Firma

Control de Cambios

Fecha de analisis Responsables del analisis [Describa la fecha.]

Describa los nombres de los responsables del análisis

Cambio aceptado Cambio rechazado Describir los procesos, artefactos o procedimientos que se ven

afectados.

Describir el porqué no se acepta el cambio. Justificar muy bien el

rechazo.

Fecha de inicio de cambio Responsable del cambio [Describa la fecha.]

Describa el o los nombres de los responsables del cambio

Elaborado por: Describir quién elabora el control de cambios

Firma:

Aprobado por: Describir quién aprueba el control de cambios

Firma:

136



C O N T R O L D E C A M B I O S D E L P R O Y E C T O < N U T R I C I Ó N

137



02-02-2010 1.0 Control de cambios Ing. Roy Céspedes G

2. Definición

El documento de control de cambios define formalmente como será el flujo para la

aceptación y solución de los cambios que se pidan para el proyecto, estos

cambios representan tanto los cambios en el procedimiento del proyecto, así como

los cambios en el desarrollo propio del desarrollo del software. Este documento es

desarrollado en la etapa inicial del proyecto, para dar una estandarización de

cómo tratar los cambios del proyecto a desarrollar, sin embargo su utilización se

puede dar en cualquier fase del proyecto.

3. Proceso para la aceptación de la plantilla para un cambio en el

proyecto.

• Plantilla de petición de cambio llenada y firmada.

• Entregar la plantilla en recepción de la UTIC.

• Entregar la plantilla a Coordinador de Analistas desarrolladores.

• Revisión de petición de cambio por parte del Coordinador de Analistas

desarrolladores y el Analista encargado del proyecto

• Desarrollar carta de comunicación para el usuario, con la aceptación del

cambio o la no aceptación del cambio con los motivos del rechazo.

138

Petición de cambios

Fecha Nombre de proyecto 02-02-2010 Nutrición


Descripción del cambio Describir en forma clara, cual es el cambio solicitado.

• Mantenimiento de alimentos • Revisar el método de guardado con código de cinco cifras

Nombre del cliente Firma Ana María Jimenez

Control de Cambios

Fecha de analisis Responsables del analisis 02-02-2010

Ing. Roy Céspedes G.

Cambio aceptado Cambio rechazado Proceso de guardado de alimentos

Fecha de inicio de cambio Responsable del cambio 20-02-2010

Ing. Roy Céspedes Garbanzo

Elaborado por: Ing. Roy Céspedes G.

Firma:

Aprobado por: Armando Oporta S.

Firma:

139

8.8. Anexo n. o 8: Plantilla para reporte de avance



R E P O R T E D E A V A N C E D E L P R O Y E C T O < N O M B R E D E L P R O Y E C T O >

140

1. Descripción

Este artefacto provee un mecanismo para administrar las expectativas de los

interesados a lo largo de todo el ciclo de vida del proyecto, al proporcionar

información sobre el reporte de tareas y el personal asignado a cada una de ellas,

así como el avance del mismo.

2. Resumen del estado actual [Describe el avance actual tanto del proyecto como del sistema, con respecto al avance planificado para la

fecha. En esta sección se indica el porcentaje de avance de las tareas con respecto a la planificación inicial].

3. Lista de tareas concluidas en el período reporta do [Indicar la lista de tareas concluidas en el período]

Responsable de las tareas: [Describa el nombre del responsable de la tarea]

ID Tarea Inicio previsto

Fin previsto

Inicio Real

Fin real

4. Lista de tareas atrasadas al momento del informe [Indicar la lista de tareas que se encuentran atrasadas con respecto a la planificación inicial]



Fin previsto

Inicio Real

Fin real

5. Lista de tareas por realizar según el proyecto [Indicar la lista de tareas por realizar según el proyecto]



Fin previsto Responsable

6. Asuntos críticos [Puntualice que asuntos críticos para el proyecto se presentaron durante el período, la forma en que impactó

o puede impactar el proyecto y qué medidas se tomaron o se deben tomar al respecto].

141



R E P O R T E D E A V A N C E D E L P R O Y E C T O N U T R I C I Ó N

142

1. Descripción

Este artefacto provee un mecanismo para administrar las expectativas de los

interesados a lo largo de todo el ciclo de vida del proyecto, al proporcionar

información sobre el reporte de tareas y el personal asignado a cada una de ellas,

así como el avance del mismo.

2. Resumen del estado actual El proyecto tiene un avance del 10 %.

3. Lista de tareas concluidas en el período reporta do Responsable de las tareas: Ing. Roy Céspedes G.


Fin previsto

Inicio Real Fin real

01 Revisión de código de los alimentos 02-02-2010 02-02-2010 02-02-2010 02-02-2010

4. Lista de tareas atrasadas al momento del informe Responsable de las tareas: [Describa el nombre del responsable de la tarea]


Fin previsto

Inicio Real

Fin real

5. Lista de tareas por realizar según el proyecto




02 Desarrollo de tabla en la base de datos 02-02-2010 02-02-2010 Ing. Roy Céspedes G.

6. Asuntos críticos 1. El tiempo de la técnica de Nutrición

143

8.9. Anexo n. o 9: Plan de Métricas

[Defina las métricas que serán recolectadas y calculadas para el control del proyecto, a fin de monitorear su

progreso. Las métricas permiten medir el desempeño del proyecto para establecer la aceptación del mismo.

Para facilitar su identificación, defina metas de administración en términos de calidad y progreso;

considerando lo que necesita ser medido para apoyar esas metas.]

1. Plantilla para una métrica

Código: [Indicar el consecutivo para la métrica del proyecto.] Nombre: [Describa el nombre de la métrica.]

Fecha Nombre de Proyecto [Describa la fecha de control.] [Anote el nombre del proyecto]

Definición de la métrica Anote el qué se va a medir y como se va medir.

Nombre del encargado de realizar la métrica Anote el nombre del encargado del proyecto

Cálculo de la métrica

Anote la operación para realizar el calculo y la forma de aplicarla

Resultado de la métrica

Porcentaje obtenido Medición de avance de la tarea Atrasos Anote el porcentaje del resultado de la métrica

Anote el avance de la tarea en términos de: • Bajo • Medio

• Alto

Anote los atrasos ocurridos en la realización de la tarea

144

Métrica

Métrica para evaluar digitación de alimentos

1. Plantilla para una métrica

Código: 01 Nombre: Métrica de digitación de alimentos

Fecha Nombre de Proyecto 02-02-2010 Nutrición

Definición de la métrica Métrica de digitación Ingresos de alimentos por hora

Nombre del encargado de realizar la métrica Ing. Roy Céspedes G.

Cálculo de la métrica

Suma de alimentos por hora 25 por hora 50 por hora 75 por hora

Resultado de la métrica

Porcentaje obtenido Medición de avance de la tarea Atrasos

51 % • Medio

Tiempo de la Técnica de Nutrición

145

8.10. Anexo n. o 10: Cronograma

Los cronogramas del proyecto son artefactos que contienen información referente

a las tareas, la secuencia de realización, la programación de la fecha de comienzo

y fecha de fin, el responsable o responsables asignados y necesidades para

completarlas.

Este documento se realiza con la herramienta Microsoft Project 2007. Adjuntar

cronograma al plan de desarrollo del software.

146

8.11. Anexo n. o 11: Lista de asuntos

La lista de asuntos son artefactos que contienen información referente a las

tareas, la secuencia de realización, la programación de la fecha de comienzo y

fecha de fin, el responsable o responsables asignados y la conclusión o no.

Este documento se realiza con la herramienta Work Flow Chart. Adjuntar la lista

de asuntos cada vez que se reúna el equipo para monitorear el avance del

proyecto.

147

8.12. Anexo n. o 12: Orden de trabajo

Orden de trabajo

Fecha Nombre de Proyecto [Describa la fecha.] [Anote el nombre del proyecto]



Descripción de la orden de trabajo Describir en forma clara, cual es el trabajo solicitado.

Nombre del responsable del trabajo Firma

Fecha de inicio del trabajo Responsable del trabajo [Describa la fecha.]

Describa el o los nombres de los responsables del cambio

Elaborado por: Describir quién elabora la orden de trabajo

Firma:

Aprobado por: Describir quién aprueba la orden de trabajo

Firma:

148

Orden de trabajo

Fecha Nombre de Proyecto 02-02-2010 Nutrición


Descripción de la orden de trabajo Revisar códigos de alimentos con más de cinco dígitos

Nombre del responsable del trabajo Firma Ing. Ry Céspedes G.

Fecha de inicio del trabajo Responsable del trabajo 02-02-2010 Ing. Roy Céspedes G.

Elaborado por: Ana María Jiménez

Firma:

Aprobado por: Armando Oporta

Firma:

149

8.13. Anexo n. o 13: Informe del estado del proyecto



I N F O R M E D E L E S T A D O D E L P R O Y E C T O < N O M B R E D E L P R O Y E C T O >

150

1. Descripción

Este artefacto provee un mecanismo para informar a los interesados sobre el

avance del proyecto en un período específico.

2. Resumen del estado actual [Describe el avance actual del proyecto con respecto al avance planificado para la fecha]

3. Lista de tareas concluidas [Indica la lista de tareas concluidas en el período]


Fin previsto

Inicio Real

Fin real

4. Lista de tareas atrasadas al momento del informe [Indica la lista de tareas que se encuentran atrasadas con respecto a la planificación inicial]


Fin previsto

Inicio Real

Fin real

5. Lista de tareas por realizar en el siguiente per íodo [Indica la lista de tareas que se planean realizar en el siguiente período]



6. Asuntos críticos [Muestra la lista de asuntos críticos para el proyecto que se presentaron durante el período, la forma en que

impactó o puede impactar en el proyecto y las medidas que se tomaron al respecto].

151



I N F O R M E D E L E S T A D O D E L P R O Y E C T O N U T R I C I Ó N

152

1. Descripción

Este artefacto provee un mecanismo para informar a los interesados sobre el

avance del proyecto en un período específico.

2. Resumen del estado actual Avance actual de un 10%

3. Lista de tareas concluidas


Fin previsto

Inicio Real

Fin real

01 Revisión de código de los alimentos 02-02-2010 02-02-2010 02-02-2010 02-02-2010

4. Lista de tareas atrasadas al momento del informe ID Tarea Inicio

previsto Fin

previsto Inicio Real

Fin real

5. Lista de tareas por realizar en el siguiente per íodo ID Tarea Inicio

previsto Fin

previsto Responsable

02 Desarrollo de tabla en la base de datos 02-02-2010 02-02-2010 Ing. Roy Céspedes G.

6. Asuntos críticos

153

8.14. Anexo nº 14. Plan del proyecto



P L A N D E L P R O Y E C T O < N O M B R E D E L P R O Y E C T O >

154



2. Descripción El Plan de Proyecto es un artefacto integral complejo que recoge toda la

información requerida para administrar la ejecución del proyecto. Este obtiene

información de los artefactos desarrollados al inicio del proyecto y es mantenido a

través del mismo, es decir itera varias veces a lo largo de la vida del proyecto.

3. Descripción del problema [Provee una declaración resumida del problema que será resuelto por este proyecto. En la redacción del

problema tome en cuenta lo siguientes elementos:

• Describa cuál es el problema

• Indique a quién afecta

• Explique el impacto del problema]

4. Resumen Ejecutivo [Anote los aspectos relevantes del proyecto, de modo que el lector pueda tener una idea general del

contenido del proyecto. Además, incluya un resumen del contenido de este documento y su propósito.]

5. Visión general del proyecto -Objetivo general

[Debe ser conciso y realista. Debe ser planteado de forma que se pueda verificar o medir su cumplimiento.]

-Objetivos específicos

[Defina éstos en términos de logros parciales que contribuirán al alcance del objetivo general. Deben ser

claros y verificables, (inicie con un verbo en infinitivo).]

155

Justificación

[Describa cómo la acción propuesta resuelve el problema o necesidad de los involucrados, y su contribución

para alcanzar los objetivos institucionales.]

Proyectos relacionados

[Enumere y describa los proyectos en ejecución o propuestos con los cuales este proyecto se relaciona.

Puede describir la relación en términos de entregas o del objetivo que persiguen.]

Alcance

[La definición del alcance comprende la suma de los productos y servicios que se van a proveer como parte

del proyecto y que son necesarios para cumplir su objetivo. Describa el alcance de acuerdo con los criterios

que se enumeran a continuación.]

Descripción general del producto o servicio

[Realice una descripción del producto o servicio que el proyecto debe generar. Refiérase a la naturaleza,

características, requerimientos y particularidades de los bienes o servicios que se desea producir con el

proyecto para la solución del problema o necesidad.]

Entregables

[Enumere los entregables del proyecto.]

Entregables del proyecto Descripción

1.

2.

Exclusiones

[Se refiere a los elementos que no se entregarán del proyecto.]

Restricciones

[Detalle la presencia de limitaciones para el proyecto (en caso de que existan) y que podrían afectar su

rendimiento, por ejemplo: tiempo disponible para su desarrollo, disponibilidad de información, limitaciones

técnicas o de recursos. Tome en cuenta que si se dispone de un presupuesto predefinido es muy probable que

limite las opciones del proyecto, en cuanto a su alcance y asignación de personal, entre otras.]

156

Supuestos

[Los supuestos son los factores que se consideran como verdaderos y ciertos, los cuales afectan todos los

aspectos de la misma y son parte de la elaboración progresiva del proyecto.]

Dependencias críticas o factores críticos para el é xito [Enumere las dependencias críticas para asegurar el éxito del proyecto. Estas pueden ser recursos

específicos en una fecha determinada, la instalación de un software, etc.]

Estimación de beneficios [Enumere los beneficios que se esperan alcanzar con la realización del proyecto.]

Roles y responsabilidades [Establezca la estructura organizacional de los principales participantes del proyecto. Consigne los roles y el

nombre de las personas involucradas directamente en el proyecto tanto en la fase previa como posterior a la

aprobación del Plan de Proyecto. Determine la responsabilidad que cada rol asumirá durante su

intervención.]

Rol Nombre Responsabilidades

•

•

•

Planificación del Proyecto

Recursos Materiales

[Realice una estimación de los recursos tanto materiales como de equipamiento y las cantidades necesarias

de cada uno para realizar las actividades del proyecto.

• Necesidad de equipos

• Necesidad de puntos de red

• Necesidad de software

• Necesidad de puntos eléctricos

157

• Necesidad de espacio físico en la oficina

• Necesidad de espacio físico en el lugar de trabajo

• Necesidad de capacitación especial. etc.]

Recursos humanos

[Identifique el personal requerido para el proyecto y su ámbito de participación en el mismo.]

Cant. Dependencia funcional Puesto Ámbito de participación

Glosario de términos

El glosario define términos importantes para el proyecto, los cuales pueden ser poco conocidos, difíciles

de interpretar o no se utilizan con frecuencia.

Definiciones [Los términos definidos aquí forman la sustancia esencial del documento. En orden alfabético.]

Término Definición

<nombre del término> <definición del término>






158



P L A N D E L P R O Y E C T O N U T R I C I Ó N

159



2. Descripción El Plan de Proyecto es un artefacto integral complejo que recoge toda la

información requerida para administrar la ejecución del proyecto. Este obtiene

información de los artefactos desarrollados al inicio del proyecto y es mantenido a

través del mismo, es decir itera varias veces a lo largo de la vida del proyecto.

3. Descripción del problema [Provee una declaración resumida del problema que será resuelto por este proyecto. En la redacción del

problema tome en cuenta lo siguientes elementos:

• Sistema actual de programación de menús obsoleto

• Funcionarios de Nutrición, Funcionarios de Salón y Pacientes hospitalizados

• Por su obsolescencia el programa Nut 2000 puede dejar de funcionar

4. Resumen Ejecutivo Se requiere reemplazar el sistema Nut 2000, por un sistema en ambiente grafico y que interactúa con la red

del hospital

5. Visión general del proyecto -Objetivo general

-Objetivos específicos

Objetivo general Implementar el sistema de programación de menús

160

Justificación Proyectos relacionados

Nut 2000 en modo carácter hecho por Oficinas Centrales

Alcance

Programación de alimentos

Descripción general del producto o servicio

Mantenimiento de los alimentos del menú

Entregables

Entregables del proyecto Descripción

1. Modulo de control de alimentos

2.

Exclusiones

Excluye el proceso de recetas

Restricciones Supuestos

1. Contar con el tiempo de la Técnica en Nutrición

Objetivos específicos 1. Realizar diagnóstico de necesidades para la implementación del expediente electrónico en las

unidades seleccionadas. 2. Gestión de la infraestructura física necesaria 3. Realizar la instalación y puesta del software en los equipos de cómputo. 4. Sensibilizar al personal directivo y personal médico operativo, en cuanto a la necesidad de la

implementación del sistema para simplificar procesos, ahorro de tiempo de todo el personal involucrado y ahorro en papelería, mejorando la calidad de los datos y la disponibilidad de la información, para garantizar una mejor calidad.

5. Capacitación al personal operativo para la utilización práctica y adecuada del expediente electrónico.

6. Supervisar la utilización del sistema y el funcionamiento adecuado por medio de visitas periódicas.

161

Dependencias críticas o factores críticos para el é xito 2. Asignar la Técnica a tiempo completo para el proyecto

Estimación de beneficios El control de alimentos para el menú diario

Roles y responsabilidades

Rol Nombre Responsabilidades

Analista programador Ing. Roy Céspedes G. • Encargado del proyecto

Planificación del Proyecto

Recursos Materiales

• Equipo de computo

• Dos puntos de red

• Dos puntos eléctricos

Recursos humanos

Cant. Dependencia funcional Puesto Ámbito de participación

1 Nutrición Técnico Usuario experto

Glosario de términos

El glosario define términos importantes para el proyecto, los cuales pueden ser poco conocidos, difíciles de interpretar o no se utilizan con frecuencia. Definiciones [Los términos definidos aquí forman la sustancia esencial del documento. En orden alfabético.]

Término Definición




162

8.15. Anexo n. o 15: Estructura detallada de trabajo

La estructura detallada de trabajo es exhaustiva, jerárquica y descendente

formada por los entregables a realizar en un proyecto. La EDT es una herramienta

muy común y crítica en la gestión de proyectos y sirve como base para la

planificación del proyecto.

Este documento se realiza con la herramienta Work Flow Chart. Adjuntar la EDT

al plan de desarrollo del proyecto.

163

8.16. Anexo n. o 16: Plantilla para recopilar requerimientos



R E Q U E R I M I E N T O S D E L P R O Y E C T O < N O M B R E D E L P R O Y E C T O >

164



2. Descripción La plantilla de requerimientos describe la situación actual del problema a

solucionar, los usuarios del sistema, el listado de necesidades y la documentación

de los requerimientos.

Listado de requerimientos

Nombre de Proyecto [Anote el nombre del proyecto]

Descripción del problema

[Desarrolle una declaración resumida del problema que será resuelto. Tome en cuenta los siguientes elementos: • Describa cuál es el problema • Indique a quién afecta • Explique el impacto del problema]

Posicionamiento del producto

[Desarrolle una declaración de la posición única que el producto pretende llenar. Utilice el siguiente formato: Breve descripción del producto Indique los beneficios Describa, si la hay, diferencias con el sistema actual (sea manual a automático)] [La declaración de posicionamiento del producto comunica el intento de una aplicación y la importancia del proyecto a todo el personal interesado.]

Afectados [Describa los afectados o stakeholders, con un interés en el desarrollo del proyecto(no son usuarios directos del proyecto] Nombre Que hacen en el sistema Responsabilidades

[Resuma las principales responsabilidades del afectado con respecto al sistema. Por ejemplo, este afectado:

165

-asegura que el sistema será mantenible -asegura que habrá una demanda de mercado para las características del producto -monitorea el progreso del proyecto -aprueba el financiamiento

Usuarios [Presente una lista resumen de todos los usuarios identificados.]

Nombre Que hacen en el sistema Responsabilidades

[Resuma las principales responsabilidades del afectado con respecto al sistema. Por ejemplo: -captura detalles -produce reportes -coordina el trabajo

Necesidades clave de afectados o usuarios [Liste las principales necesidades y soluciones, cómo son percibidas por el afectado/usuarios.] Usuario Necesidad Solución actual Solución propuesta

¿Cuáles son las razones para este problema?

¿Cómo se resuelve actualmente?

¿Qué soluciones desea el afectado o usuario?]

Ambiente del trabajo del usuario

[Detalle el ambiente de trabajo del usuario. Ejemplo: • Plataformas de sistemas: ¿Cuáles plataformas de sistemas se utilizan actualmente? ¿Futuras plataformas? • Integración de aplicaciones: ¿Qué otras aplicaciones están en uso? ¿Su aplicación necesita integrarse con ellas?]

Código Descripción de requerimientos Responsable del requerimiento Describa el código del requerimiento

• XXX

Describa el nombre del requerimiento

• XXXXXXx

Describa el nombre del responsable XXXXX

Cambios en los requerimientos [Describa como serán administrados los cambios en los requerimientos del proyecto]

166



R E Q U E R I M I E N T O S D E L P R O Y E C T O N U T R I C I Ó N

167



2. Descripción La plantilla de requerimientos describe la situación actual del problema a

solucionar, los usuarios del sistema, el listado de necesidades y la documentación

de los requerimientos.

Listado de requerimientos

Nombre de Proyecto Nutrición

Descripción del problema

• Reemplazar sistema en modo carácter • Nutrición, Enfermería, Pacientes

Posicionamiento del producto

[Desarrolle una declaración de la posición única que el producto pretende llenar. Utilice el siguiente formato: Control de los alimentos Sistema en línea El sistema actual trabaja en un máquina con Windows 2000, el nuevo sistema trabajo en ambiente grafico

Afectados


Enfermería

Alimentar el cardex Mantenimiento de cardex

Usuarios

168


Necesidades clave de afectados o usuarios

Usuario Necesidad Solución actual Solución propuesta

Nutrición Temor de perder el sistema actauk

Sistema en Windows 98

Actualizar el sistema

Ambiente del trabajo del usuario

[Detalle el ambiente de trabajo del usuario. Ejemplo: • Plataformas de sistemas: Windows 98 • Integración de aplicaciones: Admisión, Emergencias

Código Descripción de requerimientos Responsable del requerimiento • Nut01

• Código de alimentos Ing. Roy Céspedes G.

Cambios en los requerimientos

169

8.17. Anexo n. o 17: Gestión de riesgos



G E S T I Ó N D E R I E S G O S D E L P R O Y E C T O < N O M B R E D E L P R O Y E C T O >

170



2. Descripción Un riesgo es un evento o condición de incertidumbre, al ocurrir puede provocar un

efecto negativo o positivo en al menos uno de los objetivos del proyecto. El riesgo

presenta dos elementos primarios, la probabilidad y el impacto. Un riesgo puede

tener una o más causas, si hay una probabilidad de ocurrencia, tendrá uno o más

impactos o efectos.

3. Probabilidad Probabilidad Puntaje

Muy Probable 0.9

Bastante Probable 0.7

Probable 0.5

Poco probable 0.3

Muy poco probable 0.1

La probabilidad que el riesgo se dé en el proyecto, debe ser medida y otorgarle un

puntaje para la atención inmediata y programar las soluciones a implementar en el

caso de ocurrir el riesgo.

4. Impacto Impacto Puntaje

Muy Alto 0.8

Alto 0.4

Moderado 0.2

Bajo 0.1

Muy Bajo 0.05

171

El impacto mide cuan perjudicial para el proyecto puede ser el riesgo si llegará a

presentarse.

5. Riesgo

Alto 0.99 – 0.18

Moderado 0.17 – 0.05

Bajo 0.04 – 0.01

El riesgo del proyecto proporciona una medida la cual informa como se debe tratar

el proyecto y el impacto de los riesgos detectados.

6. Nomenclatura de riesgos

Código Descripción

RA Riesgos administrativos de proyectos

RE Riesgos externos

RO Riesgos organizacional

RT Riesgo técnico

RS Riesgo en la salud

RC Riesgo del cliente

RCA Riesgo en calidad

Con la nomenclatura de riesgos se originan los códigos que identifican a cada uno

de los riesgos del proyecto. La lista de la nomenclatura se puede actualizar al

encontrar otros riesgos que afectan el proyecto.

172

7. Evaluación del impacto de un riesgo en los objet ivos principales del proyecto

Evaluación del impacto de un riesgo en los objetivo s principales del proyecto

(Escala ordinal o cardinal, escala no lineal)

Objetivo del proyecto

Muy Bajo 0,05

Bajo 0,1 Moderado 0,2

Alto 0,4 Muy Alto 0,8

Calendario

Insignificante variación del calendario

Variación del calendario < 5%

Desviación general del Proyecto 5 – 10 %


Desviación general del Proyecto >10 – 20 %

Alcance

Reducción del alcance apenas perceptible

Áreas menores del alcance son afectadas

Áreas mayores del alcance son afectadas

Reducción del alcance inaceptable para el cliente

El producto final del proyecto es inservible

Calidad

Degradación de la calidad apenas perceptible

Solo aplicaciones muy específicas son afectadas

La reducción de la calidad demanda la aprobación del cliente

Reducción de la calidad inaceptable para el cliente


8. Pasos para administrar los riesgos 1. Identificación de riesgos

• Anotar un código para cada uno de los riesgos identificados, utilizando

como ejemplo la lista de nomenclatura de riesgos con un número

consecutivo en la matriz de riesgos de la hoja electrónica.

• Describir con una lista de riesgos cuales pueden afectar la planificación

del proyecto y anote en la matriz de riesgos de la hoja electrónica la

descripción del riesgo.

Realice las siguientes preguntas para la comprensión del proyecto

¿Cuál es el alcance del proyecto?

¿Cuáles son los entregables requeridos?

¿Cuáles son sus objetivos y prioridades?

2. Posible causa del riesgo

173

• Anote en la matriz de riesgos de la hoja electrónica la causa probable

para que el riesgo se ejecute.

3. Análisis de riesgos identificados.

• Medición de la probabilidad: con la tabla de probabilidad mida el riesgo y

digite el resultado en la columna de probabilidad de la matriz de riesgos

de la hoja electrónica.

• Medición del impacto: con la tabla de impacto mida el riesgo y digite el

resultado en la columna de impacto de la matriz de riesgos de la hoja

electrónica.

4. Ordene de mayor a menor en la matriz de riesgos de la hoja electrónica, el

resultado de la sumatoria entre la cantidad de la probabilidad y la cantidad

del impacto de cada riesgo identificado.

5. Obtenga el promedio de la columna de rango de la matriz de riesgos de la

hoja electrónica. Mida el riesgo del proyecto con la tabla de riesgos antes

dada.

6. Identifique una estrategia y accionar preventivo a cada riesgo identificado

(eliminar, transferir, mitigar o aceptar el riesgo), se deben incluir en la matriz

de riesgos de la hoja electrónica.

7. Contingencia y respaldo para que al presentarse el riesgo se adopten las

medidas dispuestas y ya sea prevenir el riesgo o minimizar el impacto que

pueda afectar el proyecto, se deben incluir en la matriz de riesgos de la

hoja electrónica.

8. Identificar en la matriz de riesgos de la hoja electrónica los disparadores

que indican cuando un riesgo está a punto de empezar o ya empezó a

afectar el proyecto.

9. Anotar en la matriz de riesgos de la hoja electrónica el nombre del

responsable de la supervisión de cada riesgo.

10. En la columna de la fecha de la matriz de riesgos de la hoja electrónica,

digite la fecha si se activo el disparador.

174

Se recomienda la supervisión periódica del plan de gestión de riesgos.

175



G E S T I Ó N D E R I E S G O S D E L P R O Y E C T O N U T R I C I Ó N

176



2. Descripción Un riesgo es un evento o condición de incertidumbre, al ocurrir puede provocar un

efecto negativo o positivo en al menos uno de los objetivos del proyecto. El riesgo

presenta dos elementos primarios, la probabilidad y el impacto. Un riesgo puede

tener una o más causas, si hay una probabilidad de ocurrencia, tendrá uno o más

impactos o efectos.

3. Probabilidad Probabilidad Puntaje

Muy Probable 0.9

Bastante Probable 0.7

Probable 0.5

Poco probable 0.3

Muy poco probable 0.1

La probabilidad que el riesgo se dé en el proyecto, debe ser medida y otorgarle un

puntaje para la atención inmediata y programar las soluciones a implementar en el

caso de ocurrir el riesgo.

4. Impacto Impacto Puntaje

Muy Alto 0.8

Alto 0.4

Moderado 0.2

Bajo 0.1

177

Muy Bajo 0.05

El impacto mide cuan perjudicial para el proyecto puede ser el riesgo si llegará a

presentarse.

5. Riesgo

Alto 0.99 – 0.18

Moderado 0.17 – 0.05

Bajo 0.04 – 0.01

El riesgo del proyecto proporciona una medida la cual informa como se debe tratar

el proyecto y el impacto de los riesgos detectados.

6. Nomenclatura de riesgos

Código Descripción

RA Riesgos administrativos de proyectos

RE Riesgos externos

RO Riesgos organizacional

RT Riesgo técnico

RS Riesgo en la salud

RC Riesgo del cliente

RCA Riesgo en calidad

Con la nomenclatura de riesgos se originan los códigos que identifican a cada uno

de los riesgos del proyecto. La lista de la nomenclatura se puede actualizar al

encontrar otros riesgos que afectan el proyecto.

178

7. Evaluación del impacto de un riesgo en los objetivo s principales del proyecto

Evaluación del impacto de un riesgo en los objetivo s principales del proyecto

(Escala ordinal o cardinal, escala no lineal)

Objetivo del proyecto

Muy Bajo 0,05 Bajo 0,1 Moderado 0,2

Alto 0,4 Muy Alto 0,8

Calendario

Insignificante variación del calendario

Variación del calendario < 5%



Desviación general del Proyecto >10 – 20 %

Alcance

Reducción del alcance apenas perceptible

Áreas menores del alcance son afectadas

Áreas mayores del alcance son afectadas

Reducción del alcance inaceptable para el cliente


Calidad

Degradación de la calidad apenas perceptible

Solo aplicaciones muy específicas son afectadas

La reducción de la calidad demanda la aprobación del cliente

Reducción de la calidad inaceptable para el cliente


8. Pasos para administrar los riesgos

• Identificación de riesgos

• Anotar un código para cada uno de los riesgos identificados, utilizando

como ejemplo la lista de nomenclatura de riesgos con un número

consecutivo en la matriz de riesgos de la hoja electrónica.

• Describir con una lista de riesgos cuales pueden afectar la planificación

del proyecto y anote en la matriz de riesgos de la hoja electrónica la

descripción del riesgo.

Realice las siguientes preguntas para la comprensión del proyecto

¿Cuál es el alcance del proyecto?

¿Cuáles son los entregables requeridos?

¿Cuáles son sus objetivos y prioridades?

• Posible causa del riesgo

179

• Anote en la matriz de riesgos de la hoja electrónica la causa probable

para que el riesgo se ejecute.

• Análisis de riesgos identificados.

• Medición de la probabilidad: con la tabla de probabilidad mida el riesgo y

digite el resultado en la columna de probabilidad de la matriz de riesgos

de la hoja electrónica.

• Medición del impacto: con la tabla de impacto mida el riesgo y digite el

resultado en la columna de impacto de la matriz de riesgos de la hoja

electrónica.

• Ordene de mayor a menor en la matriz de riesgos de la hoja electrónica, el

resultado de la sumatoria entre la cantidad de la probabilidad y la cantidad

del impacto de cada riesgo identificado.

• Obtenga el promedio de la columna de rango de la matriz de riesgos de la

hoja electrónica. Mida el riesgo del proyecto con la tabla de riesgos antes

dada.

• Identifique una estrategia y accionar preventivo a cada riesgo identificado

(eliminar, transferir, mitigar o aceptar el riesgo), se deben incluir en la matriz

de riesgos de la hoja electrónica.

• Contingencia y respaldo para que al presentarse el riesgo se adopten las

medidas dispuestas y ya sea prevenir el riesgo o minimizar el impacto que

pueda afectar el proyecto, se deben incluir en la matriz de riesgos de la hoja

electrónica.

• Identificar en la matriz de riesgos de la hoja electrónica los disparadores

que indican cuando un riesgo está a punto de empezar o ya empezó a

afectar el proyecto.

• Anotar en la matriz de riesgos de la hoja electrónica el nombre del

responsable de la supervisión de cada riesgo.

• En la columna de la fecha de la matriz de riesgos de la hoja electrónica,

digite la fecha si se activo el disparador.

180

8.18. Anexo n. o 18: Gestión de comunicación



G E S T I Ó N D E C O M U N I C A C I Ó N D E L P R O Y E C T O < N O M B R E D E L P R O Y E C T O >

181



2. Descripción La gestión de comunicación tiene el objetivo de establecer los canales de

comunicación lo más sencillos y eficaces posible. La meta de la gestión de

comunicación es proveer contenidos claros, completos y que se informe a los

interesados de manera rápida y segura.

La información debe fluir entre el equipo del proyecto – jefe de proyecto, entre el

jefe de proyecto – usuario, entre el cliente – gerente, sin distingo entre los

diferentes participantes del proyecto.

3. Involucrados Definir cuáles son los involucrados. (Son todos los que intervienen en el desarrollo

y gestión del proyecto.)

4. Distribución de la información Describa para cada involucrado la mejor manera para enviar la comunicación

5. Vía de comunicación

• Comunicación ascendente: la comunicación fluye desde los subordinados a

los niveles organizativos superiores.

182

• Comunicación cruzada: está comunicación es cruzada, es decir incluye el

flujo de información horizontal entre involucrados del proyecto de niveles

iguales de la organización.

• Comunicación descendente: la comunicación fluye de los niveles superiores

de la organización a los niveles inferiores de la organización.

6. Completar la matriz de comunicación Desarrollar el plan de comunicación llenando la siguiente matriz

Mensaje Emisor Medio Frecuencia Receptor Respuesta Fecha

¿Qué se comunica?

¿Quién Comunica?

¿Cómo se Comunica? Electrónico Informe gerencia Informe trabajo Actas Minutas

¿Cuándo se Comunica? Mensual Semanal Trimestral Anual

¿A quién se comunica?

¿Cómo se retroalimenta? Fecha de envio

183



G E S T I Ó N D E C O M U N I C A C I Ó N D E L P R O Y E C T O N U T R I C I Ó N

184



2. Descripción La gestión de comunicación tiene el objetivo de establecer los canales de

comunicación lo más sencillos y eficaces posible. La meta de la gestión de

comunicación es proveer contenidos claros, completos y que se informe a los

interesados de manera rápida y segura.

La información debe fluir entre el equipo del proyecto – jefe de proyecto, entre el

jefe de proyecto – usuario, entre el cliente – gerente, sin distingo entre los

diferentes participantes del proyecto.

3. Involucrados Jefatura de Nutrición

Técnica de Nutrición

Jefatura UTIC

Analista encargado del proyecto

4. Distribución de la información Jefatura de Nutrición por notas

Técnica de Nutrición por notas y correo electrónico

Jefatura UTIC notas y correo electrónico

Analista encargado del proyecto notas y correo electrónico

185

5. Vía de comunicación

• Comunicación ascendente: la comunicación fluye desde los subordinados a

los niveles organizativos superiores.

• Comunicación cruzada: está comunicación es cruzada, es decir incluye el

flujo de información horizontal entre involucrados del proyecto de niveles

iguales de la organización.

• Comunicación descendente: la comunicación fluye de los niveles superiores

de la organización a los niveles inferiores de la organización.

6. Completar la matriz de comunicación Desarrollar el plan de comunicación llenando la siguiente matriz

Mensaje Emisor Medio Frecuencia Receptor Respuesta Fecha

Avance Encargado del proyecto

Electrónico

Mensual

Técnica Nutrición Correo electrónico 02-02-2010

186

8.19. Anexo n. o 19: Documento de arquitectura de software



D O C U M E N T O D E A R Q U I T E C T U R A D E S O F T W A R E D E L P R O Y E C T O < N O M B R E D E L P R O Y E C T O >

187



2. Descripción

La arquitectura de software permite representar la estructura del sistema, sirviendo

de comunicación entre las personas involucradas en el desarrollo y ayudando a

realizar diversos análisis que orienten el proceso de toma de decisiones.

3. Metas del sistema [La meta principal de la arquitectura del sistema es mostrar los aspectos principales que influirán en la

etapa de desarrollo.]

4. Metas

Ejemplos:

El Sistema XXX permitirá a los usuarios acceder al sistema desde cualquier terminal del hospital.

Para poder acceder al Sistema XXX, se requiere de un código de usuario válido así como de una contraseña. Además, dependiendo del perfil del usuario se deshabilitarán opciones de manejo del Sistema para proteger información confidencial.

5. Restricciones del Sistema Ejemplo:

Necesariamente el sistema usará como motor de Base de Datos Structure query language. Siendo necesario la elaboración de una copia de rescate de las tablas para no afectar la información almacenada antes de poner en total funcionamiento al sistema.

188

Las computadoras que brindarán el servicio cliente del sistema no deberán de presentar potencias menores a las brindadas por una Pentium 4, con al menos 512 MB de RAM y 200 MB de espacio en el disco, con un Sistema Operativo Windows.

6. Vista lógica [Muestra una representación gráfica y la descripción de las capas que componen el sistema y la relación que

existe entre las mismas. Soporta requerimientos funcionales descompuestos en abstracciones.]

7. Vista de casos de uso

[Es la representación gráfica y la descripción de los diagramas de casos de uso. Representa la forma de cómo un cliente opera con el sistema en desarrollo, además de la forma tipo y orden de los elementos que interactúan y así obtener el conjunto de escenarios que contendrá cada iteración.

Cada caso de uso tiene una descripción que especifica la funcionalidad que se incorporará al sistema propuesto.

En este apartado se mostraran los casos de uso más significativos del Sistema. ]

8. Vista de procesos

[Es el diagrama principal para el análisis y diseño. En este diagrama se presentan las clases del sistema con sus relaciones estructurales y de herencia. Para establecer las clases, objetos atributos y operaciones entre clases se tomó como base a los diagramas de casos de uso. ]

9. Tamaño y performance La arquitectura de software elegida apoya los requisitos dominantes de capacidad

en disco y latencia.

10. Tiempo de respuesta en el acceso a la Base de D atos

El sistema proveerá accesos a la base de datos con un tiempo de respuesta no

mayor a los XX segundos.

11. Tiempo de respuesta de transacciones

189

El programa no demorará más de XX minutos en generar una distribución óptima

para los cortes haciendo uso del algoritmo elegido y guardándolo en base de

datos.

12. Espacio en disco para el cliente

El espacio en disco necesario para la parte del cliente deberá tener como mínimo

XXX MB de espacio libre para su correcto funcionamiento, esto incluye tanto el

tamaño del software como el XXXXXXXX.

13. Espacio en disco para el servidor de Base de da tos

El espacio en disco necesario para la parte del Servidor de Base de datos deberá

tener como mínimo XX GB libres en disco para su correcto funcionamiento.

La arquitectura seleccionada apoya los requisitos de latencia y capacidad en disco

en la puesta en práctica de una arquitectura cliente servidor. La porción del cliente

solo se pone en ejecución en las PC locales de los distintos ambientes dentro del

hospital. Los componentes se han diseñado para asegurarse de obtener requisitos

mínimos de disco y memoria en el lado de las PC del cliente.

14. Usabilidad

El sistema permitirá un manejo intuitivo por parte de los usuarios.

15. Eficiencia

El programa no demorará más de XX minutos en generar una distribución óptima

para los cortes haciendo uso del algoritmo elegido.

16. Seguridad

El sistema permitirá el acceso a funcionalidades dependiendo del perfil del usuario

que ingresa al sistema, validando su ingreso a través de una clave.

190

17. Confiabilidad

El sistema tendrá en cuenta que la información ingresada en él sea válida, para lo

cual mostrará mensajes que expliquen al usuario acerca de los errores que éste

pudiera cometer y de aquellos que pueda cometer el mismo sistema.

18. Mantenimiento

El sistema será flexible, facilitando su mantenimiento futuro.

19. Estándares:

Se usará un estándar para todas las ventanas e interfaces con el usuario que

tenga el Sistema XXXXXX, así como los nombres, códigos, etc.

191



D O C U M E N T O D E A R Q U I T E C T U R A D E S O F T W A R E D E L P R O Y E C T O N U T R I C I Ó N

192



2. Descripción

La arquitectura de software permite representar la estructura del sistema, sirviendo

de comunicación entre las personas involucradas en el desarrollo y ayudando a

realizar diversos análisis que orienten el proceso de toma de decisiones.

3. Metas del sistema

Sistema desarrollado en ambiente gráfico

4. Metas El Sistema XXX permitirá a los usuarios acceder al sistema desde cualquier terminal del hospital.

Para poder acceder al Sistema Nutrición, se requiere de un código de usuario válido así como de una contraseña. Además, dependiendo del perfil del usuario se deshabilitarán opciones de manejo del Sistema para proteger información confidencial.

5. Restricciones del Sistema Necesariamente el sistema usará como motor de Base de Datos Structure query language. Siendo necesario la elaboración de una copia de rescate de las tablas para no afectar la información almacenada antes de poner en total funcionamiento al sistema.

Las computadoras que brindarán el servicio cliente del sistema no deberán de presentar potencias menores a las brindadas por una Pentium 4, con al menos 512 MB de RAM y 200 MB de espacio en el disco, con un Sistema Operativo Windows.

6. Vista de casos de uso

7. Vista de procesos

193

8. Tamaño y performance

La arquitectura de software elegida apoya los requisitos dominantes de capacidad

en disco y latencia.

10. Tiempo de respuesta en el acceso a la Base de D atos

El sistema proveerá accesos a la base de datos con un tiempo de respuesta no

mayor a los 03 segundos.

11. Tiempo de respuesta de transacciones

El programa no demorará más de 01 minutos en generar una distribución óptima

para los cortes haciendo uso del algoritmo elegido y guardándolo en base de

datos.

12. Espacio en disco para el cliente

El espacio en disco necesario para la parte del cliente deberá tener como mínimo

500 MB de espacio libre para su correcto funcionamiento.

13. Espacio en disco para el servidor de Base de da tos

El espacio en disco necesario para la parte del Servidor de Base de datos deberá

tener como mínimo 146 GB libres en disco para su correcto funcionamiento.

La arquitectura seleccionada apoya los requisitos de latencia y capacidad en disco

en la puesta en práctica de una arquitectura cliente servidor. La porción del cliente

solo se pone en ejecución en las PC locales de los distintos ambientes dentro del

hospital. Los componentes se han diseñado para asegurarse de obtener requisitos

mínimos de disco y memoria en el lado de las PC del cliente.

14. Usabilidad

El sistema permitirá un manejo intuitivo por parte de los usuarios.

194

15. Eficiencia

El programa no demorará más de 01 minutos en generar una distribución óptima

para los cortes haciendo uso del algoritmo elegido.

16. Seguridad

El sistema permitirá el acceso a funcionalidades dependiendo del perfil del usuario

que ingresa al sistema, validando su ingreso a través de una clave.

17. Confiabilidad

El sistema tendrá en cuenta que la información ingresada en él sea válida, para lo

cual mostrará mensajes que expliquen al usuario acerca de los errores que éste

pudiera cometer y de aquellos que pueda cometer el mismo sistema.

18. Mantenimiento

El sistema será flexible, facilitando su mantenimiento futuro.

19. Estándares:

Se usará un estándar para todas las ventanas e interfaces con el usuario que

tenga el Sistema Nutrición, así como los nombres, códigos, etc.

195

8.20. Anexo n. o 20: Plantilla de caso de uso



P L A N T I L L A C A S O D E U S O D E L P R O Y E C T O < N O M B R E D E L P R O Y E C T O >

196



2. Descripción Los Casos de Uso no son parte del diseño (cómo), sino parte del análisis (qué),

ayudan a describir qué es lo que el sistema debe hacer. Los Casos de Uso es ver

la funcionalidad del sistema desde el punto de vista del usuario, cual es el uso del

sistema y cómo este interactúa con el usuario.

Caso de uso

Nombre del caso de uso

[Anote el nombre del caso de uso]

Autor [Anote el nombre del creador del caso de uso]

Fecha [Anote la fecha de creación del caso de uso]

Descripción Describa lo que realizara el caso de uso

Actores Un actor es una persona u otra entidad externa al sistema de software, o quien actúa recíprocamente con el sistema y realiza el caso de uso para lograr las tareas. Describa al actor o actores que participarán en completar el caso de uso.

Precondiciones Liste cualquier actividad que debe ocurrir, o cualquier condición verdadera, antes de que el caso de uso pueda ser comenzado. Numere cada condición previa. Ejemplos: 1. La identidad del Usuario ha sido autenticada.

Flujo normal Proporcione una descripción detallada de las acciones del usuario y las respuestas del sistema que ocurrirán durante la ejecución del caso de uso en las condiciones normales esperadas. Esta descripción puede ser escrita como una respuesta a la pregunta hipotética, ¿Cómo logro la tarea indicada del caso de uso?

Flujo alternativo Documente otro escenario legítimo que pueden ocurrir dentro de este caso de uso.

Post-condiciones [Liste todos los estados posibles en que el sistema puede estar inmediatamente después de que un caso de uso ha

finalizado.]Ejemplos: 1 El Precio de artículo en la base de datos ha sido puesto al día con el valor nuevo.

197



P L A N T I L L A C A S O D E U S O D E L P R O Y E C T O N U T R I C I Ó N

198



2. Descripción Los Casos de Uso no son parte del diseño (cómo), sino parte del análisis (qué),

ayudan a describir qué es lo que el sistema debe hacer. Los Casos de Uso es ver

la funcionalidad del sistema desde el punto de vista del usuario, cual es el uso del

sistema y cómo este interactúa con el usuario.

Caso de uso

Nombre del caso de uso

CU 1 Mantenimiento de ingredientes

Autor Ing. Roy Céspedes G.

Fecha 02-02-2010

Descripción Implica las altas, bajas y cambios de los alimentos

Actores Digitador de nutrición

Precondiciones 1. La identidad del Usuario ha sido autenticada.

Flujo normal 1. El actor se loguea del digitador, 2. El usuario hace click en el botón de aceptación 3. El sistema verifica que el usuario se encuentre como usuario activo dentro del sistema 4. El caso de uso finaliza

Flujo alternativo

Post-condiciones No aplica

199

8.21. Anexo n. o 21: Documento de diseño técnico del software



D O C U M E N T O D E D I S E Ñ O T É C N I C O D E L S O F T W A R E D E L P R O Y E C T O N U T R I C I Ó N

200



2. Descripción La elaboración del manual técnico, tiene como fin inmediato que el documento

explique en forma ordenada y secuencial las herramientas específicas a personal

especializado que opere un sistema, programa o aplicación, describiendo en forma

clara y precisa los términos, vocablos y denominaciones así como las indicaciones

a seguir por este personal para su operación.

3. Presentación: Breve descripción general del manual.

4. Antecedentes: Describir las razones principales que propician la elaboración del sistema.

5. Objetivos del Sistema: Describir los puntos importantes que cubrirá el sistema.

6. Introducción: Describir el porqué de la existencia del Sistema.

A quién está dirigido este manual. Tipo de usuario a quien se dirige la información.

Manual técnico

Nombre del sistema Versión del sistema Fecha de elaboración [Anote el nombre del creador del caso de uso]

[Anote la versión] [Anote la fecha de creación]

201

7. Diagrama conceptual del sistema.

• Diagrama funcional por modulo: Representar gráficamente la forma en que funciona el sistema, con sus diferentes conexiones, acompañada de una breve explicación.

• Diccionario de Datos: Descripción de todos los objetos y elementos de la aplicación o sistema.

• Estructura de la base de datos o archivos utilizados en la aplicación: Descripción detallada de cada archivo / estructura de la base de datos.

• Diagrama Entidad Relación: Representar gráficamente la unión de las entidades por la relación del modelo del modulo, con sus diferentes conexiones.

• Requerimientos de hardware: Especificar todos los requerimientos de hardware que sean necesarios para el óptimo funcionamiento del sistema.

• Requerimientos de software: Especificar todos los requerimientos de software que sean necesarios para el uso del sistema.

• Ruta de ubicación: En caso de que sea necesario poner la ruta donde se encuentra ubicado el sistema ya sea localmente o que este concentrado en un servidor.

• Configuración: En caso de ser necesario poner los pasos requeridos que se llevan a cabo para su configuración.

• Instaladores: Describir los tipos de instaladores con los que cuenta el sistema.

• Instructivos de instalación y puesta a punto: Describir las diferentes formas de instalación con las que cuenta el sistema especificando detalladamente los pasos a seguir.

8. Manejo de errores

• Tabla de errores: En esta sección se presentara una lista con los posibles errores que maneja el sistema, seguido de una posible solución.

• Contingencias y soporte: Se incluirá en el manual una lista de las personas a las cuales el usuario puede solicitar apoyo en caso de que el sistema presente algún problema.

9. Glosario de términos: Lista con el significado de los términos, conceptos o tecnicismos, usados en este manual y que no son del dominio público.

202



D O C U M E N T O D E D I S E Ñ O T É C N I C O D E L S O F T W A R E D E L P R O Y E C T O N U T R I C I Ó N

203



2. Descripción La elaboración del manual técnico, tiene como fin inmediato que el documento

explique en forma ordenada y secuencial las herramientas específicas a personal

especializado que opere un sistema, programa o aplicación, describiendo en forma

clara y precisa los términos, vocablos y denominaciones así como las indicaciones

a seguir por este personal para su operación.

3. Presentación: Manual técnico del sistema de <nutrición

4. Antecedentes: • Sistema obsoleto del Programación de menú

5. Objetivos del Sistema: -Realizar diagnóstico de necesidades para la implementación del expediente electrónico en las unidades seleccionadas.

-Gestión de la infraestructura física necesaria

-Realizar la instalación y puesta del software en los equipos de cómputo.

-Sensibilizar al personal directivo y personal médico operativo, en cuanto a la necesidad de la implementación del sistema para simplificar procesos, ahorro de tiempo de todo el personal

Manual técnico

Nombre del sistema Versión del sistema Fecha de elaboración SISNUT 1.0 02-02-2010

204

involucrado y ahorro en papelería, mejorando la calidad de los datos y la disponibilidad de la información, para garantizar una mejor calidad.

-Capacitación al personal operativo para la utilización práctica y adecuada del expediente electrónico.

-Supervisar la utilización del sistema y el funcionamiento adecuado por medio de visitas periódicas.

6. Introducción: Usuarios técnicos

7. Diagrama conceptual del sistema.

• Diagrama funcional por modulo: • Diccionario de Datos:

• Estructura de la base de datos o archivos utilizados en la aplicación:

• Diagrama Entidad Relación:

• Requerimientos de hardware:

• Requerimientos de software:

Windows xp

• Ruta de ubicación:

• Configuración: Instalar punto bat

• Instaladores: Instalar los libs

• Instructivos de instalación y puesta a punto:

8. Manejo de errores

• Tabla de errores:

• Contingencias y soporte:

9. Glosario de términos:

205

8.22. Anexo n. o 22: Documento para casos de pruebas



D O C U M E N T O P A R A C A S O D E P R U E B A D E L P R O Y E C T O < N O M B R E D E L P R O Y E C T O >

206



2. Descripción Los casos de prueba son un conjunto específico de condiciones en las cuales el

analista comprobará que nivel de satisfacción tiene un requisito de una

aplicación.

3. Identificar escenarios Se identifican cada uno de los escenarios específicos que ocurren para cada caso

de uso.

4. Identificar casos de prueba De un escenario de un caso de uso pueden derivarse varios casos de prueba. Una

vez identificados todos los escenarios de un caso de uso se analizan cada uno de

ellos para buscar los posibles casos de prueba.

Organizar las ideas para las pruebas con base en los elementos que se desean

probar de los casos de uso: funcionalidad, atributos de calidad, validaciones de

entradas y salidas, base de datos, interfaces, etc, y completar la siguiente matriz.

207

ID caso de prueba

Nombre Resultado Esperado

Nivel de prueba Tipo de prueba

5. Detalle del caso de prueba Especificar con detalle el caso de prueba listados en la matriz anterior.

Caso de Prueba

Nombre Sistema Nombre del sistema Nivel de prueba Indique el nivel de prueba, ya establecido en el cuadro anterior

ID Caso uso Número caso uso Tipo de prueba Indique el tipo de prueba, ya establecido en el cuadro anterior

Ambiente de prueba Indique el ambiente de prueba para el caso de prueba.

Escenario Indique ID y el nombre de escenario

Autor Indique el nombre del autor

Caso de prueba Indique el ID y nombre del caso de prueba

Probador Indique el nombre del probador

Versión Indique el número de versión del caso de prueba

Fecha creación Indique la fecha de creación

Fecha ejecución Indique la fecha de ejecución

Condición(es) de ejecución Describir todas las necesidades que se deben tener resueltas para que el caso de prueba se lleva a cabo

Paso Condición Valor(es) Resultado esperado

Resultado obtenido

Criterio de aceptación Indique en porcentaje los resultados esperados

Decisión aprobación Aceptado Indique si acepta el caso de prueba

Fallado Indique si fallo el caso de prueba

Fecha de aplicación Indique la fecha de aplicación

208



D O C U M E N T O P A R A C A S O D E P R U E B A D E L P R O Y E C T O N U T R I C I Ó N

209



2. Descripción Los casos de prueba son un conjunto específico de condiciones en las cuales el

analista comprobará que nivel de satisfacción tiene un requisito de una

aplicación.

3. Identificar escenarios Se identifican cada uno de los escenarios específicos que ocurren para cada caso

de uso.

4. Identificar casos de prueba De un escenario de un caso de uso pueden derivarse varios casos de prueba. Una

vez identificados todos los escenarios de un caso de uso se analizan cada uno de

ellos para buscar los posibles casos de prueba.

Organizar las ideas para las pruebas con base en los elementos que se desean

probar de los casos de uso: funcionalidad, atributos de calidad, validaciones de

entradas y salidas, base de datos, interfaces, etc, y completar la siguiente matriz.

210

ID caso de prueba

Nombre Resultado Esperado

Nivel de prueba Tipo de prueba

AL01 Alimentación Grabado Alto Caja negra

5. Detalle del caso de prueba Especificar con detalle el caso de prueba listados en la matriz anterior.

Caso de Prueba

Nombre Sistema Nutrición Nivel de prueba Alto

ID Caso uso 01 Tipo de prueba Caja negra

Ambiente de prueba Desarrollo

Escenario 01Alta Autor Ing. Roy Céspedes G.

Caso de prueba AL01 Probador Ana María Jiménez

Versión 1.0 Fecha creación 02-02-2010 Fecha ejecución 02-02-2010

Condición(es) de ejecución

Paso Condición Valor(es) Resultado esperado

Resultado obtenido

Criterio de aceptación 80%

Decisión aprobación Aceptado SI Fallado

Fecha de aplicación 02-02-2010

211

8.23. Anexo 23. Plantilla Minuta de Aceptación

Minuta de Aceptación de Pruebas

FECHA: [Indicar Fecha de Acta .] HORA: [Indicar hora

del Acta .] LUGAR: [Indicar el lugar donde se realiza la prueba.]

MODULO/PROYECTO: [Indicar el nombre del modulo o proyecto.]

PRESENTES [Indicar los nombres de los presentes.]

Agenda

Tema:

PRUEBAS [Indicar la prueba a realizar.]

ACCIONES RESPONSABLE

[Indicar las acciones a tomar.] [Indicar el nombre del responsable.]

OBSERVACIONES:

[Indicar observaciones.]

FIRMAS

[Espacio para las firmas de los presentes.]

212

Minuta de Aceptación de Pruebas

FECHA: 02-02-2010 HORA: 22: 00 LUGAR: UTIC

MODULO/PROYECTO: Nutrición

PRESENTES Ing. Roy Céspedes G.

Agenda

Tema:

PRUEBAS Alta, baja y cambios de alimentos

ACCIONES RESPONSABLE

OBSERVACIONES:

FIRMAS

8.24. Anexo n. o 24: Documento de implementación del proyecto

UTIC

213

Unidad de Tecnologías de Información y Comunicación




D O C U M E N T O D E I M P L E M E N T A C I Ó N D E L P R O Y E C T O < N O M B R E D E L P R O Y E C T O >

214


2. Descripción La etapa de Puesta de implementación del proyecto describe las actividades que

hay que realizar para asegurar que el producto desarrollado pueda ser utilizado

por los usuarios finales.

3. Responsabilidades [Identifique las responsabilidades tanto del cliente como del equipo de desarrollo.] Equipo de trabajo Cliente

4. Liberación de versión [Lista el software y demás artefactos provistos como parte del producto entregable.]

5. Soporte para la implementación [Describir las necesidades de soporte al usuario para la liberación de la nueva versión del software.]

6. Materiales de apoyo [Lista los materiales de apoyo y todos aquellos recursos necesarios para llevar a cabo las actividades de implementación de software.]

7. Software necesario [Describa el software necesario para dar soporte al software desarrollado, por ejemplo: herramientas de desarrollo, compiladores, herramientas de diseño, utilitarios, herramientas bases de datos, archivos de datos, etc.]

8. Instaladores necesarios [Listar los instaladores y versión que se vean afectados por el software.]

215



D O C U M E N T O D E I M P L E M E N T A C I Ó N D E L P R O Y E C T O N U T R I C I Ó N

216



2. Descripción La etapa de Puesta de implementación del proyecto describe las actividades que

hay que realizar para asegurar que el producto desarrollado pueda ser utilizado

por los usuarios finales.

3. Responsabilidades Equipo de trabajo

• Aplicación funcionando perfectamente Cliente

• Digitar la totalidad de los alimentos

4. Liberación de versión • Sistema de Programación de menú

5. Soporte para la implementación • Capacitar al usuario

6. Materiales de apoyo

7. Software necesario

8. Instaladores necesarios

217

8.25. Anexo n. o 25: Comunicado de liberación de versión

Lugar, Fecha

Comunicado de liberación de versión

Proyecto: xxxxxxxxxxxxx

Versión: xxxxxxxxxxxxx

Descripción de versión [Describa los detalles más relevantes del proyecto, si es una versión nueva incluir aspectos generales del software, si es un cambio anotar los aspectos modificados en el software.] Fecha de entrega Xx/xx/xxxx Encargado general del proyecto [El funcionario encargado del proyecto.]

Atentamente,


xxxxxxx

Jefe

Copia: Expediente 2

218

San José, 02-02-2010

Comunicado de liberación de versión

Proyecto: Nutrición

Versión: 1.0

Descripción de versión Mantenimiento de los alimentos

Fecha de entrega 02-02-2010

Encargado general del proyecto Ing. Roy Céspedes G.

Atentamente,


Armando Oporta Serrano

Jefe

Copia: Expediente 2

UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL PROPUESTA DE ... · horas de paciencia. Gracias mi...

Documents

Transcript of UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL PROPUESTA DE ... · horas de paciencia. Gracias mi...