Estimacin de Costos y

Planificacin de Proyectos
Money, so they say / Is the root of all evil / Today Pink Floyd
"Oh dear! Oh dear! I shall be too late!" White Rabbit Alice In Wonderland

Universidad de los Andes

Demin Gutierrez
Febrero 2010

Cunto cuesta desarrollar

software?
Qu costos hay asociados
al desarrollo de un producto
de software?

Costo y el Esfuerzo

Costos de Hardware y Software

Costos de Viajes y Aprendizaje
Costos de Esfuerzo
Sueldos Ingenieros
Gastos de Seguros, Seguridad Social, etc,
Costos de Alquiler, Condominio, Luz,
Limpieza, Servicios Varios
Costos de Redes y Comunicacin
Costos de Recursos Compartidos,
Administracin, Salas de Reunin, etctera

Costo y el Esfuerzo
Para calcular los costos de un sistema es necesario
calcular, entre otras cosas su tamao y en
consecuencia el esfuerzo necesario para desarrollarlo

Cmo se puede estimar el

tamao y el esfuerzo necesario
para desarrollar un sistema?
Adems, es necesario considerar otros costos
indirectos asociados (gastos administrativos, de
mantenimiento, infraestructura, equipos, etctera)

mtricas?
cmo mido el
tamao de una
aplicacin?

Mtricas Qu son y por qu son necesarias?

Mtricas de Software: una mtrica es cualquier
medida o conjunto de medidas destinadas a conocer
o estimar el tamao u otra caracterstica de un
software o un sistema de informacin, generalmente
para realizar comparativas o para la planificacin de
proyectos de desarrollo
Miles de
Lneas de Cdigo
(KLOC)

Puntos de Funcin

Errores por
Caso de Uso

Nmero de
Clases e
Interfaces

Errores por
Lnea de Cdigo

Otras...

Fuente: http://es.wikipedia.org/wiki/Mtrica_(informtica)

Midiendo el Tamao de una

Aplicacin...
Midiendo la Productividad de un
Programador...

Cantidad de Lneas de Cdigo

Lneas de Cdigo
#include <iostream.h>
main() {
cout << "Hello World!" << endl;
return 0;
}

Hola Mundo en C++

(Aproximadamente 5
lneas de cdigo)

;; Hello World for the nasm Assembler (Linux)

SECTION .data
msg
db
"Hello, world!",0xa ;
len
equ
$ - msg
SECTION .text
global main
main:
mov
eax,4
; write system call
mov
ebx,1
; file (stdou)
mov
ecx,msg
; string
mov
edx,len
; strlen
int
0x80
; call kernel
mov
eax,1
; exit system call
mov
ebx,0
int
0x80
; call kernel

Hola Mundo en
Assembler
(Aproximadamente
15 lneas de cdigo)

Cantidad de Lneas de Cdigo

Un programa escrito en C++ tiene 500.000

lineas de cdigo (500 KLOC)
Un programa escrito en Assembler tiene
900.000 lineas de cdigo (900 KLOC)
Cul de los dos programas es ms grande?
Cul de los dos requiri ms esfuerzo?

Cantidad de Lneas de Cdigo

Un programador escribe unas 1000 lineas de

cdigo a la semana (en Assembler)
Otro programador escribe unas 500 lineas de
cdigo a la semana (en C++)
Cul de los dos programadores es el ms
productivo?

peor an...

Cantidad de Lneas de Cdigo

Un programador escribe unas 500 lineas de

cdigo a la semana (en C++)
Otro programador escribe unas 750 lineas de
cdigo a la semana (en C++)
Cul de los dos programadores es el ms
productivo?
Se pueden considerar otros factores para
comparar a los programadores?

por ejemplo...

Cantidad de Lneas de Cdigo

Un programador escribe unas 500 lineas de cdigo a la
semana (en C++)
(Y posteriormente, en su cdigo se encuentran 3 bugs)
(Escribe cdigo difcil de entender / ilegible)
Otro programador escribe unas 750 lineas de cdigo a la
semana (en C++)
(Y posteriormente, en su cdigo se encuentran 6 bugs)
(Escribe cdigo fcil de entender)
Otro programador escribe unas 1200 lineas de cdigo a la
semana (en C++)
(Y posteriormente, en su cdigo se encuentran 3 bugs)
(Escribe cdigo fcil de entender)

