Planificacion y Estimacion

PLANIFICACIÓN Y

ESTIMACIÓN DE UN

DESARROLLO DE SOFTWARE

José Manuel Molina López

Catedrático de Ciencia de la Computación e Inteligencia Artificial

Contenido

Estimación de Esfuerzo

Planificación de tareas

Entregables del proyecto

2

Cómo evaluar el esfuerzo en el desarrollo: los

costes, los recursos y el tiempo.

Estimación del Esfuerzo en el

Desarrollo de Software 3

4

Problemática de la estimación.

Averiguar lo que costara de desarrollar una

aplicación.(meses-persona, ptas., …)

Momento en que se desea conocer el coste (gráfico

de Boehm)

Siempre se quiere muy pronto (Yourdon)

5

Precisión de las estimaciones en

función de la fase del proyecto.

0

0,5

1

1,5

2

2,5

3

3,5

4

4,5

Via

bili

da

d

Pla

nif

ica

ció

n

y r

eq

uis

ito

s

Dis

eñ

o

Ge

ne

ral

Dis

eñ

o

De

talla

do

De

sa

rro

llo y

tes

t

En

tre

ga

6

Proceso de Estimación propuesto.

Medir lo quequiere elusuario

Estimar loque Costara(esfuerzo)

Descomponerpor fases y

tareas

HistorialEmpresa

Especificación derequerimientos

Requisitos aCumplir

Medida de lo quequiere el usuario

Estimacióndel Esfuerzo

Tareas arealizar

Experiencia Individual

Experiencia de Empresa

7

Métodos utilizados para la estimación

de proyectos.

Basados en la experiencia.

Basado exclusivamente en los recursos.

Método basado exclusivamente en el mercado.

Basado en los componentes del producto o en el

proceso de desarrollo.

Métodos algorítmicos

8

Métodos basados exclusivamente en

la experiencia:

Juicio experto

Puro,

Delphi

Analogía

Distribución de la utilización de recursos en el ciclo

de vida

9

Juicio experto: Puro

Un experto estudia las

especificaciones y haces su

estimación.

Se basa fundamentalmente en

los conocimientos del experto.

Si desaparece el experto, la

empresa deja de estimar

10

Juicio experto: 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.

11

Método de trabajo del Wideband

Delphi

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.

12

Método de trabajo del Wideband Delphi

Juan *

Alicia *

José *

María *

Estimaciones

Juan *

Alicia *

José *

María *

Estimaciones

13

Analogía

Consiste en comparar las especificaciones de un proyecto, con las de otros proyectos.

Tamaño: ¿mayor o menor?

Complejidad: ¿Más complejo de lo usual?

Usuarios: Si hay más usuarios habrán más complicaciones.

Otros factores: Sistema Operativo, entornos (la primera vez más).

Hardware, ¿Es la primera vez que se va a utilizar?

Personal del proyecto, ¿nuevos en la organización?

14

2 m. ?

Estudio

Viabilidad

Planificación

y Requisitos Diseño

General Diseño

Detallado

Desarrollo Prueba

10% 17% 15% 15% 33% 10%

Distribución de la utilización de

recursos en el ciclo de vida

Usualmente las organizaciones tienen una

estructura de costes similar entre proyectos.

Si en un proyecto ya hemos realizado algunas

fases, es de esperar que los costes se distribuyan

de manera proporciona.

15

Método basado exclusivamente en los

recursos: Parkinson

En la estimación consiste en ver de cuanto

personal y durante cuanto tiempo se dispone

de el, haciendo esa estimación.

En la realización:

“El trabajo se expande hasta

consumir todos los recursos

disponibles”

(Ley de Parkinson)

16

Método basado exclusivamente en el

mercado: precio para vender.

Lo importante es conseguir el contrato.

El precio se fija en función de lo que creemos que esta dispuesto a pagar el cliente.

Si se usa en conjunción con otros

métodos puede ser aceptable,

para ajustar la oferta.

Peligro si es el único método

utilizado.

17

Basado en los componentes del

producto o proceso de desarrollo:

Bottom-up

Se descompone el proyecto en las unidades lo

