ESTIMACIÓN DE PROYECTOS

TRABAJO INVESTIGATIVO 04

ESTIMACIÓN DE PROYECTOS

PRESENTADO POR: DAMIAN SAMAEL TOVAR 20132578120 SEBASTIÁN GAMBOA BAUTISTA 20131078091 FREDY ENRIQUE GALINDO OSMA 20132578018 JULIAN DAVID MÁRQUEZ FUENTES 20122078213

PRESENTADO A: Juan Carlos Guevara Bolaños

UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS

FACULTAD TECNOLOGICA TECNOLOGIA EN SISTEMATIZACION DE DATOS 2016

Tabla de contenido

Introducción ........................................................................................................................................ 4

Estimación de software ....................................................................................................................... 5

Definición ........................................................................................................................................ 5

Importancia de la estimación .......................................................................................................... 5

Características ................................................................................................................................. 5

Factores críticos de éxito................................................................................................................. 6

Métodos de estimación ....................................................................................................................... 6

El modelo SLIM (software, life cycle management) ........................................................................ 6

Funcionamiento .............................................................................................................................. 6

Ejemplo de aplicación ..................................................................................................................... 8

Estimación del tamaño del software ................................................................................................... 9

Técnica LDC (DATOS DE LINEAS DE CÓDIGO) .................................................................................. 9

Funcionamiento ............................................................................................................................ 10

Ejemplo de aplicación ................................................................................................................... 12

Estimación del esfuerzo .................................................................................................................... 13

Wideband Delphi ........................................................................................................................... 13

Funcionamiento ............................................................................................................................ 14


Estimación del tiempo ....................................................................................................................... 16

Método PERT (Program Evaluation and Review Technique) ........................................................ 17

Funcionamiento ............................................................................................................................ 17


Estimación del costo.......................................................................................................................... 20

COCOMO ....................................................................................................................................... 20

Funcionamiento ............................................................................................................................ 21


Software de estimación 01 ................................................................................................................ 27

Bailey-Basili ................................................................................................................................... 27

Funcionalidades ............................................................................................................................. 28

Ejemplo .......................................................................................................................................... 29


Expert Estimateur .......................................................................................................................... 30

Requerimientos tecnológicos ........................................................................................................ 31




SLIM-Metrics ................................................................................................................................. 33





COCOMO II .................................................................................................................................... 35




Conclusiones...................................................................................................................................... 38

Bibliografía ........................................................................................................................................ 38

Introducción

Durante muchos años el proceso de desarrollo de software ha sido considerado como un arte dejado a

la improvisación del jefe del proyecto. Los proyectos se dirigían más bajo consideraciones técnicas, que

de gestión. Las actividades de estimación y de planificación quedaban relegadas a un mero acto

protocolario al comienzo del proyecto. Posteriormente, el seguimiento y control se realizaban sin un

mínimo de rigor, dada la baja calidad de la estimación y la planificación realizada. Mientras los

proyectos han sido de complejidad media la euforia de la tecnología ha dominado el mercado. 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 cuándo se terminará el sistema ni cuánto costará.

Actualmente se utilizan unas actividades de desarrollo del proyecto de software con el fin de

comprender y obtener una excelente calidad y tener un enfoque claro para esto se tiene en

cuenta la medición y métricas, estimación, análisis de riesgo, planificación del programa,

seguimiento y control. El recopilar datos, calcular métricas y evaluar métricas, son algunos de los

pasos que se deben realizarse al comenzar un producto.

Es cada vez más frecuente la consideración de métricas de software, es por eso que sé están

implantando en la actualidad, llevando consigo puntos débiles y fuertes que están experimentado

los ingenieros y administradores de software. El uso de éstas se ha adoptado con éxito en el

amplio mercado de desarrollo de software introduciendo reconocimientos y consideraciones por

parte de administradores y usuarios, y estableciendo la necesidad de un enfoque más disciplinado

y de una alta calidad. Así muchos particulares y compañías desarrolladoras de software, están

reconociendo la importancia del uso de las métricas, aunque de igual modo siguen sin conocer el

alcance de madurez y calidad del producto final y la disciplina de ingeniería madura que llega a

alcanzar con la aplicación de los distintos métodos y técnicas y la interpretación de los resultados

que proyecta el uso de las métricas.

Estas métricas se basan en técnicas que son aplicadas a procesos, productos y servicios; según su criterio se pueden clasificar en:

Métricas De Procesos Métricas De Proyecto Métricas De Producto Métricas De Calidad

cada una con criterios de avaluación similares, que buscan la optimización del Software.

Estimación de software

Definición Hacer una buena estimación software antes de ofertar un proyecto nos puede ayudar a detectar

proyectos que no conviene abordar y que no son rentables. Aunque la realidad diga que

normalmente negocio, o la parte comercial, fija inamoviblemente, y sin estimación previa, el

tiempo del proyecto, esto no debería evitar las estimaciones, ya que estas nos ayudarán entonces

a saber de qué tamaño es el problema en que nos hemos metido. Mejor saber al principio que es

imposible hacer el proyecto en el tiempo ofertado que al final del plazo, cuando ya hay muy poco

margen de maniobra.

Las técnicas de estimación son importantes porque proporcionan la parte esencial de una buena gestión de proyectos. Sin una aceptable capacidad de estimación de software, los proyectos pueden sufrir los siguientes problemas:

Los programadores no tienen una base firme sobre la que apoyarse para afirmar a su manager, cliente o vendedor, que el presupuesto y el tiempo que le han sido otorgados para finalizar el producto son poco realistas.

Los analistas de software no tienen forma de realizar un análisis fiable de intercambio de

piezas hardware-software durante la fase de diseño del sistema. Esto puede provocar un diseño en el que el coste del hardware queda por debajo de lo esperado a costa de un software que ha costado mucho más de lo estimado.

Los gestores del proyecto no saben cómo estimar el tiempo y el esfuerzo que conlleva

cada fase y actividad durante el desarrollo de un determinado proyecto

Importancia de la estimación

La estimación es 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 sin dejar de tener en cuenta que la incertidumbre y el riesgo son elementos inherentes.

La estimación es importante no solo para predecir el valor de variables concretas dentro de un

