Estimacion de Proyectos de Software (VIDEO)

ESTIMACIÓN DE PROYECTOS DE SOFTWARE

Descripción e Importancia

Gestor del proyecto

Equipo de software

recursos necesarios y del tiempo que tomará el proyecto.

¿Por qué estimar el costo un proyecto de software?

¿Podrías construir una casa sin saber cuanto estarías dispuesto a gastar?

Es algo lógico y obviamente la respuesta seria NO, así es la estimación sirve para determinar cuánto dinero, esfuerzo, recursos, y tiempo supondrá construir un sistema o producto específico de software

¿Cuáles son los pasos?

La estimación comienza con una descripción del ámbito del producto que es tener clara la idea o el objetivo del proyecto utilizando la información solicitada a los clientes, a los ingenieros de software y es recomendable utilizar como guía un proyecto anterior sólido

1. Observaciones sobre la estimación2. Objetivos de la planificación del proyecto3. Ámbito del software (breve descripción)4. Recursos5. Estimación del proyecto de software6. Técnicas de descomposición

- Tamaño del software- Estimación basada en el problema- Un ejemplo de estimación basada en LDC- Un ejemplo de estimación basada en PF- Estimación basada en el proceso

7. Modelos empíricos de estimaciónLa estructura de los modelos de estimaciónEl modelo COCOMOLa ecuación del software

8. La decisión de desarrollar-comprar9. Herramientas automáticas de estimación10.Conclusiones

PLANIFICACIÓN DE PROYECTOS DE SOFTWARE Jaime Vilca, Jose Silva, Jordy Piedra

PLANIFICACIÓN DE PROYECTOS DE SOFTWARE

1. Observaciones sobre la estimación

La estimación requiere EXPERIENCIA, acceder a una buena información histórica y utilizar

la INGENIERÍA, saber qué es lo que va a ir mal antes de que ocurra.

La estimación de costo implicara siempre un riesgo , tanto la complejidad del proyecto, el tamaño del

proyecto y el grado de incertidumbre afectan la fiabilidad de la estimación

Jaime Vilca, Jose Silva, Jordy Piedra


2. Objetivos de la planificación del proyecto

Generar un marco de trabajo que permita hacer estimaciones razonables de recursos, definir escenarios del “Mejor caso” y “Peor caso”.



2. Objetivos de la planificación del proyecto

El objetivo de la planificación se logra mediante un proceso de descubrimiento de la información que lleve a estimaciones razonables.

Estas estimaciones se hacen dentro de un marco de tiempo limitado al comienzo deun proyecto de software, y deberían actualizarse regularmente a medida que progresa el proyecto.

Cuanto más sepa, mejor realizará la estimación. Por consiguiente, actualizar sus estimaciones a medida que progresa el proyecto.

CONSEJO



3. Ámbito del software (breve descripción)

Establecer un ámbito de proyecto que no sea ambiguo, ni incomprensible paradirectivos y técnicos.

Se debe delimitar la declaración del ámbito del software.

El ámbito del software describe el control y los datos a procesar, la función, el rendimiento, las restricciones, las interfaces y la fiabilidad.




Obtención de la información necesaria para el ámbito

Al principio de un proyecto de software las cosas siempre están un poco borrosas.




La técnica utilizada con más frecuencia para acercar al cliente y al desarrollador, y para hacer que comience el proceso de comunicación es establecer una reunión o una entrevista preliminar.

La primera reunión entre un ingeniero de software (el analista) y el cliente puede compararse a la primera cita entre adolescentes.

Ninguna persona sabe lo que decir o preguntar; ambos están preocupados por si lo que dicen es mal interpretado.




Sin embargo, se debe iniciar la comunicación. Gause y Weinberg sugieren que el analista comiencehaciendo preguntas de contexto libre.


Es decir, una serie de preguntas que lleven a un entendimiento básico del problema.

¿Quién está detrás de la solicitud de este trabajo?¿Quién utilizará la solución?¿Cuál será el beneficio económico de una buena solución?¿Hay otro camino para la solución?….




