software estimation (in spanish)

Estimación de tamaño, costos y

esfuerzos

• Introducción

• Métodos de Estimación

• Método Delphi de Banda Ancha

• Método COCOMO

• Método de Puntos de Función

• Método de Componentes Estándares

• Consideraciones para adopción de métodos en la

industria

• Explicación de la práctica

Reconocimientos

• Material preparado por profesor Sergio Ochoa

(Universidad de Chile) a partir del notas de clase

• Prof. Jaime Navón (www2.ing.puc.cl/~jnavon).

• Prof. Sergio Ochoa

(http://www.dcc.uchile.cl/~sochoa/)

• Material adaptado y complementado por la

profesora Raquel Anaya (Universidad EAFIT)

[email protected].

• Versión 3.0: Fáber Giraldo

Evaluar, calcular, dar valor a una actividad

de manera anticipada.

¿Qué es estimar?

¿Cómo estimas el tiempo que requieres

para preparar un parcial? ¿Cuánto tiempo estimas para

Ir de tu casa a la universidad?

¿Estimación intuitiva o basada en datos?

¿Qué tan precisa es la estimación?

• La estimación forma parte de la planificación de un proyecto

• Permite resolver tres preguntas básicas para el

desarrollo del software

– ¿Cuánto esfuerzo (Por ejemplo Horas-Hombre)se requiere para desarrollarlo?

– ¿Cuánto tiempo, de calendario, se necesita para

realizarlo?

– ¿Cuál es el costo total?

¿Por qué es importante la estimación de un

proyecto de software?

1. Desestimar el tiempo y esfuerzo necesario para hacer una buena

estimación.

2. Requisitos imprecisos. Requisitos van creciendo.

3. Muchas veces el plazo de desarrollo es fijado por gente del área

comercial o por ejecutivos, sin efectuar ningún tipo de cálculo serio.

4. El tamaño suele ser estimado por debajo.

5. Estimaciones forzadas por los recursos disponibles (Si hay que

acabar el proyecto en 12 meses y se dispone de 5 técnicos, se

estima en esfuerzo como 60 técnicos-día).

6. Usar la estimación del precio ganador. Estimar de acuerdo a lo que el

cliente esta dispuesto a pagar por el proyecto.

7. Cuando finaliza el proyecto, no hay tiempo de analizar los valores

estimados contra los valores reales.

Errores mas frecuentes al estimar (Sommeville)

Ejercicio – Estimación del Esfuerzo

En forma INDIVIDUAL….

Estime el esfuerzo de desarrollo del sistema de stock, para una Farmacia… El sistema debe llevar:

Los artículos (con el stock actual, ingresos y egresos).

Los proveedores.

Dos tipos de usuarios (actualizador y consultor).

En forma INDIVIDUAL….

Estime el esfuerzo de desarrollo del sistema de stock

Guarde el detalle de su estimación, pues loutilizaremos más adelante.

Entregue al profesor un papel anónimo con elnúmero total de Horas-Hombre (HH) delproyecto.

Ejercicio – Estimación del Esfuerzo

¿Qué debo hacer para poder

gestionar mis proyectos

de desarrollo?

Si no puedes medir

no puedes controlar

Tipos de Medidas

Medida directa, indirecta o predicción

Medida directa: se observa la entidad y se aplica el

instrumento de medida directamente (peso,

estatura).

Medida indirecta: se mide en forma directa otra entidad (o

más de una) y luego se usan relaciones conocidas

entre ellas (velocidad = distancia/tiempo).

Predicción: queremos estimar una característica (por ej.

tamaño) de una entidad que puede no existir en

este momento.

Similar a medición indirecta!

• Establecer una conexión ó relación entre las

entidades medidas directamente y las entidades cuya

medida será predicha.

• Refinar la conexión ó relación hasta llegar a una o más

fórmulas que permitan traducir las medidas directas en

predicciones confiables (medidas indirectas

aproximadas).

La diferencia clave está en que en la predicción no es

posible establecer una conexión completa => sólo se

puede aproximar a la medida correcta.

Predicción

Predicción

Similar a medición indirecta !

Sólo es posible predecir si tenemos buenas medidas en

qué basarnos!

A pesar de lo obvio de esta afirmación muchas veces

los administradores muestran gran interés en

estimación, pero no en mediciones de software.

El esfuerzo de estimar el desarrollo de un software,

siempre es una actividad de PREDICCION. La

predicción precisa requiere medición cuidadosa de

atributos claves en proyectos ya completados.

Predicción en software

Similar al proceso de diagnóstico de un médico.

El médico se basa en los análisis o estudios (medidas directas) y en su experiencia en casos anteriores o documentación relevante (relación entre medidas directas e indirectas) para poder realizar un diagnóstico y proponer una solución (estimación del proyecto de solución).

– Muchas veces se requiere una interconsulta, para determinar la relación entre las medidas directas y las indirectas (chequeo con pares).

El Reto de la Estimación de Software

Estimar es un proceso con incertidumbre:Nadie conoce cuál será el tamaño final del productoLa estimación es mas incierta cuanto más temprano

se hagaLa estimación puede estar sesgada por el negocio y

por otras presionesEstimar es un proceso de aprendizaje

La habilidad para estimar mejora con la experienciaLa estimación es mas confiable si se apoya en datos históricos Los métodos son poco usados en la industriaNo se tiene la disciplina de la medición

Agenda

• Introducción



• Método COCOMO




industria


Aproximaciones para Estimar(Nasir, M. Ahmad, F, 2006)

• Aproximaciones heurísticas: Basadas en la experiencia de las personas

y orientadas a su aprendizaje. Algunos ejemplos: Juicio de Experto,

Técnica Delphi, Técnica Delphi de Banda Ancha, Ley de Parkinson, Planing

poker.

• Aproximaciones paramétricas: Utiliza modelos de predicción obtenidos a

partir de datos históricos. Generalmente son modelos utilizados para

predecir el esfuerzo en función del tamaño. Algunos ejemplos: Líneas

de código, Puntos de Función con sus variantes, COCOMO y COCOMO-II, Puntos de Objeto, Puntos de casos de uso.

• Aproximaciones no paramétricas (Capretz,Marza, 2009): Soportadas en

algoritmos o modelos matemáticos: Algunos ejemplos: Modelo de lógica

difusa, modelo de red neuronal, modelo NeuroFuzzy, modelo de regresión múltiple, modelo estadístico.

Aproximaciones Heurísticas

• Juicio de experto: Basado en la experiencia de las personas y orientadas

a su aprendizaje

• Técnica Delphi: Es una técnica de grupo que extrae y resume el conocimiento del grupo para arribar a una estimación.

• Técnica de tres puntos: Utiliza tres 3 estimaciones de la duración de la

actividad: optimista, pesimista, media. Estimación final = (optimista + 4*

media + pesimista) /6

• Técnica Delphi de Banda Ancha (Wideband-Delphi): Es una

combinación de la técnica Delphi y la de tres puntos.

• Planning Poker: Técnica usada en estimación en conjunción con Delphide Banda Ancha, para lograr consenso de estimaciones de tamaño de los

requisitos de un proyecto de una manera rápida y ágil

• Ley de Parkynson: El proyecto cuesta según los recursos disponibles y el

ciclo de vida del proyecto se expandirá según el número de recursos disponibles en la organización

Agenda

• Introducción



• Método COCOMO




industria


Estimación Delphi de Banda Ancha

Originado en Rand Corporation, perfeccionado por B.Boehm.

Variante del método Delphi que promueve mayor interacción entre losparticipantes.

La idea fundamental es usar varios expertos que hacen estimacionesindependientes y luego convergen hacia una estimación única. Lospasos generales del método son:

1. Cada experto recibe las especificaciones del programa y unformulario de estimación.

2. Se reúnen a conversar sobre suposiciones, dudas, etc.

3. Cada miembro del equipo (por separado): a) lista las macro-tareasb) produce tres estimaciones: optimista (todo sucede según laplaneado), promedio (duración usual de la actividad), pesimista(falla todo aquello que se prevé que pueda fallar)