proyecto sino para determinar su viabilidad, no tiene sentido iniciar un proyecto que está

destinado al fracaso por no contar con el tiempo, el esfuerzo o los recursos necesarios para

llevarlo a cabo. En la actualidad son muchos los proyectos que fracasan, e incumplen sus plazos de

entrega. En la figura I se muestra un gráfico con el éxito de proyectos de software por año según el

Standish Group, aunque el gráfico revele información hasta el año 2004 la realidad no es muy

diferente en la actualidad.

Características 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 d software, tiempo, esfuerzo, cantidad d defectos esperados, entre otros.

Es razonable conocer cuánto se va a invertir, que taras se deben realizar y el tiempo que se necesitara para ejecutarlas.

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 d un único modelo coherente que pueda

capturar y utilizar la información sobre el proyecto a medida que este se conozca.

El proceso de estimación comienza usando unas pocas variables para proveer las características generales de un proyecto, y evoluciona incorporando información de más bajo nivel para producir las características más específicas.

Factores críticos de éxito Los 10 mandamientos de la gestión de los proyectos informáticos:

Están claramente establecidos el valor y los beneficios de negocio (aumento de ingresos, reducción de costos, etc.) que se obtienen al realizarlo.

Se establecen claramente los objetivos, resultados y productos que hay que obtener. Se establecen claramente el alcance y las limitaciones del trabajo.

Se realizan, controlan y actualizan planes detallados, en los cuales los hitos y actividades

aparecen bien especificados en el tiempo.

Se asegura constantemente el apoyo de la dirección, en términos de autoridad, consistencia de los objetivos y provisión de recursos.

Se escuchan e interpretan las expectativas de todos los usuarios y partes involucradas y se

planifican y gestionan adecuadamente. Se asegura la aceptación del trabajo por parte de los usuarios y otras partes interesadas.

Se asignan los recursos adecuados, con las habilidades necesarias, tanto técnicas como de

gestión de proyectos, así como otras habilidades funcionales que se requieran en cada caso. Se especifican los roles y responsabilidades de todos los miembros.

Se monitoriza, evalúa y se obtiene retroalimentación puntual a lo largo de toda la

ejecución del proyecto. Existen tecnologías maduras y personal formado y disponible para dar el servicio. Se identifican a tiempo y se gestionan las incidencias, crisis y desviaciones.

Métodos de estimación

El modelo SLIM (software, life cycle management)

El Modelo SLIM, abreviación del inglés Software LIfecycle Management, también conocido como modelo Putnam es una técnica de estimación de costes para proyectos de software, desarrollada por Lawrence H. Putnam en 1978. Fue una técnica pionera y ha sido, junto con COCOMO, la que

más repercusión ha tenido en el mundo de la ingeniería del software. Está basado en la curva de Rayleigh, que describe la necesidad de personal al desarrollar proyectos complejos.

Funcionamiento Fue desarrollada para estimar los costes de los grandes proyectos de software. En proyectos pequeños haría falta ajustar la ecuación. La ecuación básica es:

donde T es el tamaño en LDC, C es un factor que depende del entorno (vale 2.000 para entornos

poco productivos, 8.000 para entornos buenos, 11.000 para entornos excelentes), K es el esfuerzo

en personas-año, y t_d es el tiempo para completar el proyecto, medido en años. Para utilizar la

ecuación, es necesaria una estimación del tamaño en LDC, fijar C y dejar K y t_d constantes para

calcular una de las dos. Despejando K se aprecia que el esfuerzo es proporcional a la cuarta

potencia del tiempo necesario para la entrega. Así, si queremos entregar el trabajo en la mitad de

tiempo, el esfuerzo necesario en personas-año se multiplicará por 16.

El modelo SLIM se expresa en dos ecuaciones que describen la relación entre el esfuerzo de desarrollo y el calendario.

La primera ecuación, llamada ecuación de software, afirma que el esfuerzo de desarrollo es proporcional al cubo del tamaño e inversamente proporcional a la cuarta potencia del tiempo de desarrollo.

La segunda ecuación, la ecuación-la acumulación de mano de obra, declara que el esfuerzo es proporcional al cubo del tiempo de desarrollo.

Dónde:

Tamaño: Es el tamaño del producto. Putnam usa líneas de código para la medición del tamaño, sin embargo, se puede usar la métrica más adecuada para medirlo en la organización.

El término β es un escalar (factor especial de destrezas) y está en función del tamaño. Este incrementa a medida que crecen la necesidad de integración, pruebas, garantía de calidad, documentación y habilidad de administración”. Para programas pequeños

(KLDC= 5 a 15), B = 0.16. Para programas mayores de 70 KLDC, B = 0.39.

Productividad: es la productividad del proceso en una organización de desarrollo en particular a una tasa de defectos generados específica. Esfuerzo es el total de esfuerzo aplicado al proyecto, en años/hombre. Tiempo es el calendario total de implementación, dado en años.

En términos prácticos, para estimar una tarea de software la ecuación se resuelve de la siguiente forma:

Este método de estimación es bastante sensible y ajustable a la incertidumbre relacionada con el tamaño y la productividad del proceso. Su creador recomienda que la productividad sea siempre calibrada a la realidad de la organización y el proyecto. Por esto, una de las principales ventajas del modelo Putnam es su simplicidad para ser calibrado.

Ventajas: Es uno de los métodos que mayor exactitud presenta frente al resto.

Es uno de los pocos modelos de estimación que tiene presente la incertidumbre dentro de sus cálculos.

Desventajas: Es un modelo comercial y existe poca documentación disponible para

utilizarlo de forma manual.

Ejemplo de aplicación

Se tiene un paquete de software a desarrollarse para una aplicación de diseño asistido por

