Gestión de Proyectos

Estimación de Software con COSMIC

sg — Wed, 23 Dec 2015 04:08:02 +0000

Estimación de Software con COSMIC

sg Tue, 12/22/2015 - 22:08

Publicado en

SG #49

Gestión de Proyectos

Autor

Carlos Eduardo Vázquez

Hacer una estimación “bottom-up” es inviable cuando no está disponible la estructura de proyecto, y hacer una estimación solamente basada en una analogía es muy subjetivo. Además, no se puede aprender de los errores cometidos. El objetivo de este artículo es introducir el método de medición de COSMIC y presentar una propuesta para derivar unidades de producto a partir de los requerimientos funcionales del usuario en diferentes representaciones.

La problemática de la estimación

Cuando se solicita una medición a un desarrollador para entregar un programa y él provee una estimación de 12 horas, lo más probable es que esté correcto porque se trata de una pieza cuya dificultad o probabilidad de error es pequeña.

Es así que para estimar proyectos de software típicamente se aplica una estrategia bottom-up que consiste en descomponer el proyecto en sus partes constituyentes, estimar cada una de las partes y sumar los resultados para una estimación total.

La falla en esta lógica es que al inicio no se conocen todos los programas y algunas actividades no están en función de esta cantidad, como por ejemplo la ingeniería de requerimientos y el diseño de arquitectura, cuyos productos son los insumos para la programación usada en el ejemplo de apertura. En otras palabras, el nivel de información disponible no permite usar la lógica de la estimación bottom-up como solución para los desafíos de la estimación.

¿Tiene caso estimar?

Ante esta problemática, hay quienes argumentan que este tipo de estimación bottom-up cuando no se conocen los programas requeridos es un esfuerzo inútil, y que es preferible mejor aplicar ese esfuerzo a ejecutar iteraciones de entre 15 y 30 días que nos permitan resolver los aspectos desconocidos, y entonces ya poder “saber” en lugar de simplemente creer.

El problema es que a nivel directivo se requiere tener estimaciones para poder tomar decisiones. La estimación permite tomar decisiones respecto al desarrollo o mejora de sistemas. ¿Tiene caso hacer este proyecto?, ¿su beneficio será mayor que su costo?, ¿cuándo es el momento para hacerlo?, ¿cuál es el 20% de los proyectos que ejecutaremos para atender el 80% de las demandas?

Contar con estimaciones previas también facilita que los equipos sean auto-administrados y que su desempeño sea planeado y monitoreado de acuerdo con las exigencias de transparencia y eficiencia del gobierno corporativo.

Unidad de producto de software

Algunos argumentan que el proceso de software es único y está más allá de cualquier medición. Sin embargo, existen similitudes de éste con la construcción civil en escala industrial. Cada edificio es único, a pesar de que pueda compartir los elementos arquitectónicos comunes en mayor o menor medida. El proceso de entrega de un inmueble involucra desde la concepción de un proyecto arquitectónico, pasando por varios proyectos de ingeniería, construcción y pruebas específicas, hasta la aceptación final por parte del propietario y la garantía por un periodo de transición.

Cuando se construye un edificio, es necesario tener un presupuesto disponible para su construcción. Una información clave en ese momento es el valor del costo por metro cuadrado de construcción. En base a eso podemos tomar varias decisiones: qué tan grande va a ser, cómo vamos a fondear su desarrollo, etc. En esta etapa no lidiamos con el costo detallado de cada componente del edificio. Después de todo, es mucho más costoso (proporcionalmente) construir un baño que una habitación, ya que el baño tiene un costo mayor de mano de obra y materiales. Posteriormente cuando sea necesario hacer la estimación de costo específica del baño, ya contaremos con suficiente información para hacer una estimación bottom-up.

En este punto surge un importante concepto: la productividad. Esta puede ser definida como la razón entre la cantidad de bienes o servicios producidos y las unidades de tiempo o costo para su entrega.

En el caso citado del edificio, la planeación de productividad se hace en dólares por metro cuadrado (USD/m2). Es decir que medimos nuestro producto en términos de metros cuadrados, y observamos el costo generado por cada unidad de producto.

En el caso del desarrollo de software, necesitamos identificar una unidad que nos permita medir el producto durante la planeación. Dicha unidad debe permitir aproximar el tamaño del software a partir de sus requerimientos, y debe ser independiente del desarrollo técnico y decisiones de implementación.

Este tipo de unidad no elimina la necesidad de otras métricas que permitan cuantificar el desempeño técnico de productos y servicios a partir de su implementación, como por ejemplo: análisis de eficiencia del diseño, apoyo a la ingeniería de requerimientos, apoyo a la verificación y validación. Un ejemplo de métricas de este tipo son las que define ISO/IEC 25.000 (SQuaRE).

Considerando las características deseadas para esta unidad de producto, se deben tener como objetivo de medición los requerimientos funcionales del usuario, ya que están específicamente asociados a una tarea o servicio del usuario y describen lo que el software debe hacer independientemente de cómo sea desarrollado.

Contar los requerimientos funcionales parece ser una buena alternativa para representar las unidades de producto del software. Sin embargo, no todos los requerimientos son iguales y se corre el riesgo de no diferenciarlos. Para eso, la ISO/IEC definió un estándar para ese tipo de medición, denominado Medición del Tamaño Funcional, y cuyo método más moderno es supervisado por el Consorcio Internacional de Medición de Software en General o COSMIC.

COSMIC es la segunda generación de métodos de medición de tamaño funcional. Es aplicable a todo tipo de software, compatible con la ingeniería de software moderna, es de dominio público, su documentación no tiene costo, y es reconocido por ISO/IEC.

Proceso COSMIC

El método de medición consiste en un conjunto de modelos, principios, reglas y procedimientos que se aplican para determinar el valor de una magnitud para la funcionalidad entregada por el software. Dicha magnitud de la funcionalidad del software es expresada en puntos de función COSMIC.

A muy grandes rasgos, el proceso consiste en:

Establecer la frontera entre el sistema y los actores con los que interactúa (que pueden ser personas u otros sistemas).
Identificar los procesos funcionales que los actores reciben del sistema.
Para cada proceso funcional, identificar los movimientos de datos que genera. Cada que el usuario provee al sistema un conjunto de datos para realizar un proceso, hay un movimiento de datos. También es un movimiento de datos cuando el sistema provee grupos de datos al usuario, y cuando se acceden o almacenan grupos de datos en almacenamiento. Cada movimiento de datos contribuye con el equivalente a un punto de función COSMIC.

Medición vs aproximación del tamaño

Debemos recordar que en las primeras etapas del proyecto no es factible hacer estimaciones detalladas. El alcance estará definido en términos de macroprocesos de negocio y áreas funcionales. Estos elementos pueden ser contados y comparados con su correlación con el software entregado y medido en puntos de función COSMIC.

En los momentos posteriores en el ciclo de vida, cuando ya existe un alcance definido en términos de cuáles tareas el usuario deben ser parcialmente o totalmente transferidos para el software, es posible identificar procesos y aplicar la misma lógica en la extrapolación de la cantidad de puntos de función COSMIC a partir de la cantidad de procesos.

