![EJEMPLO:
Vamos a ver el caso del mantenimiento de un proyecto cuyo tamaño
es de 8000 SLOC. Van a mantenerse
4000 SLOC del proyecto inicial y se van añadir 2500 SLOC nuevas.
Estructura: Se han utilizado funciones independientes que son
llamadas desde distintos módulos y que a
la vez se comunican entre sí: Alta.
Claridad de aplicación: Claro ajuste entre programa y aplicación: Muy
Alta. Descriptivita propia: Bien documentado el código y las
cabeceras: Alto.
SU = (20 + 10 + 20) / 2= 25
MAF = 1 + X UNFM
SU
100
(Size)M = (SizeAdded + SizeModified) X MAF
Estimación de Proyectos Software
Se ha elegido a una persona que últimamente ha trabajado bastante
con el lenguaje en el que se ha
Realizado la aplicación. UNFM = 0.2.
Así tenemos que:
MAF = 1 + [(25/100) x 0.2] = 1.05
MCF = (2500 + 4000) / 8000 = 0.8125
(Size)M = [(8000) x 0.8125] x 1.05= 6825 SLOC = 6.825 KSLOC](https://image.slidesharecdn.com/cocomo2-160506210450/85/Cocomo2-8-320.jpg)
Cocomo2
- 1. “AÑO DE LA CONSOLIDACION DEL MAR DE GRAU” “INSTITUTO SUPERIOR TECNOLOGICO PRIVADO JUAN MEJIA BACA” Curso: INGENIERIA DE SOFTWARE Alumna: TORRES ARTEAGA KAREN FABIOLA Ciclo: VI Turno: NOCHE Especialidad: COMPUTACIÓN E INFORMÁTICA Docente: PORRO CHULLI MARCO
- 2. COCOMO II El modelo original COCOMO se publicó por primera vez en 1981 por Barry Boehm y reflejaba las Prácticas en desarrollo de software de aquel momento. En la década y media siguiente las técnicas de Desarrollo software cambiaron drásticamente.
- 3. CARACTERISTICAS • 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 de Cada proyecto.
- 4. OBJETIVO Los Puntos Objeto son el recuento de pantallas, informes y módulos de lenguajes de 3ª generación Desarrollados en la aplicación, cada uno ponderado mediante un factor de complejidad de tres niveles (Simple, medio y complejo).
- 5. MODELOS UTILIZACIÓN DEL MODELO DE COMPOSICIÓN DE APLICACIONES EL MODELO DE DISEÑO ANTICIPADO Y POST- ARQUITECTURA.
- 6. UTILIZACIÓN DEL MODELO DE COMPOSICIÓN DE APLICACIONES Las primeras fases o ciclos en espiral utilizados en proyectos software de Generador de Aplicaciones, Integración de Sistema e Infraestructura implicarán generalmente prototipo y utilizarán las utilidades del Módulo de Composición de Aplicaciones.
- 7. EL MODELO DE DISEÑO ANTICIPADO Y POST-ARQUITECTURA. Los modelos de Diseño Anticipado y Post- Arquitectura se basan en la misma filosofía a la hora de proporcionar una estimación. Como hemos indicado ya su principal diferencia se produce en la cantidad y detalle de la información que se utiliza para obtener la estimación en cada uno de ellos
- 8. EJEMPLO: Vamos a ver el caso del mantenimiento de un proyecto cuyo tamaño es de 8000 SLOC. Van a mantenerse 4000 SLOC del proyecto inicial y se van añadir 2500 SLOC nuevas. Estructura: Se han utilizado funciones independientes que son llamadas desde distintos módulos y que a la vez se comunican entre sí: Alta. Claridad de aplicación: Claro ajuste entre programa y aplicación: Muy Alta. Descriptivita propia: Bien documentado el código y las cabeceras: Alto. SU = (20 + 10 + 20) / 2= 25 MAF = 1 + X UNFM SU 100 (Size)M = (SizeAdded + SizeModified) X MAF Estimación de Proyectos Software Se ha elegido a una persona que últimamente ha trabajado bastante con el lenguaje en el que se ha Realizado la aplicación. UNFM = 0.2. Así tenemos que: MAF = 1 + [(25/100) x 0.2] = 1.05 MCF = (2500 + 4000) / 8000 = 0.8125 (Size)M = [(8000) x 0.8125] x 1.05= 6825 SLOC = 6.825 KSLOC
- 9. RESUMEN Desarrollar un modelo de estimación de tiempo y de coste del software de acuerdo con los ciclos de vida utilizados en los 90 y en la primera década del 2000. Desarrollar bases de datos con costes de software y herramientas de soporte para la mejora continua del modelo
- 10. SUMARY
- 11. RECOMENDACIONES 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.
- 12. APRECIACION DEL EQUIPO Es importante recalcar los cambios experimentados por COCOMO II con respecto a COCOMO 81 ya que reflejan cómo ha madurado la tecnología de la Ingeniería del software durante las dos décadas pasadas. Por ejemplo, cuando se publicó el primer modelo COCOMO 81 los programadores estaban sometidos a tareas Bath. El giro total que se experimentó afectó a su productividad. Por lo tanto un parámetro como TURN que reflejaba la espera media de un programador para recibir de vuelta su trabajo ahora no tiene sentido porque la mayoría de los programadores tienen acceso instantáneo a los recursos computacionales a través de su estación de trabajo. Este parámetro ha desaparecido en el nuevo modelo.