AUTORES: SANDRA PATRICIA FORIGUA, OSCAR …pegasus.javeriana.edu.co/~riesgors/tesis...

PROPUESTA DE UN MODELO DE ANÁLISIS PARA ESTIMACIÓN DEL TAMAÑO DEL SOFTWARE Y GESTIÓN 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

1

PROPUESTA DE UN MODELO DE ANÁLISIS PARA ESTIMACIÓN DEL

TAMAÑO DEL SOFTWARE Y GESTIÓN DE COSTOS Y RIESGOS A PARTIR DE REQUERIMIENTOS FUNCIONALES

AUTORES: SANDRA PATRICIA FORIGUA, OSCAR ARTURO BALLESTEROS

TRABAJO DE GRADO PRESENTADO PARA OPTAR EL TÍTULO DE INGENIERO DE SISTEMAS

INGENIERO LUIS CARLOS DÍAZ PROFESOR ASISTENTE

DIRECTOR DEL TRABAJO DE GRADO

PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA

CARRERA DE INGENIERIA DE SISTEMAS BOGOTA D.C.,

JUNIO 2007

2

PONTIFICIA UNIVERSIDAD JAVERIANA

FACULTAD DE INGENIERIA

CARRERA DE INGENIERIA DE SISTEMAS

Rector Magnífico: Padre Gerardo Remolina Vargas S.J.

Decano Académico Facultad de Ingeniería: Ingeniero Francisco Javier Rebolledo Muñoz

Decano del Medio Universitario Facultad de Ingeniería: Padre Sergio Bernal Restrepo S.J.

Director Carrera de Ingeniería de Sistemas: Ingeniera Hilda Cristina Chaparro López

Director Departamento de Ingeniería de Sistemas: Ingeniero Germán Alberto Chavarro Flórez

3

Nota de Aceptación

______________________________________________________

______________________________________________________

______________________________________________________

______________________________________________________

______________________________________________________

__________________________________________

Firma del Director del Proyecto

_________________________________________

Firma del Jurado

_________________________________________

Firma del Jurado

BOGOTÁ D.C., JUNIO DE 2007

4

Artículo 23 de la Resolución No. 1 de Junio de 1946:

“La Universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus proyectos de grado.

Sólo velará porque no se publique nada contrario al dogma y la moral católica y porque no contengan ataques o polémicas puramente personales. Antes bien, que se vean en ellos el anhelo de buscar la verdad y la Justicia”

5

DEDICATORIA:

Este trabajo es en primer lugar el resultado del apoyo de muchas personas que con la ayuda de

Dios nos acompañaron para lograr culminar lo que un día nos propusimos llenos de

entusiasmo y dedicación como fue estudiar la carrera de Ingeniería 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 dándonos una voz de aliento cuando en

momentos difíciles necesitábamos de un consejo y siempre creyeron en nosotros,

demostrándonos sus valores e ideales los cuales retomamos para la consecución de esta meta.

Y a Dios porque gracias a su compañía y fuerza este logro es alcanzado.

6

RESUMEN

Este trabajo de grado se encuentra orientado al estudio de las metodologías, métodos,

herramientas y técnicas asociadas a las áreas de la estimación del tamaño y la gestión de costos

y riesgos, con el propósito de sustentar la propuesta de un modelo que represente, en un solo

marco conceptual y práctico, los pasos a seguir para alcanzar una adecuada gestión de proyectos

de software en estas áreas.

Fundamentalmente este trabajo de grado recoge las principales bases conceptuales acerca de la

estimación y la gestión de costos y riesgos, y profundiza en ellas con el fin de alcanzar un

análisis comparativo que define la selección de los métodos y metodologías, como el sustento

de un modelo que apoye el desarrollo de estas actividades en pequeñas empresas de desarrollo

de software colombianas.

La propuesta de este modelo toma en cuenta las experiencias y datos estadísticos, disponibles en

la actualidad, que apuntan a las prácticas de planeación de proyectos de software en las

pequeñas empresas de software en Colombia. Para ello este trabajo incluye dentro de sus bases

teóricas los resultados de la encuesta anual de gerencia de proyectos realizada por ACIS

(Asociación Colombiana de Ingenieros de Sistemas) y las conclusiones relacionadas con la

aplicación de una encuesta dirigida a encargados de áreas tecnológicas de empresas bogotanas.

De esta manera se definieron los pasos del modelo y la forma cómo se deberían integrar los

procesos de estimación y gestión de costos con la gestión de riesgos en un solo marco,

involucrando las necesidades que ciertos procesos de planeación requieren suplir para llevar a

feliz término un proyecto de software.

Por último se expone la parte práctica del modelo a través de un caso de estudio. Esta

aplicación experimental, desarrollada sobre un proyecto de redes de comunicación, permitió

identificar aspectos del modelo que deberían ser modificados o incluidos logrando así su

refinamiento de manera gradual.

7

CONTENIDO INTRODUCCIÓN..................................................................................................................... 15 OBJETIVOS.............................................................................................................................. 16

OBJETIVO GENERAL:......................................................................................................... 16 OBJETIVOS ESPECIFICOS: ................................................................................................ 16

1. ESTADO DEL ARTE ........................................................................................................... 17 1.1 ESTIMACIÓN DEL TAMAÑO DEL SOFTWARE....................................................... 17

1.1.1 Metodologías de estimación del tamaño del software ............................................. 18 1.2 GESTIÓN DE COSTOS.................................................................................................. 21

1.2.1 Estimación del costo del proyecto ............................................................................. 21 1.2.2 Estimación del presupuesto del proyecto .................................................................. 24 1.2.3 Control del presupuesto del proyecto ........................................................................ 26

1.3 GESTIÓN DEL RIESGO ................................................................................................. 27 1.3.1 Modelos existentes .................................................................................................... 28 1.3.2 Elementos de la gestión del riesgo ............................................................................ 29

2. PROPUESTA CONCEPTUAL DEL MODELO ............................................................... 39 2.1 CARACTERIZACIÓN DE PROYECTOS DE TECNOLOGÍA DE LA INFORMACIÓN .................................................................................................................... 39

2.1.1 Caracterización de proyectos de TI en Colombia...................................................... 40 2.1.2 Aproximación a la actualidad de las empresas y áreas de tecnología colombianas .. 42 2.1.3 Generalidades de las empresas de desarrollo en el Reino Unido ............................ 44

2.2 PLANTEAMIENTO DEL MODELO PARA LA ESTIMACIÓN DEL TAMAÑO ....... 45 2.2.1 Evaluación de métodos para la estimación del tamaño del software......................... 46 2.2.2 Método escogido para la estimación del tamaño del software .................................. 46 2.2.3 ¿Por qué se escogió este método?.............................................................................. 47 2.2.4 Esquema del método de Puntos de función ............................................................... 47

2.3 PLANTEAMIENTO DEL MODELO PARA LA ESTIMACIÓN DE COSTOS DEL PROYECTO ........................................................................................................................... 47

2.3.1 Evaluación de métodos y modelos para la estimación de costos.............................. 48 2.3.2 Modelo escogido para la estimación de costos.......................................................... 49 2.3.3 Esquema del modelo COCOMO II ........................................................................... 49

2.4 PLANTEAMIENTO DEL MODELO PARA LA ESTIMACIÓN DEL PRESUPUESTO49 2.4.1 Evaluación de métodos para la estimación del presupuesto...................................... 50 2.4.2 Método escogido para la estimación del presupuesto................................................ 51

2.5 PLANTEAMIENTO DE UNA METODOLOGÍA PARA EL CONTROL DEL PRESUPUESTO..................................................................................................................... 51

2.5.1 Evaluación de métodos para el control del presupuesto............................................ 51 2.5.2 Método escogido para el control del Presupuesto ..................................................... 52

2.6 PLANTEAMIENTO DEL MODELO DE GESTIÓN DE RIESGOS.............................. 53 2.6.1 Principios básicos en los cuales debería basarse una metodología de gestión de riesgos................................................................................................................................. 53 2.6.2 Requisiciones de una metodología de gestión de riesgos.......................................... 53 2.6.3 ¿Por qué se escogió esta metodología?...................................................................... 54 2.6.4 Fases o pasos de la metodología................................................................................ 55

2.7 Resultados del capitulo ..................................................................................................... 65 3. MODELO PARA LA ESTIMACIÓN Y GESTIÓN DE PROYECTOS ......................... 66

3.1 PASO I: DEFINIR LOS REQUERIMIENTOS FUNCIONALES DEL PROYECTO .... 67 3.1.1 Proceso de definición de requerimientos................................................................... 67 3.1.2 Descripción del proyecto y especificación de los requerimientos............................ 67

3.2 PASO II: ESTIMAR EL TAMAÑO DEL SOFTWARE ................................................. 68 3.2.1 Modelo para la estimación del tamaño ...................................................................... 68

3.3 PASO III: GESTIONAR LOS COSTOS.......................................................................... 74 3.3.1 Modelo para la gestión de costos............................................................................... 74

8

3.3.2 Estimación 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 gestión .......................................................................................... 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 gestión.............................................................................................. 90 3.6 Resultados de este capítulo ............................................................................................... 90

4. CONCLUSIONES................................................................................................................. 91 5. TRABAJOS FUTUROS ....................................................................................................... 92 BIBLIOGRAFÍA....................................................................................................................... 93

9

LISTA DE TABLAS

Tabla 1. Términos del análisis del valor ganado....................................................................... 27 Tabla 2. Formulas del método de valor ganado ........................................................................ 27 Tabla 3. Procesos de gestión de riesgos .................................................................................... 28 Tabla 4. Perfil de riesgos [Armstrong, 2004]............................................................................ 30 Tabla 5. Estimación de tres puntos del calendario .................................................................... 34 Tabla 6. Evaluación de los métodos para estimación del tamaño del software ........................ 46 Tabla 7. Evaluación de los métodos para la estimación de costos ............................................ 48 Tabla 8. Evaluación de métodos para la estimación del presupuesto de un proyecto............... 50 Tabla 9. Evaluación de las metodologías para el control del presupuesto ................................ 52 Tabla 10. Comparación de las técnicas para la identificación de riesgos ................................. 57 Tabla 11. Elementos del proceso para la definición de requerimientos .................................... 67 Tabla 12. Determinación de la dificultad de implementación para ILF y ELF [Boehm, 1999] 72 Tabla 13. Determinación de la dificultad de implementación para EI [Boehm, 1999]............ 72 Tabla 14. Determinación de la dificultad de implementación para EO y EQ [Boehm, 1999] . 72 Tabla 15. Cálculo del Total de Puntos de Función ................................................................... 73 Tabla 16. Elementos del modelo para la estimación del tamaño .............................................. 74 Tabla 17. Elementos del modelo para la estimación y gestión de costos.................................. 79 Tabla 18. Acrónimos para la métrica de riesgo en calendario .................................................. 90

10

LISTA DE FIGURAS

Figura 1. Modelo de gestión de riesgos más aceptado en la actualidad ..................................... 28 Figura 2. Gráfico de perfil de riesgos [Armstrong, 2004].......................................................... 31 Figura 3. Red de actividades de un proyecto............................................................................... 33 Figura 4. Datos para la estimación de riesgos en costos ............................................................. 34 Figura 5. Rango de costos para cada uno de los elementos del WBS[Hulett, 2004] .................. 35 Figura 6. Ejemplo simulación Monte Carlo para costos fuente[Hulett, 2004]............................ 35 Figura 7. Desempeño en el cronograma de proyectos de TI en Colombia.................................. 41 Figura 8. Desempeño en el presupuesto de proyectos de TI en Colombia................................ 41 Figura 9. Actualidad de la estimación del esfuerzo y tamaño en algunas áreas y empresas ....... 43 Figura 10. Actualidad de la estimación de costos ....................................................................... 43 Figura 11. Principios básicos de un proceso de gestión de riesgos ............................................. 53 Figura 12. Requisiciones para una metodología de gestión de riesgos ....................................... 54 Figura 13. Metodología de gestión de riesgos para el modelo .................................................... 54 Figura 14. Fuentes de riesgos del modelo ................................................................................... 55 Figura 15. Categorías relacionadas con la identificación de riesgos en proyectos de software. . 56 Figura 16. Asunciones básicas de un método para la identificación de riesgos.......................... 58 Figura 17. Taxonomía de riesgos de proyectos de software [Marvin J. Carr et al., 1993]......... 59 Figura 18. Categorización de riesgos identificados..................................................................... 60 Figura 19. Tipos de análisis y categorías 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 definición de los requerimientos....................................................... 67 Figura 26. Esquema del Modelo de estimación del Tamaño ...................................................... 68 Figura 27. Esquema del Modelo para la gestión de Costos........................................................ 75 Figura 28. Diagrama de flujo de la metodología de gestión de riesgos ...................................... 80 Figura 29. Paso I de la metodología de gestión de riesgos.......................................................... 80 Figura 30. Delimitación según la clase Entorno de desarrollo.................................................... 81 Figura 31. Delimitación según la clase Restricciones de programa............................................ 81 Figura 32. Delimitación según la clase Ingeniería del producto ................................................. 82 Figura 33. Categorización de riesgos identificados..................................................................... 82 Figura 34. Dinámica variante Wideband Delphi para la evaluación de riesgos técnicos............ 84 Figura 35. Evaluación 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 revisión ........................................................................ 89 Figura 39. Métrica para riesgo en costo ..................................................................................... 89 Figura 40. Métrica 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): Método de la ruta critica, este método es usado en la

administración de proyectos, para determinar la secuencia de actividades dentro de la red del

proyecto que determina la duración del proyecto [Hulett, 2004].

Descomposición 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 términos 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 Análisis (Análisis del Valor Ganado): Es un método para estimación 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): Asociación técnico-

profesional dedicada a la estandarización en el campo de la tecnología, también se encarga de la

promover la creatividad, el avance y integración de los avances tecnológicos [IEEE, 1990].

Línea Base: Especificación 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 técnica se basa en una reunión en donde los

participantes generan ideas sobre el tema tratado [Esteves, 2004].

13

Método Monte Carlo: Método no determinístico o estadístico usado para aproximar

expresiones matemáticas complejas y costosas de evaluar con exactitud, este método

proporciona soluciones aproximadas a una gran variedad de problemas posibilitando la

realización de experimentos con muestreo de números [Hulett, 2004].

Método Wideband Delphi: Es un método de estimación basado en el consenso, es decir la

estimación es realizada por un conjunto de personas que deben llegar a un acuerdo acerca de lo

que se esta estimando, este método se ha utilizado en muchas áreas exitosamente [Labdelaoui,

2001].

Mitigar un riesgo: Aplacar o reducir los efectos que la ocurrencia de un riesgo podría

ocasionar (aplacar el impacto de un riesgo) [Thayer, 2003].

PMBOK: Es una colección de procesos y áreas de conocimiento generalmente aceptadas como

las mejores practicas dentro de la gestión de proyectos. Este estándar fue construido por el

Project management institute [Microsoft, 2002].

Punto de Función (Function Point): Medida del tamaño de un sistema de software y del

proyecto que lo construye, esta mediada se basa en la teoría de que la funcionalidad del software