Estimación Delphi de Banda Ancha (cont.)

4. Las estimaciones son recogidas por un moderador quien tabula los resultados y obtiene un promedio de las estimaciones pesimista, optimista, mediana y un promedio general utilizando la fórmula de los tres puntos:

Promedio general: (optimista + 4* media + pesimista) /6

5. Se reúnen nuevamente, se entregan los resultados y discuten las tareas (si no hay consenso).

6. Se vuelve a la tercera etapa (nueva estimación).

Repita el Ejercicio – Estimación del Esfuerzo

Usando Wideband-Delphi, en grupos de 4-5 personas….

En grupo: Resuelvan dudas y hagan suposiciones sobre

la estimación (2 minutos)

Individual: Haga una lista de tareas y Vuelva a estimar el

tiempo (pesimista, optimista, medio) de desarrollo del

sistema de stock (3 minutos).

En grupo: Obtengan el promedio general según el paso 4.

Cada grupo entrega al profesor un papel anónimo con el

número total de Horas-Hombre (HH) del proyecto (2

minutos).

Consideraciones para la aplicación

del método Delphi de Banda Ancha

Las discusiones entre los expertos a menudo clarifican aspectos y producen cambios en las estimaciones para la etapa siguiente.

El método produce estimaciones bastante precisas…pero es caro y lento.