Cul de los dos programadores es el ms

productivo?

Las lneas de cdigo en si mismas

no son una mtrica adecuada para
medir el tamao de un sistema
Es necesaria una mtrica que sea
independiente de la tecnologa
utilizada

Puntos de Funcin
Es una mtrica que sirve para estimar el tamao de
una aplicacin de forma independiente del lenguaje de
programacin o las tecnologas utilizadas
Los requisitos funcionales del sistema son
identificados y clasificados dentro de cada uno de
los siguientes cinco tipos: entradas, salidas,
interacciones con el usuario, interfaces externas y
archivos utilizados por el sistema
La mtrica fue fundamentalmente diseada para
sistemas de informacin de gestin (de negocios,
empresariales, etctera)

Es decir:
Los puntos de funcin
miden el tamao de un
sistema en trminos de la
cantidad de funcionalidad
del sistema!

Puntos de Funcin
(5 Componentes Bsicos)
Entradas: IU -> (Archivos / BD / Otros Sistemas)
Salidas: (Archivos / BD / Otros Sistemas) -> IU
Interacciones / Consultas: IU -> Archivos / BD -> UI
Interfaces Externas: Integracin con otras
aplicaciones, bases de datos, etctera externas al
sistema
Archivos (Interfaces) Internos: Integracin con
fuentes de datos internas

Puntos de Funcin
(5 Componentes Bsicos)
Categora

Cantidad

Entradas

Salidas

Interacciones

Interfaces Externas

Archivos Internos

Se realiza una estimacin, pero...

De dnde salen estos nmeros?

Puntos de Funcin
(PF)
Cada uno de los elementos de las categoras
anteriores se vuelve a clasificar segn su complejidad
en simples, promedio y complejo, asignando pesos
adicionales que van de 3 a 15 (respectivamente)
Categora

Cantidad
Total

Simples

Promedio

Complejos

Puntos de
Funcin

Entradas

1x3

2x7

1x15

3+14+15=32

Salidas

3x3

0x7

0x15

9+0+0=9

Interacciones

2x3

0x7

2x15

6+30=36

Interfaces Externas

3x3

1x7

1x15

9+7+15=31

Archivos Internos

2x3

0x7

0x7

6+0+0=6

Total FP (Function Points):

114

Quin decide la complejidad de un PF?

Puntos de Funcin
(Factor Ambiental / Aspectos Generales)
Se toman en cuenta las caractersticas no funcionales
(Aspectos Generales del Sistema)
1
2
3
4
5
6
7
8
9
10
11
12
13
14

Factor Ambiental

Rating (0...5)

Se requiere comunicacin de datos?

Existen funciones o procedimientos distribuidos?
Es crtico el rendimiento?
Se ejecutar el sistema en un entorno operativo existente y
fuertemente utilizado? Hay restricciones de plataforma?
El sistema tendr una carga transaccional alta o baja?
Nivel de Disponibilidad
Eficiencia del Usuario Final Requerida (Usabilidad)
Actualizacin en Lnea
Complejidad del Procesamiento
El sistema debe estar diseado e implementado para ser
reutilizable?
El sistema debe ser diseado para ser fcil de instalar y de portar?
Facilidad de Uso
El sistema debe soportar mltiples instalaciones en diferentes
organizaciones?
El sistema debe estar diseado e implantado para facilitar cambios?
Total (N)

5
4
3
0
5
4
2
2
5
2
3
4
2
2
43

Quin decide el Rating de cada Factor?

Puntos de Funcin
(CAF)
Se calcula el CAF
(Complexity Adjustment Factor)

CAF = 0.65 + 0.01 * N

CAF = 0.65 + 0.01 * 43
CAF = 1.08
CAF puede variar entre 0.65
(todos los ratings en 0)
hasta 1.35
(todos los ratings en 5)

Puntos de Funcin
(AFP)
Se calcula el AFP
(Adjusted Funtion Points)

AFP = FP

* CAF

AFP = 114 * 1.08

AFP = 124

124 ... Bueno, y qu?

Puntos de Aplicacin
(SLOC/FP)
Lenguaje

