¿Qué es la estimación funcional y por qué importa?

La estimación funcional es un enfoque para calcular el tamaño funcional del software, es decir, la funcionalidad que este entregará al usuario. A diferencia de los métodos tradicionales que evalúan líneas de código, se centra en el valor del software desde la perspectiva del negocio y del usuario final. Esto trae beneficios clave para gerentes generales:

• Identificación de riesgos potenciales: Permite mitigarlos desde el inicio antes de que afecten los resultados y generen gastos innecesarios. recursos estén alineados con las necesidades reales y evita los costos innecesarios.
• Determinación de costos realistas: Ayuda a evitar presupuestos insuficientes o inflados, optimizando el uso de los recursos financieros.
• Definición de cronogramas alcanzables: Basados en el esfuerzo necesario para cumplir con los requerimientos, asegurando un mejor manejo del tiempo.

Comparativa de metodologías de estimación funcional: COSMIC vs. IFPUG

Existen varias metodologías para estimar el tamaño funcional, pero dos destacan en el campo: COSMIC e IFPUG. Ambas abordan el cálculo de funcionalidades, pero tienen enfoques y aplicaciones distintas:

• COSMIC (Common Software Measurement International Consortium): Diseñada para entornos modernos y sistemas distribuidos. Es ideal para proyectos con múltiples componentes y tecnologías, permitiendo un análisis más detallado y adaptable. Ayuda a optimizar el uso de recursos humanos en entornos complejos.
• IFPUG (International Function Point Users Group): Enfoque tradicional más adecuado para sistemas consolidados con menos cambios. Es una opción fiable para entornos con requerimientos estables y pocos factores de innovación.

Un estudio reciente reveló que las empresas que implementaron COSMIC en fases tempranas lograron reducir un promedio del 20% en costos operativos durante la vida útil del software.imer trimestre”.

Caso de éxito: Planificación con estimación funcional

Una empresa de tecnología financiera enfrentó el reto de implementar un sistema de pagos digitales en un mercado competitivo. Al utilizar la metodología COSMIC desde el inicio, lograron:

• Reducir un 15% los costos totales del proyecto gracias a una estimación precisa.
• Cumplir con el cronograma original en un 98%, optimizando el uso del tiempo.
• Mejorar la satisfacción de los clientes finales gracias a funcionalidades bien priorizadas y alineadas con sus necesidades.

Este enfoque también permitió redistribuir eficientemente los recursos humanos, evitando sobrecargas en el equipo y asegurando una ejecución fluida.

Soluciones para una mejor planificación y uso de recursos

La estimación funcional del software no se limita a calcular números; transforma la manera en que abordas cada etapa de un proyecto. Desde la definición de costos y cronogramas hasta la mitigación de riesgos, esta metodología establece una base sólida para garantizar resultados exitosos.

Con herramientas como COSMIC e IFPUG, puedes elegir el enfoque que mejor se adapte a tu entorno y objetivos. Ya sea que gestiones sistemas modernos o tradicionales, invertir tiempo en una estimación funcional precisa se traduce en una planificación robusta, un mejor uso de los recursos financieros y humanos, y un retorno de inversión más alto.ndamentales en este paso, permitiéndote prever el esfuerzo necesario para cada etapa del proyecto.

No permitas que tu próximo proyecto se pierda en la estadística del 70% de fracasos. Descubre cómo SPINGERE puede ayudarte a implementar las mejores prácticas de estimación funcional y asegurar el éxito de tus proyectos.

Contacta a SPINGERE hoy mismo y transforma tus proyectos de software con soluciones avanzadas de estimación funcional.

The post Primer Paso para el Éxito en tus Proyectos de Software: Estimación Funcional del Software first appeared on Spingere.

La falta de precisión en la estimación de software puede llevar a una serie de problemas graves. Un estudio de IBM reveló que uno de cada seis proyectos de TI experimenta un sobrecosto del 200% y un retraso del 70% en comparación con las estimaciones iniciales (IBM, 2016). Estos desvíos no solo afectan la rentabilidad de los proyectos, sino también la reputación de las empresas y la confianza de los clientes.

Desafíos comunes al momento de estimar un proyecto de software.

1. Variabilidad y Complejidad: Los proyectos de software son intrínsecamente variables y complejos. Cada proyecto tiene sus propios requisitos y desafíos únicos, lo que hace difícil aplicar una fórmula estándar para la estimación.

2. Falta de Datos Históricos: Muchas organizaciones no tienen acceso a datos históricos precisos sobre proyectos anteriores, lo que complica la estimación basada en experiencias pasadas.

3. Cambios en los Requisitos: Los requisitos de software pueden cambiar durante el ciclo de vida del proyecto, afectando las estimaciones iniciales. Esto puede ser debido a nuevas necesidades del cliente, descubrimientos técnicos o cambios en el mercado.

Para mejorar la precisión en la estimación de software, utilizamos métodos y herramientas adecuadas que proporcionen una base sólida para la toma de decisiones. Una de las soluciones más efectivas en este ámbito es el método de medición de software COSMIC.

