PROPUESTA DE UN MODELO DE ANLISIS PARA ESTIMACIN DEL TAMAO DEL SOFTWARE Y GESTIN DE COSTOS Y RIESGOS A PARTIR DE REQUERIMIENTOS FUNCIONALES.

AUTORES: SANDRA PATRICIA FORIGUA, OSCAR ARTURO BALLESTEROS

PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA CARRERA DE INGENIERIA DE SISTEMAS BOGOTA D.C., JUNIO DE 2007

PROPUESTA DE UN MODELO DE ANLISIS PARA ESTIMACIN DEL TAMAO DEL SOFTWARE Y GESTIN DE COSTOS Y RIESGOS A PARTIR DE REQUERIMIENTOS FUNCIONALES

AUTORES: SANDRA PATRICIA FORIGUA, OSCAR ARTURO BALLESTEROS

TRABAJO DE GRADO PRESENTADO PARA OPTAR EL TTULO DE INGENIERO DE SISTEMAS

INGENIERO LUIS CARLOS DAZ PROFESOR ASISTENTE DIRECTOR DEL TRABAJO DE GRADO

PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA CARRERA DE INGENIERIA DE SISTEMAS BOGOTA D.C., JUNIO 2007

PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA CARRERA DE INGENIERIA DE SISTEMAS

Rector Magnfico: Padre Gerardo Remolina Vargas S.J. Decano Acadmico Facultad de Ingeniera: Ingeniero Francisco Javier Rebolledo Muoz Decano del Medio Universitario Facultad de Ingeniera: Padre Sergio Bernal Restrepo S.J. Director Carrera de Ingeniera de Sistemas: Ingeniera Hilda Cristina Chaparro Lpez Director Departamento de Ingeniera de Sistemas: Ingeniero Germn Alberto Chavarro Flrez

Nota de Aceptacin ______________________________________________________ ______________________________________________________ ______________________________________________________ ______________________________________________________ ______________________________________________________

__________________________________________ Firma del Director del Proyecto

_________________________________________ Firma del Jurado

_________________________________________ Firma del Jurado

BOGOT D.C., JUNIO DE 2007

Artculo 23 de la Resolucin No. 1 de Junio de 1946: La Universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus proyectos de grado. Slo velar porque no se publique nada contrario al dogma y la moral catlica y porque no contengan ataques o polmicas puramente personales. Antes bien, que se vean en ellos el anhelo de buscar la verdad y la Justicia

DEDICATORIA:

Este trabajo es en primer lugar el resultado del apoyo de muchas personas que con la ayuda de Dios nos acompaaron para lograr culminar lo que un da nos propusimos llenos de

entusiasmo y dedicacin como fue estudiar la carrera de Ingeniera de Sistemas, por lo cual dedicamos a todos ellos este logro tan importante en nuestra vidas. A nuestros padres que siempre estuvieron a nuestro lado dndonos una voz de aliento cuando en momentos difciles necesitbamos de un consejo y siempre creyeron en nosotros, demostrndonos sus valores e ideales los cuales retomamos para la consecucin de esta meta. Y a Dios porque gracias a su compaa y fuerza este logro es alcanzado.

RESUMEN

Este trabajo de grado se encuentra orientado al estudio de las metodologas, mtodos, herramientas y tcnicas asociadas a las reas de la estimacin del tamao y la gestin de costos y riesgos, con el propsito de sustentar la propuesta de un modelo que represente, en un solo marco conceptual y prctico, los pasos a seguir para alcanzar una adecuada gestin de proyectos de software en estas reas.

Fundamentalmente este trabajo de grado recoge las principales bases conceptuales acerca de la estimacin y la gestin de costos y riesgos, y profundiza en ellas con el fin de alcanzar un anlisis comparativo que define la seleccin de los mtodos y metodologas, como el sustento de un modelo que apoye el desarrollo de estas actividades en pequeas empresas de desarrollo de software colombianas.

La propuesta de este modelo toma en cuenta las experiencias y datos estadsticos, disponibles en la actualidad, que apuntan a las prcticas de planeacin de proyectos de software en las pequeas empresas de software en Colombia. Para ello este trabajo incluye dentro de sus bases tericas los resultados de la encuesta anual de gerencia de proyectos realizada por ACIS (Asociacin Colombiana de Ingenieros de Sistemas) y las conclusiones relacionadas con la aplicacin de una encuesta dirigida a encargados de reas tecnolgicas de empresas bogotanas.

De esta manera se definieron los pasos del modelo y la forma cmo se deberan integrar los procesos de estimacin y gestin de costos con la gestin de riesgos en un solo marco, involucrando las necesidades que ciertos procesos de planeacin requieren suplir para llevar a feliz trmino un proyecto de software.

Por ltimo se expone la parte prctica del modelo a travs de un caso de estudio.

Esta

aplicacin experimental, desarrollada sobre un proyecto de redes de comunicacin, permiti identificar aspectos del modelo que deberan ser modificados o incluidos logrando as su refinamiento de manera gradual.

CONTENIDO
INTRODUCCIN..................................................................................................................... 15 OBJETIVOS.............................................................................................................................. 16 OBJETIVO GENERAL:......................................................................................................... 16 OBJETIVOS ESPECIFICOS: ................................................................................................ 16 1. ESTADO DEL ARTE ........................................................................................................... 17 1.1 ESTIMACIN DEL TAMAO DEL SOFTWARE....................................................... 17 1.1.1 Metodologas de estimacin del tamao del software ............................................. 18 1.2 GESTIN DE COSTOS.................................................................................................. 21 1.2.1 Estimacin del costo del proyecto ............................................................................. 21 1.2.2 Estimacin del presupuesto del proyecto .................................................................. 24 1.2.3 Control del presupuesto del proyecto ........................................................................ 26 1.3 GESTIN DEL RIESGO ................................................................................................. 27 1.3.1 Modelos existentes .................................................................................................... 28 1.3.2 Elementos de la gestin del riesgo ............................................................................ 29 2. PROPUESTA CONCEPTUAL DEL MODELO ............................................................... 39 2.1 CARACTERIZACIN DE PROYECTOS DE TECNOLOGA DE LA INFORMACIN .................................................................................................................... 39 2.1.1 Caracterizacin de proyectos de TI en Colombia...................................................... 40 2.1.2 Aproximacin a la actualidad de las empresas y reas de tecnologa colombianas .. 42 2.1.3 Generalidades de las empresas de desarrollo en el Reino Unido ............................ 44 2.2 PLANTEAMIENTO DEL MODELO PARA LA ESTIMACIN DEL TAMAO ....... 45 2.2.1 Evaluacin de mtodos para la estimacin del tamao del software......................... 46 2.2.2 Mtodo escogido para la estimacin del tamao del software .................................. 46 2.2.3 Por qu se escogi este mtodo?.............................................................................. 47 2.2.4 Esquema del mtodo de Puntos de funcin ............................................................... 47 2.3 PLANTEAMIENTO DEL MODELO PARA LA ESTIMACIN DE COSTOS DEL PROYECTO ........................................................................................................................... 47 2.3.1 Evaluacin de mtodos y modelos para la estimacin de costos.............................. 48 2.3.2 Modelo escogido para la estimacin de costos.......................................................... 49 2.3.3 Esquema del modelo COCOMO II ........................................................................... 49 2.4 PLANTEAMIENTO DEL MODELO PARA LA ESTIMACIN DEL PRESUPUESTO49 2.4.1 Evaluacin de mtodos para la estimacin del presupuesto...................................... 50 2.4.2 Mtodo escogido para la estimacin del presupuesto................................................ 51 2.5 PLANTEAMIENTO DE UNA METODOLOGA PARA EL CONTROL DEL PRESUPUESTO..................................................................................................................... 51 2.5.1 Evaluacin de mtodos para el control del presupuesto............................................ 51 2.5.2 Mtodo escogido para el control del Presupuesto ..................................................... 52 2.6 PLANTEAMIENTO DEL MODELO DE GESTIN DE RIESGOS.............................. 53 2.6.1 Principios bsicos en los cuales debera basarse una metodologa de gestin de riesgos................................................................................................................................. 53 2.6.2 Requisiciones de una metodologa de gestin de riesgos.......................................... 53 2.6.3 Por qu se escogi esta metodologa?...................................................................... 54 2.6.4 Fases o pasos de la metodologa................................................................................ 55 2.7 Resultados del capitulo ..................................................................................................... 65 3. MODELO PARA LA ESTIMACIN Y GESTIN DE PROYECTOS ......................... 66 3.1 PASO I: DEFINIR LOS REQUERIMIENTOS FUNCIONALES DEL PROYECTO .... 67 3.1.1 Proceso de definicin de requerimientos................................................................... 67 3.1.2 Descripcin del proyecto y especificacin de los requerimientos............................ 67 3.2 PASO II: ESTIMAR EL TAMAO DEL SOFTWARE ................................................. 68 3.2.1 Modelo para la estimacin del tamao ...................................................................... 68 3.3 PASO III: GESTIONAR LOS COSTOS.......................................................................... 74 3.3.1 Modelo para la gestin de costos............................................................................... 74

3.3.2 Estimacin de costos utilizando COCOMO II .......................................................... 75 3.3.3 Control de costos y presupuesto ................................................................................ 78 3.4 PASO IV: GESTIONAR LOS RIESGOS ........................................................................ 79 3.4.1 Prepararse para la gestin .......................................................................................... 80 3.4.2 Identificar los riesgos y categorizarlos ..................................................................... 81 3.4.3 Cuantificar y cualificar los riesgos ............................................................................ 83 3.4.4 Responder al riesgo .................................................................................................. 87 3.4.5 Fase de control y seguimiento ................................................................................. 88 3.5 Paso V: Finalizar la gestin.............................................................................................. 90 3.6 Resultados de este captulo ............................................................................................... 90 4. CONCLUSIONES................................................................................................................. 91 5. TRABAJOS FUTUROS ....................................................................................................... 92 BIBLIOGRAFA....................................................................................................................... 93

LISTA DE TABLAS

Tabla 1. Trminos del anlisis del valor ganado ....................................................................... 27 Tabla 2. Formulas del mtodo de valor ganado ........................................................................ 27 Tabla 3. Procesos de gestin de riesgos .................................................................................... 28 Tabla 4. Perfil de riesgos [Armstrong, 2004]............................................................................ 30 Tabla 5. Estimacin de tres puntos del calendario .................................................................... 34 Tabla 6. Evaluacin de los mtodos para estimacin del tamao del software ........................ 46 Tabla 7. Evaluacin de los mtodos para la estimacin de costos ............................................ 48 Tabla 8. Evaluacin de mtodos para la estimacin del presupuesto de un proyecto............... 50 Tabla 9. Evaluacin de las metodologas para el control del presupuesto ................................ 52 Tabla 10. Comparacin de las tcnicas para la identificacin de riesgos ................................. 57 Tabla 11. Elementos del proceso para la definicin de requerimientos .................................... 67 Tabla 12. Determinacin de la dificultad de implementacin para ILF y ELF [Boehm, 1999] 72 Tabla 13. Determinacin de la dificultad de implementacin para EI [Boehm, 1999]............ 72 Tabla 14. Determinacin de la dificultad de implementacin para EO y EQ [Boehm, 1999] . 72 Tabla 15. Clculo del Total de Puntos de Funcin ................................................................... 73 Tabla 16. Elementos del modelo para la estimacin del tamao .............................................. 74 Tabla 17. Elementos del modelo para la estimacin y gestin de costos.................................. 79 Tabla 18. Acrnimos para la mtrica de riesgo en calendario .................................................. 90

10

LISTA DE FIGURAS

Figura 1. Modelo de gestin de riesgos ms aceptado en la actualidad ..................................... 28 Figura 2. Grfico de perfil de riesgos [Armstrong, 2004].......................................................... 31 Figura 3. Red de actividades de un proyecto............................................................................... 33 Figura 4. Datos para la estimacin de riesgos en costos ............................................................. 34 Figura 5. Rango de costos para cada uno de los elementos del WBS[Hulett, 2004] .................. 35 Figura 6. Ejemplo simulacin Monte Carlo para costos fuente[Hulett, 2004]............................ 35 Figura 7. Desempeo en el cronograma de proyectos de TI en Colombia.................................. 41 Figura 8. Desempeo en el presupuesto de proyectos de TI en Colombia................................ 41 Figura 9. Actualidad de la estimacin del esfuerzo y tamao en algunas reas y empresas ....... 43 Figura 10. Actualidad de la estimacin de costos ....................................................................... 43 Figura 11. Principios bsicos de un proceso de gestin de riesgos ............................................. 53 Figura 12. Requisiciones para una metodologa de gestin de riesgos ....................................... 54 Figura 13. Metodologa de gestin de riesgos para el modelo .................................................... 54 Figura 14. Fuentes de riesgos del modelo ................................................................................... 55 Figura 15. Categoras relacionadas con la identificacin de riesgos en proyectos de software. . 56 Figura 16. Asunciones bsicas de un mtodo para la identificacin de riesgos.......................... 58 Figura 17. Taxonoma de riesgos de proyectos de software [Marvin J. Carr et al., 1993]......... 59 Figura 18. Categorizacin de riesgos identificados..................................................................... 60 Figura 19. Tipos de anlisis y categoras del riesgo.................................................................... 61 Figura 20. Niveles de prioridad de riesgos.................................................................................. 61 Figura 21. Propuesta de reuniones del tipo Wideband Delphi para la cualificar los riesgos ...... 63 Figura 22. Proceso de respuesta al riesgo ................................................................................... 64 Figura 23. Proceso de control de respuesta al riesgo. ................................................................. 65 Figura 24. Pasos del modelo propuesto....................................................................................... 66 Figura 25. Proceso para la definicin de los requerimientos....................................................... 67 Figura 26. Esquema del Modelo de estimacin del Tamao ...................................................... 68 Figura 27. Esquema del Modelo para la gestin de Costos........................................................ 75 Figura 28. Diagrama de flujo de la metodologa de gestin de riesgos ...................................... 80 Figura 29. Paso I de la metodologa de gestin de riesgos.......................................................... 80 Figura 30. Delimitacin segn la clase Entorno de desarrollo.................................................... 81 Figura 31. Delimitacin segn la clase Restricciones de programa............................................ 81 Figura 32. Delimitacin segn la clase Ingeniera del producto ................................................. 82 Figura 33. Categorizacin de riesgos identificados..................................................................... 82 Figura 34. Dinmica variante Wideband Delphi para la evaluacin de riesgos tcnicos............ 84 Figura 35. Evaluacin de resultados ........................................................................................... 85 Figura 36. Respuesta al riesgo del modelo propuesto ................................................................. 87 Figura 37. Control y seguimiento del modelo propuesto ............................................................ 88 Figura 38. Estado de planes de riesgo y revisin ........................................................................ 89 Figura 39. Mtrica para riesgo en costo ..................................................................................... 89 Figura 40. Mtrica para riesgo en calendario .............................................................................. 90

11

LISTA DE ANEXOS

Anexo A ...................................................................................................................................... 96 Anexo B .................................................................................................................................... 112 Anexo C .................................................................................................................................... 123 Anexo D .................................................................................................................................... 139 Anexo E..................................................................................................................................... 141

12

GLOSARIO

COCOMO (Constructive Cost Model): Modelo parametrico usado para estimar el esfuerzo y calendario de un proyecto de desarrollo de software [Boehm, 1999].

CPM (Critical Path Model): Mtodo de la ruta critica, este mtodo es usado en la administracin de proyectos, para determinar la secuencia de actividades dentro de la red del proyecto que determina la duracin del proyecto [Hulett, 2004].

Descomposicin de la Estructura del Trabajo (Work Breakdown Structure): Estructura formada por el conjunto de tareas y entregables necesarios para completar un proyecto [Hulett, 2004].

EAC (Estimate At Completion): Valor expresado en moneda u horas para representar los costes finales de trabajo cuando est sea terminado. En trminos de un proyecto se define mediante la formula EAC=ETC + ACWP, donde ETC representa el valor de lo que habr que gastar hasta el final del proyecto y ACWP el valor del cote total del proyecto al final de ste [Thayer, 2003].

Earned Value Anlisis (Anlisis del Valor Ganado): Es un mtodo para estimacin del progreso en cualquier punto del tiempo, se encarga de estimar el momento en que se finalice el proyecto, el costo del mismo al finalizar y analiza las variaciones en costo y calendario [Kirkpatrick, 92].

IEEE (The Institute of Electrical and Electronics Engineers): Asociacin tcnicoprofesional dedicada a la estandarizacin en el campo de la tecnologa, tambin se encarga de la promover la creatividad, el avance y integracin de los avances tecnolgicos [IEEE, 1990].

Lnea Base: Especificacin o producto que se ha revisado formalmente y sobre el cual se ha llegado a un acuerdo, y que de ah en adelante sirve como base para un desarrollo posterior [Kirkpatrick, 92].

Lluvia de Ideas: Es una herramienta de trabajo grupal que ayuda el surgimiento de nuevas ideas sobre un tema o problema determinado, la tcnica se basa en una reunin en donde los participantes generan ideas sobre el tema tratado [Esteves, 2004].

13

Mtodo Monte Carlo: Mtodo no determinstico o estadstico usado para aproximar expresiones matemticas complejas y costosas de evaluar con exactitud, este mtodo proporciona soluciones aproximadas a una gran variedad de problemas posibilitando la realizacin de experimentos con muestreo de nmeros [Hulett, 2004].

Mtodo Wideband Delphi: Es un mtodo de estimacin basado en el consenso, es decir la estimacin es realizada por un conjunto de personas que deben llegar a un acuerdo acerca de lo que se esta estimando, este mtodo se ha utilizado en muchas reas exitosamente [Labdelaoui, 2001].

Mitigar un riesgo: Aplacar o reducir los efectos que la ocurrencia de un riesgo podra ocasionar (aplacar el impacto de un riesgo) [Thayer, 2003].

PMBOK: Es una coleccin de procesos y reas de conocimiento generalmente aceptadas como las mejores practicas dentro de la gestin de proyectos. Este estndar fue construido por el Project management institute [Microsoft, 2002].

Punto de Funcin (Function Point): Medida del tamao de un sistema de software y del proyecto que lo construye, esta mediada se basa en la teora de que la funcionalidad del software es la mejor medida de su tamao [Labdelaoui, 2001].

Requerimientos Funcionales: estos son las funciones que el sistema en desarrollo ser capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas [Camacho, 2005].

SEI (Software Engineering Institute): Instituto federal de investigacin, dedicado a la investigacin de temas relacionados con la ingeniera de software y el mejoramiento en el proceso de desarrollo de software [Marvin J. Carr et al., 1993].

SRS (Software Requeriments Specification): Documento donde se definen de forma precisa los requerimientos funcionales del software que se va a construir [IEEE, 1990].

14

INTRODUCCIN

La medicin del software se presenta en nuestros das como un medio esencial para realizar las estimaciones oportunas del esfuerzo, tiempo y coste necesarios para el desarrollo de proyectos de software [Labdelaoui, 2001], asimismo, la gestin de costos y la atencin temprana de los posibles riesgos enfrentados de un proyecto surgen como actividades fundamentales que una empresa relacionada con las actividades de tecnologa de la informacin (TI) debe tener en cuenta dentro de su presupuesto. Adicionalmente a travs de la historia, se han planteado diversos modelos que integran tcnicas y metodologas construidas para estos fines.

Este trabajo integra los estudios y anlisis efectuados entorno a los temas de estimacin del tamao del software y la gestin de costos y riesgos de un proyecto de desarrollo, los cuales encuentran su razn de ser en las metodologas y tcnicas creadas pensando, fundamentalmente, en facilitar las labores de planeacin de un proyecto. Por otro lado, nace tras la necesidad de establecer criterios para la seleccin de cualquiera de estas mismas tcnicas o metodologas que apoyen procesos de gran importancia como el de la gestin de costos y riesgos.

La definicin de los criterios para la clasificacin de las metodologas as como el reconocimiento de ciertos principios y requisiciones que deben ser tenidos en cuenta para su utilizacin en diversos contextos, no estara completo sin la debida formulacin de un marco comn que las integre a todas. De esta manera se plantea la propuesta de un modelo integral que cubre diversas tcnicas y metodologas asociadas a las reas de estimacin del tamao y gestin de costos y riesgos de un proyecto de desarrollo.

Por ltimo, cabe resaltar la importancia que representa para el modelo la definicin de los requerimientos funcionales. Los requerimientos especifican una base sobre la cual se generan algunos de los conceptos, decisiones y procedimientos que se desarrollarn en cualquiera de los pasos que lo constituyen.

Este documento refiere cada uno de los aspectos tratados anteriormente de acuerdo con la siguiente estructura: en primera instancia se enmarca el estado del arte de la propuesta del modelo, enseguida se establece la propuesta conceptual como un resultado de la integracin entre la revisin y estudio del estado del arte, y el conjunto de pasos y procedimientos que se quieren proponer en el marco del mismo. Finalmente se sustenta el conjunto de pasos que constituyen el modelo junto con la explicacin del caso de estudio escogido.

15

OBJETIVOS

OBJETIVO GENERAL: Desarrollar un modelo que rena diversas metodologas para la estimacin del tamao del software as como la gestin de costos y riesgos dentro de un proyecto de desarrollo basado en los requerimientos funcionales.

OBJETIVOS ESPECIFICOS: 1. Definir criterios especficos que permitan establecer una clasificacin de las metodologas existentes para la estimacin del tamao del software y la gestin de costos y riesgos en un proyecto de desarrollo teniendo presente el dominio del problema.

2. Determinar metodologas especficas a las reas de estimacin de tamao, gestin de costos y riesgos acordes con la clasificacin desarrollada y fundamentadas en los requerimientos identificados en un proyecto de desarrollo.

3. Definir un modelo que rena las metodologas anteriormente definidas de acuerdo con los criterios especificados y que facilite la estimacin del tamao del software y la gestin de costos y riesgos.

4. Verificar experimentalmente la validez del modelo mediante su aplicacin en al menos un caso de estudio, representado en un proyecto de software cuya fase de recoleccin de requerimientos se encuentre completamente definida mediante un modelo de anlisis de requerimientos.

16

1. ESTADO DEL ARTE

El contenido presentado en este captulo es el resultado de un estudio estructurado sobre las diversas fuentes bibliogrficas y experimentales relacionadas con los modelos, mtodos, metodologas y tcnicas construidos alrededor de los temas de estimacin del tamao del software, gestin de costos y riesgos en un proyecto de desarrollo. De manera resumida constituye la base terica sobre la cual se apoyarn los procedimientos y pasos que sern presentados. En la propuesta conceptual del modelo.

1.1 ESTIMACIN DEL TAMAO DEL SOFTWARE

Esta actividad se refiere a la necesidad de conocer a ciencia cierta qu tan grande va a ser el software que se va a construir y lograr conocer de manera tangible el costo de desarrollar un sistema basndose en una medicin acertada acerca del tamao del software [C. Shi Kuo, 2002].

La estimacin del tamao del software se puede realizar en diferentes etapas del proyecto. Dependiendo del perodo en que sta se lleve a cabo, es posible determinar su correspondencia con el tamao real del software. Por ejemplo, si la estimacin se realiza al final del proyecto se puede realizar una estimacin, por as decirlo 100% acertada, debido a que para este momento ya se conoce la duracin total de ste, adems de la cantidad de cdigo escrito. Sin embargo, si la estimacin se realiza en etapas tempranas del proyecto se podra decir que el resultado estara bastante alejado de la realidad. En conclusin, la realizacin de una estimacin ms temprana contribuye a que la incertidumbre entorno a los factores que afectan el proyecto disminuya.

Lo realmente importante de la estimacin no es necesariamente que sta sea 100% confiable, sino el hecho de que su realizacin contribuya en la determinacin del costo total del proyecto, por lo cual, se recomienda que durante el desarrollo de ste se realicen estimaciones y se corrijan las anteriores con la informacin que se vaya recolectando, lo que a largo plazo, ayuda a que las estimaciones que se hagan sobre proyectos futuros sean cada vez ms acertadas.

Para la realizacin de esta actividad existen diversos mtodos y metodologas, pero las metodologas mas destacadas para la estimacin del tamao del software son el conteo de lneas de cdigo del programa producido y el conteo de puntos de funcin. Sin embargo, en este tipo de estimaciones no se tienen en cuenta los documentos que se deben generar cuando se est

17

construyendo software. Dichos documentos tambin requieren tiempo y recursos, que incrementan el tamao del software en desarrollo. 1.1.1 Metodologas de estimacin del tamao del software

A continuacin se presenta una descripcin de cada una de las metodologas de estimacin del tamao, consideradas como las ms importantes y ms usadas por la industria. Como fue mencionado anteriormente existen bsicamente dos aproximaciones a esta estimacin: el conteo de lneas de cdigo y el conteo de puntos de funcin. A continuacin describiremos dichas aproximaciones [C. Shi Kuo, 2002]. Estimacin basada en lneas de cdigo. Esta estimacin se podra catalogar como de tipo tardo, ya que el nmero total de lneas de cdigo slo se puede conocer cuando el producto est terminado, aunque la tarea no es tan sencilla como contar la longitud de cada archivo; se debe acordar un formato, en donde se especifique qu es lo que se va a contar y qu no. Por ejemplo, los comentarios escritos en el cdigo no deberan ser contados, por lo cual slo se debe contar, lo que se especifique a ser contado. Dentro de esta categora existen varias metodologas las cuales usan las lneas de cdigo como base para la realizacin de su estimacin [C. Shi Kuo, 2002]. A continuacin se explican algunas de estas metodologas. Estimacin por conteo de bloques Este enfoque se basa en estimar el nmero de funciones esperadas que tendr el sistema. Se puede ver como un enfoque de estimacin temprana debido a que estima el nmero de funciones esperadas. Por tanto, se cuenta con poca informacin acerca del proyecto con lo que las estimaciones no podran ser muy exactas. De esta manera, a medida que avanza el proyecto es deseable que las estimaciones fueran ms coherentes con la realidad. Es posible que el mtodo pueda ser complementado con funciones estadsticas para encontrar una estimacin ms precisa. Con este fin es usada la desviacin estndar, obtenida a partir de la informacin de proyectos pasados ya realizados, lo cual mejora en gran parte las estimaciones para la organizacin.

A continuacin se enumeran los pasos empleados en el uso de este modelo:

a. Estimar el nmero de bloques, o componentes de software esperados. b. Multiplicar el nmero de bloques por el tamao esperado de cada tipo de bloque. c. Calcular la desviacin estndar para dicho proyecto.

18

