Presentación de PowerPoint -...
27
www.sgcampus.com.mx @sgcampus Carlos Eduardo Vázquez Estimación del esfuerzo y costos necesarios para el desarrollo de un proyecto de software
Transcript of Presentación de PowerPoint -...
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 Impacto
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 @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
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
La unidad de producto en la construcción civil
www.sgcampus.com.mx @sgcampus
2. Unidad de producto para
producción de software
1 m
1 m
US$ 500,00/
m2
Productividad
Casa construida
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 @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
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
imple
menta
ció
n
desempeño,
compatibilidad,
usabilidad,
confiabilidad,
seguridad,
mantenibilidad y
portabilidad
La c
alid
ad
La
org
aniz
ació
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 A
l
am
bie
nte
No son Requerimientos Funcionales
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
Derivación de unidad de producto de los requerimientos funcionales
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
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 parcial
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
3
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)
frontera frontera aplicación
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
Almacenamiento
persistente cam
ada d
e a
plic
ació
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
