www.sgcampus.com.mx @sgcampus
www.sgcampus.com.mx
@sgcampus
Carlos Eduardo Vázquez
Estimación del esfuerzo y costos
necesarios para el desarrollo de un
proyecto de software
www.sgcampus.com.mx @sgcampus
Objetivos
1. Despertar en el público la conciencia sobre la
problemática en la elaboración de estimaciones
en el desarrollo de software
2. Presentar el concepto de unidad de producto y
de cómo aplicarlo en la medición de software para
la planeación y monitoreo de la productividad en su
desarrollo
3. Introducir el método de COSMIC para la medición
del tamaño funcional y su papel en la generación de
unidades de producto a partir de los requerimientos
funcionales
www.sgcampus.com.mx @sgcampus
1. La problemática de la
estimación
•
Cuando se solicita una medición a un desarrollador para entregar un programa probado y brinda una estimación de 12 horas, lo más probable es que esté en lo cierto
Esto porque se trata de un programa cuya dificultad de estimación es menor o su impacto de error es pequeño.
Estimar pequeños elementos es fácil
Programar una Transacción
Probar una Transacción
Estimar la realización de una actividad de
12 horas Pequeño! Dificuldad Impacto www.sgcampus.com.mx @sgcampus
1. La problemática de la
estimación
La solución para todos los problemas de estimación es
descomponer un proyecto en sus partes y hacer las
estimaciones en estos mismos modelos
Los escenarios en los que la
estimación del todo es difícil y que el impacto de
los errores es demasiado grande no serían un problema y todo el mundo estaría feliz
Un gran elemento como la suma de pequeñas partes
Estimar la entrega de un
producto final a lo largo de dos años
Fase 01 Fase 02 Fase 03 Fase 04 Grande!
Dificultad
www.sgcampus.com.mx @sgcampus
1. La problemática de la
estimación
•
Al inicio no sé sabe cuáles son todos los programas Hay trabajo que no es una
función de esa cantidad de
programas
El nivel de información disponible no permite usar la lógica de la estimación de abajo hacia arriba como solución para los desafíos de la estimación
El fallo en esta lógica
Evolución del desarrollo
Decisiones y acuerdos sobre la solución Proceso de la Ingeniería de Requierimientos Alcance
preliminar
Necesidades de negocio
?
No se pueden identificar cuáles son esas
actividades de 12 horas durante las fases iniciales del desarrollo
?
?
?
?
www.sgcampus.com.mx @sgcampus1. La problemática de la
estimación
•#NoEstimates ¿Por qué estimar si al final
del trabajo ya estoy seguro de la información de interés? Al final, son apenas entre 15 o 30 días en un ambiente donde se hace uso de
enfoques ágiles de desarrollo Se puede esperar por ese momento para “saber” en lugar de simplemente creer.
De igual forma, no se puede decidir sobre los cambios que deben ser
priorizados dentro del 20% de las demandas que consumen el 80% de
www.sgcampus.com.mx @sgcampus
1. La problemática de la
estimación
> 2.000 HH 18% < 2.000 HH 82% CANTIDAD (#) > 2.000 HH 61% < 2.000 HH 39% ESFUERZO (HH)Las decisiones ejecutivas de inversión deben ser justificadas a quien mantiene el gobierno de aquella organización
¿Cómo hacer esto con #NoEstimates?
www.sgcampus.com.mx @sgcampus
2. Unidad de producto para
producción de software
A partir de esto, tuve la oportunidad de tomar varias decisiones:
• Es más caro (proporcionalmente) construir un baño que un cuarto • Cuando tuve que estimar el costo
únicamente del baño, ya tenía elementos para realizar estimaciones de abajo para arriba…
• Los desembolsos ocurridos no excedieron la estimación inicial basada en la cantidad de metros cuadrados y en la productividad media
Casa en el estilo Santa Fé de Cadu
Presupuesto disponible
1 m 1 m
Costo unitario medio de
construcción por m2
www.sgcampus.com.mx @sgcampus
2. Unidad de producto para
producción de software
1 m 1 m US$ 500,00/ m2 Productividad Casa construída 300 m2 Producto Costo Desembolso con las inversiones US$ 150.000,00 Arquitectos Ingenieros Maestro de obras Albañiles Ayudantes Impuestos y tasas Aprobaciones y registros Diversos materiales Apropiación indirecta de costos Apropiación directa de costos www.sgcampus.com.mx @sgcampus2. Unidad de producto para
producción de software
?
?
Unidad de Producto¿Cuál sería la métrica que cumple el papel de unidad de
producto para la planificación
y seguimiento del desempeño para el desarrollo de
software?
Permite aproximar o medir el tamaño del software a partir de sus requerimientos
Permite comparar la productividad entre las diferentes técnicas y tecnologías disponibles
Apoya en la estimación del
esfuerzo del proyecto o en la cuantificación del desempeño a
partir de la perspectiva del usuario o dueño para fines del análisis de productividad
Es independiente del desarrollo técnico y decisiones de
www.sgcampus.com.mx @sgcampus Dimensión del
diseño y calidad
2. Unidad de producto para
producción de software
Otras métricas permiten
cuantificar el desempeño técnico de
productos y servicios a partir de su implementación
Análisis de eficiencia del diseño
Apoyo a la verificación y validación Mejora en el rendimiento del diseño
Apoyo a la Ingeniería de Requerimientos
www.sgcampus.com.mx @sgcampus
2. Unidad de producto para
producción de software
Tipos de Requerimientos
Requerimientos Funcionales
Requerimientos que están específicamente asociados a una tarea o
servicio del usuario y
que describen lo que el software debe hacer
independientemente de cómo lo haga Manipulación y movimiento de datos Transferencia Transformación Almacenamiento Recuperación Cualquier otro tipo de requerimientos o de restricción de
orden general para el producto
las tecnologías de desarrollo, mantenimiento, soporte y ejecución como: herramientas de programación y pruebas, sistemas operativos, sistemas de gestión de bases de datos, sistemas de gestión de la interfaz gráfica con el usuario, etc. La im p le m e n ta c ió n desempeño, compatibilidad, usabilidad, confiabilidad, seguridad, mantenibilidad y portabilidad La c a lid a d La o rg a n iz a c ió n equipos de destino, la adhesión a las normas y los lugares para la operación
la interoperabilidad, privacidad y la
protección contra daños incidentales o accidentales Al a m b ie n te
www.sgcampus.com.mx @sgcampus
2. Unidad de producto para
producción de software
Requerimientos Funcionales del Usuário
(‘RFU’) en los artefatos del software a ser medido
artefatos con definición de requerimientos
artefatos del modelo /análisis de datos artefatos con decomposición funcional de los requerimientos pré-implementación artefatos de almacenamiento físico de datos Procedimentos y manuales
operacionales del software
pós-implementación
programas físicos
¿Dónde están los requerimientos funcionales?
www.sgcampus.com.mx @sgcampus
Artefactos de Software
Primera versión de los Requerimientos
Versión posterior de los Requerimientos Puede ser medido por COSMIC Debería ser registrado, puede ser cuantificable Requerimientos Funcionales del Usuario Requerimientos no Funcionales ‘Verdaderos’ RFN Requerimientos Funcionales del Usuario
Evolución de la Línea del Tiempo del Proyecto
2. Unidad de producto para
producción de software
La relación entre los requerimientos funcionales y no funcionales a lo largo del desarrollo
www.sgcampus.com.mx @sgcampus
Inicialmente, RNF RFU a ser desenvolvido ou adquirido
RNF após requisitos iniciais evoluírem em RFU
El tiempo de respueta medio en horarios pico no debe exceder X segundos
Proveer datos externos en tiempo real
Monitorar y reportar tiempo medio de respuesta
Equipo apropriado
Parte del software escrito en lenguaje de bajo nivel
La disponibilidad debe aumentar Y% en relación a la media anual pasada
Habilitar el cambio rápido de procesamiento para un procesador alternativo sin interrupción del servico
Procesador alternativo operando en‘hot stand by’
2. Unidad de producto para
producción de software
La relación entre los requerimientos funcionales y no funcionales a lo largo del desarrollo
www.sgcampus.com.mx @sgcampus
ISO/IEC 14143 define los principios de la medición del tamaño funcional
Implementados en métodos de medición del tamaño funcional por:
– COSMIC (ISO/IEC 19761:2011)
– IFPUG APF (ISO/IEC 20926:2009) – UKSMA Mk II (ISO/IEC 20968:2002) – NESMA APF (ISO/IEC 24570:2005) – FISMA (ISO/IEC 29881:2010)
2. Unidad de producto para
producción de software
www.sgcampus.com.mx @sgcampus
2ageneración de métodos de medición del tamaño funcional
Nivel de confiabilidad compatible con todos los tipos de
software
Accesible al público y su documentación no tiene costo Tiene reconocimiento total de la ISO/IEC
Proyecto es simple y posee una base conceptual compatible con la Ingeniería de Software moderna:
– Los métodos anteriores no siempre tienen una aplicación amplia
suficiente para atender las necesidades del mercado, o funcionan apenas con acceso restringido
Planificación y medición del desempeño tiene mayor exactitud Tiene la habilidad de capturar el tamaño a partir de múltiples
perspectivas
3. El método de medición de
tamaño funcional de COSMIC
www.sgcampus.com.mx @sgcampus Conjunto de: Modelos Principios Reglas Procesos
3. El método de medición de
tamaño funcional de COSMIC
Visión general del método de medición COSMIC
objetivos
1
4
Independiente de
implementación
relacionada con los artefactos del software a ser medido Es un valor de una magnitud de acuerdo con el método de COSMIC Expresado en unidades: Puntos de Función COSMIC o PFC tamaño funcional de la parte del software
Describe lo que el software debe hacer para los usuarios, quienes son los destinatarios y remitentes de los datos
Excluye requerimientos técnicos
o de calidad que expresan cómo el software funciona
La función es relativa al proceso de información que el software debe ejecutar para sus usuarios Requerimientos funcionales
del usuario en los artefactos del software a ser medido
2
www.sgcampus.com.mx @sgcampus
3. El método de medición de
tamaño funcional de COSMIC
Las fases en la medición COSMIC
Tamaño funcional del software en unidades de PFC Objetivos 1 4 3 Estrategia de medición 6
Definición de cada parte del software a ser medido de la
medición exigida 7 Fase de mapeo 9 Modelo de contexto de software 5 Modelo general de software 8 Requerimientos Funcionales del Usuario en la forma del modelo general de software 10 Fase de medición 11 Requerimientos funcionales del Usuario en artefatos del software a ser medido 2 www.sgcampus.com.mx @sgcampus
3. El método de medición de
tamaño funcional de COSMIC
Usuario funcional Usuario funcional humano aplicación siendo medida Aplicación para usuario funcional de la
aplicación siendo medida
Usuarios funcionales de una parte del software a ser medido identificados a partir de sus RFU,
como fuentes y/o destinos pretendidos para datos
En la visión lógica para una parte del software de aplicaciones de negocio, los RFU acostumbran a describir sólo la funcionalidad requerida desde el punto de vista de usuarios
humanos y, tal vez, otras aplicaciones pares que envíen o reciban datos
Cualquier camada de software y dispositivos de hardware que soporten la interación de los usuarios funcionales con la aplicación son facilitadores de las transferencias de datos y no remitentes o destinatarios
www.sgcampus.com.mx @sgcampus
3. El método de medición de
tamaño funcional de COSMIC
Frontera
Frontera definida como interfaz conceptual entre software y usuario funcional
Frontera no debe ser confundida con qualquier línea diseñada en un diagrama para delimitar o
alcance de una parte del software o camada
Frontera permite hacer distinción clara entre cualquier parte del software medido (dentro) y
cualquier parte del ambiente de los usuarios funcionales (fuera)
fronteraaplicación frontera
siendo medida
Aplicación par
www.sgcampus.com.mx @sgcampus
3. El método de medición de
tamaño funcional de COSMIC
Movimientos de datos
Usuarios funcionales interactuan con el software a través de la frontera via dos tipos de movimientos de datos (entries y exits)
Software también intercambia datos con el dispositivo de almacenamiento persistente via dos tipos de movimientos de datos (reads y writes)
El dispositivo de almacenamiento no es considerado como un usuario del software y, por tanto, está dentro de la frontera del software
aplicación siendo medida aplicación par entradas salidas exits entries exits entries armazenamento persistente cam a d a d e a p lic a c ió n lecturas grabaciones Movimientos de datos
www.sgcampus.com.mx @sgcampus pedido
item del pedido
cliente
producto pedido
item del pedido usuario
funcional processo
funcional
objetos de interés
cliente producto pedido items
de pedido
confirmación del pedido
Ejemplo de Movimientos de datos
3. El método de medición de
tamaño funcional de COSMIC
www.sgcampus.com.mx @sgcampus Editar y gerenciar pedidos de vacaciones 100 PFCG1 incluir, alterar, excluir, apreciar... 150 PFCG2 1 PFCG1 = 1,5 PFCG2 ± 25% especificación completa 200 PFCG3 1 PFCG2 = 1,33 PFCG3 ± 15% Estimar/Aproximar Medir
propuesta requerimientos proyecto construcción implementación
1. Evaluar el desempeño por la relación entre la cantidad de horas invertidas y la cantidad de puntos función COSMIC medidos
2. Re-evaluar los indicadores de productividad para que pasen a incluir el desempeño de los proyectos que terminan
3. Re-evaluar la cantidad de puntos función COSMIC que corresponden en promedio a los procesos y a los conceptos de negocio
Medición Vs Aproximación del tamaño
3. El método de medición de
tamaño funcional de COSMIC
www.sgcampus.com.mx @sgcampus Benchmarking
3. El método de medición de
tamaño funcional de COSMIC
Aproximación del Tamaño:
150 CFP
Esfuerzo estimado por otros métodos:
1000 HH 07 HH/CFP o menos de 8% de probabilidad www.sgcampus.com.mx @sgcampus Conócete a ti mismo
3. El método de medición de
tamaño funcional de COSMIC
www.sgcampus.com.mx @sgcampus
Conclusión
De algo que estoy seguro es sobre la diferencia de las respuestas para la siguiente pregunta:
"¿Por qué me pides 5.000 HH para el proyecto y no 2.000 HH?”
Porque yo lo sé
Porque sólo hay un 2% de probabilidad de entregar el proyecto de este tamaño con 2.000 HH de acuerdo a nuestros datos históricos. No hay un proyecto de la base de datos internacional de evaluación comparativa que indique esto como algo posible