Eds Fib Feb06

Gestión de Proyectos
Profesores: LLuís Duran, Process Improvement
Febrero 2006
Gestión de Proyectos Informáticos
Programa
•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
Copyright © 2003 Electronic Data Systems Corporation. All rights

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

A. Introducción a la Gestión de Proyectos Informáticos
ÍNDICE
• 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

• A.2. Áreas a gestionar
• A.3. Elementos de la gestión
4
A. Introducción Gestión Proyectos
A.1. Objetivo de la gestión - ¿Cuál? (1/2)
COSTE
OBJETIVO
COSTE
TIEMPO
REQUISITOS
OBJETIVO
COSTE
OBJETIVO
TIEMPO
REQUISITOS
TIEMPO
REQUISITOS

A.1. Objetivo de la gestión - ¿Cuál? (2/2)
• 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.2. Áreas a gestionar - ¿Cómo?
Procesos
Personas Tecnología
7
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,
bonus/malus proveedor, garantías, formación…).
8
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.
9
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 10
A.3 Elementos de la Gestión
Comunica-
Contrato
ciones
Finanzas Riesgo
Calidad Alcance
Recursos Planificación
11
A.3. Elementos de la Gestión
• TRABAJO EN GRUPO - identificación de factores de éxito
12
APARTADO B
Creación del Plan de Proyecto

B. Creación del Plan de Proyecto
Í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.
• 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
14
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.
Com
P re s unic
acio
Equ upu nes
ipo esto
Plan Trab
Contrato Comunica- ifica ajo
ciones ción
Cali
dad
Finanzas Ries
Riesgo
gos
Exp
ecta
requ ti
erim vas y
ient
Calidad Alcance os
Com
pon
ente
s
Recursos Plan
Planificación
Pro
yec
to
15
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.
• Han de quedar perfectamente identificados los COSTE

objetivos de negocio que han decidido la realización
de dicho proyecto:
– Expectativas y Requisitos del cliente OBJETIVO
– Fecha límite de implantación asociada a motivos de negocio.
– Presupuesto aprobado para este proyecto.
TIEMPO
• Sobre todo, objetivos que no son misión de este proyecto
su consecución REQUISITOS
16
B.1. Ámbito del proyecto (2/6)
• Ejemplos:
• OBJETIVOS de negocio para realizar el proyecto
– Obtener una solución orientada única i 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 ala información muy costoso
– No estandarización de los procesos
17
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
18
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”.
19
• 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
20
Ejemplo de Matriz de Trazabilidad de Requerimientos:

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
Requirement #:
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
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 Design #:
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 21
UTC-003 X X X
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.
22
• 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.
23
• 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.
24
B.2. Valoración y Control (4/9)
Identificación de Riesgos
Valoración
de Riesgos Análisis de Riesgos
Priorización de Riesgos
Gestión de
Riesgos
Planificación de la Gestión
Control de
Riesgos Resolución de Riesgos
Monitorización de Riesgos
25
B.2. Gestión Riesgo: Identificación y Análisis (5/9)
• 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 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.
Valor Debo hacer algo? Cuando?

D Si Ahora
C Si Pronto
B Puede ser Revisar
A No Aparcar
26
B.2. Gestión Riesgo: Priorización (6/9)
Probability
“D”
“C”
D “B”
(Lejos
del “A”
Núcleo)
C
Riesgo con
alto Impacto
B
Primer
Proximidad Riesgo B
a mirar
A
C
D
B Riesgo de
(Cerca del Bajo Impacto
Núcleo) A
Estamos aquí Tiempo

27
B.2. Gestión Riesgo: Control y monitorización (7/9)
• 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.
28
B.2. Gestión Riesgo (8/9)
• TRABAJO EN GRUPO - identificación de riesgos
29
B.2. Gestión Riesgo: Trabajo en Grupo (9/9)
• 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.
30
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.
31
100 Fallos
80 Ahorro
Defectos
Tiempo, 60
Coste,
Esfuerzo 40
Testing
20
Prevención
0
Actual Futuro
• ¿Cuál es el coste de la Inversión? • ¿Vale la pena para este proyecto?
32
Costes de un proyecto =
C De Proyectos
Del desarrollo +
O
S De la implantación +
T Del mantenimiento
De Implantación Calidad
E
¿TIEMPO?
Porque es necesario una buena gestión de la cualidad:

• 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
33
• 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
34
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
35
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.
36
• 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.
37
38
39
B.7. Componentes - Gestión Equipo Trabajo (1/6)
• 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:
Definición de Roles y
Roles y Responsabilidades
Responsabilidades ‘Organizational Breakdown
Structure’
Plan de Recursos (Personas)

Requerimientos Relación de Conocimientos
de Plantilla Plan de Desarrollo del Equipo
Plan de Reconocimiento
Plan de Reasignación/
Infraestructura Adquisición de Recursos
40
• 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 Definidas por la versión vigente de GSCM y los estándares Jefe Proyecto
de requerimientos (RM) 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 S
S
Especialista en el Definidas por la versión vigente de GSCM y los estándares Jefe Proyecto
S
aseguramiento de calidad vigentes en el SC para la función del miembro del equipo. Analista B
S
(QA) Además:
-Participa en las revisiones del proceso y auditorías de QA
-Participa y puede liderar las revisiones de productos
Especialista en la gestión Definidas por la versión vigente de GSCM y los estándares Analista A
de configuración (CM) vigentes en el SC para la función del miembro del equipo. Analista B
Además: 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
41
• En el cuadro siguiente se muestra un ejemplo de una distribución roles/responsabilidades de
un proyecto:
Participantes en el Proyecto
Gerente Jefe AF’s Experto Direcc. Superv.
Tareas Gestión Cuenta Proy. AP’s Tecnol. Financ. Cliente
Establecer Equipo del Proyecto R S A S
Crear el Libro del Proyecto A R S S S
Elaborar el Plan del Proyecto R R S S C S
S S A
Establecer Relaciones Cliente R S S S S S
S
Definir el Alcance del Proyecto R S S S C S S
S A
Establecer el entorno de S
Dirección de Proyecto R S S A
C C S
Establecer el Proceso de
A R S S S S S
Gestión de la Configuración
Definir Procedim. Financieros R R A SS

Identificar Riesgo del Proyecto R S S S R I R SR
Anunciar Proyecto R A S
S S
S S
Revisar el Plan del Proyecto R S S S S
Clave 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
42
• 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...
Recursos Disponibles Enero Febrero Marzo Abril Mayo

JefeProyecto 1 1 1 1 1
JefeProyecto Pedro, Maribel Analistas 2 2 2 2 1
Analistas Isabel, Jordi, Alberto A/P 1 2 3 3 2
A/P Antonio Programadores 1 3 5 5 2
TOTAL EQUIVALENTE 5 8 11 11 6
Prog.Seniors Elena,Maria %Utilización 85% 90% 90% 90% 90%
Prog.Junior Felipe, Luis, Rosa, Eva TOTAL PERSONAS 5,88 8,89 12,22 12,22 6,67
Formación
Reconocimiento
Desarrollo de Carrera
al Empleado
• 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

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 46
TRABAJO EN GRUPO - elementos de un plan de comunicación
47
• 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.
48
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.
49
• Ejemplo del seguimiento económico de un proyecto planificado para el año 2004 al cerrar el mes de Febrero
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
• Estos datos, por si solos, noDiferencia 0,00

son indicativos de si el proyecto va3.000,00 -3.000,00
bien o no. Deben 0,00
analizarse conjuntamente con el0,00 0,00
resto de métricas 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%
50
• 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
51
APARTADO C
Ciclo de vida en la Gestión del Proyecto

C. Ciclo de vida de la Gestión de un Proyecto
Í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
• 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
53
C.0 Introducción
54
C.1. Definición ámbito y valoración esfuerzo
• ¿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
Estimación Estimación Estimación

