Tesis definitiva 4 13(lcd)

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

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
BOGOTA D.C.,
JUNIO 2007

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

Nota de Aceptación
______________________________________________________
______________________________________________________
______________________________________________________
______________________________________________________
______________________________________________________
__________________________________________
Firma del Director del Proyecto
_________________________________________
Firma del Jurado
_________________________________________
Firma del Jurado
BOGOTÁ D.C., JUNIO DE 2007

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”

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.

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

CONTENIDO
INTRODUCCIÓN.......................................................................................................15
OBJETIVOS...............................................................................................................16
OBJETIVO GENERAL:...........................................................................................16
OBJETIVOS ESPECIFICOS:...................................................................................16
1. ESTADO DEL ARTE..............................................................................................17
1.1ESTIMACIÓN DEL TAMAÑO DEL SOFTWARE...........................................17
1.1.1Metodologí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
1.3.2.3 Planificación del riesgo..............................................................................36
1.3.2.4 Seguimiento del riesgo .............................................................................37
1.4 RESULTADOS DEL CAPÍTULO.....................................................................38
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.3Generalidades 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
PRESUPUESTO........................................................................................................49
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.6.4.1 Fase de Preparación para la gestión de riesgos..........................................55
2.6.4.2 Fase de identificación del riesgo................................................................57
2.7 RESULTADOS DEL CAPÍTULO......................................................................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............................................................75
3.3.1 Modelo para la gestión de costos..................................................................75
3.3.2 Estimación de costos utilizando COCOMO II.............................................76
3.3.3 Control de costos y presupuesto...................................................................79
3.4PASO IV: GESTIONAR LOS RIESGOS............................................................80
3.4.1 Prepararse para la gestión ...........................................................................81
3.4.2 Identificar los riesgos y categorizarlos........................................................81
3.4.3 Cuantificar y cualificar los riesgos...............................................................84
3.4.4 Responder al riesgo......................................................................................88
3.4.5Fase de control y seguimiento.......................................................................89
3.5Paso V: Finalizar la gestión..................................................................................91
3.6 RESULTADOS DE L CAPÍTULO.....................................................................92
4. CONCLUSIONES...................................................................................................93
5. TRABAJOS FUTUROS..........................................................................................94
BIBLIOGRAFÍA.........................................................................................................95
Especificación de Requerimientos............................................................................145
El Propósito del Proyecto..........................................................................................148
Stakeholders...............................................................................................................148
Usuarios del Producto...............................................................................................149
Restricciones Obligatorias........................................................................................149
Hechos Relevantes y asumpciones............................................................................149
El alcance del Trabajo...............................................................................................150
El Alcance del Producto............................................................................................150
Requerimientos Funcionales.....................................................................................151

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]............................................................31
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]...............................................................................................................73
Tabla 15. Cálculo del Total de Puntos de Función...................................................74
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................80
Tabla 18. Acrónimos para la métrica de riesgo en calendario................................91

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.....................81
Figura 29. Paso I de la metodología de gestión de riesgos.........................................81
Figura 30. Delimitación según la clase Entorno de desarrollo..................................82
Figura 31. Delimitación según la clase Restricciones de programa..........................83
Figura 32. Delimitación según la clase Ingeniería del producto...............................83
Figura 33. Categorización de riesgos identificados....................................................84
Figura 34. Dinámica variante Wideband Delphi para la evaluación de riesgos
técnicos............................................................................................................................85
Figura 35. Evaluación de resultados............................................................................86
Figura 36. Respuesta al riesgo del modelo propuesto................................................89
Figura 37. Control y seguimiento del modelo propuesto...........................................89
Figura 38. Estado de planes de riesgo y revisión........................................................90
Figura 39. Métrica para riesgo en costo.....................................................................90
Figura 40. Métrica para riesgo en calendario.............................................................91

LISTA DE ANEXOS
Anexo A..........................................................................................................................98
Anexo B.........................................................................................................................114
Anexo C........................................................................................................................127
Anexo D........................................................................................................................142
Anexo E.........................................................................................................................144

