De hecho, según Standish Group, solo el 31% de los proyectos de software son completados en tiempo y presupuesto. Un número bastante bajo, ¿verdad?

Si sueles tener problemas asociados con retrasos en las entregas de tus proyectos de software o desviaciones de la planificación, este artículo es para ti. Continua leyendo para conocer algunos consejos prácticos para superar estos desafíos y asegurar entregas exitosas para mantener felices a tus clientes. 

3 problemas comunes a causa del retraso y desviaciones del cronograma de proyectos de software 

1. Aumento en los costos asociados con el proyecto, ya que se necesitan más recursos y horas de trabajo para completarlo.

2. Los retrasos en la entrega del proyecto pueden llevar a la insatisfacción del cliente y erosionar la confianza en tu empresa. Esto puede tener un impacto negativo en las relaciones comerciales a largo plazo.

3. Tu empresa perderá oportunidades clave en el mercado, especialmente si el proyecto está relacionado con un lanzamiento de producto o un evento importante.

De acuerdo con Standish Group, más de la mitad de los proyectos de software (53%) cuestan más de 190% de lo estimado originalmente y, por otro lado, según CISQ, el costo total de los proyectos de desarrollo de software fallidos entre las empresas estadounidenses se estima en $260 Billones de Dólares, es decir, cualquier retraso o falla puede convertirse en una consecuencia millonaria para tu empresa. 

Además, cuando los proyectos de software se retrasan o desvían del cronograma, los clientes se ven afectados en términos de tiempo y recursos. Los retrasos pueden llevar a esperas prolongadas para la implementación de nuevas funcionalidades o sistemas, lo que puede afectar sus operaciones diarias.

Esto puede provocar que los clientes tengan que destinar recursos adicionales para lidiar con la falta de un sistema, componente o funcionalidad específica, lo que puede generar costos adicionales y afectar su eficiencia.

“Cuida los minutos y las horas se cuidarán solas”

Lord Chesterfield

¿Cómo evitar retrasos en la entrega de tus proyectos de software?

Para garantizar que tu proyecto de software se mantenga en el rumbo correcto y evitar retrasos y desviaciones del cronograma, es fundamental implementar estas 3 prácticas en tu gestión:

1. Estimación precisa

Al inicio del proyecto, es crucial establecer expectativas realistas y asegurarte de que se asignen los recursos adecuados. Utilizando técnicas de estimación confiables, como la estimación por puntos de función COSMIC (ISO/IEC 19761), qué es el estándar más novedoso para medir el software, puedes determinar: 

El tamaño del proyecto en unidades comparables.

Asociar el costo unitario de tus proyectos con distintas características.

Medir y comparar la productividad de tus equipos y colaboradores.

Los esfuerzos y tiempos necesarios con mayor precisión.

Según Reporte de Standish Group, más del 50% de los proyectos de software son entregados con retrasos y una de las causas más relevantes es la falta de estimación precisa antes comenzar con el desarrollo del proyecto. 

2. Seguimiento regular

Esta práctica es esencial para identificar cualquier desviación temprana y tomar medidas correctivas de manera oportuna. Es importante que utilices herramientas adecuadas, basadas en datos comparables con independencia de tu metodología de trabajo para rastrear el avance del trabajo. Esto te ayudará a:

Establecer hitos y puntos de control

Evaluar el progreso el proyecto y compararlo con el plan inicial

Analizar constantemente el estado proyecto

Abordar cualquier problema o retraso identificado

3. Análisis de tendencias

Para finalizar, como última herramienta para tener control total de tus proyectos de software, está el análisis de tendencias, que consiste en examinar datos históricos de proyectos anteriores para detectar comportamientos que pueda afectar el proyecto actual, permitiéndote: 

Identificar patrones y áreas problemáticas recurrentes.

Tomar medidas preventivas.

Asignar más recursos o ajustar los plazos.

Planificar y estimar proyectos futuros más precisamente.

Imagina poder cumplir con todos tus objetivos al implementar proyectos de software y conocer exactamente los recursos que toma alcanzarlos

En Spingere, somos expertos en la medición y estimación de proyectos; y estamos comprometidos a ayudarte a evitar retrasos y desviaciones en tus proyectos de desarrollo de software. Nuestro enfoque basado en métricas formales y seguimiento continuo garantiza entregas exitosas y asegura la satisfacción de tus clientes.

La información es poder y estamos aquí para enseñarte cómo usarla a tu favor.

Solicita una cotización

The post Evita retrasos y desviaciones del cronograma en tu proyecto de software first appeared on Spingere.

De hecho, ¿Sabías que, según Standish Group, el 52,7% de los proyectos de software cuestan el 189% de sus estimaciones originales?