menores posibles.

Se estima cada unidad y se calcula el coste total.

Top-Down

Se ve todo el proyecto, se descompone en grandes

bloques o fases.

Se estima el coste de cada componente.

18

Aplicación a

desarrollar

Coste

...

f(x) x

y

z

v u

Métodos algorítmicos

Se basan en la utilización de fórmulas que

aplicadas sobre modelos top-down o bottom-up

producen una estimación de coste del proyecto

19

0

2

4

6

8

10

12

14

16

0 2 4 6 8 10 12 14 16 18 20 22 24

Meses de Desarrollo

Esfuerzo

Asignado

Putnam

Relaciona cantidad de personas-

mes y la duración del proyecto.

Y=2Kate-at² Y = Personas-mes en cada punto

K = Esfuerzo total del proyecto,

(Área bajo la curva)

a = Cte. asociada a la aceleración

de entrada de personas en el

proyecto,

t = instante del tiempo.

20

COCOMO

Partimos de conocer el número de líneas que tendrá

la futura aplicación.

Orgánico, hay otros dos

MM-nominal = 3.2 (KLOC)1.5

T.desarrollo= 2.5 (MM)0.38

21

COCOMO

Determinar los multiplicadores del esfuerzo:

Tamaño B.D., experiencia analistas, herramientas, …

(15 en total, varían de 0.75-1.66)

Estimación esfuerzo con las correcciones.

Estimación de factores relacionados ($, duración

fases,…)

22

Métrica de los Puntos de Función

Es una métrica que se puede aplicar en las

primeras fases de desarrollo.

Se basa en características fundamentalmente

“Externas” de la aplicación a desarrollar.

Mide dos tipos de características:

Los elementos de función (entradas, salidas, ficheros,

etc.)

Los factores de Complejidad.

23

Estimación del Esfuerzo Requerido

Partimos de los datos históricos de la Organización

Esfuerzo = PFA * Promedio ( Lenguaje)

24

Estimación del Esfuerzo Requerido

Nombre Proyecto Puntos de Función Lenguaje Esfuerzo en horas

Sénia 200 COBOL 5.017

Mijares 300 PASCAL 5.410

Paláncia 150 PASCAL 2.569

Turia 375 4GL 3.011

Albufera 500 PASCAL 9.479

Magro 425 4GL 3.342

Cabriel 800 PASCAL 13.349

Júcar 180 PASCAL 2.800

Serpis 325 4GL 2.541

Montnegre 225 PASCAL 4.528

Vinalopó 310 PASCAL 5.628

Segura 470 COBOL 13.218

Definir tareas y su relación.

Planificación del proyecto 25

26

Planificar

Descomponer el esfuerzo estimado en tareas.

Para esto identificaremos:

Entregables del proyecto,

Fases del proyecto y

Tareas del proyecto.

Métodos de descomposición

Por PROCESOS

Diferentes fases conceptuales

¿Que?, ¿Como?, Realización, Pruebas ...

Por PRODUCTOS

Detectamos diferentes productos que conformaran el sistema que nos piden.

Ej.: Facturación, Control de Stocks, ...

27

Estará enfocado a un solo producto.

Razones:

Tamaño de un proyecto - riesgo de fracaso.

Costes de coordinación.

Actualmente de desarrollo incremental.

Lo lógico en que la “dirección estratégica” es quien se

encargue de identificar los productos más necesarios

para la empresa.

28

Descomposición en actividades del

proyecto (WBS).

Work Breakdown Structure (WBS)

método de representar de forma jerárquica los

componentes de un proceso o producto.

1.1. Estudiar

Sistema Actual

1.2. ide. nuevas

carácteristica

1.0. Especificar

necesidades

2.1. Estudiar

Procesos

2.2. Estudiar

Datos

2.0. Analizar

Contabilidad

3.1. Diseño

B.D

3.2. Diseño

Programas

3.0. Diseñar

Aplicación

4.1. Creación

Esquema

4.2. Codificación

Programas

4.0. Codificación

5.1. Prueba

Unidades

5.2. Prueba del

Sistema

5.0. Pruebas

