Francisco Valdes Souto

¿Cómo Estimar Cuando No Hay Requerimientos Detallados?

fvaldes25 — Wed, 22 Apr 2015 22:24:04 +0000

¿Cómo Estimar Cuando No Hay Requerimientos Detallados?

Evento

SG Conferencia y Expo 2015

fvaldes25 Wed, 04/22/2015 - 17:24

Conferencista(s)

Francisco Valdes Souto

Estimacion requerimientos vagos from Software Guru

Si bien la estimación es básica para el éxito de los proyectos, la realidad es que cuando se realizan las estimaciones se cuenta con muy poca información, o no tienes mucho tiempo para hacerte llegar información detallada que te permita estimar correctamente.

En la plática se describirán algunas técnicas para estimar en circunstancias similares a las previamente descritas, así como un caso de estudio que muestra un ejemplo en un proyecto real en dónde se utilizan algunas de estas técnicas, que permiten lograr una estimación formal y confiable.

Acerca del conferencista

Francisco Valdés Souto es Dr. en Ingeniería de Software, especialista en dimensionamiento y estimación de proyectos de software, así como evaluación de factibilidad y desempeño de proyectos. Es el primer mexicano certificado en el estándar de medición de tamaño funcional de segunda generación COSMIC ISO/IEC 19761 (CCFL), International Advisory Council para México ante el Common Software Measurement International Consortium (COSMIC), Representante en el Work Group 12 del ISO/IEC Joint Technical Committee 1, Sub-Committee 7 (Software Engineering) México.

Importancia de la Medición del Tamaño Funcional

sg — Sun, 20 Apr 2014 05:56:27 +0000

Importancia de la Medición del Tamaño Funcional sg Sun, 04/20/2014 - 00:56

Publicado en

SG #43

Gestión de Proyectos

Autor

Francisco Valdes Souto

Muchas veces en la literatura para desarrollo de software se ha hecho la analogía acerca de una construcción de una casa con la construcción de un software. En esta analogía normalmente, los distintos planos de la casa son los distintos modelos de diseño empleados para la construcción del software.

¿Qué pasaría si en los planos no vinieran las medidas?, es muy probable que la construcción de la casa fuera un caos, por que no serían del tamaño correcto las ventanas, la loza, las puertas etc. Es fácil ver que no se podría construir una casa sin conocer las medidas del tamaño de cada uno de sus elementos. Más aún, en función de estas medidas se puede estimar la duración de la obra, el costo, se puede tener un control de las dimensiones de la casa, comparar contra otras construcciones, etc.

¿Se puede desarrollar el software sin tener medidas de tamaño? La respuesta es sí, en la mayoría de los casos así se hace. Sin embargo, esto fomenta que el desarrollo de software sea un arte y no un proceso ingenieril, con resultados nada prometedores (The Standish Group International, 2011)( Emam, 2008).

“De acuerdo al testimonio del Goverment Accountability Office del pasado septiempre, si se establecieran con más realismo las líneas base de los requerimientos, costo, calendario y riesgos durante las fases de planeación de los proyectos, cerca de la mitad serían cancelados o rebasarían los presupuestos de los programas de TI. Esto podría ahorrar $5.5 billones anuales de acuerdo con un estudio realizado por Price Systems LLC, una empresa de software y consultoría de Mount Laural, N.J., USA. El estudio considera 104 ejecutivos de Gobierno de TI.” (PMI, 2007)

Muchas personas involucradas en la industria del software tienen una idea errónea acerca de la medición del mismo, consideran que no se puede medir ya que es algo intangible, que es algo intelectual por lo que medirlo sería muy complejo. Esto no es cierto, por ejemplo, la velocidad de la luz la medimos y no precisamente de manera física, se mide con un modelo adecuado y generalmente aceptado.

Entonces, ¿se puede medir el software? Sí, de hecho hoy en día la única medición estándar es el tamaño funcional (Functional Size Measurement, FSM, ISO/IEC 14143). Si cada organización midiera el software de manera distinta (por módulos, LOC, CU, etc.) no se podrían hacer comparaciones; esto sería el equivalente a que las medidas utilizadas en cada plano fueran diferentes ¿serviría?, por supuesto que no.