tamaño esfuerzo planificación
•Puntos Función •Persona/mes •Número meses
•Desglose Tareas
Refinamiento de la planificación
55
C.1. Definición ámbito y valoración esfuerzo
• 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
56
C.1. Definición ámbito y valoración esfuerzo - PUNTOS FUNCION
• 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
57
• 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
58
• 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
59
Todas las estructuras de datos se agrupan en 5 tipos de función

SISTEMA DE INFORMACION
FICHEROS
INTERNOS
ENTRADAS SALIDAS
CONSULTAS FICHEROS
EXTERNOS 60
Clasificación individual de las estructuras de datos según la complejidad funcional
Por ejemplo:
Clasificación del tipo de función FLI (fichero lógico interno) según

complejidad funcional
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 2A5 (B)AJA (M)EDIA (A)LTA
REGISTRO 6 O MÁS (M)EDIA (A)LTA (A)LTA
61
Tipos de función Baja Media Alta
• Entradas 6 x 3 = 18 2x4 =8 3 x 6 = 18
• Salidas 7 x 4 = 28 7 x 5 = 35 0x7 =0
• Consultas 0x3 =0 2x4 =8 4 x 6 = 24
• Ficheros lógicos internos 5 x 7 = 35 2 x 10 = 20 3 x 15 = 45
• Ficheros de interfaz externos 9 x 5 = 45 0x7 =0 2 x 10 = 20
• Total PFD sin ajustar 304
Número de ocurrencias según Factor de peso fijo

complejidad funcional
62
Criterios de Ajuste para obtener el Grado de Influencia (GI)

• Comunicación de datos • Actualización interactiva
• Proceso distribuido • Complejidad de los procesos
• Rendimiento • Reutilización
• Configuraciones ampliamente utilizadas • Facilidad de instalación
• Volumen de transacciones • Facilidad de operación
• Entrada interactiva de datos • Ubicación múltiple
• Diseño orientado a la eficiencia del • Facilidad de cambios
usuario final
GIT =  GI
Tabla de valores para estimar el G.I. de cada criterio

0 - NO PRESENTA INFLUENCIA 3 - INFLUENCIA MEDIA
1 - INFLUENCIA INCIDENTAL 4 - INFLUENCIA SIGNIFICATIVA
2 - INFLUENCIA MODERADA 5 - INFLUENCIA FUERTE
63

Tipos de función Baja Media Alta
• Entradas 6 x 3 = 18 2x4 =8 3 x 6 = 18
• Salidas 7 x 4 = 28 7 x 5 = 35 0x7 =0
• Consultas 0x3 =0 2x4 =8 4 x 6 = 24
• Ficheros lógicos internos 5 x 7 = 35 2 x 10 = 20 3 x 15 = 45
• Ficheros de interfaz externos 9 x 5 = 45 0x7 =0 2 x 10 = 20
• Total PFD sin ajustar 304
• FAV = 0,65 + (0,01 x GIT) 1,15
• PFA = PFD * FAV 350
64
C.1. Definición ámbito y valoración esfuerzo - OTROS
• 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.
65
C.2. Planificación
66
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
67
C.2. Planificación
• La Planificación da respuesta a las siguientes preguntas
– Qué hay que hacer – Qué rendimiento se requiere
– Cómo debe hacerse – Qué puntos fuertes tiene
– Quién debe hacerlo – Qué puntos débiles
– Cuándo hay que hacerlo – Qué oportunidades
– Cuánto va a costar – Qué amenazas
– Cómo tiene que ser de bueno
• 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 68
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
69
C.2. Planificación - Deficiente gestión de cambios
Gestión de la Configuración
Los
Antídotos Alertar al equipo
de los peligros
Simplemente
decir “no” El
Pozo
Retrabajo en Insatisfacción
aumento del Cliente Beneficio
Planificación Coste Baja Calidad Reducido
Excedida Excedido
Baja Moral de Equipo
70
Fuente - Cursos PM2 EDS
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
71
C.2. Planificación – Desglose de Tareas
• 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
72
C.2. Planificación - Desglose de Tareas
• 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
73
C.2. Planificación - Desglose de Tareas Modelo
Nivel 2 PROYECTO
Nivel 3 FASE FASE FASE
Nivel 4 SUBFASE SUBFASE SUBFASE
Nivel 5 ACTIVIDAD ACTIVIDAD ACTIVIDAD
Nivel 6 TAREA
74
C.2. Planificación - Desglose de Tareas Ejemplo
REFORMA
Nivel 2 VIVIENDA
PINTURA SUSTITUCION
Nivel 3 INTERIOR DEL TEJADO JARDINERIA
Nivel 4 MOVER CUBRIR TAPAR QUITAR PLANTAR INSTALAR