Viabilidad

Una vez se ha identificado el ámbito (con la ayuda del cliente)

¿Podemos construir el software de acuerdo a este ámbito? ¿Es factible el proyecto?

El estudio de viabilidad es importante, pero las necesidades de la gestión son inclusa más importantes. NO es bueno construir un producto o sistema de alta tecnología que en realidad nadie quiera.


CONSEJO



Cada recurso queda

especificado mediante

cuatro característica

s

Descripción del recurso

Informe de disponibilidad

Fecha cronológica en la que se requiere

el recurso

Tiempo durante el que será

aplicado el recurso.

4. Recursos



PERSONAS

COMPONENTES DE SOFTWARE REUTILIZABLES

Herramientas hardware/ software

Componentes ya desarrollados (CCYD)

COMPONENTE YA EXPERIMENTADOS

COMPONENTES CON EXPERIENCIA PARCIAL

COMPONENTES NUEVOS

4. Recursos



5. Estimación del Proyecto de Software

El software es uno de los elementos más costosos de los sistemas informáticos.

Un error en la estimación puede marcar la diferencia entre beneficios y perdidas

Estimación Costo - Esfuerzo

Humanas

Políticas

Técnicas

De Entorno



- No dejar la estimación para más adelante - Proyectos similares ya terminados

- Técnicas de descomposición- Modelos empíricos para la estimación del coste y esfuerzo

Divide y vencerás. d=f (Vi)

Valores estimados: Esfuerzo, coste, duración del proyecto

Parámetros determinados: LDC o PF estimados

Donde f:

Donde Vi:

5. Estimación del Proyecto de Software


TÉCNICAS DE DESCOMPOSICIÓN

La estimación de proyectos de software es una forma de resolución de

problemas y, en la mayoría de los casos, el problema a resolver (es decir,

desarrollar estimaciones de coste y de esfuerzo para un proyecto de software) es demasiado complejo para considerarlo como un todo. Por esta razón, descomponemos el problema, volviéndolo a definir como un conjunto de pequeños problemas.

Descomposición del problema. Descomposición del proceso.


6. Técnicas de descomposición


La estimación hace uso de una o ambas formas de particionamiento.

Pero antes de hacer una estimación, el planificador del proyecto debe comprender

el ámbito del software a construir y generar una estimación de su

«tamaño».


6. Técnicas de descomposición


Tamaño del software

La precisión de una estimación del proyecto de software se predice basándose en una serie de cosas:

1. EL grado en el que el planificador ha estimado adecuadamente el tamaño del producto a construir.

2. La habilidad para traducir la estimación del tamaño en esfuerzo humano, tiempo y dinero (una función de La disponibilidad de métricas fiables de software de proyectos anteriores).

3. El grado en el que el plan del proyecto refleja las habilidades del equipo de software.

4. La estabilidad de los requisitos del software y el entorno que soporta el esfuerzo de la ingeniería del software.


6. Técnicas de descomposición (Tamaño del software)


El <<tamaño>> del software se puede estimar utilizando:

Medida Directa LDC(Líneas de código)

Medida Indirecta PF (Puntos de función)




Putnam y Myers sugieren cuatro enfoques diferentes del problema del tamaño:

• Tamaño en «lógica difusa»• Tamaño en punto de función• Tamaño de componentes estándar

• Tamaño del cambio




Putnam y Myers sugieren que los resultados de cada uno de los métodos de tamaño señalados anteriormente se combinan estadísticamente para crear una estimación de tres puntos o del Valor Esperado (VE).




Esto se lleva a cabo desarrollando valores de tamaño:

Optimistas (alto) Más probables Pesimistas (bajo)

𝑉𝐸=𝑆𝑜𝑝𝑡+4𝑆𝑚+𝑆𝑝𝑒𝑠𝑠

6Ecuación



Sopt =valor optimistaSm = valor probableSpess= valor pesimista

Donde:


Para estimaciones de LDC, la descomposición se centra