Método de medición de software COSMIC

El método COSMIC (Common Software Measurement International Consortium) es una metodología estándar de medición de software que permite una estimación precisa y objetiva. Al enfocarse en la funcionalidad del software, COSMIC proporciona una medida clara y consistente que puede utilizarse para planificar y gestionar proyectos de manera efectiva.

Beneficios del Método COSMIC:

– Objetividad y Consistencia: COSMIC ofrece una manera objetiva de medir la funcionalidad del software, eliminando las suposiciones y subjetividades que a menudo afectan las estimaciones.

– Adaptabilidad: COSMIC puede aplicarse a una amplia variedad de tipos de software y proyectos, desde sistemas empresariales hasta aplicaciones móviles, lo que lo hace versátil y adaptable.

– Datos Basados en Hechos: Utilizando el método COSMIC, puedes basar tus estimaciones en datos precisos y medibles, lo que reduce el riesgo de errores y mejora la confianza en las predicciones.

¿Me puedo capacitar en el método COSMIC?

Además de adoptar el método COSMIC, es crucial contar con capacitaciones adecuadas para tu equipo y servicios especializados que garanticen la correcta implementación de esta metodología. La capacitación en estimación de software y el uso de herramientas avanzadas de medición pueden marcar una gran diferencia en la precisión de tus estimaciones.

La precisión en la estimación de software es fundamental para el éxito de cualquier proyecto de TI. Con el método COSMIC y las capacitaciones adecuadas, puedes mejorar significativamente tus estimaciones, optimizando recursos y asegurando que tus proyectos se completen a tiempo y dentro del presupuesto. No dejes que las imprecisiones afecten tus proyectos; adopta una metodología probada y garantiza el éxito de tus iniciativas de software.

The post La certificación COSMIC: un cambio de juego para la precisión en la estimación de software first appeared on Spingere.

Estudios recientes muestran que aproximadamente el 70% de los proyectos de software no cumplen con sus objetivos iniciales en términos de tiempo y presupuesto (Standish Group, 2020). Esto no solo genera frustración, sino que también puede resultar en pérdidas financieras considerables. Los gerentes financieros, operacionales y de compras se enfrentan a un gran dilema: cómo mantener un control efectivo sobre los recursos, tiempos y costos sin sacrificar la calidad del proyecto.

Desafíos comunes de las empresas que tienen proyectos de software.

1. Retrasos en la Entrega: Los proyectos de software son notoriamente difíciles de prever con exactitud, y los retrasos son comunes. Estos pueden deberse a problemas técnicos, cambios en los requisitos o falta de comunicación entre equipos.

2. Sobrecostos: Sin una estimación precisa y un control riguroso, los costos pueden dispararse rápidamente. Un informe de McKinsey encontró que los proyectos de TI con grandes desviaciones de presupuesto pueden gastar hasta un 45% más de lo previsto inicialmente (McKinsey, 2017).

3. Falta de Transparencia: Sin una visión clara de cada fase del proyecto, desde la planificación hasta la ejecución, es difícil tomar decisiones informadas. La falta de transparencia puede llevar a la ineficiencia y a la duplicación de esfuerzos.

Para abordar estos desafíos, es esencial implementar un enfoque integral que permita el control total y la visibilidad en cada etapa del proyecto. Aquí es donde entra en juego la Software Accountability Office (SAO ®).

Control Total con la Software Accountability Office (SAO ®)

La SAO ® es una persona o un equipo que proporciona una visión clara y detallada de tu proyecto de software. Desde la planificación inicial hasta la entrega final, la SAO ® asegura que cada etapa esté perfectamente controlada y alineada con los objetivos de negocio. Algunos de los beneficios clave incluyen:

– Transparencia Completa: Con la SAO ®, obtienes visibilidad total sobre el uso de recursos, tiempos y costos. Esto permite identificar problemas potenciales antes de que se conviertan en obstáculos significativos.

– Optimización de Recursos: La SAO ® facilita la optimización de cada recurso, asegurando que se utilicen de la manera más eficiente posible. Esto ayuda a evitar sobrecostos y maximizar el retorno de inversión.

– Toma de Decisiones Informadas: Con datos precisos y actualizados en tiempo real, puedes tomar decisiones basadas en hechos y no en suposiciones. Esto reduce el riesgo de errores costosos y mejora la eficiencia del proyecto.

¿Cómo ha ayudado la SAO ® a las empresas?

La empresa INDRA, compartió una experiencia real sobre la implementación de la Software Accountability Office (SAO ®):

“Me gustaría destacar la importancia de la SAO ® porque nos ayudó en tres puntos principales: 

1. Poder tener aproximaciones y mediciones oportunas.
2. En el tema de los entregables para ver el proceso y avance de cada uno de los proyectos, ante nuestro cliente en el sector gobierno es importantísimo tener un perito certificado en el momento de entregar tanto estimaciones como mediciones.
3. Nos ayudó muchísimo a abrirnos puertas con otros clientes.”

¡Implementa ahora mismo la SAO ®!