Al final del proyecto, una vez que se tiene el sistema implementado, se hace una medición (ya no es una estimación) del producto terminado. Esto se hace para:

Evaluar el desempeño mediante la relación entre la cantidad de horas invertidas y la cantidad de puntos función COSMIC medidos.
Revaluar los indicadores de productividad para que pasen a incluir el desempeño del proyecto que acaba de terminar.
Revaluar la cantidad de puntos función COSMIC que corresponden en promedio a los procesos y a los conceptos de negocio conforme al nivel de información disponible en los diferentes puntos que se desea estimar.

Benchmarking

Los resultados reales del proyecto (tamaño, tiempo, esfuerzo y costo) nos sirven para compararlos con nuestra estimación inicial y en base a eso ajustar nuestro proceso de estimación para próximas estimaciones. De manera similar, debemos calcular cuál fue la productividad real (ej. horas hombre por punto de función) y tomarla en cuenta para futuras decisiones.

Con datos históricos de proyectos en la empresa podemos hacer benchmarking para comparar nuestra estimación. Por ejemplo, si estimamos un proyecto para el desarrollo en Java como si tuviera 150 puntos de función COSMIC y un esfuerzo de 1,050 horas hombre esto equivale a una tasa de entrega de 7 horas hombre por punto función (hh/cfp). Si tenemos una base de datos histórica de proyectos podríamos determinar qué tan factible es lograr una productividad de 7 hh/cfp.

Si no contamos con datos internos, podemos apoyarnos en bases de datos de la industria. Por ejemplo, el ISBSG (International Software Benchmarking Standards Group) provee herramientas y bases de datos para la estimación de proyectos de software.

Bio

Carlos Eduardo Vázquez es fundador y responsable de investigación y desarrollo en Fatto Consultoría, empresa de origen brasileño especializada en consultoría para la estimación de proyectos de software. Tiene más de 20 años de experiencia en investigación, consultoría y entrenamiento en estimación con puntos de función. Fue uno de los tres primeros brasileños certificados expertos en puntos de función por el IFPUG en 1996 y uno de los primeros brasileños certificados por COSMIC en 2012. carlos.vazquez@fattocs.com

Cómo Aprovechar la Arquitectura Empresarial en la Administración de Proyectos de TIC

sg — Mon, 15 Dec 2014 22:58:23 +0000

Cómo Aprovechar la Arquitectura Empresarial en la Administración de Proyectos de TIC

sg Mon, 12/15/2014 - 16:58

Publicado en

SG #46

Gestión de Proyectos

Autor

Óscar Gutiérrez Rodríguez

Uno de los retos que tienen las organizaciones al hacer inversiones en TIC, es asegurar los resultados y el impacto que éstos generan al negocio y la estrategia de la organización, por lo que es necesario que se alinien a sus necesidades y al cumplimiento de los objetivos estratégicos, además de maximizar la relación costo-beneficio de la inversión.

El marco de Arquitectura Empresarial permite mejorar el desempeño de los programas y proyectos al seguir un modelo de capas sucesivas de intervención, desde el nivel de la estrategia del negocio hasta el nivel de la infraestructura de TIC.

INFOTEC plantea en sus proyectos el uso del marco VIA INFOTEC, que consiste en siete capas horizontales y dos verticales, por medio de las cuales y sus interrelaciones es posible contextualizar los proyectos dentro de la organización, identificando todos sus aspectos e impactos (ver figura 1).

Figura 1. Estructura del marco VIA INFOTEC.

Dicho marco establece como principio fundamental la vinculación y transformación de las capas de la organización en propuestas de solución integradas para obtener los resultados deseados.

La utilidad del uso del marco de Arquitectura Empresarial en la administración de proyectos de TIC consiste en contextualizar el proyecto en el ecosistema de la organización, con el fin de establecer adecuadamente el alcance, los riesgos, las condiciones, las restricciones y las oportunidades que cada proyecto conlleva. En este nivel no se pretende modelar y documentar cada una de las capas, la recomendación es contar con los elementos necesarios para realizar una planeación, ejecución, seguimiento y cierre del proyecto en un enfoque integral y estratégico. Cuando identificamos la capa en la que se centra el proyecto, podemos determinar la interrelación que tiene con las otras capas dándonos una visión global de los aspectos que generarán el éxito.

El modelo también nos permite identificar a los grupos de interés del proyecto, que es un aspecto fundamental en la gestión, ya que podemos saber quién es el usuario final y quienes se verán afectados positiva o negativamente; así mismo permite formalizar la gobernabilidad al poder precisar los actores que conforman el grupo estratégico y el grupo táctico-operativo para delimitar la toma de decisiones y las acciones necesarias para alcanzar los objetivos del proyecto. Además, podemos reconocer los procesos que se verán afectados en los diferentes niveles (estratégicos, sustantivos, de apoyo y de TIC), lo que permite definir la estrategia de intervención y administración del proyecto, sin dejar supuestos o cabos sueltos.

Como se puede observar, el impacto en el concepto de Arquitectura Empresarial es diverso y no solo está centrado en la documentación de una infinidad de mapas, planos o artefactos que definen cada capa de la organización, o como una herramienta para lograr una arquitectura orientada a servicios. Por el contrario, es una herramienta que se puede utilizar para la alineación de las TIC con el negocio y con la estrategia, para dimensionar y planear un proyecto o como un mecanismo de comunicación entre los diferentes involucrados que coadyuva en la concepción de una visión compartida del proyecto. Los administradores de proyectos y los ejecutivos de las organizaciones deben romper el paradigma que centra la Arquitectura Empresarial como una herramienta de los responsables de la unidades de TIC, y en su lugar apreciarla como un mecanismo que les permitirá hacer mejor las actividades de planeación estratégica, programación y administración de proyectos de TIC.

Bio

Oscar Gutiérrez Rodríguez es Ingeniero Mecánico Electricista especializado en el área de Ingeniería Industrial. Durante los últimos 4 años ha sido responsable de la Subgerencia de Consultoría de Negocio de la Dirección Adjunta de Competitividad en el INFOTEC, así como de las especialidades y el portafolio de servicios de Planeación Estratégica, Gestión de Procesos de Negocio, Inteligencia de Negocio, Arquitectura de Negocio y Arquitectura Empresarial.

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.

Administración de Proyectos en la era de Big Data

sg — Sun, 20 Apr 2014 03:41:03 +0000

Administración de Proyectos en la era de Big Data sg Sat, 04/19/2014 - 22:41

Publicado en

SG #43

Gestión de Proyectos

Autor

Iván Rivera

Meses atrás empecé a escribir un artículo sobre cómo creo que será la Administración de proyectos en la era del Big Data. Antes de compartir mis comentarios, quiero revisar el concepto general.

Jhon Weathington (2012) propone la siguiente definición: grandes cantidades de datos que fluyen con rapidez.

Para ser competitivo con los clientes, los grandes volúmenes de datos deben crear productos que sean valiosos y únicos.
Para ser competitivo con los proveedores, los grandes volúmenes de datos deben estar disponibles gratuitamente, sin obligaciones o limitaciones.
Para ser competitivos con los nuevos operadores, grandes volúmenes de datos son difíciles para los recién llegados a probar.
Para ser competitivo con sustitutos, los grandes volúmenes de datos deben crear productos que excluyan a otros productos que pueden satisfacer la misma necesidad.