GLOSARIO
AC: Término relacionado con las métricas para especificar el costo actual del proyecto [Kirkpatrick,
1992].
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].
DVP: Término relacionado con la métrica para riesgo en costo que especifica el valor del costo estimado
para el proyecto.
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, 1992].
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, 1992].
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].
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].
PTP: Término relacionado con la métrica para riesgo en calendario especifica la probabilidad de
laterminación del proyecto en una fecha dada.
PTPE: Término relacionado con la métrica para riesgo en calendario especifica la probabilidad de
cumplimiento del cronograma.
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].

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 DELARTE
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 del mismo 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, el
medio y el 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. 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.
- Archivos Internos: agrupamiento lógico de información almacenada en el sistema.
20

- 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 algorítmicos 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 dos 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
obtener una estimación del proyecto a realizarle, los métodos que pertenecen a esta categoría
21

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 cinco 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 y 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 en la experiencia y resultados obtenidos en
proyectos anteriores. Este método utiliza una ecuación en donde se relaciona el tiempo de
entrega y factores ambientales, en los cuales se refleja la capacidad de desarrollo de la
compañía.
- 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, 2004], 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
gestión de riesgos (además de las expuestas en la tabla 3 la literatura menciona otras
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 éstos se
conviertan en un problema que afecte el proyecto” [Hulett, 2004].
• 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 una mención especial a la técnica de
identificación basada en taxonomía y cuyo concepto general se explica a continuación:
- 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 y de entorno contribuyen a su ocurrencia.
La identificació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
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:
a. Son listados de riesgos que se han encontrado en proyectos similares a los que se intenta
analizar.
1
SEI: Software Egieneering Institute, 1991.
29

b. Se debe validar la aplicabilidad y validez de la información presentada en esta técnica. Es
decir, la consideración de los riesgos planteados en esta técnica es general y común a los
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.
Un factor crucial para generar una apropiada priorización es el nivel de amenaza que un riesgo
representa para el proyecto. La combinación de la probabilidad y el impacto define el nivel de
amenaza del riesgo.
• Probabilidad e impacto de un riesgo
Se define la probabilidad como la posibilidad de que un riesgo ocurra. El impacto se entiende
como una pérdida o efecto negativo obtenido como resultado de la ocurrencia de un riesgo
[Esteves, 2004].
- Niveles de probabilidad
a. Remoto: >10%
b. Improbable: (11 – 30) %
c. Probabilidad media: (31 – 50)%
d. Posible: (51 - 70) %
e. Muy probable: (>71%).
- Niveles de impacto: los niveles de impacto considerados para efectos de este trabajo son:
Mínimo: 1, Bajo: 2, Medio: 3, Severo: 4, Crítico: 5
Un riesgo con alta probabilidad de ocurrencia y generación de alto impacto es un riesgo que
contiene un alto nivel de amenaza para el proyecto y por tanto debe tener una prioridad alta.
La información del riesgo, ahora complementada con el nivel de amenaza y prioridad, se
representa en una tabla de 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
30

R5 Posible Crítico Alto
Tabla 4. Perfil de riesgos [Armstrong, 2004]
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
son identificados en el proyecto. Está diseñado para medir, según una escala de calificación,
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
El análisis cuantitativo utiliza las distribuciones de probabilidad para representar la
incertidumbre sobre algunos ítems del proyecto como lo son: las duraciones de las
actividades del calendario [Hulett, 2004] y el costo en la estructura del trabajo del proyecto
(Work Break Down Structure).
- Entradas y salidas
Las entradas de un 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.
31

Las distribuciones son generadas a partir de los rangos de riesgo para el costo o duración de
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 posibles en cada caso.
- Técnicas y herramientas
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 hora
de representar el plan o estrategia del proyecto. Está constituida por cadenas de actividades
sucesoras y predecesoras relacionadas que forman, a su vez, los caminos a 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 presente implicará, a su vez, un retraso en el proyecto. Sin embargo, aquellas
trayectorias que no son críticas no necesariamente retrasarían el proyecto si ocurriera una
demora en ellas. El método del Camino Crítico es tradicional y bien aceptado y esencial para
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écnicas 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
del riesgo se reúne con varias personas especializadas en una parte específica del proyecto
con el fin de determinar datos relevantes del proyecto relacionados con el calendario y los
costos.
c. Herramientas de simulación
El análisis cuantitativo del riesgo utiliza comúnmente el método de simulación Monte Carlo
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.
32

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.
Suponiendo un proyecto simple de 8 actividades y una fecha de entrega (Figura 3). Teniendo
en cuenta las duraciones (sólo días laborales) para cada actividad, si este proyecto está
planeado para iniciarse el 7 de enero el CPM muestra que el proyecto tomará 24.5 días y será
completado el día 14 de febrero.
Las fechas mostradas en el diagrama son estimadas por el gerente del proyecto.
Figura 3. Red de actividades de un proyecto
b. Rangos de duración de las actividades
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 recursos planeados [Hulett, 2003]. Sin embargo las experiencias en
desarrollo de proyectos han demostrado que el trabajo puede tomar mayor tiempo que el
adjudicado en el valor “más probable”. Por ello la incertidumbre en las duraciones de cada
actividad se representa mediante una estimación de tres puntos donde se definen los valores
de tiempo optimista (bajo) y pesimista (alto) que cierta actividad podría tardar.
De esta manera, una vez establecidas las actividades junto con su tiempo de desarrollo
miembros del equipo de estimación deben estimar los rangos de duración basados en los
escenarios de puntos bajos (nivel optimista) y en los escenarios de puntos altos (nivel
pesimista) de tiempo de trabajo para la culminación de estas actividades.
La tabla 5 muestra los valores máximo y mínimo de duración para las actividades del
proyecto de la figura 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 Riesgo:
Lo primero a tener en cuenta en el análisis de riesgos en costos es la “descomposición de la
estructura del trabajo”. Es a partir de ésta que se comienzan a recolectar los datos de los
costos extremos (optimista y pesimista) de cada uno de los elementos 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
riesgos adyacentes y propios de sus áreas. De manera similar a la estimación de riesgos en
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
PROBABLE
ALTO
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, 2003-3]):
Figura 5. Rango de costos para cada uno de los elementos del WBS[Hulett, 2004]
Utilizando la estimación de tres puntos para cada uno de los elementos del WBS se presenta la
siguiente simulación mediante el método Monte Carlo (Figura 6 tomada de [Hulett, 2004]):
Figura 6. Ejemplo simulación Monte Carlo para costos fuente[Hulett, 2004]
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 millones de
dó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
riesgo. Las estrategias son representadas mediante el desarrollo de planes de de acción tales
como: la creación de un plan de riesgos integrado. De acuerdo con [Marvin J. Carr et al., 1993]
el plan para un riesgo específico puede involucrar alguna de las siguientes actividades:
- Formulación de un plan de contingencia para mitigar el impacto del riesgo en caso de que
éste llegase a ocurrir.
- Evasión del riesgo mediante la reducción de su probabilidad y/o las consecuencias de su
ocurrencia. Se pueden asumir cambios en el proceso de desarrollo o diseño del producto de
software con el fin de evitar eventos indeseados.
- Aceptación del riesgo, es decir, prescindir de cualquier tipo de acción para mitigarlo y de esta
manera se asumen las consecuencias en caso de que éste ocurra.
- Transferencia: trasladar el riesgo a otra área de responsabilidad.
- Adquisición de conocimiento: Consiste en recolectar nueva información que permita a los
gerentes de proyecto analizar el riesgo con mayor profundidad y desarrollar planes nuevos de
contingencia.
• Elementos de un plan de riesgo
La fuente [Wiegers, 1998] plantea los siguientes elementos para un plan de riesgos:
- Identificador del riesgo
- Clasificación del riesgo
- Día de reporte
- Descripción del riesgo
- Probabilidad
- Impacto
- Nivel de riesgo
- Primer disparador del riesgo.
- Respuesta al riesgo <controlar, evitar, minimizar, mitigar el riesgo>
- Fecha de inicio de la respuesta al riesgo
- Fecha de finalización de la respuesta al riesgo.
- Estado actual del plan
- Plan de contingencia
- Disparador del plan de contingencia.
• Posibles estados de un plan de riesgo
36

