Gestion_de_Proyectos.ppt

Gestión de Proyectos
Profesores: L. Luís Duran,
Febrero 2006

Copyright © 2003 Electronic Data Systems Corporation. All rights reserved
•A. Introducción Gestión Proyectos Informáticos
•B. Creación del Plan de Proyecto
•C. Ciclo de vida en la Gestión del Proyecto
•D. Gestión de la Calidad
Gestión de Proyectos Informáticos
Programa

APARTADO A
Introducción Gestión Proyectos Informáticos

4
ÍNDICE
A. Introducción a la Gestión de Proyectos Informáticos
• A.1. Objetivo de la gestión
• A.2. Áreas a gestionar
• A.3. Elementos de la gestión
• Objetivo: obtener una visión básica de los
temas fundamentales a tratar en este módulo
• Finalidad: evitar asociar gestión de un
proyecto informático a la gestión del
cronograma de un proyecto

A.1. Objetivo de la gestión - ¿Cuál? (1/2)
A. Introducción Gestión Proyectos
COSTE
TIEMPO
REQUISITOS
OBJETIVO
COSTE
TIEMPO
REQUISITOS
OBJETIVO
COSTE
TIEMPO
REQUISITOS
OBJETIVO

• OBJETIVO: garantizar la satisfacción del cliente y
darle una solución.
• No sólo es necesario aportarle una solución sino
que ésta solución debe implantarse en un tiempo y
con unos costes acordados.
• Para asegurar estos plazos y costes se realizan
una serie de actividades relacionadas con la
gestión del proyecto.
A.1. Objetivo de la gestión - ¿Cuál? (2/2)

7
A.2. Áreas a gestionar - ¿Cómo?
Personas
Procesos
Tecnología

8
A.2. Área a gestionar - Procesos
• Evitar siempre la reinvención de la rueda, tanto en métodos como en
herramientas (no es recomendable ‘’la improvisación’’).
• Analizadas las características del proyecto, los principales procesos a
considerar son casi siempre:
– Como validamos el cumplimiento de expectativas de nuestro
“cliente”
– Como vamos a gestionar los riesgos del proyecto
– Como vamos a planificar (definición y seguimiento semanal)
– Asociado a la Ingeniería del Software, que ciclo de vida debe ser
aplicado, centrándose en dos aspectos fundamentales: La obtención
de requerimientos, y la posterior validación en todo el ciclo de vida
de que el software cumple con estos requerimientos
(revisiones/pruebas y gestión de la configuración)
– Como se van a gestionar los costes, no sólo directos, sino también
los indirectos (puesto de trabajo, recursos administrativos,
buenos/malos proveedor, garantías, formación…).

9
A.2. Área a gestionar - Personas
• Una de las principales causas de proyectos fracasados es la mala
definición de roles y responsabilidades, tanto a nivel interno como del
cliente/usuario, que afloran de manera indirecta (mala valoración,
pruebas defectuosas,..)
• Una buena gestión del proyecto ha de permitir definir, y mantener:
– Responsabilidades a nivel de cliente/usuario final:
• ¿Van a haber resistencias al cambio, o simplemente
boicoteadores?
• ¿Quien define los requisitos es quien va a usar la
aplicación?
• ¿Existen recursos humanos de parte del
cliente/organización para abordar el proyecto?
– Responsabilidades y funciones del equipo de trabajo:
• Saber determinar el nivel de compromiso con el proyecto
con relación a la criticidad del rol de cada persona.
• Fijar diferencial capacidades (técnicas y de gestión) con
relación a las necesidades del proyecto.

10
A.2. Área a gestionar - Tecnología
• Tal vez los aspectos tecnológicos sean los más directamente
gestionables por parte del Gestor de Proyectos.
• De todas maneras, no perder de vista el impacto en:
– Procesos: Riesgos tecnológicos, impacto en ciclo de vida del
software, costes/ahorros,…
– Personas: Formación usuarios finales / no disponibilidad de
técnicos capacitados.
• La tecnología no sólo debe contemplarse como un elemento a
aplicar en el producto objeto del proyecto, sino sobre todo, en la
mejora de la productividad del propio proyecto, tanto a corto como a
medio plazo:
– Gestión documental
– Herramientas CASE
– Planificadores/Simuladores
– Herramientas gestión configuración
– E-Learning
– Teleworking

11
A.3 Elementos de la Gestión
Comunica-
ciones
Calidad Alcance
Planificación
Riesgo
Finanzas
Contrato
Recursos

12
A.3. Elementos de la Gestión
• TRABAJO EN GRUPO - identificación de factores de éxito

APARTADO B
Creación del Plan de Proyecto

14
B. Creación del Plan de Proyecto
• B.0. Componentes del Plan de Proyecto
• B.1. Definición del ámbito del Proyecto, y gestión
de expectativas y requerimientos
• B.2. Gestión Riesgos
• B.3. Gestión Calidad
• B.4. Gestión Planificación
• B.5. Gestión Equipo Trabajo
• B.6. Gestión Comunicaiones
• B.7. Gestión Económíca
Índice
• Objetivo: conocer los diferentes componentes de un Plan
de Proyecto, así como sus características principales
• Finalidad: ser conscientes de que antes de iniciar la
ejecución del proyecto es necesario haber creado la
versión inicial del Plan, y que dicho Plan es la herramienta
para la gestión del mismo a lo largo de su ciclo de vida.

15
B.0. Componentes del Plan de Proyecto (1/1)
• El Plan de Proyecto es un conjunto de planes para cada elemento a gestionar,
controlados cada uno bajo su propio “versionado”, cada plan tiene anexados
un conjunto de documentos que demuestran la aplicación del mismo.
Comunica-
ciones
Calidad Alcance
Planificación
Riesgo
Finanzas
Contrato
Recursos

16
B.1. Definición del ámbito del Proyecto (1/6)
• Determinar la dimensión de los tres ejes que definen el objetivo de un
proyecto. Se debe tomar como punto de partida el contrato con el
Cliente (si existe), o en su defecto el acta de la reunión de
lanzamiento/aprobación del proyecto.
COSTE
TIEMPO
REQUISITOS
OBJETIVO
• Han de quedar perfectamente identificados
los objetivos de negocio que han decidido la
realización de dicho proyecto:
– Expectativas y Requisitos del cliente
– Fecha límite de implantación asociada a motivos
de negocio.
– Presupuesto aprobado para este proyecto.
• Sobre todo, objetivos que no son misión de este
proyecto su consecución

17
B.1. Ámbito del proyecto (2/6)
• Ejemplos:
• OBJETIVOS de negocio para realizar el proyecto
– Obtener una solución orientada única y exclusivamente a los requisitos
del “cliente”
– Facilitar el acceso a la información
– Unificar y racionalizar la información
– Mejorar el rendimiento del sistema
• NO son Objetivos
– Modelo de datos y acceso a la información muy costoso
– No estandarización de los procesos

18
B.1. Gestión Expectativas (3/6)
• Quien tiene la única visión válida de si un proyecto ha sido exitoso o no, es el
“cliente/s destinatario/s” (muchas veces no coincide con el usuario final)
• En consecuencia, es fundamental que el Gestor del Proyecto tenga
explicitadas, dentro de lo posible, las expectativas del “cliente/s”.
• Para ello debería ser posible el crear una matriz donde:
– Definir cada expectativa en términos de negocio del “cliente”
– Identificar la prioridad de su cumplimiento
– Identificar el parámetro objetivamente medible que indica el valor actual,
el valor objetivo, así como cuando se prevé obtener dicho valor
– Medir periódicamente el valor de dicho parámetro
– Definir acciones/responsables asociados al seguimiento de dichas
expectativas

19
B.1. Gestión Requerimientos (4/6)
• Recoger de una manera formal los requerimientos del cliente que conforman
el objeto del proyecto, así como cuales han sido los cambios posteriormente
solicitados y aprobados de estos requerimientos originales, son la base que
facilita una gestión exitosa.
• En este capítulo del Plan de Proyecto deben recogerse:
– Documentos, o ubicación física o electrónica, que indican cuales son los
requisitos originalmente aprobados por el “cliente”, así como los cambios
posteriormente solicitados/aprobados.
– Documentos, o ubicación física o electrónica, que recogen la transformación de
estos requerimientos en diseño físico, tanto de datos como procesos. Por
ejemplo, donde encontrar el modelo conceptual de datos y de procesos, o el
modelo lógico de procesos, ...
– Ubicaciones de los diferentes conjuntos de software y BB.DD.,tanto para el
desarrollo, como para la pre-producción (entorno integración).
– Versiones de software que hay en producción, indicando el nexo de unión entre
cada versión de software con los requerimientos originales del “cliente”.

20
• Una buena gestión de requerimientos, y en función de la envergadura del
proyecto, necesitará disponer de una serie de herramientas fundamentales:
– Herramienta que facilite de manera formal el diálogo ‘’cliente’’ – equipo gestor del
proyecto
– Herramienta CASE adecuada a la metodología seleccionada, y que permite un
control de versiones de los diferentes elementos implicados
– Herramienta de control de configuración del software y de las BB.DD.
– Matriz trazabilidad Requerimientos

21
Ejemplo de Matriz de Trazabilidad de Requerimientos:
Requirement #:
RD1
RD1.1
RD1.1.1
RD1.1.2
RD1.1.3
RD1.1.4
RD1.1.5
RD1.1.6
RD1.1.7
RD1.1.8
RD1.1.9
RD2
RD3
RD4
RD5
RD6
RD7
RD7.1
RD7.1.1
RD7.1.2
RD7.2
RD7.3
RD8
RD8.1
RD8.2
RD8.3
RD9
RD9.1
RD9.2
RD10
RD11
RD12
RD13
Application Design Specifications (oam_ads.doc - Version 1.0)
AD1.0 X
AD2.0 X X X X X X X X
Technical Architecture Specifications (oam_tas.doc - Version 1.0)
TAS-1 X
TAS-2 X
Formal Acceptance Test Specifications (oam_fat_tsp.doc - Version 1.0)
FATC-1 X
FATC-2 X
Application Design #:
AD1.0
AD2.0
AD2.1
AD2.2
AD2.3
AD2.4
AD2.5
AD3.0
AD3.1
AD3.2
AD3.3
AD3.4
AD3.5
AD3.6
AD3.7
AD3.8
AD3.9
AD3.10
AD3.11
AD4.0
AD5.0
AD6.0
AD6.1
AD6.2
Application Components
ufusr X
ufusr_ask_unload X
oam_ui_mgr_invoke X
oam_ui_mgr_initialize X
oam_ui_mgr_cleanup X
oam_ui_mgr_list_errors X
oam_ui_mgr_const_cb X
oam_ui_mgr_operation_cb X
Unit Test Cases (UTC)
UTC-001 X X X
UTC-002 X X X X
UTC-003 X X X