En resumen: Big data es gran cantidad de datos en movimiento rápido y con libre disposición que potencialmente sirve a una necesidad valiosa y única en el mercado, pero es extremadamente caro y difícil de extraer por medios tradicionales.

Ajustes en la gestión de proyectos

Jhon Googpasture (2012) revisa un ensayo de Cukier y Mayer- Schoenberger en la Revista Foreign Affairs que señala que usar grandes volúmenes de información requiere tres cambios profundos respecto a proyectos tradicionales:

Recopilar y utilizar una gran cantidad de datos en lugar de conformarse con pequeñas cantidades o muestras, al contrario de cómo se han hecho estadísticas en el último siglo.
Cambiar nuestra preferencia por los datos muy procesados en lugar de aceptar el desorden.
En muchos casos, tendremos que abandonar nuestra búsqueda por descubrir la causa de las cosas, a cambio de aceptar las correlaciones.

Jhon considera que “olvidar muestras económicamente viables, aceptar desorden sobre la exactitud, y ser felices sin entender la causalidad de la correlación” son las bases de la definición de “Terminado” para el patrocinador del proyecto.

Según una reciente encuesta de Infochimps, el 58% de los encuestados indicó que la causa principal del fracaso de los proyectos de BigData fue tener un alcance impreciso (Gilchrist, 2013).

La gestión de requisitos es una preocupación importante en estos proyectos, ya que el alcance inexacto es una de las tres principales causas de fracaso de acuerdo con la opinión de directores de TI encuestados.

Considerando estas estadísticas sombrías para los proyectos de Big Data, es evidente que algo hay que hacer para solucionar este problema. Y algo debe cambiar en la manera de gestionar los requisitos.

Los consejos que se pueden aplicar para ayudar a planear para el éxito de los proyectos de BigData, según Patti Gilchrist (op cit.) son:

Identificar las metas y objetivos de negocio. ¿Con qué frecuencia los equipos de trabajo del proyecto no están conscientes de la misión general o cómo el proyecto encaja en la estrategia general de la empresa? Hay que recordar que los datos sólo valen algo si los puede usar alguien que entiende la misión de la empresa y puede explicar por qué se necesita un proyecto Big Data en primer lugar.
Definir el problema. En el entorno actual de negocios de ritmo rápido y dinámico en el que hay una presión constante para la innovación y la velocidad al mercado, muchos equipos de proyectos abrazan un sentido de urgencia para comenzar a trabajar en un proyecto con información muy limitada, a regañadientes consienten esperar a tener una visión clara, y comienzan la ejecución sin una comprensión fundamental del problema que debe ser solucionado. La recomendación es que antes de iniciar un proyecto de Big Data se debe tener una idea muy clara de qué es exactamente lo se está tratando de lograr cuando se empieza.
Priorizar objetivos. En el artículo de Gilchrist también se recomienda determinar las prioridades. Entender los motivadores del negocio ayudará a priorizar los objetivos y asegurarse que el proyecto se está centrando en lo que va a agregar valor al negocio.
Establecer el caso de uso. ¿Con qué frecuencia se ha empezado a trabajar en un proyecto en el que no se proveen casos de uso? A menudo, en un esfuerzo frenético para aumentar la velocidad del mercado, los proyectos comienzan su ejecución sin una comprensión clara de los casos de uso. El modelado de casos de uso es una herramienta de planificación eficaz que proporciona un marco para los requisitos en un lenguaje fácil de entender y que sirve para facilitar el lograr acuerdos con los clientes y las partes interesadas. Los Casos de Uso enlazan las necesidades de los interesados con los requerimientos, ayudan a validar que se capturan todos estos requerimientos, y a verificar la comprensión de los interesados.
Determinar las necesidades de datos e identificar las fuentes de datos necesarias para apoyar sus casos de uso. Hay que recordar que mientras más grande es la misión de una organización, más complejos serán sus requerimientos de datos, y se requerirá más trabajo para delimitar el alcance en forma adecuada. Y se debe tener en cuenta el origen y la calidad de sus datos. ¿De dónde proceden?, ¿se necesita limpiarlos?, ¿están almacenados en bases de datos relacionales tradicionales?, ¿es un formato estructurado, procedente de canales web y las redes sociales?, ¿los datos están en reposo o en movimiento?
Se deben considerar las necesidades de infraestructura. Muchas organizaciones subestiman las necesidades de almacenamiento. Aunque las organizaciones son conscientes de los volúmenes de datos existentes, no se dan cuenta de que tendrán que duplicar los datos en un entorno independiente para realizar el análisis avanzado requerido. Debido al modelo de servicio basado en la utilidad o la medida de la computación en nube, muchas organizaciones han descubierto que los servicios basados en la nube ofrecen un precio más económico a la escala requerida para el manejo de grandes volúmenes de datos.
Comprender plenamente las necesidades de recursos. Un reto para la mayoría de los proyectos de TI es encontrar las habilidades necesarias para ejecutar con éxito los objetivos de negocio definidos. Para los proyectos de Big Data, es una tarea aún más difícil. Teniendo en cuenta las nuevas tecnologías y herramientas que intervienen, hay una escasez de recursos con experiencia. Y hay nuevos roles emergentes en la escena, como el ingeniero de datos - que es un rol relativamente nuevo pero crucial en los proyectos de Big Data.

Para tener éxito en un proyecto de Big Data, se necesitan recursos con conocimientos de matemáticas, estadística, algoritmos, ciencia de datos, así como visión para los negocios para entender cómo el esfuerzo se inscribe en el panorama más amplio de metas y objetivos de negocio. Un buen esquema de seguridad también resulta beneficioso si se utiliza información clasificada o restringida. Además, se necesita gente que se sienta cómoda con el aprendizaje y el uso de herramientas y tecnologías nuevas y complejas, tales como bases de datos no relacionales.

La necesidad de una gama compleja y amplia de habilidades hace aún más difícil la tarea de encontrar los recursos adecuados para el equipo.

Así que cuando se prepare para el próximo proyecto de Big Data, se deben evaluar el alcance, los requisitos y criterios de éxito para idear un plan que permita llevar a cabo las metas y objetivos.

Bio

Iván Rivera es maestro en Administración de Tecnologías de Información por el Tecnológico de Monterrey. Es administrador de Proyectos Certificado por el PMI y por la Universidad de Stanford, con más de 10 años de experiencia en el control de proyectos con fuertes restricciones de alcance, tiempo, costo y calidad, alineados a la estrategia organizacional. Cuenta con antecedentes empresariales desarrollados a través de puestos directivos en empresas de servicios. Innovador, orientado a soluciones y con habilidades de coordinación de equipos de trabajo.

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.

Gestión Ágil de Equipos

lasr21 — Thu, 21 Mar 2013 04:30:10 +0000

Gestión Ágil de Equipos lasr21 Wed, 03/20/2013 - 22:30

Publicado en

SG #39

Gestión de Proyectos

