PROPUESTA DE UN MODELO DE ANLISIS PARA ESTIMACIN DEL

TAMAO DEL SOFTWARE Y GESTIN DE COSTOS Y RIESGOS A PARTIR DE

REQUERIMIENTOS FUNCIONALES.

AUTORES: SANDRA PATRICIA FORIGUA, OSCAR ARTURO BALLESTEROS

PONTIFICIA UNIVERSIDAD JAVERIANA

FACULTAD DE INGENIERIA
CARRERA DE INGENIERIA DE SISTEMAS
BOGOTA D.C.,
JUNIO DE 2007
 PROPUESTA DE UN MODELO DE ANLISIS PARA ESTIMACIN DEL
TAMAO DEL SOFTWARE Y GESTIN DE COSTOS Y RIESGOS A PARTIR DE
REQUERIMIENTOS FUNCIONALES

AUTORES: SANDRA PATRICIA FORIGUA, OSCAR ARTURO BALLESTEROS

TRABAJO DE GRADO PRESENTADO PARA OPTAR EL TTULO DE INGENIERO

DE SISTEMAS

INGENIERO LUIS CARLOS DAZ

PROFESOR ASISTENTE
DIRECTOR DEL TRABAJO DE GRADO

PONTIFICIA UNIVERSIDAD JAVERIANA

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

FACULTAD DE INGENIERIA

CARRERA DE INGENIERIA DE SISTEMAS

Rector Magnfico: Padre Gerardo Remolina Vargas S.J.

Decano Acadmico Facultad de Ingeniera: Ingeniero Francisco Javier Rebolledo

Muoz

Decano del Medio Universitario Facultad de Ingeniera: Padre Sergio Bernal Restrepo
S.J.

Director Carrera de Ingeniera de Sistemas: Ingeniera Hilda Cristina Chaparro Lpez

Director Departamento de Ingeniera de Sistemas: Ingeniero Germn Alberto Chavarro

Flrez
 Nota de Aceptacin

______________________________________________________

______________________________________________________

______________________________________________________

______________________________________________________

______________________________________________________

__________________________________________

Firma del Director del Proyecto

_________________________________________

Firma del Jurado

_________________________________________

Firma del Jurado

BOGOT D.C., JUNIO DE 2007

Artculo 23 de la Resolucin No. 1 de Junio de 1946:

La Universidad no se hace responsable de los conceptos emitidos por sus alumnos en

sus proyectos de grado.

Slo velar porque no se publique nada contrario al dogma y la moral catlica y porque
no contengan ataques o polmicas puramente personales. Antes bien, que se vean en
ellos el anhelo de buscar la verdad y la Justicia
DEDICATORIA:

Este trabajo es en primer lugar el resultado del apoyo de muchas personas que con la ayuda de
Dios nos acompaaron para lograr culminar lo que un da nos propusimos llenos de
entusiasmo y dedicacin como fue estudiar la carrera de Ingeniera de Sistemas, por lo cual
dedicamos a todos ellos este logro tan importante en nuestra vidas.

A nuestros padres que siempre estuvieron a nuestro lado dndonos una voz de aliento cuando en
momentos difciles necesitbamos de un consejo y siempre creyeron en nosotros,
demostrndonos sus valores e ideales los cuales retomamos para la consecucin de esta meta.

Y a Dios porque gracias a su compaa y fuerza este logro es alcanzado.

 RESUMEN

Este trabajo de grado se encuentra orientado al estudio de las metodologas, mtodos,

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

Fundamentalmente se recogen las principales bases conceptuales acerca de la estimacin y la

gestin de costos y riesgos, y profundiza en ellas con el fin de alcanzar un anlisis comparativo
que define la seleccin de los mtodos y metodologas, como el sustento de un modelo que
apoye el desarrollo de estas actividades en pequeas empresas de desarrollo de software
colombianas.

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

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

Por ltimo se expone la parte prctica del modelo a travs de un caso de estudio. Esta
aplicacin experimental, desarrollada sobre un proyecto de redes de comunicacin, permiti
identificar aspectos del modelo que deberan ser modificados o incluidos logrando as su
refinamiento de manera gradual.
 CONTENIDO

INTRODUCCIN....................................................................................................................15
OBJETIVOS.............................................................................................................................16
OBJETIVO GENERAL:........................................................................................................16
OBJETIVOS ESPECIFICOS:................................................................................................16
1. ESTADO DEL ARTE...........................................................................................................17
1.1 ESTIMACIN DEL TAMAO DEL SOFTWARE........................................................17
1.1.1 Metodologas de estimacin del tamao del software.............................................18
1.2 GESTIN DE COSTOS.................................................................................................21
1.2.1 Estimacin del costo del proyecto.............................................................................21
1.2.2 Estimacin del presupuesto del proyecto..................................................................24
1.2.3 Control del presupuesto del proyecto........................................................................26
1.3 GESTIN DEL RIESGO.................................................................................................27
1.3.1 Modelos existentes....................................................................................................28
1.3.2 Elementos de la gestin del riesgo............................................................................29
1.4 RESULTADOS DEL CAPTULO................................................................................38
2. PROPUESTA CONCEPTUAL DEL MODELO................................................................39
2.1 CARACTERIZACIN DE PROYECTOS DE TECNOLOGA DE LA
INFORMACIN...................................................................................................................39
2.1.1 Caracterizacin de proyectos de TI en Colombia......................................................40
2.1.2 Aproximacin a la actualidad de las empresas y reas de tecnologa colombianas...42
2.1.3 Generalidades de las empresas de desarrollo en el Reino Unido.............................44
2.2 PLANTEAMIENTO DEL MODELO PARA LA ESTIMACIN DEL TAMAO.........45
2.2.1 Evaluacin de mtodos para la estimacin del tamao del software.........................46
2.2.2 Mtodo escogido para la estimacin del tamao del software..................................46
2.2.3 Por qu se escogi este mtodo?.............................................................................47
2.2.4 Esquema del mtodo de Puntos de funcin...............................................................47
2.3 PLANTEAMIENTO DEL MODELO PARA LA ESTIMACIN DE COSTOS DEL
PROYECTO..........................................................................................................................47
2.3.1 Evaluacin de mtodos y modelos para la estimacin de costos..............................48
2.3.2 Modelo escogido para la estimacin de costos..........................................................49
2.3.3 Esquema del modelo COCOMO II...........................................................................49
2.4 PLANTEAMIENTO DEL MODELO PARA LA ESTIMACIN DEL PRESUPUESTO
49
2.4.1 Evaluacin de mtodos para la estimacin del presupuesto......................................50
2.4.2 Mtodo escogido para la estimacin del presupuesto................................................51
2.5 PLANTEAMIENTO DE UNA METODOLOGA PARA EL CONTROL DEL
PRESUPUESTO....................................................................................................................51
2.5.1 Evaluacin de mtodos para el control del presupuesto............................................51
2.5.2 Mtodo escogido para el control del Presupuesto.....................................................52
2.6 PLANTEAMIENTO DEL MODELO DE GESTIN DE RIESGOS..............................53
2.6.1 Principios bsicos en los cuales debera basarse una metodologa de gestin de
riesgos................................................................................................................................53
2.6.2 Requisiciones de una metodologa de gestin de riesgos..........................................53
2.6.3 Por qu se escogi esta metodologa?.....................................................................54
2.6.4 Fases o pasos de la metodologa...............................................................................55
2.7 RESULTADOS DEL CAPTULO...................................................................................65
3. MODELO PARA LA ESTIMACIN Y GESTIN DE PROYECTOS...........................66
3.1 PASO I: DEFINIR LOS REQUERIMIENTOS FUNCIONALES DEL PROYECTO.....67
3.1.1 Proceso de definicin de requerimientos...................................................................67
3.1.2 Descripcin del proyecto y especificacin de los requerimientos............................68
3.2 PASO II: ESTIMAR EL TAMAO DEL SOFTWARE...................................................68
3.2.1 Modelo para la estimacin del tamao......................................................................68
 3.3 PASO III: GESTIONAR LOS COSTOS..........................................................................75
3.3.1 Modelo para la gestin de costos..............................................................................75
3.3.2 Estimacin de costos utilizando COCOMO II..........................................................76
3.3.3 Control de costos y presupuesto................................................................................79
3.4 PASO IV: GESTIONAR LOS RIESGOS........................................................................81
3.4.1 Prepararse para la gestin.........................................................................................81
3.4.2 Identificar los riesgos y categorizarlos.....................................................................82
3.4.3 Cuantificar y cualificar los riesgos............................................................................84
3.4.4 Responder al riesgo..................................................................................................88
3.4.5 Fase de control y seguimiento.................................................................................89
3.5 Paso V: Finalizar la gestin.............................................................................................91
3.6 RESULTADOS DE L CAPTULO..................................................................................92
4. CONCLUSIONES................................................................................................................93
5. TRABAJOS FUTUROS.......................................................................................................94
BIBLIOGRAFA........................................................................................................................95
 LISTA DE TABLAS

Tabla 1. Trminos del anlisis del valor ganado.......................................................................27

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

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

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

Anexo A.......................................................................................................................................................98
Anexo B.....................................................................................................................................................114
Anexo C.....................................................................................................................................................125
Anexo D.....................................................................................................................................................141
Anexo E.....................................................................................................................................................143
 GLOSARIO

AC: Trmino relacionado con las mtricas 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): Mtodo de la ruta critica, este mtodo es usado en la administracin de
proyectos, para determinar la secuencia de actividades dentro de la red del proyecto que determina la
duracin del proyecto [Hulett, 2004].

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

DVP: Trmino relacionado con la mtrica 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 trminos de un proyecto se define mediante la formula
EAC=ETC + ACWP, donde ETC representa el valor de lo que habr que gastar hasta el final del proyecto
y ACWP el valor del cote total del proyecto al final de ste [Thayer, 2003].

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

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

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

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

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

Mtodo Wideband Delphi: Es un mtodo de estimacin basado en el consenso, es decir la estimacin es

realizada por un conjunto de personas que deben llegar a un acuerdo acerca de lo que se esta estimando,
este mtodo se ha utilizado en muchas reas exitosamente [Labdelaoui, 2001].

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

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

PTP: Trmino relacionado con la mtrica para riesgo en calendario especifica la probabilidad de
laterminacin del proyecto en una fecha dada.

PTPE: Trmino relacionado con la mtrica para riesgo en calendario especifica la probabilidad de
cumplimiento del cronograma.

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

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

SEI (Software Engineering Institute): Instituto federal de investigacin, dedicado a la investigacin de

temas relacionados con la ingeniera de software y el mejoramiento en el proceso de desarrollo de
software [Marvin J. Carr et al., 1993].

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

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

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

La definicin de los criterios para la clasificacin de las metodologas as como el

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

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

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

15
 OBJETIVOS

OBJETIVO GENERAL:

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

OBJETIVOS ESPECIFICOS:

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

2. Determinar metodologas especficas a las reas de estimacin de tamao, gestin de costos y

riesgos acordes con la clasificacin desarrollada y fundamentadas en los requerimientos
identificados en un proyecto de desarrollo.

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

4. Verificar experimentalmente la validez del modelo mediante su aplicacin en al menos un

caso de estudio, representado en un proyecto de software cuya fase de recoleccin de
requerimientos se encuentre completamente definida mediante un modelo de anlisis de
requerimientos.

16
 1. ESTADO DEL ARTE

El contenido presentado en este captulo es el resultado de un estudio estructurado sobre las

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

1.1 ESTIMACIN DEL TAMAO DEL SOFTWARE

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

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

Lo realmente importante de la estimacin no es necesariamente que sta sea 100% confiable,

sino el hecho de que su realizacin contribuya en la determinacin del costo total del proyecto,
por lo cual, se recomienda que durante el desarrollo del mismo se realicen estimaciones y se
corrijan las anteriores con la informacin que se vaya recolectando, lo que a largo plazo, ayuda
a que las estimaciones que se hagan sobre proyectos futuros sean cada vez ms acertadas.

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

17
construyendo software. Dichos documentos tambin requieren tiempo y recursos, que
incrementan el tamao del software en desarrollo.

1.1.1 Metodologas de estimacin del tamao del software

A continuacin se presenta una descripcin de cada una de las metodologas de estimacin del
tamao, consideradas como las ms importantes y ms usadas por la industria. Como fue
mencionado anteriormente existen bsicamente dos aproximaciones a esta estimacin: el conteo
de lneas de cdigo y el conteo de puntos de funcin. A continuacin describiremos dichas
aproximaciones [C. Shi Kuo, 2002].

Estimacin basada en lneas de cdigo.

Esta estimacin se podra catalogar como de tipo tardo, ya que el nmero total de lneas de
cdigo slo se puede conocer cuando el producto est terminado, aunque la tarea no es tan
sencilla como contar la longitud de cada archivo; se debe acordar un formato, en donde se
especifique qu es lo que se va a contar y qu no. Por ejemplo, los comentarios escritos en el
cdigo no deberan ser contados, por lo cual slo se debe contar, lo que se especifique a ser
contado.
Dentro de esta categora existen varias metodologas las cuales usan las lneas de cdigo como
base para la realizacin de su estimacin [C. Shi Kuo, 2002]. A continuacin se explican
algunas de estas metodologas.

Estimacin por conteo de bloques

Este enfoque se basa en estimar el nmero de funciones esperadas que tendr el sistema. Se
puede ver como un enfoque de estimacin temprana debido a que estima el nmero de
funciones esperadas. Por tanto, se cuenta con poca informacin acerca del proyecto con lo que
las estimaciones no podran ser muy exactas. De esta manera, a medida que avanza el proyecto
es deseable que las estimaciones fueran ms coherentes con la realidad.
Es posible que el mtodo pueda ser complementado con funciones estadsticas para encontrar
una estimacin ms precisa. Con este fin es usada la desviacin estndar, obtenida a partir de la
informacin de proyectos pasados ya realizados, lo cual mejora en gran parte las estimaciones
para la organizacin.

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

a. Estimar el nmero de bloques, o componentes de software esperados.

b. Multiplicar el nmero de bloques por el tamao esperado de cada tipo de bloque.
c. Calcular la desviacin estndar para dicho proyecto.

18
d. Aplicar el mtodo repetidamente para los diferentes niveles de detalle, y as obtener una
estimacin ms precisa.

Estimacin del tamao estadstica

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

a. Determinar las funciones que compondrn el nuevo sistema.

b. Buscar informacin acerca del tamao de funciones similares ya desarrolladas.
c. Identificar las diferencias entre las funciones similares y las nuevas.
d. Para cada componente o funcin a estimar, se deben estimar tres parmetros, el menor, el
medio y el mximo tamao de cada uno de los componentes o funciones.
e. Calcular la media estadstica y desviacin estndar de cada uno de los nmeros obtenidos en
el numeral anterior.
f. Tabular cada uno de estos datos obtenidos.
g. Calcular la media total del proyecto, y la desviacin estndar del proyecto.

Estimacin por lgica difusa

Este mtodo se basa en dividir el proyecto en categoras de tamao. Dependiendo de la cantidad
de lneas de cdigo producidas en cada una clasificarlas en grande, mediano y pequeo. Para
realizar esta categorizacin se requiere tener informacin de proyectos anteriores para generar
los grupos antes descritos.

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

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

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

El Anlisis de Punto Funcin es una tcnica que, mediante la descomposicin de un sistema en

componentes ms pequeos, permite que stos puedan ser mejor comprendidos y analizados en
forma individual.

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

El Anlisis del Punto Funcin es un mtodo estndar de medicin de desarrollo de software

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

El mtodo realiza su estimacin contando el nmero de componentes de cada clase de punto

funcional, luego se estima la complejidad de cada uno de los componentes medidos, alta o baja,
segn sea el caso, luego se multiplica cada contador de puntos de funcin por el valor adecuado,
y se suma el total de puntos de funcin.

Cada uno de los tipos de puntos de funcin se describe a continuacin.

- Entradas externas: Datos o entradas de control al sistema que causan que el sistema lleve a
cabo algn procesamiento.
- Salidas Externas: datos o salidas de control que salen del sistema, luego de que un
procesamiento a sido llevado a cabo.
- Peticiones Externas: Solicitudes del sistema que requieren inmediata atencin.
- Interfaces Externas: Archivos o programas que salen del sistema.
- Archivos Internos: agrupamiento lgico de informacin 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 GESTIN DE COSTOS

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

1.2.1 Estimacin del costo del proyecto

Como es de suponerse, el costo de un proyecto se encuentra directamente ligado al tamao del

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

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

Mtodos no algortmicos:
Estos mtodos estn basados especficamente en las capacidades de juicio de las personas que
realizan estas estimaciones, las personas se basan en su experiencia o experiencia de otros para
obtener una estimacin del proyecto a realizarle, los mtodos que pertenecen a esta categora

21
muchas veces requieren de datos histricos para las estimaciones, lo que muchas veces es algo
problemtico ya que no todas las organizaciones mantienen informacin de sus proyectos
anteriores. Estos pueden ser:

- Costos por Analoga

Requiere que al menos se tenga informacin de un proyecto anterior similar, se usan los datos
de las anteriores estimaciones y sus resultados para lograr una estimacin ms precisa.

- Juicio Experto
Se requiere consultar a uno o ms expertos en la estimacin del tamao de software, donde cada
uno realiza una estimacin diferente y luego se llega a un consenso sobre sta. Los pasos que
contiene este mtodo son:
a. Se presenta a cada estimador, se realiza la estimacin en la base de los compaeros.
b. Cada experto llena una forma con los resultados obtenidos.
c. El Coordinador prepara un resumen sobre cada una de as estimaciones.
d. Se Repiten los 2 ltimos aspectos, hace lograr consenso entre los expertos.

- Parkinson
Se estima sobre el volumen de la produccin del cliente, la cual se produce con los recursos que
ste puede generar, se ajusta la propuesta para cumplir el presupuesto del cliente. Se obtiene una
estimacin global a partir de las caractersticas de todo el sistema, para luego realizar basado en
esto, la estimacin de cada parte del sistema.

- Precio a Ganar
Se fija el valor del proyecto para que sea el mejor de todos, sin tener en cuenta el tamao, toma
en cuenta el presupuesto del cliente.

- Bottom UP
Se estima cada uno de los componentes del sistema por separado, y luego se realiza una
estimacin total que comprende la sumatoria de cada una de las estimaciones pequeas.

- Top down
Este mtodo es opuesto al anterior, para este mtodo se realiza la estimacin del total del costo
para el proyecto, y desde este total se deriva el costo de cada uno de los componentes del
software a estimar, este mtodo es adecuado para fases iniciales del proyecto.

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

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

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

- Modelos basados en funciones de potencia.

Relaciona el tamao del software con otros factores de costo que influyen en el costo total del
desarrollo del proyecto.

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

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

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

- SLIM
Se basa en la distribucin de poder hombre y en la experiencia y resultados obtenidos en
proyectos anteriores. Este mtodo utiliza una ecuacin en donde se relaciona el tiempo de
entrega y factores ambientales, en los cuales se refleja la capacidad de desarrollo de la
compaa.

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