22
B.2. Gestión Riesgos (1/9)
• Definiciones
– Riesgo
• Un posible evento futuro que, si ocurre, puede provocar resultados inesperados.
– Riesgos del Proyecto
• Efecto acumulado de los sucesos con resultado incierto que afectan
negativamente a los objetivos del proyecto.
– Gestión del riesgo
• Conjunto de actividades realizadas para la identificación, análisis y control de los
riesgos de un proyecto.

23
• Por que es necesaria la gestión del Riesgo?
– Los proyectos tienen tendencia a complicarse y a crecer
– Cada vez son necesarias más y diversas tecnologías
– El número de usuarios es mayor
– Los cambios en los negocios cada vez son más radicales
• Hechos que afectan a la gestión del Riesgo
– Construir software es un negocio arriesgado.
– Es estándar de la industria es ignorar los riesgos.
– La gestión de riesgos cuesta dinero y no se puede demostrar, de antemano, que sea
necesaria.
– La tendencia natural es posponer las partes más complejas del proyecto.

24
• Frases célebres sobre la gestión de Proyectos
– Las Malas noticias no mejoran con el tiempo.
– Lo que no está escrito en un papel, no se ha dicho.

25
B.2. Valoración y Control (4/9)
Gestión de
Riesgos
Valoración
de Riesgos
Control de
Riesgos
Identificación de Riesgos
Análisis de Riesgos
Priorización de Riesgos
Planificación de la Gestión
Resolución de Riesgos
Monitorización de Riesgos

26
• Identificación de los Riesgos
– Se debe mantener un inventario de los riesgos identificando la causa y el efecto
que tendrá.
– Las fuentes pueden ser muy diversas, como sesiones de participación en resolver
problemas en grupo (Brainstorming), datos de Consultores, Análisis Causa-Efecto,
Herramientas, etc.
– Nuestras fuentes son las Suposiciones realizadas al recoger los requerimientos, el
plan de trabajo (camino crítico) y el análisis de los Costes esperados.
• Análisis de los Riesgos
– Se identifica cuándo puede ocurrir, el impacto que puede tener, la probabilidad de
que ocurra y la proximidad al núcleo del proyecto.
– Nosotros utilizamos un método cualitativo, asignando las letras A (bueno) a D
(malo) a cada concepto.
B.2. Gestión Riesgo: Identificación y Análisis (5/9)
Valor Debo hacer algo? Cuando?
D Si Ahora
C Si Pronto
B Puede ser Revisar
A No Aparcar

Riesgo con
alto Impacto
27
B.2. Gestión Riesgo: Priorización (6/9)
Tiempo
Estamos aquí
Primer
Riesgo
a mirar
Riesgo de
Bajo Impacto
(Cerca del
Núcleo)
(Lejos
del
Núcleo)
“D”
“C”
“B”
“A”
Probability
D
C
C
B
B
B
D
A
A
Proximidad

28
• Planificación de la gestión de riesgos
– Contiene qué acciones se realizarán para Estabilizar o Desensibilizar el
proyecto de los efectos de, al menos, los 10 riesgos principales, quién las
ejecutará y en que momento.
– Adicionalmente el plan deberá contener los criterios de éxito de la acción
así como los procedimientos de monitorización y los eventos que deben
disparar las alarmas.
• Monitorización de riesgos
– Se realiza una revisión continua e individualizada de las acciones
planificadas para eliminar o mitigar los riesgos principales.
– Se realizan revisiones periódicas para ver si aparecen nuevos riesgos o
se pueden modificar los resultados del análisis de los riesgos
– Los encargados de riesgos deben estar alerta sobre los riesgos y evitar
que estos sean ignorados.
B.2. Gestión Riesgo: Control y monitorización (7/9)

29
• TRABAJO EN GRUPO - identificación de riesgos
B.2. Gestión Riesgo (8/9)

30
• Problemas más comunes en proyectos de desarrollo de Software
– Estimaciones inferiores
• Si no se valoran los proyectos de forma adecuada, el resultado final puede
ser entre un 100% y un 250% mayor de lo previsto.
– Gestión del ámbito
• Los proyectos de software tienden a crecer durante el tiempo. Se puede
esperar un crecimiento del tamaño de un 1% mensual.
– Pérdida de esfuerzo
• Puede que todo el tiempo invertido no sea productivo por una baja calidad
del tiempo (interrupciones, ruido ambiental, etc.), por rotación o por realizar
reuniones demasiado largas
– Bajo rendimiento
• La productividad es un factor clave que puede verse alterada por la
complejidad del proyecto, uso de nuevos lenguajes y tecnologías,
herramientas de soporte no adecuadas o necesidad de invertir en procesos
de mejora.
B.2. Gestión Riesgo: Trabajo en Grupo (9/9)

31
B.4. Componentes - Gestión Calidad (1/5)
• Dentro del Plan de Proyecto de calidad deben contemplarse tres aspectos
básicos:
– La definición de los estándares seleccionados, los cuales han de cubrir
desde el ciclo de vida / metodología que se va a utilizar para el proyecto,
hasta aspectos fundamentales de diseño, programación, documentación…
– El plan de control de configuración, tanto del software como de la
documentación utilizada. Es fundamental tener una eficiente gestión de
cambios, y poder asociar cada versión de software/documento con el
requerimiento aprobado por el “cliente”.
– El plan de revisiones de conformidad, así como el resultado de su ejecución,
para validar que:
• la ejecución del proyecto se ciñe a los estándares elegidos
• se está diseñando/programando/probando/implantado/manteniendo
exclusivamente en base a los requerimientos formalmente aprobados.

32
Actual Futuro
Fallos
100
80
60
40
20
0
Defectos
Testing
Prevención
Ahorro
Tiempo,
Coste,
Esfuerzo
• ¿Cuál es el coste de la Inversión? • ¿Vale la pena para este proyecto?

33
C
O
S
T
E
De Proyectos
De Implantación Calidad
Costes de un proyecto =
Del desarrollo +
De la implantación +
Del mantenimiento
Porque es necesario una buena gestión de la calidad:
• no repetir el mismo error más de una vez
• seguir unos estándares del proyecto o del cliente, previenen defectos
• minimizar los costes/tiempo/esfuerzo a consumir en el tiempo
• es clave para conseguir el objetivo del proyecto

34
• Para poder evaluar la calidad del proyecto es necesario disponer de medidas
que no puedan ayudar a ver si se están consiguiendo los objetivos del proyecto.
• Las métricas más usuales en la gestión de proyectos son:
– Número de Recursos
– Tamaño o estimación del proyecto
– Defectos, que incluyen los resultados de las revisiones de calidad de los
productos
– Cambios

35
Ejemplo del plan de métricas básicas para el proyecto
Enero Febrer Marzo Abril Mayo Junio Julio Agosto Septiembre Octubre Noviembre Diciembre Total
Recursos Asignados Total 2,00 5,00 10,00 15,00 20,00 20,00 20,00 20,00 18,00 16,00 8,00 4,50 158,50
Requeridos Reals 2,00 5,00 10,00 15,00 20,00 20,00 20,00 20,00 18,00 16,00 8,00 4,50 158,50
Diferencia Reals 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
Horas Teóricas Laborables 328,50 821,26 1.888,89 2.463,77 3.285,02 3.449,28 3.080,00 3.080,00 3.104,35 2.628,02 1.379,71 776,09 26.284,88
Vacaciones 40,00 40,00 40,00 200,00 120,00 160,00 200,00 550,00 300,00 80,00 80,00 100,00 1.910,00
Ausencias 15,92 43,11 95,17 124,92 174,65 177,06 164,37 144,39 150,95 140,60 69,96 36,39 1.337,49
Proyectos 272,58 738,15 1.753,72 2.138,85 2.990,37 3.112,22 2.715,63 2.385,61 2.653,40 2.407,42 1.229,75 639,69 23.037,39
Proyectos Reales 272,58 738,15 1.753,72 2.138,85 2.990,37 3.112,22 2.715,63 2.385,61 2.653,40 2.407,42 1.229,75 639,69 23.037,39
Diferencia 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
Efectivas Reales 272,58 738,15 1.753,72 2.138,85 2.990,37 3.112,22 2.715,63 2.385,61 2.653,40 2.407,42 1.229,75 639,69 23.037,39
Diferencia 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
Ausencias Vacaciones Reales 40,00 40,00 40,00 200,00 120,00 160,00 200,00 550,00 300,00 80,00 80,00 100,00 1.910,00
Previstas 40,00 40,00 40,00 200,00 120,00 160,00 200,00 550,00 300,00 80,00 80,00 100,00 1.910,00
Diferencia 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
Bajas/Otros Reales 7,72 20,91 49,49 60,60 84,73 88,05 77,10 67,73 75,07 68,21 34,79 18,10 652,50
Previstas 7,72 20,91 49,49 60,60 84,73 88,05 77,10 67,73 75,07 68,21 34,79 18,10 652,50
Diferencia 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
Formación Reales 8,20 22,20 45,68 64,32 89,92 89,00 87,27 76,67 75,88 72,39 35,17 18,29 685,00
Previstas 8,20 22,20 45,68 64,32 89,92 89,00 87,27 76,67 75,88 72,39 35,17 18,29 685,00
Diferencia 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
Ratios Utilización Mensual 94,48% 94,48% 94,85% 94,48% 94,48% 94,62% 94,29% 94,29% 94,62% 94,48% 94,62% 94,62%
Acumulado 94,48% 94,48% 94,72% 94,61% 94,56% 94,58% 94,52% 94,49% 94,51% 94,50% 94,51% 94,51%
Prod. Real Mensual 94,48% 94,48% 94,85% 94,48% 94,48% 94,62% 94,29% 94,29% 94,62% 94,48% 94,62% 94,62%
Acumulado 94,48% 94,48% 94,72% 94,61% 94,56% 94,58% 94,52% 94,49% 94,51% 94,50% 94,51% 94,51%
Grado Avance Acumulado 1 1 1 1 1 1 1 1 1 1 1 1