computadora (computer-aideddesign, 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.

Ilustración 1 Valor de productividad

Simplificación del proceso de estimación:

Putnam y Myers sugieren un conjunto de ecuaciones obtenidas de la ecuación del software. Un tiempo mínimo de desarrollo se define como:

Ilustración 2 Ecuaciones del software

Análisis:

Ilustración 3 Analisis

Estimación del tamaño del software

Técnica LDC (DATOS DE LINEAS DE CÓDIGO)

Técnicas De Estimación De Tamaño

Técnicas De Descomposición

Antes de realizar la estimación del proyecto se debe generar una estimación del tamaño del software a construir.

Tamaño del software

Dentro de la planificación de proyectos, el tamaño se refiere a una producción cuantificable del proyecto de software.

o El tamaño se mide en LDC, si se utiliza un enfoque directo o El tamaño se representa como PF, si se utiliza un enfoque indirecto.

Se tienen 4 enfoques referentes al tamaño:

a) Tamaño en lógica difusa

Utiliza las técnicas aproximadas de razonamiento. Para aplicar este enfoque se debe:

Identificar el tipo de aplicación Establecer su magnitud en una escala cuantitativa Refinar la magnitud dentro del rango original

b) Tamaño de componentes estándar

El software está compuesto por un número de componentes estándar (subsistemas, módulos, pantallas, informes, etc) que son genéricos para un área en particular, Se debe:

Estimar el número de incidencias de cada uno de los componentes

Utilizar los datos de proyectos históricos para determinar el tamaño de entrega por componente.

c) Tamaño del cambio

Este enfoque se utiliza cuando en un proyecto se utiliza software existente y que se debe modificar de alguna manera como parte del proyecto.

Se debe estimar el número y tipo de modificaciones que se deben llevar a cabo.

Para estimar el tamaño del cambio,

Funcionamiento

Las LDC miden en forma directa el tamaño del producto de software. Se calculan contando las instrucciones de código fuente de cada elemento del producto de software excluyendo, generalmente, los comentarios.

Antes de adoptar esta métrica, la organización debe definirla en forma exhaustiva. Esta definición debe respetarse, ya que podría atentar a la integridad de los datos del proyecto. Cuando se utiliza LDC como variable de estimación, la descomposición funcional es absolutamente esencial, a menudo se lleva hasta considerables niveles de detalle.

Usando PF es la variable de estimación es menos detallado. También, debe de tenerse en cuenta

que mientras que LDC se estima directamente, PF se determina indirectamente mediante la

estimación del número de entradas, salidas, archivos de datos y peticiones externas, entre otras.

Entonces, se calcula el valor esperado de LDC. El valor esperado para la variable de estimación, E,

se obtiene como una medida ponderada de las estimaciones LDC óptima (a), más probable (m) y

pesimista (b). Esta técnica trata de definir el tiempo y el costo del proyecto en base a la cantidad

de líneas de código se tienen que escribir, cual es el costo por línea y cuantas líneas de código

desarrollamos en un mes.

Ilustración 4 Tabla tomada de. http://arfduoc.blogspot.com.co/p/estimaciones-ldc-y-pf.html

¿Qué valores se ponen en esta tabla?

Se coloca en la columna de "Bsf/línea" el precio de cada línea en cada módulo, esto

generalmente se realiza basados en los costos de proyectos anteriores. La siguiente casilla pertenece a cuantas líneas se pueden escribir en un mes.

La casilla de "Coste", nos permite tener el cálculo de cuánto costaría cada módulo, esto se obtiene

de multiplicar la columna de "Bsf. por línea" con la de "Esperada". Los meses se calculan

multiplicando las "Líneas al mes" por "Esperada" Al totalizarlas columnas calculadas tendríamos

en la columna de "Esperada" la cantidad de líneas que se escribirían, en la de "Coste" el costo

estimado del proyecto y en la de "Meses" los meses que demoraría el proyecto.

Pasos para el cálculo LDC:

Descomponer el problema Estimar valores para columnas de líneas de código a escribir Calcular columna esperada

Ilustración 5 Formula, estraido de. http://arfduoc.blogspot.com.co/p/estimaciones-ldc-y-pf.html

Ilustración 6 Procesos de estimación


Considere un paquete de software a desarrollar para una aplicación de diseño asistido por

computadora. Revisando la especificación del sistema encontramos que el software va a

ejecutarse en una estación de trabajo de microcomputadora y se conectara con varios periféricos gráficos incluyendo ratón, digitalizador, pantalla en color de alta resolución, y

una impresora de alta resolución.

La evaluación del alcance indica que se requiere las siguientes funciones principales para el software CAD:

Estimación del esfuerzo

Ilustración 7 Estimación del esfuerzo

Wideband Delphi Un grupo de personas son informadas y tratan de adivinar lo que costara el desarrollo tanto en esfuerzo, como su duración.

Las estimaciones en grupo suelen ser mejores que las individuales.

Funcionamiento

Se dan las especificaciones a un grupo de expertos. Se les reúne para que discutan tanto el producto como la estimación. Remiten sus estimaciones individuales al coordinador.

Cada estimador recibe información sobre su estimación, y las ajenas pero de

forma anónima. Se reúnen de nuevo para discutir las estimaciones. Cada uno revisa su propia estimación y la envía al coordinador. Se repite el proceso hasta que la estimación converge de forma razonable.

Ejemplo de aplicación Estimación por grupos de expertos: Método Delphi.

La información sobre este método la he extraído del libro de McConnell sobre estimación de software: Software Estimation, Demystifying the Black Art, que os recomiendo.

El método wideband Delphi es una técnica de estimación estructurada en grupo. Deriva de un método creado en los 40.

Se basa fundamentalmente en que varios expertos, tras crear estimaciones individuales, se reunen para ponerse de acuerdo en una estimación.

Un estudio del método original decía que no se obtenían mejores resultados que con estimaciones individuales debido a las presiones políticas que se podían ejercer sobre el grupo. Así que Boehm y Farquhar crean en los 70 el Wideband Delphi como mejora del original.

El proceso mejorado es el siguiente:

El coordinador presenta a cada experto la especificación y un formulario de estimación. Los estimadores trabajan individualmente. (Se puede hacer esto tras el paso 3)

Se hace una reunión en la que los expertos hablan de los posibles problemas de

estimación. Los expertos rellenan las estimaciones y se las dan al coordinador de manera anónima. El coordinador prepara un resumen de las estimaciones y la reparte a todos los expertos.

Se reunen tanto el coordinador como los expertos para ver variaciones en las

estimaciones.