d. Aplicar el mtodo repetidamente para los diferentes niveles de detalle, y as obtener una estimacin ms precisa. Estimacin del tamao estadstica Este mtodo se basa en la estimacin del tamao a partir de la utilizacin de clculos estadsticos y dividiendo el sistema en componentes para cada uno de los componentes que integran el sistema posibilitando la estimacin del sistema completo tomando como base cada uno de sus componentes por separado. Asimismo, este mtodo se encarga de disminuir la incertidumbre acerca de las estimaciones de los componentes individuales, lo cual posibilita contar con una estimacin mucho ms segura del sistema completo. Con este fin, el mtodo se basa en la estimacin por analoga, en la cual se compara el proyecto actual con otros anteriores ya realizados, evidenciando la necesidad de mantener una base de datos con la informacin acerca de todos estos proyectos anteriores que servirn para la estimacin del proyecto en curso.A continuacin se listan los pasos para estimar el tamao del software con este mtodo:

a. Determinar las funciones que compondrn el nuevo sistema. b. Buscar informacin acerca del tamao de funciones similares ya desarrolladas. c. Identificar las diferencias entre las funciones similares y las nuevas. d. Para cada componente o funcin a estimar, se deben estimar tres parmetros, el menor, medio y mximo tamao de cada uno de los componentes o funciones. e. Calcular la media estadstica y desviacin estndar de cada uno de los nmeros obtenidos en el numeral anterior. f. Tabular cada uno de estos datos obtenidos. g. Calcular la media total del proyecto, y la desviacin estndar del proyecto. Estimacin por lgica difusa Este mtodo se basa en dividir el proyecto en categoras de tamao y dependiendo de la cantidad de lneas de cdigo producidas en cada una clasificarlas en grande, mediano y pequeo. Para realizar esta categorizacin se requiere tener informacin de proyectos anteriores para generar los grupos antes descritos.

Por consiguiente para realizar la estimacin del nuevo proyecto se debe juzgar en qu categora quedara ste, lo cual dara un rango de lneas de cdigo que el nuevo proyecto podra producir.

Un problema que presenta este mtodo, es que el cambio tecnolgico trae como consecuencia que la magnitud en lneas de cdigo de un proyecto vari, lo cual podra hacer que los grupos ya anteriormente definidos necesariamente tengan que cambiar.

19

 Estimacin basada en puntos de funcin

Este mtodo se diferencia a los basados en lneas de cdigo en que, no se basa en la longitud de programa sino en la funcionalidad que presta, lo cual hace a este mtodo independiente del lenguaje.

El Anlisis de Punto Funcin es una tcnica que, mediante la descomposicin de un sistema en componentes ms pequeos, permite que stos puedan ser mejor comprendidos y analizados en forma individual.

El Anlisis de Punto Funcin se basa en la teora de que las funciones de una aplicacin son la mejor medida del tamao de un sistema. El Punto Funcin mide el software mediante la cuantificacin de la funcionalidad que el sistema le brinda al usuario basado fundamentalmente en el diseo lgico. Es independiente del lenguaje de computacin, de la metodologa de desarrollo, de la tecnologa utilizada y de la capacidad del equipo de trabajo para desarrollar la aplicacin [Mulcahy, 2002].

El Anlisis del Punto Funcin es un mtodo estndar de medicin de desarrollo de software desde el punto de vista del usuario. Su objetivo es medir el software basndose en la cuantificacin de la funcionalidad brindada al usuario partiendo fundamentalmente de diseos lgicos. La cuenta de Punto Funcin para proyectos de desarrollo mide las funcionalidades que se le proporcionan al usuario conjuntamente con la primera instalacin del software producido cuando el proyecto es terminado [Longstreet, 2004].

El mtodo realiza su estimacin contando el nmero de componentes de cada clase de punto funcional, luego se estima la complejidad de cada uno de los componentes medidos, alta o baja, segn sea el caso, luego se multiplica cada contador de puntos de funcin por el valor adecuado, y se suma el total de puntos de funcin.

Cada uno de los tipos de puntos de funcin se describe a continuacin. - Entradas externas: Datos o entradas de control al sistema que causan que el sistema lleve a cabo algn procesamiento. - Salidas Externas: datos o salidas de control que salen del sistema, luego de que un procesamiento a sido llevado a cabo. - Peticiones Externas: Solicitudes del sistema que requieren inmediata atencin. - Interfaces Externas: Archivos o programas que salen del sistema.

20

- Archivos Internos: agrupamiento lgico de informacin almacenada en el sistema. - Con cada uno de estos elementos se determina qu tan grande va a ser el sistema a desarrollar. 1.2 GESTIN DE COSTOS

La gestin de costos es una actividad necesaria para cualquier proyecto debido a que permite conocer qu tanto se va a gastar en su implementacin y desarrollo, el destino de los diferentes recursos del proyecto a las actividades planeadas y el control de lo que se est invirtiendo; de esta actividad depende en gran parte que la terminacin del proyecto genere ganancias o prdidas. Enseguida se enumeran cada una de las actividades que comprende la gestin de costos junto con la explicacin de cada una: 1.2.1 Estimacin del costo del proyecto

Como es de suponerse, el costo de un proyecto se encuentra directamente ligado al tamao del mismo, ya que el tamao determina en la mayora de los casos la duracin y la dificultad de realizar dicho sistema. Partiendo de esto, el tamao constituye uno de los factores que deben ser tenidos en cuenta al momento de realizar una buena estimacin del costo de un proyecto. Sin embargo, existen otros tales como: el costo del personal y los recursos necesarios que son claves para el debido desarrollo de esta actividad. Lo anterior nos deja una clara visin acerca de los mltiples aspectos que deben ser tenidos en cuenta al momento de realizar una estimacin apropiada del costo de un proyecto, as como el mtodo a usar para dicha estimacin. En general, existen dos tipos de mtodos para la estimacin del costo de un proyecto: los mtodos algortmicos y no algortmicos, los mtodos no algoritmos se basan por lo general en la experiencia dejada por proyectos anteriores. A continuacin se har una breve descripcin de los mtodos ms importantes para estimar el costo de un proyecto de software: 1.2.1.1 Metodologas de estimacin del costo de un proyecto de software

En general existen 2 tipos de mtodos para la estimacin del costo de un proyecto: los mtodos no algortmicos y no algortmicos [C. Shi Kuo, 2002]. A continuacin se hace una breve explicacin de los mtodos ms relevantes en esta rea. Mtodos no algortmicos:

Estos mtodos estn basados especficamente en las capacidades de juicio de las personas que realizan estas estimaciones, las personas se basan en su experiencia o experiencia de otros para

21

obtener una estimacin del proyecto a realizarle, los mtodos que pertenecen a esta categora muchas veces requieren de datos histricos para las estimaciones, lo que muchas veces es algo problemtico ya que no todas las organizaciones mantienen informacin de sus proyectos anteriores. Estos pueden ser: - Costos por Analoga Requiere que al menos se tenga informacin de un proyecto anterior similar, se usan los datos de las anteriores estimaciones y sus resultados para lograr una estimacin ms precisa. - Juicio Experto Se requiere consultar a uno o ms expertos en la estimacin del tamao de software, donde cada uno realiza una estimacin diferente y luego se llega a un consenso sobre sta. Los pasos que contiene este mtodo son:

a. Se presenta a cada estimador, se realiza la estimacin en la base de los compaeros. b. Cada experto llena una forma con los resultados obtenidos. c. El Coordinador prepara un resumen sobre cada una de as estimaciones. d. Se Repiten los 2 ltimos aspectos, hace lograr consenso entre los expertos.

- Parkinson Se estima sobre el volumen de la produccin del cliente, la cual se produce con los recursos que ste puede generar, se ajusta la propuesta para cumplir el presupuesto del cliente. Se obtiene una estimacin global a partir de las caractersticas de todo el sistema, para luego realizar basado en esto, la estimacin de cada parte del sistema. - Precio a Ganar Se fija el valor del proyecto para que sea el mejor de todos, sin tener en cuenta el tamao, toma en cuenta el presupuesto del cliente. - Bottom UP Se estima cada uno de los componentes del sistema por separado, y luego se realiza una estimacin total que comprende la sumatoria de cada una de las estimaciones pequeas. - Top down Este mtodo es opuesto al anterior, para este mtodo se realiza la estimacin del total del costo para el proyecto, y desde este total se deriva el costo de cada uno de los componentes del software a estimar, este mtodo es adecuado para fases iniciales del proyecto.

22

 Mtodos Algortmicos Estos mtodos se basan en la aplicacin de una funcin a las propiedades del sistema para obtener una estimacin formal de proyecto a implementar. Los mtodos algortmicos tienen en cuenta factores relacionados con: costos, producto, herramientas computacionales, humano, proyecto. equipo

- Modelos Lineales Los mtodos algortmicos se basan en la sumatoria de los aspectos que son relevantes al proyecto. Presenta como principal desventaja que la mayora de veces el desarrollo de un proyecto en cuanto al precio no se comporta de forma lineal

- Modelos Multiplicativos Se multiplican los factores importantes del software que determinan el costo total del proyecto.

- Modelos basados en funciones de potencia. Relaciona el tamao del software con otros factores de costo que influyen en el costo total del desarrollo del proyecto.

- COCOMO Este modelo fue publicado por Barry Boehm [Boehm,1999] y modificado posteriormente, es una proyeccin de las prcticas en la construccin de software de la poca, evolucionando hasta darle un giro completo a la manera en la que el software era construido, lo cual hizo que el modelo original quedar obsoleto, y entonces se decidiera, reconstruir el modelo para adaptarlo a las nuevas prcticas y hacerlo de nuevo vigente [Baker,2003]. Este modelo permite estimar el costo, el esfuerzo y el tiempo de duracin de un proyecto de software, y fue creado para su utilizacin junto a los ciclos de vida modernos en los proyectos de software y sigue las necesidades de los usuarios de la estimacin de costos en los proyectos de software, las cuales son apoyo en la planificacin de proyectos, previsin del personal del proyecto, preparacin del proyecto, replanificacin, seguimiento del proyecto [B. Boehm, 1999].

Para realizar todo esto, COCOMO II proporciona tres modelos de estimacin cada vez ms detallado, que tienen en cuenta cada sector y tipo de informacin necesaria en cada etapa del desarrollo de un proyecto de software. Cada uno de estos modelos ofrece mayor fidelidad en las estimaciones a medida que se avanza en la planificacin y el diseo del mismo. Los modelos indicados son:

23

a. Modelo de composicin de aplicaciones: Este modelo cubre los proyectos realizados con herramientas modernas de construccin de interfases grficas. b. Modelo de Diseo Anticipado: Este modelo est diseado para aplicarse en etapas iniciales del desarrollo en las cuales la arquitectura del mismo no haya sido totalmente definida. c. Modelo de Postarquitectura: Este es el modelo ms completo incluido en COCOMO II, y est diseado para aplicarse luego que se ha terminado la etapa de diseo y luego de que la arquitectura del proyecto se encuentra bien planificada.

- SLIM Se basa en la distribucin de poder hombre y los descubrimientos en proyectos anteriores. Se usa la ecuacin de software, en donde se relaciona, el tiempo de entrega, factores ambientales, en los cuales se refleja la capacidad de desarrollo de la compaa, mediante el uso de informacin de proyectos pasados.

- Modelos discretos Estos modelos son del tipo modular en donde se relaciona el esfuerzo, duracin y dificultad y otros factores de costo, son fciles de usar. 1.2.2 Estimacin del presupuesto del proyecto

El presupuesto es el plan de gastos para un proyecto. En dicho presupuesto se le asignan recursos a cada una de las actividades en las que se dividi la totalidad del proyecto. Tal asignacin debe tener en cuenta factores tales como: salarios, costos de instalaciones, costo de equipos, etc.; pero ms all que una asignacin de recursos, el presupuesto es una herramienta de control que servir para una futura determinacin del estado del proyecto recuerdo con el dinero gastado.

Es importante realizar las estimacin del presupuesto usando una divisin detallada del trabajo, es decir, dividir el proyecto en tareas lo ms atmicas posibles; de esta manera, durante el desarrollo del proyecto se podr controlar el mismo de una manera mucho ms exacta.

1.2.2.1 Consideraciones al realizar un presupuesto

Ahora se presentarn algunos aspectos tiles al momento de construir el presupuesto de un proyecto [Baker, 2003]. - El Costo del Proyecto est atado a las metas del mismo.

24

- El Costo est atado al calendario del proyecto y hacer las cosas mucho ms rpido requerir mucho ms dinero. - Consultar la estimacin del presupuesto de cada una de las actividades con las personas que las realizarn: estas personas tienen un mayor conocimiento del esfuerzo que se debe emplear en estas tareas. - Consultar con otros gerentes de la organizacin: en la misma organizacin pueden encontrarse otras personas que hayan realizado proyectos similares y puedan contribuir con estimaciones para el proyecto. - Realizar estimaciones comparativas: comparar cada una de las actividades con actividades similares de otros proyectos. - Usar expertos: al ser personas entrenadas para ello pueden evaluar estimaciones previamente realizadas y dar consejos para el mejoramiento de stas. - Usar datos histricos de prepuestos realizados anteriormente: lo cual puede contribuir a determinar si una estimacin es correcta o si es muy optimista o pesimista. De igual manera, permite evaluar qu tanto la organizacin ha fallado en el presupuesto planeado y el realmente ejecutado generando un porcentaje de varianza que se debe tener en cuenta al realizar la estimacin.

1.2.2.2 Mtodos para la estimacin del presupuesto.

En esencia, la estimacin del presupuesto se refiere a asignar recursos a todas las tareas en las que se dividi un proyecto, la cantidad de recursos que se asignen a cada tarea depende de muchos factores como la dificultad de la misma o el tiempo en que se requiere para realizarla. A continuacin se mencionarn los mtodos ms comunes con los que se estima el presupuesto de un proyecto: Bottom Up En este mtodo, el personal encargado de realizar la estimacin trata de estimar la cantidad de recursos a asignar para cada tarea individual del proyecto con el fin de obtener un presupuesto para todo el proyecto sumando los estimados para cada tarea. El personal encargado de esta estimacin se puede dividir en grupos realizando varias estimaciones que luego sern evaluadas y discutidas por los diferentes grupos y lograr llegar al acuerdo sobre un presupuesto. Top Down Para este mtodo, los gerentes de mayor rango realizan estimaciones de todo el proyecto; luego de realizar estas estimaciones, se asignan los presupuestos a los gerentes de menor rango para que lleven a cabo las estimaciones sobre tareas ms pequeas, pero siempre basndose en la estimacin de nivel superior.

25

 Estimacin por Fases Presenta la combinacin entre Botton Up y Top Down. Como su nombre los indica, la estimacin se puede llevar a cabo en cualquiera de las fases del proyecto: iniciacin, anlisis, desarrollo, haciendo parecerlas como un proyecto individual [Baker, 2003]. 1.2.3 Control del presupuesto del proyecto

Tan importante como la estimacin del costo del proyecto y el calendario del mismo es el control presupuesto del proyecto. A travs del control del presupuesto se puede conocer el estatus del mismo en cualquier momento as como determinar cuando se debe iniciar un plan de contingencia para evitar prdidas y sobre costos.

1.2.3.1 Mtodos para el control del presupuesto En cuanto a los mtodos para el control del presupuesto es posible afirmar que la mayora se basan en la comparacin de lo que se ha gastado hasta el momento con respecto a lo que se encontraba planeado gastar. Estos son los mtodos encontrados para el control de presupuesto: Seguimiento del plan de gastos Este es un mtodo sencillo en el cual se realizan reportes peridicos de los gastos del proyecto, stos son comparados con el presupuesto del proyecto, y lo que debera haberse gastado hasta ese momento. Este mtodo puede ser complementado con la realizacin de grficas del desempeo del proyecto frente a los costos a travs del tiempo; stas grficas pueden mostrar de manera mucho ms clara en qu proporcin los gastos del proyecto son mayores o menores frente al costo estimado en el presupuesto. Anlisis del Valor Ganado Este es un mtodo para estimar el alcance en el tiempo y el desempeo del proyecto, esto mediante una serie de mtricas con las que es posible estimar muchos aspectos tiles del desempeo del proyecto [Mulcahy2002]. En esencia, el anlisis usa tres aspectos desde los cuales se estiman los dems aspectos con los que se mide el proyecto en cuanto a costos. Estos aspectos son: - Cunto trabajo est planeado para desarrollarse en el momento de la aplicacin del mtodo. - Cunto se ha gastado al momento de la aplicacin del mtodo. - El trabajo que se ha realizado hasta el momento. Conociendo estos tres aspectos se procede a estimar las siguientes mtricas mostradas en la tabla 1:

26

ACRNIMO PV EV AC BAC EAC ETC VAC

TERMINO Valor Planeado Valor Ganado Costo Actual Presupuesto Completado Presupuesto a Terminacin Estimacin a la Terminacin Variacin a la Terminacin

INTERPRETACIN Cul es el valor estimado del trabajo planeado a realizar hecho. Cul es el valor estimado del trabajo, actualmente completado Cunto se ha gastado en el momento actual Cunto es el presupuesto para todo el trabajo. Cul es la estimacin del costo del proyecto en el momento actual. Sobre el punto actual del proyecto, cunto ms se espera que se gaste en el proyecto. Cunto por encima o por debajo del presupuesto se espera que termine el proyecto.

Tabla 1. Trminos del anlisis del valor ganado

Ahora que se conocen los significados de los aspectos a evaluar, es necesario conocer las diferentes ecuaciones que involucran los trmicos anteriores (ver Tabla 1) para obtener una estimacin del estado actual de desempeo del proyecto.
NOMBRE Variacin del Costo (CV) Variacin del Calendario (SV) ndice de desempeo del Costo (CPI) ndice de desarrollo del Calendario (SPI) FORMULA EV-AC EV-PV EV/AC EV/PV BAC/CPI Estimado a la Terminacin. (EAC) Nota: Existen diversas formas para calcular EAC AC + ETC INTERPRETACIN NEGATIVO si el costo est por encima del presupuesto - POSITIVO si el costo est por debajo del presupuesto. NEGATIVO si est atrasado segn el calendarioPOSITIVO si est adelantado segn el calendario Obtencin de una parte de una unidad de dinero gastada. Avance porcentual en el proyecto de la tasa de avance originalmente planeada. 1. Cunto se espera que cueste el proyecto en total. 2. Usado si no han ocurrido variaciones en BAC o si se continuar con la misma tasa de gastos. Usado cuando la estimacin original fue errnea 3. Dato actual del presupuesto remanente, usado cuando existen varianzas debido a un fututo atpico. 4. Dato actual ms el remanente del presupuesto modificado por el desempeo. Cunto ms el proyecto costar. Cunto por encima del presupuesto se tendr a la terminacin del proyecto.

AC+BAC-EV AC+(BAC-EV)/CPI

Estimacin a la Terminacin (ETC) Variacin a la Terminacin (VAC)

EAC-AC BAC-EAC

Tabla 2. Formulas del mtodo de valor ganado

1.3 GESTIN DEL RIESGO Se define a la Gestin del riesgo como el conjunto de actividades y prcticas ejecutadas para controlar el riesgo. De igual manera el Riesgo se puede definir como la posibilidad de que algo negativo ocurra [Hulett, Risk Identification Outputs], en pocas palabras un riesgo se convierte, ms adelante, en la incapacidad de alcanzar los objetivos planteados del proyecto. Los riesgos estn conformados por al menos dos componentes: 1) la probabilidad de que un evento negativo ocurra y 2) las consecuencias de su ocurrencia.

27

La gestin del riesgo se encuentra evocada a un logro en especfico: identificar y manejar aspectos de un proyecto en especfico que afecten la entrega oportuna, bajo el presupuesto destinado, de un producto de software que satisfaga los requerimientos acordados [Thayer, 2003]. 1.3.1 Modelos existentes La siguiente tabla muestra la descripcin de los diversos procesos construidos para gestionar los riesgos de un proyecto de software (el proceso puede involucrar diversas metodologas, mtodos y herramientas dentro de sus pasos de gestin de riesgos):

PROCESO

DESCRIPCIN - Estndar que utiliza el conocimiento, herramientas y tcnicas para resolver posibles problemas del proyecto. - Involucra las fases de planteamiento, anlisis de riesgo (cualitativo y cuantitativo), respuesta al riesgo y supervisin y control de los planes de riesgo. - Proporciona una gua compuesta por principios, conceptos y funciones para la toma de decisiones entorno a riesgos que deben ser evaluados continuamente. - Permite tomar decisiones entorno a la gestin de riesgos de un proyecto a lo largo de todas las fases del mismo. - Involucra las fases de planeacin, identificacin, estimacin, evaluacin, planificacin, tratamiento, seguimiento y control y comunicacin. - Establece una norma para el desarrollo de planes de gestin del riesgo constituidos por el uso de formatos. Esta norma no establece tcnicas exactas para ser usadas en los planes de proyecto. - Sugiere que cada organizacin debera desarrollar un conjunto de prcticas y procedimientos destinados a la preparacin y ejecucin de planes gestin del riesgo.

PMBok 2000

SEI - Mtodo Continuos Risk Management

IEEE

Tabla 3. Procesos de gestin de riesgos

Segn [Maniasi, 2005] el modelo de gestin de riesgos ms utilizado en la actualidad contiene los siguientes elementos:

Figura 1. Modelo de gestin de riesgos ms aceptado en la actualidad

28

1.3.2 Elementos de la gestin del riesgo

Debido a que son numerosos los procesos y actividades creadas con el fin de apoyar la gestin de riesgos (adems de las expuestas en la tabla 3 la literatura menciona otras ms) es necesario profundizar en los elementos que apoyan la diversas fases del riesgo.

De esta manera, a continuacin se explica con mayor detalle cada uno de los elementos que involucra la Gestin de riesgos y expuestos en la figura 1. 1.3.2.1 Identificacin del riesgo

[Thayer, 2003]

la define como una aproximacin cuidadosa y organizada de la bsqueda de

los riesgos reales asociados a un sistema. La identificacin de riesgos comprende tambin el descubrimiento, definicin, descripcin y comunicacin de los riesgos antes de que stos se conviertan en un problema que afecte el proyecto [Hulett, 2004]. Tcnicas de identificacin de riesgos Existen diversos mtodos y herramientas enfocados a la captura de riesgos. La informacin obtenida acerca de las tcnicas para la identificacin de riesgos de este trabajo, fue extrada de
[Maniasi, 2005]. Para

efectos del presente trabajo se har slo una mencin especial a la tcnica de

identificacin basada en taxonoma y cuyo concepto general se explica a continuacin: - Identificacin en base a taxonomas Una taxonoma es una forma de clasificar y organizar la informacin acerca de por qu ocurren eventos relevantes. Generalmente las taxonomas surgen de la experiencia obtenida al analizar eventos relevantes y de aprender cmo los factores humanos, materiales, circunstanciales y de entorno contribuyen a su ocurrencia.

La identificacin consiste, entonces, en utilizar una estructura agrupadora de los riesgos de acuerdo a sus diferentes clases como una lista de consulta durante la fase de identificacin de riesgos. Esta lista tiene su fuente originaria [Marvin J. Carr et al.,1993] quien en 1993 desarroll la identificacin de riesgos basado en taxonoma para el SEI1. Estas son algunas generalidades de esta tcnica: a. Son listados de riesgos que se han encontrado en proyectos similares a los que se intenta analizar. b. Se debe validar la aplicabilidad y validez de la informacin presentada en esta tcnica. Es decir, la consideracin de los riesgos planteados en esta tcnica es general y comn a los

SEI: Software Egieneering Institute, 1991.

29

proyectos de desarrollo de software pero puede que la aplicabilidad vare de acuerdo con el tipo de proyecto.

1.3.2.2 Anlisis de riesgo

De acuerdo con [Armstrong, 2004] el siguiente paso despus de la identificacin de los riesgos es priorizar los problemas y crear un perfil de riesgos del proyecto. Un factor crucial para generar una apropiada priorizacin es el nivel de amenaza que un riesgo representa para el proyecto. La combinacin de la probabilidad y el impacto define el nivel de amenaza del riesgo. Probabilidad e impacto de un riesgo Se define la probabilidad como la posibilidad de que un riesgo ocurra. El impacto se entiende como una prdida o efecto negativo obtenido como resultado de la ocurrencia de un riesgo [Esteves, 2004].

- Niveles de probabilidad a. Remoto: >10% b. Improbable: (11 30) % c. Probabilidad media: (31 50)% d. Posible: (51 - 70) % e. Muy probable: (>71%).

- Niveles de impacto: los niveles de impacto considerados para efectos de este trabajo son: Mnimo: 1, Bajo: 2, Medio: 3, Severo: 4, Crtico: 5

Un riesgo con alta probabilidad de ocurrencia y generacin de alto impacto es un riesgo que contiene un alto nivel de amenaza para el proyecto y por tanto debe tener una prioridad alta. La informacin del riesgo, ahora complementada con el nivel de amenaza y prioridad, se representa en una tabla de perfil del riesgo (ver tabla 4). Riesgo R1 R2 R3 R4 R5 Probabilidad Posible Posible Remota Probable Posible Impacto Bajo Crtico Severo Severo Crtico Prioridad Bajo Alto Bajo Alto Alto

Tabla 4. Perfil de riesgos [Armstrong, 2004]

30

A su vez, la informacin de la esta tabla puede ser tratada en un grfico de perfil del riesgo con el fin de ilustrar aquellos que tienen una prioridad alta para la formulacin de planes de riesgo (ver Figura 2).

Figura 2. Grfico de perfil de riesgos [Armstrong, 2004]

Anlisis cualitativo El anlisis cualitativo del riesgo es utilizado para evaluar un nmero amplio de riesgos que son identificados en el proyecto. Est diseado para medir, segn una escala de calificacin, los riesgos del proyecto por parte de miembros pertenecientes a l. Generalmente los rangos de calificacin estn compuestos por los niveles de probabilidad e impacto de cada riesgo. Anlisis cuantitativo El anlisis cuantitativo utiliza las distribuciones de probabilidad para representar la incertidumbre sobre algunos tems del proyecto como lo son: las duraciones de las actividades del calendario [Hulett, 2004] y el costo en la estructura del trabajo del proyecto (Work Break Down Structure).

- Entradas y salidas Las entradas de un anlisis de riesgos son distribuciones de probabilidad de elementos de costos y duraciones de actividades del proyecto [Hulett, 2004] y representan los posibles valores que estos pueden tomar.

Las distribuciones son generadas a partir de los rangos de riesgo para el costo o duracin de las actividades del calendario, en ambos casos es importante obtener los rangos de estimacin compuestos por los valores optimista y pesimista que pueden ser posibles en cada caso.

31

- Tcnicas y herramientas

En general el anlisis cuantitativo de riesgos requiere modelaje, recoleccin de datos y simulacin. Estas son las herramientas utilizadas en cada aspecto:

a. Tcnicas de modelaje: Mtodo del Camino Crtico (Critical Path Model - CPM): Es una herramienta para la administracin del calendario de proyectos. Resulta til a la hora de representar el plan o estrategia del proyecto. Est constituida por cadenas de actividades sucesoras y predecesoras relacionadas que forman, a su vez, los caminos a travs de la red. De esta manera el CPM permite calcular la duracin ms corta para la completitud del proyecto as como la fecha de finalizacin a travs del camino ms largo de la trayectoria.