Responde si o no en tu cabeza las siguientes preguntas:

¿La mayoría del tiempo entregas tarde tus proyectos?

¿Los costos de tus proyectos son mayores que los estimados originalmente?

¿Sientes que los tiempos de entrega siempre son demasiado ajustados?

¿Te suenan familiares estos problemas? En este artículo, exploraremos la importancia de contar con una estimación precisa y los desafíos más comunes que debes enfrentar para asegurar el éxito de tus proyectos de desarrollo de software.

¿Por qué es importante la estimación precisa de tiempo y costos en proyectos de desarrollo de software?

Imagina que estás construyendo una casa para tu familia. Sin una estimación de tiempos y costos, podrías enfrentarte a una construcción que se extiende eternamente, por lo que comenzarás a notar que los trabajadores parecen estarse tomando vacaciones en vez de trabajar y que las facturas comienzan a llegar cada vez más grandes y más seguidas. 

La estimación precisa de tiempos y costos en proyectos de desarrollo de software funciona de manera similar. Permite que tú, como dueño, gerente de la empresa o encargado del proyecto, planifiques y organices los recursos adecuados, desde el personal hasta el presupuesto, ayudándote a mantener un control sólido sobre el proyecto, evitando que se convierta en una montaña rusa de sorpresas desagradables.

En efecto, de acuerdo con Mckinsey, el 17% de los grandes proyectos de TI van tan mal que amenazan la existencia misma de la empresa.

Sin embargo, cuando tienes una estimación precisa en tus manos, puedes tomar decisiones informadas y estratégicas para asignar tareas y recursos de manera eficiente, sabiendo exactamente cuánto tiempo se requerirá para cada etapa del proyecto y cuánto dinero necesitarás para llevarlo a cabo. 

Conoce los 3 desafíos más comunes asociados a la estimación de proyectos de software

1. Cambios en los requisitos

Suele pasar que tus clientes comprendan mejor sus necesidades durante el desarrollo del proyecto o que surjan oportunidades que requieran cambios en su alcance. Por ejemplo: tu equipo está desarrollando una aplicación móvil y, de repente, el cliente indica que también necesita una versión para tabletas. Esto implica ajustar la estimación original para incluir el tiempo adicional necesario para el desarrollo y las pruebas en múltiples dispositivos; y lidiar con estos cambios de manera efectiva puede ser todo un desafío. 

2. Complejidad técnica

La mayoría de los proyectos de desarrollo de software traen consigo un desafío técnico, como por ejemplo:

Integración con sistemas existentes

El uso de tecnologías nuevas o no probadas

La necesidad de cumplir con estándares y regulaciones específicas

De hecho, no entender los requisitos y, por tanto, dar requisitos imprecisos es la segunda razón más importante del fracaso de un proyecto de software.

3. Falta de datos históricos confiables

Por ejemplo, si estás trabajando en el primer proyecto de una nueva línea de productos o utilizando una tecnología completamente nueva, es posible que no tengas datos históricos relevantes para respaldar tus estimaciones. 

¿Cómo la estimación precisa puede ayudarte a superar estos desafíos?

Muchas empresas no comprenden la necesidad de implantar soluciones de gestión de proyectos y esto incluye realizar estimaciones precisas de tiempos y costos de operaciones. Dicho esto, es importante resaltar los beneficios que puedes obtener al implementar una estimación precisa de tus proyectos de desarrollo de software:

Proporciona una base sólida para evaluar el impacto de los cambios.

Ayuda a identificar los riesgos técnicos y establecer planes de mitigación adecuados.

Permite tomar decisiones informadas utilizando enfoques alternativos en caso de falta de datos.

DEJA DE PERDER TIEMPO Y DINERO EN TUS PROYECTOS DE SOFTWARE

El hecho de que sea “muy normal” que tus proyectos de software suelen salirse de control en cuanto al tiempo de entrega o costos estimados, no quiere decir que sea una situación tolerable.

En Spingere, nos especializamos en brindarte el conocimiento preciso sobre los recursos necesarios para el desarrollo de tu software. Contamos con un equipo de profesionales expertos en medición y estimación que te proporcionarán un control total sobre los tiempos y costos estimados de tus proyectos. Nuestro objetivo es ayudarte a evitar sorpresas costosas e inesperadas a lo largo de tu proceso de trabajo y convertirnos en tu aliado para el desarrollo de software exitosos. 

Solicita una cotización

The post Tiempos y costos descontrolados en proyectos de software: ¿Cómo estimar con precisión para evitar sorpresas costosas? first appeared on Spingere.

En este primer artículo se describirá brevemente la historia de los métodos de medición de tamaño funcional para tener un contexto inicial.