De igual manera la lista de los posibles estados de un riesgo es [Maniasi, 2005]:
- 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.
- Plan Aprobado: El plan para el riesgo ha sido aprobado y se encuentra en condiciones de ser
ejecutado.
- Plan Verde: El plan se está ejecutando 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.
- Plan completo: El plan se ha ejecutado por completo y se encuentra pendiente la verificación
de sus resultados.
- Completado: El plan ejecutado ha sido verificado y sus resultados se consideran apropiados.
- Re-Abierto: El plan ejecutado ha sido verificado y sus resultados no se consideran apropiados
por lo cual se solicita una nueva ejecución del ciclo de vida o proceso del riesgo.
- Completo: luego de Re-Abierto el plan se ha ejecutado, ha sido verificado y sus resultados se
consideran apropiados.
1.3.2.4 Seguimiento del riesgo
Una vez identificado el riesgo se debe proseguir con un seguimiento continuo sobre éste y
permanecer atento a las señales que indican si se ha convertido en un problema. De igual
manera, se debe permanecer atento al estado en que se encuentran las acciones tomadas para
minimizarlo. Una herramienta importante de esta fase es el uso adecuado de métricas que
permitan la supervisión de los riesgos y de sus planes de mitigación.
1.3.2.5 Control del riesgo
Supervisa los planes de acción del riesgo. Tiene la capacidad de mejorar el proceso de gestión
del riesgo de acuerdo con los resultados de las métricas y eventos asociados a los riesgos.
• 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.
• Documentación
37

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.
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
adelantándose
al cronograma
por encima del cronograma
Desempeño en el presupuesto de
proyectos de TI
12, 12%
42, 42%6, 6%
40, 40%
Proyectos abandonados
ajustándose al presupuesto
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
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
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.
Modulo de
Administración
de
requerimientos
Modulo de
Administración
de
requerimientos
- Producto
- Proyecto
- Tipo de
desarrollo
Criterios
Cálculo de los
promedios
totales
Cálculo de los
promedios
totales
GUÍA DE
LA
ESTIMACIÓN
GUÍA DE
LA
ESTIMACIÓN
Estimación
individual:
EXPERIENCIA
Estimación
individual:
EXPERIENCIA
- Gerente
- Ingeniero
- Usuario
Cálculo del
esfuerzo y tamaño
según el participante
Cálculo del
esfuerzo y tamaño
según el participante
Discusión de
resultados y
acuerdo.
Discusión de
resultados y
acuerdo.
Valor del esfuerzo
total estimadoValor del esfuerzo
total estimado
- Hardware
- Software
- Comunicaciones
- Entrenamiento
- Logística
Valor HORA
PROMEDIOValor HORA
PROMEDIO
Valor del esfuerzo
total estimadoValor del esfuerzo
total estimado
X
43

