estimación

Sistemas de Información

UNIVERSIDAD TÉCNICA DE AMBATO INGENIERIA EN SISTEMAS


Renato Urvina




Renato Urvina

Estimación de Proyectos SoftwareConceptos Básicos Importancia

Puntos de FunciónConceptos Ejercicios

COCOMOConceptosEjercicios



Pide entendimiento y busca la sabiduría como si buscaras plata o un

tesoro escondido. Así llegarás a entender lo que es obedecer a Dios y

conocerlo de verdad. Sólo Dios puede hacerte sabio; sólo Dios puede darte conocimiento.

Proverbios 2 3:6



1. Estimación de Proyectos Software

2. Puntos de Función

3. Cocomo



Estimación de Proyectos Software

Estimación

“Apreciar, poner precio, evaluar algo”

Estimación de proyectos de software

“Actividad de la planificación del proyecto de sw

que intenta determinar cuánto dinero, esfuerzo,

recursos y tiempo tomará construir un sistema o

producto sw”.

¿Que es la estimación?




• No necesita realizarse en una forma improvisada.

• La experiencia es una gran ayuda.

• La estimación implica riesgo inherente, y esteconduce a la incertidumbre.

• El riesgo de la estimación se mide por el grado deincertidumbre en las estimaciones cuantitativas pararecursos, costos y programa de trabajo.

¿Que es la estimación?




Un gran error en la estimación puede hacer la diferencia entre Ganancia o Perdida.

Mala Estimación

Desastre para el

Desarrollador

Importancia de la estimación



Estimación de Proyectos Software Importancia de la estimación

La realización de estimaciones adecuadassobre el tamaño y esfuerzo requerido es una delas características fundamentales de unproyecto de desarrollo de software exitoso.

Las malas estimaciones o más comúnmentelas no estimaciones, son posiblemente una delas principales causas de los fracasos.



Estimación de Proyectos Software Importancia de la estimación

Las estimaciones están asociadas con elesfuerzo, costo y el tiempo de las actividadesidentificadas del proyecto.

El objetivo de la estimación de proyectoses reducir los costos e incrementar losniveles de servicio y de calidad.



Estimación de Proyectos SoftwareEstimación en proyectos de

software



Estimación de Proyectos Software ¿En qué consiste la estimación

de proyectos software? «Aplicación continua de

técnicas basadas en las

medidas de los procesos

de desarrollo del software

y sus productos, para

producir una información

de gestión significativa y a

tiempo. Esta información

se utilizará para mejorar

esos procesos los

productos que se obtienen

de ellos» (SYMONS, C.,

1998).



Estimación de Proyectos Software ¿Cuál es el objetivo de la

estimación?

Predecir las variables involucradas en el proyecto con

cierto grado de certeza.

Trata de aportar una predicción de algún indicador

importante para la gestión de proyectos de

software tiempo, esfuerzo, cantidad de defectos

esperados entre otros.

Es razonable conocer, antes de comenzar a desarrollar

el SW, cuánto se va a invertir, qué tareas se deben

realizar y cuánto tiempo se necesitará.



Estimación de Proyectos Software ¿Quién es y cuál es el objetivo del

estimador de un proyecto software?

El estimador debe ser un profesional que no tenga

ningún interés, directo o indirecto, en los resultados del

proceso de estimación y que este únicamente guiado

por su profesionalismo.

El principal objetivo del estimador es obtener

estimaciones de calidad, las cuales no tienen siempre

por qué coincidir con las expectativas de la empresa

en términos de costo y tiempo.



Estimación de Proyectos Software Requisitos que debe cumplir

un buen estimador… Formación y experiencia profesional adecuada.

Una posición en la organización que le permita adoptar un juicio

independiente.

Debe basarse en un método que pueda ser explicado, cuestionado,

discutido y auditado.

Debe poder describir su experiencia en cada estimación.

Debe documentar su estimación, incluyendo los resultados

obtenidos y cualquier información necesaria para hacer el proceso

