Estimaciones de Software

20
FACULTAD DE INGENIERÍA ESCUELA PROFESIONAL DE ING. DE COMPUTACIÓN Y SISTEMAS CURSO: Ingeniería de Software TEMA: Estimaciones de Software PROFESOR: Cárdenas Rengifo, Luis ALUMNO: Durán Meléndez, Adrián Arturo. CICLO: V

description

estimaciones de software

Transcript of Estimaciones de Software

FACULTAD DE INGENIERAESCUELA PROFESIONAL DE ING. DE COMPUTACIN Y SISTEMAS

CURSO:Ingeniera de SoftwareTEMA:Estimaciones de SoftwarePROFESOR:Crdenas Rengifo, LuisALUMNO: Durn Melndez, Adrin Arturo.

CICLO:V

Trujillo, 28 de Noviembre de 2014

INTRODUCCINLa Ingeniera del Software es uno de las cuestiones ms olvidadas y rechazadas entre la mayora de estudiantes de Ingeniera Informtica. Sin embargo, es una de las temticas ms importantes en el conjunto global de la titulacin de Ingeniera Informtica, y fundamental para el correcto desarrollo de productos software.Errneamente se identifica la creacin de software slo con su programacin y prueba, dando de lado el proceso anterior de planificacin y diseo, as como de asignacin de recursos y de esfuerzo. La Ingeniera Software es vital para la correcta elaboracin de productos software. Antes de comenzar la tarea puramente de programacin y creacin del programa es necesario realizar una estimacin y una previsin sobre la cantidad de tiempo que llevar su realizacin as como del esfuerzo y el personal necesario para completarlo. Para llevar a cabo esta estimacin existen una serie de modelos que actualmente son utilizados por las empresas de desarrollo software, y cuyos resultados poseen una calidad dependiente del entorno. Por ello este estudio intentar esclarecer cules son los mejores modelos as como mostrar una comparativa entre ellos.Todos estos modelos y herramientas pueden ser directamente aplicados a la estimacin de parmetros como esfuerzo y costo de proyectos de tipo software.Las actividades de estimacin y de planificacin quedaban relegadas a un mero acto protocolario al comienzo del proyecto. Posteriormente, el seguimiento y control se realizaban sin un mnimo de rigor, dada la baja calidad de la estimacin y la planificacin realizada. Es entonces que las desviaciones en costos y tiempo han sido consideradas como algo natural en un proyecto software. Algo as como si nadie estuviera obligado a saber cundo se terminar el sistema ni cunto costar.

Por lo tanto una tarea importante dentro del proceso de desarrollos de productos de software, es el proceso de estimacin del software, el cual nos permitir establecer una cierta visin de los que nos espera durante el proceso de desarrollo, no solo en costos sino tambin en esfuerzo; estando as mejor preparados y conociendo cuales son las caractersticas a invertir para que el proceso sea de carcter satisfactorio.

1. DEFINICINLa estimacin se define como el proceso que proporciona un valor a un conjunto de variables para la realizacin de un trabajo, dentro de un rango aceptable de tolerancia. Podemos definirlo tambin como la prediccin de personal, del esfuerzo, de los costes y de la planificacin que se requerir para realizar todas las actividades y construir todos los productos asociados con el proyecto. Predecir valores de entidades y sus atributos que sean relevantes para el proyecto.Uno de los parmetros crticos de la estimacin es determinar su exactitud. La estimacin puede realizarse a partir de datos histricos o con herramientas. Curiosamente, en la actualidad, est ocurriendo algo sorprendente y es que algunas herramientas actualmente existentes proporcionan una estimacin ms exacta que la obtenida por la empresa a partir de sus datos histricos.Vista desde el punto de vista de un diccionario, una estimacin es un conjunto aproximado de valores para algo que ha de ser hecho. En el mundo del desarrollo de software, Larry Putnam ha apuntado que la gestin del desarrollo de software considera la estimacin como una actividad que permite obtener, principalmente, respuestas aproximadas a las siguientes preguntas: Cunto costar? Cunto tiempo llevar hacerlo?2. PROBLEMTICA DEL PROCESO DE ESTIMACIN DEL SOFTWAREYa en los aos 70 se comenz a hablar del proceso de estimacin del software. Sin embargo, y desafortunadamente, el arte y la ciencia de la estimacin estn hoy en da en sus inicios. La industria del software sigue fuera de control, con costes y tiempos desmedidos. Pero, Qu hace que la estimacin sea tan difcil de realizar? Entre las razones para esta complejidad estn las siguientes:

No existe un modelo de estimacin universal o una frmula que pueda ser usada para todas las organizaciones. Hay muchas personas implicadas en los proyectos que precisan de estimaciones. La utilidad de una estimacin tambin depender de la etapa de desarrollo en la que nos encontremos. Las caractersticas del software y de su desarrollo hacen difcil la estimacin. Existen malas interpretaciones en las relaciones lineales entre la capacidad requerida por unidad de tiempo y el tiempo disponible. El estimador tiende a reducir en algn grado las estimaciones para hacer ms aceptable la oferta. Existe una tendencia aparente de los desarrolladores hacia la subestimacin. La rapidez con la que cambia la tecnologa de la informacin y las metodologas de desarrollo de software son problemas para la estabilizacin del proceso de estimacin.

3. PROCESO DE ESTIMACINEn la industria en general, es necesario calcular y estimar el esfuerzo y el tamao del proyecto en etapas muy tempranas del desarrollo del mismo. Sin embargo, si en el mbito software se hacen las estimaciones en estas fases iniciales, dichas previsiones pueden estar basadas en unos requerimientos errneos o incompletos, por lo que disminuye mucho su fiabilidad.El proceso de estimacin del coste y esfuerzo de un producto software est formado por un conjunto de tcnicas y procedimientos que se usan en la organizacin para poder llegar a una prediccin fiable. ste es un proceso continuo, que debe ser usado y consultado a lo largo de todo el ciclo de vida del proyecto. Se divide en los siguientes pasos: Estimacin del tamao. Estimacin del costo y del esfuerzo. Estimacin de la programacin temporal. Estimacin de la cantidad de recursos computacionales. Asuncin de riesgos. Inspeccin y aprobacin. Redaccin de informes de estimacin. Medicin y perfeccionamiento del proceso. Todas estas estimaciones necesarias estn basadas en probabilidades debido a la influencia de factores externos de difcil control. De una manera general podemos afirmar que existen dos maneras diferentes de estimar el presupuesto y el tiempo para un proyecto software: usando modelos de costo y usando razonamiento basado en similitud. En ambas opciones es necesario recurrir a informacin histrica y de proyectos anteriores previamente almacenados en bases de datos.

Existen cuatro puntos fundamentales sobre los que se apoya la estimacin: Las consideraciones y opiniones de los profesionales de la materia. La participacin de expertos. La utilizacin de factores estndar de tiempos, calculados y establecidos a partir de proyectos anteriores. Por ltimo el empleo de frmulas y funciones.4. REQUISITOS QUE DEBE CUMPLIR UN BUEN ESTIMADOR

El estimador debe ser un profesional, que no tenga ningn inters, directo o indirecto, en los resultados del proceso de estimacin y que est nicamente guiado por su profesionalidad.El principal objetivo de un estimador es obtener unas estimaciones de calidad, las cuales no tienen siempre por qu coincidir con las expectativas de la direccin en trminos de coste y tiempo.Un buen estimador debera cumplir los siguientes requisitos: Debe poseer una importante formacin y experiencia profesional que le ayuden a entender y solucionar los problemas de la gestin de proyectos. Debe tener una posicin en la organizacin que le permita adoptar un juicio independiente. Debe basarse en un mtodo que pueda ser explicado, cuestionado, discutido y auditado por otros expertos. Siempre que use una herramienta de estimacin, sta debe ajustarse a su propsito de estimacin y debe soportar el mtodo. La herramienta tambin debe estar documentada y controlada. Debe ser capaz de describir su experiencia en cada estimacin. Es decir, describir los problemas a los que ha tenido que enfrentarse, las soluciones, etc. Debe ser capaz de documentar su estimacin, incluyendo los resultados obtenidos y cualquier informacin necesaria para hacer el proceso de estimacin repetible y verificarle.5. MARCO TEMPORAL DE LA ESTIMACIN DE PROYECTOSLa estimacin, es un proceso continuo. La estimacin continua nos permite el uso de un nico modelo coherente que pueda capturar y utilizar la informacin sobre el proyecto a medida que este se conozca. Siendo ms precisos, el proceso de estimacin comienza usando unas pocas variables claves para proveer las "macro-caractersticas" de un proyecto, y evoluciona incorporando informacin de ms bajo nivel para producir las "micro-caractersticas" del proyecto. De esta forma es interesante conocer el esfuerzo total del proyecto, su duracin, riesgos, necesidades de personal, etc. A esta primera estimacin se le denomina macro-estimacin de un proyecto.