1.2.2 Estimacin del presupuesto del proyecto

El presupuesto es el plan de gastos para un proyecto. En dicho presupuesto se le asignan

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

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

1.2.2.1 Consideraciones al realizar un presupuesto

Ahora se presentarn algunos aspectos tiles al momento de construir el presupuesto de un

proyecto [Baker, 2003].
- El Costo del Proyecto est atado a las metas del mismo.

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

1.2.2.2 Mtodos para la estimacin del presupuesto.

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

Top Down
Para este mtodo, los gerentes de mayor rango realizan estimaciones de todo el proyecto; luego
de realizar estas estimaciones, se asignan los presupuestos a los gerentes de menor rango para
que lleven a cabo las estimaciones sobre tareas ms pequeas, pero siempre basndose en la
estimacin de nivel superior.

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

1.2.3 Control del presupuesto del proyecto

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

1.2.3.1 Mtodos para el control del presupuesto

En cuanto a los mtodos para el control del presupuesto es posible afirmar que la mayora se
basan en la comparacin de lo que se ha gastado hasta el momento con respecto a lo que se
encontraba planeado gastar. Estos son los mtodos encontrados para el control de presupuesto:

Seguimiento del plan de gastos

Este es un mtodo sencillo en el cual se realizan reportes peridicos de los gastos del proyecto,
stos son comparados con el presupuesto del proyecto, y lo que debera haberse gastado hasta
ese momento. Este mtodo puede ser complementado con la realizacin de grficas del
desempeo del proyecto frente a los costos a travs del tiempo; stas grficas pueden mostrar de
manera mucho ms clara en qu proporcin los gastos del proyecto son mayores o menores
frente al costo estimado en el presupuesto.

Anlisis del Valor Ganado

Este es un mtodo para estimar el alcance en el tiempo y el desempeo del proyecto, esto
mediante una serie de mtricas con las que es posible estimar muchos aspectos tiles del
desempeo del proyecto [Mulcahy2002]. En esencia, el anlisis usa tres aspectos desde los
cuales se estiman los dems aspectos con los que se mide el proyecto en cuanto a costos. Estos
aspectos son:
- Cunto trabajo est planeado para desarrollarse en el momento de la aplicacin del mtodo.
- Cunto se ha gastado al momento de la aplicacin del mtodo.
- El trabajo que se ha realizado hasta el momento.
Conociendo estos tres aspectos se procede a estimar las siguientes mtricas mostradas en la
tabla 1:

26
 ACRNIMO TERMINO INTERPRETACIN

PV Valor Planeado Cul es el valor estimado del trabajo planeado a realizar hecho.
EV Valor Ganado Cul es el valor estimado del trabajo, actualmente completado
AC Costo Actual Cunto se ha gastado en el momento actual
BAC Presupuesto Completado Cunto es el presupuesto para todo el trabajo.
Cul es la estimacin del costo del proyecto en el momento
EAC Presupuesto a Terminacin
actual.
Sobre el punto actual del proyecto, cunto ms se espera que se
ETC Estimacin a la Terminacin
gaste en el proyecto.
Cunto por encima o por debajo del presupuesto se espera que
VAC Variacin a la Terminacin
termine el proyecto.
Tabla 1. Trminos del anlisis del valor ganado

Ahora que se conocen los significados de los aspectos a evaluar, es necesario conocer las
diferentes ecuaciones que involucran los trmicos anteriores (ver Tabla 1) para obtener una
estimacin del estado actual de desempeo del proyecto.

NOMBRE FORMULA INTERPRETACIN

Variacin del Costo (CV)
Variacin del Calendario (SV)
ndice de desempeo del Costo
(CPI)
ndice de desarrollo del Calendario
(SPI)
Estimado a la Terminacin.
(EAC)
Nota: Existen diversas formas para
calcular EAC
NEGATIVO si el costo est por encima del
EV-AC presupuesto - POSITIVO si el costo est por debajo
del presupuesto.
NEGATIVO si est atrasado segn el calendario-
EV-PV
POSITIVO si est adelantado segn el calendario
Obtencin de una parte de una unidad de dinero
EV/AC
gastada.
Avance porcentual en el proyecto de la tasa de
EV/PV
avance originalmente planeada.
BAC/CPI
1. Cunto se espera que cueste el proyecto en total.
2. Usado si no han ocurrido variaciones en BAC
AC + ETC
o si se continuar con la misma tasa de gastos.
Usado cuando la estimacin original fue errnea
3. Dato actual del presupuesto remanente, usado
cuando existen varianzas debido a un fututo atpico.
AC+BAC-EV
4. Dato actual ms el remanente del presupuesto
modificado por el desempeo.
AC+(BAC-EV)/CPI

Estimacin a la Terminacin (ETC) EAC-AC Cunto ms el proyecto costar.

Cunto por encima del presupuesto se tendr a la

Variacin a la Terminacin (VAC) BAC-EAC
terminacin del proyecto.
Tabla 2. Formulas del mtodo de valor ganado

1.3 GESTIN DEL RIESGO

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

27
La gestin del riesgo se encuentra evocada a un logro en especfico: identificar y manejar
aspectos de un proyecto en especfico que afecten la entrega oportuna, bajo el presupuesto
destinado, de un producto de software que satisfaga los requerimientos acordados [Thayer, 2003].

1.3.1 Modelos existentes

La siguiente tabla muestra la descripcin de los diversos procesos construidos para gestionar los
riesgos de un proyecto de software (el proceso puede involucrar diversas metodologas, mtodos
y herramientas dentro de sus pasos de gestin de riesgos):

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

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

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

28
1.3.2 Elementos de la gestin del riesgo

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

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

1.3.2.1 Identificacin del riesgo

[Thayer, 2003] la define como una aproximacin cuidadosa y organizada de la bsqueda de

los riesgos reales asociados a un sistema. La identificacin de riesgos comprende tambin el
descubrimiento, definicin, descripcin y comunicacin de los riesgos antes de que stos se
conviertan en un problema que afecte el proyecto [Hulett, 2004].

Tcnicas de identificacin de riesgos

Existen diversos mtodos y herramientas enfocados a la captura de riesgos. La informacin
obtenida acerca de las tcnicas para la identificacin de riesgos de este trabajo, fue extrada de
[Maniasi, 2005]. Para efectos del presente trabajo se har slo una mencin especial a la tcnica de
identificacin basada en taxonoma y cuyo concepto general se explica a continuacin:
- Identificacin en base a taxonomas
Una taxonoma es una forma de clasificar y organizar la informacin acerca de por qu
ocurren eventos relevantes. Generalmente las taxonomas surgen de la experiencia obtenida al
analizar eventos relevantes y de aprender cmo los factores humanos, materiales,
circunstanciales y de entorno contribuyen a su ocurrencia.

La identificacin consiste, entonces, en utilizar una estructura agrupadora de los riesgos de

acuerdo a sus diferentes clases como una lista de consulta durante la fase de identificacin de
riesgos. Esta lista tiene su fuente originaria [Marvin J. Carr et al.,1993] quien en 1993 desarroll
la identificacin de riesgos basado en taxonoma para el SEI 1. Estas son algunas generalidades
de esta tcnica:
a. Son listados de riesgos que se han encontrado en proyectos similares a los que se intenta
analizar.

1
SEI: Software Egieneering Institute, 1991.

29
b. Se debe validar la aplicabilidad y validez de la informacin presentada en esta tcnica. Es
decir, la consideracin de los riesgos planteados en esta tcnica es general y comn a los
proyectos de desarrollo de software pero puede que la aplicabilidad vare de acuerdo con el tipo
de proyecto.

1.3.2.2 Anlisis de riesgo

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

- Niveles de probabilidad
a. Remoto: >10%
b. Improbable: (11 30) %
c. Probabilidad media: (31 50)%
d. Posible: (51 - 70) %
e. Muy probable: (>71%).
- Niveles de impacto: los niveles de impacto considerados para efectos de este trabajo son:
Mnimo: 1, Bajo: 2, Medio: 3, Severo: 4, Crtico: 5

Un riesgo con alta probabilidad de ocurrencia y generacin de alto impacto es un riesgo que
contiene un alto nivel de amenaza para el proyecto y por tanto debe tener una prioridad alta.

La informacin del riesgo, ahora complementada con el nivel de amenaza y prioridad, se

representa en una tabla de perfil del riesgo (ver tabla 4).
Riesgo Probabilidad Impacto Prioridad

R1 Posible Bajo Bajo

R2 Posible Crtico Alto

R3 Remota Severo Bajo

R4 Probable Severo Alto

30
 R5 Posible Crtico Alto

Tabla 4. Perfil de riesgos [Armstrong, 2004]

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

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

Anlisis cualitativo

El anlisis cualitativo del riesgo es utilizado para evaluar un nmero amplio de riesgos que
son identificados en el proyecto. Est diseado para medir, segn una escala de calificacin,
los riesgos del proyecto por parte de miembros pertenecientes a l. Generalmente los rangos
de calificacin estn compuestos por los niveles de probabilidad e impacto de cada riesgo.

Anlisis cuantitativo

El anlisis cuantitativo utiliza las distribuciones de probabilidad para representar la

incertidumbre sobre algunos tems del proyecto como lo son: las duraciones de las
actividades del calendario [Hulett, 2004] y el costo en la estructura del trabajo del proyecto
(Work Break Down Structure).

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

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

En general el anlisis cuantitativo de riesgos requiere modelaje, recoleccin de datos y

simulacin. Estas son las herramientas utilizadas en cada aspecto:

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

El camino ms largo a travs de la red es denominado Camino Crtico y cualquier retraso

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

b.Tcnica de recoleccin de datos

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

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

- Proceso para la estimacin de riesgos en calendario

a. Determinacin del calendario CPM o Lnea Base de la red de actividades del proyecto.

32
Consiste en determinar las actividades o tareas necesarias para satisfacer los requerimientos
del proyecto fijando un tiempo de duracin, as como las fechas de inicio y de finalizacin
para cada una.
Suponiendo un proyecto simple de 8 actividades y una fecha de entrega (Figura 3). Teniendo
en cuenta las duraciones (slo das laborales) para cada actividad, si este proyecto est
planeado para iniciarse el 7 de enero el CPM muestra que el proyecto tomar 24.5 das y ser
completado el da 14 de febrero.
Las fechas mostradas en el diagrama son estimadas por el gerente del proyecto.

Figura 3. Red de actividades de un proyecto

b. Rangos de duracin de las actividades

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

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

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

33
 MS
ACTIVIDADES BAJO PROBABLE ALTO
Anlisis 1 2 5

Diseo 1 4,5 10

Desarrollo 7 16 30

Documentacin 1 2 5

TOTAL 10 24,5 40
Tabla 5. Estimacin de tres puntos del calendario

c. Simulacin del Calendario del Proyecto

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

- Proceso para la estimacin de riesgos en costos

a. Los Datos del Riesgo:

Lo primero a tener en cuenta en el anlisis de riesgos en costos es la descomposicin de la

estructura del trabajo. Es a partir de sta que se comienzan a recolectar los datos de los
costos extremos (optimista y pesimista) de cada uno de los elementos ms riesgosos. La
recoleccin se realiza a travs de la evaluacin de los lderes de equipo quienes evalan los
riesgos adyacentes y propios de sus reas. De manera similar a la estimacin de riesgos en
calendario, se debe obtener para cada elemento del WBS el valor mnimo y mximo de los
costes que conlleva llevarlos a cabo. La figura 4 muestra los datos de un anlisis para la
estimacin de riesgos en costos:

ELEMENTO DEL WBS VALOR PARA EAC

BAJO MS ALTO
PROBABLE

Figura 4. Datos para la estimacin de riesgos en costos

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

34
 b. Simulacin de tres puntos

La figura 5 es un ejemplo de la estimacin de tres puntos a partir de cada uno de los

elementos del WBS del proyecto: (ejemplo extrado de la fuente [Hulett, 2003-3]):

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

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

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

c. Resultados de la simulacin

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

dlares.

35
1.3.2.3 Planificacin del riesgo

Comprende el desarrollo y documentacin de estrategias que caracterizarn la Gestin del

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

- Formulacin de un plan de contingencia para mitigar el impacto del riesgo en caso de que
ste llegase a ocurrir.
- Evasin del riesgo mediante la reduccin de su probabilidad y/o las consecuencias de su
ocurrencia. Se pueden asumir cambios en el proceso de desarrollo o diseo del producto de
software con el fin de evitar eventos indeseados.
- Aceptacin del riesgo, es decir, prescindir de cualquier tipo de accin para mitigarlo y de esta
manera se asumen las consecuencias en caso de que ste ocurra.
- Transferencia: trasladar el riesgo a otra rea de responsabilidad.
- Adquisicin de conocimiento: Consiste en recolectar nueva informacin que permita a los
gerentes de proyecto analizar el riesgo con mayor profundidad y desarrollar planes nuevos de
contingencia.

Elementos de un plan de riesgo

La fuente [Wiegers, 1998] plantea los siguientes elementos para un plan de riesgos:
- Identificador del riesgo
- Clasificacin del riesgo
- Da de reporte
- Descripcin del riesgo
- Probabilidad
- Impacto
- Nivel de riesgo
- Primer disparador del riesgo.
- Respuesta al riesgo <controlar, evitar, minimizar, mitigar el riesgo>
- Fecha de inicio de la respuesta al riesgo
- Fecha de finalizacin de la respuesta al riesgo.
- Estado actual del plan
- Plan de contingencia
- Disparador del plan de contingencia.

Posibles estados de un plan de riesgo

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 aprobacin.
- Plan Aprobado: El plan para el riesgo ha sido aprobado y se encuentra en condiciones de ser
ejecutado.
- Plan Verde: El plan se est ejecutando segn lo planificado.
- Plan Amarrillo: El plan se est ejecutando con leves diferencias respecto a lo planificado.
- Plan Rojo: El plan se est ejecutando con severas diferencias respecto a lo planificado,
seleccionado o definido.
- Plan completo: El plan se ha ejecutado por completo y se encuentra pendiente la verificacin
de sus resultados.
- Completado: El plan ejecutado ha sido verificado y sus resultados se consideran apropiados.
- Re-Abierto: El plan ejecutado ha sido verificado y sus resultados no se consideran apropiados
por lo cual se solicita una nueva ejecucin del ciclo de vida o proceso del riesgo.
- Completo: luego de Re-Abierto el plan se ha ejecutado, ha sido verificado y sus resultados se
consideran apropiados.

1.3.2.4 Seguimiento del riesgo

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

1.3.2.5 Control del riesgo

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

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

Documentacin

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

1.4 RESULTADOS DEL CAPTULO

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

38
 2. PROPUESTA CONCEPTUAL DEL MODELO

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

Los primeros numerales de esta propuesta conceptual se concentran en la caracterizacin del

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

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

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

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

2.1 CARACTERIZACIN DE PROYECTOS DE TECNOLOGA DE LA INFORMACIN

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

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

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

2.1.1 Caracterizacin de proyectos de TI en Colombia

La V Encuesta Nacional de Gerencia de Proyectos de Tecnologa de la Informacin

publicada por [ACIS, 2007] expone las siguientes estadsticas que enmarcan el estado de los
proyectos de tecnologa informtica en Colombia:

Actividades de un proyecto de TI
Las dos principales actividades en las cuales se enfoca los proyectos de TI en Colombia son:
- Especificacin de requerimientos (73%)
- Integracin de sistemas (53%).

Factores de fracaso en proyectos de TI

- Mala Planeacin: Como es indicado en [Salinas, 2007] el alto porcentaje de fracaso financiero
en proyectos de tecnologa informtica se debe al mal direccionamiento y enfoque de los planes
de accin por parte de los involucrados en los proyectos. Por su parte ACIS expone como factor
principal para el fracaso en proyectos de TI a la mala planeacin.

- Poca y/o mala comunicacin

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

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

40
 Desempeo en el cronograma de
proyectos de TI

Proyectos completados
ajustndose
al cronograma 27, 27%
Proyectos cancelados o
abandonados 3, 3%
Proyectos completados 3, 3%
adelantndose
al cronograma 67, 67%
Proyectos completados
por encima del cronograma

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

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

- Desempeo en el presupuesto

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

Desempeo en el presupuesto de
proyectos de TI
Proyectos abandonados

Proyectos completados 40, 40%

ajustndose al presupuesto 12, 12%
Proyectos completados
sin exceder presupuesto

Proyectos completados con

xito por encima del
presupuesto 6, 6% 42, 42%

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

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

41
evidencia la necesidad de llevar a cabo una estimacin de costos realista adems de tener en
cuenta los riesgos asociados con el costo de un proyecto de TI.

Recomendaciones
ACIS basado en la experiencia obtenida durante la fase de investigacin de estas estadsticas,
suministra las siguientes recomendaciones dirigidas a los gestores de proyectos de TI en
Colombia:

- Valorar la experiencia obtenida durante el proyecto.

- Control del cronograma y el presupuesto

2.1.2 Aproximacin a la actualidad de las empresas y reas de tecnologa colombianas

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

2.1.2.1 Qu se est usando en la actualidad para estimacin del esfuerzo y tamao del
software?

Las empresas o reas de tecnologa comnmente utilizan el proceso representado en la figura 9

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

42
 - Producto
- Proyecto
- Tipo de
desarrollo

Modulo de
Modulo de
Administracin Clculo de los GUA DE
Administracin Clculo de los GUA DE
LA
de promedios
de promedios LA
ESTIMACIN
requerimientos Criterios totales
requerimientos totales ESTIMACIN

Discusin de Clculo del Estimacin

Discusin
resultadosdey Clculo dely tamao
esfuerzo Estimacin
individual:
resultados
acuerdo. y esfuerzo
segn ely participante
tamao individual:
EXPERIENCIA
acuerdo. segn el participante EXPERIENCIA

Valor del esfuerzo - Gerente

Valor
totaldel esfuerzo
estimado - Ingeniero
total estimado - Usuario

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

2.1.2.2 Qu se est usando en la actualidad para la estimacin de costos?

De acuerdo con el valor del esfuerzo estimado el costo se calcula as: Esfuerzo total * valor hora
promedio de cualquiera de los recursos listados en la figura 10.

Valor del esfuerzo Valor HORA - Hardware

Valor
totaldel esfuerzo Valor HORA
X
estimado PROMEDIO - Software
total estimado PROMEDIO - Comunicaciones
- Entrenamiento
- Logstica

Figura 10. Actualidad de la estimacin de costos

2.1.2.3 Qu se est usando en la actualidad para la gestin de riesgos?

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

43
2.1.2.4 Qu se puede concluir acerca de esta aproximacin?

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

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

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

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

2.1.3 Generalidades de las empresas de desarrollo en el Reino Unido

Los datos relacionados en esta seccin proyectan el estado de las empresas desarrolladoras de
software en el Reino Unido. La razn por la cual son citados en este trabajo tiene que ver con el
hecho de contar con otros contextos que permitan encontrar similitudes y nuevos aspectos que
complementen la caracterizacin de gestin de proyectos nacional.

