You are on page 1of 8

Tcnicas de Estimacin.

Una vez definidas las mtricas de Software podemos entender las diferentes tcnicas existentes para la estimacin, existen principalmente cuatro tcnicas de estimacin. 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 partir del esfuerzo requerido para producir los componentes ms pequeos o para realizar las tareas de nivel inferior. La estimacin global de un 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. Requisitos de un Buen Mtodo de Estimacin Un mtodo de estimacin tendr xito s: La estimacin inicial est dentro de un 30 % de desviacin del costo 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.

Mtodos de Estimacin Un mtodo de estimacin eficaz permitir ignorar aspectos sin inters y concentrase en los aspectos esenciales. Un buen modelo debera poseer capacidades predicitivas, mejor que ser meramente descriptivo o explicativo. La validez de las mtricas de Software y de los modelos de estimacin debe ser establecida mostrando la coincidencia entre los datos empricos y experimentales. Esto requiere una cuidadosa atencin en la toma de medidas y en el anlisis de los datos. Los modelos de estimacin existentes se pueden clasificar como Modelos de Estadsticos, Modelos basados en Teoras y Modelos Compuestos. A continuacin describiremos cada uno de ellos. Modelos Estadsticos C.E Walson y P.C. Felix, de IBM utilizaron datos de 60 proyectos terminados completamente para desarrollar un modelo simple de calculo 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 una anlisis de regresin se encontraron los valores apropiados para a y b. La ecuacin resultante fue: E = 5,2 L 0,91

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. Modelos basados en Teoras: Modelo de Putnam. 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 partir de distribuciones de mano de obra de 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. E = L3 / (C3T4) Donde: L = el nmero de instrucciones fuente producidas E = el esfuerzo durante todo el ciclo de vida en aos / personas. C = una constante dependiente de la tecnologa T = el tiempo de desarrollo en aos. Los varios tipos 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 tecnologa adecuada, documentacin y revisiones); C = 1.100 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 los anteriores esfuerzos de desarrollo. Mtodos Compuestos Son modelos que utilizan una combinacin de intuicin anlisis estadstico y juicio de expertos. A continuacin se describen los ms importantes.

1. Modelos COCOMO de Boehm. Es probablemente el ms conocido y slidamente documentado de todos los modelos de estimacin de costos. Mas adelante se estudiara en profundidad este modelo, con aplicaciones prcticas.

2. SOFTCOST. Tausworthe: Trausworthe, de Jet Propulsin Laboratory, intent desarrollar una estimacin de costo del Software utilizando elementos de los modelos con ms xito disponibles. Este modelo requiere 68 parmetros de entrada, cuyos valores se deducen a partir de las respuestas del usuario a 47 preguntas acerca del proyecto.

3. SPQR- Capers Jones: Capers Jones ha desarrollado un modelo de estimacin de costos 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 costo y productividad del desarrollo del software y que estn bien definidos y otros 25 factores que no estn tan bien definidos. SPQR es un producto comercial, pero no esta tan bien documentados como otros modelos. Requiere responder a ms de 100 preguntas relacionadas con el proyecto para formular los parmetros de entrada necesarios en el calculo de los costos y los planes. Jones seala que con este modelo es posible proporcionar estimaciones de costo que estarn el 90% de las veces dentro del valor real con una desviacin del 15%. 1. COPMO- Thebaut: Thebaut 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 calculo de esfuerzo es: E = a + bS + cPd Donde: A,b,c,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 medio de personal durante el ciclo de vida del proyecto Desafortunadamente, este modelo no requiere uno si no 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 frmula interesante, pero necesita un mayor desarrollo y ajuste par que sea de inters general. Herramientas Automticas de Estimacin Las tcnicas de descomposicin y los modelos empricos de estimacin descritos en las secciones anteriores se pueden implementar con Software. Las herramientas automticas de estimacin permiten al planificador estimar costos y esfuerzos, as como llevar a cabo anlisis del tipo "qu pasa s" con importantes variables del proyecto, tales como la fecha de entrega o la seleccin de personal. Aunque existen muchas herramientas automticas de estimacin, todas exhiben las mismas caractersticas generales y todas requieren una o ms clases de datos como los mostrados a continuacin:

1. Una estimacin cuantitativa del tamao del proyecto ( por ejemplo, en LDC) o de la funcionalidad ( datos sobre los puntos de funcin)

2. Caractersticas cualitativas del proyecto, tales como la complejidad, fiabilidad requerida o el grado de criticidad del negocio.

3. Alguna descripcin del personal de desarrollo y/o del entorno de desarrollo.