36
B.6. Componentes - Gestión Planificación (1/4)
• Este apartado del Plan de Trabajo es el que requiere la mayor atención del Jefe
de Proyecto, pero hay que evitar el perder de vista el resto de capítulos
(enfoques) del dicho Plan.
• Dependiendo de la envergadura del proyecto, o del nivel de experiencia del Jefe
de Proyecto en el manejo de planificaciones, esta tarea podría recaer en el grupo
de Planificación y Control.
• En líneas generales, tal y como se verá en el capítulo C de este curso, el ciclo de
vida de un plan de trabajo se inicia con la valoración y la posterior obtención de
la planificación base con un horizonte hasta el final del proyecto, pero
periódicamente (semanalmente) debe de recogerse el nivel de actividad incurrido
de cada recurso, replanificar toda la parte no ejecutada del proyecto analizando el
efecto de las medidas correctoras a aplicar en caso de desviaciones, y obtener el
plan de trabajo para cada recurso a realizar en el periodo (semana) siguiente.

37
• En este apartado del Plan de Proyecto debe de recogerse:
– La valoraciones de los requerimientos del “cliente” (ver detalle en capítulo C)
– Los diferentes planes de trabajo iniciales elaborados a partir de estas valoraciones y
de la metodología utilizada, así como de las restricciones de tiempo asociadas.
– La diferentes versiones de dichos planes de trabajo, aunque normalmente con la
planificación base y con la planificación actual es suficiente.
– Los indicadores de actividad, o partes de trabajo, de cada período (semanales).
– El análisis de las principales desviaciones de cada período, y las medidas particulares
previstas a aplicar o aplicadas.
• Finalmente, destacar que el enfoque de la planificación no puede ser el mismo para un
proyecto cerrado (construcción/implantación nuevo sistema),que para un proyecto
parcialmente abierto (mantenimiento de una aplicación)
– En el primer caso este irá orientado a tareas/fechas, incorporando/desincorporando
recursos a medida que sea necesario.
– Mientras que en el segundo caso, la planificación irá orientada a la capacidad de los
recursos disponibles, fijando la finalización de las tareas en función de estas
capacidades.

38

39

40
B.7. Componentes - Gestión Equipo Trabajo (1/6)
Roles y
Responsabilidades
Definición de Roles y
Responsabilidades
‘Organizational Breakdown
Structure’
Infraestructura Plan de Reasignación/
Adquisición de Recursos
Requerimientos
de Plantilla
Plan de Recursos (Personas)
Relación de Conocimientos
Plan de Desarrollo del Equipo
Plan de Reconocimiento
• Este capítulo del Plan de Trabajo se encontrará condicionado por la política de RR.HH. que
impere en la empresa. No obstante, en mayor o menor medida, será indispensable detallar
los siguientes aspectos del proyecto:

41
S
S
S
S
S
• Definición Roles: Es fundamental que en un proyecto cada miembro del equipo de trabajo
tenga claras sus responsabilidades. En el cuadro siguiente se define las responsabilidades de
algunos de los miembros de un equipo :
Función Responsabilidades Persona(s)
Especialista en la gestión
de requerimientos (RM)
Definidas por la versión vigente de GSCM y los estándares
vigentes en el SC para la función del miembro del equipo.
Además:
-Interlocutor válido para los compromisos con el cliente
-Responsable para las peticiones de desarrollo pequeñas y
medianas
Jefe Proyecto
Especialista en el
aseguramiento de calidad
(QA)
Además:
-Participa en las revisiones del proceso y auditorías de QA
-Participa y puede liderar las revisiones de productos
Jefe Proyecto
Analista B
Especialista en la gestión
de configuración (CM)
Además:
-Da soporte al resto del equipo en las actividades del control
de cambios y versiones
-Realiza las revisiones de las Baselines según lo planificado
en el Plan de gestión de configuración
Analista A
Analista B

42
S
S
S
S
S
• En el cuadro siguiente se muestra un ejemplo de una distribución roles/responsabilidades de
un proyecto:
S
S
C
S
R
S
S
C
S
R
S
A
A
S
S
R
S
R = Responsable del Proceso
A = Aprueba/Acepta los entregables del Proceso
S = Soporte en la creación de los entregables
I = Necesita Información del ‘status’ y contenido de los entregables
C = Proporciona consultoría o información a los entregables
Clave
R S A
Establecer Equipo del Proyecto
Crear el Libro del Proyecto
Elaborar el Plan del Proyecto
A
R
R
R
R
A
R
R
R
R
R
R
R
R
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
C
S
C
A
A
I
A
S
S
S
S
S
S
S
S
S
Participantes en el Proyecto
Establecer Relaciones Cliente
Definir el Alcance del Proyecto
Establecer el entorno de
Dirección de Proyecto
Establecer el Proceso de
Gestión de la Configuración
Definir Procedim. Financieros
Identificar Riesgo del Proyecto
Anunciar Proyecto
Revisar el Plan del Proyecto
Tareas Gestión
Gerente
Cuenta
Jefe
Proy.
AF’s
AP’s
Experto
Tecnol.
Direcc.
Financ.
Superv.
Cliente

• Requerimientos Plantilla: A partir de la planificación del proyecto, se debe analizar la
necesidad de recursos por perfiles profesionales, así como cual ha de ser la evolución de la
pirámide durante la vida del proyecto.
• Es importante el saber calcular, a partir del número equivalente de recursos obtenidos de la
planificación del proyecto, los recursos que realmente son necesarios en función del % de
utilización de los mismos.
– %Utilización = (Horas Disponibles - Formación - Bajas - Vacaciones) / Horas
Disponibles
• Por ejemplo, en el cuadro siguiente, cada mes será necesario prever un recurso más por mes.
Enero Febrero Marzo Abril Mayo
JefeProyecto 1 1 1 1 1
Analistas 2 2 2 2 1
A/P 1 2 3 3 2
Programadores 1 3 5 5 2
TOTAL EQUIVALENTE 5 8 11 11 6
%Utilización 85% 90% 90% 90% 90%
TOTAL PERSONAS 5,88 8,89 12,22 12,22 6,67

• En el momento de la asignación de personas a las diferentes funciones derivadas de la
planificación del proyecto, dado que el encaje ideal casi nunca se da, será necesario planificar
una serie de acciones para conseguir dicho encaje, pasando por la formación, la recompensa
de sobreesfuerzos no productivos...
Enero Febrero Marzo Abril Mayo
JefeProyecto 1 1 1 1 1
Analistas 2 2 2 2 1
A/P 1 2 3 3 2
Programadores 1 3 5 5 2
TOTAL EQUIVALENTE 5 8 11 11 6
%Utilización 85% 90% 90% 90% 90%
TOTAL PERSONAS 5,88 8,89 12,22 12,22 6,67
Recursos Disponibles
JefeProyecto Pedro, Maribel
Analistas Isabel, Jordi, Alberto
A/P Antonio
Prog.Seniors Elena,Maria
Prog.Junior Felipe, Luis, Rosa, Eva
Reconocimiento
al Empleado
Formación
Desarrollo de Carrera

• Infraestructura: Finalmente, para que los niveles de productividad estén dentro de los
previstos en la planificación del proyecto, los medios al alcance del equipo de trabajo han
de ser los adecuados, y su nivel de disponibilidad tan elevado como el que suele
exigirnos el cliente.
• Dentro de estos recursos hay que contemplar:
– Hardware y software base, tanto de servidores como de redes
– Hardware y software particular para el desarrollo del proyecto
– Servicios de soporte de calidad suficiente para resolución de incidencias, alta
usuarios, tareas administrativas…
– Puestos de trabajo: mesa, teléfono, …
• En consecuencia, si las particularidades del proyecto difieren de los estándares
imperantes para el resto de proyectos, será necesario planificar las acciones particulares
a implantar

46
B.8. Componentes - Gestión Comunicaciones (1/3)
Los elementos a considerar para crear un plan eficaz de comunicaciones son:
– Determinar qué debe ser comunicado
– Describir el contenido de cada elemento de comunicación
– Documentar el propósito
– Documentar a qué audiencia va dirigido
– Documentar la frecuencia y el lugar
– Documentar el medio elegido
– Documentar el responsable de cada ‘item’ de comunicación
– Documentar el responsable de la distribución
– Documentar la cantidad estimada y el coste
Como principales “outputs” del plan de comunicaciones hay que considerar:
– El informe periódico de avance del proyecto a compartir con el “cliente”.
– La estructura de actas y relación de compromisos derivados
– La sesión mensual con el equipo de trabajo

47
TRABAJO EN GRUPO - elementos de un plan de comunicación

48
• Por lo tanto, en este capítulo del Plan del Proyecto, se deberán definir:
– Estructuras y frecuencia de los principales informes, tanto internos como
hacia el “cliente”
– Responsables de la elaboración de los contenidos
– Circuitos de aprobación de dichos informes, o de los contenidos de las
presentaciones
• Finalmente, no basta con describir los elementos del plan de comunicaciones, sino que
en este capítulo del Plan del Proyecto deben de almacenarse, o indicar donde pueden
ser localizados, lo elementos de comunicación elaborados en el transcurso del proyecto,
destacando la relación de actas/compromisos derivados de las múltiples sesiones de
trabajo.

49
B.9. Componentes - Gestión Económica (1/3)
• Al igual que en el resto de capítulos del Plan de Proyecto, en este se deberá de:
– Describir los procedimientos/métodos utilizados para realizar el análisis
del grado de avance económico del proyecto
– Asignar los responsables de realizar dicho análisis, y de determinar
acciones correctoras para corregir las desviaciones en el plano
económico
– Documentar periódicamente, a partir de los procedimientos descritos, el
estado de salud económica del proyecto
• No hay que dar por supuesto que un proyecto con desviaciones en plazos tiene
desviaciones económicas, o que la inexistencia de desviaciones en esfuerzo/plazo es un
indicativo de que económicamente el proyecto va bien.