de estimación repetible y verificable.



Estimación de Proyectos Software ¿Cuándo se debe llevar a cabo?

La estimación es un proceso continuo. A

medida que el proyecto avanza, más se conoce

de él, y por lo tanto más parámetros están

disponibles para introducir en un modelo de

estimación.

La estimación continua nos permite el uso de un

único modelo coherente que pueda capturar y

utilizar la información sobre el proyecto a

medida que éste se conozca.



Estimación de Proyectos Software ¿Cuándo se debe llevar a cabo?

El proceso de estimación comienza usando

unas pocas variables claves para proveer las

«macrocaracterísticas» de un proyecto, y

evoluciona incorporando información de más

bajo nivel para producir las «micro-

características» del proyecto.



Estimación de Proyectos Software Ejemplo con un MCVS en cascada



Estimación de Proyectos SoftwareTécnicas de estimación…

La opinión de los expertos

Esta técnica se basa en la experiencia profesional de

los Participantes en el proyecto de estimación.

La analogía

o Se basa en la comparación directa de uno o más

proyectos pasados.

o Para poder utilizar esta técnica es necesario disponer

de una base de datos histórica de proyectos finalizados

con la que poder realizar la comparación.

o Los proyectos deben tener muchas similitudes en

cuanto a su esquema.




La descomposición

o Consiste en la descomposición de un producto en

componentes más pequeños, o descomponer un

proyecto en tareas de nivel inferior.

o La estimación se hace a partir del esfuerzo requerido

para producir los componentes más pequeños o para

realizar las tareas de nivel inferior.

Las ecuaciones de estimación (basado en tamaño):

o Son fórmulas matemáticas que establecen la relación de

algunas medidas de entrada (que normalmente es la

medida del tamaño del producto) y determinan el

esfuerzo que se requerirá.




Técnicas de estimación…

basado en tamaño del producto



Estimación de Proyectos Software Técnicas de estimación…

basado en tamaño

• Podemos considerar dos tamaños del software:• Tamaño en LDC.

• Tamaño en PF.

• En cualquier caso, la precisión de la estimación depende de:• El grado en el que el planificador ha estimado

adecuadamente el tamaño del producto a construir.




basado en tamaño

• La habilidad para traducir la estimación deltamaño en esfuerzo y dinero. Dependefundamentalmente de la existencia demétricas.

El grado en que el plan del proyecto refleja lashabilidades del equipo de software.




basado en tamaño

METRICA“Un Método y una escala cuantitativos quepueden ser usados para determinar elvalor que toma cierta característica en unproducto de software concreto.”




Clasificación de las MétricasMÉTRICAS TÉCNICAS: Se centran en las características de

software.

MÉTRICAS DE CALIDAD: proporcionan una indicación de cómo se ajusta el software a los requisitos implícitos y explícitos del

cliente.

MÉTRICAS DE PRODUCTIVIDAD. Se centran en el rendimiento del proceso de la ingeniería del software.




Clasificación de las Métricas

MÉTRICAS ORIENTADAS A LA PERSONA. Proporcionan medidas e información sobre la forma que la gente desarrolla el software

de computadoras y sobre todo el punto de vista humano de la efectividad de las herramientas y métodos.

MÉTRICAS ORIENTADAS AL TAMAÑO. Es para saber en que tiempo voy a terminar el software y cuantas personas voy a

necesitar.




Clasificación de las Métricas

MÉTRICAS ORIENTADAS A LA FUNCIÓN. Son medidas indirectas del software y del proceso

por el cual se desarrolla.

Métricas del Software

Métricas Orientadas al tamaño

Métricas Orientadas a la función

Medidas directas del resultadoy del proceso

Medidas indirectas del software y del proceso

• Sistemas de Información


Métricas orientadas al tamaño

Esfuerzo humano (persona - mes)

Coste (USD)

Páginas de documentación

N° de errores

N° de defectosLDC

Productividad = KLDC / persona-mesCalidad = N° de errores (defectos) / KLDCCoste medio = USD / KLDCDocumentación = KLDC / persona-mes