El camino ms largo a travs de la red es denominado Camino Crtico y cualquier retraso que ste presente implicar, a su vez, un retraso en el proyecto. Sin embargo, aquellas trayectorias que no son crticas no necesariamente retrasaran el proyecto si ocurriera una demora en ellas. El mtodo del Camino Crtico es tradicional y bien aceptado y esencial para desarrollar la lgica del trabajo del proyecto y para administrar diariamente las actividades que incluye.

b.Tcnica de recoleccin de datos Las tcnicas para la recoleccin de datos giran, frecuentemente, entorno a las denominadas entrevistas del riesgo. Las entrevistas del riesgo es un proceso mediante el cual el analista del riesgo se rene con varias personas especializadas en una parte especfica del proyecto con el fin de determinar datos relevantes del proyecto relacionados con el calendario y los costos.

c. Herramientas de simulacin El anlisis cuantitativo del riesgo utiliza comnmente el mtodo de simulacin Monte Carlo para estimar la probabilidad de las fechas y costos de la terminacin total del proyecto.

- Proceso para la estimacin de riesgos en calendario

a. Determinacin del calendario CPM o Lnea Base de la red de actividades del proyecto. Consiste en determinar las actividades o tareas necesarias para satisfacer los requerimientos del proyecto fijando un tiempo de duracin, as como las fechas de inicio y de finalizacin para cada una.

32

Suponiendo un proyecto simple de 8 actividades y una fecha de entrega (Figura 3). Teniendo en cuenta las duraciones (slo das laborales) para cada actividad, si este proyecto est planeado para iniciarse el 7 de enero el CPM muestra que el proyecto tomar 24.5 das y ser completado el da 14 de febrero. Las fechas mostradas en el diagrama son estimadas por el gerente del proyecto.

Figura 3. Red de actividades de un proyecto

b. Rangos de duracin de las actividades

Las duraciones de las actividades que son utilizadas para calcular la ruta crtica son generalmente cantidades de tiempo consideradas como las ms probables para completar el trabajo dado los recursos planeados [Hulett, 2003]. Sin embargo las experiencias en desarrollo de proyectos han demostrado que el trabajo puede tomar mayor tiempo que el adjudicado en el valor ms probable. Por ello la incertidumbre en las duraciones de cada actividad se representa mediante una estimacin de tres puntos donde se definen los valores de tiempo optimista (bajo) y pesimista (alto) que cierta actividad podra tardar.

De esta manera, una vez establecidas las actividades junto con su tiempo de desarrollo miembros del equipo de estimacin deben estimar los rangos de duracin basados en los escenarios de puntos bajos (nivel optimista) y en los escenarios de puntos altos (nivel pesimista) de tiempo de trabajo para la culminacin de estas actividades.

La tabla 5 muestra los valores mximo y mnimo de duracin para las actividades del proyecto de la figura 3:

33

ACTIVIDADES
Anlisis Diseo

BAJO
1 1

MS PROBABLE
2 4,5

ALTO
5 10

Desarrollo Documentacin

7 1

16 2

30 5

TOTAL

10

24,5

40

Tabla 5. Estimacin de tres puntos del calendario

c. Simulacin del Calendario del Proyecto Esta fase se inicia cuando ya han sido determinados los rangos y distribucin de la duracin para cada una de las actividades del proyecto. A partir de esta etapa el anlisis de riesgos en calendario estar en la capacidad de responder a las siguientes preguntas: Qu tan probable es sobrepasar la fecha de completitud del proyecto contemplada para el 26 de marzo? O Es esta fecha la ms probable para la terminacin del proyecto. Si no es as cul sera la fecha ms probable para la completitud del proyecto?.

- Proceso para la estimacin de riesgos en costos a. Los Datos del Riesgo: Lo primero a tener en cuenta en el anlisis de riesgos en costos es la descomposicin de la estructura del trabajo. Es a partir de sta que se comienzan a recolectar los datos de los costos extremos (optimista y pesimista) de cada uno de los elementos ms riesgosos. La recoleccin se realiza a travs de la evaluacin de los lderes de equipo quienes evalan los riesgos adyacentes y propios de sus reas. De manera similar a la estimacin de riesgos en calendario, se debe obtener para cada elemento del WBS el valor mnimo y mximo de los costes que conlleva llevarlos a cabo. La figura 4 muestra los datos de un anlisis para la estimacin de riesgos en costos:
ELEMENTO DEL WBS VALOR PARA EAC BAJO MS ALTO PROBABLE

Figura 4. Datos para la estimacin de riesgos en costos

*EAC (Estimate at Completion): Cul es el costo total esperado del proyecto.

34

b. Simulacin de tres puntos La figura 5 es un ejemplo de la estimacin de tres puntos a partir de cada uno de los elementos del WBS del proyecto: (ejemplo extrado de la fuente [Hulett, Integrated Cost Scheduled
Risk Analysis]):

Figura 5. Rango de costos para cada uno de los elementos del WBS[Hulett, 2004]

Utilizando la estimacin de tres puntos para cada uno de los elementos del WBS se presenta la siguiente simulacin mediante el mtodo Monte Carlo (Figura 6 tomada de [Hulett, 2004]):

Figura 6. Ejemplo simulacin Monte Carlo para costos fuente[Hulett, 2004]

c. Resultados de la simulacin De acuerdo con la figura 6 de la simulacin el costo ms probable es de $28.4 millones de dlares.

35

1.3.2.3 Planificacin del riesgo Comprende el desarrollo y documentacin de estrategias que caracterizarn la Gestin del riesgo. Las estrategias son representadas mediante el desarrollo de planes de de accin tales como: la creacin de un plan de riesgos integrado. De acuerdo con [Marvin J. Carr et al., 1993] el plan para un riesgo especfico puede involucrar alguna de las siguientes actividades:

- Formulacin de un plan de contingencia para mitigar el impacto del riesgo en caso de que

ste llegase a ocurrir.

- Evasin del riesgo mediante la reduccin de su probabilidad y/o las consecuencias de su

ocurrencia. Se pueden asumir cambios en el proceso de desarrollo o diseo del producto de software con el fin de evitar eventos indeseados.
- Aceptacin del riesgo, es decir, prescindir de cualquier tipo de accin para mitigarlo y de esta

manera se asumen las consecuencias en caso de que ste ocurra. - Transferencia: trasladar el riesgo a otra rea de responsabilidad.
- Adquisicin de conocimiento: Consiste en recolectar nueva informacin que permita a los

gerentes de proyecto analizar el riesgo con mayor profundidad y desarrollar planes nuevos de contingencia. Elementos de un plan de riesgo La fuente [Wiegers, 1998] plantea los siguientes elementos para un plan de riesgos: - Identificador del riesgo - Clasificacin del riesgo - Da de reporte - Descripcin del riesgo - Probabilidad - Impacto - Nivel de riesgo - Primer disparador del riesgo. - Respuesta al riesgo <controlar, evitar, minimizar, mitigar el riesgo> - Fecha de inicio de la respuesta al riesgo - Fecha de finalizacin de la respuesta al riesgo. - Estado actual del plan - Plan de contingencia - Disparador del plan de contingencia. Posibles estados de un plan de riesgo De igual manera la lista de los posibles estados de un riesgo es [Maniasi, 2005]:

36

- Abierto: Riesgo aceptado y asignado. - Cancelado: Un riesgo que ha dejado de ser verificado por el proyecto. - Plan Creado: El plan para el riesgo ha sido creado y se encuentra pendiente de aprobacin. - Plan Aprobado: El plan para el riesgo ha sido aprobado y se encuentra en condiciones de ser ejecutado. - Plan Verde: El plan se est ejecutando segn lo planificado. - Plan Amarrillo: El plan se est ejecutando con leves diferencias respecto a lo planificado. - Plan Rojo: El plan se est ejecutando con severas diferencias respecto a lo planificado, seleccionado o definido. - Plan completo: El plan se ha ejecutado por completo y se encuentra pendiente la verificacin de sus resultados. - Completado: El plan ejecutado ha sido verificado y sus resultados se consideran apropiados. - Re-Abierto: El plan ejecutado ha sido verificado y sus resultados no se consideran apropiados por lo cual se solicita una nueva ejecucin del ciclo de vida o proceso del riesgo.

- Completo: luego de Re-Abierto el plan se ha ejecutado, ha sido verificado y sus resultados se

consideran apropiados. 1.3.2.4 Seguimiento del riesgo Una vez identificado el riesgo se debe proseguir con un seguimiento continuo sobre ste y permanecer atento a las seales que indican si se ha convertido en un problema. De igual manera, se debe permanecer atento al estado en que se encuentran las acciones tomadas para minimizarlo. Una herramienta importante de esta fase es el uso adecuado de mtricas que permitan la supervisin de los riesgos y de sus planes de mitigacin.

1.3.2.5 Control del riesgo

Supervisa los planes de accin del riesgo. Tiene la capacidad de mejorar el proceso de gestin del riesgo de acuerdo con los resultados de las mtricas y eventos asociados a los riesgos. Comunicacin

Tal y como lo expresa [Maniasi, 2005] la comunicacin debe estar presente en las diferentes fases del modelo de gestin de costos: entre los diferentes pasos del proceso y a un nivel interno del equipo de proyecto.

37

 Documentacin

La base que sustenta las acciones adoptadas en el proceso de gestin de riesgos. Los planes de accin de un riesgo en cualquiera de las formas expuestas anteriormente (Planificacin del riesgo) deben ser documentados.

1.4 RESULTADOS DEL CAPTULO En este captulo se dieron a conocer los conceptos y definiciones que se sern tiles en la propuesta del modelo y su base terica. De igual manera, se expusieron los procesos y pasos involucrados en las metodologas y mtodos relacionados con la estimacin y gestin de proyectos, as como los modelos ms utilizados en la actualidad concernientes a estos temas. Sin embargo, la revisin bibliogrfica plasmada en este documento es susceptible de ampliarse a nuevas fuentes de estudio teniendo en cuenta que es un rea de constante evolucin.

38

2. PROPUESTA CONCEPTUAL DEL MODELO

Este captulo integra los conceptos y definiciones obtenidos como producto de la revisin bibliogrfica del estado del arte, con un anlisis que va desde evaluaciones comparativas (sobre los diversos mtodos para la estimacin y gestin de proyectos), hasta la recopilacin de algunos estudios estadsticos relacionados con los proyectos de software en Colombia.

Los primeros numerales de esta propuesta conceptual se concentran en la caracterizacin del marco actual que rodea el estado de los proyectos de software en Colombia. Para ello se tuvieron en cuenta los resultados de algunas encuestas sobre gerencia de proyectos llevadas a cabo por la Asociacin Colombiana de Ingenieros de Sistemas [ACIS, 2007]. De igual manera se cont con la realizacin de un pequeo estudio, del cual participaron algunos encargados y gerentes de reas tecnolgicas de distintas empresas de software en Bogot.

Posteriormente se da inicio a la seleccin de los mtodos y metodologas que harn parte del modelo a proponer, utilizando para ello criterios de clasificacin definidos, ya sea en la estimacin del tamao del software como en la gestin de costos y riesgos. En cuanto a la estimacin y costos se muestra una evaluacin comparativa de los mtodos creados para estas dos actividades.

En tanto que para la parte de riesgos se desarroll un anlisis para escoger la tcnica de identificacin ms adecuada teniendo en cuenta los criterios, requisiciones y asunciones de una metodologa para gestin de riesgos, as como los resultados de la caracterizacin de los proyectos de software mencionados con anterioridad.

Por ltimo cabe mencionar que este anlisis es la base fundamental del modelo propuesto ya que de ste se toman los mtodos, procesos y conceptos necesarios para su sustentacin, teniendo en cuenta el marco actual de los proyectos de software.

2.1 CARACTERIZACIN DE PROYECTOS DE TECNOLOGA DE LA INFORMACIN Esta caracterizacin se divide en dos partes. La primera explora el estado de los proyectos de Tecnologa Informtica (TI) en Colombia utilizando como fuente la encuesta anual de gerencia de proyectos de La Asociacin Colombiana de Ingenieros de Sistemas [ACIS, 2007]. La

39

segunda es una aproximacin hacia las reas de estimacin y gestin que desarrollan algunas empresas y reas de tecnologa en Bogot y la cual conforma un aporte de este trabajo. La finalidad de conocer el contexto actual de los proyectos de software es el de conformar un marco comn de datos que permita apoyar algunos conceptos, funciones y procesos del modelo a proponer y cuya definicin se establecer ms adelante.

Por ltimo se expone un estudio que proyecta el estado de las empresas de desarrollo de software en el Reino Unido, tambin con el fin de conocer un contexto an ms globalizado que rodea a las reas de la estimacin y gestin.

2.1.1 Caracterizacin de proyectos de TI en Colombia La V Encuesta Nacional de Gerencia de Proyectos de Tecnologa de la Informacin publicada por [ACIS, 2007] expone las siguientes estadsticas que enmarcan el estado de los proyectos de tecnologa informtica en Colombia: Actividades de un proyecto de TI Las dos principales actividades en las cuales se enfoca los proyectos de TI en Colombia son: - Especificacin de requerimientos (73%) - Integracin de sistemas (53%). Factores de fracaso en proyectos de TI - Mala Planeacin: Como es indicado en [Salinas, 2007] el alto porcentaje de fracaso financiero en proyectos de tecnologa informtica se debe al mal direccionamiento y enfoque de los planes de accin por parte de los involucrados en los proyectos. Por su parte ACIS expone como factor principal para el fracaso en proyectos de TI a la mala planeacin.

- Poca y/o mala comunicacin Los miembros del equipo no se comunican o no se ponen de acuerdo en como hacer las cosas.

- Desempeo en el cronograma La figura 7 representa el desempeo en el cronograma de los proyectos de TI en Colombia.

40

Desempeo en el cronograma de proyectos de TI

Proyectos completados ajustndose al cronograma Proyectos cancelados o abandonados Proyectos completados adelantndose al cronograma Proyectos completados por encima del cronograma

27, 27% 3, 3% 3, 3% 67, 67%

Figura 7. Desempeo en el cronograma de proyectos de TI en Colombia

El alto porcentaje de proyectos completados con xito pero con atraso en el cronograma refleja una deficiencia en los mtodos de planeacin del proyecto as como una posible carencia de estimaciones de riesgos relacionadas con el tema del calendario. Es necesario, por tanto, tratar aquellos riesgos relacionados con la duracin total del desarrollo.

- Desempeo en el presupuesto

La figura 8 representa el desempeo en el presupuesto de los proyectos de TI en Colombia.

Desempeo en el presupuesto de proyectos de TI

Proyectos abandonados Proyectos completados ajustndose al presupuesto Proyectos completados sin exceder presupuesto Proyectos completados con xito por encima del presupuesto

40, 40%

12, 12%

6, 6%

42, 42%

Figura 8. Desempeo en el presupuesto de proyectos de TI en Colombia.

Menos de la mitad de los proyectos en TI que hicieron parte de la encuesta lograron alcanzar con xito la terminacin del proyecto y adems ajustarse al presupuesto. De esta manera, se

41

evidencia la necesidad de llevar a cabo una estimacin de costos realista adems de tener en cuenta los riesgos asociados con el costo de un proyecto de TI. Recomendaciones ACIS basado en la experiencia obtenida durante la fase de investigacin de estas estadsticas, suministra las siguientes recomendaciones dirigidas a los gestores de proyectos de TI en Colombia:

- Valorar la experiencia obtenida durante el proyecto. - Control del cronograma y el presupuesto

2.1.2 Aproximacin a la actualidad de las empresas y reas de tecnologa colombianas Mediante la aplicacin de una encuesta sobre gestin de proyectos (ver Anexo D) a un total de cinco personas, entre encargados y directivos de reas de tecnologa de empresas de software de Bogot, se logr obtener una aproximacin de algunos procesos, que relacionados con los temas de estimacin de software y gestin de costos y riesgos, se desarrollan actualmente al interior de nuestras empresas, estos son algunos de ellos:

2.1.2.1 Qu se est usando en la actualidad para estimacin del esfuerzo y tamao del software? Las empresas o reas de tecnologa comnmente utilizan el proceso representado en la figura 9 para la estimacin del esfuerzo y tamao. Generalmente de este proceso hacen parte los gerentes, ingenieros y usuarios finales del producto. A partir del mdulo de administracin de requerimientos, el gerente establece una gua (basndose en el producto, tipo de proyecto, tipo de desarrollo) de los promedios totales de esfuerzo y tamao para cada fase del proyecto. Posteriormente, cada estimador realiza la estimacin para cada una de las actividades (el gerente estima el esfuerzo de todas las actividades, el usuario estima el esfuerzo de todas las actividades en las que participa, el ingeniero estima el esfuerzo de todas las actividades de las que hace parte activa). Por ltimo se calcula el esfuerzo y el tamao por cada actividad dependiendo del tipo de participante (por ejemplo: Estimacin gerente de proyecto * 0.6 + Estimacin ingeniero * 0.4) y los resultados son discutidos por el grupo tratando de llegar a un consenso.

42

- Producto - Proyecto - Tipo de desarrollo

Modulo de Administracin de requerimientos

Criterios

Clculo de los promedios totales

GUA DE LA
ESTIMACIN

Discusin de resultados y acuerdo.

Clculo del esfuerzo y tamao segn el participante

Estimacin individual: EXPERIENCIA

Valor del esfuerzo total estimado

- Gerente - Ingeniero - Usuario

Figura 9. Actualidad de la estimacin del esfuerzo y tamao en algunas reas y empresas

2.1.2.2 Qu se est usando en la actualidad para la estimacin de costos? De acuerdo con el valor del esfuerzo estimado el costo se calcula as: Esfuerzo total * valor hora promedio de cualquiera de los recursos listados en la figura 10.
- Hardware - Software - Comunicaciones - Entrenamiento - Logstica

Valor del esfuerzo total estimado

Valor HORA PROMEDIO

Figura 10. Actualidad de la estimacin de costos

2.1.2.3 Qu se est usando en la actualidad para la gestin de riesgos? Las empresas y reas de tecnologa que hicieron parte de esta aproximacin no presentan como tal un proceso especfico para la gestin de riesgos, por tanto, ningn participante que hizo parte de este pequeo estudio respondi a una fuente determinada de manejo de riesgos como la empleada en su empresa. Sin embargo en la mayora de los casos se utilizan formatos que hacen parte del documento de plan de proyecto que acompaan a ste a todo lo largo de su ciclo de vida y en donde cada actualizacin generar una nueva versin del plan. El formato para riesgos de un proyecto contiene de manera comn los siguientes elementos: No (nmero) riesgo, descripcin, fecha de identificacin, nombre de quin lo identific, causas, consecuencias, probabilidad de ocurrencia, severidad de impacto, estado, estrategia de mitigacin, plan de contingencia, responsable, fecha de cierre.

43

2.1.2.4 Qu se puede concluir acerca de esta aproximacin?

A pesar de no contar con metodologas especficas, por ejemplo: puntos de funcin para el caso de la estimacin o COCOMO para los costos, s existen procesos establecidos por cada empresa o rea que apoyan las actividades relacionadas con la gestin de proyectos de software. Sin embargo, en la mayora de veces dichos procesos hasta ahora se estn instaurando y por tanto su mejoramiento puede tardarse.

Con respecto a la gestin de costos y riesgos no se logr evidenciar un proceso como tal dentro de todas las empresas consultadas: nicamente para el rea de riesgos se est desarrollando una parte especfica dentro del plan del proyecto pero slo involucrando una descripcin general de los elementos que lo componen (id del riesgo, estado, plan de contingencia, etc.).

Finalmente es posible establecer, con base en el estudio realizado por [ACIS, 2007], la necesidad inmediata de instaurar procesos con actividades y recursos contundentes en las empresas y reas de tecnologa. Los resultados expuestos por la encuesta anual de gerencia de proyectos y la aproximacin realizada por este trabajo son equivalentes en varios aspectos:

- Los sobrecostos pueden obedecer a la carencia de un proceso para el manejo del presupuesto a lo largo del proyecto. - El incumplimiento de las fechas de entrega del proyecto tienen como origen la falta de una debida estimacin y control de calendario. - El hecho de que hasta ahora se estn instaurando estos procesos en las empresas y reas tecnolgicas supone una falta de experiencia que hasta el momento no ha podido ser documentada y deja al gerentes de proyecto sin un recurso valioso a la hora de estimar y gestionar proyectos de software.

2.1.3 Generalidades de las empresas de desarrollo en el Reino Unido Los datos relacionados en esta seccin proyectan el estado de las empresas desarrolladoras de software en el Reino Unido. La razn por la cual son citados en este trabajo tiene que ver con el hecho de contar con otros contextos que permitan encontrar similitudes y nuevos aspectos que complementen la caracterizacin de gestin de proyectos nacional. Las siguientes estadsticas fueron recolectadas de reportes generados por Standish Group compaa que public los resultados acerca de un estudio desarrollado sobre diferentes empresas desarrolladoras de software en el Reino Unido.

44

 Desempeo en proyectos de TI Proyecto abandonados: - En el ao 1995: 53% - En el ao 1999: 46% - En el ao 2003: 51% Proyectos terminados con problemas: - En el ao 1995: 31% - En el ao 1999: 28% - En el ao 2003: 15% Proyectos terminados con xito: - En el ao 1995: 16% - En el ao 1999: 26% - En el ao 2003: 34% Las estadsticas de las principales causas de fracaso en proyectos de TI segn el Standish Group son: - Sobrecostos: En promedio el sobrecosto en el que incurren grandes compaas en sus proyectos de TI es del 178%, mientras que para las medianas y las pequeas es del 182% y 214% respectivamente. - Atraso en el cronograma: En promedio el atraso en cronograma en el que incurren grandes compaas en sus proyectos de TI es del 230%, mientras que para las medianas y las pequeas es del 202% y 239% respectivamente.

Como fue mencionado en la parte introductoria del captulo, es importante resaltar este estudio debido a que puede llegar a reflejar similitudes, en algunos aspectos, con el contexto de los proyectos de software en Colombia permitiendo evidenciar otros no contemplados en los estudios y estadsticas nacionales. En este caso, problemas como el sobrecosto y el atraso en el cronograma son comunes a ambos contextos, lo cual sugiere la necesidad inmediata de una fase de planeacin adecuada que soporte la mayora de los proyectos de software que son emprendidos en Colombia y en otros pases. 2.2 PLANTEAMIENTO DEL MODELO PARA LA ESTIMACIN DEL TAMAO Esta seccin contiene un anlisis comparativo sobre las diversas metodologas para la estimacin del tamao del software con el fin de proponer las bases del modelo a desarrollar en el captulo siguiente.

45

2.2.1 Evaluacin de mtodos para la estimacin del tamao del software Con el fin de proponer un modelo para la estimacin del tamao basado en las metodologas ya expuestas para ello, se presenta la siguiente tabla en donde se evalan las virtudes y defectos de cada una permitiendo la escogencia adecuada del mtodo que ser utilizado en el modelo propuesto:
METODO DESCRIPCIN
Este mtodo toma las lneas de cdigo necesarias para la construccin de un sistema como medida de su tamao.

VENTAJA
-Se basa en el producto del desarrollo de software. -Fcil Conteo

DESVENTAJA
-Dependiente del lenguaje de programacin. - Dependiente de los programadores. - Estimacin difcil en etapas tempranas del desarrollo.

Conteo de Lneas de Cdigo

Estimacin basada en la estadstica

Este mtodo divide, el sistema en componentes, para as realizar estimaciones sobre cada componente por analoga con otros componentes ya realizados, luego obtienen una estimacin pesimista, media y optimista.

-Disminuye la incertidumbre, dividiendo el sistema en componentes. -Se basa en un proceso estadstico, que ofrece un grado de seguridad. -El grado de confiabilidad de las estimaciones se hace mejor a medida que se realicen ms estimaciones. -Si no se cuenta con datos histricos, las estimaciones sern poco confiables. -El mtodo requiere un tiempo para converger en buenas estimaciones.

Estimacin Por Lgica Difusa

Este mtodo se basa en estimacin por analoga, ya que se toma informacin histrica del tamao de diferentes proyectos, y se realizan categoras de tamao en las que se encasillan los proyectos, luego el nuevo proyecto se encasilla en una de estas categoras, lo cual da un aproximado del tamao del proyecto. Se basa en la funcionalidad del sistema. Para realizar su estimacin se deben determinar los componentes de puntos de funcin para el sistema y clasificarlos segn su dificultad.

-Depende de la informacin histrica, de otros proyectos. -Es un mtodo sencillo de aplicar. -Da un rango del tamao del software, lo que no se compromete del todo con un tamao exacto - El proyecto estimado posiblemente no est en el rango especificado, lo que podra resultar en una estimacin muy alejada de la realidad. Requiere un tiempo de convergencia. Es posible que no se encuentren todos los componentes necesarios, lo que dara una estimacin equivocada. No es muy adecuado para cuando el software se encuentra construido.

Estimacin Por Puntos de Funcin

-Al depender de la funcionalidad del sistema, su aplicacin se puede realizar desde la definicin de los requerimientos del sistema. -Es Independiente del Lenguaje. -Fcil Utilizacin.

Tabla 6. Evaluacin de los mtodos para estimacin del tamao del software

2.2.2 Mtodo escogido para la estimacin del tamao del software De acuerdo con los aspectos expuestos en la tabla 6 y considerando el estado del arte de la estimacin de proyectos de software, es posible afirmar que las metodologas son muy variadas y su uso, mas que depender de lo que ofrecen, depende del entorno y la organizacin que quiera implementarlo, as como los procesos de la misma y el mtodo de desarrollo de software que se utilice.

46

De igual manera se aprecia que las tcnicas suelen ser muy sencillas, debido a que solo requieren de una persona para obtener la informacin del tamao. Sin embargo, se dejan de lado muchos aspectos importantes que deben ser considerados en la estimacin, otros mtodos utilizan la funcionalidad del software, por ejemplo, para implantar una debida estimacin. Pensando en la funcionalidad del software y en la facilidad que los puntos de funcin pueden aportar a las actividades de estimacin del tamao, este ltimo aspecto tambin importante porque atribuye la sencillez o simplicidad que una pequea empresa de desarrollo necesita de este tipo de procesos, los puntos de funcin constituyen el mtodo seleccionado para llevar a cabo la fase de estimacin del modelo a proponer. 2.2.3 Por qu se escogi este mtodo? La caracterstica principal por la que se escogi este mtodo fue la flexibilidad que presenta para ser utilizado en etapas tempranas del desarrollo del software, en donde no es mucho lo que se sabe con respecto a las caractersticas del proyecto: esta metodologa se basa en la funcionalidad del sistema a implementar y no en el producto a crear.