Los expertos votan anónimamente si aceptan la estimación media. Si alguien vota que no se vuelve al paso 3.

La estimación final es una estimación única (single-point estimate). También podría ser un

rango creado durante la estimación en la que la single-point es el caso esperado (recordad lo de caso más probable, menos probable y caso esperado).

Ilustración 8 Ejemplo extraida de: http://photos1.blogger.com/x/blogger/1795/2883/1600/965561/widebanddelphi.png

En la imagen se muestra cómo podría evolucionar un supuesto proceso de estimación, y también cómo es el formulario de estimación: una escala en la que colocar la estimación. Hay que tener en cuenta que la escala debe ser lo suficientemente amplia para no coaccionar a los estimadores.

¿Es útil el método?

McConnell dice que en 25 grupos en los que ha recogido datos, comparando datos de estimaciones hechas haciendo un promedio de los expertos respecto a usar método Delphi, se obtiene una mejora de alrededor de un 40%.

http://photos1.blogger.com/x/blogger/1795/2883/1600/965561/widebanddelphi.png

Habla también de que muchas veces la estimación correcta (que lógicamente sólo se sabe a posteriori) no está dentro del rango original cubierto por los estimadores, y que sin embargo usando Delphi se llega, 1/3 de las veces, a incluir ese punto.

¿Cuándo usarlo?

Fundamentalmente al inicio de los proyectos, cuando todavía hay mucha incertidumbre. En el área inicial del cono de incertidumbre se puede mejorar mucho con Delphi, luego cuando hay más datos será mejor cambiar a otras técnicas.

Pero al principio puede ser útil combiar múltiples informaciones de diferentes expertos.

Estimación del tiempo

La estimación, es la actividad de la planificación del proyecto que intenta determinar cuánto dinero, esfuerzo, recursos y tiempo tomará construir un sistema o producto.

Gestión de Tiempos

La gestión de tiempos reúne todos aquellos procesos necesarios para asegurar el correcto desarrollo de las distintas tareas, dentro de los plazos especificados, así como de las herramientas para el control y seguimiento de la planificación temporal y la programación del proyecto.

Los principales procesos incluidos en esta categoría son:

Definición de tareas: Identificando las tareas específicas necesarias para el desarrollo del proyecto, y obtención de los resultados. La definición de las tareas consiste en identificar y documentar todas las tareas específicas que deben de realizarse para obtener los resultados esperados, tal y como se especifica en la planificación del proyecto.

Secuencia de actividades: Definiendo las inter-relaciones existentes entre las diferentes tareas.

Este proceso consiste en la identificación y documentación de las interacciones lógicas entre las distintas tareas, sus inter-relaciones y dependencias mutuas. Estas relaciones deben de ser planificadas con suficiente precisión, de forma que se pueda obtener posteriormente un calendario realista y una programación razonable del proyecto.

Estimación de la duración de las tareas: Estimando el número de unidades necesarias para su

completa finalización. Es el proceso de toma de información a partir de los objetivos y alcance

del proyecto, y de los recursos necesarios y disponibles, para establecer una duración lo más

aproximada posible a la realidad de cada tarea. Cada duración, suele definirse por la persona,

ó grupo de personas a cargo de cada tarea, ya que ellos conocen más detalladamente los

requisitos individuales y específicos de las tareas a su cargo. Este proceso es un proceso

progresivo, que depende en gran manera del grado de detalle, y de la calidad de la

información de la que se disponga. Establecimiento del calendario: A partir del análisis de las secuencias de tareas, duraciones, y los

recursos requeridos para cada una de ellas. Este proceso consiste en definir claramente las fechas

de inicio y fin de cada una de las tareas a desarrollar en el proyecto. Lógicamente, si estas fechas

no son realistas, es poco probable que el proyecto se desarrolle y finalice dentro de los

plazos establecidos. Este proceso depende en gran medida de los procesos de estimación de la duración de las tareas, así como de la estimación de costes.

Control del calendario: Realizando un seguimiento y ajustando en caso necesario los posibles cambios en la programación. Estos procesos interactúan entre ellos mismo, y con procesos de otras áreas, y requieren el trabajo de una sola, o de un equipo de personas en función del tamaño y de las necesidades del proyecto.

En algunos proyectos, especialmente en aquellos de reducido tamaño, la secuencia de las

tareas, la estimación de la duración, y el establecimiento del calendario están tan ligados, que se desarrollan como un único proceso.

Método PERT (Program Evaluation and Review Technique) El método pert es una técnica que le permite dirigir la programación de su proyecto. El método PERT

consiste en la representación gráfica de una red de tareas, que, cuando se colocan en una cadena,

permiten alcanzar los objetivos de un proyecto. Fue diseñada por la marina de los Estados Unidos para

permitir la coordinación del trabajo de miles de personas que tenían que construir misiles con cabezas

nucleares POLARIS. En su etapa preliminar, el método PERT incluye lo siguiente:

Desglose preciso del proyecto en tareas, Cálculo de la duración de cada tarea,

La designación de un director del proyecto que se haga cargo de asegurar la supervisión de dicho proyecto, de informar, en caso de ser necesario, y de tomar decisiones en caso de que existan variaciones de las proyecciones.

Funcionamiento La aplicación del PERT es sumamente amplia ya que puede ser utilizado en la administración de cualquier tipo de proyecto. Se plantan tres principios básicos que son necesarios para construir los diagramas a través de los cuales se representan las actividades del proyecto:

Principio de designación sucesiva. Se nombra a los vértices según los números naturales, de manera que no se les asigna número hasta que han sido nombrados todos aquellos de los que parten aristas que van a parar a ellos.

Principio de unicidad del estado inicial y el final. Se prohíbe la existencia de más de un

vértice inicial o final. Sólo existe una situación de inicio y otra de terminación del proyecto.

Principio de designación unívoca. No pueden existir dos aristas que tengan los mismos

nodos de origen y de destino. Normalmente, se nombran las actividades mediante el par

de vértices que unen. Si no se respetara este principio, puede que dos aristas recibieran la

misma denominación. La distribución beta es utilizada en este método ya que permite

aproximar la duración de las actividades; esta distribución permite incorporar datos que