SLOC/FP
(Source Lines Of Code) / (Function Points)

--

Avg

Med

Mn

Mx

ASP

56

50

32

106

Assembler

209

203

91

320

148

107

22

704

C++

59

53

20

178

C#

58

59

51

66

FoxPro

36

35

34

38

J2EE (Java)

57

50

50

67

Java

55

53

214

JavaScript

54

55

45

63

JSP

59

.NET

60

60

60

60

Perl

57

57

45

60

PL/SQL

47

39

16

78

Quin decide cuntas SLOC por PF se

van a tener por cada PF?
Fuente: http://www.qsm.com/resources/function-point-languages-table/index.html

Puntos de Funcin
Si estamos programando en Java

Es posible calcular la cantidad de lneas de

cdigo (Source Lines Of Code / SLOC) que
tendr la aplicacin:
SLOC = LANG_FACTOR * PF
SLOC = 55 * 124
SLOC = 6820

6820 ... y?
(Ser acertado este clculo?)

Puntos de Objeto / Puntos de Aplicacin

Son mtricas similares a los puntos de funcin pero adaptadas a
otros esquemas de desarrollo / tipos de sistemas
Puntos de Objeto
(Puntos de Aplicacin en COCOMO II):
Consideran:
1) Nmero de pantallas independientes que se despliegan
(Sencillas 1pto, medias 2pts, complejas 3pts)
2) Nmero de informes (reportes)
(Simples 2pts, moderados 5pts, complejos 8pts)
3) Mdulos en lenguajes imperativos (Java / C++) que deben
desarrollarse para implementar el cdigo de acceso a la BD
(10pts cada uno)

Puntos de Funcin

A lo largo del proceso se han

hecho las siguientes preguntas:
De dnde salen estos (valores de cada uno
de los componentes bsicos) nmeros?
Quin decide la complejidad de un PF?
Quin decide el Rating de cada Factor?
Quin decide cuntas SLOC por PF se van
a tener por cada PF?
Ser acertado el clculo de las lneas de
cdigo?

Puntos de Funcin

En general, para responder a las preguntas

anteriores se necesita:
Requisitos...
Que permitan darle valores a los componentes 5
bsicos
Un Experto (o un grupo de expertos)...
Que pueda sustentar cada una de los valores y pesos
seleccionados...

Y normalmente contar con un experto o un

grupo de expertos no siempre es
suficiente, ya que...

Puntos de Funcin

... muchos de los factores que afectan

estas preguntas dependen de la tecnologa
utilizada y de la experiencia y habilidades
del equipo de desarrollo
Estadsticas...
Informacin de proyectos anteriores que sirva como
base para realizar estimaciones confiables que tomen
en cuenta los factores organizacionables no
contemplados hasta los momentos

Puntos de Funcin

Bien, suponiendo que nuestros

clculos y estimaciones sean
correctas, nuestro sistema tiene
(tendr) 124 puntos de funcin y si lo
implementamos en Java tendr cerca
de 6820 lneas de cdigo...

Y qu???

Puntos de Funcin

La estrategia de PF se basa en la
experiencia del que calcule los PF
(fundamentalmente) y en el
conocimiento y grado de correcta
aplicacin de los criterios usados para
calcularlos

Puntos de Funcin

Adems...
Con los PF o la cantidad de lneas de
cdigo no resolvemos el problema
de determinar el costo de una
aplicacin...

Modelado Algortmico de Costos

Si se puede tener una estimacin del tamao de

la aplicacin, entonces es posible calcular el
esfuerzo requerido para desarrollar el sistema
con una frmula como la siguiente:
Esfuerzo=A * TamaoB * M

Donde el esfuerzo viene dado en P/M (Personas / Mes)

Modelado Algortmico de Costos

La unidad P/M es una unidad similar a las horas/hombre que
sirve para calcular el esfuerzo necesario para completar una
tarea
Si un proyecto toma X P/M esto significa que si se pudieran
contratar X personas (en circunstancias ideales) entonces el
proyecto se terminara en 1 mes...
...o bien, significa que si slo contratamos a una persona
entonces el proyecto se terminara en X meses
Es una unidad que permite tericamente determinar la cantidad
de personas que seran necesarias para terminar un proyecto en
cierto tiempo, o la cantidad de tiempo que sera necesario para
terminar el proyecto con cierta cantidad de personas