en las funciones del software.

Para estimaciones de PF, la descomposición se centra

en las características del dominio de información.

Una vez que se ha determinado el valor esperado de la variable de estimación (mediante la ecuación) , se

aplican datos históricos de productividad de LDC y PF.




¿Son correctas las estimaciones?La única respuesta razonable a esto es: «No podemos estar seguros».

Se debe volver a comprobar con otro enfoque

Va a prevalecer el sentido común y la

experiencia




Un ejemplo de estimación basada en LDC

Un paquete de software a desarrollarse para una aplicación de diseño asistido por computadora (computer-aided design, CAD) de componentes mecánicos.

Una revisión de la especificación del sistema indica que el software

va a ejecutarse en una estación de trabajo de ingeniería y que debe

interconectarse con varios periféricos de gráficos de computadora entre los que se incluyen un ratón, un digitalizador, una pantalla a color de alta

resolución y una impresora láser.

…


6. Técnicas de descomposición (Ejemplo de estimación basada en LDC )


Se desarrolla un rango de estimaciones de LDC para cada función.

Por ejemplo, el rango de estimaciones de LDC de la función Análisis geométrico de tres dimensiones es:

Optimista 4.600 LDCMás probable 6.900 LDCPesimista 8.600 LDC

Aplicando la Ecuación Remplazando valores

el valor esperado de la función Análisis geométrico de tres dimensiones es 6.800 LDC





Tabla de estimación para el método de LDC.





Se establece una estimación de 33.200 líneas de código para el sistema de CAD.

Una revisión de datos históricos indica que la productividad media de la organización para

sistemas de este tipo es de 620 LDC/pm. Según una tarifa laboral de €8.000 ($10.962) por mes, el coste por línea de código es aproximadamente de €13,00 ($17,81). Según la estimación de LDC y los datos de productividad históricos, el coste total estimado del

proyecto es de €431.000 ($590.556) y el esfuerzo estimado es de 54 personas-mes.

CONSEJO: Debería obtener otra estimación utilizando un método diferente




Donde: LDC/pm = Líneas de código por mes

Para obtener el costo total del proyecto, se multiplica el valor de la línea de código establecido en $17,81 y el numero total de líneas de código del sistema y obtenemos el valor resultante de $591.556 en un proyecto donde intervinieron 54 personas.


• Miden el software cualificando la funcionalidad que proporciona

externamente, basándose en el diseño lógico del sistema.

• En el caso de subsistemas diseñados independientemente los Puntos

de Función se calcularán para cada una de ellas, y luego se sumarán.

6. Técnicas de descomposición (Estimación basada en PF )


PUNTOS DE FUNCIÓN


OBJETIVO DE LOS PF

• Medir lo que el usuario pide y lo que el usuario recibe.

• Medir independientemente de la tecnología utilizada en la implantación del sistema.

• Proporcionar una métrica de tamaño que dé soporte al análisis de la calidad y la

productividad.

• Proporcionar un medio para la estimación del software.

• Proporcionar un factor de normalización para la comparación de distintos software.



Se centra en los valores de dominio de información, y NO en las funciones del software.

Teniendo en cuenta la tabla de cálculos de punto de función.

Estimación de los valores del dominio de información.

𝑃𝐹𝑒𝑠𝑡𝑖𝑚𝑎𝑑𝑜=𝑐𝑢𝑒𝑛𝑡𝑎𝑡𝑜𝑡𝑎𝑙 𝑥 [ 0,65+0,01 𝑥∑ (𝐹𝑖 ) ]En donde cuenta total es la suma de todas las entradas PF obtenidas.



En donde es la sumatoria de los factores de ponderación de complejidad

Fórmula para calcular puntos de función estimados


Cálculo de puntos de función




Se estima cada uno de los factores de ponderación de la complejidad, y se calcula el factor de ajuste de la complejidad.

55

Un ejemplo de estimación basada en PF


6. Técnicas de descomposición (Ejemplo de estimación basada en PF )