no se distribuyen normalmente y, además, el tiempo atribuible a cada actividad puede

acomodarse hacia alguno de los extremos en función de la existencia, o no, de algún

atraso en la actividad.

Ilustración 9 Program Evaluation and Review Technique

Ejemplo de aplicación Consideremos el proyecto utilizado para ejemplificar la metodología CPM. Sin embargo, asumiremos distintos escenarios de ocurrencia asociados al tiempo necesario para completar cada actividad, los que se resumen en la siguiente tabla:

Ilustración 10 Tabla Ejemplo

El primer paso consiste en calcular el tiempo esperado (te) asociado a cada actividad, utilizando la fórmula presentada anteriormente:


Notar que en este caso m = te para cada actividad, lo cual no tiene que ser necesario. Lo importante es tener en cuenta la metodología a utilizar. Luego, una vez obtenido el tiempo esperado (te) para cada actividad se procede a calcular la duración del proyecto utilizando un procedimiento similar a CPM. Los resultados se resumen en el siguiente diagrama:

Ilustración 12 Ejemplo

La ruta crítica (única) esta conformada por las actividades B-C-E-F-H con una duración total de 49 semanas. (Ver detalle en CPM). Posteriormente se calcula la varianza para cada actividad (aun cuando en estricto rigor sólo es necesario para las actividades críticas, es decir, con holgura igual a cero), de modo de obtener finalmente la varianza (y desviación estándar) de la ruta crítica.


con esta información podemos responder a preguntas como ¿Cuál es la probabilidad de completar el proyecto en 52 semanas o menos? Básicamente esto consiste en determinar el porcentaje del área acumulada para una distribución normal para determinado valor de Z.

Ilustración 14 Ejemplo

P[Tp<=52]=P[Z<=(52-49)/2,81]=P[Z<=1,07]=85,77%

En conclusión, la probabilidad de completar el proyecto en 52 semanas o menos es de un 85,77%.

Estimación del costo

COCOMO

Ilustración 15 Niveles y modelos Modelo COCOMO

Este modelo ayuda a un estimador a comprender mejor la complejidad del software; este modelo es un ejemplo de variable simple estático y es usado por miles de administradores de proyecto de software.

COCOMO ayuda a estimar el esfuerzo, tiempo, gente y costos (ya sea estos de desarrollo, equipamiento y mantenimiento).

Funcionamiento El modelo provee tres "niveles" de aplicación: básico, intermedio y avanzado, basados en los factores considerados por el modelo.

Básico: es un modelo estático simplemente evaluado que calcula el esfuerzo (y costo) del desarrollo del software como función del programa expresado en líneas de código (LDC estimados).

Intermedio: calcula el esfuerzo del desarrollo del software como función del tamaño del

programa y un conjunto de "guías de costo" que incluye una evaluación subjetiva del producto, hardware, personal y de los atributos del proyecto.

Avanzado: incorpora todas las características de la versión intermedia con una evaluación

del impacto de las vías de costo en cada fase (análisis, diseño, etc) del proceso de la ingeniería de software.

El modelo básico se extiende para considerar un conjunto de atributos de guías de costo que pueden agruparse en cuatro categorías principales:

Producto (por ej. Requerimientos de software, confiabilidad, tamaño de la base de datos,

y complejidad del producto). Computadora (por ej. Restricciones en el tiempo de ejecución y almacenamiento).

Personal (por ej. Capacidad de análisis, experiencia en aplicaciones tanto en lenguajes de

programación y capacidad del programador)

Proyecto (por ej. Uso de prácticas modernas de programación, uso de herramientas de software y requerimiento de un plan de desarrollo).

En cada nivel de aplicación están definidos para tres tipos de proyectos de software:

Modo orgánico, proyectos de software relativamente pequeños y sencillos en los que pequeños equipos con buena experiencia en la aplicación trabajan en un conjunto de requerimiento poco rígidos.

Modo semi-acoplado(semi-detached), un proyecto de software intermedio en tamaño y

complejidad en el cual equipos con distintos niveles de experiencia debe satisfacer requerimientos poco y medio rígidos

Modo acoplado(detached), un proyecto de software que debe ser desarrollado dentro un

conjunto estricto de hardware, software y de restricciones operativas.

Modos que están basados en la complejidad de la aplicación y el desarrollo del ambiente

Ilustración 16 Modelo intermedio que depende de modo de desarrollo

Ilustración 17 Modo básico utiliza el tamaño y el modo intermedio 15 manejadores de costo


Entre los distintos métodos de estimación de costes de desarrollo de software, el modelo COCOMO (COnstructive COst MOdel) desarrollado por Barry M. Boehm, se engloba en el grupo de los modelos algorítmicos que tratan de establecer una relación matemática la cual permite estimar el esfuerzo y tiempo requerido para desarrollar un producto.

Para nuestro caso el modelo intermedio será el que usaremos, dado que realiza las estimaciones con bastante precisión.

Así pues, las fórmulas serán las siguientes:

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)

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:

Tabla 1 Datos conocidos

LENGUAJE LDC/PF

Ensamblador 320

C 150

COBOL 105

Pascal 91

Prolog/LISP 64

C++ 64

Visual Basic 32

SQL 12

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

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:

Tabla 2 Coeficientes

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

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:

Tabla 3 Resultados

CONDUCTORES DE COSTE VALORACIÓN

Muy Bajo Nominal Alto Muy Extr. bajo alto 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,65

Restricciones del tiempo de ejecución - - 1.00 1,11 1,30 1,66 Restricciones del almacenamiento principal - - 1.00 1,06 1,21 1,56 Volatilidad 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

Justificación de los valores:

Atributos de software

Fiabilidad requerida del software: Si se produce un fallo por el pago de un pedido, o fallo en alguna reserva, etc... puede ocasionar grandes pérdidas a la empresa (Valoración Alta).

Tamaño de la base de datos: La base de datos de nuestro producto será de tipo estándar (Valoración Nominal).

Complejidad del producto: La aplicación no va a realizar cálculos complejos (Valoración Baja).

Atributos de hardware

Restricciones del tiempo de ejecución: En los requerimientos se exige alto rendimiento (Valoración Alta).