Tradicionalmente, los equipos de desarrollo de software tienen una estructura jerárquica, con la fuerte presencia del jefe de proyecto y alto énfasis en la asignación de roles y especializaciones a personas, que solo se dedican a efectuar el trabajo de su rol o especialización. Este tipo de estructura restringe la interacción entre los miembros del equipo.

La utilización de Kanban & Lean se orienta a generar equipos auto-organizados, en donde se alinea el alto empoderamiento con el alineamiento de objetivos comunes: alta flexibilidad, sin tendencia al caos.

La gestión tradicional de los equipos visualizados como recursos intercambiables y renovables, puede lograr resultados a cierto grado, pero tiene un alto costo humano, la motivación y autovaloración del desarrollador van mermando, generando un alto riesgo de abandono laboral y la incapacidad de generar equipos fuertemente de alto rendimiento, debido a que nunca se genera un equipo fuerte y permanente, sólo personas que vienen y van.

Un intento fallido

Alguna vez colaboré en un proyecto con una empresa dedicada a las microfinanzas. El proyecto era de gran relevancia, y mi jefe directo tenía una fuerte intención de utilizar metodologías ágiles. Al ingresar detecté en los miembros del equipo un alto interés en aprender y trabajar de forma diferente. Les expliqué que utilizaríamos Kanban, que con sus principios básicos era suficiente para partir e iniciar el proceso de mejora continua (Kaizen).

Aprovechamos cuando el jefe de proyectos se fue de vacaciones para hacer un tablero Kanban. Nuestro tablero contaba con columnas para agrupar los elementos en Pila, Seleccionado, En curso, Listo para revisión, Revisión y Terminado. Iniciamos las Stand-Up Meeting diarias. Si bien existía una Gantt como guía de actividades y tiempos, debido a los altos cambios que sufría el proyecto, la stand-up meeting nos permitían organizarnos día a día balanceando las cargas de trabajo, aumentando el rendimiento de equipo y lo más importante, el ánimo y cohesión generado al ser los únicos trabajando en forma distinta al resto de los equipos.

Al regresar nuestro jefe, en un inicio se interesó bastante en la forma de trabajar. Sin embargo, conforme pasó el tiempo el interés fue mermando, haciendo más hincapié en el seguimiento y re-planificación de la Gantt que poseía. El equipo no se juntaba si nuestro jefe no participaba o no invocaba, el tablero se dejó de actualizar y dejó de tener sentido utilizarlo.

Una nueva situación

En mi nuevo trabajo me comentaron inmediatamente la urgencia de estructurar y gestionar las actividades de cada desarrollador del equipo. El problema observado en primera instancia era la sobrecarga de tareas a cada desarrollador, sin tener una priorización clara o planificación.

Adicionalmente teníamos los siguientes impedimentos:

Bajo nivel técnico del equipo.
Restricción inicial de contratación de analista QA.
Restricción inicial de contratación de nuevo desarrollador.

Cuando el desarrollador estimaba e iniciaba una tarea, se le asignaban 2 o 3 tareas más (además de retrabajos), generando retrasos y grandes problemas de calidad ya que no estaba controlado el trabajo que tenía en curso. Esto generaba una gran frustración, sobrecarga emocional y estrés, además de existir un mal ambiente interno, generando diferencias técnicas y de calidad en el trabajo. Esto generaba una división y un quiebre interno (entre los que trabajaban bien, y los que no).

Existía una fuerte desconfianza de parte del cliente sobre nuestros desarrollos, por carecer de calidad e innovación tecnológica. Si bien los desarrollos eran entregados en un corto tiempo, el tiempo destinado a hacer retrabajos era aproximadamente un 30% de tiempo involucrado en desarrollar, tiempo que era tomado de estimaciones de otros desarrollos, por lo cual el desarrollador debía efectuar esta corrección y además continuar con los desarrollos asignados y en el tiempo comprometido. En el equipo esto generaba una frustración, ya que se sentían “malos desarrolladores”.

Para abarcar y solucionar esta problemática, se definieron las siguientes metas:

Mejorar motivación y compromiso del equipo.
Optimizar el trabajo en curso (WIP).
Mejorar la calidad de los desarrollos.
Recuperar la confianza del cliente.

A continuación describo las acciones realizadas para lograr estas metas.

Visualización del trabajo

Lo primero que se realizó fue la creación del tablero Kanban (ver figura 1) para el equipo completo, con las siguientes columnas: Pila, Seleccionado, Análisis, Desarrollo (restricción de WIP, que puede tener el estado de “en progreso” o “listo”), Revisión y Terminado.

Tabla 1. Tablero Kanban

La visualización del trabajo nos permitió inmediatamente detectar y visualizar en conjunto la carga de trabajo que tenía el equipo, y los tipos de tareas que existirían (mantenimientos, requerimiento nuevo, soporte, error, urgencia o documentación.). Fue el inicio del cambio. Adicionalmente, cuando creamos el tablero Kanban acordamos limitar el trabajo en curso y cumplirlo con total rigidez, no superando nunca el límite establecido.

Hitos y documentación

Se definieron ciertos criterios e hitos a cumplir en la transición de cada tarea en el tablero, que incluían la generación de documentación simple. A continuación la documentación que acordamos generar:

Identificación de necesidades: Descripción de las necesidades de los clientes, validadas por un representante del cliente.
Documento de evidencia de pruebas: Generación de pruebas unitarias y revisión completa del desarrollo, permitiendo detectar el máximo de problemas antes de pasar a producción.
Documento de entrega: documento en donde el desarrollador enumera todos los fuentes creados o modificados y su descripción, permitiendo detectar posibles alteraciones al sistema por un desarrollo nuevo (impacto a la funcionalidad en producción).
Setup: El documento de Setup está orientado a generar un instalable de uno o más desarrollos que se solicitan instalar en producción. Eso se debe a que cada desarrollador puede generar uno o más entregables, pero estos se pueden efectuar en una sola instalación.

La utilización de estos documentos permitió al desarrollador y al equipo dedicar tiempo a la comprensión de los requerimientos y a la revisión más exhaustiva de los desarrollos terminados.

TimeBoxing

De un universo limitado de funcionalidades, se pueden escoger un subconjunto de estas que sean inmediatamente prioritarias y determinar una fecha de entrega fija. Se negocian las funcionalidades que podemos asegurar entregar para esa fecha. Esto elimina los retrasos de entrega, logrando entregar lo prioritario primero, ganando tiempo y permitiendo limitar y enfocar nuestro trabajo en curso.

En nuestro caso, cada requerimiento recibido de parte del cliente contenía varios “sub-requerimientos” que eran específicamente las funcionalidades que el cliente requería, por lo tanto, lo que efectuamos es definir conjuntamente con el cliente las funcionalidades más prioritarias e indicar una fecha de entrega de ese subconjunto de funcionalidades priorizadas y una segunda fecha para entregar el resto de funcionalidades. Claramente, una vez entregado el primer subconjunto de funcionalidades existía una re-priorización, lo que nos permitía nuevamente re-planificar y adecuarnos a las necesidades y prioridades del cliente, permitiéndonos entregar las funcionalidades de mayor importancia a su negocio.

