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.