Fi (i = 1 a 14) son «valores de ajuste de la complejidad» según las respuestas a las siguientes preguntas 1. ¿Requiere el sistema copias de seguridad y de recuperación fiables?2. ¿Se requiere comunicación de datos?3. ¿Existen funciones de procesamiento distribuido?4. ¿Es crítico el rendimiento?5. ¿Se ejecutará el sistema en un entorno operativo existente y fuertemente utilizado?6. ¿Requiere el sistema entrada de datos interactiva?7. ¿Requiere la entrada de datos interactiva que las transacciones de entrada se lleven a cabo sobre múltiples pantallas u

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 para ser fácilmente utilizada por el usuario?

𝑃𝐹𝑒𝑠𝑡𝑖𝑚𝑎𝑑𝑜=𝑐𝑢𝑒𝑛𝑡𝑎𝑡𝑜𝑡𝑎𝑙 𝑥 [ 0,65+0,01 𝑥∑ (𝐹𝑖 ) ]




Cada una de las preguntas anteriores es respondida usando una escala con rangos desde 0 (no

importante o aplicable) hasta 5 (absolutamente esencial).

Los valores constantes de la ecuación y los factores de peso que se aplican a las cuentas de los

dominios de información se determinan empíricamente. Una vez que se han calculado los puntos de función, se utilizan de forma análoga a las LDC como

forma de normalizar las medidas de productividad, calidad y otros atributos del software.




Finalmente, se obtiene el número estimado de PF:

𝑃𝐹𝑒𝑠𝑡𝑖𝑚𝑎𝑑𝑜=𝑐𝑢𝑒𝑛𝑡𝑎𝑡𝑜𝑡𝑎𝑙 𝑥 [ 0,65+0,01 𝑥∑ (𝐹𝑖 ) ]𝑃𝐹𝑒𝑠𝑡𝑖𝑚𝑎𝑑𝑜=375

La productividad media organizacional para sistemas de este tipo es de 6,5 PF/pm. Según la tarifa laboral

de €8.000 ($ 10.962) por mes, el coste por PF es aproximadamente de €1.230 ($ 1685). Según la

estimación de LDC y los datos de productividad históricos, el coste total estimado del proyecto es de

€461.000 ($ 631.662), y el esfuerzo estimado es de 58 personas/mes.

Un ejemplo de estimación basada en PF


En donde: PF/pm = Puntos de función por mes.



Estimación basada en el proceso La técnica más común para estimar un proyecto es basar la estimación en el proceso que se va a utilizar. Es decir, el proceso se descompone en un conjunto relativamente pequeño de actividades o tareas, y en el

esfuerzo requerido para llevar a cabo la estimación de cada tarea.


6. Técnicas de descomposición (Estimación basada en el proceso)


MODELOS EMPIRICOS DE ESTIMACIÓN

• Un modelo de estimación de software utiliza formulas derivadas empíricamente

para predecir el esfuerzo con una función de LDC o PF.

• No todo modelo de estimación es adecuado para cierta clase de software.

7. Modelos empíricos de estimación

Empírico: Que es un resultado inmediato de la experiencia, que solo se funda en la observación de los hechos.


ESTRUCTURA DE LOS MODELOS DE ESTIMACIÓN

• La estructura global de tales modelos adquiere la forma de:

• Donde A, B y C son constantes obtenidas empíricamente, E es el esfuerzo en

personas-mes, y ev es la variable de estimación (de LDC o PF).




• Modelo de Walston-Felix

• Modelo de Bailey-Basili

• Modelo simple de Boehm

• Modelo Doty para KLDC > 9

• Modelo de Albretch y Gaffney

MODELOS


KLDC = El valor de Kilo-líneas de código


MÉTODO COCOMO

• Este modelo se aplica a los desarrollos que siguen el ciclo de vida en cascada (en nueve etapas), y corresponde a las siguientes fases:

Ingeniería y Análisis del Sistema

Análisis de los Requisitos

Diseño

Codificación

Prueba