2.1.2.4 ¿Qué se puede concluir acerca de esta aproximación?
A pesar de no contar con metodologías específicas, por ejemplo: puntos de función para el caso
de la estimación o COCOMO para los costos, sí existen procesos establecidos por cada empresa
o área que apoyan las actividades relacionadas con la gestión de proyectos de software. Sin
embargo, en la mayoría de veces dichos procesos hasta ahora se están instaurando y por tanto su
mejoramiento puede tardarse.
Con respecto a la gestión de costos y riesgos no se logró evidenciar un proceso como tal dentro
de todas las empresas consultadas: únicamente para el área de riesgos se está desarrollando una
parte específica dentro del plan del proyecto pero sólo involucrando una descripción general de
los elementos que lo componen (id del riesgo, estado, plan de contingencia, etc.).
Finalmente es posible establecer, con base en el estudio realizado por [ACIS, 2007], la
necesidad inmediata de instaurar procesos con actividades y recursos contundentes en las
empresas y áreas de tecnología. Los resultados expuestos por la encuesta anual de gerencia de
proyectos y la aproximación realizada por este trabajo son equivalentes en varios aspectos:
- Los sobrecostos pueden obedecer a la carencia de un proceso para el manejo del presupuesto
a lo largo del proyecto.
- El incumplimiento de las fechas de entrega del proyecto tienen como origen la falta de una
debida estimación y control de calendario.
- El hecho de que hasta ahora se están instaurando estos procesos en las empresas y áreas
tecnológicas supone una falta de experiencia que hasta el momento no ha podido ser
documentada y deja al gerentes de proyecto sin un recurso valioso a la hora de estimar y
gestionar proyectos de software.
2.1.3 Generalidades de las empresas de desarrollo en el Reino Unido
Los datos relacionados en esta sección proyectan el estado de las empresas desarrolladoras de
software en el Reino Unido. La razón por la cual son citados en este trabajo tiene que ver con el
hecho de contar con otros contextos que permitan encontrar similitudes y nuevos aspectos que
complementen la caracterización de gestión de proyectos nacional.
Las siguientes estadísticas fueron recolectadas de reportes generados por Standish Group
compañía que publicó los resultados acerca de un estudio desarrollado sobre diferentes
empresas desarrolladoras de software en el Reino Unido.
44