Las siguientes estadsticas fueron recolectadas de reportes generados por Standish Group
compaa que public los resultados acerca de un estudio desarrollado sobre diferentes
empresas desarrolladoras de software en el Reino Unido.

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

Como fue mencionado en la parte introductoria del captulo, es importante resaltar este estudio
debido a que puede llegar a reflejar similitudes, en algunos aspectos, con el contexto de los
proyectos de software en Colombia permitiendo evidenciar otros no contemplados en los
estudios y estadsticas nacionales. En este caso, problemas como el sobrecosto y el atraso en el
cronograma son comunes a ambos contextos, lo cual sugiere la necesidad inmediata de una fase
de planeacin adecuada que soporte la mayora de los proyectos de software que son
emprendidos en Colombia y en otros pases.

2.2 PLANTEAMIENTO DEL MODELO PARA LA ESTIMACIN DEL TAMAO

Esta seccin contiene un anlisis comparativo sobre las diversas metodologas para la
estimacin del tamao del software con el fin de proponer las bases del modelo a desarrollar en
el captulo siguiente.

45
2.2.1 Evaluacin de mtodos para la estimacin del tamao del software

Con el fin de proponer un modelo para la estimacin del tamao basado en las metodologas ya
expuestas para ello, se presenta la siguiente tabla en donde se evalan las virtudes y defectos de
cada una permitiendo la escogencia adecuada del mtodo que ser utilizado en el modelo
propuesto:

METODO DESCRIPCIN VENTAJA DESVENTAJA

-Dependiente del lenguaje de

Este mtodo toma las lneas de -Se basa en el producto del programacin.
cdigo necesarias para la desarrollo de software.
Conteo de Lneas de construccin de un sistema como - Dependiente de los
Cdigo medida de su tamao. -Fcil Conteo programadores.

- Estimacin difcil en etapas

Este mtodo divide, el sistema en
componentes, para as realizar
estimaciones sobre cada
componente por analoga con
Estimacin basada en la otros componentes ya realizados,
estadstica luego obtienen una estimacin
pesimista, media y optimista.
Este mtodo se basa en
estimacin por analoga, ya que
se toma informacin histrica del
tamao de diferentes proyectos, y
se realizan categoras de tamao
Estimacin Por Lgica en las que se encasillan los
Difusa proyectos, luego el nuevo
proyecto se encasilla en una de
estas categoras, lo cual da un
aproximado del tamao del
proyecto.
Estimacin Por Puntos de Se basa en la funcionalidad del
Funcin sistema. Para realizar su
estimacin se deben determinar
los componentes de puntos de
funcin para el sistema y
clasificarlos segn su dificultad.
Tabla 6. Evaluacin de los mtodos para estimacin del tamao del software
-Disminuye la incertidumbre,
dividiendo el sistema en
componentes.
-Se basa en un proceso
estadstico, que ofrece un
grado de seguridad.
-El grado de confiabilidad de
las estimaciones se hace
mejor a medida que se
realicen ms estimaciones.
-Es un mtodo sencillo de
aplicar.
-Da un rango del tamao del rango especificado, lo que
software, lo que no se
compromete del todo con un
tamao exacto
-Al depender de la
funcionalidad del sistema, su
aplicacin se puede realizar
desde la definicin de los
requerimientos del sistema.
-Es Independiente del
Lenguaje.
-Fcil Utilizacin.
tempranas del desarrollo.
-Si no se cuenta con datos
histricos, las estimaciones
sern poco confiables.
-El mtodo requiere un
tiempo para converger en
buenas estimaciones.
-Depende de la informacin
histrica, de otros proyectos.
- El proyecto estimado
posiblemente no est en el
podra resultar en una
estimacin muy alejada de la
realidad.
Requiere un tiempo de
convergencia.
Es posible que no se
encuentren todos los
componentes necesarios, lo
que dara una estimacin
equivocada.
No es muy adecuado para
cuando el software se
encuentra construido.

2.2.2 Mtodo escogido para la estimacin del tamao del software

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

46
De igual manera se aprecia que las tcnicas suelen ser muy sencillas, debido a que solo
requieren de una persona para obtener la informacin del tamao.
Sin embargo, se dejan de lado muchos aspectos importantes que deben ser considerados en la
estimacin, otros mtodos utilizan la funcionalidad del software, por ejemplo, para implantar
una debida estimacin.
Pensando en la funcionalidad del software y en la facilidad que los puntos de funcin pueden
aportar a las actividades de estimacin del tamao, este ltimo aspecto tambin importante
porque atribuye la sencillez o simplicidad que una pequea empresa de desarrollo necesita de
este tipo de procesos, los puntos de funcin constituyen el mtodo seleccionado para llevar a
cabo la fase de estimacin del modelo a proponer.

2.2.3 Por qu se escogi este mtodo?

La caracterstica principal por la que se escogi este mtodo fue la flexibilidad que presenta
para ser utilizado en etapas tempranas del desarrollo del software, en donde no es mucho lo que
se sabe con respecto a las caractersticas del proyecto: esta metodologa se basa en la
funcionalidad del sistema a implementar y no en el producto a crear.

El mtodo puede ser utilizado en diversas etapas del proyecto, a medida que aumente el
conocimiento acerca del proyecto tambin aumentar la calidad de las estimaciones,
hacindolas cada vez ms acercadas a la realidad. Otra caracterstica destacable del anlisis de
puntos de funcin, es su dependencia del lenguaje, esto debido a que se basa en la
funcionalidad, lo que hace que esta metodologa sea ideal para cualquier tipo de sistema.

2.2.4 Esquema del mtodo de Puntos de funcin

Para estimar el tamao de software por puntos de funcin, se deben encontrar algunos
elementos como las salidas y entradas del sistema y bases de datos/archivos en donde se guarda
la informacin. Posteriormente se debe encontrar la dificultad de cada componente. Finalmente
mediante la aplicacin de una serie de formulas sencillas se obtiene el nmero total de puntos de
funcin que componen el software.

2.3 PLANTEAMIENTO DEL MODELO PARA LA ESTIMACIN DE COSTOS DEL

PROYECTO

Esta seccin contiene un anlisis comparativo sobre las diversas metodologas para la
estimacin del costo del proyecto con el fin de proponer las bases del modelo a desarrollar en el
prximo captulo. Cabe resaltar en este punto los pasos considerados para realizar una buena
estimacin de costos:

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

Tambin sera conveniente recordar que para estimar el costo de un proyecto se debe conocer el
tamao del mismo, por lo cual primero se debe estimar el tamao del proyecto.

2.3.1 Evaluacin de mtodos y modelos para la estimacin de costos

En este campo se encontraron diversas metodologas para la estimacin de costos del software a
construir. A continuacin se muestra una tabla mostrando las fortalezas y debilidades de cada
una las metodologas que descritas en el captulo del estado del arte:

METODOLOGA DESCRIPCIN VENTAJAS DESVENTAJAS

NO ALGORTMICOS
Se requiere informacin
Si se cuenta con buena histrica de proyectos para
informacin histrica de realizar la estimacin.
proyectos pasados, se
El costo del proyecto se
pueden obtener Para que el mtodo sea
estima en base al costo de
Costos por Analoga estimaciones bastante efectivo se requiere ajustar
proyectos similares ya
acertadas. el mtodo con informacin
realizados.
de la organizacin que
Las estimaciones son realiza el proyecto.
sencillas de realizar

Se ajusta el precio del
proyecto, para mejorar la
Precio a Ganar
propuesta ms econmica
realizada, con el fin de
ganar el proyecto.
MTODOS ALGORTMICOS
Modelo emprico para la que inciden en el costo
estimacin del esfuerzo y del proyecto.
costo del desarrollo de un
sistema de software, se
COCOMO basa en el uso de
multiplicadores de
esfuerzo, para realizar una
estimacin del esfuerzo y Permite su utilizacin a
costo
Se basa en la distribucin
de poder hombre, se usa la
ecuacin de software, en
donde se relaciona, el
SLIM
tiempo de entrega, factores
ambientales, en los cuales
se refleja la capacidad de
desarrollo de la compaa
La estimacin muy
La estimacin se realiza
seguramente est mal, y el
de una manera muy
costo real estar muy
sencilla.
alejado de la realidad.
Es muy probable que se
Puede ocasionar que el
gane el proyecto.
proyecto lleve a perdidas.
Predisposicin por parte
Involucra varios factores
del equipo de gestin ante
la utilizacin de frmulas
matemticas.
No requiere en principio
Es un proceso extenso para
el uso de datos de
completar la estimacin
proyectos anteriores.
Algunos factores son algo
complicados de
lo largo de todo el
determinar.
proyecto.
Predisposicin por parte
del equipo de gestin ante
Usa factores del proyecto la utilizacin de frmulas
y producto, para realizar matemticas.
la estimacin, estos
factores inciden en el Es un proceso algo largo,
costo del proyecto. para completar la
estimacin

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

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

48
Existen metodologas basadas en la experiencia de los gerentes de proyectos, algunas un poco
menos elaboradas, lo que intentan es ganar un contrato en cambio de realizar una estimacin
seria.
De igual manera existen metodologas ms complicadas que utilizan modelos empricos y
matemticos para estimar el costo de un software, evaluando a su vez, una serie de factores
concernientes al tamao del software, a la organizacin, experiencia en esta clase de proyectos,
etc.

2.3.2 Modelo escogido para la estimacin de costos

En el caso de la estimacin de costos se escogi como metodologa COCOMO II, aunque esta
es un tanto complicada, debido a la utilizacin de varias formulas que estiman el costo de un
proyecto, cuenta con la ventaja de usar para su estimacin un amplio dominio de factores que
inciden sobre el costo del proyecto, tales como: retrasos en el cronograma, prdida de personal,
etc.

2.3.3 Esquema del modelo COCOMO II

El modelo se divide en 3 submodelos dependiendo del conocimiento del proyecto, es decir si no

se conoce mucho acerca del proyecto, para una estimacin inicial se usara el modelo de
composicin de aplicaciones , en una etapa ms avanzada del proyecto, se podra utilizar el
modelo de diseo anticipado, y en el momento que se encuentren diseada la arquitectura del
proyecto, se podra utilizar el modelo de postarquitectura, estos modelos aumentan en
complejidad a medida que se avanza las diferentes fases del proyecto, es decir el modelo de
composicin de aplicaciones es mucho ms sencillo que el de diseo anticipado y
postarquitectura, de igual manera las calidad de las estimaciones aumenta cuando se usan
mtodos mas complicados.
Para este modelo se usar el modelo de diseo anticipado, ya que es un modelo adecuado para
realizar estimaciones en las que se tienen en cuenta varios parmetros que inciden en gran parte
en el costo de un proyecto, y a su vez disminuye la dificultad para realizar estas estimaciones,
adicionalmente se desarrollarn plantillas para la realizacin estas estimaciones, con lo que se
disminuir en gran medida la dificultad en la aplicacin del mtodo.

2.4 PLANTEAMIENTO DEL MODELO PARA LA ESTIMACIN DEL PRESUPUESTO

Esta seccin contiene un anlisis comparativo sobre las diversas metodologas para la
estimacin del presupuesto del proyecto con el fin de proponer las bases del modelo a
desarrollar en el captulo 3.

49
2.4.1 Evaluacin de mtodos para la estimacin del presupuesto

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

Para efectos de este trabajo no se usar ninguna tcnica para estimar el presupuesto del
proyecto, ya que la estimacin del costo del proyecto, se hace en base a la divisin del trabajo
propuesta en la fase de requerimientos, es decir la estimacin del costo del proyecto, se realiza
para cada uno de los requerimientos definidos, lo cual se toma como el presupuesto para el
proyecto lo cual facilita el uso del modelo para los usuarios del mismo. A continuacin se
presentar una evaluacin de estas formas en las que se realiza la estimacin del presupuesto.

METODOLOGA DESCRIPCIN VENTAJAS DESVENTAJAS

Bottom Up En este mtodo, las Al ser estimaciones al Requiere de un mayor
estimaciones se realizan nivel de tarea, se tiene tiempo de estimacin, ya
al nivel de tareas, cada menor riesgo en estimar que para cada tarea se
tarea se estiman los el presupuesto de todo el debe realizan un
aspectos del presupuesto proyecto de manera estimacin de presupuesto
necesarios errnea.
Top Down En este mtodo una Las estimaciones pueden Al depender la estimacin
persona encargada de las ser realizadas por varias de todo el presupuesto de
estimaciones, realiza la personas una estimacin global, es
estimacin para todo el simultneamente, mucho ms factible que la
proyecto, y basndose en dependiendo de la estimacin de todas las
esta estimacin se divisin del trabajo tareas en conjunto sea
realizan las estimaciones propuesta. errnea.
para las diferentes tareas.
Estimacin por Fases En este mtodo las Como ventaja este Como desventaja se tiene
estimaciones se hacen mtodo provee, que las que al no realizar un
segn la fase del proyecto estimaciones se realizan estimacin clara del total
en que se encuentre, y a en un momento en el que del proyecto, nunca se
medida que el proyecto se sabe que se va estimar, conoce en realidad cuanto
avanza se realizan las y se tienen informacin es el costo del proyecto,
estimaciones de las otras de las fases anteriores lo que no es muy
fases, se puede utilizar para mejorar la conveniente al realizar un
una combinacin de los estimacin. contrato.
mtodos anteriores para
realizar estas Las estimaciones no son
estimaciones. tan grandes, por lo que
solo se estima una fase
del proyecto a la vez.
Tabla 8. Evaluacin de mtodos para la estimacin del presupuesto de un proyecto

50
2.4.2 Mtodo escogido para la estimacin del presupuesto

El mtodo seleccionado es Bottom Up ya que se estima el costo de implementar cada

requerimiento, antes de obtener un estimativo para el proyecto completo. Lo cual es pertinente
para el modelo propuesto teniendo en cuenta que una de las bases las que parte es asumiendo
una especificacin de requerimientos establecida.
De igual manera, suministra un apoyo importante para las pequeas empresas de software
teniendo en cuenta que una de sus principales actividades (ver seccin 2.1) consiste en la
especificacin de requerimientos y de esta manera se podra garantizar aun ms su
cumplimiento dentro de su presupuesto estipulado.

2.5 PLANTEAMIENTO DE UNA METODOLOGA PARA EL CONTROL DEL

PRESUPUESTO

Esta seccin contiene un anlisis comparativo sobre las diversas metodologas para la
estimacin del presupuesto del proyecto con el fin de proponer las bases del modelo a
desarrollar en el captulo siguiente.
En cuanto a las metodologas para el control del presupuesto stas tienen como base la
comparacin de lo transcurrido con lo planeado. Al usar estas comparaciones se puede
determinar el progreso de un proyecto, y qu tan bien se ha desempeado el desarrollo del
mismo.
Las diferencias entre los mtodos estudiados para el control del presupuesto residen en el nivel
de detalle con el que realizan las comparaciones, en el caso del primer mtodo se compara el
presupuesto total del proyecto con lo gastado a la fecha del proyecto y para el segundo mtodo,
se realiza por actividad propuesta del proyecto una comparacin que incluye adems de lo
gastado una serie de aspectos adicionales acerca del desempeo que ayuda a los gerentes a tener
un mayor control del desempeo del proyecto.

2.5.1 Evaluacin de mtodos para el control del presupuesto

Ahora se proceder a realizar la evaluacin de los mtodos ms importantes para el control del
presupuesto, y se expondrn las ventajas y desventajas de cada mtodo.

51
 METODOLOGA DESCRIPCIN VENTAJAS DESVENTAJAS
Seguimiento del Plan de En este mtodo se deben Es un mtodo fcil de Al solo proveer una
gastos tener claro lo que se ha usar, ya que slo mtrica acerca del
gastado en el desarrollo requiere el desempeo en cuanto
del proyecto, ya que esto conocimiento de dos costos del proyecto, hay
se compara con lo que valores. Adicionalmente mucha ms informacin
deba haber gastado, en es fcil de entender ya relevante que no es
el momento de realizar que la informacin que analizada.
la comparacin, con provee es clara, y puede
estos dos valores se incluir la funcionalidad La grfica de este
obtiene una medida que de agregar una grfica mtodo no es muy
indica si se est con el desempeo del adecuada para proyectos
desfasado en costos, o si proyecto en costos. grandes, ya que no
est acorde con el muestra toda la
proyecto, o si por el informacin requerida.
contrario se ha gastado
ms de lo planeado.
Anlisis del Valor Este mtodo intenta Ofrece diversas mtricas Predisposicin por parte
Ganado evaluar varios factores para la evaluacin del del equipo de gestin
de desempeo en cuento desempeo en cuanto a ante la utilizacin de
al costo del proyecto, los costos del proyecto. frmulas matemticas.
esto lo hace mediante Estas mtricas evalan
diversas mtricas que mltiples aspectos del
bsicamente compararn proyecto, que dan un
lo invertido en el mayor control sobre el
proyecto con lo gastado proyecto
en el mismo.
Tabla 9. Evaluacin de las metodologas para el control del presupuesto

De acuerdo con la tabla 9 la diferencia entre los mtodos anteriores se encuentra en el nivel de
detalle de stos, y la decisin de escoger uno u otro para un proyecto depende del tamao del
mismo, ya que para un proyecto pequeo el primer mtodo es ideal, al no ser complicado y
podra dar una buena visin del desempeo del mismo, en cuanto al segundo mtodo es ideal
para proyectos ms grandes, en donde se requiere un mayor control del desempeo del
proyecto.

2.5.2 Mtodo escogido para el control del Presupuesto

Para el caso del control del presupuesto fue seleccionado el mtodo de anlisis del valor ganado,
ya que incluye una evaluacin mucho ms profunda acerca del desempeo de un proyecto, y
aunque no es la metodologa para el control de costos ms fcil de usar, no es complicada del
todo, adems de ofrecer excelentes resultados.

Su operacin consiste en la evaluacin de una serie de mtricas a partir de lo que se ha invertido

en el proyecto y lo que se haba planeado invertir, con estos datos se puede obtener informacin

52
 muy valiosa, la cual permite a los gerentes de proyecto tener una visin clara acerca del
proyecto.

2.6 PLANTEAMIENTO DEL MODELO DE GESTIN DE RIESGOS

Con base en la literatura estudiada se plante una metodologa de gestin de riesgos (Figura 13),
enseguida se explican las razones por las cuales esta metodologa fue la planteada para la
propuesta de este modelo.

2.6.1 Principios bsicos en los cuales debera basarse una metodologa de gestin de riesgos

Un primer criterio utilizado para la seleccin de la metodologa los constituy el grupo de

principios bsicos en los cuales se debe basar la metodologa de gestin de riesgos. La figura 11
muestra algunos de los principios fundamentales sobre los cuales debera basarse un proceso de
gestin de riesgos de acuerdo con la propuesta de [Microsoft, 2002]:

Administracin de riesgos de manera proactiva a travs de