0.0. Proyecto

Contabilidad

Representación en lista del WBS

0.Proyecto Contabilidad.

1.Especificar necesidades.

1.1.Estudiar Sistema Actual.

1.2.Añadir Nuevas

Características.

2.Analizar Contabilidad.

2.1.Estudiar Procesos.

2.2.Estudiar Datos.

3.Diseñar Aplicación.

3.1.Diseño B.D.

3.2.Diseño Programas.

4.Codificación.

4.1.Construcción del esquema.

4.2.Codificación de los

Programas

5.Pruebas

5.1.Prueba de Unidades

5.2.Prueba del Sistema

11. Liderazgo.

30

WBS

La numeración facilita la localización de las

tareas en el WBS.

Los nodos se leen como:

es un componente de …

forma parte de …

Construcción:

Nombrar el nodo inicial,

Poner en torno a 72 en cada nivel.

Las tareas son las hojas del árbol.

31

Ficha de Tarea

Especificación de tarea

Número: 3.1.

Nombre: Diseño B.D.

Descripción: Se diseñara la base de datos, partiendo del

modelo entidad-relación propuesto en el

análisis y con el objetivo de tener un sistema

funcionando sobre DB2.

Esfuerzo Estimado: 2 semanas/hombre

Entregables: Estructura de implementación de la B.D.

……………: ……………………………

32

Descomposición en fases del desarrollo

de un sistema.

Desde hace tiempo muchas empresas clasifican los

tipos de tareas que se realizan en un proyecto y

analizan el esfuerzo dedicado a cada una.

Veremos los ejemplos que da Martyn A. Ould, así

como un ejemplo de HP.

33

Reparto del Esfuerzo a mediados de

los ´70

24

46

5

5

20

0 10 20 30 40 50

Integración de sistema

Diseño del sistema

Dirección del proyecto

34

Reparto del Esfuerzo a principios de

los ´80

19

35

13

14

19

0 10 20 30 40


Diseño del sistema


11. Liderazgo. 35

Reparto del Esfuerzo a finales de los

´80

11

25

15

28

21

0 10 20 30


Diseño del sistema


36

Reparto del Esfuerzo en HP (´96)

5

7

8

11

19

2

209

0 5 10 15 20

Soporte

Manuales

Asegurar la calidad


Producción del sistema

Analisis y diseño

Definición del sistema


37

Tareas usuales de un proyecto

informático.

Estudio de viabilidad

Análisis

Diseño

Codificación

Pruebas

Instalación

Mantenimiento

38

Estudio de viabilidad:

Analizar el sistema propuesto

Escribir una descripción.

Definir y documentar posibles sistemas.

Analizar el coste de sistemas similares.

Estimar el tamaño del sistema, la planificación y los

costes. (tener en cuenta los entregables mas

importantes).

39


Definir cualitativa y cuantitativamente los beneficios

del sistema propuesto.

Realizar una planificación inicial del plazo de

recuperación de la inversión.

Realización de una estimación detallada de costes,

planificación, recursos, etc., de la siguiente fase

(Análisis).

40


Asignar director del proyecto.

Composición del documento de estudio de

viabilidad.

Presentación del documento de viabilidad a la

dirección para su aprobación.

41

Análisis: Captura de requisitos:

Definir el ámbito del sistema propuesto

Funciones, Dimensiones, Usuarios, Restricciones

Entrevista a todos los usuarios propuestos y

actuales:

Determinar:

Utilización del sistema actual

Deficiencias del sistema actual

Requisitos nuevos del sistema

42


(continua)

Documentar:

Descripción del sistema actual

Deficiencias del sistema actual

Producir el documento de requisitos del nuevo

sistema

Requisitos del usuario priorizados

Resoluciones sobre las deficiencias del sistema actual

43


(continua)

Producir una lista de los beneficios tangibles e

intangibles ( un refinamiento de la lista del estudio

de viabilidad)



(Especificación del sistema).

44


(continua)

Producir una estimación revisada de costes,

planificación, recursos, etc., para el resto del

proyecto.

Producir el documento de definición de requisitos;