• Desempeño en proyectos de TI
Proyecto abandonados:
- En el año 1995: 53%
- En el año 1999: 46%
- En el año 2003: 51%
• Proyectos terminados con problemas:
- En el año 1995: 31%
- En el año 1999: 28%
- En el año 2003: 15%
• Proyectos terminados con éxito:
- En el año 1995: 16%
- En el año 1999: 26%
- En el año 2003: 34%
• Las estadísticas de las principales causas de fracaso en proyectos de TI según el Standish
Group son:
- Sobrecostos:
En promedio el sobrecosto en el que incurren grandes compañías en sus proyectos de TI es del
178%, mientras que para las medianas y las pequeñas es del 182% y 214% respectivamente.
- Atraso en el cronograma:
En promedio el atraso en cronograma en el que incurren grandes compañías en sus proyectos
de TI es del 230%, mientras que para las medianas y las pequeñas es del 202% y 239%
respectivamente.
Como fue mencionado en la parte introductoria del capítulo, es importante resaltar este estudio
debido a que puede llegar a reflejar similitudes, en algunos aspectos, con el contexto de los
proyectos de software en Colombia permitiendo evidenciar otros no contemplados en los
estudios y estadísticas nacionales. En este caso, problemas como el sobrecosto y el atraso en el
cronograma son comunes a ambos contextos, lo cual sugiere la necesidad inmediata de una fase
de planeación adecuada que soporte la mayoría de los proyectos de software que son
emprendidos en Colombia y en otros países.
2.2 PLANTEAMIENTO DEL MODELO PARA LA ESTIMACIÓN DEL TAMAÑO
Esta sección contiene un análisis comparativo sobre las diversas metodologías para la
estimación del tamaño del software con el fin de proponer las bases del modelo a desarrollar en
el capítulo siguiente.
45

2.2.1 Evaluación de métodos para la estimación del tamaño del software
Con el fin de proponer un modelo para la estimación del tamaño basado en las metodologías ya
expuestas para ello, se presenta la siguiente tabla en donde se evalúan las virtudes y defectos de
cada una permitiendo la escogencia adecuada del método que será utilizado en el modelo
propuesto:
Tabla 6. Evaluación de los métodos para estimación del tamaño del software
2.2.2 Método escogido para la estimación del tamaño del software
De acuerdo con los aspectos expuestos en la tabla 6 y considerando el estado del arte de la
estimación de proyectos de software, es posible afirmar que las metodologías son muy variadas
y su uso, mas que depender de lo que ofrecen, depende del entorno y la organización que quiera
implementarlo, así como los procesos de la misma y el método de desarrollo de software que se
utilice.
METODO DESCRIPCIÓN VENTAJA DESVENTAJA
Conteo de Líneas de
Código
Este método toma las líneas de
código necesarias para la
construcción de un sistema como
medida de su tamaño.
-Se basa en el producto del
desarrollo de software.
-Fácil Conteo
-Dependiente del lenguaje de
programación.
- Dependiente de los
programadores.
- Estimación difícil en etapas
tempranas del desarrollo.
Estimación basada en la
estadística
Este método divide, el sistema en
componentes, para así realizar
estimaciones sobre cada
componente por analogía con
otros componentes ya realizados,
luego obtienen una estimación
pesimista, media y optimista.
-Disminuye la incertidumbre,
dividiendo el sistema en
componentes.
-Se basa en un proceso
estadístico, que ofrece un
grado de seguridad.
-El grado de confiabilidad de
las estimaciones se hace
mejor a medida que se
realicen más estimaciones.
-Si no se cuenta con datos
históricos, las estimaciones
serán poco confiables.
-El método requiere un
tiempo para converger en
buenas estimaciones.
Estimación Por Lógica
Difusa
Este método se basa en
estimación por analogía, ya que
se toma información histórica del
tamaño de diferentes proyectos, y
se realizan categorías de tamaño
en las que se encasillan los
proyectos, luego el nuevo
proyecto se encasilla en una de
estas categorías, lo cual da un
aproximado del tamaño del
proyecto.
-Es un método sencillo de
aplicar.
-Da un rango del tamaño del
software, lo que no se
compromete del todo con un
tamaño exacto
-Depende de la información
histórica, de otros proyectos.
- El proyecto estimado
posiblemente no esté en el
rango especificado, lo que
podría resultar en una
estimación muy alejada de la
realidad.
Requiere un tiempo de
convergencia.
Estimación Por Puntos de
Función
Se basa en la funcionalidad del
sistema. Para realizar su
estimación se deben determinar
los componentes de puntos de
función para el sistema y
clasificarlos según su dificultad.
-Al depender de la
funcionalidad del sistema, su
aplicación se puede realizar
desde la definición de los
requerimientos del sistema.
-Es Independiente del
Lenguaje.
-Fácil Utilización.
Es posible que no se
encuentren todos los
componentes necesarios, lo
que daría una estimación
equivocada.
No es muy adecuado para
cuando el software se
encuentra construido.
46