Modelado Algortmico de Costos

A
1,05

B
1,05

M
1,02

Esfuerzo=A * TamaoB * M
Tamao (PF)

Esfuerzo (PM)

Equipo de 5

Equipo de 10

En 6 meses

En 12 meses

PF

A*PF B*M

PM/5

PM/10

PM/6

PM/12

10

12,02

2,4

1,2

20

24,88

4,98

2,49

4,15

2,07

30

38,09

7,62

3,81

6,35

3,17

40

51,52

10,3

5,15

8,59

4,29

50

65,12

13,02

6,51

10,85

5,43

60

78,86

15,77

7,89

13,14

6,57

70

92,71

18,54

9,27

15,45

7,73

80

106,67

21,33

10,67

17,78

8,89

90

120,71

24,14

12,07

20,12

10,06

100

134,83

26,97

13,48

22,47

11,24

Modelado Algortmico de Costos

Recordar que la
relacin no es lineal
(A*TamaoB*M)

30

Tiempo / Tamao del Equipo

25

20

Equipo de 5
Equipo de 10
En 6 meses
En 12 meses

15

10

0
10

20

30

40

50

60

70

80

90

100

Tamao (PF)

Cuntas personas necesito para desarrollar

el proyecto en 15 das?

Modelado Algortmico de Costos

The Mythical
Man Month
En general, no es
posible forzar la
cantidad de
participantes en
un proyecto ms
all de cierto
punto para
acelerar la fecha
de entrega
Lo peor que se puede hacer para resolver retrasos existentes en un
proyecto es aadir mas personal al equipo de trabajo...
Ver: http://en.wikipedia.org/wiki/The_Mythical_Man-Month

COCOMO 81
(Constructive Cost Model)

COCOMO (Constructive Cost Model):

Es una estrategia basada en el modelado
algortmico de costos, desarrollada en 1981 por
Barry W. Boehm
Se bas en el estudio de 63 proyectos de
software desarrollados fundamentalmente
usando el modelo de proceso en cascada y que
oscilaban entre las 2.000 a las 100.000 lneas
de cdigo

COCOMO 81
(Constructive Cost Model)
Proyectos Simples: Aplicaciones bien entendidas desarrolladas
por equipos pequeos

PM=2.4 * KSLOC1.05 * M
Proyectos Moderados: Aplicaciones ms complejas en las que
el equipo de desarrollo tiene experiencia limitada en el tipo de
sistema en cuestin

PM=3.0 * KSLOC1.12 * M
Proyectos Empotrados: Proyectos complejos donde la
aplicacin es parte de un fuerte acoplamiento de software,
hardware y reglas operacionales

PM=3.6 * KSLOC1.20 * M

COCOMO 81
(Constructive Cost Model)
Atributos

Siglas

Valor
Muy bajo

Bajo

Nominal

Alto

Muy alto

Extra
alto

Atributos de software
Fiabilidad

RELY

0,75

0,88

1,15

1,4

--

Tamao de Base de datos

DATA

--

0,94

1,08

1,16

--

Complejidad

CPLX

0,7

0,85

1,15

1,3

1,65

Atributos de hardware
TIME

--

--

1,11

1,3

1,66

Restricciones de memoria virtual STOR

Volatilidad de la mquina virtual VIRT

--

--

1,06

1,21

1,56

--

0,87

1,15

1,3

--

TURN

--

0,87

1,07

1,15

--

Restricciones de tiempo de
ejecucin

Tiempo de respuesta

Atributos de personal
Capacidad de anlisis

ACAP

1,46

1,19

0,86

0,71

--

Experiencia en la aplicacin

AEXP

1,29

1,13

0,91

0,82

--

Calidad de los programadores

PCAP

1,42

1,17

0,86

0,7

--

Experiencia en la mquina
virtual
Experiencia
en el lenguaje

VEXP

1,21

1,1

0,9

--

--

LEXP

1,14

1,07

0,95

--

--

Atributos del proyecto

Tcnicas actualizadas de
programacin

MODP

1,24

1,1

0,91

0,82

--

Utilizacin de herramientas de
software

TOOL

1,24

1,1

0,91

0,83