Esto nos permitió directamente establecer un marco de mayor confianza con el cliente y priorizar nuestro trabajo, limitando nuestro trabajo en curso a lo priorizado, eliminando la sobrecarga laboral y canalizándola de una manera más estratégica.

Stand Up Meeting

Se iniciaron las reuniones diarias, en donde se presentaba la tarea asignada y el progreso que se tenía de esta, además de los impedimentos (qué estoy haciendo, qué haré y qué problemas he tenido) poco a poco se va “barriendo” el tablero de derecha a izquierda, iniciando por las tareas inconclusas, hasta las que se planean efectuar (para de iniciar, empieza a terminar).

Planificaciones semanales.

Con el tiempo las reuniones diarias se alargaban, planificando y analizando nuevos requerimientos recepcionados, por lo cual empezamos a efectuar planificaciones semanales de máximo 2 horas los lunes. Estas reuniones nos permitían generar metas concretas, específicas y priorizadas, lo que permitiría al equipo cuantificar sus avances y sentir que han logrado nuevas y mejores cosas. Esto nos permitía elegir e iniciar aquellas tareas más prioritarias según los objetivos definidos al iniciar la semana.

Entrega continua

La entrega continua de los desarrollos permitió inmediatamente alinearlos con las necesidades del cliente y recuperar su confianza. Definimos dos tipos de entregas:

Entrega parcial: Nos permite informar al cliente de un avance en ambiente de revisión interna, pero con riesgos de mal funcionamiento o problemas de escritura en los desarrollos. El objetivo de una entrega parcial es montar un ambiente de integración, rectificación de un requerimiento completo o netamente para disminuir la angustia del cliente ante cortos tiempos de desarrollo.

Entrega total: Es la entrega de una funcionalidad completa en los tiempos planificados, con documento de evidencia de funcionamiento y entrega. Esto quiere decir que con el visto bueno del cliente, se procedía a la instalación de esa funcionalidad o de otras.

Enseñanza para mejorar la calidad.

Basándonos en el Libro de Kanban de David J. Anderson, rescatamos la siguiente receta para permitir aumentar la calidad de nuestros desarrollos:

Aplicar desarrollo dirigido por pruebas (TDD). Pedirle a los desarrolladores que escriban pruebas unitarias y las automaticen para proporcionar pruebas de regresión automatizadas también tiene un efecto dramático. Esto aún no ha sido 100% implementado, ya que trabajar con TDD es duro y requiere un cambio mental fuerte.

Realizar inspecciones de Código. Establecimos una práctica de revisión por terceros, lo cual nos ayudó a mejorar la calidad del código que generamos. Esto nos ha permitido detectar deficiencias de código, corregirlas y que todo el equipo aprenda para no replicarlas.

Hacer análisis y diseño en colaboración. La calidad se incrementa cuando se les pide a los equipos que trabajen juntos para analizar problemas y soluciones de diseño. Decidimos analizar todos los requerimientos en conjunto (todo el equipo) identificando riesgos, dependencias y dudas, para luego definir ítems de trabajos (subconjunto de funcionalidades), que pueden ser priorizadas y paralelizadas. Esto permitió distribuir el trabajo en el equipo completo, balanceando la carga de trabajo, aumentando la comunicación en el equipo y disminuyendo la especialización, además de permitirnos compartir conocimiento y estrategias de implementación.

Apoyarse en patrones de diseño. Aplicar patrones de diseño facilita y acelera el diseño, además de que ayuda a reducir errores.

Utilizar herramientas modernas de desarrollo. Muchas de las herramientas modernas incluyen funciones para realizar un análisis estático y dinámico de código. No poseemos herramientas modernas de desarrollo, pero esta dentro de nuestro próximo objetivo.

Conclusiones

El uso de Kanban, sumado con conceptos de gestión ágil, nos ha permitido aumentar la calidad de nuestros desarrollos, permitiendo el retorno de confianza de nuestros clientes. Gracias a esto, uno de nuestros clientes recientemente nos evaluó como una de las empresas proveedoras Top Ten en confianza, calidad y responsabilidad.

Por otra parte, el trabajar con una metodología ágil, limitar el trabajo en curso, definir hitos o explicitar el proceso, y llevar a cabo las reuniones definidas (stand-Up meeting, planificación semanal y análisis en conjunto) ha permitido al equipo conformar una identidad única en la empresa, mejorando su ánimo, motivación y empoderamiento, ya que se ha logrado con una simple guía y políticas puntuales, una auto-organización fuerte, entendida y compartida por todo el equipo. Los miembros del equipo no nos sentimos como recursos genéricos, sino como una fuente de mejora, innovación y orgullo por las metas conseguidas en conjunto: calidad de los desarrollos, optimización de nuestro trabajo, retorno de la confianza del cliente, y lo mejor, motivación y compromiso por parte del equipo.

Los recursos no tienen capacidad de auto-organización, las personas sí.

Bio

Pablo Cáceres Ferreira es Project Manager en Rhiscom S.A Chile. Se especializa en el desarrollo y gestión de proyectos tecnológicos y de innovación utilizando metodologías ágiles. Su próximo objetivo es por medio de BPM lograr la alineación estratégica de la tecnología al servicio de los negocios y los procesos.

Estimación Empírica de Proyectos con Planning Poker

hmcuesta — Thu, 21 Mar 2013 04:29:37 +0000

Estimación Empírica de Proyectos con Planning Poker hmcuesta Wed, 03/20/2013 - 22:29

Publicado en

SG #39

Gestión de Proyectos

Para planear el desarrollo de un software es necesario estimar de una u otra forma su tamaño y por supuesto su costo. Existen diversas mecanismos para estimar el tamaño de un software y el esfuerzo requerido para construirlo, en las páginas de SG anteriormente se han publicado artículos sobre métodos como la estimación por puntos de función, así como el recurrir a información histórica de proyectos anteriores.

En este artículo se muestra una técnica de estimación empírica conocida como “Planning Poker”, donde un grupo de expertos discuten y evalúan el esfuerzo requerido para cada tarea del proyecto. Se utiliza la opinión de expertos como referencia ya que su experiencia les permite adaptarse a nuevas tareas en base a su similitud. Esta técnica se utiliza en metodologías ágiles como XP (Programación extrema) para estimar cada historia de usuario [1].

La técnica

Consiste en crear una reunión de trabajo con el grupo de expertos. Se requiere de un moderador que dirigirá la actividad. Primero se expone el proyecto que se va a desarrollar. Luego se determinan las actividades requeridas para ejecutar el proyecto, y entonces para cada una de las actividades los distintos miembros del equipo realizan una estimación empírica y se conjuntan y discuten los resultados con el fin de cerrar la brecha y converger en un valor estimado para cada tarea. La información obtenida con la estimación de cada tarea se utiliza para realizar el plan general del proyecto y conocer el esfuerzo total.

Figura 1. Interface web para realizar estimaciones en planningpoker.com

El proceso

A continuación mostramos el proceso en mayor detalle que se realiza para cada historia de usuario a estimar.