De igual manera se aprecia que las técnicas suelen ser muy sencillas, debido a que solo
requieren de una persona para obtener la información del tamaño.
Sin embargo, se dejan de lado muchos aspectos importantes que deben ser considerados en la
estimación, otros métodos utilizan la funcionalidad del software, por ejemplo, para implantar
una debida estimación.
Pensando en la funcionalidad del software y en la facilidad que los puntos de función pueden
aportar a las actividades de estimación del tamaño, este último aspecto también importante
porque atribuye la sencillez o simplicidad que una pequeña empresa de desarrollo necesita de
este tipo de procesos, los puntos de función constituyen el método seleccionado para llevar a
cabo la fase de estimación del modelo a proponer.
2.2.3 ¿Por qué se escogió este método?
La característica principal por la que se escogió este método fue la flexibilidad que presenta
para ser utilizado en etapas tempranas del desarrollo del software, en donde no es mucho lo que
se sabe con respecto a las características del proyecto: esta metodología se basa en la
funcionalidad del sistema a implementar y no en el producto a crear.
El método puede ser utilizado en diversas etapas del proyecto, a medida que aumente el
conocimiento acerca del proyecto también aumentará la calidad de las estimaciones,
haciéndolas cada vez más acercadas a la realidad. Otra característica destacable del análisis de
puntos de función, es su dependencia del lenguaje, esto debido a que se basa en la
funcionalidad, lo que hace que esta metodología sea ideal para cualquier tipo de sistema.
2.2.4 Esquema del método de Puntos de función
Para estimar el tamaño de software por puntos de función, se deben encontrar algunos
elementos como las salidas y entradas del sistema y bases de datos/archivos en donde se guarda
la información. Posteriormente se debe encontrar la dificultad de cada componente. Finalmente
mediante la aplicación de una serie de formulas sencillas se obtiene el número total de puntos de
función que componen el software.
2.3 PLANTEAMIENTO DEL MODELO PARA LA ESTIMACIÓN DE COSTOS DEL
PROYECTO
estimación del costo del proyecto con el fin de proponer las bases del modelo a desarrollar en el
próximo capítulo. Cabe resaltar en este punto los pasos considerados para realizar una buena
estimación de costos:
47