Mantenimiento



Incorpora dentro del proceso:

•Verificación y Validación.

•Gestión de Configuración.

MÉTODO COCOMO




Modelos que define COCOMO:


Modelo básico: Se basa exclusivamente en el tamaño expresado en LDC.

Modelo intermedio: Además del tamaño del programa incluye un conjunto de medidas subjetivas llamadas conductores de costes.

Modelo avanzado: Incluye todo lo del modelo intermedio además del impacto de cada conductor de coste en las distintas fases de desarrollo.


• Orgánico: proyectos relativamente sencillos, menores de 50 KDLC líneas de código, en los cuales se tiene experiencia de proyectos similares y se encuentran en entornos estables.

• Semi-acoplado: proyectos intermedios en complejidad y tamaño (menores de 300 KDLC), donde la experiencia en este tipo de proyectos es variable, y las restricciones intermedias.

• Empotrado: proyectos bastante complejos, en los que apenas se tiene experiencia y se engloban en un entorno de gran innovación técnica. Además se trabaja con unos requisitos muy restrictivos y de gran volatilidad.

Tipos de Proyectos del MÉTODO COCOMO



PROYECTO SOFTWARE a e c d

Orgánico 3,2 1,05 2,5 0,38

Semi-acoplado 3,0 1,12 2,5 0,35

Empotrado 2,8 1,20 2,5 0,32




EJEMPLO MÉTODO COCOMO (usando el modelo intermedio)

Formulas:E = Esfuerzo = a KLDC e * FAE (persona x mes)T = Tiempo de duración del desarrollo = c Esfuerzo d (meses)P= Personal = E/T (personas)Donde : KLDC= Kilo-líneas de códigoFAE = Multiplicación de los 15 conductores de coste.a,e,c,d = Constantes del tipo de proyecto.


Para calcular el Esfuerzo, necesitaremos hallar la variable KDLC (Kilo-líneas de código), donde los PF son 261,36 (dato conocido) y las líneas por cada PF equivalen a 32 según vemos en la tabla que se ilustra a continuación:

E = Esfuerzo = a KLDC e * FAE (persona x mes)




Así pues tras saber que son 32 LDC por cada PF, por el hecho de ser Visual Basic el resultado de los KDLC será el siguiente:KLDC= (PF * Líneas de código por cada PF)/1000 = (261,36*32)/1000= 8,363 KDLC



E = Esfuerzo = a KLDC e * FAE (persona x mes)LENGUAJE LDC/PF

Ensamblador 320

C 150

COBOL 105

Pascal 91

Prolog/LISP 64

C++ 64

Visual Basic 32

SQL 12




E = Esfuerzo = a 8,363 e * FAE (persona x mes)Así pues, en nuestro caso el tipo orgánico será el más apropiado ya que el número de líneas de código no supera los 50 KLDC, y además el proyecto no es muy complejo, por consiguiente, los coeficientes que usaremos serán las siguientes:


Orgánico 3,2 1,05 2,5 0,38

Semi-acoplado 3,0 1,12 2,5 0,35

Empotrado 2,8 1,20 2,5 0,32




E = Esfuerzo = 3,2 (8,363)1,05 * FAE (persona x mes)Y por otro lado también hemos de hallar la variable FAE, la cual se obtiene mediante la multiplicación de los valores evaluados en los diferentes 15 conductores de coste que se observan en la siguiente tabla:

CONDUCTORES DE COSTE

VALORACIÓN

Muy bajo

Bajo Nominal Alto Muyalto

Extr. alto