Agilidad todas la fases del proyecto, ya que los cambios efectuados en
cualquiera de ellas, implican cambios a nivel de riesgo
tambin.

El proceso de gestin de riesgos debe ser

Participacin responsabilidad de todos los miembros del equipo. De
necesaria igual manera cada uno debe asumir la responsabilidad
de las tareas especficas que le son asignadas.

PRINCIPIOS
BSICOS
DE LA Reconocimiento de Reconocer el hecho de que cualquier proyecto de
la necesidad de desarrollo de software se encuentra amenazado por
GESTIN DE
gestionar algn o varios riesgos.
RIESGOS

Generar los espacios suficientes para discutir de forma

Potenciar la abierta los riesgos y de tal manera crear la oportunidad
comunicacin para que los miembros del equipo participen en las
diferentes tareas relacionadas con los riesgos.

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

2.6.2 Requisiciones de una metodologa de gestin de riesgos

El segundo criterio determinante para la seleccin de la metodologa los constituy el grupo de

requisiciones que debe cumplir una metodologa de gestin de riesgos. Segn [Motorola LMPS,
1999] a nivel organizacional una poltica de gestin de riesgos debera considerar por lo menos
los siguientes aspectos:

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

Figura 12. Requisiciones para una metodologa de gestin de riesgos

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

Preparacin para la
Gestin

Aprendizaje

Control de repuesta Identificacin del

al riesgo riesgo

Comunicacin

Respuesta al riesgo Cuantificar y cualificar los riesgos

Figura 13. Metodologa de gestin de riesgos para el modelo

2.6.3 Por qu se escogi esta metodologa?

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

54
 De acuerdo con la caracterizacin de los proyectos de TI en Colombia realizada en este
trabajo, es clara la necesidad de mantener una comunicacin abierta entre los miembros del
equipo de proyecto. La comunicacin se debe generar tambin en esta parte de gestin de
riesgos y no slo en las fases del modelo de desarrollo establecido.

2.6.4 Fases o pasos de la metodologa

La descripcin de las fases y de las actividades que se desarrollan en la metodologa para la

gestin de riesgos seleccionada se menciona a continuacin.

2.6.4.1 Fase de Preparacin para la gestin de riesgos

La preparacin se propone una como una fase previa a la identificacin con el fin de limitar el
marco de las fuentes y categoras de los riesgos. Por tanto esta fase se concentra en el
reconocimiento de las fuentes, productoras de los posibles riesgos del proyecto, as como las
categoras a las que los riesgos, ms adelante identificados, se podran asociar.

Identificacin de Fuentes de riesgo

Las fuentes de riesgo son reas comunes donde los riesgos suelen originarse [Maniasi, 2003].
La importancia de identificar tempranamente las fuentes de riesgos radica en encontrar un
mecanismo de evaluacin, que de manera eventual, permitir observar los cambios producidos a
travs del tiempo en el entorno donde se desarrolla el proyecto. Es decir, puede que una fuente
de riesgo sea eliminada debido a cambios estructurales en la organizacin o empresa donde el
proyecto tiene lugar por tanto dicha fuente ya no ser productora de riesgos en el proyecto y de
manera recproca el riesgo podra desaparecer.
Uno de los estudios desarrollados en este trabajo encontr que las fuentes ms comunes de
riesgos en los proyectos de desarrollo de software son los mostrados en la figura 14:

Fuentes de
riesgos

Estimaciones Requerimientos Tecnologa no Capacidad incierta de Asignacin irrealista

errneas inciertos disponible proveedores de recursos

Figura 14. Fuentes de riesgos del modelo

55
 Este modelo, con el fin de definir un marco especfico de fuentes de riesgos para todos los tipos
de proyectos de software, se acoge a esta lista de fuentes de riesgos basada en la investigacin
desarrollada por [Maniasi, 2005] para su tesis de magster.

Identificacin de categoras del riesgo

Surgen con el objetivo de agrupar los riesgos que ms adelante van a ser identificados. Las
categoras del riesgo del proyecto deben ser clarificadas al inicio de la gestin con el fin de
caracterizar diferentes marcos comunes en dnde cada riesgo ser clasificado: por tal razn hace
parte de la fase de preparacin de la metodologa planteada. La categorizacin de los riesgos
permitir generar una bsqueda apropiada de aquellos que puedan tener mayores consecuencias
sobre el logro de las metas del proyecto [Maniasi, 2005].

El modelo establece tres categoras del riesgo como un mecanismo para clasificar y organizar
los riesgos pensando en la futura fase de identificacin (Figura 15)

Los problemas ms comunes [ESII, 2001] en proyectos

se dan por variaciones en:
Riesgos de
Presupuesto
proyectos
Personal
Planificacin
Recursos

Riesgos tcnicos
Riesgos de
negocio

Los problemas ms comunes en riesgos tcnicos Categoras

son [ESII, 2001]: Las clases de riesgo de negocio son [ESII,
De Diseo del riesgo 2001]:
De Implementacin De Mercado
De Interfaz Estratgico
De Verificacin y mantenimiento De Comercializacin
Clientes y requisitos. De Direccin
De presupuesto

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

A continuacin se da una breve descripcin de cada una de las categoras:

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

56
- Riesgos tcnicos: son aquellos aspectos o eventos asociados con la definicin del alcance del
proyecto que podran afectar el nivel actual de funcionalidad del sistema con respecto a la
misin requerida y el anlisis de requerimientos documentado.
- Riesgos de negocio: Riesgos que afectan la viabilidad de negocio del software desarrollado.

2.6.4.2 Fase de identificacin del riesgo

De acuerdo con [Maniasi, 2005] quizs el aspecto ms importante en la etapa de identificacin

sea el hecho de capturar tantos riesgos como sea posible; de esta manera, pensando en la
definicin de una tcnica para identificacin de riesgos conforme a este criterio, se desarroll un
breve estudio comparativo de los diversos tipos de tcnicas para la identificacin de riesgos,
expuestos en el estado del arte. La Tabla 10 enuncia las ventajas y desventajas de cada una de
las tcnicas tratadas:
TCNICA VENTAJA DESVENTAJA

- Al ser un mtodo no estructurado permite - Puede que para el momento de la

evidenciar posibles riesgos de cualquier fuente
y descripcin.
Lluvia de ideas
- El planteamiento de un suceso o hecho como
un posible riesgo puede ser discutido desde
diversos puntos de vista y experiencias
expuestas por loe miembros del equipo.
- Permite prever no slo la descripcin de
posibles riesgos sino su comportamiento a
Experiencia y conocimiento partir de la experiencia obtenida en proyectos
documentado similares lo cual puede servir como un punto
de referencia para los manejadores del riesgo o
gerentes de proyecto.
- Es posible obtener una gran variedad de
opiniones sin tener la necesidad de organizar
una reunin donde, seguramente, no todos los
Encuestas participantes convocados podrn estar
presentes.
- Permite obtener un amplio rango de riesgos
permitiendo destacar tambin aquellas reas
que requieran de mayor atencin por parte del
equipo de proyecto.
reunin no se cuente con personas
relacionadas con el tema o con posibles
expertos que posean la experiencia sobre
las implicaciones y marco del proyecto.
- No todas las organizaciones cuentan
con una documentacin especfica o
base de datos de los riesgos y su manejo
en otros proyectos similares.
- Generalmente las personas suelen tener
poco inters en contestar una encuesta lo
cual puede generar respuestas
inapropiadas.
- La evaluacin de las respuestas puede
tornarse difcil por su carcter subjetivo.
Carece de una clasificacin del dominio
de los riesgos siendo ste todava muy
extenso para tenerlos todos en cuenta en
la fase de identificacin.

- En la fase de identificacin estimula el

pensamiento sobre los inconvenientes que se
pueden producir en la diferentes reas del
Taxonomas proyecto [Microsoft, 2002].
- Permite que riesgos similares puedan
agruparse aligerando la complejidad
[Microsoft, 2002].
- Permite utilizar un terminologa unificada
que el equipo de proyecto puede utilizar para
supervisar y notificar el estado de los riesgos
[Microsoft, 2002].
Tabla 10. Comparacin de las tcnicas para la identificacin de riesgos

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

57
 Repetible y estructurado: con el fin de alcanzar
una gestin consistente del riesgo.

Asunciones bsicas de una

Cubrimiento de todas las reas clave
tcnica para la del proyecto
identificacin de riesgos

El nmero de riesgos identificados no debe ser un

factor usado para predecir el xito o fracaso del
proyecto.

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

Seleccin de la tcnica de identificacin basada en taxonomas

Tanto las asunciones bsicas con las que debe contar una tcnica de identificacin de riesgos y
el estudio comparativo mostrado en la tabla 10 constituyeron los criterios clave para seleccionar
la tcnica de identificacin basada en taxonomas como la que apoyar la fase de identificacin
de este modelo propuesto. Asimismo era evidente la necesidad de implantar una metodologa
que permitiera reconocer un amplio rango de riesgos.
Es necesario, por tanto, ampliar la informacin referente a esta tcnica. A continuacin se
exponen los aspectos y conceptos ms importantes de sta.

Identificacin de riesgos basada en taxonoma

Fue desarrollado en primera instancia por el SEI [Marvin J. Carr et al.., 1993] agrupando
diferentes fuentes y categoras de riesgos comunes proyecto de desarrollo de software.
La taxonoma agrupa los riesgos en tres niveles:
- Primer Nivel: Clases
a. Ingeniera del producto: comprende aquellos riesgos relacionados con el aspecto tcnico del
proyecto.
b. Entorno de desarrollo: riesgos relacionados con los mtodos, herramientas y procedimientos
a ser usados en el producto de software (ver Glosario).
c. Restricciones del programa: riesgos asociados con los factores organizacionales,
operacionales y contractuales dentro de los cuales se va a desarrollar el software.

- Segundo nivel: Elementos

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

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

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

De acuerdo con la figura 17 el modelo puede contar con una base de riesgos que son producto
de un estudio sobre diferentes proyectos de desarrollo de software [Marvin J. Carr et al., 1993].
Delimitacin del dominio
Una de las desventajas de la tcnica para identificacin de riesgos basada en taxonoma la
constituye precisamente el extenso dominio de los riesgos que se pueden reconocer, puede
resultar complejo realizar el anlisis por cada elemento de las clases y aun ms responder el
cuestionario establecido por cada uno de los atributos que constituyen los elementos.

Cmo delimitar el dominio de los riesgos?

Este modelo propone la delimitacin del dominio de los riesgos correspondiendo la definicin
de cada clase de la tcnica basada en taxonomas con la base estadstica recolectada gracias al
estudio sobre el estado de los proyectos de TI en Colombia desarrollado en este trabajo.

De qu manera intervienen los requerimientos funcionales en esta fase de identificacin?

Al constituir la base del trabajo es necesario profundizar en los posibles riesgos que se pueden
generar entorno a ellos. A pesar de partir de una clara especificacin de requerimientos, estos

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

Categorizacin de los riesgos identificados

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

En esta categora deben clasificar los riesgos relacionados con

RIESGOS DE problemas en: presupuesto, personal, planificacin, recursos.
PROYECTOS

RIESGOS En esta categora debe clasificar los riesgos relacionados con

TCNICOS problemas en: diseo, implementacin, interfaz, verificacin,
CATEGORAS mantenimiento, clientes y requisitos.

RIESGOS DE En esta categora debe clasificar los riesgos relacionados con

NEGOCIO problemas en: mercado, estrategia, comercializacin,
presupuesto de mercadeo.

Figura 18. Categorizacin de riesgos identificados

El resultado de la identificacin del riesgo

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

2.6.4.3 Cuantificar y cualificar los riesgos

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

60
 Anlisis
cuantitavito Cuantificar
Riesgos asociados al proyecto

Riesgos tcnicos
Anlisis Cualificar
cualitativo Riesgos de mercado

Figura 19. Tipos de anlisis y categoras del riesgo

De acuerdo con la figura 19 los riesgos categorizados como tcnicos o de mercado sern
analizados cualitativamente, mientras que los riesgos asociados a la categora de proyectos sern
analizados cuantitativamente.

Por qu esta divisin de anlisis para las categoras de riesgos?

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

Niveles de prioridad y de amenaza

Para mayor simplicidad, el nivel de prioridad de un riesgo basado en la combinacin de su
probabilidad e impacto estar definido de acuerdo con el siguiente grfico:

Probabilidad / Impacto Mnimo Bajo Medio Severo Crtico

Remoto
Improbable
Media
Posible
Muy Probable
Figura 20. Niveles de prioridad de riesgos

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

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

Media Medio, Severo

Posible Medio
Nivel
Muymedio
probable Mnimo, Bajo,
de amenaza Medio
Improbable Crtico

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

Remoto Mnimo, bajo, medio,
severo, critico
Improbable
Nivel bajo de Mnimo, bajo, medio,
severo
amenaza
Media Mnimo, bajo
Posible Mnimo, bajo

Proceso de anlisis cuantitativo

- Entradas
El anlisis cuantitativo usa como entrada una red de actividades, en el caso de la estimacin de
riesgos en calendario, y en la descomposicin de la estructura del trabajo en el caso de los
riesgos en costo. La construccin de la red de actividades generalmente se realiza sobre
Microsoft Project.
El anlisis cuantitativo se basa principalmente en el hecho de que existe una incertidumbre
entorno al proyecto que podra ocasionar, por ejemplo, que una actividad dure ms (o menos)
tiempo de lo planeado, o costar ms (o menos) dinero que lo presupuestado.

Software para el anlisis cuantitativo del modelo

El software destinado al anlisis cuantitativo de proyectos, como Monte Carlo en el caso de este
modelo, permite definir diferentes distribuciones de probabilidad para las actividades del
proyecto y generar simulaciones para poner a prueba el comportamiento del proyecto bajo
distintas condiciones.
Proceso de anlisis cualitativo

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

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

2.6.4.4 Respuesta al riesgo

Comprende la formulacin de planes de accin (planes de riesgo) para responder a los riesgos
en alta prioridad y otros analizados en la fase de cuantificacin y cualificacin. Este modelo
puede emplear cualquiera de las formas de expuestas en la fase de planificacin del riesgo con
el fin de crear planes que mitiguen el impacto del riesgo.

Plan de riesgo
De acuerdo con lo expuesto en la fase de planificacin del estado del arte los planes de riesgo
son estrategias que involucran acciones y otros conceptos para hacer frente al riesgo. De
acuerdo con la informacin recolectada acerca de los elementos de un plan de riesgos el modelo
define la siguiente lista para su propuesta:

- Elementos que debe contener el plan de riesgos del modelo

63
a. Nombre del riesgo: nombre que identifica como nico al riesgo.
b. Categora: nombre de la categora a la cual fue asociado el riesgo identificado.
c. Descripcin: breve caracterizacin del riesgo
d. Fuente: nombre del indicador que seala que el riesgo puede ocurrir en cualquier momento.
Se refiere a la misma definicin de fuente de riesgo otorgada en la fase de preparacin de la
metodologa.
e. Tipo de plan de riesgo: el tipo de plan de accin como estrategia para hacer frente al riesgo
puede ser cualquiera de las formas que puede tener un plan de riesgo y que se exponen en el
estado del arte. Los posibles planes de riesgo son: <plan de contingencia, evitar, aceptar,
transferencia, adquisicin de conocimiento>
f. Estado del plan de riesgo: lista de posibles estados de un plan de riesgo segn la fuente
[Maniasi, 2005] y los cuales se exponen en la fase de respuesta al riesgo del estado del arte.
g. Fecha de inicio del plan de riesgo: fecha en la que comenz a implementarse el plan de riesgo
h. Fecha mxima para finalizacin del plan de riesgo: fecha para la cual el plan de riesgo ya
debe estar implementado.
i. Responsable del plan de riesgo: persona encargada de ejecutar el plan de riesgo.
j. Acciones del plan de riesgo: acciones a llevar a cabo para lidiar con los problemas que
surgiran en caso de que el riesgo se convierta en un problema.

Proceso de respuesta al riesgo

En este punto es importante resaltar la importancia de recolectar en una base de conocimiento
del proyecto los riesgos junto con sus planes de riesgo, que como resultado de la fase de
cuantificacin y cualificacin, fueron evaluados como de alta prioridad o alto nivel de amenaza.

RIESGOS ALTA RIESGOS

PRIORIDAD PRIORIDAD
FORMULACIN DE
PLANES DE RIESGO MEDIA

RIESGOS
PRIORIDAD BAJA
Formulario de plan
Formulario de plan
de riesgo de la BASE DE APRENDIZAJE
de riesgo de la
metodologa DE RIESGOS
metodologa

Figura 22. Proceso de respuesta al riesgo

2.6.4.5 Control y seguimiento al riesgo

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

- Estado del plan de riesgos tal y como lo presenta [Maniasi, 2005].

- Mtricas obtenidas desde la estimacin de costos.
- Estado de la fuente o disparador del riesgo.
Luego de verificar la respuesta al riesgo la metodologa estar en la capacidad de decidir si el
plan de riesgo requiere revisiones o ajustes.

Proceso de control y seguimiento

FUENTES DE
RIESGOS
VERIFICACIN Y CONTROL
DEL PLAN DE RIESGO ESTADO PLAN DE
RIESGO

AJUSTES Y
REVISIN DE MTRICAS
PLANES SI
APLICA

Figura 23. Proceso de control de respuesta al riesgo.

2.7 RESULTADOS DEL CAPTULO

En este captulo se definieron los mtodos, metodologas y herramientas que fueron

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

65
 3. MODELO PARA LA ESTIMACIN Y GESTIN DE PROYECTOS

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

De igual manera el Anexo B contiene un caso prctico en donde se documenta el desarrollo y

resultados de la aplicacin experimental de este modelo.

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

Requerimientos Estimacin del Tamao

Requerimientos Estimacin
tamao del
funcionales
funcionales tamao enTamao
puntos
deenfuncin
puntos
de funcin

Formulario de
Formulariodel
estimacin de
estimacin
tamao del Control del
tamao Control del
presupuesto
presupuesto
Estimacin del costo y Formulario de
Estimacin del costo y
presupuesto Formulariodede
estimacin
presupuesto estimacin de Duracin total
costos Duracin total
costos del proyecto
del proyecto

Costo total por Plan de

Costo total por
requerimiento Plan de
requerimiento control de
control de
riesgos.
riesgos.

Gestin de riesgos
Gestin de riesgos
Figura 24. Pasos del modelo propuesto

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

66
3.1 PASO I: DEFINIR LOS REQUERIMIENTOS FUNCIONALES DEL PROYECTO

Las actividades que comprende la definicin de los requerimientos funcionales para el

modelo se explican a continuacin de manera formal, especificando sus entradas,
salidas y el proceso requerido.

3.1.1 Proceso de definicin de requerimientos

Este proceso comprende desde el conocimiento de los requerimientos funcionales del proyecto
hasta su especificacin utilizando la plantilla propuesta por la IEEE 2. Especialmente para el caso
de estudio donde se muestra la aplicacin prctica del modelo (Anexo B) fue utilizada la
plantilla para Especificacin de Requerimientos de Volere 3.

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