Restricciones del almacenamiento principal: No hay restricciones al respecto (Valoración

Nominal). Volatilidad de la máquina virtual: Se usarán sistemas de la “Familia Windows” (Valoración

Nominal).

Tiempo de respuesta del ordenador: Deberá ser interactivo con el usuario (Valoración Alta).

Atributos del personal

Capacidad del analista: Capacidad alta relativamente, debido a la experiencia en análisis en proyecto similar (Valoración Alta)

Experiencia en la aplicación: Se tiene cierta experiencia en aplicaciones de esta envergadura

(Valoración muy alta).

Capacidad de los programadores: Teóricamente deberá tenerse una capacidad muy alta por la experiencia en anteriores proyectos similares (Valoración muy alta).

Experiencia en S.O. utilizado: Con Windows 2000 Professional la experiencia es a nivel usuario

(Valoración Nominal).

Experiencia en el lenguaje de programación: Es relativamente alta, dado que se controlan las nociones básicas y las propias del proyecto (Valoración Alta).

Atributos del proyecto

Prácticas de programación modernas: Se usarán prácticas de programación mayormente convencional (Valoración Nominal).

Utilización de herramientas software: Se usarán herramientas estándar que no exigirán apenas

formación, de las cuales se tiene cierta experiencia (Valoración Alta).

Limitaciones de planificación del proyecto: Existen pocos límites de planificación. (Valoración Baja).

Cálculo del esfuerzo del desarrollo:

E = a KLDC e * FAE = 3,2 * (8.363)^1,05 * 0,53508480 = 15,91 personas /mes

Cálculo tiempo de desarrollo:

T = c Esfuerzo d = 2,5 * (15,91)^0,38 = 7,15 meses

Productividad:

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

Personal promedio:

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

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/3 nos da alrededor de este resultado).

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

Software de estimación 01

Bailey-Basili Bailey y Basili (81) sugirieron una técnica para obtener un modelo de coste a partir de sus propios datos.

La ecuación del esfuerzo obtenida a partir de 18 grandes proyectos es:

E = 5.5 + 0.73 S1.16

La ecuación se ajusta mediante un factor de ajuste del esfuerzo calculado a partir de los atributos de la tabla siguiente.

A cada entrada en la tabla se le da una puntuación de 0 a 5. Los valores obtenidos se usan para ajustar la ecuación:

Ajuste del esfuerzo = a METH + b CPLX + c EXP + d

Ilustración 18 Bailey-Basili extraido de : http://www.lsi.us.es/docencia/get.php?id=326

Funcionalidades

Más que un modelo de estimación en sí mismo, Bailey y Basili presentan un método de construcción de un modelo local de estimación. El proceso de generación del modelo consiste en tres pasos:

Calcular el Esfuerzo a partir de la ecuación inicial proporcionada por el modelo.

Determinar qué conjunto de factores diferencian al proyecto que se ha estimado y que podrían explicar las variaciones entre los datos medidos en el proyecto real y los valores

estimados obtenidos mediante la ecuación inicial. Bailey y Basili identificaron cerca de 100 atributos dependientes del entorno local de desarrollo como posibles causantes de la variación entre el esfuerzo medido y el estimado, aunque al trabajar solamente con 18

conjuntos de datos no podían considerar matemáticamente tantos atributos.

Para resolver el problema propusieron la utilización de distintas técnicas como la experiencia de expertos, o las matrices de correlación, para seleccionar los más influyentes; de esta forma

obtuvieron finalmente 21 atributos. Además agruparon dichos atributos siguiendo la lógica de que

el grupo tuviera un impacto positivo o negativo sobre el esfuerzo y fuera fácilmente explicable. Los tres grupos obtenidos fueron:

Metodología Total (METH) Diagramas de árbol.

Diseño Top – Down.

Formalismos de Diseño.

Lectura de código.

Jefe del grupo de programadores.

Planes formales de pruebas.

http://www.lsi.us.es/docencia/get.php?id=326

Unidades de desarrollo.

Planes formales de formación.

¿Complejidad Acumulada (CMPLX) Complejidad de interfaz de usuario.

Cambios del cliente iniciado el diseño.

Complejidad de proceso de la aplicación.

Complejidad del flujo de datos del programa.

Complejidad de comunicación interna.

Complejidad de comunicación externa.

Complejidad de la base de datos.

Experiencia Acumulada (CEXP) Aptitud del programador.

Experiencia del programador con la máquina.

Experiencia del programador con el lenguaje.

Experiencia del programador con la aplicación.

Trabajos previos del equipo trabajando juntos.

Utilizar el modelo para predecir nuevos proyectos. La ecuación inicial o relación básica entre esfuerzo y tamaño se determinó, como se ha dicho, utilizando 18 conjuntos de datos procedentes del SEL (Software Engineering Laboratory – Laboratorio de Ingeniería del Software) de la NASA (National Agency Space Administration – Agencia Nacional para la Administración del

Espacio).

Ejemplo

Ilustración 19 Extraido de https://prezi.com/i8dmryocefad/tecnica-de-estimacion-de-esfuerzo-bailey-basili/

Ilustración 20 Extraido de http://images.slideplayer.es/1/110733/slides/slide_18.jpg


Expert Estimateur

Es una estimación de software que le permite producir sus citas de forma rápida, eficaz para asegurar la cita de seguimiento, y para obtener precios estandarizados en tiempo real. Un socio de los principales distribuidores de productos eléctricos y de plomería, experto Estimador tiene más de 500 clientes especializados en fontanería, electricidad, calefacción y ventilación en Canadá.

• Desde un punto de vista comercial, menor será el tiempo que gasta citas que se

preparan, los más citas que son capaces de preparar; los más citas, más peticiones, así

como los proyectos que son más propensos a ser adjudicado. Y los más proyectos que se

otorgan, cuanto mayor sea su ingreso - pero sólo si sus proyectos son rentables.

¡Asegúrese de que su proceso es rentable!

Características principales:

Una base de datos que contiene todos los productos desde el distribuidor de su elección con presupuesto personalizado;

Las actualizaciones de precios automáticos disponibles 24/7;

Capacidad de agregar sus productos de uso personal;