El FSM es muy importante, ya que es el único estándar de medición de software existente, es generalmente aceptado y nos habilita para realizar la parte ingenieril del desarrollo de software. A continuación vamos a mencionar algunos de los usos más relevantes que se le pueden dar a una medición de tamaño funcional adecuada.

Estimación de proyectos

La estimación de proyectos es muy importante para poder tener una buena administración de recursos a lo largo del proyecto. Hay que recordar que en cualquier proceso de producción de algo (en este caso el software) existe una relación entre la cantidad producida y el costo/esfuerzo requerido para hacerlo.

Si se tiene una buena medición de tamaño funcional, es posible generar modelos de estimación algorítmicos que permitan hacer estimaciones del esfuerzo o costo de los proyectos. Si las mediciones funcionales no son confiables, los modelos de estimación no los séran.

Medición del desempeño del proyecto

En cualquier industria la habilidad para medir el desempeño es crítica para poder mejorarlo. Por ejemplo, cuántas veces hemos escuchado en el software temas relacionados a la productividad.

La productividad en el software como en cualquier otra industria es muy importante, todos quisiéramos que las organizaciones fueran más productivas, que las áreas de software también lo fueran, es más que los programadores o desarrolladores fueran más productivos, ¿qué significa esto? La productividad está definida por la cantidad de producto terminado, dividida entre el esfuerzo necesitado para producirla (o algún otro recurso); el elemento clave es el tamaño, que para el software es tamaño funcional.

Hay otras mediciones que se pueden obtener de un proyecto como son velocidad de entrega, que se puede medir dividiendo el tamaño del software en un tiempo determinado. La densidad de defectos, que se obtiene de dividir el número de defectos entre el tamaño de software.

Un tema importante es que teniendo un estándar de medición confiable, el desempeño de las organizaciones y/o áreas puede ser comparado gracias a la estandarización de las mediciones de tamaño funcional, que como hemos visto para el desempeño del desarrollo de software son una parte fundamental.

Control del alcance de los proyectos

El alcance de los proyectos muchas veces es definido de manera subjetiva, si se mide el alcance del proyecto utilizando un método de medición de tamaño funcional, cada modificación o cambio puede ser medido de igual manera, lo que permite determinar la diferencia entre el alcance original o tamaño original y el nuevo tamaño, “scope creep”.

Se pueden definir umbrales de modificación de alcance, por ejemplo 20%, lo que implicaría dividir el tamaño funcional del nuevo requerimiento o modificación entre el tamaño original, si excede el umbral no se aceptaría porque podría repercutir en el tiempo de entrega o en costos.

Con estos elementos se puede ayudar a determinar si procede un cambio o requerimiento nuevo, pero también ayuda a saber al final del proyecto cuánto creció en alcance de manera cuantitativa y no solamente de forma subjetiva. Actualmente esto es muy complicado de saber.

Control de contratos de software

Hoy en día, para la definición de contratos de desarrollo de software se hace un requerimiento, el proveedor del desarrollo pone el precio en base a su experiencia y con una negociación se determina el precio final.

Si se necesitara una medición del tamaño de software, solamente basta con multiplicar el número de unidades de tamaño a desarrollar por su costo y ya está. Esto podría apoyar a la industria ya que se debería tender a una estabilización de los costos por unidad de tamaño de software.

Si se requiriera un cambio de alcance o modificación del software, ya se sabe el costo por unidad de tamaño funcional, no se reinicia una negociación para determinar el costo del cambio que muchas veces suele sobrestimarse.

Conclusión

La medición de tamaño funcional del software es muy importante, ya que hoy en día es el único estándar cuantitativo para determinar el valor de una característica del software, y si se utiliza adecuadamente puede ser el habilitador para que los proyectos de desarrollo de software sean exitosos, y así ayudar entre otras cosas a la estimación de proyectos, medición del desempeño de proyectos, control del alcance de los proyectos, y control de contratos de software.

Referencias