esta tarea incluye la construcción de un prototipo.

45


(continua)

Realizar una revisión final del documento de

requisitos.

Tomar la decisión de continuar o no con el proyecto.

Definir las responsabilidades en la próxima fase

para el director, miembros del equipo de desarrollo

y otros.

46

Análisis: Especificación del sistema:

Definir el tipo de sistema propuesto: ¿Sistema

basado en transacciones? ¿Distribuido o

centralizado? ¿Estaciones de trabajo o terminales?

Esquematizar el sistema propuesto: transformar los

requerimientos del usuario de la fase anterior en

unas especificaciones funcionales.

47


Construir el diccionario de datos. Si existe DD de la

empresa, hacerlo compatible.

Revisar y expandir el análisis de coste beneficio.



(Diseño del sistema).

48


Producir una estimación revisada de costes para el

resto del proyecto.

Producir el documento de especificación del

sistema.

Realizar una revisión final del documento de

especificación del sistema.

49




para el director, miembros del equipo de desarrollo

y otros.

50

Diseño:

Producir el diseño global del sistema.

Localización de paquetes software.

Desarrollar un diseño detallado del sistema, por

alternativa de diseño planteada

Revisar y expandir el análisis de coste beneficio

para cada alternativa.

Evaluar las alternativas de diseño, para cada

alternativa.

51

Diseño:

Desarrollo de un plan de test del sistema:

Desarrollar un plan de test diferenciado para cada

alternativa.

Identificar las necesidades de entrenamiento y

documentación de los usuarios; definir las guías.

Producir el documento de diseño del sistema.

52

Diseño:

Realizar una revisión final del documento de diseño

del sistema.


Recomendar una alternativa.

53

Diseño:

Hacer recomendaciones sobre el nivel de

compromiso, si los hay, de programadores

subcontratados y otros.


para el director, miembros de los equipos de

programación y test, así como de otros implicados.

54

Codificación:

Producir un plan de trabajo:

Realización del diseño detallado de cada

programa.

Codificar, documentar y pasar los test en cada

programa.

Realizar el test de integración.

Terminar los manuales de operador y usuario, así

como los de formación.

55

Codificación:



(Prueba del sistema).

Producir una estimación revisada de costes,

planificación, recursos, etc., para el resto del

proyecto.

Confeccionar el documento de diseño de

programas y codificación.

56

Codificación:

Realizar revisiones del documento de diseño de

programas y codificación.

Obtener los resultados finales de la integración

completa del sistema y de las pruebas de

integración.


para el director, miembros del equipo de test, así

como de otros implicados.

57

Pruebas:

Realizar el test del sistema

Revisar la planificación de instalación.

Esbozar el plan ante caídas:

Desarrollar un acuerdo de nivel de servicio:

Producir los documentos de test en la entrega.

Revisión y aprobación de los documentos de

entrega.

58

Pruebas:

Aprobación de la documentación del sistema

Aprobación del plan de instalación.

Aprobación de los planes de contingencia,

recuperación y caídas

Finalización del sistema completamente probado.

59

Instalación:

Instalación del hardware y software nuevo.

Formar a los primeros usuarios y operadores.

Desarrollar los planes de contingencia, recuperación

y caída.

Desarrollar los procedimientos de mantenimiento y

versiones.

60

Instalación:

Establecer procedimientos para gestión versiones

Llevar a cabo cualquier conversión de datos

necesaria.

Llevar a cabo la instalación del sistema nuevo a

producción.

Comenzar el uso de los acuerdos de nivel de

servicio.

61

Instalación:

Planificar y programar las revisiones post-

instalación:

Llevar a cabo las revisiones post-instalación:

Establecer el calendario para otras revisiones post-

instalación si es necesario.

62

Mantenimiento:

Implementar los cambios del sistema:

Asegurarse de que el sistema continua solucionando

las necesidades de los usuarios.

Utilizar los procedimientos y contenido de las

revisiones post-instalación.

63

Reflexiones descomposición de

proyecto en tareas

Hacer las unidades de estimación que se aproximen

a la semana.

Tareas tan independientes como se pueda, es decir