--

Restricciones de tiempo de
desarrollo

SCED

1,23

1,08

1,04

1,1

--

Fuente: http://es.wikipedia.org/wiki/COCOMO

COCOMO 81
(Constructive Cost Model)

Modelo Bsico:
M=1
Modelo Intermedio:
M = RELY * DATA * CPLX * TIME * STOR *
VIRT * TURN * ACAP * AEXP * PCAP * VEXP *
LEXP * MODP * TOOL * SCED

COCOMO 81
(Constructive Cost Model)

COCOMO II (Constructive Cost Model):

Desarrollado por Barry Boehm y otros autores
en el ao 1997 (publicado en el ao 2000).
Incorpora a COCOMO 81 elementos adicionales
que permiten hacer mejores estimaciones en
funcin a las tcnicas y tecnologas de
desarrollo de software existentes en la
actualidad

COCOMO II
(Constructive Cost Model)

La pgina oficial de COCOMO II:

http://sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html

Herramienta para hacer estimacin con COCOMO y

con otros esquemas de Modelado Algortmico de
Costos:
http://www.softstarsystems.com/

Estimacin por Analoga

Proyecto

SLOC

Esfuerzo
(PM)

Alfa

12.100

24

Beta

27.200

Gamma
...

Costo
(BsF)

Pginas
Documentacin

Errores

Defectos

Personas

45.000

165

134

29

8,00

62

140.000

245

321

86

12,40

20.200

43

150.000

500

256

64

7,17

...

...

...

...

...

...

...

...

El costo se calcula por

comparacin con proyectos
similares en el mismo dominio
de aplicacin
(Mtricas)

Tiempo de
Desarrollo
(Meses)

Estimacin por Analoga

Ventajas:
Preciso si se dispone de datos previos
Desventajas:
Imposible de realizar si no se han desarrollado
proyectos comparables.
Es necesario mantener una base de datos con
la informacin necesaria.
Es necesario que las condiciones generales de
los proyectos a comparar sean similares.

Juicio Experto

Uno o ms expertos, tanto en

desarrollo de software como en el
dominio de la aplicacin usan su
experiencia para predecir los costos
del software.
Se realizan iteraciones hasta llegar a
un consenso.
Siguiente... El experto...

Juicio Experto

Costo=

=Happy Monkey

<== El Experto!!!

Juicio Experto

Costo = 200.000 BsF

De verdad, no es
broma...
Cmo lo hacen?

Juicio Experto
CU01
CU02

CU09

CU03

CU10

actor

CU04
actor

CU05

CU11

CU06
actor

CU07
CU12
CU08
actor

El costo se puede
estimar en funcin a
un grupo de
requisitos / casos de
uso / funcionalidad
inicial, la experiencia
de los expertos en el
dominio y la
experiencia de los
expertos en software

Juicio Experto
Tiempos / Costos de Desarrollo Sistema XXX
Costo / hora

Caso de uso / Concepto

Bs65,00

Tiempo (Das)

Costo

Arranque del proyecto

Levantamiento de Requerimientos /
Refinar casos de uso
Arquitectura del sistema / arranque del
proyecto

15

Bs7.800,00

10

Bs5.200,00

25

Bs13.000,00

2
2
1
3

Bs1.040,00
Bs1.040,00
Bs520,00
Bs1.560,00

Bs4.160,00

20
5

Bs10.400,00
Bs2.600,00

25

Bs13.000,00

20
0

Bs10.400,00
Bs0,00

Subtotal

20

Bs10.400,00

Total (Tiempo neto en das /

Costos)

78

Bs40.560,00

Subtotal
Recursos Logsticos

Flujo Incorporacin a Inventario

Flujo Desincorporacin a Inventario
Buscar Desincorporacin a Inventario
Inventario

Subtotal
Control de calidad / ajustes finales
Control de Calidad
Instalacin y puesta a punto final

Subtotal
Manuales / Entrenamiento
Desarrollo del manual de usuario
Entrenamiento

Una hoja de clculo es su mejor amigo al momento

de calcular costos...

Juicio Experto

Ventajas:
Suele ser muy barato.
Puede ser muy exacto si se cuenta con los
expertos adecuados.
Desventajas:
Imposible de realizar (o muy impreciso) si no se
cuenta con los expertos adecuados