El moderador lee y explica una historia o requerimiento ante los miembros del equipo. Se podrán hacer preguntas para dejar claro qué se desea alcanzar.
Los participantes anotan en una tarjeta su estimación para dicha tarea y la entregan al moderador de manera anónima, es decir que no se sepa qué tarjeta corresponde a qué persona.
El moderador captura los resultados en un pizarrón o en alguna herramienta de software tal como la de http://www.planningpoker.com.
Una vez que se conoce los integrantes deberán discutirlas, haciendo énfasis en el razonamiento detrás de los valores extremos (el más bajo y el más alto).
Tomando en cuenta el conocimiento obtenido por esta discusión, cada participante hace una nueva estimación para la historia y la anota en una tarjeta.
El moderador captura las estimaciones ajustadas y en caso de no haber consenso se vuelven a discutir.

III. Verificación y Validación

Es recomendable que al terminar el proyecto y realizar el post-mortem de éste se compare la estimación contra el esfuerzo real, de manera que esto se tome en cuenta para futuras estimaciones.

Para esto podemos recurrir al cálculo del balance relativo de error (BRE) con la siguiente ecuación:

Donde X = real y Y = estimado

Consideraciones

Esta técnica requiere de un moderador con gran pericia para lograr que rápidamente haya convergencia en las estimaciones. También hay que tener cuidado cuando uno de los integrantes tiene demasiada autoridad, ya que puede sesgar la estimación. No es posible estimar un proyecto entero de esta forma, sino que se recomienda estimar por historia o sprint si se trabaja con SCRUM.

Uno de los beneficios de esta técnica es que permite considerar distintos puntos de vista. Adicionalmente, ayuda a hacer amenizar una tarea que puede ser tediosa. Resulta ser una técnica mejor que Delphi y que grupos no estructurados, tal vez por la discusión cara a cara entre los participantes. A medida que se practica Planner poker se podrán hacer mejores estimaciones.

Referencias

[1] N. Haugen. “An empirical Study Planning for user story estimation”. Proceedings of AGILE 2006 Conference. IEEE, 2006.
[2] N. Haugen & K. Molokken-Ostovoldl. “Combining Estimates with planning poker: An empirical study”. Proceedings of the 2007 Australian Software Engineering Conference. IEEE, 2007.
[3] T. Stober & U. Hansmann. Agile Software Development: Best Practices for Large Software Development Projects. Springer, 2010.

Bio

Héctor Cuesta-Arvizu (@hmcuesta) es Lic. en Informática y actualmente cursa la maestría en ciencias de la computación en la UAEM Texcoco. Cuenta con seis años de experiencia desarrollando y administrando proyectos de software. Adicionalmente se desempeña como instructor para Nyce en el área de base de datos e ingeniería de software.

José Sergio Ruíz Castilla es Profesor Investigador de la Universidad Autónoma del Estado de México, estudia el Doctorado en Ingeniería de Software y trabaja en proyectos de Ingeniería de Software y Sistemas de Gestión del Conocimiento.

El Extraño caso del Líder Jekyll y Mr. Hyde

lasr21 — Mon, 03 Dec 2012 07:34:29 +0000

El Extraño caso del Líder Jekyll y Mr. Hyde lasr21 Mon, 12/03/2012 - 01:34

Publicado en

SG #38

Gestión de Proyectos

Esta es la historia de un líder de proyecto llamado Jekyll, el cual alegremente —al menos al comienzo— lideraba un nuevo proyecto de desarrollo de software como tantos otros que existen, han existido y existirán.

Nuestro líder Jekyll era un caso típico de trayectoria profesional en nuestra industria. Después de estudiar una carrera afín al mundo de sistemas, inició como programador becario en alguna tecnología de moda para luego desempeñar durante algunos años diferentes roles de ingeniería de software en diferentes proyectos —a veces varios de manera simultánea—. En el transcurso tomó uno que otro curso, normalmente relacionado con lenguajes de programación o herramientas de desarrollo. Finalmente, en aras de su probada capacidad técnica y organización personal, su jefe tomó la decisión de convertirlo en "líder de proyecto" (entendiendo como tal lo que el rol significara para el jefe), y para "foguearlo" lo asignó a dirigir un nuevo proyecto.

Acostumbrado a afrontar nuevos retos con optimismo, Jekyll aceptó su nuevo rol poniéndose al frente del equipo de trabajo que le fue asignado, el cual estaba compuesto principalmente por recursos de poca experiencia junto con un par de "lobos de mar". El proyecto, según le explicó su jefe, había sido ganado "con mucho esfuerzo", para lo cual había sido necesario realizar ajustes en las tarifas y recortes en los tiempos. Al preguntar quién había calculado los tiempos, recibió como respuesta que “el equipo de ventas” (sin más detalles de quiénes o cómo). Sin embargo, para tranquilizarlo su jefe añadió que tenía la ventaja de que el levantamiento de requerimientos ya estaba hecho (lo había hecho otra consultoría), y que la arquitectura base ya estaba definida (la había definido el cliente), por lo que “únicamente” le iba a tocar dirigir el desarrollo.

De manera previsora, nuestro Jekyll solicitó a sus "lobos de mar" asignados que le echaran un vistazo a la arquitectura base. Para su sorpresa, los lobos le manifestaron que, a pesar de contar con varios años de experiencia y un largo recorrido en desarrollo de sistemas, desconocían por completo las tecnologías que la componían. Dado que el resto del equipo estaba compuesto por programadores novatos, lo más que pudo obtener fue un par de "leí algo, alguna vez, en un sitio de Internet...". Por tanto, Jekyll acudió con su jefe para solicitar que se le asignara algún recurso con experiencia en la tecnología, a lo que recibió una negativa con el argumento de falta de personal y comentarios respecto a problemas con las tarifas. Sin embargo, el jefe recordó que Jekyll había participado como desarrollador en algo parecido en el pasado, por lo que aseveró que seguramente no tendría ningún problema para implementar el proyecto. Un poco intranquilo, Jekyll hizo "de tripas corazón" y en aras del cumplimiento del proyecto aceptó la responsabilidad técnica del mismo (es decir, desempeñar también el rol de arquitecto).

Requerimientos difusos

Continuando con el proyecto, Jekyll solicitó una vez más el apoyo de los lobos de mar para dimensionar el alcance a partir del análisis de los documentos de requerimientos. Consternados, detectaron varios problemas:

A pesar de que la consultora que realizó el levantamiento de requerimientos se anunciaba como “experta en análisis de negocio”, no existía ningún documento de un análisis del negocio como tal. Los únicos documentos disponibles eran especificaciones de casos de uso. El estilo de redacción de los casos de uso variaba desde vagas descripciones hasta verdadero pseudocódigo, y en ocasiones se apreciaba que eran un mero “copy-paste”.

Muchos de los términos y procedimientos del negocio eran completamente desconocidos para el equipo de trabajo, y no existía documentación disponible al respecto.

Se hacía mención a la necesidad del cumplimiento de legislaciones y estándares, pero no había ninguna información que los explicara.

Los casos de uso no tenían ningún tipo de agrupación o secuencia, ni venía documentada su alineación con los flujos de operación del negocio.

Se indicaban decenas de validaciones y cálculos, pero en ningún lugar se describían. Las reglas de negocio no estaban documentadas en ningún otro lado.

Las relaciones entre casos de uso eran inconsistentes o incorrectas, y los actores participantes no eran homogéneos ni se describían en ninguna parte de la documentación. De hecho, tampoco casaban con roles de los empleados de la empresa.