The Standish Group International (2011), Extreme Chaos, Inc. 2000-2011 Reports.
Emam, K.; Koru, A.G. (2008), A Replicated Survey of IT Software Project Failures, Software, IEEE Volume 25, Issue 5, Sept.-Oct. 2008 Page(s):84 - 90
PMI (2007), Off Base : Insufficient expertise in setting baselines hits U.S federal IT budgets where it hurts”, PM NETWORK, March 2007 / VOLUME 21
Alain Abran, (2008) , Software Benchmarking, Estimation and Quality Models Based on Functional Size with COSMIC – ISO 19761, Draft April 2008

Bio

Francisco Valdés Souto (@valdessoutofco) es Candidato a PhD. en Ingeniería de Software con especialización en medición y estimación de software Universidad de Quebéc en École de Technologie Supérieure. Certified ScrumMaster (CSM). Project Manager Professional (PMP). Primer mexicano certificado como COSMIC FFP Size Measurer por el COMMON SOFTWARE MEASUREMENT INTERNATIONAL CONSORTIUM (COSMIC). COSMIC International Advisory Council (IAC). Experiencia de 14 años en desarrollo de Software Financiero de desempeño crítico, Socio de SPINGERE, primera empresa en ofrecer servicios especializados en dimensionamiento y estimación de software desde un enfoque ingenieril en América Latina. Participación en conferencias internacionales como: SERA2010, IWSM-Mensura 2007.

Midiendo la Calidad del Software

lasr21 — Tue, 11 Jun 2013 16:54:13 +0000

Midiendo la Calidad del Software lasr21 Tue, 06/11/2013 - 11:54

Publicado en

SG #40

Gestión de Proyectos

Autor

Francisco Valdes Souto

Ante la necesidad de un consenso acerca de los elementos que definen la calidad del software, ISO desde hace tiempo creo estándares en este sentido. El primero es el ISO 9126, originalmente publicado en 1991 y posteriormente revisado en 2001. Posteriormente desarrolló el estándar ISO/IEC 25010: SQuaRE (Software Product Quality Requirements and Evaluation), que fue publicado en 2011 y viene a ser el reemplazo de ISO 9126.

Como ya se explicó en el artículo de la Dra. Hanna Oktaba “SQuaRE: Modelo actualizado de las características de calidad” publicado en SG #29, este modelo evalúa la calidad desde dos perspectivas: la calidad del producto como tal (calidad interna), y la calidad de el uso del software (externa). Cada perspectiva considera diversas características, y a su vez cada característica puede tener una o más subcaracterísticas.

Características y subcaracterísticas de calidad interna:

Adecuación funcional: funcionalidad adecuada, funcionalidad correcta, funcionalidad completa.
Confiabilidad: madurez, disponibilidad, tolerancia a fallos, recuperabilidad.
Eficiencia de rendimiento: tiempo de respuesta, utilización de recursos, capacidad.
Operabilidad: reconocimiento de funcionalidad adecuada, facilidad de uso, facilidad de aprendizaje, protección contra errores de usuario, accesibilidad, estética de la interfaz de usuario.
Seguridad: confidencialidad, integridad, no rechazo, responsabilidad, autenticidad.
Compatibilidad: interoperabilidad, capacidad de coexistencia.
Mantenibilidad: modularidad, reusabilidad, capacidad de ser analizado, capacidad de ser modificado, capacidad de ser verificado/probado.
Transmisibilidad/Portabilidad: instalabilidad, adaptabilidad, reemplazabilidad.

Características y subcaracterísticas de calidad externa:

Satisfacción de uso: utilidad, confianza, placer, comodidad.
Seguridad de uso: mitigación de riesgos económicos, mitigación de riesgos para el usuario, mitigación de riesgos ambientales.
Flexibilidad de uso: cobertura del contexto, flexibilidad.
Efectividad de uso.
Eficiencia de uso.

Aunque algunas de estas características se pueden medir de manera objetiva, la mayor parte requieren una evaluación subjetiva. Esto hace que la manera más utilizada, más rápida, menos costosa y quizá la que más refleja la realidad, sea la utilización de la experiencia de los empleados de una organización. Sin embargo, esto no permite realizar comparaciones objetivas y presenta algunos otros problemas como que le pertenece al experto y no a la organización, no se puede replicar sistemáticamente y no contribuye a la madurez de la ingeniería de software.