no cortar procesos naturales.

Tener en cuenta comunicación entre personas.

Reutilizar código, ser conscientes de que también es

trabajo.

Qué material se debe entregar para cada fase

del proyecto

Entregables del proyecto 64

65

Entregables de un proyecto

informático.

Definición:

"Productos que, en un cierto estado, se intercambian entre los clientes y los desarrolladores a lo largo de la ejecución del proyecto informático".

Relativos:

Al objetivo.

A la gestión proyecto.

Deben ser:

Del conjunto de componentes que formaran el producto una vez finalizado el desarrollo.

Los medios para medir el progreso y la calidad del producto en desarrollo.

Los materiales necesarios para la siguiente etapa.

66

Entregables usuales. Estudio de

viabilidad:

Descripción breve del sistema propuesto y sus

características.

Descripción breve de las necesidades del negocio en el

sistema propuesto.

Propuesta de organización del equipo de desarrollo y

definición de responsabilidades.

Estudio de los costes, que contendrán estimaciones groseras

de la planificación y fechas, tentativas, de entrega de los

productos.

Estudio de los beneficios que producirá el sistema.

67

Entregables del Análisis:

Captura de requisitos:

Análisis del sistema actual (si existe).

Requisitos nuevos de los usuarios.

Descripción del sistema propuesto.

Especificación del sistema

Descripción del sistema (DFDs, etc.).

Requisitos de datos.

Requisitos de telecomunicaciones.

Requisitos de hardware.

Plan de pruebas de integración.

68

Entregables del Diseño:

Descripción detallada del sistema, contendrá:

Programas, módulos reutilizables y objetos.

Ficheros y bases de datos.

Transacciones

Diccionario de datos

Procedimientos

Carga del sistema y tiempos de respuesta

Interfaces, tanto humanos como de máquinas.

69

Entregables del Diseño:

Descripción de los controles del sistema propuestos.

Diseños alternativos recomendados.

Estándares de programación y diseño de programas,

recomendados.

Técnicas de implementación recomendadas:

codificación propia, compra de paquetes, contratación

externa, etc.

Plan de pruebas de programas.

70

Entregables de la Codificación:

Documentos del diseño final del sistema y de cada

programa.

Diagramas definitivos del sistema y de los

programas.

Descripción detallada de la lógica de cada

programa.

Descripción de las Entradas y Salidas (ficheros,

pantallas, listados, etc.).

71


Listado de los programas, conteniendo comentarios.

Cadenas de ejecución si es necesario (JCL, scripts,

etc.).

Resultado de las pruebas de cada unidad.

Resultado de las pruebas de cada programa.

72


Resultado de las pruebas de la integración.

Guía para los operadores del sistema.

Programa de entrenamiento de los operadores.

Manual de usuario del sistema.

73

Entregables de las Pruebas:

Plan de pruebas del sistema (actualizado).

Informe de los resultados de las pruebas.

Descripción de las pruebas, el resultado esperado,

resultado obtenido y acciones a tomar para corregir

las desviaciones.

Resultados de las pruebas a la documentación.

74

Entregables de la Instalación:

Planes detallados de contingencias de explotación,

caídas del sistema y recuperación.

Plan de revisión post-instalación.

Informe de la instalación.

Carta de aceptación del sistema.

75

Entregables del Mantenimiento:

Listado de fallos detectados en el sistema.

Listado de mejoras solicitadas por los usuarios (si no

dan lugar a nuevos proyectos).

Traza detallada de los cambios realizados en el

sistema.

Actas de las revisiones regulares del sistema y

aceptación de los niveles de soporte.

Qué recursos y cómo se asignan por tarea los

mismos

Asignación de recursos 76

77

Asignación de Recursos

Consiste en asociar a cada una de las tareas, en el

proyecto, las personas y materiales necesarios para

que estas se pueda realizar.

Los recursos humanos constituyen el componente

económico mas importante de los Proyectos

Informáticos. Por encima de los recursos físicos (HW

e Instalaciones)

78

¿Recursos Humanos?

Las personas no son recursos humanos. Son

individuos vivos, con todo su derecho a ser

