autores: sandra patricia forigua, oscar …pegasus.javeriana.edu.co/~riesgors/tesis...
Post on 23-Jun-2018
214 Views
Preview:
TRANSCRIPT
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
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
Esta sección contiene un análisis comparativo sobre las diversas metodologías para la
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
Esta sección contiene un análisis comparativo sobre las diversas metodologías para la
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
Esta sección contiene un análisis comparativo sobre las diversas metodologías para la
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 deamenazade 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
Baja 5 Alta 6 Media 4
Entradas Externas (EI)
Baja 3 Alta 7 Media 5
Salidas Externas (EO)
Baja 4 Alta 6 Media 4
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
Número de componentes de datos
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
Número de componentes de datos
Dificultad
Entradas Externas (EI) Requerimiento 1 Requerimiento2 Requerimiento 3 Requerimienton FTR DET
Requerimientos
Número de componentes de datos
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
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
FORMULARIO DE EVALUACIÓN DE RESULTADOS
Fecha evaluación RIESGO
PROMEDIO
PROBABILIDAD
DESVIACIÓN ESTÁNDAR
MODA
PROMEDIO IMPACTO
DESVIACIÓN ESTÁNDAR
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
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
Número de Componentes de datos
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
Número de Componentes de datos
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
FORMULARIO DE RIESGOS IDENTIFICADOS
FORMULARIO DE RIESGOS IDENTIFICADOS
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
FORMULARIO DE EVALUACIÓN DE RESULTADOS
RIESGO
PROMEDIO PROBABILIDAD
DESVIACIÓN ESTÁNDAR
PROMEDIO IMPACTO
DESVIACIÓN ESTÁNDAR
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
FORMULARIO DE PLAN DE RIESGO
EN CALENDARIO
FORMULARIO DE PLAN DE RIESGO
NOMBRE DEL RIESGO CATEGORÍA
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)
FUENTE TIPO PLAN DE RIESGO
Estimación errónea. Contingencia
FECHA INICIO DE PLAN FECHA FINAL DE PLAN
Inmediato En 1 semana
ESTADO DEL PLAN DEL RIESGO RESPONSABLE
Abierto
ACCIONES A LLEVAR A CABO
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
FORMULARIO DE PLAN DE RIESGO
EN COSTO
FORMULARIO DE PLAN DE RIESGO
NOMBRE DEL RIESGO CATEGORÍA
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).
FUENTE TIPO PLAN DE RIESGO
Estimación errónea. Contingencia
FECHA INICIO DE PLAN FECHA FINAL DE PLAN
Inmediato En 1 semana
ESTADO DEL PLAN DEL RIESGO RESPONSABLE
Abierto
ACCIONES A LLEVAR A CABO
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
FORMULARIO DE PLAN DE RIESGO
NOMBRE DEL RIESGO CATEGORÍA
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.
FUENTE TIPO PLAN DE RIESGO
Tecnología no disponible Contingencia
FECHA INICIO DE PLAN FECHA FINAL DE PLAN
inmediato
ESTADO DEL PLAN DEL RIESGO RESPONSABLE
Abierto
ACCIONES A LLEVAR A CABO
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
FORMULARIO DE PLAN DE RIESGO
NOMBRE DEL RIESGO CATEGORÍA
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.
FUENTE TIPO PLAN DE RIESGO
Estimación errónea. Contingencia
FECHA INICIO DE PLAN FECHA FINAL DE PLAN
Inmediato En 1 semana
ESTADO DEL PLAN DEL RIESGO RESPONSABLE
Re-abierto
ACCIONES A LLEVAR A CABO
PLAN DE CONTINGENCIA: Pendiente por formular
136
PLAN DE RIESGO EN COSTO AJUSTADO
FORMULARIO DE PLAN DE RIESGO
NOMBRE DEL RIESGO CATEGORÍA
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.
FUENTE TIPO PLAN DE RIESGO
Estimación errónea. Contingencia
FECHA INICIO DE PLAN FECHA FINAL DE PLAN
ESTADO DEL PLAN DEL RIESGO RESPONSABLE
CERRADO
ACCIONES A LLEVAR A CABO
137
PLAN DE RIESGO TÉCNICO AJUSTADO
NOMBRE DEL RIESGO CATEGORÍA
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.
FUENTE TIPO PLAN DE RIESGO
Estimación errónea. Contingencia
FECHA INICIO DE PLAN FECHA FINAL DE PLAN
ESTADO DEL PLAN DEL RIESGO RESPONSABLE
CERRADO
ACCIONES A LLEVAR A CABO
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
top related