COCOMO II - Gerencia de Proyectos Informáticos

download COCOMO II - Gerencia de Proyectos Informáticos

of 14

Transcript of COCOMO II - Gerencia de Proyectos Informáticos

  • 8/17/2019 COCOMO II - Gerencia de Proyectos Informáticos

    1/14

    Gerencia de Proyectos Informáticos C.P.Ingeniería de Sistemas e Informática - UTEA  2011

    1 Ing. Hesmeralda Rojas Enriquez

    COCOMO II

    Breve historia

    El modelo COCOMO ha evolucionado debido a los constantes avances en

    el mercado de desarrollo de software.

    En el año 1981 Barry Boehm publica el modelo COCOMO, acorde a las prácticas de desarrollo de

    software de aquel momento [Boehm 1981]. Durante la década de los 80, el modelo se continuó

    perfeccionando y consolidando, siendo el modelo de estimación de costos más ampliamente

    utilizado en el mundo.

    En el año 1983 se introduce el lenguaje de programación Ada (American National Standard

    Institute) para reducir los costos de desarrollo de grandes sistemas. Algunos aspectos de Ada

    provocaron un gran impacto en los costos de desarrollo y mantenimiento, así Barry Boehm y

    Walker Royce definieron un modelo revisado, llamado Ada COCOMO [Boehm 1989].

    En los 90, las técnicas de desarrollo de software cambiaron dramáticamente, surgieron la necesidad

    de reusar software existente, la construcción de sistemas usando

    librerías, etc. Estos cambios comenzaron a generar problemas en la

    aplicación del modelo COCOMO. La solución fue reinventar el

    modelo. Después de algunos años y de un esfuerzo combinado de

    USC-CSE (University of Southern California- Center For Software

    Engineering), IRUS at UC Irvine y organizaciones privadas, aparece

    COCOMO II. Las incorporaciones a este modelo lo reforzaron e

    hicieron apto para ser aplicado en proyectos vinculados a

    tecnologías como orientación a objetos, desarrollo incremental,

    composición de aplicación, y reingeniería. COCOMO II consta de tres

    modelos, cada uno de los cuales ofrece una precisión acorde a cada

    etapa de desarrollo del proyecto. Enunciados en orden creciente de

    fidelidad son, modelo de Composición de Aplicación, Diseño Temprano y Post Arquitectura.

    El USC- CSE implementó los dos últimos modelos en una herramienta de software. Esta

    herramienta le permite al planificador hacer rápidamente una exploración de las posibilidades de

    un proyecto, analizando qué efectos provoca el ajuste de requerimientos, recursos y staff sobre la

    estimación de costos y tiempos.

    Para evitar confusión el modelo COCOMO original fue redesignado con el nombre COCOMO’ 81. Así

    todas las referencias de COCOMO encontradas en la literatura antes de 1995 se refieren a lo que

    ahora llamamos COCOMO’81. La mayoría de las referencias publicadas a partir de 1995 se refieren

    a COCOMO II.

  • 8/17/2019 COCOMO II - Gerencia de Proyectos Informáticos

    2/14

    Gerencia de Proyectos Informáticos C.P.Ingeniería de Sistemas e Informática - UTEA  2011

    2 Ing. Hesmeralda Rojas Enriquez

    Cocomo II

    Es un modelo de estimación de costes.COnstrucive COst MOdel (MOdelo COnstructivo de Costo.Creado por Barry W. Boehm.

    Los objetivos principales que se tuvieron en cuenta para construir el modelo COCOMO II fueron:

    Desarrollar un modelo de estimación de costo y cronograma de proyectos de software que

    se adaptara tanto a las prácticas de desarrollo de la década del 90 como a las futuras.

    Construir una base de datos de proyectos de software que permitiera la calibración

    continua del modelo, y así incrementar la precisión en la estimación.

    Implementar una herramienta de software que soportara el modelo.

    Proveer un marco analítico cuantitativo y un conjunto de herramientas y técnicas que

    evaluaran el impacto de las mejoras tecnológicas de software sobre los costos y tiempos en

    las diferentes etapas del ciclo de vida de desarrollo.

    COCOMO II está compuesto por tres modelos denominados: Composición de Aplicación, Diseño

    Temprano y Post-Arquitectura.

    Éstos surgen en respuesta a la diversidad del mercado actual y futuro de desarrollo de software.

    Esta diversidad podría representarse con el siguiente esquema

  • 8/17/2019 COCOMO II - Gerencia de Proyectos Informáticos

    3/14

    Gerencia de Proyectos Informáticos C.P.Ingeniería de Sistemas e Informática - UTEA  2011

    3 Ing. Hesmeralda Rojas Enriquez

    Aplicaciones desarrolladas por Usuarios Finales:

    •En este sector se encuentran las aplicaciones de procesamiento de información generadasdirectamente por usuarios finales, mediante la utilización de generadores de aplicacionestales como planillas de cálculo, sistemas de consultas, etc. Estas aplicaciones surgendebido al uso masivo de estas herramientas, conjuntamente con la presión actual paraobtener soluciones rápidas y flexibles.

    Generadores de Aplicaciones:

    •En este sector operan firmas como Lotus, Microsoft, Novell, Borland con el objetivo decrear módulos pre-empaquetados que serán usados por usuarios finales yprogramadores.

    Aplicaciones con Componentes:

    •Sector en el que se encuentran aquellas aplicaciones que son específicas para serresueltas por soluciones pre-empaquetadas, pero son lo suficientemente simples para serconstruidas a partir de componentes interoperables.

    •Componentes típicas son constructores de interfases gráficas, administradores de basesde datos, buscadores inteligentes de datos, componentes de dominio-específico(medicina, finanzas, procesos industriales, etc.). Estas aplicaciones son generadas por un

    equipo reducido de personas, en pocas semanas o meses.Sistemas Integrados: Sistemas de gran escala, con un alto grado de integraciónentre sus componentes, sin antecedentes en el mercado que se puedan tomarcomo base. Porciones de estos sistemas pueden ser desarrolladas a través de lacomposición de aplicaciones. Entre las empresas que desarrollan softwarerepresentativo de este sector, se encuentran grandes firmas que desarrollansoftware de telecomunicaciones, sistemas de información corporativos, sistemasde control de fabricación, etc.

    Infraestructura: Área que comprende el desarrollo de sistemas operativos,protocolos de redes, sistemas administradores de bases de datos, etc.Incrementalmente este sector direccionará sus soluciones, hacia problemasgenéricos de procesamiento distribuido y procesamiento de transacciones, asoluciones middleware. Firmas representativas son Microsoft, Oracle, SyBase,

    Novell y NeXT.

  • 8/17/2019 COCOMO II - Gerencia de Proyectos Informáticos

    4/14

    Gerencia de Proyectos Informáticos C.P.Ingeniería de Sistemas e Informática - UTEA  2011

    4 Ing. Hesmeralda Rojas Enriquez

    1.  Modelo I:

    Nivel inicial de prototipado - Modelo Composición de Aplicación.

    El esfuerzo necesario para concretar un proyecto de desarrollo de software, cualquiera sea el

    modelo empleado, se expresa en meses/persona (PM) y representa los meses de trabajo de

    una persona fulltime, requeridos para desarrollar el proyecto.

    Estimación del Esfuerzo

    Estimaciones realizadas con puntos de objeto y una fórmula simple para el cálculo del esfuerzoSoporta proyectos con prototipado y proyectos que hacen uso intensivo de lareutilización.Basado en estimaciones estándar de la productividad del desarrollador en puntos-objeto/mes.Tiene en cuenta el uso de herramientas CASELa fórmula es:.

    Cálculo de Esfuerzo PM = ( NOP * (1 - %reuse/100 ) ) / PROD 

    Donde:

    NOP (Nuevos Puntos Objeto): Tamaño del nuevo software a desarrollar expresado

    en Puntos Objeto y se calcula de la siguiente manera:

    %reuso: Porcentaje de reuso que se espera lograr en el proyecto

    PROD: Es la productividad promedio determinada a partir del análisis de datos de

    proyectos en [Banker 1994], mostrada en

    2.  Modelo II:Modelo para Diseño Temprano (EDM)

    Este modelo se usa en las etapas tempranas de un proyecto de software, cuando se conoce

    muy poco del tamaño del producto a ser desarrollado, de la naturaleza de la plataforma, del

    personal a ser incorporado al proyecto o detalles específicos del proceso a utilizar. Este modelo

    podría emplearse tanto en productos desarrollados en sectores de Generadores de Aplicación,

    Sistemas Integrados o Infraestructura.

    El modelo de Diseño Temprano ajusta el esfuerzo nominal usando siete factores de costo. La

    fórmula para el cálculo del esfuerzo es la siguiente:

  • 8/17/2019 COCOMO II - Gerencia de Proyectos Informáticos

    5/14

    Gerencia de Proyectos Informáticos C.P.Ingeniería de Sistemas e Informática - UTEA  2011

    5 Ing. Hesmeralda Rojas Enriquez

    Donde

    PMEstimado: es el esfuerzo nominal ajustado por 7 factores, que reflejan otros aspectos

    propios del proyecto que afectan al esfuerzo necesario para la ejecución del mismo.  

    KSLOC: es el tamaño del software a desarrollar expresado en miles de líneas de código

    fuente.

    A es una constante que captura los efectos lineales sobre el esfuerzo de acuerdo a la

    variación del tamaño, (A=2.94).

    B es el factor exponencial de escala, toma en cuenta las características relacionadas con las

    economías y deseconomías de escala producidas cuando un proyecto de software

    incrementa su tamaño.

    EMi corresponde a los factores de costo que tienen un efecto multiplicativo sobre el

    esfuerzo, llamados Multiplicadores de Esfuerzo (Effort Multipliers). Cada factor se puede

    clasificar en seis niveles diferentes que expresan el impacto del multiplicador sobre el

    esfuerzo de desarrollo. Esta escala varía desde un nivel Extra Bajo hasta un nivel Extra Alto.

    Cada nivel tiene un peso asociado. El peso promedio o nominal es 1.0.Si el factor provoca un efecto nocivo en el esfuerzo de un proyecto, el valor del

    multiplicador correspondiente será mayor que 1.0, caso contrario el multiplicador será

    inferior a 1.0.

    Los multiplicadores reflejan la capacidad de los desarrolladores, requerimientos no funcionales,

    la familiaridad con la plataforma de desarrollo, etc.

    1.  Abrev. Descripción Ponderación

    2.  RCPX Fiabilidad de producto y complejidad 0 a 1

    3.  RUSE Reutilización requerida 0 a 1

    4.  PDIF Dificultad de la plataforma 0 a 15.  PREX Experiencia del personal 0 a 1

    6.  PERS Capacidad del personal 0 a 1

    7.  SCED Agenda requerida 0 a 1

    8.  FCIL Facilidades de soporte de grupo 0 a 1

    PM refleja la cantidad de código generada automáticamente

  • 8/17/2019 COCOMO II - Gerencia de Proyectos Informáticos

    6/14

    Gerencia de Proyectos Informáticos C.P.Ingeniería de Sistemas e Informática - UTEA  2011

    6 Ing. Hesmeralda Rojas Enriquez

    3.  Modelo III:

    Nivel 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 deproductos de software incluidos en las áreas de Sistemas Integrados, Infraestructura y

    Generadores de Aplicaciones.

    El esfuerzo nominal se ajusta usando 17 factores 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. La fórmula para el cálculo del esfuerzo es la siguiente:

    Estimación de Esfuerzo 

    Personas Mes Nominales .

    PM= A * TamañoB * EMi (A= 2.94) 

    B < 1. Los esfuerzos de desarrollo mejoran cuando escalan. Si se dobla el tamaño, elesfuerzo es menor del doble. 

    B = 1. Los proyectos están balanceados. Los aumentos son proporcionales.  

    B > 1. Los esfuerzos de desarrollo empeoran cuando escalan. Si se dobla el tamaño, elesfuerzo es menor del doble. 

    Factor de Escala 

    B = 0,91 + 0,01 Wi 

    Cálculo de Esfuerzo 

    PM = PMnominal * EMi 

  • 8/17/2019 COCOMO II - Gerencia de Proyectos Informáticos

    7/14

    Gerencia de Proyectos Informáticos C.P.Ingeniería de Sistemas e Informática - UTEA  2011

    7 Ing. Hesmeralda Rojas Enriquez

    EM : Effort Multipliers W : Factores de Escala (F i) 

    Nº Factores de escala Fi  Abreviatura

    1.  Precedentes PREC

    2.  Flexibilidad de desarrollo FLEX

    3.  Resolución de arquitectura riesgo RESL4.  Cohesión del equipo de trabajo TEAM

    5.  Madurez del Proceso PMAT

    Tabla de Puntuación:

    Modelos de Madurez del software

    Nivel Definición CaracterísticasOptimizado

    0.00 La organización completa está volcada en la mejoracontinua de los procesos. Se hace uso intensivo de lasmétricas y se gestiona el proceso de innovación. 

    Mejoramientorealimentando al proceso – Productividad y calidad 

    Gestionado

    cuantitativamente

    1.56 

    Se caracteriza porque las organizaciones disponen deun conjunto de métricas significativas de calidad yproductividad, que se usan de modo sistemático para latoma de decisiones y la gestión de riesgos. El softwareresultante es de alta calidad. 

    Proceso medido

    Definido

    3.12 Además de una buena gestión de proyectos, a estenivel las organizaciones disponen de correctos

    procedimientos de coordinación entre grupos,formación del personal, técnicas de ingeniería másdetalladas y un nivel más avanzado de métricas en los

    Proceso definido einstitucionalizado

  • 8/17/2019 COCOMO II - Gerencia de Proyectos Informáticos

    8/14

    Gerencia de Proyectos Informáticos C.P.Ingeniería de Sistemas e Informática - UTEA  2011

    8 Ing. Hesmeralda Rojas Enriquez

    procesos. Se implementan técnicas de revisión porpares. 

    Repetible

    4.68 En este nivel las organizaciones disponen de unasprácticas institucionalizadas de gestión de proyectos,existen unas métricas básicas y un razonableseguimiento de la calidad. La relación con

    subcontratistas y clientes está gestionadasistemáticamente. 

    Proceso dependiente deindividuo

    Inicial

    Superior 6.24

    Inferior 7.80 

    Las organizaciones en este nivel no disponen de unambiente estable para el desarrollo y mantenimientode software. Aunque se utilicen técnicas correctas deingeniería, los esfuerzos se ven minados por falta deplanificación. El éxito de los proyectos se basa lamayoría de las veces en el esfuerzo personal, aunque amenudo se producen fracasos y casi siempre retrasos ysobrecostes. El resultado de los proyectos esimpredecible. 

    Caótico - Riesgo 

  • 8/17/2019 COCOMO II - Gerencia de Proyectos Informáticos

    9/14

    Gerencia de Proyectos Informáticos C.P.Ingeniería de Sistemas e Informática - UTEA  2011

    9 Ing. Hesmeralda Rojas Enriquez

    Multiplicadores de esfuerzo (EM)Son 17:

      Relacionados con el producto: 

    1.  (RELY). Fiabilidad Requerida de Software

    Esta es la medida de hasta qué punto el software debe realizar su función esperadadurante un periodo de tiempo.

    2.  (DATA). Medida del Volumen de Datos

    Esta medida intenta capturar lo que afecta en el desarrollo del producto losrequerimientos de datos grandes. La medida se determina calculando D/P.

    DATA se valora como Bajo si D/P es menor que 10 y Muy Alto si es mayor que 1000.

    3.  (CPLX). Complejidad del Producto 

    Las Medidas de complejidad del módulo versus Tipo de módulo proporciona la escala devalores CPLX de Cocomo II. La complejidad se decide en 5 áreas: Funcionamiento decontrol, Funcionamiento computacional, Funcionamiento de Dispositivos dependientes,

    Funcionamiento del sector de datos y Funcionamiento del Gestor de Interfaz de Usuario.Se seleccionará el área o combinación de áreas que caracterizan al producto o a unsubsistema del producto. La medida de complejidad es la media subjetiva de estas áreas.3.1. Funcionamiento de control

    Muy Bajo: código con unos pocos operadores de programación no anidados.Bajo: anidamiento sencillo de operadores de programación estructurados.Nominal : Mayoría de anidamiento simple.

     Alto: Operadores de programación estructurados altamente anidadoscompuestos de muchos predicados.Muy Alto: Codificación recursiva. Manejo de interrupciones con prioridadesfijadas. Sincronización de tareas, retorno de llamadas complejas, proceso

    distribuido, etc.Extra Alto: Múltiples recursos de planificación con cambio dinámico deprioridades. Control a nivel de microcódigo. Control distribuido en tiempo real.

    3.2. Funcionamiento computacional

    Muy Bajo: Evaluación de expresiones simples, por ejemplo

    Bajo: Evaluación de expresiones de nivel moderado: p.ej

    Nominal : Uso de rutinas matemáticas y estadísticas estándar. Alto: Análisis numérico básico: ecuaciones diferenciales ordinarias.Muy Alto: Análisis numérico difícil pero estructurado: ecuaciones de matrices,

    ecuaciones diferenciales parciales.Extra Alto: Análisis numérico difícil y sin estructurar.

  • 8/17/2019 COCOMO II - Gerencia de Proyectos Informáticos

    10/14

    Gerencia de Proyectos Informáticos C.P.Ingeniería de Sistemas e Informática - UTEA  2011

    10 Ing. Hesmeralda Rojas Enriquez

    3.3. Funcionamiento dispositivos dependientes

    Muy Bajo: Declaraciones simples de lectura-escritura con formatos simples.Bajo: No necesidad de conocimiento de características del procesadorparticular o del dispositivo de I/O.Nominal : El proceso de I/O incluye selección de dispositivo, estado de

    validación y proceso de errores. Alto: Operación de I/O a nivel físico (traducción de direcciones físicas dealmacenamiento: búsquedas, lecturas, etc.).Muy Alto: Rutinas para diagnóstico de interrupciones, servicio deenmascaramiento. Manejo de línea de comunicación.Extra Alto: Dispositivo dependiente temporalmente de la codificación.Operaciones microprogramazas.

    3.4. Funcionamiento del sector de datos

    Muy Bajo: Arrays simples en memoria principal. Actualizaciones, Queriessimples

    Bajo:  Archivos únicos sin cambio en la estructura de datos, sin ediciones, sinarchivos intermedios. Actualizaciones, Queries moderadamente complejosNominal : Entradas de múltiples archivos y salida de un único archivo. Cambiosestructurales simples, ediciones simples. Actualizaciones, Queries complejos.

     Alto: Encadenamientos simples activados por contenidos de hileras de datos.Muy Alto: Coordinación de bases de datos distribuidas. Encadenamientoscomplejos. Optimización de la búsquedaExtra Alto: Acoplamiento fuerte, estructuras de objetos y relacionalesdinámicas.

    3.5. Funcionamiento de gestor de Interfaces de usuario

    Muy Bajo: Forma de entrada simple, generadores de informes

    Bajo: Uso de constructores simples de interfaces gráficos de usuarioNominal : Uso simple de conjunto Widget Alto: Extensión y desarrollo de conjunto Widget. Voz simple de I/O multimediaMuy Alto: Multimedia complejo 2D/3D, gráficos dinámicos multimediaExtra Alto: Multimedia complejo, realidad virtual.

    4.  (RUSE). Reutilización Requerida

    Explica el esfuerzo adicional necesario para construir componentes pensados para sereutilizados en otros proyectos.

    5.  (DOCU). Documentación Asociada a las Necesidades del Ciclo de Vida

  • 8/17/2019 COCOMO II - Gerencia de Proyectos Informáticos

    11/14

    Gerencia de Proyectos Informáticos C.P.Ingeniería de Sistemas e Informática - UTEA  2011

    11 Ing. Hesmeralda Rojas Enriquez

      Relacionados con la plataforma de desarrollo:

    6.  (TIME). Restricción del Tiempo de EjecuciónEsta es una medida de la restricción del tiempo de ejecución

    7.  (STOR). Restricción de Almacenamiento PrincipalEsta medida representa el grado de restricción de almacenamiento principal.

    8.  (PVOL). Volatilidad de la PlataformaPlataforma:  significa la complejidad del Hardware y Software (OS, DBMS, etc.) que el productosoftware necesita para realizar sus tareas.

      Relacionados con personal

    9.  (ACAP). Habilidad del AnalistaLo que se debe considerar en esta medida son la habilidad de análisis y diseño, la eficiencia y lahabilidad para comunicar y cooperar que posee el Analista, no se debe considerar aquí el nivel deexperiencia ya que se mide con AEXP.

    10.(PCAP). Habilidad del ProgramadorLo que se debe considerar en esta medida son la habilidad de análisis y diseño, la eficiencia y lahabilidad para comunicar y cooperar que posee el Programador, no se debe considerar aquí elnivel de experiencia ya que se mide con AEXP.

    11.(AEXP). Experiencia en las AplicacionesEsto mide el nivel de experiencia en aplicaciones del equipo de proyecto en el desarrollo desistemas.

    12.(PEXP). Experiencia en la PlataformaAquí se reconoce la importancia de entender el uso de plataformas más poderosas, incluyendomás interfaces gráficas.

    13.(LTEX). Experiencia en la Herramienta y en el Lenguaje

    Esta es una medida del nivel de experiencia en el lenguaje de programación.

  • 8/17/2019 COCOMO II - Gerencia de Proyectos Informáticos

    12/14

    Gerencia de Proyectos Informáticos C.P.Ingeniería de Sistemas e Informática - UTEA  2011

    12 Ing. Hesmeralda Rojas Enriquez

    14.(PCON). Continuidad del PersonalLa escala de valores mide el movimiento de personal del proyecto anualmente.

      Relacionados con el proyecto

    15.(TOOL) Uso de Herramientas Software

    Los valores para la herramienta van desde edición y código simple, Muy Bajo, hasta herramientasintegradas de gestión del ciclo de vida, Muy Alto.

    16.(SITE). Desarrollo MultilugarDeterminar la medida del driver de costo incluye el cálculo y la medida de 2 factores: Localizacióndel lugar (desde totalmente localizado hasta distribución internacional) y soporte decomunicación (desde correo de superficie y algún acceso telefónico hasta multimedia totalmenteinteractivo).

    17.(SCED). Calendario de Desarrollo RequeridoEste valor mide las restricciones de horario impuestas al equipo de proyecto que desarrolla elsoftware. Los valores se definen en términos de porcentaje de aceleración o alargamiento sobreel calendario respecto de un calendario nominal para un proyecto que requiere una cantidad deesfuerzo dada.

  • 8/17/2019 COCOMO II - Gerencia de Proyectos Informáticos

    13/14

    Gerencia de Proyectos Informáticos C.P.Ingeniería de Sistemas e Informática - UTEA  2011

    13 Ing. Hesmeralda Rojas Enriquez

    Tabla que refleja los coeficientes necesarios para el cálculo:

    Abreviatura Muy bajo Bajo Nominal Alto Muy alto Extra alto

    RELY 0.75 0.88 1.00 1.15 1.39 1.00

    DATA 1.00 0.93 1.00 1.09 1.19 1.00

    CPLX 0.75 0.88 1.00 1.15 1.30 1.66

    RUSE 1.00 0.91 1.00 1.14 1.29 1.49

    DOCU 0.89 0.95 1.00 1.06 1.13 1.00

    TIME 1.00 1.00 1.00 1.11 1.31 1.67

    STOR 1.00 1.00 1.00 1.06 1.21 1..57

    PVOL 1.00 0.87 1.00 1.15 1.30 1.00

     ACAP 1.50 1.22 1.00 0.83 0.67 1.00

    PCAP 1.37 1.16 1.00 0.87 0.74 1.00

    PCON 1.24 1.10 1.00 0.92 0.84 1.00

     AEXP 1.22 1.10 1.00 0.89 0.81 1.00

    PEXP 1.25 1.12 1.00 0.88 0.81 1.00

    LTEX 1.22 1.10 1.00 0.91 0.84 1.00

    TOOL 1.24 1.12 1.00 0.86 0.72 1.00

    SITE 1.25 1.10 1.00 0.92 0.84 1.00

    SCED 1.29 1.10 1.00 1.00 1.00 1.00

    Determinación del Tiempo de Desarrollo y Cantidad de Personal

    Determinación del Tiempo de Desarrollo

    Tdes= 3.67 * (E)0.28 + 0.002 * ∑SFi 

    Cantidad de Personal

    CH= E/Tdes

  • 8/17/2019 COCOMO II - Gerencia de Proyectos Informáticos

    14/14

    Gerencia de Proyectos Informáticos C.P.Ingeniería de Sistemas e Informática - UTEA  2011

    14 Ing. Hesmeralda Rojas Enriquez

    EJERCICIOS

    Para un software se ha hallado que el total de Puntos de Función Ajustados fue de 349.6

    TLDC = Nº medio de LDC de “x” lenguaje de programación x PFA/1000 

    TLDC= 53 x 349.6 / 1000

    TLDC= 18.52

    Determinación de los factores de escala

    E= A * (Tamaño)B X EMi

    E= Esfuerzo nominal

    Tamaño= Puntos de Función Ajustados