Una vez que los requisitos han sido definidos, se necesita una estimacin ms detallada para la siguiente fase, diseo del producto, con el fin de utilizarla para confeccionar una planificacin para dicha fase. Tambin se necesita una estimacin a ms alto nivel para el resto del proyecto. Despus de que el diseo del producto ha finalizado, puede ser incluso que la base de la estimacin haya cambiado, es decir, se puede pasar de utilizar parmetros descriptivos a emplear otros ms detallados como el nmero de mdulos esperados, o el nmero de lneas de cdigo. Tambin podran conocerse consideraciones tecnolgicas a un nivel de detalle razonable.Al final de la fase de diseo detallado, la informacin sobre el nmero de mdulos y lneas de cdigo, por ejemplo, puede ser refinada para la mejora de las estimaciones de las restantes fases.Cuando la codificacin, las pruebas y la instalacin han finalizado podemos obtener datos sobre el rendimiento y la calidad del sistema que, cuantificados adecuadamente, pueden constituir la base para la estimacin de defectos. Estos datos, junto con el conocimiento sobre el entorno del desarrollo, permitirn realizar estimaciones para la fase de mantenimiento.

6. SALIDAS DEL PROCESO DE ESTIMACINDentro de esta etapa nace la pregunta: Qu es lo que debemos estimar?Al comienzo de este informe sobre la definicin de estimacin se mencionaron dos preguntas a las que este proceso deba dar respuesta. Estas preguntas eran: Cunto costar? Y Cunto tiempo llevar hacerlo?Esta informacin constituye la informacin bsica de todo proceso de estimacin. Los distintos mtodos existentes para realizar este proceso proporcionan informacin adicional para dar respuestas, en funcin del mtodo a algunas de las siguientes preguntas: Cunta gente se necesita? De qu perfiles? Cules son los riesgos? Cmo afectan las restricciones impuestas a las estimaciones? Cunto esfuerzo se necesita para realizar cada fase del ciclo de vida? Cul ser el esfuerzo para mantener este proyecto? Cmo impacta este proceso en el resto de los proyectos de la empresa? Cul ser el tamao del sistema? Cuntos defectos tendr el producto?Se podra crear una lista compuesta por todas estas preguntas, para utilizarla como base para la solucin al problema de Qu estimar. As, se observara que existen muchos conceptos en la mente de los estimadores. Todos estos parmetros que se pretenden obtener, son en realidad medidas sobre el producto software, es decir mtricas, tema que no se tocara en el presente informe.

7. TCNICAS DE ESTIMACINPara la estimacin, existen cuatro tcnicas bsicas y comunes:1. La opinin de los expertos. Esta tcnica se basa en la experiencia profesional de los participantes en el proyecto de estimacin.2. La analoga. Es una aproximacin ms formal que la experiencia de los expertos y se basa en la comparacin directa de uno o ms proyectos pasados. La estimacin inicial se ajusta dependiendo de las diferencias entre el proyecto pasado y el nuevo.3. La descomposicin. Consiste en la descomposicin de un producto en componentes ms pequeos, o descomponer un proyecto en tareas de nivel inferior. La estimacin se hace a partir del esfuerzo requerido para producir los componentes ms pequeos o para realizar las tareas de nivel inferior. La estimacin global del proyecto resultar de sumar las estimaciones de los componentes.4. Las ecuaciones de estimacin. Son frmulas matemticas que establecen la relacin de algunas medidas de entrada (que normalmente es la medida del tamao del producto) y determinan el esfuerzo que se requerir.La primera tcnica es un tanto informal y es la que se ha llevado a cabo hasta el momento, con no muy buenos resultados como ya hemos visto, dada la complejidad del propio proceso de estimacin. Para poder utilizar la segunda tcnica es necesario disponer de una base de datos histrica de proyectos finalizados con la que poder realizar la comparacin. Adems todos esos proyectos tendrn que haber seguido un proceso estndar.Para aplicar la tercera tcnica hay que disponer tambin de una base de datos histrica para poder identificar el esfuerzo de las distintas actividades de bajo nivel, y sta no est normalmente definida por las razones que anteriormente hemos indicado.Por todo ello, cuando se comienza a realizar el proceso de estimacin en una organizacin se utiliza algn mtodo o modelo establecido, es decir, se emplea la cuarta tcnica.7.2. Requisitos de una buena tcnica de estimacinUn mtodo de estimacin tendr xito si: La estimacin inicial est dentro del 30% de desviacin del coste final real. El mtodo permite el refinamiento de la estimacin durante el ciclo de vida del producto software. El mtodo es fcil de usar por el estimador. Esto permite una rpida re-estimacin cuando sea necesario; por ejemplo, para evaluar distintas alternativas. Las reglas de la estimacin son entendidas por todas las personas a las que afectan los resultados de la misma. Los directivos se sienten ms seguros cuando el proceso de estimacin es fcilmente comprensible.