Ley de Parkinson

Los costos del proyecto estn en funcin de los

recursos disponibles, utilizando todo el tiempo
permitido
(Normalmente esto no es una buena idea)
Ventajas:
No realiza presupuestos abultados
Desventajas:
El sistema normalmente no se termina
(O se desperdicia tiempo / recursos)

Pricing to Win

El costo del proyecto est en funcin de lo que

el cliente est dispuesto a pagar
(Normalmente esto no es una buena idea)
Ventajas:
La empresa de software consigue el contrato
(desarrollar un producto que vale 50.000 BsF
por tan slo 5.000 BsF)
Desventajas:
La probabilidad de que el cliente obtenga el
trabajo es mnima ya que los costos no reflejan
verdaderamente el trabajo requerido

Costos fijos
Concepto

Costos Fijos

Administradores
Limpieza

2.000,00 Incluye seguro y otros aspectos legales

600,00 Incluye seguro y otros aspectos legales

Alquiler

2.000,00

Papelera

1.000,00

Luz / Agua

400,00

Redes / Comunicacin

500,00

Condominio

200,00

TOTAL (A)

6.700,00

Sueldo Ingeniero (B)

Cantidad de Ingenieros (C)
Costos Fijos / Ingenieros (D)
Costo Mensual / Ingeniero (E)
Costo Hora/Hombre (F)

No olvide calcular y contemplar los

costos fijos de algn modo... y si
puede consiga un administrador que
se encargue de los detalles
financieros

4.000,00
15,00
446,67

A/C

4.446,67

B+D

26,47

E / (21 das) / (8 horas)

Recordar tambin los costos de depreciacin de equipos...

Requerimientos antes de costos?

Muchos Ingenieros de Software coinciden en:

...la necesidad de profundizar en la
especificacin de requerimientos (o tener algn
tipo de requerimientos) ANTES de ejecutar la
estimacin de plazos y esfuerzos del proyecto
de software...
Simplemente, cmo se puede calcular el costo
de un edificio sin saber cuantos pisos se van a
construir?

Planificacin y Gestin del

Proyecto?

Requerimientos antes de costos?

Es necesario realizar la planificacin y

calendarizacin del proyecto.
Esto se logra definiendo y desglosando las
tareas que hay que realizar para poder llevar
a trmino el proyecto.
Luego se define quin realizar las tareas,
qu recursos se necesitarn, cundo se
realizaran y cul ser el orden en el que se
realizaran.

Planificacin (Tareas)

Proceso
Tcnico 1

Proceso
Tcnico 2

Grupo de
Procesos

Proceso
Tcnico N
NO ENTRAR EN
MUCHO DETALE

Proceso A

...

...

Subproceso
A.1

Proceso B

...

...

Subproceso
A.n

Proceso C

...

Fuente: Adaptado de GRAY WATCH MTODO DE DESARROLLO DE SOFTWARE PARA APLICACIONES

EMPRESARIALES / Noviembre 2008

Planificacin (Hitos)

Estudio de
Viabilidad

Informe
de
Viabilidad

La definicin y
verificacin de
Hitos es una
forma de darle
visibilidad al
proceso

Perfilar
Requisitos

Definicin
de
Requisitos

Desarrollo de
Prototipos

Especificacin
de Requisitos

Especificacin
de
Requisitos

Prototipos

Informe
de
Evaluacin
de Prototipos

NO ENTRAR EN
MUCHO DETALE

Fuente: Adaptado de EPS Informtica UAM (T3: 18/19)

Requerimientos antes de costos?

El desglose de tareas se realiza en base al proceso (actividades
generales a realizar) y en base a las tareas especficas
resultantes de los requerimientos (funcionalidad)
NO ENTRAR EN
MUCHO DETALE

Requerimientos antes de costos?

Modelos Incrementales
(Modelo Incremental)

Requerimientos
y Funcionalidad

Planificar slo
pensando en los
requerimientos o
slo pensando en el
proceso
(especialmente esto
ltimo) usualmente
no es adecuado

R
ec

ur
so

hu
m
an

os

Mtodo / Proceso

La planificacin y el clculo de costos son