METRICA LDC• Calcular la productividad, calidad, coste medio y documentación de acuerdo a lainformación proporcionada en la tabla que se muestra a continuación: Productividad = KLDC / personas-mes Calidad = Nº errores (defectos) / KLDC Coste medio = Dólares / KLDC Documentación = Páginas de documentación / KLDC

PROYECTO LDC ESFUERZO $(MILES) PAG. DOC ERRORES DEFECTOS PERSONAS

Alfa 12,100 24 168 365 134 29 3

Beta 27,200 62 440 1,224 321 86 5

Gama 20,200 43 314 1,050 256 64 6



METRICAS LDCCon los datos contenidos en la tabla se puede obtener un conjunto de métricas

simples adicionales:

• No. De Errores por LDC 134 / 12,100 0.01 Errores / LDC

• No. De Defectos por LDC 29/12,100 0.002 Defectos / LDC

• Costo por LDC 168,000 / 12,100 $ 13.88 / LDC

• LDC por persona-mes 12,100 / 24 904 LDC/p-m



METRICA LDCVentajas:

• - Es una métrica fácil de comprender.

• - Muchos modelos, herramientas automáticas y literatura de estimación se basan en LDC.



METRICA LDC

• Desventajas:

• Las LDC son dependientes del lenguaje. Escribir el mismo programaen lenguajes diferentes puede arrojar una diferencia en LCF bastantegrande.

• Resulta difícil que el planificador estime las LCF a producirse muchoantes de que se complete el análisis y el diseño, más aún si no tienedatos históricos.

-34-

Hay que desarrollar un software CAD que aceptará datos geométricos de 2 o 3 dimensiones por parte del ingeniero. Éste controlará el sistema CAD por medio de una interfaz que debe tener un diseño de buena calidad. Una base de datos CAD contiene todos los datos geométricos y la información de soporte. Se desarrollarán módulos de análisis de diseño para producir la salida requerida que se va a visualizar en varios dispositivos gráficos.El software se diseñará para controlar e interconectar diversos periféricos, como un ratón, un digitalizador y una impresora láser.

Funciones identificadas:interfaz de usuario y facilidades de control (IUFC)análisis geométrico de dos dimensiones (AG2D)análisis geométrico de tres dimensiones (AG3D)gestión de base de datos (GBD)facilidades de la interfaz gráfica (FIG)control periféricos (CP)módulos de análisis del diseño (MAD)

Estimación en LDC de AG3D:optimista: 4600más probable: 6900pesimista: 8600

VE = (Sopt + 4Sm + Spes)/6

Función LDC estimada

IUFC 2300AG2D 5300AG3D 6800GBD 3350FIG 4950CP 2100MAD 8400Total 33200

Datos históricos:productividad media de la organización en proyectos similares: 620 LDC/pm

Tarifa laboral: 8000 $ /mes

Coste LDC: $ 13 ($12.90)

de

sco

mpo

sic

ión

de

funcio

ne

sm

étr

icas d

ep

roye

cto

s

ante

rio

res

Coste total proyecto: $ 431.600

Esfuerzo estimado: 54 personas-mes

Métricas orientadas a la función

salidas

entradas

consultas

Ficheros logicosinternos

Ficheros de interfaz

PF

Estimación

OptimistaMas

ProbablePesimista

Valor Esperado

Entradas

• Informaciones que llegan a la aplicación desde el exterior.

• Tienen una sola dirección (Exterior à Interior)

• Siempre actualizan algún fichero interno.

4. Apendice, Métrica de los puntos de función. 37

Clasificación de las salidas

DIFICULTAD

SALIDAS

Número de Campos o Atributos de la Salida

1-5 Atributos 6-19 Atributos 20 + Atributos

0 ó 1 ficheros

accedidosBAJA BAJA MEDIA

2 ó 3 ficheros

accedidosBAJA MEDIA ALTA

4 + ficheros

accedidosMEDIA ALTA ALTA

