# data[].attributes.attachment_link.title
🚀 Ley de Parkinson - Aprendizaje Ágil del día en 2 min (fast & furious) 🚀

# data[].attributes.body
Una vez identificado el alcance del proyecto, el método de estimación descendente desglosa dicho alcance en fases, trabajos y tareas, según la estructura de desglose del trabajo (WBS).

Con este método de estimación, las partes interesadas​​con una visión ambiciosa pueden establecer un cronograma o presupuesto general para un proyecto sin conocer todos los detalles. Luego, se puede dividir el plan en partes más pequeñas y delegar los detalles a aquellas personas con más conocimiento acerca de las especificaciones del proyecto.

Supongamos, por ejemplo, que tu empresa está planificando el lanzamiento de un producto nuevo en los próximos seis meses. Esta iniciativa involucraría a casi todos los equipos, desde desarrolladores hasta especialistas en marketing. Dado que conoces el cronograma general, puedes desglosar el proyecto en fases más pequeñas con cronogramas individuales asignados a equipos específicos.

# data[].attributes.body
A diferencia de la estimación descendente, el método de estimación ascendente analiza primero las fases individuales del proyecto para luego definir el cronograma o el presupuesto general.

Por lo general, se prefiere una estimación ascendente a una estimación descendente, ya que las personas que realizan el trabajo son las mismas que establecen el cronograma y el presupuesto. También es más probable que se realicen estimaciones más precisas.

Si consideramos el ejemplo anterior, es posible que te preguntes por qué este equipo de gestión optó por un cronograma de seis meses para el lanzamiento del producto. Si la gerencia hubiera consultado primero con cada uno de los departamentos, tal vez habría llegado a la conclusión de que ocho meses era un plazo más realista.

Si bien el método de estimación ascendente no siempre es una opción cuando los plazos o los presupuestos son ajustados, los gerentes generalmente lo prefieren al método de estimación descendente. Sin embargo, aunque este método es más preciso, lleva un poco más de tiempo armarlo.

# data[].attributes.body
El método de estimación de tres puntos toma un promedio de tres cifras para determinar el esfuerzo necesario para completar una tarea individual:

Tu mejor estimación

Tu estimación optimista

Tu estimación pesimista

Esta técnica se suele combinar con el método ascendente para crear estimaciones aún más precisas.

Por ejemplo, supongamos que estás planificando la fase de desarrollo de tu producto. Si todo sale según lo planeado, deberías tener una versión beta dentro de tres semanas (tu mejor estimación). Si el equipo obtiene la aprobación para el uso de un software más potente, entonces el desarrollo podría tomar tan solo dos semanas (tu estimación optimista). Pero si se presentan varios mensajes de error o fallas, esta fase podría demorar hasta cinco semanas (tu estimación pesimista).

Si realizas un promedio de las estimaciones de tres, dos y cinco semanas, puedes predecir que la tarea tomará alrededor de tres semanas y media.

# data[].attributes.body
La estimación paramétrica también utiliza datos históricos de proyectos anteriores similares, pero además tiene en cuenta las diferencias entre los proyectos pasados ​​y el proyecto actual.

Para esta técnica se usa un conjunto de algoritmos para calcular la estimación. Supongamos que tu equipo de marketing tardó cuatro semanas en desarrollar la campaña para el último lanzamiento de producto. Este proyecto se realizó hace un año y, actualmente, tu equipo cuenta con el doble de colaboradores. Si todos los miembros del equipo están involucrados en la campaña, puedes suponer que esta vez solo tomará dos semanas completar la misma tarea.

# data[].attributes.body
El juicio de expertos suele ser el método más rápido y sencillo, ya que se basa en la “intuición” de un experto para estimar los proyectos.

Este método tiene en cuenta las habilidades, la experiencia y los conocimientos especializados al momento de realizar una estimación. Es posible que debas colaborar con otros miembros de tu equipo, partes interesadas del proyecto, consultores o expertos en la materia para obtener la información que necesitas.

El juicio de expertos es un método útil si tienes como prioridad evaluar las respuestas a los riesgos o las oportunidades del proyecto. Sin embargo, ten en cuenta los sesgos que podrían distorsionar tus datos, como el exceso de confianza.

# data[].attributes.headline
Estimación de costos en el desarrollo de un sistema de gestión documental