Existe un modelo que puede ser utilizado para la evaluación de este tipo de variables, el modelo EPEI (EPCU por sus siglas en inglés) el cual permite en un entorno de información imperfecta (información vaga o ambigua), pasar de entornos cualitativos a entornos cuantitativos. En otras palabras, es un modelo que nos permite a partir de opiniones (juicio de experto) de una serie de variables subjetivas, determinar un valor cuantitativo suficientemente razonable, generado por la evaluación de reglas de inferencia definidas por expertos. (Valdés, 2012).

Caso de estudio para medir la calidad de productos de software
Se realizó un estudio para evaluar la calidad de 44 proyectos. Los proyectos considerados fueron realizados en 4 áreas distintas de una organización que trabaja en un esquema de outsourcing (cada una con un proveedor distinto) controlados por líderes de proyecto internos, estos fueron los encargados de evaluar la calidad interna de los proyectos realizados.

De los 44 proyectos solamente 24 se pusieron en producción, por esta razón sólo a estos últimos se les evaluó la calidad de uso (externa), los usuarios fueron los encargados de evaluar la calidad de uso de las aplicaciones.

El procedimiento que se siguió para evaluar la calidad interna/externa de los productos de software fue solicitar a cada líder de proyecto la asignación de valores para las características definidas en el estándar para la calidad externa/interna en relación a su proyecto, las características fueron consideradas como variables de entrada en el modelo EPEI.

La asignación de los valores de las variables de entrada se realizó considerando el juicio de experto de los líderes de cada proyecto, determinándose un valor en un rango definido de 0 a 5 sobre el dominio de los número reales.

Por cada área de la organización se obtuvo el promedio de los valores asignados a cada una de las características de calidad considerando todos los proyectos evaluados.

Con los datos promedio de las categorías por área se calculó el índice de calidad por proyecto utilizando el modelo EPCU, de tal manera que se obtuvo un índice de calidad promedio que representa la calidad de los proyectos desarrollados en cada área de la organización.

Esto se realizó para la evaluación de la calidad externa/interna. Los resultados se muestran en las figuras 1 y 2.

Figura 1. Asignación de valores promedio para calidad interna.

Figura 2. Asignación de valores promedio para calidad externa.

Como se puede observar en este caso de estudio, es posible tener un valor cuantitativo formal y calculado de una misma forma para los distintos proyectos con base en las categorías del estándar para evaluación de la calidad de software SQuaRE, las cuales se manejan como variables de entrada al modelo EPCU.

Al tener un valor cuantitativo, formal y consistente con los índices de calidad calculados, es posible hacer comparaciones, sin embargo, es importante considerar que además del índice como valor de la calidad (externa/interna) se presentan los valores que alcanza cada una de las variables o categorías de la calidad, lo que puede ser determinante para definir las estrategias a seguir para mejorarla.

Conclusiones

A través del modelo EPCU es posible determinar un valor cuantitativo consistente, de manera formal y que nos permita hacer comparaciones acerca de la calidad de los productos de software de una manera práctica.

Este modelo permite evaluar a partir del juicio de experto, mediante mecanismos formales de manejo de información imperfecta y con base en el estándar de calidad ISO/IEC 25000, la calidad de los productos de software tanto desde el punto de vista de su construcción (calidad interna) como desde el punto de vista del usuario (calidad externa).

Debido a que el índice de calidad es consecuencia de los distintos valores de las categorías definidas por el estándar, es posible determinar estrategias relevantes y factibles para incrementar el índice de calidad a través de mejorar las categorías de calidad.

El poder tener un valor cuantitativo de calidad, sin duda, dará certeza al usuario, sobre todo si el también participa en la evaluación de la calidad externa del producto de software.

Referencias
[1] H. Oktaba. “SQuaRE Modelo Actualizado de las Características de Calidad”. SG Software Guru, Agosto-Octubre 2010. http://swgu.ru/sg40r13
[2] F. Valdés Souto. Design of A Fuzzy Logic Estimation Process for Software Projects. http://swgu.ru/sg40r14

Bio

