metodología para la gestión del alcance en proyectos de
TRANSCRIPT
Universidad para la Cooperación Internacional
(UCI)
Metodología para la Gestión del Alcance
en Proyectos de Desarrollo de Software
para Aplicaciones Empresariales
GEORGINA SABORIO DOBLES
PROYECTO FINAL DE GRADUACION PRESENTADO COMO REQUISITO PARCIAL
PARA OPTAR POR EL TITULO DE MAESTRIA EN ADMINISTRACION DE
PROYECTOS
San José, Costa Rica
Junio, 2009
ii
UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL
(UCI)
Este Proyecto Final de Graduación fue aprobado por la Universidad como Requisito parcial para optar al grado de Master en Administración de Proyectos
_________________________ Mario López Soto. MAP
DIRECTOR DEL PROYECTO
__________________________ Ramiro Fonseca Macrini. MAP
LECTOR
__________________________ Edgar Zamora M. MAP
LECTOR
________________________ Georgina Saborío Dobles.
SUSTENTANTE
iii
A mis hijos
Eva y Gabriel,
quienes me han iluminado
con su luz clara y divertida ☺
iv
Reconocimientos
Quiero hacer un reconocimiento especial a mi padre, Álvaro Saborío Ruiz, quien no
dejó de vacilarme con este asunto del proyecto de graduación pues tardé tres años en
materializarla luego de terminar los cursos de carrera, pero quien a su vez nunca dejó
de creer que la sacaría después de todo. Una persona quien con sus conversaciones
me inspira a inventar proyectos y seguir aprendiendo.
A mis hijos, Eva y Gabriel Malek Saborío, por tenerme tanta paciencia al robarles un
poquito del tiempo que tengo para ellos en le ejecución de esta maestría con su
respectivo proyecto final de graduación, la dirección de proyectos de software, que en
muchas ocasiones consume tiempo personal, y un sin fin de otros proyectos, en los
que se han visto involucrados sin querer queriendo.
A mi madre, María Cecilia Dobles Yzaguirre, por su apoyo incondicional y quien muy
objetivamente se ofreció a leer esta documento, hacer comentarios formales y
observaciones desde una perspectiva diferente.
A mi hermana, Elvira Saborío Dobles, quien me dio la primera clase de administración
de proyecto con anotaciones en una servilleta, y cuyo objetivo era pasar una entrevista
de trabajo que tenía al día siguiente como Directora de Proyectos de Desarrollo de
Software. Conocimiento que me sirvió para pasar la entrevista, y me motivó para llevar
esta maestría, sin la cual no hubiera sobrevivido ni un mes el trabajo otorgado.
A su esposo y mi cuñado, Carlos Sánchez, con quien he tenido conversaciones muy
reconfortantes sobre la administración de proyectos de software, y que me ayudaron a
superar la inevitable frustración que todo Director de Proyectos debe experimentar al
iniciarse en esta labor.
A mi hermano, Luis Saborío Dobles y su esposa Silvia Ruiz, y en general a toda mi
familia por su apoyo y cercanía en momentos difíciles de la vida.
Quiero agradecer a los profesores que realmente les apasiona la Administración de
Proyectos y quienes por lo tanto hacen que los cursos sean entretenidos. Muchas
Gracias por compartir sus experiencias y ofrecer su granito de arena a la enseñanza
de esta maestría.
v
Índice de contenidos
RESUMEN EJECUTIVO ........................................................................................... IX
I INTRODUCCIÓN .......................................................................................... 11
I.1 ANTECEDENTES ............................................................................................. 11
I.2 DESCRIPCIÓN DEL PROBLEMA ............................................................................. 12
I.3 JUSTIFICACIÓN DEL PROYECTO ............................................................................ 13
I.4 OBJETIVOS DE ESTE TRABAJO ............................................................................. 14
I.4.1 Objetivo General ............................................................................................................... 14
I.4.2 Objetivos Específicos .......................................................................................................... 14
II MARCO TEÓRICO ........................................................................................ 15
II.1 DIMENSIONES DE UNA ORGANIZACIÓN .................................................................... 15
II.2 ESTRUCTURAS ORGANIZACIONALES ...................................................................... 16
II.3 MODELOS DE DESARROLLO Y ADMINISTRACIÓN PARA SISTEMAS DE SOFTWARE ..................... 19
II.3.1 Modelado de Procesos: ................................................................................................... 21
II.3.2 Modelado de Datos: ....................................................................................................... 28
II.4 MARCO REFERENCIAL ...................................................................................... 30
II.4.1 Estándares para la Administración de Proyectos en IT de Intel ............................................... 31
II.4.2 Proyectos Tradicionales ................................................................................................... 33
II.5 ACTUALIZACIONES EN LE GESTIÓN DEL ALCANCE DESDE LA PERSPECTIVA PMBOK ................ 34
III MARCO METODOLÓGICO ............................................................................. 35
III.1 HERRAMIENTAS Y FUENTES DE INFORMACIÓN ........................................................... 35
III.2 METODOLOGÍA DE APLICACIÓN ............................................................................ 35
III.3 METODOLOGÍA DE ANÁLISIS ............................................................................... 36
IV DESARROLLO .............................................................................................. 37
IV.1 METODOLOGÍA PARA LA DEFINICIÓN DEL ALCANCE ..................................................... 37
IV.2 EDT DE LA METODOLOGÍA PROPUESTA .................................................................. 40
IV.3 DEFINICIÓN DE CONCEPTOS IMPORTANTES ............................................................... 41
vi
IV.4 ANTEPROYECTO ............................................................................................. 43
IV.4.1 PASO 1: Investigación y modelado del negocio existente ...................................................... 44
IV.4.2 PASO 2: Modelado el negocio por crear.............................................................................. 47
IV.4.3 PASO 3: Negociación del vocabulario ................................................................................. 52
IV.5 EXPLORACIÓN ............................................................................................... 55
IV.5.1 PASO 4: Estructuración de los requerimientos en bloques conceptuales ................................... 55
IV.5.2 PASO 5: Definición de Requerimientos ............................................................................... 57
IV.5.3 PASO 6: Exploración del Diseño........................................................................................ 63
IV.5.4 PASO 7: Revisión de Requerimientos ................................................................................. 69
IV.6 PLANEACIÓN ................................................................................................. 76
IV.6.1 PASO 8: Construcción del Esquema de Distribución de Tareas (EDT) ....................................... 76
IV.6.2 PASO 9: Plan de pruebas ................................................................................................ 78
IV.6.3 PASO 10: Manejo de cambios en los requerimientos ............................................................ 80
V CONCLUSIONES .......................................................................................... 84
V.1 LECCIONES APRENDIDAS DURANTE LA PLANEACIÓN DE LAR LEAVE CONSOLIDATION .............. 85
V.2 RECOMENDACIONES ........................................................................................ 86
VI BIBLIOGRAFÍA ........................................................................................... 87
VII ANEXO A – DOCUMENTACIÓN PARA LA ADMINISTRACIÓN DE ESTE
PROYECTO DE GRADUACIÓN ................................................................................ 89
VII.1 CHARTER DEL PROYECTO DE GRADUACIÓN .............................................................. 89
VII.2 DECLARACIÓN DEL ALCANCE DEL PROYECTO DE GRADUACIÓN ....................................... 90
VII.3 ESTRUCTURA DE TAREAS DEL PROYECTO DE GRADUACIÓN ............................................ 92
VII.4 CRONOGRAMA............................................................................................... 93
VIII ANEXO B – DOCUMENTOS DEL PROYECTO LAR LEAVE CONSOLIDATION . 94
VIII.1 ACTA DEL PROYECTO LAR LEAVE CONSOLIDATION ................................................. 94
vii
Índice de Ilustraciones FIGURA NO. 1: PASOS PARA LA DEFINICIÓN DEL ALCANCE SEGÚN ALEC SHARP, 2008 ......................................... 20 FIGURA NO. 2: MODELO EN CASCADA, INTEL (2009) .............................................................................................. 23 FIGURA NO. 3: MODELO EN ESPIRAL DE BHOEM, PHILIPPE WOLKOVICZ (1999).................................................... 24 FIGURA NO. 4: EXTREME PROGRAMMING ................................................................................................................ 26 FIGURA NO. 5: SCRUM ........................................................................................................................................... 27 FIGURA NO. 6: MODELO ENTIDAD-RELACIÓN (ERM, POR SUS SIGLAS EN INGLÉS) ................................................ 29 FIGURA NO. 7: MODELO LÓGICO (SEGÚN LA NOTACIÓN PATA DE GALLO) ............................................................... 29 FIGURA NO. 8: CICLO DE VIDA GENERAL DE LOS PROYECTOS EN IT ....................................................................... 31 FIGURA NO. 9: LISTA DE DOCUMENTOS PARA PROYECTOS TRADICIONALES.......................................................... 33 FIGURA NO. 10: TRANSICIÓN DEL PMBOK 2003 AL 2008...................................................................................... 34 FIGURA NO. 11: EDT DEL PROYECTO FINAL DE GRADUACIÓN ............................................................................... 36 FIGURA NO. 12: METODOLOGÍA PARA LA GESTIÓN DEL ALCANCE EN RELACIÓN A PMBOK 2003 ........................ 37 FIGURA NO. 13: METODOLOGÍA PARA LA GESTIÓN DEL ALCANCE EN RELACIÓN A PMBOK 2008 ........................ 39 FIGURA NO. 14: PASOS DEL ANTEPROYECTO ......................................................................................................... 44 FIGURA NO. 15: FLUJO DE TRABAJO PARCIAL DE LAR LEAVE CONSOLIDATION ..................................................... 46 FIGURA NO. 16: PASOS DEL ANTEPROYECTO .......................................................................................................... 47 FIGURA NO. 17: MODELO ORGANIZACIONAL PARCIAL DEL PROYECTO .................................................................. 48 FIGURA NO. 18: MODELO DE INTERACCIÓN DEL NEGOCIO ...................................................................................... 49 FIGURA NO. 19: MODELO DE DESCOMPOSICIÓN DEL PROCESO - LAR LEAVE CONSOLIDATION ........................... 49 FIGURA NO. 20: MODELO DE FLUJO DE TRABAJO – LAR LEAVE CONSOLIDATION ................................................. 50 FIGURA NO. 21: MODELO PARCIAL SEGÚN SISTEMA EXISTENTE – LAR LEAVE CONSOLIDATION .......................... 51 FIGURA NO. 22: MODELO PARCIAL SEGÚN SISTEMA PROPUESTO – LAR LEAVE CONSOLIDATION ........................ 52 FIGURA NO. 23: PASOS DEL ANTEPROYECTO .......................................................................................................... 52 FIGURA NO. 24: FLUJO DE ESTADOS EN EL PROYECTO LAR LEAVE CONSOLIDATION .......................................... 54 FIGURA NO. 25: PRIMEROS PASOS DE LA ETAPA DE EXPLORACIÓN ........................................................................ 55 FIGURA NO. 26: PRIMEROS PASOS DE LA ETAPA DE EXPLORACIÓN ........................................................................ 57 FIGURA NO. 27: PROPUESTA PARA LA PÁGINA INICIAL - LAR LEAVE CONSOLIDATION ........................................... 60 FIGURA NO. 28: EXPLORACIÓN DEL DISEÑO ............................................................................................................ 63 FIGURA NO. 29: MODELO CONTEXTUAL DEL PROYECTO LAR LEAVE CONSOLIDATION ......................................... 65 FIGURA NO. 30: MODELO CONCEPTUAL DEL PROYECTO LAR LEAVE CONSOLIDATION ......................................... 65 FIGURA NO. 31: MODELO LÓGICO DEL PROYECTO LAR LEAVE CONSOLIDATION .................................................. 66 FIGURA NO. 32: MODELO DE INTERACCIÓN DE SISTEMAS ....................................................................................... 67 FIGURA NO. 33: MODELO DE CÁLCULO ALGORÍTMICO ............................................................................................ 68 FIGURA NO. 34: REVISIÓN DE REQUERIMIENTOS ..................................................................................................... 69 FIGURA NO. 35: ROLES Y RESPONSABILIDADES SEGÚN RAPID ............................................................................. 72 FIGURA NO. 36: EDT ................................................................................................................................................ 76 FIGURA NO. 37: EDT DEL PROYECTO LAR LEAVE CONSOLIDATION ...................................................................... 77 FIGURA NO. 38: PLAN DE PRUEBAS ......................................................................................................................... 78 FIGURA NO. 39: MANEJO CAMBIOS EN LOS REQUERIMIENTOS ................................................................................ 80 FIGURA NO. 40: FLUJO DEL PROCESO DEL SISTEMA DE CONTROL DE CAMBIOS ................................................... 82 FIGURA NO. 41: SISTEMA DE SEGUIMIENTO DE CAMBIOS EN EL PROYECTO EJEMPLIFICADO.................................. 83 FIGURA NO. 42: EDT DEL PROYECTO FINAL DE GRADUACIÓN ............................................................................... 92 FIGURA NO. 43: CRONOGRAMA DEL PROYECTO FINAL DE GRADUACIÓN ............................................................... 93
viii
Índice de Contenidos
CUADRO NO. 1: NIVELES DE MADUREZ - CMMI, COMPUESTO CON BASE EN MARY BETH CRISIS, MIKE KONRAD Y
SANDY SHRUM (2006) ....................................................................................................................................... 22 CUADRO NO. 2: ROLES DEL PROYECTO LAR LEAVE CONSOLIDATION ................................................................... 54 CUADRO NO. 3: DISTRIBUCIÓN DE ROLES SEGÚN CALIPSO .................................................................................... 71 CUADRO NO. 4: MODELO RAPID PARA EL PROYECTO LAR LEAVE CONSOLIDATION ............................................ 73 CUADRO NO. 5: MATRIZ DE REQUERIMIENTOS DEL PROYECTO LAR LEAVE CONSOLIDATION ............................... 74 CUADRO NO. 6: ROLES Y RESPONSABILIDADES DEL SCC EN EL PROYECTO EJEMPLIFICADO ............................... 81 CUADRO NO. 7: ACTA DEL PROYECTO DE GRADUACIÓN ......................................................................................... 89 CUADRO NO. 8: ACTA DEL PROYECTO LAR LEAVE CONSOLIDATION ..................................................................... 94
Índice de Abreviaciones
Abreviación Definición LAR Región Latinoamericana por sus siglas en ingles EDT Estructura Detallada de Tares
ix
Resumen Ejecutivo
El desarrollo de aplicaciones de software es una actividad humana que apenas
tiene un poco más de un lustro, por lo que el conjunto de conocimientos y mejores formas de hacer el trabajo están aún siendo exploradas y debatidas. Existen tendencias metodológicas que dependen mucho de la cultura y formación de la organización, del tamaño o escala del proyecto, del objetivo general – ya sea para establecer un modelo de desarrollo continuo sobre un sistema existente, o más bien crear una aplicación desde cero. Debido a esta diversa cantidad de variables, en la que resalta la ingeniosa naturaleza humana como recurso de desarrollo indispensable en este tipo de proyectos, es de esperar que las distintas metodologías de trabajo existentes sean también muy variables y en algunos casos hasta controversiales, ya que tratan de atacar el problema desde perspectivas opuestas, como si el objetivo de algunas fuera mitigar el impacto negativo de otras, y no resolver el problema de una forma integral.
La idea del presente proyecto de graduación es proponer una metodología para la gestión del alcance en proyectos de software para aplicaciones empresariales que combine conceptos de distintas técnicas ya establecidas para mejorar la experiencia de administrar proyectos y que pueda ofrecer resultados más efectivos. Para ello se pretende estudiar y analizar diversas técnicas para definir y manejar requerimientos, así como para modelar negocios, procesos y datos que ayuden a comprender como pueden ser utilizadas durante la gestión del alcance en proyectos de software. Esto incluye analizar las diferencias entre el PMBOK 2003 (versión 3) y el 2008 (versión 4) en relación con la Gestión del Alcance.
Se espera que uno de los objetivos de mayor utilidad para el lector, sea el análisis de un proyecto específico para convertir la teoría en metodología práctica, palpable y fácil de comprender. El proyecto elegido es LAR Leave Consolidation el cual ha iniciado su etapa de exploración en noviembre del 2008 y durante la elaboración este documento completo su etapa de planeación, la cual incluye la definición de sus requerimientos y el diseño de la aplicación. El propósito de esta herramienta es ofrecer una solución integral para el manejo de horas especiales, como vacaciones, incapacidades, guardas u horas extras asociadas a los empleados de la Corporación Intel en Latinoamérica.
El proyecto de graduación se desglosa en tres etapas fundamentales. La primera es de investigación y análisis sobre lecturas afines. Algunos de los modelos analizados son: CMMi, Proyectos Tradicionales o en Cascada, Proyectos en Espiral, AGILE, aunque también se estudian técnicas para analizar negocios desde la perspectiva de sistema automatizable con un flujo de datos definido, y técnicas de diseño para aplicaciones web. Estas últimas se presentan desde una perspectiva técnica muy básica, aunque enriquecido con la experiencia adquirida en el desarrollo de otros proyectos de software y de interés para el cliente.
x
La segunda propone una metodología de trabajo para la Gestión del Alcance que combina los conceptos estudiados y definidos en las distintas técnicas analizadas. Esta se desglosada en diez pasos agrupados en tres etapas de proyecto: (1) Pre-exploración, (2) Exploración y (3) Planeación. Los primeros cinco pasos se pueden ejecutar de una forma secuencial siguiendo la conceptualización en cascada, donde cada uno se alimenta de los resultados de los anteriores. Al iniciar los pasos numero seis y siete, los cuales corresponden al Diseño y Revisión de Requerimientos, el flujo metodológico se convierte en un proceso mas iterativo, donde las actividades de diseño y planeación retroalimentan la definición de los requerimientos antes de que estos sean aprobados por el cliente, de tal forma que se minimice la cantidad de cambios que puedan ser introducidos por una falta de análisis.
La tercera etapa finaliza este proyecto de graduación con una serie de conclusiones, recomendaciones y lecciones aprendidas, entre las cuales se tiene que la gran mayoría de técnicas para definir y manejar requerimientos no toma en cuenta los beneficios que la labor de diseño puede aportar durante la definición detallada del alcance, como dos actividades que se complementan entre sí de una forma orgánica, y no separada o minimizada como se sugiere en otras metodologías.
También se comprueba de una forma positiva que el cambio analizado entre el
PMBOK 2003 y el 2008 es un aliciente para la propuesta de este proyecto de graduación, ya que aunque el PMBOK 2008 no ofrece ningún proceso que indique una retroalimentación necesaria a la hora de definir el alcance, sí introduce el concepto de elaboración progresiva, centralizada en el Plan de Gestión del Proyecto.
A su vez se verifica que el modelado de datos representa una herramienta muy
valiosa para retroalimentar la gestión del alcance en proyectos de software, debido a que permite establecer un puente entre el modelado de procesos del negocio y el diseño del sistema, el cual permite detallar el alcance desde una perspectiva técnica. Cuando no se realiza modelado de datos en el diseño de un sistema, por más pequeño que sea, es muy fácil obtener una aplicación ineficiente, con serios problemas de desempeño, de explosión / crecimiento de datos y manejo de recursos del sistema.
Otro aspecto interesante a mencionar dentro de las lecciones aprendidas durante
la administración de proyectos de software es que si el equipo no tiene experiencia en la estimación de tiempos para proyectos con características similares, el diseño DEBE realizarse antes de la estimación de tiempos como parte de la definición del alcance, debido a que aporta el grado de confiabilidad necesaria para establecer un compromiso de tiempo/costo acertado.
Por ultimo, la visión de crear este proyecto de graduación es que este sea un
documento que le ayude a Ud. como lector, a resolver problemas similares durante la Gestión del Alcance. Con esta metodología es posible que se logre minimizar la oscuridad inicial que se presenta por la gran cantidad de variables en proyectos de software, y así establecer un plan sólido para enfrentarse a las áreas subsiguientes de la Administración de Proyectos. Este es tan solo el principio del todo.
11
I Introducción
I.1 Antecedentes
El desarrollo de software, en especial de aplicaciones web, es una actividad humana
relativamente nueva, en la que el conjunto de las mejores prácticas de conocimiento
están aún siendo exploradas y debatidas. Existen tendencias de trabajo, o
metodologías, que dependen mucho de la cultura y formación de la organización, del
tamaño o escala del proyecto, del objetivo general – ya sea para establecer un modelo
de desarrollo continuo sobre un sistema existente, o más bien crear una aplicación
desde un inicio. Debido a esta diversa cantidad de variables, en la que resalta la
ingeniosa naturaleza humana como recurso de desarrollo indispensable en este tipo de
proyectos, es de esperar que las distintas metodologías de trabajo existentes sean
también muy variables y en algunos casos hasta contrapuestas entre sí, ya que tratan
de atacar el mismo problema desde perspectivas opuestas, como si el objetivo de
algunas metodologías fuera mitigar el impacto negativo de otras, y no resolver el
problema de una forma integral.
A pesar de la diversidad de enfoques para establecer las metodologías de desarrollo
de proyectos de software, está claro que la Ingeniería de los Requerimientos y el
Análisis de Sistemas es una labor vital para el éxito inmediato o de mediano y largo
plazo de las entidades que lo implementen. Según Mike Mannion y Barry Keepence
(1995), esta fase inicial del proyecto en la que se explora un negocio o se analiza un
sistema para poder especificar sus requerimientos es todo un arte, en el que se
combinan habilidades como:
• discriminar en la escucha,
• describir y explicar visualmente,
• comprender conceptos abstractos de una forma ágil y rápida
• interesarse genuinamente y con entusiasmo por resolver los problemas de
otras personas
12
• poder especificar y documentar estos conceptos de una forma clara y
concisa.
La última habilidad enunciada se ha logrado mejorar a través de la experiencia que
nuevos proyectos de desarrollo de software van aportando al bagaje de “mejores
prácticas”, recopiladas colectivamente por distintos grupo afines. Estos conocimientos
han ayudado a crear técnicas de modelado formal y análisis estructurado, las cuales se
mencionaran y en el Marco Teórico del presente documento.
I.2 Descripción del Problema
En el conjunto de proyectos de desarrollo de aplicaciones empresariales, en las que
se enfoca este trabajo, todavía permanecen ciertas dudas de cuando utilizar una
metodología en contraposición con otra. Tampoco se cuenta con gran claridad que
permita llegar a saber cual es la mejor manera de escribir los requerimientos sin perder
detalles importantes que luego se vuelvan malentendidos, ni de donde extrapolarlos de
una forma clara y visual, tanto para el equipo del proyecto, como para sus clientes.
Entonces se puede hablar que en esta tipo de metodologías no existen recetas para ser
aplicadas tal cuales, pues los factores que intervienen son múltiples como los seres
humanos que participan.
La planificación de un proyecto de desarrollo de software es todavía un tema muy
difuso, con muchas incógnitas, a pesar que existen ciertos estándares para la
administración de proyectos, como los definidos por el “Project Management Institute”
(PMI, por sus siglas en inglés), que tratan de establecer guías para iluminar los pasos
importantes que deben definirse durante la planificación (el QUE). En el área de
desarrollo de software, el COMO todavía esta en ciernes, y es aquí donde este trabajo
pretende ofrecer algunas ideas y concreciones basadas en experiencias laborales y en
análisis que de ellas se han realizado en diferentes circunstancias.
13
I.3 Justificación del Proyecto
La relación entre alcance y diseño es todavía un concepto discutible. Para un
proyecto civil, por ejemplo, el diseño consiste en desarrollar los planos de una casa, lo
cual es un entregable muy visual que sintetiza los requerimientos estructurales del
producto que se pretende desarrollar. En el caso del desarrollo de software, los
entregables para la definición del alcance varían según los procedimientos que la
organización haya elegido como los estándares para la administración de sus
proyectos. Se sigue dependiendo entonces de la capacidad creativa, de la calidad del
análisis y síntesis, de la interpretación del deseo de los clientes y un poco del sexto
sentido por parte del director del proyecto y su equipo de investigación, para lograr
establecer un alcance que sea entendido como tal por los distintos involucrados.
Este trabajo no pretende generalizar la definición del alcance, ya que como se ha
mencionado, la índole de un proyecto de desarrollo de software tiene variables que hay
que analizar antes de tomar una decisión sobre la metodología por seguir. Sin embargo,
pretende ofrecer una manera estructurada y ejemplificada de cómo definir el alcance de
un proyecto de desarrollo para aplicaciones empresariales, donde el objetivo sea crear
un sistema completamente nuevo para solucionar un problema de negocio o
automatizar un proceso. No se tomarán en cuenta aplicaciones SAP o proyectos,
donde su objetivo principal es configurar un sistema genérico, para lograr una aplicación
específica.
14
I.4 Objetivos de este trabajo
I.4.1 Objetivo General
Desarrollar una metodología para la gestión del alcance en proyectos de desarrollo
de aplicaciones empresariales que combine conceptos de distintas técnicas ya
establecidas para mejorar la experiencia de administrar proyectos.
I.4.2 Objetivos Específicos
• Estudiar y analizar técnicas de modelado de negocios, procesos y datos
para comprender como pueden ser utilizadas durante la gestión del alcance en
proyectos de software.
• Investigar técnicas para definir y manejar requerimientos en proyectos de
desarrollo de software.
• Entender las diferencias entre el PMBOK 2003 (versión 3) y el 2008
(versión 4) en relación con la Gestión del Alcance.
• Proponer una metodología de gestión del alcance con base en los
estándares del Instituto de Administración de Proyectos (PMI) definidos en el
PMBOK.
• Utilizar los modelos analizados para enriquecer la propuesta metodológica
de este proyecto de graduación.
• Utilizar el proyecto LAR Leave Consolidation para ejemplificar la propuesta
metodológica y así ofrecer una experiencia mas practica al lector.
15
II Marco Teórico
Las organizaciones que se dedican al desarrollo de software pueden tener diversas
estructuras jerárquicas, que por lo general dependen de la forma en que nacieron. Y
aunque muchos empresarios de la industria del software reconocen que la estructura
que elijan tiene un impacto directo en alcanzar el éxito de sus objetivos, no existen
lineamientos claros de cual es la mejor forma de administrar sus proyectos de software.
El tamaño de una organización de desarrollo de software puede ser variado. Se
pueden encontrar pequeñas empresas incipientes formadas en el garaje de sus
fundadores o grandes departamentos de Tecnología de la Información (IT)
pertenecientes a las 500 compañías más famosas enlistadas en la revista Fortune,
como lo son Microsoft, Google o Intel.
II.1 Dimensiones de una organización
Según Hamilton y Kern (1999) las organizaciones no solo se construyen de
diagramas con nombres y títulos encerrados en cuadros y conectados por líneas
jerárquicas, sino que también existen diversas dimensiones que las caracterizan, como
por ejemplo:
• La gente: Cada individuo en una organización tiene ciertas habilidades y
competencias, las cuales se miden por medio de indicadores formales o
informales, que a su vez dirige los paquetes de compensación para incentivar
mejoras en el desempeño. Las personas de una organización establecen su
cultura , es decir, los patrones de comportamiento o valores adoptados en la
organización. En la industria de desarrollo de software, el recurso más importante
para establecer el COSTO de un proyecto es la gente.
• Los procesos: Estos se refieren a los procedimientos y metodologías
utilizadas por la gente de una organización. Casi todas las organizaciones
definen su propia economía a través de procesos para estimación de costos,
definición de prioridades y aprobación de proyectos. En muchos casos, los
procesos pueden burocratizar el sistema y hacer que la organización se vuelva
lenta y engorrosa. Por lo que al mismo tiempo que se establecen procesos, se
16
deben establecer límites , como por ejemplo en el proceso de aprobación de
proyectos, se podría definir que solo se requieran dos o tres firmas de
aprobación.
• La tecnología: Debe facilitar el empleo de herramientas que las personas
de una organización utilizan para llevar a cabo las distintas funciones o tareas del
negocio. En el caso de desarrollo de software, la tecnología es indispensable
para realizar el trabajo.
• La estructura es la dimensión que unifica las tres anteriores, ya que
establece la interrelación que debe existir entre la gente de una organización
para alinearlas a objetivos comunes. Sin una estructura estable y bien definida,
las personas empiezan a competir por recompensas individuales, más que por el
bienestar de la organización. Al mismo tiempo, los procesos no tendrían cabida y
la economía de la organización podría colapsar, debido al conflicto de intereses.
La tecnología se visualiza con interés investigativo, en lugar de como una
herramienta en sí misma, para lograr objetivos y resultados.
II.2 Estructuras Organizacionales
La mayoría de las organizaciones que se dedican al desarrollo de software trabajan
por desarrollo de proyectos, entonces por lo general su estructura está influenciada por
alguna de las formas referidas a continuación (Hamilton y Kern, 1999) y cuyo desglose
tabular sobre estructuras organizacionales está enriquecido con información extraída
del segundo capitulo, sección 2.3.3 del PMBOK (2003):
• Organización Centrada en Desarrollo de Proyectos :
Generalmente se encuentran en empresas recién formadas u organizaciones
pequeñas, no más de 40 personas, que podrían soportar alrededor de 1 a 8 proyectos
de menos de un año de duración. En este tipo de organizaciones, cada grupo es
prácticamente independiente y tiene suficientes recursos con las habilidades necesarias
para todas las etapas del ciclo de vida de cada proyecto, lo que implica que la mayoría
17
de las personas tienen responsabilidades administrativas, además del desarrollo de
software.
Generalmente, cuando estas organizaciones crecen se convierten en entidades
centradas en departamentos, ya que cada grupo deja de tener el privilegio de poder
trabajar dentro de su propio ecosistema. Los recursos deben empezar a compartirse
para resolver las necesidades de la mayoría de los proyectos.
• Organización Centrada en Departamentos :
Estas organizaciones se pueden estructurar en departamentos agrupados por las
habilidades de los recursos o por etapas especificas del ciclo de vida de los proyectos.
Por ejemplo se podrían crear departamentos especializados en:
o Administración de sistemas y bases de datos
o Desarrolladores de software
o Validación de la calidad y administración de la configuración
Algunas organizaciones centradas en departamentos tienden a separar a los
arquitectos del software de los programadores, lo que según Hamilton y Kern (1999) es
un error, porque puede crear elitismo y problemas en la interacción entre ambos grupos.
Aunque no todos los desarrolladores quieren llegar a ser arquitectos, sí les gusta estar
involucrados en el diseño, por lo que si se separan, es posible que el desarrollador no
quiera seguir los lineamientos del diseño presentados por el arquitecto, si no le gusta o
no tiene potestad de cambiarlo, por lo que lo implementaría a la ligera. Y si la aplicación
no cumpliera con los objetivos o llegara a estar mal implementada, el arquitecto culparía
al desarrollador por no seguir su diseño.
• Organización Matricial:
Este tipo de organización se utiliza, por lo general, en compañías con un gran
número de desarrolladores de software – en el orden de centenas – que trabajan en una
gran variedad de proyectos de software. En un lado de la matriz tenemos la lista de
habilidades y competencias, mientras que en el otro se encuentra el portafolio de
18
proyectos. En una organización matricial, cada recurso de contribución individual tiene
dos “jefes”, provenientes de cada lado de la matriz. Por lo general, el recurso
permanecerá en un departamento determinado, mientras su habilidad o competencia
sea compatible con esta área. Al terminar un proyecto determinado, el recurso “regresa”
a su departamento para una nueva asignación. Los recursos pueden estar asignados a
varios proyectos al mismo tiempo, y es posible que no todos los proyectos requieran
recursos de cada departamento.
Cada departamento es responsable de contratar y capacitar sus recursos, además
de encontrarles asignaciones a proyectos, por lo que es posible que existan lapsos de
tiempo en los que algunos recursos no estén asignados a proyectos, ni “generando”
ingresos a la compañía. Lo que evidencia que este tipo de organizaciones se aplican a
compañías relativamente grandes, que puedan solventar este sobrepeso.
El desafío más grande de las organizaciones matriciales es lograr el número
correcto de departamentos, con las habilidades y competencias adecuadas, así como
mantener la lealtad de sus recursos hacia los proyectos, ya que la administración del
recurso a largo plazo recae sobre su propio departamento.
• Organización por Línea de Producto:
Para comprender este tipo de organizaciones vale aclarar ciertos términos, según
fueron definidos por la Corporación Intel, 2007
o Producto : corresponde a cualquier bien terminado, el cual puede
ser un grupo de datos, una aplicación o una tecnología, que se entrega al
cliente como una solución completa o en parte para su consumo y
satisfacción.
o Línea de Producto : es un conjunto de productos que ofrecen un
paquete de funciones similares o relacionadas entre si.
o Director de Líneas de Producto : tiene la responsabilidad de
interactuar entre distintas líneas de negocio, comprender sus necesidades
y escenarios de alcance para ofrecer las soluciones mas apropiadas. Esto
19
incluye la comunicación de estrategias a interesados, clientes, vendedores
y socios laterales.
En las Organizaciones por Línea de Producto, los recursos son asignados a
proyectos organizados por las líneas de producto o negocio, en contraposición a
departamentos por área de habilidades y competencias. Este tipo de organizaciones es
responsable de encontrar recursos con las habilidades correctas para cada proyecto en
cualquier parte de la organización. Esto funciona, si la organización es lo
suficientemente grande como para solventar duplicidad de funciones, y tener suficientes
recursos para las épocas duras, aunque estén sin trabajo real en periodos de menor
actividad.
En estos casos existe el riesgo de que algunos recursos se puedan quedar sin
trabajo por periodos indefinidos, por lo que se han visto algunas tendencias a “eternizar”
los proyectos para evitar movilidades indeseables.
II.3 Modelos de desarrollo y administración para Si stemas de Software
La mayoría de las aplicaciones de software se desarrollan con base en un modelo
de negocio , por ejemplo si se desea administrar una estación de trenes para
calendarizar la entrada y salida de los viajes o registrar un listado de posibles rutas, es
necesario modelar el negocio de la estación.
Siguiendo la misma línea de pensamiento, aunque desde un punto de vista más
abstracto, cada negocio tiene un flujo determinado de datos. En el caso de la estación
de trenes, un flujo posible de datos puede ser la ruta que sigue un pasajero
determinado, el cual puede estar formado de uno o más viajes en tren. Por lo que el
modelado de datos del ejemplo en cuestión tiene que contemplar los tiempos de
espera que un pasajero debe hacer entre dos viajes consecutivos.
20
Alec Sharp (2008) muestra en su presentación de extras para el seminario de
“Advanced Modeling”, el siguiente cuadro para ilustrar los primeros pasos que un
proyecto de desarrollo de software puede seguir para definir su alcance.
Figura No. 1 : Pasos para la definición del Alcance según Alec Sharp, 2008
Como se observa, la metodología para definir el alcance esta muy asociada al
tamaño del proyecto. En el primer caso, para proyectos grandes en el que se involucra
el análisis de un negocio complejo, quizá con varias redes de sistema asociadas, la
definición del alcance debe estar orientada a un proceso de reingeniería en el que se
modele el flujo de trabajo existente para luego proponer un flujo optimizado /
automatizado. A esta metodología, Alec Sharp la califica como “outside-in”, porque el
análisis va de afuera (modelado del negocio) hacia adentro (modelado de datos).
Mientras que para proyectos más pequeños, en el que quizá ya exista una aplicación, la
cual se pretende optimizar, el análisis para definir el alcance debe darse de adentro
(seguimiento de datos) hacia fuera (comprensión del negocio), por lo que se califica
como “inside-out”.
21
II.3.1 Modelado de Procesos:
Existen diversas técnicas para modelar los procesos que involucran el desarrollo y la
administración de software. En este apartado se describen las más conocidas, sin
embargo hay una gran cantidad que no se mencionan, por lo que si se desea conocer
más al respecto, se recomienda revisar cualquier enciclopedia del internet mundial.
• Capability Maturity Model Integration (CMMi): Este es el sistema más
utilizado en la elaboración de aplicaciones a gran escala, ya que se basa en técnicas
de mejoramiento continuo para la madurez de una organización con respecto a sus
técnicas y procesos de administración de proyectos. CMMi se originó en el Software
Engineering Institute (SEI) de la Universidad de Carnegie Mellon con el objetivo de
ayudar a dimensionar las características que las organizaciones de software tienen
para desarrollar sus negocios. Según Crisis, Beth, Mike Konrad y Sandy Shrum, en
su libro CMMI, 2006, la idea para desarrollar el modelo CMMi se basó en el fuerte
triángulo relacional que existe entre la gente, las herramientas y los procesos de una
organización. Se le dio énfasis a la utilidad de los procesos, debido a que estos
permiten alinear a la gente en un negocio y analizar sus tendencias, establecer las
reglas del juego y proliferar el conocimiento adquirido en experiencias anteriores
para mejorar continuamente los proyectos venideros. Cinco áreas de exploración
nacieron de esta iniciativa:
o Planeación, seguimiento y administración del calendario.
o Definición de requerimientos y control de la configuración
o Valoración de los Procesos
o Medición de la calidad y mejoramiento continuo
o Mejoramiento evolutivo
Y del análisis de diversas empresas de desarrollo de software, cinco niveles de
madurez fueron establecidos para medir la capacidad que una organización tiene
para lograr el mejor provecho de sus procesos, y por ende de sus negocios. Así todo
modelo CMMi refleja algún nivel de madurez como se muestra en la Tabla no. 1
22
Cuadro No. 1 : Niveles de Madurez - CMMi, compuesto con base en Mary Beth Crisis, Mike Konrad y Sandy Shrum (2006)
Nivel Características
1 – Inicial Los procesos son ad hoc y caóticos. La organización no ofrece un ambiente
estable para mantener sus procesos. El éxito de sus proyectos depende de la
competencia y características heroicas de su gente. Sin embargo, en la mayoría de
los cosas no se logran alcanzar las metas de tiempo y costo, por lo que estas
organizaciones se caracterizan por una tendencia a sobre comprometerse, abandono
de procesos en tiempos de crisis y una incompetencia para repetir sus éxitos.
2 – Administrado La organización ha demostrado que sus procesos son planeados y ejecutados con
base en una política de empresa. Los proyectos utilizan gente especializada según
sus requerimientos para producir resultados esperados, por lo que en tiempos de
crisis la disciplina establecida en sus procesos, impide que haya un abandono de los
mismos, por lo que favorece la posibilidad de repetir éxitos logrados con anterioridad.
3 – Definido Los procesos están bien definidos y estandarizados, lo que permite consistencia a
través de toda la organización. Un distinción importante entre el nivel 2 y el 3 es que
en un nivel 2, dependiendo de las características especificas de un proyecto, los
procesos pueden variar considerablemente, sin relación aparente entre los mismos.
Mientras que en una organización con nivel 3 de madurez, las características
especificas de cada proyecto se derivan de los procesos estandarizados de la
organización, por lo que son más consistentes.
4 – Administrado
Cuantitativamente
La organización y sus proyectos establecen objetivos cuantitativos para la
valoración de la calidad y el desempeño de sus procesos, y utilizan estos resultados
para la administración de sus procesos. De tal forma que en teoría, una organización
con nivel 4, puede predecir de forma cuantitativa el comportamiento de sus procesos
en proyectos determinados y con características similares. Este nivel es muy difícil de
alcanzar, ya que los datos cualificados dependen mucho de decisiones subjetivas
realizadas por el equipo de cada proyecto.
5 - Optimizado La idea de este nivel es que una organización con un nivel 5 de madurez puede
mejorar continuamente sus procesos con base en un entendimiento cuantitativo de las
causas comunes que producen variaciones inherentes en sus procesos. Este es un
nivel tan controlado, que existe cierta oposición a lograrlo, ya que la eficiencia que se
gana en mejoramiento continuo de sus procesos para minimizar duplicaciones, se
pierde en la administración misma de sus procesos, y en el tiempo dedicado a llenar
el papeleo que este nivel requiere.
23
Lo mejor es lograr un balance entre la administración de los procesos de una
empresa, el objetivo de un proyecto, las herramientas disponibles y la capacidad de
su gente.
• Modelo en Cascada – Ciclo de Vida Tradicional
Este modelo es muy utilizado en los ciclos de vida de proyectos tradicionales de
software. Sus procesos están muy bien definidos y se representan en fases
diferentes del proyecto, como se muestra en la Figura No. 2 . Algunas desventajas
que se le han reconocido, es que como el desarrollo del sistema se visualiza de una
forma secuencial, en el que una etapa depende la anterior, la retroalimentación del
diseño hacia los requerimientos es muy poca, por lo que aumenta la probabilidad de
que hayan cambios en fases tardías del proyecto. Por esta razón, en la mayoría de
proyectos tradicionales se debe definir un proceso de manejo de cambios de
requerimientos robusto durante la definición de los requerimientos.
Figura No. 2: Modelo en Cascada, Intel (2009)
24
• Modelo Espiral de Bhoem
El modelo de Bhoem combina elementos de diseño y del modelado en cascada,
así como de metodologías para la realización de prototipos. Este fue ideado por
Barry Bhoem en 1988 para explicar por qué las iteraciones son importantes en el
desarrollo de software. Como se observa en le Figura No. 3 , este es un sistema
con base en iteraciones en el que las distintas etapas del proyecto se traslapan y se
retroalimentan entre si, de tal forma que posibles errores en la concepción del
producto o definición de requerimientos se pueden detectar en fases tempranas del
proyecto. Este modelo es muy utilizado en proyectos militares de gran envergadura,
donde la retroalimentación que los prototipos ofrecen a los requerimientos es
importante para lograr la efectividad del sistema.
Figura No. 3: Modelo en Espiral de Bhoem, Philippe Wolkovicz (1999)
25
• AGILE
Este modelo se refiera a un conjunto de metodologías que se relacionan con al
concepto de iteraciones definido en el modelo de espiral de Bhoem. Se utiliza sobre
todo en organizaciones cuya cultura empresarial ha adoptado un ritmo de trabajo
iterativo, en lapsos de dos a cuatro semanas, y donde se requiera la colaboración
entre equipos de trabajo y sus clientes o patrocinadores. AGILE enfatiza en la
comunicación cara a cara, y en el desarrollo de código en parejas, al dividir las
actividades de un proyecto en pequeños incrementos de trabajo con una minima
necesidad de planeación. El conjunto de metodologías AGILE esta basado en un
manifiesto que prioriza los siguientes principios:
o Individuos e Interacciones sobre procesos y herramientas.
o Software funcional sobre documentación comprensiva
o Colaboración del cliente sobre negociación contractual
o Responder al cambio sobre seguir un plan
En este caso lo importante es la “rapidez” en la obtención de resultados, la
simplicidad en la administración del proyecto y la flexibilidad de adaptación al
cambio, por lo que su aplicación parece ser mas marcada en proyectos de desarrollo
continuo sobre productos existentes o en proyectos pequeños, cuyos integrantes de
equipo, clientes e interesados están localizados en un mismo lugar.
26
Algunas de las metodologías pertenecientes a AGILE se describen a
continuación:
Figura No. 4: eXtreme Programming
o Extreme Programming (XP):
Esta metodología fue creada por Kent
Beck en 1996 y lo que hace es llevar
prácticas de desarrollo de software
conocidas a niveles extremos. XP se
basa en la idea de que ningún proceso
se aplica de la misma manera a dos o
más proyectos, por mas que se
parezcan, por lo que debe haber una
adaptación explicita a las necesidades
del proyectos, que puede dar de forma
estática, en la que el contexto del proyecto se da al inicio del mismo, o dinámica, en
la que el contexto se construye incrementalmente a través del proyecto. RDP es una
técnica presentada durante la Conferencia de ICSE 2008 para estructurar la
adaptación explicita de los procesos XP. Algunas de las prácticas de XP son:
� Codificar diversas alternativas para elegir la que mejor funcione. Para
ello se utiliza “pair programming ”, en la que es necesario que dos
personas trabajen en el mismo código a la vez.
� Validar conforme se va codificando por medio de “unit tests ”,
automatizados en paralelo al código.
� Escuchar lo que el analista de negocio o cliente indique para cada
actividad desarrollada. Esta actividad se realiza por medio de una reunión
conocida como “planning game ”, la cual ocurre al inicio de cada iteración,
generalmente una vez por semana. En ella se establecen los “user
stories ” que son requerimientos vistos desde el punto de vista del usuario.
� Diseñar : esta actividad no está muy clara en el modelo de XP, por lo
que muchas veces se termina con un sistema inflexible y lleno de parches.
Este es uno de los puntos controversiales de esta metodología.
27
o SCRUM: Este es una
metodología de procesos
iterativos incremental,
descrita por primera vez y de
una forma holística por
Hirotaka Takeuchi e Ikujiro
Nonaka en 1986, quienes la
compararon con el juego de
rugby , en la que los
Figura No. 5: SCRUM
integrantes de cada equipo tienen que llevar una bola de un lado a otro como grupo
pasándosela uno a otro.
SCRUM no es un acrónimo, es un término mencionado en el libro de Takeuchi y
Nonaka, y representa un conjunto de procesos y roles predefinidos. SCRUM tiene
tres roles:
� Maestro del Scrum (Scrum Master): Este mantiene la viabilidad
de los procesos y funciona como un director de proyecto.
� Dueño del Producto: Quien representa a los clientes e
interesados. Es el que mejor conoce el producto deseado.
� Equipo: Los desarrolladores del producto.
Durante cada “sprint ” o iteración, la cual dura de dos a cuatro semanas, el
equipo desarrolla un incremento del software utilizable. El grupo de actividades
incrementales viene de una pila de requerimientos ordenada en orden de prioridad,
llamada en inglés “Product Backlog ”, y luego en orden de “sprint ” (“Sprint
Backlog ”) Cada vez que un sprint finaliza, se le muestra al Dueño del Producto para
verificar que funciona según las expectativas.
28
II.3.2 Modelado de Datos:
Este es un tema que se introduce por lo general en las carreras de Ingeniería en
Sistemas. Sin embargo, en la práctica profesional es difícil lograr su experticia, debido a
que se requieren habilidades muy diferentes entre si, como por ejemplo: lógica
matemática, inteligencia espacial e inteligencia oral.
El modelado de datos es una metodología utilizada para analizar los datos en los
requerimientos de una aplicación. Esta se realiza de una forma progresiva iniciando
desde una perspectiva conceptual, en la que el analista o modelador de datos agrupa
terminologías y actividades del negocio de una forma contextual, hasta entender la
lógica en el flujo de esos datos. De esta forma, una empresa u organización que realice
modelado de datos de una forma sistemática puede lograr una compatibilidad de datos
a través de diversos sistemas. A continuación se presenta la definición de una serie de
conceptos correspondientes al campo semántica del modelado de datos.
• Regla de Negocio: Son oraciones afirmativas, sencillas, con solo un verbo activo
que explican la actividad o relación que existe entre dos entidades del negocio.
Por ejemplo: el artista puede cantar muchas o ninguna canción.
• Entidades : Es el vocablo que representa a personas, cosas, roles, productos o
asociaciones de vocablos correspondientes al negocio. Las entidades se tienen
que definir en singular, por ejemplo “artista” o “canción”.
• Atributos : Corresponde a las características de una entidad. Por ejemplo el
“nombre” de la canción.
• Relaciones : Estas corresponden al verbo activo de la regla de negocio. En el
caso de la Figura No. 6 , la relación seria “canta” o “compone”.
Existen diversos modelos de datos, que presentan la información de un negocio
desde distintas perspectivas y con distintos objetivos, por ejemplo un modelo contextual
agrupa los datos según su contexto, o un modelo dimensional establece la relación que
existe entre las distintas áreas contextuales con respecto al producto o dimensión
central del negocio. Sin embargo, hay tres modelos básicos indispensables para
cualquier análisis de datos. Estos tres modelos son:
29
• Modelo Conceptual : Establece la relación que existe entre distintas
entidades, según las reglas y terminologías utilizadas en la organización.
Este modelo se puede representar de diversas formas y nomenclaturas,
siendo el ERM uno de ellos. Un ejemplo de este modelo se presenta en la
Figura No. 6 .
Figura No. 6: Modelo Entidad-Relación (ERM, por sus siglas en inglés)
• Modelo Lógico: El primer modelo lógico fue creado por ANSI en 1975,
para dos formas relacionales: jerárquica y de red. La importancia de este
modelo radica en que es el puente o enlace entre el modelo conceptual,
el cual es más fácil visualizar desde una perspectiva humana, y el físico,
que corresponde a la base de datos de la aplicación. En este punto del
modelado de datos, se deben establecer las características de los
atributos y las relaciones que existen entre las entidades, como se
muestra en la Figura No. 7
Figura No. 7: Modelo Lógico (según la notación pata de gallo)
• Modelo Físico: Este modelo es lcon base en datos de un sistema. Para
aplicaciones medianas, este modelo puede tener alrededor de 40 tablas,
por lo que ya es difícil de visualizar y comprender a primera vista.
Estos modelos se podrán comprender mejor cuando se apliquen al proyecto
analizado en este documento.
30
II.4 Marco Referencial
Como se ha mencionado, el presente documento se basa en la experiencia que se
fue adquiriendo conforme fue avanzando la etapa de exploración y definición del
alcance del proyecto LAR Leave Consolidation, una aplicación que pretende integrar
varios servicios, procesos y aplicaciones existentes para ofrecer una solución integral al
manejo de tiempos especiales que se le asignan a los empleados de la Corporación
Intel en América Latina. Los tiempos especiales incluyen vacaciones, incapacidades,
guardas y horas extra que los empleados pueden tomar como parte de su paquete de
beneficios.
Consiste en una aplicación que inició su etapa de exploración en noviembre del
2008 y se considera un proyecto grande ya que en comparación con otros proyectos se
puede inferir que su etapa de desarrollo o ejecución va a durar por lo menos 26
semanas. A su vez se ha elegido una metodología de “outside-in”, en la que se debe
comprender el negocio existente, basado en un conjunto de soluciones independientes
integradas a través de procesos manuales e incompatibles entre los distintos países de
Latino América, hasta establecer una solución con un nuevo modelo de datos que
ofrezca una solución integral.
La región de Latinoamérica que se maneja por la organización de Recursos
Humanos en la Corporación Intel Costa Rica está integrada por cuatro países:
Argentina, Brasil, Costa Rica y México. Uno de los desafíos más grandes que involucra
este proyecto es que cada uno de estos países maneja sus tiempos especiales bajo
distintas leyes laborales por lo que, por ejemplo, el cálculo de vacaciones varía
considerablemente de una nación a otra.
Otro problema conocido es que existen por lo menos doce aplicaciones que manejan
distintos tipos de horas especiales, por lo que en algunos casos no se conoce la
prioridad o integración que existe entre ellas. La resolución de conflictos entre los
tiempos especiales es muy subjetiva y depende del caso especial de cada empleado.
31
II.4.1 Estándares para la Administración de Proyect os en IT de Intel
El departamento de Tecnología de la Información de la Corporación Intel se base en
el siguiente gráfico para especificar el Ciclo de Vida de sus proyectos:
Figura No. 8: Ciclo de Vida general de los proyectos en IT
Algunos puntos importantes a rescatar de la Figura No.8 son:
• Todos los documentos asociados a las distintas etapas del ciclo de vida de
un proyecto se guardan en un repositorio de datos. Esto facilita el aporte y
seguimiento de ideas o tareas entre los integrantes del equipo.
• Cada etapa del proyecto finaliza con alguna decisión importante que
alinea el proyecto a la directriz propuesta en su alcance.
El trabajo desarrollado en este proyecto de graduación transcurre en las dos
primeras etapas y se extiende al inicio de la tercera. Sin embargo, no se involucra en
áreas de administración de proyectos como la definición de tiempo y costo, que se
estiman durante las etapas de Exploración y Planeación, según la Figura No. 8
32
La mayoría de las organizaciones del departamento de Tecnología de la Información
en la Corporación Intel tienen un nivel de madurez 2, por lo que la clasificación de sus
proyectos no se deriva de una definición general que los englobe a todos, sino que se
agrupan en base al concepto de Ciclo de Vida graficado en la Figura No. 8 como se
muestra a continuación:
• Proyectos Tradicionales: Este concepto agrupa casi todos los proyectos
de desarrollo de aplicaciones empresariales que se crean en la organización o
involucren un análisis de mejoramiento continuo o de administración del negocio.
Los procesos que siguen estos proyectos están muy alineados con el modelo
CMMi, e incluye las siguientes clasificaciones:
o Proyectos en cascada: Donde cada etapa depende de la anterior
para poder iniciarse y desarrollarse.
o Non Software: Proyectos de Mejoramiento Continúo o de
Administración del Negocio.
• Proyecto Iterativos: Estos proyectos tienen alguna etapa que se repite
varia veces durante su ciclo de vida y también siguen el modelo CMMi. En este
caso se encuentran:
o Proyectos Espirales: Los cuales tienen múltiples implementaciones,
por lo que las etapas de planeación, desarrollo y migración se pueden
repetir varias veces
o RUP (Rational Unified Process): Este tiene varias iteraciones en las
etapas intermedias de planeación y desarrollo, pero con sola una etapa de
migración.
• Proyectos AGILE: Estos proyectos siguen la metodología AGILE, la cual
requiere las etapas de análisis, diseño, construcción y validación se completen
en iteraciones cíclicas de 15 a 22 días, con puntos de control muy rigurosos.
33
• Proyectos SAP : Estos involucran por lo general una operación masiva
con una transformación grande de negocio. Todo el proceso puede tomar años, y
es muy común encontrar que prácticamente todas las personas de una
organización están involucradas de una u otra manera, por lo que fácilmente
pueden ser proyectos con equipos de trabajo de tres dígitos.
• Proyectos Pequeños: Estos son proyecto de soporte o para probar un
concepto (POC). Por lo general duran menos de 8 semanas para completar
todas sus fases.
II.4.2 Proyectos Tradicionales
El ciclo de vida de los proyectos
tradicionales de la mayoría de las
organizaciones de IT debe cumplir con los
pasos enlistados en la Figura No.9 , en la
que se observa que el único documento
asociado directamente a la definición del
alcance es “Plantilla de Requerimientos”,
el cual consiste en una plantilla de Excel,
con datos similares al de una Matriz de
Seguimiento de Requerimientos.
El proyecto LAR Leave Consolidation se
considera un Proyecto Tradicional, debido
a que cada una de sus etapas depende de
la anterior. Por esta razón, el presente
documento se enfoca en este tipo de
proyectos con algunas variaciones propias
de los proyectos iterativos.
Figura No. 9: Lista de Documentos para
Proyectos Tradicionales
34
II.5 Actualizaciones en le Gestión del Alcance desd e la perspectiva PMBOK
Este año 2008, el Instituto para la Administración de Proyectos, PMI por sus siglas
en inglés, ha actualizado su guía de estándares PMBOK (Project Management Body of
Knowledge) con la cuarta edición del documento. Existen varios cambios sustanciales
en la conceptualización de la Gestión del Alcance, debido a que la Planeación del
Alcance (versión 3 - 5.1) y el Enunciado Preliminar del Alcance (versión 3 - 4.2) de la
tercera edición han sido sustituidos por el concepto de elaboración progresiva. De tal
forma que:
• La Planeación del Alcance (versión 3 - 5.1) es ahora parte del Plan de Gestión
del Proyecto.
• La duplicación conceptual entre el Acta del Proyecto (versión 3 - 4.1) y el
Enunciado del Alcance (versión 3 - 5.2.3.1) se ha reconocido, de tal forma que el
enunciado del alcance tiene ahora menos información.
• Y dos nuevos procesos han sido agregados:
o Área de Gestión de la Comunicación : Identificación de los Interesados
(versión 4 – 10.1)
o Área de Gestión del Alcance : Recolección de Requerimientos (ver. 4 – 5.1)
Figura No. 10: Transición del PMBOK 2003 al 2008
35
III Marco Metodológico
III.1 Herramientas y Fuentes de Información
La elaboración de este documento se basa en dos fuentes de información
importantes. La primera corresponde a la experiencia adquirida en la administración y
participación de proyectos, como por ejemplo el Caso en Estudio – LAR Leave
Consolidation, cuyo objetivo es mostrar como se ha aplicado la metodología propuesta
para desarrollar la definición de su alcance, así como de otros proyectos en que el el
aprendizaje has sido muy valioso, debido tanto a los errores como a los éxitos logrados.
La segunda encierra todo el proceso de investigación que se ha llevado a cabo para
fundamentar la metodología propuesta. En algunos casos se ha consultado el criterio de
expertos para dar dirección y comparar puntos de vista con respecto a aspectos
subjetivos de la definición del alcance, sobre todo con respecto al orden de los pasos a
seguir y la definición de requerimientos.
La herramienta básica es la tecnología, la cual permitirá facilitar el levantado de texto
por medio de software como MS Word o Excel (para tablas), presentación de gráficos,
figuras, diagramas y cronogramas, con ayuda de aplicaciones como MS Project, Paint,
Mind Manager, etc.
III.2 Metodología de Aplicación
El desarrollo de esta tesis se ha dividido en tres fases, según las fuentes de
información asociadas a ellas, la primera corresponde a una etapa de investigación, la
segunda se base en describir la propuesta metodológica ejemplificándola con el caso en
estudio, según se muestra en la Figura no. 11 del EDT del proyecto. Finalmente se
presentarán las conclusiones y recomendación con base en los objetivos del proyecto
de graduación y las lecciones aprendidazas a través de su elaboración.
36
Figura No. 11: EDT del Proyecto Final de Graduación
III.3 Metodología de Análisis
El análisis realizado en este proyecto de graduación está basado en la experiencia
adquirida en la administración de proyectos tradicionales de desarrollo de software, en
la comparación de aspectos comunes y diferencias fundamentales que existen entre
ellos y en el estudio de distintas fuentes de información relacionadas con la
administración de proyectos y modelado de negocios.
37
IV Desarrollo
IV.1 Metodología para la definición del Alcance
La metodología que se propone en este documento está destinada a proyectos de
desarrollo de aplicaciones, donde haya que hacer un análisis del negocio inicial.
También podría ser utilizada en proyectos de mejoramiento o ampliaciones de sistemas,
en cuyo caso habría que hacer una investigación del uso del sistema existente, similar
al análisis del negocio. Esta propuesta metodológica tiene algunas técnicas tomadas de
proyectos CMMi, así como de escritos como los de Alec Sharp (2008) y los
Requerimientos SMART de Mike Mannion y Barry Keepence (1995). La Figura No. 12
muestra la relación que existe entre la metodología propuesta y la Gestión del Alcance
expuesta en el PMBOK 2003. Esta metodología se ha aplicado al proyecto LAR Leave
Consolidation, el cual se encuentra en su etapa de exploración y definición del alcance
durante la elaboración de este proyecto de graduación.
Figura No. 12: Metodología para la Gestión del Alcance en relación a PMBOK 2003
38
Como se nota en la figura adjunta, la metodología propuesta involucra un proceso de
retroalimentación que enriquece la definición del alcance a través de los siguientes
procesos:
• Matriz de Requerimientos: Este permite visualizar la posición de cada
requerimiento con respecto a las etapas del proyecto, sobre todo antes de
establecer un compromiso de entrega, lo que ayuda estructurar la
retroalimentación proveniente de otras tareas.
• Roles y Responsabilidades: Identificar los interesados y establecer los poderes
de decisión a través del proyecto permite saber quienes son los responsables de
retroalimentar los requerimientos
Los requerimientos se retroalimentan a través de los siguientes procesos:
• Diseño: Solidifica el alcance al definir la tecnologías a utilizar y la capacidad
técnica del equipo y la relación que existe entre uno y otro requerimiento.
• Plan de Pruebas: Ayuda a visualizar los requerimientos desde otro ángulo por lo
que permite encontrar omisiones u errores que pudiesen haber ocurrido en la
definición del requerimiento.
• EDT: Este esquema ayuda a agrupar los requerimientos en entregables para
luego distribuirlos a través del tiempo, dependiendo del recurso que va a realizar
la tarea y la prioridad asignadas en la Matriz de Requerimientos.
Es muy interesante notar como estos cambios en la Gestión del Alcance en la cuarta
versión del PMBOK se alinean de una manera muy orgánica a la metodología propuesta
en este proyecto de graduación, quedando como se muestra en la Figura No. 13.
Al comparar las Figuras 12 y 13 , se observa que hay más puntos de encuentro
(líneas azules) entre la metodología propuesta en este proyecto de graduación y el
PMBOK 2008, por lo que se evidencia un paralelismo entre las experiencias en
proyectos de software con la actualización del PMBOK. Esto se logra debido a los dos
39
nuevos procesos (en morado) que se han agregado en el PMBOK 2008, los cuales
proporcionan una unidad más lógica entre las partes.
Figura No. 13: Metodología para la Gestión del Alcance en relación a PMBOK 2008
Un detalle que vale rescatar es que aunque el PMBOK 2008 no ofrece ningún
proceso que indique una retroalimentación necesaria a la hora de definir el alcance,
como se enuncia claramente en la metodología propuesta, sí introduce el concepto de
elaboración progresiva durante la Gestión del Alcance, la cual está muy ligada con el
Plan de Gestión del Proyecto, de tal forma que en opinión de la autora de este proyecto
de graduación, un proceso alimenta a otro continuamente, sin que el principio y el fin de
cada proceso deba estar ligado a fechas contundentes.
Esto es quizás lo que más cuesta aprender a “tolerar” durante la elaboración del
alcance, ya que los procesos permiten visualizar una línea de dirección, como lo hace la
cuenca de un río con el agua que contiene y dirige, mas no debe ser una razón de
40
frustración si no se logran cumplir los tiempos estimados. En este punto las
estimaciones dependen muchísimo de la experiencia del director de proyecto o el
analista del sistema y ninguno nace aprendido.
IV.2 EDT de la Metodología Propuesta
La metodología propuesta consta de diez pasos los cuales se describen a
continuación con sus respectivos entregables:
ANTEPROYECTO
1. Investigación y modelado del negocio existente
� Entregables:
� Modelos de flujo de Trabajo del negocio existente
2. Modelado el negocio por crear
� Entregables:
� Modelos de flujo de Trabajo del negocio a crear
3. Negociación de vocabulario
� Entregables:
� Lista de terminologías
EXPLORACION:
4. Estructuración los requerimientos en bloques conceptuales
� Entregables:
� Requerimientos de Alto Nivel
5. Definición de requerimientos (bajo nivel – SMART, Visualización, Excepciones)
� Entregables:
� Requerimientos de Bajo Nivel
6. Exploración del Diseño
� Entregables:
� Modelado de Datos
� Análisis de Impacto
7. Revisión de Requerimientos
� Entregables:
� Roles y Responsabilidades
41
� Matriz de Requerimientos
PLANEACION:
8. Esquema de Distribución de Tareas (EDT)
� Entregables:
� EDT
9. Definición de casos de prueba en base a requerimientos (calidad)
� Entregables:
� Plan de Prueba
10. Manejo de cambios en los requerimientos
� Entregables:
� Sistema de Control de Cambios
IV.3 Definición de Conceptos Importantes
Antes de continuar con los pasos detallados de la metodología propuesta, vale
destacar que existen diversas opiniones sobre lo que implica el concepto de diseñar y la
relación que tiene con la definición del alcance en un proyecto. En el diccionario de la
Real Academia Española (2001), el diseño está definido como: (1) “Traza o delineación
de un edificio o de una figura”, lo cual es fácilmente relacionable con el plano
bidimensional de un proyecto civil. Aunque también menciona la definición (2) “Plan de
proyecto” y (3) “Descripción o bosquejo verbal de algo”, dos conceptos muy amplios que
podrían abarcar tanto la definición del alcance como el total de la etapa de planeación.
Según Michael W. Newell (2005), la definición del alcance corresponde al enunciado
de los requerimientos del proyecto a como son vistos en el momento de ser
mencionados. Al principio esta definición no es muy detallada y se irá construyendo
conforme el proyecto avance.
42
Para que no haya más dudas con respecto a la utilización de estos conceptos en el
desarrollo de esta propuesta metodológica, se parte de la premisa que estos se
entienden a como sigue:
� ALCANCE: Representa el QUE de un proyecto, lo que se desea alcanzar o
construir a través del mismo. La definición del alcance se va construyendo
progresivamente durante la planeación del proyecto.
� DISEÑO: Es la actividad que se realiza para detallar los requerimientos desde
una perspectiva técnica, asociada al área especifica del proyecto. Por ejemplo, si es un
proyecto civil, el diseño se refiere a los planos del inmueble. Para un proyecto de
software, el diseño involucra modelado de datos, así como diagramas de arquitectura,
de flujo de datos, de estados, de secuencias, de clases, entre otros. El diseño no es
una actividad desasociada del alcance, sino que la complementa.
43
IV.4 Anteproyecto
El anteproyecto de la metodología propuesta se puede comparar con el
anteproyecto que se realiza al querer construir una casa o un edificio, en el cual el
arquitecto se sienta en varias sesiones de exploración con el cliente y sus sueños. En
un proyecto civil el arquitecto o ingeniero diseña los planos en paralelo a sus sesiones
de investigación, debido a que los planos bidimensionales son relativamente intuitivos y
en muchos casos, los clientes logran participar de su elaboración. Al realizar proyectos
de desarrollo de software, el diseño se separa de la parte de análisis del negocio o de
los sistemas existentes, debido a que la conceptualización y entendimiento del diseño
de sistemas de computación son mucho más abstractos, por lo que no es posible
comprenderlos intuitivamente sin un bagaje cultural de fondo. Quizá este aspecto tan
sui generis de los proyectos de software cambie con el tiempo, debido a que cada vez
más niños y jóvenes se involucran con los conceptos de computación a muy temprana
edad.
Ahora bien, en este apartado hemos separado el modelado del negocio en dos
fases. La primera es más investigativa ya que consiste en analizar el negocio existente.
Mientras que la segunda es más creativa, ya que su objetivo es ofrecer una posible
solución o propuesto de modelo más íntegra y eficiente para el nuevo sistema.
44
IV.4.1 PASO 1: Investigación y modelado del negocio existente
Este es el primer paso del Anteproyecto, como se
muestra en la Figura No. 14 . En este se debe hacer
una investigación para entender el negocio existente.
Al iniciar el proceso de investigación ninguna de las
personas con las que se habla realmente conoce el
negocio completo, ya que cada empleado ejecuta una
labor específica y limitada por los objetivos de su
puesto. El proceso de modelar un negocio puede llegar
a ser muy desafiante, ya que es como armar un
rompecabezas en el que cada conversación se
convierte en una pieza real o en una falsa, según la
interpretación que se le dé, lo que puede dirigir la
investigación hacia conclusiones acertadas o totalmente
equivocadas y catastróficas para el “nacimiento” del
proyecto.
Figura No. 14: Pasos del
Anteproyecto
LAR Leave Consolidation fue formado en base a una iniciativa para reducir la
cantidad de herramientas soportadas en Latinoamérica, derivada directamente de los
objetivos estratégicos de la organización, por lo que desde el inicio contó con suficiente
respaldo gerencial, el cual asignó recursos y tiempo para elaborar una investigación
exhaustiva del negocio de Recursos Humanos. Este no es el caso más común a la hora
de iniciar proyectos de desarrollo de aplicaciones de software. Sin embargo, cuando
una idea surge en la mente de una persona no tiene ningún compromiso de salir
exitosa, simplemente representa el inicio del proceso de probar el terreno para ver que
pasa, por lo que tiene la ventaja de no estar dentro del foco de atención de los
proyectos ya formados, donde el tiempo y costo son muy controlados. Si la persona que
tiene la idea se esfuerza en sacarla adelante por convicción propia, es posible que
aunque no cuente con el respaldo gerencial, logre salir avanti con tiempo prestado de
otras actividades laborales o personales. Si por el contrario, LAR Leave Consolidation
45
hubiese sido asignado a un analista de sistema o a un director de proyecto que no
creyese en su importancia entonces, aunque hubiese sido apoyado por la gerencia, el
proyecto no hubiese sido formado, ya que en esta etapa lo más importante es asignarle
fe a un posible proyecto por más difícil o imposible que parezca.
En el caso de LAR Leave Consolidation, se analizaron más de doce sistemas ya
existentes, sus ramificaciones, formas de uso y procesos manuales de integración y
resolución de conflictos entre las distintas aplicaciones, para lo que se desarrollaron las
siguientes actividades:
1. Crear una lista de las aplicaciones existentes
2. Planear y ejecutar conversaciones sobre las aplicaciones con recursos humanos
para ver su forma de uso
3. Planear y ejecutar conversaciones con los dueños de las aplicaciones para
revisar las bases de datos y la manera en que fueron construidas.
4. Crear los modelos de flujo de trabajo, explicados en la siguiente Sección IV.4.2 –
Modelando el Negocio por crear, para cada sistema existente.
Al crear la lista inicial se utilizó el sistema oficial de aplicaciones en la organización,
el cual tenía tan solo siete aplicaciones por integrar. Sin embargo, conforma la
investigación siguió su curso, se descubrieron cinco más, entre las cuales habían
sistemas parciales creados para integrar aplicaciones con otras y consolidar sus datos.
También hubo que analizar los procesos de cálculos de planilla, para comprender la
relación que existe entre las herramientas dedicadas al manejo de días especiales y la
planilla en sí de los empleados.
46
Figura No. 15: Flujo de trabajo parcial de LAR Leave Consolidation
Como ya se ha mencionado, el análisis de sistema no es sencillo, y en muchos
casos es difícil reconocer cuales procesos o actividades se deben eliminar. Sin
embargo, una manera sencilla de lograrlo se ilustra con la Figura no. 14 . Este es un
Modelo de Flujo de Trabajo , el cual representa un caso muy común, pero que puede
perderse muy fácilmente al ser incluido dentro de un flujo más amplio y recargado de
actividades. El objetivo del analista de sistemas es tratar de reconocer estos casos. En
esta figura se muestra una visión parcial de uno de los flujos de trabajo desarrollados en
esta etapa. El proceso para desarrollar un flujo de trabajo se describe en la siguiente
sección IV.4.2 del Anteproyecto – Modelando el Negocio por crear. Estas dos
actividades se han extraído de un flujo más complejo, para resaltar su problemática.
Así, conforme se va desarrollando el análisis, hay que poner atención a:
1. Actividades que tienen un tiempo de duración muy largos, las cuales por lo
general representan trabajos manuales que se pueden automatizar en el
sistema. Al transferir datos cuantificables (duración, tamaño, cantidad) dentro
de un modelo visual (flujo de trabajo) se pueden hacer decisiones cualitativas
más fácilmente, ya que a su vez se tiene la relación que existe entre los
distintos procesos.
2. Actividades que tiene un cierto rango de redundancia. Por ejemplo en la
Figura no. 15 se nota que los jefes de empleado ingresan tiquetes en un
47
sistema, del cual se extraen datos manualmente (centro de transacciones)
para luego ingresarlos en otro sistema, a pesar de que la tecnología de
computadoras nos permite automatizar la transferencia de datos de un sistema
a otro.
Este es un caso muy común que se observa cuando un negocio crece, sin que lo
hagan los sistemas que lo automatizan. Las personas crean entonces formas de
integrar estos sistemas manualmente y seguir haciendo su trabajo.
En la sección IV.4.2 se utiliza este mismo ejemplo para ejemplificar como este flujo
puede reducirse y automatizarse.
IV.4.2 PASO 2: Modelado el negocio por crear
Este es el segundo paso del Anteproyecto, como se
muestra en la Figura No. 16 . Una vez que se ha
analizado y comprendido el negocio existente, se
procede a optimizarlo, eliminando los procesos
duplicados y definiendo los roles necesarios para
obtener los objetivos del negocio, de tal forma que se
crea un nuevo modelo.
Existen múltiples modelos para analizar un negocio
y cada uno de ellos ofrece una abstracción limitada de
lo que en realidad se está tratado de representar. En
este documento se mencionaran cuatro, que han sido
escogidas por dos motivos:
Figura No. 16: Pasos del
Anteproyecto
48
1.) Se pueden desarrollar de una forma secuencial en la que el primer modelo
aporta conocimiento al segundo, de tal forma que es posible conceptualizar
un negocio paulatinamente dentro de un proceso enriquecedor.
2.) En la Corporación Intel existen varios departamentos, además de IT, que han
empezado a utilizar estos modelos de una forma secuencial. Esto ha
beneficiado el proceso de investigación al conferirle cierta estructura lógica a
una actividad comúnmente asociado a términos como desorden, búsqueda,
oscuridad, debido a la cantidad de aspectos desconocidos que se tienen al
iniciar una investigación.
Los cuatro modelos de negocio se enlistan a continuación:
• Modelo Organizacional : Este modelo es muy similar a un organigrama,
con la diferencia de que sus componentes se refieren a roles, no a
personas en específico. Este caso se ejemplifica con un modelo parcial
de una Organización de Recursos Humanos en la Figura No. 17 . Este
modelo se ha reducido para no mostrar detalles confidenciales que
pudiese tener el proyecto LAR Leave Consolidation respecto a la
organización de Recursos Humanos de la Corporación Intel.
Figura No. 17: Modelo Organizacional Parcial del Proyecto
49
• Modelo de Interacción del Negocio : Este muestra la interacción que
existe entre los roles definidos el primer modelo organizacional, de esta
forma el analista del sistema puede ir notando y comprendiendo las
relaciones que existen entre los empleados, los clientes, sus proveedores
y la competencia.
Figura No. 18: Modelo de Interacción del Negocio
• Modelo de Descomposición del Proceso: Es muy parecido al primer
modelo organizacional, pero con la diferencia de que sus componentes
son actividades jerarquizadas, similar a un EDT
Figura No. 19: Modelo de Descomposición del Proceso - LAR Leave Consolidation
50
Por lo general los procesos de un negocio se pueden descomponer en:
� Procesos Introductorios o de Planeación, como en este caso es la
Configuración del Sistema.
� Procesos de Producción o Ejecución, los cuales también pueden
involucrar procesos de control o retroalimentación. Generalmente
están muy relacionados con el producto del negocio en si.
� Procesos de Reconciliación o Cierre, los cuales tienen que ver con
reportes, integración y verificación de datos.
• Modelo de Flujo de Trabajo: Este es paralelo al modelo de Interacción
del Negocio, pero utilizando las tareas definidas en el modelo de
descomposición del proceso y ordenado por niveles según lo roles
establecidos en el primer modelo organizacional de la empresa. Este es el
modelo más importante para definir las reglas y excepciones del negocio,
ya que tiene la cantidad de detalle que el Analista de Sistema desee.
Figura No. 20: Modelo de Flujo de Trabajo – LAR Leave Consolidation
51
El flujo de trabajo mostrado en este ejemplo ha sido desarrollado utilizando
ProVision, un producto de Metastorm para modelar arquitecturas de negocios, una de
tantas herramientas en el mercado. Es importante mencionar que la Figura no. 20
muestra el nivel de mayor abstracción de un modelo del flujo de trabajo, pero en el
software cada actividad (rectángulos en azul) se puede detallar aún más al ingresar en
niveles de abstracción más bajos (haciendo clic en la flecha de la base inferior de cada
rectángulo azul).
En la sección IV.4.2 , se muestra un flujo parcial de trabajo con problemas de
desempeño, el cual se ha reproducido en la Figura No. 21. La segunda actividad
representa una labor de parche que un Centro de Transacciones realiza para ingresar
manualmente los datos de un sistema de eventos, en la que los jefes ingresan cambios
sobre los días de trabajo de sus empleados, al sistema oficial de la empresa.
Posiblemente fue agregada dentro del modelo del negocio debido a una falta de
comunicación, análisis, seguridad o simplemente desconocimiento entre los dueños de
cada aplicación.
Figura No. 21: Modelo Parcial según sistema existente – LAR Leave Consolidation
Para corregir este problema y luego de una serie de negociaciones con las distintas
partes, se llegó a la conclusión de que el sistema de eventos intermedio es totalmente
irrelevante, ya que el nuevo sistema propuesta puede estar localizado en la misma
plataforma del sistema oficial de empleados, por lo que podría actualizar la información
52
del empleado automáticamente, sin necesidad de un sistema intermedio. La Figura No.
22 muestra el modelo parcial propuesto para el nuevo sistema.
Figura No. 22: Modelo Parcial según sistema propuesto – LAR Leave Consolidation
IV.4.3 PASO 3: Negociación del vocabulario
Este es el tercer paso del Anteproyecto, como se
muestra en la Figura No. 23 . En este debe negociar la
terminología mas adecuada a la visión y objetivos del
negocio.
El vocabulario del negocio lo constituyen las
palabras que se utilicen para definir la interacción que
existe entre las personas en un Modelo de Interacción
del Negocio. Retomando al ejemplo dado para los dos
primeros modelos de la sección IV.4.2 de este proyecto
de graduación y observando la Figura No. 18, el pasaje,
el tren, el viaje, la ruta forman el campo semántica
correspondiente al vocabulario especial del negocio.
Figura No. 23: Pasos del
Anteproyecto
53
Para negocios nuevos o cuando están desperdigados, es decir, crecieron de manera
desordenada sin interacción visible entre sus partes, es muy posible encontrar que su
vocabulario no sea estándar para todos los departamentos. De tal manera que las
personas a pesar de pertenecer a la misma empresa, no hablan el mismo idioma. Por
ejemplo, en una estación de trenes, la ruta y el viaje puede referirse al mismo concepto
aunque no sea el mismo vocablo por lo que si los empleados de un departamento
utilizan uno y los empleados de otro utilizan el otro, cuando tengan que comunicarse
posiblemente no se entiendan, ya que cada uno pensará que el otro esta hablando de
otra cosa.
Es importante establecer entonces un vocabulario común para que lo integrantes del
proyecto, así como los clientes y sus interesados logren comunicarse eficientemente.
En el caso de LAR Leave Consolidation, hubo que integrar tres listas de vocabularios.
• Lista de días especiales, como vacaciones, incapacidades, guardas, etc.
• Lista de estados, como disponibles, aprobados, rechazados, pagados.
• Lista de usuarios, lo que establece los distintos niveles de permiso al
sistema
La lista de días especiales es un conjunto de vocablos muy propios del negocio
elaborado en este proyecto en específico, ya que el sistema pretende administrar los
días especiales de los empleados en Latinoamérica. Sin embargo, la lista de estados y
de usuarios es un problema genérico en la elaboración de proyectos de software, ya
que es muy común seguir un flujo de negocio por medio de estados y utilizado por
distintos usuarios. Por esta razón, es muy recomendable incluirlos dentro de cualquier
plan de exploración de requerimientos.
Un ejemplo de un flujo de estados se muestra en la Figura No. 23 . Cada línea
muestra el tipo de usuario responsable de mover el producto de un estado a otro. En
algunos casos, esta responsabilidad recae sobre el sistema, lo que se muestra como
“auto ” en al figura.
54
Figura No. 24: Flujo de Estados en el Proyecto LAR Leave Consolidation
Los usuarios de un sistema se pueden describir como se muestra en la siguiente
Tabla No. 2 . En la primera columna se coloca el rol establecido en el Modelo
Organizacional (revisar sección II.3.1 ), en la segunda columna se coloca el vocablo
negociado para establecer los niveles de permiso en el sistema, y la tercera columna
establece las actividades que el rol del sistema tiene derecho a realizar.
Cuadro No. 2 : Roles del Proyecto LAR Leave Consolidation
Rol Organizacional Rol del Sistema Descripción
Empleado EMPLEADO Solo puede solicitar días especiales para si mismo
Jefe, Supervisor o Jefe Delegado
JEFE
Pude solicitar días especiales para sí mismo y cualquiera de sus empleados. A su vez puede aprobar o rechazar los pedidos realizados por sus empleados.
Cualquier representante de Recursos Humanos
RECURSO HUMANO
Puede realizar modificaciones especiales en los pedidos de los empleados.
Pendiente de Aprobación
Aprobado
Borrado Rechazado
Pendiente de Pago
Pagado Atrasado
empleado jefe
jefe
empleado
jefe
auto
Disponible
Expirado
empleado
auto
auto
Recurso Humano
55
IV.5 Exploración
La fase de exploración inicia una vez que se ha comprendido el negocio en
conjunción con los objetivos del proyecto. En este punto ya se puede hacer una
propuesta, establecer una dirección, proponer objetivos y construir el Acta del Proyecto
para formalizar el y obtener la aprobación de la idea o el concepto, tal como se sugiere
en el PMBOK, y se describe de una forma más aplicada en el libro Administración
Profesional de Proyectos de Yamal Chamoun (2002). El Acta del Proyecto de LAR
Leave Consolidation se puede observar en el Anexo B de este proyecto de graduación.
Mientras el director del proyecto formaliza el proyecto, es importante que dos
actividades empiecen a suceder en paralelo:
1. Estructura los requerimientos en bloques conceptuales
2. Identificar las personas que de alguna u otra forma pueden influenciar el
proyecto o sean impactados por el mismo
IV.5.1 PASO 4: Estructuración de los requerimientos en bloques co nceptuales
Este es el primer paso de la etapa de Exploración y
el cuarto de la metodología propuesta, como se muestra
en la Figura No. 25 . Este proceso recibe la información
del ANTEPROYECTO y la estructura en una lista de
entregables para luego detallarla en requerimientos.
En la mayoría de aplicaciones Web, estas áreas
pueden representar páginas o los rubros que componen
el menú del sistemas. Sin embargo, también se pueden
estructurar bloques referentes a interacciones entre
sistemas, trabajos automatizable, cálculos u algoritmos
especiales y reportes.
Figura No. 25: Primeros
pasos de la etapa de
Exploración
56
Lo más importantes es que la forma en que se estructuren estos bloques muestre la
relación natural con el negocio. En el caso de LAR Leave Consolidation, las tareas
correspondientes al mayor nivel de abstracción del flujo de trabajo son:
1. PLAN: Configuración del Sistema
2. PRODUCCION: Administración del Requerimiento
3. DISTRIBUCION: Reconciliación de Datos
Por lo que una forma natural de estructurar los requerimientos en bloques
conceptuales sería:
1. PLAN: Requerimientos Generales y Páginas Administrativas
a. Manejo de Usuarios
b. Flujos de Estado
c. Manejo de Notificaciones
d. Administraciones especiales
2. PRODUCCION: Páginas para administrar el requerimiento
a. Página para pedir y modificar días especiales – accesible a cualquier
empleado
b. Página para aprobar o rechazar días especiales – accesible a los jefes
3. DISTRIBUCION:
a. Reportes y Auditorías
b. Páginas de administración para Recursos Humanos
c. Interacción con otros sistemas
d. Migración de datos de los sistemas existentes
Durante la estructuración de los requerimientos es importante notar que la
negociaciones realizada durante el ANTEPROYECTO para establecer vocabulario
común entre los integrantes del proyecto y de la organización, constituye un elemento
de gran ayuda para iniciar la definición de requerimientos generales, como por ejemplo
el manejo de usuarios; ya que cuando se inicia la definición de los requerimientos de
57
cada página, la visualización de cada uno de sus elementos va a depender del nivel de
acceso que cada usuario tenga. En los bloques conceptuales de requerimientos
tabulada para el caso de LAR Leave Consolidation, se muestra de manera ejemplificada
que las páginas para pedir días especiales puede ser accesible a cualquier empleado,
pero la página para aprobar o rechazar pedidos, solo puede ser accesible a los jefes.
IV.5.2 PASO 5: Definición de Requerimientos
Este es el segundo paso de la etapa de
Exploración y el quinto de la metodología propuesta,
como se muestra en la Figura No. 26 .
Este paso se alinea directamente con la
Declaración del Alcance, enunciada en el PMBOK.
Según Yamal Chamoun, 2002 este trabajo consiste
en “realizar pequeños Charters de cada entregable
final, desglosándolos, describiéndolos, especificando
como deben quedar para ser aceptados por el
Cliente.”
Figura No. 26: Primeros pasos
de la etapa de Exploración
Existen diversos escritos muy bien justificados de cómo deben escribirse los
requerimientos de un proyecto de software, entre ellos se encuentran:
• El ensayo sobre Requerimientos SMART (Specific, Measurable, Atainable,
Realisable and Time bounded), escrito en 1995 por Mike Mannion y Barry
Keepence de la Universidad Napier en Inglaterra.
58
• El libro Software Requirements , publicado por Microsoft Press, muestra de una
forma muy amena como deben ser definidos y manejados los requerimientos en
un proyecto de desarrollo de software.
• La Metodología de administración de requerimientos par a proyectos de
software escrita por Marco Chacón y Henry Víquez (2003), como requisito
parcial para optar por la Maestría de Administración de Proyectos en la
Universidad para la Cooperación Internacional de Costa Rica.
Cada uno de estos documentos establece una perspectiva propia de cómo abordar
la definición de requerimientos, sin embargo, los tres coinciden en que estos deben ser:
• Nombrados: Poner un nombre o una etiqueta (label) que puede ser manejado
claramente tanto por el cliente, los interesados y el equipo del proyecto ayuda a
mejorar la comunicación durante la definición y luego el manejo de
requerimientos. Esto se logra con mayor facilidad al agrupar los requerimientos
en bloques conceptuales como se explica en la sección anterior de este proyecto
de graduación.
• Visuales: Al definir un requerimiento es indispensable hacerlo visualmente, ya
que todas las personas imaginan y sueñan de muy diversas maneras. Esto se
puede lograr por medio de figuras y esquemas en papel o por computadora,
como los prototipos, los cuales pueden inclusive reducir riesgos, ya que
minimizan los malentendidos en la comunicación no verbal.
• SMART: Acrónimo por sus siglas en inglés, para definir las características mas
deseables en los requerimientos: específicos, medibles, logrables, producibles y
estimables en tiempo.
Para ejemplificar la definición de requerimientos, se utiliza la primera página
desarrollada como prototipo del proyecto LAR Leave Consolidation. Esta página
representa el portal de la aplicación a construir, es lo primero que el usuario va a ver
59
cuando ingrese al sistema a pedir una vacación, incapacidad u horas extra, por lo que
su negociación radica en establecer el tema y vocabulario del resto de la aplicación.
El equipo del proyecto, y más específicamente el diseñador de páginas establece el
tamaño, las letras, la escala de colores según los estándares de la empresa y acomoda
las distintas componentes de la página aprovechando su espacio de la mejor manera
posible. La estructuración de las páginas ocurre durante las primeras etapas del diseño
de la aplicación, sin embargo, es importante ofrecer una propuesta visual durante la
definición de requerimientos, ya que esto no solo mejora el entendimiento del
requerimiento por los distintos jugadores, sino que también permite identificar cabos
sueltos, como reglas muy especificas, excepciones y/o generalizaciones en casos de
proyectos de consolidación como el presente caso de estudio.
La Figura No. 27 muestra la propuesta inicial que se realizó sobre la página de
acceso al sistema HOME realizada para el proyecto LAR Leave Consolidation. En ella
se definieron aspectos como:
• Localización del menú: En este caso se eligió un menú horizontal ya que se
ajusta de una manera más orgánica al diseño de la propuesta y permite mayor
bienes raíces para el resto de los componentes de la página.
• Componentes del menú: En este punto hubo varias discusiones con el cliente,
ya que al consolidar las aplicaciones existentes, hubo que elegir un nombre lo
suficientemente general para establecer el pedido de días especiales, sin crear
un vocablo desconocido al negocio. De esta forma se eligió la palabra “Time”
como uno de los componentes principales del menú.
• Numero de clics: El proyecto analizado es un esfuerzo de consolidación para
una serie de aplicaciones existentes, por lo que debe generalizar terminología,
así como agregar opciones en las diferentes páginas. Sin embargo, el cliente ha
especificado como una de sus expectativas, que la cantidad de clics que los
usuarios deban hacer sea la minima en relación con los sistemas existentes. Este
60
no es un requerimiento muy común al desarrollar aplicaciones web, ya que no
solo minimiza los problemas de desempeño de la aplicación, sino que también
reduce los tiempos de espera del usuario, uno de los aspectos que genera más
disgustos en los usuarios de Internet.
• Estructuración de la página: Debido a que el objetivo del proyecto LAR Leave
Consolidation es sustituir al menos 10 sistemas, existen muchas personas que
de alguna u otra manera están o han estado relacionados con las aplicaciones
existentes, y desean que su opinión sea tomada en cuenta con respecto a la
estructuración de las páginas del nuevo sistema. Es por ello, que este punto ha
recibido muchísimas recomendaciones, algunas divergentes entre si. Sin
embargo, se ha convertido en uno de los puntos que ha permitido enriquecer el
entendimiento general de lo que se percibe sobre esta aplicación, debido a que la
persona que finalmente ha diseñado las páginas es un agente externo al bagaje
de experiencias que hay detrás de los involucrados, y ha logrado amalgamar
estas opiniones en una propuesta visualmente agradable a la mayoría de las
opiniones.
Figura No. 27: Propuesta para la página inicial - LAR Leave Consolidation
61
Esta página también tiene aspectos no visuales que deben ser definidos dentro de la
documentación de los requerimientos, como por ejemplo:
• Manejo de Usuarios: Al definir los requerimientos de una página, es
indispensable establecer que roles del sistema tendrán acceso a esta página, en
el campo semántica de la Ingeniería de Sistemas, esto se conoce como la
información de login . El login puede tener diversas variables, como por ejemplo:
o Roles del sistema: Ejemplificados para LAR Leave Consolidation durante
la sección IV.4.3 de este proyecto de graduación.
o Localización: Hoy en día, la mayoría de las aplicaciones web pueden ser
desarrolladas para mercados globales, debido a la facilidad que ofrece el
Internet. Es por esta razón, que a la hora de definir los roles de una
aplicaciones es necesario tomar en cuenta de que países provienen y
cuales es su idioma oficial.
• Reglas del Negocio: Este rubro de la definición de los requerimientos es muy
importante para luego diseñar el flujo de datos del sistema por desarrollar. Es en
este punto donde se establece una estrecha relación entre negocio y datos, lo
que corresponde al corazón de la aplicación y lo que contiene los conceptos más
abstractos de la definición de un sistema. En este punto es donde se debe utilizar
el concepto de SMART, ya que las reglas deben ser clara, concisas, específicas,
medibles, producibles y estimables en tiempo, para lograr el mejor balance de lo
que se puede y se debe hacer en el sistema.
o Regla: Una regla de negocio, pude ser por ejemplo: “Los empleados
puede pedir vacaciones en cualquier día laboral.” En la sección II.3.2 se
describe como esta regla se asocia a los datos del sistema.
o Excepciones a la Regla: Las excepciones marcan la flexibilidad del
sistema, ya que por ejemplo para la primera regla (enunciada sin
excepciones), se puede diseñar un sistema de forma:
62
� RESTRINGIDA: El empleado SOLO puede pedir días completos,
sin tomar en cuenta días parciales, lo que en un futuro podría
representar una limitante del sistema.
� ERRONEA: El diseño del sistema puede no haber tomado en
cuenta que durante los días feriados no se labora y ser permisivo
para el pedido de vacaciones en estos días, lo que podría
“ensuciar” los datos.
Lo mejor seria redefinir la regla enunciada con sus debidas excepciones:
“Los empleados puede pedir vacaciones de días parciales en cualquier día
laboral, que no sea feriado.” He aquí la importancia de estas reglas.
• Manejo de Eventos : Los eventos son situaciones que ocurren cuando se
presentan condiciones excepcionales o limites establecidas en la reglas de
negocio y que deban advertir al usuario de algún comportamiento indebido o un
error en el sistema. Esto quizá no sea muy evidente para el cliente o los
interesados, y no haya que negociarlo muy extensamente con los mismos. Sin
embargo, es un aspecto que el analista del sistema o el director del proyecto
tienen que tener presente a la hora de definir los requerimientos, debido a que
muestran excepciones que pueden dificultar un requerimiento y causar cambios
mas adelante. En este caso hay que definir aspectos de:
o Validación de Datos: Esto corresponde al tipo entradas que el usuario
tenga que ejecutar en el sistema. Por ejemplo, si es un comentario de
texto, se deben establecer los caracteres permisibles; o si es un dato
numérico, los valores mínimo y máximo autorizados en el sistema.
o Mensajes de Error o de Advertencia: En algunos casos el cliente
requiere que cierto tipo de mensajes se desplieguen en cierta
circunstancia. Aquí se especifican las circunstancias y sus excepciones.
o Notificaciones por correo electrónico: Durante ciertos eventos, es
necesario enviar mensajes electrónicos para notificar el empleado. En
63
tales casos se debe definir aspectos como la frecuencia de notificación y
los usuarios que deben ser notificados.
IV.5.3 PASO 6: Exploración del Diseño
El diseño de la aplicación de software permite
retroalimentar la definición de requerimientos, por
lo que aunque esta etapa se establezca
tradicionalmente en la fase de Planeación, esta
propuesta metodológica recomienda realizar al
menos la exploración y análisis del diseño durante
la fase de Exploración, ya que esto permite que los
desarrolladores e integrantes del equipo que vayan
a implementar y validar el código tengan la
oportunidad de analizar y comprender los
requerimientos antes de que estos sean
aprobados, lo que reduce el riesgo de introducción
de cambios debido a falta de comunicación o
sincronía entre los participantes del equipo.
Figura No. 28: Exploración del
Diseño
Este por ello que este paso se ha colocado entre las etapas de EXPLORACION y
PLANEACION, como se muestra en la Figura No. 28 .
Vale resaltar que teóricamente, si la definición de requerimientos es clara, concisas,
específicas, medibles, producibles y estimables en tiempo desde el punto de vista de
todos los integrantes del equipo, se reduce la posibilidad de que el diseño impacte la
implementación de estos requerimientos, ya que la tecnología de desarrollo de software
existente es lo suficientemente flexible como para cumplir con las expectativas posible
de una aplicación web. Sin embargo, este es un caso IDEAL, ya que por lo general en
proyectos tradicionales, los programadores y validadotes entran al equipo al final de la
etapa de exploración, lo que genera una actividad de re-exploración y análisis de
64
requerimientos por su parte, y en muchos casos impacta el tiempo y costo estimados
para el diseño.
El diseño que permiten comprender los requerimientos y sus implicaciones de una
manera eficiente corresponden a las actividades que tengan que ver modelado,
transformación, manipulación y trasmisión de datos, desglosadas en los siguientes
rubros:
• Modelado de Datos
El modelado de datos del proyecto LAR Leave Consolidation se ejemplifica
siguiendo la Regla de Negocio establecida en el capitulo anterior, y siguiendo las
técnicas introducidas en la sección II.3.2 – Modelado de Datos del Marco Teórico.
La regla de negocio es:
“Los empleados pueden pedir vacaciones de días parciales en cualquier día
laboral, que no sea feriado.”
.
Para ello se elaboraron cuatro modelos de datos, el contextual, conceptual,
lógico y físico (la base de datos). En este proyecto de graduación se va a
ejemplificar la regla por medio de los tres primero modelos.
o Modelo Contextual: Este es un modelo muy comprensible desde el punto
de vista humano, ya que permite visualizar el contexto de cada elemento
en el sistema. En este caso lo que el grafico de la Figura No. 29
representa es que la gente puede pedir un día especial a través de un
proceso específico, que puede ser por país por tipo de pedido.
65
Figura No. 29: Modelo Contextual del proyecto LAR Leave Consolidation
o Modelo Conceptual: Este es un modelo bastante sencillo de extrapolar del
modelo contextual ya que se basa en ir definiendo entidades del negocio
para cada área contextual. En este caso se han reconocido seis
entidades, tres principales como son: empleado, día especial y pedido,
una asociativa como lo es el inventario de días y dos últimas que tipifican
o caracterizan como lo es la vacación y el feriado. Este modelo se ha
definido siguiendo la notación de pata de gallo, no la notación ERM, como
se hizo en el Marco Teórico.
Figura No. 30: Modelo Conceptual del proyecto LAR Leave Consolidation
Lo que se desea resaltar de este ejemplo es el procesamiento mental que
debe ocurrir en los desarrolladores, con la ayuda del analista de datos
para comprender lo que el cliente desea en los términos abstractos
propios del desarrollo de software. Por ejemplo en la Figura No. 30 se ha
definido una entidad denominada Inventario de Días, la cual puede o no
estar, según la Regla de Negocio definida para este ejemplo, ya que no se
dice explícitamente que se requiera un inventario de días. Sin embargo,
Gente Días Especiales
Proceso de Pedidos
66
analizando otras reglas de negocio y aclarando conceptos con el cliente,
por medio de una retroalimentación, es posible que se llegue a la
conclusión de que para cumplir con otros requerimientos o para flexibilizar
el seguimiento de días haya que incluir una entidad de este tipo.
Otro aspecto que vale mencionar es que las entidades del modelo
conceptual no necesariamente son las mismas del modelo lógico, ya que
en el modelo lógico se detallan todas las reglas del negocio, mientras que
en el conceptual todavía se visualizan desde una perspectiva de concepto.
Este es como un modelo transitorio entre la perspectiva humana y la
perspectiva de mecánica, mientras que el lógico es un modelo transitorio
entre el conceptual y el físico.
Figura No. 31: Modelo Lógico del proyecto LAR Leave Consolidation
o Modelo Lógico: Este modelo lleva por lo menos cuatro o cinco veces más
trabajo que el modelo conceptual, ya que existen una relación directa
entre las entidades de este modelo y las tablas de la base de datos. Para
el ejemplo dado en este documento, no hay mucha diferencia entre los
modelos conceptual y lógico, ya que ambos describen solo una Regla de
Negocio por lo que la relación es uno a uno, como se muestra en la
Figura No. 31
67
• Interacción con otros sistemas:
Lo más importante en el diseño de interacción de sistemas con respecto a la
definición de requerimientos es:
o Identificar la dirección de la transferencia: Lo primero que hay que definir
es la dirección en la que van a transferir los datos. Esto debe ser parte de
los requerimientos para que no hayan mal entendidos de autoridad con
respecto a los dueños del otro sistema.
o Identificar Datos a Transferir: Reconocer los datos que se van a transferir
de un sistema a otro.
Figura No. 32: Modelo de Interacción de Sistemas
o Comprender Transformación: Antes de transferir un datos de un sistema a
otro es importante comprender el tipo y la información que contiene para
decidir en que se puede transformar. En el ejemplo de la Figura No. 32 ,
se necesita convertir el dato a1 a a2 antes de ser enviado del sistema Y al
sistema Z.
o Análisis de Impacto: Analizar el impacto de la transferencia de datos sobre
el manejo de datos en cada sistema. Si el Análisis de Impacto no se
realiza antes de aprobar los requerimientos esto puede dar al traste con
las expectativas que se tengan, ya que existen muchas variables que
pueden impedir una comunicación entre sistemas, incluyendo de tiempo y
costo.
Sistema Y: Identificar Dato a1
Sistema Z: Identificar Dato correspondiente a2 Modificar a2 puede impactar b2
Convertir Dato a1 ���� a2
68
• Cálculos algorítmicos o de reporte:
El diseño de algoritmos de cálculo es similar al diseño de interacción de sistemas ya
que requiere de un análisis de entradas y salidas. Sin embargo es mas seguro, si se
cuenta con recursos dedicados al proyecto y con la potestad del sistema, ya que se
tiene control sobre su información.
Figura No. 33: Modelo de Cálculo Algorítmico
Aquí lo complejo es comprender el cálculo algorítmico que hay que realizar, y la
mejor manera de hacerlo si impactar el desempeño de la máquina. Existen métodos
de análisis y diseño dependiendo de la tecnología de desarrollo que se elija. Sin
embargo, este tema se sale del alcance de este proyecto de graduación, ya que no
tiene un impacto directo sobre la definición de requerimientos.
Entradas Identificar Datos: a, b, c
Salidas Identificar Resultado(s): X, Y, Z
Calculo Algorítmico Comprender formula(s)
69
IV.5.4 PASO 7: Revisión de Requerimientos
Este paso es el que más valor agrega a la metodología propuesta, ya que funciona
como catalizador o habilitador para crear un ambiente de retroalimentación entre los
distintos procesos que interfieren en la Gestión del Alcance. Esto se logra a través de
dos entregables como se muestra en la Figura No. 34
• Matriz de Requerimientos
• Roles y Responsabilidades
Los cuales se describen a continuación.
Figura No. 34: Revisión de Requerimientos
70
IV.5.4.1 Definición de Roles y Responsabilidades
Para poder revisar y aprobar los requerimientos establecidos en un sistema es
necesario establecer las personas que de alguna u otra manera pueden inferir en las
decisiones que se tomen del proyecto, así como poder visualizar de una forma global y
manejable el alcance del proyecto.
Existen varias técnicas para construir un modelo de gobernabilidad o de toma de
decisiones, para minimizar los problemas de índole política durante la administración de
un proyecto. El PMBOK 2008 ha agregado un nuevo proceso en el Área de la
Comunicación para identificar a los interesados durante las primeras etapas de un
proyecto, y lograr los siguientes objetivos:
• Definir claramente los elementos de trabajo en proyectos grandes con interfaces
de diversa índole
• Poder realizar decisiones a tiempo, si es posible durante la exploración del
proyecto, para minimizar la cantidad de cambios que puedan ocurrir en etapas
mas tardías debido a una falta de comunicación.
• Abrir las líneas de comunicación
• Llegar a un acuerdo con respecto a los roles y responsabilidades de los
diferentes interesados, sobre todo cuando existen o pudiesen existir conflictos de
interés.
Existen diversas técnicas para identificar los roles y responsabilidades de los
integrantes de un proyecto. En este momento, la técnica más utilizada en proyecto de
desarrollo de software en el departamento de IT de la Corporación Intel es Calipso, la
cual distribuye los roles de las persona a través de los rubros enunciados en la primera
celda de la siguiente tabla:
71
Cuadro No. 3 : Distribución de Roles según Calipso
Nombre del Proyecto Roles y Responsabilidades C = Coopera A = Aprueba L = (List) Enlistar otros roles y responsabilidades, ej. R = Revisa I = Informa P = Participa S = Sugiere O = (Own) Responsable P
atro
cina
dor
Ana
lista
Fin
anci
ero
Inte
resa
do
Dire
ctor
del
Pro
gram
a
Dire
ctor
del
Pro
yect
o
Dire
ctor
del
Pro
duct
o
Ana
lista
del
Sis
tem
a
Ana
lista
de
Dat
os
Des
arro
llado
r
Líde
r de
Val
idac
ión
Líde
r de
Ent
rena
mie
nto
Líde
r de
Sop
orte
Líde
r de
Impl
emen
taci
ón
Adm
inis
trad
or d
e la
C
onfig
urac
ión
Líde
r de
la T
rans
ició
n de
l C
ambi
o de
Neg
ocio
Proyecto Tradicional
Acta del Proyecto R O R R R R R R
Plan del Proyecto A O R R R R R R R R
Requerimientos A A R O R R
Diseño A O R R
Plan de Validación A R R O
Plan de Entrenamiento R R O
Líneas Base A O Ambientes de Desarrollo & Test O R
Modelo de Datos R O R
Desarrollo R O R R
Ejecución de Pruebas R R O Documentación y Comunicación R R R R O
Entrenamiento A O R R Documentación Técnica para el Usuario R R R R O Día Uno de Pruebas del Usuario R R R R O Implementación Técnica del Producto R R O
Entrega del Producto R O
Estabilización del Producto R R R R O
Revisión del Proyecto C C O C C C C C C C C
Un ejemplo aplicado se muestra en la tabla adjunta. Esta técnica se utiliza mucho
para asignar roles a los integrantes del equipo del proyecto, aunque carece de una
definición estándar de responsabilidades, por lo que cada equipo de proyecto debe
definir un set de responsabilidades antes de definir los roles que se utilizarán, es en si
una técnica muy flexible. Funciona bien si el equipo se conoce bien, y cada uno
comprender el la responsabilidad que le corresponde al recibir un rol en especifico.
En casos, en que el equipo no se conozca bien y haya que tomar decisiones con
respecto a los roles y responsabilidades per se, esto puede convertirse en una arma de
72
dobla filo, ya que es posible que no todos estén de acuerdo con la decisión de roles y
responsabilidades que tome una persona del bando “opuesto”, o que se subestime la
importancia de tomar una decisión sobre los lista de roles y responsabilidades desde
una perspectiva táctica, al calor del momento o debido a la cantidad de actividades de
exploración y planeación. Es por ello, que se ha ideado una técnica que establece las
reglas del juego de una forma estratégica, conocida como RAPID, la cual tiene un set
de roles y responsabilidades muy definidos, como se muestra en la siguiente figura:
Figura No. 35: Roles y Responsabilidades según RAPID
La conceptualización de esta técnica radica en el rol de decisión, sin que
necesariamente sea la persona que ejecuta el trabajo. Esto propone la visualización de
la responsabilidad desde la perspectiva de la persona que podría sobrellevar la culpa,
como líder, lo que libera la carga del contribuyente individual, quien es el que realmente
ejecuta la actividad.
73
El proyecto LAR Leave Consolidation ha utilizado la técnica de RAPID para definir
los roles y responsabilidades de las diferentes personas involucradas como se muestra
en la siguiente tabla:
Cuadro No. 4 : Modelo RAPID para el proyecto LAR Leave Consolidation
RAPID
Com
ité d
e R
evis
ión
G
eren
cial
(M
RC
)
Dire
ctor
de
la
Líne
a de
Pro
duct
o
Jefe
de
Rec
urso
s H
uman
os
Arq
uite
cto
Dire
ctor
del
Pro
yect
o
Ana
lista
del
Sis
tem
a
Ana
lista
del
Neg
ocio
Equ
ipo
del P
roye
cto
D
istin
tos
Rep
rese
ntan
tes
de
Rec
urso
s H
uman
os
Jefe
de
Pla
nilla
de
R
ecur
sos
Hum
anos
Lega
l
Fin
anza
s
Com
unic
acio
nes
Con
trol
es
Cen
tro
de S
opor
te
Esc
alac
ión
PRE-Exploración: Aprobación del Concepto
D R I A A
Exploración: Decisión de Valor D R P P I I A A
Aprobación de los Requerimientos
D I P P I R
Planning: Decisión de Compromiso
D R I I I I A
Aprobación del Plan D R I I I I
Aprobación del Diseño D R P,I
Aprobación del Plan de Pruebas
I D R P I I
Aprobación de la Línea Base D,P I I R
Aprobación del Plan de Riesgo I I R P P I D I D
Plan de Comunicación I D R
Desarrollo: Decisión de GOnGO D R P I A
Revisión del Código D R I P
Revisión de Resultados de Prueba
D P R I
Ejecución de Pruebas de Acepción de Usuario
D I P R P
Aprobación del Plan de Migración
D R I I I
Training Plan D I I I I R
Revisar y Ejecutar Comunicación
I R I D
Modelo de Soporte de Usuario R I D
Modelo de Soporte Técnico D R I P I
Entrega del Producto: Decisión de Cierre
D R I A
74
IV.5.4.2 Administración del Requerimiento - Matriz de Requerimientos
Una vez que se han definido los requerimientos, estos se pueden ir tabulando en la
Matriz de Requerimientos, como se muestra en la Tabla No. 5. Esta tabla se ha llenado
para ejemplificar como se podría ir completando cada etapa. Sin embargo, al momento
de escribir este proyecto de graduación, el proyecto LAR Leave Consolidation se
encuentra en la etapa de exploración, por lo que las únicas columnas que en realidad
están llenas son las de Requerimiento y Prioridad. Las columnas de Arquitectura y
Diseño se llenan durante la etapa de PLANIFICACIÓN, y la de Implementación y
Calidad en la etapa de DESARROLLO.
Cuadro No. 5 : Matriz de Requerimientos del proyecto LAR Leave Consolidation
Nombre del Proyecto: LAR Leave Consolidation No. 123
Director del Proyecto: Georgina Saborio Dobles
Ultima Revisión: Abril 10, 2009
Requerimiento Prioridad Arquitectura Diseño Implementación Calidad
1. PLAN: Requerimientos Generales y Páginas Administrativas
1.1. Manejo de Usuarios 3 Arch 2.4 Module B Class Y, Z TC 1.1 1.2. Flujos de Estado 1 Module 2.5 Module C Class W TC 1.2 1.3. Manejo de Notificaciones
1 Module 2.6 Module B Procedure A TC 1.3
1.4. Administraciones especiales
3 Module 2.6 Module B Procedure B TC 1.4
2. PRODUCCION: Páginas para administrar el requerimiento
2.1. Página para pedir y modificar días especiales – accesible a cualquier empleado
1
Arch 2.3 Module A Class X TC 2.1 2.2. Página para aprobar o rechazar días especiales – accesible a los jefes
1
Module 2.10 Module B password.html TC 2.2 3. DISTRIBUCION: 3.1. Reportes y Auditorías 2 Module 2.12 Module B logo.gif TC 3.1 3.2. Páginas de administración para Recursos Humanos
1
Arch 2.3 Module A Class X TC 3.2 3.3. Interacción con otros sistemas
2 Module 2.7 Module C Function B TC 3.3
3.4. Migración de datos de los sistemas existentes
1 Module 2.11 Module A lookup.DLL TC 3.4
75
Las columnas de Arquitectura, Diseño, Implementación y Calidad se pueden
modificar al gusto, es decir, el director del proyecto o el analista del sistema podría
agregar o quitar columnas dependiendo de su propio estilo de administración de
requerimientos, lo importante de esta plantilla es tener la capacidad de poder planear
una forma de seguimiento sobre los requerimientos que se van a implementar. Este es
también el primer paso para empezar a construir el EDT del proyecto.
La columna de “Prioridad” permite agrupar los requerimientos dependiendo de un
valor de importancia que puede venir de diversas fuentes, como por ejemplo:
• el punto de vista del cliente
o urgencia o necesidad de negocio
o tamaño del requerimiento
• etapas independientes durante el desarrollo de la aplicación
o en cascada
o para aplicaciones AGILE
76
IV.6 Planeación
Una vez que se comprenden quienes son los jugadores y su papel en el proyecto, se
han revisado y aprobado los requerimientos se inicia la etapa de planeación, la cual
combina la creatividad del diseño, con la mecánica de los procesos que la caracterizan,
como la creación del EDT y la rutinaria labor del crear y si es posible automatizar los
casos de prueba.
IV.6.1 PASO 8: Construcción del Esquema de Distribución de Tareas (EDT)
Este es el primer paso “oficial”
de la etapa de PLANEACION, como
se muestra en la Figura No. 36 .
El EDT se puede iniciar con la
estructuración de los requerimientos
en bloques conceptuales, como se
explica en la sección IV.5.1 .
Figura No. 36: EDT
En el proyecto LAR Leave Consolidation, el EDT se basa a su vez en el ciclo de vida
de los proyectos tradicionales mencionados en el Marco Referencial de este
documento.
En el momento de escribir este proyecto de graduación, el EDT de LAR Leave
Consolidation ya forma parte del calendario inicial del proyecto, su desglose parcial de
tareas para las etapas de pre-exploración, exploración y planeación se muestra en la
Figura adjunta No. 37.
77
Figura No. 37: EDT del proyecto LAR Leave Consolidation
78
IV.6.2 PASO 9: Plan de pruebas
Este es el segundo paso de la
etapa de PLANEACION, y
retroalimenta la revisión de
requerimientos a través de la Matriz
de Requerimientos y su EDT
elaborados como premisa para
iniciar el Plan de Pruebas, según se
muestra en la Figura No. 38 .
Figura No. 38: Plan de Pruebas
Existen diversos tipos de pruebas que validan la calidad de un sistema. Esta sección
se enfoca en el plan de pruebas que mayor incidencia tiene sobre el manejo de
requerimientos, por lo que no se abordan pruebas más globales como de Integración de
Sistemas o Desempeño de la Aplicación.
El plan de pruebas se inicia una vez que se tengan claros y ojala estén aprobados
los requerimientos del sistema. Según la propuesta metodológica de este proyecto de
graduación, la planificación de pruebas en una aplicación web consta de las siguientes
etapas:
• Definición de Matriz de Requerimientos: En la sección IV.5.3.2 se ha
explicado como definir esta matriz. En este apartado se sigue el ejemplo del
requerimiento definido en base a una regla de negocio: “Los empleados pueden
pedir vacaciones de días parciales en cualquier día laboral, que no sea feriado.”
• Definición de pruebas para cada requerimiento: Cada requerimiento que se le
haya asignado una identidad de seguimiento debe tener por lo menos uno de los
siguientes tipos de prueba:
o Funcionalidad: Esta prueba verificar que el requerimiento se cumpla. En
algunos casos es necesario hacer una serie de pasos de configuración o
79
de definición del caso de prueba para tener los datos correctos que
puedan comprobar un requerimiento. Por ejemplo para el requerimiento
dado en base a una reglar de negocio “Los empleados pueden pedir
vacaciones de días parciales en cualquier día laboral, que no sea feriado”,
es importante buscar un mes que tenga días feriados, antes de ingresar el
pedido de vacación para un empleado.
o Errores: En algunos casos el sistema debe verificar el ingreso de datos
correctos. Por ejemplo si el sistema permite el ingreso de fechas como
una entrada de texto, entonce debe verificar que el usuario no ingrese
datos como por ejemplo: 13/13/1000, ya que el año solo tiene 12 meses.
o Límites: Este tipo de pruebas pretende corroborar que los casos límite de
un requerimiento no causen problemas al sistema, o funcionen como lo
indica el requerimiento. Por ejemplo, en el caso de las fechas 13/13/1000
como entrada de texto, muy posiblemente el año 1000 sea irrelevante para
el sistema, por lo que debe existir un límite de años accesible al sistema.
o Niveles de permiso: Existen requerimientos que indican el nivel de acceso
de los usuarios tienen para realizar cierta funciones en un sistema. Por lo
que se deben crear pruebas básicas de acceso, repetidas para cada nivel
de permiso definido.
80
IV.6.3 PASO 10: Manejo de cambios en los requerimientos El último PASO de esta
metodología corresponde al manejo
de cambios en los requerimientos,
el cual permite una buena
administración del proyecto a través
de la etapa más larga del mismo, la
EJECUCION o DESARROLLO del
sistema, por lo que según se
muestra en la Figura No. 39 , se ha
colocado saliendo de la etapa de
PLANEACION.
Figura No. 39: Manejo cambios en los
Requerimientos
Los proyectos tradicionales tienen etapas muy bien definidas, por lo que por
ejemplo, para que empiece el diseño y la implementación del sistema es necesario
haber aprobado los requerimientos y tener un documento oficial con las
especificaciones a desarrollar, es necesario definir un Sistema de Control de Cambios
(SCC). Según Yamal Chamoun, 2002 estos cambios pueden ocurrir por cuatro razones:
• Solicitud del Cliente: Por cambios en objetivos propios de su organización
• Errores u omisiones: A la hora de recolectar requerimientos y analizar el
negocio.
• Condiciones Inesperadas: Cambios desarrollados en el ambiente externo del
proyecto, como la economía, el mercado, la industria, la tecnología.
• Oportunidades de Ahorro: Como efecto de otro cambio
Estos cambios pueden causar un efecto negativo o positivo al proyecto,
dependiendo de cómo se manejen, por lo que es importante estar preparados. Para
ellos es necesario definir tres puntos en el Sistema de Control de Cambios.
81
IV.6.3.1 Roles y Responsabilidades del SCC
Al igual que se hace con los involucrados del proyecto es necesario establecer el
papel que cada integrante del equipo juega en el Sistema de Control de Cambios. Para
le proyecto LAR Leave Consolidation, estos se establecieron de la siguiente manera:
Cuadro No. 6 : Roles y Responsabilidades del SCC en el proyecto ejemplificado
Rol Responsabilidad
Representante de
Recursos Humanos
- Enviar requerimiento de cambio
- Atender la reunión del SCC y presentar el cambio requerido
- Comunicar decisiones al departamento que representa
Analista del Impacto - Analizar el impacto del cambio en el sistema y el negocio
- Recomendar para decisiones rápidas
Equipo Técnico - Hacer un análisis de impacto en la aplicación
- Proveer estimaciones de tiempo y costo y su impacto en el
calendario
- Recomendar el diseño
Administrador de la
Configuración
- Facilitar el proceso del Sistema de Control de Cambios y sus
reuniones
Aprobador de la
decisión
- Decidir que requerimientos se aprueban a cambiar el calendario y
costo del proyecto según la propuesta del equipo técnico. Por lo
general es el cliente.
Aprobador de
decisiones rápidas
- Por lo general el Director del Proyecto
82
IV.6.3.2 Flujo del Proceso del Sistema de Control d e Cambios
Una vez que se han definido los roles, es importante el papel que cada uno juego y
como se relacionan las labores entre si. Para ello hay que definir un flujo que describe el
proceso del Sistema de Control de Cambios. En el proyecto LAR Leave Consolidation
este se definió como se muestra en la Figura No. 40
Figura No. 40: Flujo del Proceso del Sistema de Control de Cambios
83
IV.6.3.3 Seguimiento de cambios en los requerimient os
En el proyecto LAR Leave Consolidation este se estableció un sistema por medio del
repositorio para permitir el acceso de cambios a requerimientos en línea, lo cual facilita
el seguimiento y la comunicación entre los participantes del SCC. La Figura No. 41
muestra la página de entra de datos al sistema. Lo mas importante es que haya un
espacio para la descripción del requerimiento, su prioridad, titulo, estado y una razón del
porque cree el cliente que ocurrió este cambio.
Figura No. 41: Sistema de seguimiento de cambios en el proyecto ejemplificado
84
V Conclusiones
• Existen diversas técnicas para definir y manejar requerimientos en proyectos de
desarrollo de software. Sin embargo, la gran mayoría no toma en cuenta los
beneficios que la labor de diseño puede aportar durante la definición detallado
del alcance, como dos actividades que se complementan entre sí de una forma
orgánica, lo cual se propone con este proyecto de graduación. En los proyectos
en cascada por ejemplo, se tiene la noción de que el alcance debe orientar y
definir el diseño, como dos etapas bien diferenciadas, con la desventaja de que
por lo general hay una gran cantidad de cambios que deben ser manejados con
procedimientos rigurosos, que involucran variables políticas y burocráticas.
Mientras que en los proyectos AGILE, el diseño se minimiza al punto de que en
muchas ocasiones es obviado, por lo que solo se puede abarcar proyectos cuya
primera etapa se pueda concluir en lapsos de dos a cuatro semanas, es decir,
proyectos pequeños o de soporte.
• El cambio analizado entre el PMBOK 2003 (versión 3) y el 2008 (versión 4) es un
aliciente para la propuesta de este proyecto de graduación, ya que aunque el
PMBOK 2008 no ofrece ningún proceso que indique una retroalimentación
necesaria a la hora de definir el alcance, como se enuncia claramente en la
metodología propuesta, sí introduce el concepto de elaboración progresiva
durante la Gestión del Alcance, la cual está muy ligada con el Plan de Gestión
del Proyecto, de tal forma que un proceso alimenta a otro continuamente.
• A pesar de que el modelado de datos es una rama relativamente nueva, apenas
30 años desde que dieron los primeros pasos para establecer nomenclaturas y
reglas que pudiesen estandarizar el conocimiento repartido entre diversas
entidades, representa una herramienta muy valiosa para retroalimentar la gestión
del alcance en proyectos de software. Esto debido a que permite establecer un
puente entre el modelado de procesos y negocio, actividad que por lo general se
realiza del lado del cliente, quien no necesariamente entiende de aplicaciones de
software, y el diseño, el cual retroalimenta y detalla el alcance desde una
perspectiva técnica.
85
• A pesar de que la Administración de Proyecto de Desarrollo de Software es
relativamente nueva, apenas del último lustro con respecto a actividades mas
antiguas como puede ser la arquitectura o construcción, se nota un esfuerzo
significativo de entidades y empresas, incluyendo el Instituto para la
Administración de Proyecto (PMI) por lograr reunir las mejores prácticas de
trabajo que faciliten la labor de los directores de proyecto.
V.1 Lecciones Aprendidas durante la Planeación de LAR Leave Consolidation
• Al construir el modelo de negocio con base en una serie de observaciones,
entrevistas y su respectivo análisis, es posible que al finalizar se entere uno de
que ya esa investigación se había hecho, por lo que es importante empezar por
indagar quienes ya han trabajado en el modelo del negocio existente y pedir a la
gerencia esa posible documentación.
• Es muy común que el cliente diga que quiere un requerimiento de cierta manera,
porque así piensa que se debería ejecutar el negocio, pero en la práctica es
posible que sea diferente, por lo que hay que verificar el comportamiento
existente.
• La retroalimentación entre los distintos procesos que influyen en la Gestión del
Alcance es muy importante y no se debería obviar de los proyectos tradicionales,
ya que esto reduce el riesgo de que hayan cambios significativos en etapas
tardías, y por ende de mayor impacto, en el proyecto.
• Al comparar la experiencia adquirida durante la etapa de planeación de LAR
Leave Consolidation, el cual ha seguido la metodología propuesta en este
proyecto de graduación, con la de otros proyectos realizados con anterioridad; se
concluye que si el equipo no tiene experiencia en la estimación de tiempos para
proyectos con características similares, el diseño DEBE realizarse antes de la
estimación de tiempos como parte de la definición del alcance, debido a que
aporta el grado de confiabilidad necesaria para establecer un compromiso de
tiempo / costo realista y acertado.
86
V.2 Recomendaciones
• La etapa de pre-exploración en proyectos de software debe aprovecharse para
entender el negocio, los sistemas adyacentes, las personas involucradas y sus
intereses de la mejor forma posible, con lo que se favorecerá el desarrollo de las
etapas subsiguientes.
• Empezar el diseño y el análisis de impacto en sistemas existentes antes de que
los requerimientos sean aprobados puede reducir el riesgo de tener que
administrar cambios que atenten contra el éxito de proyectos tradicionales.
• Las personas quieren ser tomadas en cuenta, inclusive los involucrados con muy
poca influencia en el desarrollo del proyecto, por lo que en muchos casos con
solo preguntar su opinión es suficiente para que apoyen el proyecto, y ayuden a
proliferar sus beneficios.
• Las personas que más preguntas hacen y mas tratan de atentar contra el
desarrollo del proyecto, son las que se deben involucrar en el círculo de
decisiones.
• No minimizar la labor de definición del alcance a tan solo especificación de
objetivos y requerimientos. El alcance debe estar formulado con base en la
retroalimentación que reciba de los resultados del diseño.
• El proceso de diseño para aplicaciones de software no es una actividad intuitiva.
Requiere un proceso de aprendizaje y técnicas que se han ido mejorando con el
tiempo. Si el equipo es muy nuevo en la labor de diseño, es recomendable contar
con una asesoría externa que permita el desarrollo de esta capacidad en el
equipo.
• La labor del analista de sistema debe ser un trabajo integral que involucre no solo
el interés del cliente y su negocio, si no también las características técnicas del
ambiente de desarrollo. Esto puede resolver mal entendidos que se pueden
presentar al inicio de las conversaciones de investigación y análisis.
87
VI Bibliografía
Chacon Jiménez, Marco y Henry Viquez Díaz, Metodología de Administración de
Requerimientos para Proyectos de Software , Proyecto Final de Graduación
presentado en le Universidad para la Cooperación Internacional, San José, Costa Rica,
Octubre, 2003.
Chamoun, Yamal. Administración Profesional de Proyectos: La Guía , Primera
Edición, McGraw-Hill Interamericana, México, 2002
Crisis, Mary Beth, Mike Konrad and Sandy Shrum, CMMI ® Guidelines for Process
Integration and Product Development, Second Edition, SEI Series in Software
Engineering, Addison Wesley, 2006
Creighton, James L. y James W.R. Adams, Caber Meeting: How to Link People
and Technology in your Organization, AMACOM, New York – USA, 1998
De Bono, Edward and Robert Heller, Thinking Managers, 2006 extracted from
http://www.thinkingmanagers.com/business-management/business-strategy.php
Guillen Brenes, Johnny Adalberto, Administración de Proyectos con equipos
multiculturales y geográficamente dispersos (Aspect os Humanos y de
Comunicación), Proyecto Final de Graduación presentado en le Universidad para la
Cooperación Internacional, San José, Costa Rica, Marzo, 2007.
Hamilton, Marc y Harris Kern, Software Development: Building Reliable Systems ,
Prentice Hall PTR, 1999
Lipnak, Jessica y Jeffrey Stamps, Virtual Teams: Reaching Across Space, Time
and Organizations with Technology, John Wiley & Sons INC, New York – USA, 1997
88
Mannion , Mike and Barry Keepence. SMART Requirements , Sottware Engineering
Research Group, Napier University, Department of Mechanical, Manufaeting and
Sottware Engineering, United Kingdom, 1995
Miller, Todd, Matthew L. Nelson, Stella Ying Shen and Michael J. Shaw. e-Business
Management Models: A Services Perspective and Case Studies , The Revere Group
in conjunction with the University of Illinois, 2009
National Aeronautics and Space Administration (NASA), CALIPSO: Management
Challenges within a Complex Project Structure , Teaching Note for NASA Case
Study, 2007
Newell, Michael W. Preparing for the Project Management Professional ( PMP)
Certification Exam , Tercera Edición, Editorial AMACOM, 2005
PMI Standard, Guía de los Fundamentos de la Dirección de Proyecto s (Guía del
PMBOK) , Tercera Edición, ANSI/PMI, 2003
Real Academia Española. Diccionario de la Lengua Española , Vigésimo Segunda
Edición, 2001
Sharp, Alec. Presentación de Extras . Trabajo presentado durante el seminario
Advanced Data Modeling: Communication, Consistency and Complexity de la
compañía Clariteq Systems Consulting para Intel Costa Rica, 2008
Scofield, Michael, Data Quality: Building a Data Inventory Utilizing D ata
Profiling , Article URL: http://www.b-eye-network.com/view/1447, Aug 30, 2005
Wiegers, Karl E. Software Requirements , Second Edition, Microsoft Press, 2003
Wolkovicz, Philippe. UML: Object Oriented Analysis and Design Course , ACTL
Systems, Jerusalem, Israel, 1999
89
VII Anexo A – Documentación para la Administración de este
Proyecto de Graduación
VII.1 Charter del Proyecto de Graduación
Cuadro No. 7 : Acta del Proyecto de Graduación
Acta del Proyecto (Charter)
Fecha: Nombre del Proyecto:
Enero 20, 2009
Metodología para la definición del Alcance durante la Planificación de
un Proyecto de Desarrollo de Software
Áreas de Conocimiento: Área de Aplicación:
Alcance, Destrezas Gerenciales, Estrategia Proyectos de desarrollo de software
Fecha de Inicio: Fecha de Fin:
Enero 26, 2009 Abril 17, 2009
Objetivos del Proyecto:
General: Desarrollar una metodología de planificación para la definición del alcance en un proyecto de desarrollo de
aplicaciones empresariales.
Específicos :
o Investigar varios modelos de administración de proyectos de software (CMMi, AGILE, TOC, Proyectos SAP).
o Estudiar tres técnicas de modelado para negocios, datos y sistemas.
o Utilizar estos modelos en la definición del alcance del proyecto LAR Leave Consolidation.
Descripción del Producto:
Documento investigativo teórico/practico que ofrece una seria de soluciones con base en las lecciones aprendidas
en diversos proyectos de software y ejemplificando la definición del alcance por medio del caso LAR Leave Consolidation
Necesidad del Proyecto:
En el conjunto de proyectos de desarrollo de aplicaciones empresariales o de gran escala, en las que se enfoca este
documento, todavía hay ciertas dudas de cuando utilizar una metodología en contraposición a otra. Tampoco queda muy
claro cual es la mejor manera de escribir los requerimientos sin perder detalles importantes que luego se vuelven mal
entendidos, ni de donde extrapolarlos de una forma clara y visual, tanto para el equipo del proyecto, como para sus
clientes.
Justificación del Impacto:
Este trabajo no pretende generalizar la definición del alcance, ya que como se ha mencionado, la índole de un
proyecto de desarrollo de software tiene variables que hay que responder antes de tomar una decisión sobre la
metodología a seguir. Sin embargo, pretende ofrecer una manera estructurada y ejemplificada de cómo definir el alcance
de un proyecto de desarrollo para aplicaciones empresariales, donde la escala del producto sea considerada grande, es
decir, cuyo objetivo sea crear un sistema completo para solucionar un problema de negocio o automatizar un proceso.
No se tomarán en cuenta aplicaciones SAP o proyectos, donde su objetivo principal es configurar un sistema genérico,
para lograr una aplicación específica al negocio.
90
Restricciones/Factores Críticos de Éxito:
Rest ricciones:
- Este documento está basado en la experiencia de proyectos para aplicaciones empresariales desarrolladas desde su
inicio, por lo que es muy probable que existan matices relacionados con la definición del alcance que aplican a otro tipo
de proyectos de desarrollo de software y que no serán mencionados.
- El proyecto final de graduación será desarrollado en un lapso de tres meses, independientemente de las actividades del
proyecto "LAR Leave Consolidation".
Factores de Éxito:
- El producto cumple con sus objetivos y representa un documento de calidad.
Grupos de Interés:
Posibles Clientes:
- Estudiantes de Maestría en Administración de Proyectos.
- Personas involucradas en administrar, planear o analizar estrategias para Proyectos de software.
Aprobado por: Firma:
VII.2 Declaración del Alcance del Proyecto de Gradu ación
Proyecto: Metodología para la definición del Alcance durante la Planificación de un
Proyecto de Desarrollo de Software
Fecha: Enero 20, 2009
Planteo del Problema:
En el conjunto de proyectos de desarrollo de aplicaciones empresariales o de gran
escala, en las que se enfoca este documento, todavía hay ciertas dudas de cuando
utilizar una metodología en contraposición a otra. Tampoco queda muy claro cual es la
mejor manera de escribir los requerimientos sin perder detalles importantes que luego
se vuelven mal entendidos, ni de donde extrapolarlos de una forma clara y visual, tanto
para el equipo del proyecto, como para sus clientes.
Objetivos del Proyecto:
General: Desarrollar una metodología de planificación para la definición del alcance
en un proyecto de desarrollo de aplicaciones empresariales.
91
Específicos:
• Investigar varios modelos de administración de proyectos de software
(CMMi, AGILE, TOC, Proyectos SAP)
• Estudiar tres técnicas de modelado para negocios, datos y sistemas, así
como técnicas para desarrollar requerimientos.
• Utilizar estos modelos en la definición del alcance del proyecto LAR Leave
Consolidation.
Producto Principal del Proyecto:
Documento investigativo teórico/practico que ofrece una seria de soluciones en base
a las lecciones aprendidas en diversos proyectos de software y ejemplificando la
definición del alcance por medio del caso LAR Leave Consolidation
Entregables del Proyecto:
• Para el Seminario:
o Estructuración del documento para el Proyecto Final de
Graduación.
o Marco Teórico y Marco Metodológico del PFG.
• Para el desarrollo del proyecto de graduación:
o Procesos y Estructuras de Negocio: Soluciones para desarrollo de
procesos de negocios en paralelo al desarrollo de software.
o Técnicas sobre modelado de datos y flujos de trabajo, así como
para la definición de requerimientos.
o Metodología para la definición del alcance y estructuración de
requerimientos para proyectos de desarrollo de aplicaciones
empresariales.
92
VII.3 Estructura de Tareas del Proyecto de Graduaci ón
Figura No. 42: EDT del Proyecto Final de Graduación
93
VII.4 Cronograma
Figura No. 43: Cronograma del Proyecto Final de Graduación
94
VIII Anexo B – Documentos del Proyecto LAR Leave Consolidation VIII.1 Acta del Proyecto LAR Leave Consolidation
Cuadro No. 8 : Acta del Proyecto LAR Leave Consolidation
Project Manager Georgina Saborio
Start Date 1-Nov-08
Project Name LAR Leave Request Tool End Date 15-Dec-09
Element Description Please complete this section about your project:
1. Project Description/ Problem statement
What offering is to be developed, improved or extended? What improvement is targeted and what will be the impact? How do you quantify success? Problem statement and goal
There are about 10 tools being used to calculate special days, like vacations, leaves, overtime and on call hours. The amount of manual work and cumbersome procedures, like following very detailed checklists to integrate the information, covers a great amount of work, which may introduce data integrity issues. This also increases supportability costs every time there are new exceptions to the already complicated process. The goal is to explore and develop the possibility of consolidating 10 tools into one solution, in order to reduce maintenance costs for IT, increase flexibility in supporting new regulations and increase quality.
2. Project Scope What will be included/ what will be excluded:
In Scope: 1. Vacations 2. Overtime 3. On Call 4. Leaves 5. Payroll integration and consolidation Out of Scope: 1. Time and attendance tools 2. Payroll Calculations
3. Metrics What improvement is targeted? How do you quantify success?
Process Metric Baseline/ Current Goal Units
Description of Metric 1
Flexible Rule Exception Handling
Today there are about x number of exceptions that need to handled manually or by code changes, extra checklist
Configurable through database
Description of Metric 2
Conflicts Resolutions
There is no prioritization list or very basic. It is a manual process.
Develop prioritization list
Provide exception case handling through a page
Description of Metric 3
Tool Integration X number of manual processes to integrate employee data
Reduce the amount of manual processes to zero. Implement tool integration with various jobs.
4. Customers and Benefits
How is the project linked to the strategic and operating plans? What key business issues are addressed? What key business issues are addressed?
Internal Customer Benefits: payroll, TC, employees and support groups. For payroll and the TC we will reduce the time spend running the payroll; for the employees we will give them a complete application were they can request and keep track of all their types of leaves and for the support groups we will reduce the amount of applications to support from around 10 to 1. External Customer Benefits – N/A
5. Strategic Importance What resources are available to the team? What decisions can the team make? What recommendations might the team make?
� Progress to Overall IT End of Life Objectives