UNIVERSIDAD PERUANA DE CIENCIAS APLICADAS

FACULTAD DE INGENIERA DIVISIN DE ESTUDIOS PROFESIONALES PARA EJECUTIVOS

CARRERA DE INGENIERA DE SISTEMAS

APLICACIN DE METODOLOGIAS INTERNACIONALES Y BUENAS PRCTICAS PARA LA GESTION DE PROYECTOS DE DESARROLLO DE SOFTWARE

PROYECTO PROFESIONAL PRESENTADO POR: LORENA SIA GONZALEZ ALFREDO ACEVEDO OSHITA

PARA OPTAR POR EL TTULO DE INGENIERO DE SISTEMAS

Lima, Noviembre de 2011

RESUMEN EJECUTIVO

La presente investigacin se centra en la aplicacin de nuevas metodologas internacionales como lo son BPM y Agile, as como de las Buenas Prcticas de CMMI en empresas de consultora de sistemas, desarrollo de software y de servicios administrativos generales.

Hemos sustentado el estudio de las metodologas y prcticas sealadas en 3 captulos. El Primer Captulo realiza un anlisis de los procesos de Solicitud de Cita y Atencin Mdica Hospitalaria para la empresa Clnica San Juan de Dios. El objetivo es el elaborar un nuevo modelo de gestin de los procesos que cumpla con los requerimientos actuales de la institucin, utilizando para tal, la Metodologa de Modelamiento de procesos BMP y la herramienta Bizagi Process Modeler, como la aplicacin de software para el diseo. Es importante tener en cuenta que la realidad de cada centro de atencin hospitalaria del Grupo San Juan de Dios en el pas es diferente, por lo cual, solo ser base de nuestro estudio la clnica en Lima.

El Segundo Captulo realiza un estudio de los procesos para el desarrollo de software del Grupo SYPSA S.A. La implementacin de CMMI en esta organizacin obedece a la necesidad de poner en marcha un programa de

mejoras continuas en todos los procesos del rea de Aplicaciones y Desarrollo de Software. Los procedimientos que se van a desarrollar son: identificar los problemas latentes ms importantes en la organizacin, conocer los objetivos de negocio y de mejora que se requieren, realizar un diagnstico de los procesos del rea en estudio respecto al modelo CMMI que incluyen solamente el Planeamiento de los Proyectos y la Gestin de Requerimientos y proponer mtricas para el seguimiento de los proyectos.

Finalmente, el Tercer Captulo desarrolla la experiencia de algunas prcticas de la Metodologa Agile en dos empresas consultoras de soluciones informticas como son Dainko S.A. y CSC Consultores SAC. Las prcticas son: Aplicacin de Scrum Taskboard; Experiencias Daily Meeting, como

herramienta para aumentar la productividad, aprendizaje y compromiso del equipo de desarrollo en los proyectos y Pair Programming como una experiencia en el mejoramiento de la codificacin, programacin y desarrollo de aplicaciones de software en equipos pares de trabajo.

Como conclusin, nuestro trabajo de investigacin permitir el conocimiento de nuevas metodologas y prcticas para la gestin de proyectos de desarrollo de software, las cuales sern aplicadas en empresas cuyo negocio no solo es la tecnologa de desarrollo sino tambin servicios en general.

INDICE

RESUMEN INDICE LISTAS ESPECIALES INTRODUCCION CAPITULO 1:

1 4 8 9 GESTIN DE PROCESOS DE NEGOCIO CON BPM 1.1 INTRODUCCIN 1.2 ANTECEDENTES DE LA EMPRESA 1.2.1 Misin 1.2.2 Visin 1.2.3 Objetivos Estratgicos 1.2.4 Organigrama Clnica San Juan de Dios 1.3 CAMPO DE ACCIN 1.4 SITUACIN ACTUAL 1.4.1 Admisin 1.4.2 Asistencia Social 1.4.3 Caja 1.4.4 Consulta Mdica 1.5 OPORTUNIDADES DE MEJORA 1.5.1 Descripcin del Proceso en Estudio 1.6 OBJETIVOS DE LA SOLUCIN 1.7 PROTOTIPO DEL PROCESO EN BPM STUDIO 1.7.1 Sub-Procesos 1.7.1.1 Registrar Informacin de Paciente 13 14 15 15 15 18 19 20 20 21 21 22 22 23 26 27 28 28
0

1.7.1.2 Evaluar Paciente 1.7.1.3 Evaluar Re categorizacin 1.8 INDICADORES DE DESEMPEO 1.9 CONCLUSIONES CAPITULO II: GESTION DE PROYECTOS CON CMMI 2.1 INTRODUCCIN 2.2 ANTECEDENTES DE LA EMPRESA 2.2.1 Misin 2.2.2 Visin 2.2.3 Organigrama Grupo Sypsa S.A. 2.2.4 Objetivos del Negocio 2.3 ALCANCE DE LA EVALUACIN 2.4 FACTIBILIDAD DEL CAMBIO 2.4.1 Resea procesos 2.4.2 Probables focos de resistencia sobre antecedentes de

28 28 29 31 32 32 32 35 35 35 36 36 37 cambios 37 38 de

2.4.3 Procesos, mecanismos, mtodos, prcticas actual 39 2.4.4 Problemas u oportunidades de mejora conocidos 2.4.5 Factores Clave de xito Actuales 2.5 Evaluacin de la Situacin Actual 2.5.1 Descripcin Utilizadas de las Fuentes de 41 42 Informacin 42

2.5.2 Evaluacin de Cumplimiento de las Prcticas Especficas y Genricas de las siguientes reas de Proceso 2.5.2.1 Project Planning (PP) 2.5.2.2 Project Monitoring and Control (PMC) 2.5.2.3 Requirements Management (REQM) 2.5.2.4 Presentacin de resultados 43 43 49 53 57

2.5.2.5 Por cada rea de proceso, porcentaje de prcticas cumplidas y no cumplidas 57

2.5.2.6 Porcentaje total de prcticas cumplidas y no cumplidas 2.6 PROCESOS PROPUESTOS 2.6.1 Proceso de Project Planning (PP) 2.6.1.1 Definicin del Proceso 2.6.1.2 Descripcin del Proceso 60 61 61 61 62

2.6.1.3 Matriz de Trazabilidad de las actividades vs. Practicas especficas de PP 66

2.6.2 Proceso de Requirements Management (REQM) 2.6.2.1 Definicin del Proceso 2.6.2.2 Descripcin del Proceso 2.6.2.3 Roles y conocimientos esperados 67 68 73

2.6.2.4 Matriz de Trazabilidad de las actividades vs. Practicas especficas de REQM 2.7 Conclusiones 77 78

CAPITULO SOFTWARE

III:

METODOS

AGILES

PARA

EL

DESARROLLO 79 79 81 83 85 86 86 86 94

DE

3.1 INTRODUCCIN 3.2 FUNDAMENTACIN TERICA 3.2.1 BENEFICIOS 3.2.2 RESTRICCIONES 3.3 ADOPCIN DE PRCTICAS AGILES 3.3.1 EN DAINKO 3.3.1.1 Taskboard Scrum 3.3.1.2 Daily Meeting 3.3.2 En CSC Consulting SAC 3.3.2.1 Pair Programming 3.3.2.2 TaskBoard Scrum 3.4 EVALUACIN DE RESULTADOS

100 100 109 118

3.4.1 Anlisis de las retrospectivas del sprint 2 y 3 118 3.4.2 Retrospectiva de todo el trabajo 3.5 CONCLUSIONES CONCLUSIONES GLOSARIO DE TERMINOS BIBLIOGRAFIA ANEXOS 121 123 125 127 128 129

LISTAS ESPECIALES Cuadro 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 Nombre Objetivos Clnica San Juan de Dios Organigrama Clnica San Juan de Dios Descripcin de Proceso en estudio Modelo BMP Registro de Cita Clnica San Juan de Dios Registrar Informacin de paciente Evaluar paciente Evaluar Re categorizacin Organigrama Grupo Sypsa SA Project Planning Project Monitoring and Control Requirements Management (REQM) Prcticas especificas cumplidas y no cumplidas para PP Prcticas especificas cumplidas y no cumplidas para PCM Prcticas especificas cumplidas y no cumplidas para RQM Total Acumulado de Prcticas especificas cumplidas y no cumplidas Definicin del Proceso de PP Descripcin del Proceso de PP Actividades del proceso de PP Matriz de Trazabilidad de las actividades vs. Practicas especficas de PP Definicin del Proceso REQM Descripcin del Proceso REQM Roles y conocimientos esperados en REQM Actividades del Proceso RQM Matriz de Trazabilidad REQM Registro de Actividades en el Taskboard Taskboard de la Compaa Dainko Ejecucin de TaskBoard en Sprint 2 TaskBoard al finalizar Sprint 3 Daily Meeting con el equipo de Dainko Sesin Daily Meeting Sprint 3 Plataforma Tunki Banco Interbank Previos a la iteracin de Pair Programming Sprint 2 Revisin de ejecutable sesin Pair Programming Reunin de planificacin Sprint 3 Pair Programming Revisando conceptos Cloud Computing y Gestin de Libreras Turno de QC para modificar cdigo. Primer Taskboard prueba al iniciar iteracin 2 Taskboard iteracin 2 segundo da TaskBoard de inicio Sprint 3 Revisin de TaskBoard Sprint 3 TaskBoard previo a cierre de Sprint 3 Pgina 17 18 23 27 28 28 28 35 43 49 53 57 58 59 60 61 62 62 66 67 68 73 73 77 89 89 92 93 96 99 101 102 103 105 106 107 110 111 114 115 116

INTRODUCCION

Durante los ltimos aos la gestin de proyectos de software ha evolucionado considerablemente. Conceptos como Business Process Management BPM, CMMI y Metodologas Agiles han sido incluidos en empresas de alto nivel pues los costos de aplicacin resultan ser altos, no solo en dinero, sino en el costo de cambio de cultura organizacional que requieren para que su implementacin sea la ms favorable y ptima posible.

La metodologa BPM nos permitir mejorar la eficiencia de los procesos del negocio a travs del modelamiento, documentacin y optimizacin de los mismos de manera continua, logrando su ptimo entendimiento y

comportamiento dentro de la organizacin con la minimizacin de errores en su ejecucin.

Por otro lado la naturaleza de los Mtodos Agiles radica en la novedad de su estilo para gestionar los proyectos de desarrollo de software, permitiendo el logro iterativo de versiones de software para los clientes, con entregas

oportunas y de calidad para los paquetes o entrega final del producto. La participacin activa del usuario es vital en esta prctica lo que refuerza el alto nivel de satisfaccin y compromiso con el equipo de trabajo y que finalmente se traslada a relaciones de negocios ms estrechas y duraderas. Mientras, CMMI demuestra ser un modelo para aplicar mejoras de gran impacto en procesos de desarrollo de productos software, reduciendo los defectos, mejora en la planificacin, mejor calidad de producto terminado, etc. Sin embargo hemos detectado que exige mucho esfuerzo de implantacin en las empresas y el alto costo que se produce si es que no forma parte de la prctica de gestin en la institucin, haciendo engorrosa su aplicacin. Por tanto no solo es un mtodo de evaluacin, sino las indicaciones de que hacer para la mejora de proyectos de desarrollo de software.

El presente trabajo de investigacin est enfocado en la implementacin de BPM en la Clnica San Juan de Dios, aplicacin del modelo CMMI en el Grupo Sypsa S.A. y aplicaciones prcticas de los Mtodos Agile en Dainko S.A. y CSC Consulting SAC.

Actualmente la Clnica San Juan Dios tiene como fin la rehabilitacin fsica de nios y jvenes discapacitados de escasos recursos econmicos. Presentan muchos problemas en la gestin de citas mdicas y atencin del paciente de manera oportuna y con registros confiables para el seguimiento de los tratamientos de rehabilitacin. Por tal, hemos considerado aplicar los conceptos de mejoramiento de la gestin de procesos para el rea en mencin, proponiendo una nueva solucin en el desarrollo del mismo y optimizacin de los tiempos de ejecucin de las actividades y rpida
10

obtencin de resultados bajo los conceptos que nos ensea el BPM. La implementacin de este concepto de gestin la detallaremos en el Captulo I del presente trabajo.

El Captulo II se enfocar a la prctica del modelo CMMI para el grupo SYPSA S.A., organizacin de profesionales, dedicada a proveer soluciones y servicios de alta tecnologa a la pequea, mediana y gran empresa. Con ms de 30 aos de experiencia, ofrecen una amplia gama de productos tanto de hardware como de software de las marcas ms prestigiadas del mercado informtico y diversos servicios de Tecnologa de la Informacin e Integracin de Sistemas. El Grupo SYPSA cuenta con un rea de desarrollo de software con casi ningn lineamiento o metodologa de gestin de proyectos definida, ms que la de su propio criterio de gestin. Es un modelo de negocio ideal para estudiar a fondo los pasos que nos propone a CMMI para optimizar la gestin del desarrollo de software y evaluar con ms criterio profesional el estado actual de dicha gestin para as, proponer mejoras a la direccin de la empresa.

La Metodologa Agile y algunas de sus prcticas ms comunes sern tratadas en el Captulo III. Centraremos nuestro estudio en dos empresas consultoras en desarrollo de software y en servicios de Tecnologa de la Informacin. Ellas son Dainko S.A., empresa dedicada al servicio de consultora y desarrollo de soluciones informticas en plataforma 2.0 direccionadas a soluciones de Redes Sociales Corporativas, Portales e Intranets, Social Learning, Aplicaciones Administrativas propietarias en Gestin y Desarrollo Humano, etc.; y, CSC Consulting SAC empresa de soluciones informticas
11

cuya especialidad es el Testing, Diseo de Procesos, Estandarizaciones, Modelamientos y puestas en marcha de base de datos corporativas, Control de Calidad sobre software.

La aplicacin de estos nuevos conceptos en la gestin de procesos y gestin de proyectos de desarrollo de software en las empresas indicadas nos permitir reforzar los conocimientos respectivos y ganar experiencia para proyectos de gran envergadura futuros.

12

CAPITULO I

GESTION DE PROCESOS DE NEGOCIO CON BPM

1. Gestin de Procesos de Negocio con BPM

1.1 Introduccin.

En este captulo, se realiza la evaluacin del proceso de negocio bajo la metodologa BPM. Este modelado estar enfocado principalmente a los procesos de Registro de Cita y Atencin Clnica de la Clnica San Juan de Dios. Una vez se concluya con el anlisis correspondiente se proceder a disear un nuevo modelo el cual incluir todas las mejoras obtenidas. El anlisis y diseo de este modelo estar realizado bajo la metodologa de Gestin de Procesos de Negocios (BPM) y como herramienta de implementacin de utilizar Bizagi Process Modeler. El objetivo de este anlisis es la reduccin del tiempo en el proceso de recepcin de citas y mejora la atencin de los pacientes en las diferentes especialidades que brinda la institucin.

13

1.2 Antecedentes de la empresa La institucin objeto de estudio, es la Clnica San Juan de Dios, que fue creada en el ao 1952 bajo la denominacin de Hogar Clnica San Juan de Dios, cuya finalidad es la rehabilitacin fsica de nios y jvenes discapacitados de escasos recursos econmicos.

La Orden Hospitalaria de San Juan de Dios tiene a cargo la administracin de 6 clnicas en el Per, y han decidido reorganizar el sistema de Gestin Hospitalaria en todas ellas, por lo que no solo se enfocan en el cambio de un nuevo software sino tambin en los procedimientos administrativos como tales. Se encontraron deficiencias para lograr una integracin y un solo lenguaje para todas las clnicas, pues cada sistema funciona solo en cada sede haciendo imposible replicarlas a todas las dems. Este proyecto se enfocara solamente al proceso de Atencin Hospitalaria, desde la toma de cita, asignacin de cita y resultado de la actividad para todas las especialidades de la clnica. Los tratamientos mdicos no solo refieren a las rehabilitaciones fsicas de varios campos sino tambin a otras especialidades como pediatra, odontologa, etc.

La gestin administrativa actual ha considerado el cambio de nombre de Hogar a simplemente Clnica pues el nmero de nios atendidos ya no son meramente abandonados, sino que se ha elevado el nmero de atenciones privadas de sectores econmicos de toda ndole.

14

1.2.1 Misin Brindar asistencia integral de salud a la poblacin infantil de bajos recursos econmicos; con calidad, calidez y excelencia, participando en la docencia pre y pos grado de los profesionales de salud, autogenerando recursos econmicos con la atencin de pacientes privados de compaas de seguros.

1.2.2 Visin Ser una institucin lder en el pas acreditada por su excelencia asistencial tecnolgica y acadmica tocando como fundamento los principios y valores de la Orden Hospitalaria de San Juan de Dios.

1.2.3 Objetivos Estratgicos

Para el proceso de formulacin de los objetivos estratgicos generales de la Clnica San Juan de Dios se definieron los siguientes lineamientos: Modelo de atencin basado en la calidad y excelencia.- Un modelo de atencin basado en la calidad y excelencia de los diferentes servicios que se prestan en la institucin, bajo un enfoque comn. Fortalecer el marco regulatorio.Que permita contar con

metodologas y normas adecuadas para realizar una supervisin efectiva sobre las diferentes reas de la institucin.

15

 Fomentar una mayor inclusin social.- Que permita impulsar la rehabilitacin de las personas con menores recursos econmicos. Esto se lograr a travs del establecimiento de mecanismos que permitan: un mayor acceso a los servicios y beneficios de las personas, un mayor conocimiento sobre los servicios que brinda la institucin. Mejorar la imagen y posicionamiento de la Clnica San Juan de Dios.- Con un mejor conocimiento de la funcin y rol de la Institucin por parte de las personas e instituciones sociales se facilitar la labor de la institucin. Por otro lado, la cooperacin es otra fuente que debe ser aprovechada para el fortalecimiento en aspectos como la capacitacin del personal profesional, tcnico y administrativo adems de la adquisicin de infraestructura

necesaria para poder cumplir con las necesidades de las diferentes reas. Incrementar la eficiencia de los procesos.- Que permita dar un servicio oportuno y de calidad a los usuarios externos e internos. Se espera que los procesos de atencin hospitalaria cuenten con mecanismos de alertas en cada una de las instancias con la finalidad de mejorar el desempeo y productividad en la atencin de los requerimientos.

16

Los objetivos estratgicos que se plantean en la institucin son:

Cuadro 01: Objetivos Clnica San Juan de Dios

Objetivo Estratgico General

Objetivos Estratgicos Especficos

Implementar un modelo de atencin Definir un basada en la calidad y excelencia.

modelo de atencin

basado en la calidad y excelencia. Implementar el modelo atencin basado en la calidad y excelencia.

Fortalecer el marco regulatorio

Mejorar

proceso

de

reserva

atencin hospitalaria Fomentar mayor inclusin social. Promover y consolidar una mayor atencin a las personas ms

necesitadas. Mejorar el posicionamiento e Consolidar una imagen positiva de la Clnica San Juan de Dios. Fortalecer cooperacin nacionales Incrementar la eficiencia de los Automatizacin, procesos mejora y los con vnculos y

imagen de la clnica.

instituciones

optimizacin de los procesos.

17

1.2.4 Organigrama Clnica San Juan de Dios (Cuadro 02)

18

1.3 Campo de Accin La problemtica actual de la institucin se sostiene en el continuo crecimiento de la informacin y sobre todo de la cantidad de sistemas que se manejan en las distintas clnicas, motivo que lleva a concluir que los procesos y sistemas informticos con los que se trabaja en la actualidad estn siendo cada da ms deficientes. Por tal motivo se plantea realizar una reingeniera o una actualizacin a todos los procesos de la gestin hospitalaria, que contemplen una futura implementacin bajo un solo estndar para todas las clnicas. Nos enfocaremos en crear procesos que tengan la capacidad de soportar las diferentes actividades que se generen en un futuro.

El campo de accin del presente trabajo est asociado al proceso de Atencin Hospitalaria, que consiste en la solicitud de cita, validacin de disponibilidad de horario, generacin de historia clnica, generacin de cita, generacin de documentos de pago, consulta, etc.

Las reas principales, involucradas directamente en el presente proceso son: Admisin, rea que participa directamente en las actividades del proceso. Caja, rea que recibe la informacin validada y consolidada. Archivo, rea encarga de almacenar la informacin del paciente (HC). Bienestar Social, rea encargada de evaluar la situacin del paciente.
19

 Consulta, rea encargada de la atencin del paciente.

1.4 Situacin Actual Hemos detectado diversos problemas en las siguientes reas del negocio, y que afectan directamente al desarrollo del proceso en estudio.

1.4.1 Admisin Problema Consecuencia

Lentitud en el proceso de registro de Ello origina la incomodidad por citas: Muchas veces el registro de citas no se realiza segn los tiempos parte de los pacientes.

estimados o no se dispone de la informacin necesaria Datos Incorrectos en los Horarios Ello origina que el personal de Mdicos: Muchas veces la relacin admisin de horarios mdicos no no cuente con la

est informacin correcta al momento

disponible o no se ha realizado las de otorgar la cita. correcciones correspondientes. Problemas en la Generacin de Ello origina malestar por parte de

Cronograma de Terapia: Algunas los pacientes debido a que no veces existen del no problemas en la pueden ser atendidos segn el de cronograma que tenan asignados. la

generacin terapias por

cronograma contar con