diferentes.

las empresas del futuro

Tendrán en el conocimiento su principal recurso,

Organizaciones compuestas fundamentalmente por

especialistas que trabajaran de acuerdo a las

informaciones que reciban.

Otros Recursos Importantes

HARDWARE

Los costes del Hw

bajan de forma

continua.

La utilización de

recursos Hw es función

de la cantidad de

personas asignadas al

proyecto

CONSULTORES

Son profesionales externos.

Soporte a tareas donde la empresa no tiene experiencia.

Pueden llegar a suponer un coste similar al de los desarrolladores, en proyectos complejos.

80

Otro recurso importante:

Los clientes y usuarios

Están presentes en todas las fases del proyecto,

fundamentalmente en:

las primeras (análisis) y

últimas (pruebas).

No suelen tenerse en cuenta a la hora de la

planificación, se ve cuando:

Se quejan: “Con el tiempo que...”

Cuando un usuario se excusa de la asistencia a una

reunión…

81

Además de las tareas del proyecto.

Para que un grupo haga su trabajo, es necesario:

tareas en si mismas.

tareas de mantenimiento del equipo:

mantener su cohesión, su motivación y su voluntad general

de dedicarse a la tarea.

Satisfacer las necesidades individuales:

lo que ayuda al individuo a sentirse parte del grupo y le

capacita para realizar su aportación máxima.

82

No forzar las planificaciones por bajo

de lo previsible.

Condenan al proyecto independientemente de la

calidad del personal o de la disponibilidad de

herramientas, lenguajes y procesos.

Si se comprime la duración o el presupuesto

el personal no será eficientemente,

no se forzara si ve imposible alcanzar la meta.

Peor aun, cuando los retrasos empiecen,

Sufrirá la moral y el proyecto probablemente cueste más que

de haberse hecho de forma razonable.

83

Determinación del plazo de entrega

de la aplicación.

Puntos de vista:

Del informático:

Aplicación es el objetivo de la creación.

Proyecto es el medio.

Del Usuario y cliente

Aplicación: “Es lo que me hace falta para poder alcanzar

mis objetivos empresariales”

Proyecto: “Un mal trago que hay que pasar”

84

Determinación del plazo de entrega

de la aplicación.

Equilibrio:

Cuanto tiempo y $ consumirá

este proyecto,

Cuando deberá estar disponible

para el usuario.

85

Límites duración del proyecto y

Asignación de recursos

Un proyecto de 165 meses/hombre

Una Persona en 15 AÑOS

Ya no hará falta

Costes de oportunidad

Obsoleto para cuando lo entreguemos

Puede hacer falta especialistas

3.300 Personas en un día

Orden de las tareas

86

La duración de los P.I. se deben ajustar

a los aspectos:

...del negocio,

...técnicos del desarrollo

cantidad máxima de recursos en cada tarea,

...de gestión

equipo de desarrollo lo más pequeño posible,

de evitar problemas de comunicación y coordinación.

87

Determinación del plazo.

La negociación.

Selección de una alternativa

Método empírico de Putnam y Norden.

88

La negociación.

Esta bien, espíritu comercial, peligrosa si: Se comienza a negociar sin tener claras las especificaciones

del cliente.

El usuario con ligeras nociones de las técnicas de desarrollo actuales.

El usuario tiene la necesidad de disponer de la aplicación lo antes posible.

El director del CPD o jefe de proyecto tiene que negociar con un usuario de mayor nivel jerárquico.

El trabajo usual de muchos usuarios es el de contratar servicios a empresas externas y saben que siempre hay un margen que se puede disminuir.

89

La negociación de los plazos, lleva a:

Fuertes niveles de compromiso personal del jefe del

proyecto,

Escasa participación en la fijación de plazos de los

que van a desarrollar la aplicación.

El marco es el ideal para el fracaso:

El desconocimiento de las necesidades del usuario suele

hacer que se subestimen

El compromiso unilateral del jefe, en estas condiciones,

difícilmente será respaldado por sus subordinados.

Selección de una alternativa.

Quiero pasar una tarde divertida...