es la mejor medida de su tamaño [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 investigación, dedicado a la

investigación de temas relacionados con la ingeniería 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

INTRODUCCIÓN

La medición del software se presenta en nuestros días 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 gestión de costos y la atención temprana de los

posibles riesgos enfrentados de un proyecto surgen como actividades fundamentales que una

empresa relacionada con las actividades de tecnología de la información (TI) debe tener en

cuenta dentro de su presupuesto. Adicionalmente a través de la historia, se han planteado

diversos modelos que integran técnicas y metodologías construidas para estos fines.

Este trabajo integra los estudios y análisis efectuados entorno a los temas de estimación del

tamaño del software y la gestión de costos y riesgos de un proyecto de desarrollo, los cuales

encuentran su razón de ser en las metodologías y técnicas creadas pensando, fundamentalmente,

en facilitar las labores de planeación de un proyecto. Por otro lado, nace tras la necesidad de

establecer criterios para la selección de cualquiera de estas mismas técnicas o metodologías que

apoyen procesos de gran importancia como el de la gestión de costos y riesgos.

La definición de los criterios para la clasificación de las metodologías así como el

reconocimiento de ciertos principios y requisiciones que deben ser tenidos en cuenta para su

utilización en diversos contextos, no estaría completo sin la debida formulación de un marco

común que las integre a todas. De esta manera se plantea la propuesta de un modelo integral que

cubre diversas técnicas y metodologías asociadas a las áreas de estimación del tamaño y gestión

de costos y riesgos de un proyecto de desarrollo.

Por último, cabe resaltar la importancia que representa para el modelo la definición de los

requerimientos funcionales. Los requerimientos especifican una base sobre la cual se generan

algunos de los conceptos, decisiones y procedimientos que se desarrollarán 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 integración

entre la revisión 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 explicación del caso de estudio escogido.

15

OBJETIVOS

OBJETIVO GENERAL:

Desarrollar un modelo que reúna diversas metodologías para la estimación del tamaño del

software así como la gestión de costos y riesgos dentro de un proyecto de desarrollo basado en

los requerimientos funcionales.

OBJETIVOS ESPECIFICOS:

1. Definir criterios específicos que permitan establecer una clasificación de las metodologías

existentes para la estimación del tamaño del software y la gestión de costos y riesgos en un

proyecto de desarrollo teniendo presente el dominio del problema.

2. Determinar metodologías específicas a las áreas de estimación de tamaño, gestión de costos y

riesgos acordes con la clasificación desarrollada y fundamentadas en los requerimientos

identificados en un proyecto de desarrollo.

3. Definir un modelo que reúna las metodologías anteriormente definidas de acuerdo con los

criterios especificados y que facilite la estimación del tamaño del software y la gestión de costos

y riesgos.

4. Verificar experimentalmente la validez del modelo mediante su aplicación en al menos un

caso de estudio, representado en un proyecto de software cuya fase de recolección de

requerimientos se encuentre completamente definida mediante un modelo de análisis de

requerimientos.

16

1. ESTADO DEL ARTE

El contenido presentado en este capítulo es el resultado de un estudio estructurado sobre las

diversas fuentes bibliográficas y experimentales relacionadas con los modelos, métodos,

metodologías y técnicas construidos alrededor de los temas de estimación del tamaño del

software, gestión de costos y riesgos en un proyecto de desarrollo.

De manera resumida constituye la base teórica sobre la cual se apoyarán los procedimientos y

pasos que serán presentados. En la propuesta conceptual del modelo.

1.1 ESTIMACIÓN DEL TAMAÑO 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 basándose en una medición acertada acerca del tamaño del software [C. Shi Kuo, 2002].

La estimación del tamaño del software se puede realizar en diferentes etapas del proyecto.

Dependiendo del período en que ésta se lleve a cabo, es posible determinar su correspondencia

con el tamaño real del software. Por ejemplo, si la estimación se realiza al final del proyecto se

puede realizar una estimación, por así decirlo 100% acertada, debido a que para este momento

ya se conoce la duración total de éste, además de la cantidad de código escrito. Sin embargo, si

la estimación se realiza en etapas tempranas del proyecto se podría decir que el resultado estaría

bastante alejado de la realidad. En conclusión, la realización de una estimación más temprana

contribuye a que la incertidumbre entorno a los factores que afectan el proyecto disminuya.

Lo realmente importante de la estimación no es necesariamente que ésta sea 100% confiable,

sino el hecho de que su realización contribuya en la determinación 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 información que se vaya recolectando, lo que a largo plazo, ayuda

a que las estimaciones que se hagan sobre proyectos futuros sean cada vez más acertadas.

Para la realización de esta actividad existen diversos métodos y metodologías, pero las

metodologías mas destacadas para la estimación del tamaño del software son el conteo de líneas

de código del programa producido y el conteo de puntos de función. 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 también requieren tiempo y recursos, que

incrementan el tamaño del software en desarrollo.

1.1.1 Metodologías de estimación del tamaño del software

A continuación se presenta una descripción de cada una de las metodologías de estimación del

tamaño, consideradas como las más importantes y más usadas por la industria. Como fue

mencionado anteriormente existen básicamente dos aproximaciones a esta estimación: el conteo

de líneas de código y el conteo de puntos de función. A continuación describiremos dichas

aproximaciones [C. Shi Kuo, 2002].

• Estimación basada en líneas de código.

Esta estimación se podría catalogar como de tipo tardío, ya que el número total de líneas de

código sólo 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

código no deberían ser contados, por lo cual sólo se debe contar, lo que se especifique a ser

contado.

Dentro de esta categoría existen varias metodologías las cuales usan las líneas de código como

base para la realización de su estimación [C. Shi Kuo, 2002]. A continuación se explican

algunas de estas metodologías.

• Estimación por conteo de bloques

Este enfoque se basa en estimar el número de funciones esperadas que tendrá el sistema. Se

puede ver como un enfoque de estimación temprana debido a que estima el número de

funciones esperadas. Por tanto, se cuenta con poca información acerca del proyecto con lo que

las estimaciones no podrían ser muy exactas. De esta manera, a medida que avanza el proyecto

es deseable que las estimaciones fueran más coherentes con la realidad.

Es posible que el método pueda ser complementado con funciones estadísticas para encontrar

una estimación más precisa. Con este fin es usada la desviación estándar, obtenida a partir de la

información de proyectos pasados ya realizados, lo cual mejora en gran parte las estimaciones

para la organización.

A continuación se enumeran los pasos empleados en el uso de este modelo:

a. Estimar el número de bloques, o componentes de software esperados.

b. Multiplicar el número de bloques por el tamaño esperado de cada tipo de bloque.

c. Calcular la desviación estándar para dicho proyecto.

18

d. Aplicar el método repetidamente para los diferentes niveles de detalle, y así obtener una

estimación más precisa.

• Estimación del tamaño estadística

Este método se basa en la estimación del tamaño a partir de la utilización de cálculos

estadísticos y dividiendo el sistema en componentes para cada uno de los componentes que

integran el sistema posibilitando la estimación del sistema completo tomando como base cada

uno de sus componentes por separado. Asimismo, este método se encarga de disminuir la

incertidumbre acerca de las estimaciones de los componentes individuales, lo cual posibilita

contar con una estimación mucho más segura del sistema completo. Con este fin, el método se

basa en la estimación por analogía, en la cual se compara el proyecto actual con otros anteriores

ya realizados, evidenciando la necesidad de mantener una base de datos con la información

acerca de todos estos proyectos anteriores que servirán para la estimación del proyecto en

curso.A continuación se listan los pasos para estimar el tamaño del software con este método:

a. Determinar las funciones que compondrán el nuevo sistema.

b. Buscar información acerca del tamaño de funciones similares ya desarrolladas.

c. Identificar las diferencias entre las funciones similares y las nuevas.

d. Para cada componente o función a estimar, se deben estimar tres parámetros, el menor, medio

y máximo tamaño de cada uno de los componentes o funciones.

e. Calcular la media estadística y desviación estándar de cada uno de los números obtenidos en

el numeral anterior.

f. Tabular cada uno de estos datos obtenidos.

g. Calcular la media total del proyecto, y la desviación estándar del proyecto.

• Estimación por lógica difusa

Este método se basa en dividir el proyecto en categorías de tamaño y dependiendo de la

cantidad de líneas de código producidas en cada una clasificarlas en grande, mediano y

pequeño. Para realizar esta categorización se requiere tener información de proyectos anteriores

para generar los grupos antes descritos.

Por consiguiente para realizar la estimación del nuevo proyecto se debe juzgar en qué categoría

quedaría éste, lo cual daría un rango de líneas de código que el nuevo proyecto podría producir.

Un problema que presenta este método, es que el cambio tecnológico trae como consecuencia

que la magnitud en líneas de código de un proyecto varié, lo cual podría hacer que los grupos ya

anteriormente definidos necesariamente tengan que cambiar.

19

• Estimación basada en puntos de función

Este método se diferencia a los basados en líneas de código en que, no se basa en la longitud de

programa sino en la funcionalidad que presta, lo cual hace a este método independiente del

lenguaje.

El Análisis de Punto Función es una técnica que, mediante la descomposición de un sistema en

componentes más pequeños, permite que éstos puedan ser mejor comprendidos y analizados en

forma individual.

El Análisis de Punto Función se basa en la teoría de que las funciones de una aplicación son la

mejor medida del tamaño de un sistema. El Punto Función mide el software mediante la

cuantificación de la funcionalidad que el sistema le brinda al usuario basado fundamentalmente

en el diseño lógico. Es independiente del lenguaje de computación, de la metodología de

desarrollo, de la tecnología utilizada y de la capacidad del equipo de trabajo para desarrollar la

aplicación [Mulcahy, 2002].

El Análisis del Punto Función es un método estándar de medición de desarrollo de software

desde el punto de vista del usuario. Su objetivo es medir el software basándose en la

cuantificación de la funcionalidad brindada al usuario partiendo fundamentalmente de diseños

lógicos. La cuenta de Punto Función para proyectos de desarrollo mide las funcionalidades que

se le proporcionan al usuario conjuntamente con la primera instalación del software producido

cuando el proyecto es terminado [Longstreet, 2004].

El método realiza su estimación contando el número de componentes de cada clase de punto

funcional, luego se estima la complejidad de cada uno de los componentes medidos, alta o baja,

según sea el caso, luego se multiplica cada contador de puntos de función por el valor adecuado,

y se suma el total de puntos de función.

Cada uno de los tipos de puntos de función se describe a continuación.

- Entradas externas: Datos o entradas de control al sistema que causan que el sistema lleve a

cabo algún 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 atención.

- Interfaces Externas: Archivos o programas que salen del sistema.

20

- Archivos Internos: agrupamiento lógico de información almacenada en el sistema.

- Con cada uno de estos elementos se determina qué tan grande va a ser el sistema a

desarrollar.

1.2 GESTIÓN DE COSTOS

La gestión de costos es una actividad necesaria para cualquier proyecto debido a que permite

conocer qué tanto se va a gastar en su implementación 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 terminación del proyecto genere ganancias o

pérdidas. Enseguida se enumeran cada una de las actividades que comprende la gestión de

costos junto con la explicación de cada una:

1.2.1 Estimación del costo del proyecto

Como es de suponerse, el costo de un proyecto se encuentra directamente ligado al tamaño del

mismo, ya que el tamaño determina en la mayoría de los casos la duración y la dificultad de

realizar dicho sistema. Partiendo de esto, el tamaño constituye uno de los factores que deben ser

tenidos en cuenta al momento de realizar una buena estimación 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 visión acerca de los múltiples aspectos que deben ser tenidos en

cuenta al momento de realizar una estimación apropiada del costo de un proyecto, así como el

método a usar para dicha estimación. En general, existen dos tipos de métodos para la

estimación del costo de un proyecto: los métodos algorítmicos y no algorítmicos, los métodos

no algoritmos se basan por lo general en la experiencia dejada por proyectos anteriores.

A continuación se hará una breve descripción de los métodos más importantes para estimar el

costo de un proyecto de software:

1.2.1.1 Metodologías de estimación del costo de un proyecto de software

En general existen 2 tipos de métodos para la estimación del costo de un proyecto: los métodos

no algorítmicos y no algorítmicos [C. Shi Kuo, 2002]. A continuación se hace una breve

explicación de los métodos más relevantes en esta área.

• Métodos no algorítmicos:

Estos métodos están basados específicamente 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 estimación del proyecto a realizarle, los métodos que pertenecen a esta categoría

muchas veces requieren de datos históricos para las estimaciones, lo que muchas veces es algo

problemático ya que no todas las organizaciones mantienen información de sus proyectos

anteriores.

Estos pueden ser:

- Costos por Analogía

Requiere que al menos se tenga información de un proyecto anterior similar, se usan los datos

de las anteriores estimaciones y sus resultados para lograr una estimación más precisa.

- Juicio Experto

Se requiere consultar a uno o más expertos en la estimación del tamaño de software, donde cada

uno realiza una estimación diferente y luego se llega a un consenso sobre ésta. Los pasos que

contiene este método son:

a. Se presenta a cada estimador, se realiza la estimación en la base de los compañeros.

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 producción 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

estimación global a partir de las características de todo el sistema, para luego realizar basado en

esto, la estimación 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 tamaño, 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

estimación total que comprende la sumatoria de cada una de las estimaciones pequeñas.

- Top – down

Este método es opuesto al anterior, para este método se realiza la estimación 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 método es adecuado para fases iniciales del proyecto.

22

• Métodos Algorítmicos

Estos métodos se basan en la aplicación de una función a las propiedades del sistema para

obtener una estimación formal de proyecto a implementar. Los métodos algorítmicos tienen en

cuenta factores relacionados con: costos, producto, herramientas computacionales, equipo

humano, proyecto.

- Modelos Lineales

Los métodos algorítmicos se basan en la sumatoria de los aspectos que son relevantes al

proyecto. Presenta como principal desventaja que la mayoría 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 tamaño 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 proyección de las prácticas en la construcción 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 prácticas y hacerlo de nuevo vigente [Baker,2003].

Este modelo permite estimar el costo, el esfuerzo y el tiempo de duración de un proyecto de

software, y fue creado para su utilización junto a los ciclos de vida modernos en los proyectos

de software y sigue las necesidades de los usuarios de la estimación de costos en los proyectos

de software, las cuales son apoyo en la planificación de proyectos, previsión del personal del

proyecto, preparación del proyecto, replanificación, seguimiento del proyecto [B. Boehm,

1999].

Para realizar todo esto, COCOMO II proporciona tres modelos de estimación cada vez más

detallado, que tienen en cuenta cada sector y tipo de información 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 planificación y el diseño del mismo. Los modelos

indicados son:

23

a. Modelo de composición de aplicaciones: Este modelo cubre los proyectos realizados con

herramientas modernas de construcción de interfases gráficas.

b. Modelo de Diseño Anticipado: Este modelo está diseñado 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 más completo incluido en COCOMO II, y está

diseñado para aplicarse luego que se ha terminado la etapa de diseño y luego de que la

arquitectura del proyecto se encuentra bien planificada.

- SLIM

Se basa en la distribución de poder hombre y los descubrimientos en proyectos anteriores. Se

usa la ecuación de software, en donde se relaciona, el tiempo de entrega, factores ambientales,

en los cuales se refleja la capacidad de desarrollo de la compañía, mediante el uso de

información de proyectos pasados.

- Modelos discretos

Estos modelos son del tipo modular en donde se relaciona el esfuerzo, duración y dificultad y

otros factores de costo, son fáciles de usar.

1.2.2 Estimación 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

asignación debe tener en cuenta factores tales como: salarios, costos de instalaciones, costo de

equipos, etc.; pero más allá que una asignación de recursos, el presupuesto es una herramienta

de control que servirá para una futura determinación del estado del proyecto recuerdo con el

dinero gastado.

Es importante realizar las estimación del presupuesto usando una división detallada del trabajo,

es decir, dividir el proyecto en tareas lo más atómicas posibles; de esta manera, durante el

desarrollo del proyecto se podrá controlar el mismo de una manera mucho más exacta.

1.2.2.1 Consideraciones al realizar un presupuesto

Ahora se presentarán 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 más rápido requerirá

mucho más dinero.

- Consultar la estimación del presupuesto de cada una de las actividades con las personas que

las realizarán: estas personas tienen un mayor conocimiento del esfuerzo que se debe emplear en

estas tareas.

- Consultar con otros gerentes de la organización: en la misma organización 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 históricos de prepuestos realizados anteriormente: lo cual puede contribuir a

determinar si una estimación es correcta o si es muy optimista o pesimista. De igual manera,

permite evaluar qué tanto la organización ha fallado en el presupuesto planeado y el realmente

ejecutado generando un porcentaje de varianza que se debe tener en cuenta al realizar la

estimación.

1.2.2.2 Métodos para la estimación del presupuesto.

En esencia, la estimación 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 continuación se mencionarán los métodos más comunes con los que se estima el presupuesto

de un proyecto:

• Bottom Up

En este método, el personal encargado de realizar la estimación 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

estimación se puede dividir en grupos realizando varias estimaciones que luego serán evaluadas

y discutidas por los diferentes grupos y lograr llegar al acuerdo sobre un presupuesto.

• Top Down

Para este método, 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 más pequeñas, pero siempre basándose en la

estimación de nivel superior.

25

• Estimación por Fases

Presenta la combinación entre Botton Up y Top Down. Como su nombre los indica, la

estimación se puede llevar a cabo en cualquiera de las fases del proyecto: iniciación, análisis,

desarrollo, haciendo parecerlas como un proyecto individual [Baker, 2003].

1.2.3 Control del presupuesto del proyecto

Tan importante como la estimación del costo del proyecto y el calendario del mismo es el

control presupuesto del proyecto. A través 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 pérdidas y sobre costos.

1.2.3.1 Métodos para el control del presupuesto

En cuanto a los métodos para el control del presupuesto es posible afirmar que la mayoría se

basan en la comparación de lo que se ha gastado hasta el momento con respecto a lo que se

encontraba planeado gastar. Estos son los métodos encontrados para el control de presupuesto:

• Seguimiento del plan de gastos

Este es un método sencillo en el cual se realizan reportes periódicos de los gastos del proyecto,

éstos son comparados con el presupuesto del proyecto, y lo que debería haberse gastado hasta

ese momento. Este método puede ser complementado con la realización de gráficas del

desempeño del proyecto frente a los costos a través del tiempo; éstas gráficas pueden mostrar de

manera mucho más clara en qué proporción los gastos del proyecto son mayores o menores

frente al costo estimado en el presupuesto.

• Análisis del Valor Ganado

Este es un método para estimar el alcance en el tiempo y el desempeño del proyecto, esto

mediante una serie de métricas con las que es posible estimar muchos aspectos útiles del

desempeño del proyecto [Mulcahy2002]. En esencia, el análisis usa tres aspectos desde los

cuales se estiman los demás aspectos con los que se mide el proyecto en cuanto a costos. Estos

aspectos son:

- Cuánto trabajo está planeado para desarrollarse en el momento de la aplicación del método.

- Cuánto se ha gastado al momento de la aplicación del método.

- El trabajo que se ha realizado hasta el momento.

Conociendo estos tres aspectos se procede a estimar las siguientes métricas mostradas en la

tabla 1:

26

ACRÓNIMO TERMINO INTERPRETACIÓN

PV Valor Planeado Cuál es el valor estimado del trabajo planeado a realizar hecho. EV Valor Ganado Cuál es el valor estimado del trabajo, actualmente completado

AC Costo Actual Cuánto se ha gastado en el momento actual

BAC Presupuesto Completado Cuánto es el presupuesto para todo el trabajo.

EAC Presupuesto a Terminación Cuál es la estimación del costo del proyecto en el momento actual.

ETC Estimación a la Terminación Sobre el punto actual del proyecto, cuánto más se espera que se gaste en el proyecto.

VAC Variación a la Terminación Cuánto por encima o por debajo del presupuesto se espera que termine el proyecto.

Tabla 1. Términos del análisis del valor ganado Ahora que se conocen los significados de los aspectos a evaluar, es necesario conocer las

diferentes ecuaciones que involucran los térmicos anteriores (ver Tabla 1) para obtener una

estimación del estado actual de desempeño del proyecto.

NOMBRE FORMULA INTERPRETACIÓN

Variación del Costo (CV) EV-AC NEGATIVO si el costo está por encima del presupuesto - POSITIVO si el costo está por debajo del presupuesto.

Variación del Calendario (SV) EV-PV NEGATIVO si está atrasado según el calendario- POSITIVO si está adelantado según el calendario

Índice de desempeño del Costo (CPI) EV/AC Obtención de una parte de una unidad de dinero

gastada. Índice de desarrollo del Calendario (SPI) EV/PV Avance porcentual en el proyecto de la tasa de

avance originalmente planeada.

Estimado a la Terminación. (EAC) Nota: Existen diversas formas para calcular EAC

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

1. Cuánto 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 estimación original fue errónea 3. Dato actual del presupuesto remanente, usado cuando existen varianzas debido a un fututo atípico. 4. Dato actual más el remanente del presupuesto modificado por el desempeño.

Estimación a la Terminación (ETC)

EAC-AC Cuánto más el proyecto costará.

Variación a la Terminación (VAC) BAC-EAC Cuánto por encima del presupuesto se tendrá a la terminación del proyecto.

Tabla 2. Formulas del método de valor ganado

1.3 GESTIÓN DEL RIESGO

Se define a la Gestión del riesgo como el conjunto de actividades y prácticas 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, más

adelante, en la incapacidad de alcanzar los objetivos planteados del proyecto. Los riesgos están

conformados por al menos dos componentes: 1) la probabilidad de que un evento negativo

ocurra y 2) las consecuencias de su ocurrencia.

27

La gestión del riesgo se encuentra evocada a un logro en específico: “identificar y manejar

aspectos de un proyecto en específico 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 descripción de los diversos procesos construidos para gestionar los

riesgos de un proyecto de software (el proceso puede involucrar diversas metodologías, métodos

y herramientas dentro de sus pasos de gestión de riesgos):

PROCESO DESCRIPCIÓN

PMBok® 2000

- Estándar que utiliza el conocimiento, herramientas y técnicas para resolver posibles problemas del proyecto. - Involucra las fases de planteamiento, análisis de riesgo (cualitativo y cuantitativo), respuesta al riesgo y supervisión y control de los planes de riesgo.

SEI - Método Continuos Risk Management

- Proporciona una guía 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 gestión de riesgos de un proyecto a lo largo de todas las fases del mismo. - Involucra las fases de planeación, identificación, estimación, evaluación, planificación, tratamiento, seguimiento y control y comunicación.

IEEE

- Establece una norma para el desarrollo de planes de gestión del riesgo constituidos por el uso de formatos. Esta norma no establece técnicas exactas para ser usadas en los planes de proyecto. - Sugiere que cada organización debería desarrollar un conjunto de prácticas y procedimientos destinados a la preparación y ejecución de planes gestión del riesgo.

Tabla 3. Procesos de gestión de riesgos

Según [Maniasi, 2005] el modelo de gestión de riesgos más utilizado en la actualidad contiene los

siguientes elementos:

Figura 1. Modelo de gestión de riesgos más aceptado en la actualidad

28

1.3.2 Elementos de la gestión del riesgo Debido a que son numerosos los procesos y actividades creadas con el fin de apoyar la

estión de riesgos (además de las expuestas en la tabla 3 la literatura menciona otras

éstos se

proyecto” [Hulett, 2004].

na mención especial a la técnica de

entificación basada en taxonomía y cuyo concepto general se explica a continuación:

y de entorno contribuyen a su ocurrencia.

ación 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 identificación de

a. Son listados de riesgos que se han encontrado en proyectos similares a los que se intenta

. Se debe validar la aplicabilidad y validez de la información presentada en esta técnica. Es

g

más) es necesario profundizar en los elementos que apoyan la diversas fases del riesgo.

De esta manera, a continuación se explica con mayor detalle cada uno de los elementos que

involucra la Gestión de riesgos y expuestos en la figura 1.

1.3.2.1 Identificación del riesgo

[Thayer, 2003] la define como una aproximación “cuidadosa” y “organizada” de la búsqueda de

los “riesgos reales” asociados a un sistema. La identificación de riesgos comprende también “el

descubrimiento, definición, descripción y comunicación de los riesgos antes de que

conviertan en un problema que afecte el

• Técnicas de identificación de riesgos

Existen diversos métodos y herramientas enfocados a la captura de riesgos. La información

obtenida acerca de las técnicas para la identificación de riesgos de este trabajo, fue extraída de

[Maniasi, 2005]. Para efectos del presente trabajo se hará sólo u

id

- Identificación en base a taxonomías

Una taxonomía es una forma de clasificar y organizar la información acerca de por qué

ocurren eventos relevantes. Generalmente las taxonomías surgen de la experiencia obtenida al

analizar eventos relevantes y de aprender cómo los factores humanos, materiales,

circunstanciales

La identific

riesgos. Esta lista tiene su fuente originaria [Marvin J. Carr et al.,1993] quien en 1993 desarrolló

la identificación de riesgos basado en taxonomía para el SEI1. Estas son algunas generalidades

de esta técnica:

analizar.

b

decir, la consideración de los riesgos planteados en esta técnica es general y común a los

1 SEI: Software Egieneering Institute, 1991.

29

proyectos de desarrollo de software pero puede que la aplicabilidad varíe de acuerdo con el tipo

de proyecto.

1.3.2.2 Análisis de riesgo

De acuerdo con [Armstrong, 2004] el siguiente paso después de la identificación de los riesgos

es priorizar los problemas y crear un perfil de riesgos del proyecto.

n factor crucial para generar una apropiada priorización es el nivel de amenaza que un riesgo

. La combinación de la probabilidad y el impacto define el nivel de

.

un esgo

osibilidad de que un riesgo ocurra. El impacto se entiende

cto negativo obtenido como resultado de la ocurrencia de un riesgo

. Improbable: (11 – 30) %

e. Muy probable: (>71%).

dos para efectos de este trabajo son:

Mínimo : 2, Medio: tico: 5

Un riesgo alta probabilidad rencia y genera alto impacto es sgo que

contiene u to nivel de amen yecto y po ebe tener una prioridad alta.

La inform n del riesgo, ah lementada con el nivel de amenaza y idad, se

representa en una tabla de

U

representa para el proyecto

amenaza del riesgo

• Probabilidad e impacto de ri

Se define la probabilidad como la p

como una pérdida o efe

[Esteves, 2004].

- Niveles de probabilidad

a. Remoto: >10%

b

c. Probabilidad media: (31 – 50)%

d. Posible: (51 - 70) %

- Niveles de impacto: los niveles de impacto considera

: 1, Bajo 3, Severo: 4, Crí

con de ocur ción de un rie

n al aza para el pro r tanto d

ació ora comp prior

perfil del riesgo (ver tabla 4).

Riesgo Probabilidad Impacto Prioridad

R1 Posible Bajo Bajo

R2 Posible Crítico Alto

R3 Remota Severo Bajo

R4 Probable Severo Alto

R5 Posible Crítico Alto

Tabla 4. Perfil de riesgos [Armstrong, 2004]

30

A su vez, la información de la esta tabla puede ser tratada en un gráfico de perfil del riesgo con

el fin de ilustrar aquellos que tienen una prioridad alta para la formulación de planes de riesgo

(ver Figura 2).

Figura 2. Gráfico de perfil de riesgos [Armstrong, 2004]

• Análisis cualitativo

El análisis cualitativo del riesgo es utilizado para evaluar un número amplio de riesgos que

royecto. Está diseñado para medir, según una escala de calificación,