MUEBLES SUELOS VENTANAS PINTAR ÁRBOLES ARBUSTOS RIEGO
Nivel 5 ELEGIR
PINTURA MEZCLAR APLICAR
75
C.2. Planificación - Desglose de Tareas Proyecto
Compra entradas
por cajero
Nivel 2
Análisis Construcción Puesta en marcha

Nivel 3
An. Modelo datos Entrada datos Salida

Nivel 4 datos
Pantalla Codificar programa Pruebas integradas

Nivel 5
Nivel 6 Dibujar pantalla
76
• 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, …
77
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
78
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
79
• Sistemas de Programación - Diagrama de GANTT

1997 1998 1999
WBS Title Early Finish Qtr 1 Qtr 2 Qtr 3 Qtr 4 Qtr 1 Qtr 2 Qtr 3 Qtr 4 Qtr 1 Qtr 2 Qtr 3
1.2.1 Upper Air 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.DSTA Design Technical Architecture 8/13/97
1.2.1.DSTA01 Define Impact on Current Environment 6/9/97
1.2.1.DSTA02 Define Hardware/Software Selection Criteria 6/17/97
1.2.1.DSTA03 Evaluate Hardware/Software

Alternatives 6/25/97
1.2.1.DSTA04 Specify Environment Selections/Configurations 8/5/97
1.2.1.DSTA05 CommitTechnicalArchitecture 8/13/97

1.2.1.DSAP01 Design Application 1/23/98
1.2.1.DSAP01 DesignApplicationArchitecture 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 Environ Interfaces & Support Functions 1/9/98
1.2.1.DSAP07 CommitApplication Designs 1/23/98

80
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
81
• Sistemas de Programación - PERT
E
B
G
A
D
F
C
AON
82
• Sistemas de Programación - CPM
OTM=0 OTM=20 OTM=35 OTM=49

OTR=0 OTR=25 OTR=35 OTR=49
CTM=0 CTM=20
CTR=5 CTR=25
A C
CTM=35
(20,2) (10,2) CTR=35
CTM=20 F
OTM=20 CTR=20 (14,2)
OTR=20
D
PRINCIPIO CTM=0 FIN
(15,5)
CTR=0
B CTM=20
(20,0) CTR=39
E
(10,2)
OTM: OCURRENCIA MÁS PRONTO POSIBLE CTM: COMIENZO MÁS PRONTO POSIBLE
OTR: OCURRENCIA MÁS TARDE POSIBLE CTR: COMIENZO MÁS TARDE POSIBLE
83
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
84
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
85
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
86
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
87
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
88
• 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
89
• 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
90
C.2. Planificación
• TRABAJO EN GRUPO - planificación proyecto
91
C.3. Seguimiento y Control
92
• 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
93
• 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
94
• 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
Entradas PROCESO Salidas
REALIMENTACION
95
• 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
96
– 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
97
C.3. Seguimiento y Control - Análisis del valor acumulado
• 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
98
C.3. Seguimiento y Control - Análisis del valor acumulado
Informe de situación del proyecto

Proyecto nº Descripción Fecha
Preparado por Firmado por
Acumulado hasta la fecha A la finalización

Coste de Trabajo
presupuestado Varianza Ultima
Tarea Programado Realizado Coste Real Programa Coste Presupuest. estimación Varianza
TOTALES
99
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)
100
• 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
101
• 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!!
102
• 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
103
• 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
104
• 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
105
• 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
106
C.4. Cierre
107
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?
108
C.4. Cierre del Proyecto - Proceso de Cierre
Revisión
Cierre del Cierre del
Post-
Contrato Proyecto
Proyecto
109
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
110
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
111
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
112
APARTADO D
Gestión de la Calidad