Francisco Valdes Souto (@valdessoutofco) es PhD en Ingeniería de Software con especialización en medición y estimación de software por la Universidad de Quebéc. Es Certified ScrumMaster (CSM), Project Manager Professional (PMP) y el primer mexicano certificado como COSMIC FFP Size Measurer por el Common Software Measurement International Consortium (COSMIC). Es socio de SPINGERE, primera empresa en ofrecer servicios especializados en dimensionamiento y estimación de software desde un enfoque ingenieril en América Latina.

Modelo EPEI para Estimación de Proyectos de Software (parte 2)

Anonymous — Thu, 25 Aug 2011 19:31:45 +0000

Modelo EPEI para Estimación de Proyectos de Software (parte 2) Anonymous Thu, 08/25/2011 - 14:31

Publicado en

SG #33

Gestión de Proyectos

Autor

Francisco Valdes Souto

En la edición anterior describimos y mostramos un ejemplo en el cual una mala estimación puede ocasionar desde problemas de negociación hasta problemas económicos por tener que absorber costos no planeados. Esta situación es bastante común en la industria. De hecho, de 49 organizaciones que yo he entrevistado, tanto consultoras de software como corporativos e instituciones públicas, solamente 3 (6%) me han manifestado la ausencia de problemas en el tema relativo a las estimaciones.

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”, el problema sigue existiendo, ¿por qué?
Esta pregunta no es sencilla pero en parte se debe a que la ingeniería de software es relativamente joven comparada con otras ingenierías. 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. 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.
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”.

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

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.

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.

Configuración del Modelo. Se reunió a los participantes en la estimación original del proyecto, los roles que participaron fueron: Gerente de Procesos y Calidad, Gerente de Administración de Proyectos, Consultor en Procesos, Director de Administración de Proyectos, Director de Tecnología y Calidad. La configuración y generación de siete escenarios distintos llevó aproximadamente 2 horas.

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.

Variable de Salida. Para la variable de salida ellos definieron que sus proyectos iban del rango de 2 meses hasta 36 meses, ya que les interesaba estimar duración. Para la parte de estimación de esfuerzo ellos utilizaban la tabla mostrada en la figura 1. Sin embargo, esta tabla de esfuerzos no representa la realidad ya que una sola hora puede ser la diferencia entre un proyecto pequeño y uno mediano, o uno mediano y uno grande. El modelo EPEI utilizó algo que representa mejor la variable de salida que es una función como la que se muestra en la figura 2 con rango de 2 a 36 meses para duración y con rango de 500 a 19000 horas para esfuerzo.

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.

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.

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).

La evaluación de las variables se utilizó tanto para estimar la duración como el esfuerzo. En las tablas 1 y 2 se muestran la evaluación de las variables y los resultados obtenidos.

Conclusiones

Se ha mostrado en las dos partes de este artículo que existe un problema vigente para la estimación de proyectos de software en etapas tempranas. Al mismo tiempo se ha propuesto el uso de un modelo novedoso que permite realizar estas estimaciones con un enfoque de ingeniería incluso cuando la mayoría de las variables son cualitativas.

El modelo presenta una posible solución con varias ventajas, entre las que se encuentran que la experiencia pasa a ser un activo de la organización ya que se almacena en una base de datos basada en inferencias definidas por los expertos y que permite que la experiencia sea replicada sistemáticamente, ya que una vez definida la base de conocimiento las estimaciones pueden ser realizadas por otras personas, conservando el principio de las mediciones que deben de ser realizadas con el mismo instrumento para poder compararse, lo que no es posible realizar con juicio de experto.

El uso de este modelo nos habilitaría a realizar ingeniería incluso tomando como base el juicio de experto, al permitir realizar el enfoque cuantificable aún en etapas tempranas del desarrollo de software.

Bio

Estimación de proyectos de software: Un problema, una solución

sg — Fri, 13 May 2011 21:13:26 +0000

Estimación de proyectos de software: Un problema, una solución sg Fri, 05/13/2011 - 16:13

Publicado en

SG #32

Gestión de Proyectos

Autor

Francisco Valdes Souto

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

Lo anterior ocasiona que 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”.

Sin embargo, 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.

Hasta aquí es la parte que representa el problema descrito en el título, a continuación voy a presentar un ejemplo de esta situación:
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.

