Javier Garzas (URJC Kybele) Claves para implantar un modelo de estimación software en grandes empresas

Dr. Javier Garzás
@jgarzas

KYBELE CONSULTING S.L. www.kybeleconsulting.com - Copyright © 2008 All rights reserved. Contains propietary information.

La mayor causa de fracaso
en proyectos software viene
de la presión del calendario…
por haber hecho malas
estimaciones
- Brooks (1975)

5 áreas más problemáticas
5 Gestión de la
Configuración

4
Aseguramiento
12,9%
1 Medición
30,5%
de la Calidad
12,9%
Planificación del
Proyecto
2
Institucionaliza
(ESTIMACIÓN) ción
3 21,1% 23,5%

#1 –Método y unidad de
medición del
tamaño


#2 –Ajustar el método a
la organización

42


#1 – Método y unidad
de medición del
tamaño


Putnam
COCOMO

Effort
Cost Estimation
Estimation

Puntos
Size Función Staffing
Estimation LOC Estimation

Duration
Scheduling
Estimation


- Basados en la experiencia
- Históricos – Analogía
- De base estadística
(Putnam, COCOMO, Punto
Función, etc.)


Se utilizan las líneas de
código como unidad,
pero es difícil estimarlas
en las primeras fases
del ciclo de vida

Puntos Función
miden el
tamaño
funcional (no
esfuerzo, y sólo
software) en
base a los
requerimientos

COSMIC
FISMA
IFPUG
MK II
NESMA

MÉTODOS SIMPLIFICADOS

FP Lite
Punto Caso de
Uso
13


La estimación parte de los
requisitos, del pliego de
Prescripciones Técnicas o
de una descripción
informal de requisitos

14


PROCESO (MÉTODO ESTÁNDAR
DE IFPUG)
1. Identificar la Frontera de la Aplicación
2. Identificar los 5 Elementos
Funcionales
3. Evaluar la Complejidad
4. Calcular lo PF Sin Ajustar
5. Evaluar los 14 Atributos de Ajuste
6. Calcular el Factor de Ajuste
7. Calcular el Valor Final de los PF

CÁLCULO DE LOS 5 ELEMENTOS
CLAVE
Ficheros
Lógicos Internos
(ILFs)
Funciones
de datos
Ficheros
Lógicos
Externos
(ELFs)
Cálculo de Puntos
Función

Entradas (EI)
Funciones
de
transaccione Salidas (EO)
s

Consultas (EQ)


Puntos Función =
cada elemento * su complejidad
Parámetro significativo Complejidad Complejidad Complejidad Total
baja media alta parámetro
Entradas x3 x4 x6
Salidas x4 x5 x7
Ficheros internos lógicos x7 x 10 x 15
Ficheros de interfaz x5 x7 x 10
externos
Consultas externas x3 x4 x6
Puntos de función no
ajustados


AJUSTE DE LOS PF
14 factores que contribuyen a la
complejidad de una aplicación.
Se valoran del 0-5
Factores de complejidad (FC) 0-5 Factores de complejidad (FC) 0-5
Comunicación de datos Funciones distribuidas
Rendimiento Gran carga de trabajo
Frecuencia de transacciones Entrada on-line de datos
Requisitos de manejo del usuario Actualizaciones on-line
final
Procesos complejos Utilización con otros sistemas
Facilidad de mantenimiento Facilidad de operación
Instalación en múltiples lugares Facilidad de cambio


Factor Ajuste =
(0.01 * Factores Complejidad) +
0.65
El FA puede oscilar
entre 0,65 y 1,35, es
decir, permite una
variación máxima de
35% sobre el valor de
los PF

Puntos Función
PF sin ajustar Factor Ajuste


www.qsm.com/resources/function-point-languages-table


PROCESO (MÉTODO ESTÁNDAR
DE IFPUG)
1. Identificar la Frontera de la Aplicación
2. Identificar los 5 Elementos
Funcionales
3. Evaluar la Complejidad PUNTOS
4. Calcular lo PF Sin Ajustar FUNCIÓN LITE

5. Evaluar los 14 Atributos de Ajuste
6. Calcular el Factor de Ajuste
7. Calcular el Valor Final de los PF

Caso de uso: Descripción
narrativa de la secuencia de
eventos entre un actor y el
sistema