D. Gestión de la Calidad
Índice
• 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.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

D.0 Introducción
“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
“La calidad del SW viene directamente determinada por

la calidad de los procesos utilizado para su desarrollo”
PROCESOS
PERSONAS TECNOLOGIA
Su mejora continua se mide a partir de las

variables: planificación / costes / defectos

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
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

D.0 Introducción
La Calidad: aspectos fundamentales

Mejoras continuadas Procesos de Producto de
del proceso Alta calidad 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.1 Modelo de Referencia
D.0. Introducción

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

ISO
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.

CMM
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
• 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...

CMM
5
Mejora continua.
OPTIMIZADO
4
GESTIONADO Control estadístico del proceso.
3 Proceso organizativo estándar, planes de formación,

DEFINIDO metodologías, etc.
2 Modelo básico de la gestión de proyectos, gestión de proveedores, gestión de

REPETIBLE la configuración y calidad.
1 Dependencia exclusiva del esfuerzo personal, actuaciones “apagafuegos”, poca integración

INICIAL de herramientas de soporte, etc...

CMM
Ejemplo: NIVEL=2
NIVELES DE MADUREZ
FOCUS = GESTIÓN DE PROYECTOS
MATURITY LEVELS
MATURITY LEVELS • Gestión de Requisitos (RM)
INDICAN ESTRUCTURADOS EN AREAS • Gestión de Proyectos (SPP y SPTO)

CLAVE (KPA)
PROCESS • Aseguramiento de Calidad (SQA)
PROCESS KEY PROCESS AREAS
CAPABILITY KEY PROCESS AREAS
CAPABILITY • Gestión de la Configuración (SCM)
REPETITIBILIDAD
ORGANIZADOS EN • Gestión de la subcontratación (SSM)
ALCANZAN CARACTERÍSTICAS COMUNES
GOALS COMMON FEATURES
GOALS COMMON FEATURES
CONDUCEN
• COMMITMMENT
• GOAL: Los planes,
productos y actividades se IMPLANTATION • ABILITIES
IMPLANTATION CONTIENEN
INSTITUTIONALIZATION
mantienen consistentes con INSTITUTIONALIZATION • ACTIVITIES
los requisitos acordados. DESCRIBEN KEY PRACTICES
KEY PRACTICES
• MEASUREMENT
• ...
IMPLANTATION ACTIVITIES • VERIFICATION
ACTIVITIES
• Los cambios a los requisitos

se revisan y se incorporan al
proyecto…
•

CMM versus SPICE
CMM SPICE
Modelo en dos dimensiones (procesos y Modelo en una dimensión (define etapas de
capacidades de estos procesos) evolución)
5 niveles de madurez 6 niveles de capacidad

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

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

D.2 Ejemplo de Implantación
Estrategia EDS
Objetivos de calidad
Modelo avanzado de gestión de la calidad

SW-CMM
SW-CMM1.1
1.1
Proceso estándar EDS

GSMS
GSMS2.0
2.0
INGENIERIA
INGENIERIA
DEL
DELSOFTWARE
SOFTWARE
GESTIÓN
GESTIÓNDE
DE
PROYECTOS
PROYECTOS
....
....

Objetivos EDS
Objectius de calidad
Procés estàndard
EDS
SW-CMM 1.1
Model avançat
de gestió de la calidad
GSMS 2.0
ENGINYERIA
GESTIÓ DE
DE
PROJECTES
SOFTWARE
....
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

CMM a EDS
Procés estàndard
EDS
SW-CMM 1.1
Model avançat
GSMS 2.0
ENGINYERIA
GESTIÓ DE
DE
PROJECTES
SOFTWARE
....
 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

GSMS
GSMS Proceso estándar EDS.