Fiabilidad requerida del software 0,75 0,88 1.00 1,15 1,40 -Tamaño de la base de datos - 0,94 1.00 1,08 1,16 -Complejidad del producto 0,70 0,85 1.00 1,15 1,30 1,65Restricciones del tiempo de ejecución - - 1.00 1,11 1,30 1,66Restricciones del almacenamiento principal - - 1.00 1,06 1,21 1,56Volatilidad de la máquina virtual - 0,87 1.00 1,15 1,30 -Tiempo de respuesta del ordenador - 0,87 1.00 1,07 1,15 -Capacidad del analista 1,46 1,19 1.00 0,86 0,71 -Experiencia en la aplicación 1,29 1,13 1.00 0,91 0,82 -Capacidad de los programadores 1,42 1,17 1.00 0,86 0,70 -Experiencia en S.O. utilizado 1,21 1,10 1.00 0,90 - -Experiencia en el lenguaje de programación 1,14 1,07 1.00 0,95 - -

Prácticas de programación modernas 1,24 1,10 1.00 0,91 0,82 -Utilización de herramientas software 1,24 1,10 1.00 0,91 0,83 -Limitaciones de planificación del proyecto 1,23 1,08 1.00 1,04 1,10 -

FAE=1,15*1,00*0,85*1,11*1,00*1,00*1,07*0,86*0,82*0,70*1,00*0,95*1,00*0,91*1,08 = 0,53508480




Obtenemos como resultado:

E = a KLDC e * FAE

Cálculo del esfuerzo del desarrollo:

E = 15,91 personas /mes

E = Esfuerzo = 3,2 (8,363)1,05 * 0,53508480 (persona x mes)




E = a KLDC e * FAE E = 15,91 personas /mes Cálculo tiempo de desarrollo (T): T = c Esfuerzo d = 2,5 * (15,91)^0,38 = 7,15 meses

Productividad (PR):

PR = LDC/Esfuerzo = 8363/15,91 = 525 ,64 LDC/personas mes

Personal promedio (P):

P = E/T = 15,91/7,15 = 2,22 personas


Orgánico 3,2 1,05 2,5 0,38

KLDC = 8,363 LDC = 8,363*1000 = 8363FAE = 0,53508480E= Esfuerzo




CONCLUSIÓN (aplicando el modelo COCOMO)

Según estas cifras será necesario un equipo de 3 personas trabajando alrededor de 7 meses, pero puesto que el desarrollo del proyecto debe realizarse en un plazo 3 meses, incrementaremos a 6 personas el número de personas del equipo de proyecto (ya que 15,91(Esfuerzo)/3(meses) nos da alrededor de 6 personas.)

Así pues tendremos un equipo formado por :1 Jefe de proyecto, 2 Analistas, 2 programadores y 1 Responsable de calidad.

La estimación de costo en dólares es de acuerdo al salario mensual de cada miembro del equipo.


• Distribuye el esfuerzo a lo largo de la vida de un proyecto de desarrollo de software.

Dónde:

• E = esfuerzo en personas-mes o personas-año,

• t = duración del proyecto en meses o años,

• B = «factor especial de destrezas»

• P = «parámetro de productividad»

LA ECUACIÓN DEL SOFTWARE



• Los valores típicos para el desarrollo del software empotrado en tiempo real podrían ser :

P = 2.000; P = 10.000 para telecomunicaciones y software de sistemas; y P = 28.000 para aplicaciones comerciales de sistemas.

LA ECUACIÓN DEL SOFTWARE



• P = 12.000 (valor recomendado para software científico) • = 12.6 meses• = 58 personas-Mes

EJEMPLO ECUACIÓN DEL SOFTWARE



Putnam y Myers sugieren un conjunto de ecuaciones obtenidas de la ecuación del software.

Un tiempo mínimo de desarrollo se define como:

> 6 meses

E>= 20 p/m


La decisión de desarrollar-comprar


8. Desarrollar - Comprar


En muchas áreas de aplicación del software, a menudo es más rentable adquirir el software de computadora que desarrollarlo.

Los gestores de ingeniería del software se enfrentan con una decisión desarrollar o comprar que se

puede complicar aún más con las opciones de adquisición:

1. El software se puede comprar (con licencia) ya desarrollado2. Se pueden adquirir componentes de software «totalmente experimentado» o «parcialmente

experimentado» y entonces modificarse e integrarse para cumplir las necesidades específicas3. El software puede ser construido de forma personalizada por una empresa externa para cumplir las