… Cada persona tiene sus gustos ...

Y se puede ofrecer

Distintos Diseños…

Distintas planificaciones para un diseño dado.

Distintos enfoques al desarrollo:

Desarrollo propio,

Outsourcing o subcontratación,

Compra de paquetes

91

Esfuerzo t Kate at 22

Método empírico de Putnam y Norden.

La cantidad de gente que hace falta a lo largo de

un proyecto depende del instante en que nos

encontremos.

92

Curva para un proyecto de 165 meses

hombre

0

5

10

15

0 3 6 9 12 15 18 21 24

Meses de Desarrollo

Esfuerzo

Asignado

Esfuerzo t Kate at 22

93

0

5

10

15

0 3 6 9 12 15 18 21 24

Meses de Desarrollo

Pers

on

as

94

Podemos adaptarnos a la cantidad

de gente disponible.

0

10

20

30

40

50

60

70

80

1 713 19 25 31 37 43 49 55 61 67 73 79

Meses de realización

Pers

on

al asig

nad

o

95

Boehm, definiendo la región

imposible,...

en cuanto a la duración de un proyecto, en

concreto, indica que desde la especificación a la

entrega de un producto informático, no puede

pasar menos de:

Y el 99% de los proyectos cumplen esto.

315,2 sPersonasMeT

96

Tipos de recursos usuales.

Trabajo

Lugar de trabajo

Equipamiento

Material básico para el desarrollo

Material fungible

97

Trabajo

Equipo de desarrollo

Soporte al desarrollo

Clientes y usuarios

98

Lugar de trabajo

Salas de reuniones

Entorno de desarrollo

Silenciosos

Tranquilos

Zonas para recogida de datos

Equipamiento

Mobiliario de oficina

Ordenadores

Material para

presentaciones

100

Material básico para el desarrollo

S.O., Lenguajes de desarrollo, herramientas de

desarrollo (case).

Manuales del software: iniciación, manual de

usuario, librerías, etc..

Libros con referencia a técnicas de desarrollo

101

Material fungible

Material de escritorio: bolígrafos, clips, grapas

El material necesario para los equipos: tinta o toner

de impresora

102

Duración de las tareas

Recursos (esfuerzo) está en relación con la

duración

Esfuerzo y duración de las tareas

Asignación de personas a tareas

Tipo y duración de las tareas en función de la

cantidad de personas asignadas

103

Esfuerzo y duración de las tareas

Esfuerzo Duración Recursos

Asignados

10 días 5 semanas 2 días/semana

10 días 1 semana 2 personas a

Tiempo

Completo

104

Esfuerzo y duración de las tareas: las

interferencias

Repetición de trabajos o corrección defectos

Vacaciones, fiestas, fiestas locales, etc.

Consultas de otros equipos de la empresa

Papeleos que deberían haber sido delegados.

Falta de formación en el personal del proyecto.

105

Esfuerzo y duración de las tareas: las

interferencias

Falta de reuniones del equipo.

Interrupciones de todo tipo, telefónicas etc..

Tiempo de espera en reuniones.

Tiempo que tarda el personal en cambiar de tarea,

no se puede esperar que sea instantáneo.

Puede suponer entre un 30% y un 50%

106

Cuando más experiencia las más

afectadas

Deben enseñar y adiestrar al personal del proyecto

en temas no previstos;

Son consultados por otros proyectos, y

Se les suele pedir que asistan a reuniones,

presentaciones, ... Que en principio no tienen

relación con el proyecto actual.

107


Es mejor disponer de un equipo pequeño de buenos profesionales

Con la gente correcta aun con herramientas, lenguajes y procesos insuficientes, pueden tener éxito.

Lo contrario parece imposible.

Pero:

Si confiamos todo a unas pocas personas

¿Qué ocurre si se van?

Hay que equilibrar el personal.

108

Relación empleado y tarea, inersan

estos aspectos:

El cognitivo (KAS), la capacidad técnica: (Knowlegue, Abilities, Skils)

Los conocimientos para realizar la tarea

La capacidad de realizarla, y

La experiencia sobre la materia.