Especificacin de los Descripcin del proyecto y

requerimientosde los
Especificacin Descripcin del proyecto
especificacin y
de requerimientos
funcionales
requerimientos especificacin de requerimientos
funcionales

Descripcin formal del

proyecto formal del
Descripcin
proyecto

Figura 25. Proceso para la definicin de los requerimientos

ENTRADAS SALIDAS PROCESOS DESCRIPCIN

- Descripcin del proyecto. Descripcin del proyecto Descripcin formal del La especificacin de los
y de sus requerimientos proyecto requerimientos puede
- Especificacin de los funcionales. hacerse utilizando la
requerimientos funcionales plantilla Volere2.
utilizando la plantilla de
Volere.
Tabla 11. Elementos del proceso para la definicin de requerimientos

3.1.2 Descripcin del proyecto y especificacin de los requerimientos

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

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

67
la especificacin de cada uno de los requerimientos del proyecto se sugiere diligenciar la
plantilla propuesta por Volere4.
NOTA: La descripcin del proyecto puede ir contenida en la plantilla para la especificacin de
los requerimientos, sin embargo, sera conveniente contar con una descripcin global previa a la
especificacin.

3.2 PASO II: ESTIMAR EL TAMAO DEL SOFTWARE

Las actividades que comprende el paso para la estimacin del tamao se explican a
continuacin de manera formal, especificando sus entradas, salidas y el proceso
requerido.

3.2.1 Modelo para la estimacin del tamao

La figura 26 muestra las entradas y salidas que involucra el proceso para la estimacin del
tamao del software.

Requerimientos Categorizacin Lista priorizada de los

Requerimientos
Funcionales Categorizacin
determinacin: Lista priorizada de losde
elementos de puntos
Funcionales determinacin: elementos
componentes de funcin de puntos de
componentes de
Puntos de Funcin funcin
Puntos de Funcin

Informacin de
Informacin
entrada de
entrada

Clculo del Estimacin del tamao por

Clculo Estimacin del tamao por
total dedel
puntos de funcin requerimiento
total de puntos de funcin requerimiento

Figura 26. Esquema del Modelo de estimacin del Tamao

A continuacin se explica de manera ms formal las entradas, salidas y proceso para la

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

En el caso de este modelo la estimacin del tamao se realizar por requerimiento

contribuyendo con una estimacin mucho mas detallada. Para facilitar la utilizacin de esta

4
Volere Requirements Specification Template. Pgina consultada [Junio 2005]. Disponible en Internet:
<http:// http://www.volere.co.uk/template.htm>

68
parte del modelo se dise un formulario para la estimacin del tamao, el cual ser expuesto en
las siguientes secciones.

3.2.1.1 Entradas del modelo

Las entradas del modelo para la estimacin del tamao se enuncian acontinuacin:

Especificacin de requerimientos del proyecto: son las funcionalidades que el software debe
realizar. Esta especificacin debe ser tan formal como sea posible con el fin de que las
estimaciones realizadas se acerquen a la realidad del proyecto.

Informacin de Sistemas Externos: esta informacin hace referencia a toda la informacin

del entorno donde funciona el software que se est planeando. Dicha informacin consiste en:
- Bases de datos que utiliza.

- Otras fuentes de datos requeridas por el software.

- Sistemas externos con los que interacta.

3.2.1.2 Salidas del Modelo

Las salidas del modelo para la estimacin del tamao se enuncian acontinuacin:

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

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

3.2.1.3 Proceso para la estimacin del tamao

Ahora que ya se han mencionado las entradas y salidas del modelo para la estimacin del
tamao, se proceder a describir el proceso con el cual se estimar el tamao de cada uno de los
requerimientos del proyecto.

69
a. Identificar componentes funcionales

La metodologa de puntos de funcin requiere que se identifiquen una serie de componentes

funcionales los cuales proporcionan informacin acerca de la complejidad de un sistema de
software: para este caso la complejidad de implementar un requerimiento, a continuacin se
explican en ms detalle estos componentes.

Archivos Lgicos Internos (ILF)

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

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

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

b. Categorizar y definir el peso de cada uno de los componentes

Esta tarea se refiere a encontrar la dificultad para implementar cada uno de los componentes
identificados de puntos de funcin. La determinacin de esta dificultad permite estimar el
nmero de puntos de funcin para implementar en cada componente.

La dificultad de implementar cada uno de los componentes de puntos de funcin se determina,

encontrando el nmero de elementos de datos que se maneja en cada uno de estos componentes,
los tipos de elementos de datos varan dependiendo del tipo al cual corresponda ste. A
continuacin se clasifican los componentes de datos por componente, esto clarificar que se
debe identificar al evaluar la dificultad de implementacin para cada componente.

Archivos Lgicos Internos y Archivos de Interfaz Externos

Para estimar la complejidad de estos componentes se deben identificar dos elementos.
- Tipos de elementos de datos (DET): como su nombre lo indica son tipos de datos presentes
en el repositorio, un ejemplo de tipos de datos puede ser una columna de una tabla en una base
de datos.
- Conjunto de elementos de datos (RET): este elemento representa conjunto de elementos de
datos relacionados lgicamente que se encuentran en el repositorio de informacin, un ejemplo
de esto sera el conjunto de DET que representen una direccin.

Entradas Externas, Salidas Externas y Consultas Externas

En el caso de estos componentes se deben identificar los siguientes elementos para determinar
la complejidad para implementarlos.

- Tipos de elementos de datos (DET): al igual que para los anteriores componentes este
elemento representa los tipo de datos presentes en el componente, para el caso de los elementos

71
del tipo transaccional como los EI, EO, EQ este elemento representa datos que entran o salen de
la aplicacin, como ejemplo de estos elementos se tiene un campo de entrada de texto presente
en una interfaz grfica.

- Tipo de archivo referenciado (FTR): este elemento representa los repositorios de datos que
estn involucrados en el desarrollo de la transaccin del componente, estos repositorios son lo
que se identificaron anteriormente, como un ejemplo se puede tomar una transaccin que
obtiene datos de una tabla perteneciente a una base de datos, esta tabla sera el FTR a identificar.

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

Los elementos de puntos de funcin son clasificados dependiendo del nmero de elementos
identificados para cada uno en 3 categoras Alto, Medio, Bajo, para obtener las categoras a
partir del nmero de elementos se deben seguir las siguientes tablas.

Archivos Lgicos Internos y Archivos de Interfaz Externos

Para identificar la complejidad de estos componentes se sigue la tabla 12:

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

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

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

Salidas Externas y Consultas Externas

Para determinar la dificultad de implementacin se utiliza la tabla 14

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

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

c. Calcular el total de puntos de funcin.

Para esta labor se deben tomar los componentes identificados y categorizados en los numerales
anteriores y calcular el total de puntos de funcin para cada requerimiento: este clculo del total
de puntos de funcin se realiza mediante una ecuacin en la cual se le da un peso especfico y a
cada valor en los que se categoriz cada componente (Alto, Medio, Bajo). Para cada elemento
se debe multiplicar el peso del componente por el nmero de elementos de este tipo y luego
sumar este resultado con el valor dado para cada uno de los componentes, y el resultado de estas
operaciones es el total de puntos de funcin.

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

Para facilitar el clculo, el mtodo de puntos de funcin incluye una tabla en la cual se
encapsula la ecuacin necesaria para calcular el total de puntos de funcin, a continuacin se
muestra en la tabla 15:

Parmetro Complejidad Peso Cantidad Total = cantidad * peso

Ficheros Lgicos Alta 15
Media 10
Baja 7
Ficheros Lgicos Alta 10
Externos Media 7
Baja 5
Entradas Externas Alta 6
(EI) Media 4

73
 Baja 3
Salidas Externas Alta 7
(EO) Media 5
Baja 4
Consultas Externas Alta 6
(EQ) Media 4
Baja 3
Total Puntos Funcin = Suma de Totales
Tabla 15. Clculo del Total de Puntos de Funcin

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

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

Luego de realizar la estimacin del tamao con el mtodo de puntos de funcin, se procede a
estimar el costo necesario para implantar estos requerimientos.
Posteriormente se suma el resultado de cada uno de los tipos de componentes y este es el total
de puntos de funcin que se estim. La tabla 16 muestra los elementos que hacen parte de este
modelo:
ENTRADAS SALIDAS PROCESOS ACTORES
-Especificacin de los
requerimientos
funcionales.

-Informacin de
El tamao de cada uno de
Sistemas Externos: hace Aplicacin del mtodo Gerente del proyecto,
los requerimientos
referencia, a toda la de puntos funcin. para estimadores y el analista
especificados que se
informacin del entorno la estimacin del tamao de requerimientos
desean implementar.
donde funciona el
software (bases de datos
que utiliza, sistemas
externos con los que
interacta).
Tabla 16. Elementos del modelo para la estimacin del tamao

3.2.1.3 Formulario que apoya el modelo para la estimacin del tamao

El formulario diseado para este modelo: Formulario para la estimacin del tamao con
puntos de funcin (vase Anexo A) permite almacenar la informacin para el clculo de
puntos de funcin para cada uno de los requerimientos a estimar.

3.3 PASO III: GESTIONAR LOS COSTOS

74
Las actividades que comprende el paso para la gestin de costos del modelo se explican
a continuacin de manera formal, especificando sus entradas, salidas y el proceso
requerido.

3.3.1 Modelo para la gestin de costos

Este modelo de gestin de costos ofrece una herramienta sencilla que permite a sus usuarios
realizar este proceso sin la necesidad de usar recursos costosos que le consuman mucho tiempo.

Por otro lado, las actividades de estimacin de costos y de presupuesto se realizarn

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

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

La figura 27 muestra el proceso para la gestin de costos:

Tamao de los
Tamao de los
requerimientos
requerimientos

Estimacin de costos Costo total

Estimacin de costos Costo total
del proyecto del proyecto
del proyecto del proyecto

Estimacin del presupuesto del Presupuesto

Estimacin del presupuesto del Presupuesto
proyecto del proyecto
proyecto del proyecto

Presupuesto del
Presupuesto del
proyecto
proyecto
Indicadores de
Indicadores de
Control del presupuesto gestin
Control del presupuesto gestin

Figura 27. Esquema del Modelo para la gestin de Costos

Enseguida se explica en detalle cada uno de los pasos contenidos en la figura 27:

75
3.3.2 Estimacin de costos utilizando COCOMO II

Como se mencion en el capitulo anterior la metodologa escogida para realizar la estimacin

del costo del proyecto fue COCOMO II, especficamente el modelo de diseo anticipado,
debido a que es un modelo que ofrece buena seguridad en la estimacin sin mostrar toda la
complejidad del modelo de postarquitectura.

En esta explicacin no se adjuntarn las tablas mediante las cuales se calculan los parmetros
necesarios para realizar la estimacin con COCOMO, en el momento que se realice esta
estimacin se debe referir al manual de este modelo [Boehm, 1999]. Para aplicar el modelo
COCOMO II se deben realizar los siguientes pasos:

3.3.2.1 Estimar los Factores de escala para todo el proyecto

Estos factores slo deben ser estimados una vez para la estimacin de todos los requerimientos,
debido a que estos factores son explcitos para la organizacin que construir el software mas no
para un requerimiento especfico de la organizacin. Dichos factores indican si el desempeo
que muestra una organizacin ante un proyecto, especficamente si a medida que crece el
tamao del software a desarrollar de la misma manera crece el esfuerzo de desarrollarlo, o por el
contrario el esfuerzo de desarrollar este software es mucho mayor que el tamao, lo que
conlleva a un mayor costo en el proyecto. La estimacin de los factores de costo se realiza
utilizando la ecuacin 1:

Ecuacin 1. Estrimacin de factores de escala

En la ecuacin 1 se deben sumar los valores de cada uno de los 5 factores de escala para
aplicarlos a la ecuacin, las constantes presentadas en la misma son resultado de la
investigacin emprica realizada al desarrollar el modelo COCOMO, para encontrar el valor y
categorizacin de cada uno de estos factores se debe consultar el manual del modelo COCOMO
II [Boehm, 1999].
Los resultados de aplicar la ecuacin pueden ser:
- Si el resultado de la ecuacin (B) es >1 el esfuerzo necesitado para completar un proyecto se
incrementa en mayor medida que en la que aumenta el tamao del mismo.
- Si (B) es =1 el esfuerzo necesitado para completar un proyecto se incrementa en la misma
medida que el tamao del mismo.

76
- Si B es <1 el esfuerzo necesitado para completar un proyecto se incrementa en una menor
magnitud que el tamao del mimo.

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

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

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

Para efectos de esta propuesta el modelo de COCOMO II que se aplicar es el de diseo

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

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

3.3.2.3 Estimar el Presupuesto del Proyecto utilizando la ecuacin de COCOMO

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

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

Luego de conocer los valores anteriores se procede a utilizar la ecuacin 2 para el modelo de
diseo anticipado:

Ecuacin 2. Estimacin para el modelo diseo anticipado

La ecuacin 2 tiene varios parmetros que deben ser explicados para dar claridad acerca de la
utilizacin de este modelo:
- PM: esfuerzo necesario para implantar el requerimiento, este valor esta dado en personas/mes
requeridas para completar el proyecto.
- A: constante determinada empricamente por los creadores del modelo.

- Size: Tamao del requerimiento a implantar, obtenido anteriormente cuando se estimo el

tamao del requerimiento en estimacin.
- EM: esta variable representa el valor numrico dado a cada uno de los factores de costo
anteriormente categorizados.

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

En el Formulario para la estimacin de costos (ver Anexo A) se diligencian todos estos valores
obtenidos de la estimacin, con el fin facilitar la estimacin y permitir guardar registro de las
estimaciones realizadas.

3.3.3 Control de costos y presupuesto

78
Este paso en el modelo de Gestin de costos se realizara el control del presupuesto el cual se
estimo en el paso anterior, dicho control se realizara utilizando el mtodo del anlisis del valor
ganado, especficamente usando las mtricas relacionadas con el presupuesto, estas mtricas
permiten medir el desempeo del proyecto en algn punto del mismo, por ejemplo se puede
medir que tanto ha variado el costo del proyecto en contra del presupuesto del mismo.

3.3.3.1 Mtodo para el Control del Presupuesto

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

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

- Valor Planeado (PV): este parmetro representa el costo del trabajo que se ha realizado hasta
el momento de la aplicacin del mtodo.
- Earned Value (EV): el parmetro representa el valor estimado del trabajo actualmente
completado.
- Costo Actual (AC): este ltimo parmetro representa el dinero realmente invertido al
momento actual.

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

- Variacin del Costo (CV): esta mtrica estima en cuanto el proyecto se encuentra por encima
o debajo del presupuesto.
- ndice de desempeo del costo (CPI): en esta mtrica se obtiene cuanto se gana o se pierde
por cada unidad de dinero invertida en el proyecto.
- Estimacin a la Terminacin (EAC): para esta mtrica existen varias formula pero en general
lo que intentan estimar es cuanto constara el proyecto en total luego de obtener estas mtricas.
- Estimacin a la Terminacin (ETC): esta mtrica intenta estimar cuanto mas el proyecto
costara luego del avance alcanzado al momento de utilizar la mtrica.
- Variacin a la Terminacin (VAC): La mtrica estima cuanto sobre el presupuesto costara
realmente el proyecto.

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

De manera resumida se exponen las entradas, salidas, procesos y actores involucrados en los
proceso de estimacin y gestin de costos (ver tabla 17).
ENTRADAS SALIDAS PROCESOS ACTORES
- Estimacin de costos:
Tamao de cada
- Presupuesto del
requerimiento funcional. Aplicacin del mtodo Gerente del proyecto,
proyecto: unin de las
de puntos funcin. para estimadores y el analista
estimaciones de costo de
Gestin de costos: la estimacin del tamao de requerimientos
cada requerimiento
presupuesto estimado

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

3.4 PASO IV: GESTIONAR LOS RIESGOS

De acuerdo con el diagrama de flujo mostrado en la figura 28, las fases corresponden a cada uno
de los pasos de la metodologa para la gestin de riesgos que se propone. Las salidas
(componentes en color amarillo representan los formularios de apoyo que suministra la
metodologa en algunos de los pasos de la gestin del riesgos).

Preparacin
Preparacin
Identificacin y categorizacin Formulario de
Identificacin y categorizacin Formulario
riesgos de
identificados
riesgos identificados

Fase de cuantificacin y
Fase de cuantificacin y
Anlisis cualitativo priorizacin Anlisis cuantitativo
Anlisis cualitativo priorizacin Anlisis cuantitativo

Estimacin de riesgos Estimacin de riesgos de

Estimacin
tcnicos de riesgos
y de negocio Estimacin de riesgos de
proyecto
tcnicos y de negocio proyecto

Formularios de Formularios para

Formularios de Formularios para
anlisis
apoyo dinmica
apoyo dinmica anlisis
cuantitativo
Wideband Delphi
Wideband Delphi cuantitativo
Respuesta al riesgo
Respuesta al riesgo
Formularios de
Formularios
Plan de riesgo de
Plan de riesgo
Control de respuesta Revisar y ajustar el
Control de respuesta Revisar y ajustar el
al riesgo plan de riesgo
al riesgo plan de riesgo
BASE DE APRENDIZAJE
DE RIESGOS

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

A continuacin se explican en detalle cada uno de los pasos de esta metodologa:

3.4.1 Prepararse para la gestin

Comprende la delimitacin y definicin del marco de las fuentes y categoras del riesgo.
Finaliza con la comunicacin del marco de las fuentes y categoras a los miembros del equipo.
Ver figura 29.

Conjunt Conjunto
o de de
fuentes categoras
de riesgo.
riesgo.

DAR A CONOCER -COMUNICAR

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

3.4.2 Identificar los riesgos y categorizarlos

Delimitar e identificar el dominio de posibles riesgos segn la tcnica de identificacin

basada en taxonomas.
La delimitacin realizada segn las clases se expone a continuacin:

- Delimitacin segn la clase Entorno de desarrollo

Reconocer los riesgos asociados con la poca y/o mala comunicacin y los asociados con la
planeacin del proyecto dentro del proceso de gestin de riesgos.
Mientras que la experiencia del gerente del proyecto, atributo del elemento Proceso de
administracin, puede surgir como un riesgo alterno teniendo en cuenta las estadsticas
relacionadas con los aos y estudios de los gerentes de proyectos de TI en Colombia. Ver figura
30.

81
 Proces
o de
EXPERIENCI admini PLANEACIN
EXPERIENCI PLANEACIN
A DEL straci
A DEL
GERENTE n
GERENTE

Criterios
de fracaso
Elemento de la clase