Salidas

• Informaciones elaboradas por la aplicación que son transmitidas al usuario.

• Tienen una sola dirección (Interior a Exterior)


Consultas

• Entradas que producen inmediatamente una salida

• No modifica los datos del sistema


4. Apendice, Métrica de los puntos de función.

41

Clasificación de las consultas

• Calculamos la complejidad de la parte de entrada

• Calculamos la complejidad de la parte de salida

• Nos quedamos sólo con la complejidad mayor de las dos.

Ficheros Lógicos o Internos

• Agrupaciones de datos, tal y como los percibe el usuario

• Es diferente de:• Entidades y Relaciones

• Tablas o archivos resultantes del diseño físico

• Los grupos de datos serán accedidos y actualizados por la aplicación


Clasificación de los Ficheros Lógicos o Internos

DIFICULTAD

FICHEROS

Número de Campos o Atributos

LÓGICOS 1-19 Atributos 20-50Atributos 51 + Atributos

1 Registro

LógicoBAJA BAJA MEDIA

2 a 5 Registros

LógicosBAJA MEDIA ALTA

6 o más

Registros Lógic.MEDIA ALTA ALTA

Ficheros de Interfaz

• Ficheros a los que accede la aplicación con el único objetivo de obtener información.

• Son mantenidos por otras aplicaciones

• Nunca los actualiza la aplicación.


DIAGRAMA DE CONTEXTO

Clasificación de los Ficheros de Interfaz

DIFICULTAD

FICHEROS

Número de Campos o Atributos

DE INTERFAZ 1-19 Atributos 20-50Atributos 51 + Atributos

1 Entidad o

Registro LógicoBAJA BAJA MEDIA

2 a 5 Registros

LógicoBAJA MEDIA ALTA

6 o más

Registros Lógic.MEDIA ALTA ALTA

TABLA PARA CALCULAR PUNTOS DE FUNCION

FACTORES DE COMPLEJIDAD

• Son catorce factores que completan la visión externa de la aplicación.

• No están recogidos en la funcionalidad de la aplicación.

• Toman un valor entre 0 y 5

Factores de Ajuste de Complejidad: evaluar cada factor de 0 a 5

0- Sin influencia 3- Medio

1- Incidental 4- Significativo

2- Moderado 5- Esencial

1. ¿Requiere el sistema copias de seguridad fiables?

2. ¿Se requieren comunicaciones de datos?

3. ¿Existen funciones de procesamiento distribuido?

4. ¿Es crítico el rendimiento?

5. ¿Será ejecutado el sistema en un entorno operativo existente y utilizado?

6. ¿Se requiere entrada de datos interactiva?

7. ¿Requiere la entrada interactiva que las transacciones de entrada se hagan sobre múltiples pantallas o variadas operaciones?

8. ¿Se actualizan los archivos maestros de forma interactiva?

9. ¿Son complejas las entradas, las salidas, los archivos o las peticiones?

10.¿Es complejo el procesamiento interno?

11.¿Se ha diseñado el código para ser reutilizable?

12.¿Están incluidas en el diseño la conversión y la instalación?

13.¿Se ha diseñado el sistema para soportar múltiples instalaciones en diferentes organizaciones?

14.¿Se ha diseñado la aplicación para facilitar los cambios y ser

Métricas orientadas a la función

PF = cuentatotal X [0,65 + 0,01 * Sumatoria (Fi) ]

Punto de función

Sumatoria total resultante de la ejecutar las operaciones en la

tabla siguiente

Valores de ajuste de

complejidad

En función de un cuestionario de 14 preguntas

• Para el ejemplo descrito se asume que la Fi es 46 (un productomoderadamente complejo), por consiguiente:

PF = 50 x (0,65 + 0,01 x 46) = 55.5 ≈ 56

• Donde cuenta-total es la suma de todas las entradas PF obtenidas de lafigura 9.2 y Fi (i=1 a 14) son los "valores de ajuste de complejidad".

Factor de ponderación