# data[].attributes.subject
Estimación de costos en el desarrollo de un sistema de gestión documental

# data[].attributes.body
El proyecto

Este proyecto consistía en desarrollar un sistema de gestión documental para una empresa de logística. El sistema debía permitir el almacenamiento, búsqueda y consulta de documentos relacionados con operaciones de transporte y gestión de cargas, incluyendo funcionalidades para la gestión de facturación, cálculos de almacenamiento y búsqueda avanzada de información. Además, el sistema debía cumplir con regulaciones de seguridad y contar con mecanismos de firma electrónica para la autenticación de documentos.

Al igual que en el ejemplo anterior, la descripción inicial del proyecto era bastante general y no definía con precisión todos los requerimientos. A pesar de esta ambigüedad, la empresa solicitó una cotización que incluyera estimaciones de tiempo, esfuerzo y costos.

Contexto del proyecto

El equipo encargado del proyecto tenía experiencia en el desarrollo de software para la gestión de inventarios, pero carecía de un conocimiento profundo en las regulaciones específicas del sector de la logística y los requerimientos tecnológicos relacionados con la firma electrónica y la seguridad documental.

Además, el líder del proyecto estaba asignado simultáneamente a otros dos proyectos, lo que limitaba su capacidad para supervisar este nuevo desarrollo de manera integral.

Herramientas utilizadas para la estimación

La organización empleó una combinación de técnicas empíricas basadas en la experiencia previa y herramientas automatizadas para calcular los puntos de función (IFPUG) y los puntos de casos de uso (UCP). La estimación se apoyó en hojas de cálculo de Excel, en las que se documentaron las horas de trabajo necesarias según la complejidad de las funcionalidades solicitadas, basándose en proyectos similares previos.

También se utilizó una técnica de estimación "bottom-up", donde se desglosaron todas las tareas en elementos individuales, lo que permitió calcular de manera detallada las horas de trabajo de cada especialista involucrado en el proyecto.

Resultados

Inicialmente, la estimación de tiempo y esfuerzo fue de 7 meses, con un costo total estimado en $200,000. Sin embargo, varios factores no previstos retrasaron la entrega final del proyecto:

1. Falta de conocimiento del equipo: Al igual que en el ejemplo anterior, el desconocimiento del equipo sobre el dominio específico del negocio y las tecnologías clave retrasó el desarrollo de ciertas funcionalidades, en particular las relacionadas con la firma electrónica y la seguridad documental.

2. Problemas de gestión: La baja disponibilidad del líder del proyecto, junto con la inexperiencia del suplente, dificultó la coordinación efectiva del equipo y la resolución de problemas técnicos.

Como resultado, el proyecto se extendió a 11 meses, con un costo final de $350,000, lo que representó un incremento del 75% sobre el costo estimado y un retraso del 57% en el tiempo de entrega. Este retraso generó tensiones en la relación con el cliente, lo que implicó renegociaciones complejas y pérdida de confianza.

Conclusiones

Este caso demuestra la importancia de realizar estimaciones realistas, considerando la complejidad del dominio y las tecnologías involucradas. Además, subraya la necesidad de contar con un equipo que tenga experiencia en el área específica y con un liderazgo que pueda dedicar tiempo suficiente al proyecto para garantizar su éxito.

Las estimaciones empíricas, aunque útiles como punto de partida, no siempre capturan todos los factores que pueden impactar el proyecto. Por ello, es recomendable combinar estas estimaciones con técnicas más formales y robustas que permitan contemplar todos los posibles riesgos y desajustes.

# data[].attributes.body
La estimación análoga consiste en utilizar datos de proyectos previos similares para estimar el costo de un proyecto actual. Es una técnica rápida y de bajo costo que resulta útil cuando se dispone de información fiable sobre proyectos similares y cuando los nuevos proyectos tienen características, alcances y tamaños semejantes. Sin embargo, esta técnica puede no ser muy precisa, ya que los proyectos pueden diferir en aspectos cruciales que no se reflejan en los datos históricos. La estimación análoga se basa en la experiencia del equipo y en la capacidad para identificar similitudes relevantes entre proyectos.

# data[].attributes.body
El análisis de reserva implica la adición de un margen o colchón al presupuesto estimado para cubrir riesgos o incertidumbres que no han sido considerados directamente en la planificación. Las reservas se pueden clasificar en dos tipos:

Reserva para contingencias: Se utiliza para cubrir riesgos conocidos que podrían materializarse, como demoras o problemas técnicos específicos.

Reserva de gestión: Es para riesgos desconocidos o imprevistos que pueden surgir durante la ejecución del proyecto. Este análisis es fundamental para proyectos que presentan altos niveles de incertidumbre o donde se anticipan cambios potenciales en el alcance, tecnología o recursos.

# data[].attributes.body
La estimación de costos directos e indirectos se refiere a la identificación y asignación de diferentes tipos de costos dentro de un proyecto de software:

Costos directos: Son aquellos que se pueden rastrear directamente hasta una actividad específica del proyecto, como los salarios de los desarrolladores, licencias de software, equipos y materiales.

Costos indirectos: Son aquellos que no están directamente asociados a una actividad particular del proyecto pero que son necesarios para su operación, como alquileres de oficina, servicios generales, costos administrativos y de gestión. Esta distinción es importante para asegurar que todos los gastos se tomen en cuenta y se reflejen en la estimación total del proyecto.

# data[].attributes.body
El costo de la calidad incluye todos los gastos relacionados con asegurar que el producto cumple con los estándares de calidad establecidos. Se clasifica en dos grandes áreas:

Costos de prevención: Son aquellos asociados a evitar defectos antes de que ocurran, como capacitación, diseño robusto y pruebas durante el desarrollo.

Costos de fallos: Se dividen en internos (corrección de errores antes de la entrega) y externos (costos asociados a corregir problemas que detecta el cliente después de la entrega, lo que incluye garantías y reclamaciones). Invertir en prevención es clave para reducir el costo de los fallos externos, que suelen ser los más costosos y los que más afectan la relación con el cliente.

# data[].attributes.headline
Estimación de Puntos de Función (Function Point Analysis)

# data[].attributes.subject
Estimación de Puntos de Función (Function Point Analysis)

# data[].attributes.body
La Estimación de Puntos de Función es un método para estimar el tamaño funcional de un proyecto de software basado en la cantidad de funcionalidades que se entregarán al usuario. Cada funcionalidad se mide en términos de entradas, salidas, consultas y almacenamiento de datos. Los puntos de función son una medida independiente de la tecnología utilizada y del lenguaje de programación, lo que los convierte en una técnica útil para comparar proyectos de distintos tipos y para predecir el esfuerzo necesario para completarlos. Los puntos de función permiten una estimación más objetiva y se correlacionan con el esfuerzo, tiempo y costo requerido para el proyecto.

# data[].attributes.headline
Estimación Basada en Casos de Uso (Use Case Points)

# data[].attributes.subject
Estimación Basada en Casos de Uso (Use Case Points)

# data[].attributes.body
La estimación basada en puntos de casos de uso (UCP) se utiliza para medir el esfuerzo necesario para implementar un sistema basado en la cantidad y complejidad de los casos de uso identificados en el proyecto. Un caso de uso es una descripción detallada de cómo un usuario interactuará con el sistema. Los puntos de casos de uso se calculan asignando pesos a los casos de uso según su complejidad (simple, promedio o complejo) y sumando estos puntos para obtener una estimación del esfuerzo necesario. A este número se le aplican factores de ajuste, como la experiencia del equipo y la complejidad técnica, para refinar la estimación.

# data[].attributes.body
El modelo COCOMO (Constructive Cost Model) es un método algorítmico para estimar los costos de desarrollo de software basado en la cantidad de líneas de código (LOC) esperadas. COCOMO tiene tres niveles:

COCOMO Básico: Proporciona una estimación general basada en el tamaño del software.

COCOMO Intermedio: Ajusta la estimación teniendo en cuenta factores adicionales como la experiencia del equipo y la complejidad del producto.

COCOMO Detallado: Desglosa el proyecto en componentes más pequeños y calcula el esfuerzo para cada uno, lo que permite una mayor precisión en proyectos complejos. COCOMO se ajusta según la categoría del proyecto (orgánico, semidesarrollado o embebido) y es ampliamente utilizado para proyectos de gran envergadura.

# data[].attributes.attachment_link.title
COMO ESTIMAR LOS COSTOS DE UN PROYECTO - Examen PMP®

# data[].attributes.headline
Análisis de Recursos Humanos Disponibles