50
• Ejemplo del seguimiento económico de un proyecto planificado para el año 2004 al
cerrar el mes de Febrero
• Estos datos, por si solos, no son indicativos de si el proyecto va bien o no. Deben
analizarse conjuntamente con el resto de métricas
Costes Salarios Previstos 6.000,00 15.000,00 30.000,00 45.000,00 60.000,00 60.000,00 60.000,00 60.000,00 54.000,00 48.000,00 24.000,00 13.500,00 475.500,00
Reales 6.000,00 12.000,00 33.000,00 45.000,00 60.000,00 60.000,00 60.000,00 60.000,00 54.000,00 48.000,00 24.000,00 13.500,00 475.500,00
Diferencia 0,00 3.000,00 -3.000,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
Infraestructura Previstos 300,00 750,00 1.500,00 2.250,00 3.000,00 3.000,00 3.000,00 3.000,00 2.700,00 2.400,00 1.200,00 675,00 23.775,00
Reales 300,00 600,00 1.650,00 2.250,00 3.000,00 3.000,00 3.000,00 3.000,00 2.700,00 2.400,00 1.200,00 675,00 23.775,00
Diferencia 0,00 150,00 -150,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
Otros Previstos 670,00 1.675,00 3.350,00 5.025,00 6.700,00 6.700,00 6.700,00 6.700,00 6.030,00 5.360,00 2.680,00 1.507,50 53.097,50
Reales 670,00 1.340,00 3.685,00 5.025,00 6.700,00 6.700,00 6.700,00 6.700,00 6.030,00 5.360,00 2.680,00 1.507,50 53.097,50
Diferencia 0,00 335,00 -335,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
Ingresos Previstos 8.995,22 24.358,80 57.872,67 70.582,09 98.682,37 102.703,26 89.615,85 78.725,04 87.562,04 79.444,76 40.581,73 21.109,92 760.233,76
Reales 9.240,00 18.150,00 63.327,00 70.582,09 98.682,37 102.703,26 89.615,85 78.725,04 87.562,04 79.444,76 40.581,73 21.109,92 759.724,06
Diferencia 244,78 -6.208,80 5.454,33 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 509,69
Resultado Previstos 22,51% 26,86% 35,06% 31,08% 30,43% 30,91% 29,19% 26,57% 26,82% 27,16% 27,39% 27,34%
Reales 24,57% 23,66% 34,69% 30,86% 30,30% 30,82% 29,11% 26,50% 26,76% 27,11% 27,34% 27,29%
Diferencia 2,05% -3,20% -0,36% -0,22% -0,14% -0,10% -0,08% -0,07% -0,06% -0,05% -0,05% -0,05%

51
• Ejemplo del seguimiento de las métricas del proyecto
Recursos Asignados Total 2,00 4,00 11,00 15,00 20,00 20,00 20,00 20,00 18,00 16,00 8,00 4,50 158,50
Requeridos Reals 2,00 5,00 10,00 15,00 20,00 20,00 20,00 20,00 18,00 16,00 8,00 4,50 158,50
Diferencia Reals 0,00 -1,00 1,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
Horas Teóricas Laborables 328,50 821,26 1.888,89 2.463,77 3.285,02 3.449,28 3.080,00 3.080,00 3.104,35 2.628,02 1.379,71 776,09 26.284,88
Vacaciones 40,00 40,00 40,00 200,00 120,00 160,00 200,00 550,00 300,00 80,00 80,00 100,00 1.910,00
Ausencias 15,92 43,11 95,17 124,92 174,65 177,06 164,37 144,39 150,95 140,60 69,96 36,39 1.337,49
Proyectos 272,58 738,15 1.753,72 2.138,85 2.990,37 3.112,22 2.715,63 2.385,61 2.653,40 2.407,42 1.229,75 639,69 23.037,39
Proyectos Reales 285,00 570,00 1.919,00 2.138,85 2.990,37 3.112,22 2.715,63 2.385,61 2.653,40 2.407,42 1.229,75 639,69 23.046,94
Diferencia 12,42 -168,15 165,28 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 9,55
Efectivas Reales 280,00 550,00 1.919,00 2.138,85 2.990,37 3.112,22 2.715,63 2.385,61 2.653,40 2.407,42 1.229,75 639,69 23.021,94
Diferencia -5,00 -20,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 -25,00
Ausencias Vacaciones Reales 32,00 48,00 40,00 200,00 120,00 160,00 200,00 550,00 300,00 80,00 80,00 100,00 1.910,00
Previstas 40,00 40,00 40,00 200,00 120,00 160,00 200,00 550,00 300,00 80,00 80,00 100,00 1.910,00
Diferencia 8,00 -8,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
Bajas/Otros Reales 12,00 24,00 56,00 60,60 84,73 88,05 77,10 67,73 75,07 68,21 34,79 18,10 666,37
Previstas 7,72 20,91 49,49 60,60 84,73 88,05 77,10 67,73 75,07 68,21 34,79 18,10 652,50
Diferencia -4,28 -3,09 -6,51 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 -13,87
Formación Reales 0,00 16,00 48,00 64,32 89,92 89,00 87,27 76,67 75,88 72,39 35,17 18,29 672,92
Previstas 8,20 22,20 45,68 64,32 89,92 89,00 87,27 76,67 75,88 72,39 35,17 18,29 685,00
Diferencia 8,20 6,20 -2,32 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 12,07
Ratios Utilización Mensual 95,96% 93,44% 94,86% 94,48% 94,48% 94,62% 94,29% 94,29% 94,62% 94,48% 94,62% 94,62%
Acumulado 95,96% 94,27% 94,68% 94,59% 94,55% 94,57% 94,51% 94,48% 94,50% 94,50% 94,50% 94,51%
Prod. Real Mensual 94,28% 90,16% 94,86% 94,48% 94,48% 94,62% 94,29% 94,29% 94,62% 94,48% 94,62% 94,62%
Acumulado 94,28% 91,51% 93,82% 94,11% 94,25% 94,35% 94,34% 94,33% 94,37% 94,39% 94,40% 94,41%
Grado Avance Acumulado 0,98 0,97 0,99 0,99 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00

APARTADO C
Ciclo de vida en la Gestión del Proyecto

53
C. Ciclo de vida de la Gestión de un Proyecto
• C.0. Introducción
• C.1. Definición ámbito y valoración esfuerzo
• C.2. Planificación
• C.3. Seguimiento y control
• C.4. Cierre
Índice
• Objetivo: Describir las cuatro etapas del ciclo de vida de la
gestión de un proyecto
• Finalidad: Conocer en cada fase del ciclo de vida las
principales actividades a realizar

54
C.0 Introducción

55
• ¿Cómo se lleva a cabo la estimación de un proyecto de software?
– 1º Se estima el tamaño del producto
– 2º Se estima el esfuerzo
– 3º Se estima la planificación
– 4º Se da un intervalo de estimación y se refina periódicamente
C.1. Definición ámbito y valoración esfuerzo
Estimación
tamaño
Estimación
esfuerzo
Estimación
planificación
Refinamiento de la planificación
•Puntos Función
•Desglose Tareas
•Persona/mes •Número meses

56
• Definición del ámbito
– Amplitud y profundidad del conjunto de prestaciones
– Complejidad y dificultad del producto
– Fundamental una excelente gestión de los requerimientos
Registrar las diferentes versiones de software asociadas a los cambios en los requerimientos
del cliente
• Estimación del tamaño del producto
– Enfoque algorítmico partiendo de las prestaciones del producto
– Software de estimación partiendo de la descripción de las prestaciones
del producto
– Antecedentes: a partir de la estimación de antiguos proyectos
• La medida exacta de proyectos anteriores es clave de éxito a largo plazo, utilizando
cualquier tipo de estimación
C.1. Definición ámbito y valoración esfuerzo

57
• Es una medida sintética bastante exacta para medir el tamaño de un Sistema de
Información.
• Su objetivo es obtener una medida de las unidades a producir, aunque se puede
llegar a deducir el esfuerzo en horas asociado a dicha producción.
• Características
– El cálculo de las unidades de medida de producción es independiente del
entorno técnico y de las herramientas de programación
– Se basa en funciones, facilidades y características que conoce y pide el
que establece los requerimientos
– Los PF se calculan después de que los requerimientos se plasmen
en el Análisis Funcional
– El cálculo puede ser llevado a cabo por personal de perfil no técnico
C.1. Definición ámbito y valoración esfuerzo - PUNTOS FUNCION

58
• Cálculo de PF
– Calcular PF desajustados (PFD)
– Calcular Factor Ajuste del Valor (FAV)
– Calcular los PF ajustados (PFA)
PF de desarrollo (proyecto): PFA = PFD * FAV

59
• Proceso de recuento de PFD
– Si hemos de aplicar técnicas de análisis y diseño estructurado, cerrar el
Diseño Funcional de contexto y el modelo conceptual de datos
– Clasificar todas las estructuras de datos dentro de los 5 tipos de función
requeridos por el usuario (Entrada, Salida, Consultas, Ficheros Internos,
Ficheros Externos)
– Clasificar,según los criterios a aplicar a cada tipo de función, en uno de
los 3 niveles de complejidad de procesamiento de información (A/M/B), todas
las estructuras de datos.
– Por cada tipo de función/nivel de complejidad, contar el número de
estructuras de datos, y aplicar factor de peso a cada combinación para
obtener PFD

60
SALIDAS
CONSULTAS FICHEROS
EXTERNOS
Todas las estructuras de datos se agrupan en 5 tipos de función
ENTRADAS
FICHEROS
INTERNOS
SISTEMA DE INFORMACION

61
Nº DE TIPOS DE DATO
1 A 19 20 A 50 51 O MÁS
Nº DE 1 (B)AJA (B)AJA (M)EDIA
TIPOS DE 2 A 5 (B)AJA (M)EDIA (A)LTA
REGISTRO 6 O MÁS (M)EDIA (A)LTA (A)LTA
Por ejemplo:
Clasificación del tipo de función FLI (fichero lógico interno) según
complejidad funcional
Clasificación individual de las estructuras de datos según la complejidad funcional

Factor de peso fijo
Número de ocurrencias según
complejidad funcional
62
Tipos de función
• Entradas
• Salidas
• Consultas
• Ficheros lógicos internos
• Ficheros de interfaz externos
• Total PFD sin ajustar
Baja
6 x 3 = 18
7 x 4 = 28
0 x 3 = 0
5 x 7 = 35
9 x 5 = 45
304
Media
2 x 4 = 8
7 x 5 = 35
2 x 4 = 8
2 x 10 = 20
0 x 7 = 0
Alta
3 x 6 = 18
0 x 7 = 0
4 x 6 = 24
3 x 15 = 45
2 x 10 = 20

• Comunicación de datos
• Proceso distribuido
• Rendimiento
• Configuraciones ampliamente utilizadas
• Volumen de transacciones
• Entrada interactiva de datos
• Diseño orientado a la eficiencia del
usuario final
• Actualización interactiva
• Complejidad de los procesos
• Reutilización
• Facilidad de instalación
• Facilidad de operación
• Ubicación múltiple
• Facilidad de cambios
GIT =  GI
Criterios de Ajuste para obtener el Grado de Influencia (GI)
63
0 - NO PRESENTA INFLUENCIA
1 - INFLUENCIA INCIDENTAL
2 - INFLUENCIA MODERADA
3 - INFLUENCIA MEDIA
4 - INFLUENCIA SIGNIFICATIVA
5 - INFLUENCIA FUERTE
Tabla de valores para estimar el G.I. de cada criterio