El mtodo puede ser utilizado en diversas etapas del proyecto, a medida que aumente el conocimiento acerca del proyecto tambin aumentar la calidad de las estimaciones, hacindolas cada vez ms acercadas a la realidad. Otra caracterstica destacable del anlisis de puntos de funcin, es su dependencia del lenguaje, esto debido a que se basa en la funcionalidad, lo que hace que esta metodologa sea ideal para cualquier tipo de sistema. 2.2.4 Esquema del mtodo de Puntos de funcin Para estimar el tamao de software por puntos de funcin, se deben encontrar algunos elementos como las salidas y entradas del sistema y bases de datos/archivos en donde se guarda la informacin. Posteriormente se debe encontrar la dificultad de cada componente. Finalmente mediante la aplicacin de una serie de formulas sencillas se obtiene el nmero total de puntos de funcin que componen el software. 2.3 PLANTEAMIENTO DEL MODELO PARA LA ESTIMACIN DE COSTOS DEL PROYECTO Esta seccin contiene un anlisis comparativo sobre las diversas metodologas para la estimacin del costo del proyecto con el fin de proponer las bases del modelo a desarrollar en el prximo captulo. Cabe resaltar en este punto los pasos considerados para realizar una buena estimacin de costos:

47

- Estimacin del Costo del Proyecto. - Estimacin del Presupuesto del Proyecto. - Control del Presupuesto del Proyecto.

Tambin sera conveniente recordar que para estimar el costo de un proyecto se debe conocer el tamao del mismo, por lo cual primero se debe estimar el tamao del proyecto. 2.3.1 Evaluacin de mtodos y modelos para la estimacin de costos En este campo se encontraron diversas metodologas para la estimacin de costos del software a construir. A continuacin se muestra una tabla mostrando las fortalezas y debilidades de cada una las metodologas que descritas en el captulo del estado del arte:
METODOLOGA DESCRIPCIN VENTAJAS NO ALGORTMICOS
Si se cuenta con buena informacin histrica de proyectos pasados, se pueden obtener estimaciones bastante acertadas. Las estimaciones son sencillas de realizar La estimacin se realiza de una manera muy sencilla. Es muy probable que se gane el proyecto.

DESVENTAJAS
Se requiere informacin histrica de proyectos para realizar la estimacin. Para que el mtodo sea efectivo se requiere ajustar el mtodo con informacin de la organizacin que realiza el proyecto.

Costos por Analoga

El costo del proyecto se estima en base al costo de proyectos similares ya realizados.

Precio a Ganar

Se ajusta el precio del proyecto, para mejorar la propuesta ms econmica realizada, con el fin de ganar el proyecto.

La estimacin muy seguramente est mal, y el costo real estar muy alejado de la realidad. Puede ocasionar que el proyecto lleve a perdidas. Predisposicin por parte del equipo de gestin ante la utilizacin de frmulas matemticas. Es un proceso extenso para completar la estimacin Algunos factores son algo complicados de determinar. Predisposicin por parte del equipo de gestin ante la utilizacin de frmulas matemticas. Es un proceso algo largo, para completar la estimacin

MTODOS ALGORTMICOS
Modelo emprico para la estimacin del esfuerzo y costo del desarrollo de un sistema de software, se basa en el uso de multiplicadores de esfuerzo, para realizar una estimacin del esfuerzo y costo Involucra varios factores que inciden en el costo del proyecto. No requiere en principio el uso de datos de proyectos anteriores. Permite su utilizacin a lo largo de todo el proyecto.

COCOMO

SLIM

Se basa en la distribucin de poder hombre, se usa la ecuacin de software, en donde se relaciona, el tiempo de entrega, factores ambientales, en los cuales se refleja la capacidad de desarrollo de la compaa

Usa factores del proyecto y producto, para realizar la estimacin, estos factores inciden en el costo del proyecto.

Tabla 7. Evaluacin de los mtodos para la estimacin de costos

De acuerdo con la tabla 7 se evidencia un amplio rango de metodologa para la estimacin del costo, y cada uno con caractersticas diferentes, que los hacen aplicables en diferentes entornos.

48

Existen metodologas basadas en la experiencia de los gerentes de proyectos, algunas un poco menos elaboradas, lo que intentan es ganar un contrato en cambio de realizar una estimacin seria. De igual manera existen metodologas ms complicadas que utilizan modelos empricos y

matemticos para estimar el costo de un software, evaluando a su vez, una serie de factores concernientes al tamao del software, a la organizacin, experiencia en esta clase de proyectos, etc. 2.3.2 Modelo escogido para la estimacin de costos En el caso de la estimacin de costos se escogi como metodologa COCOMO II, aunque esta es un tanto complicada, debido a la utilizacin de varias formulas que estiman el costo de un proyecto, cuenta con la ventaja de usar para su estimacin un amplio dominio de factores que inciden sobre el costo del proyecto, tales como: retrasos en el cronograma, prdida de personal, etc. 2.3.3 Esquema del modelo COCOMO II El modelo se divide en 3 submodelos dependiendo del conocimiento del proyecto, es decir si no se conoce mucho acerca del proyecto, para una estimacin inicial se usara el modelo de composicin de aplicaciones , en una etapa ms avanzada del proyecto, se podra utilizar el modelo de diseo anticipado, y en el momento que se encuentren diseada la arquitectura del proyecto, se podra utilizar el modelo de postarquitectura, estos modelos aumentan en complejidad a medida que se avanza las diferentes fases del proyecto, es decir el modelo de composicin de aplicaciones es mucho ms sencillo que el de diseo anticipado y postarquitectura, de igual manera las calidad de las estimaciones aumenta cuando se usan mtodos mas complicados. Para este modelo se usar el modelo de diseo anticipado, ya que es un modelo adecuado para realizar estimaciones en las que se tienen en cuenta varios parmetros que inciden en gran parte en el costo de un proyecto, y a su vez disminuye la dificultad para realizar estas estimaciones, adicionalmente se desarrollarn plantillas para la realizacin estas estimaciones, con lo que se disminuir en gran medida la dificultad en la aplicacin del mtodo. 2.4 PLANTEAMIENTO DEL MODELO PARA LA ESTIMACIN DEL PRESUPUESTO Esta seccin contiene un anlisis comparativo sobre las diversas metodologas para la estimacin del presupuesto del proyecto con el fin de proponer las bases del modelo a desarrollar en el captulo 3.

49

2.4.1 Evaluacin de mtodos para la estimacin del presupuesto De acuerdo con [Boehm, 1999] la estimacin del presupuesto depende de muchos aspectos relevantes a cada organizacin, a cada proyecto y tipo de proyecto a realizar, lo cual hace que mas que existir metodologas para estas estimaciones, existen consejos de sobre qu aspectos evaluar al momento de realizar esta estimacin.

Para efectos de este trabajo no se usar ninguna tcnica para estimar el presupuesto del proyecto, ya que la estimacin del costo del proyecto, se hace en base a la divisin del trabajo propuesta en la fase de requerimientos, es decir la estimacin del costo del proyecto, se realiza para cada uno de los requerimientos definidos, lo cual se toma como el presupuesto para el proyecto lo cual facilita el uso del modelo para los usuarios del mismo. A continuacin se presentar una evaluacin de estas formas en las que se realiza la estimacin del presupuesto.
METODOLOGA Bottom Up En DESCRIPCIN este mtodo, las VENTAJAS Al ser estimaciones al nivel de tarea, se tiene menor riesgo en estimar el presupuesto de todo el proyecto errnea. mtodo una Las estimaciones pueden ser realizadas por varias personas simultneamente, dependiendo divisin propuesta. del de la Al depender la estimacin de todo el presupuesto de una estimacin global, es mucho ms factible que la estimacin de todas las tareas en conjunto sea errnea. de manera DESVENTAJAS Requiere de un mayor tiempo de estimacin, ya que para cada tarea se debe realizan un

estimaciones se realizan al nivel de tareas, cada tarea se estiman los

aspectos del presupuesto necesarios Top Down En este

estimacin de presupuesto

persona encargada de las estimaciones, realiza la estimacin para todo el proyecto, y basndose en esta estimacin se

trabajo

realizan las estimaciones para las diferentes tareas. Estimacin por Fases En este mtodo se las hacen

Como

ventaja

este

Como desventaja se tiene que al no realizar un estimacin clara del total del proyecto, nunca se conoce en realidad cuanto es el costo del proyecto, lo que no es muy

estimaciones

mtodo provee, que las estimaciones se realizan en un momento en el que se sabe que se va estimar, y se tienen informacin de las fases anteriores para mejorar la

segn la fase del proyecto en que se encuentre, y a medida que el proyecto avanza se realizan las estimaciones de las otras fases, se puede utilizar una combinacin de los mtodos anteriores para realizar estimaciones. estas

conveniente al realizar un contrato.

estimacin.

Las estimaciones no son tan grandes, por lo que solo se estima una fase del proyecto a la vez.

Tabla 8. Evaluacin de mtodos para la estimacin del presupuesto de un proyecto

50

2.4.2 Mtodo escogido para la estimacin del presupuesto El mtodo seleccionado es Bottom Up ya que se estima el costo de implementar cada requerimiento, antes de obtener un estimativo para el proyecto completo. Lo cual es pertinente para el modelo propuesto teniendo en cuenta que una de las bases las que parte es asumiendo una especificacin de requerimientos establecida. De igual manera, suministra un apoyo importante para las pequeas empresas de software teniendo en cuenta que una de sus principales actividades (ver seccin 2.1) consiste en la especificacin de requerimientos y de esta manera se podra garantizar aun ms su cumplimiento dentro de su presupuesto estipulado. 2.5 PLANTEAMIENTO DE UNA METODOLOGA PARA EL CONTROL DEL PRESUPUESTO Esta seccin contiene un anlisis comparativo sobre las diversas metodologas para la estimacin del presupuesto del proyecto con el fin de proponer las bases del modelo a desarrollar en el captulo siguiente. En cuanto a las metodologas para el control del presupuesto stas tienen como base la comparacin de lo transcurrido con lo planeado. Al usar estas comparaciones se puede determinar el progreso de un proyecto, y qu tan bien se ha desempeado el desarrollo del mismo. Las diferencias entre los mtodos estudiados para el control del presupuesto residen en el nivel de detalle con el que realizan las comparaciones, en el caso del primer mtodo se compara el presupuesto total del proyecto con lo gastado a la fecha del proyecto y para el segundo mtodo, se realiza por actividad propuesta del proyecto una comparacin que incluye adems de lo gastado una serie de aspectos adicionales acerca del desempeo que ayuda a los gerentes a tener un mayor control del desempeo del proyecto. 2.5.1 Evaluacin de mtodos para el control del presupuesto Ahora se proceder a realizar la evaluacin de los mtodos ms importantes para el control del presupuesto, y se expondrn las ventajas y desventajas de cada mtodo.

51

METODOLOGA
Seguimiento del Plan de gastos

DESCRIPCIN
En este mtodo se deben tener claro lo que se ha gastado en el desarrollo del proyecto, ya que esto se compara con lo que deba haber gastado, en el momento de realizar la comparacin, dos valores con se usar,

VENTAJAS
Es un mtodo fcil de ya que slo el de dos

DESVENTAJAS
Al solo proveer una mtrica acerca del

requiere conocimiento

desempeo en cuanto costos del proyecto, hay mucha ms informacin relevante analizada. que no es

valores. Adicionalmente es fcil de entender ya que la informacin que provee es clara, y puede incluir la funcionalidad de agregar una grfica con el desempeo del proyecto en costos.

estos

La

grfica no

de es

este muy

obtiene una medida que indica si se est

mtodo

adecuada para proyectos grandes, muestra ya que no la

desfasado en costos, o si est acorde con el

toda

proyecto, o si por el contrario se ha gastado ms de lo planeado. Anlisis Ganado del Valor Este mtodo intenta Ofrece diversas mtricas para la evaluacin del desempeo en cuanto a los costos del proyecto. Estas mtricas evalan mltiples aspectos del proyecto, que dan un mayor control sobre el proyecto

informacin requerida.

Predisposicin por parte del equipo de gestin ante la utilizacin de frmulas matemticas.

evaluar varios factores de desempeo en cuento al costo del proyecto, esto lo hace mediante diversas mtricas que

bsicamente compararn lo invertido en el

proyecto con lo gastado en el mismo.

Tabla 9. Evaluacin de las metodologas para el control del presupuesto

De acuerdo con la tabla 9 la diferencia entre los mtodos anteriores se encuentra en el nivel de detalle de stos, y la decisin de escoger uno u otro para un proyecto depende del tamao del mismo, ya que para un proyecto pequeo el primer mtodo es ideal, al no ser complicado y podra dar una buena visin del desempeo del mismo, en cuanto al segundo mtodo es ideal para proyectos ms grandes, en donde se requiere un mayor control del desempeo del proyecto. 2.5.2 Mtodo escogido para el control del Presupuesto Para el caso del control del presupuesto fue seleccionado el mtodo de anlisis del valor ganado, ya que incluye una evaluacin mucho ms profunda acerca del desempeo de un proyecto, y aunque no es la metodologa para el control de costos ms fcil de usar, no es complicada del todo, adems de ofrecer excelentes resultados.

Su operacin consiste en la evaluacin de una serie de mtricas a partir de lo que se ha invertido en el proyecto y lo que se haba planeado invertir, con estos datos se puede obtener informacin

52

muy valiosa, la cual permite a los gerentes de proyecto tener una visin clara acerca del proyecto. 2.6 PLANTEAMIENTO DEL MODELO DE GESTIN DE RIESGOS Con base en la literatura estudiada se plante una metodologa de gestin de riesgos (Figura 13), enseguida se explican las razones por las cuales esta metodologa fue la planteada para la propuesta de este modelo. 2.6.1 Principios bsicos en los cuales debera basarse una metodologa de gestin de riesgos Un primer criterio utilizado para la seleccin de la metodologa los constituy el grupo de principios bsicos en los cuales se debe basar la metodologa de gestin de riesgos. La figura 11 muestra algunos de los principios fundamentales sobre los cuales debera basarse un proceso de gestin de riesgos de acuerdo con la propuesta de [Microsoft, 2002]:
Administracin de riesgos de manera proactiva a travs de todas la fases del proyecto, ya que los cambios efectuados en cualquiera de ellas, implican cambios a nivel de riesgo tambin. El proceso de gestin de riesgos debe ser responsabilidad de todos los miembros del equipo. De igual manera cada uno debe asumir la responsabilidad de las tareas especficas que le son asignadas.

Agilidad

Participacin necesaria

PRINCIPIOS BSICOS DE LA GESTIN DE RIESGOS

Reconocimiento de la necesidad de gestionar

Reconocer el hecho de que cualquier proyecto de desarrollo de software se encuentra amenazado por algn o varios riesgos.

Potenciar la comunicacin

Generar los espacios suficientes para discutir de forma abierta los riesgos y de tal manera crear la oportunidad para que los miembros del equipo participen en las diferentes tareas relacionadas con los riesgos.

Figura 11. Principios bsicos de un proceso de gestin de riesgos

2.6.2 Requisiciones de una metodologa de gestin de riesgos El segundo criterio determinante para la seleccin de la metodologa los constituy el grupo de requisiciones que debe cumplir una metodologa de gestin de riesgos. Segn [Motorola LMPS, 1999] a nivel organizacional una poltica de gestin de riesgos debera considerar por lo menos los siguientes aspectos:

53

REQUISICIONES PARA UNA METODOLOGA DE GESTIN DE RIESGOS

Todos los riesgos relacionados con los proyectos de desarrollo deben ser identificados, analizados priorizados y revisados siguiendo un plan de gestin de riesgos. Como consecuencia de los constantes cambios, la lista de los riesgos y la informacin relacionada con su estado actual e historia reciente , deben ser mantenidos en una Base de Datos de Riesgos de Proyecto separada. La informacin contenida en la Base de Datos de Riesgos debe ser utilizada para acrecentar la informacin contenida en una Base de Datos de Riesgos Organizacional.

Figura 12. Requisiciones para una metodologa de gestin de riesgos

Con base en los principios bsicos y los requerimientos de una metodologa de riesgos (Figuras 11 y 12) se plante la siguiente metodologa para la gestin de riesgos:

Preparacin para la Gestin

Aprendizaje
Control de repuesta al riesgo Identificacin del riesgo

Comunicacin

Respuesta al riesgo

Cuantificar y cualificar los riesgos

Figura 13. Metodologa de gestin de riesgos para el modelo

2.6.3 Por qu se escogi esta metodologa? Una de las razones fundamentales es que cubre la totalidad de las fases que en las que se desarrollan los mtodos de gestin de riesgos en la actualidad (ver Figura 1). De acuerdo con las requisiciones para una metodologa de riesgos cabe resaltar la necesidad de aprendizaje que todo el proceso puede y debe generar entorno a la identificacin y manejo de los riesgos. De esta manera, la base de datos de los riesgos puede convertirse en una base de aprendizaje de riesgos en donde se recopilen aspectos relacionados con su estado.

54

 De acuerdo con la caracterizacin de los proyectos de TI en Colombia realizada en este trabajo, es clara la necesidad de mantener una comunicacin abierta entre los miembros del equipo de proyecto. La comunicacin se debe generar tambin en esta parte de gestin de riesgos y no slo en las fases del modelo de desarrollo establecido. 2.6.4 Fases o pasos de la metodologa La descripcin de las fases y de las actividades que se desarrollan en la metodologa para la gestin de riesgos seleccionada se menciona a continuacin. 2.6.4.1 Fase de Preparacin para la gestin de riesgos La preparacin se propone una como una fase previa a la identificacin con el fin de limitar el marco de las fuentes y categoras de los riesgos. Por tanto esta fase se concentra en el reconocimiento de las fuentes, productoras de los posibles riesgos del proyecto, as como las categoras a las que los riesgos, ms adelante identificados, se podran asociar. Identificacin de Fuentes de riesgo: Las fuentes de riesgo son reas comunes donde los riesgos suelen originarse [Maniasi, 2003]. La importancia de identificar tempranamente las fuentes de riesgos radica en encontrar un mecanismo de evaluacin, que de manera eventual, permitir observar los cambios producidos a travs del tiempo en el entorno donde se desarrolla el proyecto. Es decir, puede que una fuente de riesgo sea eliminada debido a cambios estructurales en la organizacin o empresa donde el proyecto tiene lugar por tanto dicha fuente ya no ser productora de riesgos en el proyecto y de manera recproca el riesgo podra desaparecer. Uno de los estudios desarrollados en este trabajo encontr que las fuentes ms comunes de riesgos en los proyectos de desarrollo de software son los mostrados en la figura 14:

Fuentes de riesgos

Estimaciones errneas

Requerimientos inciertos

Tecnologa no disponible

Capacidad incierta de proveedores

Asignacin irrealista de recursos

Figura 14. Fuentes de riesgos del modelo

55

Este modelo, con el fin de definir un marco especfico de fuentes de riesgos para todos los tipos de proyectos de software, se acoge a esta lista de fuentes de riesgos basada en la investigacin desarrollada por [Maniasi, 2005] para su tesis de magster. Identificacin de categoras del riesgo: surgen con el objetivo de agrupar los riesgos que ms adelante van a ser identificados. Las categoras del riesgo del proyecto deben ser clarificadas al inicio de la gestin con el fin de caracterizar diferentes marcos comunes en dnde cada riesgo ser clasificado: por tal razn hace parte de la fase de preparacin de la metodologa planteada. La categorizacin de los riesgos permitir generar una bsqueda apropiada de aquellos que puedan tener mayores consecuencias sobre el logro de las metas del proyecto [Maniasi, 2005].

El modelo establece tres categoras del riesgo como un mecanismo para clasificar y organizar los riesgos pensando en la futura fase de identificacin (Figura 15)
Los problemas ms comunes [ESII, 2001] en proyectos se dan por variaciones en: Presupuesto Personal Planificacin Recursos

Riesgos de proyectos

Riesgos tcnicos Riesgos de negocio

Los problemas ms comunes en riesgos tcnicos son [ESII, 2001]: De Diseo De Implementacin De Interfaz De Verificacin y mantenimiento Clientes y requisitos.

Categoras del riesgo

Las clases de riesgo de negocio son [ESII, 2001]: De Mercado Estratgico De Comercializacin De Direccin De presupuesto

Figura 15. Categoras relacionadas con la identificacin de riesgos en proyectos de software.

A continuacin se da una breve descripcin de cada una de las categoras: - Riesgos de proyecto: Inherentes al plan de proyecto. Para el modelo se consideran dos especficamente: a. Riesgos en calendario: eventos que generan retrasos en la terminacin de actividades y tambin, pueden generar retraso en la terminacin del proyecto. b. Riesgos en costos: Son los riesgos asociados con la capacidad del proyecto de mantener el costo del ciclo de vida planeado.

56

- Riesgos tcnicos: son aquellos aspectos o eventos asociados con la definicin del alcance del proyecto que podran afectar el nivel actual de funcionalidad del sistema con respecto a la misin requerida y el anlisis de requerimientos documentado. - Riesgos de negocio: Riesgos que afectan la viabilidad de negocio del software desarrollado. 2.6.4.2 Fase de identificacin del riesgo De acuerdo con [Maniasi, 2005] quizs el aspecto ms importante en la etapa de identificacin sea el hecho de capturar tantos riesgos como sea posible; de esta manera, pensando en la definicin de una tcnica para identificacin de riesgos conforme a este criterio, se desarroll un breve estudio comparativo de los diversos tipos de tcnicas para la identificacin de riesgos, expuestos en el estado del arte. La Tabla 10 enuncia las ventajas y desventajas de cada una de las tcnicas tratadas:
TCNICA VENTAJA - Al ser un mtodo no estructurado permite evidenciar posibles riesgos de cualquier fuente y descripcin. Lluvia de ideas - El planteamiento de un suceso o hecho como un posible riesgo puede ser discutido desde diversos puntos de vista y experiencias expuestas por loe miembros del equipo. - Permite prever no slo la descripcin de posibles riesgos sino su comportamiento a partir de la experiencia obtenida en proyectos similares lo cual puede servir como un punto de referencia para los manejadores del riesgo o gerentes de proyecto. - Es posible obtener una gran variedad de opiniones sin tener la necesidad de organizar una reunin donde, seguramente, no todos los participantes convocados podrn estar presentes. DESVENTAJA - Puede que para el momento de la reunin no se cuente con personas relacionadas con el tema o con posibles expertos que posean la experiencia sobre las implicaciones y marco del proyecto.

Experiencia y conocimiento documentado

- No todas las organizaciones cuentan con una documentacin especfica o base de datos de los riesgos y su manejo en otros proyectos similares.

Encuestas

- Generalmente las personas suelen tener poco inters en contestar una encuesta lo cual puede generar respuestas inapropiadas. - La evaluacin de las respuestas puede tornarse difcil por su carcter subjetivo. Carece de una clasificacin del dominio de los riesgos siendo ste todava muy extenso para tenerlos todos en cuenta en la fase de identificacin.

- Permite obtener un amplio rango de riesgos permitiendo destacar tambin aquellas reas que requieran de mayor atencin por parte del equipo de proyecto. - En la fase de identificacin estimula el pensamiento sobre los inconvenientes que se pueden producir en la diferentes reas del proyecto [Microsoft, 2002]. - Permite que riesgos similares puedan agruparse aligerando la complejidad [Microsoft, 2002]. - Permite utilizar un terminologa unificada que el equipo de proyecto puede utilizar para supervisar y notificar el estado de los riesgos [Microsoft, 2002].

Taxonomas

Tabla 10. Comparacin de las tcnicas para la identificacin de riesgos

Por otro lado, se declaran ciertas asunciones sobre las cuales debe estar basado un mtodo para la identificacin de riesgos [Marvin J. Carr et al., 2003]:

57

Repetible y estructurado: con el fin de alcanzar una gestin consistente del riesgo. Cubrimiento de todas las reas clave del proyecto El nmero de riesgos identificados no debe ser un factor usado para predecir el xito o fracaso del proyecto.

Asunciones bsicas de una tcnica para la identificacin de riesgos

Figura 16. Asunciones bsicas de un mtodo para la identificacin de riesgos.

Seleccin de la tcnica de identificacin basada en taxonomas Tanto las asunciones bsicas con las que debe contar una tcnica de identificacin de riesgos y el estudio comparativo mostrado en la tabla 10 constituyeron los criterios clave para seleccionar la tcnica de identificacin basada en taxonomas como la que apoyar la fase de identificacin de este modelo propuesto. Asimismo era evidente la necesidad de implantar una metodologa que permitiera reconocer un amplio rango de riesgos. Es necesario, por tanto, ampliar la informacin referente a esta tcnica. A continuacin se exponen los aspectos y conceptos ms importantes de sta. Identificacin de riesgos basada en taxonoma Fue desarrollado en primera instancia por el SEI [Marvin J. Carr et al.., 1993] agrupando diferentes fuentes y categoras de riesgos comunes proyecto de desarrollo de software. La taxonoma agrupa los riesgos en tres niveles: - Primer Nivel: Clases a. Ingeniera del producto: comprende aquellos riesgos relacionados con el aspecto tcnico del proyecto. b. Entorno de desarrollo: riesgos relacionados con los mtodos, herramientas y procedimientos a ser usados en el producto de software (ver Glosario). c. Restricciones del programa: riesgos asociados con los factores organizacionales, operacionales y contractuales dentro de los cuales se va a desarrollar el software.

- Segundo nivel: Elementos Cada uno de las clases mencionadas anteriormente contiene una lista de elementos en las cuales se concentra el trabajo del desarrollo del software. Los elementos correspondiente a cada clase son expuestos y explicados de acuerdo con la fuente [Marvin J. Carr et al., 1993].

58

- Tercer nivel: Atributos Cada una de los elementos posee una lista de atributos relacionados que permite identificar la aplicabilidad del riesgo segn el elemento de acuerdo con un cuestionario (Cuestionario basado en taxonoma [Marvin J. Carr et al., 1993]). De esta manera se presentan preguntas que puede que no sean relevantes para un tipo de proyecto, en particular, lo cual permite a los identificadores aceptar o no el riesgo dentro del proceso de gestin.

Figura 17. Taxonoma de riesgos de proyectos de software [Marvin J. Carr et al., 1993]

De acuerdo con la figura 17 el modelo puede contar con una base de riesgos que son producto de un estudio sobre diferentes proyectos de desarrollo de software [Marvin J. Carr et al., 1993]. Delimitacin del dominio Una de las desventajas de la tcnica para identificacin de riesgos basada en taxonoma la constituye precisamente el extenso dominio de los riesgos que se pueden reconocer, puede resultar complejo realizar el anlisis por cada elemento de las clases y aun ms responder el cuestionario establecido por cada uno de los atributos que constituyen los elementos. Cmo delimitar el dominio de los riesgos? Este modelo propone la delimitacin del dominio de los riesgos correspondiendo la definicin de cada clase de la tcnica basada en taxonomas con la base estadstica recolectada gracias al estudio sobre el estado de los proyectos de TI en Colombia desarrollado en este trabajo. De qu manera intervienen los requerimientos funcionales en esta fase de identificacin? Al constituir la base del trabajo es necesario profundizar en los posibles riesgos que se pueden generar entorno a ellos. A pesar de partir de una clara especificacin de requerimientos, estos

59