El costo depende de lo que a usted le cuesten los expertos… y de cuán alineados estén ellos respecto de sus estimaciones.

Usted podría aplicar esto en su organización, utilizando a sus colegas como posibles expertos.

Ojo: las estimaciones grupales heurísticas son

la base de los métodos ágiles de estimación!!!

• Planning Poker

• Team Sort (T-Shirt Sizing)

• One Point One Card (Lean)

Ver más info en

http://agile.dzone.com/articles/agile-estimation-practice

El principio de los modelos Paramétricos

Estos modelos utilizan fórmulas derivadas empíricamente para predecir los datos que se requieren para la

planificación del proyecto de software:

Agenda

• Introducción



• Método COCOMO




industria


Aproximaciones Paramétricas:

El Modelo COCOMO

Ejemplo 1: El modelo COCOMO simple relaciona el esfuerzo E (meses-hombre) con el tamaño S (MLOCS) y el tiempo con el esfuerzo de acuerdo a:

E (esfuerzo) = a * Sb

T (tiempo) = p * Et

Donde a, b, p y t son parámetros determinados por el tipo de software a ser desarrollado (están tabulados en bases a estudios estadísticos).

Para usar este modelo para predecir el esfuerzo en la etapa de captura de requisitos, necesitamos primero determinar (predecir) los parámetros y luego el tamaño del eventual sistema.

El Modelo COCOMO

Los modelos COCOMO están definidos para tres tipos de

proyectos de software:

(1) modo orgánico: proyectos relativamente pequeños y

sencillos en los que trabajan pequeños equipos, con buena

experiencia en la aplicación, sobre un conjunto de requisitos poco

rígidos;

(2) modo semiacoplado: proyectos intermedios (en tamaño

y complejidad) en los que equipos, con variados niveles de

experiencia, deben satisfacer requisitos poco o medio rígidos;

(3) modo empotrado: proyectos que deben ser

desarrollados en un conjunto de hardware, software y

restricciones operativas muy restringido.

El Modelo COCOMO

Modelos como COCOMO no consideran las

particularidades de cada equipo de desarrollo.

El modelo COCOMO Intermedio y Avanzado

introducen un multiplicador:

E (esfuerzo) = a * Sb * m(x)

T (tiempo) = p * Et

M(x) en un multiplicador que depende de 15 puntos

Mediciones de Software

Multiplicadores para COCOMO:

(1) Atributos del producto

• RELY: garantía de funcionamiento requerida al software

• DATA: tamaño de la base de datos

• CPLX: complejidad del producto

(2) Atributos del computador (Server)

• TIME: restricción de tiempos de ejecución (Tiempo de Servicio y Uptime)

• STOR: restricción del almacenamiento principal

• VIRT: volatilidad de la máquina virtual

• TURN: tiempo de respuesta del computador

(3) Atributos del personal

• ACAP: capacidad del analista

• AEXP: experiencia en la aplicación

• PCAP: capacidad del programador

• VEXP: experiencia en máquina virtual

• LEXP: experiencia en el lenguaje de programación

(4) Atributos del proyecto

• MODP: prácticas de programación modernas

• TOOL: utilización de herramientas software

• SCED: plan de desarrollo requerido

Agenda

• Introducción



• Método COCOMO




industria


Modelo de Puntos de Función

Albrecht (IBM, 1979) desarrolló la idea de Puntos de Función

(FPs).

La métrica de Puntos de Función sirve para establecer el

tamaño y complejidad de los sistemas informáticos basada