Controlar un proyecto de software puede ser desafiante, pero con las herramientas y estrategias adecuadas, es posible garantizar el éxito. 

La Software Accountability Office (SAO ®) es una solución efectiva que SPINGERE implementa para lograr la transparencia, el control y la optimización necesarios en cualquier proyecto de software. Imagina la tranquilidad de saber que cada aspecto de tu proyecto está bajo control y alineado con tus objetivos de negocio. Si te interesa conocer más sobre la implementación y los beneficios que la SAO ® ofrecen, contáctanos ahora mismo.

The post La clave del éxito en proyectos de software: precisión en la estimación y medición first appeared on Spingere.

En el desarrollo de software, medir el tamaño del software es esencial para estimar costos, planificar proyectos y gestionar recursos. Dos métodos populares para medir el tamaño del software son el IFPUG (International Function Point Users Group) y el COSMIC (Common Software Measurement International Consortium). En este artículo, exploraremos sus diferencias y cómo pueden ser útiles en diferentes contextos.

Método IFPUG

El método IFPUG se basa en Puntos de Función (Function Points, FP), que mide el tamaño del software en términos de su funcionalidad desde la perspectiva del usuario. Los Puntos de Función se calculan evaluando cinco componentes principales:

1. Entradas Externas (EI): Datos o controles ingresados al sistema.
2. Salidas Externas (EO): Datos o controles generados por el sistema.
3. Consultas Externas (EQ): Respuestas a consultas del usuario.
4. Archivos Lógicos Internos (ILF): Datos controlados dentro del sistema.
5. Archivos de Interfaz Externos (EIF): Datos controlados por sistemas externos.

Ventajas del método IFPUG

• Estandarización: Bien estandarizado y ampliamente reconocido.
• Orientado al usuario: Enfocado en la funcionalidad desde la perspectiva del usuario.
• Base de datos rica: Gran cantidad de proyectos medidos para comparaciones y benchmarking.

Limitaciones del método IFPUG

• Complejidad: Requiere formación significativa.
• Subjetividad: Variaciones en la interpretación de los criterios de medición.

Método COSMIC

El método COSMIC mide el tamaño funcional del software enfocándose en los flujos de datos a través de cuatro tipos de movimientos:

1. Entrada (Entry, E): Datos ingresados al sistema.
2. Salida (Exit, X): Datos proporcionados desde el sistema.
3. Lectura (Read, R): Datos leídos desde un almacenamiento persistente.
4. Escritura (Write, W): Datos escritos en un almacenamiento persistente.

COSMIC mide el tamaño del software en “Unidades de Medida COSMIC” (COSMIC Function Points, CFP).

Ventajas del método COSMIC

• Precisión en sistemas modernos: Adecuado para sistemas orientados a servicios y aplicaciones distribuidas.
• Menor subjetividad: Enfoque en flujos de datos claros y definidos.
• Flexibilidad: Aplicable a una variedad de tipos de software, incluyendo sistemas embebidos y aplicaciones en tiempo real.

Limitaciones del método COSMIC

• Requiere adaptación: Necesidad de tiempo para adaptación y formación del personal.
• Menor adopción: No tan ampliamente adoptado como el método IFPUG.

Estadísticas y uso en la industria

Según ISBSG (International Software Benchmarking Standards Group), alrededor del 60% de los proyectos de software utilizan Puntos de Función (IFPUG) para la medición del tamaño del software. En comparación, el método COSMIC ha visto un crecimiento en adopción del 15% anual en los últimos años, especialmente en sectores como el automotriz y las telecomunicaciones debido a su precisión en sistemas modernos y distribuidos.

¿Y cuál es mejor?

Adaptabilidad y escalabilidad

El método COSMIC ofrece una medición detallada de los flujos de datos, lo que es especialmente relevante para aplicaciones distribuidas, sistemas embebidos y servicios basados en la nube. Esta adaptabilidad y escalabilidad hacen de COSMIC una opción robusta para el futuro del desarrollo de software.

Menor subjetividad

COSMIC reduce el margen de error y las variaciones en las estimaciones, proporcionando una planificación y gestión de proyectos más precisa y confiable en comparación con IFPUG.

Mayor precisión en sistemas modernos

La capacidad de COSMIC para modelar y medir con precisión los movimientos de datos lo hace ideal para las arquitecturas de software modernas. Esto es particularmente útil en sectores de rápido crecimiento como IoT (Internet de las Cosas), donde los flujos de datos complejos son comunes.

Flexibilidad y creciente adopción

Aunque el método IFPUG sigue siendo ampliamente adoptado, el crecimiento del uso de COSMIC en la industria muestra una tendencia clara hacia su aceptación. Este método proporciona una herramienta adaptable para medir el tamaño del software en una amplia variedad de aplicaciones.

Asociarse con Spingere para la excelencia en la medición de software

En Spingere, entendemos el poder transformador de la medición de software en la era digital de hoy. Nuestro equipo de expertos se especializa en ayudar a las organizaciones a implementar prácticas de medición robustas que impulsen el éxito. Utilizamos el método COSMIC para medir con precisión los flujos de datos y asegurar estimaciones precisas y confiables. Ya sea que necesites ayuda con la recopilación de datos, el análisis o la interpretación, estamos aquí para apoyarte en cada paso del camino.

