Está en la página 1de 3

MODELO EPEI PARA ESTIMACION DE PROYECTOS DE SOFTWARE

1.- A pesar de que ya conocemos el problema que implica la falta de información


en etapas tempranas de los proyectos (la mayoría de las variables son subjetivas,
no hay mucho que contar) y que sabemos que el método más utilizado porque
mejor se acopla a esa realidad es el “juicio de experto”
2.- También tiene que ver con que la gente cree que el software es más intelectual
que físico y por esto no se puede medir.
3.- Difiero con esto porque si no tenemos qué medir, entonces no podemos hacer
ingeniería, lo que hacemos es arte. Y el problema con hacer arte es que los
resultados dependen por completo de tener buenos artistas y no es algo
sustentable.
4.- La IEEE define ingeniería de software como; “La aplicación de una estrategia
sistemática, disciplinada y cuantificable, al desarrollo, operación y mantenimiento
de software; es decir, la aplicación de ingeniería al software”.
5.- Entonces, para hacer ingeniería necesitamos medir. Si la mayoría de las
variables que tenemos son cualitativas entonces necesitamos un mecanismo para
medir este tipo de variables.
6.- Esta situación ha sido detectada y estudiada por varias personas, algunas de
las cuales han encontrado en la Lógica Difusa un apoyo para trabajar mejor con
estas variables [2,3], ya que estos modelos son diseñados típicamente sobre la
base de reconocidos expertos que identifican e intuitivamente cuantifican las
entradas con valores lingüísticos para inferir la variable dependiente.
7.- Se han realizado a nivel científico varios estudios que demuestran que en
comparaciones contra los métodos tradicionales utilizados para generar modelos
de estimación como regresión lineal, redes neuronales, etc., los basados en lógica
difusa han presentado ventajas en las capacidades de modelado.
8.- Existe un modelo que cubre estos requisitos además de un estudio formal muy
extenso, es mexicano y se denomina Estimación de Proyectos en Entornos de
Incertidumbre (EPEI), el problema del proyecto descrito en el número anterior se
evaluó con este modelo y se presentan a continuación el proceso y los resultados.
9.- Configuración del Modelo. Se reunió a los participantes en la estimación
original del proyecto. La configuración y generación de siete escenarios distintos
llevó aproximadamente 2 horas.
10.- Variables de Entrada. A estas personas se les pidió que identificaran las
variables que afectaron mayormente al resultado del proyecto. Las variables
identificadas fueron: Experiencia en tecnologías, conocimiento del negocio,
disponibilidad de recursos, nivel de liderazgo.
11.- Variable de Salida. Este enfoque del modelo es muy relevante ya que trabaja
en función de precisión de significado, esto es que se entiende que un proyecto
conforme deja de ser Pequeño, empieza a ser Promedio, y conforme deja de ser
Promedio empieza a ser Grande, de hecho, en algún momento puede pertenecer
a dos valores al mismo tiempo, es decir, un proyecto pareciera ser entre Promedio
y Grande. Este enfoque de manejo de variables sin duda refleja de mejor manera
la realidad que el manejo de rangos.
11.- Reglas de Inferencia. Al grupo de expertos se les pidió que definieran la
relación de las distintas variables de entrada que definieron en función de la
variable de salida del proyecto en base a reglas “If…then”, generando con esto un
motor de inferencia propio para la organización ya que representa el conocimiento
de sus expertos.
12.- Resultados obtenidos. A los expertos que participaron en la estimación
original y en la configuración del modelo se les pidió que evaluaran las variables
de entrada en el rango definido (de 0 a 5). Con estos valores se generaron
distintos escenarios, uno para cada participante, se obtuvo el promedio de los
valores asignados a cada variable y se obtuvo un escenario promedio, ya con los
datos se obtuvo un escenario PERT ([O-P]/6).
ESTIMACION DE PROYECTOS DE SOFTWARE: UN PROBLEMA, UNA
SOLUCION.
1.- Hoy en día el factor del tiempo de duración de un proyecto es crucial y
estratégico ya que se juega en una línea muy delgada que puede generar
pérdidas o ganancias. En este sentido los proyectos relacionados con el manejo
de información (Software: obtención, explotación) cobran una gran relevancia.
2.- La mayoría de las veces cuando se tiene que decidir la factibilidad de un
proyecto de SW en etapas tempranas, la información con la que se cuenta es muy
poca o es ambigua, esto sucede debido a que la adquisición de la información
para un proyecto de SW es paulatina y en las primeras etapas es escasa y muy
susceptible a cambios.
3.- La manera más utilizada, más rápida, menos costosa y la más utilizada a nivel
mundial para estimar esfuerzo, duración, costo de un proyecto de este tipo sea la
utilización de la experiencia de los empleados de una organización, mejor
conocida como “Juicio de Experto”.
4.- Esto no siempre es una buena idea ya que esta manera de realizar
estimaciones presenta algunos problemas como que le pertenece al experto y no
a la organización, está influenciada por el contexto o circunstancias en las que
esté el experto al realizar los juicios, además los expertos hacen inferencias a
partir de variables de entrada con valores subjetivos (complejidad, experiencia del
equipo, experiencia en la herramienta, etc.) no determinísticos y por si fuera poco,
no se puede replicar sistemáticamente, lo que genera dependencia de los
expertos.
5.-Para clarificar esta situación se describe a continuación un ejemplo de un
proyecto específico el cuál se estimó en tiempo y esfuerzo de manera empírica, es
decir utilizando juicio de experto, y las herramientas que tenía la organización a su
alcance.
6.- La definición del proyecto que proporcionó el cliente en primera instancia fue la
siguiente: “Desarrollar solución técnica que permita brindar el servicio de tercero
confiable para apoyo n las operaciones de comercio exterior”.
7.- Las herramientas con las que contaba la organización que realizó este
proyecto eran la experiencia o sus expertos (herramientas empíricas, hojas de
Excel generadas a partir de la experiencia, ejercicios históricos de FP (IFPUG) y
Use Case Points (UCP) y una clasificación en rangos de esfuerzo históricos por
tipo de proyecto específica para la organización.
8.- El proyecto que se estimó originalmente en 5 meses por un grupo de expertos
de la organización, terminó en realidad en 13.25 meses lo que implicó un retraso
de 165%.
9.- Se puede observar claramente que el realizar malas estimaciones tiene una
repercusión directa en la economía de las empresas ya que este tipo de
desfasamientos, que son comunes en la industria [1] implica que alguien tiene que
absorber el gasto, ya sea el cliente o el proveedor, implicando negociaciones por
demás complejas y desgastantes.
REDUCE LA COMPLEJIDAD DE TUS PROYECTOS DE SOFTWARE
1.- La disciplina de dirección de proyectos es compleja. Involucra nueve áreas de
conocimiento que conforman cinco grupos de procesos.
2.- El gerente de proyecto tiene que entender los principios y dinámicas que se dan al
trabajar en grupo, el ciclo de vida de las expectativas y cómo administrarlo
adecuadamente; además de entender los aspectos técnicos del proyecto y del negocio,
también debe tener excelentes habilidades interpersonales, particularmente la de ser un
buen comunicador.
2.- Evidentemente para una sola persona tener un buen nivel de dominio de todos esos
temas es muy difícil.

También podría gustarte