Entorn
Estado de proyectos de TI
o de
trabajo
COMUNICACI
Atributo COMUNICACI
N
N
E
E
X
Figura X
P 30. Delimitacin segn la clase Entorno de desarrollo
P
E
E
R
R
I
I
E
- Delimitacin segn la clase Restricciones del programa
E
N
N del desempeo en cronograma y presupuesto de los proyectos de TI en Colombia
El estado
C
C
I
(secciones
A
I 1.1.1 y 1.1.2) justifica el hecho de incorporar los riesgos asociados con el desempeo
A
del proyecto y los recursos en el proceso de gestin del riesgo.
D
D
E
E Desem
L
L DESEMPEO EN peo
DESEMPEO EN
G ELPRESUPUESTO
EL proyect DESEMPEO EN
PRESUPUESTO DESEMPEO EN
G os EL
E EL
CRONOGRAMA
E CRONOGRAMA
R
R
E Estado de proyectos de TI
E
N
N
T Recurs
T Elementos de la clase
E os Recurs
E
os
Atributo

E
E
X
Figura 31. Delimitacin segn la clase Restricciones de programa
X
P
P
E riesgos y los requerimientos funcionales del proyecto
- Delimitacin del dominio de los E
R
R
La especificacin de requerimientos
I al constituir una de las principales actividades en la cual se
I
E
enfoca los proyectos de TI debe E
N demandar tambin una mayor atencin en el sentido que la
N
C requerimientos debe ayudar a identificar y controlar aquellos
gestin de riesgos asociados a losC
I
aspectos que pudieran desviar laA Idefinicin del producto a desarrollar as como el cumplimiento
A
D
de los requerimientos establecidos
E
D por el cliente.
E
L
Otro aspecto a considerar, no menos
L importante que el anterior, es el hecho de que este trabajo
G
establece como punto de partida G
E una buena especificacin de requerimientos (no ambiguos y
E
R
completos) lo cual conlleva a ElaR necesidad de asegurar un marco en donde stos se puedan
E
N
N
T
T
E
E 82
implementar de acuerdo con la definicin y las funcionalidades establecidas en la fase de
especificacin.

Requerimientos
CARACTERSTICAS
CARACTERSTICAS
DEL ELEMENTO
DEL ELEMENTO

Estado de proyectos
de TI
Actividades
Elementos de la clase en proyectos
de TI
Estabilidad
Atributo Claridad
Completitud Validez
E
E
X
X Figura 32. Delimitacin segn la clase Ingeniera del producto
P
P
La identificacin de un conjunto ms amplio de riesgos es una opcin contemplada dentro de
E
E
R
I
R
esta propuesta. La delimitacin planteada en esta seccin se construy con el fin de fusionar los
I
E del trabajo con los de la caracterizacin del estado de proyectos de TI en Colombia.
objetivos
E
N
N
C
C
I
NOTA: A
I Utilizar otras tcnicas y criterios de limitacin del dominio de riesgos si se considera
A
necesario es posible hacer uso de otras tcnicas para la identificacin de riesgos. Para ello, la
D
fuenteED
[Maniasi, 2005] explica las principales de ellas.
E
L
L
G Categorizar los riesgos identificados
3.4.2.1G
E
E
La categorizacin con base a los riesgos identificados se ilustra en la figura 33:
R
R
E
E Tcnica Requerimientos
N
N
T
T
E CATEGORAS Plan de proyecto Recursos Entorno de trabajo Proceso de administracin
E

Negocio Otros elementos de la taxonoma

Figura 33. Categorizacin de riesgos identificados

3.4.2.2 Dar a conocer el resultado de la identificacin

Con el fin de facilitar el entendimiento y comunicacin de los riesgos el Formulario de riesgos

identificados (vase Anexo A) muestra el diseo de un formato que recopilar la informacin
ms importante por cada riesgo identificado del proyecto como resultado de esta fase de
identificacin de la metodologa.

3.4.3 Cuantificar y cualificar los riesgos

Una vez los riesgos son identificados es necesario medir las consecuencias y
probabilidad de ocurrencia. Los riesgos categorizados como tcnico sern tratado bajo

83
un anlisis cualitativo mientras que los de proyecto (calendario y costos) se analizaran
cuantitativamente.

3.4.3.1 Anlisis cualitativo

Realizar Dinmica variante del mtodo Wideband Delphi para el anlisis cualitativo de riesgos

Participantes dinmica variante Wideband Delphi

- Coordinador
- Miembro del equipo de proyecto

Pasos que comprende la dinmica variante Wideband Delphi

La figura 34 muestra los pasos de la variante de la dinmica Wideband Delphi propuesta en este
modelo. La explicacin de cada uno de los pasos as como los participantes que los desarrollan
se muestran a continuacin.

Sesin para la
Sesin revisin de
Formato de
introductoria Formato de resultados
evaluacin de
evaluacin de
resultados
resultados

Riesgos descritos y
Riesgos descritos y
categorizados
categorizados
(Formulario de la
(Formulario de la Informe de la
sesin introductoria). Sesin de evaluacin Informe de la
sesin introductoria). evaluacin
de resultados evaluacin

Sesin para la
revisin de la
estimacin final
Formato de recordacin de
Formato de
niveles de recordacin
probabilidad,de
nivelesy prioridad.
impacto de probabilidad,
impacto y prioridad.

Formulario de
Formulario de Formato de la
la estimacin Formato de la
la estimacin estimacin final
individual estimacin final
individual

Sesin de
estimacin
individual

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

Paso 1: Sesin introductoria. Incluye la presentacin de los riesgos identificados junto con su
categora y descripcin. Para ello el modelo propone la utilizacin del Formulario de la sesin
introductoria (vase Anexo A).

84
a. El coordinador presenta a los miembros del equipo los riesgos identificados durante la fase
de anterior, su categorizacin y fuente.
b. El coordinador explica las razones por la cuales fueron considerados esos riesgos como
problemas potenciales para el proyecto.
c. El coordinador explica los valores por cada nivel de impacto y probabilidad que se van a
manejar.

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

Paso3: Evaluacin de resultados. El coordinador evala los resultados de las estimaciones

individuales (vase Anexo A Formulario de evaluacin de resultados) utilizando el promedio
de los valores de probabilidad e impacto comenzando por los riesgos que fueron evaluados con
alto nivel de amenaza.

85
 Discusin: nueva
iteracin Analizar valor de
Riesgo con cierto la moda
nivel de amenaza SI
Desviaci
n
estndar
baja NO
Revisar valor de la Estipular la prioridad del
desviacin estndar riesgo conforme al nivel de
amenaza

Prioridad de riesgo alta: el

riesgo requiere un plan de
mitigacin de inmediato

Figura 35. Evaluacin de resultados

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

NOTA: Si los valores de promedio de la probabilidad o el impacto del riesgo difieren

significativamente despus de la tercera iteracin es necesario llevar a un acuerdo las opiniones
de los participantes con el fin de alcanzar un nivel de prioridad consensuado.

Paso 4. Sesin para la revisin de la estimacin. El coordinador presenta el informe de la

evaluacin (vase Anexo A Formulario de evaluacin de resultados) que contiene:
- Los nuevos riesgos junto con sus valores de probabilidad e impacto.
- Los riesgos con un valor de desviacin estndar significativo en sus promedios de impacto
y/o probabilidad.

86
- El equipo reanuda las estimaciones teniendo en cuenta el informe preparado por el
coordinador.
- El coordinador prepara el informe final con los resultados de la ltima estimacin.

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

3.4.3.2 Anlisis cuantitativo

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

3.4.3.3 Pasos para el anlisis cuantitativo de riesgos

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

87
Paso 5: Comunicar el resultado del anlisis al grupo (vase Anexo A Formulario de revisin
de la estimacin final).

3.4.4 Responder al riesgo

La figura 22 muestra paso a paso la definicin de la fase de respuesta al riesgo para la

metodologa propuesta en este modelo.

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

3.4.4.2 Plan de riesgo

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

3.4.4.3 Base de aprendizaje de riesgos del proyecto

Consiste en un espacio (puede ser un medio magntico) destinado a agrupar los planes de riesgo
de aquellos priorizados de manera alta tras la fase de cuantificacin y cualificacin.

Riesgos
cualificados y
cuantificados

Plan de riesgo

Riesgos
con alta
prioridad

FIN
BASE DE
APRENDIZAJE
DE RIESGOS

Figura 36. Respuesta al riesgo del modelo propuesto

3.4.4.4 Salidas de la respuesta al riesgo

88
Las salidas para esta fase la conforman el grupo de planes de riesgo algunos de los cuales,
dependiendo de la prioridad deben ser enviados a la base de aprendizaje de riesgos del proyecto,
es preciso mencionar, adems, que de acuerdo con la categora del riesgo los planes pueden
incluir nuevos elementos:
- Para el caso del riesgo en costo se pueden especificar las mtricas de control de costos del
modelo (este modelo define ya algunas en la fase de control y seguimiento) mediante las cuales
se puede medir el plan de riesgo
- Para el riesgo en calendario se deben definir las acciones para reducir la duracin de las
actividades del proyecto y cumplir con la probabilidad mnima de establecida por la gerencia de
terminar el proyecto en una fecha dada (corresponde con la mtrica definida para medir el plan
de riesgo en calendario).

3.4.5 Fase de control y seguimiento

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

FUENTES
Planes
Planesdede EVALUACIN ESTADO PLAN DE
riesgos RIESGO
riesgos
MTRICAS

Figura 37. Control y seguimiento del modelo propuesto

3.4.5.1 Verificacin de plan de riesgo segn las fuentes del riesgo

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

89
 PLAN
PLANDE
DERIESGO
RIESGO
Implica revisin rigurosa y continua
Plan rojo del plan de riesgo y la realizacin de
ajustes conforme a los resultados de
sta.

Implica el ejercicio de revisiones

Plan amarillo breves sobre el plan de riesgo y
pequeos ajustes que se vayan
requiriendo conforme a stas.

Otros planes se han

Plan reabierto implementado sin arrojar los
resultados esperados: ste
debe ser, por tanto, revisado
continuamente.

Figura 38. Estado de planes de riesgo y revisin

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

Mtrica para riesgo en costo

DVP: desviacin
mxima aceptada por
Mtrica: AC>DVP
encima del VP

Figura 39. Mtrica para riesgo en costo

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

Mtrica asociada con el riesgo en calendario

Los acrnimos usados para esta mtrica se mencionan en la siguiente tabla:
Acrnimo Trmino Explicacin
PTPE Probabilidad esperada de cumplimiento del Cul es la probabilidad
cronograma en la fecha de terminacin del mnima esperada de que el
proyecto. proyecto se termine en la
fecha de terminacin
estipulada?
PTP Probabilidad de la terminacin del proyecto Probabilidad de terminacin
en una fecha del proyecto en una fecha
dada (obtenida a travs de la
simulacin)
Tabla 18. Acrnimos para la mtrica de riesgo en calendario

90
 Mtrica: PTP< PTPE
Cronograma: X% de
probabilidad de xito
en la fecha de
terminacin.

Figura 40. Mtrica para riesgo en calendario

Si la mtrica indicara que la probabilidad obtenida del cumplimiento del cronograma del
proyecto (PTP) en la fecha estipulada para su terminacin, a travs del mtodo Monte Carlo, es
menor que la probabilidad mnima esperada (PTPE), el plan de riesgo debe ser supervisado y
ajustado en cuanto a sus acciones a seguir.
NOTA: El dominio de estas mtricas puede crecer conforme al tipo de proyecto y otras medidas
que el gestor de riesgos u otros miembros del equipo de proyecto identifiquen a lo largo del
proceso.

3.5 Paso V: Finalizar la gestin

Una vez culmine la fase de gestin del riesgo los resultados de la ejecucin de los pasos modelo
materializados en los formularios diligenciados del mismo, deben ser tratados y almacenados en
un repositorio de informacin relacionada con la planeacin del proyecto.
Los datos que guardan las estimaciones del tamao y de la gestin deben ser revisados
continuamente con el fin de determinar si la realidad actual del proyecto coincide con lo
plasmado all.

3.6 RESULTADOS DE L CAPTULO

En este captulo se obtuvieron los modelos y metodologas definitivas que sustentan el modelo.
Los modelos para la estimacin y gestin de costos y la metodologa definida para la gestin de
riesgos son obtenidos como resultado del anlisis efectuado en la propuesta conceptual de este
trabajo.

91
 4. CONCLUSIONES

1. Se logr desarrollar un modelo para la estimacin del tamao del software y la gestin de
costos y riesgos de un proyecto de desarrollo tomando como base los requerimientos
funcionales del mismo.
2. El modelo propuesto se encuentra fundamentado en la utilizacin de diversas
metodologas y tcnicas para la estimacin del tamao y gestin de costos y riesgos de un
proyecto de software, extradas como resultado del estudio sobre diversas fuentes de
informacin relacionadas con el tema.

3. Se establecieron criterios para la clasificacin de las metodologas encontradas para la

estimacin del tamao y gestin de costos y riesgos de un proyecto de desarrollo, llevando a
cabo para este fin un marco comparativo entre dichas metodologas.

4. Adicionalmente a la definicin de los criterios fue posible establecer requisiciones y

principios bsicos sobre los cuales debe basarse una metodologa de gestin de riesgos y
algunas tcnicas involucradas en este mismo proceso.

5. Se establecieron metodologas y tcnicas especficas asociadas con la estimacin del

tamao y gestin de costos y riesgos de un proyecto de software que responden a los
criterios ya definidos.

6. Las metodologas y tcnicas especificadas con base en los criterios definidos,

constituyen la base del modelo propuesto para la estimacin de tamao y gestin de costos
y riesgos de un proyecto de desarrollo de software.

7. Es una finalidad del modelo suministrar un marco bsico de metodologas y tcnicas

basadas en el uso de herramientas de fcil acceso que faciliten, a su vez, el proceso de
estimacin y gestin de costos y riesgos en un proyecto de desarrollo.

8. La aplicacin prctica del modelo a travs de un caso de estudio permiti validar

experimentalmente algunos de los pasos que constituyen el mismo, generando una adecuada
gestin de costos y riesgos de acuerdo con los criterios especificados.

9. La validacin experimental del modelo present algunas limitaciones como resultado de

algunas restricciones de la empresa donde se desarrollo el caso de estudio, por tanto algunos

92
 pasos del modelo tuvieron que ser adaptados de acuerdo con otros anteriores que s se
lograron aplicar de manera prctica.

5. TRABAJOS FUTUROS

.1 Implementar una herramienta computacional de apoyo al modelo que incluya todos los
pasos propuestos por ste y facilite al usuario el almacenamiento y clculo de los datos en un
mismo entorno.
.2 Ampliar la aplicacin prctica del modelo en empresas a gran escala, con el fin de obtener
nuevos resultados que complementen el caso de estudio presentado en este trabajo y exploren
nuevas experiencias con el fin de sugerir mejoramientos a los procesos y conceptos propuestos
para la estimacin y gestin de proyectos de software.

.3 Complementar el modelo a travs de la propuesta de una metodologa para la estimacin y

control de calendario.

.4 Se sugiere el desarrollo de un estudio ms profundo acerca del estado de las pymes

colombianas con respecto a las reas de estimacin y gestin de proyectos, con el fin de
extender la aplicacin del modelo teniendo en cuenta nuevas necesidades y requerimientos de
las empresas aparte de las mencionadas e identificadas en este trabajo.

93
 BIBLIOGRAFA

[ACIS, 2007]. V Encuesta de gerencia de proyectos. Asociacin colombiana de ingenieros de

sistemas, 2007.
[Armstrong, 2004]. Managing Software Project Risk. 2004. Tassc-solutions.

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

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

[Boehm, 1990] Boehm, B. Software Risk Management: Principles and Practices. IEEE
Software (January 1990)

[Camacho, 2005]. Herramienta Para El Anlisis De Requerimientos Dentro De La Pequea

Empresa Desarrolladora De Software En Bogot, Pontificia Universidad Javeriana,
Departamento de Ingeniera de Sistemas, Colombia, 2005.

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

[Esteves, 2004]. Implementacin y Mejora del Mtodo de Gestin Riesgos del SEI en un
proyecto universitario de desarrollo de software, Argentina, 2004.

[Hulett, 2003-1]. Quantitative Risk Analysis is Fundamentals, Acquisition Community

Connection, Los Angeles, 2003.

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

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

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

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

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

[Labdelaoui, 2001]. Mtodos de Estimacin de Tamao Funcional del Software Aplicados a

Enfoques de desarrollo, NASSCOM Conference, India, 2001.

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

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

tesis de Magster, Argentina, 2005.

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

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

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

[Salinas, 2007]. SALINAS, Andrs. Obstculos en la gestin de proyectos en tecnologas de

informacin y comunicacin TICs y posibles soluciones. UPB Bucaramanga. 2007.

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

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

95
 ANEXOS

A FORMULARIOS DEL MODELO

B CASO DE ESTUDIO

C FORMULARIOS DEL CASO DE ESTUDIO

D ENCUESTA SOBRE GESTIN DE PROYECTOS

ESPECIFICACIN DE LOS REQUERIMIENTOS

E DEL PROYECTO: CASO DE ESTUDIO

96
 Anexo A

AFORMULARIOS DEL MODELO

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

97
 Formulario para la estimacin del tamao con Puntos de Funcin

Nmero de Dificultad
Requerimientos componentes de datos
Archivos que gestionan la Requerimiento1 Requerimiento2 Requerimiento3 Requerimienton RET DET
aplicacin(ILF)

Nmero de Dificultad
Requerimientos componentes de datos
Archivos de Interfaz (ELF) Requerimiento 1 Requerimiento2 Requerimiento 3 Requerimienton RET DET

98
 Formulario para la estimacin del tamao con Puntos de Funcin

Nmero de componentes Dificultad

Requerimientos de datos
Entradas Externas (EI) Requerimiento 1 Requerimiento2 Requerimiento 3 Requerimienton FTR DET

Nmero de componentes Dificultad

Requerimientos de datos
Salidas Externas (EO) Requerimiento 1 Requerimiento2 Requerimiento 3 Requerimienton FTR DET

99
 Nmero de Dificultad
Requerimientos componentes de datos
Consultas Externas (EQ) Requerimiento 1 Requerimiento2 Requerimiento 3 Requerimienton FTR DET

Total de Puntos de Funcin

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

100
 Formulario para la estimacin de costos

Factores de Escala

Valor Extra Alto Alto Nominal Bajo Muy Bajo

Factores de Escala
Precedencia
Experiencia de trabajo con sistemas de sw relacionados

Flexibilidad de desarrollo
Arquitectura / Resolucin de Riesgos
Madurez del Proceso

Estimacin de Costos

101
Tamao Requerimiento(Puntos de
Funcin)
Factores de Escala Valor Requerimiento 1 Requerimiento 2 Requerimiento 3 Req n
Extra Alto
Muy Alto
Alto
Fiabilidad del Producto y Complejidad Nominal
Bajo
Muy Bajo
ExtraBajo
Extra Alto
Muy Alto
Alto
Reutilizacin Requerida Nominal
Bajo
Muy Bajo
ExtraBajo
Extra Alto
Muy Alto
Alto
Dificultad de la Plataforma Nominal
Bajo
Muy Bajo
ExtraBajo