Procés estàndard
EDS
SW-CMM 1.1
Model avançat
GSMS 2.0
ENGINYERIA
GESTIÓ DE
DE
PROJECTES
SOFTWARE
....
MODELO DE  Ciclos de vida predefinidos

PROCESOS EDS  Plantillas para los documentos
 Roles y responsabilidades
 Metodología gestión proyectos PM2  Herramientas de soporte
 Metodología desarrollo SLC3  Aseguramiento calidad
 Metodología gestión de requisitos RDP  Reporting y métricas
 Metodología gestión de riesgos
 Control de cambios
 etc...
• 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
Proyectos
Procés estàndard
EDS
SW-CMM 1.1
Model avançat
GSMS 2.0
ENGINYERIA
GESTIÓ DE
DE
PROJECTES
SOFTWARE
....
Aseguramiento: GSMS - Proceso estándar EDS
Control Procesos: Control Resultados: Cliente:

1. Autoevaluaciones 1. Puntos de control 1. SLAs
2. Auditorias 2. Conformance R.
Visión del Cliente

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

Gestión
Calidad
del Proyecto
• Identificación:
-objetivos del proyecto
Planning -estándares y normativas aplicables
Calidad
• Actividades para su cumplimiento

SI NO SABES DONDE IR….
NO HAY CARRETERA QUE TE
Actividades orientadas a la
LLEVE…. verificación del cumplimiento de
Control
Calidad los objetivos del proyecto
contemplando productos de
ingeniería y gestión.
Monitorización de resultados para

Aseguramiento determinar el cumplimiento
Calidad
respecto al sistema de calidad, e
identificar defectos y
oportunidades de mejora

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

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

Ejemplo: Evaluación de productos
EXPLOTACIÓN
CheckPoints
¿ Cuando se realizan ?
FASE DE DETECCIÓN
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
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
Ejemplo: Auditorías de Calidad
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
Aunque necesitaría
mejorar mi técnica Así pues, me
Me gusta el golf
“auditan”
el juego
Y quizás debo
hacer cosas, Pero, adoptándolas
que pueden parecer a las características
no ‘ser de golf’
de mi juego... Saqué dos hoyos
de ventaja…..

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

Planificación
GESTIÓN
MÉTRICAS
PROYECTO
PLANIFICA
CIÓN G1
G1
1. Goal Question Metric
Q1
Q1 Q2
Q2 Q3
Q3
SEGUIMIEN
TO Y
ANALISIS
2. Relación métricas primitivas m1

m1 m2
m2 m3
m3 m4
m4
BALANCE Y
REPOSITO
estándar
RIO
3. ...
Outputs
Inputs
• Plan de Métricas
• Plan de Calidad del • ADAPTACIÓN DEL PROGRAMA
Proyecto • MÉTRICAS
•
• Programa de PLANIFICACIÓN,
Métricas Planificación •INSTRUCCIONES DE

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

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

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
• …
Ejemplo. Métrica: Esfuerzo
• 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.
• Mejora de futuras estimaciones
• Evaluación de la productividad
• Validación de ‘best practices’ y procesos de mejora
• …

Ejemplo. Métrica: Staff
• NUM. Personas – Número de personas asignadas a un proyecto

durante un periodo determinado.
• Fuertemente relacionada con Esfuerzo y Duración, proporciona
visibilidad respecto a la relación COSTE / CALIDAD / TIEMPO.
• Mejora de la planificación y seguimiento del proyecto:
• Dimensionamiento
• Velocidad de cambios (altas/bajas) en el equipo
• …

Ejemplo. Métrica: Duración
• DIAS / HORAS – Proporciona información necesaria para la

estimación y control de las actividades
• Resulta de vital interés a clientes y proveedores por la derivación
directa del tiempo de implantación.
• Mejora en la estimación, medida y análisis del ciclo de vida de desarrollo:
• Etapas
• Actividades
• …

Ejemplo. Métrica: Defectos
• NUM DEFECTOS – Proporciona información para la evaluación de