en la cantidad de funcionalidad requerida y entregada a los

usuarios” (ISO Bulletin May 2003).

Es uno de los modelos de predicción más populares y se

encuentran homologados con el ISO


The terms functional size (FS), functional size measurement

(FSM), and functional user requirements (FUR) are defined by

the ISO/IEC 14143-1:2007 Functional Size Measurement: Part 1

Definition of Concepts: (ISO/IEC, 2007)

ISO/IEC 14143-6:2006. Information technology—Software

measurement— Functional size measurement—Part 6: Guide

for use of ISO/IEC 14143 series and related International

Standards.l


Existen diferentes variantes de método:◦ ISO/IEC 20926:2003. IFPUG 4.1 Unadjusted functional size

measurement method. Es el mas conocido y utilizado en Estados

Unidos

◦ ISO/IEC 24570. NESMA -- Function Point Analysis. Estándar

definido para NEtherlands Software Metrics Users Association. Esta

es una pequeña variante del método del IFPUG

◦ ISO/IEC 20968:2002. Mk II Function Point Analysis. Desarrollado

por la United Kingdom Software MetricsAssociation, simplificando el

método y haciéndolo compatible con ideas de análisis y diseño

estructurado

◦ ISO/IEC 19761:2003. COSMIC-FFP - integrado por expertos de

Europa y Canadá, para adecuarlo a sistemas en tiempo real


La propuesta original identifica 5 tipos de funciones básicas

Funciones transaccionales:

Inputs: Entrada externa. Proceso para mantener uno o mas archivos lógicos internos. Cuenta las pantallas o formularios usados para captura. Ejemplos:

- Ingresar un nuevo producto

- Ingresar el pedido de un cliente

Outputs: Salida Externa. Proceso para presentar información al usuario que requiere operaciones adicionales al de solo recuperar datos . Cuenta pantallas o reportes que la aplicación produce. Ejemplos:

- Informe semanal de ventas

- Lista de pedidos pendientes por despachar

Consultas. Procesos para presentar información leída de uno o más grupos de datos (no requieren procesamiento adicional). Ejemplos:

- Consultar estado de un pedido

- Consultar existencia de un producto


La propuesta original identifica 5 tipos de funciones básicas

Funciones de Datos:

Archivo Lógico Interno: número de almacenamiento de datos mantenidos a través de alguna transacción. Ejemplos:

Entidad pedido

Entidad producto

Entidad detalle de pedidos

Interfaces. Archivo de interfaz externa. Grupos de datos relacionados y referenciados que son mantenidos por otro sistema (archivos compartidos de entrada o salida, parámetros, etc). Ejemplos:

Entidad Cliente (el cliente es consultado desde un sistema externo)

Interfaz con componente de mensajería (se invocan servicios de mensajería)


Número Tipo Peso Total

8 Inputs (EI) x4 32

12 Outputs (EO) x5 60

4 Consultas (EQ) x4 16

2 Archivos (ILF) x10 20

1 Interfaz (EIF) x7 7

Total Sin Ajustar: 135 PF

Factor de Complejidad: 1.06

Puntos de Función: 143 PF

El modelo define un peso diferente (PF) para cada tipo de función básica

Peso asignado a cada

tipo de función según

datos históricos

(viene dado por el modelo)

Valores estimados

según descripción

del sistema

Identificando la Función Básica

Tomado de S. E. Durán “Puntos por Función Una métrica

estándar para establecer el tamaño del software”. Boletín de

Política Informática Núm. 6, 2003

Factor de Complejidad

Para calcular el factor de complejidad se consideran 14

aspectos, otorgándosele a cada uno, una influencia de 0 a

5, generándose así un puntaje que va de 0 a 70.

El factor de complejidad estará dado por:

FC = 0.65 + 0.01 * Puntaje

El FC se mueve en el rango de 0.65 hasta 1.35.

Esto contempla hasta un 35% de aumento o reducción del

esfuerzo de desarrollo.

Factor de Complejidad

Los factores que influencian la complejidad son:

- Comunicaciones. - Funciones distribuidas.

- Objetivos de desempeño - Configuración. (sobrecarga).

- Tasa de transacciones. - Entrada de datos on-line

- Eficiencia para usuario. - Actualización en línea.

- Proceso complejo. - Reuso.

- Facilidad de instalación. - Facilidad de operación.