informacin de los horarios o la relacin de citas programadas

anteriormente. Lentitud en la generacin de HC y Ello origina problemas a la hora Carnet de paciente: Con frecuencia que los mdicos requieran la se presentan problemas con la Historia Clnica (HC) para realizar

generacin de HC y/o Carnet del la consulta del paciente.

20

paciente, ya

sea por fallas del

sistema o disponibilidad del personal encargado.

1.4.2 Asistencia Social En esta etapa se han detectado los siguientes problemas: Problema Consecuencia

Categorizacin del Paciente: Algunas Ello origina la incomodidad del veces este proceso tomas demasiado cliente por no poder saber el costo tiempo motivando el retraso en la real de su tratamiento. emisin del comprobante de pago. Recepcin de Documentos del Ello origina la incomodidad del

paciente a Evaluar. Algunas veces no cliente por no poder saber el costo se cuenta con la informacin real de su tratamiento.

requerida del paciente motivo por el cual no se puede proceder con la evaluacin correspondiente. Generar Informe de Evaluacin: Ello origina la incomodidad por

Algunas veces no se puede proceder parte del paciente y del rea de con la generacin del informe de caja para poder emitir el importe evaluacin porque no se registr toda de la consulta o del tratamiento de la informacin del paciente. terapia.

1.4.3 Caja En esta etapa se han detectado los siguientes problemas:

Problema

Consecuencia

Recepcin de Documentos de Pago: Ello origina inconvenientes en el Algunas veces se presentan personal de caja, sus no pueden

problemas para la emisin de los realizar

actividades

documentos de pago por falta de correctamente y con los pacientes

21

informacin del rea de admisin.

por el tiempo

transcurrido en la

separacin de una cita. Clculo del Importe de la Cita: Ello origina un problema en el

Presenta algunos problemas cuando proceso de generacin de factura se requiere realizar el clculo de la o boleta de pago repercutiendo en cita de algunos pacientes que han la sensacin o apreciacin que solicitado una re categorizacin tendr el paciente de nuestra institucin.

1.4.4 Consulta Mdica En esta etapa se han detectado los siguientes problemas:

Problema

Consecuencia

Generar Cronograma de Terapias: Ello origina inconvenientes en el Algunas veces se presentan personal de caja a la hora de emitir comprobante de pago y/o

problemas debido a que el mdico no el procedi con de la generacin terapias para

del factura, tambin incomodidad en el el paciente al momento de querer realizar el pago correspondiente.

cronograma paciente.

1.5 Oportunidades de Mejora La eleccin del presente proceso est relacionada a los siguientes puntos: La informacin generada es de suma importancia para poder cumplir con todo el proceso de atencin hospitalaria del paciente, ya que todas las reas internas de la institucin necesitan de dicha informacin, con la finalidad de poder conocer la informacin del paciente y su historia.

Las oportunidades de mejora obedecen a resolver la problemtica que se tiene en las tareas de recepcin, validacin y generacin de citas
22

adems de optimizar el proceso de consulta mdica. Estas mejoras se basan principalmente en la automatizacin de tareas que actualmente se realizan de forma manual lo cual demanda mayor tiempo por parte de los usuarios y no son del todo eficientes.

1.5.1 Descripcin del Proceso en Estudio (Cuadro 03) Descripcin del proceso 1 Solicitud de Cita El paciente se acerca a la institucin y solicita una cita medica 2 Verificar tipo de paciente El personal de admisin verifica si es el paciente tiene HC o es un paciente nuevo. 3 Tipo de Consulta El personal de admisin verifica el tipo de consulta solicitado por el cliente: 4 Consulta Mdica Terapia de Rehabilitacin. Terapia de Rehabilitacin Si el paciente solicita una terapia de rehabilitacin, el personal de admisin verifica si ya tiene registrado un cronograma de Terapia, si la verificacin es correcta procede a generar la informacin de pago para caja. Si el paciente no tiene un cronograma de rehabilitacin, se procede a registrar una cita mdica segn el horario solicitado por el paciente y la

23

disponibilidad existente. Luego de eso se genera la informacin de pago para caja. 5 Consulta mdica

Si el paciente que solicita la consulta mdica no tiene Historia Clnica en la institucin, se procede a generar la cita segn el requerimiento del paciente y la disponibilidad de horarios existentes, tambin se procede con la generacin de la historia clnica y el carnet del paciente en el caso que sea un paciente nuevo. Luego de realizadas esas actividades se procede a generar la informacin de pago para caja. 6 Calcular costo de Cita El personal de caja recibe la informacin de admisin y procede a calcular el costo de la cita. Se informa al paciente sobre el importe de la cita. Si el paciente no est conforme con el monto calculado y pide una re categorizacin se enva la informacin a la asistencia social para su evaluacin correspondiente y se da por concluido el proceso hasta tener la respuesta de la asistencia social (mximo 1 semana.) 7 Generacin de Factura o Comprobante de pago El personal de caja procede a generar la factura o comprobante de pago por el importe de la cita o terapia de rehabilitacin correspondiente, en este proceso se tiene en cuenta el informe enviado por la asistenta social si existe un pedido de re categorizacin. 8 Evaluar Re categorizacin La asistenta social recibe la informacin del paciente y procede a realizar
24

la evaluacin respectiva segn los indicadores o mtricas que se deben de utilizar para estos casos. Si no existiera la informacin necesaria se informara al paciente para que proporcione la informacin requerida. El personal tiene como mximo 1 semana para poder realizar la evaluacin correspondiente. 9 Autorizar Re-categorizacin del paciente La asistenta social procede a autorizar la re categorizacin del paciente si cumple con todos los requisitos establecidos, luego procede a emitir un informe del proceso de evaluacin y emite un mensaje al rea de caja para que proceda a emitir el documento correspondiente con el nuevo monto recalculado. 11 Solicitar Historia Clnica. El personal de enfermera solicita el HC al rea de archivo para la consulta del paciente. El rea de archivo enva el documento fsico de la HC al departamento mdico que lo est solicitando. 12 Realizar Terapia de Rehabilitacin. El personal mdico realiza la terapia correspondiente al paciente. 13 Evaluacin del Paciente. El personal mdico examina la paciente, realiza el diagnostico correspondiente, si requiere terapia Genera el Cronograma de Terapias, si solamente requiere otra cita procede a Generar la Orden para la prxima cita y enviar la informacin a caja para la emisin de los documentos de pago correspondientes. 14 Actualizar Historia Clnica (HC) El personal mdico procede a actualizar el HC con la informacin
25

generada por la consulta o la terapia de rehabilitacin. 15 Emisin de Receta Mdica. El personal mdico procede a la emisin de la receta si es necesario

1.6 Objetivos de la Solucin

El objetivo principal de la solucin es lograr una disminucin del tiempo en el proceso de registro de cita y atencin del paciente, registro idneo de las citas respetando horarios y especialidades, adems de aumentar la calidad en la informacin registrada, a fin de que todas las reas de la institucin puedan tener la informacin consolidada en el momento que les sea necesario.

Esto es de mucha utilidad para los diferentes departamentos de la clnica ya que les permitir mejorar sus procesos de evaluacin al tener la informacin en tiempos ms oportunos. Tambin mejorar la imagen de la institucin al mostrar mayor eficacia en sus procesos lo cual se ver reflejado en una mejor atencin a los pacientes y pblico en general.

26

1.7 Prototipo del proceso en BPM Studio A continuacin se muestra el diagrama del modelo propuesto en la metodologa BPM.

Cuadro 04: Modelo BPM Registro de Cita Clnica San Juan de Dios

27

1.7.1 Sub-Procesos 1.7.1.1 Registrar Informacin de Paciente (Cuadro 05)

1.7.1.2 Evaluar Paciente (Cuadro 06)

1.7.1.3 Evaluar Re categorizacin (Cuadro 07)

28

1.8 Indicadores desempeo Plantearemos los siguientes indicadores de desempeo para medir los resultados de la aplicacin de las mejoras en el proceso.

Nombre Finalidad

Tiempo de Registro de Cita. Reducir el tiempo de registro de cita por parte del personal de admisin.

Tipo Indicador Meta/s Expresin

de Efectividad

Disminuir en un 65% respecto al proceso actual. 0,10 TDH + 0,60 TRIP + 0,30 TGIP Dnde: TDH = Tiempo de disponibilidad de Horarios TRIP = Tiempo de registro de informacin del paciente TGIP = Tiempo de generar informacin de pago.

Nombre Finalidad

Tiempo de Evaluacin de la Categorizacin Reducir el tiempo de evaluacin de la Asistencia Social, una vez registrada la informacin del paciente.

Tipo Indicador Meta/s

de Efectividad

Disminuir en un 25% respecto al proceso actual (10 das)

Expresin

0,20 TVI + 0,40 TVD + 0,40 TVIF Dnde: TVI = Tiempo de validacin de la informacin TVD = Tiempo de validacin domiciliaria TVIF = Tiempo de validacin de ingresos familiares.

29

Nombre Finalidad Tipo Indicador Meta/s Expresin

% de Citas por Especialidad Monitorear la cantidad de citas por especialidad. de Demanda

Aumentar el nmero de especialista segn demanda

Nombre Finalidad

% Satisfaccin de los Pacientes Aumentar el % de satisfaccin de los pacientes con el servicio prestado. Esta informacin se obtendr en funcin a una encuesta que se realizara

peridicamente a los pacientes. Tipo Indicador Meta/s Aumentar en un 50% la satisfaccin de los pacientes en el servicio ofrecido. Realizar una encuesta a los clientes despus de haber sido atendido Expresin 0,30 CS + 0,20 TE + 0,25 IN + 0.25 ET Dnde: CS = Calidad del servicio ofrecido TE = Tiempo de espera IN = Instalaciones ET = Equipamiento Tecnolgico de Satisfaccin

30

1.9 Conclusiones En el presente proyecto se ha desarrollo un estudio sobre el proceso de atencin hospitalaria que se viene utilizando en la Clnica San Juan de Dios. En dicho estudio se ha identificado las causas que estn originando la demora en el proceso de registro de citas.

En ste anlisis se pudo apreciar que los mtodos o actividades que se estn realizado no son muy eficientes, motivo por el cual se propone una solucin ms ptima atencin mdica. para los proceso de registro de cita y

Se proporciona una mejor visin de las actividades o procesos a automatizar, lo cual permitir tener un panorama ms claro y preciso de las actividades que se estn realizando.

Optimizacin de los tiempos y costos para la institucin

Optimizacin del proceso de atencin hospitalaria, reforzando los procesos y estndares a ser aplicados en la red hospitalaria.

Para el modelamiento y planteamiento de la solucin se utiliz la herramienta Bizagi Process Modeler, en la cual se modelaron los procesos por los cuales se deben de transitar para obtener un servicio de atencin ms eficiente y optimizada.

31

CAPITULO II

GESTION DE PROYECTOS CON CMMI

2. GESTION DE PROYECTOS CON CMMI

2.1 Introduccin.

El siguiente estudio refiere a la aplicacin del modelo CMMI en la empresa Grupo Sypsa S.A. como parte del desarrollo de nuevas prcticas en el rea de Aplicaciones y Desarrollo de software. CMMI permitir el anlisis situacional del rea en mencin proponiendo mejoras en la gestin de los proyectos de desarrollo y diseo de software implementados en la empresa. Enfocaremos el alcance del estudio en los procesos de planeamiento (PP) y de la Gestin de Requerimientos (REQM) para los nuevos desarrollos de software hacia clientes.

2.2 Antecedentes de la empresa

GRUPO SYPSA S.A. es una organizacin de profesionales, dedicada a proveer soluciones y servicios de alta tecnologa a la pequea, mediana y
32

gran empresa. Con ms de 30 aos de experiencia, ofrecen una amplia gama de productos tanto de hardware como de software de las marcas ms prestigiadas del mercado informtico y diversos servicios de Tecnologa de la Informacin e Integracin de Sistemas.

La compaa ha ido adquiriendo un completo conocimiento de los diversos mercados e industrias a travs de los aos, con el fin de ofrecer soluciones y servicios que agreguen valor a los clientes. El personal de sistemas cuenta en su mayora con certificaciones de los principales fabricantes de tecnologa, adquiridas a lo largo de su desarrollo profesional en las distintas empresas donde laboraron.

Actualmente la empresa est integrada por profesionales de las diferentes reas de la Tecnologa de la Informacin, habiendo expandido sus actividades a otros pases tales como Mxico, Ecuador, Guatemala, Panam y Venezuela.

Grupo SYPSA ha sido reconocido por la Corporacin de VMware como la empresa de "Mayor crecimiento en ventas durante el ao 2009", mrito que fue otorgado en el evento Kick off del 2010 por el Gerente de Preventas VMware. En dicho nombramiento se destac el resultado obtenido por la empresa al haber implementado en forma exitosa el primer proyecto del Per de una solucin de virtualizacin de estaciones de trabajo (VDI) en una de las principales empresas pesqueras del medio. En la actualidad contamos con el mayor nmero de profesionales certificados del Per en VMware Versin 4.
33

Grupo SYPSA, ha mantenido durante muchos aos una larga y exitosa relacin de negocios con IBM del Per S.A., siendo certificada por ellos a nivel internacional en la comercializacin de los Sistemas IBM iSeries, pSeries y xSeries, logrando actualmente ser los Asociados de Negocios de IBM ms antiguo del pas. (Primer Socio de Negocios de IBM del Per, desde 1984. Socio categora PREMIER, la ms alta otorgada por IBM). Empresa con amplia experiencia en proyectos de implementacin de ERP en el Per, socio GOLDEN de SAP Andina y del Caribe; lder consecutivo durante los ltimos 3 aos de SAP Business One.

Por tanto presentamos las alianzas estratgicas:

En soluciones de Infraestructura Infraestructura de IBM del Per (Storage, Blades servidores Power). Principales canales de ventas de Lenovo y DELL del Per. Distribuidores de soluciones de Impresin de Lexmark.

En Soluciones de Software Canal con mayor crecimiento de SAP Distribuidor de licencias de Oracle, Tivoli.

Soluciones de Valor Agregado Implementacin de soluciones de Alta Disponibilidad de Vision Solutions Inc. y de DoubleTake. Implementaciones de soluciones de virtualizacin de VMWare.

34

2.2.1 Misin
Brindar el mximo nivel de excelencia y satisfaccin en el valor agregado de las soluciones, productos y servicios que otorgamos a nuestros clientes, estableciendo como base una relacin de confianza y transparencia que nos permita compartir su visin estratgica de negocios a mediano y largo plazo.

2.2.2 Visin
Ser la empresa lder en brindar y gestionar Servicios de Tecnologa de la informacin de primer nivel en nuestro pas, contribuyendo con el desarrollo nacional y por la calidad profesional y tica de sus colaboradores.

2.2.3 Organigrama Grupo Sypsa S.A.(Cuadro 08)

35

2.2.4 Objetivos del Negocio

Desarrollar programas con la finalidad y capacidad de resolver situaciones reales a las empresas para su desarrollo, y evolucin tecnolgica para atender sus necesidades y hacerlas mejores empresas en su campo laboral, financiero, administrativo y econmico, adems de actualizarlos en el campo computacional.

Consolidarse como el mejor servicio de Desarrollo de Software propietario. Actualizacin tecnolgica de los productos que se encuentran ya implementados en varios clientes, as como el incorporar una serie de nuevos productos que permitan ampliar el portafolio del rea.

2.3 Alcance de la evaluacin

Grupo Sypsa SA cuenta con un Departamento de Desarrollo Propietario o llamado Aplicaciones y Desarrollo de Software, rea a estudiar en el presente proyecto. El Alcance se enfoca en el anlisis y propuesta de mejora para los procesos de planeamiento (PP) y de la Gestin de Requerimientos (REQM) para nuevos desarrollos en la empresa.

36

2.4 Factibilidad del cambio 2.4.1 Resea sobre antecedentes de cambios de procesos

En el 2009, la empresa tom la decisin de contratar los servicios de un tercero para realizar una nueva versin del ERP, la misma que se basaba en un cambio del look and feel de las pantallas.

Como parte de las tareas de este proyecto, el rea de desarrollo deba ser instruida en el manejo de los nuevos controles utilizados con el objetivo de brindar apoyo en la culminacin del proyecto y estar aptos para tomar el control del mismo.

La empresa proporcion el cdigo fuente del ERP, este proyecto estuvo planificado, organizado y controlado por el tercero, no se involucr al personal del rea de desarrollo.

En el 2010, la empresa realiz el lanzamiento de la nueva versin invitando a la base de clientes instalada, con lo cual se comprometieron a iniciar las instalaciones en el primer trimestre del 2011.

Debido a que el proyecto no tuvo control ni se realiz seguimiento por parte del personal de la empresa, al momento de involucrar a las personas del rea de implementacin para un control de calidad, se encontraron una infinidad de errores: proceso incompletos, procesos
37

cambiados, desorganizacin, validaciones faltantes y descontrol de las opciones con las que contaba el ERP; fue en ese momento que se pudo conocer que el nivel de cambio de la nueva versin no estaba slo en la forma (look and feel) sino tambin en la codificacin de los procesos.

La nueva versin no pudo ser instalada en el tiempo ofrecido, teniendo que reenviar cartas a los clientes para una prxima fecha. Enseguida se asegur la capacitacin integral al personal de desarrollo de la empresa, luego se retir del proyecto al tercero y la empresa tom el control del proyecto.

2.4.2 Probables focos de resistencia

No existe una definicin de funciones de cada puesto, lo cual ocasiona que una responsabilidad es de todos y de nadie a la vez. No se ha implementado una poltica para el rea de desarrollo concerniente a creacin de nuevos productos; razn por la cual no se sabe de qu manera coordinar las actividades en caso que algn proyecto haya sido desarrollado por un tercero. La organizacin exige que el costo de un proyecto sea ms importante que el tiempo necesario para generar un producto organizado, controlado y documentado. Los programadores no tienen documentan sus labores o tareas que desarrollan diariamente.

38

 Dentro de la organizacin no existe un grupo de personas dedicadas a realizar las pruebas (testing), el nivel del control de calidad est basado en dos momentos: las pruebas del programador y las pruebas que pueda realizar el cliente el consultor de la empresa asignado al cliente. Los clientes estn acostumbrados a enviar sus requerimientos de diversas formas, no se le ha solicitado manejar formatos ni asignar a una persona para comunicar los requerimientos. La empresa no ha definido las herramientas, mecanismos o formatos especficos para utilizarlos en la diagramacin de procesos. Un programador o el rea de programacin no cuenta con informacin de los procesos a nivel funcional, que permitan realizar modificaciones al sistema logrando un entendimiento previo del proceso.

2.4.3 Procesos, mecanismos, mtodos, prcticas actuales.

Registro de modificaciones de los programas; actualmente se maneja un procedimiento definido para realizar y registrar modificaciones en los programas que sufren cambios. Distribucin de cambios; se ha definido un procedimiento para controlar e instalar los cambios realizados en el ERP hacia los clientes.

39

 Registro de incidencias; se cuenta con una herramienta para ingresar las incidencias del ERP reportadas por los consultores o clientes.

2.4.4 Problemas u oportunidades de mejora conocidos.

Proceso para planificar proyectos de desarrollo. Proceso para gestionar los requerimientos. Proceso para realizar las pruebas de control de calidad. No se cuenta con una metodologa formalizada para el desarrollo de los sistemas. No se ha definido un procedimiento formal para la gestin de cambio en los sistemas. No se cuenta con un esquema definido para realizar las pruebas funcionales e integrales necesarias para poner en produccin un desarrollo. Existen algunos requisitos implcitos o expectativas que a menudo no se mencionan, o se mencionan de forma incompleta. No se cuenta con un ambiente dedicado para la realizacin de las pruebas funcionales e integrales. No se cuenta con procedimientos para proteger y controlar los datos de pruebas. Las mtricas del proceso de desarrollo son determinados mediante estadsticas basadas en la experiencia.

40

2.4.5 Factores clave de xito actuales.

Obtener el apoyo de la Gerencia General para lograr inicialmente algn nivel de certificacin. Lograr institucionalizar en la empresa que el tiempo para cubrir fases de un proyecto es necesario e importante, ya que de no ser as podra convertirse en serios problemas de expansin del proyecto. Entrenamiento apropiado del conocimiento y actualizaciones regulares de polticas y procedimientos organizacionales a todos los empleados de la organizacin, contratistas y usuarios de terceros como sea relevante para la funcin de su trabajo. Formalizar un Manual de Organizacin y Funciones (MOF) para la empresa. Asignacin especfica y firme de los recursos incluidos en el plan (humanos, econmicos, etc.) Implementar una estrategia que homologue los niveles de informacin en toda la organizacin, involucrando a los todos stakeholders y tomando activamente la retroalimentacin de las personas que han interactuado en el desarrollo de los sistemas a fin de explicar la visin futura y eliminar temores.

41

2.5 Evaluacin de la situacin actual 2.5.1 Descripcin de las fuentes de informacin utilizadas
Se realizaron diversas entrevistas y encuestas con el objetivo de conocer ms a fondo la forma de trabajo del rea de desarrollo del Grupo Sypsa S.A. y la documentacin actual con las que cuentan para iniciar sus proyectos de implementacin. Los roles de las personas entrevistadas fueron: Gerente de Desarrollo y Proyectos Jefes de Desarrollo. Analistas programadores. Algunos usuarios de la empresa.