constituyen una de las actividades en las que ms se fundamentan los proyectos de desarrollo y por ende deben recibir el tratamiento que en cuestin de gestin de riesgos corresponde. La delimitacin del modelo se muestra en detalle en el capitulo 4 del modelo propuesto Categorizacin de los riesgos identificados

Este trabajo propone tambin un grupo definido de categoras como resultado del estudio efectuado en el estado del arte. Conforme a las tres categoras establecidas (fase de preparacin para la gestin del riesgo) el conjunto de los riesgos identificados se unir a cualquiera de las tres atendiendo a la definicin con la que cada categora cuenta (seccin de preparacin para el riesgo). De esta manera, la categorizacin, propuesta en este modelo, con base a los riesgos identificados se ilustra en la figura 18:
En esta categora deben clasificar los riesgos relacionados con problemas en: presupuesto, personal, planificacin, recursos.

RIESGOS DE PROYECTOS

CATEGORAS

RIESGOS TCNICOS

En esta categora debe clasificar los riesgos relacionados con problemas en: diseo, implementacin, interfaz, verificacin, mantenimiento, clientes y requisitos.

RIESGOS DE NEGOCIO

En esta categora debe clasificar los riesgos relacionados con problemas en: mercado, estrategia, comercializacin, presupuesto de mercadeo.

Figura 18. Categorizacin de riesgos identificados

El resultado de la identificacin del riesgo

Con el fin de facilitar el entendimiento y comunicacin de los riesgos es necesario recopilar la informacin ms importante por cada riesgo identificado del proyecto como resultado de esta fase de identificacin del modelo. El siguiente captulo especfica un formulario de informacin destinado para este fin.

2.6.4.3 Cuantificar y cualificar los riesgos

Esta fase emplea dos tipos de anlisis para la cuantificacin y cualificacin de riesgos de acuerdo con su categora.

60

Anlisis cuantitavito

Riesgos asociados al proyecto

Cuantificar

Riesgos tcnicos

Anlisis cualitativo

Cualificar

Riesgos de mercado

Figura 19. Tipos de anlisis y categoras del riesgo

De acuerdo con la figura 19 los riesgos categorizados como tcnicos o de mercado sern analizados cualitativamente, mientras que los riesgos asociados a la categora de proyectos sern analizados cuantitativamente. Por qu esta divisin de anlisis para las categoras de riesgos?

De acuerdo con la definicin que en el estado del arte recibe el anlisis cuantitativo, son los riesgos que pueden generar los problemas en calendario, costo/presupuesto, recursos, etc., los que deben cuantificarse a travs de este tipo de anlisis: el calendario a travs de las duraciones de cada una de sus actividades, mientras que el costo/presupuesto mediante la descomposicin de la estructura del trabajo que para el caso de este modelo viene dada por los requerimientos del proyecto. Los riesgos tcnicos y de mercado se cualifican de acuerdo a los criterios y experiencia de personas del equipo de proyecto, quienes se basan en la escala de probabilidad e impacto definida para establecer la prioridad y nivel de amenaza del riesgo. NOTA: Los niveles de prioridad y amenaza de un riesgo tambin son aplicables al anlisis cuantitativo. La diferencia con el mtodo cualitativo es el mtodo a travs del cual se determinan estos niveles. Niveles de prioridad y de amenaza Para mayor simplicidad, el nivel de prioridad de un riesgo basado en la combinacin de su probabilidad e impacto estar definido de acuerdo con el siguiente grfico:

Probabilidad / Impacto Mnimo Bajo Medio Remoto Improbable Media Posible Muy Probable Figura 20. Niveles de prioridad de riesgos

Severo

Crtico

61

- Prioridad alta: cualquiera de las combinaciones dadas entre el siguiente conjunto de duplas (probabilidad-impacto):
Posible Muy probable Media Posible Muy probable Severo Crtico Crtico Crtico Severo

Nivel alto de amenaza

- Prioridad media: Comprende las siguientes combinaciones (probabilidad-impacto):

Media Posible Muy probable Improbable

Medio, Severo Medio Mnimo, Bajo, Medio Crtico

Nivel medio de amenaza

- Prioridad baja: Comprende la siguiente combinacin (probabilidad-impacto):

Remoto Improbable Media Posible Mnimo, bajo, medio, severo, critico Mnimo, bajo, medio, severo Mnimo, bajo Mnimo, bajo

Nivel bajo de amenaza

Proceso de anlisis cuantitativo

- Entradas El anlisis cuantitativo usa como entrada una red de actividades, en el caso de la estimacin de riesgos en calendario, y en la descomposicin de la estructura del trabajo en el caso de los riesgos en costo. La construccin de la red de actividades generalmente se realiza sobre Microsoft Project. El anlisis cuantitativo se basa principalmente en el hecho de que existe una incertidumbre entorno al proyecto que podra ocasionar, por ejemplo, que una actividad dure ms (o menos) tiempo de lo planeado, o costar ms (o menos) dinero que lo presupuestado. Software para el anlisis cuantitativo del modelo El software destinado al anlisis cuantitativo de proyectos, como Monte Carlo en el caso de este modelo, permite definir diferentes distribuciones de probabilidad para las actividades del proyecto y generar simulaciones para poner a prueba el comportamiento del proyecto bajo distintas condiciones.

62

 Proceso de anlisis cualitativo

Como se mencion anteriormente y en el estado del arte el anlisis cualitativo se encuentra diseado para recopilar las evaluaciones individuales o grupales que los miembros del equipo de proyecto realicen sobre los riesgos identificados con base en los niveles de probabilidad e impacto dados. Partiendo de la consideracin de que la falta de comunicacin constituye uno de los factores de fracaso de proyectos de TI en Colombia, resultara poco sensato reunir a todos los miembros del equipo para que en una sola sesin se llegue a un acuerdo sobre la priorizacin de los riesgos. Por tal razn para este proceso el modelo plantea la utilizacin del mtodo Wideband Delphi [Wiegers, 1998] como lo muestra la Figura 21.

Figura 21. Propuesta de reuniones del tipo Wideband Delphi para la cualificar los riesgos

2.6.4.4 Respuesta al riesgo

Comprende la formulacin de planes de accin (planes de riesgo) para responder a los riesgos en alta prioridad y otros analizados en la fase de cuantificacin y cualificacin. Este modelo puede emplear cualquiera de las formas de expuestas en la fase de planificacin del riesgo con el fin de crear planes que mitiguen el impacto del riesgo. Plan de riesgo De acuerdo con lo expuesto en la fase de planificacin del estado del arte los planes de riesgo son estrategias que involucran acciones y otros conceptos para hacer frente al riesgo. De

acuerdo con la informacin recolectada acerca de los elementos de un plan de riesgos el modelo define la siguiente lista para su propuesta:

63

- Elementos que debe contener el plan de riesgos del modelo

a. Nombre del riesgo: nombre que identifica como nico al riesgo. b. Categora: nombre de la categora a la cual fue asociado el riesgo identificado. c. Descripcin: breve caracterizacin del riesgo d. Fuente: nombre del indicador que seala que el riesgo puede ocurrir en cualquier momento. Se refiere a la misma definicin de fuente de riesgo otorgada en la fase de preparacin de la metodologa. e. Tipo de plan de riesgo: el tipo de plan de accin como estrategia para hacer frente al riesgo puede ser cualquiera de las formas que puede tener un plan de riesgo y que se exponen en el estado del arte. Los posibles planes de riesgo son: <plan de contingencia, evitar, aceptar, transferencia, adquisicin de conocimiento> f. Estado del plan de riesgo: lista de posibles estados de un plan de riesgo segn la fuente [Maniasi, 2005] y los cuales se exponen en la fase de respuesta al riesgo del estado del arte. g. Fecha de inicio del plan de riesgo: fecha en la que comenz a implementarse el plan de riesgo h. Fecha mxima para finalizacin del plan de riesgo: fecha para la cual el plan de riesgo ya debe estar implementado. i. Responsable del plan de riesgo: persona encargada de ejecutar el plan de riesgo. j. Acciones del plan de riesgo: acciones a llevar a cabo para lidiar con los problemas que surgiran en caso de que el riesgo se convierta en un problema. Proceso de respuesta al riesgo En este punto es importante resaltar la importancia de recolectar en una base de conocimiento del proyecto los riesgos junto con sus planes de riesgo, que como resultado de la fase de cuantificacin y cualificacin, fueron evaluados como de alta prioridad o alto nivel de amenaza.
RIESGOS ALTA PRIORIDAD

FORMULACIN DE PLANES DE RIESGO

RIESGOS PRIORIDAD MEDIA

Formulario de plan de riesgo de la metodologa

RIESGOS PRIORIDAD BAJA BASE DE APRENDIZAJE DE RIESGOS

Figura 22. Proceso de respuesta al riesgo

64

2.6.4.5 Control y seguimiento al riesgo

Esta fase del modelo supervisar la respuesta al riesgo es decir los planes de riesgo implementados. Para este fin la metodologa se apoyar sobre los siguientes conceptos:

- Estado del plan de riesgos tal y como lo presenta [Maniasi, 2005]. - Mtricas obtenidas desde la estimacin de costos. - Estado de la fuente o disparador del riesgo. Luego de verificar la respuesta al riesgo la metodologa estar en la capacidad de decidir si el plan de riesgo requiere revisiones o ajustes.

Proceso de control y seguimiento

FUENTES DE RIESGOS

VERIFICACIN Y CONTROL DEL PLAN DE RIESGO

AJUSTES Y REVISIN DE PLANES SI APLICA

ESTADO PLAN DE RIESGO

MTRICAS

Figura 23. Proceso de control de respuesta al riesgo.

2.7 Resultados del captulo En este captulo se definieron los mtodos, metodologas y herramientas que fueron seleccionadas para ser usadas en cada uno de los pasos del modelo propuesto tanto para la estimacin del tamao como para la gestin de costos y riesgos. Para ello se evaluaron cada una de estas metodologas o herramientas enumerando sus ventajas y desventajas a travs de las siguientes tablas: evaluacin de los mtodos para la estimacin del tamao del software (tabla 6), evaluacin de los mtodos para la estimacin de costos (tabla 7), evaluacin de los mtodos para la estimacin del presupuesto del proyecto (tabla 8), evaluacin de metodologas para el control del presupuesto (tabla 9) y se realiz un nfasis especial sobre la gestin de riesgos y la comparacin de las tcnicas para la identificacin de los mismos (tabla 10). As fue posible establecer los principios, requisiciones y asunciones bsicas para una metodologa de gestin de riesgos (figuras: 11, 12 ,16). Por ltimo se definieron las fuentes y categoras de los riesgos que establece el modelo (figuras: 14 y 5).

65

3. MODELO PARA LA ESTIMACIN Y GESTIN DE PROYECTOS

Este captulo expone cada uno de los pasos planteados por el modelo para llevar a cabo los procesos de estimacin y gestin de costos y riesgos, basndose para ello en las metodologas, herramientas y mtodos, seleccionados en la propuesta conceptual, tras la evaluacin de sus ventajas y desventajas y teniendo en cuenta los criterios de clasificacin especificados.

De igual manera el Anexo B contiene un caso prctico en donde se documenta el desarrollo y resultados de la aplicacin experimental de este modelo.

A continuacin se explican los pasos que contempla el modelo. Dando a conocer por cada uno sus entradas, salidas, procesos y actores que los integran

Requerimientos funcionales

Estimacin del tamao

Tamao en puntos de funcin

Formulario de estimacin del tamao Estimacin del costo y presupuesto Formulario de estimacin de

Control del presupuesto

Duracin total del proyecto

Costo total por requerimiento

Plan de control de riesgos.

Gestin de riesgos Figura 24. Pasos del modelo propuesto

Con base en la figura 24, los primeros tres pasos (Estimacin de tamao, esfuerzo y costo) son secuenciales y cada uno se explica con ms detalle a continuacin. La gestin de riesgos puede iniciarse de manera paralela a los tres primeros pasos. Sin embargo, es importante destacar, que utiliza los datos obtenidos de la estimacin de costos para llevar a cabo un anlisis cuantitativo de riesgo en costo (Figura 24). De igual manera, puede utilizar algunas mtricas del proceso de gestin del presupuesto para supervisar los planes de riesgo (Figura 23: control de respuesta al

66

riesgo). Con el fin de atribuir una mayor simplicidad al modelo, la metodologa de gestin de riesgos propuesta se implementar como un paso posterior a la de gestin de costos. 3.1 PASO I: DEFINIR LOS REQUERIMIENTOS FUNCIONALES DEL PROYECTO 3.1.1 Proceso de definicin de requerimientos Este proceso comprende desde el conocimiento de los requerimientos funcionales del proyecto hasta su especificacin utilizando la plantilla propuesta por la IEEE2. Especialmente para el caso de estudio donde se muestra la aplicacin prctica del modelo (Anexo B) fue utilizada la plantilla para Especificacin de Requerimientos de Volere3.

La figura 25 especifica con detalle los elementos de este proceso.

Especificacin de los requerimientos funcionales

Descripcin del proyecto y especificacin de requerimientos

Descripcin formal del proyecto

Figura 25. Proceso para la definicin de los requerimientos

ENTRADAS - Descripcin del proyecto. - Especificacin de los requerimientos funcionales utilizando la plantilla de Volere. SALIDAS Descripcin del proyecto y de sus requerimientos funcionales. PROCESOS Descripcin formal del proyecto DESCRIPCIN La especificacin de los requerimientos puede hacerse utilizando la plantilla Volere2.

Tabla 11. Elementos del proceso para la definicin de requerimientos

3.1.2 Descripcin del proyecto y especificacin de los requerimientos Es importante contar con una descripcin detallada del proyecto y las funcionalidades que debe implementar. Para ello es necesario que el proyecto sea descrito de la manera ms clara y completa posible y que se especifiquen los requerimientos que deben ser implementados. Para

IEEE Software Requirements Specification Template. Pgina consultada [Mayo 2005]. Disponible en Internet: <http:// www.computing.dcu.ie/~roconnor/modules/ca326/srs_template.doc> 3 Volere Requirements Specification Template. Pgina consultada [Junio 2005]. Disponible en Internet: <http:// http://www.volere.co.uk/template.htm>

67

la especificacin de cada uno de los requerimientos del proyecto se sugiere diligenciar la plantilla propuesta por Volere2. NOTA: La descripcin del proyecto puede ir contenida en la plantilla para la especificacin de los requerimientos, sin embargo, sera conveniente contar con una descripcin global previa a la especificacin. 3.2 PASO II: ESTIMAR EL TAMAO DEL SOFTWARE 3.2.1 Modelo para la estimacin del tamao El siguiente esquema muestra las entradas y salidas que involucra el proceso para la estimacin del tamao del software como segundo paso de este modelo.

Requerimientos Funcionales

Categorizacin determinacin: componentes de Puntos de Funcin

Lista priorizada de los elementos de puntos de funcin

Informacin de entrada Estimacin del tamao por

Clculo del total de puntos de funcin

requerimiento

Figura 26. Esquema del Modelo de estimacin del Tamao

A continuacin se explica de manera ms formal las entradas, salidas y proceso para la estimacin del tamao del software.

Para realizar estas estimaciones se utilizar la metodologa del anlisis de puntos de funcin, y mediante sta se medir el tamao del software a implementar a travs de los componentes funcionales que deba manejar el sistema en desarrollo.

En el caso de este modelo la estimacin del tamao se realizar por requerimiento contribuyendo con una estimacin mucho mas detallada.

Para facilitar la utilizacin de esta parte del modelo se dise un formulario para la estimacin del tamao, el cual ser expuesto en las siguientes secciones.
Volere Requirements Specification Template. Pgina consultada [Junio 2005]. Disponible en Internet: <http:// http://www.volere.co.uk/template.htm>
2

68

3.2.1.1 Entradas del Modelo Especificacin de requerimientos del proyecto: estos son las funcionalidades que el software debe realizar, esta especificacin debe ser lo ms formal con el fin de que las estimaciones realizadas se acerquen a la realidad del proyecto. Informacin de Sistemas Externos: esta informacin hace referencia a toda la informacin del entorno donde funciona el software que se esta planeando, esta informacin consiste en:

Bases de datos que utiliza. Otras fuentes de datos requeridas por el software. Sistemas externos con los que interacta.

3.2.1.2 Salidas del Modelo Tamao del software a implementar para los requerimientos planteados: Este resultado representa la medicin en puntos de funcin del tamao de cada uno de los requerimientos que componen el proyecto al cual se le est aplicando el modelo.

Como ayuda para la aplicacin del modelo de estimacin del tamao se dise el Formulario para la estimacin del tamao con Puntos de Funcin (ver Anexo A) sobre el cual se diligencia la informacin del tamao de cada uno de los requerimientos del proyecto.

Ahora que ya se han mencionado las entradas y salidas del modelo para la estimacin del tamao, se procede a describir el proceso con el cual se estimara el tamao de cada uno de los requerimientos del proyecto en estimacin. 1. Identificar los componentes funcionales necesarios para la estimacin del tamao. 2. Categorizar cada uno de estos componentes para as identificar el peso de cada uno de estos componentes. 3. Calcular el total de puntos de funcin, segn la categorizacin de los elementos funcionales encontrados. Cabe recordar que esta estimacin del tamao se realizara para cada uno de los requerimientos ingresados, por lo cual los pasos anteriores se deben repetir para cada requerimiento, ahora se profundizara en cada uno de estos pasos.

3.2.1.3 Identificar componentes funcionales

La metodologa de puntos de funcin requiere que se identifiquen una seria de componentes funcionales los cuales proporcionan informacin acerca de la complejidad de un sistema de

69

software, para este caso la complejidad de implementar un requerimiento, a continuacin se explican en mas detalle estos componentes. Archivos Lgicos Internos (ILF): Estos componentes representan informacin relacionada lgicamente o reconocida por el usuario que es manejada por la aplicacin, es decir un repositorio de datos manejado por la aplicacin. Archivos de Interfase Externos (ELF): Este componente representa un grupo de datos relacionados lgicamente o informacin de control reconocida por el usuario y referenciada pero mantenida aplicacin. Entradas Externas (EI): Este componente representa un proceso elemental o una accin que procesa datos o informacin de control que vienen desde afuera de la aplicacin hacia adentro, la informacin pude venir desde una pantalla u otro sistema. Salidas Externas (EO): El componente representa un proceso elemental o una accin que enva datos o informacin de control hacia fuera de la aplicacin, en este procedo debe estar involucrado algn tipo de procesamiento lgico sobre los datos de salida, estos elementos pueden ser consultas a bases de datos. Consultas Externas (EQ): Este componente es un proceso elemental o una accin que enva datos o informacin de control hacia fuera la aplicacin, el propsito de esta operacin es presentar datos tal cual se encuentran en la aplicacin, sin ningn procesamiento lgico. por otra aplicacin, es decir repositorios de datos manejados por otra

Los componentes identificados por cada uno de los requerimientos son los que deben ser implementados en el proyecto. Dicha identificacin debe ser diligenciada en el Formulario para la estimacin del tamao con Puntos de Funcin (ver Anexo A), este formulario cuenta con una tabla por cada uno de los componentes de puntos de funcin anteriormente mencionados, en cada tabla se deben nombrar los componentes identificados de cada tipo.

En estas tablas se relacionan los requerimientos que deben ser implementados, esto con el fin de identificar cada uno de los componentes de puntos de funcin por requerimiento. Posteriormente en cada una de las tablas se seala los componentes que se relacionan con cada requerimiento. Luego de relacionar cada componente de puntos de funcin con uno o ms requerimientos se procede a clasificar la dificulta de implementar cada componente.

70

3.2.1.4 Categorizar y definir el peso de cada uno de los componentes Esta tarea se refiere a encontrar la dificultad para implementar cada uno de los componentes identificados de puntos de funcin, al determinar esta dificultad se puede estimar el nmero de puntos de funcin para implementar cada componente.

La dificultad de implementar cada uno de los componentes de puntos de funcin se determina, encontrando el numero de elementos de datos que se maneja en cada uno de estos componentes, los tipos de elementos de datos varan dependiendo del componente, a continuacin se clasifican los componentes de datos por componente, esto clarificara que se debe identificar al evaluar la dificultad de implementacin para cada componente. Archivos Lgicos Internos y Archivos de Interfase Externos: Para estimar la complejidad de estos componentes se deben identificar 2 elementos.

Tipos de elementos de datos (DET): como su nombre lo indica son tipos de datos presentes

en el repositorio, un ejemplo de tipos de datos puede ser una columna de una tabla en una base de datos.

Conjunto de elementos de datos (RET) : este elemento representa conjunto de elementos de

datos relacionados lgicamente que se encuentren en el repositorio de informacin, un ejemplo de esto seria el conjunto de DET que representen una direccin. Entradas Externas, Salidas Externas y Consultas Externas En el caso de estos componentes se deben identificar los siguientes elementos para determinar la complejidad para implementarlos.

Tipos de elementos de datos (DET): al igual que para los anteriores componentes este

elemento representan tipo de datos presentes en el componente, para el caso de los elementos del tipo transaccional como los EI, EO, EQ este elemento representa datos que entran o salen de la aplicacin, como ejemplo de estos elementos se tiene un campo de entrada de texto presente en una interfase grafica.

Tipo de archivo referenciado (FTR): este elemento representa los repositorios de datos que

estn involucrados en el desarrollo de la transaccin del componente, estos repositorios son lo que se identificaron anteriormente, como un ejemplo se puede tomar una transaccin que para obtener datos de una tabla perteneciente a una base de datos, esta tabla seria el FTR a identificar.

71

Luego de que explicar la manera en que se categorizar cada uno de los elementos de puntos de funcin, se debe realizar dicha categorizacin, para esto se prosigue a diligenciar el numero de elementos identificado para cada elemento de puntos de funcin en el Formulario para la estimacin del tamao con Puntos de Funcin (ver Anexo A), esto se realiza diligenciando el numero de elementos de clasificacin para cada componente luego de la seccin de requerimientos.

Los elementos de puntos de funcin son clasificados dependiendo del nmero de elementos identificados para cada uno en 3 categoras Alto, Medio, Bajo, para obtener las categoras a partir del nmero de elementos se deben seguir las siguientes tablas. Archivos Lgicos Internos y Archivos de Interfase Externos: Para identificar la complejidad de estos componentes se sigue esta tabla.

Entradas Externas: En el caso de las Entradas Externas se usa la siguiente tabla para determinar la complejidad de implementacin de estos componentes.

Tabla 12. Determinacin de la dificultad de implementacin para ILF y ELF [Boehm, 1999]

Salidas Externas y Consultas Externas: Para determinar la dificultad de implementacin

Tabla 13. Determinacin de la dificultad de implementacin para EI [Boehm, 1999]

Tabla 14. Determinacin de la dificultad de implementacin para EO y EQ [Boehm, 1999]

Luego de clasificar cada uno de los elementos de puntos de funcin se procede a calcular el total de puntos de funcin por requerimiento.

3.2.1.5 Calcular el total de puntos de funcin. Para esta labor se deben tomar los componentes identificados y categorizados en los numerales anteriores y calcular el total de puntos de funcin para cada requerimiento: este clculo del total de puntos de funcin se realiza mediante una ecuacin en la cual se le da un peso especifico y a

72

cada valor en los que se categoriz cada componente (Alto, Medio, Bajo), para cada elemento se debe multiplicar el peso del componente por el numero de elementos de este tipo y luego sumar este resultado con el valor dado para cada uno de los componentes, y el resultado de estas operaciones es el total de puntos de funcin.

En el caso de este modelo se debe realizar una estimacin por requerimiento, por lo cual se utilizara la ecuacin por requerimiento.

Para facilitar el clculo del total de puntos de funcin, el mtodo de puntos de funcin incluye una tabla en la cual se encapsula la ecuacin necesaria para calcular el total de puntos de funcin, a continuacin se muestra en la siguiente tabla:
Parmetro Ficheros Lgicos Complejidad Alta Media Baja Ficheros Lgicos Externos Entradas Externas (EI) Salidas Externas (EO) Consultas Externas (EQ) Alta Media Baja Alta Media Baja Alta Media Baja Alta Media Baja Peso 15 10 7 10 7 5 6 4 3 7 5 4 6 4 3 Total Puntos Funcin = Suma de Totales Cantidad Total = cantidad * peso

Tabla 15. Clculo del Total de Puntos de Funcin

Cabe recordar que esta tabla debe ser utilizada por requerimiento y para cada requerimiento se debe incluir en la tabla solo los componentes de puntos de funcin relacionados al requerimiento.

Luego que se calcule el total de puntos de funcin para cada requerimiento se procede a diligenciar el colocar estos datos en el formulario de estimacin del tamao, esto se realiza en la parte final del formulario en donde se relaciona cada requerimiento con su tamao.

Luego de realizar la estimacin del tamao con el mtodo de puntos de funcin, se procede a estimar el costo necesario para implantar estos requerimientos.

73

Posteriormente se suma el resultado de cada uno de los tipos de componentes y este es el total de puntos de funcin que se estim. La tabla 16 muestra los elementos que hacen parte de este modelo:
ENTRADAS -Especificacin de los requerimientos funcionales. -Informacin de Sistemas Externos: hace referencia, a toda la informacin del entorno donde funciona el software (bases de datos que utiliza, sistemas externos con los que interacta). El tamao de cada uno de los requerimientos especificados que se desean implementar. SALIDAS PROCESOS ACTORES

Aplicacin del mtodo de puntos funcin. para la estimacin del tamao

Gerente del proyecto, estimadores y el analista de requerimientos

Tabla 16. Elementos del modelo para la estimacin del tamao

3.2.1.6 Formulario que apoya el modelo para la estimacin del tamao

El formulario diseado para este modelo: Formulario para la estimacin del tamao con puntos de funcin (vase Anexo A) permite almacenar la informacin para el clculo de puntos de funcin para cada uno de los requerimientos a estimar. 3.3 PASO III: GESTIONAR LOS COSTOS 3.3.1 Modelo para la gestin de costos Este modelo de gestin de costos ofrece una herramienta sencilla que permite a sus usuarios realizar este proceso sin la necesidad de usar recursos costosos que le consuman mucho tiempo.

Por otro lado, las actividades de estimacin de costos y de presupuesto se realizarn simultneamente debido a que en esta primera se incluye una divisin del trabajo por requerimientos y por tanto la estimacin total, involucrndolos a todos, dar como resultado el presupuesto total para todo el proyecto.

Otra razn importante para unir estos dos pasos consiste en las propias caractersticas del mtodo a utilizar: COCOMO II. Como entrada este mtodo requiere para calcular el costo de un producto de software conocer el costo para la organizacin de una persona/mes, en dicha entrada deben venir especificados todos los factores contemplados en el momento de realizar un presupuesto.

A continuacin se muestra el esquema que sigue el modelo:

74

Tamao de los requerimientos Estimacin de costos del proyecto Costo total del proyecto

Estimacin del presupuesto del proyecto

Presupuesto del proyecto

Presupuesto del proyecto Indicadores de gestin