El análisis cuantitativo utiliza las distribuciones de probabilidad para representar la

algunos ítems del proyecto como lo son: las duraciones de las

- Entradas y salidas

as distribuciones son generadas a partir de los rangos de riesgo para el costo o duración de

sibles en cada caso.

son identificados en el p

los riesgos del proyecto por parte de miembros pertenecientes a él. Generalmente los rangos

de calificación están compuestos por los niveles de probabilidad e impacto de cada riesgo.

• Análisis cuantitativo

incertidumbre sobre

actividades del calendario [Hulett, 2004] y el costo en la estructura del trabajo del proyecto

(Work Break Down Structure).

Las entradas de un análisis 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.

L

las actividades del calendario, en ambos casos es importante obtener los rangos de estimación

compuestos por los valores optimista y pesimista que pueden ser po

31

- Técnicas y herramientas

a

e representar el plan o estrategia del proyecto. Está constituida por cadenas de actividades

ente implicará, a su vez, un retraso en el proyecto. Sin embargo, aquellas

ayectorias que no son críticas no necesariamente retrasarían el proyecto si ocurriera una

mino Crítico es tradicional y bien aceptado y esencial para

icas para la recolección de datos giran, frecuentemente, entorno a las denominadas

entrevistas del riesgo”. Las entrevistas del riesgo es un proceso mediante el cual el analista

personas especializadas en una parte específica del proyecto

l análisis cuantitativo del riesgo utiliza comúnmente el método de simulación Monte Carlo

En general el análisis cuantitativo de riesgos requiere modelaje, recolección de datos y

simulación. Estas son las herramientas utilizadas en cada aspecto:

a. Técnicas de modelaje: Método del Camino Crítico (“Critical Path Model” - CPM):

Es una herramienta para la administración del calendario de proyectos. Resulta útil a la hor

d

sucesoras y predecesoras relacionadas que forman, a su vez, los caminos a través de la red.

De esta manera el CPM permite calcular la duración más corta para la completitud del

proyecto así como la fecha de finalización a través del camino más largo de la trayectoria.

El camino más largo a través de la red es denominado “Camino Crítico” y cualquier retraso

que éste pres

tr

demora en ellas. El método del Ca

desarrollar la lógica del trabajo del proyecto y para administrar diariamente las actividades

que incluye.

b.Técnica de recolección de datos

Las técn

“

del riesgo se reúne con varias

con el fin de determinar datos relevantes del proyecto relacionados con el calendario y los

costos.

c. Herramientas de simulación

E

para estimar la probabilidad de las fechas y costos de la terminación total del proyecto.

- Proceso para la estimación de riesgos en calendario

a. Determinación del calendario CPM o Línea 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 duración, así como las fechas de inicio y de finalización

para cada una.

32

Suponiendo un proyecto simple de 8 actividades y una fecha de entrega (Figura 3). Teniendo

en cuenta las duracion d, si este proyecto está

planeado para iniciarse el 7 de enero el CPM muestra que el proyecto tomará 24.5 días y será

Las fechas mostradas en el diagrama son estimadas por el gerente del proyecto.

es (sólo días laborales) para cada activida

completado el día 14 de febrero.

Figura 3. Red de actividades de un proyecto

b. Rangos de duración de las actividades

s planeados [Hulett, 2003]. Sin embargo las experiencias en

yectos han demostrado que el trabajo puede tomar mayor tiempo que el

n el valor “más probable”. Por ello la incertidumbre en las duraciones de cada

epresenta mediante una estimación de tres puntos donde se definen los valores

po optimista (bajo) y pesimista (alto) que cierta actividad podría tardar.

De esta manera, z establecidas las ctividades junto con su tiempo de desarrollo

miembros del equi stimación deben stimar los rangos duración basados en los

escenarios de puntos bajos (nivel optimista) y en los escenarios de puntos altos (nivel

pesimista) de tiem bajo para la culm ación de estas acti ades.

La tabla 5 mues máximo ínimo de duración para las actividades del

proyecto de la figura

Las duraciones de las actividades que son utilizadas para calcular la ruta crítica son

generalmente cantidades de tiempo consideradas como las “más probables” para completar el

trabajo dado los recurso

desarrollo de pro

adjudicado e

actividad se r

de tiem

una ve a

po de e e de

po de tra in vid

tra los valores y m

3:

33

ACTIVIDADES BAJO MÁS

PROBABLE ALTO

Análisis 1 2 5

Diseño 1 4,5 10

Desarrollo 7 16 30

Documentación 1 2 5

TOTAL 10 24,5 40

Tabla 5. Estimación de tres puntos del calendario

c. Simulación del Calendario del Proyecto

Esta fase se inicia cuando ya han sido determinados los rangos y distribución de la duración

para cada una de las actividades del proyecto. A partir de esta etapa el análisis 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 “más probable” para

la terminación del proyecto. Si no es así cuál sería la fecha

“más probable” para la completitud del proyecto?.

- Proceso para la estimación de riesgos en costos

a. Los Datos del R

mposición de la

estructura del trabajo”. Es a partir de ésta que se comienzan a recolectar los datos de los

ostos extremos (optimista y pesimista) de cada uno de los elementos más riesgosos. La

recolección se realiza a través de la evaluación de los líderes de equipo quienes evalúan los

de sus áreas. De manera similar a la estimación de riesgos en

iesgo:

Lo primero a tener en cuenta en el análisis de riesgos en costos es la “desco

c

riesgos adyacentes y propios

calendario, se debe obtener para cada elemento del WBS el valor mínimo y máximo de los

costes que conlleva llevarlos a cabo. La figura 4 muestra los datos de un análisis para la

estimación de riesgos en costos:

ELEMENTO DEL WBS VALOR PARA EAC BAJO MÁS

PROBABLEALTO

Figura 4. Datos para la estimación de riesgos en costos

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

34

b. Simulación de tres puntos

La figura 5 es un ejemplo de la estimación de tres puntos a partir de cada uno de los

elementos del WBS del proyecto: (ejemplo extraído de la fuente [Hulett, Integrated Cost Scheduled

Risk Analysis]):

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

U

simulación mediante el método Monte Carlo (Figura 6 tomada de [Hulett, 2004]):

tilizando la estimación de tres puntos para cada uno de los elementos del WBS se presenta la

siguiente

Figura 6. Ejemplo simulación Monte Carlo para costos fuente[Hulett, 2004]

illones de

c. Resultados de la simulación

De acuerdo con la figura 6 de la simulación el costo más probable es de $28.4 mdólares.

35

1.3.2.3 Planificación del riesgo

Comprende el desarrollo y documentación de estrategias que caracterizarán la Gestión del

ntadas mediante el desarrollo de planes de de acción tales

t al., 1993]

cífico puede involucrar alguna de las siguientes actividades:

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

riesgo mediante la reducción de su probabilidad y/o las consecuencias de su

Se pueden asumir cambios en el proceso de desarrollo o diseño del producto de

de evitar eventos indeseados.

ir, prescindir de cualquier tipo de acción para mitigarlo y de esta

rea de responsabilidad.

olectar nueva información que permita a los

lizar el riesgo con mayor profundidad y desarrollar planes nuevos de

La fuente [Wiegers, 1998] plantea los siguientes elementos para un plan de riesgos:

iesgo

la respuesta al riesgo.

cia

De igual manera la lista de los posibles estados de un riesgo es [Maniasi, 2005]:

riesgo. Las estrategias son represe