No dejes tu éxito al azar. Ponte en contacto con Spingere hoy mismo para desbloquear todo el potencial de la medición de software y llevar a tu organización a nuevas alturas.

The post IFPUG V.S. Método COSMIC ¿Qué elegir? first appeared on Spingere.

En el mundo del desarrollo de software, la medición juega un papel fundamental en la evaluación y gestión de proyectos. Existen diversas metodologías y enfoques para medir el software, cada uno con sus propias ventajas y aplicaciones. En este artículo, exploraremos los diferentes tipos de medición de software, con un énfasis particular en el Método de Medición COSMIC, y cómo puede beneficiar a las organizaciones en la gestión de sus proyectos de software.

¿Por qué es importante la medición de software?

La medición de software proporciona a los equipos de desarrollo y gestión una manera objetiva de evaluar la complejidad, el tamaño y otros atributos de un proyecto de software. Algunas de las razones por las cuales la medición de software es importante incluyen:

1. Planificación y Estimación: La medición proporciona datos clave que ayudan a planificar y estimar los recursos necesarios para completar un proyecto de software.
2. Control de Calidad: Permite monitorear la calidad del software durante todo el ciclo de vida del proyecto, identificando posibles problemas y áreas de mejora.
3. Gestión de Proyectos: Facilita la gestión de proyectos al proporcionar métricas objetivas para evaluar el progreso y el rendimiento del equipo.

“No puedes controlar lo que no puedes medir” 

– Tom DeMarco

Tipos de medición de software

Existen varios tipos de medición de software, cada uno enfocado en aspectos específicos del desarrollo de software. Algunos de los tipos más comunes incluyen:

1. Medición de Tamaño Funcional: Se centra en la funcionalidad del software, midiendo el tamaño basado en los requisitos funcionales del sistema.
2. Medición de Tamaño del Código: Evalúa el tamaño del software en función del código fuente, incluyendo líneas de código y complejidad ciclomática.
3. Medición de Esfuerzo: Evalúa la cantidad de esfuerzo humano necesario para completar un proyecto de software, generalmente medido en horas hombre o puntos de función.

Método de medición COSMIC

El Método de Medición COSMIC es una metodología de medición de tamaño funcional que se ha vuelto cada vez más popular en la industria del software. Se destaca por su enfoque en la medición de la funcionalidad del software de una manera independiente del lenguaje de programación y la tecnología utilizada.

Algunas características clave del Método de Medición COSMIC incluyen:

• Basado en Transacciones: Mide el tamaño del software en función de las transacciones de entrada y salida que realiza el sistema.
• Enfoque en la Funcionalidad del Usuario: Se centra en medir la funcionalidad del software que es visible para el usuario final.
• Escalabilidad y Flexibilidad: Puede aplicarse a una amplia gama de sistemas de software, desde aplicaciones pequeñas hasta sistemas empresariales complejos.

El Método COSMIC se ha implementado en más de 30 países y ha sido adoptado por más de 200 organizaciones en diversas industrias. Estudios de caso muestran que la precisión en la estimación de proyectos de software mejora en un 20-30% cuando se utiliza el Método COSMIC en comparación con otras metodologías de medición.

Beneficios del método de medición COSMIC

Organizaciones que han adoptado COSMIC reportan una reducción del 15% en el tiempo de desarrollo de proyectos debido a una mejor planificación y estimación.

El Método de Medición COSMIC ofrece varios beneficios para las organizaciones que buscan medir el tamaño funcional de su software de manera precisa y objetiva. Algunos de estos beneficios incluyen:

1. Independencia Tecnológica: Al medir la funcionalidad del software en lugar del código fuente, el Método COSMIC es independiente del lenguaje de programación y la tecnología utilizada.
2. Estimaciones Precisas: Proporciona estimaciones más precisas del tamaño y la complejidad del software, lo que ayuda en la planificación y estimación de proyectos.
3. Comparabilidad: Permite comparaciones objetivas entre diferentes proyectos de software, independientemente de las tecnologías utilizadas o los enfoques de desarrollo.

Asociarse con spingere para la implementación del método de medición COSMIC

En Spingere, entendemos la importancia de la medición precisa en el desarrollo de software y estamos comprometidos a ayudar a las organizaciones a implementar el Método de Medición COSMIC de manera efectiva. Nuestro equipo de expertos puede proporcionar capacitación, consultoría y soporte para garantizar que aproveches al máximo esta poderosa metodología de medición.

No subestimes el valor de la medición de software en la gestión de proyectos. ¡Contacta con Spingere hoy mismo para obtener más información sobre cómo podemos ayudarte a implementar el Método de Medición COSMIC en tu organización!

The post Tipos de Medición de Software usando el Método de Medición COSMIC first appeared on Spingere.

Surgimiento y Concepto de PSP