# data[].attributes.subject
Análisis de Recursos Humanos Disponibles

# data[].attributes.body
El análisis de recursos humanos disponibles es una técnica que se utiliza para evaluar y optimizar el uso del personal que ya está dentro de la organización antes de considerar la contratación de nuevos recursos. Implica un examen exhaustivo de las habilidades, competencias, experiencia y disponibilidad del equipo actual. Este análisis permite identificar:

Compatibilidad de habilidades: Evalúa si el personal existente posee las habilidades técnicas necesarias para completar el proyecto, como conocimiento de lenguajes de programación específicos, herramientas de diseño o metodologías ágiles.

Disponibilidad del personal: Determina si el equipo tiene suficiente tiempo disponible para dedicarse al proyecto sin comprometer sus responsabilidades actuales. Esto incluye revisar cargas de trabajo previas y otros proyectos en los que estén involucrados.

Necesidad de capacitación: Si el análisis revela que el personal existente no tiene todas las habilidades necesarias, se puede considerar ofrecer formación o adquirir nuevas competencias, lo que puede ser más rentable que contratar nuevo personal.

Redistribución de recursos: En lugar de contratar más personas, se puede redistribuir el personal dentro de la organización para cubrir las necesidades del proyecto. Esto puede implicar mover empleados de otras áreas menos críticas a roles más necesarios en el nuevo proyecto.

Este enfoque busca maximizar la eficiencia de los recursos internos y minimizar los costos asociados a la contratación o la subcontratación.

# data[].attributes.headline
Técnica Delphi para la Estimación de Personal

# data[].attributes.subject
Técnica Delphi para la Estimación de Personal

# data[].attributes.body
La técnica Delphi es un método colaborativo que se utiliza para obtener estimaciones de manera sistemática a partir de un grupo de expertos. Se caracteriza por un proceso iterativo que busca alcanzar un consenso a través de rondas de estimación anónima y retroalimentación. En el contexto de estimación de personal, sigue estos pasos:

1. Selección de expertos: Se reúne a un grupo de personas con experiencia en proyectos similares y se les solicita que hagan una estimación independiente sobre el número de personal necesario para el proyecto en cuestión.

2. Primera ronda de estimaciones: Cada experto proporciona su estimación de manera anónima, lo que minimiza la influencia de opiniones dominantes y permite que cada miembro del grupo se base únicamente en su experiencia.

3. Análisis y retroalimentación: Se compilan las estimaciones y se devuelve un resumen estadístico al grupo, que incluye los valores medios, máximos y mínimos. Los expertos reciben este resumen, junto con justificaciones anónimas de otros expertos sobre sus estimaciones.

4. Segunda ronda: Basándose en los resultados de la primera ronda, los expertos pueden ajustar sus estimaciones si consideran que los argumentos presentados por sus colegas son válidos o relevantes. Este proceso se repite hasta que se llega a un consenso o las estimaciones comienzan a converger.

5. Decisión final: Se toma como resultado la estimación consensuada, que refleja una visión más equilibrada, basada en múltiples perspectivas expertas.

La técnica Delphi es especialmente útil para proyectos complejos o inciertos, donde no hay datos históricos precisos que permitan realizar estimaciones cuantitativas directas. Al involucrar a un panel de expertos, se incrementa la precisión de la estimación y se tiene en cuenta una gama más amplia de factores y riesgos potenciales.

Esta técnica es reconocida por su capacidad para reducir el sesgo en las estimaciones, mejorar la calidad de las decisiones, y proporcionar una estimación colaborativa que tiene un alto grado de confianza.

# data[].attributes.attachment_link.title
¿Cómo Estimar los Recursos del Proyecto?

# data[].attributes.body
Charette, R. N. (2005). Why Software Fails: A Conversation with the Author of the New Book 'Why Software Fails'. IEEE Software, 22(3), 12-14. https://doi.org/10.1109/MS.2005.68

Jørgensen, M. (2004). Software Development Effort Estimation: A Study of Expert Judgments. Journal of Systems and Software, 73(2), 151-160. https://doi.org/10.1016/j.jss.2003.12.015

Karlsson, J., & Ryan, K. (1997). Requirements Engineering in Practice. IEEE Software, 14(6), 33-39. https://doi.org/10.1109/52.646183