La empresa y el nombre del proyecto no se mencionan por confidencialidad, pero los datos son reales.

El proyecto

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”.

Como podemos ver, la información está dada a un nivel de abstracción muy alto y es muy ambigua. El cliente pidió con esto una cotización, lo que implicaba una estimación de duración y esfuerzo del proyecto.

Aunque sé que muchas personas por la finalidad de vender o por la costumbre de realizar así las estimaciones se verían tentados a dar los números solicitados, la realidad es que se pidió más información al cliente, éste proporcionó la siguiente información:

Contar con una herramienta que permita apoyar la operaciones de Comercio Exterior de carga, sin la necesidad de presentación física de papeles, haciendo más eficientes los procesos en las agencias aduanales en cuestión de resguardo y localización de pedimentos, sus anexos y documentos relacionados.
Contar con una herramienta que permita el resguardo digital de pedimentos, sus anexos y documentos relacionados por medio de un expediente único.
Dentro del proceso de resguardo de archivos autentificar los mismos mediante el certificado digital de Firma Electrónica Avanzada.
Contar con esquemas de búsqueda y consulta de información de acuerdo al rol del área y vigencia de resguardo.
Contar con esquema de “Facturación” que incluya costeo de almacenamiento, manejo de niveles de cuotas, bonificaciones y emisión de reportes.
Contar con información histórica (documentos) con una antigüedad hasta por 10 años.

Contexto del proyecto

El grupo que realizó las estimaciones conocía el contexto en el cual se realizaría el proyecto que lo describió de esta manera:

El equipo que iba a realizar la solución no contaba con un buen conocimiento del negocio ya que usualmente ellos se dedicaban a cuestiones financieras.
Tampoco se contaba con toda la experiencia de las tecnologías involucradas para el desarrollo de la solución como digitalización y firma electrónica aunque conceptualmente se conocían.
El líder de proyecto no tenía toda la disponibilidad ya estaba compartido en tres proyectos y el suplente no tenía mucha experiencia ni liderazgo para llevar a cabo un proyecto de manera independiente.

Herramientas utilizadas para la estimación

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, similar a la que se muestra en la Figura 1.

Figura 1. Rangos de Esfuerzo por tamaño de Proyecto.

Resultados

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%. Cabe mencionar que este grupo realizó originalmente la estimación, en un aproximadamente una de esfuerzo.

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 defasamientos, 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. Ver Figura 2.

Figura 2. Desfasamiento estimado Vs. real.

“De acuerdo al testimonio de la Government Accountability Office el pasado septiembre, si se establecieran con más realismo las líneas base de los requerimientos, costos, calendario y riesgos durante las fases de planeación de proyectos, cerca de la mitad de cancelaciones o programas que rebasan el presupuesto de TI podrían ser evitados. Eso ahorraría anualmente $5.5 billones, de acuerdo a un estudio hecho por Price Systems LLS, una compañía de software y consultoría de Mount Laurel, N.J de EEUU. El estudio considera 140 ejecutivos TI del Gobierno”. [2]

La sección de la solución correspondiente al título se mostrará en otra edición debido a la limitación del espacio.

Referencias:

The Standish Group International, Extreme Chaos, The Standish Group International, Inc, 2000 – 2004 Research Reports.
Off Base Insufficient expertise in setting baselines hits U.S federal IT budgets where it hurts”, PM NETWORK, March 2007 / VOLUME 21.

Bio

Francisco Valdés Souto es Candidato a PhD. en Ingeniería de Software con especialización en medición y estimación de software Universidad de Quebéc en École de Technologie Supérieure. Certified ScrumMaster (CSM). Project Manager Professional (PMP). Primer mexicano certificado como COSMIC FFP Size Measurer por el COMMON SOFTWARE MEASUREMENT INTERNATIONAL CONSORTIUM (COSMIC). COSMIC International Advisory Council (IAC). Experiencia de 14 años en desarrollo de Software Financiero de desempeño crítico, Socio de SPINGERE, primera empresa en ofrecer servicios especializados en dimensionamiento y estimación de software desde un enfoque ingenieril en América Latina. Participación en conferencias internacionales como: SERA2010, IWSM-Mensura 2007. @valdessoutofco