Use Case Name: COMPRAR LIBROS
Basic flow of events:
1. El “usuario” introduce su login y password
2. El “usuario” selecciona el libro a comprar
3. El “usuario” selecciona las unidades del libro a comprar
4. El “usuario” introduce su número de tarjeta de crédito
5. El “sistema” valida la tarjeta con el “centro de validación del Banco”
6. El “sistema” muestra una confirmación
Alternative flow of events:
3.1 No hay suficientes unidades del libro:
3.1.1 El sistema informa que no se puede realizar la compra.
5.1 La tarjeta de crédito no es valida
6.1.1 El sistema informa al usuario de que la tarjeta no es valida
6.1.2 El cliente puede cancelar la operación o repetirla.


Los diagramas no son
suficiente, es necesaria
la descripción textual, y
casos de uso
cortos, claros y
unificados

“Actors” categorizados “Use cases” categorizados
según complejidad según complejidad

Unadjusted Use
Technical Factors Environmental
Case Point
(TCF) Factors (EF)
(UUCP)

USE CASE
POINTS (UCP)

ESTIMATION


ACTOR TYPE WEIGHT
Simple (another system with
defined API) 1
Average (interaction through a
protocol such as TCP/IP) 2
Complex (interaction through a
GUI or Web Page) 3
* Se miden más las interacciones que los casos de uso


Num of Transactions
USE CASE
(UC steps, including WEIGHT
TYPE
secondary scenarios)

Simple 3 or minor 1
Average 4 to 7 2
Complex 7 or major 3


UNADJUSTED
USE CASE
POINTS
Complejidad de
cada actor
Complejidad de
cada CU


Los “unadjusted use case points” se ajustan en
base a 13 factores técnicos
Influence (0 = no influence; 3
Factor Description Weight Resultant
= average; 5 strong)
T1 Distributed System 2 n1 r1 = 2*n1
T2 Response adjectives 2 n2 r2 = 2*n2
T3 End-user efficiency 1 n3 r3 = 1*n3
T4 Complex processing 1 n4 r4 = 1*n4
T5 Reusable code 1 n5 r5 = 1*n5
T6 Easy to install 0,5 n6 r6 = 0,5*n6
T7 Easy to use 0,5 n7 r7 = 0,5*n7
T8 Portable 2 n8 r8 = 2*n8
T9 Easy to change 1 n9 r9 = 1*n9
T10 Concurrent 1 n10 r10 = 1*n10
T11 Security features 1 n11 r11 = 1*n11
T12 Access for third parties 1 n12 r12 = 1*n12
T13 Special training required 1 n13 r13 = 1*n13

TECHNICAL FACTORS
(TCF)
r 13
0,6 (0,01* r1
)

Los “unadjusted use case points” se ajustan en
base a 8 factores de entorno
Influence (0 = no influence; 3
Factor Description Weight Resultant
= average; 5 strong)
F1 Familiar with RUP 1,5 n1 r1 = 1,5*n1
F2 Application experience 0,5 n2 r2 = 0,5*n2
F3 Object-oriented experience 1 n3 r3 = 1*n3
F4 Lead analyst capability Motivation 0,5 n4 r4 = 0,5*n4
F5 Motivation 1 n5 r5 = 1*n5
F6 Stable requirements 2 n6 r6 = 2*n6
F7 Part-time workers -1 n7 r7 = -1*n7
F8 Difficult programming languaje 2 n8 r8 = 2*n8

ENVIROMENT FACTORS
(EF)
r8
1,4 ( 0,03 * r1
)


PUNTOS CASO DE
USO
PCU SIN AJUSTAR * FAC. TÉCNICOS * FAC.
ENTORNO


ESFUERZO (horas
/hombre) =
PF o PCU*
FACTOR DE
PRODUCTIVIDAD


Karner propone 20
horas por punto caso
de uso. Barnerjee entre
15 y 30 horas

SLIM (Putnam), en base
al estudio de 750
sistemas, elabora un
método estadístico para
estimar esfuerzo y tiempo
de desarrollo. COCOMO

La Productividad incluye un
conjunto de factores que afectan a
toda la organización, incluyendo:
la gestión del proyecto
la utilización de buenos requerimientos,
diseños,
codificaciones, etc.
el nivel del lenguaje de programación
el estado de la tecnología
la experiencia de los miembros del grupo
la complejidad de la aplicación.


Los factores de
productividad (PCU * x)
dependen de cada
organización… lo
importante es fijar uno
e ir ajustándolo