Land, L. J., & G. D. (2015). Estimating the Cost of Software Development: A Survey of Practices. Software Quality Journal, 23(1), 37-57. https://doi.org/10.1007/s11219-014-9266-7

Sommerville, I. (2016). Software Engineering (10th ed.). Pearson. https://www.pearson.com/us/higher-education/program/Sommerville-Software-Engineering-10th-Edition/PGM32993.html

Valdes, F. (s. f.). Estimación de proyectos de software: Un problema, una solución. SG Buzz. https://sg.com.mx/revista/32/estimacion-proyectos-software

Team Asana. (2024, 28 enero). ¿Qué son los métodos de estimación? Conoce esta seis técnicas para una planificación de proyectos efectiva. Asana. https://asana.com/es/resources/estimation-methods

Santos, D. (2024, 20 febrero). Qué es y cómo hacer un análisis de riesgos (con ejemplos). HubSpot. https://blog.hubspot.es/marketing/analisis-de-riesgos

Team Asana. (2024b, febrero 3). Cómo realizar un análisis de riesgos y ejemplos. Asana. https://asana.com/es/resources/project-risks

# data[].attributes.body
El análisis cuantitativo de riesgos (ACR) es la metodología que te llevará más tiempo y recursos, aunque también es la más eficaz. El análisis cuantitativo de riesgos es especialmente útil cuando prevés algún riesgo elevado, cuando existe algún requisito legal relevante o, por ejemplo, si se requiere para una toma de decisiones.

Los métodos cuantitativos adjudican un valor numérico a cada riesgo. Existen varias técnicas para realizar un análisis cuantitativo de riesgos entre las que cabe destacar:

El análisis de sensibilidad. Este tipo de técnica nos ayudará a identificar los riesgos que pueden afectar más al objetivo del proyecto.

Análisis del valor monetario esperado o EMV (por sus siglas en inglés) calcula el resultado promedio teniendo en cuenta las oportunidades esperadas, que se expresarán en positivo, y los riesgos probables que se expresarán en negativo.

Modelado y simulación. En una simulación se proyectan las incertidumbres para traducirlas en el impacto que podrían tener sobre el objetivo del proyecto. Generalmente, las simulaciones iterativas se realizan utilizando la técnica Montecarlo.

# data[].attributes.body
Los métodos cualitativos de riesgos son prácticos y eficaces especialmente en empresas pequeñas o que no cuentan con los recursos necesarios para realizar un análisis cuantitativo. Cuando trabajas con las técnicas de análisis cualitativo de riesgos también es recomendable adjudicar un valor numérico a cada riesgo o nivel de riesgo. Sin embargo, esta puntuación la realizarás basándote solo en tu experiencia o experiencias pasadas de la empresa. Entre las técnicas habituales para realizar este método se encuentran: el brainstorming, las entrevistas y evaluación por parte de expertos.

# data[].attributes.body
La matriz de fortalezas, oportunidades, debilidades y amenazas es uno de los métodos que más se utilizan dentro de la gestión de una empresa. Además, es una muy buena herramienta de análisis cualitativo en una etapa temprana de cualquier organización o proyecto de trabajo.

La matriz FODA consiste en elaborar un documento en el que desarrolles un análisis interno (fuerzas y debilidades), que quizá no harías en otras circunstancias; y realizar un contraste con las circunstancias externas (oportunidades, amenazas) para comprender mejor en qué áreas se necesita establecer un plan de prevención de riesgos.

# data[].attributes.body
La técnica de brainstorming o lluvia de ideas es un método poderoso para generar ideas. Sin embargo, su efectividad a menudo se ve subestimada. Cuando tienes un equipo con diferentes perspectivas, la lluvia de ideas es una excelente manera de estimular la creatividad y evaluar los riesgos. Es una técnica utilizada con frecuencia en el análisis de riesgos cualitativo.

Un brainstorming suele ser el primer paso para crear un registro de riesgos ya que se necesita un punto de partida para identificarlos. Aprender nuevas técnicas para lluvia de ideas puede ayudar a tu equipo a identificar los riesgos, mantener la agilidad y, posiblemente, evitar que los riesgos se materialicen.