64
Tipos de función
• Entradas
• Salidas
• Consultas
• Ficheros lógicos internos
• Ficheros de interfaz externos
• Total PFD sin ajustar
• FAV = 0,65 + (0,01 x GIT)
• PFA = PFD * FAV
Baja
6 x 3 = 18
7 x 4 = 28
0 x 3 = 0
5 x 7 = 35
9 x 5 = 45
304
1,15
350
Media
2 x 4 = 8
7 x 5 = 35
2 x 4 = 8
2 x 10 = 20
0 x 7 = 0
Alta
3 x 6 = 18
0 x 7 = 0
4 x 6 = 24
3 x 15 = 45
2 x 10 = 20

65
• Existen otros sistemas para la valoración del esfuerzo/tamaño
– Recuento del número de componentes de software
– Recuento del número de líneas de código (sin contar con las líneas de
comentarios)
– Existen herramientas más modernas (algunas empresas se han
especializado en este tema y son requeridas por empresas de servicios
para ayudar en este tema).
– Ejemplo de sistema de valoración de un proyecto de mantenimiento, que se utiliza en EDS.
C.1. Definición ámbito y valoración esfuerzo - OTROS

66
C.2. Planificación

67
C.2. Planificación
• Planificación
– Sitúa el desarrollo informático en un calendario concreto, usando recursos
asignados y disponibles y teniendo en cuenta todas las relaciones
externas del proyecto
• Variables de la planificación
– Las tareas y su coste de estimación
– El perfil necesario para la realización según la estimación
– La ordenación de las tareas en el tiempo según la metodología
– Las personas del equipo y su disponibilidad
– El calendario con todas sus constantes
– La relación de dependencia con otras tareas externas
– La estrategia global de la planificación: calendario vs. recursos

68
C.2. Planificación
• La Planificación da respuesta a las siguientes preguntas
– Qué hay que hacer
– Cómo debe hacerse
– Quién debe hacerlo
– Cuándo hay que hacerlo
– Cuánto va a costar
– Cómo tiene que ser de bueno
– Qué rendimiento se requiere
– Qué puntos fuertes tiene
– Qué puntos débiles
– Qué oportunidades
– Qué amenazas
• Puntos clave
– Nivel de detalle
– Técnica de aproximación
– Herramientas de apoyo
– Seguimiento/Refinamiento semanal
– Flexibilidad/Agilidad al cambio
– Apoyarse en experiencias de proyectos similares

69
C.2. Planificación
• Errores usuales
– Trabajar sin un plan es la esencia del planteamiento desordenado
– “No tengo tiempo para planificar”
– “No sabemos adónde nos dirigimos, pero vamos a llegar muy rápidos”
– No implicar en el proceso de planificación a los ejecutores del plan
– Olvidar que las personas no producen 8h al día, 20 días al mes, 12
meses al año (vacaciones,formación, bajas, falta formación, asignación a
otras actividades, …..)
– Creer que vamos a gestionar los recursos externos como si fueran
internos (disponibilidad usuarios, otros proveedores, ….)
– Inexistencia de la Gestión de Cambios, sobre todo por el impacto en
la planificación en la fase de ejecución del proyecto

70
C.2. Planificación - Deficiente gestión de cambios
Insatisfacción
del Cliente
Los
Antídotos
El
Pozo
Planificación
Excedida
Coste
Excedido
Beneficio
Reducido
Baja Moral de Equipo
Retrabajo en
aumento
Baja Calidad
Gestión de la Configuración
Alertar al equipo
de los peligros
Simplemente
decir “no”
Fuente - Cursos PM2 EDS

71
C.2. Planificación
• Pasos en la planificación
– Definir el problema que debe resolver el proyecto (OBJETIVOS)
– Elaborar una estructura de desglose del trabajo
– Calcular la duración, necesidades de recursos y costes de la actividad
– Preparar el calendario del proyecto y el presupuesto
– Definir técnicas y herramientas de planificación y control
– Decidir la estructura organizativa del proyecto
– Conseguir la aceptación de la Planificación

72
• Estructura de Descomposición del Trabajo
• Técnica para hacer o refinar la estimación del esfuerzo y del coste de un proyecto
• Identificación y definición de las tareas en las que se descompone un proyecto
• Descomposición jerárquica con 6 niveles de estructura:
– Programa total
– Proyecto
– Tarea
– Subtarea
– Paquete de trabajo
– Actividad o nivel de esfuerzo
C.2. Planificación – Desglose de Tareas

73
• Objetivo: Reducir el proyecto a tareas que, individualmente puedan ser
definidas, presupuestadas, planificadas, asignadas y controladas
• Ventajas
– Buena definición del trabajo (especificación)
– Asignación de recursos necesarios
– El esfuerzo requerido para su realización
– Coste total y coste por tarea
– Un programa de trabajo por periodos (p.e., semanal)
– Asignación de responsabilidades
– Una visión global del alcance del proyecto
C.2. Planificación - Desglose de Tareas

74
C.2. Planificación - Desglose de Tareas Modelo
FASE FASE
SUBFASE SUBFASE SUBFASE
ACTIVIDAD ACTIVIDAD ACTIVIDAD
PROYECTO
TAREA
FASE
Nivel 2
Nivel 3
Nivel 4
Nivel 5
Nivel 6

75
C.2. Planificación - Desglose de Tareas Ejemplo
PINTURA
INTERIOR
SUSTITUCION
DEL TEJADO
MOVER
MUEBLES
CUBRIR
SUELOS PINTAR
ELEGIR
PINTURA MEZCLAR APLICAR
REFORMA
VIVIENDA
JARDINERIA
Nivel 2
Nivel 3
Nivel 4
Nivel 5
TAPAR
VENTANAS
QUITAR
ÁRBOLES
INSTALAR
RIEGO
PLANTAR
ARBUSTOS

76
C.2. Planificación - Desglose de Tareas Proyecto
Nivel 2
Nivel 3
Nivel 4
Nivel 5
Análisis Construcción
An. Modelo datos Entrada datos Salida
datos
Pantalla Codificar programa Pruebas integradas
Compra entradas
por cajero
Dibujar pantalla
Puesta en marcha
Nivel 6

77
• Catálogo de Actividades
– Adicionalmente a las propias derivadas del método de Ingeniería de
Software seleccionado:
• Análisis y Diseño
• Programación y prueba unitaria
• Pruebas de integración, de rendimiento y de usuario
• Pase a explotación y seguimiento post-arranque
– Deben contemplarse con el mismo grado de precisión:
• Las asociadas a la gestión del proyecto: Gestión plan de trabajo,
controles de calidad (revisiones formales), informes de progreso, ...
• Las asociadas a la gestión del cambio: Documentación, Formación,
Atención HelpDesk...
• Las asociadas a la infraestructura tecnológica: Instalación y tunning
de sistemas y de elementos de comunicaciones, …

78
EN FASE DE ESTIMACION
• Las cargas de trabajo por elemento de realización
• Las competencias requeridas
• Las posibilidades de paralelismo
• Los medios materiales que van a utilizarse
• La duración de la realización
• Los costes de la realización y las inversiones necesarias
EN FASE DE PLANIFICACION
• Ordenar cronológicamente las tareas
• Asignar un responsable y los recursos necesarios
• Determinar su duración
• Definir las fechas
• Calcular los márgenes
• Calcular las cargas por participante

79
C.2. Planificación - Programación del proyecto
• Sistemas de Programación
– Diagramas de GANTT: Henry Gantt
 Nos muestra las interrelaciones entre tareas dentro de su
secuencia temporal
– Sistema PERT: Performance Evaluation and review technique
– Sistema CPM: Critical Path Method
 PERT y CPM son similares ya que contemplan la relación
entre actividades
 PERT usa métodos probabilísticos basados en estadística
y CPM no
– El camino crítico es un método de programación que determina el camino
más largo para obtener la fecha más temprana

80
• Sistemas de Programación - Diagrama de GANTT
1.2.1 UpperAir Meteorology 10/27/98
1.2.1.DF Define 4/25/97
1.2.1.AN Analyze 5/23/97
1.2.1.DS Design 1/23/98
1.2.1.DSPP Plan/Prepare to Design 1/22/98
1.2.1.DSPP01 Develop/Update W
ork Plan 1/22/98
1.2.1.DSPP02 Acquire Project Resources 6/10/97
1.2.1.DSPP03 Prepare Participants for Participation 6/10/97
1.2.1.DSPP04 Establish Environment 12/30/97
1.2.1.DST
A Design T
echnical Architecture 8/13/97
1.2.1.DST
A01 Define Impact on Current Environment 6/9/97
1.2.1.DST
A02 Define Hardware/Software Selection Criteria 6/17/97
1.2.1.DST
A03 Ev aluate Hardware/Software
Alternativ es 6/25/97
1.2.1.DST
A04 Specify Env ironment Selections/Configurations 8/5/97
1.2.1.DST
A05 Commit TechnicalArchitecture 8/13/97
1.2.1.DSA
P01 DesignApplication 1/23/98
1.2.1.DSAP01 DesignApplication Architecture 10/2/97
1.2.1.DSAP02 Design Data Storage/Management 12/19/97
1.2.1.DSAP03 Design User Interface 9/1/97
1.2.1.DSAP04 DesignApplication Logic 12/18/97
1.2.1.DSAP05 DesignApplication Interfaces 1/9/98
1.2.1.DSAP06 Design Env iron Interfaces & Support Functions 1/9/98
1.2.1.DSAP07 Commit Application Designs 1/23/98
WBS Title Early FinishQtr 1 Qtr 2 Qtr 3 Qtr 4 Qtr 1 Qtr 2 Qtr 3 Qtr 4 Qtr 1 Qtr 2 Qtr 3
1997 1998 1999

81
PERT- Red de Actividades
– Componentes:
• Origen y Extremo
• Arcos o Flechas
• Nudos o Sucesos
• Duración
– La Red es una representación lógica del proyecto
– La Red se construye estableciendo para cada actividad: cuáles la
preceden, cuáles la siguen, cuáles pueden hacerse simultáneamente
– El Camino es la sucesión de actividades que permiten ir de un suceso a
otro
– Las actividades críticas definen el camino crítico de la Red

AON
A
B
C
D
E
F
G
82
• Sistemas de Programación - PERT

83
PRINCIPIO
D
E
F
A
(20,2)
B
(20,0)
C
(10,2)
(15,5)
(10,2)
(14,2)
FIN
OTM=0
OTR=0
OTM=20
OTR=25
OTM=35
OTR=35
OTM=49
OTR=49
CTM=0
CTR=5
CTM=20
CTR=25
CTM=35
CTR=35
CTM=20
CTR=20
CTM=0
CTR=0
CTM=20
CTR=39
OTM=20
OTR=20
OTM: OCURRENCIA MÁS PRONTO POSIBLE
OTR: OCURRENCIA MÁS TARDE POSIBLE
CTM: COMIENZO MÁS PRONTO POSIBLE
CTR: COMIENZO MÁS TARDE POSIBLE
• Sistemas de Programación - CPM