- Varios sitios. - Facilidad de mantención

Agenda

• Introducción



• Método COCOMO




industria


41

Componentes Estándares

El método de Componentes

Estándares: se basa en la

premisa de que nosotros no

reinventamos la rueda en

cada proyecto, sino que más

bien reproducimos nuestras

soluciones exitosas.

Ejemplos de Componentes Estándares

42

Ejemplos de Componentes

Estándares son:• Mantenedores (Operaciones

básicas sobre entidades de

referencia).

• Transacciones (Actualizaciones

sobre mas de una entidad, que contempla reglas de negocio)

• Menús de Navegación.

• Consultas de registros individuales

• Consultas de múltiples registros.

• Informes por Impresora.

• Procesos en Background.

• Notificaciones..

• Autorización / Autenticación

43


El método de Componentes Estándares se basa en mantener

una base de datos histórica con información de componentes

usados en proyectos previos, en varios niveles de abstracción:

subsistemas completos, módulos, interfaces de usuario, etc.

Se estima cuántos componentes estándares habrá, por cada

tipo, en el nuevo proyecto, utilizando puntos (estimado,

máximo y mínimo).

Se combina esto, ponderando 4 veces el más probable

(estimado) y una vez el máximo y el mínimo: (4*est + máx +

min) / 6.

Ejemplo:

Componente LOC min est max prob LOC

Módulo A 932 11 18 22 17.5 16310

Módulo B 543 35 40 44 39.8 21611

... ... ... ... ... ...

... ... ... ... ... ...

Total: 546359

… Se puede o no llevar esta estimación a líneas de código. 44


45

Componentes Estándares y FPs

El primer desafío es construir y mantener esta tabla:

Componente FP

Mantenedor………………….. 5

Transacciones…………………7

Menu/navegación…...…..….. 6

Consultas……………...…..… 2

Informes por Impresora.….... 2

Procesos en Background….. 8

Notificaciones………………. 2

Autorización / Autenticación. 3

46

Componentes Estándares y FPs

El segundo desafío es ponerle costos y tiempos:

Componente FP Costo Tiempo

Mantenedor………………… 5 M$ 750 100HH

Menu/navegación…...…….. 7 M$1050 140HH

Consultas……………...…… 2 M$ 300 40HH

Informes por

Impresora…………………...2 M$ 300 40HH

Procesos en Background… 8 M$1200 160HH

Tablas………………………. 1 M$ 150 20HH

Notificaciones……………… 2 M$ 300 40HH

Aut./Autenticación ………… 3 M$ 450 60HH

Ref: 1 PF = $150.000 = 20HH

Agenda

• Introducción



• Método COCOMO




industria


Aplicación de los métodos de estimación

• Cada uno de nosotros tiene que construir su propio sistema de

predicción de costos.

• Podemos inventar uno nuevo, o modificar o parametrizar alguno

ya existente.

• Lo importante es que el sistema de predicción nos represente

(tenga en cuenta nuestra realidad).

• También hay que identificar la precisión y el contexto en el cual

mi sistema arroja valores creíbles (tamaño y tipo de proyectos,

tamaño de grupos, etc.).

Validación de la Predicción

Validación de un Sistema de Predicción

• Se debe establecer empíricamente la precisión de la predicción (comparando el modelo con puntos conocidos).

• Involucra experimentación y testeo de la relación entre las variables observadas.

Validación de una Medida

• Se debe asegurar que la medida es una caracterización numérica adecuada del atributo en cuestión.

La Validación genera confianza en el sistema

¿Qué y cómo medir? He aquí el dilema…

Medir sólo aquellos aspectos del proceso o del producto, que son relevantes para mi.

¿Relevantes para qué?

• Mejorar mi proceso

• Mejorar mis productos

• Mejorar mis estimaciones

Guardar información para todo esto puede ser una tarea demasiado pesada, y podría entorpecer los desarrollos.

Medir y guardar la información, sólo si yo soy capaz de confiar en ella.

Las mediciones no deberían entorpecer el trabajo de la gente.

Dominio de Mediciones

¿Medir para Mejorar? o ¿para Estimar Mejor?

Medir cada fase (Análisis, Diseño, ….) => Medir para mejorar.

Medir a paquete completo (el proyecto como un todo) => Medir para estimar mejor.

52

¿Cómo saber cuánto le cuesta a mi equipo de trabajo implantar un FP?