A las personas entrevistadas se les solicitaron contestar con respuestas afirmativas o negativas sustentadas en algunos casos de atencin en la empresa. Estas respuestas nos permitirn evaluar el cumplimiento y aplicacin de las prcticas especficas y genricas establecidas por CMMi en las reas de planificacin de proyectos y gestin de requerimientos.

42

2.5.2 Evaluacin de cumplimiento de las prcticas especficas y genricas de las siguientes reas de proceso:

2.5.2.1

Project Planning (PP) (Cuadro 09)

PP

Preguntas

Si/No Comentario

SG 1 Establecer estimaciones SP 1.1 Est descrito en algn lugar cul es el alcance del proyecto en alto nivel, considerando que cubra todo lo que se tiene que hacer? SP 1.2 Se calcula el tamao de los productos? Si Se calcula la el tamao al del No

culminar

evaluacin

producto que se requiere. Se puede conocer cul fue el tamao anteriores? de los proyectos Si La informacin se puede

obtener consultando con las personas encargadas del

requerimiento. SP 1.3 Existe alguna definicin que seale cules son los ciclos de vida posibles? Si Dentro del cronograma

utilizado se establece etapas como: levantamiento aprobacin diseo de de de de

informacin,

requerimientos, programas,

aprobacin

diseo, programacin, pruebas con usuario, depuracin,

entrega. Esta definicin es conocida, y se utiliza para planificar el proyecto? SP 1.4 Se calcula el estimado utilizando algn procedimiento adems del
43

No

No siempre se utiliza.

No

juicio de experto? Se toma en cuenta la No Se considera la experiencia de proyectos anteriores, pero no existe informacin escrita. Se conoce bajo qu supuestos se estim? SG 2 Desarrollar un plan de proyecto SP 2.1 Se tiene el presupuesto del proyecto? Se prepar en base al estimado, incluyendo otros costos no No No

informacin histrica?

asociados al esfuerzo (alquiler de equipos, licencias, etc.)?

Se

tiene

un

cronograma

No

El cronograma se construye considerando las horas de

elaborado en base al esfuerzo?

cada una de las tareas a realizar. Contiene todas las actividades del proyecto? Se conocen y los los hitos, recursos Si No Hay algunas actividades que a ese nivel no son incluidas. Se establecen se hitos; las

dependencias, asignados?

actividades

ordenan

considerando que algunas son pre requisito de otras; los recursos son asignados en el cronograma.

SP 2.2

Se identifican y analizan los riesgos?

No

Hay algunos riesgos que estn relacionados a los recursos asignados cuales al se proyecto los

cubren

incrementando el tiempo de las actividades relacionadas, y

44

otros riesgos que estn en el lado del cliente los cuales no son contemplados. Se encuentran documentados en algn lugar? SP 2.3 Existe un plan de datos del proyecto? Si Cada lder del proyecto No

establece como administrar la informacin que se genera del proyecto.

Se sabe qu informacin se debe recolectar y cul generar?

Si

Se construye un file con los documentos que se reciben durante el levantamiento de informacin; de igual forma coordina con cada

programador el resguardo de los programas que se estn generando, a travs de backup semanales. Se establecen los niveles de acceso? Se tienen niveles de control de cambio (ej. Versiones) para los entregables que lo requieran? Si Slo hay una directiva que para elaborar cambios en los programas o interfaces se Si

debe guardar antes un backup de lo anterior. SP 2.4 Se determinan los recursos etc., Si Los recursos necesarios para el proyecto son considerados antes de iniciar el proyecto inclusive el equipamiento en la locacin del cliente. Dnde se documenta? No El recurso slo est incluido en el cronograma.

humanos,

equipamiento,

necesarios del proyecto?

El equipamiento se solicita a
45

travs de correo. SP 2.5 Se identifican las necesidades de capacitacin de los recursos humanos del proyecto? Cmo? En dnde se de planifican las No

acciones necesarias?

capacitacin

SP 2.6

Se identifican los stakeholders relevantes de todas las fases del proyecto? Cmo se sabe cules son? Dnde se registra el

Si

Como parte de la propuesta se incluye un organigrama del proyecto donde se indican los cargos y lderes de cada rea que estarn involucrados con el proyecto.

resultado de la planificacin?

SP 2.7

Se tiene un plan documentado?

No

SG 3 Obtener el compromiso con el Plan SP 3.1 Se identifican otros planes de los que depende el proyecto? Dnde se documentan para su posterior seguimiento? SP 3.2 Se reconcilia el plan de proyecto con los recursos realmente No El plan de proyecto no se modifica a menos que el No Se identificar pero actividades no son

preliminares

documentadas.

asignados? Qu sucede si no se cuenta con los recursos

cliente decida suspender por algn motivo el proyecto.

estimados? El plan se modifica para acomodarse a la Si no hay disponibilidad de recursos se maneja haciendo uso del en tiempo el adicional

disponibilidad de los recursos?

incluido

cronograma,

pero si este excediera se cubre el retraso con horas de trabajo

46

adicionales.

SP 3.3

Se obtiene el compromiso de los miembros del proyecto, con el plan? Cmo?

Si

Antes de iniciar el proyecto se lleva a cabo una reunin (kick off) con los integrantes del proyecto, en el que se

presenta las metas y objetivos del proyecto, lineamientos

generales, roles, etc. GG 1 Lograr metas especificas GP 1.1 GG 2 Institucionalizar un proceso gestionado GP 2.1 Existe una poltica que indique cmo se debe realizar la No No se realiza actividades para hacer la planificacin. Realizar las prcticas especficas No No se cumplen en su totalidad.

planificacin del proyecto? Las personas que realizan la planificacin conocen esta

poltica? La utilizan? GP 2.2 Las actividades que se realizan durante el plan, se encuentran planificadas? GP 2.3 Se asignan recursos para la planificacin? (plantillas, software, etc.) GP 2.4 Est establecido qu roles estn involucrados en el planeamiento del proyecto, y est documentado quines roles?
47

No

No

No

El planeamiento es realizado por una sola persona.

desempean

estos

GP 2.5

Los roles involucrados en el proceso de planeamiento, han recibido entrenamiento en el

No

La

persona

encargada

del

planeamiento utiliza juicio de experto.

proceso establecido? GP 2.6 Se utilizan mecanismos de No

control (versionado, control de cambios, etc.), a los entregables producidos planeamiento? durante el

GP 2.7

Se conoce a quienes se debe involucrar en el planeamiento del proyecto?

No

GP 2.8

Se

utilizan el

indicadores proceso

para de

No

controlar

planeamiento? GP 2.9 Se revisa la adherencia de las actividades ejecutadas de versus planificacin el proceso No

establecido en la poltica? GP 2.10 Se entera y la Gerencia de del la Si El medio de comunicacin es a travs de las reuniones en las que asiste el jefe del rea e informa sobre el desarrollo de las actividades y los proyectos nuevos que van a iniciar.

progreso

resultados

planificacin de los proyectos?

48

2.5.2.2

Project Monitoring and Control (PMC) (Cuadro 10) Si/No Comentario

PCM Preguntas

SG 1 Monitorizar el proyecto frente al plan SP 1.1 Se hace seguimiento al avance del cronograma, considerando Si Se lleva el control del cronograma considerando el tiempo ofrecido.

avance esperado vs real? Se hace seguimiento al costo y esfuerzo considerando del los proyecto, valores No

esperados vs reales? Cundo existen desviaciones se toman decisiones? Si En caso de haber una desviacin se adiciona horas de trabajo para cubrir en lo posible lo ofrecido. Se documenta el resultado del seguimiento? SP 1.2 Se hace seguimiento a los compromisos del proyecto? Si A travs de definiciones de hitos se involucra a los lderes de cada rea correspondiente para la revisin del desarrollo concerniente en el hito. SP 1.3 Se realiza seguimiento a los riesgos identificados? Se deja evidencia del seguimiento, No No

(considerar aquellos internos y externos)

acciones realizadas y estado de los riesgos en el tiempo? SP 1.4 Se verifica que los se estn Si Como parte de la documentacin del hito se adjunta una hoja de evaluacin para que el cliente indique sus observaciones y/o

produciendo acordados?

entregables

conformidad de la entrega.

49

Se verifica que los entregables de entrada estn siendo

Si

Despus que el cliente revisa la documentacin del hito, alimenta la hoja de evaluacin y luego la enva; esta hoja es recibida como muestra de conformidad o

recibidos?

disconformidad y se utiliza para llevar a cabo una revisin si fuera el caso. Se verifica el cumplimiento de las reglas de resguardo (niveles de acceso, backup)? No La mayora de veces si, pero ha ocurrido en ocasiones que las directivas dadas para el resguardo de la informacin no se ha dado. Se toma accin cuando no se cumple lo establecido? No Se reitera la directiva verbalmente o a travs de correo, indicando la importancia que tiene. SP 1.5 Se hace seguimiento a la Si Algunas tareas como pruebas,

participacin de los stakeholders identificados?

carga de informacin, etc. que figuran en el cronograma tienen una responsabilidad definida a

nivel de rea o empresa. SP 1.6 Se realizan revisiones del de Si Hay reuniones que se desarrollan en el rea de desarrollo donde se exponen los proyectos en curso, posibles inconvenientes. El equipo de proyecto conoce el estado del proyecto? No A las reuniones de control de avance de proyecto asisten los lderes del proyecto mas no todo el equipo. SP 1.7 Se tienen reuniones formales con el cliente y otros stakeholders relevantes para revisar el estado del proyecto en hitos Si Las revisiones son a travs de los hitos, que en se con caso resulte a problemas o

progreso

proyecto

peridicamente?

disconforme reuniones

convoca las

partes
50

predeterminados? Se documenta el resultado?

involucradas de las cuales se generan actas de reunin cuyo detalle indica los puntos fechas en de

disconformidad,

resolucin, responsables y nueva revisin. SG 2 Gestionar las acciones correctivas hasta su cierre SP 2.1 Se registran los problemas del proyecto? Se registran las acciones indicando Si Dentro del esquema del acta de reunin existe un acpite que indica acciones correctivas. Si Se establece reuniones para Si A travs de las actas de reunin.

correctivas,

responsables, fechas, etc.? SP 2.2 Se hace seguimiento a las acciones correctivas

revisar los puntos pendientes y/o acciones comprometidas. No El lder o jefe del proyecto es el encargado de hacer seguimiento a lo que est pendiente, pero no existe un documento tabulado correctivas

establecidas? Se conoce cules son? SP 2.3 El jefe de proyecto se asegura que las acciones correctivas se lleven a cabo? Se actualiza el estado correctivas de y las acciones problemas?

donde se registre los problemas y el estado de cada uno.

Se puede conocer cul es la lista de problemas pendientes de solucionar del proyecto? GG 1 Lograr metas especificas GP 1.1 GP 2.1 Existe una poltica que indique cmo se debe realizar el control del proyecto? Las personas que realizan el control conocen esta poltica y la No No Realizar las prcticas especficas No

No se cumplen todas las prcticas.

Las

formas

de

controlar

un

proyecto son diferentes an siendo del mismo tipo (nuevo desarrollo) En casi un 70% se utiliza una misma forma de realizar algn

51

utilizan?

control, pero depende mucho de la negociacin del tiempo del

proyecto en que esta vare. GP 2.2 Las actividades que forman parte del control, se encuentran Si Dentro del cronograma se definen hitos, alguno de al ellos control estn del

planificadas?

relacionados desarrollo.

GP 2.3

Se asignan recursos adecuados para realizar las actividades de control del proyecto? (plantillas, software, etc.)

No

En algunas ocasiones no se asigna el recurso idneo lo cual es

trascendente por el conocimiento y experiencia que se requiere. No No est especificado. involucradas en Las el

GP 2.4

Est establecido qu roles estn involucrados en el control del proyecto? quines roles? Est documentado estos

personas

mantenimiento y control de los proyectos estn definidas pero

desempean

dependiendo de la carga laboral el rol puede ser llevado por diferentes personas.

GP 2.5

Los roles involucrados en el proceso de control de proyecto han recibido entrenamiento en el proceso establecido?

No

En

algunas

ocasiones

hay

capacitacin al personal que se encargar de brindar el soporte pero no es siempre.

GP 2.6

Se

utilizan

mecanismos

de

Si

Existe

un

procedimiento

control (versionado, control de cambios, etc.), en los entregables producidos o utilizados durante el control del proyecto?

establecido para el control de los cambios realizados en los

proyectos, el cual involucra el registro de las modificaciones y versiones.

GP 2.7

Se conoce a quienes se debe involucrar proyecto? en el control del

Si

Si las actividades de control estn incluidas en el cronograma cada una de ellas tiene asignado un responsable.

GP

Se utilizan indicadores para el

No
52

2.8 GP 2.9

control del progreso del proyecto? Se revisa la adherencia de las actividades de control de No Cada actividad establecida en el cronograma detallado maneja

proyecto ejecutadas versus el proceso poltica? establecido en la

diferentes situaciones que permiten identificar en que proceso se

encuentra (por definir, iniciada, en proceso, etc.) pero no hay

vinculacin con lo establecido. GP 2.10 Se entera y la Gerencia resultados del del Si Se realizan reuniones peridicas en las que se informa el estado de los proyectos.

progreso proyecto?

2.5.2.3

Requirements Management (REQM) (Cuadro 11) Si/No Comentario

REQM Preguntas SG 1 SP 1.1

Obtener una comprensin de los requerimientos Existen criterios para aceptar requerimientos? (ejemplo de No

criterios: plantilla para recibirlos, fuentes autorizadas trminos de a

requerimientos, evitar, etc.)

Se revisan y aprueban los requerimientos?

Si

Los requerimientos se revisan y son plasmados en un modelo conceptual para su aprobacin.

Se mantiene una lista con los requerimientos autorizados? SP 1.2 Existe algn mecanismo que permita obtener el compromiso de los desarrolladores y testers con los requerimientos? Este mecanismo se ejecuta en la prctica?

Si

Se manejan los requerimientos dentro del cronograma detallado.

Si

Se lleva a cabo una reunin para comunicar las especificaciones del proyecto (objetivo, requerimientos, fases, responsabilidades, tiempo)

No

Se ejecuta cuando los proyectos son medianos o grandes.

53

SP 1.3

Se registran los cambios a la lista acordada de

Si

Las modificaciones se detallan la lista inicial de requerimientos, la cual se nombra como una versin 2.

requerimientos?

Se evala el impacto? Por todos los posibles

No

La evaluacin del impacto utiliza juicio de experto, que en ocasiones no satisface lo necesario.