84
C.2. Planificación - Cálculo de la programación
Cálculo de la programación
– 1º Se construye la Red partiendo del desglose de Tareas
– 2º Se calcula el camino crítico
– 3º Se observa si la duración total del proyecto encaja entre las fechas establecidas
 El camino crítico esté dentro del margen de fechas
 El camino crítico sea más largo de lo esperado y deba ser acortado
– Redes secuenciales y Redes escalonadas
 Elementos de Espera y Desfase

85
C.2. Planificación - Uso del planificador
• Fases de la planificación de un proyecto
– Planificación del proyecto
 Definición de objetivos
 Determinación de la secuencia (constricciones temporales)
 Asignación de recursos necesarios
 Programación del proyecto (calendario)
– Control y seguimiento de la ejecución
 Actualizar información
 Controlar el uso de recursos
 Ajustar la planificación (correcciones)
 Ordenar la información

86
Planificador
– El planificador es una herramienta para planificar y controlar la ejecución
de proyectos, permitiendo actualizar la información y presentar el estado
del proyecto
– Formatos
• Formulario
• Tabla
• Diagramas gráficos
 GANTT
 CPM/PERT
 Recursos

87
División en partes del proyecto
• Tiene como misión facilitarnos la planificación
• Colección de tareas de fácil evaluación
• Técnica TOP-DOWN
– División del proyecto en unidades recurrentes
– Similar al EDT
Establecimiento de relaciones entre tareas
• Tomar cada tarea y comparala con el resto del proyecto
• Posibles relaciones:
– Finish-to-Start
– Start-to-Start
– Finish-to-Finish
• Tras esta fase se obtiene una visión clara del calendario

88
Asignación de recursos a las tareas
• Especificación de quiénes y con qué materiales deberán realizar las
tareas
• Planificación dirigida por los recursos
– La duración de las tareas dependerá de la cantidad de recursos
que dispongamos para ella, y de la productividad de dichos
recursos
– La duración del proyecto dependerá de la utilización que
hagamos de los recursos
• Planificación de duración fija
– La duración de cada tarea es fija
– Es independiente de los recursos que se le asignen

89
• Asignación de calendarios de trabajo
– Pretende tener en cuenta cuáles van a ser los días en los que se va a
trabajar y con qué horario
– Primero se crea un calendario base para el proyecto y calendarios
particulares para cada recurso o grupos de recursos
• Análisis y optimización de la planificación
– Es un proceso con un alto grado de realimentación
– Observar con mucha atención el camino crítico y las holguras de las
tareas para evitar los retrasos
• Total Stack
• Free Stack

90
• Seguimiento de la ejecución de un proyecto
– Pretende evaluar en cada momento la situación real del proyecto:
 Desviaciones en tiempo y coste
 Análisis de la causas
 Evaluación de los recursos
 Evaluación de las consecuencias de los cambios planteados
– Se desarrolla en 3 pasos:
 Establecimiento de un plan de ejecución a partir de la
planificación del proyecto
 Actualización periódica de la planificación
 Preparación de la situación actual del proyecto con la
planificación inicial que se realizó para él

91
C.2. Planificación
• TRABAJO EN GRUPO - planificación proyecto

92
C.3. Seguimiento y Control

93
• Objetivo: Cumplir con el objetivo del proyecto
• Valor añadido a largo plazo: Conocimiento
• Instrumentos necesarios
– Comité de Seguimiento
 Impulsar el desarrollo de los Sistema de Información
 Decidir acciones de alto nivel
 Garantizar el compromiso del usuario
– Técnicas y herramientas de seguimiento
 La planificación
 El registro de consumos y la previsión del estimado que falta
 La supervisión de tareas y productos
 El informe de progreso y los documentos de presentación

94
• Características del Control
– Evaluar el grado de avance en el proceso productivo del sistema
– Evaluar el grado de calidad del sistema en base a los resultados
intermedios obtenidos
– Identificar las desviaciones que se producen o se producirán en los 2
aspectos de la construcción: el proceso y el producto
– Comunicar el impacto en recursos, plazos, alcance y productividad del
proyecto
– Reflexionar sobre los factores de riesgo
– Facilitar la toma de decisiones correctas en el ámbito del proyecto y otras
de rango superior

95
• El control se logra comparando dónde estamos y dónde se supone que
debemos estar
• ¿Qué es el control? Saber donde estamos, cómo estamos, donde deberíamos estar
• ¿Qué se controla? Planificación, tareas, grado avance,..
• ¿Cómo se controla? Diferentes métodos
• ¿Cuáles son los componentes de un sistema de control?
• Depende de la herramienta utilizada para el control (horas imputadas por tarea,
componentes de software, dedicaciones, fechas,..)
– El control se ejerce de acuerdo a un Sistema de realimentación
PROCESO
REALIMENTACION
Entradas Salidas

96
• El control debe concebirse como información y no como poder (es necesario
que sea consultable por los miembros del equipo, sobretodo los analistas)
• Hay que controlar el trabajo por cumplimiento de objetivos, no a los
trabajadores
• Un directivo ejerce el control únicamente cuando todos y cada uno de los
miembros de la estructura de su equipo controlan su propio trabajo
• ¿Cómo delegar en las personas?
– Es necesario fomentar su COMPLICIDAD
– Se delegan tareas no responsabilidades
– Definición clara de lo que deben hacer cada uno de los miembros del
equipo (fechas inicio/fin, tiempo de ejecución, requerimientos bien definidos,
objetivos, como se relaciona su trabajo con el trabajo de los demás miembros del
equipo, ...)
– Un plan personal de cómo hacer el trabajo

97
– Supervisión/realimentación sobre los progresos (es muy importante
informar de los errores y corregirlos en el momento en que se descubren a las
personas que han realizado el trabajo para prevenir su repetición. Además
descubrir errores en fase de análisis es menos costoso que en fase de
construcción y aún menos costoso que en fase de puesta en marcha)
– Capacidades y recursos adecuados
– Definición clara de su autoridad
• La dirección de proyectos no es sólo un conjunto de herramientas, es también
una disciplina y sólo será un éxito si las personas están bien dirigidas

98
• No puede haber control si no se realiza una evaluación, y por lo tanto se cuenta con
medidas precisas
• El análisis de la varianza o valor acumulado mide el progreso de un proyecto
• Varianza es cualquier desviación respecto a un plan que debe ser sometida a
seguimiento
– Varianza de coste: compara desviaciones de coste real y presupuestado
– Varianza de programa: compara el trabajo planificado ya terminado con el
trabajo real
• Las variables para realizar las mediciones son
– Coste presupuestado del trabajo programado (CPTP)
– Coste presupuestado del trabajo realizado (CPTR)
– Coste real del trabajo realizado (CRTR)
• Varianza de coste = CPTR - CRTR
• Varianza de programa = CPTR - CPTP
C.3. Seguimiento y Control - Análisis del valor acumulado

99
C.3. Seguimiento y Control - Análisis del valor acumulado
Programado Realizado Programa Coste
TOTALES
Tarea Presupuest.
Ultima
estimación Varianza
Acumulado hasta la fecha A la finalización
Coste de Trabajo
presupuestado
Coste Real
Varianza
Preparado por Firmado por
Proyecto nº Descripción Fecha
Informe de situación del proyecto

100
C.3. Seguimiento y Control - Actividades de seguimiento (1/7)
• Orden de trabajo (lunes)
• Captura de información (jueves)
• Análisis del progreso (viernes)
• Valoración de problemas (viernes)
• Reuniones de seguimiento (quincena)
• Informe de seguimiento interno/externo (mensual)

101
• Orden de trabajo (lunes)
– Objetivos del trabajo
– Fechas previstas para su realización
– Persona que debe realizar la tarea
– Dedicaciones presupuestadas para la persona y tarea
– Encuadre de la tarea dentro del Desglose del Proyecto
– Especificaciones y requisitos

102
• Captura de información (jueves)
– Identificación de la persona
– Código de la tarea
– Dedicaciones consumidas
– Dedicaciones Pendientes
– Fecha de inicio real
– Fecha de fin real
– ¡¡Ojo a los cambios de requerimientos en fase de ejecución!!

103
• Análisis de progreso (viernes)
– Por cada tarea y proyecto completo
– Fechas de inicio y final previstos
– Fecha de comienzo real
– Fecha programada de finalización
– Dedicación presupuestada
– Dedicación consumida
– Responsable y resultado
– Calidad del producto

104
• Valoración de problemas (viernes)
– Analizar causas de los problemas y desviaciones
– Grado importancia en relación al proyecto
– Decidir acciones correctivas
– Impacto
– Prever desviaciones
– Detectar nuevos factores de riesgo

105
• Informe de seguimiento
– Comprensión general de los objetivos
– Conocimiento del progreso de tareas y de necesidades de coordinación
– Planificación más realista, adaptada a las nuevas necesidades
– Detección temprana de problemas potenciales y del retraso en el proyecto
– Valorar el grado de avance del proyecto
– Enumerar los cambios en los requerimientos del cliente que afectan a la
planificación, objetivos,..
– Enumerar los nuevos factores de riesgo y revisar el estado de los anteriores

106
• Reuniones de seguimiento
– Motivar a los participantes en la consecución de los objetivos (complicidad)
– Clarificar y coordinar los diferentes puntos de vista
– Resolver los conflictos planteados
– Revisar las prioridades de los trabajos
– Reconducir la marcha del proyecto
– Revisar el método de trabajo
– Analizar desviaciones y proponer alternativas de solución

107
C.4. Cierre

108
C.4. Cierre del Proyecto
¿Cuando puede darse por cerrado un proyecto?
• ¿Cuando se realiza el pase a producción?
• ¿Cuando se paga/cobra la última factura?
• ¿Cuando finaliza la garantía?
• ¿Cuando los temas pendientes se dejan para una Fase II?

109
C.4. Cierre del Proyecto - Proceso de Cierre
Cierre del
Contrato
Cierre del
Proyecto
Revisión
Post-
Proyecto

110
C.4. Cierre del Proyecto - Cierre del Contrato
• Asegurar que se han cumplido los requerimientos del contrato
• Terminar los entregables del contrato
• Identificar, documentar y resolver los temas pendientes derivados del
cierre del contrato
• Realizar la aceptación formal de la finalización del contrato (por parte
del cliente)
• Archivar la documentación del contrato