- Estimación del Costo del Proyecto.
- Estimación del Presupuesto del Proyecto.
- Control del Presupuesto del Proyecto.
También sería conveniente recordar que para estimar el costo de un proyecto se debe conocer el
tamaño del mismo, por lo cual primero se debe estimar el tamaño del proyecto.
2.3.1 Evaluación de métodos y modelos para la estimación de costos
En este campo se encontraron diversas metodologías para la estimación de costos del software a
construir. A continuación se muestra una tabla mostrando las fortalezas y debilidades de cada
una las metodologías que descritas en el capítulo del estado del arte:
METODOLOGÍA DESCRIPCIÓN VENTAJAS DESVENTAJAS
NO ALGORÍTMICOS
Costos por Analogía
El costo del proyecto se
estima en base al costo de
proyectos similares ya
realizados.
Si se cuenta con buena
información histórica de
proyectos pasados, se
pueden obtener
estimaciones bastante
acertadas.
Las estimaciones son
sencillas de realizar
Se requiere información
histórica de proyectos para
realizar la estimación.
Para que el método sea
efectivo se requiere ajustar
el método con información
de la organización que
realiza el proyecto.
Precio a Ganar
Se ajusta el precio del
proyecto, para mejorar la
propuesta más económica
realizada, con el fin de
ganar el proyecto.
La estimación se realiza
de una manera muy
sencilla.
Es muy probable que se
gane el proyecto.
La estimación muy
seguramente está mal, y el
costo real estará muy
alejado de la realidad.
Puede ocasionar que el
proyecto lleve a perdidas.
MÉTODOS ALGORÍTMICOS
COCOMO
Modelo empírico para la
estimación del esfuerzo y
costo del desarrollo de un
sistema de software, se
basa en el uso de
multiplicadores de
esfuerzo, para realizar una
estimación del esfuerzo y
costo
Involucra varios factores
que inciden en el costo
del proyecto.
No requiere en principio
el uso de datos de
proyectos anteriores.
Permite su utilización a
lo largo de todo el
proyecto.
Predisposición por parte
del equipo de gestión ante
la utilización de fórmulas
matemáticas.
Es un proceso extenso para
completar la estimación
Algunos factores son algo
complicados de
determinar.
SLIM
Se basa en la distribución
de poder hombre, se usa la
ecuación de software, en
donde se relaciona, el
tiempo de entrega, factores
ambientales, en los cuales
se refleja la capacidad de
desarrollo de la compañía
Usa factores del proyecto
y producto, para realizar
la estimación, estos
factores inciden en el
costo del proyecto.
Predisposición por parte
del equipo de gestión ante
la utilización de fórmulas
matemáticas.
Es un proceso algo largo,
para completar la
estimación
Tabla 7. Evaluación de los métodos para la estimación de costos
De acuerdo con la tabla 7 se evidencia un amplio rango de metodología para la estimación del
costo, y cada uno con características diferentes, que los hacen aplicables en diferentes entornos.
48

Existen metodologías basadas en la experiencia de los gerentes de proyectos, algunas un poco
menos elaboradas, lo que intentan es ganar un contrato en cambio de realizar una estimación
seria.
De igual manera existen metodologías más complicadas que utilizan modelos empíricos y
matemáticos para estimar el costo de un software, evaluando a su vez, una serie de factores
concernientes al tamaño del software, a la organización, experiencia en esta clase de proyectos,
etc.
2.3.2 Modelo escogido para la estimación de costos
En el caso de la estimación de costos se escogió como metodología COCOMO II, aunque esta
es un tanto complicada, debido a la utilización de varias formulas que estiman el costo de un
proyecto, cuenta con la ventaja de usar para su estimación un amplio dominio de factores que
inciden sobre el costo del proyecto, tales como: retrasos en el cronograma, pérdida de personal,
etc.
2.3.3 Esquema del modelo COCOMO II
El modelo se divide en 3 submodelos dependiendo del conocimiento del proyecto, es decir si no
se conoce mucho acerca del proyecto, para una estimación inicial se usaría el modelo de
composición de aplicaciones , en una etapa más avanzada del proyecto, se podría utilizar el
modelo de diseño anticipado, y en el momento que se encuentren diseñada la arquitectura del
proyecto, se podría utilizar el modelo de postarquitectura, estos modelos aumentan en
complejidad a medida que se avanza las diferentes fases del proyecto, es decir el modelo de
composición de aplicaciones es mucho más sencillo que el de diseño anticipado y
postarquitectura, de igual manera las calidad de las estimaciones aumenta cuando se usan
métodos mas complicados.
Para este modelo se usará el modelo de diseño anticipado, ya que es un modelo adecuado para
realizar estimaciones en las que se tienen en cuenta varios parámetros que inciden en gran parte
en el costo de un proyecto, y a su vez disminuye la dificultad para realizar estas estimaciones,
adicionalmente se desarrollarán plantillas para la realización estas estimaciones, con lo que se
disminuirá en gran medida la dificultad en la aplicación del método.
2.4 PLANTEAMIENTO DEL MODELO PARA LA ESTIMACIÓN DEL PRESUPUESTO
estimación del presupuesto del proyecto con el fin de proponer las bases del modelo a
desarrollar en el capítulo 3.
49

Tesis definitiva 4 13(lcd)

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (19)

Similar a Tesis definitiva 4 13(lcd)

Similar a Tesis definitiva 4 13(lcd) (20)

Último

Último (9)

Tesis definitiva 4 13(lcd)