El mtodo es soportado por herramientas y est documentado. La disponibilidad de herramientas aumenta la eficacia de cualquier mtodo. Esto es debido, principalmente, a que los resultados pueden ser obtenidos ms rpidamente y de una forma estndar.

8. MODELOS MTODOS DE ESTIMACIN8.1 CLASIFICACION DE LOS MODELOS DE ESTIMACIN Los diferentes modelos de estimacin para proyectos pueden ser clasificados de diversas maneras, de entre las cuales se deben destacar las aportadas por dos autores principales:Segn Basili, existen tres modelos: Modelos con una o varias variables estticas, que se basan en aplicar funciones y constantes a algunas propiedades del proyecto, por ejemplo el LOC (Lines Of Code). Modelos con varias variables dinmicas, que miden el tiempo del proyecto frente a su costo, usando una distribucin obtenida de manera emprica. Modelos tericos con algoritmos prediseados, que se basan en una hiptesis para realizar una prediccin a travs de una funcin obtenida teniendo en cuenta informacin histrica.

Segn KitchenhamKitchenham propone una clasificacin ms simple para estos modelos, basada en distinguir entre aquellos que especifican la relacin entre varios parmetros de costo, llamados modelos de restriccin, y los que predicen el valor de un parmetro de costo, llamado modelos de factor emprico.Otras clasificacionesOtras maneras ms simples de clasificar los modelos de estimacin distinguen tres categoras bsicas: Juicio experto: aunque no es un mtodo en el sentido estricto de obtener resultados de una manera explcita y repetitiva, es una de las prcticas ms extendidas, en las que se combinan las opiniones de varios expertos para obtener estimaciones, como por ejemplo el mtodo Delphi. Modelos algortmicos: se basan en frmulas y parmetros con los que realizan las estimaciones. Son tambin muy conocidos y empleados en la actualidad, encontrndose en este grupo el modelo COCOMO o puntos de funcin. Analoga: puede ser tomada como una variante del juicio experto, ya que tambin intervienen las opiniones de los estimadores, pero a diferencia de este tipo, necesita caracterizar claramente el proyecto que se va a estimar y almacenar los proyectos previos para buscar entre ellos el ms parecido al actual.

8.2 METODOS DE ESTIMACINUn mtodo de estimacin eficaz permitir ignorar aspectos sin inters y concentrare en los aspectos esenciales. Un buen modelo debera poseer capacidades predictivas, mejor que ser meramente descriptivo o explicativo.La validez de las mtricas de software y de los modelos de estimacin debe ser establecida demostrando la coincidencia entre los datos empricos y los experimentales. Esto requiere una cuidadosa atencin en la toma de medidas y en el anlisis de los datos.En general, el anlisis y la validacin de las mtricas y los modelos de estimacin requiere una slida base estadstica y diseo de experimentos. Para obtener resultados significativos son necesarios una definicin precisa de las mtricas involucradas y de los procedimientos para la captura de datosLos modelos de estimacin existentes se pueden clasificar como Modelos Estadsticos, Modelos basados en Teoras y Modelos Compuestos. 8.2.1 MODELOS ESTADSTICOSC.E. Walston y P.C. Felix, de IBM utilizaron datos de 60 proyectos terminados completamente para desarrollar un modelo simple de clculo del esfuerzo de desarrollo de software.El principal determinante del esfuerzo de desarrollo fue la mtrica LOC.Se asumi una relacin de la forma: E = aLb, donde L es el nmero de lneas de cdigo, en miles y E es el esfuerzo total requerido en meses/personas. Mediante un anlisis de regresin se encontraron los valores apropiados para a y b.La ecuacin resultante fue:

La productividad nominal de programacin en LOC por persona/mes, puede ser calculada como L/E. Walston y Felix tambin intentaron desarrollar un ndice de productividad, I, que podra hacer incrementar o disminuir la productividad, dependiendo de la naturaleza del proyecto.8.2.2 MODELOS BASADOS EN TEORAS: MODELO DE PUTNAM.Pocos modelos propuestos tienen una base tcnica substancial. El modelo ms importante es el de Putnam. Este modelo asume una distribucin especfica del esfuerzo a lo largo de la vida de un proyecto de desarrollo de software. El modelo se ha obtenido a partir de distribuciones de mano de obra en grandes proyectos. Sin embargo, se puede extrapolar a proyectos ms pequeos.

Putnam desarroll la siguiente relacin entre el tamao del producto software y el tiempo de desarrollo:

donde L = el nmero de instrucciones fuente producidas.E = el esfuerzo durante todo el ciclo de vida en aos/personaC = una constante dependiente de la tecnologa.T = el tiempo de desarrollo en aos.Los valores tpicos de C pueden ser: C = 2.000 para un entorno pobre de desarrollo de software (sin metodologa, con una documentacin y unas revisiones pobres); C = 8.000 para un buen entorno de desarrollo de software (con una buena metodologa, adecuadas documentacin y revisiones); C = 11.000 para un entorno excelente (con herramientas y tcnicas automticas). Se puede obtener la constante C correspondiente al entorno propio a partir de datos histricos recopilados sobre anteriores esfuerzos de desarrollo.8.2.3 MODELOS COMPUESTOSSon modelos que utilizan una combinacin de intuicin, anlisis estadstico y juicio de expertos. Entre los ms importantes estn:a) Modelo COCOMO de Boehm.Es probablemente el ms conocido y slidamente documentado de todos los modelos de estimacin de costes. Por lo que desarrollaremos este modelo a ms detalle.Este modelo se aplica a los desarrollos que siguen el ciclo de vida en cascada, e incorpora dentro de esas etapas procesos como: Verificacin y Validacin, Gestin de Configuracin.Existen tres modos de desarrollo de software segn COCOMO: orgnico, semilibre y rgido, segn las caractersticas de la aplicacin y del entorno de desarrollo. A cada uno de estos modelos se le puede aplicar tres mtodos de estimacin distintos: bsico, intermedio y detallado.Cuando un ingeniero de software est ante un proyecto a estimar, lo primero que debe hacer para aplicar el COCOMO es situar su proyecto en el espacio de dos dimensiones (modo, modelo) de la Figura 6.1.En la Figura 6.1, Px es un proyecto que va a ser desarrollado segn un modelo Semilibre, dado el tipo de aplicacin y el equipo del que se dispone, y se va estimar segn COCOMO Detallado, dada la exactitud que se requiere de la estimacin.

6.2. Modos de Desarrollo de SoftwareEste modelo considera tres modos distintos de desarrollo de software:6.2.1. Modo OrgnicoEste modo se caracteriza por lo siguiente: El proyecto se desarrolla en equipos relativamente pequeos en un entorno familiar, en la propia empresa. Muchas personas relacionadas con el proyecto tienen amplia experiencia trabajando en sistemas similares dentro de la propia organizacin y tienen un buen conocimiento de cmo el sistema que se est desarrollando contribuir a los objetivos de la Organizacin. Esto significa que muchas personas podrn contribuir al proyecto desde las primeras etapas, sin generar una sobrecarga de comunicacin importante. Se desarrolla en un entorno generalmente estable, con muy pequea probabilidad de coincidencia en el desarrollo de un nuevo hardware u operaciones desconocidas. Mnima motivacin para terminar el proyecto antes de lo previsto.6.2.2. Modo SemilibreEste modelo se caracteriza por lo siguiente: El equipo del proyecto tiene un nivel medio de experiencia en proyectos similares. El equipo es una combinacin de personal experto e inexperto. Algunos miembros del proyecto tienen alguna experiencia en aspectos del proyecto y otros no. El tipo de proyectos representativo podra ser un sistema de proceso de transacciones con interfaces muy poco rigurosas en algunos casos y muy rgidas en otros.

6.2.3. Modo RgidoLos elementos caractersticos de este modo de desarrollo son: Proyectos que deben desarrollarse dentro de unas limitaciones muy estrictas. El producto debe explotarse dentro de un entorno muy acoplado de hardware, software, normativa y procedimientos operativos. Los costes de cambiar algo en este complejo entramado son tan altos, que sus caractersticas se consideran inmodificables, as que el software debe realizarse estrictamente conforme a las especificaciones. Estos proyectos se desarrollan en reas generalmente desconocidas, lo cual lleva inicialmente a equipos pequeos de analistas y a una sobrecarga de comunicacin importante durante el desarrollo. Se aplica a proyectos de cualquier tamao