# data[].attributes.body
Una matriz de riesgos es una herramienta de análisis de riesgos que te ayudará con la evaluación del riesgo, la probabilidad y la gravedad del riesgo durante la planificación del proyecto. Deberás identificar la probabilidad y gravedad de cada riesgo para incorporarlos a tu matriz de riesgos y poder calcular así la calificación del impacto de cada uno de ellos. Estas calificaciones ayudarán a tu equipo a determinar qué prioridad asignar a los riesgos del proyecto y a gestionarlos de manera efectiva.

# data[].attributes.body
Se describe a continuación un ejemplo de un proyecto específico el cuál se estimó en tiempo y esfuerzo de manera empírica, es decir utilizando juicio de experto, y las herramientas que tenía la organización a su alcance.

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

El proyecto

La definición del proyecto que proporcionó el cliente en primera instancia fue la siguiente: “Desarrollar solución técnica que permita brindar el servicio de tercero confiable para apoyo n las operaciones de comercio exterior”.

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

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

Contar con una herramienta que permita apoyar la operaciones de Comercio Exterior de carga, sin la necesidad de presentación física de papeles, haciendo más eficientes los procesos en las agencias aduanales en cuestión de resguardo y localización de pedimentos, sus anexos y documentos relacionados.

Contar con una herramienta que permita el resguardo digital de pedimentos, sus anexos y documentos relacionados por medio de un expediente único.

Dentro del proceso de resguardo de archivos autentificar los mismos mediante el certificado digital de Firma Electrónica Avanzada.

Contar con esquemas de búsqueda y consulta de información de acuerdo al rol del área y vigencia de resguardo.

Contar con esquema de “Facturación” que incluya costeo de almacenamiento, manejo de niveles de cuotas, bonificaciones y emisión de reportes.

Contar con información histórica (documentos) con una antigüedad hasta por 10 años.

Contexto del proyecto

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

El equipo que iba a realizar la solución no contaba con un buen conocimiento del negocio ya que usualmente ellos se dedicaban a cuestiones financieras.

Tampoco se contaba con toda la experiencia de las tecnologías involucradas para el desarrollo de la solución como digitalización y firma electrónica aunque conceptualmente se conocían.

El líder de proyecto no tenía toda la disponibilidad ya estaba compartido en tres proyectos y el suplente no tenía mucha experiencia ni liderazgo para llevar a cabo un proyecto de manera independiente.

Herramientas utilizadas para la estimación

Las herramientas con las que contaba la organización que realizó este proyecto eran la experiencia o sus expertos (herramientas empíricas, hojas de Excel generadas a partir de la experiencia, ejercicios históricos de FP (IFPUG) y Use Case Points (UCP) y una clasificación en rangos de esfuerzo históricos por tipo de proyecto específica para la organización

Resultados

El proyecto que se estimó originalmente en 5 meses por un grupo de expertos de la organización terminó en realidad en 13.25 meses lo que implicó un retraso de 165%. Cabe mencionar que este grupo realizó originalmente la estimación, en un aproximadamente una de esfuerzo.

Se puede observar claramente que el realizar malas estimaciones tiene una repercusión directa en la economía de las empresas ya que este tipo de defasamientos, que son comunes en la industria implica que alguien tiene que absorber el gasto, ya sea el cliente o el proveedor, implicando negociaciones por demás complejas y desgastantes.

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

# data[].attributes.body
El equipo encargado del proyecto tenía experiencia en el desarrollo de software para la gestión de inventarios, pero carecía de un conocimiento profundo en las regulaciones específicas del sector de la logística y los requerimientos tecnológicos relacionados con la firma electrónica y la seguridad documental.

Además, el líder del proyecto estaba asignado simultáneamente a otros dos proyectos, lo que limitaba su capacidad para supervisar este nuevo desarrollo de manera integral.

# data[].attributes.headline
Herramientas utilizadas para la estimación

# data[].attributes.subject
Herramientas utilizadas para la estimación

# data[].attributes.body
La organización empleó una combinación de técnicas empíricas basadas en la experiencia previa y herramientas automatizadas para calcular los puntos de función (IFPUG) y los puntos de casos de uso (UCP). La estimación se apoyó en hojas de cálculo de Excel, en las que se documentaron las horas de trabajo necesarias según la complejidad de las funcionalidades solicitadas, basándose en proyectos similares previos.

También se utilizó una técnica de estimación "bottom-up", donde se desglosaron todas las tareas en elementos individuales, lo que permitió calcular de manera detallada las horas de trabajo de cada especialista involucrado en el proyecto.