la calidad y de la fiabilidad de los productos.
• El análisis de defectos proporciona comprensión del proceso de
desarrollo, facilitando la focalización de acciones.
• Mejora de la calidad y de la satisfacción del cliente.
• Mejora de la información en cuanto a la eficiencia del proceso de desarrollo.
• Ayuda a la determinación de acciones de mejora.
• …

Ejemplo. Métrica: Cambios
• NUM. CAMBIOS – Proporciona información de los cambios que

experimenta un proyecto a lo largo del tiempo, facilitando su control y
gestión.
• Proporciona una medida de la volatilidad (frecuencia de cambio) de un
sistema respecto a los requisitos.
• Medida del impacto por cambios de requerimientos en el proyecto.
• Mejora de la información en cuanto a la eficiencia del proceso de cambios.
• Ayuda a la determinación de acciones de mejora.
• …

Métricas informales en entornos no CMM
• Pizza Productivity Metric – número de cajas de pizza por persona-

hombre, como medida del sobreesfuerzo necesario del equipo delante
de una mala estimación del proyecto.
• Aspirin Metric – medida del estrés del equipo durante el desarrollo del
proyecto expresado en número de aspirinas tomadas.
• Beer Metric – número de invitaciones a cañas de cerveza los Viernes

tarde, como indicador del factor de frustración del equipo.

Objetivo: La Gestión de Configuración define una serie de

procesos y actividades encaminadas a gestionar la
evolución de los Sistemas de Información a lo largo de su
ciclo de vida completo, de forma que en todo momento
pueda conocerse su estado.
En el Plan….contemplamos y describimos las actividades y

características particulares dentro del proyecto en cuanto a:
a) CONTROL DE LA CONFIGURACIÓN,
b) CONTROL DE CAMBIOS,
c) GESTIÓN DE LOS REPOSITORIOS Y BASELINES.

Procesos
•...
•Diseño Técnico
Producto ACTIVIDADES DE DESARROLLO •Programación
•...
Producto 2. Cambios: Producto •Código fuente

• ¿ Como se modifican •Clases
los productos ?
•...
1. Configuración:
• ¿ Que Baselines?
• ¿ Que productos pertenecen Extracción Inserción
a cada baseline ?
•Fase Beta Testing

Baseline 1
Baseline 2 •...
...
Baseline N
3. Gestión de los repositorios y baselines:

• ¿ Es coherente, completa, etc.. la baseline ?
• ¿ Esta definida la función de seguridad de acceso ?
Control de la Configuración
Actividades principales
 Identificación de los elementos de configuración.

Se entiende por configuración, el conjunto de PRODUCTOS o elementos que definen un
sistema. En esta actividad se determina cuáles de ellos serán productos del sistema tanto
iniciales, como intermedios y finales.
 Codificación de los elementos de configuración.

Los elementos de configuración y su documentación asociada, deben de poder ser
identificados en todo momento según una codificación que cumpla ciertos requisitos
como simplicidad, unicidad y auto-explicación.
 Identificación de las líneas de base y de los repositorios que las contendrán.

El plan de gestión de configuración establece qué líneas de referencia (en qué etapas o
fases), y los repositorios que las contendrán junto con sus propiedades de acceso.

Control de cambios
 Gestión de cambios.
Delante de cambios, se aplican los procedimientos predefinidos de extracción y inserción.
 Análisis de impacto.
Identificación de las áreas y elementos del proyecto a las que puede afectar un cambio y
de qué manera.
 Evaluación de cambios.
Actividades de decisión sobre la viabilidad y conveniencia de la implantación de un
cambio (CCB – Comité de control de cambios)
 Seguimiento e implantación de los cambios autorizados.

Una vez que la orden de cambio a la línea base ha sido autorizada por el CCB, el
responsable del proyecto realiza la planificación y seguimiento de las actividades
necesarias para su implantación.

Gestión de los repositorios y baselines
 Creación y organización de los repositorios.

 Establecimiento de las medidas de seguridad a aplicar.
 Verificación y Auditorías periódicas a las baselines para asegurar su completitud y
coherencia.
 Seguimiento de las actividades, accesos, versiones, etc..