Procesos batch y reportes venían especificados usando los mismos formatos usados para documentar casos de uso. Sin embargo, los “layouts” de los reportes no estaban indicados.

Los requerimientos no funcionales no eran explícitos, además en ocasiones chocaban con notas y comentarios desperdigados en los casos de uso.

Ante lo anterior, Jekyll solicitó el apoyo de su jefe, el cual para tranquilizarlo procedió a negociar con el cliente un periodo "extraordinario" para aclaración de dudas del equipo (no quedando claro quién absorbería el impacto en costo y calendario). Como había que designar un responsable del lado del equipo, una vez más Jekyll aceptó la responsabilidad y se constituyó en el "líder de análisis" del proyecto.

Arquitectura incongruente

Recordando Jekyll que tenía también el rol de arquitecto, para aprovechar el tiempo procedió a revisar más a fondo la arquitectura base establecida por el cliente. Resultó ser un documento largo y pomposo el cual:

A todas luces se veía que había sido generado haciendo una mezcla de documentación proveniente de otros sistemas. Incluso el nombre de los mismos aparecía en varios lugares donde se les había pasado reemplazarlos por el nombre del sistema actual.

Incluía una combinación de tecnologías sin justificar la razón de su elección.

Sin ton ni son mezclaba vistas, modelos y conceptos de diferentes metodologías y marcos de descripción de arquitecturas.

Sus diagramas adolecían del “síndrome del rompecabezas abstracto”, es decir diagramas que encajan bien y se ven bonitos pero no es claro lo que representan las piezas. Esto ocurría porque los autores no acompañaron a los diagramas con descripciones de cada una de las partes que los componían, asumiendo que las etiquetas de nombres transmitían perfectamente el objetivo y características de cada parte.

Hacía referencia a funcionalidad no incluida en las especificaciones.

En ningún lugar se explicaba como la “arquitectura base” abordaba el cumplimiento de los requerimientos no funcionales.

Al preguntar Jekyll al cliente si esa arquitectura base ya se estaba utilizando en algún sistema que estuviera en operación de la empresa, recibió la respuesta de que "no, pero hay uno que casi la utiliza". Después de realizar diversas gestiones en diferentes frentes, Jekyll consiguió que se le mandara una versión "triple I" (incompilable, incompleta e ininteligible) de la arquitectura base. Al preguntar si era posible realizarle cambios, le contestaron que no porque la había definido el comité de arquitectura de la empresa (cuyos miembros no tenían participación ni responsabilidad alguna en el proyecto, ni tampoco era posible consultarles), y porque su uso estaba establecido por contrato.

Bajo involucramiento del cliente

Ante esto, Jekyll (que a estas alturas del partido aún no había leído el contrato de servicio), solicitó a su jefe una copia del mismo y procedió a leerla con detenimiento. Al hacerlo, entre otras cosas encontró que venían cláusulas leoninas de penalización por incumplimiento por parte del equipo de desarrollo, pero no se había incluido ninguna que tocara al cliente por incumplimiento de acuerdos o por períodos de espera atribuibles al cliente. Una vez más Jekyll acudió con su jefe para exponer estos puntos. Resultó que de muchos de ellos el jefe no estaba enterado, pero intentó tranquilizarlo con la indicación de que no se preocupara, porque contaba con todo el apoyo de la empresa y porque el cliente estaba comprometido.

Francamente alarmado, Jekyll comenzó a acudir a las sesiones de "aclaración de dudas", en donde los participantes del lado del cliente con frecuencia no acudían, llegaban tarde o se iban antes (porque no podían descuidar sus actividades normales), no sabían de qué se les estaba hablando (porque la consultora anterior jamás les había presentado los casos de uso), disentían de su contenido (porque la operación “no era” como la indicaban los casos de uso), planteaban sobre la marcha cambios y "mejoras" (discutiendo arduamente entre ellos por cuestiones triviales sin llegar a ningún acuerdo), o con una sonrisa comentaban que lo contenido en los casos de uso "ya no aplicaba" (porque en el inter habían ocurrido cambios en el negocio, en un sistema externo o en alguna legislación). Al acudir por enésima vez con el jefe a plantear los problemas, recibió una palmadita en la espalda y una vez más la recomendación de que no se preocupara, porque el proyecto "iba a salir".

¿Y todavía se preguntan de dónde sale el Mr. Hyde de esta historia?

Conclusión

Para los lobos marinos que todavía se hacen a la mar, sirva el presente cuento para provocarles sonrisas al reconocer escollos y monstruos marinos atemorizantes. Para aquellos que ya no se hacen a la mar y que viven en los puertos despachando navíos, sirva para revivirles sensaciones casi olvidadas de sus épocas marineras y crearles conciencia no sólo de la crueldad de designar a marinos jóvenes como capitanes para mandarlos inmediatamente a navegar en aguas tormentosas, sino de la más que probable posibilidad de que al hacerlo se vayan a pique los barcos que comandan.

Bio

Efraín Cordero López es responsable técnico y líder de proyecto en grupo CARSO. Es licenciado en computación por la Universidad Autónoma Metropolitana y cuenta con acreditaciones como SCJP, SCWCD y Oracle SOA Implementation Champion. Es autor de cursos de diseño, pruebas unitarias y mejores prácticas de ingeniería de software.

Estimación de Costos

hmcuesta — Wed, 30 Nov 2011 21:49:21 +0000

Estimación de Costos hmcuesta Wed, 11/30/2011 - 15:49

Publicado en

SG #34

Gestión de Proyectos

El Cliente dice: “¡Te damos tiempos límite razonables! ¿Por qué no puedes cumplirlos?”

Ese argumento es muy común en el desarrollo de software y el hecho de fijar la fecha de entrega antes de establecer los requisitos, es el problema más antiguo de la ingeniería de software, pero si ya estamos conscientes de todo esto ¿por qué la improvisación parece ser el estándar? y ¿por qué no se tienen procesos de estimación bien definidos?
Hoy en día existen diversas herramientas y metodologías que nos permiten estimar costos como SPR KnowledgePlan de Capers Jones o COCOMO II de Barry Boehm, por comentar algunos. Sin embargo fenómenos como el “Proyecto interminable” y la “Marcha de la muerte” siguen siendo comunes en muchos desarrollos. Existen muchos factores que afectan las estimaciones de costo como:

Incertidumbre en los requerimientos.
Términos contractuales rígidos.
Salud financiera (ganar licitaciones sacrificando costo y tiempo).
Falta de experiencia con “X” tecnología.

No existe una forma simple de calcular el esfuerzo requerido para desarrollar un proyecto de software. Las estimaciones iniciales se hacen bajo la base a la definición de requisitos que el cliente provee a un alto nivel (funcionalidades o pantallas). Los pasos típicos en una estimación son:

Análisis de los requisitos.
Predicción del tamaño.
Descripción de las Actividades.
Estimación de fallas potenciales y métodos de eliminación de defectos en el software.
Estimación de requisitos del personal.
Ajuste de suposiciones basadas en capacidades y experiencia.
Estimación del esfuerzo y fechas límite.
Estimación de costos del desarrollo.
Estimación de costos de mantenimiento y mejora.