1. Arme y valide su tabla de componentes estándares.

2. Busque en su información histórica (de los contratos): tiempo total y costo

total de un proyecto.

3. Haga una tabla con la distribución de componentes estándares que usted

tiene en cada proyecto:

Componente PF x Unidad Cant. PF Total

Mantenedor 5PF 20 100PF

Menu/Navegac. 7PF 3 21PF

Consultas 2PF 10 20PF

Reportes Impres. 2PF 3 6PF

Proc.Background 8PF 7 56PF

Tablas 1PF 20 20PF

TOTAL 223PF

Entendiendo la historia

53

¿Cómo saber cuánto le cuesta a mi organización implantar un FP?

4. Divida el costo total del proyecto por los PFs asociados al él. Por ejemplo:

Costo PF = $ 38.000.000 / 223 PF = $ 170.403

5. Divida la cantidad total de HH del proyecto por los PFs asociados al él. Por ejemplo:

Tiempo PF = 5.320HH / 223 PF = 23,9 HH

- Estos valores son referenciales y dependen del tamaño ycaracterísticas del equipo de trabajo.

- Cuanto más muestras estadísticas tenga, más ajustados estaránmis números.


54

¿Cómo saber cuál es la velocidad de desarrollo (aprox.) de un equipode mi organización?

En proyectos terminados, divida la cantidad total de HH del proyectopor el tiempo lineal de duración del proyecto (en horas). Por ejemplo:

Veloc. Desarr. = 5.320HH / 4.5 meses

= 5.320HH / 720 Horas = 7.4

NOTA: Este valor no tiene unidad, sin embargo puede entendersecomo si fuera “velocidad de desplazamiento” del proyecto.

- Estos valores también son referenciales, y deben manejarse dentrodel mismo contexto.


55


Para que los datos históricos sean válidos o tengan alguna utilidad:

1. El tamaño y composición del equipo de trabajo debe ser similar.

2. Si no es similar, debemos conocer la relación aproximada entre los escenarios anteriores y el actual.

3. La información histórica deberá ser creíble para las personas.

4. Deberá estar disponible (tal vez en carpetas) la información histórica detallada usada como base.

5. El producto a desarrollar deberá ser de un tipo, tamaño y complejidad acorde a nuestras experiencias previas.

56

Conclusiones Finales

• Los modelos de estimación son útiles pero deben ser adaptados a las condiciones de cada empresa / proyecto.

• Una de las competencias que debo adquirir como desarrollador es poder estimar el esfuerzo invertido en el desarrollo de una aplicación.

• Se necesita disciplina para crear información histórica de mi desempeño como desarrollador

57

Consideraciones Finales

• Es indispensable contar con los datos históricos deproyectos de la organización, sin embargo, es muyfrecuente encontrar que las compañías no facilitan elacceso a los mismos debido a que esta información escrítica.

• Se cuenta con algunas bases de datos internacionalesque guardan información histórica de proyectos y quepodrían servir como referentes para afinar el modelopropio.

• Es importante realizar estudios para caracterizar losproyectos de la industria de software latinoamericana

Agenda

• Introducción



• Método COCOMO




industria


• Ian Sommerville. Ingenieria De Software. 7ª Edición. México : Pearson

Educacion, 2005. Capítulo 25

• Nasir, M. Ahmad, F. “An Empirical Study to Investigate Software Estimation Trend in Organizations Targeting CMMI”. Proceedings of the 5th IEEE/ACIS

International Conference on Computer and Information Science and 1st

IEEE/ACIS International Workshop on Component-Based Software

Engineering, Software Architecture and Reuse, 2006.

• S.E. Durán Rubio. Puntos por Función. Una métrica estándar para

establecer el tamaño del software. Boletín de Política Informática Num 6,

2003.

• L. F. Capretz, V. Marza. Improving Effort Estimation by Voting Software EstimationModels. Advances in Software Engineering Volume 2009, Article

ID 829725, 8 pages

Bibliografía

• http://www.javiergarzas.com/2012/03/puntos-funcion.html

• http://www.ibm.com/developerworks/rational/library/edge/09/mar09/collaris_

dekker/

• http://www.ifpug.org/

• http://www.devdaily.com/FunctionPoints/

More…

software estimation (in spanish)

Documents

Transcript of software estimation (in spanish)