111
C.4. Cierre del Proyecto - Finalización formal del proyecto
• Comunicar el cierre del proyecto
• Actualizar el Plan de Recursos
• Recoger las métricas finales
• Completar la Revisión Final de Aseguramiento de la Calidad
• Actualizar estándares y procedimientos de la organización
• Realizar el cierre financiero
• Archivar el Plan del Proyecto

112
C.4. Cierre del Proyecto - Revisión Post-Proyecto
• Preparar la revisión a partir de los datos asociados a las expectativas del
cliente tanto de calidad, como de uso, como de Business Plan
• Realizar la revisión y documentarla.
• Comunicar el resultado de la misma, así como el plan de acciones
correctoras, si se ha detectado alguna.
• Cerrar/Prorrogar formalmente el período de garantía

APARTADO D
Gestión de la Calidad

D.0. Introducción
D.1. El proceso de mejora de la calidad. Modelos de referencia
D.2. Ejemplo de implantación en EDS Catalunya.
D.3. Plan de Calidad del proyecto
D.3.1 Plan de Calidad
D.3.2 Plan de Métricas
D.3.3 Plan de Gestión de Configuración
• Objetivo: Demostrar que las buenas prácticas asociadas a la Gestión de Proyectos,
emanan de un modelo de Gestión de Calidad completo y orientado a la ingeniería
del software, así cómo ver la materialización de algunas de dichas prácticas dentro
de los proyectos.
• Finalidad: Presentar dos modelos de referencia de gestión de calidad,
relacionando sus puntos débiles y fuertes desde el punto de vista de la gestión de
proyectos de software. Presentar los planes de proyecto relacionados con la
función de Aseguramiento de Calidad.
D. Gestión de la Calidad
Índice

“Calidad …..es algo que inventaron un día un grupo de empleados
aburridos y que consiste en generar papeles, muchos papeles,
cantidades ingentes de papeles….para justificar que se está
haciendo algo cuando en realidad no se hace nada”
-- Dilbert.
D.0 Introducción

 A todos los Gestores se les exige:
– Reducción de costes.
– Mayor productividad.
– Aprovechar las oportunidades del mercado global.
– Fidelizar las relaciones Cliente/Proveedor:
• Orientación a resultados: Acordes del nivel de servicio (SLA)
• Orientación al beneficio mutuo: Relaciones WIN-WIN
 No obstante el entorno profesional es cada vez más complejo
– Impacto creciente de les aplicaciones en el negocio
– Tiempo de desarrollo más corto.
– Visibilidad y control del proyecto: calendario, costes y defectos
– Herencia histórica:
• Poca documentación existente de procesos.
D.0 Introducción

Su mejora continua se mide a partir de las
variables: planificación / costes / defectos
PERSONAS TECNOLOGIA
“La calidad del SW viene directamente determinada por
la calidad de los procesos utilizado para su desarrollo”
PROCESOS
D.0 Introducción

¿Que procesos deben mejorarse?
• De gestión del proyecto:
• Planificación, Expectativas, Riesgos, Seguimiento, Cierre.
• De desarrollo:
• Análisis, Codificación, testing...
• De gestión de la configuración:
• Versiones, Control de cambios...
• De gestión de la calidad:
• Programa de Métricas, Calendario revisiones….
• De gestión de proveedores….
D.0 Introducción

Objetivo principal: tener un plan de gestión de la calidad para
• Empezar a dar pequeños pasos en la mejora de los procesos de software
• Mejorar la planificación del tiempo de entrega de un producto
• Tener el flujo de trabajo controlado
• Disminuir el coste de mantenimiento del SW
• Tener datos objetivos sobre el estado del producto en cada momento: Nivel de Calidad
D.0 Introducción

Algunos datos:
• Ratio del coste que se consume en la resolución de errores según la etapa de
ejecución del proyecto donde se descubre el error
D.0 Introducción
ETAPA COSTE RELATIVO RESOLUCIÓN
Definición requerimientos 1
Diseño 3.5
Desarrollo 10
Pruebas 50
Post-entrega 170
• Los errores de SW cuestan anualmente a la economía norteamericana (según datos
de junio del 2004):
62 billones de dólares

La Calidad: aspectos fundamentales
D.0 Introducción
Mejoras continuadas
del proceso
Procesos de
Alta calidad
Producto de
alta calidad
COMUNICACIÓN
• Micromejoras, porqué:
- Para que no sean imposibles
- Para que no se vean como imposibles
- Para que se entiendan
- Para que se puedan compatibilizar con el trabajo diario
• Comunicación, aspecto clave para el éxito:
- Explicar, aclarar y justificar (qué se va a hacer, porqué, cómo,..)
- A quién comunicar (equipo desarrollo, responsables superiores, usuarios)
- Comunicar y saber escuchar
- Persuadir, motivar, orientar,….

D.0. Introducción
D.1 Modelo de Referencia

 ¿ Por qué un modelo ?
 ¿ Qué modelo ?
1. ISO
International Organization Standardization
2. CMM
Software Capability Maturity Model

Modelo general de aseguramiento de la calidad del diseño, desarrollo,
producción, instalación y servicio post-venta. En consecuencia, para el
software, necesita ser complementado con guías específicas.
– ISO 9000-3: Guías para la aplicación de la ISO 9001 al desarrollo,
suministro y mantenimiento del SW.
– Otras guías prácticas de ayuda:
• TickIT: (UK) guía de ayuda a la interpretación de
estas.
• SEDISI: Guia para la Calidad según ISO 9001
ISO

• Amplio reconocimiento internacional
• Gran difusión en las TIC
– (a2000) cerca de 7000 certificaciones ww
• Frecuentemente por requerimientos de clientes
• Procesos Software, Hardware, Servicios….
• 20 Capítulos  Requisitos mínimos.

ISO

• Falta de detalle (genérico)
• Procesos de auditoria poco estandarizados
• Alineamiento objetivos  mayor orientación certificación
• La mejora ... de los propios capítulos de la norma

ISO

• SPICE  ISO 15504 (actual)
• Software Process Improvement and Capability
Etermination
» El objetivo de SPICE es el desarrollo de un estándart
internacional para la consultoría en procesos de software,
que permite determinar un plan de mejora de los
procesos, definiendo detalladamente los riesgos y
prioridades, de forma que se pueda determinar el nivel de
madurez de los procesos que componen el desarrollo de
sw.
» Tiene en cuenta la estrategia de negocio del usuario.
ISO

Capability Maturity Model
Define las etapas de evolución de una organización
a medida que progresivamente va:
Definiendo, gestionando, midiendo, y mejorando sus
procesos de desarrollo de software.
Originario del Software Engineering Institute (SEI) organización de
investigación y desarrollo de software, financiada por el Departamento de
Defensa de los Estados Unidos de América y gestionada por la Universidad
Carnegie Mellon de Pittsburg.
CMM


• Específico SW
• Con gran “rodaje”: evaluado y medido
• No orientado al “diploma”
• Proceso de auditoria:
– CBA-IPI (Common based appraisal for internal process improvement)
– no tan orientado “al pie de la letra” y más al
“comportamiento”
• Mayor detalle: 4 Niveles de madurez con áreas Clave
(18) que definen objetivos (52) y centenares de
prácticas.
CMM


• Sólo actividades Ing. Soft. (no Ing Sist, no Consult.)
• En proceso de difusión en UE
– (Jun 2002) Evaluaciones en ~1750 Org ww
• Soporte a objetivos de negocio
CMM
• SW CMM 1.1  CMMI 1.0 (Integrated CMM)
• Representación por etapas y también continua.
• Cobertura de actividades de Ing. Sistemas
• Revisión áreas clave, prácticas...

Dependencia exclusiva del esfuerzo personal, actuaciones “apagafuegos”, poca
integración de herramientas de soporte, etc...
1
INICIAL
Mejora continua.
5
OPTIMIZADO
Control estadístico del proceso.
4
GESTIONADO
Proceso organizativo estándar, planes de formación,
metodologías, etc.
3
DEFINIDO
Modelo básico de la gestión de proyectos, gestión de proveedores, gestión de
la configuración y calidad.
2
REPETIBLE
CMM

CMM
ACTIVITIES
KEY PRACTICES
CONTIENEN
DESCRIBEN
GOALS
KEY PROCESS AREAS
ESTRUCTURADOS EN AREAS
CLAVE (KPA)
ALCANZAN
COMMON FEATURES
IMPLANTATION
INSTITUTIONALIZATION
ORGANIZADOS EN
CARACTERÍSTICAS COMUNES
CONDUCEN
PROCESS
CAPABILITY
INDICAN
MATURITY LEVELS
NIVELES DE MADUREZ
Ejemplo: NIVEL=2
• Los cambios a los requisitos
se revisan y se incorporan al
proyecto…
•
• GOAL: Los planes,
productos y actividades se
mantienen consistentes con
los requisitos acordados.
• ...
REPETITIBILIDAD
IMPLANTATION
FOCUS = GESTIÓN DE PROYECTOS
• Gestión de Requisitos (RM)
• Gestión de Proyectos (SPP y SPTO)
• Aseguramiento de Calidad (SQA)
• Gestión de la Configuración (SCM)
• Gestión de la subcontratación (SSM)
• COMMITMMENT
• ABILITIES
• ACTIVITIES
• MEASUREMENT
• VERIFICATION

CMM versus SPICE
CMM SPICE
Modelo en dos dimensiones (procesos y
capacidades de estos procesos)
Modelo en una dimensión (define etapas de
evolución)
5 niveles de madurez
(inicial, repetible, definido, gestionado,
optimizado)
6 niveles de capacidad
(incomplete, performed, managed, established,
predictable, optimizing)
18 áreas clave (kpa: key practice areas) que
definen 52 objetivos y centenares de
practicas)
6 categorías de procesos con 238 tipos de
procesos
Se realizan auditorias para revisar el nivel Se realizan auditorias para revisar el nivel
CMM, certifica un nivel final para una
organización
SPICE, certifica para cada proceso un nivel
final, en un proyecto/área determinados

D.0. Introducción
D.2 Ejemplo de Implantación en EDS Cat.

INGENIERIA
DEL SOFTWARE
GESTIÓN DE
PROYECTOS
GSMS 2.0
SW-CMM 1.1
....
Objetivos de calidad
Proceso estándar EDS
Modelo avanzado de gestión de la calidad
D.2 Ejemplo de Implantación
Estrategia EDS