especificaciones del comprador.




Árbol de decisión para apoyar la decisión desarrollar-comprar.PLANIFICACIÓN DE PROYECTOS DE SOFTWARE



HERRAMIENTAS AUTOMATICAS DE ESTIMACIÓN

• Las técnicas de descomposición y los modelos empíricos se pueden implementar en

software.

• Existen muchas herramientas automáticas de estimación, todas exhiben las mismas

características generales y todas realizan las seis funciones genéricas.


9. Herramientas automáticas de estimación


DIMENSIONAMIENTO DE LAS ENTREGAS DEL PROYECTO

• Se estima el «tamaño» de uno o más productos de software. • Los productos incluyen:

• La representación externa del software• Su funcionalidad (Puntos de función)• La información descriptiva (por ejemplo, documentos).




SELECCIÓN DE LAS ACTIVIDADES DEL PROYECTO

Se selecciona el marco de trabajo del proceso adecuado y se especifica el conjunto de

tareas de ingeniería del software.

PREDICCIÓN DE LOS NIVELES DE LA PLANTILLA

• Se especifica el número de personas disponibles para realizar el trabajo.

• Esto es muy importante, puesto que la relación entre las personas disponibles y el

trabajo (esfuerzo previsto) no es muy lineal.




PREDICCIÓN DEL ESFUERZO DEL SOFTWARE

Las herramientas de estimación utilizan uno o más modelos que relacionan el

tamaño de las entregas del proyecto con el esfuerzo necesario para producirlas.

PREDICCIÓN DEL COSTE DEL SOFTWARE

Dado los resultados del paso 4, los costes pueden calcularse asignando proporciones

del trabajo a las actividades del proyecto señaladas en el paso 2.




PREDICCIÓN DE PLANIFICACIÓN DEL SOFTWARE

• Cuando se conoce el esfuerzo, los niveles de la plantilla y las actividades del proyecto,

se puede realizar un borrador de la planificación asignando el trabajo a través de

actividades de ingeniería del software basadas en modelos recomendados para la

distribución del esfuerzo.

• Herramientas Case(Ingeniería de Software Asistida por Computadora).




• Cuando se aplican distintas herramientas de estimación a los mismos datos del

proyecto, se observa una variación relativamente grande entre los resultados

estimados.

• Esto refuerza la idea de que los resultados obtenidos por las herramientas de

estimación se deben usar sólo como «punto de partida» para la obtención de

estimaciones

HERRAMIENTAS AUTOMATICAS DE ESTIMACIÓN




• La estimación del proyecto de software debe considerar cuatro aspectos antes del inicio el proyecto:

• El tiempo de duración

• El esfuerzo

• El costo

• El personal implicado en el desarrollo

• Los modelos o técnicas a pesar de su perfeccionamiento para estimar el esfuerzo y el costo de acuerdo

al tiempo no modelan de manera exacta la estimación.

10. Conclusiones


• Es necesario comparar con otros modelos y proyectos anteriores que sirvan de guía

para no cometer errores en la estimación de nuestro proyecto para no tener

complicaciones a futuro.

• COCOMO es una herramienta basada en la líneas de código la cual le hace muy

poderoso para la estimación de costos y no como otros que solamente miden el

esfuerzo en base al tamaño.


10. Conclusiones


REFERENCIAS

• [BEN92] Bennatan, E. M., Software Project Management: APractitioner's

Approach, McGraw-Hill, 1992.

• [BOE96] Boehm, B., «Anchoring the Software Process», IEESoftware, vol. 13, n.Q

4, Julio 1996, pp. 73-82.

• [PUT97b] Putnam, L., y W. Myers, Industrial Strength Software:

• Effective Management Using Measurement, IEEEComputer Society Press, 1997.

• Ingernieria de software, un enfoque practico. Roger S. Pressman

Estimacion de Proyectos de Software (VIDEO)

Documents

Transcript of Estimacion de Proyectos de Software (VIDEO)