afectados? (desarrolladores, testers) Se registra el impacto? Se hace seguimiento a la aplicacin del cambio? (Se conoce la lista de cambios No No analistas,

pendientes de implementar? SP 1.4 Se puede relacionar los No Actualmente estas relaciones no estn documentadas. Se trabajan plantillas similares a las Caso de uso de sistema pero plantearemos una optimizacin de la plantilla. SP 1.5 Se tienen actividades que que los Si Los cambios aceptados dentro del proyecto son certificados por el cliente, a travs de los hitos de entrega, Cronograma de Proyecto visualiza hitos de atencin de requerimientos programados. Se consideran en el Acta de Constitucin del Proyecto GG 1 GP 1.1 GP 2.1 Lograr metas especificas Realizar especficas. Existe una poltica que indique cmo se debe realizar la gestin No No hay una poltica establecida, pero existen algunos lineamientos
54

requerimientos como los planes, especificaciones funcionales,

casos de prueba y cambios al cdigo fuente?

permitan

asegurar

cambios aceptados estn siendo considerados en el plan?

las

prcticas

No

No se cumplen todas las prcticas.

de los requerimientos?

que son de conocimiento de las personas que tienen la

responsabilidad del desarrollo. Las personas que realizan la gestin conocen cumplen? de esta requerimientos poltica y la Si Como directiva se cumple con las actividades que se desarrollan en el levantamiento de informacin. Se publican en el Boletn

Institucional. GP 2.2 Las actividades de gestin de requerimientos, se encuentran planificadas? Si Dentro del cronograma hay una actividad que se denomina

levantamiento de informacin y aprobacin de requerimientos.

Priorizamos requerimientos en el Cronograma del Proyecto, siendo supervisado por el Gerente del Proyecto. GP 2.3 Cules son los recursos que se utilizan para la gestin de No

requerimientos? Son adecuados y suficientes? Los utilizan? GP 2.4 Est establecido qu roles Si Se definen las personas que

estn involucrados en la gestin de requerimientos? Est documentado quines

cumplirn el rol de analista los cuales sern responsables de esta actividad dentro del cronograma.

desempean estos roles? GP 2.5 Los roles involucrados en el proceso de gestin han de No Vamos a considerar el registro tanto en el Acta de Proyecto como en la Poltica de Gestin de Requerimientos. Se va a crear una Plantilla de Roles. mecanismos de Si Solo a travs de los nombres de los archivos que contienen los
55

requerimientos,

recibido

entrenamiento en el proceso establecido? GP 2.6 Se utilizan

control (versionado, control de

cambios, etc.), a los entregables producidos durante la gestin de requerimientos?

requerimientos.

Se

realiza

por

manejo

de

Versiones, pero por cada cierto nmero o conjunto solicitados de y

requerimientos entregados. GP 2.7 Se conoce a quienes se debe involucrar en las actividades de gestin de requerimientos? No Las personas los

encargadas

de

gestionar

requerimientos

conocen su responsabilidad, pero esta informacin no est distribuida en la organizacin.

GP 2.8

Se utilizan indicadores para controlar la gestin de los

Si

Se

realizan

encuestas avance

de del

satisfaccin

sobre

requerimientos? GP 2.9 Se revisa la adherencia de las actividades de gestin de No

diseo entregado al cliente.

requerimientos

ejecutadas

versus el proceso establecido en la poltica? GP 2.10 Se entera la Gerencia del progreso y resultados de las actividades de la gestin de requerimientos? Si Reuniones de Comit con Jefe de Proyecto y revisin del

Cronograma de Proyecto

56

2.5.3 Presentacin de resultados

Obtuvimos los siguientes resultados generales luego de la primera evaluacin y entrevistas con los miembros de la empresa objeto de estudio.
Porcentaje de cumplimiento Prcticas Prcticas especificas especificas no Acumulado PE vs cumplidas cumplidas PG 31% 50% 47% 42% 69% 50% 52% 57% 20% 43% 52% 43%

rea de proceso PP PMC REQM CM

Los resultados primarios no son alentadores pues la empresa tiene altos niveles de no cumplimiento de las practicas especficas y genricas en los 3 campos de estudio de CMMI para este proyecto.

2.5.3.1

Por cada rea de proceso, porcentaje de prcticas cumplidas y no cumplidas.

Cuadro 12: Practicas cumplidas y no cumplidas para la Planeacin de Proyectos (PP)

rea de proceso: PP

Cumplidas y No cumplidas

100% 80% 60%

40%
20% 0% No Si Total 80% 20%

57

En la figura anterior mostramos que es muy bajo el cumplimiento de las prcticas para el proceso de PP en el Grupo Sypsa S.A. Las oportunidades de mejora y replanteamiento en el proceso en su composicin son diversas. Requerir de un arduo trabajo de equipo y apoyo en la institucin para incrementar el porcentaje de cumplimiento de la prctica y lograr la estandarizacin de acuerdo al modelo.

Evaluamos la prctica PCM para la empresa, logrando los resultados mostrados a continuacin.
Cuadro 13: Prcticas cumplidas y no cumplidas para el Seguimiento y Control de Proyecto (PCM)

rea de proceso: PCM

Cumplidas y No cumplidas

100% 80% 60%

40%
20% 0% No Si Total 57% 43%

Los resultados no son tan crticos como la prctica anterior, sin embargo el lograr el 100% ser una tarea difcil y que la empresa no estara dispuesta a trabajar por el momento. No forma parte de nuestra propuesta de estudio el presentar las propuestas de mejora y

58

las plantillas de apoyo al cumplimiento de las prcticas de este control para el presente proyecto.

Evaluamos finalmente el cumplimiento de las prcticas REQM en la empresa:

Cuadro 14: Prcticas cumplidas y no cumplidas para la Gestin de Requerimiento

rea de proceso: REQM

Cumplidas y No cumplidas

100% 80% 60% 40% 20%

0%
No Si

Total 48% 52%

De igual manera, las practicas REQM tienen alto porcentaje de aplicacin respecto a las de PP, sin embargo existe mucha oportunidad de mejora en la empresa.

59

2.5.3.2

Porcentaje total de prcticas cumplidas y no cumplidas En este cuadro se consolidan los porcentajes de cumplimiento por parte de la empresa sobre las prcticas especficas y genricas utilizando el modelo CMMI.

Cuadro 15: Total Acumulado de Practicas cumplidas y no cumplidas.

Total de Practicas cumplidas y no cumplidas en las tres reas de proceso (PP, PMP y REQM)

Cumplidas y No cumplidas

100% 80% 60% 40%

20%
0% No Si Total 57% 43%

60

2.6 Procesos propuestos.

2.6.1 Proceso de Project Planning (PP) 2.6.1.1 Definicin del Proceso de PP (Cuadro 16)

61

2.6.1.2

Descripcin del Proceso PP (Cuadro 17)

Planeamiento de Proyectos Establecer y mantener los planes que definan las actividades de un proyecto. Desarrollar el plan del proyecto. Interactuar con las partes involucradas. Obtener el compromiso del plan. Mantener el plan del proyecto.

Proceso Propsito Objetivos

Inicio Fin

El proceso inicia con la recepcin del proyecto que enva el rea de ventas. Como resultado del proceso se obtiene el plan del proyecto.

Responsable Gerente de Consultora.

Rol y Abreviacin rea de Ventas

Conocimientos AV Habilidad para establecer relaciones interpersonales, proactividad, capacidad de negociacin y liderazgo. Encargado de coordinar con el cliente la mejor solucin para implementar nuevos desarrollos. GC Muchas veces es un representante del cliente y debe determinar e implementar la satisfaccin y atencin de las necesidades e inquietudes exactas del cliente, basndose en su conocimiento de la firma que representa en el grado de calidad esperado.

Gerencia de Consulto ra

Actividades del Proceso de PP (Cuadro 18) Planeamiento de Proyectos AP1. Entregar proyecto Cod. AP 1.1 Prctica Rol Tarea

AV El AV entrega el proyecto a la GC. AP2. Recibir proyecto

AP 2.1

GC El GC recibe el proyecto del AV. AP3. Evaluar y definir el alcance

62

AP 3.1

GC El GC realiza un anlisis del proyecto para definir su alcance. AP4. Definir secuencia de actividades

AP 4.1

GC El GC define toda la secuencia de actividades a realizarse en el planeamiento. AP5. Preparar el WBS

AP 5.1

SP 1.1

GC El GC divide el proyecto en paquetes manejables que permitan identificar el esfuerzo, las

responsabilidades y el calendario del proyecto. AP6. Estimar el tamao del proyecto AP 6.1 SP 1.2 SP 1.4 AP 6.2 SP 1.3 GC El GC estima los puntos de funcin para calcular el tamao del proyecto. GC El GC definir el ciclo de vida del proyecto. AP7. Estimar el presupuesto del proyecto AP 7.1 SP 2.1 GC El GC identifica los hitos principales, define un cronograma calendarizado, riesgos, y

dependencia de tareas y el presupuesto. AP8. Identificar recursos, roles y responsabilidades del proyecto AP 8.1 GC El GC identifica a las personas involucradas y le asigna un responsabilidad y rol dentro del proyecto. AP9. Elaborar acta de constitucin del proyecto AP 9.1 SP 2.6 GC El GC consolida la informacin del proyecto: objetivos, alcance, fases, organigrama, y costos estimados; con la finalidad de crear el acta de constitucin. AP10. Identificar y evaluar riesgos del proyecto AP 10.1 SP 2.2 GC El GC identifica y analiza los riesgos para determinar el impacto y la probabilidad que ocurra, de esa manera brindar soporte a la
63

planificacin del proyecto. AP11. Conciliar otros planes relacionados AP 11.1 SP 3.1 SP 3.2 GC El GC verifica los planes de otras reas relacionadas al rea de desarrollo, con las cuales el proyecto va intercambiar informacin y

compartir actividades, con el objetivo de integrar los planes de trabajo. AP12. Elaborar el plan de proyecto AP 12.1 GC El GC se encarga de organizar y documentar la definicin de los roles, responsabilidades, riesgos y planes relacionados al proyecto. AP13. Solicitar ambientes y equipo AP 13.1 SP 2.4 GC El GC se encarga de solicitar los equipos, servidores, ambientes de trabajo, accesos, etc. necesarios para el desarrollo del proyecto. AP14. Solicitar recursos humanos AP 14.1 SP 2.4 GC El GC en funcin a la necesidad de recursos identificados para el proyecto solicita al rea de recursos humanos los recursos en caso de no contar con los requeridos. AP15. Seleccionar y contratar AP 15.1 GC RRHH se encargar para de realizar al los

procedimientos

contratar

personal

solicitado para los proyectos en caso sea necesario. AP16. Planificar capacitacin AP 16.1 SP 2.5 GC Si el conocimiento del personal es insuficiente para efectos de involucrarlos en el proyecto El GC organiza un plan de capacitacin que abarque desde la bsqueda del instructor hasta la construccin del syllabus de la capacitacin. AP17. Actualizar plan de proyecto

64

AP 17.1

SP 3.2

GC El GC actualiza la informacin de los recursos, equipos y ambientes asignados al proyecto y las actividades del plan de capacitacin en caso de haberse realizado. AP18. Informar estado del plan de proyecto

AP 18.1

GP 2.10 GC El GC comunica el plan del proyecto a la gerencia general a travs de un correo. AP19. Definir comit de proyectos

AP 19.1

GC El GC define los stakeholders internos y externos que estarn involucrados en el proyecto y las responsabilidades de cada uno. AP20. Preparar reunin kick off

AP 20.1

GC El GC prepara la presentacin que deber contener un resumen del alcance del proyecto.

65

2.6.1.3

Matriz de Trazabilidad de las actividades vs. Practicas especficas de PP. (Cuadro 19)

SP 1.1

SP 1.2

SP 1.3

SP 1.4

SP 2.1

SP 2.2

SP 2.3

SP 2.4

SP 2.5

SP 2.6

SP 2.7

SP 3.1

SP 3.2
X

Actividades

AP 1.1 AP 2.1 AP 3.1 AP 4.1 AP 5.1 AP 6.1 AP 6.2 AP 7.1 AP 8.1 AP 9.1 AP 10.1 AP 11.1 AP 12.1 AP 13.1 AP 14.1 AP 15.1 AP 16.1 AP 17.1 AP 18.1 AP 19.1 AP 20.1

X X X X X X

X X X X X X X X X X X X X X

66

SP 3.3

Practicas Especficas

2.6.2 Proceso de Requirements Management (REQM) 2.6.2.1 Definicin del Proceso REQM (Cuadro 20)

67

2.6.2.2

Descripcin del Proceso REQM (Cuadro 21) Gestin de Requerimientos Efectuar el anlisis de los requerimientos del Cliente. Determinar el alcance de los requerimientos del Cliente. Definir los requerimientos funcionales y los no funcionales. Identificar los casos de uso, los actores y las relaciones entre estos. Priorizar los casos de uso para un mejor avance en el proyecto. Comprometer al equipo del proyecto con los

Proceso Propsito

requerimientos del sistema. Preparar el documento de las Especificaciones Funcionales. Descripcin Este proceso es descrito por las siguientes

actividades: 1. Se establece una reunin en la cual el cliente especifica sus requerimientos. En caso no se de la reunin, el cliente puede proporcionar un documento fsico o un correo electrnico especificando los detalles pero ajustado al formato de Solicitud de Requerimiento. 2. Este requerimiento es recibido por el equipo de

68

gestin de requerimientos (Jefe de Proyecto) quien revisa que la solicitud cuente con el detalle y las especificaciones completas, segn formato, para realizar una adecuada revisin con el objetivo de generar la propuesta adecuada. Si el requerimiento no cumple con el formato establecido (Solicitud de Requerimiento) se enva un mensaje al cliente solicitndole enviar la informacin en el formato establecido. 3. En caso el requerimiento cuente con todo lo necesario se procede a enviar la informacin al analista de sistema para que proceda con el anlisis

correspondiente. 4. Si la solicitud es: un nuevo requerimiento, entonces se procede a elaborar el modelo conceptual que ser enviado al Jefe de Proyecto para su evaluacin. En caso se encuentren algunas observaciones o

documentos insuficientes para poder realizar una propuesta se le informa al cliente la necesidad de mayor detalle o ms informacin que d una mayor precisin del tema. 5. Si la solicitud es: una modificacin sobre un requerimiento, el analista procede a evaluar los cambios, si se acepta la evaluacin se procede a verificar los requisitos directamente afectados, luego

69

se procede a generar la propuesta del cambio y elaborar un informe de impacto el cual ser enviado al cliente, este documento es registrado en una lista de cambios. 6. Si la propuesta de cambio no es aceptada se genera un informe de evaluacin y se remite al Jefe de Proyecto para su envo al cliente. 7. El Jefe de Proyecto revisa la propuesta con los requerimientos y observa en caso alguno de ellos sea ambiguo o no se entienda, en caso que las observaciones no puedan ser resueltas por el equipo se convoca a reunin con el cliente para poder cerrar las dudas que se tengan. 8. Una vez que el documento est sin observaciones y cumpla con todas las requisitos del requerimiento, el Jefe de Proyecto enva el documento de Atencin de Requerimiento al cliente para su validacin

correspondiente y as obtener la aprobacin del requerimiento para su pase al rea correspondiente. 9. Si el documento es observado por el cliente, este es enviado al equipo de requerimiento para su

evaluacin y correccin correspondiente. Una vez que se han levantado todas las observaciones reportadas por el cliente se hacen los ajustes necesarios para que el documento sea enviado nuevamente al Jefe de

70

Proyecto. Finalmente se entrega el documento de especificaciones funcionales al cliente a fin de validar su entendimiento y lograr la aprobacin de este documento el cual ser la base para el diseo de sistemas. 10. Una vez obtenida la aprobacin del cliente se

procede a registrar el requerimiento aprobado, luego se procede a elaborar el cronograma de desarrollo del requerimiento (se elabora un cronograma detallado con todas la actividades que se van a implementar y el cual ser utilizada por el Jefe de Proyecto, el analista y los desarrolladores, adems de un

cronograma resumido para poder llevar un control por parte de la gerencia.). Tambin se procede a generar un organigrama con informacin de los integrantes que estarn a cargo de la implementacin del requerimiento, esta informacin estar registrada en un acta de compromiso. Objetivos Optimizar la gestin de requerimientos en la empresa. Lograr que los requerimientos de cliente sean claramente comprendidos para tener en claro el alcance del mismo y general una propuesta ptima. Desarrollar los requerimientos hasta un nivel de detalle que permita identificar con facilidad los componentes del producto que permitir satisfacer las

71

necesidades del cliente. Inicio Inicio de un nuevo proyecto. Contrastar los requerimientos del cliente con el detalle obtenido de los mismos. Fin Cuando el requerimiento es atendido. Esta gestin se da en cualquier parte del proyecto general si el requerimiento forma parte de un proyecto. Responsable Jefe de Proyecto: Responsable de la gestin de los requerimientos. Evaluar el documento de anlisis del equipo de desarrollo que resumen la comprensin de la solicitud y que ser enviada al Cliente para su revisin y autorizacin. Analista Funcional: Responsable de realizar el anlisis de los requerimientos del Cliente y plasmarlos en los Casos de Uso. Cliente: Quien solicita un requerimiento nuevo o la modificacin a un requerimiento anterior.

72

2.6.2.3 Rol y

Roles y conocimientos esperados en REQM (Cuadro 22) Conocimientos

Abreviacin Cliente Analista Funcional Jefe de proyecto JP AF Aplicaciones de la empresa. Preparacin de Solicitud de Requerimiento. Conocimiento Mtodos Agiles. Preparacin de documentos funcionales. Nivel alto de capacidad de anlisis. Poder de negociacin y paciencia. Liderazgo, seguridad. Poder de negociacin, conocimientos de RUP, UML. Manejo de equipos de trabajo. RUP, UML, herramientas Case,

Actividades del Proceso REQM (Cuadro 23) Requerimientos de Desarrollo: Nuevos Proyectos AR1. Solicitar Requerimiento Cod. AR 1.1 AR2.Levantar informacin sobre Requerimiento AR 2.1 AR GP 1.1 JP El Jefe de Proyecto recibe la solicitud de requerimiento y revisa la validez del formato. JP Si el formato no es correcto, Solicita el envi del Prctica Rol SP 1.1 C Tarea El cliente enva requerimiento para ser atendido.

73

2.2

Formato valido de la Solicitud de Requerimiento. AR3. Registrar Requerimiento

AR 3.1

SP 1.1

AF Si el requerimiento ha sido solicitado en el Formato Valido registrado en la Poltica de Gestin de Requerimientos, entonces se procede a Registrar la Solicitud del Requerimiento para su posterior anlisis de atencin. AR4. Analizar Requerimiento

AR 4.1

SP 1.1

AF El Requerimiento se analiza para conocer si es un nuevo requerimiento o es un cambio a un

requerimiento solicitado previamente o cambio de algn grado de impacto en el sistema. AR5. Elaborar Modelo Conceptual AR 5.1 SP 1.4 AF Si es un nuevo requerimiento, se elabora un modelo conceptual para asegurar la comprensin de la solicitud. AR6. Anlisis y Validacin de cambio AR 6.1 SP 1.3 AF Los Requisitos sern verificados ante alguna

afectacin frente a un cambio solicitado por algn requerimiento.

AR 6.2

SP 1.3

AF El Analista Funcional trabajara una propuesta de cambio, sealando lo analizado del requerimiento solicitado

AR 6.3

SP 1.3

AF Se elabora un informe del impacto que el cambio puede generar en el desarrollo.

74

AR 6.4

SP 1.3

AF Se registra el cambio y el impacto en la Lista de cambios, tanto para conocer lo que se trabaja y los cambios pendientes de implementacin

AR 6.5

AF Si el cambio es rechazado termina la actividad. Si es aprobado se le enva al Jefe de Proyecto para que Evalu la propuesta y continua el flujo. AR7. Evaluar propuesta

AR 7.1

JP Evala la propuesta de atencin de requerimiento o el anlisis del impacto de un cambio solicitado, arma una Atencin de Requerimiento y se lo enva al cliente para su aprobacin. AR8. Recibir propuesta de atencin de Requerimiento

AR 8.1

El cliente analiza la comprensin de la solicitud por ser atendida y procede con la aprobacin de la propuesta para que siga su curso. AR9. Registrar Requerimiento Aprobado

AR 9.1 AR 10.1

SP 1.1

JP Se registra el requerimiento con la aceptacin del cliente y se actualiza la lista de requerimientos.

SP 1.2

JP Se actualiza la Lista de Requerimientos para mantener actualizada la informacin. AR10. Elaborar Cronograma de Desarrollo

AR 10.1

SP 2.2

JP Se elabora el cronograma de desarrollo para tener actualizada la informacin y que ninguna actividad se desfase de la planificacin del proyecto.
75

AR 11.1

SP 1.5

JP Se actualiza el cronograma tanto resumido como detallado. Se considera la inclusin de los cambios aceptados por atender.

AR 12.1 AR 13.1

GP 2.4 JP GP 2.2 JP

Se detallan los involucrados en la atencin del requerimiento Se verifica la inclusin de todas las actividades de la gestin de requerimientos AR11. Desarrollar Organigrama del Proyecto

AR 11.1

SP 1.2

JP Se verifica la inclusin de los recursos del proyecto. Se asegura los integrantes para la atencin de la gestin de requerimientos.

AR 12.1

SP 1.2

JP Se elabora el Acta de Reunin AR12 Informar a Gerencia del proyecto

AR 12.1

GP 2.10 JP Se enva toda la informacin de las actividades de gestin de los requerimientos.

76

2.6.2.4

Matriz de Trazabilidad de las actividades vs. Practicas especficas de REQM

Cuadro 24: Matriz de Trazabilidad REQM

Actividades AR 1.1 AR 2.1 AR 2.2 AR 3.1 AR 4.1 AR 5.1 AR 6.1 AR 6.2 AR 6.3 AR 6.4 AR 6.5 AR 6.6 AR 7.1 AR 8.1 AR 8.2 AR 9.1 AR 9.2 AR 10.1 AR 10.2 AR 10.3 AR 10.4 AR 10.5 AR 11.1 AR 11.2 AR 11.3 AR 12.1

X X X X X X X X X X X X X X X X X X X X X X X X X X X X

77

GP 2.10

GP 1.1

GP 2.1

GP 2.2

GP 2.3

GP 2.4

GP 2.5

GP 2.6

GP 2.7

GP 2.8

GP 2.9

SP 1.1

SP 1.2

SP 1.3

SP 1.4

SP 1.5

Practicas Especficas

2.7 Conclusiones.
De acuerdo al resultado de anlisis realizado para determinar el grado de cumplimiento y no cumplimiento de las prcticas en las tres reas de proceso (PP, PCM y REQM), se determina que se requiere ms del 50% de esfuerzo de la Organizacin para obtener procesos eficaces. La evaluacin de las tres reas del proceso (PP, PCM y REQM) permitir tener una oportunidad para corregir o modificar los

procesos de software que han perdido su desempeo por el paso del tiempo. Se debe de implementar una poltica o normativa que permita cambiar la actitud del personal frente a los nuevos procesos que se estn implementando en la compaa. Fomentar la integracin entre todos los integrantes de la compaa, mediante reuniones de coordinacin donde cada uno podr aportar ideas en beneficio de todos los colaboradores. Incentivar la formacin de una cultura organizacional, enfocada en cumplir con las expectativas de los clientes. Implementar nuevas tcnicas o metodologas que ayuden a los colaboradores a aumentar la productividad, efectividad y utilidad de la empresa, as mismo continuar con la poltica de mejora continua en los procesos de software y servicios. La definicin del proceso de planificacin es de vital importancia en el ciclo de vida del proyecto, ya que al culminar el proyecto permitir evaluar lo real con lo estimado.
78

CAPITULO III

METODOS AGILES PARA EL DESARROLLO DE SOFTWARE

3. Aplicacin de Mtodos Agiles en empresas de desarrollo de software

3.1

Introduccin
Desde hace un tiempo nos estamos enfrentando a grandes cambios en todos los sectores de la industria, La ventaja competitiva est dada por el grado de conocimiento, informacin y habilidad para enfrentarse a los cambios que exige el mercado, por encima de otros factores claves como la calificacin del personal o los recursos logsticos. La aparicin continua de nuevos productos y servicios, nos obliga a incrementar la productividad y disminuir el tiempo de reaccin, adaptarse rpidamente a las necesidades de los clientes y aumentar la capacidad de competir en un mercado mucho ms amplio. En este escenario las metodologas giles aparecen como una opcin atractiva pues se centran en habilidades de prediccin

79

que perciben cada respuesta al cambio como una oportunidad para mejorar el sistema e incrementar la satisfaccin del cliente.

Dainko S.A. y CSC Consulting SAC permitirn nuestro ingreso a sus instalaciones y equipos de trabajo para poner a prueba la implementacin de las prcticas TaskBoard del Scrum, Daily Meeting y Pair Programming.

Dainko S.A. se caracteriza por los desarrollos en plataforma 2.0 direccionadas a soluciones de Redes Sociales Corporativas, Portales e Intranets, Social Learning, Aplicaciones

Administrativas propietarias en Gestin y Desarrollo Humano, Tramite documentario, Inteligencia de negocios, Aplicaciones basadas en Business Process Management (BPM), Desarrollo en .Net y Cloud Computing, etc.

CSC Consulting SAC es una empresa que brinda soluciones informticas cuya especialidad es el Testing, Diseo de Procesos, Estandarizaciones, Modelamientos y puestas en marcha de base de datos corporativas, Control de Calidad sobre software. Son representantes de la lnea de Rational para IBM. Hace poco han puesto en marcha los servicios de Gestin de la Infraestructura para empresas medianas, esto incluye,

virtualizaciones y optimizacin de recursos informticos como nueva lnea de negocio.

80

Aplicaremos en Dainko las prcticas de Daily Meeting y TaskBoard para los 6 proyectos de desarrollo de software que tienen en curso actualmente; y tambin aplicaremos TaskBoard en CSC Consulting as como la puesta en prueba de Pair Programming para un proyecto con el Banco Interbank. Dichas prcticas no son conocidas en las empresas, pero ellas han permitido mejorar la gestin de los proyectos de desarrollo de software, sustentados por el resultado obtenido de aplicarlas.

3.2 Fundamentacin Terica

Las metodologas giles son en general muy simples en su composicin, sin embargo sus fundamentos tericos y los valores en los que se fundamentan tienen implicaciones que van ms all de la simplicidad de sus componentes. En este tipo de forma de trabajo, lo que se tiene en cuenta en primer lugar es a las personas, estas son las que aceptan o no los cambios constantes en todos los aspectos del trabajo, son las que se hacen responsables y comienzan a tomar decisiones sabiendo las implicancias de ellas, son las que pueden transformarse y aprender constantemente para elevar su trabajo y apuntar a la excelencia en forma constante.

El enfoque gil para desarrollar software tiene sus orgenes en los principios de la manufactura Lean inventada por Toyota y la transferencia de estos al mbito del software. En un proyecto
81

gil se emplean ciclos cortos involucrando al cliente para definir y priorizar requerimientos con el objetivo de que, a travs de la colaboracin con el equipo de desarrollo, se disponga de un producto potencialmente entregable al final de cada iteracin.

A principios de la dcada del 90, surgi un enfoque que fue bastante revolucionario para su momento ya que iba en contra de toda creencia que mediante procesos altamente definidos se iba a lograr obtener software en tiempo, costo y con la requerida calidad. El enfoque fue planteado por primera vez por Martin y se dio a conocer en la comunidad de Ingeniera de Software con el nombre de RAD o Rapid Application Development. RAD consista en un entorno de desarrollo altamente productivo, en el que participaban grupos pequeos de programadores utilizando herramientas que generaban cdigo en forma automtica tomando como entradas sintaxis de alto nivel. En general, se considera que este fue uno de los primeros hitos en pos de la agilidad en los procesos de desarrollo.

Daily Meeting: El objetivo principal de esta prctica es organizar una reunin que facilita la transferencia de informacin y la colaboracin entre los miembros del equipo para aumentar su productividad. Cada miembro del equipo informa de las actividades que realizo, est realizando as como los problemas

82

o inconvenientes que se presentaron durante el desarrollo de sus actividades.

Cada miembro del equipo debera responder las siguientes: Qu he hecho desde la ltima reunin de sincronizacin? Pude hacer todo lo que tena planeado? Cul fue el problema? Qu voy a hacer a partir de este momento? Qu impedimentos tengo o voy a tener para cumplir mis compromisos en esta iteracin y en el proyecto?

3.2.1 Beneficios

Aumentar la productividad en el proyecto y potencia el compromiso de equipo, dado que cada miembro pone de manifiesto delante del resto:
o

Las tareas que pueden afectar a otros miembros del equipo, por que impactan en su trabajo o porque hay dependencias (especialmente si existe un retraso).

Los impedimentos con que se encuentra. El resto de miembros del equipo pueden ofrecer ayuda a otros en la realizacin de tareas o para resolver problemas que ya tuvieron anteriormente. El Facilitador (Scrum Master) se encargar de solucionar los impedimentos que el equipo no puede solucionar por s solo o que le quitan tiempo para cumplir con su compromiso fundamental de desarrollo de requisitos.
83

Las tareas no planeadas que est realizando que el equipo no conoce y puede que no estn alineadas con el compromiso del equipo, aunque l crea que lo que est haciendo es lo mejor que se puede hacer.

Cules son sus necesidades. Cada miembro entiende las necesidades de los otros miembros del equipo respecto a su trabajo, de manera que pueden colaborar y adaptar sus trabajos para que den el mximo valor y no realizar tareas que no proporcionan ningn beneficio al resto del equipo.

Cul es su ritmo de trabajo. Se hace visible si de manera continua un miembro del equipo est realizando tareas por debajo del rendimiento esperado. Se evita que una persona seale con el dedo a otra, dado que la reunin de sincronizacin pone a todos los miembros del equipo en la misma situacin de tener que explicar en qu tareas estn trabajando.

Cules son los criterios que est utilizando para realizar sus tareas, de manera que estn alineados con los objetivos comunes del equipo.

Fomentar el aprendizaje de los miembros del equipo, ya que pueden ver cmo trabajan los otros segn sus especialidades y experiencias.

84

Conocer el estado de la iteracin, ver si es posible completar los requisitos a que se comprometi el equipo, en vista de las desviaciones y de las tareas pendientes.

3.2.2 Restricciones

La reunin diaria de estado y sincronizacin del equipo no es para resolver problemas, los problemas se resuelven despus de la reunin.
o

No a todos los miembros del equipo les interesan todos los detalles de cada tema.

En la reunin los miembros del equipo programan reuniones entre ellos donde colaborar sincronizando tareas, ayudando a resolver problemas, etc.

No puede haber una persona explicando su estado mientras otras "se han apartado" de la reunin para comentar un tema particular. Si apareciese alguna conversacin de inters comn (que debe ser rpida), debe poder ser escuchada por todo el equipo sin distraer el principal objetivo de que todos conozcan en qu estn trabajando los dems. Si la mini conversacin no es del inters de todos, debe hacerse despus de la reunin.

El equipo debe contar con unos criterios consensuados sobre el proceso de ejecucin de las de tareas

85

El

proceso

de

ejecucin

de

las

tareas

debe

estar

consensuado para evitar que cada reunin sea una exposicin de discrepancias entre los miembros del equipo.

3.3 Adopcin de Prcticas Agiles

3.3.1 En Dainko S.A.

3.3.1.1

Taskboard Scrum en Dainko S.A.

A. Sprint 1 (i) Anlisis de la situacin actual Antes de la implementar del Taskboard Scrum, la compaa realizaba el control de todas sus actividades de forma tradicional (cronograma de proyecto), este mtodo permita llevar un control al jefe de proyecto, pero los integrantes del equipo de desarrollo no tenan la informacin del estado de las actividades y quien estaba a cargo. Si un integrante del grupo necesitaba esa informacin deba recurrir obligatoriamente al archivo del cronograma del proyecto, el cual se ubicaba en su PC o en el directorio asignado al proyecto.

En un primer momento el Jefe de Sistemas no estaba de acuerdo con la implementacin de esta metodologa debi a la

86

carga laboral que se tena en ese instante, motivo por el cual se procedi con la elaboracin de tablero de forma reservada. Luego de unos das se procedi a mostrar el tablero a los integrantes de grupo, se explic su funcionamiento y todos estaban de acuerdo que era de utilidad para el desarrollo y cumplimiento de las actividades programadas. Nos abrieron la oportunidad de implementar en un periodo corto de tiempo a manera de prueba.

(ii) Resultado Esperado Con la implementacin del Taskboard Scrum se logra tener un mejor control de todas las actividades que se desarrollan en el da, mediante la asignacin de actividades y su distribucin en el tablero se logr tener una visin ms amplia y rpida de las actividades que se deban de realizar, la secuencia y asignacin del personal por cada una de dichas actividades y el estado o avance de cada una de ellas.

Esta herramienta era entendida como un radiador de informacin amigable para todos los integrantes del equipo de trabajo.

87

B. Sprint 2 (i) Planificacin Como actividades previas a la ejecucin del Taskboard se procedi a elaborar las actividades que estaran incluidas en el tablero, los integrantes del equipo que participaran en el desarrollo de cada una de las actividades. Se definir el lugar en el cual estara ubicado el Taskboard, as como el material necesario para su elaboracin. (ii) Ejecucin Se procedi con la elaboracin de una plantilla en base al modelo propuesto para la aplicacin de esta prctica. Se planificaron las actividades que van a ser asignadas a cada integrante del equipo.

En el Taskboard, se colocaron actividades correspondientes a 6 proyectos que se estn desarrollando actualmente en la empresa: Anaranjado: Actividades del Proyecto de FaceMarket Celeste: Actividades del proyecto de Natclar Online. Amarrillo: Sistema Integral de Desarrollo Humano Blanco: Tunki - Red Social Corporativa de Grupo Interbank. Rosado: Natclar Portal y sub portal.

88

Cuadro 25: Registro de Actividades en el Taskboard

Cuadro 26: Taskboard de la Compaa Dainko S.A.

En el Tablero se observa la distribucin de columnas por hacer, haciendo, por verificar y Completado. Al margen izquierdo el nombre de los integrantes, divisin que es importante de definir para medir carga laboral y responsabilidades.

89

Ntese que no se tienen muchas actividades en etiquetas, y esto responde a que la empresa colocaba en conjunto varias actividades que despus serian importantes desglosar.

Existe una fila en vacio, que refiere al registro de actividades del practicante que sera contratado justo la semana de inicio de la prctica. Nos solicitaron presentar as el tablero.

Se trabaj todos los das la reunin de planificacin y revisin para monitorear y producir los movimientos de tareas en el tablero. El sprint 2 culmin en la versin que muestra la imagen anterior.

(iii) Retrospectiva

La implementacin de sta prctica ayud a mejorar la visin global de todas las actividades del proyecto. En la elaboracin del primer Taskboard se procedi a colocar actividades con un tiempo de ejecucin de una semana, motivo por el cual no se pudo ver reflejado el progreso de los avances en forma diaria. La primera semana en la cual se implement este prctica no se consider a todos los integrantes del grupo, solamente se realiz una prueba piloto con tres integrantes.

90

 Para poder identificar las actividades y el proyecto al cual pertenecan se procedi a identificar con un color determinado a cada actividad, este color estaba asociado con un proyecto especfico. C. Sprint 3 (i) Planificacin Se procedi a elaborar una revisin de las actividades que estaban incluidas en el ltimo sprint. Se revisara que las actividades estn agrupadas por proyectos y se recomend colocar un timing por cada una de ellas para as no superar la programacin del sprint ms tiempo de lo permitido. Cada actividad no debera tomar ms de 8 horas, si se diera el exceso de proyeccin se procedera a dividir dicha actividad en otra actividad. Se planteo una estrategia simple para la estimacin de las actividades, se tomo referencias de labores anteriores y recomendaciones de los miembros del equipo.

De la retrospectiva del ltimo entregable surgi la idea de confeccionar un sello para estamparlo al Post-it, con informacin relevante de la actividad y que debera constituir desde ese momento como un estndar a completar por la persona responsable de ella. Se inicio as la primera iteracin del sprint 3.

91

(ii) Ejecucin Se procedi a realizar los mismos pasos que el proceso de la semana anterior con la nica variacin que en sta iteracin las actividades son como mximo de 8 horas con lo cual se puede apreciar mejor el movimiento de las actividades en el tablero Taskboard.

Cuadro 27: Ejecucin de TaskBoard en Sprint 2

(iii) Retrospectiva

Se not una mayor participacin e inters de todos los integrantes del equipo de desarrollo. Se presentaron propuestas de mejoras para modificar la estructura del tablero. Sera necesario colocar un medidor de avance en el tablero y se elaborara los grficos de avance para el siguiente sprint. El equipo aprendi que la prctica es una herramienta ideal para el control de avance y entregables al cliente.

92

Cuadro 28: TaskBoard al finalizar Sprint 3

93

3.3.1.2

Daily Meeting en Dainko S.A.

A. Sprint 1 (i) Anlisis de la situacin actual Antes de implementar Daily Meeting, la compaa realizaba reuniones semanales con una duracin aproximada de 6 horas, donde participaban todos los integrantes del rea de sistemas.

Cada uno realizaba un informe detallado de las actividades que desarroll, las pendientes, en ejecucin y concluidas, adems de presentar un informe con todos los problemas o inconveniente que se present en su desarrollo. Estas reuniones frecuentemente demandaban una gran cantidad de tiempo, debido a que todos los integrantes tenan que presentar sus informes y acostumbrarse a disponer del tiempo para plasmar dicha informacin en un documento. Adicionalmente se realizaban reuniones semanales de 2 horas para exponer el estado de los proyectos y emitir un informe con las actividades que estn realizando. Se tena que definir el horario de todos los das a las 10 am, por un lapso de 15 a 20 minutos para las reuniones de Daily Meeting que formaran parte de esta experiencia. Llegaron a un consenso y aceptaron la disposicin para iniciar el primer sprint.

94

(ii) Resultado Esperado Con la implementacin del Daily Meeting se lograra mejorar la comunicacin entre todos los integrantes del equipo. Cada integrante del equipo realiza un informe oral de las actividades que realiz, las que van a realizar y los problemas que tuvieron que resolver.

Esto ayud a que todos los integrantes del equipo estn enterados de las actividades que estn realizando cada uno, adems aportar ideas ante los problemas que estn siendo comunicados.

B. Sprint 2 (i) Planificacin Se planifica realizar las reuniones en el mismo ambiente de trabajo a las 10 de la maana con la participacin de los integrantes del equipo de desarrollo. Los miembros del equipo ya tendran claro las preguntas que se trabajaran en la reunin para as no perder tiempo y lograr el resultado esperado.

95

(ii) Ejecucin Se realiza la reunin con la participacin de todos los integrantes del equipo de desarrollo, cada uno de ellos da su informe de las actividades que tiene asignado.
Cuadro 29: Daily Meeting con el equipo de Dainko

Hubo un primer retraso puesto que no es parte de la cultura laboral trabajar un horario especfico y rutinario para esta informacin, sin embargo se logro el objetivo durante toda la duracin del sprint.

Se pregunt a cada miembro del equipo: Que fue lo que avanz el ltimo sprint? Que aprendi de esta iteracin y que obstculos tendra para continuar. Con ello se aseguraba el cumplimiento de las actividades proyectadas al terminar el sprint.

Todos se mostraron colaboradores y les pareci interesante la prctica implementada para mejorar la comunicacin de los avances. Existieron algunos reuniones en que no participaban
96

todos los miembros de equipo pero de todas maneras se realizaba la revisin diaria. Esto no podra retrasar el objetivo planteado para introducir la prctica en la empresa. Fuimos apoyados por el director de la empresa en esta decisin. (iii) Retrospectiva En esta primera semana que se implement esta prctica en la compaa, se pudo apreciar que el equipo de trabajo estaba un poco sorprendido que se realizara una reunin de coordinacin de 15 minutos en la cual podran indicar las actividades que estaban haciendo, los problemas que se estaba presentando y buscar soluciones en conjunto, una vez que se explic el motivo de estas reuniones todos estaban de acuerdo con ellas. No se pudo respetar el horario de la reunin, debido a las actividades de cada uno de los integrantes del equipo, motivo por el cual algunas veces no todos los participantes podan acudir a la reunin. Las reuniones se realizaron en el mismo lugar de trabajo y no parados como se indica en la teora. Esto no present consecuencia alguna por que el equipo de trabajo es pequeo (4 personas) sin embargo la conversacin no se daba cara a cara dificultando el entendimiento y trabajo en equipo bajo comunicacin clara y confiable.

97

 Es necesario incentivar a los miembros de equipo en la importancia de la aplicacin de la prctica y que no vieran el tiempo como un desperdicio sino como una inversin para el cumplimiento ptimo de las actividades programadas.

C. Sprint 3 (i) Planificacin Se planifica realizar las reuniones en el mismo ambiente de trabajo a las 10 de la maana para que puedan estar presentes todos los integrantes del grupo de trabajo. No se debera variar el horario pues tendran que acostumbrarse a ello. En esta segunda interaccin se considera la participacin de todos los integrantes del equipo de trabajo.

(ii) Ejecucin Se realiza la reunin con la participacin de todos los integrantes del equipo de desarrollo, cada uno de ellos da su informe de las actividades que tiene asignado. En esta segunda interaccin participaron todos los integrantes del equipo de desarrollo. Se resuelven las mismas preguntas por cada integrante y se obtiene una perspectiva mejor del trabajo en los proyectos. Los compromisos se afianzan.

98

(iii) Retrospectiva Se logra una mayor participacin de todos los integrantes de equipo de trabajo. Se logr cumplir con el tiempo estimado de 15 minutos. Acordaron generar el acta de la reunin con la informacin proporcionada por cada uno de los participantes, la cual servir para generar un informe de las actividades que se presentaran en la reunin de fin de mes.

Cuadro 30: Sesin Daily Meeting Sprint 3

99

3.3.2 En CSC Consulting SAC

3.3.2.1

Pair Programming en CSC Consulting SAC

A. Sprint 1 (i) Anlisis de la situacin actual En CSC Consulting se tienen varios proyectos de desarrollo en cartera. Uno de ellos es el proyecto de Control de Calidad sobre el servicio que brinda Dainko al Banco Interbank, esto es, la optimizacin de la aplicacin Red Social Tunki y su puesta en marcho bajo el marco de Cloud Computing.

Como parte del servicio de QC, la empresa CSC debe realizar un acompaamiento in situ de los entregables presentados a la gerencia de proyecto de la empresa de servicio, previa a la reunin de revisin con el cliente. CSC es contratada directamente por el banco para realizar esta labor de seguimiento. Para ello trabajaran los jefes de desarrollo en la revisin del cdigo y optimizacin del rendimiento de la aplicacin.

100

Cuadro 31: Plataforma Tunki Banco Interbank

Para este trabajo, hemos considerado realizar la tcnica de Pair Programming para el mejoramiento de la Actualizacin de Registros de Cliente en la plataforma. Encontramos un punto de quiebre para realizar la revisin de cdigo entre el jefe de desarrollo del outsourcing (Dainko) y la jefe de proyecto de QC. (ii) Resultado Esperado Esperamos con esta prctica, el aseguramiento del cdigo de la plataforma, eliminando cdigo basura, redundancias, excesos de programacin y pesadez en la produccin de la aplicacin. La presencia del jefe de proyecto de QC permite la transmisin de conocimiento para una mejora y establecer una comunicacin entre desarrolladores de tal manera que la aplicacin sea optimizada.

101

B. Sprint 2 (i) Planificacin Al iniciar el Sprint decidimos tener unos minutos para la planeacin del trabajo de revisin de la iteracin que tenemos que concretar. Definimos los puntos que revisaremos, el cdigo fuente de la tarea a realizar y qu mejoras se realizaran. Revisaremos tambin la base de datos del sistema y las reglas de negocio en caso aplique.
Cuadro 32: Previos a la iteracin de Pair Programming Sprint 2

En esta reunin de planificacin nos comprometemos a completar la iteracin bajo los requisitos planteados y aprobados por nosotros. Este objetivo no lo podremos replantear sino hasta terminar el sprint.

102

(ii) Ejecucin Iniciamos la iteracin 2 con los pasos de revisin de las pantallas de la aplicacin en ejecutable. Revisamos que las

funcionalidades estn operativas y verificamos los posibles errores de ejecucin.

Cuadro 33: Revisin de ejecutable sesin Pair Programming

Verificamos que las pantallas de ingreso de usuarios, validacin de base de datos y apertura de perfil de usuario no tenan problema en su ejecucin. Sin embargo al revisar el punto de comentarios en red social, observamos un error. Atacamos dicho error que significaba que el sistema daba error cuando se ingresaba una denuncia en la red social Tunki, sta no se actualizaba en los mensajes de los dueos del comentario y tampoco en los perfiles de los auspiciadores. Al parecer, cuando se corra la aplicacin en red local no exista el error; sin embargo, al colgar el cdigo y levantar el sistema en el cloud o en la nube daba error esta sub-tarea.

103

El jefe de QC sugiri revisar las libreras del cdigo pues al parecer ese era parte del error. Debera existir alguna librera que no sea reconocida al subir la aplicacin al cloud. Este sera un punto a revisar para la iteracin siguiente.

El desarrollador realizo una prueba en un cdigo pequeo de otro programa solo para descartar el problema detectado con la librera. Tambin dio error de ejecucin en el cloud. Por tanto quedo claro que la participacin de ambos, y los conocimientos de nosotros como ingenieros de software, permiti que por PP se detecte un error importante y que exigir una investigacin de concepto para que el entregable sea el ptimo.

(iii) Retrospectiva La retrospectiva empieza cuando se cerr la iteracin 2. Nos reunimos nuevamente para especficamente resolver las

preguntas recomendadas por la prctica: que funciono en la iteracin?, que se aprendi?, plan de accin para la siguiente operacin y que obstculos tendramos para la siguiente entrega?

Se anotan los problemas detectados en un cuadro de Excel y detallamos las caractersticas del error. Planificamos cual sera el tiempo disponible para la investigacin que tomara resolver el tema de la validacin de las libreras en el cloud y si esta
104

investigacin se dar antes o durante la ejecucin de la iteracin 3. Revisamos el plan de accin para el siguiente entregable, definimos actividades y discutimos los tiempos de ejecucin de las tareas. Nos comprometimos en desarrollar un documento sobre la reunin de retrospectiva. Declaramos los posibles obstculos, como por ejemplo lograr el entendimiento del nuevo entorno de trabajo virtual y cuanto demoraramos en las pruebas para que el siguiente entregable no presente errores.

C. Sprint 3 (i) Planificacin Luego de la reunin de retrospectiva obtuvimos la base para planificar las actividades de la iteracin 3. La reunin de planificacin dur por 10 minutos puesto que no tendramos mucho tiempo para la reunin de ejecucin.

Cuadro 34: Reunin de planificacin Sprint 3 Pair Programming

105

Revisamos el acta de la retrospectiva del sprint 2 y generamos un cuadro gil para los puntos que trabajaremos en el siguiente entregable. Colocamos prioridades de revisin por los puntos error de la anterior iteracin y los puntos a trabajar para generar un nuevo avance del producto final para la iteracin 3.

(ii) Ejecucin Iniciamos la sesin de revisin y lo primero que hicimos fue verificar la validacin de las libreras del cdigo para el nuevo entorno virtual. Sabamos que si sta primera revisin no daba resultado positivo, no tendra caso continuar con la iteracin pues las dems tareas dependan de que el cdigo funcione. Hay que anotar que no era fcil decidir la cancelacin del sprint en medio proceso pues eso traera problemas con entregables anteriores o con el resultado del entregable esperado para el nuevo sprint.
Cuadro 35: Revisando conceptos Cloud Computing y Gestin de Libreras

106

Si bien es cierto hubo los problemas de validacin en el sprint 2, esto no fue perjudicial al resultado de dicho sprint pues lo que pidi el cliente para tal sprint fue que el cdigo corra a nivel local y no solicito que ese entregable ya funcione para el entorno virtual.

Logramos validar las libreras para el cloud y lo que quedaba por revisar en conjunto, era el cdigo para la validacin de comentario y el colgar aplicaciones ya hechas como link en el entorno del Tunki. La tarea fue exitosa.
Cuadro 36: Turno de QC para modificar cdigo.

Se agregaron las dems funcionalidades planificadas como agenda y calendario individual y compartidas de (por) usuario (s) y se logr ejecutar. Con esto se cerr la iteracin 3 y se entrego el subproducto al cliente. QC valid la entrega.

107

(iii) Retrospectiva Esta iteracin fue ms fcil de administrar por los ingenieros de software pues entendimos que no era una revisin sosa ni prdida de tiempo el realizar Pair Programming, sino que es a veces mejor pensar entre dos cuando nos entrampamos en un error que nos podra quitar el tiempo para lograr el entregable.

Ya no elaboramos un Excel para documentar lo observado, sino, desarrollamos una comunicacin cara a cara ms activa y divertida pues ya entendimos mejor como ejecutar esta prctica gil.

108

3.3.2.2

TaskBoard Scrum en CSC Consulting SAC

A. Sprint 1 (i) Anlisis de la situacin actual Debido a que se tena que documentar los proyectos que sern delegados a otro gerente de proyecto, considere esta prctica como lo ms gil y rpida de entender y explicar al sucesor. Me encuentro en proceso de cambio laboral y estoy delegando la administracin del proyecto Implementacin de Data Center en el cliente CSC SAC al nuevo equipo de trabajo. El Taskboard de Scrum apoy la delegacin de las tareas y seguimiento de manera rpida y clara. La empresa no tena experiencia en la prctica en s, sin embargo, manejaba otro tipo de chart para la gestin de proyecto. Tal chart se inclinaba a una adecuacin de un Project nada ms. Les presente la idea del Taskboard y la consideraron prctica y divertida.

(ii) Resultado Esperado Introducir la prctica como parte de la cultura de la empresa para el seguimiento de los proyectos.

109

B. Sprint 2 (i) Planificacin Solicit a mi equipo, tome conciencia que trabajaramos el radiador de informacin del proyecto de Implementacin del Data Center del cliente CSC SAC, solo de tal proyecto. Cada uno (y ramos 4) llenara en post-its sus actividades responsables en el proyecto y aquellas que creen deberan ser incluidas en el board. Una vez en mano las etiquetas, procedimos con determinar los colores para cada actividad: rojo, amarillo, verde y las seales naranjas y rojas para suspendido o urgente.

Cuadro 37: Primer Taskboard prueba al iniciar iteracin 2

(ii) Ejecucin Iniciamos la colocacin de los post-its con las tareas escritas por cada miembro del equipo de proyecto. Consideramos colocar
110

una columna a la izquierda donde se ubicaran los nombres de los integrantes, seguida de una columna de actividades que sabemos se deben realizar pero que aun no concretaramos su programacin. Luego vienen las columnas Por hacer, En Proceso y Concluidas.

Al iniciar esta iteracin estbamos a punto de concluir actividades del proyecto, por ello observan que el board ya tiene actividades concluidas, y que notamos con etiqueta roja pues eran urgentes y de pocos das de duracin. Es ese el punto de partida para la iteracin 2. Utilizamos un papelgrafo grueso, plumones, lapiceros, cinta adhesiva y regla.

Luego fuimos coordinando el llenado del primer Taskboard, previa reunin de planificacin del sprint. Culminamos la iteracin 2 con las actividades programadas y en ejecucin debidamente documentadas para que todos estn al tanto de lo que el equipo est trabajando.

Cuadro 38: Taskboard iteracin 2 segundo da

111

Nos dimos cuenta que haban tareas que se podan unificar para concluirlas rpido y optimizar el tiempo de trabajo. Estas tareas serian revisadas a lo largo de la semana en el Scrum Daily Meeting. No entraremos en el detalle de la prctica, pero dicha reunin nos permitir revisar da a da el avance de la iteracin y conocer el trabajo actual de los miembros del equipo.

Durante la colocacin de las tareas, decidimos cambiar algunas de amarillo a rojo, puesto que su ejecucin y cumplimiento era vital para otras tareas. Utilizamos tambin sealizadores tipo flecha para colocar como tipo urgente en algunas tareas amarillas. En el correr de la iteracin tuvimos que colocar en suspender algunas actividades pues se estaban ocasionando cuellos de botella innecesarios o actividades que no afectaran si se colocaban en pausa pues no afectara el resultado de la iteracin. Para esta prctica, actu (Lorena) como Scrum Master.

(iii) Retrospectiva

Obtuvimos en primer lugar el conocimiento de la prctica de Taskboard. El equipo tendra que comprender cul era el objetivo de trabajar el conocimiento de un proyecto con esta herramienta. Permiti ordenar las actividades por integrante,
112

compartir ideas sobre ejecucin de tareas, logramos unificar tareas entre nosotros y construir una sola denominacin para ciertas actividades (esto hara que dos personas no trabajen en un mismo objetivo).

Nuestro objetivo era plasmar en el board las tareas a la fecha del primer sprint para ordenar nuestro trabajo y programar ms claramente las actividades esperadas para la siguiente iteracin.

C. Sprint 3 (i) Planificacin

Empezamos la reunin de planificacin del sprint con todos los integrantes del proyecto. Nos aseguramos la presencia de los mismos sin falta para no tener problemas futuros con alguna observacin hacia alguna tarea programada.

Recibimos el Taskboard como el grafico que sigue a continuacin, donde ya se observan cambios respecto a la iteracin 2 pues ocurrieron 5 reuniones diarias que ocasionaron movimientos al board.

113

Cuadro 39: TaskBoard de inicio Sprint 3

Revisamos el estado actual de las actividades y solicite que cada uno revise las actividades que estn bajo su

responsabilidad y si tendran ms que agregar. Eso era lo primero que se esperaba de la reunin de planificacin para este sprint. Inici la ejecucin de la iteracin.

Se solicit tengan ya listo sus opiniones sobre priorizacin de actividades, ya que en el sprint anterior no se contemplaron las priorizaciones seriamente. Se comprendi, como retrospectiva, que tendramos que llegar a un consenso sobre que prioridad le daramos a las actividades por hacer.

(ii) Ejecucin Iniciamos la iteracin primero verificando las tareas Por Hacer.

114

Uno

uno

con

cada

miembro

revisamos

sus

tareas

programadas en dicha columna y verificamos que estn todas las que deberan, en todo caso, este sera el momento de ingresar las actividades faltantes. Un miembro del equipo observo que no se haban actualizado tareas en el TaskBoard respecto a la iteracin anterior, por tanto se realizo el movimiento de etiquetas quedando actualizado el TaskBoard.

Cuadro 40: Revisin de TaskBoard Sprint 3

Se complet el tablero con todas las tareas programadas y en proceso para actualizar lo faltante del mismo. Se levantaron las observaciones de cada usuario verificando que se incluyeron las actividades nuevas. Intercambiamos ideas respecto al tablero previo a la culminacin del Sprint 3.

115

Colocamos varias actividades ya en proceso y quitamos seales de suspendido y de urgente puesto que se resolvieron entre los das transcurridos entre Sprint 2 y 3.

Cuadro 41: TaskBoard previo a cierre de Sprint 3

Se cerr el sprint, pero se acord en no quitar las tareas Concluido por el momento.

(iii) Retrospectiva Observamos ms compromiso de los participantes en esta iteracin. Logramos que cada integrante se sienta ms comprometido con las tareas que tenan asignadas de manera individual.

El tablero permiti afianzar el trabajo en equipo y cada uno se preocupaba de que sus tareas tengan avances continuos y con resultados, esto alimentaba su imagen frente al grupo.

116

Sin embargo aprendieron que deban ordenar ms el tablero, creando lmites entre participante vs estado del proyecto para que la informacin se vea ms amigable. Presentamos la idea del Burn Down Chart para el Taskboard, y seria aplicado para la siguiente iteracin pues haca falta lograr visualizar la medicin de cmo iba el resultado de la iteracin vs lo programado para ella.

117

3.4 Evaluacin de resultados

3.4.1 Anlisis de las retrospectivas del Sprint 2 y 3 - En Dainko: Sobre la implementacin del Taskboard: la prctica optimiz el manejo del conocimiento del estado de cada actividad en cada proyecto de la empresa. Permiti que el equipo de trabajo trabaje en equipo, puesto que ahora se sabra que cada uno informara de sus actividades y avances y esto servira a incentivar la competencia sana para obtener ms logros da a da. Se logr introducir la tcnica de manera tan exitosa que se crearon plantillas para cada etiqueta, no solo en color sino en contenido. Esto mejorara la informacin de cada actividad y no llenarse de etiquetas que impidan tener una mejor visin de la tarea en el panel. Al culminar el sprint 3 de la prctica mencionada, notamos mayor inters de todos los integrantes del equipo de desarrollo y del gerente general de la empresa en constituir esta prctica como algo necesario en la institucin. Definitivamente es importante incluir a manera visual un medidor de avance en el tablero y se elaborara los Burn Charts para la siguiente iteracin.

118

 Sobre el Daily Meeting, no fue fcil introducir la costumbre de reunirse en la empresa, pero si se insista mucho en la importancia de desarrollar la practica sobre todo por ser una empresa de desarrollo de software y de compromisos con cliente muy fuertes. No se pudo respetar el horario de la reunin, debido a las actividades de cada uno de los integrantes del equipo, motivo por el cual algunas veces no todos los participantes no podan acudir a la reunin. Las reuniones no podran darse sentados en la mesa del directorio, pues no era parte respetada de la practica. Complicado fue incentivar a que sean parados puesto que les resultada incomodo. Con el correr de los das se sinti mayor participacin de todos los integrantes de equipo de trabajo. Sera importante no pasarse los 15 minutos estimados para cada reunin y apoyar al miembro del equipo que tendra reparos en soltarse oralmente durante la ejecucin.

Se logr una idea aceptada que refera a la generacin de un acta con la informacin proporcionada por cada uno de los participantes, la cual servir para generar un informe de las actividades que se presentaran en la reunin de fin de mes.

119

- En CSC Consulting Para Pair Programming: la aplicacin de la prctica no se vio como una prdida de tiempo sino como algo muy positivo pues compartimos conocimiento para obtener un resultado mejor. Las experiencias en desarrollo de software para aplicaciones web permiti que los resultados de los entregables sean satisfactorios siempre. Era importante considera un plan de trabajo previo al inicio de la iteracin, los puntos que se revisaran y lo que s o s debera darse al concluir el sprint. La practica permiti revisar errores y en conjunto solucionarlos de tal manera que no afecte la calidad del entregable. Consideramos incluir en el plan de trabajo, los obstculos que tendramos para ejecutar el siguiente sprint, como el tiempo que deberamos disponer para la

investigacin de detalles de desarrollo para entorno Cloud Computing por ejemplo. Para el desarrollo del TaskBoard: era importante que el equipo comprenda cul era el objetivo de trabajar el conocimiento de un proyecto con esta herramienta. Apoya en el ordenamiento de las actividades necesarias e importantes para el xito del entregable. Todos deberan conocer las tareas relevantes del proyecto de implementacin y colaborar entre ellos para que ninguna actividad quede fuera o se omita. El plasmar en el board las tareas a la fecha era importante
120

para el compartir del conocimiento del estado del proyecto. Todos sabran que se est trabajando y que se obtendra en periodos conocidos y aprobados por todos.

La introduccin de cuadros BurnDown Chart para el Board, sera importante para visualizar mejor los avances y medir logros, esto sera aplicado para los siguientes sprints.

3.4.2 Retrospectiva de todo el trabajo Es importante el compromiso de los integrantes de un proyecto.

Las practicas agiles permiten afianzar el trabajo en equipo para lograr mejores entregables.

Mejora la obtencin de resultados para cada subproducto esperado por el cliente.

Es importante involucrar al cliente en la revisin de los sprints, sea el caso del Pair Programming. Las actividades del TaskBoard y Daily Meeting quedan ms para el ordenamiento dentro del equipo de desarrollo, salvo que algunas tareas dependan de la participacin del cliente para su cumplimiento.

121

 Lograr disminuir la resistencia al cambio o a la introduccin de nuevas prcticas de control en los integrantes del equipo para que la informacin fluya transparentemente y a favor del resultado final.

Mejorar el desarrollo de la planificacin previo a la ejecucin del sprint. No empezar la iteracin si no se conoce totalmente el objetivo de la misma, por los miembros del equipo.

122

3.5 Conclusiones
- Con la implementacin de Daily Meeting se logra una mayor comunicacin entre todos los integrantes del equipo, permitiendo saber las actividades que cada uno est desarrollando, las futuras actividades que desarrollara y los problemas que se estn presentando en el transcurso del da. - Es un mecanismo que facilita la emisin de informacin, al realizar reuniones cortas y diarias, todos estn enterados de las actividades y problemas que se estn presentando en el desarrollo de las actividades. - Al realizar reuniones cortas (15 minutos) se logra reducir el costo a la empresa, por que juntar un numero considerables de personas por un periodo de 1 hora o mas tiene un costo directo a la empresa. - Al realizarse reuniones cortas y diarias se logra captar la atencin de todos los integrantes del grupo de trabajo. - Con la implementacin del Taskboard se logra una mejor visin y control de las actividades que se estn desarrollando. - Proporcionar al todo el personal un enfoque global de las actividades que se estn desarrollando y el estado de cada una de ellas. - Con la implementacin de Pair Programming se logra la integracin entre todos los integrantes del equipo de trabajo.

123

- Con la implementacin de Pair Programming se logra que el equipo de trabajo pueda realizar un control continuo del proceso que estn realizando. - Con la implementacin de estas prcticas se puede optimizar los procedimientos en la implementacin de software en la compaa. Agilizar la entrega de los entregables, priorizar el desarrollo del software antes que la elaboracin de mucha documentacin tcnica, emisin y distribucin de informacin entre todos los integrantes del equipo. - Lograr disminuir la resistencia al cambio entre todos los integrantes del equipo de trabajo, para la aplicacin de nuevas metodologas de desarrollo que den un nuevo valor agregado a la compaa.

124

CONCLUSIONES

En el presente trabajo se ha realizado un anlisis de la problemtica existente en las instituciones Clnica San Juan de Dios, Grupo Sypsa S.A., Dainko S.A. y CSC Consulting SAC., en relacin a sus procesos administrativos y de desarrollo de software. Se han identificado sus fortalezas y debilidades, se han implementado procedimientos o modelos para poder optimizar el buen funcionamiento de todas estas instituciones.

Este trabajo de investigacin ha sido enfocado desde 3 puntos de vista: la gestin del proceso de negocio, CMMI y Mtodos giles para el desarrollo de software Cada uno de estos puntos estn desarrollados en el presente trabajo de investigacin.

En el Captulo 1, Gestin de Procesos de Negocio, se analiz el proceso de una empresa de servicios hospitalarios, que con el apoyo de la redefinicin de procesos con la metodologa BPM y la herramienta Bizagi Process Modeler se logr definir un proceso mejorado para la optimizacin de las actividades en las reas de Registro de Citas y Atencin Medica, segn los requerimientos actuales de la institucin.

125

En el Captulo 2, se aplic el modelo de buenas prcticas CMMI, para la administracin de proyectos de desarrollo de software en una empresa nacional. Se logr un mayor control en todas las reas relacionadas con el desarrollo de proyectos informticos. Se definieron procedimientos y plantillas que deben a ser utilizados por el personal para uniformizar los procesos que se realizan dentro de la institucin. Se logr la participacin y colaboracin de todos los lideres o encargados de los procesos de negocios para poder implementar nuevas mecanismos o procedimientos que ayuden a optimizar el desempeo de los trabajadores y aumentar la rentabilidad de la compaa.

Finalmente en el Captulo 3, Mtodos giles para el desarrollo de SW, implementamos las siguientes prcticas con la finalidad de introducirlas en la cultura de las empresas en estudio y mostrar sus ventajas en la administracin de proyectos de software: Daily Meeting, Taskboard y Pair Programming. Se observ mayor integracin entre todos los integrantes de equipo de desarrollo, mediante la comunicacin y compromiso. Se increment el flujo de la informacin entre todos los integrantes de los proyectos en prctica. Logramos mejorar la calidad de los productos entregados al cliente mediante la aplicacin de prcticas agiles en las instituciones.

126

GLOSARIO DE TERMINOS BMP: Es una metodologa orientada al modelado de procesos de negocios. BMPN: Es una notacin grfica estandarizada basada en diagramas de flujo para describir procesos de negocio. CMMI: Capability Maturity Model Integration. Modelo para la mejora y evaluacin de procesos para el desarrollo, mantenimiento y operacin de sistemas de software. CSC: Siglas de negocio que refiere a un Centro de Servicios Compartidos. Daily Meeting: Reuniones diarias de 15 minutos donde cada integrante del equipo de desarrollo informa de las actividades que estas desarrollando y los problemas que est afrontando. Taskboard: Es un tablero en el cual se colocan las actividades que se estn desarrollando en el da, estas actividades no pueden superar las 8 horas. Pair Programming: Es una prctica gil, mediante la cual dos personas realizan una actividad es un mismo lugar de trabajo.

127

BIBLIOGRAFIA Diapositivas de Procesos de Gestin de Negocios BMP UPC 2011 Diapositivas de CMMI UPC 2011 Diapositivas de Metodologas Agiles UPC 2011 PMBOK 4ta. Edicin (espaol) Kiran Garimella, Michael Lees y Bruce Williams 2001 Introduccin a BMP para Dummies. Bizagi Process Modeler
(http://www.bizagi.com/index.php?option=com_content&view=article&id=9 5&Itemid=107&lang=es0

Mary Beth Chrissis, Mike Konrad, Sandy Shrum. CMMI, Gua para la integracin de procesos y la mejora de productos. Laurie Williams y Alistair Cockbum Costo y Beneficio de la Programacin de Pares. Clases del curso de Metodologas Agiles dictadas en el curso de Titulacin de la UPC. Profesor: Lennon Shimokawa. Build a TaskBoard in 10 steps (http://www.xqa.com.ar/visualmanagement/)

128

ANEXOS Anexos CMMI A. Proceso de Project Planning (PP)

1. SP 1.1: Plantilla de WBS

Plantilla WBS.doc

129

2. SP 1.2 SP 1.4: Plantilla COCOMO: estima el tamao del producto:

Paso 1 - Estimar Puntos de Funcin (PF) Estimar los Elementos de Funcionalidad (EF) No modificar las 7 primeras filas de esta pgna No Elemento de Funcionalidad (EF) 1 Actualizar Clientes (agregar) 2 Actualizar Clientes (modificar) 3 Actualizar Clientes (eliminar) 4 Actualizar Clientes (imprimir) 5 Mostrar movimiento en KARDEX 6 Consultar estado de cuenta 7 Actualizar Vendedor (agregar) 8 Actualizar Vendedor (modificar) 9 Actualizar Vendedor (eliminar) 10 Actualizar Vendedor (imprimir)

TEF EE EE EE SE SE CE EE EE EE SE

ED 18 18 1 18 6 1 7 7 1 7

AR Nivel 6 A 6 A 9 P 6 A 2 P 1 B 3 P 3 P 2 B 3 P

Nivel para las EE - Entradas Externas Archivos Elementos de Datos (ED) Referenciados (AR) 1-4 5-15 0-1 Bajo Bajo 2-3 Bajo Promedio 4+ Promedio Alto

16+ Promedio Alto Alto

Nivel para las SE - Salidas Externas y CE - Consultas Externas Archivos Elementos de Datos (ED) Referenciados (AR) 1-5 6-19 20+ 0-1 Bajo Bajo Promedio 2-3 Bajo Promedio Alto 4+ Promedio Alto Alto

Estimar los elementos de funcionalidad

Paso 2 - Estimar Puntos de Funcin (PF) Estimar los Archivos Lgicos (AL) No modificar las 7 primeras filas de esta pgna No Nombre del Archivo Lgico (AL) 1 Factura 2 DetalleFactura 3 Producto 4 Cheque 5 Boucher 6 Cuenta 7 Funcin 8 Peso 9 Categoria 10 Familia

TAL ALI ALI ALI ALI ALI ALI ALI ALI ALI ALI

ED 10 12 56 6 9 20 3 4 15 14

AR Nivel 1 B 1 B 1 P 1 B 1 B 1 B 1 B 1 B 1 B 1 B

Nivel para Archivos Lgicos Internos (ALI) y Externos (ALE) Archivos Elementos de Datos (ED) Referenciados (AR) 1-19 20-50 51+ 0-1 Bajo Bajo Promedio 2-5 Bajo Promedio Alto 6+ Promedio Alto Alto

Estimar los archivos lgicos

130

Paso 3 - Estimar los Factores de Ajuste (FA)

No 1 2 3 4 5 6 7 8 9 10 11 12 13 14

Sigla DCM DDP PER HUC TRT ODE EUE OUP CPR REU IEA OFE MSI FCH

Factores de Ajustes Nivel Comunicacin de Datos 2 Procesamiento de Datos Distribuidos 3 Rendimiento 1 Restricciones sobre la Configuracin 4 Ratio de Transacciones 0 Entrada de Datos en Lnea 3 Eficiencia del Usuario Final 2 Actualizacin en Lnea 3 Procesamiento Complejo 3 Reusabilidad 3 Facilidad de Instalacin 3 Facilidad Operacional 5 Mltiples Sitios 2 Facilidad de Cambio 2 Total Factores de Ajuste (TFA) 36 Valor del Factor de Ajuste (VFA) = 0.65 + 0.01 * TFA 1.01

Estimar factores de ajuste

Paso 4 - Ajustar los Puntos de Funcin (PFA) No modificar ninguna fila, columna o elemento de esta pgina. Se calculan automticos Tipo de Punto de Funcin BAJO PROMEDIO ALTO (TEF/TAL) Conteo Peso Conteo Peso Conteo Peso Subtotal EE - Entradas Externas 1 3 3 4 2 6 27 SE - Salidas Externas 0 4 2 6 1 7 19 CE - Consultas Externas 1 3 0 4 0 6 3 ALI - Archivos Lgicos Internos 9 7 1 10 0 15 73 ALE - Archivos Lgicos Externos 0 5 0 7 0 10 0 Puntos de Funcin Desajustados (PFD) 122 Puntos de Funcin Ajustados (PFA) 123.22 Calcular Puntos De Funcin
Ajustar los puntos de funcin

Paso 6 - Estimar factibilidad econmica para el proyecto

Variable MD - Modo de Desarrollo ESF - Esfuerzo TDES - Tiempo de Desarrollo CH - Cantidad de Hombres (promedio) CHM - Costo por Hombre al Mes (promedio) C - Costo del Proyecto

Valor 1 9.47 5.87 2 1100 10 418.29

hombres-mes meses hombres dlares dlares

Estimar factibilidad econmica

131

Paso 7 - Distribuir la Factbilidad Econmca para el proyecto

Distribucin para las fases del proyecto ESF Fase Valor (%) Concepcin 0.47 5 Elaboracin 1.89 20 Construccin 6.16 65 Transicin 0.95 10 Total 9.47 100

TDES Valor (%) 0.59 10 1.76 30 2.94 50 0.59 10 5.87 100

(Fuente: Philippe Kruchten A Rational Development Process )

Distribucin para las etapas del proyecto ESF Etapa Valor (%) Modelado del Negocio 0.47 5 Requerimientos 1.42 15 Anlisis y Diseo 2.37 25 Implementacin 3.31 35 Prueba 0.47 5 Implantacin 1.42 15 Total 9.47 100

TDES Valor (%) 0.88 15 0.88 15 1.47 25 1.76 30 0.29 5 0.59 10 5.87 100

(Fuente: Philippe Kruchten A Rational Development Process )

Distribucin para los cursos de la carrera ESF Curso Valor (%) Proyecto Informtico 1 4.74 50 Proyecto Informtico 2 3.79 40 Tesis 0.95 10 Total 9.47 100

TDES Valor (%) 2.35 40 2.35 40 1.17 20 5.87 100

Distribuir la factibilidad econmica

132

3.

SP 1.3: Plantilla de Ciclo de vida

Cronogram a de Desarrollo - Resum en Etapa Responsable SYPSA CLIENTE 1 2 GS, US GS, US D1 3 4 5 6 Semanas 7 8 9 10 11 12 13 14 15 16 17 18

Levantamiento de Informacin Aprobacin de Requerimientos Diseo de Programas Aprobacin de Diseo Programacion Pruebas con Usuario Depuracion Entrega

GP, JI, JD GP, JI, JD JD, P1, P2 GP, JD JD, P1, P2

GS, US

D2

JD, P1, P2 US JD, P1, P2 US GP, JD GS, US D3 D4

Ciclo de Vida.doc

4. a.

SP 2.1: Plantilla para Estimar el presupuesto Calculo del presupuesto

Variables en costos (Und) Viaticos 200.00 Viajes 1228.00 Maquinas 310.00 PMO 5000.00 Porcentajes Porcentaje Contingencia 20.00% Porcentaje Gestion 25.00% Porcentaje utilidad 8.00% Gastos Generales 1.682 Variables por dia Capacitacion 20 Cantidad Viajes 1 Cantidad de maquinas 9 Tipo de cambio 3.1
Variables a considerar.xls

Presupuesto Del Proyecto

Detalles Costos (S/.) Montos Variables Inicializacion 2,856 Analisis y diseo 7,574 Ambiente y Desarrollo 1,919 Desarrollo 17,636 Pruebas y Planeamiento 15,746 Deployment 3,698 Costos total Variables 49,428 Montos fijos Viticos 4,000 Viajes 1,228 PMO (Pago Personal y servicio) 50,000 Maquinas 27,900 Costo Total Fijos 83,128 Costos Totales 132,556 Reserva de Contingencia (20%) 26,511 Linea Base 159,067 Riesgo de Gestion (25%) 39,767 Presupuesto 198,834 Utilidad (8%) 15,907 Monto total 214,741 Costo Proyecto 214,741

Calculo del presupuesto.xls

133

b.

Planilla Lista de verificacin

LISTA DE VERIFICACIN DE ESTIMACIN DE COSTOS

Nombre del Proyecto: Preparado por: Fecha: Asegurarse que todos los recursos necesarios sean tomados en consideracin:

Administracin del Proyecto

Personal

Materiales

Proveedores

Viajes

Pagos a consultores y otros servicios profesionales

Diversos (traslados, copias, mensajeras, etc.)

Plan de contingencia

Inflacin

Recomendaciones Sea lo ms especfico posible, usar estimaciones, mtricas para cuantificar los recursos que el proyecto requerir. Expresar los costos estimados en unidades monetarias Asegrese que las actividades consideradas en el proyecto, tienen costos potenciales involucrada en el proyecto, cuando considere un potencial costo Asegurarse que las estimaciones o mtricas muestren cantidades realistas para cada item de costo, tales como nmero de horas/das por alquiler de equipo, nmero de trabajadores requeridos para realizar la construccin en horas/das y as por el estilo.

Plantilla de lista de verificacin para estimacin de costos.doc

134

c.

Plantilla para especificacin de hitos del proyecto

HITOS DEL PROYECTO

Nombre del Proyecto: Preparado por: Fecha:

Hitos

WBS

Fecha

Descripcin

Comentarios: Revisado por: Fecha: Autorizado por: Fecha:

Plantilla para Hitos del Proyecto.doc

135

d.

Plantilla Cronograma detallado

CRONOGRAMA DETALLADO SEMANA Responsab H i 1 2 3 4 5

Inicio

Tarea Lanzam iento FASE 1 - LEVANTAMIENTO DE INFORMACIN

FASE 2 - ANALISIS Y DISEO

FASE 3 - APROBACIN DE DISEO

FASE 4 - DESARROLLO Y PROGRAMACION

FASE 4 - PRUEBAS Y CONTROL DE CALIDAD

FASE 5 - PUESTA EN MARCHA Y SOPORTE

136

5.

SP 2.2: Plantilla de Registro de Riesgos

REGISTRO DE LOS RIESGOS DEL PROYECTO

Nombre del Proyecto: Preparado por: Fecha:
NOTA: Enumere todos los riesgos identificados del proyecto dentro de cada categora. Conserve esta informacin para su referencia a travs del proceso de la gerencia de riesgo:

Riesgos tcnicos 1. 2. 3. 4. 5. Riesgos de gestin 1. 2. 3. 4. 5. Riesgos organizacionales 1. 2. 3. 4. 5. Riesgos externos 1. 2. 3. 4. 5.

Plantilla de registro de los riesgos.doc

EVALUACIN CUALITATIVA DE LOS RIESGOS DEL PROYECTO

Nombre del Proyecto: Preparado por: Fecha:

Riesgo Actual Respuesta Probabilidad Impacto Prioridad al riesgo Accin a tomar Nuevo Probabilidad Impacto Prioridad

0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0

Evaluacin cualitativa de los riesgos.xls

137

6.

SP 2.3: Plan de datos

Procedimiento para la Seguridad Lgica, accesos y confidencial de la informacin producida

Todos los involucrados en el proyecto debern sujetarse a las polticas de seguridad establecidas. Se asignar por usuario un espacio limitado para el almacenamiento de la informacin vincula con la actividad laboral en los servidores de archivos autorizados por la Jefatura de Desarrollo. Est restringido el almacenamiento de informacin que no guarde ninguna relacin o vnculo con el proyecto asignado. Se debern establecer los niveles de acceso para los miembros del proyectos.

a. De Aplicacin por parte del Encargado del rea de Soporte

Establecer las medidas de seguridad y confidencialidad que se aplicar en la produccin, generacin, emisin, publicacin, intercambio, distribucin y transmisin de datos e informacin automatizada relacionada con el proyecto Mantendr el derecho de los usuarios a la confidencialidad del correo electrnico.

b. De Aplicacin por parte del Usuario

Deber mantener el respaldo de la informacin requerida para su trabajo, incluyendo en ello, el respaldo de los mensajes de correo electrnico que requiere conservar, para lo cual deber archivar dicha informacin en el directorio asignado por el Encargado de Soporte ubicado en el servidor principal de Empresa. Los usuarios tendrn derecho a la confidencialidad de su informacin, con la salvedad de aquellos casos en que se detecten acciones que se pongan en riesgo la seguridad de la red de datos y/o fuga de informacin. Deber utilizar la cuenta asignada, para el acceso a los servicios a los que tenga autorizacin.
Poltica Plan de Datos 1/3.doc

138

Procedimiento para Gestin de Cambios Es la evaluacin y planificacin del proceso de cambio para asegurar que, si ste se lleva a cabo, se haga de la forma ms eficiente, siguiendo los procedimientos establecidos y asegurando en todo momento la calidad y continuidad del servicio TI.

CONTROL DE VERSIONES Versin Hecha por Revisada por Aprobada por Fecha Motivo

PLAN DE GESTIN DE CAMBIOS

Nombre del proyecto
NOMBRE DEL ROL PERSONA ASIGNADA RESPONSABILIDADES NIVELES DE AUTORIDAD

TIPOS DE CAMBIOS: DESCRIBIR LOS TIPOS DE CAMBIOS Y LAS DIFERENCIAS PARA TRATAR CADA UNO DE ELLOS.

PROCESO GENERAL DE GESTIN DE CAMBIOS: DESCRIBIR EN DETALLE LOS PROCESOS DE LA GESTIN DE CAMBIOS,
ESPECIFICANDO QU, QUIN, CMO, CUNDO Y DNDE

SOLICITUD DE CAMBIOS:
Captar las solicitudes y preparar el documento en forma adecuada y precisa.

Poltica Plan de Datos 2/3.doc

139

VERIFICAR SOLICITUD DE CAMBIO: Asegurar que se ha

provisto toda la informacin necesarioa para hacer la evaluacin

EVALUAR IMPACTOS:
Evala los impactos integrales de los cambios

TOMAR DECISIN Y REPLANIFICAR: Se toma la

decisin a la luz de los impactos, (dependiendo de los niveles de autoridad), se replanifica segn sea necesario

IMPLANTAR EL CAMBIO:
Se realiza el cambio, se monitorea el progreso, y se reporta el estado del cambio

CONCLUIR EL PROCESO DE CAMBIO: Asegura que todo

el proceso haya sido seguido correctamente, se actualizan los registros

PLAN DE CONTINGENCIA ANTE SOLICITUDES DE CAMBIO URGENTES: DESCRIBIR EL PLAN DE CONTINGENCIA PARA
ATENDER SOLICITUDES DE CAMBIO SUMAMENTE URGENTES QUE NO PUEDEN ESPERAR A QUE SE RENA EL COMIT DE CONTROL DE CAMBIOS.

HERRAMIENTAS DE GESTIN DE CAMBIOS: DESCRIBIR CON QUE HERRAMIENTAS SE CUENTA PARA OPERAR LA GESTIN DE
CAMBIOS.

SOFTWARE PROCEDIMIENTOS FORMATOS OTROS

Poltica Plan de Datos 3/3.doc

140

7.

SP 2.4: Plantilla de Requerimiento de Recursos

Plantilla de Requerimiento de Recursos

Nombre del Proyecto: Preparado por: Fecha
Entregable Actividad Recurso Cantidad % Desde asignacin Hasta Observaciones

Plantilla de Requerimientos de Recursos.doc

141

8.

SP 2.5: Plantilla de plan de capacitacin

Plan de Capacitacin
Nombre del Proyecto: Preparado por: Fecha: Justificacin del Proyecto:

La necesidad del negocio que dio origen o necesidad del proyecto.

Descripcin del producto:

Un breve resumen de la descripcin del producto

Seleccionar las necesidades especficas de capacitacin: Determinar los recursos de capacitacin 1. Determinar los recursos de capacitacin 2.... Determinar los recursos de capacitacin n Desarrollar material de formacin: Obtener instructores calificados: Realizar capacitacin: Evaluar la efectividad del entrenamiento: Actualizar la formacin recibida a cada recurso de la organizacin:
Periodo inicio fin Indicar material que se requiere para la capacitacin

Plantilla del plan de capacitacin.doc

142

9.

SP 2.6: Plantilla de Acta de Constitucin del Proyecto

Acta de Constitucin del Proyecto (Project Charter)

A. Informacin General
Nombre del Proyecto Patrocinador: Preparado por: Fecha de Preparacin Fecha de Modificacin: Autorizado por:

B.

Descripcin del producto o servicio del Proyecto

Descripcin narrativa de los productos y servicios que deben ser suministrados por el proyecto.

C.

Alineamiento del Proyecto

Consideraciones de la Organizacin Propsitos del Proyecto

D.
Costo Plazo Calidad Alcance

Objetivos del Proyecto

Objetivos del Proyecto

E.

Alcance y Extensin del Proyecto

Principales Entregables del Proyecto.

Plantilla del Acta de constitucin del proyecto 1/3.doc

143

Principales Fases del Proyecto.

Stakeholders claves.

Restricciones.

Asunciones

Lmites del proyecto

F.

Factores Crticos de xito del Proyecto

G.

Planeamiento Inicial del Proyecto al alto nivel

Estimacin de recursos requeridos:

Costo Estimado del Proyecto:

Beneficios Estimados:

Estimacin de Fechas a Programar:

Plantilla del Acta de constitucin del proyecto 2/3.doc

144

Fecha de inicio: Fecha de trmino:

H.

Autoridad del Proyecto

Autorizacin

Gerente del proyecto

Nombre:

Comit de Seguimiento (Direccin)

I. Integrantes del equipo del proyecto, Roles y Responsabilidades

1. 2. 3. 4. 5.

J.

Firmas
Nombre/Funcin Firma Fecha

Plantilla del Acta de constitucin del proyecto 3/3.doc

145

10.

SP 3.1; GP 2.10: Plantilla acta de reunin donde se documentan la 24/10/a dependencia con otros planes y otros acuerdos Pg. 1

CT030: Acta de Reunin

Nmero: Proyecto / asunto: Fecha de reunin: Asistentes:

Agenda Puntos tratados:

En agenda

Fuera de agenda

Puntos pendientes:

Plantilla de Acta de Reunin

146

11.

SP 3.3: Plantilla relacin de los miembros del proyecto

Re la ci n de mi em br os del pr o ye c t o

Reunin de Trabajo
Proyecto: Asistentes:

Fecha: DD/MM/YYYY

Cargo Usuario lder principal Usuario administrador Usuario lder mdulo 1 Usuario lder mdulo 2 Usuario Coordinador de sistemas Jefe de Desarrollo Analista Programador Tester

Abrev. ULP AD ULM2 ULM1 US CS JD ANA PGM QA

Funciones

Firma

Plantilla de relacin de miembros del proyecto.doc

147

12.

GP 2.1; GP 2.2; GP 2.3; GP 2.4; GP 2.5; GP 2.7, G 2.9: Poltica para Planificacin de Proyectos
POLTICA PARA PLANIFICACIN DE PROYECTOS

Seccin 1 - Resumen Ejecutivo (Qu como mnimo incluya):

El nombre del proyecto Nombre del cliente Todas las instalaciones involucradas Una historia breve del proyecto Una descripcin del proyecto Una descripcin de la solucin que ser entregada Cualquier otra informacin relevante al programa

Seccin 2 - Introduccin Seccin 2.1 - Propsito y objetivos

Brevemente describa las necesidades del negocio del cliente y sus problemas y cmo sern resueltos por el proveedor de la solucin.
Seccin 2.2 - Estrategia del proyecto

Describa cmo se alcanzarn los objetivos del proyecto. Documente las fases del ciclo de vida posibles. Los proyectos se pueden estructurar por fases, como Iniciacin, Planificacin, Ejecucin y Cierre. Identifique los hitos principales.
Seccin 2.3 - Alcance

Describa los lmites del proyecto. El alcance circunscribe las actividades o funciones a realizar. Brevemente describa qu procesos del cliente, instalaciones y locaciones se emplearn. Documento aquello que el proyecto no tendr en cuenta.
Seccin 2.4 - Entregables o productos

Describa la lista de los principales productos del proyecto, como los componentes del servicio, documentos, etc. Cubra componentes como hardware, software, entrenamiento y consultora.
Seccin 2.5 - Interfaces organizacionales

Describa todas las interfaces organizacionales que intervienen en el proyecto como clientes, terceras partes, de clientes de la organizacin del cliente, etc. Adicionalmente, identifique las interfaces internas del cliente y su organizacin que sean relevantes.
Poltica para Planificacin de Proyectos 1/6.doc

148

Seccin 2.6 - Documentos de referencia

Incluya ttulos, fechas y revisiones de los documentos que pertenezcan al proyecto.

Seccin 3 - Estructura del proyecto

La identificacin clara de la estructura del proyecto facilitar la planificacin y las comunicaciones. Tome en cuenta la organizacin y estructura del proyecto, roles y responsabilidades. Use una o ms grficas para bosquejar la organizacin del proyecto. Incluya al cliente, proveedores de la solucin y terceras partes.
Seccin 3.1 - Roles y responsabilidades

Identifique todos los miembros del proyecto y equipos de proyectos relacionados, al igual que otras personas claves. Describa roles y responsabilidades especficos. Aclare los roles gerenciales versus los roles de personal tcnico. Incluya los nmeros telefnicos y direccin de correo electrnico. Tambin incluya los roles del usuario final en cualquier actividad que represente una dependencia para el proyecto e indique sus responsabilidades.
Seccin 3.2 - Proyectos integrantes del proyecto, relaciones y dependencias

Identifique todos los gerentes / lderes de proyectos participantes tanto del cliente como del contratista. Incluya los proyectos gerenciados por el cliente cuando sea apropiado, por ejemplo, si se comparten coberturas diferentes de alcance de un proyecto general ms amplio. Revise todos los proyectos integrantes para identificar interdependencias y asunto interdisciplinarios.
Seccin 3.3 - Cmo trabajar el equipo del proyecto

Muestre las relaciones de informes entre los miembros del proyecto, tanto para el cliente como para el contratista. Defina los roles de supervisin. Describa las reuniones proyectadas regularmente, procedimiento de comunicaciones, reportes y otros procedimientos. Determine quines sern las personas a contactar en las instalaciones del cliente.
Seccin 3.4 - Roles del cliente

Identifique el personal del cliente que se comunicar con el personal del contratista e indique los medios de comunicacin (verbal, escrita) que se emplearn. Si el cliente exige reportes o reuniones formales, descrbalos.
Seccin 3.5- Rol de terceras partes

Describa cmo participarn las terceras partes dentro del marco del proyecto.
Seccin 3.6 - Intervencin de ejecutivos y aprobaciones, relaciones ejecutivas
Poltica para Planificacin de Proyectos 2/6.doc

149

Defina cmo intervienen los ejecutivos o gerentes funcionales de las partes participantes. Defina las aprobaciones necesarias para los productos principales del proyecto. Enumere, desde la perspectiva del usuario, los nombres de los ejecutivos de las partes y describa cmo se espera que apoyen el proyecto.
Seccin 3.7 - Proceso de control de cambios

Defina el proceso de control de cambios que se usar para controlar los entregables del proyecto. Defina los niveles de responsabilidad para la aprobacin de cambios.
Seccin 3.8 - Tcnicas y herramientas de gestin de proyectos

Describa las tcnicas que se emplearn para administrar el proyecto.

Seccin 3.9 - Proceso de comunicacin

Asegure comunicaciones frecuentes entre las partes asociadas con el proyecto para evitar el fracaso del proyecto. Planee los enlaces de flujos de informacin internas y externas al proyecto y determine qu tan frecuentemente se requiere la comunicacin.
Seccin 4 - Actividades y Estimados

Aqu se deben definir las actividades y estimados principales del proyecto.

Seccin 4.1 - Tareas, subtareas, actividades y esfuerzos respectivos y habilidades para el proyecto e integrantes

Para cada fase del proyecto, defina la estrategia, prerrequisitos, tareas, actividades externas y criterios de xito. Para cada tarea, proporcione una descripcin, el recurso y la habilidad o conocimiento requeridos, estime el esfuerzo y el nombre de la persona responsable. De modo similar, designa las subtareas para cualquier tarea que se ejecutan enteramente a nivel del proyecto. Las subtareas de las tareas ejecutadas por proyectos integrantes sern definidas en los proyectos respectivos.
Seccin 5 - Recursos

Proporcione los recursos necesarios y disponibles para el proyecto.

Seccin 5.1 -Personal
Poltica para Planificacin de Proyectos 3/6.doc

150

Presente una tabla que muestre los recursos humanos asignados, sus roles, organizaciones y tiempo asignado. Resuma la cantidad total de das-hombre y otros gastos por fases, haga una referenciacin cruzada entre proyectos e identifique las fuentes de los estimados.
Seccin 5.2 - Equipos

Describa los requerimientos logsticos para acceso telefnico, fotocopiadoras, equipos especiales y equipos de cmputo requeridos.
Seccin 5.3 - Instalaciones

Describa las necesidades para espacio en el sitio de trabajo, espacio de oficina u otra necesidad.
Seccin 5.4 - Otros

Proporcione una lista de requerimientos especiales como accesos a pisos, cuentas de correo electrnico, etc.
Seccin 6 - Cronograma

Desarrolle el cronograma del proyecto sobre la base de los estimados de tiempo y la secuencia requerida y duracin de las tareas, subtareas y actividades.
Seccin 6.1 - Cronograma por fase y tareas principales del proyecto y proyectos relacionados

Detalle el cronograma del proyecto, fase por fase, incluyendo las tareas principales del proyecto y proyectos relacionados.
Seccin 6.2 - Lista de Hitos

Detalle los hitos principales del proyecto e indique el estado de estos en cualquier momento dado durante el proyecto.
Seccin 7 - Revisiones y aprobaciones

Esta seccin puede ser la ms crtica del Plan del proyecto. Todo el personal que interviene debe entender el propsito y cronograma del proyecto como tambin los procedimientos que se usarn y la reparticin de responsabilidades.
Seccin 7.1 - Revisiones del proyecto

Establezca un calendario de revisiones para el proyecto que satisfaga las necesidades de todas partes. Provea detalles suficientes para anunciar y preparar las revisiones y agendas, como objetivos, participantes, directores, asuntos a tratar, distribucin de los informes de revisin y disposicin de los materiales de revisin.
Poltica para Planificacin de Proyectos 4/6.doc

151

Seccin 7.2 - Aprobaciones de documentos del proyecto

Describa el proceso de aprobaciones (incluyendo nivel de aprobacin, organizacin y procedimientos) dentro de la firma contratista, la empresa cliente y terceras partes.
Seccin 7.3 - Transiciones entre fases

Defina los criterios y procesos para realizar las transiciones entre las fases.
Seccin 8 - Dependencias del proyecto, riesgos y contingencias

Revise y valore los riesgos y dependencias de los proyectos integrantes y del proyecto total. Resalte los riesgos que queden fuera del control de los miembros del equipo del proyecto. Discuta los planes de contingencia para mitigar la ocurrencia de los riesgos.
Seccin 8.1 - Dependencias hacia proyectos y eventos

Discuta las actividades sobre las cuales el equipo del proyecto tiene poco control. Describa y discuta el impacto de las actividades que se retrasen o fallen. Discuta la sensibilidad que presenta el proyecto general hacia esos eventos. Explique las medidas de mitigacin de riesgo que se tomarn.
Seccin 8.2 - Riesgos y contingencias

Cules son los riesgos tcnicos y administrativos? Cul es la probabilidad de ocurrencia de los eventos de riesgo? Cmo se puede mitigar la posibilidad de falla por esos riesgos? Se han desarrollado los planes de reduccin de riesgos? Qu planes de contingencias se tienen? Se cuenta con fondos de contingencia?
Seccin 8.3 - Proceso de solucin de problemas

Describa cmo se identificarn, clasificarn, priorizarn, escalarn y resolvern los problemas. Tambin identifique los mecanismos de comunicacin y rutas y responsabilidad de resolver problemas para el proyecto y cada proyecto integrante.
Seccin 8.4 Seguimiento y Control

Realizar un seguimiento de tareas y esfuerzos en la consecucin de proyectos. El proceso de captura de datos para el Seguimiento y Control debe hacerse de forma peridica y en periodos de tiempo pequeos para obtener mayor detalle en los resultados y tomar las acciones pertinentes de forma rpida y eficaz.
Seccin 8.4 Aseguramiento de la Calidad

Realizar la revisin de las actividades y documentacin producida durante la etapa de planificacin, as como el cumplimiento de las polticas establecidas para tal fin; se recomienda que el grupo o
Poltica para Planificacin de Proyectos 5/6.doc

152

persona asignada para estas auditoras no formen parte del proyecto a revisar y posteriormente realice las observaciones y recomendaciones que deban ser mejoradas. Procedimiento de revisin y listas de verificacin Procedimiento de revisin La informacin contenida en el Plan del proyecto debe presentarse de un modo conveniente para revisin de la Direccin del Proyecto. Cualquier interrogante detallado que requiera mayor investigacin se debe resolver antes de la revisin, de ser posible. Cualesquier cambios convenidos sern registrados. La Direccin por parte del contratista acordar y aprobar los requerimientos de recursos, hitos crticos y riesgos del proyecto y la administracin de estos. Lista de verificacin La siguiente lista de verificacin se puede usar para revisar si el Plan del Proyecto est completo: Las afirmaciones en la Introduccin, Seccin 2, estn alineadas con los objetivos subyacentes del proyecto. Las actividades de la seccin 4, Actividades y Estimados, cubren completamente los objetivos fijados en la seccin 2 y cumplen con los entregables requeridos. El tipo y cantidad de entregables se ha definido. Todos los recursos mencionados en la seccin 6, Recursos, estn en concordancia con los ltimos compromisos. Cada miembro del equipo ha ledo y aprobado el Plan del Proyecto. El cronograma ha sido convenido y est en concordancia con los compromisos de recursos. Los hitos han sido convenidos por el cliente y el contratista. Se incluyen todos los planes apropiados. Las dependencias del proyecto estn alineadas con el plan de recursos. Se han identificado las dependencias del proyecto hacia los usuarios finales y se cuenta con planes de contingencia y eventos activadores. Los riesgos adicionales se han comunicado a las personas que intervienen. Por ejemplo, los riesgos con recursos se han comunicado a los gerentes de los recursos. Cualquier asunto pendiente ha sido resuelto, se ha identificado el riesgo o se cuenta con un procedimiento para resolverlo. El plan se puede poner en operacin tan pronto sea aprobado. Todas las participaciones del cliente se han comunicado al cliente y han sido entendidas

Poltica para Planificacin de Proyectos 6/6.doc

153

13.

GP 2.8: Plantillas para el seguimiento y control de tareas

SEGUIMIENTO Y CONTROL DE TAREAS

Nombre del proyecto: Estado actual del proyecto: Estado esperado del proyecto Tareas sin finalizar Ciclo de vida del Nombre de tareas proyecto Grado de avance % Horas gastadas Horas planificadas Desviacin

Horas totales: Tareas finalizadas Ciclo de vida Nombre de tareas Fecha fin Horas gastadas Horas planificadas Desviacin

Horas totales: Otros temas: Hitos (Entregables) finalizados Nombre Fecha entrega Fecha planificada Desviacin (das)

Plantilla para el Seguimiento y control de tareas.doc

154

14.

GP 2.9: Lista de verificacin para evaluar la Adherencia del

Proyecto
Listas de Verificacin para el Control de Calidad
Nombre del Proyecto: Preparado por: Fecha: Auditor: Lista de Verificacin de las actividades realizadas durante la Planificacin Puntos de control Conforme Observado Comentarios

Realizado por: Fecha:

Lista de verificacin para evaluar la Adherencia del Proyecto.doc

155

B. Proceso de Requirements Management (REQM)

1. SP1.1: Solicitud de Requerimiento
Nro. <Correlativo asignado por Sistemas>

SOLICITUD DE REQUERIMIENTO
Fecha: 16.08.11 Recibido por:<Nombre> Persona que recibe el requerimiento de servicio, Presentado por: Fecha requerida para:

I. SOLICITANTE: Lder Usuario rea: II. OBJETIVOS Y FUNCIONALIDAD: Titulo: 2. Funcin-objetivo principal:

3. Definiciones funcionales: Describe qu debe cumplirse en cada nivel (operativo, gestin, control) 3.1- Funcionalidad Operativa:
Describir las funciones que se requieren al nivel operativo. Precisar los entregables, criterios, frmulas u otros que se requieren para definir completamente la funcin descrita. Precisar si se adjunta algn anexo.

3.2- Funcionalidad de Gestin: <a. Descripcin 1>

Describir las funciones que se requieren en los diferentes niveles de gestin asociados con el requerimiento; por ejemplo, reportes sumarios de gestin, acumulaciones, ratios, estadsticas. Precisar los entregables, criterios, frmulas u otros q ue se requieren para definir completamente la funcin descrita. Precisar si se adjunta algn anexo.

3.3- Funcionalidad de Control: <a. Descripcin 1> <b. Descripcin 2> 4. Referencia legal: <a. Descripcin 1>
Si fuese necesario, describir los requerimientos legales que deben cumplirse, o en los cuales se basa; incluir la referencia a los dispositivos legales o normas internas. Precisar si se adjunta algn anexo.

5. Otras reas relacionadas y sus coordinadores: <a. Descripcin 1> <b. Descripcin 2>
En caso de relacionarse con otras reas o empresas, detllelas, indicando el coordinador o contacto correspondiente. Igualmente si tuviese alguna relacin con otro proceso o sistema informtico.

III. BENEFICIOS:
.

156

IV. OTRAS OBSERVACIONES: <a. Descripcin 1>

Incluir cualquier otra informacin que pueda ser til para la evaluacin, o dimensionamiento del proyecto, as como para un mejor entendimiento del mismo.

Firmas

Gerente rea Solicitante

Lder Usuario

157

2.

SP1.1, SP 1.3: Lista de requerimientos (hoja de clculo)

Fecha DD/MM/YYYY

Documento.

RELACIN DE REQUERIMIENTOS PROYECTO X Programa. Anlisis/ Diseo Prueba/ Soporte IT Req. ActiRespon Coment Cate- Priori vidasable arios goria dad des

Requerimiento Tipo Mdulo rea

0.0 0 0.0 0 0.00 0.00 0.00 0.00 0.00

3.

SP 1.2: Acta de Reunin

158

Total

4.

SP 1.3: Lista de Cambios

CT410: Lista de Cambios Relacin de Requerimientos adicionales pendientes (con severidad necesaria)
Mdulo de Contabilidad General
Requerimiento de Cambio Anlisis de Impacto Solucin Fec. req Fec. ent Sever Estado

(*) La severidad del requerimiento se est clasificando en Necesario, Conveniente y Deseable.

Mdulos de cuentas por pagar y tesorera

Requerimiento de Cambio Anlisis de Impacto Solucin Fec. req Fec. ent Sever Estado

(*) La severidad del requerimiento se est clasificando en Necesario, Conveniente y Deseable.

Mdulos de Inventario
Requerimiento de Cambio Anlisis de Impacto Solucin Fec. req Fec. ent Sever Estado

(*) La severidad del requerimiento se est clasificando en Necesario, Conveniente y Deseable.

159

5.

SP 1.4: Documento Funcional

Casos de Uso: Referencia a Requerimientos Funcionales

160

6.

SP 1.5; GP 2.7; GP 2.10: Cronograma de Desarrollo Resumen de Cronograma

Cronograma de Desarrollo Resumen Responsable Etapa SYPSA CLIENTE GS, US GS, US D1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 Semanas

Levantamiento de Informacin Aprobacin de Requerimientos Diseo de Programas Aprobacin de Diseo Programacin Pruebas con Usuario Depuracin Entrega

GP, JI, JD GP, JI, JD JD, P1, P2 GP, JD JD, P1, P2 JD, P1, P2 JD, P1, P2 GP, JD

GS, US

D2

US US GS, US D3 D4

7.

SP 2.2: Plantilla Cronograma de Desarrollo Detalle de Cronograma

Cronograma de Desarrollo Detallado

tem Proyecto Requerimi Indicacio Comentarios Situacin Responsable Fecha ento nes Programada Fecha Real Prioridad

161

8.

GP 1.1; GP 2.1: Poltica de Gestin de Requerimientos

Seccin 1 Resumen Ejecutivo El nombre del requerimiento Nombre del cliente Todas las instalaciones involucradas Una descripcin del requerimiento Una descripcin de la solucin que ser entregada Seccin 2 - Introduccin Seccin 2.1 - Propsito y objetivos Describir brevemente las necesidades del negocio del cliente y sus problemas y cmo sern resueltos con la solucin del requerimiento. Seccin 2.2 - Estrategia del requerimiento Describa cmo se alcanzarn los objetivos del requerimiento. Documente las fases del ciclo de vida posibles. Iniciacin Planificacin Ejecucin Cierre. Seccin 2.3 - Alcance Describa los lmites del requerimiento. El alcance circunscribe las actividades o funciones a realizar. Brevemente describa qu procesos del cliente, instalaciones y locaciones se emplearn. Documento aquello que el proyecto no tendr en cuenta. Seccin 2.4 - Entregables o productos Describa la lista de los principales productos del requerimiento, como los componentes del servicio, documentos, etc. Seccin 2.5 - Interfaces organizacionales Describa todas las instancias que intervienen en el en la solucin del requerimiento como usuario lder, encargo del requerimiento por parte del cliente y otras personas que sean relevantes en el proceso. Seccin 2.6 - Documentos de referencia Incluya documentacin referencial que est relacionada con el requerimiento solicitado. Seccin 3 - Estructura del requerimiento La identificacin clara de la estructura del requerimiento facilitar la planificacin y las comunicaciones. Tome en cuenta la organizacin y estructura del requerimiento, roles y responsabilidades. Use una o ms grficas para bosquejar la organizacin del requerimiento. Incluya al cliente, proveedores de la solucin y terceras partes. Seccin 3.1 - Roles y responsabilidades Identifique a todos los miembros del proyecto y equipos de proyectos relacionados, al igual que otras personas claves. Describa roles y responsabilidades especficos. Aclare los roles gerenciales versus los roles de personal tcnico. Incluya los nmeros telefnicos y direccin de correo electrnico. Tambin incluya los roles del usuario

162

final en cualquier actividad que represente una dependencia para el proyecto e indique sus responsabilidades. Seccin 3.2 - Proyectos integrantes del proyecto, relaciones y dependencias Identifique todos los gerentes / lderes de proyectos participantes tanto del cliente como del proveedor. Seccin 3.3 - Cmo trabajar el equipo del proyecto Muestre los informes entre los miembros del proyecto. Defina los roles de supervisin. Proporcione la relacin de reuniones proyectadas regularmente, reportes y otros procedimientos. Seccin 3.4 - Roles del cliente Identifique al personal del cliente que ser en nexo entre el cliente y el proveedor e indique los medios de comunicacin que se emplearn. Seccin 3.5- Rol de terceras partes Describa cmo participarn las terceras partes dentro del marco del proyecto. Seccin 3.6 - Intervencin de ejecutivos y aprobaciones, relaciones ejecutivas Defina cmo intervienen los ejecutivos o gerentes funcionales de las partes participantes. Defina las aprobaciones necesarias para los productos principales del proyecto. Enumere, desde la perspectiva del usuario, los nombres de los ejecutivos de las partes y describa cmo se espera que apoyen el proyecto. Seccin 3.7 - Proceso de control de cambios Defina el proceso de control de cambios que se usar para controlar los entregables del requerimiento. Defina los niveles de responsabilidad para la aprobacin de cambios. Seccin 3.8 - Tcnicas y herramientas de gestin de proyectos Seccin 4 - Actividades y Estimados Aqu se deben definir las actividades y estimados principales del proyecto. Seccin 4.1 - Tareas, subtareas, actividades y esfuerzos respectivos y habilidades para el proyecto e integrantes Para cada fase del proyecto, defina la estrategia, prerrequisitos, tareas, actividades externas y criterios de xito. Adems por cada tarea o sub tarea, proporcione una descripcin, el recurso y la habilidad o conocimiento requeridos, estime el esfuerzo y el nombre de la persona responsable. Seccin 5 - Recursos Proporcione los recursos necesarios y disponibles para el proyecto. Seccin 5.1 -Personal Presente un listado donde se muestre los recursos humanos asignados, sus roles, organizaciones y tiempo asignado. Resuma la cantidad total de das-hombre y otros gastos por fases, haga una referencia cruzada entre proyectos e identifique las fuentes de los estimados. Seccin 5.2 - Equipos Describa los requerimientos logsticos necesarios para el desarrollo del requerimiento (telfono, equipos de cmputo requeridos y otros recursos requeridos.) 163

Seccin 5.3 - Instalaciones Describa las necesidades de instalacin requeridos por el grupo del proyecto. Seccin 6 - Cronograma Desarrolle el cronograma del proyecto sobre la base de los estimados de tiempo y la secuencia requerida y duracin de las tareas, subtareas y actividades. Seccin 6.1 - Cronograma por fase y tareas principales del proyecto Detalle el cronograma del proyecto, fase por fase, incluyendo las tareas principales del proyecto. Seccin 6.2 - Lista de Hitos Detalle los hitos principales del proyecto e indique el estado de estos en cualquier momento dado durante el proyecto. Seccin 7 - Revisiones y aprobaciones Todo el personal debe de estar informado del cronograma del proyecto as como de las funciones o responsabilidades que tendr cada uno de ellos. Seccin 7.1 - Revisiones del proyecto Establezca un calendario de revisiones para el proyecto que satisfaga las necesidades de todas las partes. Proporcione informacin sobre los procedimientos o mtodos que se van a utilizar en los casos de pruebas. Seccin 7.2 - Aprobaciones de documentos del proyecto Describa el proceso de aprobaciones (incluyendo nivel de aprobacin, organizacin y procedimientos) dentro de la firma contratista, la empresa cliente y terceras partes. Seccin 7.3 - Transiciones entre fases Defina los criterios y procesos para realizar las transiciones entre las fases. Seccin 8 - Dependencias del proyecto, riesgos y contingencias Revise y valore los riesgos y dependencias del proyecto. Resalte los riesgos que queden fuera del control de los miembros del equipo del proyecto. Discuta los planes de contingencia para mitigar la ocurrencia de los riesgos. Seccin 8.1 - Dependencias hacia proyectos y eventos Discuta las actividades sobre las cuales el equipo del proyecto tiene poco control. Describa y discuta el impacto de las actividades que se retrasen o fallen. Discuta la sensibilidad que presenta el proyecto general hacia esos eventos. Explique las medidas de mitigacin de riesgo que se tomarn. Seccin 8.2 - Riesgos y contingencias Cules son los riesgos tcnicos y administrativos? Cul es la probabilidad de ocurrencia de los eventos de riesgo? Cmo se puede mitigar la posibilidad de falla por esos riesgos? Se han desarrollado los planes de reduccin de riesgos? Qu planes de contingencias se tienen? Se cuenta con fondos de contingencia? Seccin 8.3 - Proceso de solucin de problemas Describa cmo se identificarn, clasificarn, priorizarn, escalarn y resolvern los problemas. Tambin identifique los mecanismos de comunicacin y rutas y responsabilidad de resolver problemas para el proyecto y cada proyecto integrante. 164

Seccin 8.4 Seguimiento y Control Realizar un seguimiento de tareas y esfuerzos en la consecucin de proyectos. El proceso de captura de datos para el Seguimiento y Control debe hacerse de forma peridica y en periodos de tiempo pequeos para obtener mayor detalle en los resultados y tomar las acciones pertinentes de forma rpida y eficaz. Seccin 8.4 Aseguramiento de la Calidad Realizar la revisin de las actividades y documentacin producida durante la etapa de planificacin, se recomienda que el grupo o persona asignada para estas auditoras no formen parte del proyecto a revisar y posteriormente realice las observaciones y recomendaciones que deban ser mejoradas. Procedimiento de revisin y listas de verificacin Procedimiento de revisin La informacin contenida en el Plan del Requerimiento se debe presentar de forma detallado, que permita realizar una revisin de forma rpida y precisa. Cualquier interrogante que requiera mayor investigacin se debe resolver antes de la revisin, de ser posible. Lista de verificacin La siguiente lista de verificacin se puede usar para revisar si el Plan del Requerimiento est completo: Las afirmaciones en la Introduccin, Seccin 2, estn alineadas con los objetivos subyacentes del proyecto. Las actividades de la seccin 4, Actividades y Estimados, cubren completamente los objetivos fijados en la seccin 2 y cumplen con los entregables requeridos. El tipo y cantidad de entregables se ha definido. Todos los recursos mencionados en la seccin 6, Recursos, estn en concordancia con los ltimos compromisos. Cada miembro del equipo ha ledo y aprobado el Plan del Proyecto. El cronograma ha sido convenido y est en concordancia con los compromisos de recursos. Los hitos han sido convenidos por el cliente y el contratista. Se incluyen todos los planes apropiados. Las dependencias del proyecto estn alineadas con el plan de recursos. Se han identificado las dependencias del proyecto hacia los usuarios finales y se cuenta con planes de contingencia y eventos activadores. Los riesgos adicionales se han comunicado a las personas que intervienen. Por ejemplo, los riesgos con recursos se han comunicado a los gerentes de los recursos. Cualquier asunto pendiente ha sido resuelto, se ha identificado el riesgo o se cuenta con un procedimiento para resolverlo. El plan se puede poner en operacin tan pronto sea aprobado. Todas las participaciones del cliente se han comunicado al cliente y han sido entendidas.

165

9.

GP 2.3: Plantilla de Control de Recursos de Requerimientos

10.

GP 2.4: Plantilla de Roles para Requerimientos

166

11.

GP 2.8: Plantilla de Encuesta de Satisfaccin

El objetivo de esta encuesta es medir la actitud mostrada por los consultores de la EMPRESA durante el desarrollo de las tareas como Consultor Asignado a su Empresa. Esta informacin nos ayudar a mejorar el servicio brindado a nuestros clientes.
CLIENTE PROYECTO CONSULTOR EVALUADOR CARGO FECHA

Marcar con una X lo que corresponda.

1. Los consultores fueron puntuales al asistir a las reuniones o actividades programadas para el proyecto?
SI NO

2. Los consultores fueron lo suficientemente claros y amables al responder a las interrogantes formuladas por los usuarios?
MUY BUENO BUENO REGULAR MALO

3. El consultor cumplieron con los tiempos acordados en la presentacin de las tareas que le correspondieron?
MUY BUENO BUENO REGULAR MALO

4.

En que grado not usted que el consultor estuvo involucrado en el proyecto? MUY BUENO BUENO REGULAR MALO 5. Cul es su nivel general de satisfaccin con el avance o resultado del proyecto? MUY BUENO BUENO REGULAR MALO 6. Agradeceremos cualquier comentario que usted considere conveniente para ayudarnos a mejorar nuestro nivel de servicio:

167