Eds Fib Feb06

Gestión de ProyectosGestión de Proyectos

Profesores: LLuís Duran, Process Improvement

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


APARTADO AAPARTADO A

Introducción Gestión Proyectos Informáticos


4

ÍNDICEA. 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

TIEMPOREQUISITOS

OBJETIVO

COSTE

TIEMPOREQUISITOS

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)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, bonus/malus 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

RiesgoFinanzas

Contrato

Recursos


12

A.3. Elementos de la Gestión

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



APARTADO BAPARTADO 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.

ComunicacionesPresupuesto

Equipo TrabajoPlanificaciónCalidad

Riesgos Expectativas y requerimientos

ComponentesPlan

Proyecto

Comunica-ciones

Calidad Alcance

Planificación

RiesgoFinanzas

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)B. Creación del Plan de Proyecto

• 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


18

B.1. Gestión Expectativas (3/6)B. Creación del Plan de Proyecto

• 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)B. Creación del Plan de Proyecto

• 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 #:

RD

1

RD

1.1

RD

1.1.1

RD

1.1.2

RD

1.1.3

RD

1.1.4

RD

1.1.5

RD

1.1.6

RD

1.1.7

RD

1.1.8

RD

1.1.9

RD

2

RD

3

RD

4

RD

5

RD

6

RD

7

RD

7.1

RD

7.1.1

RD

7.1.2

RD

7.2

RD

7.3

RD

8

RD

8.1

RD

8.2

RD

8.3

RD

9

RD

9.1

RD

9.2

RD

10

RD

11

RD

12

RD

13

Application Design Specifications (oam_ads.doc - Version 1.0)AD1.0 XAD2.0 X X X X X X X X

Technical Architecture Specifications (oam_tas.doc - Version 1.0)TAS-1 XTAS-2 X

Formal Acceptance Test Specifications (oam_fat_tsp.doc - Version 1.0)FATC-1 XFATC-2 X

Application Design #:

AD

1.0

AD

2.0

AD

2.1

AD

2.2

AD

2.3

AD

2.4

AD

2.5

AD

3.0

AD

3.1

AD

3.2

AD

3.3

AD

3.4

AD

3.5

AD

3.6

AD

3.7

AD

3.8

AD

3.9

AD

3.10

AD

3.11

AD

4.0

AD

5.0

AD

6.0

AD

6.1

AD

6.2

Application Componentsufusr Xufusr_ask_unload Xoam_ui_mgr_invoke Xoam_ui_mgr_initialize Xoam_ui_mgr_cleanup Xoam_ui_mgr_list_errors Xoam_ui_mgr_const_cb Xoam_ui_mgr_operation_cb X

Unit Test Cases (UTC)UTC-001 X X XUTC-002 X X X XUTC-003 X X X


22

B.2. Gestión Riesgos (1/9)B. Creación del Plan de Proyecto

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

Valoración de Riesgos

Control deRiesgos

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 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 AhoraC Si ProntoB Puede ser RevisarA No Aparcar


Riesgo con Riesgo con alto Impactoalto Impacto

27

B.2. Gestión Riesgo: Priorización (6/9)


Tiempo Tiempo Estamos aquíEstamos aquí

Primer Primer Riesgo Riesgo a mirara mirar

Riesgo de Riesgo de Bajo ImpactoBajo Impacto(Cerca del(Cerca del

Núcleo)Núcleo)

(Lejos (Lejos del del

Núcleo)Núcleo)

““D”D”

““C”C”

““B”B”

““A”A”

ProbabilityProbability

D

C

C

B

B

B

D

A

A

ProximidadProximidad


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

Fallos100

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

¿ T I E M P O ?

Costes de un proyecto =

Del desarrollo +

De la implantación +

Del mantenimiento

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


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

Infraestructura Plan de Reasignación/Adquisición de Recursos

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

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:-Participa en las revisiones del proceso y auditorías de QA-Participa y puede liderar las revisiones de productos

Jefe ProyectoAnalista B

Especialista en la gestión de configuración (CM)

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:-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 AAnalista 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 AEstablecer 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 deDirecció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ónGerenteCuenta

JefeProy.

AF’sAP’s

ExpertoTecnol.

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

Analistas 2 2 2 2 1A/P 1 2 3 3 2

Programadores 1 3 5 5 2TOTAL 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 MayoJefeProyecto 1 1 1 1 1

Analistas 2 2 2 2 1A/P 1 2 3 3 2

Programadores 1 3 5 5 2TOTAL 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 DisponiblesJefeProyecto Pedro, Maribel

Analistas Isabel, Jordi, AlbertoA/P Antonio