Después de la II Guerra mundial (1945), el enfoque en calidad de las organizaciones (incluidas las de desarrollo de software) estaba fundamentado en las pruebas. Fue hasta los 70’s y los 80’s que E. Deming y J.M. Juran convencieron a la industria de USA de enfocarse en la forma en que las personas realizan su trabajo. Sin embargo, la industria de software siguió fundamentando la calidad de las piezas de software en las pruebas.

El primer gran paso hacia el enfoque propuesto por Deming y Juran en el área de software se dio con las inspecciones de software propuestas por Michael Fangan (1976), otro gran paso se dio en 1987 con la introducción de Capability Maturity Model (CMM).

Es fundamental entender que el enfoque principal del CMM y hoy Capability Maturity Model Integration (CMMI) for Development es el sistema de administración, soporte y asistencia que se proporciona a los ingenieros de desarrollo de software [1], en otras palabras su enfoque es en mejorar la calidad de los desarrollos de software, a través de mejorar el desempeño de los procesos de una organización relacionados con la construcción de software. El SEI ha documentado efectos sustancialmente positivos por el uso de de CMM y CMMI.

En 1995 surge el Personal Software Process (PSP), que fue generado por Watts Humphrey y busca extender los beneficios de la mejora de procesos organizacionales a las personas que realizan el trabajo, el PSP se enfoca en las prácticas de trabajo individuales de los ingenieros de desarrollo de software (proceso personal), la estructura básica conceptual del PSP se muestra en la Figura 1.

Se inicia con un establecimiento de los requerimientos, después se realiza una planeación, posteriormente el diseño, la codificación, etc. ¿Qué es lo que lo hace diferente? Que durante todo el ciclo se generan “scripts de procesos” los cuales define los pasos para cada fase, también los “logs” y las formas de registro y almacenamiento de información, así como los estándares que deben de seguir los desarrolladores, es decir, son guías de lo que se debe de hacer en cada fase del ciclo definido (checklist).

Pero quizá lo más relevante de todo lo que se ha mencionado, y la fortaleza del PSP es el registro y almacenamiento de información ya que es lo que permite la mejora la productividad de las personas, mejora en los hábitos de programación, así como una detección temprana de defectos y riesgos.

Visto de otra manera lo que establece PSP es un “proceso de medición”, un proceso de medición es como lo que hace un área contable, cada día van identificando las facturas que se pagan, los pagos que se cobran, las pólizas, etc.

Si esto se hace cada mes, lo que algunas veces sucede, se acumulará más trabajo y la visibilidad de lo sucedido será con corte cada mes, por lo que si existiera algún riesgo durante el periodo, no se identificaría, hasta que se contabilizara todo.

Si esto lo extendemos a un año se acumula más trabajo y la posibilidad de poder tener visibilidad de lo sucedido cuando ya no se pueda hacer nada. Lo mismo sucede en el desarrollo de proyectos de software.

Estimación de Tamaño y Recursos con PSP (Método PROBE)

Dentro de la fase de planeación (Figura 2) se establece la estimación de tiempo y recursos, el método que propone PSP para realizar la estimación tanto de tamaño como de esfuerzo es el método PROBE (PROxy Based Estimating), el cual se basa en la utilización de objetos base -denominados proxys- para estimar el tamaño más probable de un producto.

Figura 1. Estructura Conceptual PSP

Como muchos mecanismos que utilizan elementos cuantitativos, establece que la precisión de los estimados depende del detalle de conocimiento sobre los requerimientos del trabajo a realizar, por eso incluye una etapa de diseño conceptual que se toma como base para estimar tanto el tamaño del producto como los recursos, considerando la siguiente suposición: “La correlación entre el tamaño del programa y el tiempo de desarrollo es ligeramente moderada entre equipos de ingenieros/desarrolladores y organizaciones. Sin embargo, de forma individual es generalmente alta”. [1]

Para realizar la estimación de tiempo, un desarrollador determina los tipos de objeto requeridos para desarrollar una pieza de software, con base en datos históricos de objetos similares – el método PROBE establece que se requieren datos de al menos tres proyectos- se determina el tamaño (LOC) más probable del tipo de objeto de acuerdo a distintos rangos, con los tamaños estimados de los objetos a desarrollar y utilizando una regresión lineal, se determina la cantidad de código que se planea desarrollar.

Reflexión: Hasta aquí todo suena bien, sin embargo, en la documentación PSP [1] se menciona una suposición que si bien cuando se creó PSP pudo hacer sentido, hoy podemos considerarla errónea: “como el tamaño de un objeto es función del estilo de programación, el método PROBE enseña a los ingenieros cómo utilizar los datos generados por ellos mismos para generar rangos de uso personal”.

Porqué se considera errónea, la suposición se basa en el supuesto de que se estima el tamaño del software a producir con base a líneas de código (LOC), sin embargo después de mucho avance de la disciplina Ingeniería de Software, se reconoce que esta no es una medida adecuada del tamaño de una sistema, en virtud de que no es estándar y depende de la tecnología, por lo que no puede ser utilizada como parámetro de comparación.