Historia resumida de los Métodos de Medición de Tamaño Funcional del Software

La mayoría de las personas involucradas en el desarrollo de software ya sea de un área interna o una casa de software reconocen que medir en el software es fundamental, la frase “Si no lo puedes medir no lo puedes controlar” es dicha con mucha más frecuencia que lo que realmente se aplica.

Sin embargo, ¿qué es lo que se puede medir del software?, cada organización puede definir elementos a medir del software que realiza en función de sus prácticas y experiencias, sin embargo, esto no permite comparaciones con otras organizaciones o industrias, en virtud de que las unidades de medición son distintas.

En los años 70’s (30 años aproximadamente) Allan J. Albrecht’s desarrolló una forma de medición funcional del software independiente de la plataforma de desarrollo y que consideraba el punto de vista del usuario, actualmente llamada Function Points (IFPUG Method), ésta técnica de medición considera conceptos vigentes para aquel tiempo cómo archivos lógicos, además tiene un alcance solo para aplicaciones de tipo MIS (Management Information System), en la actualidad existe una gran variedad de aplicaciones no solo las MIS, como lo son en tiempo real, ERP, DWH, etc.

Más tarde a finales de los años 80’s (20 años aproximadamente) surgió un método llamado Mark II, este método estaba basado en transacciones lógicas y en el modelado de relaciones de entidades, populares en ese tiempo. Estos dos, y otros métodos como: 3D Function Points, Feature Points, FISMA, etc., son considerados de la primera generación de modelos de Medición de Tamaño Funcional (FSM: Functional Size Measurement).

Todos estos métodos se generan a partir de estudios estadísticos realizados en alguna empresa, el análisis de los proyectos expresa en sus resultados, la manera de operar de la empresa para los tipos de proyectos analizados, cuando se trata de utilizar en alguna otra empresa o con otro tipo de proyectos, usualmente los resultados no son buenos, la razón resulta obvia.

¿Por qué tamaño funcional del software?, solo hay un estándar internacional (ISO 14143) que proporciona los meta-estándares que describen el concepto y prácticas de FSM. Dicho de otra forma, si queremos medir algo del software y poder compararlo o compararnos debe de ser el tamaño funcional, ya que es el único estándar para medir una característica del software, claro con alguna de las técnicas o estándares internacionalmente aceptados para esto.

La segunda generación de métodos de FSM está representada por COSMIC (Common Software Measurement International Consortium), este estándar se generó considerando como base el estándar ISO 14143 y la experiencia de los métodos de la primera generación, lo que implica que resuelve la mayoría de los problemas presentados dichos modelos como el manejo de conceptos actualmente no vigentes, el alcance de aplicación de los métodos y una escala de medición más práctica y homogénea, aunado a lo anterior tiene un dominio de aplicación mayor, por lo que se puede utilizar para todo tipo de software vigente al día de hoy, teniendo consideraciones para aquel software de gran complejidad algorítmica, pero esto es igual para cualquier estándar de medición, en virtud de que al día de hoy no existe un estándar para determinar cuantitativamente la complejidad del software.

Figura 1. Historia de los métodos de medición de tamaño funcional

Email secured by Check Point

The post Historia Breve de los Métodos de Medición de Tamaño Funcional del Software first appeared on Spingere.

¿Qué pasaría si en los planos no vinieran medidas? Es muy probable que la construcción de la casa fuera un caos, por que las ventanas no serían del tamaño correcto, o la loza, o 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).

“According to testimony by the Government Accountability Office last September, if were established more realistic baselines of requirements, cost, schedule and risk during project’s planning phases, nearly half of canceled or over budget IT programs could be avoided. That would save $5.5 billion annually, according to a study made by Price Systems LLC, a software and consulting company in Mount Laurel, N.J., USA. The study consider 104 Government IT executives” (PMI, 2007)

Muchas personas involucradas en la industria del software tienen una idea errónea acerca de la medición del software, consideran que no se puede medir ya que es algo intangible, que es algo intelectual por lo que medirlo sería muy complejo, etc. 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 del software 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 entonces, 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 importantes que se le pueden dar a una medición de tamaño funcional adecuada.

Estimación de proyectos

La estimación de proyectos es my 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 son confiables.

Medición del desempeño del proyecto

En cualquier industria la habilidad para medir 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 cómo en cualquier otra industria es muy importante, todos quisiéramos que las organizaciones fueran más productivas, que las áreas de software fueran más productivas, es más que los programadores o desarrolladores fueran más productivos. Pero ¿qué significa esto?, bueno 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

Actualmente 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, con una negociación se determina el precio final.