El conativo (MAC), la voluntad: (motivation atachement confidence)

La motivación de la persona,

El compromiso que asumirá, y

La seguridad que tiene en si para realizarla

109


Puede realizar el trabajo y quiere realizarlo.

Puede realizar el trabajo y esta accede a realizarlo -> hay que motivar!!!!!

Puede realizar el trabajo pero no esta dispuesto a realizarlo -> estamos en la situación siguiente???

Puede ser formado para realizar el trabajo.

Gastar dinero para la formación.

Modificar la programación con la formación.

Estar dispuestos a la sobrecarga que suponga.

Afrontar el riesgo de que no funcione bien

No puede realizar el trabajo.

110

Según la cantidad de personas

asignadas.

A una tarea podemos asignar una cantidad

determinada de personas.

La proporción entre cantidad de personas

asignadas a una tarea y el esfuerzo, no tienen

relaciones lineales.

Asignar más gente a un proyecto a mitad de éste

no reduce necesariamente su duración.

111

Según la cantidad de personas

asignadas.

1) las tareas se pueden repartir de forma perfecta, sin

necesidad de comunicación entre las personas.

2) la tarea no se puede partir (para que nazca un niño se

requieren nueve meses, no importa cuantas mujeres se

asignen).

3) la tarea se puede partir, pero se requiere comunicación

entre las personas.

4) la tarea se puede partir pero las interrelaciones son tan

complejas que cuesta más tiempo realizar la tarea con muchas

personas.

112

1) las tareas se pueden repartir de

forma perfecta.

0

1

2

3

4

5

6

7

8

9

0 1 2 3 4 5 6 7 8

Personas

Duració

n

113

2) la tarea no se puede partir.

0

1

2

3

4

5

6

7

8

9

0 1 2 3 4 5 6 7 8

Personas

Duració

n

114

3) Se requiere comunicación entre las

personas.

0

1

2

3

4

5

6

7

8

9

0 1 2 3 4 5 6 7 8

Personas

Duració

n

6. Asignación de Recursos en los

Proyectos Informáticos.

115

4) interrelaciones tan complejas que cuesta

más tiempo.

0

1

2

3

4

5

6

7

8

9

0 1 2 3 4 5 6 7 8

Personas

Duració

n

116

Una vez asignadas las tareas

tendremos

TAREAS DEL PROYECTO

Recursos

Humanos

Asignación

117

Asignación consistente de las tareas.

distinta visión del director y los empleados es sobre

el trabajo.

Asignar las tareas a quienes quieren.

Trabajar las asignaciones con los empleados.

Hacer una lista de objetivos por trabajador.

Ir haciendo reuniones hasta que este clara la

asignación.

118

Consideraciones finales.

Coste mínimo de desarrollo

En tiempo (especialistas ya formados en cada área de

trabajo. Tantos como se pueda).

En dinero (utilizar el personal necesario para que se

lleven a cabo las tareas y que ya conozcan las áreas

que se les asignan).

119

Consideraciones finales.

Coste mínimo a largo plazo (pensar en el

mantenimiento y otros proyectos)

Hacer que el personal menos experimentado trabaje

en el desarrollo, dando formación en caso necesario.

Hacer que el personal se sienta promocionado.

Detectar los objetivos de cada empleado y hacer que

cada nuevo proyecto sea un paso en la consecución de

estos.

120

Combine recordar, al asignar personas

a tareas, que:

Que la productividad de los programadores es muy

variable, es habitual la relación 1:5.

En un estudio se dieron diferencias de 1 a 26 en los

niveles de productividad.

En las tareas criticas convendrá poner al personal

con mayor experiencia y reputación, ya que se

espera sean más productivos.

121

Ficha de Tarea

Especificación de tarea

Número: 3.1.

Nombre: Diseño B.D.

Descripción: Se diseñara la base ...

Esfuerzo Estimado: 2 semanas/hombre

Personas: 1 Diseñador …

Recursos: Sala de reuniones …

Duración: 2 semanas

Entregables: Estructura de implementación de la B.D.

…: …

Planificacion y Estimacion

Documents

Transcript of Planificacion y Estimacion