Parámetro de medición Cuenta Simple Media Compl.ejo

Número de entradas del usuario 3 X 3 4 6 = 9

Número de salidas del usuario 2 X 4 5 7 = 8

Número de consultas del usuario 2 X 3 4 6 = 6

Número de archivos 1 X 7 10 15 = 7

Número de interfaces externas 4 X 5 7 10 = 20

Cuenta total 50

Fig. Cálculo de puntos de función

Número entradas usuario x 3 4 6 =

Número salidas de usuario x 4 5 7 =

Número peticiones al usuario x 3 4 6 =

Número de archivos x 7 10 15 =

Número interfaces externos x 5 7 10 =

Cuenta total

Parámetro de medida Cuenta Simple Medio Complejo

Factor de peso

PF = Cuenta Total x [0,65 + 0,01 x SUM(Fi)]

Fi : valores de ajuste de complejidad

Factores de Ajuste de Complejidad: evaluar cada factor de 0 a 50- Sin influencia 3- Medio

1- Incidental 4- Significativo

2- Moderado 5- Esencial

1. ¿Requiere el sistema copias de seguridad fiables?2. ¿Se requieren comunicaciones de datos?3. ¿Existen funciones de procesamiento distribuido?

4. ¿Es crítico el rendimiento?5. ¿Será ejecutado el sistema en un entorno

operativo existente y utilizado?6. ¿Se requiere entrada de datos interactiva?7. ¿Requiere la entrada interactiva que las

transacciones de entrada se hagan sobre múltiples pantallas o variadas operaciones?

8. ¿Se actualizan los archivos maestros de forma interactiva?

9. ¿Son complejas las entradas, las salidas, los

archivos o las peticiones?10.¿Es complejo el procesamiento interno?

11.¿Se ha diseñado el código para ser reutilizable?12.¿Están incluidas en el diseño la conversión y la

instalación?

13.¿Se ha diseñado el sistema para soportar múltiples instalaciones en diferentes

organizaciones?14.¿Se ha diseñado la aplicación para facilitar los

cambios y ser fácilmente utilizada por el usuario?

-52-

Valor dominio información

Opt. Probable Pesimista Cuenta est

Peso Cuenta PF

Num. entradas 20 24 30 24 4 96

Num. salidas 12 15 22 16 5 80

Num. peticiones 16 22 28 22 4 88

Num. archivos 4 4 5 4 10 40

Num. interfaces ext. 2 2 3 2 7 14

Cuenta total 318

Copia de seguridad y recuperación 4Comunicaciones 2Proceso distribuido 0Rendimiento crítico 4Entorno operativo existente 3Entrada de datos online 4Transacciones entrada en varias pant. 5Archivos maestros actualizados online 3Complejidad valores dominio información 5Complejidad procesamiento interno 5Código diseñado para reutilización 4Conversión en diseño 3Instalaciones múltiples 5Aplicación diseñada para cambios 5