A partir de estos datos, el modelo implementado por la herramienta automtica de estimacin proporciona estimaciones del esfuerzo requerido para llevar acabo el proyecto, los costos, la carga del personal, la duracin y en algunos casos, la planificacin temporal del desarrollo y el riesgo asociado.

2.5 Planificacin de Proyectos.

El objetivo de planificacin del proyecto de Software es proporcionar un marco de trabajo que permita al gestor hacer estimaciones razonables de recursos, costo y planificacin temporal. Estas estimaciones se hacen dentro de un marco de tiempo limitado al comienzo de un proyecto de Software, y deberan actualizarse a medida que progresa el proyecto. Adems, las estimaciones deberan definir los escenarios del " mejor caso " y " peor caso " de forma que los resultados del proyecto puedan limitarse . El objetivo de la planificacin se logra mediante un proceso de descubrimiento de la informacin que lleve a estimaciones razonables. mbito del Software. La primera actividad de la planificacin del proyecto de Software es determinar el mbito del Software . Se deben evaluar la funcin y el rendimiento que se asignaron al Software durante la ingeniera del sistema. El mbito del Software describe la funcin, el rendimiento, las restricciones, las interfases y la fiabilidad. Se evalan las funciones descritas en el enunciado del mbito, y en algunos casos se refinan para dar ms detalles antes del comienzo de la estimacin. La tcnica ms utilizada con frecuencia para acercar al cliente y al desarrollador, y para hacer que comienza el proceso de comunicacin es establecer una entrevista preliminar. La comunicacin con el cliente lleva a una definicin de datos , funciones, y comportamientos a implementarse, y de informacin sobre el rendimiento y imitaciones que delimitan el sistema. Recursos La segunda tarea de la planificacin del desarrollo de Software es la estimacin de los recursos requeridos para acometer el esfuerzo de desarrollo de Software.

En base a la pirmide de recursos se encuentra el entorno de desarrolloHardware y Software- que proporciona la infraestructura de soporte al esfuerzo de desarrollo. En un nivel ms alto se encuentra los componentes del Software Reutilizables, los bloques de Software que pueden reducir drsticamente los costos de desarrollo y acelerar la entrega. En la parte ms alta esta el recurso primario- las personas. Recursos Humanos El encargado de la planificacin comienza elevando el mbito y seleccionando las habilidades tcnicas que se requieren para llevar acabo el desarrollo. El nmero de personas requeridas para un proyecto de Software slo puede ser determinado despus de hacer una estimacin del esfuerzo de desarrollo ( por ejemplo, personas - mes o personas - aos.) Recursos de Software Reutilizables. Cualquier estudio sobre recurso de Software estara incompleto sin estudiar la reutilizacin, esto es, la creacin y la reutilizacin de bloques de construccin de software [H0091]. Tales bloques deben establecerse en catlogos para una consulta ms fcil, estandarizarse para una fcil aplicacin y validarse para tambin la fcil integracin. Bernnatan [BEN92] sugiere cuatro categoras de recursos de Software que se deberan tener en cuenta a medida que se avanza con la planificacin.

Componentes ya desarrollados. El Software existente se puede adquirir de una tercera parte o provenir de uno desarrollado internamente para un proyecto anterior. Estos componentes estn listos para utilizarse en el proyecto actual y se han validado totalmente. Componentes ya experimentados. Las especificaciones, diseos, cdigos, o datos de pruebas ya existentes y desarrollados para proyectos anteriores que son similares al Software que se va a construir para el proyecto actual. Los miembros del equipo del Software actual ya han tenido la experiencia completa en el rea de la aplicacin representada para estos componentes, Las modificaciones, por tanto, requeridas para componentes de total experiencia, tendr un riesgo relativamente bajo. Componentes con experiencia parcial. Las especificaciones, los diseos, cdigos o los datos de prueba existentes ya desarrollados para proyectos anteriores que se relacionan con el Software que se va a construir para el proyecto actual, pero que requerirn una modificacin sustancial. Los miembros del equipo del Software actual han limitado su experiencia slo al rea de aplicacin representada por estos componentes. Las modificaciones, por tanto, requeridas para componentes de experiencia parcial tendrn bastante grado de riesgo. Componentes nuevos. Los componentes de Software que el equipo de Software debe construir son especficamente para las necesidades del proyecto actual. Recursos de entorno El entorno es donde se apoya el proyecto de Software, llamado a menudo entorno de Ingeniera de Software(EIS) incorpora Hardware y Software. El Hardware proporciona una plataforma con las herramientas (Software) requeridas para producir los productos que son el resultado de una buena prctica de la ingeniera de Software.

You might also like