estimación de proyectos de software
TRANSCRIPT
Estimación de proyectos de software – COCOMO IIFase posterior a la arquitectura
Camilo Andrés Velásquez CastiblancoVIII Semestre - Ingeniería de Sistemas
UNIVERSIDAD DECARTAGENA
Estimación
•Consiste en determinar, con cierto grado de certeza, los recursos de hardware y software, costo ($), tiempo (dias - semanas) y esfuerzo (t/hombre) necesarios para el desarrollo de los mismos.
Precisión de las estimaciones en función de la fase del proyecto.
0
0.5
1
1.5
2
2.5
3
3.5
4
4.5
Via
bili
da
d
Pla
nif
ica
ció
ny
re
qu
isit
os
Dis
eñ
oG
en
era
l
Dis
eñ
oD
eta
llad
o
De
sa
rro
llo y
tes
t
En
tre
ga
Modelo Cocomo II• Este modelo permite realizar estimaciones en
función del tamaño del software, y de un conjunto de factores de costo y de escala.
• Los factores de costo describen aspectos relacionados con la naturaleza del producto, hardware utilizado, personal involucrado, y características propias del proyecto.
• El conjunto de factores de escala explica las economías y deseconomías de escala producidas a medida que un proyecto de software incrementa su tamaño.
Modelo Cocomo II
•El modelo original COCOMO ha tenido mucho éxito pero no puede emplearse con las prácticas de desarrollo software más recientes tan bien como con las prácticas tradicionales.
•COCOMO II apunta hacia los proyectos software de los 90 y de la primera década del 2000, y continuará evolucionando durante los próximos años.
Elementos principales• Preservar la apertura del COCOMO original.• Desarrollar COCOMO II de forma que sea
compatible con el futuro mercado del software
• Ajustar las entradas y salidas de los submodelos de COCOMO II al nivel de información disponible.
• Permitir que los submodelos de COCOMO II se ajusten a las estrategias de proceso particulares decada proyecto.
Familia de modelos de estimaciónPara apoyar a los distintos sectores del mercado
software, COCOMO II proporciona una familia de modelos de estimación de coste software cada vez más detallado y tiene en cuenta las necesidades de cada sector y el tipo de información disponible para sostener la estimación del coste software.
Esta familia de modelos está compuesta por tres submodelos cada uno de los cuales ofrece mayor fidelidad a medida que uno avanza en la planificación del proyecto y en el proceso de diseño.
Submodelos COCOMO II• El modelo de Composición de Aplicaciones.
Indicado para proyectos construidos con herramientas modernas de construcción de interfaces gráficos para usuario.
• El modelo de Diseño anticipado. Este modelo puede utilizarse para obtener
estimaciones aproximadas del coste de un proyecto antes de que esté determinada por completo su arquitectura. Utiliza un pequeño conjunto de drivers de coste nuevo y nuevas ecuaciones de estimación. Está basado en Punto de Función sin ajustar o KSLOC (Miles de Líneas de Código Fuente).
SubModelos Cocomo II
•El modelo Post-Arquitectura. Este es el modelo COCOMO II más
detallado. Se utiliza una vez que se ha desarrollado por completo la arquitectura del proyecto.
Modelo Post-Arquitectura
•Es el modelo de estimación más detallado y se aplica cuando la arquitectura del proyecto está completamente definida.
•Este modelo se aplica durante el desarrollo y mantenimiento de productos de software incluidos en las áreas de Sistemas Integrados, Infraestructura y Generadores de Aplicaciones.
Modelo Post-Arquitectura
•El esfuerzo nominal se ajusta usando 17 factores (drivers) multiplicadores de esfuerzo. El mayor número de multiplicadores permite analizar con más exactitud el conocimiento disponible en las últimas etapas de desarrollo, ajustando el modelo de tal forma que refleje fielmente el producto de software bajo desarrollo.
El modelo de post-arquitectura
La fórmula básica para obtener una estimación de esfuerzo:
MM = A X (Size)B
Esta ecuación calcula el esfuerzo nominal para un proyecto de un tamaño dado expresado en Meses-persona (MM).
El modelo de post-arquitectura
•MM = A X (Size)B
•CONSTANTE A:Se usa para capturar los efectos multiplicativos de esfuerzo en proyectos de tamaño incremental. Provisionalmente se le ha estimado un valor de 2.45.
El modelo de post-arquitectura
•MM = A X (Size)B
•VARIABLE SIZE:Donde: Size = Size x [ 1+BRAK/100]
Cocomo II utiliza un porcentaje de Rotura BRAK para ajustar el tamaño eficaz del producto. Es el porcentaje de código desperdiciado debido a la volatilidad de los requisitos.
El modelo de post-arquitectura• MM = A X (Size)B• VARIABLE B:
El exponente B se obtiene mediante los denominados drivers (factores) de escala.
Los modelos de estimación de coste del software a menudo tienen un factor exponencial para considerar los gastos y ahorros relativos de escala encontrados en proyectos software de distinto tamaño el cual viene representado por B.
EL MODELO DE POST-ARQUITECTURA
•Si B < 1 El proyecto presenta ahorros de escala.
•Si B = 1 Los ahorros y gastos de escala
están equilibrados.
•Si B > 1 El proyecto presenta gastos de escala.
DRIVERS DE ESCALA
•(PREC) (FLEX). Precedencia y Flexibilidad de desarrollo.
•(RESL) Arquitectura/Resolución de Riesgos.
•(TEAM). Cohesión del Equipo.•(PMAT). Madurez del proceso.
DRIVERS DE ESCALA
DRIVERS DE ESCALA(PMAT). Madurez del proceso
El procedimiento para determinar PMAT se obtiene a través del Modelo de Madurez de Capacidad del Instituto de Ingeniería del Software.El periodo de tiempo para medir la madurez del proceso es el momento en el que el proyecto comienza.
DRIVERS DE ESCALA(PMAT). Madurez del proceso
La formas de medir la madurez del proceso se hace en base a 18 áreas de procesos principales del modelo de madures de capacidad SEI. Y tiene 6 rangos de evaluación:
• Casi siempre(>90%)• Frecuentemente(60%-90%)• En la Mitad(40%-60%)• Ocasionalmente(40%-10%)• En pocas Ocasiones(<10%)• No se Aplica o no se conoce.
DRIVERS DE ESCALA(PMAT). Madurez del proceso
1. Gestión de requisitos2. Planificación de Proyectos
Software3. Seguimiento del proyecto
software4. Gestión de subcontrato
software5. Aseguramiento de la calidad
software6. Gestión de la configuración
software7. Focos de proceso de
organización8. Definición de proceso de
organización:9. Programa de formación
10. Gestión del software integrado11. Ingeniería de producto software12. Coordinación inter-grupos13. Informes detallados14. Gestión de proceso cuantitativo15. Gestión de calidad software16. Prevención de defectos17. Gestión de cambio de tecnología18. Gestión de cambio de proceso
Las diferentes áreas del proceso son:
DRIVERS DE ESCALA(PMAT). Madurez del proceso
Después de que el nivel de conformidad se determina, se pesa cada nivel de conformidad y se calcula un factor PMAT.
AJUSTE MEDIANTE DRIVERS DE COSTE
Los drivers de coste se usan para capturar características del desarrollo del software que afectan al esfuerzo para completar el proyecto.
DRIVERS DE COSTE• (RELY). Fiabilidad Requerida de
Software• (RELY). Fiabilidad Requerida de
Software• (CPLX). Complejidad del
Producto• (RUSE). Reutilización Requerida• (DOCU). Documentación
Asociada a las Necesidades del Ciclo de Vida
• (TIME). Restricción del Tiempo de Ejecución
• (PCON). Continuidad del Personal• (TOOL). Uso de Herramientas
Software• (SCED). Calendario de Desarrollo
Requerido
• (STOR). Restricción de Almacenamiento Principal
• (PVOL). Volatilidad de la Plataforma
• (ACAP). Habilidad del Analista
• (PCAP). Habilidad del Programador
• (AEXP). Experiencia en las Aplicaciones
• (PEXP). Experiencia en la Plataforma
• (LTEX). Experiencia en la Herramienta y en el Lenguaje
• (SITE). Desarrollo Multilugar
DRIVERS DE COSTE
Formulario para la estimación de esfuerzo y tiempo de desarrollo utilizando COCOMO II
Bibliografía• R.S Pressman, “Ingeniería de Software, Un
enfoque practico”,5th. Edicion, Mc Graw Hill, 2002
• www,creaweb.ei.uvigo.es/creaweb/Asignaturas/PPI/.../cocomo2k.pdf
• www.alarcos.inf-cr.uclm.es/doc/pgsi/doc/teo/8/cocomo2-apuntes.pdf
• www.upv.es/~jmontesa/eog/eog00-t4.ppt• www.liderdeproyecto.com/.../
estimacion_de_esfuerzo_del_proyecto.html