A medida de que los proyectos de software aumentan en complejidad, se observa que no existe una relación simple entre el precio de software al cliente y los costos involucrados en el desarrollo, así como la falsa creencia que hay una relación entre el número de desarrolladores contra el número de funcionalidades del proyecto. Por eso y para facilitar el proceso de estimación se han establecido a lo largo del tiempo, métricas que ayudan a dar una idea aproximada del tamaño del software:

Medidas relacionadas con el tamaño del código ( LOC - Lines of code). Esta forma de medir el tamaño de un software era utilizado cuando los lenguajes de programación, patrones de desarrollo y entornos de desarrollo (IDE), no estaban ampliamente desarrollados. Hoy en día es impráctico tratar de estimar el software a través de sus líneas de código ya que depende de la experiencia de los programadores o si hablamos de lenguajes de programación dinámicos como Ruby, Scala y Groovy o herramientas e IDEs que facilitan gran parte del trabajo de programación.

Medidas relacionadas con la función (UFC – Puntos de Función). El total de puntos de función no es una característica simple sino que es una combinación de características del software a las cuales se les asigna un valor que cambia dependiendo de su complejidad.UFC es igual a la suma de los “n” elementos evaluados por el peso asignado al tipo de función.
Sin embargo a lo largo del proyecto las funciones cambian, las métricas de puntos de función tienen en cuenta esto y multiplican los UFC iniciales por un factor de complejidad (asignándoles un factor de peso que va desde 3 a 15 puntos). Una desventaja de los puntos de función se presenta cuando el sistema está orientado por eventos. Por eso algunos autores piensan que UFC no es muy útil para medir productividad.

Los Puntos de Objeto (PO). Los PO se utilizan en el modelo de estimación Cocomo II con el nombre de Puntos de Aplicación. Estos son una alternativa a los UFC, y son usados en los lenguajes orientados a objetos y de scripts. Dan valor a cada pantalla dependiendo de su complejidad: simples = 1, medianamente complejas = 2, muy complejas = 3. Los reportes van de 2 a 8 dependiendo del nivel de complejidad, y los módulos en lenguaje imperativo como Java o C++ se contabilizan como 10. Esto puede ser relacionado directamente a las historias de usuario de algunas metodologías agiles con lo cual facilita la estimación de la iteración.

Modelo Constructivo de Costo: COCOMO II

Uno de los modelos de estimación más usados es COCOMO (Constructive Cost Model) creado por el Dr. Barry Boehm. COCOMO apareció por primera vez en su libro Software Engineering Economics [1] en 1981. En 1999 se definió la segunda versión del modelo que toma en cuenta el proyecto, el producto, el hardware y la experiencia del equipo de desarrollo en sus fórmulas de estimación de costo, incluyendo mecanismos de predicción de tiempo.

Cocomo II provee niveles que nos permiten hacer estimaciones en diferentes momentos del desarrollo ya que la estimación de costos debe de ser un proceso dinámico a lo largo del desarrollo, actualizando constantemente las variables, la evolución del equipo de desarrollo, las herramientas y lenguajes involucrados. Los distintos niveles son:

Construcción de prototipos. Las estimaciones de tamaño están basadas en puntos de aplicación con base en componentes reutilizables, prototipos y la fórmula para estimar el esfuerzo requerido es muy simple: tamaño / productividad.

Diseño inicial. Está basado en los requerimientos originales del sistema a un alto nivel (pantallas, reportes, procesos, transacciones) lo que son traducidos a puntos de aplicación, esto nos sirve para hacer una predicción temprana del costo.

Reutilización. Este nivel se utiliza para calcular el esfuerzo requerido para integrar el código generado por los IDE’s o herramientas de generación de código reutilizable como Spring Roo o Genexus por ejemplo, tomando en cuenta componentes reutilizables que facilitan el desarrollo como Apache Commons.

Post-arquitectura. Ya diseñado el sistema se pueden hacer estimaciones más precisas del tamaño del software, aquí es importante señalar que el software tiene una tasa de crecimiento de los requerimientos del sistema entre el 2 y el 5 por ciento mensual, por lo cual no es posible hacer una estimación exacta pero las predicciones de costo se pueden acercar mucho a la realidad gracias a la aplicación de métricas que nos permiten tener una variación muy pequeña con respecto al producto final.

Cocomo está basado en fórmulas para hacer las estimaciones, véase la figura 1 donde se estima el esfuerzo del personal por mes (PM), después se hace la estimación del tamaño del proyecto (SIZE) y finalmente se obtiene una proyección del esfuerzo requerido (B) contemplando los factores involucrados (SF).

Obviamente el realizar los cálculos manualmente es una tarea lenta y tediosa por lo cual existen muchas aplicaciones que se encargan de realizar todas las fórmulas, como USC COCOMO II que es la aplicación de la página oficial de COCOMO. Podemos descargar gratuitamente el software en http://swgu.ru/sg3414

Conclusión

La estimación de costos es una actividad muy importante en el desarrollo de software. Esta actividad no es estática sino que cambia en diferentes puntos del ciclo de vida del desarrollo.

Se tienen que hacer estimaciones desde diferentes puntos de vista, desde la predicción de costos hasta la retrospectiva de comportamiento del costo, para lo cual las herramientas de estimación nos ayudan a agilizar la tarea. Sin duda el poder hacer predicciones con respecto al costo del software nos da ventajas que facilitan el éxito de un proyecto, sin embargo esto no debe de ser exhaustivo ya que se tienen variables que el modelo no contempla totalmente como la incertidumbre, la complejidad o factores humanos de los cuales no se puede tener control, por lo cual se deben tomar en cuenta los riesgos del proceso de desarrollo de software.

Una de las ventajas de COCOMO es el poder medir el comportamiento de costo de un proyecto de software de forma interna para la empresa de desarrollo. Lo que nos permite tener un referente en diferentes puntos del proyecto y así poder comprobar que las proyecciones de costo originales se cumplan.

Referencias
[1] B. Boehm. “Software Engineering Economics”. Prentice Hall, 1981.
[2] C. Jones. “Estimating Software Costs”. McGraw-Hill, 2007.
[3] “COCOMO II Model Definition Manual”. Center for Software Engineering, USC.
[4] B. Boehm, C. Abts, et al. “Software Cost Estimation with COCOMO II”. Prentice Hall, 2000.

Bio

Héctor Cuesta-Arvizu es Lic. en Informática y actualmente cursa la maestría en ciencias de la computación en la UAEM Texcoco. Cuenta con seis años de experiencia desarrollando y administrando proyectos de software en el ámbito de manufactura y recursos humanos. Adicionalmente se desempeña como instructor de TI para Nyce en el área de base de datos e ingeniería de software. @hmcuesta

M. en C. José Sergio Ruíz Castilla es Profesor Investigador de la Universidad Autónoma del Estado de México, estudia el Doctorado en Ingeniería de Software y trabaja en proyectos de Ingeniería de Software y Sistemas de Gestión del Conocimiento.

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

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). Es socio de SPINGERE, empresa especializada en servicios de dimensionamiento y estimación de software. @valdessoutofco