Experiencia del Personal Extra Alto

Muy Alto
Alto

102
 Nominal
Bajo
Muy Bajo
ExtraBajo
Extra Alto
Muy Alto
Alto
Facilidades Nominal
Bajo
Muy Bajo
ExtraBajo
Extra Alto
Muy Alto
Alto
Planificacin Temporal Nominal
Bajo
Muy Bajo
ExtraBajo
Costo Requerimiento $

103
 FORMULARIO DE RIESGOS IDENTIFICADOS
FORMULARIO DE RIESGOS IDENTIFICADOS
INFORMACIN REQUERIDA
DEL RIESGO
Nombre riesgo
Fecha Nombre
Componente subsistema
Categora asociada
Descripcin del riesgo
Fuente de riesgo
Responsabilidad
DESCRIPCIN DEL RIESGO
IDENTIFICADO
Asigna un nombre nico al riesgo.
Fecha y nombre de la persona que report el
riesgo.
Identifica el subsistema / componente de la
descomposicin de la estructura del trabajo (WBS)
o proceso en el cual se localiza el riesgo.
Identifica a qu categora (Tcnico. Proyecto o
negocio) se encuentra asociado el riesgo.
Es una breve descripcin del riesgo. Puede ser
complementada durante la fase de cuantificacin y
priorizacin.
Situaciones que hacen parte del entorno del
proyecto y a su vez son productoras del riesgo.
Determina a quien fue asignada la responsabilidad
individual del manejo del riesgo.
104
 FORMULARIO DE LA SESIN INTRODUCTORIA

FORMULARIO DE LA SESIN INTRODUCTORIA

Nombre participante: Fecha

No DESCRIPCIN CATEGORIA OBSERVACIONES

RIESGO

105
 FORMULARIO DE LA SESIN DE ESTIMACIN
INDIVIDUAL

FORMULARIO DE LA SESIN DE ESTIMACIN INDIVIDUAL

Nombre participante: Fecha

No RIESGO DESCRIPCIN PROBABILIDAD IMPACTO PRIORIDAD

LISTA DE RIESGOS ADICIONALES PROPUESTOS

JUSTIFICACIN
RIESGO DESCRIPCIN CATEGORA

FORMATO PARA LA RECORDACIN DE NIVELES

DE PROBABILIDAD, IMPACTO Y PRIORIDAD

106
 NIVEL DE PROBABILIDAD ESCALA

Remoto >10%
Improbable (11 30) %
Probabilidad media (31 50)%
Posible (51 - 70) %
Muy Probable (>71%)
ESCALA
NIVEL DE IMPACTO

Mnimo 1
Bajo 2
Medio 3
Severo 4
Crtico 5

Probabilidad / Impacto Mnimo Bajo Medio Severo Crtico

Remoto
Improbable
Probabilidad media
Posible
Muy Probable

FORMULARIO DE EVALUACIN DE RESULTADOS

FORMULARIO DE EVALUACIN DE RESULTADOS

Fecha evaluacin

107
RIESGO PROMEDIO DESVIACIN PROMEDIO DESVIACIN MODA
PROBABILIDAD ESTNDAR MODA IMPACTO ESTNDAR

108
FORMULARIO DE REVISIN DE LA ESTIMACIN
FINAL

FORMULARIO DE REVISIN DE LA ESTIMACIN FINAL

Fecha:
RIESGO FUENTE CATEGORA PRIORIDAD
(Opcional)

109
 FORMULARIO PARA EL ANLISIS CUANTITATIVO
DE RIESGO EN CALENDARIO

ANALISIS CUANTITATIVO DE RIESGO EN CALENDARIO

Nombre evaluador: Fecha

ACTIVIDAD DURACIN DURACIN DURACIN

MNIMO MS MXIMO
PROBABLE

110
 FORMULARIO PARA EL ANLISIS CUANTITATIVO
DE RIESGO EN COSTOS

ANALISIS CUANTITATIVO DE RIESGO EN COSTO

Nombre: Fecha:

REQUERIMIENTO COSTO COSTO MS COSTO

MNIMO PROBABLE MXIMO

111
 FORMULARIO DE PLAN DE RIESGO

FORMULARIO DE PLAN DE RIESGO

NOMBRE DEL RIESGO CATEGORA

DESCRIPCIN

FUENTE TIPO PLAN DE RIESGO

FECHA INICIO DE PLAN FECHA FINAL DE PLAN

112
ESTADO DEL PLAN DEL RIESGO RESPONSABLE

ACCIONES A LLEVAR A CABO

Anexo B

B CASO DE ESTUDIO

- Descripcin y formalizacin del proyecto de caso de estudio

- Aplicacin prctica de algunos pasos de la metodologa

- Formularios utilizados en la aplicacin prctica

113
Descripcin del proyecto y definicin de los requerimientos funcionales

1.1 Descripcin del proyecto

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

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

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

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

En el momento de planear este proyecto se pens que para su implementacin lo ms conveniente

era desarrollar componentes genricos que pudieran ser extendidos con nuevos servicios, esto con el
fin de disminuir el tiempo de implantacin de estos.

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

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

Figura 1. Diagrama de casos de uso del proyecto

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

1.2 Especificacin de los requerimientos funcionales

A continuacin se listan los requerimientos funcionales a implementar:

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

115
Estimar el tamao del software

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

2.1 Resultado del modelo para la estimacin del tamao

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

Gestionar los costos

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

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

116
Gestionar los riesgos

De acuerdo con lo que se ilustra en la figura 36 se documentan algunos de los pasos de la

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

1. Prepararse para la gestin

1.1 Fuentes de riesgo

El dominio de las fuentes as como de las categoras planteadas por el modelo fueron acogidas por el
gestor del proyecto.

2. Identificar y categorizar los riesgos

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

3. Cualificar y cuantificar los riesgos

3.1 Anlisis cualitativo

Se realiz el anlisis cualitativo al riesgo tcnico

3.1.1 Desarrollo de la dinmica variante del Mtodo Wideband Delphi

Se presenta el formulario de evaluacin de resultados que contiene la evaluacin individual del

riesgo tcnico obtenido en una de las iteraciones de la dinmica (vase Anexo C Formulario de
evaluacin de resultados).

117
4. Cuantificacin y priorizacin

4.1 Estimacin de riesgo en calendario

4.1.1 Determinacin de la lnea base de actividades del proyecto.

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

Figura 2. Cronograma estimado para el proyecto

De acuerdo con la figura 40 la lnea base de actividades del proyecto es:
- Actividad 1: Anlisis
- Actividad 2: Diseo
- Actividad 3: Desarrollo
- Actividad 4: Documentacin
Y la fecha de terminacin del proyecto hasta la fase de documentacin debera ser el da 14 de
febrero.
4.1.2 Definicin de rango de duracin para cada una de las actividades.
Contamos con la participacin del gerente de proyecto para obtener las estimaciones de tres
puntos correspondientes a las duraciones de cada una de las actividades de la lnea base del
proyecto:
Actividades Bajo Ms probable Alto
Anlisis 1 2 5
Diseo 1 4,5 10
Desarrollo 7 16 30
Documentacin 1 2 5
TOTAL 10 24,5 50
Tabla 1. Estimacin de tres puntos de las actividades del proyecto.

4.1.3 Simulacin de tres puntos para la probabilidad de la Terminacin Total del proyecto
Esta distribucin de fechas de finalizacin del proyecto es hallada mediante la simulacin del
cronograma varias veces. En cada iteracin una duracin de la estimacin de tres puntos es escogida
aleatoriamente. Como en este caso no se conoce cul combinacin de duraciones va a ocurrir la

118
simulacin se realiz con 2500 iteraciones cada una con una duracin seleccionada al azar. La figura
40 muestra la distribucin generada a partir de los rangos de estimacin de los valores optimista
(bajo), ms probable y pesimista (alto) para cada una de las actividades del cronograma del proyecto.

Figura 3. Distribucin de probabilidad de posibles fechas de entrega

Conforme a la grfica de distribucin de las fechas de actividades del proyecto (Figura 3) es posible
concluir que la fecha de finalizacin del proyecto es cercana al 22 de febrero.
Probabilidad acumulada:
Los resultados del anlisis de riesgos proveen posibles fechas y sus probabilidades para la entrega
del sistema. La tabla muestra la probabilidad por cada posible fecha de finalizacin del proyecto:
Fecha Probabilidad
12/02/2007 38,30%
13/02/2007 42,50%
14/02/2007 46,90%
15/02/2007 50,30%
16/02/2007 55,90%
19/02/2007 60,70%
20/02/2007 66,80%
21/02/2007 70,70%
22/02/2007 74,70%
23/02/2007 77,77%
26/02/2007 81,10%
27/02/2007 84,80%
Tabla 2. Probabilidad de las fechas para la finalizacin del proyecto.

De acuerdo con la tabla 16, la probabilidad de terminar el proyecto hasta la fase de documentacin
en la fecha estimada (14 / 02/ 2007) es de slo 46,9%.

En este caso era requerido que el cronograma contara con por lo menos un 80 % de probabilidad de
xito es decir que el da estipulado de finalizacin (14 de febrero) contar, al menos con una

119
probabilidad del 80% de haber terminado el proyecto. Sin embargo, como se aprecia en la tabla 2 la
fecha que cuenta con dicha probabilidad es hasta el 26 de febrero: 12 das despus de la fecha
estimada para la terminacin.

4.1.4 Discusin de resultados

En cuanto a costos es inminente la necesidad de acordar un plan de mitigacin relacionado con el

posible retraso del proyecto debido a las siguientes razones:

La probabilidad de que la fecha estimada para la terminacin del proyecto es menor al 50%: las
posibilidades de finalizacin en la fecha planeada se reducen slo a la mitad del total de ellas, por
tanto, constituye un alto riesgo la manera como el cronograma se encuentra planeado.
La planeacin del cronograma no alcanza siquiera a satisfacer el requerimiento de al menos el
80% del cumplimiento: el desfase en das es de 12 un nmero que puede ser considerablemente alto
teniendo en cuenta este tipo de proyectos.

4.2 Estimacin de riesgo en costos

Una segunda parte del anlisis cuantitativo lo constituye la estimacin de los riesgos en costos. A
continuacin se describen las actividades y resultados obtenidos con respecto a este caso de estudio.

4.2.1 Determinar el grupo de elementos del WBS

El grupo de elementos de la descomposicin de la estructura del trabajo de acuerdo con lo

planteado por este modelo lo constituyen los requerimientos del proyecto. La siguiente es
la lista de los requerimientos del proyecto junto con el costo de implementarlos:

REQUERIMIENTOS ID Costo
Un cliente podr consultar las direcciones IP que tenga 01 4000000
disponibles.
El sistema debe generar las direcciones IP disponibles 02 4000000
de un cliente de acuerdo con su plan de pago.
03 5000000
Un cliente podr cambiar el nombre de su direccin IP
04 5000000
Un cliente podr eliminar el nombre de su direccin IP
El sistema deber notificar al cliente el nmero de cada 05 2000000
una de las direcciones IP que tenga adscritas.
El sistema deber verificar la existencia de una 06 2000000
direccin IP de un cliente.
El administrador del sistema podr consultar los logs 07 4000000
de la aplicacin.
Tabla 3. Estimacin de costos de los requerimientos del proyecto

120
4.2.2 Definicin de rango de costos para cada uno de los requerimientos

Elemento del WBS Valor para

EAC
Requerimiento (ID) Bajo Ms Alto
Probable
01 4000000 3500000 4000000 4500000
02 4000000 3950000 4000000 5000000
03 5000000 3800000 5000000 6000000
04 5000000 4200000 5000000 5600000
05 2000000 1450000 2000000 3100000
06 2000000 1450000 2000000 3500000
07 4000000 3400000 4000000 4500000
Tabla 4. Estimacin de tres puntos de los costos de los requerimientos del proyecto

4.2.3 Simulacin de tres puntos y discusin de resultados

Despus de llevar a cabo la simulacin Montecarlo se logr determinar que la probabilidad de

satisfacer las funcionalidades del proyecto con los costos establecidos para la implementacin de sus
requerimientos es de tan solo el 27.00%.

4.2.4 Formulacin del nivel de prioridad y comunicacin de resultados de anlisis

El Anexo C (Resultado de la cualificacin y cuantificacin de riesgos) contiene el formulario de

revisin de la estimacin final obtenida en este anlisis de riesgo en calendario junto con el de riesgo
en costo y riesgo tcnico. El formulario fue presentado al resto de los miembros del equipo del
proyecto.

5 Responder al riesgo

Los riesgos cuantificados y cualificados ahora son comunicados al equipo de proyecto. A

continuacin se presentan los planes de riesgos formulados para cada uno.

5.1 Plan de riesgo

Los siguientes son los planes formulados para los riesgos identificados de acuerdo con el resultado
del anlisis cuantitativo de riesgos caso de estudio y resultado del anlisis cualitativo de riesgos caso
estudio.

121
 Plan de riesgo en calendario: se plante el plan de riesgo que se muestra en el Anexo C (Plan de
riesgo en calendario).
Plan de riesgo en costo: se plante el plan de riesgo que se muestra en el Anexo C (Plan de
riesgo en costo).

Plan de riesgo tcnico: el plan de riesgo es una posible adaptacin de lo que se espera pudiese ser
una respuesta adecuada a este riesgo (ver Anexo C Plan de riesgo tcnico).

5.2 Base de aprendizaje de riesgos del proyecto

Se espera ampliar el grupo de planes de riesgo que contendr la base de aprendizaje del proyecto,
por ahora los planes de riesgo que sern almacenados en dicha base son los analizados a travs del
mtodo cuantitativo (riesgo en costo y riesgo en calendario).

6 Fase de control y seguimiento

Con la formulacin de los planes de riesgo surge la necesidad de comprobar si en verdad stos estn
cumpliendo con el objetivo para el cual fueron formulados. Los siguientes numerales de esta
seccin muestran cmo fueron verificadas las acciones que comprendan los planes establecidos
como respuesta.

6.1 Verificacin del plan de riesgo

6.1.1 Segn mtricas del control de costos y calendario.

Riesgo en calendario: Despus de realizar nuevamente un anlisis cuantitativo luego de seguir el

plan de riesgo establecido se observ que la probabilidad de terminacin del proyecto en la fecha
establecida para ello era menor que la probabilidad esperada: PTP < PTPE. Con lo que se concluye
que el plan de riesgo deber ser revisado y ajustado. (Anexo C Plan de riesgo en calendario ajustado).
Riesgo en costo: Despus de realizar nuevamente un anlisis cuantitativo luego de seguir el plan
de riesgo establecido se observ que el costo actual del proyecto (AC) con mayor probabilidad de
ocurrir era menor que el valor mximo aceptado por encima del valor planeado del proyecto (DVP).
Por tanto el estado del plan de riesgo fue ajustado (Anexo C Plan de riesgo en costo ajustado).

6.1.2 Segn las fuentes de riesgos

La fuente de riesgo a la cual estaba asociado el riesgo tcnico de este caso de estudio cambi a lo
largo de este proceso de gestin y fue eliminada por tanto el estado del plan de riesgo fue ajustado
(Vase Anexo C Plan de riesgo tcnico ajustado).

122
Finalizar la gestin

La gestin concluy con el almacenamiento de los formularios para su posterior revisin. Se espera,
particularmente para el caso especial de los planes de riesgo, se pueda contar con un entorno
computacional especfico que permita ordenarlos de manera que se facilite su bsqueda y a su vez se
genere la oportunidad de involucrar todos los dems pasos del modelo en un solo ambiente
computacional.

En conclusin los resultados obtenidos en este caso de estudio fueron importantes ya que
permitieron definir:

- Los puntos de funcin totales por cada uno de los requerimientos del proyecto.
- Los posibles riesgos, su probabilidad e impacto.

- La formulacin de planes de riesgo.

- La verificacin de los planes de riesgo, utilizando para ello los elementos propuestos por el
modelo.

Sin embargo, es posible que el modelo pueda ser refinado teniendo en cuenta algunos pasos, que por
causas relacionadas con la privacidad de la empresa, no fueron ejecutados y probados como debera
ser. Estos pasos son:

- Estimacin de costos y presupuesto: no se cont con la informacin histrica suficiente para

desarrollar la estimacin.
- Reuniones del tipo Wideband Delphi: a pesar de que el modelo facilita la estimacin de
riesgos para que el anlisis cualitativo se desarrolle en el menos tiempo posible, en
ocasiones algunos de los miembros del equipo del proyecto no contaban cpn el tiempo
suficiente para reunirse a realizar las estimaciones.

123
124
 Anexo C

FORMULARIOS DEL CASO DE

C ESTUDIO

125
 FORMULARIO PARA LA ESTIMACIN DEL TAMAO CON PUNTOS DE FUNCIN

Requerimientos Nmero de Componentes de Dificultad

datos

Archivos que Requerimiento 1 Requerimiento2 Requerimiento 3 Requerimiento Requerimiento 5 Requerimiento 6 Requerimiento 7 RET DET
4
gestionan la
aplicacin(ILF)
Tabla de Clientes X X X X 3 8 Bajo
Tabla de Logs X 1 5 Bajo
Archivos de Reverso X X X X 1 4 Bajo
DNS
Archivos de Zona DNS X X X X 1 4 Bajo

| Requerimientos Nmero de Componentes de Dificultad

datos

Archivos de Interfaz Requerimiento 1 Requerimiento2 Requerimiento 3 Requerimiento 4 Requerimiento 5 Requerimiento 6 Requerimiento 7 RET DET
(ELF)

Nmero de Componentes de datos Dificultad

126
 Requerimientos

Entradas Externas Requerimiento 1 Requerimiento2 Requerimiento 3 Requerimiento 4 Requerimiento 5 Requerimiento 6 Requerimiento 7 FTR DET
(EI)
Eliminar Reverso X 2 15 Alto
Cambiar Reverso X 2 15 Alto
Cliente

Nmero de Componentes de datos Dificultad

Requerimientos

Salidas Requerimiento 1 Requerimiento2 Requerimiento 3 Requerimiento 4 Requerimiento 5 Requerimiento 6 Requerimiento 7 FTR DET
Externas (EO)
Consultar Ips X 3 6 Medio
Cliente

Requerimientos Nmero de Componentes de Dificultad

datos

Consultas Externas Requerimiento 1 Requerimiento2 Requerimiento 3 Requerimiento 4 Requerimiento 5 Requerimiento 6 Requerimiento 7 FTR DET
(EQ)

127
Consultar Logs X 1 5
Consulta Existencia X X 2 4 Bajo
Ips Cliente
Consulta Numero X 2 4 Bajo
de Ips Cliente

Total de Puntos de Funcin

Requerimiento No Puntos de funcin

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

Formulario para la estimacin de costos

Factores de Escala

Valor Extra Alto Alto Nominal Bajo Muy Bajo

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

Total Factores de Escala

B 1.1624

Estimacin de Costos

129
 Experiencia del Personal Extra