problemas muy complejos con muchas
variables, pero en general, las ms
importantes son los mtodos y procesos
usados, los requerimientos y los recursos
humanos

Otros aspectos de la gestin de proyectos?

Una reflexin final sobre lo profundo del abismo

Gestin de
Grupos
(eGroupware,
PHPGroupware)

Soporte
al Usuario
(Foros, Issue
Trackers y otras
herramientas

Discusiones
(Foros y otras
herramientas)
(mybb, phpbb,
fluxbb, SMF)

Gestin de
Cdigo Fuente
(SCM)
(CVS, SVN, Hg,
Git, etc)
Manejo de
Contenido
(CMS)
(Drupal,
Joomla, etc)
Base
de Conocimiento
(Wiki / Otras)
Dokuwiki,
Mediawiki,
etc

Gestin y
Asignacin de Tareas
(Redmine, dotProject,
eGroupware,
Trac)

Gestin
de Bugs
(FlySpray, Trac,
Jira, Mantis,
etc)
Gestin de
Documentos
(GoogleDocs,
KnowledgeTree,
eGroupWare,
Collanos)

Manejo de
Clientes
(CRS)

Gestin
gil de Proyectos
(SCRUM, XP,
Otros)
Gestin de
Recursos
Humanos

otras...
(Launchpad,
Atlassian (tools),
PHProjekt,
Gforge, Saros)

Algunas Herramientas de Planificacin

Planner (Libre/Escritorio):
http://live.gnome.org/Planner
Openproj (Libre/Escritorio):
http://openproj.org/
Dotproject (Libre/Web):
http://www.dotproject.net/
M$ Project (Propietario/Escritorio)
Otros...

Sobre el PMBok

Ms informacin en:
http://www.pmi.org/
(PMBok: Project Management Body of Knowledge)

Otras herramientas interesantes para revisar

http://marketplace.eclipse.org/content/saros-distributed-collaborative-editing-and-pair-programming

Ultimately, everyone wants estimates with the highest possibility or probability

of being correct. If an estimate has an equal amount of possibility to be early
as late, then this is the highest probability. Imagine a bell curve for a moment.
At the peak of the bell curve (the mean value) the most likely outcome. This
should be the estimate. If, on the other hand, an estimate has no probability of
being early, then it has just about zero percent possibility of actually
happening and about 100% probability of being late. In other words, the
estimate is to the far left side of the bell curve. A good estimate should have
an equal probability of being early or late.
When an estimate is based upon some quantitative process, it is easier to stand
behind the estimate. When the estimate is based upon a guess, there is more
likelihood to cave when pressure is applied. The reason for this is simply a lack
of confidence in the estimating process. The only thing to change about an
estimate is the inputs used to generate an estimate. If the estimate is too high,
then functionality needs to be reduced.

Esto est genial para futuros cursos

Fuente Reboot Rethink /
http://www.rebootrethink.com/forcesBehavior/miracleWorkers.php

The reason overtime is rewarded is because

software development managers have no other
metric in place to measure performance. These
same managers illogically conclude a person who
is working overtime is a dedicated, productive,
and hard working employee.

Crudo pero cierto en muchos

casos...
Recuerdan las 40 horas a la semana de
XP?
Fuente Reboot Rethink /
http://www.rebootrethink.com/forcesBehavior/workingOvertime.php

Estimates need to be non-negotiable. An estimate should be created using

a quantified method. That means there is some method to creating
estimates. Put some data into a formula and derive the result. The only
thing you should be willing to budge on is the inputs. There are several
inputs with an estimate including size of the project, deadlines, staff, so on
and so forth. Hence, if the estimate is too high, then one of the inputs
needs to be changed.
Unfortunately, what traditionally happens is that an estimate is nothing more
than a guess. The estimate has no substance at all; in other words, it is not
based upon historical performance or statistical modeling. Often when working
on a contract I ask the question, How did you come up with your estimate?
More often than not the person actually admits it was a guess. Another common
answer begins, based upon my vast experience as a software professional. In
other words, questioning the estimate is the same as questioning their integrity.
It is important for an estimator to be able to quantitatively explain how they
derived their estimate.
Fuente Reboot Rethink /
http://www.rebootrethink.com/forcesBehavior/nonNegotiable.php

Gracias

Gracias!