Control del presupuesto

Figura 27. Esquema del Modelo para la gestin de Costos

Enseguida se explica en detalle cada uno de los pasos contenidos en la figura 27: 3.3.2 Estimacin de costos utilizando COCOMO II Como se mencion en el capitulo anterior la metodologa escogida para realizar la estimacin del costo del proyecto fue COCOMO II, especficamente el modelo de diseo anticipado, debido a que es un modelo que ofrece buena seguridad en la estimacin sin mostrar toda la complejidad del modelo de postarquitectura.

En esta explicacin acerca del mtodo a utilizar para estimar el costo del proyecto, en esta explicacin no se adjuntaran las tablas mediante las cuales se calculan los parmetros necesarios para realizar la estimacin con COCOMO, en el momento que se realice esta estimacin se debe referir al manual de este modelo [Boehm, 1999].

Para aplicar el modelo COCOMO II se deben realizar los siguientes pasos.

3.3.2.1 Estimar los Factores de escala para todo el proyecto. Estos factores solo deben ser estimados una vez para la estimacin de todos los requerimientos, debido a que estos factores son explcitos para la organizacin que construir el software mas no para un requerimiento especifico de la organizacin, estos factores indican si el desempeo que muestra una organizacin ante un proyecto, especficamente si a medida que crece el tamao del software a desarrollar de la misma manera crece el esfuerzo de desarrollarlo, o por el contrario el esfuerzo de desarrollar este software es mucho mayor que el tamao, lo que conlleva a un

75

mayor costo en el proyecto. La estimacin de los factores de costo se realiza utilizando la siguiente ecuacin

En esta ecuacin se deben sumar los valores de cada uno de los 5 factores de escala para aplicarlos a la ecuacin, las constantes presentadas en la misma son resultado de la investigacin emprica realizada al desarrollar el modelo COCOMO, para encontrar el valor y categorizacin que cada uno de estos factores se debe consultar el manual del modelo COCOMO II [Boehm, 1999]. Los resultados de aplicar la ecuacin pueden ser:.

Si el resultado de la ecuacin (B) es >1 el esfuerzo necesitado para completar un proyecto se incrementa en mayor medida que en la que aumenta el tamao del mismo. Si (B) es =1 el esfuerzo necesitado para completar un proyecto se incrementa en la misma medida que el tamao del mismo. Si B es <1 el esfuerzo necesitado para completar un proyecto se incrementa en una menor magnitud que el tamao del mimo.

El valor B es requerido para determinar el esfuerzo y costo del proyecto utilizando por el modelo, por lo que se requiere como entrada para el siguiente paso este valor. La determinacin de B esta apoyada por los factores de escala mostrados en el Formulario para la estimacin de costos (Ver Anexo A). En dicho formulario se diligencia la categora en la que se encuentra cada uno de los factores, facilitando la determinacin de B.

3.3.2.2 Categorizar cada uno de los factores de costo del modelo por requerimiento: de igual manera que los factores de escala se deben determinar los factores de costo, estos factores evalan diversos factores que inciden en el costo del proyecto, estos factores corresponden a factores del producto, factores organizacionales, factores de personal.

A diferencia de los factores de escala, los factores de costo deben ser estimados por requerimiento, debido a que la estimacin de costo se quiere realizar por requerimiento.

Para efectos de esta propuesta el modelo de COCOMO II que se aplicar es el de diseo anticipado. Tal modelo ofrece estimaciones ms precisas sin hacer que la aplicacin del mtodo sea excesivamente complicada.

76

En este paso se determinar la complejidad de cada uno de los factores de costo por requerimiento. Para determinar la complejidad de estos factores se debe entender que significa cada uno de estos factores y que significa el nivel en el cual se categoriza, esta informacin se encuentra en el manual del modelo COCOMO II [Boehm, 1999], la categorizacin de cada uno de los factores de costo se hace en categoras que van desde Muy Bajo hasta Muy Alto, y cada una de estas categoras presenta un valor numrico con el cual se calcula el costo del proyecto.

Para apoyar este paso en la estimacin del costo y presupuesto del proyecto se diseo el formulario COCOMO II Estimacin del Costo el cual se puede encontrar en el anexo B del documento, en dicho formulario se diligencia por requerimiento la categora de cada uno de los factores de costo.

3.3.2.3 Estimar el Presupuesto del Proyecto utilizando la ecuacin de COCOMO: en este paso lo que se espera obtener en primera medida es el esfuerzo que se requiere para completar cada uno de los requerimientos del proyecto, esto se realiza directamente con la ecuacin que presenta el modelo COCOMO para el modelo de diseo anticipado.

Para obtener esta estimacin se deben conocer la variable B que se estimo en el paso anterior, el tamao de cada uno de los requerimientos del proyecto en puntos de funcin, el tamao de los requerimientos se obtuvo anteriormente, y por ultimo se debe conocer el valor para la organizacin de persona/mes dicho, dicho valor es nico para cada organizacin por lo que debe conocer para obtener la estimacin de costos.

Luego de conocer los valores anteriores se procede a utilizar la ecuacin para el modelo de diseo anticipado, esta ecuacin es la siguiente:

Esta ecuacin tiene varios parmetros que deben ser explicados para dar claridad acerca de la utilizacin de este modelo:

PM: esfuerzo necesario para implantar el requerimiento, este valor esta dado en personas/mes

requeridas para completar el proyecto. A: constante determinada empricamente por los creadores del modelo. Size: Tamao del requerimiento a implantar, obtenido anteriormente cuando se estimo el

tamao del requerimiento en estimacin.

77

EM: esta variable representa el valor numrico dado a cada uno de los factores de costo

anteriormente categorizados.

En esta ecuacin se deben multiplicar el valor de cada uno de los 7 factores de costo incluidos en el modelo de diseo anticipado, estos valores se encuentran en el manual del modelo COCOMO II [COCOMO 1999]

En el Formulario para la estimacin de costos (ver Anexo A) se diligencian todos estos valores obtenidos de la estimacin, con el fin facilitar la estimacin y permitir guardar registro de las estimaciones realizadas. 3.3.3 Control de costos y presupuesto Este paso en el modelo de Gestin de costos se realizara el control del presupuesto el cual se estimo en el paso anterior, dicho control se realizara utilizando el mtodo del anlisis del valor ganado, especficamente usando las mtricas relacionadas con el presupuesto, estas mtricas permiten medir el desempeo del proyecto en algn punto del mismo, por ejemplo se puede medir que tanto ha variado el costo del proyecto en contra del presupuesto del mismo. 3.3.3.1 Mtodo para el Control del Presupuesto

El mtodo para realizar esta tarea como ya se menciono el Anlisis del Valor Ganado, este mtodo ofrece una serie de mtricas que permiten conocer varios aspectos sobre el desempeo del proyecto, pero cabe aclarar que en el anlisis del valor ganado no solamente se controla el presupuesto si no el cronograma del mismo, por lo cual las mtricas correspondientes al calendario no sern utilizadas.

Para iniciar la actividad del control del presupuest se deben tener definidas las siguientes variables, desde las cuales se obtendrn las mtricas para el control del presupuesto

Valor Planeado (PV): este parmetro representa el costo del trabajo que se ha realizado hasta

el momento de la aplicacin del mtodo. Earned Value (EV): el parmetro representa el valor estimado del trabajo actualmente

completado. Costo Actual (AC): este ltimo parmetro representa el dinero realmente invertido al

momento actual.

78

Estos parmetros son obtenidos del presupuesto del proyecto o del control de gastos del proyecto, por lo que hace esencial que adems de realizar un buen presupuesto, se lleve a cabo durante todo el proyecto un control de gastos, lo que podr permitir que el control del presupuesto se realice con la mayor calidad.Tambin cabe aclarar que el presupuesto se controlara por cada requerimiento lo que dar informacin en el desempeo de cada requerimiento. A continuacin se explicarn cada una de las mtricas que se deben estimar.

Variacin del Costo (CV): esta mtrica estima en cuanto el proyecto se encuentra por encima

o debajo del presupuesto. ndice de desempeo del costo (CPI): en esta mtrica se obtiene cuanto se gana o se pierde

por cada unidad de dinero invertida en el proyecto. Estimacin a la Terminacin (EAC): para esta mtrica existen varias formula pero en general

lo que intentan estimar es cuanto constara el proyecto en total luego de obtener estas mtricas. Estimacin a la Terminacin (ETC): esta mtrica intenta estimar cuanto mas el proyecto

costara luego del avance alcanzado al momento de utilizar la mtrica. Variacin a la Terminacin (VAC): La mtrica estima cuanto sobre el presupuesto costara

realmente el proyecto.

Luego de aplicar estas mtricas se puede decir que existe claridad acerca, si el proyecto esta teniendo perdidas, si el dinero que se invierte en el mismo obtiene ganancias o perdidas, y de igual manera permite estimar si vale la pena o no terminar un proyecto. Para el caso de este modelo la informacin obtenida estar clasificada por requerimiento, lo que permite entender los requerimientos que obtienen perdidas y ganancias, lo que pude mejorar en gran medida las estimaciones futuras.

De manera resumida se exponen las entradas, salidas, procesos y actores involucrados en los proceso de estimacin y gestin de costos.
ENTRADAS - Estimacin de costos: Tamao de cada requerimiento funcional. Gestin de costos: presupuesto estimado SALIDAS PROCESOS ACTORES

- Presupuesto del proyecto: unin de las estimaciones de costo de cada requerimiento

Aplicacin del mtodo de puntos funcin. para la estimacin del tamao

Gerente del proyecto, estimadores y el analista de requerimientos

Tabla 17. Elementos del modelo para la estimacin y gestin de costos

3.4 PASO IV: GESTIONAR LOS RIESGOS De acuerdo con el diagrama de flujo mostrado en la figura 28, las fases corresponden a cada uno de los pasos de la metodologa para la gestin de riesgos que se propone. Las salidas

79

(componentes en color amarillo representan los formularios de apoyo que suministra la metodologa en algunos de los pasos de la gestin del riesgos).

Preparacin Identificacin y categorizacin

Formulario de riesgos identificados

Anlisis cualitativo

Fase de cuantificacin y priorizacin

Anlisis cuantitativo

Estimacin de riesgos tcnicos y de negocio

Estimacin de riesgos de proyecto

Formularios de apoyo dinmica Wideband Delphi

Formularios para anlisis cuantitativo

Respuesta al riesgo
Formularios de Plan de riesgo

Control de respuesta al riesgo

BASE DE APRENDIZAJE DE RIESGOS

Revisar y ajustar el plan de riesgo

Figura 28. Diagrama de flujo de la metodologa de gestin de riesgos

A continuacin se explican en detalle cada uno de los pasos de esta metodologa: 3.4.1 Prepararse para la gestin Comprende la delimitacin y definicin del marco de las fuentes y categoras del riesgo. Finaliza con la comunicacin del marco de las fuentes y categoras a los miembros del equipo. Ver figura 29.

Conjunto de fuentes de riesgo.

Conjunto de categoras riesgo.

DAR A CONOCER -COMUNICAR

Figura 29. Paso I de la metodologa de gestin de riesgos.

80

3.4.2 Identificar los riesgos y categorizarlos Delimitar e identificar el dominio de posibles riesgos segn la tcnica de identificacin basada en taxonomas. - Delimitacin segn la clase Entorno de desarrollo Reconocer los riesgos asociados con la poca y/o mala comunicacin y los asociados con la planeacin del proyecto dentro del proceso de gestin de riesgos. Mientras que la experiencia del gerente del proyecto, atributo del elemento Proceso de administracin, puede surgir como un riesgo alterno teniendo en cuenta las estadsticas relacionadas con los aos y estudios de los gerentes de proyectos de TI en Colombia. Ver figura 30.

EXPERIENCIA DEL GERENTE

Proceso de administracin

PLANEACIN

Criterios de fracaso
Elemento de la clase Estado de proyectos de TI Atributo

Entorno de trabajo

COMUNICACIN

Figura 30. Delimitacin segn la clase Entorno de desarrollo

- Delimitacin segn la clase Restricciones del programa El estado del desempeo en cronograma y presupuesto de los proyectos de TI en Colombia (secciones 1.1.1 y 1.1.2) justifica el hecho de incorporar los riesgos asociados con el desempeo del proyecto y los recursos en el proceso de gestin del riesgo.

DESEMPEO EN EL PRESUPUESTO

Desempeo proyectos

DESEMPEO EN EL CRONOGRAMA

Estado de proyectos de TI

Recursos

Elementos de la clase Atributo

Recursos

Figura 31. Delimitacin segn la clase Restricciones de programa

81

- Delimitacin del dominio de los riesgos y los requerimientos funcionales del proyecto La especificacin de requerimientos al constituir una de las principales actividades en la cual se enfoca los proyectos de TI debe demandar tambin una mayor atencin en el sentido que la gestin de riesgos asociados a los requerimientos debe ayudar a identificar y controlar aquellos aspectos que pudieran desviar la definicin del producto a desarrollar as como el cumplimiento de los requerimientos establecidos por el cliente. Otro aspecto a considerar, no menos importante que el anterior, es el hecho de que este trabajo establece como punto de partida una buena especificacin de requerimientos (no ambiguos y completos) lo cual conlleva a la necesidad de asegurar un marco en donde stos se puedan implementar de acuerdo con la definicin y las funcionalidades establecidas en la fase de especificacin.

Requerimientos
CARACTERSTICAS DEL ELEMENTO

Estado de proyectos d Elementos de la clase Atributo

Actividades en proyectos de TI Estabilidad Claridad Completitud Validez

Figura 32. Delimitacin segn la clase Ingeniera del producto

La identificacin de un conjunto ms amplio de riesgos es una opcin contemplada dentro de esta propuesta. La delimitacin planteada en esta seccin se construy con el fin de fusionar los objetivos del trabajo con los de la caracterizacin del estado de proyectos de TI en Colombia.

NOTA: Utilizar otras tcnicas y criterios de limitacin del dominio de riesgos si se considera necesario es posible hacer uso de otras tcnicas para la identificacin de riesgos. Para ello, la fuente [Maniasi, 2005] explica las principales de ellas.

3.4.2.1 Categorizar los riesgos identificados La categorizacin con base a los riesgos identificados se ilustra en la figura 33:
Tcnica CATEGORAS Plan de proyecto Negocio

Requerimientos Recursos Entorno de trabajo Proceso de administracin

Otros elementos de la taxonoma

Figura 33. Categorizacin de riesgos identificados

82

3.4.2.2 Dar a conocer el resultado de la identificacin

Con el fin de facilitar el entendimiento y comunicacin de los riesgos el Formulario de riesgos identificados (vase Anexo A) muestra el diseo de un formato que recopilar la informacin ms importante por cada riesgo identificado del proyecto como resultado de esta fase de identificacin de la metodologa. 3.4.3 Cuantificar y cualificar los riesgos

Una vez los riesgos son identificados es necesario medir las consecuencias y probabilidad de ocurrencia. Los riesgos categorizados como tcnico sern tratado bajo un anlisis cualitativo mientras que los de proyecto (calendario y costos) se analizaran cuantitativamente.
3.4.3.1 Anlisis cualitativo Realizar Dinmica variante del mtodo Wideband Delphi para el anlisis cualitativo de riesgos Participantes dinmica variante Wideband Delphi - Coordinador - Miembro del equipo de proyecto Pasos que comprende la dinmica variante Wideband Delphi La figura 34 muestra los pasos de la variante de la dinmica Wideband Delphi propuesta en este modelo. La explicacin de cada uno de los pasos as como los participantes que los desarrollan se muestran a continuacin.

83

Sesin introductoria

Formato de evaluacin de resultados

Sesin para la revisin de resultados

Riesgos descritos y categorizados (Formulario de la sesin introductoria).

Sesin de evaluacin de resultados

Informe de la evaluacin

Sesin para la revisin de la estimacin final

Formato de recordacin de niveles de probabilidad, impacto y prioridad.

Formulario de la estimacin individual Sesin de estimacin individual

Formato de la estimacin final

Figura 34. Dinmica variante Wideband Delphi para la evaluacin de riesgos tcnicos

Paso 1: Sesin introductoria. Incluye la presentacin de los riesgos identificados junto con su categora y descripcin. Para ello el modelo propone la utilizacin del Formulario de la sesin introductoria (vase Anexo A). a. El coordinador presenta a los miembros del equipo los riesgos identificados durante la fase de anterior, su categorizacin y fuente. b. El coordinador explica las razones por la cuales fueron considerados esos riesgos como problemas potenciales para el proyecto. c. El coordinador explica los valores por cada nivel de impacto y probabilidad que se van a manejar.

Paso 2: Sesin de estimacin individual. Cada uno de los participantes realiza, de manera individual, la evaluacin de los riesgos presentados. Puede incluir riesgos adicionales que no hayan sido tenidos en cuenta en la sesin introductoria y que considere como problemas potenciales para el proyecto. (vase A Formulario de la sesin de estimacin individual). a. El participante del equipo realiza su evaluacin de los riesgos otorgndole a cada uno la probabilidad e impacto de acuerdo con los niveles y valores entregados por el coordinador. b. El participante del equipo calcula el nivel de amenaza por cada riesgo.

84

c. El participante clasifica cada riesgo de acuerdo con su prioridad. NOTA: El participante podra agregar riesgos adicionales, junto con su probabilidad e impacto, que no fueron tenidos en cuenta en la sesin introductoria y si lo considera necesario.

Paso3: Evaluacin de resultados. El coordinador evala los resultados de las estimaciones individuales (vase Anexo A Formulario de evaluacin de resultados) utilizando el promedio de los valores de probabilidad e impacto comenzando por los riesgos que fueron evaluados con alto nivel de amenaza.

Discusin: nueva iteracin Riesgo con cierto nivel de amenaza Desviacin estndar baja Revisar valor de la desviacin estndar SI

Analizar valor de la moda

NO Estipular la prioridad del riesgo conforme al nivel de amenaza

Prioridad de riesgo alta: el riesgo requiere un plan de mitigacin de inmediato

Figura 35. Evaluacin de resultados

El coordinador evala los valores de probabilidad e impacto por cada uno de los riesgos, empezando por aquellos que fueron encontrados con un alto nivel de amenaza con el fin de brindarles una mayor prioridad. Si los valores de la desviacin estndar, del promedio de la probabilidad, del impacto o de ambos, es alto, el riesgo debe ser puesto nuevamente en discusin hasta alcanzar un consenso entre los participantes generando una nueva iteracin (alternativamente puede ser usado el valor de la moda para tomar una decisin entorno a la prioridad del riesgo). Si los valores de promedio de probabilidad e impacto no difieren significativamente, se estipula la prioridad del riesgo de acuerdo con el nivel de amenaza con el que cuenta.

NOTA: Si los valores de promedio de la probabilidad o el impacto del riesgo difieren significativamente despus de la tercera iteracin es necesario llevar a un acuerdo las opiniones de los participantes con el fin de alcanzar un nivel de prioridad consensuado.

Paso 4. Sesin para la revisin de la estimacin. El coordinador presenta el informe de la evaluacin (vase Anexo A Formulario de evaluacin de resultados) que contiene:

85

- Los nuevos riesgos junto con sus valores de probabilidad e impacto. - Los riesgos con un valor de desviacin estndar significativo en sus promedios de impacto y/o probabilidad. - El equipo reanuda las estimaciones teniendo en cuenta el informe preparado por el coordinador. - El coordinador prepara el informe final con los resultados de la ltima estimacin.

Paso 5. Sesin para la revisin de la estimacin final. El coordinador presenta los resultados de la ltima estimacin mostrando: - La lista de riesgos priorizados y por tanto, mostrando cules deben contar con mayor prelacin a la hora de formular los planes de riesgo para ello propone la utilizacin del Formulario de revisin de la estimacin final (vase Anexo A). Para este fin el coordinador puede apoyarse en herramientas tales como la grfica de perfil de riesgos ilustrada en la seccin. - El coordinador debe ingresar los riesgos con mayor prioridad a la base de aprendizaje de riesgos del proyecto.

3.4.3.2 Anlisis cuantitativo

Este modelo propone la utilizacin del mtodo cuantitativo para la estimacin de riesgos inherentes al plan de proyecto (categora de calendario y costos). El mtodo cuantitativo permite determinar la probabilidad de que el proyecto vaya a ser finalizado en el perodo de tiempo y el presupuesto planeados.

3.4.3.3 Pasos para el anlisis cuantitativo de riesgos

El modelo propone, para una mayor simplicidad que los pasos sean ejecutados por el gestor o el miembro del equipo que cuenta con la mayor experiencia en proyectos de desarrollo de software. Paso 1: establecer la lnea base de actividades fijadas para satisfacer los requerimientos del proyecto para el caso de riesgo en calendario y la lista de requerimientos para el caso de riesgo en costos (esta ltima obtenida de la parte de estimacin del tamao del software) Paso 2: determinar los rangos de duracin por cada una de las actividades (vase Anexo A Formulario para el anlisis cuantitativo de riesgo en calendario) y costos por cada una de los requerimientos (vase Anexo B Formulario para el anlisis cuantitativo de riesgo en costos). Paso 3: Llevar a cabo la simulacin de tres puntos y mostrar las probabilidades de riesgo de calendario y costos del proyecto.

86

Paso 4: Formulacin de nivel de prioridad y amenaza del riesgo de acuerdo con la probabilidad encontrada y el impacto estimado por el gestor del proyecto. Paso 5: Comunicar el resultado del anlisis al grupo (vase Anexo A Formulario de revisin de la estimacin final). 3.4.4 Responder al riesgo La figura 22 muestra paso a paso la definicin de la fase de respuesta al riesgo para la metodologa propuesta en este modelo.

3.4.4.1 Entradas Las entradas para esta fase estn conformadas por el resultado de los riesgos cualificados y cuantificados (vase Anexo A Formulario De Revisin De La Estimacin Final).

3.4.4.2 Plan de riesgo

Para mayor simplicidad el plan de riesgo debe ser acordado por el gestor del proyecto y uno de los miembros del equipo de proyecto. Se propone el uso de un formulario del modelo que documente algunos elementos del plan de riesgo en un espacio nico (vase Anexo A Formulario de plan de riesgo)

3.4.4.3 Base de aprendizaje de riesgos del proyecto Consiste en un espacio (puede ser un medio magntico) destinado a agrupar los planes de riesgo de aquellos priorizados de manera alta tras la fase de cuantificacin y cualificacin.
Riesgos cualificados y cuantificados

Plan de riesgo

Riesgos con alta prioridad

FIN
BASE DE APRENDIZAJE DE RIESGOS

Figura 36. Respuesta al riesgo del modelo propuesto

87

3.4.4.4 Salidas de la respuesta al riesgo Las salidas para esta fase la conforman el grupo de planes de riesgo algunos de los cuales, dependiendo de la prioridad deben ser enviados a la base de aprendizaje de riesgos del proyecto, es preciso mencionar, adems, que de acuerdo con la categora del riesgo los planes pueden incluir nuevos elementos:

Para el caso del riesgo en costo se pueden especificar las mtricas de control de costos del

modelo (este modelo define ya algunas en la fase de control y seguimiento) mediante las cuales se puede medir el plan de riesgo

Para el riesgo en calendario se deben definir las acciones para reducir la duracin de las

actividades del proyecto y cumplir con la probabilidad mnima de establecida por la gerencia de terminar el proyecto en una fecha dada (corresponde con la mtrica definida para medir el plan de riesgo en calendario). 3.4.5 Fase de control y seguimiento

La figura 37 muestra cmo se debe desarrollar esta fase cuyo enfoque principal apunta a la revisin y supervisin de los planes de riesgo como resultado de la fase de respuesta previa. Para ello se apoya en los elementos ilustrados: FUENTES

Planes de riesgos

EVALUACIN

ESTADO PLAN DE RIESGO

MTRICAS
Figura 37. Control y seguimiento del modelo propuesto

3.4.5.1 Verificacin de plan de riesgo segn las fuentes del riesgo

Tal y como lo ilustra la figura 37: la variacin de las fuentes de riesgos a travs del tiempo mostrada en la fase de preparacin, una fuente puede representar una situacin cambiante en el tiempo. Por tanto es necesario revisar su estado y verificar si an persiste en el entorno del proyecto para lo cual los riesgos asociados a ella persistiran tambin; por el contrario, si fue una situacin que desapareci o fue eliminada del contexto del proyecto sus riesgos asociados pueden ser despreciados tambin.

88

3.4.5.2 Verificacin del plan de riesgo segn el estado del plan La siguiente figura 38 ilustra los estados del plan de riesgo para lo cuales el plan de riesgo requerira de revisin y nuevos ajustes:

PLAN DE RIESGO
Plan rojo
Implica revisin rigurosa y continua del plan de riesgo y la realizacin de ajustes conforme a los resultados de sta. Implica el ejercicio de revisiones breves sobre el plan de riesgo y pequeos ajustes que se vayan requiriendo conforme a stas. Otros planes se han implementado sin arrojar los resultados esperados: ste debe ser, por tanto, revisado continuamente.

Plan amarillo Plan reabierto

Figura 38. Estado de planes de riesgo y revisin

3.4.5.3 Verificacin del plan de riesgo segn mtricas del control de costos y calendario Este modelo plantea las siguientes mtricas basado en la gestin de costos del modelo (ver tabla 18):

Mtrica para riesgo en costo

DVP: desviacin mxima aceptada por encima del VP

Mtrica: AC>DVP

Figura 39. Mtrica para riesgo en costo

Si la mtrica indicara que el costo del proyecto actual (AC) con mayor probabilidad de ocurrir (anlisis a travs del mtodo Monte Carlo) sobrepasa el valor mximo aceptado por encima del valor planeado de costo del proyecto (DVP) el plan de riesgo correspondiente debera ser revisado y ajustado.

89

 Mtrica asociada con el riesgo en calendario Los acrnimos usados para esta mtrica se mencionan en la siguiente tabla: Acrnimo
PTPE

Trmino
Probabilidad esperada de cumplimiento del cronograma en la fecha de terminacin del proyecto.

Explicacin
Cul es la probabilidad mnima esperada de que el proyecto se termine en la fecha de terminacin estipulada? Probabilidad de terminacin del proyecto en una fecha dada (obtenida a travs de la simulacin)

PTP

Probabilidad de la terminacin del proyecto en una fecha

Tabla 18. Acrnimos para la mtrica de riesgo en calendario

Cronograma: X% de probabilidad de xito en la fecha de terminacin.

Mtrica: PTP< PTPE

Figura 40. Mtrica para riesgo en calendario