Prog.Seniors Elena,MariaProg.Junior Felipe, Luis, Rosa, Eva

Reconocimientoal 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

Enero Febrer Marzo Abril Mayo Junio Julio Agosto Septiembre Octubre Noviembre Diciembre Total

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 proyectoEnero Febrer Marzo Abril Mayo Junio Julio Agosto Septiembre Octubre Noviembre Diciembre Total

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 CAPARTADO 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ónC. Ciclo de vida de la Gestión de un Proyecto


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 esfuerzoC. Ciclo de vida de la Gestión de un Proyecto


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 FUNCIONC. Ciclo de vida de la Gestión de un Proyecto


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

C.1. Definición ámbito y valoración esfuerzo - PUNTOS FUNCION



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

C. Ciclo de vida de la Gestión de un ProyectoC.1. Definición ámbito y valoración esfuerzo - PUNTOS FUNCION


60

SALIDAS

CONSULTAS FICHEROSEXTERNOS

Todas las estructuras de datos se agrupan en 5 tipos de función

C. Ciclo de vida de la Gestión de un ProyectoC.1. Definición ámbito y valoración esfuerzo - PUNTOS FUNCION

ENTRADAS

FICHEROSINTERNOS

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

C.1. Definición ámbito y valoración esfuerzo - PUNTOS FUNCIONC. Ciclo de vida de la Gestión de un Proyecto

• 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. Ciclo de vida de la Gestión de un ProyectoC.1. Definición ámbito y valoración esfuerzo - OTROS


66

C.2. PlanificaciónC. Ciclo de vida de la Gestión de un Proyecto


67


• 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


• 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


• 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 cambiosC. Ciclo de vida de la Gestión de un Proyecto

Insatisfaccióndel Cliente

LosAntídotos

ElPozo

PlanificaciónExcedida

CosteExcedido

BeneficioReducido

Baja Moral de Equipo

Retrabajo enaumento

Baja Calidad

Gestión de la Configuración

Alertar al equipode los peligros

Simplementedecir “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 TareasC. Ciclo de vida de la Gestión de un Proyecto


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 TareasC. Ciclo de vida de la Gestión de un Proyecto


74

C.2. Planificación - Desglose de Tareas ModeloC. Ciclo de vida de la Gestión de un Proyecto

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 EjemploC. Ciclo de vida de la Gestión de un Proyecto

PINTURA INTERIOR

SUSTITUCIONDEL TEJADO

MOVERMUEBLES

CUBRIRSUELOS PINTAR

ELEGIR

PINTURA MEZCLAR APLICAR

REFORMAVIVIENDA

JARDINERIA

Nivel 2

Nivel 3

Nivel 4

Nivel 5

TAPARVENTANAS

QUITARÁRBOLES

INSTALARRIEGO

PLANTARARBUSTOS


76

C.2. Planificación - Desglose de Tareas Proyecto C. Ciclo de vida de la Gestión de un 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, …

C.2. Planificación - Desglose de Tareas C. Ciclo de vida de la Gestión de un Proyecto


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

C.2. Planificación - Desglose de Tareas C. Ciclo de vida de la Gestión de un Proyecto

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 proyectoC. Ciclo de vida de la Gestión de un 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 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 Work 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 Commit Technical Architecture 8/13/97

1.2.1.DSAP01 Design Application 1/23/98

1.2.1.DSAP01 Design Application 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 Design Application Logic 12/18/97

1.2.1.DSAP05 Design Application Interfaces 1/9/98

1.2.1.DSAP06 Design Environ Interfaces & Support Functions 1/9/98

1.2.1.DSAP07 Commit Application Designs 1/23/98

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 31997 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=0OTR=0

OTM=20OTR=25

OTM=35OTR=35

OTM=49OTR=49

CTM=0CTR=5

CTM=20CTR=25

CTM=35CTR=35

CTM=20CTR=20

CTM=0CTR=0

CTM=20CTR=39

OTM=20OTR=20

OTM: OCURRENCIA MÁS PRONTO POSIBLEOTR: OCURRENCIA MÁS TARDE POSIBLE

CTM: COMIENZO MÁS PRONTO POSIBLECTR: COMIENZO MÁS TARDE POSIBLE

• Sistemas de Programación - CPM


84

C.2. Planificación - Cálculo de la programaciónC. Ciclo de vida de la Gestión de un Proyecto

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 planificadorC. Ciclo de vida de la Gestión de un Proyecto

• 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 C. Ciclo de vida de la Gestión de un Proyecto

• TRABAJO EN GRUPO - planificación proyecto


92

C.3. Seguimiento y ControlC. Ciclo de vida de la Gestión de un Proyecto


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

