Tema 1: Conceptos de la Gestión de Proyectos Software

(1)

Tema 1: Conceptos de la

Gestión de Proyectos

(2)

Procesos de Software www.kybele.urjc.es

Bibliografía



Calvo-Manzano, J.A., Cervera, J., Fernández, L., Piattini, M.

Aplicaciones Informáticas de Gestión. Una perspectiva de

Ingeniería del Software. Ra-ma, 2004



Pressman, R. S., Ingeniería del Software. Un Enfoque

Práctico.McGraw-Hill, 2005.



S. McConell, Desarrollo y Gestión de Proyectos Informáticos.

McGraw-Hill.

(3)

Indice

1. ¿Qué es un proyecto?

2. ¿Cómo comienza un Proyecto?

3. El Personal

3.1. Los Participantes: el Jefe de Proyecto 3.2. El Equipo

4. El Producto

5. El Proceso

(4)

¿Qué es un proyecto?



Definición 1:

o

_{Es un conjunto de actividades planificadas, ejecutadas}

y supervisadas que, con recursos finitos, tiene como

objetivo crear un producto o servicio único.



Definición 2:

o

_{Un proyecto es una actividad que tiene un inicio, que}

se lleva a cabo para conseguir unos objetivos definidos

y tiene un final previsto.

(5)

Objetivo de un proyecto



El objetivo principal es obtener un resultado en

forma de bien o producto para un cliente que da

una especificaciones y marca unos objetivos a

(6)

Actividades

del Proyecto

Da las especificaciones y marca unos objetivos a cumplir Gestión y planificación Restricciones económicas, temporales, de personal…

Cliente

Recursos

Bien o servicio

Esquema de un proyecto

(7)

¿Cómo debe ser un buen

proyecto?



Objetivos claros y definidos.



Las actividades se deben poder planificar,

ejecutar y controlar.



Menor número de recursos y mínimo tiempo.



Debe tener un inicio y un final previstos.

(8)

Fases de un proyecto

• Planificación y

estimaciones

Inicio

• Seguimiento del

Proyecto

Desarrollo

• Comprobar que todo ha

terminado con “éxito”

(9)

¿Por qué la Gestión de

Proyectos?



Gran número de empresas, buenas y malas,

grandes y pequeñas, tienen a menudo un factor

común  Proyectos pesadilla:



Proyectos con fechas imposibles de cumplir



_{Generando productos decepcionantes para sus}

usuarios

(10)

Dificultad de Dirigir un Proyecto

Informático



El software es intangible

◦

_{Tiene una naturaleza no física (el hardware tiene una}

importancia sólo relativa), lo que le separa de los productos de

otras ingenierías

 No es fácil de controlar (efectos laterales imprevistos)  Composición no trivial (costos de integración)

 Muy difícil de medir (necesidad de métricas propias)

 Medir el producto, y también el proceso

◦

_{Además, su costo de replicación es prácticamente nulo}

 Es la característica principal que distingue al proceso de software  No es comparable a una ingeniería clásica

 El costo de diseño no se amortiza con la producción en serie

 Recuerda más a la arquitectura, y aun así no se construye

◦

_{Finalmente, incluso el comportamiento del proyecto es distinto}

 Ley de Brooks – en Informática, no existe el hombre-mes

 “La adición de personal a un proyecto informático, de hecho lo retrasa”

09/09/201 1

(11)

¿Qué es la Gestión de

Proyectos?



Es un conjunto de actividades con el objetivo de

ordenar, disponer y organizar los recursos y las

necesidades para completar con éxito un cierto

proyecto.



El proceso de gestión es un conjunto de actividades

que se hacen antes y durante todo el proceso de

desarrollo de forma paralela a éste.

(12)

¿Qué involucra la Gestión de

Proyectos?



¿Quién la hace?: Todos gestionan.

o

_{Ing. Sw: Gestiona sus actividades diarias; planifica,}

supervisa y controla labores técnicas.

o