Aunado a lo anterior, hoy sabemos que solamente existe un estándar cuantitativo para determinar el tamaño de la funcionalidad del software, se denomina tamaño funcional (ISO/IEC 14143) y se determina a través de distintos métodos estándares, entre los que se encuentra COSMIC como el único método de segunda generación (referencia blog).

En lo que se refiere a la estimación de recursos, el método PROBE recomienda utilizar una regresión lineal considerando el tamaño (la cantidad de código) estimado y el esfuerzo real (en alguna unidad de tiempo como meses, días u horas-persona) de acuerdo a los datos históricos personales, también recomienda al menos tres proyectos siempre y cuando se demuestre una correlación razonable entre los datos.

Una vez estimado el tiempo total del proyecto, se establece con base en los datos históricos el esfuerzo por fases, y se detalla por mes, semana o día, para proyectos grandes PSP introduce también el uso del método de Earn Value.

Aquí cabe mencionar que uno de los problemas más grandes para la realización de estimados es el contar con datos históricos, Morgenshtern [2] menciona que los modelos algorítmicos necesitan datos históricos, y muchas organizaciones no cuentan con esta información. Adicionalmente, recolectar estos datos implica un costo muy alto en dinero y tiempo.

Figura 2. Fase DE planeación en PSP

Mejorando PSP

Si bien la técnica PSP utiliza las LOC como unidad principal de medida, también indica que “cualquier unidad de medida puede ser utilizada, siempre y cuando proporcione una correlación razonable entre el tiempo y el tamaño del producto” [1].

“Measuring software productivity by lines of code is like measuring progress on an airplane by how much it weighs.” – Bill Gates.

P. Bourque [3] menciona que los requerimientos definen el alcance o tamaño del producto, el tamaño determina el esfuerzo y éste influye en la duración; también menciona que la relación entre esfuerzo y tiempo no es lineal.

Aunado a lo anterior resulta lógico pensar que es mejor utilizar un estándar generalmente aceptado para determinar una unidad de medida y poder realizar comparaciones.

Por estas razones, se considera que los resultados que se obtienen con PSP pueden ser visiblemente mejorados si se utiliza un mecanismo estandarizado de dimensionamiento de tamaño de software, que para este caso se puede recomendar el único estándar de segunda generación de tamaño funcional; método COSMIC (ISO/IEC 19761), como se muestra a continuación.

Figura 3. Método PROBE utilizando COSMIC

Conclusión

PSP en un proceso que se enfoca en mejorar las prácticas de trabajo individuales, a través de la definición y utilización de un “proceso de medición” basado en LOC.

Sin embargo, existen estudios que demuestran que la correlación entre LOC y esfuerzo no es muy adecuada, en virtud de que las LOC son dependientes de las distintas tecnologías, así como de la experiencia de programación de los desarrolladores, además de no ser un estándar.

Por lo anterior, se considera que los resultados de PSP pueden ser mejorados si se utiliza un mecanismo estándar de medición como el método COSMIC, en virtud de ser un método que determina unidades de tamaño estándares generalmente aceptados, y en particular COSMIC por ser el único estándar para medición de tamaño funcional de segunda generación, el cual presenta algunas ventajas sobre los métodos de la primera generación.

En relación a las preguntas planteadas originalmente respecto si el método COSMIC se puede utilizar con el método PROBE de PSP, la respuesta es SI, de hecho se complementan.

Respecto de la pregunta de ¿porqué no usar PSP en lugar de COSMIC?, la respuesta es porque no son excluyentes, PSP es un proceso y COSMIC es estándar de medición de tamaño de la funcionalidad del software.

Referencias

[1] Watts S. Humphrey (2000), “The Personal Software Process SM (PSPSM), Technical report CMU/SEI-2000-TR-022, ESC-TR-2000-022, November 2000.

[2] Morgenshtern, O., T. Raz, and D Dovir (2007), “Factors affecting duration and effort estimation errors in software development projects,” Information and Software Technology, vol. 49, no. 8, August 2007, pp. 827-837.

[3] Bourque, Pierre, S. Oligny, A. Abran, B. Fourrnier. 2007. « Developing Project Duration Models in Software Engineering ». Journal of Computer Science and Technology, vol. 22, p. 348-357.

The post Mejorando el Personal Software Process (PSP) con el Método COSMIC first appeared on Spingere.

Como no tiene tiempo ni interés en aprender todo el tema contable (Leyes, Normas, Boletines, etc.), usualmente lo que hace es contratar a un contador que realiza la contabilidad, de manera simplificada solo consideraremos 2 escenarios, uno en el que el ingeniero de desarrollo contrata al contador solamente para hacer la declaración anual (escenario 1) y otro cuando lo contrata a un contador durante todo el año (escenario 2) para realizar las declaraciones mensuales y para hacer la declaración anual.

Escenario 1

En este escenario es claro ver que si se contrata a un contador solo para hacer la declaración anual, el resultado es tácito, solamente indicará si se tiene un saldo a pagar o un saldo a favor con base en los comprobantes que se juntaron en el año, no se puede hacer mucho al respecto.

Escenario 2