C.3. Seguimiento y Control


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 acumuladoC. Ciclo de vida de la Gestión de un Proyecto


99

C.3. Seguimiento y Control - Análisis del valor acumuladoC. Ciclo de vida de la Gestión de un Proyecto

Programado Realizado Programa Coste

TOTALES

Tarea Presupuest.Ultima

estimación Varianza

Acumulado hasta la fecha A la finalizaciónCoste de Trabajo presupuestado

Coste RealVarianza

Preparado por Firmado por

Proyecto nº Descripción FechaInforme de situación del proyecto


100

C.3. Seguimiento y Control - Actividades de seguimiento (1/7)C. Ciclo de vida de la Gestión de un Proyecto

• 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

C.3. Seguimiento y Control - Actividades de seguimiento (4/7)


• 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

C.3. Seguimiento y Control - Actividades de seguimiento (5/7)


• 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 ProyectoC. Ciclo de vida de la Gestión de un 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 CierreC. Ciclo de vida de la Gestión de un Proyecto

Cierre delContrato

Cierre delProyecto

RevisiónPost-

Proyecto


110

C.4. Cierre del Proyecto - Cierre del ContratoC. Ciclo de vida de la Gestión de un Proyecto

• 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 proyectoC. Ciclo de vida de la Gestión de un 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 DAPARTADO D

Gestión de la Calidad


D.0. IntroducciónD.1. El proceso de mejora de la calidad. Modelos de referenciaD.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étricasD.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ÍndiceD. 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ónD.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.



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



¿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….



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



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


La Calidad: aspectos fundamentales


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.1 Modelo de ReferenciaD.1 Modelo de Referencia


¿ Por qué un modelo ?

¿ Qué modelo ?

1. ISO International Organization Standardization

2. CMM Software Capability Maturity Model

D.1 Modelo de ReferenciaD.1 Modelo de Referencia


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

D.1 Modelo de ReferenciaISOD.1 Modelo de ReferenciaISO


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

D.1 Modelo de Referencia ISOD.1 Modelo de Referencia 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

D.1 Modelo de Referencia ISOD.1 Modelo de Referencia 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.

D.1 Modelo de ReferenciaISOD.1 Modelo de ReferenciaISO


Capability Maturity Model

Define las etapas de evolución de una organizacióna 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.

D.1 Modelo de ReferenciaCMMD.1 Modelo de ReferenciaCMM


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



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


Dependencia exclusiva del esfuerzo personal, actuaciones “apagafuegos”, poca integración de herramientas de soporte, etc...

1INICIAL

Mejora continua.5

OPTIMIZADO

Control estadístico del proceso.4

GESTIONADO

Proceso organizativo estándar, planes de formación, metodologías, etc.

3DEFINIDO

Modelo básico de la gestión de proyectos, gestión de proveedores, gestión de la configuración y calidad.

2REPETIBLE




ACTIVITIESACTIVITIES

KEY PRACTICESKEY PRACTICES

CONTIENEN

DESCRIBEN

GOALSGOALS

KEY PROCESS AREASKEY PROCESS AREAS

ESTRUCTURADOS EN AREASCLAVE (KPA)

ALCANZAN

COMMON FEATURESCOMMON FEATURES

IMPLANTATIONINSTITUTIONALIZATION

IMPLANTATIONINSTITUTIONALIZATION

ORGANIZADOS EN CARACTERÍSTICAS COMUNES

CONDUCEN

PROCESSCAPABILITY

PROCESSCAPABILITY

INDICAN

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


D.1 Modelo de ReferenciaCMM versus SPICED.1 Modelo de ReferenciaCMM versus SPICE

CMM SPICEModelo 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.2 Ejemplo de Implantación en EDS Cat.D.2 Ejemplo de Implantación en EDS Cat.


INGENIERIADEL SOFTWARE

INGENIERIADEL SOFTWARE

GESTIÓN DEPROYECTOS

GESTIÓN DEPROYECTOS

GSMS 2.0GSMS 2.0

SW-CMM 1.1SW-CMM 1.1

........

Objetivos de calidad

Proceso estándar EDS

Modelo avanzado de gestión de la calidad

D.2 Ejemplo de ImplantaciónEstrategia EDSD.2 Ejemplo de ImplantaciónEstrategia 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

ENGINYERIADE SOFTWARE

GESTIÓ DEPROJECTES

GSMS 2.0

SW-CMM 1.1

....

Objectius de calidad

Procés estàndard

EDS

D.2 Ejemplo de ImplantaciónObjetivos EDSD.2 Ejemplo de ImplantaciónObjetivos EDS