_{Gestores de Proyecto: Planifican, supervisan y controlan el}

trabajo del equipo de IS.

o

_{Gestores Ejecutivos: Coordinan la relación entre el}

negocio y los profesionales del software.



¿Por qué es importante?:

o

_{La construcción de software involucra a mucha gente que}

trabaja durante mucho tiempo



Actividad compleja que necesita ser gestionada.

09/09/201 1

(13)

Gestión vs Dirección



Son actividades complementarias.



La dirección de proyectos es un rol que tiene que

existir en la gestión de proyectos.



Dirección: Actividades de coordinación y

cumplimiento de la gestión de proyectos



Gestión: Requiere más experiencia y

(14)

Áreas que se deben gestionar

I – Definición

• Estimación

• Análisis y gestión del riesgo • Planificación temporal del

programa

• Análisis del sistema • Elección del Paradigma

II – Desarrollo • Diseño • Implementación o codificación • Pruebas • Estrategias de prueba • Técnicas de prueba III – Mantenimiento y Gestión de la Configuración del Software* 09/09/201 1

(15)

Indice

1. ¿Qué es un proyecto?

2. ¿Cómo comienza un Proyecto?

3. El Personal

4. El Producto

5. El Proceso

(16)

La gestión eficaz de un proyecto software se centra en :

• Personal.- Organizado para el trabajo con efectividad

• Producto.- La comunicación entre el cliente y el equipo debe permitir

comprender el ámbito y los requisitos del producto

• “Mal Inicio = Problema equivocado”

• Proceso.- Se debe seleccionar un proceso adecuado para el personal y

para el producto.

• Proyecto.- se debe: estimar el tiempo y el esfuerzo para cumplir los

objetivos; definir productos de trabajo; establecer puntos de control de calidad; identificar mecanismos de supervisión y control del trabajo planificado.

¿Cuál es el producto obtenido?: El Plan de Proyecto. Este incluye:

• El proceso y las labores que se llevarán a cabo

• El Personal

• Los mecanismos de control de riesgos, control de cambios y evaluación de la calidad

(17)

¿Cómo puedo estar seguro de que lo he hecho correctamente?: Cuando haya

entregado un producto:

• De alta calidad

• En tiempo

• Dentro del presupuesto

Un BUEN Gestor de Proyecto debe:

• Alentar al personal a trabajar en EQUIPO

• Enfocar su atención tanto a las necesidades del CLIENTE como a las del PRODUCTO

(18)

(19)

1. Decisión de emprender el proyecto

 Procedente de necesidad interna

 Procedente de solicitud externa

2. Selección del jefe de proyecto

3. Inicio del proyecto

(20)

1 - Decisión de emprender el proyecto

Necesidad INTERNA



Orígenes en la decisión de emprender un proyecto:

• Variación en los requisitos Software (legislación, estándares…)

• Petición cliente o usuario

• Propuesta generada dentro de la organización de desarrollo

• Necesidad detectada por el departamento de marketing

• Recomendación del personal de mantenimiento de aplicaciones

existentes