6.3.1. Modelo BsicoSe suele aplicar en los desarrollos de productos pequeos/medios, desarrollados por personal de la propia empresa en modo orgnico. Aunque tambin puede aplicarse al resto de los modos. Las ecuaciones de estimacin de esfuerzo y tiempo de desarrollo para cada modo de desarrollo:

Donde,KDSI significa nmero de instrucciones de cdigo en miles.MM significa esfuerzo medido en Meses/Hombre.TDEV significa duracin en Meses.

6.3.2. Modelo IntermedioEl modelo intermedio incorpora 15 variables de prediccin que influyen en el coste del proyecto. Estas variables se agrupan en cuatro categoras: atributos del producto software, atributos del ordenador, atributos de personal y atributos del proyecto.6.3.2.1. Atributos del Producto Software RELY : Fiabilidad requerida del software. DATA : Tamao de la base de datos. CPLX : Complejidad del Producto.6.3.2.2. Atributos del Ordenador TIME : Limitaciones en el Tiempo de Ejecucin. STOR : Limitaciones de Memoria Principal VIRT : Volatilidad de la Mquina Virtual. TURN : Frecuencia de cambio en el modelo de explotacin del ordenador.6.3.2.3. Atributos de Personal ACAP : Capacitacin de los Analistas. AEXP : Experiencia en Aplicaciones. PCAP : Capacitacin de los Programadores. VEXP : Experiencia en la Maquina Virtual. LEXP : Experiencia en el Lenguaje de Programacin. 6.3.2.4. Atributos del Proyecto MODP : Prcticas Modernas de Programacin TOOL : Uso de herramientas para el Desarrollo de Software SCED : Limitaciones en la planificacin.La estimacin de esfuerzo aplicando este modelo es:

El tiempo de desarrollo TDEV se calcula como en el Modelo Bsico.

6.3.3. Modelo DetalladoEl Modelo Intermedio tiene dos limitaciones que pueden ser significativas en la estimacin detallada de coste en grandes proyectos de software: La distribucin de esfuerzo por fases puede ser inadecuada. Puede ser muy engorroso utilizarlo en un producto con muchos componentes.

El modelo detallado presenta dos funcionalidades que resuelven las limitaciones de COCOMOIntermedio:

l. Multiplicadores de esfuerzo por fases: El modelo detallado proporciona un conjunto de multiplicadores de esfuerzo para cada atributo en cada fase. Estos multiplicadores determinan el esfuerzo requerido para completar cada fase.

2. Descomposicin jerrquica del producto a tres niveles.El COCOMO detallado evita este problema proporcionando una jerarquizaron del producto a tres niveles: Nivel mdulo. Nivel subsistema. Nivel sistema.No se desarrolla este modelo dado que su aplicacin queda reservada a grandes proyectos no muy frecuentes.c) SPQR - Capers JonesCapers Jones ha desarrollado un modelo de estimacin de costes llamado Software Productivity, Quality and Reliability (SPQR).El enfoque del problema es similar al de Boehm en su modelo COCOMO. Est basado en 20 factores que influyen razonablemente en el coste y productividad del desarrollo de software y que estn bien definidos y otros 25 factores que no estn tan bien definidos.SPQR es un producto comercial, pero no est tan bien documentado como otros modelos. Requiere responder a ms de 100 preguntas relacionadas con el proyecto para formular los parmetros de entrada necesarios en el clculo de los costes y los planes. Jones seala que con este modelo es posible proporcionar estimaciones de coste que estarn el 90% de las veces dentro del valor real con una desviacin del 15%.

d) COPMO - ThebautThebaut propone un modelo de desarrollo de software que intenta contabilizar el esfuerzo requerido cuando los equipos de programacin estn involucrados en grandes proyectos. La ecuacin general de clculo de esfuerzo es:

dondea, b, c y d son constantes para ser determinadas a partir de datos empricos mediante anlisis de regresin: S es el tamao del programa en miles de LOC P es el nivel medio de personal durante el ciclo de vida del proyecto.Desafortunadamente, este modelo requiere no uno sino dos parmetros cuyos valores no son conocidos hasta la terminacin del proyecto. Adems, las constantes b y c dependientes de la complejidad del software no son fcilmente determinables.Este modelo presenta una formula interesante, pero necesita un mayor desarrollo y ajuste para que sea de inters general.