Model avançat



GESTIÓ DEPROJECTES

GSMS 2.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 FrameworkSelf AssessmentMentored Self AssessmentMini-Assessment

Interpretación detallada y global a través de GSMS

D.2 Ejemplo de ImplantaciónCMM a EDSD.2 Ejemplo de ImplantaciónCMM 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



GESTIÓ DEPROJECTES

GSMS 2.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

D.2 Ejemplo de ImplantaciónGSMSD.2 Ejemplo de ImplantaciónGSMS


?

Aseguramiento: GSMS - Proceso estándar EDS

Visión del Cliente

Control Procesos:1. Autoevaluaciones2. Auditorias

Control Resultados:1. Puntos de control2. Conformance R.

Cliente:1. SLAs

Model avançat



GESTIÓ DEPROJECTES

GSMS 2.0

SW-CMM 1.1

....


Procés estàndard

EDS

D.2 Ejemplo de ImplantaciónProyectosD.2 Ejemplo de ImplantaciónProyectos


D.3 Plan de Calidad del proyectoD.3 Plan de Calidad del proyecto




D.3.1 Plan de CalidadD.3.1 Plan de Calidad

• Identificación:-objetivos del proyecto-estándares y normativas aplicables

• Actividades para su cumplimiento

PlanningCalidad

Aseguramiento Calidad

Control Calidad

GestiónCalidad

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


D.3.1 Plan de CalidadPlanificación de la CalidadD.3.1 Plan de CalidadPlanificación de la Calidad

Inputs• Política Calidad• Descripción Proyecto• SLA• Objetivos del

proyecto• Estándares y

normativas

Técnicas y herramientas1. Diagramas de flujo

2. Análisis coste-beneficio

3. Benchmarking

4. ...

Outputs• Plan de Calidad

del Proyecto

• Checklists

PlanningCalidad

–Objetivos proyecto analizados

–Estructura del equipo

–Responsabilidades

–Procedimientos

–Recursos necesarios

–Definiciones-Acepciones



PlanningCalidad

Aseguramiento

Calidad

Control Calidad

GestiónCalidad

del Proyecto

Actividades orientadas a la verificación del cumplimiento de los objetivos del proyecto.



D.3.1 Plan de CalidadAseguramiento de la CalidadD.3.1 Plan de CalidadAseguramiento de la Calidad

Inputs• Plan de Calidad

del Proyecto

• Registros de las pruebas, auditorías, control…

Técnicas y herramientas1. Auditorías de Calidad

2. Benchmarking

3. Costes de Calidad

4. ...

Outputs

• Mejoras de calidad

Aseguramiento Calidad



PlanningCalidad

Aseguramiento

Calidad

Control Calidad

GestiónCalidad

del Proyecto



xx

xx


D.3.1 Plan de CalidadControl de la CalidadD.3.1 Plan de CalidadControl de la Calidad

Inputs• Plan de Calidad del

Proyecto

• SLA

• Checklists

• Productos del proyecto

Técnicas y herramientas1. 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



PlanningCalidad

Aseguramiento

Calidad

Control Calidad

GestiónCalidad

del Proyecto




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 validarFASE DE ORIGEN

FA

SE D

E D

ET

EC

CIÓ

N

EXPLOTACIÓN

D.3.1 Plan de CalidadEjemplo: Evaluación de productosD.3.1 Plan de CalidadEjemplo: Evaluación de productos

Conformance Review¿ Cuando se realizan ?

• En proyectos de nuevo desarrollo, antes de la entrega a cliente.• En proyectos de mantenimiento, periódicamente - cada mes.

¿ Por parte de quien ?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 lasactividades del proyecto a los estándares aplicables.

¿ Cuando se realizan ?Periódicamente / “espontáneamente”

¿ Por parte de quien ?

• 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

D.3.1 Plan de CalidadEjemplo: Auditorías de CalidadD.3.1 Plan de CalidadEjemplo: 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ándolasa las características

de mi juego... Saqué dos hoyos de ventaja…..

D.3.1 Plan de CalidadEjemplo: Auditorías de CalidadD.3.1 Plan de CalidadEjemplo: Auditorías de Calidad


D.3.2 Plan de MétricasD.3.2 Plan de Métricas

PLANIFICACIÓN

SEGUIMIENTO Y ANÁLISIS

BALANCE Y CIERRE

GESTIÓN MÉTRICASPROYECTO

NO SE PUEDE CONTROLAR….LO QUE NO SE PUEDE MEDIR….


D.3.2 Plan de MétricasPlanificaciónD.3.2 Plan de MétricasPlanificación