• Necesidad detectada por el personal informático (por quejas de

(21)



Priorizaron de proyectos:

1. Por plan estratégico de Sistemas de Información (si existe)

2. Dirigida por la atención de solicitudes (RFS):

• Corrección rápida de un defecto en proyectos de emergencia.

• Proyectos obligados que requieren cambios del sistema para una

fecha concreta.

• Proyectos de mejora o crecimiento.

• Proyectos de desarrollo de un nuevo sistema, remplazar uno

existente o prolongar su vida operativa.



Se recomienda:

1. Obtener una idea clara de lo que se pretende hacer

1 - Decisión de emprender el proyecto

(22)



Orígenes en la decisión de emprender un proyecto:

•Respuesta a la demanda de un cliente como resultado de una labor

comercial concreta.

•Respuesta a la demanda de un cliente como consecuencia de una solicitud

de propuestas (RFP).



Se recomienda :

1. Obtener una idea clara de las necesidades del cliente

•Definir y analizar los requisitos del sistema, mediante técnicas de recogida de información. Los resultados de los estudios previos se recogen en un documento denominado Informe de Necesidades.

2. Valorar la viabilidad del proyecto

•Los beneficios dependen de las condiciones contractuales que se establezcan.

•La preparación de la propuesta implica ya un consumo de recursos que hay que valorar. Es importante que este gasto inicial no influya en la decisión de continuar con el proyecto porque “ya se ha gastado mucho”.

1 - Decisión de emprender el proyecto

(23)



Criterios para tomar la decisión de emprender o no un proyecto:

1. Relacionados con el negocio:

• Incremento de beneficios y/o reducción de costes.

• Mejora de información disponible para toma de decisiones.

• Apoyo a objetivos de cualquier nivel

.

2. Relacionados con los riesgos:

• Sobre la implementación (experiencia, complejidad, esfuerzo requerido…).

• Sobre los beneficios (calidad de estimaciones, dificultad para medir logros…).

• Sobre la organización (interrelación con otros proyectos, relación entre distintos equipos involucrados).

1 - Decisión de emprender el proyecto

(24)



Decisión posterior a la de emprender el proyecto, pero

recomendable que intervenga desde el principio del proceso.



Es el elemento más crítico para el éxito del proyecto.



Cada proyecto requiere un jefe de proyecto con una cualificación

diferente.



Es importante un buen nivel en:

• Relación con el negocio

• Competencias personales

• Competencias interpersonales

• Gestión

(25)



El jefe de proyecto debe establecer el entorno de trabajo incluso antes

de realizarse la viabilidad.



Es la primera versión del PLAN DEL PROYECTO que incluye:

• Identificación de las áreas de riesgo del proyecto

• Establecimiento de presupuestos, calendarios, planes de trabajo,

asignación de tareas

• Herramientas y técnicas utilizadas

• Técnicas de comunicación en el equipo

• Requisitos subcontratistas

• Interacción con el cliente, etc.



El jefe de proyecto controla las actividades en función del plan de

(26)

Indice

1. ¿Qué es un proyecto?

2. ¿Cómo comienza un Proyecto?

3. El Personal

4. El Producto

5. El Proceso

(27)

Madurez del Proceso Software:

1.CMMI-SW (Modelo Integrado de Madurez de la Capacidad de Software)

+

2.MMCGP (Modelo de Madurez de la Capacidad de Gestión del Personal).

Software Engineering Institute (SEI), de la Carnegie Mellon (EEUU).

El MMCGP define las siguientes prácticas clave:  Reclutamiento

 Selección

 Gestión del desempeño

 _{Entrenamiento}  Retribución

 Desarrollo de la carrera

 Diseño de la organización y el trabajo

 Desarrollo de la cultura de equipo

(28)

Indice

1. ¿Qué es un proyecto?

2. ¿Cómo comienza un Proyecto?

3. El Personal

3.1. Los Participantes: el Jefe de Proyecto

3.2. El Equipo

4. El Producto

5. El Proceso

(29)



Taxonomía de participantes en un proceso de software:

 _{Gestores ejecutivos: definen aspectos del negocio con influencia}

significativa en el proyecto.

 _{Gestores (técnicos) del proyecto: planifican, motivan y controlan a los}

profesionales que realizan el trabajo de software.

 _{Profesionales: proporcionan las habilidades técnicas necesarias para}

realizar la ingeniería de un producto o aplicación.

 _{Clientes: especifican los requisitos y otros elementos que tengan interés}

para el resultado.

 _{Usuarios: interactúan con el software una vez que se libera para su uso.}

(30)



Habilidades deseables para un jefe de proyecto:

 Liderazgo y motivación.-Habilidad para motivar al equipo, potenciando su iniciativa y auto-confianza. Conviene utilizar incentivos que recompensen la iniciativa y logros demostrando que asumir riesgos controlados no se penalizará.  Ideas o innovación.-Habilidad para crear sin salirse de los límites establecidos por los requisitos.

 _{Resolución de problemas}.-Eficiencia para detectar conflictos (técnicos y organizativos), estructurar de manera sistemática una solución y aplicar en nuevas situaciones lecciones aprendidas.

 _Gestión.-Capacidad para planificar y controlar actividades, costes y presupuestos del proyecto.

 Fomento de la cultura de equipo.-Capacidad de transmitir cultura del trabajo en equipo en contraposición con trabajo en grupo o individual. Capacidad para convertir objetivos comunes en propios.

 Influencia y Relación.-Ser capaz de “leer” en la gente, reaccionando a las necesidades de cada integrante del equipo. Ser capaz de mantener el control en situaciones de alta tensión emocional. Comunicar con los miembros del equipo, desarrollar sus capacidades.

 _{Visión de negocio}.-Conocimiento, negociación y compromiso con la calidad.  Comprensión técnica.-Conocimientos para tomar decisiones técnicas correctas.

 Presteza y decisión.-Ser capaz de observar, evaluar y decidir. Se debe combinar con capacidad analítica y de pensamiento conceptual.

 Versatilidad y flexibilidad.-Capacidad para encauzar imprevistos, y para anticipar el impacto de decisiones.  Integridad.- Para seleccionar al personal más capacitado, ganarse la confianza del cliente y mantener una credibilidad.

 Previsión.-Para anticiparse a los problemas y aportar soluciones.

Los Participantes

(31)

Indice

1. ¿Qué es un proyecto?

2. ¿Cómo comienza un Proyecto?

3. El Personal

3.1. Los Participantes: el Jefe de Proyecto

3.2. El Equipo

4. El Producto

5. El Proceso

(32)

El Equipo



Definición



Estructura organizada del personal de desarrollo de software

encargada de la implementación de una solución



Enfoques de organización



Nº tareas = Nº de individuos  gestor del proyecto debe

coordinar



Nº tareas > Nº de individuos  equipos informales con líder



Varios equipos  estructura homogénea. Coordinación dentro

del grupo y por el gestor del proyecto

09/09/201 1

(33)



La estructura organizacional no depende del gestor de proyecto

software; la organización del personal involucrado en un proyecto

software si.



La “mejor” estructura de equipo depende de diversos factores

(Mantei, 1981):

 Dificultad del problema a resolver.

 Tamaño del programa (en líneas de código o puntos función).

 Vida del equipo (tiempo que el equipo permanece junto).

 _{Grado de modularidad del problema.}

 _{Calidad y confiabilidad requeridos para el sistema a construir.}  Rigidez en las fechas de entrega.

 Grado de sociabilidad (comunicación) que requiere el proyecto.

Si quiere ser cada vez mejor: sea competitivo.

I.2.2 El Equipo

El Equipo

(34)



Organigramas de equipo

o

_{Descentralizado Democrático (DD)}



Sin líder de grupo permanente  en función de la tarea



Decisiones por consenso dentro del grupo



Comunicación horizontal



Características

• Recomendado en problemas difíciles (capacidades personales)

• Para equipos con tiempo de vida largo. Moral más alta y

satisfacción

• Problemas de modularidad baja (gran cantidad de comunicación)

09/09/201 1

(35)



Organigramas de equipo



Descentralizado controlado (DC)



Líder de grupo permanente  jefes secundarios en subtareas



Resolución de problemas en grupo. Implementación de subtareas

asignada por el líder



Comunicación horizontal entre subgrupos e individuos.

Comunicación de control vertical



Características

• Recomendado en problemas complejos fácilmente modularizables en problemas sencillos

• - Cantidad de comunicación = + Rendimiento  Proyectos grandes con formación de subgrupos

(36)



Organigramas de equipo



_{Centralizado controlado (CC)}



Líder de grupo permanente  resolución de problemas de

alto nivel + coordinación interna



Comunicación vertical



Características

• Recomendado en problemas complejos fácilmente modularizables

en problemas sencillos

• Menos defectos que organigramas no controlados

• Requieren menos tiempo que organigramas descentralizados

09/09/201 1

(37)



Paradigmas de organización (Constatine, 1993):



Paradigma cerrado



Jerarquía tradicional de autoridad (similar a CC)



Ideal para SW similar a otro ya existente



Poca innovación



_{Paradigma aleatorio}



Libertad en el equipo



Potencia la iniciativa  innovación o avances tecnológicos



Problemas para rendimiento ordenado

(38)



Paradigmas de organización

(Constatine, 1993):



Paradigma abierto



Mezcla entre paradigmas “cerrado” y “aleatorio”



Mucha comunicación, colaboración. Decisiones consensuadas



Solución de problemas complejos pero rendimiento no muy

eficiente



_{Paradigma sincronizado}



Alto grado de fraccionamiento del problema



Compartimentar al personal del equipo



Poca comunicación

09/09/201 1

(39)

El paradigma aleatorio parece un enfoque adecuado para el desarrollo de

software:

• Ventaja: libertad de trabajo

• Desventaja: es necesario canalizar la energía creativa para conseguir un

equipo de alto rendimiento.

Para lograr un equipo de alto rendimiento:

• Los miembros del equipo deben tener confianza unos en los otros • La distribución de las habilidades debe adecuarse al problema

• Los disidentes, probablemente, deben ser excluidos del equipo para

conservar la cohesión.

Independientemente de la estructura del equipo, el objetivo de cualquier jefe de proyecto debe de ser la COHESIÓN DEL EQUIPO.

(40)



Un equipo cuajado:

• Es más productivo

• Está más motivado

• Sus miembros comparten una meta común

• Sus miembros comparten una cultura común

• Sus miembros comparten un sentimiento

“elitista” que los hace únicos

Un equipo cuajado es un grupo de personas tan fuertemente unido que el todo es mayor que la suma de las partes. De Marco y Lister (1998)

(41)

•Atmósfera de trabajo frenética

•Alta frustración que provoca fricción

entre sus miembros

•Proceso de software fragmentado o

pobremente coordinado

•Definición poco clara de los papeles

del equipo de software

 Acceso a toda la información requerida por parte de los miembros del equipo

 Las metas y objetivos no deben modificarse salvo que sea absolutamente necesario

 Importante dar al equipo tanta

responsabilidad en la toma de decisiones como sea posible

Factores que fomentan un ambiente de equipo tóxico:

 Comprender bien el producto y el personal

 Permitir al equipo seleccionar su propio modelo de proceso

 El equipo debe establecer por sí mismo mecanismos para su responsabilidad

 El equipo debe definir una serie de enfoques correctivos cuando un miembro del quipo falle

(42)



Desarrollo Ágil:

• Satisfacción del cliente mediante la entrega rápida e incremental del

software

• Equipos pequeños muy motivados

• Métodos informales

• Productos de trabajo de IS mínimos

• Simplicidad en el desarrollo



Equipos Ágiles:

• El enfoque ágil subraya la competencia individual en conjunción con la

colaboración del grupo.

• Son equipos auto-organizados

• Aprovechan elementos de los distintos paradigmas de equipos

(43)



Equipos Ágiles:

•

El equipo tiene una gran autonomía

•

Mínima planificación

•

Selecciona su propio enfoque limitado sólo por los requisitos

del negocio y estándares de la organización

•

Es común la realización de breves reuniones diarias para

coordinar el trabajo diario

•

Son claves la auto-organización continua y la colaboración

(44)



Conflictos de coordinación y comunicación



_{Como consecuencia de las características del software}

moderno:

• Escala. Tamaño grande = provoca complejidad, confusión y dificultades

• Incertidumbre. Provoca cambios continuos.

• Interoperabilidad. Compatibilidad de SW nuevo con el anterior



_{Como consecuencia de las características personales de cada}

miembro del equipo



_{Es necesario establecer mecanismos para la comunicación:}

• Formal. Escritos, reuniones estructuradas, etc.

• Informal. Compartición de ideas ad-hoc, cuando surgen problemas,

etc.

(45)

Indice

1. ¿Qué es un proyecto?

2. ¿Cómo comienza un Proyecto?

3. El Personal

4. El Producto

5. El Proceso

(46)



Problema inicial

◦

Se requieren estimaciones y un plan organizado de

abordaje del problema

◦

No se dispone de información sólida



Actividades

◦

Definir el ámbito del problema

◦

Descomponer el problema



Objetivo

◦

Conseguir información sólida y consistente para elaborar

un plan

09/09/201 1

(47)



Contexto



¿Cómo encaja el nuevo SW en un sistema o contexto de

negocios mayor? ¿Limitaciones del entorno?



Objetivos de información



Datos de entrada y de salida del producto a desarrollar



Función y rendimiento



¿Cómo se transforma la información? (descripción genérica)



_{¿Limitaciones de eficiencia?¿Características de rendimiento}

especiales?

El Producto

(48)



El ámbito no debe definirse de manera ambigua y debe

ser comprensible tanto a nivel de gestión como a nivel

técnico.



Se debe acotar un enunciado del ámbito de software:

•

Estableciendo de manera explícita los datos cuantitativos (numero

de usuarios simultáneos, tamaño de listas de correo, tiempo

máximo de respuesta permitido...).

•

Anotando las limitaciones o restricciones (por ejemplo, el coste del

producto restringe el tamaño de la memoria).

•

Describiendo los factores que reducen riesgos (por ejemplo,

algoritmos).

I.3. El Producto

El Producto

(49)

Estrategia: DIVIDE Y VENCERÁS



Cuando el problema es complejo, se recomienda descomponerlo.



Esta descomposición se aplica en dos áreas:

• La funcionalidad a entregar.

• El proceso que se empleará para entregarla.



La descomposición se realiza al comienzo de la planificación del

proyecto:

• Después de acotar el ámbito

• Antes de realizar la estimación (debido a que la estimación de costes y

planificación temporal están orientadas funcionalmente, es útil un cierto

I.3. El Producto

El Producto

(50)

Indice

1. ¿Qué es un proyecto?

2. ¿Cómo comienza un Proyecto?

3. El Personal

4. El Producto

5. El Proceso

(51)



Existen unas actividades que caracterizan el proceso software

aplicables a todos los proyectos.



Estas actividades constituyen un marco de trabajo que debe ser

adaptado en cada proyecto concreto.



El director de proyecto debe elegir el modelo de proceso más

adecuado para:

• El cliente y el personal

• Las características del propio producto

• El ambiente del proyecto en el que se trabaja



Una vez elegido el modelo de proceso, el equipo define un plan de

proyecto preliminar; se toman como base el marco de trabajo.



A continuación se comienza con la descomposición del proceso,

(52)



La planificación del proyecto comienza combinando el producto con el

proceso:

• Cada función que el equipo de software tiene que llevar a cabo, debe pasar

por cada una de las actividades del marco de trabajo definidas para la organización.



Para ello, se crea una matriz:

• Columnas: cada función del producto

• Filas: Actividades del marco de trabajo

• Subfila: se incluyen las tareas requeridas para actividad del marco de trabajo



El director de proyecto, con la ayuda del equipo, debe definir los recursos

requeridos para cada celda de la matriz, las fechas de inicio y final para

cada tarea, así como los productos resultantes de cada tarea.

I.4. El Proceso

El Proceso

(53)



El equipo de software debe tener una cierta flexibilidad para elegir el

modelo de proceso, y las tareas que lo componen, que mejor se adapte

al proyecto. Ejemplos:

• Un proyecto pequeño y similar a otros previos: enfoque secuencial y lineal

• Un problema que se puede compartimentalizar y con restricciones de

tiempo: modelo de desarrollo rápido de aplicaciones

• Si la fecha límite es muy restringida y no se puede alcanzar con la

funcionalidad completa: enfoque incremental



Una vez elegido el modelo de proceso, el marco de trabajo se adapta.



El marco de trabajo del proceso es invariable y sirve como base para

todos los desarrollos de software que realiza una organización.



Sin embargo, las tareas de trabajo real varían.

(54)

Indice

1. ¿Qué es un proyecto?

2. ¿Cómo comienza un Proyecto?

3. El Personal

4. El Producto

5. El Proceso

(55)



Una buena gestión de un proyecto software requiere entender qué puede

salir mal.



10 señales que indican que un proyecto está en peligro (Reel 1999):

• El personal de software no entiende las necesidades de sus clientes • El ámbito del producto está mal definido

• Los cambios se gestionan mal • La tecnología elegida cambia

• Las necesidades comerciales cambian (o están mal definidas) • Los plazos de entrega no son realistas

• Los usuarios se resisten

• Se pierde el patrocinio (o nunca se obtuvo de manera adecuada) • El equipo de proyecto carece de las habilidades apropiadas

• Los gestores, y el personal del equipo, no hacen uso de las mejores prácticas y las

(56)

 Enfoque se sentido común (Reel, 1999):

1. Comience con el pie derecho

 Entender bien el problema a resolver. Definir objetivos y expectativas realistas

 Constituir el equipo correcto. Dar al equipo la autonomía, autoridad y tecnología necesarios para hacer el trabajo

2. Mantenga el ímpetu

 Proporcionar incentivos que mantengan los reveses del personal en el mínimo absoluto  El equipo debe de resaltar la calidad de cada tarea que realice

 Los gestores deben de mantenerse alejados del equipo: este debe ser auto-organizado y autónomo.

3. Rastree el progreso

 Mediante la elaboración de productos de trabajo (modelos, código, pruebas, etc.) y su aprobación (mediante revisiones técnicas formales)

 Además se pueden aplicar medidas del proyecto

4. Tome decisiones inteligentes

 Decisiones orientadas a “mantenerlo lo más simple posible”: utilizar software comercial, librerías ya desarrolladas, interfaces estándar, identificar y evitar riesgos obvios, asignar más tiempo a tareas con riesgos…

5. Realice un análisis de resultados

 Establecer mecanismos para extraer lecciones aprendidas de cada proyecto

 Evaluar la planificación real y la prevista; realizar y analizar métricas de proyecto de software; obtener realimentación del equipo y de los clientes; describir los hallazgos de forma escrita.

I.5. El Proyecto

¿Cómo debe actuar un director de proyecto?

(57)

 El principio W5HH (Boehm, 1996):

1. Why?. ¿Porqué se desarrolla el sistema?.

Dicho de otro modo, ¿el propósito del negocio justifica el gasto de personal, tiempo y dinero?

2. What? ¿Qué se hará?.

Establece el conjunto de tareas requeridas para el proyecto.

3. When? ¿Cuándo se hará?

Esta pregunta ayuda a establecer una planificación del proyecto, identificando cuándo se realizan las tareas y cuando se obtienen los objetivos

4. Who? ¿Quién es el responsable de una función?

La respuesta a esta pregunta ayuda a lograr la definición explícita de las responsabilidades de cada miembro del equipo

5. Where? ¿Dónde están ubicados los responsables dentro de la organización?

No todas las responsabilidades residen en el equipo de software. También tienen responsabilidades otros participantes (como el cliente, los usuarios, etc.)

6. How? ¿Cómo se hará el trabajo, tato desde el punto de vista técnico como del de gestión?

El Proyecto

(58)



Prácticas críticas de software para la gestión basada en el

desempeño (Airlie Council, 1999):

• Gestión del proyecto basada en métricas

• Coste empírico (basado en datos) y estimación de la planificación

• Seguimiento del valor ganado

• Gestión formal del riesgo

• Seguimiento de defectos frente a objetivos de calidad

• Gestión del personal.