Beruflich Dokumente
Kultur Dokumente
FACULTAD DE INGENIERIA
Decano del Medio Universitario Facultad de Ingeniera: Padre Sergio Bernal Restrepo
S.J.
______________________________________________________
______________________________________________________
______________________________________________________
______________________________________________________
______________________________________________________
__________________________________________
_________________________________________
_________________________________________
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.
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
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].
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].
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.
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.
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.
16
1. ESTADO DEL ARTE
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.
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.
18
d. Aplicar el mtodo repetidamente para los diferentes niveles de detalle, y as obtener una
estimacin ms precisa.
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 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].
20
- Con cada uno de estos elementos se determina qu tan grande va a ser el sistema a
desarrollar.
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:
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:
- 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.
- 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.
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.
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.
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].
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.
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.
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].
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:
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
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.
- 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.
30
R5 Posible Crtico Alto
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).
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
- 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
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.
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.
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.
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
34
b. Simulacin de tres puntos
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]):
c. Resultados de la simulacin
35
1.3.2.3 Planificacin del riesgo
- 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.
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.
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.
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.
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.
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.
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.
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%).
- 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
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
Desempeo en el presupuesto de
proyectos de TI
Proyectos abandonados
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:
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?
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
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.
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.
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.
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:
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.
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.
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.
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.
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:
La estimacin muy
La estimacin se realiza
Se ajusta el precio del seguramente est mal, y el
de una manera muy
proyecto, para mejorar la costo real estar muy
Precio a Ganar sencilla.
propuesta ms econmica alejado de la realidad.
realizada, con el fin de
Es muy probable que se
ganar el proyecto. Puede ocasionar que el
gane el proyecto.
proyecto lleve a perdidas.
MTODOS ALGORTMICOS
Predisposicin por parte
Involucra varios factores
del equipo de gestin ante
Modelo emprico para la que inciden en el costo
la utilizacin de frmulas
estimacin del esfuerzo y del proyecto.
matemticas.
costo del desarrollo de un
sistema de software, se No requiere en principio
Es un proceso extenso para
COCOMO basa en el uso de el uso de datos de
completar la estimacin
multiplicadores de proyectos anteriores.
esfuerzo, para realizar una
Algunos factores son algo
estimacin del esfuerzo y Permite su utilizacin a
complicados de
costo lo largo de todo el
determinar.
proyecto.
Predisposicin por parte
Se basa en la distribucin
del equipo de gestin ante
de poder hombre, se usa la
Usa factores del proyecto la utilizacin de frmulas
ecuacin de software, en
y producto, para realizar matemticas.
donde se relaciona, el
SLIM la estimacin, estos
tiempo de entrega, factores
factores inciden en el Es un proceso algo largo,
ambientales, en los cuales
costo del proyecto. para completar la
se refleja la capacidad de
estimacin
desarrollo de la compaa
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.
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.
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.
50
2.4.2 Mtodo escogido 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 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.
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.
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.
52
muy valiosa, la cual permite a los gerentes de proyecto tener una visin clara acerca del
proyecto.
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
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
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.
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
Comunicacin
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.
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.
Fuentes de
riesgos
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.
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)
Riesgos tcnicos
Riesgos de
negocio
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.
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.
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.
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
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
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.
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
- 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.
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
Comprende la formulacin de planes de accin (planes de riesgo) para responder a los riesgos
en alta prioridad y otros analizados en la fase de cuantificacin y cualificacin. Este modelo
puede emplear cualquiera de las formas de expuestas en la fase de planificacin del riesgo con
el fin de crear planes que mitiguen el impacto del riesgo.
Plan de riesgo
De acuerdo con lo expuesto en la fase de planificacin del estado del arte los planes de riesgo
son estrategias que involucran acciones y otros conceptos para hacer frente al riesgo. De
acuerdo con la informacin recolectada acerca de los elementos de un plan de riesgos el modelo
define la siguiente lista para su propuesta:
63
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.
RIESGOS
PRIORIDAD BAJA
Formulario de plan
Formulario de plan
de riesgo de la BASE DE APRENDIZAJE
de riesgo de la
metodologa DE RIESGOS
metodologa
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:
FUENTES DE
RIESGOS
VERIFICACIN Y CONTROL
DEL PLAN DE RIESGO ESTADO PLAN DE
RIESGO
AJUSTES Y
REVISIN DE MTRICAS
PLANES SI
APLICA
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.
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
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
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
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.
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.
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.
La figura 26 muestra las entradas y salidas que involucra el proceso para la estimacin del
tamao del software.
Informacin de
Informacin
entrada de
entrada
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.
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.
Tamao del software a implementar para los requerimientos planteados: Este resultado
representa la medicin en puntos de funcin del tamao de cada uno de los requerimientos que
componen el proyecto al cual se le est aplicando el modelo.
Como ayuda para la aplicacin del modelo de estimacin del tamao se dise el Formulario
para la estimacin del tamao con Puntos de Funcin (ver Anexo A) sobre el cual se diligencia
la informacin del tamao de cada uno de los requerimientos del proyecto.
Ahora que ya se han mencionado las entradas y salidas del modelo para la estimacin del
tamao, se 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
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.
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.
- 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.
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.
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.
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:
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
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.
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.
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.
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.
Tamao de los
Tamao de los
requerimientos
requerimientos
Presupuesto del
Presupuesto del
proyecto
proyecto
Indicadores de
Indicadores de
Control del presupuesto gestin
Control del presupuesto gestin
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
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:
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:
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 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.
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:
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.
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.
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.
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
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
80
Figura 28. Diagrama de flujo de la metodologa de gestin de riesgos
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.
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
83
un anlisis cualitativo mientras que los de proyecto (calendario y costos) se analizaran
cuantitativamente.
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.
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
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.
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.
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.
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.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).
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)
Riesgos
cualificados y
cuantificados
Plan de riesgo
Riesgos
con alta
prioridad
FIN
BASE DE
APRENDIZAJE
DE RIESGOS
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).
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
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.
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):
DVP: desviacin
mxima aceptada por
Mtrica: AC>DVP
encima del VP
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.
90
Mtrica: PTP< PTPE
Cronograma: X% de
probabilidad de xito
en la fecha de
terminacin.
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.
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.
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.
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.
93
BIBLIOGRAFA
[Baker, 2003]. The complete idiot's guide to project management, Project Management, 2003.
[Boehm, 1990] Boehm, B. Software Risk Management: Principles and Practices. IEEE
Software (January 1990)
[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-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.
[Longstreet, 2004]. Function Points Analysis Training Course, Longstreet Consulting Inc, 2004.
[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.
[Thayer, 2003]. Software Engineering Project Management, IEEE Computer Society, 2003.
95
ANEXOS
B CASO DE ESTUDIO
96
Anexo A
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
99
Nmero de Dificultad
Requerimientos componentes de datos
Consultas Externas (EQ) Requerimiento 1 Requerimiento2 Requerimiento 3 Requerimienton FTR DET
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
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
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
104
FORMULARIO DE LA SESIN INTRODUCTORIA
105
FORMULARIO DE LA SESIN DE ESTIMACIN
INDIVIDUAL
JUSTIFICACIN
RIESGO DESCRIPCIN CATEGORA
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
Fecha evaluacin
107
RIESGO PROMEDIO DESVIACIN PROMEDIO DESVIACIN MODA
PROBABILIDAD ESTNDAR MODA IMPACTO ESTNDAR
108
FORMULARIO DE REVISIN DE LA ESTIMACIN
FINAL
Fecha:
RIESGO FUENTE CATEGORA PRIORIDAD
(Opcional)
109
FORMULARIO PARA EL ANLISIS CUANTITATIVO
DE RIESGO EN CALENDARIO
110
FORMULARIO PARA EL ANLISIS CUANTITATIVO
DE RIESGO EN COSTOS
Nombre: Fecha:
111
FORMULARIO DE PLAN DE RIESGO
DESCRIPCIN
112
ESTADO DEL PLAN DEL RIESGO RESPONSABLE
Anexo B
B CASO DE ESTUDIO
113
Descripcin del proyecto y definicin de los requerimientos funcionales
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.
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.
Los usuarios de este proyecto son: el portal empresarial de la compaa y otros sistemas que
consultan las Ips de los clientes.
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.
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
El dominio de las fuentes as como de las categoras planteadas por el modelo fueron acogidas por el
gestor del proyecto.
117
4. Cuantificacin y priorizacin
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.
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.
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.
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.
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
5 Responder al 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).
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).
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.
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 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:
123
124
Anexo C
125
FORMULARIO PARA LA ESTIMACIN DEL TAMAO CON PUNTOS DE FUNCIN
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
Archivos de Interfaz Requerimiento 1 Requerimiento2 Requerimiento 3 Requerimiento 4 Requerimiento 5 Requerimiento 6 Requerimiento 7 RET DET
(ELF)
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
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
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
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
Factores de Escala
128
Factores de Escala
Precedencia X
Flexibilidad de desarrollo X
Arquitectura/ Resolucin de Riesgos X
Cohesin del Equipo X
Madurez del Proceso X
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
131
FORMULARIO DE EVALUACIN DE RESULTADOS
Dificultad de
interoperabilidad
entre plataformas Media 0.002356 Severo 0.0518
132
RESULTADO DE LA CUALIFICACIN Y
CUANTIFICACIN DE RIESGOS
133
FORMULARIO DE PLAN DE RIESGO
EN CALENDARIO
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
134
FORMULARIO DE PLAN DE RIESGO
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
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
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.
138
ACCIONES A LLEVAR A CABO
PLAN DE CONTINGENCIA: Pendiente por formular
139
PLAN DE RIESGO TCNICO AJUSTADO
140
Anexo D
ANEXO D
SI ___
NO ___
SI ___
NO ___
SI ___
NO ___
141
En caso de realizarla indique qu mtodo utiliza:
a. Cuantitativo___
b. Cualitativo___
c. Otro, cul?: __________________________________________________
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?: __________________________________________________
SI ___
NO ___
Por qu?:___________________________________________________________
Muchas gracias!!!!
142
Anexo E
143
Especificacin de Requerimientos
10-06-2007
1.0
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
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
Lista de Usuarios.
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
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
La Situacin Actual
147
Con este proyecto se busca automatizar este proceso, adems mejorando el servicio que se les
presta a los clientes de la compaa
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.
En esta seccin se listan los casos de uso implementados para el proyecto, y una descripcin de
los mismos.
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.
Justificacin: Este requerimiento permite aumentar los servicios de informacin prestados a los
clientes de la compaa y disminuye el soporte solicitado a la compaa.
2. El sistema debe generar las direcciones IP disponibles de un cliente de acuerdo con su plan
de pago.
149
Solicitante: Gerente del Producto.
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.
5. El sistema deber notificar al cliente el nmero de las direcciones IP que tenga adscritas.
150
Solicitante: Gerente del Producto.
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.
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.
Criterio de aceptacin: este requerimiento ser aceptado si la consulta a estos logs proporciona
informacin relevante del estado del proyecto.
151