Alto
Muy Alto
Tamao
Alto X X X X X X X
Requerimiento(Puntos
de Funcin) Nominal 26 24 17 17 11 11
Bajo
Requerimiento Requerimiento Requerimiento R
Factores de Escala Valor Muy 1Bajo 2 Requerimiento 3 4 Requerimiento 5 Requerimiento 6 7

Extra ExtraBajo
Alto
Facilidades Extra
Muy Alto Alto
Fiabilidad del Producto y Alto Muy Alto
Complejidad Nominal Alto
Bajo Nominal
X X X X X X X X
Muy Bajo Bajo X X X
ExtraBajo Muy Bajo X X X
Extra ExtraBajo
Planificacion Temporal Alto Extra
Muy Alto Alto
Alto Muy Alto
Reutilizacin Requerida Alto X X X
Nominal
Bajo Nominal
X XX X X X X X
Muy Bajo Bajo X X X
ExtraBajo Muy Bajo
ExtraBajo
Extra
Costo Requerimiento $ Alto 45000000 4000000 5500000 5251035 2638600 2759061 2656890
Muy Alto
Dificultad de la Alto
Plataforma
Nominal
Bajo X X X X X X X
Muy Bajo

130
 FORMULARIO DE RIESGOS IDENTIFICADOS

FORMULARIO DE RIESGOS IDENTIFICADOS

INFORMACIN DESCRIPCIN DEL RIESGO

REQUERIDA DEL RIESGO IDENTIFICADO
Nombre riesgo Dificultad de interoperabilidad entre plataformas
Fecha Nombre 20 febrero de 2007
Componente subsistema Web Service
Categora asociada Tcnica
Descripcin del riesgo Posibles problemas de compatibilidad entre tipos
de datos.
Fuente de riesgo Tecnologa no disponible
Responsabilidad Integrante del equipo de proyecto.

131
 FORMULARIO DE EVALUACIN DE RESULTADOS

RIESGO PROMEDIO DESVIACIN PROMEDIO DESVIACIN

PROBABILIDAD ESTNDAR IMPACTO ESTNDAR

Dificultad de
interoperabilidad
entre plataformas Media 0.002356 Severo 0.0518

132
 RESULTADO DE LA CUALIFICACIN Y
CUANTIFICACIN DE RIESGOS

RIESGO FUENTE CATEGORA PROBABILIDAD IMPACTO PRIORIDAD

(Opcional)
Exceder el tiempo Estimaciones Calendario 53,1 4 Alta
de duracin errneas. riesgos de
estimado del proyecto
proyecto.
Exceder el costo Estimaciones Costos riesgos de 73% 4 Alta
estimado del errneas. proyecto
proyecto
Dificultad de Tecnologa no Tcnico 60% 4 Media
interoperabilidad disponible
entre plataformas

133
 FORMULARIO DE PLAN DE RIESGO
EN CALENDARIO

FORMULARIO DE PLAN DE RIESGO

NOMBRE DEL RIESGO CATEGORA

Exceso del tiempo estimado para la Calendario- riesgo en proyecto

terminacin del proyecto
DESCRIPCIN
Se determin un nivel alto de prioridad y amenaza del riesgo en el proyecto.

Se debe tener en cuenta las mtricas relacionadas con el calendario del proyecto con el fin de
determinar si el plan de riesgo debe ser revisado en caso de que :
la probabilidad obtenida del cumplimiento del cronograma del proyecto (PTP) en la fecha
estipulada para su terminacin sea menor que la probabilidad mnima esperada (PTPE)
FUENTE TIPO PLAN DE RIESGO
Estimacin errnea. Contingencia
FECHA INICIO DE PLAN FECHA FINAL DE PLAN
Inmediato En 1 semana

ESTADO DEL PLAN DEL RIESGO RESPONSABLE

Abierto

ACCIONES A LLEVAR A CABO

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

FORMULARIO DE PLAN DE RIESGO

EN COSTO

134
 FORMULARIO DE PLAN DE RIESGO

NOMBRE DEL RIESGO CATEGORA

Exceso del costo total estimado para el Costos- riesgo en proyecto

cumplimiento de los requerimientos del
proyecto.
DESCRIPCIN
Se determin un nivel alto de prioridad y amenaza del riesgo en el proyecto.

Se deben revisar las mtricas relacionadas con la gestin de costos del proyecto con el fin de
determinar si el plan de riesgo debe ser revisado en caso de que el costo del proyecto actual (AC) con
mayor probabilidad de ocurrir sobrepase el valor mximo aceptado por encima del valor planeado de
costo del proyecto (DVP).
FUENTE TIPO PLAN DE RIESGO
Estimacin errnea. Contingencia
FECHA INICIO DE PLAN FECHA FINAL DE PLAN
Inmediato En 1 semana

ESTADO DEL PLAN DEL RIESGO RESPONSABLE

Abierto

ACCIONES A LLEVAR A CABO

PLAN DE CONTINGENCIA:
ACCIONES PREVENTIVAS: Reevaluar el proceso de estimacin y
planeacin del costo del proyecto.

135
 DECISIONES TOMADAS: Convocar a reunin a los miembros del equipo y
re-estimar el costo total del proyecto teniendo en cuenta los requerimientos funcionales que ste debe
cumplir.

136
 PLAN DE RIESGO TCNICO

FORMULARIO DE PLAN DE RIESGO

NOMBRE DEL RIESGO CATEGORA

Dificultad de interoperabilidad entre plataformas Tcnica

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

FUENTE TIPO PLAN DE RIESGO

Tecnologa no disponible Contingencia
FECHA INICIO DE PLAN FECHA FINAL DE PLAN
inmediato

ESTADO DEL PLAN DEL RIESGO RESPONSABLE

Abierto

ACCIONES A LLEVAR A CABO

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

PLAN DE RIESGO EN CALENDARIO AJUSTADO

FORMULARIO DE PLAN DE RIESGO

NOMBRE DEL RIESGO CATEGORA

Exceso del tiempo estimado para la terminacin Calendario - riesgo en proyecto

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

FUENTE TIPO PLAN DE RIESGO

Estimacin errnea. Contingencia
FECHA INICIO DE PLAN FECHA FINAL DE PLAN
Inmediato En 1 semana

ESTADO DEL PLAN DEL RIESGO RESPONSABLE

Re-abierto

138
 ACCIONES A LLEVAR A CABO
PLAN DE CONTINGENCIA: Pendiente por formular

FORMULARIO DE PLAN DE RIESGO

NOMBRE DEL RIESGO CATEGORA

Exceso del costo total estimado para el Costos- riesgo en proyecto

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

FUENTE TIPO PLAN DE RIESGO

Estimacin errnea. Contingencia
FECHA INICIO DE PLAN FECHA FINAL DE PLAN

ESTADO DEL PLAN DEL RIESGO RESPONSABLE

CERRADO

ACCIONES A LLEVAR A CABO

PLAN DE RIESGO EN COSTO AJUSTADO

139
 PLAN DE RIESGO TCNICO AJUSTADO

NOMBRE DEL RIESGO CATEGORA

Dificultad de interoperabilidad entre Tcnica

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

FUENTE TIPO PLAN DE RIESGO

Estimacin errnea. Contingencia
FECHA INICIO DE PLAN FECHA FINAL DE PLAN

ESTADO DEL PLAN DEL RIESGO RESPONSABLE

CERRADO

ACCIONES A LLEVAR A CABO

140
 Anexo D

ANEXO D

ENCUESTA SOBRE GESTIN DE PROYECTOS

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

SI ___

NO ___

- En caso de utilizarlo por favor indique cual:

a. Basadas en conteo de lneas de cdigo

b. Basada en estadsticas
c. Puntos de funcin
d. Lgica difusa
e. Otro?, especifique por favor, cul y por qu?:
________________________________________________________

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

______________________________________________________________________

2. Su empresa utiliza algn tipo de estimacin de costos?

SI ___

NO ___

- En caso de utilizarlo por favor indique cual:

a. Costos por analoga ____
b. Juicio experto ____
c. Precio a ganar ____
d. Botton UP ____
e. Top Down ____
f. COCOMO ____

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

__________________________________________________________________

3. Su empresa realiza estimacin de riesgos?

SI ___

NO ___

141
En caso de realizarla indique qu mtodo utiliza:

a. Cuantitativo___
b. Cualitativo___
c. Otro, cul?: __________________________________________________

4. Su empresa realiza algn tipo de gestin de riesgos?:

SI ___

NO ___

- En caso de realizarla indique en cul fuente se apoya para realizar este proceso:

a. IEE___
b. SEI___
c. PMBOOK
d. Otro, cul?: __________________________________________________

5. En su opinin, beneficiara a su empresa la propuesta de una nica metodologa que integrar

la gestin de costos y riesgos?.

SI ___

NO ___

Por qu?:___________________________________________________________

6. Sobre qu cree hay mayor carencia de conocimientos en su empresa?

a. Gestin de riesgos ____

b. Estimacin y gestin de costos ____
c. Gestin de riesgos ____
d. Estimacin de mtricas ____
e. Otro? Cual:___________________________________________________

A qu causa le atribuye esta carencia?:______________________________________

Muchas gracias!!!!

142
 Anexo E

ES ESPECIFICACIN DE LOS REQUERIMIENTOS

E DEL PROYECTO

143
Especificacin de Requerimientos

Direcciones IP e Internet dedicado flexible

10-06-2007

1.0

Sandra Patricia Forigua

Oscar Ballesteros

144
 Tabla de Contenido

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

145
El Propsito del Proyecto

Descripcin de Negocio del Cliente y Motivacin del Proyecto.

Este proyecto fue desarrollado para un proveedor de servicios de Internet, el cliente se

especializa en prestar sus servicios a todo tipo de empresas, adems de proveerles
diversos servicios como correo organizacional, este proyecto est enfocada a ofrecer mas
servicios a los clientes de este isp en este caso se prestan servicios de informacin acerca
de las direcciones IP de los clientes.

Objetivos del Proyecto.

Como se mencion en la seccin anterior con este proyecto se quieren aumentar los
servicios que la organizacin ofrece a sus clientes, en este caso se quieren ofrecer
servicios a los clientes para que administren la informacin relacionada a sus direcciones
ip.

Stakeholders

El Cliente

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

El Usuario

El Usuario es el mismo que el Cliente.

Usuarios del Producto

Lista de Usuarios.

Bsicamente el usuario del producto desarrollado es el portal empresarial de la compaa, este

portal se encarga de gestionar los servicios que se les ofrecen a los diferentes clientes de la
compaa.

Restricciones Obligatorias

Restricciones en la solucin.

El sistema desarrollado debe implantar como interfaz para ser usado invocando servicios web,
esto debido a que la organizacin para la que se desarrolla el producto tiene sistemas basados
en Linux y otros basados en Windows, lo que hace necesario la implantacin se servicios web
para asegurar la interoperabilidad de todos los sistemas de la organizacin.

146
 Este sistema debe interactuar con el DNS de la compaa, en el cual se hacen las consultas y
modificaciones de la informacin de las direcciones ip de los clientes, este DNS se encuentra
montado sobre Linux.

Ambiente de Implementacin

El sistema debe ser implementado sobre Linux y debe exponer servicios web al portal de la
organizacin, a su vez el sistema debe interactuar con el DNS de la compaa y la base de
datos de clientes de la compaa.

Software pre-desarrollado

El sistema utiliza varios paquetes de software que colaboran con el desempeo del software, a
continuacin se listan estos paquetes.

Tomcat: Este es un motor de servlets sobre el cual se mont la aplicacin web que maneja
los servicios web expuestos.
Axis: Este paquete mantiene una implementacin de web services.
Hibernate: este paquete facilita la interaccin con bases de datos relacionales facilitando su
manejo.

Hechos Relevantes y asumpciones

Hechos

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

Asunciones

Las siguientes son las asunciones tomadas en el desarrollo de este proyecto.

Los archivos de configuracin del DNS de la compaa, estn disponibles en la

mquina en la cual se instalar el software desarrollado.
La base de datos de clientes esta disponible para su utilizacin desde la mquina en
la que se instalar el software.

El alcance del Trabajo

La Situacin Actual

El manejo de la informacin de las direcciones IP pertenecientes a los clientes de la compaa,

se realizaba por el personal de la compaa dependiendo de las necesidades de los clientes.
Este proceso es demorado para los clientes y aumenta el trabajo para el personal de la
compaa.

147
 Con este proyecto se busca automatizar este proceso, adems mejorando el servicio que se les
presta a los clientes de la compaa

El Contexto del Trabajo

El sistema debe interactuar con la infraestructura actual de la compaa por la parte de

ingeniera de la compaa, en esta rea toda la infraestructura se encuentra implementada en
ambientes Linux, y la informacin de los diversos clientes se encuentra distribuida en
diferentes servidores.

Por otro lado el portal empresarial de la compaa se encuentra montado sobre plataforma
Windows lo cual hace necesario que expongan servicios web para que las plataformas Linux y
Windows puedan interactuar para poder ofrecer los servicios a los clientes de la compaa.

El Alcance del Producto

La frontera del Producto.

A continuacin se mostrar el diagrama de casos de uso en donde se encuentran las

funcionalidades que se implementaron para este proyecto y el lmite que se estableci en el
desarrollo del mismo.

Lista de Casos de uso del Producto.

En esta seccin se listan los casos de uso implementados para el proyecto, y una descripcin de
los mismos.

1. Consulta Direcciones Ip: esta funcionalidad permite obtener las direcciones Ip de

un cliente y los nombres asociados a estas direcciones.
2. Consulta Reverso Ip: este caso de uso permite consultar el nombre asociado en el
DNS de la compaa de una direccin ip.

148
 3. Modificar Reverso IP: Esta funcionalidad permite a un cliente cambiar el nombre
asociado en le DNS de la compaa de una de las direcciones ip del cliente.
4. Nmero de Ips Cliente: esta funcionalidad consulta el nmero de direcciones IP
asignadas a un cliente.
5. Cliente tiene IP: este caso de uso permite consultar si un cliente especfico tiene
direcciones IP asignadas.
6. Borrar Reveso: este caso de uso permite eliminar el nombre asignada a la direccin
ip de un cliente en el DNS de la compaa.
7. Consultar Logs: este caso de uso permite consultar los logs generados por la
aplicacin.

Requerimientos Funcionales

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

1.Un cliente podr consultar las direcciones IP que tenga disponibles.

Identificador del Requerimiento: 1

Descripcin: Este servicio permitir a los clientes de la compaa consultar las direcciones ip
que tiene asignadas y los nombres asignados a estas direcciones en el DNS de la compaa.

Justificacin: Este requerimiento permite aumentar los servicios de informacin prestados a los
clientes de la compaa y disminuye el soporte solicitado a la compaa.

Solicitante: Gerente del Producto.

Criterio de aceptacin: El requerimiento ser aceptado si la implementacin del mismo obtiene

la informacin deseada acerca de las direcciones IP de los clientes de la compaa.

Satisfaccin del Cliente: 4 Insatisfaccin del Cliente: 5

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

Identificador del Requerimiento: 2

Descripcin: Con la implementacin de este requerimiento se quiere, que los clientes de la

compaa puedan consultar el numero de direcciones ip que pueden utilizar dependiendo del
plan comprado con la compaa

Justificacin: La implantacin de este requerimiento permitir a los clientes conocer

automticamente conocer que tantas direcciones ip asignadas a usado el nmero de direcciones
IP disponibles, permitiendo mejorar el control que tiene el cliente por su infraestructura de red.

149
Solicitante: Gerente del Producto.

Criterio de aceptacin: El requerimiento se considera aceptado si proporciona en todo

momento la informacin almacenada en los servidores de la compaa de manera correcta, para
todos los clientes de la organizacin.

Satisfaccin del Cliente: 4 Insatisfaccin del Cliente: 5

3. Un cliente podr cambiar el nombre de su direccin IP

Identificador del Requerimiento: 3

Descripcin: Este requerimiento busca permitir que los clientes de la compaa cambien los
nombres registrados en el DNS de la compaa de las direcciones ip asignadas a cada cliente.

Justificacin: La implementacin de este requerimiento permitir disminuir el soporte

solicitado por los clientes de la compaa para realizar estos cambios, adems de dar ms
control sobre la infraestructura de red a cada uno de los clientes de la compaa.

Solicitante: Gerente del Producto.

Criterio de aceptacin: El requerimiento se clasificar como implementado, cuando se realice

la tarea asociada a este requerimiento de forma correcta.

Satisfaccin del Cliente: 4 Insatisfaccin del Cliente: 5

4. Un cliente podr eliminar el nombre de sus direcciones IP.

Identificador del Requerimiento: 4

Descripcin: La implementacin de este requerimiento busca liberar los nombres asociados a

las direcciones ip, cuando estas direcciones ya no se encuentren en uso.

Justificacin: La implantacin de este requerimiento permitir facilitar la liberacin de las

direcciones ip asignadas a un cliente cuando este ya no desee usar una direccin.

Solicitante: Gerente del Producto.

Criterio de aceptacin: El requerimiento se considera implementado en cuando el sistema

permite eliminar si errores el nombre de una direccin IP.
Satisfaccin del Cliente: 4 Insatisfaccin del Cliente: 5

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

Identificador del Requerimiento: 5

Descripcin: El desarrollo de este requerimiento permitir informar al cliente del nmero de

direcciones IP que tiene actualmente asignadas y en uso.

Justificacin: El requerimiento permite mejorar los servicios de informacin prestados a los

clientes de la compaa mejorar los servicios ofrecidos.

150
Solicitante: Gerente del Producto.

Criterio de aceptacin: El requerimiento se considera aceptado, cuando siempre que se use el

servicio retorne informacin valida del cliente.

Satisfaccin del Cliente: 4 Insatisfaccin del Cliente: 5

6. El sistema deber verificar la existencia de una direccin IP de un cliente.

Identificador del Requerimiento: 6

Descripcin: Este servicio es usado para verificar que las operaciones que requieren
modificacin a informacin de una direccin IP se realizasen conociendo

Justificacin: Este servicio permite disminuir los errores al modificar informacin del DNS
compaa.

Solicitante: Gerente del Producto.

Criterio de aceptacin: El requerimiento se considerara aceptado cuando la informacin

consultada este acorde con la realidad de los clientes de la compaa.

Satisfaccin del Cliente: 4 Insatisfaccin del Cliente: 5

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

Identificador del Requerimiento: 7

Descripcin: la aplicacin desarrollada produce logs para determinar el estado del sistema, y
detectar errores en la misma. Este servicio fue implementado para proporcionar informacin de
la aplicacin al administrador del sistema.

Justificacin: La inclusin de este servicio facilitara el soporte que se le da a la aplicacin y en

caso de fallo facilitar la determinacin de la causa del mismo.

Solicitante: Gerente del Producto.

Criterio de aceptacin: este requerimiento ser aceptado si la consulta a estos logs proporciona
informacin relevante del estado del proyecto.

Satisfaccin del Cliente: 3 Insatisfaccin del Cliente: 3

151