Si se tuviera 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 reuinicia 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, al ser hoy en día 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, ya que ayuda entre otras cosas a : la estimación de proyectos, medición del desempeño del proyectos, control del alcance de los proyectos, y control de contratos de software.

Special Interest Group on COSMIC / México

The post Importancia de la Medición de Tamaño Funcional del Software 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.

Cuando se inició a desarrollar el software cada persona lo hacía como podía, y se empezaron a presentar algunos problemas, como, por ejemplo, que pasa si una persona se va de la empresa y alguien más debe de continuar su trabajo, cómo entiende lo que quiso hacer o hizo, o si hay alguien que hace desarrollos de software y frecuentemente lo hace bien ¿por qué no los demás pueden seguir los mismos pasos? O ¿qué pasa si alguien tiene que dar un mantenimiento a un software después de mucho tiempo? O ¿cómo definimos los requerimientos que debe cumplir el software?, en fina muchas preguntas se fueron haciendo y respondiendo conforme se avanzó en el entendimiento y la necesidad de generar software más complejo y de mayor calidad, naciendo así la Ingeniería de software.

Se entendió entonces que, así como en otras industrias, para ser más productivos era necesario automatizar, pero ¿qué puedes automatizar cuando los que transformas los insumos son personas?, bueno se automatizan las prácticas, es decir se generan procesos repetibles y susceptibles de mejorarse de manera continua.

Hay que notar que en ningún momento se elimina a las personas, de hecho, son parte fundamental ya que tienen que transformar los insumos para poder producir el software, es decir, cada persona hace algunas actividades utilizando su conocimiento y habilidades. Entonces  ¿para qué definir un proceso si cada uno lo va a realizar como quiera? Esta es la clave del tema, los procesos son definidos para garantizar que se hacen las mismas actividades y se generan los mismos productos en cada una de ellas, no significa necesariamente que se harán exactamente igual, ya que depende de cada persona, lo que garantizan es que a la salida vas a tener lo mismo.

Consideremos como proceso mínimo, las actividades que se deben de realizar para desarrollar un software independientemente de cualquier metodología, las cuáles se basan en los principios definidos en el SWEBOK (https://www.computer.org/education/bodies-of-knowledge/software-engineering), podemos mencionar que dichas actividades son: definir requisitos del software, analizar y diseñar la solución, codificación, y probar el software.

Si se define una funcionalidad a ser desarrollada por 3 equipos distintos, donde cada uno de ellos realizará de manera independiente las actividades antes mencionadas, al final del día tendremos la funcionalidad propuesta, unos terminarán antes y otros después, las soluciones no serán las mismas, los artefactos generados, diagramas y algoritmos no son iguales, pero la funcionalidad debería de ser la misma.

Justo así funciona la medición de software, de hecho, lo que se puede medir es la funcionalidad, hasta el momento no puedes interpretar como una persona piensa y desarrolla un algoritmo, o un diagrama entidad relación, pero lo que si puedes medir es que un cierto tamaño de funcionalidad conlleva más o menos esfuerzo para hacer el diseño, o la codificación en función de la plataforma o de la metodología o de la persona que lo hace.

No podemos medir lo que pasa en el cerebro, y está bien, eso es lo que hace que se tenga software mediocre y también excelente o innovador. Pero lo que es necesario es medir y principalmente la funcionalidad porque existe una relación que, a mayor funcionalidad, mayor esfuerzo es necesario para desarrollarla.

Por otro lado, el software hoy en día está completamente involucrado en la industria, es decir, los negocios, por ejemplo, bancos, aseguradoras, farmacéuticas, empresas de retail, etc., desarrollan o contratan software para implementar sus proyectos de transformación, y es fundamental para ellos estimar costos, hacer casos de negocio, priorizar algunas iniciativas sobre otras y en general obtener una rentabilidad de cada proyecto de software, si no se mide el software, esto no se puede llevar a cabo de una forma profesional, se va a hacer de manera subjetiva generando que los proyectos fracasen y sean más costosos, hay una estadística que indica que prácticamente todas las empresas han tenido en un año al menos un proyecto de software que fracasó.

SPINGERE es una empresa enfocada en dar servicios de medición y estimación profesional de software desde hace más de 14 años, incrementando la rentabilidad de los proyectos en más de 200%, aumentando la velocidad en que se hacen las estimaciones y la precisión de estas, si quieres obtener resultados diferentes, haz cosas diferentes, visita los testimonios de distintos clientes que ya han obtenido resultados tangibles. https://spingere.com.mx/testimonios

Dr. Francisco Valés Souto

Fundador de SPINGERE y la Asociación Mexicana de Métricas de Software (AMMS)

“La realidad de tus proyectos de software en métricas”

The post ¿El software se puede medir en realidad? ¿Qué no es un proceso intelectual? 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.