Estimación De Proyectos De Software

Estimación de proyectos de software – COCOMO II
Fase posterior a la arquitectura
UNIVERSIDAD
DE
CARTAGENA
Camilo Andrés Velásquez Castiblanco
VIII Semestre - Ingeniería de Sistemas

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.

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ón
Para 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).

SubModelosCocomo 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).

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.

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.

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.

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.

Las diferentes áreas del proceso son:
1. Gestión de requisitos
2. Planificación de Proyectos Software
3. Seguimiento del proyecto software
4. Gestión de subcontrato software
5. Aseguramiento de la calidad software
6. Gestión de la configuración software
7. Focos de proceso de organización
8. Definición de proceso de organización:
9. Programa de formación
10. Gestión del software integrado
11. Ingeniería de producto software
12. Coordinación inter-grupos
13. Informes detallados
14. Gestión de proceso cuantitativo
15. Gestión de calidad software
16. Prevención de defectos
17. Gestión de cambio de tecnología
18. Gestión de cambio de 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

Estimación De Proyectos De Software

by Jesus Daniel Rodriguez Oyola

Accessibility

Categories

Upload Details

Usage Rights

Statistics

Estimación De Proyectos De Software Presentation Transcript