Una herramienta de búsqueda flexible que le permite encontrar sus productos de forma rápida, utilizando 7 diferentes métodos de búsqueda;

Miles de imágenes y hojas de datos técnicos disponibles; Trabajo sobre los productos;

Posibilidad de añadir un producto a su carrito de la compra en el sitio web de

su distribuidor con un solo clic; Ver la ficha de producto en línea con un solo clic; Múltiples opciones para la impresión de informes

Requerimientos tecnológicos

Presupuesto Mínimo Necesario

Sistema operativo 1 Windows 10, Windows 8, Windows 8, Windows

Windows Server 2012, Server 2012, Windows 7,

Windows 7, Windows Windows Server 2008 R2

Server 2008 R2, Windows

Vista, Windows Server

2008, Windows XP,

Windows Server 2003 R2,

Windows Server 2003

RAM 2 Gb 4 GB

Unidad de disco duro Capacidad Standard Version 150 Mb 300 Mb

Unidad de disco duro Capacidad de red versión, la 50 Mb 150 Mb

estación de trabajo

Capacidad del disco duro de red versión, el servidor 500 Mb 1 Gb

Resolución de la pantalla 1024 × 768 o más 1024 × 768 o más

Lector de CD-ROM Necesario Necesario

Funcionalidades El software de Expertos Estimador es una herramienta esencial para los contratistas especializados en fontanería, electricidad, calefacción y ventilación. El software está disponible en 6 módulos para satisfacer sus necesidades de estimación:

Productos

Direcciones ensamblajes Citas

Facturas

Ordenes.


SLIM-Metrics

SLIM-Metrics ® trabaja con el SLIM-Data Manager ® herramienta de repositorio de datos para

ayudar a preservar la historia del proyecto, evaluar la posición competitiva, identificar cuellos de

botella, cuantificar los beneficios de la mejora de procesos, y defender las estimaciones futuras del

proyecto. Benchmark sus datos contra las tendencias de la industria de referencia de la base de

datos de más de 10.000 QSM proyectos de software completas o crear sus propias tendencias de

referencia para utilizar en SLIM-Metrics, SLIM-Estimación o SLIM-Control.

Ilustración 21 SLIM-Metrics tomado de: http://www.qsm.com/tools/slim-metrics

Requerimientos tecnológicos Todos los Sistema Operativos Licencia: Software propietario

Funcionalidades SLIM-Metrics le da la capacidad de:

Crear y comparar subconjuntos de datos Crear un número ilimitado de puntos de vista de gráficos / Informe Utilizar puntos de referencia actuales de la industria Emplear herramientas de análisis estadístico Ver detalles de cualquier punto de datos Añadir notas personalizadas y otras características Producir excelentes gráficos y tablas Los datos de exportación con facilidad


Ilustración 22 Ejemplo tomado de: http://www.slideshare.net/Sixsigmacentral/software-management-metrics-

herman-p-schultz


COCOMO II

COCOMO II 1.0.001, Este programa sin coste fue desarrollado originariamente por USC CSSE. La herramienta pertenece al grupo Desarrollo, en concreto al de aplicaciones sobre Herramientas de base de datos.

Surge como una alternativa para incluir componentes de incerteza en las estimacións conforme al

nivel de información disponible. Este es un modelo paramétrico que establece ecuaciones

matemáticas para describir las relaciones entre el tamaño del software - factor primario de costo

usualmente representado en términos de puntos de función - y otros factores secundarios que

buscan capturar particularidades de producto, proceso, personas y plataforma. Esos factores son

denominados Cost Drivers, siendo algunos de efecto proporcional y otros de efecto exponencial.

Requerimientos tecnológicos Sistema Operativo: Windows 7, Windows Xp, Windows Vista. Licencia: Gratis

Funcionalidades

Establecer la diferencia entre los actos de estimar, asumir un compromiso y establecer una meta y con eso, adoptar una postura de quien ofrece una estimación en contraste con la postura de quien lleva más tiempo o recursos.

Presentar las opciones y escenarios para que los responsables puedan establecer las metas o

asumir compromisos con base en fundamentos sólidos y en instrumentos de gerencia del conocimiento.

Diferenciar una estimación directa y un modelo de estimación paramétrica. Específicamente

sobre ésos últimos, discutimos las particularidades entre aquellas basadas en modelos determinísticos y aquellas basadas en modelos estocásticos.

Transformar los rangos de esfuerzo y plazo optimistas, más probables y pesimistas ofrecidas

por modelos de estimación estocásticas o por la estimación directa en una determinada cantidad de horas o de meses acompañados de la respectiva probabilidad.

Diferenciar entre los tres modelos que componen el COCOMOII: Composición de Aplicación

(Application Composition), Proyecto Preliminar (Early Design) y Pos arquitectura (Post-Architecture) y seleccionar aquellos más adecuados conforme al nivel de información disponible durante la elaboración de la estimación.

Utilizar el punto de función como parámetro de costo primario del modelo y realizar la

evaluación de los demás parámetros de costo secundarios relativos al producto, al proceso, al personal.

Interpretar los resultados del modelo en términos de cuáles actividades y en qué fases del

ciclo de vida de desarrollo están siendo incluídas en las estimaciones generadas; cuáles categorías de trabajo son consideradas en los resultados; en qué puntos el modelo debe ser leído como una referencia de mercado y cuáles puntos deben necesariamente ser calibrados a las condiciones locales de donde serán aplicados.


El software COCOMO II.1999.0 calcula la estimación tanto del esfuerzo como el tiempo de desarrollo del proyecto completo se pueden distribuir por fase:

Ilustración 23 Fases

Permite determinar el Tiempo de Desarrollo Estimado del proyecto, analizar las características de cada módulo y determinar en qué nivel se encuentra cada uno de los factores de costo.

Ilustración 24 Factores de costo

Ilustración 25 Estimación de Esfuerzo (hh) modelo EPEI y Juicio de Experto

Conclusiones

COCOMO es uno de los modelos más documentados en la actualidad y es muy fácil de utilizar. Es correcto con referencia a los 63 proyectos utilizados, aunque de ello no se debe desprender que deba ser válido siempre.