Si la mtrica indicara que la probabilidad obtenida del cumplimiento del cronograma del proyecto (PTP) en la fecha estipulada para su terminacin, a travs del mtodo Monte Carlo, es menor que la probabilidad mnima esperada (PTPE), el plan de riesgo debe ser supervisado y ajustado en cuanto a sus acciones a seguir. NOTA: El dominio de estas mtricas puede crecer conforme al tipo de proyecto y otras medidas que el gestor de riesgos u otros miembros del equipo de proyecto identifiquen a lo largo del proceso. 3.5 Paso V: Finalizar la gestin Una vez los culmine la fase de gestin del riesgo los resultados de la ejecucin de los pasos modelo materializados en los formularios diligenciados del mismo, deben ser tratados y almacenados en un repositorio de informacin relacionada con la planeacin del proyecto. Los datos que guardan las estimaciones del tamao y de la gestin deben ser revisados continuamente con el fin de determinar si la realidad actual del proyecto coincide con lo plasmado all. 3.6 RESULTADOS DE ESTE CAPTULO En este captulo se obtuvieron los modelos y metodologas definitivas que sustentan el modelo. Los modelos para la estimacin y gestin de costos y la metodologa definida para la gestin de riesgos son obtenidos como resultado del anlisis efectuado en la propuesta conceptual de este trabajo.

90

4. CONCLUSIONES

1. Se logr desarrollar un modelo para la estimacin del tamao del software y la gestin de costos y riesgos de un proyecto de desarrollo tomando como base los requerimientos funcionales del mismo. 2. El modelo propuesto se encuentra fundamentado en la utilizacin de diversas metodologas y tcnicas para la estimacin del tamao y gestin de costos y riesgos de un proyecto de software, extradas como resultado del estudio sobre diversas fuentes de informacin relacionadas con el tema. 3. Se establecieron criterios para la clasificacin de las metodologas encontradas para la estimacin del tamao y gestin de costos y riesgos de un proyecto de desarrollo, llevando a cabo para este fin un marco comparativo entre dichas metodologas. 4. Adicionalmente a la definicin de los criterios fue posible establecer requisiciones y principios bsicos sobre los cuales debe basarse una metodologa de gestin de riesgos y algunas tcnicas involucradas en este mismo proceso. 5. Se establecieron metodologas y tcnicas especficas asociadas con la estimacin del tamao y gestin de costos y riesgos de un proyecto de software que responden a los criterios ya definidos. 6. Las metodologas y tcnicas especificadas con base en los criterios definidos, constituyen la base del modelo propuesto para la estimacin de tamao y gestin de costos y riesgos de un proyecto de desarrollo de software. 7. Es una finalidad del modelo suministrar un marco bsico de metodologas y tcnicas basadas en el uso de herramientas de fcil acceso que faciliten, a su vez, el proceso de estimacin y gestin de costos y riesgos en un proyecto de desarrollo. 8. La aplicacin prctica del modelo a travs de un caso de estudio permiti validar experimentalmente algunos de los pasos que constituyen el mismo, generando una adecuada gestin de costos y riesgos de acuerdo con los criterios especificados. 9. La validacin experimental del modelo present algunas limitaciones como resultado de algunas restricciones de la empresa donde se desarrollo el caso de estudio, por tanto algunos pasos del modelo tuvieron que ser adaptados de acuerdo con otros anteriores que s se lograron aplicar de manera prctica.

91

5. TRABAJOS FUTUROS

1. Implementar una herramienta computacional de apoyo al modelo que incluya todos los pasos propuestos por ste y facilite al usuario el almacenamiento y clculo de los datos en un mismo entorno. 2. Ampliar la aplicacin prctica del modelo en empresas a gran escala, con el fin de obtener nuevos resultados que complementen el caso de estudio presentado en este trabajo y exploren nuevas experiencias con el fin de sugerir mejoramientos a los procesos y conceptos propuestos para la estimacin y gestin de proyectos de software. 3. Complementar el modelo a travs de la propuesta de una metodologa para la estimacin y control de calendario. 4. Se sugiere el desarrollo de un estudio ms profundo acerca del estado de las pymes colombianas con respecto a las reas de estimacin y gestin de proyectos, con el fin de extender la aplicacin del modelo teniendo en cuenta nuevas necesidades y requerimientos de las empresas aparte de las mencionadas e identificadas en este trabajo.

92

BIBLIOGRAFA

[ACIS, 2007]. V Encuesta de gerencia de proyectos. Asociacin colombiana de ingenieros de sistemas, 2007. [Armstrong, 2004]. Managing Software Project Risk. 2004. Tassc-solutions.

[Baker, 2003]. The complete idiot's guide to project management, Project Management, 2003.

[Boehm, 1999]. Cocomo II Model Definition Manual, COCOMO, 1999.

[Boehm 90] Boehm, B. Software Risk Management: Principles and Practices. IEEE Software (January 1990) [Camacho, 2005]. Herramienta Para El Anlisis De Requerimientos Dentro De La Pequea Empresa Desarrolladora De Software En Bogot, Pontificia Universidad Javeriana, Departamento de Ingeniera de Sistemas, Colombia, 2005.

[C. Shi Kuo, 2002]. Handbook of software engineering & knowledge engineering, World Scientific Publishing Co, 2002.

[Esteves, 2004]. Implementacin y Mejora del Mtodo de Gestin Riesgos del SEI en un proyecto universitario de desarrollo de software, Argentina, 2004. [Hulett, Quantitative Risk Analysis Fundamentals]. Quantitative Risk Analysis is Fundamentals, Acquisition Community Connection, Los Angeles, 2003.

[Hulett, Risk Identificaction Outputs]. Risk Identificaction Outputs, Acquisition Community Connection, Los Angeles, 2004.

[Hulett, Schedule Risk Analysis Simplified], Schedule Risk Analysis Simplified, Acquisition Community Connection, Los Angeles, 2003.

[Hulett, Integrated Cost Scheduled Risk Analysis], Integrated Cost Scheduled Risk Analysis, Acquisition Community Connection, Los Angeles, 2003.

[IEEE, 1990], IEEE Standard Glossary for Software Engineering, IEEE-STD-610.12, 1990.

93

[Kirkpatrick, 92] , Kirkpatrick, R. J.; Walker, J. A.; & Firth, R. Software Development Risk Management: An SEI Appraisal, SEI Technical Review, Pittsburgh, Pa.: 1992.

[Labdelaoui, 2001]. Mtodos de Estimacin de Tamao Funcional del Software Aplicados a Enfoques de desarrollo, NASSCOM Conference, India, 2001.

[Longstreet, 2004]. Function Points Analysis Training Course, Longstreet Consulting Inc, 2004.

[Maniasi, 2005]. Identificacin de Riesgos de Proyectos de Software en base a Taxonomas, tesis de Magster, Argentina, 2005.

[Marvin J. Carr et al., 1993]. Taxonomy- Based Risk Identification, Software Engieneering Institute, 1993.

[Microsoft, 2002]. MSF Risk Management Discipline v.1.1., Microsoft Solutions Framework, Seattle 2002.

[Mulcahy2002]. Rita's Course in a Book for Passing the PMP Exam, PMP exam prep, 2002.

[Salinas, 2007]. SALINAS, Andrs. Obstculos en la gestin de proyectos en tecnologas de informacin y comunicacin TICs y posibles soluciones. UPB Bucaramanga. 2007.

[Thayer, 2003]. Software Engineering Project Management, IEEE Computer Society, 2003.

[Wiegers, 1998]. Process Impact, Leadership Resources & consulting, 1998.

94

ANEXOS

FORMULARIOS DEL MODELO

CASO DE ESTUDIO

FORMULARIOS DEL CASO DE ESTUDIO

ENCUESTA SOBRE GESTIN DE PROYECTOS

ESPECIFICACIN DE LOS REQUERIMIENTOS DEL PROYECTO: CASO DE ESTUDIO

95

Anexo A

FORMULARIOS DEL MODELO

Presentacin de los formularios para la estimacin del tamao y gestin de costos y riesgos del modelo propuesto

96

Formulario para la estimacin del tamao con Puntos de Funcin

Requerimientos Archivos que gestionan la aplicacin(ILF)

Requerimiento1 Requerimiento2 Requerimiento3 Requerimienton

Nmero de componentes de datos

RET DET

Dificultad

Requerimientos Archivos de Interfase (ELF)

Requerimiento 1 Requerimiento2 Requerimiento 3 Requerimienton

Nmero de componentes de datos

RET DET

Dificultad

97

Formulario para la estimacin del tamao con Puntos de Funcin

Requerimientos Entradas Externas (EI)

Requerimiento 1 Requerimiento2 Requerimiento 3 Requerimienton

Nmero de componentes de datos

FTR DET

Dificultad

Requerimientos
Salidas Externas (EO)
Requerimiento 1 Requerimiento2 Requerimiento 3 Requerimienton

Nmero de componentes de datos

FTR DET

Dificultad

98

Requerimientos
Consultas Externas (EQ)
Requerimiento 1 Requerimiento2 Requerimiento 3 Requerimienton

Nmero de componentes de datos

FTR DET

Dificultad

Total de Puntos de Funcin

Requerimiento
Requerimiento 1 Requerimiento 2 Requerimiento 3 Requerimiento n Total puntos de funcin del sistema

No Puntos de funcin

99

Formulario para la estimacin de costos

Factores de Escala
Valor Factores de Escala
Precedencia Experiencia de trabajo con sistemas de sw relacionados Flexibilidad de desarrollo Arquitectura / Resolucin de Riesgos Madurez del Proceso

Extra Alto

Alto

Nominal

Bajo

Muy Bajo

100

Estimacin de Costos
Tamao Requerimiento(Puntos de Funcin) Factores de Escala Valor Extra Alto Muy Alto Alto Nominal Bajo Muy Bajo ExtraBajo Extra Alto Muy Alto Alto Nominal Bajo Muy Bajo ExtraBajo Extra Alto Muy Alto Alto Nominal Bajo Muy Bajo ExtraBajo
Requerimiento 1 Requerimiento 2 Requerimiento 3

Req n

Fiabilidad del Producto y Complejidad

Reutilizacin Requerida

Dificultad de la Plataforma

101

Experiencia del Personal

Extra Alto Muy Alto Alto Nominal Bajo Muy Bajo ExtraBajo Extra Alto Muy Alto Alto Nominal Bajo Muy Bajo ExtraBajo Extra Alto Muy Alto Alto Nominal Bajo Muy Bajo ExtraBajo

Facilidades

Planificacin Temporal

Costo Requerimiento $

102

FORMULARIO DE RIESGOS IDENTIFICADOS

FORMULARIO DE RIESGOS IDENTIFICADOS INFORMACIN REQUERIDA DEL RIESGO

Nombre riesgo Fecha Nombre Componente subsistema Fecha y nombre de la persona que report el riesgo. Identifica el subsistema / componente de la descomposicin de la estructura del trabajo (WBS) o proceso en el cual se localiza el riesgo. Identifica a qu categora (Tcnico. Proyecto o negocio) se encuentra asociado el riesgo. Es una breve descripcin del riesgo. Puede ser complementada durante la fase de cuantificacin y priorizacin. Situaciones que hacen parte del entorno del proyecto y a su vez son productoras del riesgo. Determina a quien fue asignada la responsabilidad individual del manejo del riesgo.

DESCRIPCIN DEL RIESGO IDENTIFICADO

Asigna un nombre nico al riesgo.

Categora asociada Descripcin del riesgo

Fuente de riesgo Responsabilidad

103

FORMULARIO DE LA SESIN INTRODUCTORIA

FORMULARIO DE LA SESIN INTRODUCTORIA

Nombre participante: Fecha

No RIESGO

DESCRIPCIN

CATEGORIA

OBSERVACIONES

104

FORMULARIO DE LA SESIN DE ESTIMACIN INDIVIDUAL

FORMULARIO DE LA SESIN DE ESTIMACIN INDIVIDUAL

Nombre participante: Fecha
PROBABILIDAD IMPACTO PRIORIDAD

No RIESGO

DESCRIPCIN

LISTA DE RIESGOS ADICIONALES PROPUESTOS

RIESGO

DESCRIPCIN

CATEGORA

JUSTIFICACIN

105

FORMATO PARA LA RECORDACIN DE NIVELES DE PROBABILIDAD, IMPACTO Y PRIORIDAD

NIVEL DE PROBABILIDAD
Remoto Improbable Probabilidad media Posible Muy Probable

ESCALA
>10% (11 30) % (31 50)% (51 - 70) % (>71%)

ESCALA NIVEL DE IMPACTO

Mnimo Bajo Medio Severo Crtico 1 2 3 4 5

Probabilidad / Impacto Mnimo Remoto Improbable Probabilidad media Posible Muy Probable

Bajo

Medio

Severo

Crtico

106

FORMULARIO DE EVALUACIN DE RESULTADOS

FORMULARIO DE EVALUACIN DE RESULTADOS

Fecha evaluacin

RIESGO

PROMEDIO PROBABILIDAD

DESVIACIN ESTNDAR

MODA

PROMEDIO IMPACTO

DESVIACIN ESTNDAR

MODA

107

FORMULARIO DE REVISIN DE LA ESTIMACIN FINAL

FORMULARIO DE REVISIN DE LA ESTIMACIN FINAL

Fecha:

RIESGO

FUENTE
(Opcional)

CATEGORA

PRIORIDAD

108

FORMULARIO PARA EL ANLISIS CUANTITATIVO DE RIESGO EN CALENDARIO

ANALISIS CUANTITATIVO DE RIESGO EN CALENDARIO

Nombre evaluador: Fecha

ACTIVIDAD

DURACIN MNIMO

DURACIN MS PROBABLE

DURACIN MXIMO

109

FORMULARIO PARA EL ANLISIS CUANTITATIVO DE RIESGO EN COSTOS

ANALISIS CUANTITATIVO DE RIESGO EN COSTO

Nombre: Fecha:

REQUERIMIENTO

COSTO MNIMO

COSTO MS PROBABLE

COSTO MXIMO

110

FORMULARIO DE PLAN DE RIESGO

FORMULARIO DE PLAN DE RIESGO

NOMBRE DEL RIESGO CATEGORA

DESCRIPCIN

FUENTE

TIPO PLAN DE RIESGO

FECHA INICIO DE PLAN

FECHA FINAL DE PLAN

ESTADO DEL PLAN DEL RIESGO

RESPONSABLE

ACCIONES A LLEVAR A CABO

111

Anexo B

B
-

CASO DE ESTUDIO

Descripcin y formalizacin del proyecto de caso de estudio Aplicacin prctica de algunos pasos de la metodologa Formularios utilizados en la aplicacin prctica

112

Descripcin del proyecto y definicin de los requerimientos funcionales

1.1 Descripcin del proyecto

Desarrollo para un ISP (Proveedor de servicios en Internet) con el fin de ampliar la gama de servicios ofrecidos a sus clientes, estos servicios especficamente son la administracin de las direcciones IP de los clientes y sus nombres.

Esta compaa ofrece a sus clientes servicios para la administracin de red los cuales son ofrecidos a travs del portal empresarial de la compaa, este proyecto entra a ser parte del plan de la compaa para aumentar los servicios que ofrece a sus clientes.

Existen dentro de la compaa dos ambientes diferentes que interactan para ofrecer los servicios a los clientes, por un lado el portal empresarial que se encuentra construido sobre .net y por otro el rea de ingeniera que maneja las configuraciones de servicios de red elaboradas en Linux lo que ha hecho necesario la implantacin de un puente para que los ambientes se comuniquen, dicho puente lo constituyen los servicios web que hacen transparente la interaccin entre ambas partes.

Este proyecto se encargara de ofrecer servicios web al portal empresarial, para que los clientes de la compaa puedan manejar los nombres asignados en el DNS a sus direcciones ip, y modificarlos segn lo necesiten.

En el momento de planear este proyecto se pens que para su implementacin lo ms conveniente era desarrollar componentes genricos que pudieran ser extendidos con nuevos servicios, esto con el fin de disminuir el tiempo de implantacin de estos.

Adicionalmente al los servicios de informacin relacionados con las direcciones Ip, se desarroll uno para la consulta de los logs que genera la aplicacin, este servicio es utilizado por los encargados del soporte de la aplicacin, para determinar cuando el sistema a falla o hay problema en la misma.

113

Las funcionalidades implementadas para este proyecto se exponen en el siguiente diagrama de Casos de uso.

Figura 1. Diagrama de casos de uso del proyecto

Los usuarios de este proyecto son: el portal empresarial de la compaa y otros sistemas que consultan las Ips de los clientes.

1.2 Especificacin de los requerimientos funcionales

A continuacin se listan los requerimientos funcionales a implementar: 1. Un cliente podr consultar las direcciones IP que tenga disponibles. 2. El sistema debe generar las direcciones IP disponibles de un cliente de acuerdo con su plan de pago. 3. Un cliente podr cambiar el nombre de su direccin IP 4. Un cliente podr eliminar el nombre de su direccin IP 5. El sistema deber notificar al cliente el nmero de cada una de las direcciones IP que tenga adscritas. 6. El sistema deber verificar la existencia de una direccin IP de un cliente. 7. El administrador del sistema podr consultar los logs de la aplicacin. El Anexo E muestra la especificacin formal de los requerimientos listados anteriormente siguiendo la plantilla de Volare.

114

Estimar el tamao del software

Como se describi en la propuesta conceptual del modelo la estimacin del tamao para este caso de estudio se necesita tener en cuenta los requerimientos funcionales del proyecto y la informacin relevante del sistema para realizar la estimacin por puntos de funcin, dichos requisitos fueron cumplidos por lo cual basndose en los requerimientos especificados se realizar esta estimacin. Los datos del Formulario para la estimacin de puntos de funcin se muestran en el Anexo C.

2.1 Resultado del modelo para la estimacin del tamao Luego de realizacin de todo el proceso de estimacin del Tamao se obtiene como resultado 116 puntos de funcin, valor bastante cercano al total al tamao del software que se implement. Para observar los detalles relacionados con la obtencin de este valor vase Anexo C Formulario para la estimacin del tamao con puntos de funcin.

Gestionar los costos

Para la realizacin de este proceso de gestin de costos se deben seguir los pasos descritos en la definicin del modelo. Debido a la ausencia de informacin histrica suficiente relacionada con los costos invertidos en los recursos del proyecto es posible afirmar que este hecho represent una limitacin en esta fase de aplicacin prctica del modelo. Sin embargo, s fue posible llevar a cabo una debida estimacin de costos (vase Anexo C Formulario para la estimacin de costos).

Cabe recordar que para poder gestionar los costos de un proyecto primero se debe contar con la estimacin del tamao del software a gestionar. Para este caso, la estimacin se obtuvo el tamao del software necesario para implementar los requerimientos especificados en este caso de estudio.

115

Gestionar los riesgos

De acuerdo con lo que se ilustra en la figura 36 se documentan algunos de los pasos de la metodologa de gestin de riesgos conforme al caso de estudio especificado. Algunos otros fueron adaptados de acuerdo con los resultados obtenidos en pasos anteriores. Las razones por las cuales se acudi a la adaptacin del caso de estudio por ejemplo en el diligenciamiento de algunos formularios sern expuestas en el momento en su momento.

1. Prepararse para la gestin 1.1 Fuentes de riesgo El dominio de las fuentes as como de las categoras planteadas por el modelo fueron acogidas por el gestor del proyecto.

2. Identificar y categorizar los riesgos En el Anexo C Formulario de riesgos identificados se exponen los elementos de uno de los riesgos identificado en el proyecto y categorizado como tcnico.

3. Cualificar y cuantificar los riesgos 3.1 Anlisis cualitativo Se realiz el anlisis cualitativo al riesgo tcnico 3.1.1 Desarrollo de la dinmica variante del Mtodo Wideband Delphi Se presenta el formulario de evaluacin de resultados que contiene la evaluacin individual del riesgo tcnico obtenido en una de las iteraciones de la dinmica (vase Anexo C Formulario de evaluacin de resultados).

116

4. Cuantificacin y priorizacin

4.1 Estimacin de riesgo en calendario

4.1.1 Determinacin de la lnea base de actividades del proyecto. La figura muestra el cronograma estimado para completar con xito el proyecto de Internet Dedicado Flexible y Direcciones IP. Nuestro caso de estudio solo abarcar las actividades hasta la fase de Documentacin es decir con fecha de entrega del 14 de febrero.

Figura 2. Cronograma estimado para el proyecto De acuerdo con la figura 40 la lnea base de actividades del proyecto es: - Actividad 1: Anlisis - Actividad 2: Diseo - Actividad 3: Desarrollo - Actividad 4: Documentacin Y la fecha de terminacin del proyecto hasta la fase de documentacin debera ser el da 14 de febrero. 4.1.2 Definicin de rango de duracin para cada una de las actividades.

Contamos con la participacin del gerente de proyecto para obtener las estimaciones de tres puntos correspondientes a las duraciones de cada una de las actividades de la lnea base del proyecto: Actividades
Anlisis Diseo Desarrollo Documentacin

Bajo
1 1 7 1

Ms probable
2 4,5 16 2

Alto
5 10 30 5

TOTAL 10 24,5 50 Tabla 1. Estimacin de tres puntos de las actividades del proyecto.

4.1.3

Simulacin de tres puntos para la probabilidad de la Terminacin Total del proyecto

Esta distribucin de fechas de finalizacin del proyecto es hallada mediante la simulacin del cronograma varias veces. En cada iteracin una duracin de la estimacin de tres puntos es escogida aleatoriamente. Como en este caso no se conoce cul combinacin de duraciones va a ocurrir la simulacin se realiz con 2500 iteraciones cada una con una duracin seleccionada al azar. La figura

117

40 muestra la distribucin generada a partir de los rangos de estimacin de los valores optimista (bajo), ms probable y pesimista (alto) para cada una de las actividades del cronograma del proyecto.

Figura 3. Distribucin de probabilidad de posibles fechas de entrega

Conforme a la grfica de distribucin de las fechas de actividades del proyecto (Figura 3) es posible concluir que la fecha de finalizacin del proyecto es cercana al 22 de febrero. Probabilidad acumulada: Los resultados del anlisis de riesgos proveen posibles fechas y sus probabilidades para la entrega del sistema. La tabla muestra la probabilidad por cada posible fecha de finalizacin del proyecto: Fecha Probabilidad 12/02/2007 38,30% 13/02/2007 42,50% 14/02/2007 46,90% 15/02/2007 50,30% 16/02/2007 55,90% 19/02/2007 60,70% 20/02/2007 66,80% 21/02/2007 70,70% 22/02/2007 74,70% 23/02/2007 77,77% 26/02/2007 81,10% 27/02/2007 84,80% Tabla 2. Probabilidad de las fechas para la finalizacin del proyecto. De acuerdo con la tabla 16, la probabilidad de terminar el proyecto hasta la fase de documentacin en la fecha estimada (14 / 02/ 2007) es de slo 46,9%. En este caso era requerido que el cronograma contara con por lo menos un 80 % de probabilidad de xito es decir que el da estipulado de finalizacin (14 de febrero) contar, al menos con una probabilidad del 80% de haber terminado el proyecto. Sin embargo, como se aprecia en la tabla 2 la

118

fecha que cuenta con dicha probabilidad es hasta el 26 de febrero: 12 das despus de la fecha estimada para la terminacin. 4.1.4 Discusin de resultados En cuanto a costos es inminente la necesidad de acordar un plan de mitigacin relacionado con el posible retraso del proyecto debido a las siguientes razones: La probabilidad de que la fecha estimada para la terminacin del proyecto es menor al 50%: las posibilidades de finalizacin en la fecha planeada se reducen slo a la mitad del total de ellas, por tanto, constituye un alto riesgo la manera como el cronograma se encuentra planeado. La planeacin del cronograma no alcanza siquiera a satisfacer el requerimiento de al menos el 80% del cumplimiento: el desfase en das es de 12 un nmero que puede ser considerablemente alto teniendo en cuenta este tipo de proyectos. 4.2 Estimacin de riesgo en costos Una segunda parte del anlisis cuantitativo lo constituye la estimacin de los riesgos en costos. A continuacin se describen las actividades y resultados obtenidos con respecto a este caso de estudio.

4.2.1

Determinar el grupo de elementos del WBS

El grupo de elementos de la descomposicin de la estructura del trabajo de acuerdo con lo planteado por este modelo lo constituyen los requerimientos del proyecto. La siguiente es la lista de los requerimientos del proyecto junto con el costo de implementarlos: REQUERIMIENTOS
Un cliente podr consultar las direcciones IP que tenga disponibles. El sistema debe generar las direcciones IP disponibles de un cliente de acuerdo con su plan de pago. Un cliente podr cambiar el nombre de su direccin IP Un cliente podr eliminar el nombre de su direccin IP El sistema deber notificar al cliente el nmero de cada una de las direcciones IP que tenga adscritas. El sistema deber verificar la existencia de una direccin IP de un cliente. El administrador del sistema podr consultar los logs de la aplicacin.

ID
01 02 03 04 05 06 07

Costo
4000000 4000000 5000000 5000000 2000000 2000000 4000000

Tabla 3. Estimacin de costos de los requerimientos del proyecto

119

4.2.2

Definicin de rango de costos para cada uno de los requerimientos Elemento del WBS Valor para EAC Requerimiento (ID) Bajo Ms Probable
01 02 03 04 05 06 07 4000000 4000000 5000000 5000000 2000000 2000000 4000000 3500000 3950000 3800000 4200000 1450000 1450000 3400000 4000000 4000000 5000000 5000000 2000000 2000000 4000000 4500000 5000000 6000000 5600000 3100000 3500000 4500000

Alto

Tabla 4. Estimacin de tres puntos de los costos de los requerimientos del proyecto

4.2.3

Simulacin de tres puntos y discusin de resultados

Despus de llevar a cabo la simulacin Montecarlo se logr determinar que la probabilidad de satisfacer las funcionalidades del proyecto con los costos establecidos para la implementacin de sus requerimientos es de tan solo el 27.00%. 4.2.4 Formulacin del nivel de prioridad y comunicacin de resultados de anlisis

El Anexo C (Resultado de la cualificacin y cuantificacin de riesgos) contiene el formulario de revisin de la estimacin final obtenida en este anlisis de riesgo en calendario junto con el de riesgo en costo y riesgo tcnico. El formulario fue presentado al resto de los miembros del equipo del proyecto. 5 Responder al riesgo Los riesgos cuantificados y cualificados ahora son comunicados al equipo de proyecto. continuacin se presentan los planes de riesgos formulados para cada uno. 5.1 Plan de riesgo Los siguientes son los planes formulados para los riesgos identificados de acuerdo con el resultado del anlisis cuantitativo de riesgos caso de estudio y resultado del anlisis cualitativo de riesgos caso estudio. A

120

 Plan de riesgo en calendario: se plante el plan de riesgo que se muestra en el Anexo C (Plan de riesgo en calendario). Plan de riesgo en costo: se plante el plan de riesgo que se muestra en el Anexo C (Plan de riesgo en costo). Plan de riesgo tcnico: el plan de riesgo es una posible adaptacin de lo que se espera pudiese ser una respuesta adecuada a este riesgo (ver Anexo C Plan de riesgo tcnico). 5.2 Base de aprendizaje de riesgos del proyecto Se espera ampliar el grupo de planes de riesgo que contendr la base de aprendizaje del proyecto, por ahora los planes de riesgo que sern almacenados en dicha base son los analizados a travs del mtodo cuantitativo (riesgo en costo y riesgo en calendario). 6 Fase de control y seguimiento

