Planificacion y Estimacion
-
Upload
pablocbranca -
Category
Documents
-
view
145 -
download
0
description
Transcript of 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
Integración de sistema
Diseño del sistema
Dirección del proyecto
11. Liderazgo. 35
Reparto del Esfuerzo a finales de los
´80
11
25
15
28
21
0 10 20 30
Integración de sistema
Diseño del sistema
Dirección del proyecto
36
Reparto del Esfuerzo en HP (´96)
5
7
8
11
19
2
209
0 5 10 15 20
Soporte
Manuales
Asegurar la calidad
Integración de sistema
Producción del sistema
Analisis y diseño
Definición del sistema
Dirección del proyecto
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
Estudio de viabilidad:
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
Estudio de viabilidad:
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
Análisis: Captura de requisitos:
(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
Análisis: Captura de requisitos:
(continua)
Producir una lista de los beneficios tangibles e
intangibles ( un refinamiento de la lista del estudio
de viabilidad)
Realización de una estimación detallada de costes,
planificación, recursos, etc., de la siguiente fase
(Especificación del sistema).
44
Análisis: Captura de requisitos:
(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
Análisis: Captura de requisitos:
(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
Análisis: Especificación del sistema:
Construir el diccionario de datos. Si existe DD de la
empresa, hacerlo compatible.
Revisar y expandir el análisis de coste beneficio.
Realización de una estimación detallada de costes,
planificación, recursos, etc., de la siguiente fase
(Diseño del sistema).
48
Análisis: Especificación del sistema:
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
Análisis: Especificación del sistema:
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.
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.
Tomar la decisión de continuar o no con el proyecto.
Recomendar una alternativa.
53
Diseño:
Hacer recomendaciones sobre el nivel de
compromiso, si los hay, de programadores
subcontratados y otros.
Definir las responsabilidades en la próxima fase
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:
Realización de una estimación detallada de costes,
planificación, recursos, etc., de la siguiente fase
(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.
Definir las responsabilidades en la próxima fase
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
Entregables de la Codificación:
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
Entregables de la Codificación:
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
Asignación de personas a tareas
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
Asignación de personas a tareas
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.
…: …