#2 – Ajustar el
método a la
organización
42


Metodología de Estimación de la DGT
Cálculo de Puntos de Casos de Uso sin ajustar

Adaptación del UAW: Factor de Peso de los Actores sin ajustar

Tipo de Actor Descripción Factor de peso
Se consideran actores simples aquellos sistemas externos con
los que el sistema a desarrollar se comunica mediante una API,
Simple como: 1
@Firma.
Registro Telemático.
Se consideran actores medios aquellos sistemas externos con
los que el sistema a desarrollar se comunica mediante
protocolo, como:
Medio Web Services. 2
Host (JCA). Cuando la implementación de la parte del
Host es externa a la aplicación y por tanto el Host es un
actor externo al sistema desarrollado.
Se consideran actores complejos a los usuarios que interactúan
Complejo con el sistema mediante interfaz gráfica. En el caso de la DGT, 3
normalmente será por Web.

Metodología y Herramienta de Estimación Software para la DGT (MHES) 19

43


Factor Tipología
Valor
Factor Descripción de DGT Asignado
Peso
Sistema totalmente centralizado 0

1

2

Sistema Aplicación Internet con acceso Web Service
T1 3 3
Distribuido a Intranet

Integración con Sistemas Externos con Web
4
Service

Integración con Sistemas Externos sin Web
5
Service (NEDAES)

Aplicación Batch sin requerimientos
0
especiales

Se indican requisitos de rendimiento pero sin
1
tratamiento definido.

Rendimiento o Tiempo respuesta < 5 segundos 2
T2 tiempo de 1
Tiempo respuesta < 2 segundos 3
respuesta
4

Aplicación que será ejecutada por otras
aplicaciones en background y por tanto el
5
tiempo de respuesta tiene que ser mínimo, o
la aplicación es un componente común

0

El usuario es un Área, Subdirección de la
1
DGT

2
Criticidad del
T3 1 El usuario es una Jefatura de la DGT 3
usuario final
Usuarios Externos (Otros ministerios,
4
Colegios, etc.)

El usuario es el ciudadano o la aplicación es
un componente común y los usuarios son el 5
resto de desarrollos de la DGT

44


#3- Utilizar estimación
por analogía… o
mejora continua

45


Analogía: Guardar
estimaciones pasadas,
y su desviación real,
para comparar nuevos
proyectos con otros
anteriores similares


La exactitud de la estimación crece con
los datos históricos
20%
De Esfuerzo Estimado
Sobre/Bajo Procentaje

0%

-145%
Sin Datos Históricos Con Datos Históricos
Varianción entre -145% to +20% Varianción entre +20% to -20%
(Mayormente en niveles 1 y 2 CMM) (Nivel 3)

Fuente: 120 Projects in Boeing Information Systems


International Software
Benchmarking Standards Group
(ISBSG)
Planificación Especificación Diseño Construcción Pruebas Implantación
9% 11% 15% 43% 16% 6%

IFPUG
Requisitos y Diseño y Pruebas de Pruebas de Implantación
Análisis Construcción Integración Sistema
20% 58% 10% 6% 6%


La estimación del proyecto
no es solo la estimación
software: hay
formación, instalación, pasos a
producción, vacaciones,
enfermedades, reuniones, etc.


¿Cuánto tiempo llevará
hacer una Web?
Depende.
Es imposible estimar sin
apenas tener idea de lo que
hay que construir


Cono de incertidumbre: la exactitud
es proporcional a la definición del
producto
Error en la estimación

4x

2x

1.5x
1.25x
1.0x VS.
0.8x
0.67x

0.5x

0.25x

Time

Estimación, no
“exactimación”
- Al estimar rara vez la probabilidad de
acierto será 100%.
- A mayor detalle, mejor método y según
la fase del ciclo de vida, la probabilidad
será mayor.


www.javiergarzas.com
@jgarzas


Javier Garzas (URJC Kybele) Claves para implantar un modelo de estimación software en grandes empresas

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (19)

Similaire à Javier Garzas (URJC Kybele) Claves para implantar un modelo de estimación software en grandes empresas

Similaire à Javier Garzas (URJC Kybele) Claves para implantar un modelo de estimación software en grandes empresas (20)

Dernier

Dernier (11)

Javier Garzas (URJC Kybele) Claves para implantar un modelo de estimación software en grandes empresas