Con la formulacin de los planes de riesgo surge la necesidad de comprobar si en verdad stos estn cumpliendo con el objetivo para el cual fueron formulados. Los siguientes numerales de esta seccin muestran cmo fueron verificadas las acciones que comprendan los planes establecidos como respuesta. 6.1 Verificacin del plan de riesgo 6.1.1 Segn mtricas del control de costos y calendario. Riesgo en calendario: Despus de realizar nuevamente un anlisis cuantitativo luego de seguir el plan de riesgo establecido se observ que la probabilidad de terminacin del proyecto en la fecha establecida para ello era menor que la probabilidad esperada: PTP < PTPE. Con lo que se concluye que el plan de riesgo deber ser revisado y ajustado. (Anexo C Plan de riesgo en calendario ajustado). Riesgo en costo: Despus de realizar nuevamente un anlisis cuantitativo luego de seguir el plan de riesgo establecido se observ que el costo actual del proyecto (AC) con mayor probabilidad de ocurrir era menor que el valor mximo aceptado por encima del valor planeado del proyecto (DVP). Por tanto el estado del plan de riesgo fue ajustado (Anexo C Plan de riesgo en costo ajustado). 6.1.2 Segn las fuentes de riesgos La fuente de riesgo a la cual estaba asociado el riesgo tcnico de este caso de estudio cambi a lo largo de este proceso de gestin y fue eliminada por tanto el estado del plan de riesgo fue ajustado (Vase Anexo C Plan de riesgo tcnico ajustado).

121

Finalizar la gestin La gestin concluy con el almacenamiento de los formularios para su posterior revisin. Se espera, particularmente para el caso especial de los planes de riesgo, se pueda contar con un entorno computacional especfico que permita ordenarlos de manera que se facilite su bsqueda y a su vez se genere la oportunidad de involucrar todos los dems pasos del modelo en un solo ambiente computacional. En conclusin los resultados obtenidos en este caso de estudio fueron importantes ya que permitieron definir: - Los puntos de funcin totales por cada uno de los requerimientos del proyecto. - Los posibles riesgos, su probabilidad e impacto. - La formulacin de planes de riesgo. - La verificacin de los planes de riesgo, utilizando para ello los elementos propuestos por el modelo. Sin embargo, es posible que el modelo pueda ser refinado teniendo en cuenta algunos pasos, que por causas relacionadas con la privacidad de la empresa, no fueron ejecutados y probados como debera ser. Estos pasos son: - Estimacin de costos y presupuesto: no se cont con la informacin histrica suficiente para desarrollar la estimacin. - Reuniones del tipo Wideband Delphi: a pesar de que el modelo facilita la estimacin de

riesgos para que el anlisis cualitativo se desarrolle en el menos tiempo posible,

en

ocasiones algunos de los miembros del equipo del proyecto no contaban cpn el tiempo suficiente para reunirse a realizar las estimaciones.

122

Anexo C

FORMULARIOS DEL CASO DE ESTUDIO

123

FORMULARIO PARA LA ESTIMACIN DEL TAMAO CON PUNTOS DE FUNCIN

Requerimientos
Archivos que gestionan la aplicacin(ILF) Tabla de Clientes Tabla de Logs Archivos de Reverso DNS Archivos de Zona DNS X X X X X X X X
Requerimiento 1 Requerimiento2 Requerimiento 3 Requerimiento 4 Requerimiento 5 Requerimiento 6 Requerimiento 7 Nmero de Componentes de datos

Dificultad

RET 3

DET 8 5 4 4 Bajo Bajo Bajo Bajo

X X

1 1 1

| Archivos de Interfase (ELF)

Requerimiento 1 Requerimiento2 Requerimiento 3

Requerimientos
Requerimiento 4 Requerimiento 5 Requerimiento 6 Requerimiento 7

Nmero de Componentes de datos

Dificultad

RET

DET

124

Nmero de Componentes de datos

Dificultad

Requerimientos Entradas Externas (EI) Eliminar Reverso Cambiar Reverso Cliente

Requerimiento 1 Requerimiento2 Requerimiento 3 Requerimiento 4 Requerimiento 5 Requerimiento 6 Requerimiento 7

FTR 2 2

DET 15 15 Alto Alto

X X

Nmero de Componentes de datos

Dificultad

Requerimientos
Salidas Externas (EO) Consultar Ips Cliente
Requerimiento 1 Requerimiento2 Requerimiento 3 Requerimiento 4 Requerimiento 5 Requerimiento 6 Requerimiento 7

FTR 3

DET 6 Medio

125

Requerimientos
Consultas Externas (EQ) Consultar Logs Consulta Existencia Ips Cliente Consulta Numero de Ips Cliente
Requerimiento 1 Requerimiento2 Requerimiento 3 Requerimiento 4 Requerimiento 5 Requerimiento 6 Requerimiento 7

Nmero de Componentes de datos

Dificultad

FTR 1 2 2

DET 5 4 4 Bajo Bajo

X X X X

Total de Puntos de Funcin

Requerimiento Requerimiento 1 Requerimiento 2 Requerimiento 3 Requerimiento 4 Requerimiento 5 Requerimiento 6 Requerimiento 7 Total puntos de funcin del sistema No Puntos de funcin 26 24 17 17 1 11 10 99

126

Formulario para la estimacin de costos

Factores de Escala
Valor Factores de Escala Precedencia Flexibilidad de desarrollo Arquitectura/ Resolucin de Riesgos Cohesin del Equipo Madurez del Proceso

Extra Alto

Alto X X

Nominal

Bajo

Muy Bajo

X X X

Total Factores de Escala B 1.1624

127

Estimacin de Costos
ExtraBajo Tamao Requerimiento(Puntos de Funcin) Factores de Escala Valor Extra Alto Muy Alto Fiabilidad del Producto y Complejidad Alto Nominal Bajo Muy Bajo ExtraBajo Extra Alto Muy Alto Reutilizacin Requerida Alto Nominal Bajo Muy Bajo ExtraBajo Dificultad de la Plataforma Extra Alto Muy Alto Alto Nominal Bajo Muy Bajo X X X X X X X X X X X X X X X X X X X X X

26
Requerimiento 1

24
Requerimiento 2 Requerimiento 3

17

17
Requerimiento 4 Requerimiento 5

11

11
Requerimiento 6 R 7

128

Extra Alto Muy Alto Alto Nominal Bajo Muy Bajo ExtraBajo Extra Alto Muy Alto Alto Nominal Bajo Muy Bajo ExtraBajo Extra Alto Muy Alto Alto Nominal Bajo Muy Bajo ExtraBajo Costo Requerimiento $ 45000000 4000000 5500000 5251035 2638600 2759061 2656890 X X X X X X X X X X X X X X X X X X X X X

Experiencia del Personal

Facilidades

Planificacion Temporal

129

FORMULARIO DE RIESGOS IDENTIFICADOS

FORMULARIO DE RIESGOS IDENTIFICADOS INFORMACIN REQUERIDA DEL RIESGO

Nombre riesgo Fecha Nombre Componente subsistema Categora asociada Descripcin del riesgo Fuente de riesgo Responsabilidad

DESCRIPCIN DEL RIESGO IDENTIFICADO

Dificultad de interoperabilidad entre plataformas 20 febrero de 2007 Web Service Tcnica Posibles problemas de compatibilidad entre tipos de datos. Tecnologa no disponible Integrante del equipo de proyecto.

130

FORMULARIO DE EVALUACIN DE RESULTADOS

RIESGO

PROMEDIO PROBABILIDAD

DESVIACIN ESTNDAR

PROMEDIO IMPACTO

DESVIACIN ESTNDAR

Dificultad de interoperabilidad entre plataformas

Media

0.002356

Severo

0.0518

131

RESULTADO DE LA CUALIFICACIN Y CUANTIFICACIN DE RIESGOS

RIESGO
Exceder el tiempo de duracin estimado del proyecto. Exceder el costo estimado del proyecto Dificultad de interoperabilidad entre plataformas

FUENTE
(Opcional) Estimaciones errneas.

CATEGORA
Calendario riesgos de proyecto

PROBABILIDAD

IMPACTO

PRIORIDAD

53,1

Alta

Estimaciones errneas. Tecnologa no disponible

Costos riesgos de proyecto Tcnico

73% 60%

4 4

Alta Media

132

FORMULARIO DE PLAN DE RIESGO EN CALENDARIO

FORMULARIO DE PLAN DE RIESGO

NOMBRE DEL RIESGO
Exceso del tiempo estimado para la terminacin del proyecto

CATEGORA
Calendario- riesgo en proyecto

DESCRIPCIN
Se determin un nivel alto de prioridad y amenaza del riesgo en el proyecto. Se debe tener en cuenta las mtricas relacionadas con el calendario del proyecto con el fin de determinar si el plan de riesgo debe ser revisado en caso de que : la probabilidad obtenida del cumplimiento del cronograma del proyecto (PTP) en la fecha estipulada para su terminacin sea menor que la probabilidad mnima esperada (PTPE)

FUENTE Estimacin errnea. FECHA INICIO DE PLAN Inmediato ESTADO DEL PLAN DEL RIESGO Abierto

TIPO PLAN DE RIESGO Contingencia FECHA FINAL DE PLAN En 1 semana RESPONSABLE

ACCIONES A LLEVAR A CABO

PLAN DE CONTINGENCIA:
- ACCIONES PREVENTIVAS: Reevaluar el proceso de estimacin y planeacin del calendario. - DECISIONES TOMADAS: Convocar a reunin a los miembros del equipo y estimar algunas actividades crticas del proyecto.

133

FORMULARIO DE PLAN DE RIESGO EN COSTO

FORMULARIO DE PLAN DE RIESGO

NOMBRE DEL RIESGO CATEGORA

Exceso del costo total estimado para el Costos- riesgo en proyecto cumplimiento de los requerimientos del proyecto. DESCRIPCIN
Se determin un nivel alto de prioridad y amenaza del riesgo en el proyecto. Se deben revisar las mtricas relacionadas con la gestin de costos del proyecto con el fin de determinar si el plan de riesgo debe ser revisado en caso de que el costo del proyecto actual (AC) con mayor probabilidad de ocurrir sobrepase el valor mximo aceptado por encima del valor planeado de costo del proyecto (DVP).

FUENTE Estimacin errnea. FECHA INICIO DE PLAN Inmediato ESTADO DEL PLAN DEL RIESGO Abierto

TIPO PLAN DE RIESGO Contingencia FECHA FINAL DE PLAN En 1 semana RESPONSABLE

ACCIONES A LLEVAR A CABO

PLAN DE CONTINGENCIA:
ACCIONES PREVENTIVAS: Reevaluar el proceso de estimacin y planeacin del costo del proyecto. DECISIONES TOMADAS: Convocar a reunin a los miembros del equipo y re-estimar el costo total del proyecto teniendo en cuenta los requerimientos funcionales que ste debe cumplir.

134

PLAN DE RIESGO TCNICO

FORMULARIO DE PLAN DE RIESGO

NOMBRE DEL RIESGO
Dificultad de interoperabilidad entre plataformas

CATEGORA Tcnica

DESCRIPCIN
Este riesgo representa la dificulta de la unin entre los dos ambientes de la organizacin: - ambiente Linux - ambiente Windows. Ambos deben interoperar para lograr cumplir con los servicios que se le prestan a los clientes.

FUENTE
Tecnologa no disponible

TIPO PLAN DE RIESGO Contingencia FECHA FINAL DE PLAN

FECHA INICIO DE PLAN

inmediato

ESTADO DEL PLAN DEL RIESGO

Abierto

RESPONSABLE

ACCIONES A LLEVAR A CABO

PLAN DE CONTINGENCIA:
ACCIONES PREVENTIVAS: Investigar y evaluar la compra de tecnologas de integracin y la viabilidad de adquirirlas. DECISIONES TOMADAS: Convocar a reunin a los miembros del equipo para tratar las acciones preventivas dispuestas.

135

PLAN DE RIESGO EN CALENDARIO AJUSTADO

FORMULARIO DE PLAN DE RIESGO
NOMBRE DEL RIESGO
Exceso del tiempo estimado para la terminacin del proyecto

CATEGORA
Calendario - riesgo en proyecto

DESCRIPCIN
El plan de riesgo definido con anterioridad culmin y los resultados no eran los esperados. El plan de contingencia es reabierto y se debe formular nuevas acciones preventivas y tomar nuevas decisiones.

FUENTE Estimacin errnea. FECHA INICIO DE PLAN Inmediato ESTADO DEL PLAN DEL RIESGO Re-abierto

TIPO PLAN DE RIESGO Contingencia FECHA FINAL DE PLAN En 1 semana RESPONSABLE

ACCIONES A LLEVAR A CABO

PLAN DE CONTINGENCIA: Pendiente por formular

136

PLAN DE RIESGO EN COSTO AJUSTADO

FORMULARIO DE PLAN DE RIESGO

NOMBRE DEL RIESGO
Exceso del costo total estimado para el cumplimiento de los requerimientos del proyecto.

CATEGORA
Costos- riesgo en proyecto

DESCRIPCIN
Despus de realizar nuevamente un anlisis cuantitativo luego de seguir el plan de riesgo establecido se observ que el costo actual del proyecto (AC) con mayor probabilidad de ocurrir era menor que el valor mximo aceptado por encima del valor planeado del proyecto (DVP). Por tanto el estado del plan de riesgo fue ajustado y su estado cambio a CERRADO ya que la ejecucin del plan fue verificada y los resultados obtenidos se consideraron apropiados.

FUENTE
Estimacin errnea.

TIPO PLAN DE RIESGO

Contingencia

FECHA INICIO DE PLAN

FECHA FINAL DE PLAN

ESTADO DEL PLAN DEL RIESGO

CERRADO

RESPONSABLE

ACCIONES A LLEVAR A CABO

137

PLAN DE RIESGO TCNICO AJUSTADO

NOMBRE DEL RIESGO

Dificultad de interoperabilidad entre plataformas

CATEGORA
Tcnica

DESCRIPCIN
Se tomo la decisin de adquirir tecnologas para la integracin, por tanto la fuente del riesgo fue eliminada y por tanto el plan del riesgo cerrado.

FUENTE
Estimacin errnea.

TIPO PLAN DE RIESGO

Contingencia

FECHA INICIO DE PLAN

FECHA FINAL DE PLAN

ESTADO DEL PLAN DEL RIESGO

CERRADO

RESPONSABLE

ACCIONES A LLEVAR A CABO

138

Anexo D

ANEXO D

ENCUESTA SOBRE GESTIN DE PROYECTOS

1. Su empresa utiliza algn tipo de medicin del tamao del software: SI ___

NO ___

En caso de utilizarlo por favor indique cual: a. Basadas en conteo de lneas de cdigo b. Basada en estadsticas c. Puntos de funcin d. Lgica difusa e. Otro?, especifique por favor, cul y por qu?: ________________________________________________________

- En caso de no utilizarlo indique por favor la(s) razn(es): ______________________________________________________________________

2. Su empresa utiliza algn tipo de estimacin de costos: SI ___

NO ___ - En caso de utilizarlo por favor indique cual: a. Costos por analoga ____ b. Juicio experto ____ c. Precio a ganar ____ d. Botton UP ____ e. Top Down ____ f. COCOMO ____ - En caso de no utilizarlo indique por favor la(s) razn(es): __________________________________________________________________

3. Su empresa realiza estimacin de riesgos SI ___ NO ___

139

En caso de realizarla indique qu mtodo utiliza: a. Cuantitativo___ b. Cualitativo___ c. Otro, cul?: __________________________________________________ 4. Su empresa realiza algn tipo de gestin de riesgos: SI ___ NO ___ En caso de realizarla indique en cul fuente se apoya para realizar este proceso: a. b. c. d. IEE___ SEI___ PMBOOK Otro, cul?: __________________________________________________

5. En su opinin beneficiara a su empresa la propuesta de una nica metodologa que integrar la gestin de costos y riesgos. SI ___

NO ___ Por qu?:___________________________________________________________ 6. Sobre qu cree hay mayor carencia de conocimientos en su empresa? a. b. c. d. e. Gestin de riesgos ____ Estimacin y gestin de costos ____ Gestin de riesgos ____ Estimacin de mtricas ____ Otro? Cual:___________________________________________________

A qu causa le atribuye esta carencia?:______________________________________ Muchas gracias!!!!

140

Anexo E

ES

ESPECIFICACIN DE LOS REQUERIMIENTOS DEL PROYECTO

141

Especificacin de Requerimientos

Direcciones IP e Internet dedicado flexible

10-06-2007 1.0

Sandra Patricia Forigua Oscar Ballesteros

142

Tabla de Contenido 1. 2. 3. 4. 5. 6. 7. 8. 9. Tabla de Contenido ........................................................................................................ 142 El Propsito del Proyecto............................................................................................... 144 Stakeholders.................................................................................................................... 144 Usuarios del Producto .................................................................................................... 144 Restricciones Obligatorias ............................................................................................. 144 Hechos Relevantes y asumpciones................................................................................. 145 El alcance del Trabajo.................................................................................................... 146 El Alcance del Producto ................................................................................................. 146 Requerimientos Funcionales.......................................................................................... 147

143

El Propsito del Proyecto

Descripcin de Negocio del Cliente y Motivacin del Proyecto. Este proyecto fue desarrollado para un proveedor de servicios de Internet, el cliente se especializa en prestar sus servicios a todo tipo de empresas, adems de proveerles diversos servicios como correo organizacional, este proyecto est enfocada a ofrecer mas servicios a los clientes de este isp en este caso se prestan servicios de informacin acerca de las direcciones IP de los clientes. Objetivos del Proyecto. Como se mencion en la seccin anterior con este proyecto se quieren aumentar los servicios que la organizacin ofrece a sus clientes, en este caso se quieren ofrecer servicios a los clientes para que administren la informacin relacionada a sus direcciones ip.

Stakeholders

El Cliente El Cliente es el ISP que desea aumentar los servicios que ofrece a sus clientes. El Usuario El Usuario es el mismo que el Cliente.

Usuarios del Producto Lista de Usuarios. Bsicamente el usuario del producto desarrollado es el portal empresarial de la compaa, este portal se encarga de gestionar los servicios que se les ofrecen a los diferentes clientes de la compaa.

Restricciones Obligatorias Restricciones en la solucin. El sistema desarrollado debe implantar como interfaz para ser usado invocando servicios web, esto debido a que la organizacin para la que se desarrolla el producto tiene sistemas basados

144

en Linux y otros basados en Windows, lo que hace necesario la implantacin se servicios web para asegurar la interoperabilidad de todos los sistemas de la organizacin. Este sistema debe interactuar con el DNS de la compaa, en el cual se hacen las consultas y modificaciones de la informacin de las direcciones ip de los clientes, este DNS se encuentra montado sobre Linux.

Ambiente de Implementacin El sistema debe ser implementado sobre Linux y debe exponer servicios web al portal de la organizacin, a su vez el sistema debe interactuar con el DNS de la compaa y la base de datos de clientes de la compaa. Software pre-desarrollado El sistema utiliza varios paquetes de software que colaboran con el desempeo del software, a continuacin se listan estos paquetes. Tomcat: Este es un motor de servlets sobre el cual se mont la aplicacin web que maneja los servicios web expuestos. Axis: Este paquete mantiene una implementacin de web services. Hibernate: este paquete facilita la interaccin con bases de datos relacionales facilitando su manejo.

Hechos Relevantes y asumpciones Hechos El sistema deba ser desarrollado usando el lenguaje de programacin Java y debe exponer servicios web en este lenguaje para permitir interacciones con el portal empresarial de la compaa.

Asunciones Las siguientes son las asunciones tomadas en el desarrollo de este proyecto. Los archivos de configuracin del DNS de la compaa, estn disponibles en la mquina en la cual se instalar el software desarrollado. La base de datos de clientes esta disponible para su utilizacin desde la mquina en la que se instalar el software.

145

El alcance del Trabajo La Situacin Actual El manejo de la informacin de las direcciones IP pertenecientes a los clientes de la compaa, se realizaba por el personal de la compaa dependiendo de las necesidades de los clientes. Este proceso es demorado para los clientes y aumenta el trabajo para el personal de la compaa. Con este proyecto se busca automatizar este proceso, adems mejorando el servicio que se les presta a los clientes de la compaa El Contexto del Trabajo El sistema debe interactuar con la infraestructura actual de la compaa por la parte de ingeniera de la compaa, en esta rea toda la infraestructura se encuentra implementada en ambientes Linux, y la informacin de los diversos clientes se encuentra distribuida en diferentes servidores. Por otro lado el portal empresarial de la compaa se encuentra montado sobre plataforma Windows lo cual hace necesario que expongan servicios web para que las plataformas Linux y Windows puedan interactuar para poder ofrecer los servicios a los clientes de la compaa.

El Alcance del Producto La frontera del Producto. A continuacin se mostrar el diagrama de casos de uso en donde se encuentran las funcionalidades que se implementaron para este proyecto y el lmite que se estableci en el desarrollo del mismo.

146

Lista de Casos de uso del Producto. En esta seccin se listan los casos de uso implementados para el proyecto, y una descripcin de los mismos. 1. Consulta Direcciones Ip: esta funcionalidad permite obtener las direcciones Ip de un cliente y los nombres asociados a estas direcciones. 2. Consulta Reverso Ip: este caso de uso permite consultar el nombre asociado en el DNS de la compaa de una direccin ip. 3. Modificar Reverso IP: Esta funcionalidad permite a un cliente cambiar el nombre asociado en le DNS de la compaa de una de las direcciones ip del cliente. 4. Nmero de Ips Cliente: esta funcionalidad consulta el nmero de direcciones IP asignadas a un cliente. 5. Cliente tiene IP: este caso de uso permite consultar si un cliente especfico tiene direcciones IP asignadas. 6. Borrar Reveso: este caso de uso permite eliminar el nombre asignada a la direccin ip de un cliente en el DNS de la compaa. 7. Consultar Logs: este caso de uso permite consultar los logs generados por la aplicacin.

Requerimientos Funcionales En este numeral se har una descripcin de cada uno de los requerimientos implementados para este proyecto.

1.

Un cliente podr consultar las direcciones IP que tenga disponibles. Identificador del Requerimiento: 1 Descripcin: Este servicio permitir a los clientes de la compaa consultar las direcciones ip que tiene asignadas y los nombres asignados a estas direcciones en el DNS de la compaa. Justificacin: Este requerimiento permite aumentar los servicios de informacin prestados a los clientes de la compaa y disminuye el soporte solicitado a la compaa. Solicitante: Gerente del Producto. Criterio de aceptacin: El requerimiento ser aceptado si la implementacin del mismo obtiene la informacin deseada acerca de las direcciones IP de los clientes de la compaa. Satisfaccin del Cliente: 4 Insatisfaccin del Cliente: 5

2. El sistema debe generar las direcciones IP disponibles de un cliente de acuerdo con su plan de pago.

Identificador del Requerimiento: 2 Descripcin: Con la implementacin de este requerimiento se quiere, que los clientes de la compaa puedan consultar el numero de direcciones ip que pueden utilizar dependiendo del plan comprado con la compaa

147

Justificacin: La implantacin de este requerimiento permitir a los clientes conocer automticamente conocer que tantas direcciones ip asignadas a usado el nmero de direcciones IP disponibles, permitiendo mejorar el control que tiene el cliente por su infraestructura de red. Solicitante: Gerente del Producto. Criterio de aceptacin: El requerimiento se considera aceptado si proporciona en todo momento la informacin almacenada en los servidores de la compaa de manera correcta, para todos los clientes de la organizacin. Satisfaccin del Cliente: 4 Insatisfaccin del Cliente: 5

3. Un cliente podr cambiar el nombre de su direccin IP Identificador del Requerimiento: 3 Descripcin: Este requerimiento busca permitir que los clientes de la compaa cambien los nombres registrados en el DNS de la compaa de las direcciones ip asignadas a cada cliente. Justificacin: La implementacin de este requerimiento permitir disminuir el soporte solicitado por los clientes de la compaa para realizar estos cambios, adems de dar ms control sobre la infraestructura de red a cada uno de los clientes de la compaa. Solicitante: Gerente del Producto. Criterio de aceptacin: El requerimiento se clasificar como implementado, cuando se realice la tarea asociada a este requerimiento de forma correcta. Satisfaccin del Cliente: 4 Insatisfaccin del Cliente: 5

4. Un cliente podr eliminar el nombre de sus direcciones IP. Identificador del Requerimiento: 4 Descripcin: La implementacin de este requerimiento busca liberar los nombres asociados a las direcciones ip, cuando estas direcciones ya no se encuentren en uso. Justificacin: La implantacin de este requerimiento permitir facilitar la liberacin de las direcciones ip asignadas a un cliente cuando este ya no desee usar una direccin. Solicitante: Gerente del Producto. Criterio de aceptacin: El requerimiento se considera implementado en cuando el sistema permite eliminar si errores el nombre de una direccin IP. Satisfaccin del Cliente: 4 Insatisfaccin del Cliente: 5

5. El sistema deber notificar al cliente el nmero de las direcciones IP que tenga adscritas. Identificador del Requerimiento: 5

148

Descripcin: El desarrollo de este requerimiento permitir informar al cliente del nmero de direcciones IP que tiene actualmente asignadas y en uso. Justificacin: El requerimiento permite mejorar los servicios de informacin prestados a los clientes de la compaa mejorar los servicios ofrecidos. Solicitante: Gerente del Producto. Criterio de aceptacin: El requerimiento se considera aceptado, cuando siempre que se use el servicio retorne informacin valida del cliente. Satisfaccin del Cliente: 4 Insatisfaccin del Cliente: 5

6. El sistema deber verificar la existencia de una direccin IP de un cliente. Identificador del Requerimiento: 6 Descripcin: Este servicio es usado para verificar que las operaciones que requieren modificacin a informacin de una direccin IP se realizasen conociendo Justificacin: Este servicio permite disminuir los errores al modificar informacin del DNS compaa. Solicitante: Gerente del Producto. Criterio de aceptacin: El requerimiento se considerara aceptado consultada este acorde con la realidad de los clientes de la compaa. Satisfaccin del Cliente: 4 Insatisfaccin del Cliente: 5 cuando la informacin

7. El administrador del sistema podr consultar los logs de la aplicacin.

Identificador del Requerimiento: 7 Descripcin: la aplicacin desarrollada produce logs para determinar el estado del sistema, y detectar errores en la misma. Este servicio fue implementado para proporcionar informacin de la aplicacin al administrador del sistema. Justificacin: La inclusin de este servicio facilitara el soporte que se le da a la aplicacin y en caso de fallo facilitar la determinacin de la causa del mismo.

Solicitante: Gerente del Producto. Criterio de aceptacin: este requerimiento ser aceptado si la consulta a estos logs proporciona informacin relevante del estado del proyecto. Satisfaccin del Cliente: 3 Insatisfaccin del Cliente: 3

149