Estimación de proyectos de software – COCOMO IIFase posterior a la arquitecturaUNIVERSIDAD DECARTAGENACamilo Andrés Velásquez CastiblancoVIII Semestre - Ingeniería de Sistemas
EstimaciónConsiste 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 IIEste 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 IIEl 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 principalesPreservar la apertura del COCOMO original.Desarrollar COCOMO II de forma que sea compatible con el futuro mercado del softwareAjustar 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 IIEl 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 IIEl 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-ArquitecturaEs 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-ArquitecturaEl 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-arquitecturaMM = A X (Size)BCONSTANTE 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-arquitecturaMM = A X (Size)BVARIABLE  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-arquitecturaMM = A X (Size)BVARIABLE 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-ARQUITECTURASi 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 procesoLas diferentes áreas del proceso son: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ón10. 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
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íaR.S Pressman, “Ingeniería de Software, Un enfoque practico”,5th. Edicion, Mc Graw Hill, 2002www,creaweb.ei.uvigo.es/creaweb/Asignaturas/PPI/.../cocomo2k.pdfwww.alarcos.inf-cr.uclm.es/doc/pgsi/doc/teo/8/cocomo2-apuntes.pdfwww.upv.es/~jmontesa/eog/eog00-t4.pptwww.liderdeproyecto.com/.../estimacion_de_esfuerzo_del_proyecto.html

Estimación De Proyectos De Software

  • 1.
    Estimación de proyectosde software – COCOMO IIFase posterior a la arquitecturaUNIVERSIDAD DECARTAGENACamilo Andrés Velásquez CastiblancoVIII Semestre - Ingeniería de Sistemas
  • 2.
    EstimaciónConsiste 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.
  • 3.
    Precisión de lasestimaciones en función de la fase del proyecto.
  • 4.
    Modelo Cocomo IIEstemodelo 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.
  • 5.
    Modelo Cocomo IIElmodelo 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.
  • 6.
    Elementos principalesPreservar laapertura del COCOMO original.Desarrollar COCOMO II de forma que sea compatible con el futuro mercado del softwareAjustar 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.
  • 7.
    Familia de modelosde 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.
  • 8.
    Submodelos COCOMO IIElmodelo 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).
  • 9.
    SubModelosCocomo IIEl modeloPost-Arquitectura. Este es el modelo COCOMO II más detallado. Se utiliza una vez que se ha desarrollado por completo la arquitectura del proyecto.
  • 10.
    Modelo Post-ArquitecturaEs elmodelo 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.
  • 11.
    Modelo Post-ArquitecturaEl esfuerzonominal 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.
  • 12.
    El modelo depost-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).
  • 13.
    El modelo depost-arquitecturaMM = A X (Size)BCONSTANTE 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.
  • 14.
    El modelo depost-arquitecturaMM = A X (Size)BVARIABLE 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.
  • 15.
    El modelo depost-arquitecturaMM = A X (Size)BVARIABLE 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.
  • 16.
    EL MODELO DEPOST-ARQUITECTURASi 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.
  • 17.
    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.
  • 18.
  • 19.
    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.
  • 20.
    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.
  • 21.
    DRIVERS DE ESCALA(PMAT). Madurez del procesoLas diferentes áreas del proceso son: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ón10. 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
  • 22.
    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.
  • 23.
    AJUSTE MEDIANTE DRIVERSDE COSTE Los drivers de coste se usan para capturar características del desarrollo del software que afectan al esfuerzo para completar el proyecto.
  • 24.
    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
  • 25.
  • 26.
    Formulario para laestimación de esfuerzo y tiempo de desarrollo utilizando COCOMO II
  • 27.
    BibliografíaR.S Pressman, “Ingenieríade Software, Un enfoque practico”,5th. Edicion, Mc Graw Hill, 2002www,creaweb.ei.uvigo.es/creaweb/Asignaturas/PPI/.../cocomo2k.pdfwww.alarcos.inf-cr.uclm.es/doc/pgsi/doc/teo/8/cocomo2-apuntes.pdfwww.upv.es/~jmontesa/eog/eog00-t4.pptwww.liderdeproyecto.com/.../estimacion_de_esfuerzo_del_proyecto.html