Inputs• Plan de Calidad del

Proyecto• Programa de

Métricas• Cuadro de Mando

PLANIFICACIÓN

SEGUIMIENTO Y

ANALISIS

BALANCE Y REPOSITO

RIO


Técnicas y herramientas1. 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

Q1Q1 Q2Q2 Q3Q3

m1m1 m2m2 m3m3 m4m4

G1G1


D.3.2 Plan de MétricasSeguimiento y análisisD.3.2 Plan de MétricasSeguimiento y análisis

Cumulative Open vs. Closed Issues

0

5

10

15

20

25

T1 T3 T5 T7 T9 T11

# of

Issu

es

Opened

Closed

Inputs

• Plan de Métricas

• Baseline

PLANIFICACIÓN

SEGUIMIENTO Y

ANALISIS

BALANCE Y REPOSITO

RIO


Técnicas y herramientas1. 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


D.3.2 Plan de MétricasBalance y cierreD.3.2 Plan de MétricasBalance y cierre

PLANIFICACIÓN

SEGUIMIENTO Y

ANALISIS

BALANCE Y REPOSITO

RIO


Técnicas y herramientas1. Repositorio de métricas

2. Control Estadístico

3. Benchmarking

4. Diagramas de flujo - Causa/Efecto

5. ....

Outputs

• Report proceso

• Repositorio actualizadoBalance y

cierre

Inputs

• Plan de Métricas

• Baseline

Cumulative Open vs. Closed Issues

0

5

10

15

20

25

T1 T3 T5 T7 T9 T11

# of

Issu

es

Opened

Closed


D.3.2 Plan de MétricasEjemplo. Métrica: SizeD.3.2 Plan de MétricasEjemplo. 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.

D.3.2 Plan de MétricasEjemplo. Métrica: EsfuerzoD.3.2 Plan de MétricasEjemplo. Métrica: Esfuerzo


• Mejora de futuras estimaciones

• Evaluación de la productividad

• Validación de ‘best practices’ y procesos de mejora

• …


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

D.3.2 Plan de MétricasEjemplo. Métrica: StaffD.3.2 Plan de MétricasEjemplo. Métrica: Staff


• Mejora de la planificación y seguimiento del proyecto:

• Dimensionamiento

• Velocidad de cambios (altas/bajas) en el equipo

• …


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

D.3.2 Plan de MétricasEjemplo. Métrica: DuraciónD.3.2 Plan de MétricasEjemplo. Métrica: Duración


• Mejora en la estimación, medida y análisis del ciclo de vida de desarrollo:

• Etapas

• Actividades

• …


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

D.3.2 Plan de MétricasEjemplo. Métrica: DefectosD.3.2 Plan de MétricasEjemplo. Métrica: Defectos


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

• …


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

D.3.2 Plan de MétricasEjemplo. Métrica: CambiosD.3.2 Plan de MétricasEjemplo. Métrica: Cambios


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

• …


D.3.2 Plan de MétricasMétricas informales en entornos no CMMD.3.2 Plan de MétricasMé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.

D.3.3 Plan de Gestión de ConfiguraciónD.3.3 Plan de Gestión de Configuración


D.3.3 Plan de Gestión de Configuración Procesos

Extracción Inserción

Baseline 1Baseline 2

Baseline N...

ACTIVIDADES DE DESARROLLO

Producto Producto

1. Configuración:• ¿ Que Baselines?• ¿ Que productos pertenecen a cada baseline ?

2. Cambios:• ¿ Como se modificanlos productos ?

3. Gestión de los repositorios y baselines:• ¿ Es coherente, completa, etc.. la baseline ?• ¿ Esta definida la función de seguridad de acceso ?

•Código fuente

•Clases

•...

•...

•Diseño Técnico

•Programación

•...

•Fase Beta Testing

•...

Producto


D.3.3 Plan de Gestión de ConfiguraciónControl de la ConfiguraciónD.3.3 Plan de Gestión de ConfiguraciónControl 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.


D.3.3 Plan de Gestión de ConfiguraciónControl de cambiosD.3.3 Plan de Gestión de ConfiguraciónControl 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.


D.3.3 Plan de Gestión de ConfiguraciónGestión de los repositorios y baselinesD.3.3 Plan de Gestión de ConfiguraciónGestió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..


– Production SupportProduction Support

• Software de la aplicación (código, BBDD, datos, etc.)

• Requisitos del Cliente (peticiones)

– Development +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.

D.3.3 Plan de Gestión de Configuración Ejemplo: Elementos de Configuración


eds.comeds.com

Lluís Duran Alsina – [email protected]

Documents

Eds Fib Feb06