El uso de un método apropiado de estimación es de vital importancia para cualquier compañía que desarrolle proyectos de software, ya que le permite tener una visión a futuro del esfuerzo tamaño y costo que tomará desarrollar una aplicación o proyecto.

Las métricas de software surgen para proveer mediciones con el fin de observar el progreso y la

retroalimentación necesaria para el ajuste de planes para evitar futuros riesgos y fracasos ,

teniendo en cuenta que la ingeniería de software surge con el propósito de la creación de

métodos efectivos que faciliten el desarrollo del software y haciendo al final un resultado efectivo

y de calidad para esto se utilizan las debidas herramientas como las métricas y sus software.

Bibliografía

MODELO COCOMO. (2008). MODELO COCOMO. [online] Available at: https://acevedodelacru.wordpress.com/modelo-cocomo-2/ [Accessed 17 Mar. 2016].

Sc.ehu.es. (2016). El Modelo COCOMO. [online] Available at: http://www.sc.ehu.es/jiwdocoj/mmis/cocomo.htm [Accessed 17 Mar. 2016].

proyectosumg.com/data/IngenieriaSoftware/cocomo.doc

perfil, V. (2010). *.:｡.AnaLiSis y DiSeÑo de SoFtwaRe.｡.:*. [online] Software-

keyla.blogspot.com.co. Available at: http://software-keyla.blogspot.com.co/2010/10/blog-

post.html [Accessed 17 Mar. 2016].

Pressman, R., (2015). Ingeniería del Software - Un enfoque práctico. 7ma Edición. New York: MacGRAW-HILL

Rodríguez, J.; García, J, y Lamarca, I. (2007). Gestión de proyectos informáticos: métodos, herramientas y casos (1ª. ed.). Citado el 16 de Marzo de 2016 de: https://books.google.co.cr/books?id=I22YPj6iBisC&pg=PA43&lpg=PA43&dq=&hl=es#v=onepage& q&f=false

CCM. (2016). Método PERT. [online] Available at: http://es.ccm.net/contents/582-metodo-pert [Accessed 17 Mar. 2016].

http://fi.ort.edu.uy/innovaportal/file/2025/1/gp06.estimaciones.pdf

http://www.deinsa.com/cmi/documentos/Los_factores_criticos_del_exito.pdf

Métodos de Estimación de Tamaño Funcional Software Aplicación a Enfoques de desarrollo. (2016). [online] Available at: http://www.dlsiis.fi.upm.es/docto_lsiis/Trabajos20022003/Labdelaoui2.pdf [Accessed 17 Mar. 2016].

Sites.google.com. (2016). 3.2 Estimaciones de tiempo - Gestion de Proyectos Software. [online] Available at: https://sites.google.com/site/gestiondeproyectossoftware/unidad-3-planificacion-de-proyecto/3-2-estimaciones-de-tiempo [Accessed 17 Mar. 2016].

Investigaciondeoperaciones.net. (2016). [online] Available at: http://www.investigaciondeoperaciones.net/pert.html [Accessed 17 Mar. 2016].

PF, E. (2016). Administración de recursos Informáticos Duoc 2012: Estimaciones LDC y PF. [online] Arfduoc.blogspot.com.co. Available at: http://arfduoc.blogspot.com.co/p/estimaciones-ldc-y-pf.html [Accessed 17 Mar. 2016].

Qsm.com. (2016). QSM Benchmarking | Metrics from the 10000 Software Project Database | QSM SLIM-Estimate. [online] Available at: http://www.qsm.com/tools/slim-metrics [Accessed 17 Mar. 2016].

Garzás, J. (2011). Estimación software: una breve guia. [online] Javier Garzás. Available at: http://www.javiergarzas.com/2011/06/breve-introduccion-estimacion-1.html [Accessed 18 Mar. 2016].

Lsi.us.es. (2016). [online] Available at: http://www.lsi.us.es/docencia/get.php?id=326 [Accessed 18 Mar. 2016].

Es.wikipedia.org. (2016). Modelo SLIM. [online] Available at: https://es.wikipedia.org/wiki/Modelo_SLIM [Accessed 18 Mar. 2016].

Oyola, J. (2010). La Ecuacion del Software. [online] Es.slideshare.net. Available at: http://es.slideshare.net/jedaro/la-ecuacion-del-software [Accessed 18 Mar. 2016].

Pgpubu.blogspot.com.co. (2007). Planificación y Gestión de Proyectos: Técnica de estimación: Wideband Delphi. [online] Available at: http://pgpubu.blogspot.com.co/2007/01/tcnica-de-estimacin-wideband-delphi.html [Accessed 18 Mar. 2016].

www.upv.es/~jmontesa/eog/eog00-t4.ppt

https://books.google.co.cr/books?id=I22YPj6iBisC&pg=PA43&lpg=PA43&dq=&hl=es#v=onepage&q&f=false

https://books.google.co.cr/books?id=I22YPj6iBisC&pg=PA43&lpg=PA43&dq=&hl=es#v=onepage&q&f=false

http://fi.ort.edu.uy/innovaportal/file/2025/1/gp06.estimaciones.pdf

http://www.deinsa.com/cmi/documentos/Los_factores_criticos_del_exito.pdf

Anon, (2016). ESTIMACIÓN DE PROYECTOS SOFTWARE. [online] Available at: http://is.ls.fi.upm.es/docencia/masterTI/EPS/docs/estimacion.pdf [Accessed 18 Mar. 2016].

Métricas Tecnicas del software, Capitulo 19 Roger,Pressman “Ingenieria de Sofware” Quinta Edición. [online] Available at: http://www.uv.mx/personal/asumano/files/2012/08/MetricasTecnicas.pdf [Accessed 18 Mar. 2016]. Z

Expertestimateur.ca. (2016). Client Testimonials - Expert Estimator. [online] Available at: http://www.expertestimateur.ca/en/about/testimonials/ [Accessed 18 Mar. 2016].

Expertestimateur.ca. (2016). Training Program - Expert Estimator. [online] Available at: http://www.expertestimateur.ca/en/training/training-program/ [Accessed 18 Mar. 2016].

ESTIMACIÓN DE PROYECTOS

Documents

Transcript of ESTIMACIÓN DE PROYECTOS