como: la creación de un plan de riesgos integrado. De acuerdo con [Marvin J. Carr e

el plan para un riesgo espe

- Formulación d

éste llegase a ocurrir.

- Evasión del

ocurrencia.

software con el fin

- Aceptación del riesgo, es dec

manera se asumen las consecuencias en caso de que éste ocurra.

- Transferencia: trasladar el riesgo a otra á

- Adquisición de conocimiento: Consiste en rec

gerentes de proyecto ana

contingencia.

• Elementos de un plan de riesgo

- Identificador del riesgo

- Clasificación del riesgo

- Día de reporte

- Descripción del riesgo

- Probabilidad

- Impacto

- Nivel de r

- Primer disparador del riesgo.

- Respuesta al riesgo <controlar, evitar, minimizar, mitigar el riesgo>

- Fecha de inicio de la respuesta al riesgo

- Fecha de finalización de

- Estado actual del plan

- Plan de contingen

- Disparador del plan de contingencia.

• Posibles estados de un plan de riesgo

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 aprobación.

el riesgo ha sido aprobado y se encuentra en condiciones de ser

Plan completo El plan se ha ejecutado por completo y se encuentra pendiente la verificación

dos.

p verificado y sus resultados se consideran apropiados.

Re-Abierto: El plan ejecutado ha sido verificado y sus resultados no se consideran apropiados

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

consideran apropiados.

.3.2.4 Seguimiento del riesgo

señales que indican si se ha convertido en un problema. De igual

anera, se debe permanecer atento al estado en que se encuentran las acciones tomadas para

inimizarlo. Una herramienta importante de esta fase es el uso adecuado de métricas que

p ón de los riesgos y de sus planes de mitigación.

l riesgo. Tiene la capacidad de mejorar el proceso de gestión

el riesgo de acuerdo con los resultados de las métricas y eventos asociados a los riesgos.

- Plan Aprobado: El plan para

ejecutado.

- Plan Verde: El plan se está ejecutando según 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.

:-

de sus resulta

- Com letado: El plan ejecutado ha sido

-

por lo cual se solicita una nueva ejecución del ciclo de vida o proceso del riesgo.

-

1

Una vez identificado el riesgo se debe proseguir con un seguimiento continuo sobre éste y

permanecer atento a las

m

m

ermitan la supervisi

1.3.2.5 Control del riesgo

Supervisa los planes de acción de

d

• Comunicación

Tal y como lo expresa [Maniasi, 2005] la comunicación debe estar presente en las diferentes

fases del modelo de gestión de costos: entre los diferentes pasos del proceso y a un nivel interno

del equipo de proyecto.

37

• ocumentación

La base que sustenta las acciones adoptadas en el proceso de gestión de riesgos. Los planes de

acción de un riesgo en cualquiera de las formas expuestas anteriormente (Planificación del

riesgo) deben ser documentados.

1.4 RESULTADOS DEL CAPÍTULO

En este capítulo se dieron a conocer los conceptos y definiciones que se serán útiles en la

propuesta del modelo y su base teórica. De igual manera, se expusieron los procesos y pasos

involucrados en las metodologías y métodos relacionados con la estimación y gestión de

proyectos, así como los modelos más utilizados en la actualidad concernientes a estos temas.

Sin embargo, la revisión bibliográfica plasmada en este documento es susceptible de ampliarse a

nuevas fuentes de estudio teniendo en cuenta que es un área de constante evolución.

D

38

2. PROPUESTA CONCEPTUAL DEL MODELO

Este capítulo integra los conceptos y definiciones obtenidos como producto de la revisión

bibliográfica del estado del arte, con un análisis que va desde evaluaciones comparativas (sobre

los diversos métodos para la estimación y gestión de proyectos), hasta la recopilación de

algunos estudios estadísticos relacionados con los proyectos de software en Colombia.

Los primeros numerales de esta propuesta conceptual se concentran en la caracterización 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 Asociación Colombiana de Ingenieros de Sistemas [ACIS, 2007]. De igual manera

se contó con la realización de un pequeño estudio, del cual participaron algunos encargados y

gerentes de áreas tecnológicas de distintas empresas de software en Bogotá.

Posteriormente se da inicio a la selección de los métodos y metodologías que harán parte del

modelo a proponer, utilizando para ello criterios de clasificación definidos, ya sea en la

estimación del tamaño del software como en la gestión de costos y riesgos. En cuanto a la

estimación y costos se muestra una evaluación comparativa de los métodos creados para estas

dos actividades.

En tanto que para la parte de riesgos se desarrolló un análisis para escoger la técnica de

identificación más adecuada teniendo en cuenta los criterios, requisiciones y asunciones de una

metodología para gestión de riesgos, así como los resultados de la caracterización de los

proyectos de software mencionados con anterioridad.

Por último cabe mencionar que este análisis es la base fundamental del modelo propuesto ya

que de éste se toman los métodos, procesos y conceptos necesarios para su sustentación,

teniendo en cuenta el marco actual de los proyectos de software.

2.1 CARACTERIZACIÓN DE PROYECTOS DE TECNOLOGÍA DE LA INFORMACIÓN

Esta caracterización se divide en dos partes. La primera explora el estado de los proyectos de

Tecnología Informática (TI) en Colombia utilizando como fuente la encuesta anual de gerencia

de proyectos de La Asociación Colombiana de Ingenieros de Sistemas [ACIS, 2007]. La

39

segunda es una aproximación hacia las áreas de estimación y gestión que desarrollan algunas

empresas y áreas de tecnología 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 común de datos que permita apoyar algunos conceptos, funciones y procesos del modelo

a proponer y cuya definición se establecerá más adelante.

Por último se expone un estudio que proyecta el estado de las empresas de desarrollo de

software en el Reino Unido, también con el fin de conocer un contexto aún más globalizado que

rodea a las áreas de la estimación y gestión.

2.1.1 Caracterización de proyectos de TI en Colombia

La “V Encuesta Nacional de Gerencia de Proyectos de Tecnología de la Información”

publicada por [ACIS, 2007] expone las siguientes estadísticas que enmarcan el estado de los

proyectos de tecnología informática en Colombia:

• Actividades de un proyecto de TI

Las dos principales actividades en las cuales se enfoca los proyectos de TI en Colombia son:

- Especificación de requerimientos (73%)

- Integración de sistemas (53%).

• Factores de fracaso en proyectos de TI

- Mala Planeación: Como es indicado en [Salinas, 2007] el alto porcentaje de fracaso financiero

en proyectos de tecnología informática se debe al mal direccionamiento y enfoque de los planes

de acción 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 planeación.

- Poca y/o mala comunicación

Los miembros del equipo no se comunican o no se ponen de acuerdo en como hacer las cosas.

- Desempeño en el cronograma

La figura 7 representa el desempeño en el cronograma de los proyectos de TI en Colombia.

40

http://www.acis.org.co/fileadmin/Base_de_Conocimiento/V_Jornada_Gerencia/V_Encuesta_Gerencia_Proyectos_TI.pdf

Figura 7. Desempeño 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 métodos de planeación 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 duración total del desarrollo.

- Desempeño en el presupuesto

La figura 8 representa el desempeño en el presupuesto de los proyectos de TI en Colombia.

Figura 8. Desempeño 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 terminación del proyecto y además ajustarse al presupuesto. De esta manera, se

Desempeño en el cronograma de proyectos de TI

27, 27%

3, 3%3, 3%

67, 67%

Proyectos completados ajustándose al cronograma

Proyectos cancelados o abandonados

Proyectos completados adelantándose al cronograma

Proyectos completados por encima del cronograma

Desempeño en el presupuesto deproyectos de TI

12, 12%

42, 42% 6, 6%

40, 40%

Proyectos abandonados

Proyectos completados ajustándose al presupuesto

Proyectos completados sin exceder presupuesto

Proyectos completados con éxito por encima del presupuesto

41

evidencia la necesidad de llevar a cabo una estimación de costos realista además 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 investigación de estas estadísticas,

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 Aproximación a la actualidad de las empresas y áreas de tecnología colombianas

Mediante la aplicación de una encuesta sobre gestión de proyectos (ver Anexo D) a un total de

cinco personas, entre encargados y directivos de áreas de tecnología de empresas de software de

Bogotá, se logró obtener una aproximación de algunos procesos, que relacionados con los temas

de estimación de software y gestión 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 estimación del esfuerzo y tamaño del software? Las empresas o áreas de tecnología comúnmente utilizan el proceso representado en la figura 9

para la estimación del esfuerzo y tamaño. Generalmente de este proceso hacen parte los

gerentes, ingenieros y usuarios finales del producto. A partir del módulo de administración de

requerimientos, el gerente establece una guía (basándose en el producto, tipo de proyecto, tipo

de desarrollo) de los promedios totales de esfuerzo y tamaño para cada fase del proyecto.

Posteriormente, cada estimador realiza la estimación 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 tamaño por cada actividad dependiendo del

tipo de participante (por ejemplo: Estimación gerente de proyecto * 0.6 + Estimación ingeniero * 0.4)

y los resultados son discutidos por el grupo tratando de llegar a un consenso.

42

Figura 9. Actualidad de la estimación del esfuerzo y tamaño en algunas áreas y empresas

Modulo de Administración

de requerimientos

- Producto - Proyecto - Tipo de desarrollo

Criterios Cálculo de los

promedios totales

GUÍA DE LA ESTIMACIÓN

Estimación individual: EXPERIENCIA

- Gerente - Ingeniero - Usuario

Cálculo del esfuerzo y tamaño según el participante

Discusión de resultados y acuerdo.

Valor del esfuerzo total estimado

2.1.2.2 ¿Qué se está usando en la actualidad para la estimación 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.

Figura 10. Actualidad de la estimación de costos

- Hardware - Software - Comunicaciones - Entrenamiento - Logística

Valor HORA PROMEDIO

Valor del esfuerzo total estimado X

2.1.2.3 ¿Qué se está usando en la actualidad para la gestión de riesgos? Las empresas y áreas de tecnología que hicieron parte de esta aproximación no presentan como

tal un proceso específico para la gestión de riesgos, por tanto, ningún participante que hizo parte

de este pequeño estudio respondió a una fuente determinada de manejo de riesgos como la

empleada en su empresa. Sin embargo en la mayoría de los casos se utilizan formatos que hacen

parte del documento de plan de proyecto que acompañan a éste a todo lo largo de su ciclo de

vida y en donde cada actualización generará una nueva versión del plan. El formato para riesgos

de un proyecto contiene de manera común los siguientes elementos: No (número) riesgo,

descripción, fecha de identificación, nombre de quién lo identificó, causas, consecuencias,

probabilidad de ocurrencia, severidad de impacto, estado, estrategia de mitigación, plan de

contingencia, responsable, fecha de cierre.

43

2.1.2.4 ¿Qué se puede concluir acerca de esta aproximación?

A pesar de no contar con metodologías específicas, por ejemplo: puntos de función para el caso

de la estimación o COCOMO para los costos, sí existen procesos establecidos por cada empresa

o área que apoyan las actividades relacionadas con la gestión de proyectos de software. Sin

embargo, en la mayoría de veces dichos procesos hasta ahora se están instaurando y por tanto su

mejoramiento puede tardarse.

Con respecto a la gestión 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 específica dentro del plan del proyecto pero sólo involucrando una descripción 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 tecnología. Los resultados expuestos por la encuesta anual de gerencia de

proyectos y la aproximación 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 estimación y control de calendario.

- El hecho de que hasta ahora se están instaurando estos procesos en las empresas y áreas

tecnológicas 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 sección proyectan el estado de las empresas desarrolladoras de

software en el Reino Unido. La razón 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 caracterización de gestión de proyectos nacional.

Las siguientes estadísticas fueron recolectadas de reportes generados por Standish Group

compañía que publicó los resultados acerca de un estudio desarrollado sobre diferentes

empresas desarrolladoras de software en el Reino Unido.

44

• Desempeño en proyectos de TI

Proyecto abandonados:

- En el año 1995: 53%

- En el año 1999: 46%

- En el año 2003: 51%

• Proyectos terminados con problemas:

- En el año 1995: 31%

- En el año 1999: 28%

- En el año 2003: 15%

• Proyectos terminados con éxito:

- En el año 1995: 16%

- En el año 1999: 26%

- En el año 2003: 34%

• Las estadísticas de las principales causas de fracaso en proyectos de TI según el Standish

Group son:

- Sobrecostos:

En promedio el sobrecosto en el que incurren grandes compañías en sus proyectos de TI es del

178%, mientras que para las medianas y las pequeñas es del 182% y 214% respectivamente.

- Atraso en el cronograma:

En promedio el atraso en cronograma en el que incurren grandes compañías en sus proyectos de

TI es del 230%, mientras que para las medianas y las pequeñas es del 202% y 239%

respectivamente.

Como fue mencionado en la parte introductoria del capítulo, 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 estadísticas 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 planeación adecuada que soporte la mayoría de los proyectos de software que son

emprendidos en Colombia y en otros países.

2.2 PLANTEAMIENTO DEL MODELO PARA LA ESTIMACIÓN DEL TAMAÑO

Esta sección contiene un análisis comparativo sobre las diversas metodologías para la

estimación del tamaño del software con el fin de proponer las bases del modelo a desarrollar en

el capítulo siguiente.

45

2.2.1 Evaluación de métodos para la estimación del tamaño del software

Con el fin de proponer un modelo para la estimación del tamaño basado en las metodologías ya

expuestas para ello, se presenta la siguiente tabla en donde se evalúan las virtudes y defectos de

cada una permitiendo la escogencia adecuada del método que será utilizado en el modelo

propuesto:

Tabla 6. Evaluación de los métodos para estimación del tamaño del software

2.2.2 Método escogido para la estimación del tamaño del software

De acuerdo con los aspectos expuestos en la tabla 6 y considerando el estado del arte de la

estimación de proyectos de software, es posible afirmar que las metodologías son muy variadas

y su uso, mas que depender de lo que ofrecen, depende del entorno y la organización que quiera

implementarlo, así como los procesos de la misma y el método de desarrollo de software que se

utilice.

METODO

DESCRIPCIÓN VENTAJA DESVENTAJA

Conteo de Líneas de Código

Este método toma las líneas de código necesarias para la construcción de un sistema como medida de su tamaño.

-Se basa en el producto del desarrollo de software. -Fácil Conteo

-Dependiente del lenguaje de programación. - Dependiente de los programadores. - Estimación difícil en etapas tempranas del desarrollo.

Estimación basada en la estadística

Este método divide, el sistema en componentes, para así realizar estimaciones sobre cada componente por analogía con otros componentes ya realizados, luego obtienen una estimación pesimista, media y optimista.

-Disminuye la incertidumbre, dividiendo el sistema en componentes. -Se basa en un proceso estadístico, que ofrece un grado de seguridad. -El grado de confiabilidad de las estimaciones se hace mejor a medida que se realicen más estimaciones.

-Si no se cuenta con datos históricos, las estimaciones serán poco confiables. -El método requiere un tiempo para converger en buenas estimaciones.

Estimación Por Lógica Difusa

Este método se basa en estimación por analogía, ya que se toma información histórica del tamaño de diferentes proyectos, y se realizan categorías de tamaño en las que se encasillan los proyectos, luego el nuevo proyecto se encasilla en una de estas categorías, lo cual da un aproximado del tamaño del proyecto.

-Es un método sencillo de aplicar. -Da un rango del tamaño del software, lo que no se compromete del todo con un tamaño exacto

-Depende de la información histórica, de otros proyectos. - El proyecto estimado posiblemente no esté en el rango especificado, lo que podría resultar en una estimación muy alejada de la realidad. Requiere un tiempo de convergencia.

Estimación Por Puntos de Función

Se basa en la funcionalidad del sistema. Para realizar su estimación se deben determinar los componentes de puntos de función para el sistema y clasificarlos según su dificultad.

-Al depender de la funcionalidad del sistema, su aplicación se puede realizar desde la definición de los requerimientos del sistema. -Es Independiente del Lenguaje. -Fácil Utilización.

Es posible que no se encuentren todos los componentes necesarios, lo que daría una estimación equivocada. No es muy adecuado para cuando el software se encuentra construido.

46

De igual manera se aprecia que las técnicas suelen ser muy sencillas, debido a que solo

requieren de una persona para obtener la información del tamaño.

Sin embargo, se dejan de lado muchos aspectos importantes que deben ser considerados en la

estimación, otros métodos utilizan la funcionalidad del software, por ejemplo, para implantar

una debida estimación.

Pensando en la funcionalidad del software y en la facilidad que los puntos de función pueden

aportar a las actividades de estimación del tamaño, este último aspecto también importante

porque atribuye la sencillez o simplicidad que una pequeña empresa de desarrollo necesita de

este tipo de procesos, los puntos de función constituyen el método seleccionado para llevar a

cabo la fase de estimación del modelo a proponer.

2.2.3 ¿Por qué se escogió este método? La característica principal por la que se escogió este método 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 características del proyecto: esta metodología se basa en la

funcionalidad del sistema a implementar y no en el producto a crear.

El método puede ser utilizado en diversas etapas del proyecto, a medida que aumente el

conocimiento acerca del proyecto también aumentará la calidad de las estimaciones, haciéndolas

cada vez más acercadas a la realidad. Otra característica destacable del análisis de puntos de

función, es su dependencia del lenguaje, esto debido a que se basa en la funcionalidad, lo que

hace que esta metodología sea ideal para cualquier tipo de sistema.

2.2.4 Esquema del método de Puntos de función

Para estimar el tamaño de software por puntos de función, se deben encontrar algunos

elementos como las salidas y entradas del sistema y bases de datos/archivos en donde se guarda

la información. Posteriormente se debe encontrar la dificultad de cada componente. Finalmente

mediante la aplicación de una serie de formulas sencillas se obtiene el número total de puntos de

función que componen el software.

2.3 PLANTEAMIENTO DEL MODELO PARA LA ESTIMACIÓN DE COSTOS DEL PROYECTO


estimación del costo del proyecto con el fin de proponer las bases del modelo a desarrollar en el

próximo capítulo. Cabe resaltar en este punto los pasos considerados para realizar una buena

estimación de costos:

47

- Estimación del Costo del Proyecto.

- Estimación del Presupuesto del Proyecto.

- Control del Presupuesto del Proyecto.

También sería conveniente recordar que para estimar el costo de un proyecto se debe conocer el

tamaño del mismo, por lo cual primero se debe estimar el tamaño del proyecto.

2.3.1 Evaluación de métodos y modelos para la estimación de costos

En este campo se encontraron diversas metodologías para la estimación de costos del software a

construir. A continuación se muestra una tabla mostrando las fortalezas y debilidades de cada

una las metodologías que descritas en el capítulo del estado del arte:

METODOLOGÍA DESCRIPCIÓN VENTAJAS DESVENTAJAS

NO ALGORÍTMICOS

Costos por Analogía

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

Si se cuenta con buena información histórica de proyectos pasados, se pueden obtener estimaciones bastante acertadas. Las estimaciones son sencillas de realizar

Se requiere información histórica de proyectos para realizar la estimación. Para que el método sea efectivo se requiere ajustar el método con información de la organización que realiza el proyecto.

Precio a Ganar

Se ajusta el precio del proyecto, para mejorar la propuesta más económica realizada, con el fin de ganar el proyecto.

La estimación se realiza de una manera muy sencilla. Es muy probable que se gane el proyecto.

La estimación muy seguramente está mal, y el costo real estará muy alejado de la realidad. Puede ocasionar que el proyecto lleve a perdidas.

MÉTODOS ALGORÍTMICOS

COCOMO

Modelo empírico para la estimación del esfuerzo y costo del desarrollo de un sistema de software, se basa en el uso de multiplicadores de esfuerzo, para realizar una estimación 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 utilización a lo largo de todo el proyecto.

Predisposición por parte del equipo de gestión ante la utilización de fórmulas matemáticas. Es un proceso extenso para completar la estimación Algunos factores son algo complicados de determinar.

SLIM

Se basa en la distribución de poder hombre, se usa la ecuación de software, en donde se relaciona, el tiempo de entrega, factores ambientales, en los cuales se refleja la capacidad de desarrollo de la compañía

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

Predisposición por parte del equipo de gestión ante la utilización de fórmulas matemáticas. Es un proceso algo largo, para completar la estimación

Tabla 7. Evaluación de los métodos para la estimación de costos De acuerdo con la tabla 7 se evidencia un amplio rango de metodología para la estimación del

costo, y cada uno con características diferentes, que los hacen aplicables en diferentes entornos.

48

Existen metodologías 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 estimación

seria.

De igual manera existen metodologías más complicadas que utilizan modelos empíricos y

matemáticos para estimar el costo de un software, evaluando a su vez, una serie de factores

concernientes al tamaño del software, a la organización, experiencia en esta clase de proyectos,

etc.

2.3.2 Modelo escogido para la estimación de costos

En el caso de la estimación de costos se escogió como metodología COCOMO II, aunque esta

es un tanto complicada, debido a la utilización de varias formulas que estiman el costo de un

proyecto, cuenta con la ventaja de usar para su estimación un amplio dominio de factores que

inciden sobre el costo del proyecto, tales como: retrasos en el cronograma, pérdida 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 estimación inicial se usaría el modelo de

composición de aplicaciones , en una etapa más avanzada del proyecto, se podría utilizar el

modelo de diseño anticipado, y en el momento que se encuentren diseñada la arquitectura del

proyecto, se podría 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

composición de aplicaciones es mucho más sencillo que el de diseño anticipado y

postarquitectura, de igual manera las calidad de las estimaciones aumenta cuando se usan

métodos mas complicados.

Para este modelo se usará el modelo de diseño anticipado, ya que es un modelo adecuado para

realizar estimaciones en las que se tienen en cuenta varios parámetros que inciden en gran parte

en el costo de un proyecto, y a su vez disminuye la dificultad para realizar estas estimaciones,

adicionalmente se desarrollarán plantillas para la realización estas estimaciones, con lo que se

disminuirá en gran medida la dificultad en la aplicación del método.

2.4 PLANTEAMIENTO DEL MODELO PARA LA ESTIMACIÓN DEL PRESUPUESTO


estimación del presupuesto del proyecto con el fin de proponer las bases del modelo a

desarrollar en el capítulo 3.

49

2.4.1 Evaluación de métodos para la estimación del presupuesto

De acuerdo con [Boehm, 1999] la estimación del presupuesto depende de muchos aspectos

relevantes a cada organización, a cada proyecto y tipo de proyecto a realizar, lo cual hace que

mas que existir metodologías para estas estimaciones, existen consejos de sobre qué aspectos

evaluar al momento de realizar esta estimación.

Para efectos de este trabajo no se usará ninguna técnica para estimar el presupuesto del

proyecto, ya que la estimación del costo del proyecto, se hace en base a la división del trabajo

propuesta en la fase de requerimientos, es decir la estimación 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 continuación se

presentará una evaluación de estas formas en las que se realiza la estimación del presupuesto. METODOLOGÍA DESCRIPCIÓN VENTAJAS DESVENTAJAS

Bottom Up En este método, las

estimaciones se realizan

al nivel de tareas, cada

tarea se estiman los

aspectos del presupuesto

necesarios

Al ser estimaciones al

nivel de tarea, se tiene

menor riesgo en estimar

el presupuesto de todo el

proyecto de manera

errónea.

Requiere de un mayor

tiempo de estimación, ya

que para cada tarea se

debe realizan un

estimación de presupuesto

Top Down En este método una

persona encargada de las

estimaciones, realiza la

estimación para todo el

proyecto, y basándose en

esta estimación se

realizan las estimaciones

para las diferentes tareas.

Las estimaciones pueden

ser realizadas por varias

personas

simultáneamente,

dependiendo de la

división del trabajo

propuesta.

Al depender la estimación

de todo el presupuesto de

una estimación global, es

mucho más factible que la

estimación de todas las

tareas en conjunto sea

errónea.

Estimación por Fases En este método las

estimaciones se hacen

según 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 combinación de los

métodos anteriores para

realizar estas

estimaciones.

Como ventaja este

método provee, que las

estimaciones se realizan

en un momento en el que

se sabe que se va estimar,

y se tienen información

de las fases anteriores

para mejorar la

estimación.

Las estimaciones no son

tan grandes, por lo que

solo se estima una fase

del proyecto a la vez.

Como desventaja se tiene

que al no realizar un

estimación clara del total

del proyecto, nunca se

conoce en realidad cuanto

es el costo del proyecto,

lo que no es muy

conveniente al realizar un

contrato.

Tabla 8. Evaluación de métodos para la estimación del presupuesto de un proyecto

50

2.4.2 Método escogido para la estimación del presupuesto El método 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 especificación de requerimientos establecida.

De igual manera, suministra un apoyo importante para las pequeñas empresas de software

teniendo en cuenta que una de sus principales actividades (ver sección 2.1) consiste en la

especificación de requerimientos y de esta manera se podría garantizar aun más su

cumplimiento dentro de su presupuesto estipulado.

2.5 PLANTEAMIENTO DE UNA METODOLOGÍA PARA EL CONTROL DEL PRESUPUESTO


estimación del presupuesto del proyecto con el fin de proponer las bases del modelo a

desarrollar en el capítulo siguiente.

En cuanto a las metodologías para el control del presupuesto éstas tienen como base la

comparación de lo transcurrido con lo planeado. Al usar estas comparaciones se puede

determinar el progreso de un proyecto, y qué tan bien se ha desempeñado el desarrollo del

mismo.

Las diferencias entre los métodos estudiados para el control del presupuesto residen en el nivel

de detalle con el que realizan las comparaciones, en el caso del primer método se compara el

presupuesto total del proyecto con lo gastado a la fecha del proyecto y para el segundo método,

se realiza por actividad propuesta del proyecto una comparación que incluye además de lo

gastado una serie de aspectos adicionales acerca del desempeño que ayuda a los gerentes a tener

un mayor control del desempeño del proyecto.

2.5.1 Evaluación de métodos para el control del presupuesto

Ahora se procederá a realizar la evaluación de los métodos más importantes para el control del

presupuesto, y se expondrán las ventajas y desventajas de cada método.

51

METODOLOGÍA DESCRIPCIÓN VENTAJAS DESVENTAJAS

Seguimiento del Plan de

gastos

En este método se deben

tener claro lo que se ha

gastado en el desarrollo

del proyecto, ya que esto

se compara con lo que

debía haber gastado, en

el momento de realizar

la comparación, con

estos dos valores se

obtiene una medida que

indica si se está

desfasado en costos, o si

está acorde con el

proyecto, o si por el

contrario se ha gastado

más de lo planeado.

Es un método fácil de

usar, ya que sólo

requiere el

conocimiento de dos

valores. Adicionalmente

es fácil de entender ya

que la información que

provee es clara, y puede

incluir la funcionalidad

de agregar una gráfica

con el desempeño del

proyecto en costos.

Al solo proveer una

métrica acerca del

desempeño en cuanto

costos del proyecto, hay

mucha más información

relevante que no es

analizada.

La gráfica de este

método no es muy

adecuada para proyectos

grandes, ya que no

muestra toda la

información requerida.

Análisis del Valor

Ganado

Este método intenta

evaluar varios factores

de desempeño en cuento

al costo del proyecto,

esto lo hace mediante

diversas métricas que

básicamente compararán

lo invertido en el

proyecto con lo gastado

en el mismo.

Ofrece diversas métricas

para la evaluación del

desempeño en cuanto a

los costos del proyecto.

Estas métricas evalúan

múltiples aspectos del

proyecto, que dan un

mayor control sobre el

proyecto

Predisposición por parte

del equipo de gestión

ante la utilización de

fórmulas matemáticas.

Tabla 9. Evaluación de las metodologías para el control del presupuesto De acuerdo con la tabla 9 la diferencia entre los métodos anteriores se encuentra en el nivel de

detalle de éstos, y la decisión de escoger uno u otro para un proyecto depende del tamaño del

mismo, ya que para un proyecto pequeño el primer método es ideal, al no ser complicado y

podría dar una buena visión del desempeño del mismo, en cuanto al segundo método es ideal

para proyectos más grandes, en donde se requiere un mayor control del desempeño del proyecto.

2.5.2 Método escogido para el control del Presupuesto

Para el caso del control del presupuesto fue seleccionado el método de análisis del valor ganado,

ya que incluye una evaluación mucho más profunda acerca del desempeño de un proyecto, y

aunque no es la metodología para el control de costos más fácil de usar, no es complicada del

todo, además de ofrecer excelentes resultados.

Su operación consiste en la evaluación de una serie de métricas a partir de lo que se ha invertido

en el proyecto y lo que se había planeado invertir, con estos datos se puede obtener información

52

muy valiosa, la cual permite a los gerentes de proyecto tener una visión clara acerca del

proyecto.

2.6 PLANTEAMIENTO DEL MODELO DE GESTIÓN DE RIESGOS

Con base en la literatura estudiada se planteó una metodología de gestión de riesgos (Figura 13),

enseguida se explican las razones por las cuales esta metodología fue la planteada para la

propuesta de este modelo.

2.6.1 Principios básicos en los cuales debería basarse una metodología de gestión de riesgos

Un primer criterio utilizado para la selección de la metodología los constituyó el grupo de

principios básicos en los cuales se debe basar la metodología de gestión de riesgos. La figura 11

muestra algunos de los principios fundamentales sobre los cuales debería basarse un proceso de

gestión de riesgos de acuerdo con la propuesta de [Microsoft, 2002]:

PRINCIPIOS BÁSICOS

DE LA GESTIÓN DE

RIESGOS

Agilidad

Participación necesaria

Reconocimiento de la necesidad de

gestionar

Potenciar la comunicación

Administración de riesgos de manera proactiva a través de todas la fases del proyecto, ya que los cambios efectuados en cualquiera de ellas, implican cambios a nivel de riesgo también.

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

El proceso de gestión de riesgos debe ser responsabilidad de todos los miembros del equipo. De igual manera cada uno debe asumir la responsabilidad de las tareas específicas que le son asignadas.

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 básicos de un proceso de gestión de riesgos

2.6.2 Requisiciones de una metodología de gestión de riesgos

El segundo criterio determinante para la selección de la metodología los constituyó el grupo de

requisiciones que debe cumplir una metodología de gestión de riesgos. Según [Motorola LMPS,

1999] a nivel organizacional una política de gestión de riesgos debería considerar por lo menos

los siguientes aspectos:

53

REQUISICIONES PARA UNA

METODOLOGÌA DE GESTIÓN DE

RIESGOS

o Todos los riesgos relacionados con los proyectos de desarrollo deben ser identificados, analizados priorizados y revisados siguiendo un plan de gestión de riesgos.

o Como consecuencia de los constantes cambios, la lista de los riesgos y la información relacionada con su estado actual e historia reciente , deben ser mantenidos en una Base de Datos de Riesgos de Proyecto separada.

o La información contenida en la Base de Datos de Riesgos debe ser utilizada para acrecentar la información contenida en una Base de Datos de Riesgos Organizacional.

Figura 12. Requisiciones para una metodología de gestión de riesgos

Con base en los principios básicos y los requerimientos de una metodología de riesgos (Figuras

11 y 12) se planteó la siguiente metodología para la gestión de riesgos:

Preparación para la Gestión

Identificación del riesgo

Respuesta al riesgo

Control de repuesta al riesgo

Cuantificar y cualificar los riesgos

Aprendizaje

Comunicación

Figura 13. Metodología de gestión de riesgos para el modelo

2.6.3 ¿Por qué se escogió esta metodología?

• Una de las razones fundamentales es que cubre la totalidad de las fases que en las que se

desarrollan los métodos de gestión de riesgos en la actualidad (ver Figura 1).

• De acuerdo con las requisiciones para una metodología de riesgos cabe resaltar la necesidad

de aprendizaje que todo el proceso puede y debe generar entorno a la identificación 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 caracterización de los proyectos de TI en Colombia realizada en este

trabajo, es clara la necesidad de mantener una comunicación abierta entre los miembros del

equipo de proyecto. La comunicación se debe generar también en esta parte de gestión de

riesgos y no sólo en las fases del modelo de desarrollo establecido.

2.6.4 Fases o pasos de la metodología

La descripción de las fases y de las actividades que se desarrollan en la metodología para la

gestión de riesgos seleccionada se menciona a continuación.

2.6.4.1 Fase de Preparación para la gestión de riesgos

La preparación se propone una como una fase previa a la identificación con el fin de limitar el

marco de las fuentes y categorías 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

categorías a las que los riesgos, más adelante identificados, se podrían asociar.

• Identificación 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 evaluación, que de manera eventual,

permitirá observar los cambios producidos a través 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 organización o empresa donde el proyecto tiene lugar por tanto dicha fuente

ya no será productora de riesgos en el proyecto y de manera recíproca el riesgo podría

desaparecer.

Uno de los estudios desarrollados en este trabajo encontró que las fuentes más comunes de

riesgos en los proyectos de desarrollo de software son los mostrados en la figura 14:

Requerimientos inciertos

Estimaciones erróneas

Tecnología no disponible

Asignación irrealista de recursos

Capacidad incierta de proveedores

Fuentes de riesgos

Figura 14. Fuentes de riesgos del modelo

55

Este modelo, con el fin de definir un marco específico de fuentes de riesgos para todos los tipos

de proyectos de software, se acoge a esta lista de fuentes de riesgos basada en la investigación

desarrollada por [Maniasi, 2005] para su tesis de magíster.

• Identificación de categorías del riesgo: surgen con el objetivo de agrupar los riesgos que más

adelante van a ser identificados. Las categorías del riesgo del proyecto deben ser clarificadas al

inicio de la gestión con el fin de caracterizar diferentes marcos comunes en dónde cada riesgo

será clasificado: por tal razón hace parte de la fase de preparación de la metodología planteada.

La categorización de los riesgos permitirá generar una búsqueda apropiada de aquellos que

puedan tener mayores consecuencias sobre el logro de las metas del proyecto [Maniasi, 2005].

El modelo establece tres categorías del riesgo como un mecanismo para clasificar y organizar

los riesgos pensando en la futura fase de identificación (Figura 15)

Categorías del riesgo

Riesgos técnicos

Riesgos de proyectos

Riesgos de negocio

Los problemas más comunes en riesgos técnicos son [ESII, 2001]:

- De Diseño - De Implementación - De Interfaz - De Verificación y mantenimiento - Clientes y requisitos.

Los problemas más comunes [ESII, 2001] en proyectos se dan por variaciones en:

- Presupuesto - Personal - Planificación - Recursos

Las clases de riesgo de negocio son [ESII, 2001]:

- De Mercado - Estratégico - De Comercialización - De Dirección - De presupuesto

Figura 15. Categorías relacionadas con la identificación de riesgos en proyectos de software. A continuación se da una breve descripción de cada una de las categorías:

- Riesgos de proyecto: Inherentes al plan de proyecto. Para el modelo se consideran dos

específicamente:

a. Riesgos en calendario: eventos que generan retrasos en la terminación de actividades y

también, pueden generar retraso en la terminación 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 técnicos: son aquellos aspectos o eventos asociados con la definición del alcance del

proyecto que podrían afectar el nivel actual de funcionalidad del sistema con respecto a la

misión requerida y el análisis de requerimientos documentado.

- Riesgos de negocio: Riesgos que afectan la viabilidad de negocio del software desarrollado.

2.6.4.2 Fase de identificación del riesgo

De acuerdo con [Maniasi, 2005] quizás el aspecto más importante en la etapa de identificación

sea el hecho de capturar tantos riesgos como sea posible; de esta manera, pensando en la

definición de una técnica para identificación de riesgos conforme a este criterio, se desarrolló un

breve estudio comparativo de los diversos tipos de técnicas para la identificación de riesgos,

expuestos en el estado del arte. La Tabla 10 enuncia las ventajas y desventajas de cada una de

las técnicas tratadas: TÉCNICA

VENTAJA DESVENTAJA

Lluvia de ideas

- Al ser un método no estructurado permite evidenciar posibles riesgos de cualquier fuente y descripción.

- 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.

- Puede que para el momento de la reunión 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

- Permite prever no sólo la descripción 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.

- No todas las organizaciones cuentan con una documentación específica o base de datos de los riesgos y su manejo en otros proyectos similares.

Encuestas

- Es posible obtener una gran variedad de opiniones sin tener la necesidad de organizar una reunión donde, seguramente, no todos los participantes convocados podrán estar presentes.

- Generalmente las personas suelen tener poco interés en contestar una encuesta lo cual puede generar respuestas inapropiadas.

- La evaluación de las respuestas puede tornarse difícil por su carácter subjetivo.

Taxonomías

- Permite obtener un amplio rango de riesgos permitiendo destacar también aquellas áreas que requieran de mayor atención por parte del equipo de proyecto.

- En la fase de identificación 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 terminología unificada que el equipo de proyecto puede utilizar para supervisar y notificar el estado de los riesgos [Microsoft, 2002].

Carece de una clasificación del dominio de los riesgos siendo éste todavía muy extenso para tenerlos todos en cuenta en la fase de identificación.

Tabla 10. Comparación de las técnicas para la identificación de riesgos

Por otro lado, se declaran ciertas asunciones sobre las cuales debe estar basado un método para

la identificación de riesgos [Marvin J. Carr et al., 2003]:

57

Asunciones básicas de una técnica para la identificación de riesgos

- Repetible y estructurado: con el fin de alcanzar una gestión consistente del riesgo.

- Cubrimiento de todas las

áreas clave del proyecto

- El número de riesgos identificados no debe ser un factor usado para predecir el éxito o fracaso del proyecto.

Figura 16. Asunciones básicas de un método para la identificación de riesgos.

• Selección de la técnica de identificación basada en taxonomías

Tanto las asunciones básicas con las que debe contar una técnica de identificación de riesgos y

el estudio comparativo mostrado en la tabla 10 constituyeron los criterios clave para seleccionar

la técnica de identificación basada en taxonomías como la que apoyará la fase de identificación

de este modelo propuesto. Asimismo era evidente la necesidad de implantar una metodología

que permitiera reconocer un amplio rango de riesgos.

Es necesario, por tanto, ampliar la información referente a esta técnica. A continuación se

exponen los aspectos y conceptos más importantes de ésta.

• Identificación de riesgos basada en taxonomía

Fue desarrollado en primera instancia por el SEI [Marvin J. Carr et al.., 1993] agrupando

diferentes fuentes y categorías de riesgos comunes proyecto de desarrollo de software.

La taxonomía agrupa los riesgos en tres niveles:

- Primer Nivel: Clases

a. Ingeniería del producto: comprende aquellos riesgos relacionados con el aspecto técnico del

proyecto.

b. Entorno de desarrollo: riesgos relacionados con los métodos, 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 según el elemento de acuerdo con un cuestionario (Cuestionario basado

en taxonomía [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 gestión.

Figura 17. Taxonomía 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].

• Delimitación del dominio

Una de las desventajas de la técnica para identificación de riesgos basada en taxonomía la

constituye precisamente el extenso dominio de los riesgos que se pueden reconocer, puede

resultar complejo realizar el análisis por cada elemento de las clases y aun más responder el

cuestionario establecido por cada uno de los atributos que constituyen los elementos.

• ¿Cómo delimitar el dominio de los riesgos?

Este modelo propone la delimitación del dominio de los riesgos correspondiendo la definición

de cada clase de la técnica basada en taxonomías con la base estadística 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 identificación?

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 especificación de requerimientos, estos

59

constituyen una de las actividades en las que más se fundamentan los proyectos de desarrollo y

por ende deben recibir el tratamiento que en cuestión de gestión de riesgos corresponde.

La delimitación del modelo se muestra en detalle en el capitulo 4 del modelo propuesto

• Categorización de los riesgos identificados

Este trabajo propone también un grupo definido de categorías como resultado del estudio

efectuado en el estado del arte. Conforme a las tres categorías establecidas (fase de preparación

para la gestión del riesgo) el conjunto de los riesgos identificados se unirá a cualquiera de las

tres atendiendo a la definición con la que cada categoría cuenta (sección de preparación para el

riesgo). De esta manera, la categorización, propuesta en este modelo, con base a los riesgos

identificados se ilustra en la figura 18:

RIESGOS DE PROYECTOS

RIESGOS TÉCNICOS

RIESGOS DE NEGOCIO

En esta categoría deben clasificar los riesgos relacionados con problemas en: presupuesto, personal, planificación, recursos.

En esta categoría debe clasificar los riesgos relacionados con problemas en: diseño, implementación, interfaz, verificación, mantenimiento, clientes y requisitos.

En esta categoría debe clasificar los riesgos relacionados con problemas en: mercado, estrategia, comercialización,

esupuesto de mercadeo. pr

CATEGORÍAS

Figura 18. Categorización de riesgos identificados • El resultado de la identificación del riesgo

Con el fin de facilitar el entendimiento y comunicación de los riesgos es necesario recopilar la

información más importante por cada riesgo identificado del proyecto como resultado de esta

fase de identificación del modelo. El siguiente capítulo específica un formulario de información

destinado para este fin.

2.6.4.3 Cuantificar y cualificar los riesgos

Esta fase emplea dos tipos de análisis para la cuantificación y cualificación de riesgos de

acuerdo con su categoría.

60

Análisis cuantitavito

Análisis cualitativo

Riesgos asociados al proyecto

Riesgos técnicos

Riesgos de mercado

Cualificar

Cuantificar

Figura 19. Tipos de análisis y categorías del riesgo De acuerdo con la figura 19 los riesgos categorizados como técnicos o de mercado serán

analizados cualitativamente, mientras que los riesgos asociados a la categoría de proyectos serán

analizados cuantitativamente.

• ¿Por qué esta división de análisis para las categorías de riesgos?

De acuerdo con la definición que en el estado del arte recibe el análisis cuantitativo, son los

riesgos que pueden generar los problemas en calendario, costo/presupuesto, recursos, etc., los

que deben cuantificarse a través de este tipo de análisis: el calendario a través de las duraciones

de cada una de sus actividades, mientras que el costo/presupuesto mediante la descomposición

de la estructura del trabajo que para el caso de este modelo viene dada por los requerimientos

del proyecto.

Los riesgos técnicos 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 también son aplicables al análisis

cuantitativo. La diferencia con el método cualitativo es el método a través 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 combinación de su

probabilidad e impacto estará definido de acuerdo con el siguiente gráfico:

Probabilidad / Impacto Mínimo Bajo Medio Severo Crítico Remoto Improbable Media Posible Muy Probable

Figura 20. Niveles de prioridad de riesgos

61

- Prioridad alta: cualquiera de las combinaciones dadas entre el siguiente conjunto de duplas

(probabilidad-impacto):

Posible Severo

Muy probable Crítico

Media Crítico

Posible Crítico

Muy probable Severo

- Prioridad media: Comprende las siguientes combinaciones (probabilidad-

Media Medio, Severo

Posible Medio

Muy probable Mínimo, Bajo, Medio

Improbable Crítico

- Prioridad baja: Comprende la siguiente combinación (probabilidad-impac

Remoto Mínimo, bajo, medio, severo, critico

Improbable Mínimo, bajo, medio, severo

Media Mínimo, bajo

Posible Mínimo, bajo

a

• Proceso de análisis cuantitativo

- Entradas

El análisis cuantitativo usa como entrada una red de actividades, en el cas

riesgos en calendario, y en la descomposición de la estructura del traba

riesgos en costo. La construcción de la red de actividades generalme

Microsoft Project.

El análisis cuantitativo se basa principalmente en el hecho de que exis

entorno al proyecto que podría ocasionar, por ejemplo, que una actividad

tiempo de lo planeado, o costar más (o menos) dinero que lo presupuestado

• Software para el análisis cuantitativo del modelo

El software destinado al análisis cuantitativo de proyectos, como Monte Ca

modelo, permite definir diferentes distribuciones de probabilidad para

proyecto y generar simulaciones para poner a prueba el comportamien

distintas condiciones.

Nivel alto de amenaz

impacto):

to

o

j

n

te

.

r

to

Nivel mediode amenaza

):
Nivel bajo deamenaza
de la estimación de

o en el caso de los

te se realiza sobre

una incertidumbre

dure más (o menos)

lo en el caso de este

las actividades del

del proyecto bajo

62

• Proceso de análisis cualitativo

Como se mencionó anteriormente y en el estado del arte el análisis cualitativo se encuentra

diseñado 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 consideración de que la falta de comunicación constituye uno de

los factores de fracaso de proyectos de TI en Colombia, resultaría poco sensato reunir a todos

los miembros del equipo para que en una sola sesión se llegue a un acuerdo sobre la priorización

de los riesgos.

Por tal razón para este proceso el modelo plantea la utilización del método 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 formulación de planes de acción (planes de riesgo) para responder a los riesgos

en alta prioridad y otros analizados en la fase de cuantificación y cualificación. Este modelo

puede emplear cualquiera de las formas de expuestas en la fase de planificación 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 planificación 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 información 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. Categoría: nombre de la categoría a la cual fue asociado el riesgo identificado.

c. Descripción: breve caracterización del riesgo

d. Fuente: nombre del indicador que señala que el riesgo puede ocurrir en cualquier momento.

Se refiere a la misma definición de fuente de riesgo otorgada en la fase de preparación de la

metodología.

e. Tipo de plan de riesgo: el tipo de plan de acción 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, adquisición de conocimiento>

f. Estado del plan de riesgo: lista de posibles estados de un plan de riesgo según 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 máxima para finalización 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

surgirían 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

cuantificación y cualificación, fueron evaluados como de alta prioridad o alto nivel de amenaza.

FORMULACIÓN DE PLANES DE RIESGO

RIESGOS ALTA PRIORIDAD

BASE DE APRENDIZAJE

DE RIESGOS

RIESGOS PRIORIDAD BAJA

RIESGOS PRIORIDAD MEDIA

Formulario de plan de riesgo de la metodología

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 metodología se apoyará sobre los siguientes conceptos:

- Estado del plan de riesgos tal y como lo presenta [Maniasi, 2005].

- Métricas obtenidas desde la estimación de costos.

- Estado de la fuente o disparador del riesgo.

Luego de verificar la respuesta al riesgo la metodología estará en la capacidad de decidir si el

plan de riesgo requiere revisiones o ajustes.

• Proceso de control y seguimiento

ESTADO PLAN DE RIESGO

MÈTRICAS

VERIFICACIÓN Y CONTROL DEL PLAN DE RIESGO

AJUSTES Y REVISIÓN DE

PLANES SI APLICA

FUENTES DE RIESGOS

Figura 23. Proceso de control de respuesta al riesgo.

2.7 Resultados del capítulo

En este capítulo se definieron los métodos, metodologías y herramientas que fueron

seleccionadas para ser usadas en cada uno de los pasos del modelo propuesto tanto para la

estimación del tamaño como para la gestión de costos y riesgos. Para ello se evaluaron cada una

de estas metodologías o herramientas enumerando sus ventajas y desventajas a través de las

siguientes tablas: evaluación de los métodos para la estimación del tamaño del software (tabla

6), evaluación de los métodos para la estimación de costos (tabla 7), evaluación de los métodos

para la estimación del presupuesto del proyecto (tabla 8), evaluación de metodologías para el

control del presupuesto (tabla 9) y se realizó un énfasis especial sobre la gestión de riesgos y la

comparación de las técnicas para la identificación de los mismos (tabla 10).

Así fue posible establecer los principios, requisiciones y asunciones básicas para una

metodología de gestión de riesgos (figuras: 11, 12 ,16). Por último se definieron las fuentes y

categorías de los riesgos que establece el modelo (figuras: 14 y 5).

65

3. MODELO PARA LA ESTIMACIÓN Y GESTIÓN DE PROYECTOS

Este capítulo expone cada uno de los pasos planteados por el modelo para llevar a cabo los

procesos de estimación y gestión de costos y riesgos, basándose para ello en las metodologías,

herramientas y métodos, seleccionados en la propuesta conceptual, tras la evaluación de sus

ventajas y desventajas y teniendo en cuenta los criterios de clasificación especificados.

De igual manera el Anexo B contiene un caso práctico en donde se documenta el desarrollo y

resultados de la aplicación experimental de este modelo.

A continuación se explican los pasos que contempla el modelo. Dando a conocer por cada

uno sus entradas, salidas, procesos y actores que los integran

Estimación del tamaño

Estimación del costo y presupuesto

Gestión de riesgos

Requerimientos funcionales

Tamaño en puntos de función

Costo total por requerimiento

Duración total del proyecto

Plan de control de riesgos.

Control del presupuesto

Formulario de estimación del tamaño

Formulario de estimación de

Figura 24. Pasos del modelo propuesto Con base en la figura 24, los primeros tres pasos (Estimación de tamaño, esfuerzo y costo) son

secuenciales y cada uno se explica con más detalle a continuación. La gestión de riesgos puede

iniciarse de manera paralela a los tres primeros pasos. Sin embargo, es importante destacar, que

utiliza los datos obtenidos de la estimación de costos para llevar a cabo un análisis cuantitativo

de riesgo en costo (Figura 24). De igual manera, puede utilizar algunas métricas del proceso de

gestión 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 metodología de gestión de

riesgos propuesta se implementará como un paso posterior a la de gestión de costos.

3.1 PASO I: DEFINIR LOS REQUERIMIENTOS FUNCIONALES DEL PROYECTO

3.1.1 Proceso de definición de requerimientos

Este proceso comprende desde el conocimiento de los requerimientos funcionales del proyecto

hasta su especificación utilizando la plantilla propuesta por la IEEE2. Especialmente para el caso

de estudio donde se muestra la aplicación práctica del modelo (Anexo B) fue utilizada la

plantilla para Especificación de Requerimientos de Volere3.

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

Descripción del proyecto y especificación de requerimientos

Especificación de los requerimientos funcionales

Descripción formal del proyecto

Figura 25. Proceso para la definición de los requerimientos

ENTRADAS SALIDAS PROCESOS DESCRIPCIÓN

- Descripción del proyecto. - Especificación de los requerimientos funcionales utilizando la plantilla de Volere.

Descripción del proyecto y de sus requerimientos funcionales.

Descripción formal del proyecto

La especificación de los requerimientos puede hacerse utilizando la plantilla Volere2.

Tabla 11. Elementos del proceso para la definición de requerimientos

3.1.2 Descripción del proyecto y especificación de los requerimientos Es importante contar con una descripción detallada del proyecto y las funcionalidades que debe

implementar. Para ello es necesario que el proyecto sea descrito de la manera más clara y

completa posible y que se especifiquen los requerimientos que deben ser implementados. Para

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

67

la especificación de cada uno de los requerimientos del proyecto se sugiere diligenciar la

plantilla propuesta por Volere2.

NOTA: La descripción del proyecto puede ir contenida en la plantilla para la especificación de

los requerimientos, sin embargo, sería conveniente contar con una descripción global previa a la

especificación.

3.2 PASO II: ESTIMAR EL TAMAÑO DEL SOFTWARE

3.2.1 Modelo para la estimación del tamaño

El siguiente esquema muestra las entradas y salidas que involucra el proceso para la estimación

del tamaño del software como segundo paso de este modelo.

Categorización – determinación: componentes de Puntos de Función

Información de entrada

Estimación del tamaño por requerimiento

Requerimientos Funcionales

Lista priorizada de los elementos de puntos de función

Cálculo del total de puntos de función

Figura 26. Esquema del Modelo de estimación del Tamaño A continuación se explica de manera más formal las entradas, salidas y proceso para la

estimación del tamaño del software.

Para realizar estas estimaciones se utilizará la metodología del análisis de puntos de función, y

mediante ésta se medirá el tamaño del software a implementar a través de los componentes

funcionales que deba manejar el sistema en desarrollo.

En el caso de este modelo la estimación del tamaño se realizará por requerimiento

contribuyendo con una estimación mucho mas detallada.

Para facilitar la utilización de esta parte del modelo se diseñó un formulario para la estimación

del tamaño, el cual será expuesto en las siguientes secciones.

2 Volere Requirements Specification Template. Página consultada [Junio 2005]. Disponible en Internet: <http:// http://www.volere.co.uk/template.htm>

68

3.2.1.1 Entradas del Modelo

• Especificación de requerimientos del proyecto: estos son las funcionalidades que el

software debe realizar, esta especificación debe ser lo más formal con el fin de que las

estimaciones realizadas se acerquen a la realidad del proyecto.

• Información de Sistemas Externos: esta información hace referencia a toda la información

del entorno donde funciona el software que se esta planeando, esta información consiste en:

- Bases de datos que utiliza.

- Otras fuentes de datos requeridas por el software.

- Sistemas externos con los que interactúa.

3.2.1.2 Salidas del Modelo

• Tamaño del software a implementar para los requerimientos planteados: Este resultado

representa la medición en puntos de función del tamaño de cada uno de los requerimientos que

componen el proyecto al cual se le está aplicando el modelo.

Como ayuda para la aplicación del modelo de estimación del tamaño se diseñó el Formulario

para la estimación del tamaño con Puntos de Función (ver Anexo A) sobre el cual se diligencia

la información del tamaño de cada uno de los requerimientos del proyecto.

Ahora que ya se han mencionado las entradas y salidas del modelo para la estimación del

tamaño, se procede a describir el proceso con el cual se estimara el tamaño de cada uno de los

requerimientos del proyecto en estimación.

1. Identificar los componentes funcionales necesarios para la estimación del tamaño.

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 función, según la categorización de los elementos funcionales

encontrados.

Cabe recordar que esta estimación del tamaño 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 metodología de puntos de función requiere que se identifiquen una seria de componentes

funcionales los cuales proporcionan información acerca de la complejidad de un sistema de

69

software, para este caso la complejidad de implementar un requerimiento, a continuación se

explican en mas detalle estos componentes.

• Archivos Lógicos Internos (ILF): Estos componentes representan información relacionada

lógicamente o reconocida por el usuario que es manejada por la aplicación, es decir un

repositorio de datos manejado por la aplicación.

• Archivos de Interfase Externos (ELF): Este componente representa un grupo de datos

relacionados lógicamente o información de control reconocida por el usuario y referenciada

pero mantenida por otra aplicación, es decir repositorios de datos manejados por otra

aplicación.

• Entradas Externas (EI): Este componente representa un proceso elemental o una acción que

procesa datos o información de control que vienen desde afuera de la aplicación hacia adentro,

la información pude venir desde una pantalla u otro sistema.

• Salidas Externas (EO): El componente representa un proceso elemental o una acción que

envía datos o información de control hacia fuera de la aplicación, en este procedo debe estar

involucrado algún tipo de procesamiento lógico 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 acción que envía

datos o información de control hacia fuera la aplicación, el propósito de esta operación es

presentar datos tal cual se encuentran en la aplicación, sin ningún procesamiento lógico.

Los componentes identificados por cada uno de los requerimientos son los que deben ser

implementados en el proyecto. Dicha identificación debe ser diligenciada en el Formulario para

la estimación del tamaño con Puntos de Función (ver Anexo A), este formulario cuenta con una

tabla por cada uno de los componentes de puntos de función 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 función por requerimiento.

Posteriormente en cada una de las tablas se señala los componentes que se relacionan con cada

requerimiento.

Luego de relacionar cada componente de puntos de función con uno o más 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 función, al determinar esta dificultad se puede estimar el número de

puntos de función para implementar cada componente.

La dificultad de implementar cada uno de los componentes de puntos de función se determina,

encontrando el numero de elementos de datos que se maneja en cada uno de estos componentes,

los tipos de elementos de datos varían dependiendo del componente, a continuación se clasifican

los componentes de datos por componente, esto clarificara que se debe identificar al evaluar la

dificultad de implementación para cada componente.

• Archivos Lógicos 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 lógicamente que se encuentren en el repositorio de información, un ejemplo

de esto seria el conjunto de DET que representen una dirección.

• 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 aplicación, 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

están involucrados en el desarrollo de la transacción del componente, estos repositorios son lo

que se identificaron anteriormente, como un ejemplo se puede tomar una transacción 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

función, se debe realizar dicha categorización, para esto se prosigue a diligenciar el numero de

elementos identificado para cada elemento de puntos de función en el Formulario para la

estimación del tamaño con Puntos de Función (ver Anexo A), esto se realiza diligenciando el

numero de elementos de clasificación para cada componente luego de la sección de

requerimientos.

Los elementos de puntos de función son clasificados dependiendo del número de elementos

identificados para cada uno en 3 categorías Alto, Medio, Bajo, para obtener las categorías a

partir del número de elementos se deben seguir las siguientes tablas.

• Archivos Lógicos Internos y Archivos de Interfase Externos: Para identificar la complejidad

de estos componentes se sigue esta tabla.

Tabla 12. Determinación de la dificultad de implementación para ILF y ELF [Boehm, 1999]

• Entradas Externas: En el caso de las Entradas Externas se usa la siguiente tabla para

determinar la complejidad de implementación de estos componentes.

Tabla 13. Determinación de la dificultad de implementación para EI [Boehm, 1999]

• Salidas Externas y Consultas Externas: Para determinar la dificultad de implementación

Tabla 14. Determinación de la dificultad de implementación para EO y EQ [Boehm, 1999]

Luego de clasificar cada uno de los elementos de puntos de función se procede a calcular el total

de puntos de función por requerimiento.

3.2.1.5 Calcular el total de puntos de función.

Para esta labor se deben tomar los componentes identificados y categorizados en los numerales

anteriores y calcular el total de puntos de función para cada requerimiento: este cálculo del total

de puntos de función se realiza mediante una ecuación 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 función.

En el caso de este modelo se debe realizar una estimación por requerimiento, por lo cual se

utilizara la ecuación por requerimiento.

Para facilitar el cálculo del total de puntos de función, el método de puntos de función incluye

una tabla en la cual se encapsula la ecuación necesaria para calcular el total de puntos de

función, a continuación se muestra en la siguiente tabla:

Parámetro Complejidad Peso Cantidad Total = cantidad * peso

Alta 15 Media 10

Ficheros Lógicos

Baja 7 Alta 10 Media 7

Ficheros Lógicos Externos


Entradas Externas (EI)


Salidas Externas (EO)


Consultas Externas (EQ)

Baja 3 Total Puntos Función = Suma de Totales

Tabla 15. Cálculo del Total de Puntos de Función 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 función relacionados al

requerimiento.

Luego que se calcule el total de puntos de función para cada requerimiento se procede a

diligenciar el colocar estos datos en el formulario de estimación del tamaño, esto se realiza en la

parte final del formulario en donde se relaciona cada requerimiento con su tamaño.

Luego de realizar la estimación del tamaño con el método de puntos de función, 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 función que se estimó. La tabla 16 muestra los elementos que hacen parte de este

modelo: ENTRADAS SALIDAS PROCESOS ACTORES

-Especificación de los requerimientos funcionales. -Información de Sistemas Externos: hace referencia, a toda la información del entorno donde funciona el software (bases de datos que utiliza, sistemas externos con los que interactúa).

El tamaño de cada uno de los requerimientos especificados que se desean implementar.

Aplicación del método de puntos función. para la estimación del tamaño

Gerente del proyecto, estimadores y el analista de requerimientos

Tabla 16. Elementos del modelo para la estimación del tamaño 3.2.1.6 Formulario que apoya el modelo para la estimación del tamaño

El formulario diseñado para este modelo: Formulario para la estimación del tamaño con

puntos de función (véase Anexo A) permite almacenar la información para el cálculo de

puntos de función para cada uno de los requerimientos a estimar.

3.3 PASO III: GESTIONAR LOS COSTOS

3.3.1 Modelo para la gestión de costos

Este modelo de gestión 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 estimación de costos y de presupuesto se realizarán

simultáneamente debido a que en esta primera se incluye una división del trabajo por

requerimientos y por tanto la estimación total, involucrándolos a todos, dará como resultado el

presupuesto total para todo el proyecto.

Otra razón importante para unir estos dos pasos consiste en las propias características del

método a utilizar: COCOMO II. Como entrada este método requiere para calcular el costo de un

producto de software conocer el costo para la organización de una persona/mes, en dicha

entrada deben venir especificados todos los factores contemplados en el momento de realizar un

presupuesto.

A continuación se muestra el esquema que sigue el modelo:

74

Tamaño de los requerimientos

Estimación de costos del proyecto

Costo total del proyecto

Estimación del presupuesto del proyecto

Presupuesto del proyecto

Presupuesto del proyecto

Control del presupuesto Indicadores de gestión

Figura 27. Esquema del Modelo para la gestión de Costos Enseguida se explica en detalle cada uno de los pasos contenidos en la figura 27:

3.3.2 Estimación de costos utilizando COCOMO II Como se mencionó en el capitulo anterior la metodología escogida para realizar la estimación

del costo del proyecto fue COCOMO II, específicamente el modelo de diseño anticipado,

debido a que es un modelo que ofrece buena seguridad en la estimación sin mostrar toda la

complejidad del modelo de postarquitectura.

En esta explicación acerca del método a utilizar para estimar el costo del proyecto, en esta

explicación no se adjuntaran las tablas mediante las cuales se calculan los parámetros necesarios

para realizar la estimación con COCOMO, en el momento que se realice esta estimación 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 estimación de todos los requerimientos,

debido a que estos factores son explícitos para la organización que construirá el software mas no

para un requerimiento especifico de la organización, estos factores indican si el desempeño que

muestra una organización ante un proyecto, específicamente si a medida que crece el tamaño 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 tamaño, lo que conlleva a un

75

mayor costo en el proyecto. La estimación de los factores de costo se realiza utilizando la

siguiente ecuación

En esta ecuación se deben sumar los valores de cada uno de los 5 factores de escala para

aplicarlos a la ecuación, las constantes presentadas en la misma son resultado de la

investigación empírica realizada al desarrollar el modelo COCOMO, para encontrar el valor y

categorización que cada uno de estos factores se debe consultar el manual del modelo

COCOMO II [Boehm, 1999].

Los resultados de aplicar la ecuación pueden ser:.

- Si el resultado de la ecuación (B) es >1 el esfuerzo necesitado para completar un

proyecto se incrementa en mayor medida que en la que aumenta el tamaño del mismo.

- Si (B) es =1 el esfuerzo necesitado para completar un proyecto se incrementa en la

misma medida que el tamaño del mismo.

- Si B es <1 el esfuerzo necesitado para completar un proyecto se incrementa en una

menor magnitud que el tamaño 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 determinación de B esta apoyada por los factores de escala mostrados en el Formulario para

la estimación de costos (Ver Anexo A). En dicho formulario se diligencia la categoría en la que

se encuentra cada uno de los factores, facilitando la determinación 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

evalúan 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 estimación de costo se quiere realizar por requerimiento.

Para efectos de esta propuesta el modelo de COCOMO II que se aplicará es el de diseño

anticipado. Tal modelo ofrece estimaciones más precisas sin hacer que la aplicación del método

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 información se encuentra en

el manual del modelo COCOMO II [Boehm, 1999], la categorización de cada uno de los

factores de costo se hace en categorías que van desde Muy Bajo hasta Muy Alto, y cada una de

estas categorías presenta un valor numérico con el cual se calcula el costo del proyecto.

Para apoyar este paso en la estimación del costo y presupuesto del proyecto se diseño el

formulario “COCOMO II Estimación del Costo” el cual se puede encontrar en el anexo B del

documento, en dicho formulario se diligencia por requerimiento la categoría de cada uno de los

factores de costo.

3.3.2.3 Estimar el Presupuesto del Proyecto utilizando la ecuación 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 ecuación que

presenta el modelo COCOMO para el modelo de diseño anticipado.

Para obtener esta estimación se deben conocer la variable B que se estimo en el paso anterior, el

tamaño de cada uno de los requerimientos del proyecto en puntos de función, el tamaño de los

requerimientos se obtuvo anteriormente, y por ultimo se debe conocer el valor para la

organización de persona/mes dicho, dicho valor es único para cada organización por lo que debe

conocer para obtener la estimación de costos.

Luego de conocer los valores anteriores se procede a utilizar la ecuación para el modelo de

diseño anticipado, esta ecuación es la siguiente:

Esta ecuación tiene varios parámetros que deben ser explicados para dar claridad acerca de la

utilización 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 empíricamente por los creadores del modelo.

- Size: Tamaño del requerimiento a implantar, obtenido anteriormente cuando se estimo el

tamaño del requerimiento en estimación.

77

- EM: esta variable representa el valor numérico dado a cada uno de los factores de costo

anteriormente categorizados.

En esta ecuación se deben multiplicar el valor de cada uno de los 7 factores de costo incluidos

en el modelo de diseño anticipado, estos valores se encuentran en el manual del modelo

COCOMO II [COCOMO 1999]

En el Formulario para la estimación de costos (ver Anexo A) se diligencian todos estos valores

obtenidos de la estimación, con el fin facilitar la estimación y permitir guardar registro de las

estimaciones realizadas.

3.3.3 Control de costos y presupuesto Este paso en el modelo de Gestión de costos se realizara el control del presupuesto el cual se

estimo en el paso anterior, dicho control se realizara utilizando el método del análisis del valor

ganado, específicamente usando las métricas relacionadas con el presupuesto, estas métricas

permiten medir el desempeño del proyecto en algún 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 Método para el Control del Presupuesto

El método para realizar esta tarea como ya se menciono el Análisis del Valor Ganado, este

método ofrece una serie de métricas que permiten conocer varios aspectos sobre el desempeño

del proyecto, pero cabe aclarar que en el análisis del valor ganado no solamente se controla el

presupuesto si no el cronograma del mismo, por lo cual las métricas correspondientes al

calendario no serán utilizadas.

Para iniciar la actividad del control del presupuestó se deben tener definidas las siguientes

variables, desde las cuales se obtendrán las métricas para el control del presupuesto

- Valor Planeado (PV): este parámetro representa el costo del trabajo que se ha realizado hasta

el momento de la aplicación del método.

- Earned Value (EV): el parámetro representa el valor estimado del trabajo actualmente

completado.

- Costo Actual (AC): este último parámetro representa el dinero realmente invertido al

momento actual.

78

Estos parámetros son obtenidos del presupuesto del proyecto o del control de gastos del

proyecto, por lo que hace esencial que además 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.También cabe aclarar que el presupuesto se

controlara por cada requerimiento lo que dará información en el desempeño de cada

requerimiento. A continuación se explicarán cada una de las métricas que se deben estimar.

- Variación del Costo (CV): esta métrica estima en cuanto el proyecto se encuentra por encima

o debajo del presupuesto.

- Índice de desempeño del costo (CPI): en esta métrica se obtiene cuanto se gana o se pierde

por cada unidad de dinero invertida en el proyecto.

- Estimación a la Terminación (EAC): para esta métrica existen varias formula pero en general

lo que intentan estimar es cuanto constara el proyecto en total luego de obtener estas métricas.

- Estimación a la Terminación (ETC): esta métrica intenta estimar cuanto mas el proyecto

costara luego del avance alcanzado al momento de utilizar la métrica.

- Variación a la Terminación (VAC): La métrica estima cuanto sobre el presupuesto costara

realmente el proyecto.

Luego de aplicar estas métricas 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 información 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 estimación y gestión de costos. ENTRADAS SALIDAS PROCESOS ACTORES

- Estimación de costos: Tamaño de cada requerimiento funcional. Gestión de costos: presupuesto estimado

- Presupuesto del proyecto: unión de las estimaciones de costo de cada requerimiento

Aplicación del método de puntos función. para la estimación del tamaño

Gerente del proyecto, estimadores y el analista de requerimientos

Tabla 17. Elementos del modelo para la estimación y gestión 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 metodología para la gestión de riesgos que se propone. Las salidas

79

(componentes en color amarillo representan los formularios de apoyo que suministra la

metodología en algunos de los pasos de la gestión del riesgos).

Identificación y categorización

Fase de cuantificación y priorización Análisis cualitativo Análisis cuantitativo

Preparación

Respuesta al riesgo

BASE DE APRENDIZAJE DE RIESGOS

Control de respuesta al riesgo

Revisar y ajustar el plan de riesgo

Estimación de riesgos técnicos y de negocio

Estimación de riesgos de proyecto

Formularios para análisis cuantitativo

Formularios de Plan de riesgo

Formularios de apoyo dinámica Wideband Delphi

Formulario de riesgos identificados

Figura 28. Diagrama de flujo de la metodología de gestión de riesgos A continuación se explican en detalle cada uno de los pasos de esta metodología:

3.4.1 Prepararse para la gestión

Comprende la delimitación y definición del marco de las fuentes y categorías del riesgo.

Finaliza con la comunicación del marco de las fuentes y categorías a los miembros del equipo.

Ver figura 29.

Conjunto de fuentes de riesgo.

Conjunto de categorías riesgo.

DAR A CONOCER -COMUNICAR

Figura 29. Paso I de la metodología de gestión de riesgos.

80

3.4.2 Identificar los riesgos y categorizarlos • Delimitar e identificar el dominio de posibles riesgos según la técnica de identificación

basada en taxonomías.

- Delimitación según la clase Entorno de desarrollo

Reconocer los riesgos asociados con la poca y/o mala comunicación y los asociados con la

planeación del proyecto dentro del proceso de gestión de riesgos.

Mientras que la experiencia del gerente del proyecto, atributo del elemento Proceso de

administración, puede surgir como un riesgo alterno teniendo en cuenta las estadísticas

relacionadas con los años y estudios de los gerentes de proyectos de TI en Colombia. Ver figura

30.

Proceso de administración

Criterios de fracaso

PLANEACIÓN

EXPERIENCIA DEL GERENTE

COMUNICACIÓN

Entorno de trabajo

Estado de proyectos de TI

Elemento de la clase

Atributo

Figura 30. Delimitación según la clase Entorno de desarrollo

- Delimitación según la clase Restricciones del programa

El estado del desempeño 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 desempeño

del proyecto y los recursos en el proceso de gestión del riesgo.

Desempeño proyectos

DESEMPEÑO EN

EL CRONOGRAMA

DESEMPEÑO EN

EL PRESUPUESTO

Recursos Recursos

Elementos de la clase

Estado de proyectos de TI

Atributo

Figura 31. Delimitación según la clase Restricciones de programa

81

- Delimitación del dominio de los riesgos y los requerimientos funcionales del proyecto

La especificación de requerimientos al constituir una de las principales actividades en la cual se

enfoca los proyectos de TI debe demandar también una mayor atención en el sentido que la

gestión de riesgos asociados a los requerimientos debe ayudar a identificar y controlar aquellos

aspectos que pudieran desviar la definición 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 especificación 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 definición y las funcionalidades establecidas en la fase de

especificación.

Actividades en proyectos

de TI Elementos de la clase

Estado de proyectos d

Atributo

Requerimientos CARACTERÍSTICAS

DEL ELEMENTO

Estabilidad

Completitud Validez… Claridad

Figura 32. Delimitación según la clase Ingeniería del producto La identificación de un conjunto más amplio de riesgos es una opción contemplada dentro de

esta propuesta. La delimitación planteada en esta sección se construyó con el fin de fusionar los

objetivos del trabajo con los de la caracterización del estado de proyectos de TI en Colombia.

NOTA: Utilizar otras técnicas y criterios de limitación del dominio de riesgos si se considera

necesario es posible hacer uso de otras técnicas para la identificación de riesgos. Para ello, la

fuente [Maniasi, 2005] explica las principales de ellas.

3.4.2.1 Categorizar los riesgos identificados

La categorización con base a los riesgos identificados se ilustra en la figura 33:

Figura 33. Categorización de riesgos identificados

CATEGORÍAS

Técnica

Plan de proyecto

Negocio

Requerimientos

Recursos Entorno de trabajo Proceso de administración

Otros elementos de la taxonomía

82

3.4.2.2 Dar a conocer el resultado de la identificación

Con el fin de facilitar el entendimiento y comunicación de los riesgos el Formulario de riesgos

identificados (véase Anexo A) muestra el diseño de un formato que recopilará la información

más importante por cada riesgo identificado del proyecto como resultado de esta fase de

identificación de la metodología.

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 técnico serán tratado bajo

un análisis cualitativo mientras que los de proyecto (calendario y costos) se analizaran

cuantitativamente.

3.4.3.1 Análisis cualitativo

Realizar Dinámica variante del método Wideband Delphi para el análisis cualitativo de riesgos

• Participantes dinámica variante Wideband Delphi

- Coordinador

- Miembro del equipo de proyecto

• Pasos que comprende la dinámica variante Wideband Delphi

La figura 34 muestra los pasos de la variante de la dinámica Wideband Delphi propuesta en este

modelo. La explicación de cada uno de los pasos así como los participantes que los desarrollan

se muestran a continuación.

83

Riesgos descritos y categorizados (Formulario de la sesión introductoria).

Sesión introductoria

Sesión de estimación individual

Formulario de la estimación individual

Sesión de evaluación de resultados

Formato de evaluación de resultados

Sesión para la revisión de resultados

Sesión para la revisión de la

estimación final

Formato de la estimación final

Informe de la

evaluación

Formato de recordación de niveles de probabilidad, impacto y prioridad.

Figura 34. Dinámica variante Wideband Delphi para la evaluación de riesgos técnicos Paso 1: Sesión introductoria. Incluye la presentación de los riesgos identificados junto con su

categoría y descripción. Para ello el modelo propone la utilización del Formulario de la sesión

introductoria (véase Anexo A).

a. El coordinador presenta a los miembros del equipo los riesgos identificados durante la fase

de anterior, su categorización 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: Sesión de estimación individual. Cada uno de los participantes realiza, de manera

individual, la evaluación de los riesgos presentados. Puede incluir riesgos adicionales que no

hayan sido tenidos en cuenta en la sesión introductoria y que considere como problemas

potenciales para el proyecto. (véase A Formulario de la sesión de estimación individual).

a. El participante del equipo realiza su evaluación de los riesgos otorgándole 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 podría agregar riesgos adicionales, junto con su probabilidad e impacto,

que no fueron tenidos en cuenta en la sesión introductoria y si lo considera necesario.

Paso3: Evaluación de resultados. El coordinador evalúa los resultados de las estimaciones

individuales (véase Anexo A Formulario de evaluación de resultados) utilizando el promedio

de los valores de probabilidad e impacto comenzando por los riesgos que fueron evaluados con

alto nivel de amenaza.

NO

SI

Discusión: nueva iteración

Prioridad de riesgo alta: el riesgo requiere un plan de mitigación de inmediato

Revisar valor de la desviación estándar

Estipular la prioridad del riesgo conforme al nivel de amenaza

Riesgo con cierto nivel de amenaza Desviación

estándar baja

Analizar valor de la moda

Figura 35. Evaluación de resultados El coordinador evalúa 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 desviación estándar, del promedio de la

probabilidad, del impacto o de ambos, es alto, el riesgo debe ser puesto nuevamente en

discusión hasta alcanzar un consenso entre los participantes generando una nueva iteración

(alternativamente puede ser usado el valor de la moda para tomar una decisión 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 después de la tercera iteración es necesario llevar a un acuerdo las opiniones

de los participantes con el fin de alcanzar un nivel de prioridad consensuado.

Paso 4. Sesión para la revisión de la estimación. El coordinador presenta el informe de la

evaluación (véase Anexo A Formulario de evaluación de resultados) que contiene:

85

- Los nuevos riesgos junto con sus valores de probabilidad e impacto.

- Los riesgos con un valor de desviación estándar 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 estimación.

Paso 5. Sesión para la revisión de la estimación final. El coordinador presenta los resultados

de la última estimación mostrando:

- La lista de riesgos priorizados y por tanto, mostrando cuáles deben contar con mayor

prelación a la hora de formular los planes de riesgo para ello propone la utilización del

Formulario de revisión de la estimación final (véase Anexo A). Para este fin el coordinador

puede apoyarse en herramientas tales como la gráfica de perfil de riesgos ilustrada en la sección.

- El coordinador debe ingresar los riesgos con mayor prioridad a la base de aprendizaje de

riesgos del proyecto.

3.4.3.2 Análisis cuantitativo

Este modelo propone la utilización del método cuantitativo para la estimación de riesgos

inherentes al plan de proyecto (categoría de calendario y costos). El método cuantitativo permite

determinar la probabilidad de que el proyecto vaya a ser finalizado en el período de tiempo y el

presupuesto planeados.

3.4.3.3 Pasos para el análisis 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 línea 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 estimación del tamaño del software)

Paso 2: determinar los rangos de duración por cada una de las actividades (véase Anexo A

Formulario para el análisis cuantitativo de riesgo en calendario) y costos por cada una de

los requerimientos (véase Anexo B Formulario para el análisis cuantitativo de riesgo en

costos).

Paso 3: Llevar a cabo la simulación de tres puntos y mostrar las probabilidades de riesgo de

calendario y costos del proyecto.

86

Paso 4: Formulación 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 análisis al grupo (véase Anexo A Formulario de revisión

de la estimación final).

3.4.4 Responder al riesgo

La figura 22 muestra paso a paso la definición de la fase de respuesta al riesgo para la

metodología propuesta en este modelo.

3.4.4.1 Entradas

Las entradas para esta fase están conformadas por el resultado de los riesgos cualificados y

cuantificados (véase Anexo A Formulario De Revisión De La Estimación 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 (véase 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 magnético) destinado a agrupar los planes de riesgo

de aquellos priorizados de manera alta tras la fase de cuantificación y cualificación.

Riesgos cualificados y cuantificados

Plan de riesgo

BASE DE APRENDIZAJE DE RIESGOS

Riesgos con alta prioridad

FIN

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, además, que de acuerdo con la categoría del riesgo los planes pueden

incluir nuevos elementos:

- Para el caso del riesgo en costo se pueden especificar las métricas 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 duración de las

actividades del proyecto y cumplir con la probabilidad mínima de establecida por la gerencia de

terminar el proyecto en una fecha dada (corresponde con la métrica definida para medir el plan

de riesgo en calendario).

3.4.5 Fase de control y seguimiento La figura 37 muestra cómo se debe desarrollar esta fase cuyo enfoque principal apunta a la

revisión y supervisión de los planes de riesgo como resultado de la fase de respuesta previa.

Para ello se apoya en los elementos ilustrados:

Planes de riesgos

EVALUACIÒN

FUENTES

MÉTRICAS

ESTADO PLAN DE RIESGO

Figura 37. Control y seguimiento del modelo propuesto 3.4.5.1 Verificación de plan de riesgo según las fuentes del riesgo

Tal y como lo ilustra la figura 37: la variación de las fuentes de riesgos a través del tiempo

mostrada en la fase de preparación, una fuente puede representar una situación cambiante en el

tiempo. Por tanto es necesario revisar su estado y verificar si aún persiste en el entorno del

proyecto para lo cual los riesgos asociados a ella persistirían también; por el contrario, si fue

una situación que desapareció o fue eliminada del contexto del proyecto sus riesgos asociados

pueden ser despreciados también.

88

3.4.5.2 Verificación del plan de riesgo según el estado del plan

La siguiente figura 38 ilustra los estados del plan de riesgo para lo cuales el plan de riesgo

requeriría de revisión y nuevos ajustes:

Plan rojo

Plan amarillo

Plan reabierto

PLAN DE RIESGO

Implica revisión rigurosa y continua del plan de riesgo y la realización de ajustes conforme a los resultados de ésta.

Implica el ejercicio de revisiones breves sobre el plan de riesgo y pequeños 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.

Figura 38. Estado de planes de riesgo y revisión

3.4.5.3 Verificación del plan de riesgo según métricas del control de costos y calendario

Este modelo plantea las siguientes métricas basado en la gestión de costos del modelo (ver tabla

18):

Métrica:

• Métrica para riesgo en costo

DVP: desviación máxima aceptada por encima del VP

AC>DVP

Figura 39. Métrica para riesgo en costo Si la métrica indicara que el costo del proyecto actual (AC) con mayor probabilidad de ocurrir

(análisis a través del método Monte Carlo) sobrepasa el valor máximo aceptado por encima del

valor planeado de costo del proyecto (DVP) el plan de riesgo correspondiente debería ser

revisado y ajustado.

89

• Métrica asociada con el riesgo en calendario

Los acrónimos usados para esta métrica se mencionan en la siguiente tabla:

Acrónimo Término Explicación PTPE Probabilidad esperada de cumplimiento del

cronograma en la fecha de terminación del proyecto.

Cuál es la probabilidad mínima esperada de que el proyecto se termine en la fecha de terminación estipulada?

PTP Probabilidad de la terminación del proyecto en una fecha

Probabilidad de terminación del proyecto en una fecha dada (obtenida a través de la simulación)

Tabla 18. Acrónimos para la métrica de riesgo en calendario

Figura 40. Métrica para riesgo en calendario Si la métrica indicara que la probabilidad obtenida del cumplimiento del cronograma del

proyecto (PTP) en la fecha estipulada para su terminación, a través del método Monte Carlo, es

menor que la probabilidad mínima esperada (PTPE), el plan de riesgo debe ser supervisado y

ajustado en cuanto a sus acciones a seguir.

NOTA: El dominio de estas métricas 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 gestión Una vez los culmine la fase de gestión del riesgo los resultados de la ejecución de los pasos

modelo materializados en los formularios diligenciados del mismo, deben ser tratados y

almacenados en un repositorio de información relacionada con la planeación del proyecto.

Los datos que guardan las estimaciones del tamaño y de la gestión 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 CAPÍTULO

En este capítulo se obtuvieron los modelos y metodologías definitivas que sustentan el modelo.

Los modelos para la estimación y gestión de costos y la metodología definida para la gestión de

riesgos son obtenidos como resultado del análisis efectuado en la propuesta conceptual de este

trabajo.

Cronograma: X% de probabilidad de éxito en la fecha de terminación.

Métrica: PTP< PTPE

90

4. CONCLUSIONES

1. Se logró desarrollar un modelo para la estimación del tamaño del software y la gestión 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 utilización de diversas

metodologías y técnicas para la estimación del tamaño y gestión de costos y riesgos de un

proyecto de software, extraídas como resultado del estudio sobre diversas fuentes de

información relacionadas con el tema.

3. Se establecieron criterios para la clasificación de las metodologías encontradas para la

estimación del tamaño y gestión de costos y riesgos de un proyecto de desarrollo, llevando a

cabo para este fin un marco comparativo entre dichas metodologías.

4. Adicionalmente a la definición de los criterios fue posible establecer requisiciones y

principios básicos sobre los cuales debe basarse una metodología de gestión de riesgos y

algunas técnicas involucradas en este mismo proceso.

5. Se establecieron metodologías y técnicas específicas asociadas con la estimación del

tamaño y gestión de costos y riesgos de un proyecto de software que responden a los

criterios ya definidos.

6. Las metodologías y técnicas especificadas con base en los criterios definidos,

constituyen la base del modelo propuesto para la estimación de tamaño y gestión de costos y

riesgos de un proyecto de desarrollo de software.

7. Es una finalidad del modelo suministrar un marco básico de metodologías y técnicas

basadas en el uso de herramientas de fácil acceso que faciliten, a su vez, el proceso de

estimación y gestión de costos y riesgos en un proyecto de desarrollo.

8. La aplicación práctica del modelo a través de un caso de estudio permitió validar

experimentalmente algunos de los pasos que constituyen el mismo, generando una adecuada

gestión de costos y riesgos de acuerdo con los criterios especificados.

9. La validación 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 práctica.

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 cálculo de los datos en un

mismo entorno.

2. Ampliar la aplicación práctica 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 estimación y gestión de proyectos de software.

3. Complementar el modelo a través de la propuesta de una metodología para la estimación y

control de calendario.

4. Se sugiere el desarrollo de un estudio más profundo acerca del estado de las pymes

colombianas con respecto a las áreas de estimación y gestión de proyectos, con el fin de

extender la aplicación del modelo teniendo en cuenta nuevas necesidades y requerimientos de

las empresas aparte de las mencionadas e identificadas en este trabajo.

92

BIBLIOGRAFÍA

[ACIS, 2007]. V Encuesta de gerencia de proyectos. Asociación 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 Análisis De Requerimientos Dentro De La Pequeña

Empresa Desarrolladora De Software En Bogotá, Pontificia Universidad Javeriana,

Departamento de Ingeniería de Sistemas, Colombia, 2005.

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

Scientific Publishing Co, 2002.

[Esteves, 2004]. Implementación y Mejora del Método de Gestión 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]. Métodos de Estimación de Tamaño 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]. Identificación de Riesgos de Proyectos de Software en base a Taxonomías,

tesis de Magíster, 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, Andrés. “Obstáculos en la gestión de proyectos en tecnologías de

información y comunicación 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 MODELOA

B

C

ENCUESTA SOBRE GESTIÓN DE PROYECTOS

D

ESPECIFICACIÓN DE LOS REQUERIMIENTOS DEL PROYECTO: CASO DE ESTUDIO

CASO DE ESTUDIO

FORMULARIOS DEL CASO DE ESTUDIO

E

95

96

Anexo A Presentación de los formularios para la estimación del tamaño y gestión de

costos y riesgos del modelo propuesto

FORMULARIOS DEL MODELO A

Formulario para la estimación del tamaño con Puntos de Función

Requerimientos

Número de componentes de datos

Dificultad

Archivos que gestionan la aplicación(ILF)

Requerimiento1 Requerimiento2 Requerimiento3 Requerimienton RET DET

Requerimientos


Dificultad

Archivos de Interfase (ELF) Requerimiento 1 Requerimiento2 Requerimiento 3 Requerimienton RET DET

97

Formulario para la estimación del tamaño con Puntos de Función

Requerimientos


Dificultad

Entradas Externas (EI) Requerimiento 1 Requerimiento2 Requerimiento 3 Requerimienton FTR DET

Requerimientos


Dificultad

Salidas Externas (EO) Requerimiento 1 Requerimiento2 Requerimiento 3 Requerimienton FTR DET

98

Requerimientos Número de componentes de datos

Dificultad

Consultas Externas (EQ) Requerimiento 1 Requerimiento2 Requerimiento 3 Requerimienton FTR DET

Total de Puntos de Función Requerimiento No Puntos

de función Requerimiento 1

Requerimiento 2

Requerimiento 3

Requerimiento n

Total puntos de función del sistema

99

Formulario para la estimación de costos

Factores de Escala

Valor Factores de Escala

Extra Alto Alto Nominal Bajo Muy Bajo

Precedencia Experiencia de trabajo con sistemas de sw relacionados

Flexibilidad de desarrollo Arquitectura / Resolución de Riesgos

Madurez del Proceso

100

Estimación de Costos Tamaño Requerimiento(Puntos de Función)

Factores de Escala Valor Requerimiento 1 Requerimiento 2 Requerimiento 3 Req n

Extra Alto Muy Alto

Alto Nominal

Bajo Muy Bajo

Fiabilidad del Producto y Complejidad

ExtraBajo

Extra Alto Muy Alto

Alto Nominal

Bajo Muy Bajo

Reutilización Requerida

ExtraBajo

Extra Alto Muy Alto

Alto Nominal

Bajo Muy Bajo

Dificultad de la Plataforma

ExtraBajo

101

102

Extra Alto Muy Alto

Alto Nominal

Bajo Muy Bajo

Experiencia del Personal

ExtraBajo

Extra Alto Muy Alto

Alto Nominal

Bajo Muy Bajo

Facilidades

ExtraBajo

Extra Alto Muy Alto

Alto Nominal

Bajo Muy Bajo

Planificación Temporal

ExtraBajo

Costo Requerimiento $

FORMULARIO DE RIESGOS IDENTIFICADOS


INFORMACIÓN REQUERIDA DEL RIESGO

DESCRIPCIÓN DEL RIESGO IDENTIFICADO

Nombre riesgo

Asigna un nombre único al riesgo.

Fecha – Nombre

Fecha y nombre de la persona que reportó el riesgo.

Componente – subsistema Identifica el subsistema / componente de la descomposición de la estructura del trabajo (WBS) o proceso en el cual se localiza el riesgo.

Categoría asociada Identifica a qué categoría (Técnico. Proyecto o negocio) se encuentra asociado el riesgo.

Descripción del riesgo Es una breve descripción del riesgo. Puede ser complementada durante la fase de cuantificación y priorización.

Fuente de riesgo Situaciones que hacen parte del entorno del proyecto y a su vez son productoras del riesgo.

Responsabilidad Determina a quien fue asignada la responsabilidad individual del manejo del riesgo.

103

FORMULARIO DE LA SESIÓN INTRODUCTORIA

FORMULARIO DE LA SESIÓN INTRODUCTORIA

Nombre participante: Fecha

No RIESGO

DESCRIPCIÓN CATEGORIA OBSERVACIONES

104

FORMULARIO DE LA SESIÓN DE ESTIMACIÓN

INDIVIDUAL

FORMULARIO DE LA SESIÓN DE ESTIMACIÓN INDIVIDUAL

Nombre participante: Fecha

No RIESGO

DESCRIPCIÓN PROBABILIDAD IMPACTO PRIORIDAD

LISTA DE RIESGOS ADICIONALES PROPUESTOS

RIESGO

DESCRIPCIÓN CATEGORÍA JUSTIFICACIÓN

105

FORMATO PARA LA RECORDACIÓN DE NIVELES DE PROBABILIDAD, IMPACTO Y PRIORIDAD

NIVEL DE PROBABILIDAD

ESCALA

Remoto >10% Improbable (11 – 30) % Probabilidad media (31 – 50)% Posible (51 - 70) % Muy Probable (>71%)

NIVEL DE IMPACTO

ESCALA

Mínimo 1 Bajo 2 Medio 3 Severo 4 Crítico 5

Probabilidad / Impacto Mínimo Bajo Medio Severo Crítico Remoto Improbable Probabilidad media Posible Muy Probable

106

FORMULARIO DE EVALUACIÓN DE RESULTADOS


Fecha evaluación RIESGO

PROMEDIO

PROBABILIDAD

DESVIACIÓN ESTÁNDAR

MODA

PROMEDIO IMPACTO


MODA

107

FORMULARIO DE REVISIÓN DE LA ESTIMACIÓN

FINAL

FORMULARIO DE REVISIÓN DE LA ESTIMACIÓN FINAL Fecha:

RIESGO FUENTE (Opcional)

CATEGORÍA PRIORIDAD

108

FORMULARIO PARA EL ANÁLISIS CUANTITATIVO

DE RIESGO EN CALENDARIO

ANALISIS CUANTITATIVO DE RIESGO EN CALENDARIO

Nombre evaluador:

Fecha

ACTIVIDAD DURACIÓN MÍNIMO

DURACIÓN MÁS

PROBABLE

DURACIÓN MÁXIMO

109

FORMULARIO PARA EL ANÁLISIS CUANTITATIVO

DE RIESGO EN COSTOS

ANALISIS CUANTITATIVO DE RIESGO EN COSTO

Nombre:

Fecha:

REQUERIMIENTO COSTO MÍNIMO

COSTO MÁS PROBABLE

COSTO MÁXIMO

110

FORMULARIO DE PLAN DE RIESGO


NOMBRE DEL RIESGO CATEGORÍA

DESCRIPCIÓN

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

CASO DE ESTUDIOB

- Descripción y formalización del proyecto de caso de estudio - Aplicación práctica de algunos pasos de la metodología

- Formularios utilizados en la aplicación práctica

112

Descripción del proyecto y definición de los requerimientos funcionales

1.1 Descripción 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 específicamente son la administración de las

direcciones IP de los clientes y sus nombres.

Esta compañía ofrece a sus clientes servicios para la administración de red los cuales son ofrecidos a

través del portal empresarial de la compañía, este proyecto entra a ser parte del plan de la compañía

para aumentar los servicios que ofrece a sus clientes.

Existen dentro de la compañía dos ambientes diferentes que interactúan 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 ingeniería que maneja las configuraciones de servicios de red elaboradas en Linux lo que ha

hecho necesario la implantación de un puente para que los ambientes se comuniquen, dicho puente

lo constituyen los servicios web que hacen transparente la interacción entre ambas partes.

Este proyecto se encargara de ofrecer servicios web al portal empresarial, para que los clientes de la

compañía puedan manejar los nombres asignados en el DNS a sus direcciones ip, y modificarlos

según lo necesiten.

En el momento de planear este proyecto se pensó que para su implementación lo más conveniente

era desarrollar componentes genéricos que pudieran ser extendidos con nuevos servicios, esto con el

fin de disminuir el tiempo de implantación de estos.

Adicionalmente al los servicios de información relacionados con las direcciones Ip, se desarrolló uno

para la consulta de los logs que genera la aplicación, este servicio es utilizado por los encargados del

soporte de la aplicación, 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 compañía y otros sistemas que

consultan las Ips de los clientes.

1.2 Especificación de los requerimientos funcionales

A continuación 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 dirección IP

4. Un cliente podrá eliminar el nombre de su dirección IP

5. El sistema deberá notificar al cliente el número de cada una de las direcciones IP que tenga

adscritas.

6. El sistema deberá verificar la existencia de una dirección IP de un cliente.

7. El administrador del sistema podrá consultar los logs de la aplicación.

El Anexo E muestra la especificación formal de los requerimientos listados anteriormente siguiendo

la plantilla de Volare.

114

Estimar el tamaño del software

Como se describió en la propuesta conceptual del modelo la estimación del tamaño para este caso de

estudio se necesita tener en cuenta los requerimientos funcionales del proyecto y la información

relevante del sistema para realizar la estimación por puntos de función, dichos requisitos fueron

cumplidos por lo cual basándose en los requerimientos especificados se realizará esta estimación.

Los datos del Formulario para la estimación de puntos de función se muestran en el Anexo C.

2.1 Resultado del modelo para la estimación del tamaño

Luego de realización de todo el proceso de estimación del Tamaño se obtiene como resultado 116

puntos de función, valor bastante cercano al total al tamaño del software que se implementó. Para

observar los detalles relacionados con la obtención de este valor véase Anexo C Formulario para la

estimación del tamaño con puntos de función.

Gestionar los costos

Para la realización de este proceso de gestión de costos se deben seguir los pasos descritos en la

definición del modelo. Debido a la ausencia de información histórica suficiente relacionada con los

costos invertidos en los recursos del proyecto es posible afirmar que este hecho representó una

limitación en esta fase de aplicación práctica del modelo. Sin embargo, sí fue posible llevar a cabo

una debida estimación de costos (véase Anexo C Formulario para la estimación de costos).

Cabe recordar que para poder gestionar los costos de un proyecto primero se debe contar con la

estimación del tamaño del software a gestionar. Para este caso, la estimación se obtuvo el tamaño 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

metodología de gestión 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 adaptación del caso de estudio por ejemplo en el diligenciamiento de algunos formularios

serán expuestas en el momento en su momento.

1. Prepararse para la gestión 1.1 Fuentes de riesgo El dominio de las fuentes así como de las categorías 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 técnico.

3. Cualificar y cuantificar los riesgos

3.1 Análisis cualitativo

Se realizó el análisis cualitativo al riesgo técnico

3.1.1 Desarrollo de la dinámica variante del Método Wideband Delphi

Se presenta el formulario de evaluación de resultados que contiene la evaluación individual del

riesgo técnico obtenido en una de las iteraciones de la dinámica (véase Anexo C Formulario de

evaluación de resultados).

116

4. Cuantificación y priorización

4.1 Estimación de riesgo en calendario

4.1.1 Determinación de la línea 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 Documentación es decir con fecha de entrega del 14 de febrero.

Figura 2. Cronograma estimado para el proyecto

De acuerdo con la figura 40 la línea base de actividades del proyecto es:

- Actividad 1: Análisis

- Actividad 2: Diseño

- Actividad 3: Desarrollo

- Actividad 4: Documentación

Y la fecha de terminación del proyecto hasta la fase de documentación debería ser el día 14 de

febrero.

4.1.2 Definición de rango de duración para cada una de las actividades.

Contamos con la participación del gerente de proyecto para obtener las estimaciones de tres puntos

correspondientes a las duraciones de cada una de las actividades de la línea base del proyecto:

Actividades Bajo Más probable Alto Análisis 1 2 5 Diseño 1 4,5 10 Desarrollo 7 16 30 Documentación 1 2 5

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

4.1.3 Simulación de tres puntos para la probabilidad de la Terminación Total del proyecto

Esta distribución de fechas de finalización del proyecto es hallada mediante la simulación del

cronograma varias veces. En cada iteración una duración de la estimación de tres puntos es escogida

aleatoriamente. Como en este caso no se conoce cuál combinación de duraciones va a ocurrir la

simulación se realizó con 2500 iteraciones cada una con una duración seleccionada al azar. La figura

117

40 muestra la distribución generada a partir de los rangos de estimación de los valores optimista

(bajo), más probable y pesimista (alto) para cada una de las actividades del cronograma del proyecto.

Figura 3. Distribución de probabilidad de posibles fechas de entrega

Conforme a la gráfica de distribución de las fechas de actividades del proyecto (Figura 3) es posible

concluir que la fecha de finalización del proyecto es cercana al 22 de febrero.

Probabilidad acumulada:

Los resultados del análisis de riesgos proveen posibles fechas y sus probabilidades para la entrega

del sistema. La tabla muestra la probabilidad por cada posible fecha de finalización 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 finalización del proyecto.

De acuerdo con la tabla 16, la probabilidad de terminar el proyecto hasta la fase de documentación

en la fecha estimada (14 / 02/ 2007) es de sólo 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 día estipulado de finalización (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 días después de la fecha

estimada para la terminación.

4.1.4 Discusión de resultados

En cuanto a costos es inminente la necesidad de acordar un plan de mitigación relacionado con el

posible retraso del proyecto debido a las siguientes razones:

• La probabilidad de que la fecha estimada para la terminación del proyecto es menor al 50%: las

posibilidades de finalización en la fecha planeada se reducen sólo a la mitad del total de ellas, por

tanto, constituye un alto riesgo la manera como el cronograma se encuentra planeado.

• La planeación del cronograma no alcanza siquiera a satisfacer el requerimiento de al menos el

80% del cumplimiento: el desfase en días es de 12 un número que puede ser considerablemente alto

teniendo en cuenta este tipo de proyectos.

4.2 Estimación de riesgo en costos

Una segunda parte del análisis cuantitativo lo constituye la estimación de los riesgos en costos. A

continuación 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 descomposición 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 ID Costo Un cliente podrá consultar las direcciones IP que tenga disponibles.

01 4000000

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

02 4000000

Un cliente podrá cambiar el nombre de su dirección IP 03 5000000

Un cliente podrá eliminar el nombre de su dirección IP 04 5000000

El sistema deberá notificar al cliente el número de cada una de las direcciones IP que tenga adscritas.

05 2000000

El sistema deberá verificar la existencia de una dirección IP de un cliente.

06 2000000

El administrador del sistema podrá consultar los logs de la aplicación.

07 4000000

Tabla 3. Estimación de costos de los requerimientos del proyecto

119

4.2.2 Definición de rango de costos para cada uno de los requerimientos

Elemento del WBS Valor para

EAC

Requerimiento (ID) Bajo Más

Probable

Alto

01 4000000 3500000 4000000 4500000

02 4000000 3950000 4000000 5000000

03 5000000 3800000 5000000 6000000

04 5000000 4200000 5000000 5600000

05 2000000 1450000 2000000 3100000

06 2000000 1450000 2000000 3500000

07 4000000 3400000 4000000 4500000

Tabla 4. Estimación de tres puntos de los costos de los requerimientos del proyecto

4.2.3 Simulación de tres puntos y discusión de resultados

Después de llevar a cabo la simulación Montecarlo se logró determinar que la probabilidad de

satisfacer las funcionalidades del proyecto con los costos establecidos para la implementación de sus

requerimientos es de tan solo el 27.00%.

4.2.4 Formulación del nivel de prioridad y comunicación de resultados de análisis

El Anexo C (Resultado de la cualificación y cuantificación de riesgos) contiene el formulario de

revisión de la estimación final obtenida en este análisis de riesgo en calendario junto con el de riesgo

en costo y riesgo técnico. 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. A

continuación 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 análisis cuantitativo de riesgos caso de estudio y resultado del análisis cualitativo de riesgos caso

estudio.

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 técnico: el plan de riesgo es una posible adaptación de lo que se espera pudiese ser

una respuesta adecuada a este riesgo (ver Anexo C Plan de riesgo técnico).

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 serán almacenados en dicha base son los analizados a través del

método cuantitativo (riesgo en costo y riesgo en calendario).

6 Fase de control y seguimiento

Con la formulación de los planes de riesgo surge la necesidad de comprobar si en verdad éstos están

cumpliendo con el objetivo para el cual fueron formulados. Los siguientes numerales de esta

sección muestran cómo fueron verificadas las acciones que comprendían los planes establecidos

como respuesta.

6.1 Verificación del plan de riesgo

6.1.1 Según métricas del control de costos y calendario.

• Riesgo en calendario: Después de realizar nuevamente un análisis cuantitativo luego de seguir el

plan de riesgo establecido se observó que la probabilidad de terminación 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: Después de realizar nuevamente un análisis 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 máximo 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 Según las fuentes de riesgos

La fuente de riesgo a la cual estaba asociado el riesgo técnico de este caso de estudio cambió a lo

largo de este proceso de gestión y fue eliminada por tanto el estado del plan de riesgo fue ajustado

(Véase Anexo C Plan de riesgo técnico ajustado).

121

Finalizar la gestión

La gestión concluyó con el almacenamiento de los formularios para su posterior revisión. Se espera,

particularmente para el caso especial de los planes de riesgo, se pueda contar con un entorno

computacional específico que permita ordenarlos de manera que se facilite su búsqueda y a su vez se

genere la oportunidad de involucrar todos los demás pasos del modelo en un solo ambiente

computacional.

En conclusión los resultados obtenidos en este caso de estudio fueron importantes ya que

permitieron definir:

- Los puntos de función totales por cada uno de los requerimientos del proyecto.

- Los posibles riesgos, su probabilidad e impacto.

- La formulación de planes de riesgo.

- La verificación 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 debería

ser. Estos pasos son:

- Estimación de costos y presupuesto: no se contó con la información histórica suficiente para

desarrollar la estimación.

- Reuniones del tipo Wideband Delphi: a pesar de que el modelo facilita la estimación de

riesgos para que el análisis 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

123

Anexo C

FORMULARIOS DEL CASO DE ESTUDIOC

FORMULARIO PARA LA ESTIMACIÓN DEL TAMAÑO CON PUNTOS DE FUNCIÓN

|

| Requerimientos

Número de Componentes de datos

Dificultad

Archivos de Interfase (ELF)

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

Requerimientos


Dificultad

Archivos que gestionan la aplicación(ILF)

Requerimiento 1 Requerimiento2 Requerimiento 3 Requerimiento 4

Requerimiento 5 Requerimiento 6 Requerimiento 7 RET DET

Tabla de Clientes X X X X 3 8 Bajo

Tabla de Logs X 1 5 Bajo

Archivos de Reverso DNS

X X X X 1 4 Bajo

Archivos de Zona DNS X X X X 1 4 Bajo

124

Requerimientos

Número de Componentes de datos Dificultad

Entradas Externas (EI)

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

Eliminar Reverso X 2 15 Alto

Cambiar Reverso Cliente

X 2 15 Alto

Requerimientos

Número de Componentes de datos Dificultad

Salidas Externas (EO)

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

Consultar Ips Cliente

X 3 6 Medio

125

Requerimientos


Dificultad

Consultas Externas (EQ)

Requerimiento 1

Requerimiento2 Requerimiento 3 Requerimiento 4 Requerimiento 5 Requerimiento 6 Requerimiento 7 FTR DET

Consultar Logs X 1 5

Consulta Existencia Ips Cliente

X X 2 4 Bajo

Consulta Numero de Ips Cliente

X 2 4 Bajo

Total de Puntos de Función Requerimiento No Puntos de función

Requerimiento 1 26

Requerimiento 2 24

Requerimiento 3 17

Requerimiento 4 17

Requerimiento 5 1

Requerimiento 6 11

Requerimiento 7 10

Total puntos de función del sistema 99

126

Formulario para la estimación de costos

Factores de Escala

Valor Factores de Escala Extra Alto Alto Nominal Bajo Muy Bajo

Precedencia X Flexibilidad de desarrollo X

Arquitectura/ Resolución de Riesgos X Cohesión del Equipo X Madurez del Proceso X

Total Factores de Escala

B 1.1624

127

Estimación de Costos

Tamaño Requerimiento(Puntos de Función) 26 24 17 17 11 11

Factores de Escala Valor Requerimiento

1 Requerimiento

2 Requerimiento 3 Requerimiento

4 Requerimiento 5 Requerimiento 6 R7

Extra Alto

Muy Alto Alto

Nominal Bajo X

Muy Bajo X X X

Fiabilidad del Producto y Complejidad

ExtraBajo X X X

Extra Alto

Muy Alto Alto

Nominal Bajo X X X X X X X

Muy Bajo

Reutilización Requerida

ExtraBajo

Extra Alto

Muy Alto Alto

Nominal Bajo X X X X X X X

Dificultad de la Plataforma

Muy Bajo

ExtraBajo

128

129

Extra Alto

Muy Alto Alto X X X X X X X

Nominal Bajo

Muy Bajo

Experiencia del Personal

ExtraBajo

Extra Alto

Muy Alto Alto

Nominal X X X X X X XBajo

Muy Bajo

Facilidades

ExtraBajo

Extra Alto

Muy Alto Alto X X X

Nominal X Bajo X X X

Muy Bajo

Planificacion Temporal

ExtraBajo

Costo Requerimiento $ 45000000 4000000 5500000 5251035 2638600 2759061 2656890



INFORMACIÓN REQUERIDA DEL RIESGO

DESCRIPCIÓN DEL RIESGO IDENTIFICADO

Nombre riesgo Dificultad de interoperabilidad entre plataformas Fecha – Nombre 20 febrero de 2007 Componente – subsistema Web Service Categoría asociada Técnica Descripción del riesgo Posibles problemas de compatibilidad entre tipos

de datos. Fuente de riesgo Tecnología no disponible Responsabilidad Integrante del equipo de proyecto.

130


RIESGO

PROMEDIO PROBABILIDAD


PROMEDIO IMPACTO


Dificultad de interoperabilidad entre plataformas Media 0.002356 Severo 0.0518

131

RESULTADO DE LA CUALIFICACIÓN Y

CUANTIFICACIÓN DE RIESGOS

RIESGO FUENTE (Opcional)

CATEGORÍA PROBABILIDAD IMPACTO PRIORIDAD

Exceder el tiempo de duración

estimado del proyecto.

Estimaciones erróneas.

Calendario – riesgos de proyecto

53,1 4 Alta

Exceder el costo estimado del

proyecto

Estimaciones erróneas.

Costos – riesgos de proyecto

73% 4 Alta

Dificultad de interoperabilidad

entre plataformas

Tecnología no

disponible

Técnico 60% 4 Media

132


EN CALENDARIO



Exceso del tiempo estimado para la terminación del proyecto

Calendario- riesgo en proyecto

DESCRIPCIÓN

Se determinó un nivel alto de prioridad y amenaza del riesgo en el proyecto. Se debe tener en cuenta las métricas 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 terminación sea menor que la probabilidad mínima esperada (PTPE)


Estimación errónea. Contingencia


Inmediato En 1 semana


Abierto


PLAN DE CONTINGENCIA: - ACCIONES PREVENTIVAS: Reevaluar el proceso de estimación y planeación del calendario. - DECISIONES TOMADAS: Convocar a reunión a los miembros del equipo y estimar algunas actividades críticas del proyecto.

133


EN COSTO



Exceso del costo total estimado para el cumplimiento de los requerimientos del

proyecto.

Costos- riesgo en proyecto

DESCRIPCIÓN

Se determinó un nivel alto de prioridad y amenaza del riesgo en el proyecto. Se deben revisar las métricas relacionadas con la gestión 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 máximo aceptado por encima del valor planeado de costo del proyecto (DVP).






Abierto


PLAN DE CONTINGENCIA: ACCIONES PREVENTIVAS: Reevaluar el proceso de estimación y

planeación del costo del proyecto. DECISIONES TOMADAS: Convocar a reunión 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 TÉCNICO



Dificultad de interoperabilidad entre plataformas Técnica

DESCRIPCIÓN

Este riesgo representa la dificulta de la unión entre los dos ambientes de la organización: - ambiente Linux - ambiente Windows.

Ambos deben interoperar para lograr cumplir con los servicios que se le prestan a los clientes.


Tecnología no disponible Contingencia


inmediato


Abierto


PLAN DE CONTINGENCIA: ACCIONES PREVENTIVAS: Investigar y evaluar la compra de tecnologías

de integración y la viabilidad de adquirirlas. DECISIONES TOMADAS: Convocar a reunión a los miembros del equipo

para tratar las acciones preventivas dispuestas.

135

PLAN DE RIESGO EN CALENDARIO AJUSTADO



Exceso del tiempo estimado para la terminación del proyecto

Calendario - riesgo en proyecto

DESCRIPCIÓN

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.






Re-abierto


PLAN DE CONTINGENCIA: Pendiente por formular

136

PLAN DE RIESGO EN COSTO AJUSTADO



Exceso del costo total estimado para el cumplimiento de los requerimientos del

proyecto.

Costos- riesgo en proyecto

DESCRIPCIÓN

Después de realizar nuevamente un análisis 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 máximo 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 ejecución del plan fue verificada y los resultados obtenidos se consideraron apropiados.





CERRADO


137

PLAN DE RIESGO TÉCNICO AJUSTADO


Dificultad de interoperabilidad entre plataformas

Técnica

DESCRIPCIÓN

Se tomo la decisión de adquirir tecnologías para la integración, por tanto la fuente del riesgo fue

eliminada y por tanto el plan del riesgo cerrado.





CERRADO


138

Anexo D

ANEXO D

ENCUESTA SOBRE GESTIÓN DE PROYECTOS

1. Su empresa utiliza algún tipo de medición del tamaño del software: SI ___ NO ___

- En caso de utilizarlo por favor indique cual:

a. Basadas en conteo de líneas de código b. Basada en estadísticas c. Puntos de función d. Lógica difusa e. Otro?, especifique por favor, cuál y por qué?: ________________________________________________________

- En caso de no utilizarlo indique por favor la(s) razón(es): ______________________________________________________________________ 2. Su empresa utiliza algún tipo de estimación de costos: SI ___ NO ___ - En caso de utilizarlo por favor indique cual:

a. Costos por analogía ____ 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) razón(es): __________________________________________________________________ 3. Su empresa realiza estimación de riesgos

SI ___ NO ___

139

En caso de realizarla indique qué método utiliza:

a. Cuantitativo___ b. Cualitativo___ c. Otro, cuál?: __________________________________________________

4. Su empresa realiza algún tipo de gestión de riesgos:

SI ___ NO ___

- En caso de realizarla indique en cuál fuente se apoya para realizar este proceso:

a. IEE___ b. SEI___ c. PMBOOK d. Otro, cuál?: __________________________________________________

5. En su opinión beneficiaría a su empresa la propuesta de una única metodología que integrará la gestión de costos y riesgos.

SI ___ NO ___

Por qué?:___________________________________________________________ 6. Sobre qué cree hay mayor carencia de conocimientos en su empresa?

a. Gestión de riesgos ____ b. Estimación y gestión de costos ____ c. Gestión de riesgos ____ d. Estimación de métricas ____ e. Otro? Cual:___________________________________________________

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

140

141

Anexo E

ES ESPECIFICACIÓN DE LOS REQUERIMIENTOS DEL PROYECTO E

Especificación de Requerimientos

Direcciones IP e Internet dedicado flexible

10-06-2007

1.0

Sandra Patricia Forigua Oscar Ballesteros

142

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

143

El Propósito del Proyecto

Descripción de Negocio del Cliente y Motivación 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, además 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 información acerca de las direcciones IP de los clientes.

Objetivos del Proyecto.

Como se mencionó en la sección anterior con este proyecto se quieren aumentar los servicios que la organización ofrece a sus clientes, en este caso se quieren ofrecer servicios a los clientes para que administren la información 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. Básicamente el usuario del producto desarrollado es el portal empresarial de la compañía, este portal se encarga de gestionar los servicios que se les ofrecen a los diferentes clientes de la compañía.

Restricciones Obligatorias

Restricciones en la solución.

El sistema desarrollado debe implantar como interfaz para ser usado invocando servicios web, esto debido a que la organización para la que se desarrolla el producto tiene sistemas basados

144

en Linux y otros basados en Windows, lo que hace necesario la implantación se servicios web para asegurar la interoperabilidad de todos los sistemas de la organización. Este sistema debe interactuar con el DNS de la compañía, en el cual se hacen las consultas y modificaciones de la información de las direcciones ip de los clientes, este DNS se encuentra montado sobre Linux.

Ambiente de Implementación

El sistema debe ser implementado sobre Linux y debe exponer servicios web al portal de la organización, a su vez el sistema debe interactuar con el DNS de la compañía y la base de datos de clientes de la compañía.

Software pre-desarrollado El sistema utiliza varios paquetes de software que colaboran con el desempeño del software, a continuación se listan estos paquetes. • Tomcat: Este es un motor de servlets sobre el cual se montó la aplicación web que maneja

los servicios web expuestos. • Axis: Este paquete mantiene una implementación de web services. • Hibernate: este paquete facilita la interacción con bases de datos relacionales facilitando su

manejo.

Hechos Relevantes y asumpciones

Hechos El sistema debía ser desarrollado usando el lenguaje de programación Java y debe exponer servicios web en este lenguaje para permitir interacciones con el portal empresarial de la compañía. Asunciones Las siguientes son las asunciones tomadas en el desarrollo de este proyecto.

• Los archivos de configuración del DNS de la compañía, están disponibles en la máquina en la cual se instalará el software desarrollado.

• La base de datos de clientes esta disponible para su utilización desde la máquina en la que se instalará el software.

145

El alcance del Trabajo

La Situación Actual El manejo de la información de las direcciones IP pertenecientes a los clientes de la compañía, se realizaba por el personal de la compañía dependiendo de las necesidades de los clientes. Este proceso es demorado para los clientes y aumenta el trabajo para el personal de la compañía. Con este proyecto se busca automatizar este proceso, además mejorando el servicio que se les presta a los clientes de la compañía El Contexto del Trabajo El sistema debe interactuar con la infraestructura actual de la compañía por la parte de ingeniería de la compañía, en esta área toda la infraestructura se encuentra implementada en ambientes Linux, y la información de los diversos clientes se encuentra distribuida en diferentes servidores. Por otro lado el portal empresarial de la compañía 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 compañía.

El Alcance del Producto

La frontera del Producto. A continuación se mostrará el diagrama de casos de uso en donde se encuentran las funcionalidades que se implementaron para este proyecto y el límite que se estableció en el desarrollo del mismo.

146

Lista de Casos de uso del Producto.

En esta sección se listan los casos de uso implementados para el proyecto, y una descripción 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 compañía de una dirección ip.

3. Modificar Reverso IP: Esta funcionalidad permite a un cliente cambiar el nombre asociado en le DNS de la compañía de una de las direcciones ip del cliente.

4. Número de Ips Cliente: esta funcionalidad consulta el número de direcciones IP asignadas a un cliente.

5. Cliente tiene IP: este caso de uso permite consultar si un cliente específico tiene direcciones IP asignadas.

6. Borrar Reveso: este caso de uso permite eliminar el nombre asignada a la dirección ip de un cliente en el DNS de la compañía.

7. Consultar Logs: este caso de uso permite consultar los logs generados por la aplicación.

Requerimientos Funcionales En este numeral se hará una descripción 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 Descripción: Este servicio permitirá a los clientes de la compañía consultar las direcciones ip que tiene asignadas y los nombres asignados a estas direcciones en el DNS de la compañía. Justificación: Este requerimiento permite aumentar los servicios de información prestados a los clientes de la compañía y disminuye el soporte solicitado a la compañía. Solicitante: Gerente del Producto. Criterio de aceptación: El requerimiento será aceptado si la implementación del mismo obtiene la información deseada acerca de las direcciones IP de los clientes de la compañía. Satisfacción del Cliente: 4 Insatisfacción 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 Descripción: Con la implementación de este requerimiento se quiere, que los clientes de la compañía puedan consultar el numero de direcciones ip que pueden utilizar dependiendo del plan comprado con la compañía

147

Justificación: La implantación de este requerimiento permitirá a los clientes conocer automáticamente conocer que tantas direcciones ip asignadas a usado el número de direcciones IP disponibles, permitiendo mejorar el control que tiene el cliente por su infraestructura de red. Solicitante: Gerente del Producto. Criterio de aceptación: El requerimiento se considera aceptado si proporciona en todo momento la información almacenada en los servidores de la compañía de manera correcta, para todos los clientes de la organización. Satisfacción del Cliente: 4 Insatisfacción del Cliente: 5 3. Un cliente podrá cambiar el nombre de su dirección IP Identificador del Requerimiento: 3 Descripción: Este requerimiento busca permitir que los clientes de la compañía cambien los nombres registrados en el DNS de la compañía de las direcciones ip asignadas a cada cliente. Justificación: La implementación de este requerimiento permitirá disminuir el soporte solicitado por los clientes de la compañía para realizar estos cambios, además de dar más control sobre la infraestructura de red a cada uno de los clientes de la compañía. Solicitante: Gerente del Producto. Criterio de aceptación: El requerimiento se clasificará como implementado, cuando se realice la tarea asociada a este requerimiento de forma correcta. Satisfacción del Cliente: 4 Insatisfacción del Cliente: 5 4. Un cliente podrá eliminar el nombre de sus direcciones IP. Identificador del Requerimiento: 4 Descripción: La implementación de este requerimiento busca liberar los nombres asociados a las direcciones ip, cuando estas direcciones ya no se encuentren en uso. Justificación: La implantación de este requerimiento permitirá facilitar la liberación de las direcciones ip asignadas a un cliente cuando este ya no desee usar una dirección. Solicitante: Gerente del Producto. Criterio de aceptación: El requerimiento se considera implementado en cuando el sistema permite eliminar si errores el nombre de una dirección IP. Satisfacción del Cliente: 4 Insatisfacción del Cliente: 5 5. El sistema deberá notificar al cliente el número de las direcciones IP que tenga adscritas. Identificador del Requerimiento: 5

148

Descripción: El desarrollo de este requerimiento permitirá informar al cliente del número de direcciones IP que tiene actualmente asignadas y en uso. Justificación: El requerimiento permite mejorar los servicios de información prestados a los clientes de la compañía mejorar los servicios ofrecidos. Solicitante: Gerente del Producto. Criterio de aceptación: El requerimiento se considera aceptado, cuando siempre que se use el servicio retorne información valida del cliente. Satisfacción del Cliente: 4 Insatisfacción del Cliente: 5 6. El sistema deberá verificar la existencia de una dirección IP de un cliente. Identificador del Requerimiento: 6 Descripción: Este servicio es usado para verificar que las operaciones que requieren modificación a información de una dirección IP se realizasen conociendo Justificación: Este servicio permite disminuir los errores al modificar información del DNS compañía. Solicitante: Gerente del Producto. Criterio de aceptación: El requerimiento se considerara aceptado cuando la información consultada este acorde con la realidad de los clientes de la compañía. Satisfacción del Cliente: 4 Insatisfacción del Cliente: 5 7. El administrador del sistema podrá consultar los logs de la aplicación.

Identificador del Requerimiento: 7 Descripción: la aplicación desarrollada produce logs para determinar el estado del sistema, y detectar errores en la misma. Este servicio fue implementado para proporcionar información de la aplicación al administrador del sistema. Justificación: La inclusión de este servicio facilitara el soporte que se le da a la aplicación y en caso de fallo facilitar la determinación de la causa del mismo. Solicitante: Gerente del Producto. Criterio de aceptación: este requerimiento será aceptado si la consulta a estos logs proporciona información relevante del estado del proyecto. Satisfacción del Cliente: 3 Insatisfacción del Cliente: 3

149

AUTORES: SANDRA PATRICIA FORIGUA, OSCAR …pegasus.javeriana.edu.co/~riesgors/tesis...

Documents

Transcript of AUTORES: SANDRA PATRICIA FORIGUA, OSCAR …pegasus.javeriana.edu.co/~riesgors/tesis...