Hacer una estimación de bajo hacia arriba es inviable si todavía no hay una estructura de proyecto disponible, hacer una estimación solamente basada en analogía es muy subjetivo y no se puede aprender de los errores cometidos. El objetivo de este webinar es introducir el método de medición de COSMIC y presentar una propuesta para derivar unidades de producto a partir de los requerimientos funcionales del usuario en diferentes representaciones.

1. 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

2. 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

3. 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

4. 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
Impacto

5. 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
?
? ?
?

6. www.sgcampus.com.mx @sgcampus
1. 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
los recursos

7. 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?

8. 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
La unidad de producto en la construcción civil

9. 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

10. www.sgcampus.com.mx @sgcampus
2. 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
implementación

11. 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

12. 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
implementación
desempeño,
compatibilidad,
usabilidad,
confiabilidad,
seguridad,
mantenibilidad y
portabilidad
Lacalidad
La
organizació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
ambiente
No son Requerimientos Funcionales

13. 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?

14. 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

15. 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

16. 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
Derivación de unidad de producto de los requerimientos funcionales

17. www.sgcampus.com.mx @sgcampus
 2a generació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

18. 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 medido2
3

19. 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
Objetivos1
4
3Estrategia
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

20. 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

21. 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)
frontera fronteraaplicación
siendo
medida
Aplicación par

22. 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
camadadeaplicación
lecturasgrabaciones
Movimientos
de datos

23. 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

24. 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

25. 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

26. www.sgcampus.com.mx @sgcampus
Conócete a ti mismo
3. El método de medición de
tamaño funcional de COSMIC

27. 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