Por otro lado si se contrata al contador durante todo el año, y hace las declaraciones informativas con base en los comprobantes que se juntan en el mes e informa cada corte al ingeniero de desarrollo, es posible poder definir y ejecutar un estrategia fiscal, que permita o disminuir la cantidad a pagar o incluso tener saldo a favor.

Análisis

De esta forma tenemos que el proceso contable al ser repetitivo, requerir un alto grado de especialidad o capacidades específicas dado el amplio cuerpo de conocimiento existente, adicionalmente a que esta fuera de las funciones principales del ingeniero, con las que genera valor, por tal motivo es recomendable hacerlo vía outsourcing y durante todo el ciclo (escenario 2) generando así un mayor valor.

Hoy en día es común esta práctica tanto como personas físicas como en cualquier empresa de cualquier tipo, lo que genera que las personas como las empresas se enfoquen en lo que realmente es su fuerte y utilicen a su favor la información ( y asesoría fiscal) que se genera a través de los especialistas.

Analogía con el desarrollo de software

Ahora bien, en el ámbito de los proyectos de software, la mayoría de las personas y empresas (fábricas de software) que se dedican al desarrollo tienen como objetivo principal el desarrollar aplicativos o piezas de software, durante mucho tiempo han invertido sus esfuerzos en capacitarse y prepararse en administración de proyectos, en procesos y técnicas de desarrollo como CMMI y metodologías ágiles, herramientas de desarrollo, etc. Sin embargo, muy pocas empresas/personas han tenido capacitación formal en el dimensionamiento y estimación de proyectos, que son la base para poder hacer una adecuada administración de proyectos, sobre todo con un enfoque ingenieril.

Qué sucede entonces cuándo en una empresa se requiere estimar la duración, esfuerzo o costo de un proyecto, o determinar el número de errores promedio o su factor de productividad, el número de recursos requeridos para terminar el proyecto en tiempo, etc., bueno … pues no se tienen datos históricos derivado de que no se han hecho mediciones, por lo que las estimaciones para determinar costos y planeación de esfuerzos se realizan con base en juicio de experto alineado a las prácticas del PMI, pero que pasaría si la información que tuviera la PMO fuera cuantitativa? Bueno pues las decisiones serían más objetivas, y se podría hacer una mejor planeación, monitoreo desempeño de proyectos y control de estos.

Para contar con una base de datos se necesita empezar a medir, si nunca se empieza nunca se va a conseguir!, alguien dijo: ”la caminata más larga inicia con el primer paso”

En este sentido se crea el concepto de SAO® (Software Accountability Office), esta oficina ofrece un servicio similar al outsourcing de contabilidad (por eso su nombre), se enfoca en dimensionar, estimar y registrar los datos derivado de que la gente que la integra es especializada en esto, lo que hace que el personal de la fábrica de software no requiere tener una especialización en dimensionamiento y estimación, por el contrario va a poder utilizar las capacidades actuales en desarrollo de software y administración de proyectos, solo que contando con información cuantitativa.

El objetivo de la SAO® no es administrar los proyectos, es recabar de manera formal y continua información proporcionándola para la toma de decisiones objetiva, la SAO® solo se dedica a medir, estimar y registrar la información, tiene funciones muy acotadas que se puede integrar directamente a la PMO®, y es independiente de el proceso de desarrollo de software que utilicen las entidades. El esquema de una SAO® conceptualizado por SPINGERE se muestra a continuación.

Este esquema habilita la toma de decisiones objetivas por parte de las oficinas de proyectos de las distintas entidades, además de permitir la canalización de los esfuerzos en lo que realmente les interesa, logrando así eficiencia en costos dado que permite plantear esquemas eficientes de control de contratos y proyectos de software.

The post Concepto de Software Accountability Office (SAO ®) first appeared on Spingere.

Esta carrera tecnológica, ha existido siempre desde el inicio de la computación, siempre habrá cosas nuevas que en poco tiempo serán remplazadas, como se estableció en la Ley de Moore. Sin embargo, si observamos la realidad de los proyectos de software que también inició con la carrera tecnológica, el éxito de los proyectos de software es muy bajo desde siempre (actualmente < a 30% según Standish Group) con independencia de metodologías de desarrollo, lenguajes de programación o bases de datos más novedosas. ¿Por qué sucede esto?

Recientemente en una clase de Maestría, con la finalidad de que vieran, desde mi punto de vista la razón, les pedí un análisis a los alumnos sobre los procesos del Project Management Body of Knowledge, el famoso PMBoK, que se compone de 10 Knowledge Areas (áreas de conocimiento) y que contiene 47 Procesos, cada uno de los cuales tiene un conjunto de entradas, un conjunto de herramientas y técnicas que son utilizadas para transformar las entradas en un conjunto de salidas.

Comparto los resultados aquí:

Considerando la totalidad de los procesos la Herramienta que más es promovida a utilizarse por el cuerpo de conocimiento de la administración de proyectos es el famosísimo “Juicio de Experto” con 59.57% de apariciones, y el segundo lugar “Reuniones” con el 36.7%

