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.

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.

¿Cómo puedo acceder a esas tecnologías?

Las anteriores son interrogantes que surgen generalmente por los responsables de hacer las estimaciones de desarrollo de proyectos de software y que además tienen conocimiento de la existencia de métricas para medir y posteriormente estimar los requisitos funcionales de usuario y que también saben o han escuchado que la parte de los NFR si es posible estimarlos con modelos formales.

En este blog hablaremos con más detalle acerca de una tecnología llamada EPCU [1] (Estimación de proyectos en contextos de incertidumbre). El modelo EPCU permite contextualizar y formalizar cualquier proceso humano que implique la toma de decisiones a partir ciertas entradas y de un proceso de razonamiento determinado para proporcionarnos una o varias variables de salida continuas (no binarias).

El formalismo matemático atrás del modelo EPCU es lo que se conoce como lógica difusa, la cual es una rama de la inteligencia artificial que le permite a una computadora analizar información del mundo real en una escala continua entre lo falso y lo verdadero (0,1), permitiendo manipular conceptos humanos imprecisos, como “caliente” o “húmedo”, y permite a los ingenieros construir dispositivos que juzgan la información difícil de definir de manera consistente.

Debido a la naturaleza del formalismo matemático de lógica difusa que está atrás del modelo EPCU, es que este modelo es idóneo para poder modelar contextos que permitan estimar NFR, primero porque son requerimientos que no se pueden medir con un estándar de medición y segundo porque representan requisitos bastante imprecisos y difíciles de definir; pero que sin embargo se pueden contextualizar de forma muy natural con lógica difusa.

El modelo EPCU implica 6 pasos para modelar un componente formal (contexto) que permita la toma de decisiones en un determinado ambiente de decisiones, como es el caso de la estimación de requerimientos no funcionales. Los pasos del modelo son los siguientes:

1. Identificación de las variables de entrada: El objetivo de este paso es obtener las variables más significativas para un determinado problema de toma de decisiones.
2. Identificación de las variables de salida: El objetivo de este paso es obtener la o las variables de salida que representan la acción de la toma de decisión a través de un valor continuo; por ejemplo, en el caso de los NFR es el valor que se está estimando, muy probablemente en horas hombre.
3. Fuzificación:  El objetivo de este paso es transformar los valores de las variables de entrada, a través de funciones de membresía, al dominio del mundo difuso para poder trabajar con ellas.
4. Generación de las reglas de inferencia: Es la combinación de las variables de entrada para tomar las diversas decisiones necesarias; es aquí donde se modela la inteligencia del fenómeno o proceso que se requiere formalizar.
5. Evaluación de las reglas de inferencia: Es aquí donde existe el motor de lógica difusa que permite calcular una inferencia a partir de ciertas reglas.
6.  Defuzificación: En este paso se transforma el resultado generado por el motor de inferencia y las reglas de inferencia, el cual aún está en el dominio difuso, hacia el dominio del mundo real del problema, es decir a un valor útil de la variable de salida, por ejemplo, en el caso de los NFR un valor de horas hombre estimadas.

De manera gráfica podemos visualizarlo como se muestra en la siguiente figura:

En consecuencia, con esta tecnología entre muchas otras cosas es posible estimar el esfuerzo y/o costo de los NFR de manera formal usando modelos matemáticos consistentes; más aún si trabaja de la mano con estándares que hacen una adecuada clasificación de los NFR como por ejemplo el “ISO/IEC 25010:2011 System/Software Product Quality model” [2], que agrupa en 9 categorías la forma en que se compone la calidad del producto de software.

Existen otros estándares y manuales como: IEEE Std 830-1998: Software Requirements Specifications; IFPUG Software Non-functional Assessment Process (SNAP) Asse Release 2.2ssment Practices Manual; COSMIC Guideline on Non-Functional & Project Requirements. Version 1.0; European standard ECSS-E-ST-40C – Software general requirements, etc.; que nos pueden ayudar a identificar las variables de entrada para un determinado contexto de estimación usando el modelo EPCU.

Los estándares y manuales citados anteriormente nos permiten disponer de un listado y una clasificación bastante bien definido de NFR que son comunes en los desarrollos de software; sin embargo, no son ni métodos ni modelos para estimar NFR; sin embargo, EPCU es un modelo que permite generar contextos flexibles para estimar en entornos de incertidumbre, como en el caso de los NFR, de forma tal que EPCU se puede convertir en un elemento esencial para llevar a la práctica las estimaciones formales del esfuerzo requerido por los NFR, al menos en lo que se definen estándares para esto.

La plataforma tecnológica MENSURA® desarrollada por SPINGERE; permite la habilitación de cualquier modelo EPCU (contexto) para poder estimar cualquier tipo de NFR; para más información consultar https://mensura.com.mx/.

[1] Design of A Fuzzy Logic Estimation Process for Software Projects: Estimation of Projects in a Context of Uncertainty EPCU Model by Francisco Valdés Souto (Aug 23, 2012), ISBN: 978-3-659-19774-1, Lap Lambert Pub.

[2] ISO/IEC 25010:2011, Systems and software engineering – Systems and software Quality Requirements and Evaluation (SquaRE) – System and software quality models.

Jorge Valeriano Assem.

Francisco Valdés Souto.

The post Uso del modelo EPCU para estimar requisitos no funcionales (NFR) first appeared on Spingere.