PF estimado = cuenta total x (0,65 + 0,01 x Suma (Fi)

PF estimado = 372

Coste total proyecto: $ 457.843

Esfuerzo estimado: 58 personas-mesDatos históricos:productividad media de la organización en proyectos similares: 6,5 PF/pm

Tarifa laboral: 8000 $ /mes

Coste por PF: $ 1.230 ($1230,76)

mé

tric

as d

ep

roye

cto

s

ante

rio

res

EJEMPLO PF

53

Desarrollo de un proyecto matemático de métodos numéricos:

Datos :

Productividad = 1000 pf / per-mes

Sueldo = 3000 $/ per-mes

TIPO DE FUNCIONNIVEL DE COMPLEJIDAD

TOTALSIMPLE MEDIO COMPLEJO

Entradas de

Usuario

* 3 18 * 4 = 72 * 6 72

Salidas de Usuario * 4 25 * 5 = 125 * 7 125

Archivos Internos 5 * 7 = 35 * 10 * 15 35

Archivos Externos * 5 2 * 7 = 14 * 10 14

Consultas de

Usuario

* 3 20 * 4 = 120 * 6 120

TOTAL PF SIN AJUSTAR PF = 366

54

PF = Cuenta Total x [0,65 + 0,01 x SUM(Fi)]

PF = ( 366 )x [0,65 + 0,01x (2+3+1+4+4+5+1+2+3+3+4+1+3+5)]=

PF= (366)x( 1.06)= 387,96 pf

ESCALA DE GRADO DE

INFLUENCIA

No influye 0

Insignificante 1

Moderada 2

Medio 3

Significativa 4

Fuerte 5

Copia de seguridad y recuperación 2

Comunicaciones 3

Proceso distribuido 1

Rendimiento crítico 4

Entorno operativo existente 4

Entrada de datos online 5

Transacciones entrada en varias pant 1

Archivos maestros actualizados online 2

Complejidad valores dominio información 3

Complejidad procesamiento interno 3

Código diseñado para reutilización 4

Conversión en diseño 1

Instalaciones múltiples 3

Aplicación diseñada para cambios 5

55

Calcular el costo estimado del proyecto:

pf

mesper

pf

mesperCostoporPF

$3

1000

$3000

Costo del proyecto = PF * Costo por PF = 387,96 pf * 3 $ / pf

Costo del proyecto = 1163,88 $.

4. Apendice, Métrica de los puntos de función.

56

UTILIDADES DE LOS PUNTOS DE FUNCIÓN.

• Comparar lo que solicitó el cliente con lo que recibió.

• Comparar la productividad de los diferentes entornos de desarrollo.

• Comparar la calidad que se obtiene mediante las diferentes técnicas de desarrollo.

TECNICAS DE ESTIMACION DE COSTOS

JUICIO EXPERTO

• La técnica más utilizada para la estimación de costos es el uso deljuicio experto. El juicio experto se basa en la experiencia, en elconocimiento anterior y en el sentido comercial de uno o masindividuos dentro de la organización.

JUICIO EXPERTO

El experto, por ejemplo, puede hacer una estimación de costos razonando de lasiguiente manera:

- El sistema que se va a desarrollar es muy similar a uno que se desarrolloanteriormente y que costó $ 8,000.00 y tardó 4 meses.

- Se puede reutilizar la base del proyecto anterior.

- Se utilizará el mismo equipo de cómputo y a muchos de los programadores queparticiparon en el proyecto anterior, por lo que la estimación se puede reducir enun 20 %.

JUICIO EXPERTO

- Mucho código y rutinas comunes se podrán reutilizar por lo que el esfuerzo se reduce otro 20%.

- Por lo tanto el nuevo proyecto puede ser un 20% más económico que el anterior.

JUICIO EXPERTO

Ventajas

1. Se obtiene una estimación en corto tiempo.

Desventajas

1. El experto puede confiarse y olvidar algunos factores importantes del Nuevoproyecto, creyendo que es casi igual al anterior.

2. El experto puede no tener familiaridad con el área del proyecto.

• Se desarrollo en la corporación Rand en 1948, con el fin de lograr un acuerdo deun grupo de expertos sin contar con los efectos negativos de las reuniones degrupos. La técnica se lleva a cabo de la siguiente manera:

TECNICA DELFI

TECNICA DELFI

• 1. Un coordinador proporciona a cada experto la documentación con la Definición del Sistema y una papeleta para que escriba su estimación.

• 2. Cada experto estudia la definición y determina su estimación en forma anónima; los expertos pueden consultar al coordinador, pero no entre ellos.

• 3. El coordinador prepara y distribuye un resumen de las estimaciones efectuadas, incluyendo cualquier razonamiento extraño efectuado por alguno de los expertos.

• 4. Los expertos realizan una segunda ronda de estimaciones, otra vez anónimamente, utilizando los resultados de la estimación anterior. En los casos en que una estimación difiera mucho de las demás, se podrá solicitar que también en forma anónima el experto justifique su estimación.

TECNICA DELFI

TECNICA DELFI

• 5. El proceso se repite tantas veces como se juzgue necesario, impidiendo una discusión grupal durante el proceso.

TECNICA ITERATIVA

• Se basa en la entrega evolutiva del software ( por etapas o iteraciones ).

• En cada etapa se construye un pequeño conjunto de funciones del software (miniproyecto ), que implica análisis, diseño, codificación, pruebas,documentación y evaluación del cliente.

• La técnica permite determinar el número de iteraciones y su longitud necesariapara desarrollar el proyecto completo.

NOTA: Las estimaciones son de los desarrolladores, no de los gerentes.

TECNICA ITERATIVA

1.- Estimar el esfuerzo de cada función del software.

Asegurarse de que quien haga la estimación sea el desarrollador que posea el mayor conocimiento de la función dada.

TECNICA ITERATIVA

2.- Determine el número de programadores.

Utilizando los registros de proyectos anteriores, busque una aproximación con elEsfuerzo del proyecto actual y deduzca el número de programadores queconvendría utilizar.

Ejemplo:

• Si en un proyecto anterior de 38 semanas-programador requirió 4programadores, puede ser razonable que el nuevo proyecto requiera de 5.

TECNICA ITERATIVA

3.- Determine el factor de eficiencia de los programadores ( productividad ).

Aunque los desarrolladores sean de tiempo completo, no dedicarán el 100% de lajornada en trabajo productivo.

Investigaciones de cómo usan su tiempo los programadores indican QUE:

Ejemplo: Suponga una productividad del 50% para este ejemplo.

TECNICA ITERATIVA

4.- Determine la longitud de la iteración.

Se busca una longitud de iteración fija para todo el proyecto, de modo que sepueda lograr un ritmo regular de entrega del proyecto. Cada iteración debe ser losuficientemente larga para realizar varias funciones del software.

Puede considerar longitudes de iteración de 2 a 8 semanas.

Ejemplo: Suponer para este ejemplo que se implementará en un lenguajeconocido, por lo que una longitud de iteración de 3 semanas permitiráimplementar de 2 a 4 funciones del software por iteración

TECNICA ITERATIVA

5.- Calcular el esfuerzo por iteración.

Esfuerzo por iteración ( semanas-programador ) = No. Programadores * Long.Iteración * Factor de Productividad

Ejemplo:

• Esfuerzo por iteración = 5 * 3 * 0.5 = 7.5 semanas-programador

TECNICA ITERATIVA

6.- Calcular el número de iteraciones.

No. Iteraciones = ( Esfuerzo Total / Esfuerzo por Iteración ) + 1

Ejemplo:

• No. Iteraciones = ( 50 / 7.5 ) + 1 = 7.6 aprox. 8 iteraciones

7.- Calcular el tiempo de desarrollo.

Teniendo la longitud y el número de iteraciones es fácil determinar el tiempo dedesarrollo

Tdev = Long. Iteración * No. Iteraciones

Ejemplo:

• Tdev = 3 * 8 = 24 semanas = 6 meses.

TECNICA ITERATIVA

8.- Considerar un factor de contingencia.

Agregue un factor del 10% al 20% del tiempo de construcción, dependiendo de loarriesgada que parezca la situación.

• Ejemplo:

• Considerando el factor 40-20-40, es decir, el 40% de esfuerzo es Analisis-Diseño,20% Codificación y 40% Pruebas, calculamos que el tiempo posible deconstrucción ( codificación ) es el 20% de las 24 semanas totales.

• Tcodif = 0.2 * 24 = 4.8 aprox. 5 semanas

TECNICA ITERATIVA

Suponiendo que nuestro factor de contingencia es del 15% entonces el tiempo decontingencia será

• Tconting = 0.15 * 5 = 0.75 semanas o aprox. 4 dias.

Por lo tanto el plan debe ser formulado para desarrollar el producto en 24semanas, pero el compromiso de entrega final sería para 24.75 semanas, 4 díasmás.

TECNICA ITERATIVA

estimación

Documents