1. Mejora de la gestión de proyectos:
• Más visibilidad hacia los responsables y hacia la Dirección
• Mejor control del proceso - parámetros cuantitativos: métricas
2. Mejora del rendimiento:
• Reducción de defectos y incidencias en producción
• Mejor capacidad de aprendizaje a partir del proceso estándar
3. Mejora de los resultados:
• Conseguir o superar las expectativas del Cliente  credibilidad
• Aumentar el beneficio de EDS  éxito
Model avançat
de gestió de la calidad
ENGINYERIA
DE SOFTWARE
GESTIÓ DE
PROJECTES
GSMS2.0
SW-CMM 1.1
....
Objectius de calidad
Procés estàndard
EDS
Objetivos EDS

Model avançat
ENGINYERIA
DE SOFTWARE
GESTIÓ DE
PROJECTES
GSMS2.0
SW-CMM 1.1
....
Procés estàndard
EDS
 Modelo avanzado de mejora de los procesos corporativos.
 Grupo certificado de soporte:
 CMM Lead Assessors
 Soporte a la implantación
 EDS University ofrece formación CMM
 EDS CMM Assessment Framework
Self Assessment
Mentored Self Assessment
Mini-Assessment
 Interpretación detallada y global a través de GSMS
CMM a EDS

 Ciclos de vida predefinidos
 Plantillas para los documentos
 Roles y responsabilidades
 Herramientas de soporte
 Aseguramiento calidad
 Reporting y métricas
 Control de cambios
GSMS Proceso estándar EDS.
• Grupo de PPI (Performance & Productivity Improvement):
realiza el mantenimento y guía la mejora de GSMS
• Grupo de QA: realiza control y seguimiento de las actividades
Model avançat
ENGINYERIA
DE SOFTWARE
GESTIÓ DE
PROJECTES
GSMS2.0
SW-CMM 1.1
....
Procés estàndard
EDS
 Metodología gestión proyectos PM2
 Metodología desarrollo SLC3
 Metodología gestión de requisitos RDP
 Metodología gestión de riesgos
 etc...
MODELO DE
PROCESOS EDS
GSMS

?
Aseguramiento: GSMS - Proceso estándar EDS
Visión del Cliente
Control Procesos:
1. Autoevaluaciones
2. Auditorias
Control Resultados:
1. Puntos de control
2. Conformance R.
Cliente:
1. SLAs
Model avançat
ENGINYERIA
DE SOFTWARE
GESTIÓ DE
PROJECTES
GSMS2.0
SW-CMM 1.1
....
Procés estàndard
EDS
Proyectos

D.3 Plan de Calidad del proyecto
D.0. Introducción

• Identificación:
-objetivos del proyecto
-estándares y normativas aplicables
• Actividades para su cumplimiento
Planning
Calidad
Aseguramiento
Calidad
Control
Calidad
Gestión
Calidad
del Proyecto
Actividades orientadas a la
verificación del cumplimiento de
los objetivos del proyecto
contemplando productos de
ingeniería y gestión.
Monitorización de resultados para
determinar el cumplimiento
respecto al sistema de calidad, e
identificar defectos y
oportunidades de mejora
SI NO SABES DONDE IR….
NO HAY CARRETERA QUE TE
LLEVE….

Planificación de la Calidad
Inputs
• Política Calidad
• Descripción Proyecto
• SLA
• Objetivos del
proyecto
• Estándares y
normativas
Técnicas y herramientas
1. Diagramas de flujo
2. Análisis coste-beneficio
3. Benchmarking
4. ...
Outputs
• Plan de Calidad
del Proyecto
• Checklists
Planning
Calidad
–Objetivos proyecto analizados
–Estructura del equipo
–Responsabilidades
–Procedimientos
–Recursos necesarios
–Definiciones-Acepciones
-estándares y
normativas aplicables
• Actividades para su
cumplimiento
Planning
Calidad
Asegurami
ento
Calidad
Control
Calidad
Gestión
Calidad
del Proyecto
Actividades
orientadas a la
verificación del
cumplimiento de los
objetivos del
proyecto.
Monitorización de
resultados para
determinar el
cumplimiento respecto al
sistema de calidad, e

Aseguramiento de la Calidad
Inputs
• Plan de Calidad
del Proyecto
• Registros de las
pruebas,
auditorías,
control…
1. Auditorías de Calidad
2. Benchmarking
3. Costes de Calidad
4. ...
Outputs
• Mejoras de
calidad
Aseguramiento
Calidad
-estándares y
cumplimiento
Planning
Calidad
Asegurami
ento
Calidad
Control
Calidad
Gestión
Calidad
del Proyecto
Actividades
orientadas a la
verificación del
cumplimiento de los
objetivos del
proyecto.
Monitorización de
resultados para
determinar el
x
x

Control de la Calidad
Inputs
• Plan de Calidad del
Proyecto
• SLA
• Checklists
• Productos del
proyecto
1. Inspecciones y revisiones
2. Gráficas Charts, Pareto…
3. Diagramas de flujo
4. Análisis estadístico
5. ...
Outputs
• Mejoras de
calidad
• Checklists
completadas
• Gestión
incumplimientos
Control
Calidad
-estándares y
cumplimiento
Planning
Calidad
Asegurami
ento
Calidad
Control
Calidad
Gestión
Calidad
del Proyecto
Actividades
orientadas a la
verificación del
cumplimiento de los
objetivos del
proyecto.
Monitorización de
resultados para
determinar el

CheckPoints
¿ Cuando se realizan ?
Al final de cada fase (análisis, diseño, ...)
¿ Por parte de quien ?
Equipo del proyecto
¿ Cómo ?
Cuestionario establecido por etapa con los criterios a validar
FASE DE ORIGEN
FASE
DE
DETECCIÓN
EXPLOTACIÓN
Ejemplo: Evaluación de productos
Conformance Review
• En proyectos de nuevo desarrollo, antes de la entrega a cliente.
• En proyectos de mantenimiento, periódicamente - cada mes.
Equipo del proyecto conjuntamente con el Jefe de Proyecto
¿ Cómo ?
• Se verifica que todos los productos entregables son conformes a los requisitos
y libres de error.
• Se verifican todos los puntos de control o CheckPoints

Objetivo: Verificar de forma independiente la adecuación de las
actividades del proyecto a los estándares aplicables.
Periódicamente / “espontáneamente”
• Responsable: equipo de QA
• Participantes: auditores (equipo de QA), Project Manager y miembros equipo.
¿ Cómo ?
• Preparación: definición del ámbito
• Realización: entrevistas con el equipo de proyecto y análisis de evidencias.
• Reporting: evaluación, redacción de incumplimientos y mejoras
Ejemplo: Auditorías de Calidad

Me gusta el golf
Aunque necesitaría
mejorar mi técnica Así pues, me
“auditan”
el juego
Y quizás debo
hacer cosas,
que pueden parecer
no ‘ser de golf’
Pero, adoptándolas
a las características
de mi juego... Saqué dos hoyos
de ventaja…..
Ejemplo: Auditorías de Calidad

PLANIFICACIÓN
SEGUIMIENTO Y
ANÁLISIS
BALANCE Y
CIERRE
GESTIÓN
MÉTRICAS
PROYECTO
NO SE PUEDE CONTROLAR….
LO QUE NO SE PUEDE
MEDIR….

Planificación
Inputs
• Plan de Calidad del
Proyecto
• Programa de
Métricas
• Cuadro de Mando
PLANIFICA
CIÓN
SEGUIMIEN
TO Y
ANALISIS
BALANCE Y
REPOSITO
RIO
GESTIÓN
MÉTRICAS
PROYECTO
1. Goal Question Metric
2. Relación métricas primitivas
estándar
3. ...
Outputs
• Plan de Métricas
• ADAPTACIÓN DEL PROGRAMA
• MÉTRICAS
• PLANIFICACIÓN,
•INSTRUCCIONES DE
RECOLECCION,
•PERIODICIDAD,
•RESPONSABLE,
•REPORTING,
•ANALISIS Y
DISPARADORES
• Baseline
Planificación
Q1 Q2 Q3
m1 m2 m3 m4
G1

Seguimiento y análisis
Cumulative Open vs. Closed Issues
0
5
10
15
20
25
T1 T3 T5 T7 T9 T11
#
of
Issues
Opened
Closed
Inputs
• Baseline
PLANIFICA
CIÓN
SEGUIMIEN
TO Y
ANALISIS
BALANCE Y
REPOSITO
RIO
GESTIÓN
MÉTRICAS
PROYECTO
1. Repositorio de métricas
2. Control Estadístico
3. Benchmarking
4. Diagramas de flujo - Causa/Efecto
5. ....
Outputs
• Variabilidad
• Defectos
• Escalaciones
• ...
Seguimiento y
Análisis

Balance y cierre
PLANIFICA
CIÓN
SEGUIMIEN
TO Y
ANALISIS
BALANCE Y
REPOSITO
RIO
GESTIÓN
MÉTRICAS
PROYECTO
1. Repositorio de métricas
2. Control Estadístico
3. Benchmarking
4. Diagramas de flujo - Causa/Efecto
5. ....
Outputs
• Report proceso
• Repositorio
actualizado
Balance y
cierre
Inputs
• Baseline
Cumulative Open vs. Closed Issues
0
5
10
15
20
25
T1 T3 T5 T7 T9 T11
#
of
Issues
Opened
Closed

Ejemplo. Métrica: Size
• FP (Function Points) – medida del tamaño de las aplicaciones
en términos del número de funciones desde el punto de vista del
usuario.
• SLOC (Líneas de Código) – N° de instrucciones representativas
de la lógica del conjunto de programas software del producto
final.
• N° Páginas de documentación – medida para determinar el
tamaño de los productos documentales creados como soporte
al desarrollo y/o entregables.
BENEFICIOS CONCRETOS
• Factor que con las consideraciones tecnológicas adecuadas, puede
permitir establecer un referente histórico y/o internacional y hacer
posibles comparaciones y análisis.
• Proporciona el contexto necesario para expresar otras métricas
• …

• H (Horas) – Proporciona información (a través del seguimiento de
imputaciones) de ayuda a la determinación de la productividad
• Resulta de vital interés a clientes y proveedores por la derivación
directa de costes.
Ejemplo. Métrica: Esfuerzo
BENEFICIOS CONCRETOS
• Mejora de futuras estimaciones
• Evaluación de la productividad
• Validación de ‘best practices’ y procesos de mejora
• …

Gestion_de_Proyectos.ppt

Recomendados

Recomendados

Más contenido relacionado

Similar a Gestion_de_Proyectos.ppt

Similar a Gestion_de_Proyectos.ppt (20)

Más de ssuser73f459

Más de ssuser73f459 (16)

Último

Último (20)

Gestion_de_Proyectos.ppt