Ejemplo: Elementos de Configuración
– Production Support
• Software de la aplicación (código, BBDD, datos, etc.)
• Requisitos del Cliente (peticiones)
– Development +
• Software de la aplicación (código, BBDD, datos, etc.)
• Requisitos del Cliente (peticiones)
• Análisis funcionales
• Diseños técnicos
– Project Workbook, se controlan las versiones y se documentan

cambios y estado del documento, pero en general, no se
identifica como elemento de configuración.

eds.com
Lluís Duran Alsina – Lluis.Duran@eds.com

Eds Fib Feb06

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Eds Fib Feb06

Încărcat de

Drepturi de autor:

Formate disponibile

Gestión de Proyectos

Profesores: LLuís Duran, Process Improvement

•A. Introducción Gestión Proyectos Informáticos

Copyright © 2003 Electronic Data Systems Corporation. All rights

Introducción Gestión Proyectos Informáticos

Copyright © 2003 Electronic Data Systems Corporation. All rights

• Objetivo: obtener una visión básica de los

• A.1. Objetivo de la gestión

Copyright © 2003 Electronic Data Systems Corporation. All rights

• OBJETIVO: garantizar la satisfacción del cliente y

Copyright © 2003 Electronic Data Systems Corporation. All rights

• TRABAJO EN GRUPO - identificación de factores de éxito

Creación del Plan de Proyecto

Copyright © 2003 Electronic Data Systems Corporation. All rights

• Finalidad: ser conscientes de que antes de iniciar la

• El Plan de Proyecto es un conjunto de planes para cada elemento a gestionar,

• Determinar la dimensión de los tres ejes que definen el objetivo de un

• Han de quedar perfectamente identificados los COSTE

• En este capítulo del Plan de Proyecto deben recogerse:

• Una buena gestión de requerimientos, y en función de la envergadura del

Ejemplo de Matriz de Trazabilidad de Requerimientos:

Application Design Specifications (oam_ads.doc - Version 1.0)

Technical Architecture Specifications (oam_tas.doc - Version 1.0)

Formal Acceptance Test Specifications (oam_fat_tsp.doc - Version 1.0)

Unit Test Cases (UTC)

• Por que es necesaria la gestión del Riesgo?

• 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.

• Identificación de los Riesgos

Valor Debo hacer algo? Cuando?

Estamos aquí Tiempo

• Planificación de la gestión de riesgos

• TRABAJO EN GRUPO - identificación de riesgos

• Problemas más comunes en proyectos de desarrollo de Software

• Dentro del Plan de Proyecto de calidad deben contemplarse tres aspectos

• ¿Cuál es el coste de la Inversión? • ¿Vale la pena para este proyecto?

Porque es necesario una buena gestión de la cualidad:

• Para poder evaluar la calidad del proyecto es necesario disponer de medidas

Ejemplo del plan de métricas básicas para el proyecto

Plan de Recursos (Personas)

Función Responsabilidades Persona(s)

Definir Procedim. Financieros R R A SS

Clave R = Responsable del Proceso

Enero Febrero Marzo Abril Mayo

Copyright © 2003 Electronic Data Systems Corporation. All rights

• En el momento de la asignación de personas a las diferentes funciones derivadas de la planificación del

Recursos Disponibles Enero Febrero Marzo Abril Mayo

• Dentro de estos recursos hay que contemplar:

Copyright © 2003 Electronic Data Systems Corporation. All rights

Los elementos a considerar para crear un plan eficaz de comunicaciones son:

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

• Estos datos, por si solos, noDiferencia 0,00

• Ejemplo del seguimiento de las métricas del proyecto

Ciclo de vida en la Gestión del Proyecto

Copyright © 2003 Electronic Data Systems Corporation. All rights

• Objetivo: Describir las cuatro etapas del ciclo de vida de la

• ¿Cómo se lleva a cabo la estimación de un proyecto de software?

Estimación Estimación Estimación

• Definición del ámbito

• Es una medida sintética bastante exacta para medir el tamaño de un Sistema de

– Calcular PF desajustados (PFD)

– Calcular Factor Ajuste del Valor (FAV)