Sin duda esto nos puede dar una idea de porque los proyectos de software fallan, seguimos haciendo artesanía, con muy buenos lenguajes y tecnología, pero no se puede considerar como un proceso ingenieril, ya que aún se depende de las personas que lo programaron porque no hay documentación adecuada, ni elementos cuantitativos o procesos ingenieriles que permitan darle continuidad, todo son opiniones de “expertos”.

Hace unos día vi una película “Moneyball 2011”, en esa película, un equipo de beisbol que pierde la serie mundial y su jugador estrella es comprado por otro equipo, por lo tanto el equipo tiene que hacer una reconstrucción, para lo cual el General Manager (Brad Pit) hace una reunión (justo como en el PMBoK) para preguntarle a los expertos (señores de edad avanzada con años de experiencia en el beisbol) ¿a quiénes contratarían?, este equipo de expertos esgrimiendo argumentos “subjetivos” abordan a varios jugadores hablando de cualidades no cuantificables y completamente subjetivas, aunque válidas desde su propia perspectiva. Hasta que el General Manager les hace un gesto de cansancio y desesperación. (ver escena1)

Al ver esta escena automáticamente me remonté a las reuniones de seguimiento de proyectos que he visto donde se menciona que el proyecto va retrasado porque ha habido cambios de alcance, porque es complejo un requerimiento, etc., o reuniones técnicas de equipos de desarrollo, donde se menciona que quizá es el manejador de base de datos, o que el lenguaje no permite hacer ciertas cosas, pero que un lenguaje nuevo “x” ya lo resolvió, o que el requerimiento no estaba claro, etc. Al parecer lo que importa es quien hace los comentarios más sobresalientes en términos de la moda de lenguajes o metodologías, quién puede demostrar que sabe más “subjetivamente” aunque nunca lo haya implementado, quien tiene una buena idea, o al menos quién convenza a los otros (usualmente el de mayor jerarquía), pero en realidad “NADIE PROPORCIONA DATOS” estandarizados que el encargado CIO, Project Manager, Líder de proyecto o Scrum Master, puedan usar de manera comparativa para la toma de decisiones.

En la trama de la película, el General Manager en la búsqueda de talento, va a negociar con un equipo el traspaso de algunos jugadores en una reunión de varias personas, recibe varias negativas, pero se da cuenta que las respuestas finales son consultadas con una persona al fondo de la reunión que es una persona joven de edad, contrastando con la situación que el tenía en su equipo.

Al salir de la reunión lo va a buscar y lo cuestiona de que hacía o cómo lo hacía. Este personaje le comenta que hay una falla epidemiológica en el juego, que hace que la gente de grandes ligas administre mal a sus equipos, se enfocan en comprar jugadores y no en comprar victorias (igual que en el software, muchas veces los CIO’s tratan de comprar lo más nuevo para solucionar las cosas, cuando los problemas son mucho más de fondo), para comprar victorias necesitan comprar carreras, y para esto se necesita tener los datos de qué jugadores generan más carreras, no quienes son mejores o más famosos a la vista de los “expertos”, los datos son crudos. (ver escena2)

Finalmente, este personaje se va a trabajar con el General Manager y a partir de los datos que genera hace una ecuación de predicción que identifica cuántas carreras deberían de permitir y generar, así como cuantos juegos deberían de ganar para llegar a la postemporada, con este objetivo y con la información de los jugadores de cuántas carreras generan o cuanto batean, etc., pudo armar un equipo con pocos recursos que le permitió llegar a la postemporada (ver escena3), finalmente no la ganó pero cambió la forma de ver el beisbol.

En el desarrollo de software lo que hemos estado proponiendo desde hace ya 14 años con el uso de métricas formales de software, es este cambio de paradigma, donde se pueda estimar los proyectos correctamente, hacer un seguimiento cuantitativo real de costo tiempo, alcance, que se pueda conocer la productividad, evaluar la calidad, la capacidad de planta de una fábrica de software, el nivel de producción de software en un momento dado, etc.

Sin embargo, muchas empresas y CIO’s solo lo ven como una moda u otra metodología más, que sin duda es más costosa de llevar a cabo correctamente, especialmente comparando con una metodología que puedes leer en una revista o libros de Sanborns y como todo es subjetivo puedes hacerte experto y/o promulgarte como experto, porque no hay forma de medirlo, en el caso de las métricas necesitas tener un enfoque ingenieril, conocer de matemáticas estadística y manejo de unidades, implica si o si utilizar medidas, alguien dijo “El nivel de madurez de una disciplina depende de la calidad de sus métricas”.

Si quieres cambiar la forma de tomar las decisiones de tus proyectos, e incrementar el éxito de estos, cambia la forma de hacer las cosas. www.spingere.com.mx

The post ¿Por qué son realmente importantes las métricas en el software? first appeared on Spingere.

The post GASTOS NO REALIZADOS Y NO COMPROMETIDOS EN EL DESARROLLO DE SOFTWARE first appeared on Spingere.

The post ¿ÁGILES O CASCADA CON COSMIC? first appeared on Spingere.