Tema 1: Conceptos de la Gestión de Proyectos SoftwarePS... · Pressman, R. S., Ingeniería del...

Procesos de Software www.kybele.urjc.es

Tema 1: Conceptos de la Gestión de Proyectos

Software


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.


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

6. El Proyecto: prácticas de gestión recomendadas


¿Qué es un proyecto?

Definición 1: oEs un conjunto de actividades planificadas, ejecutadas

y supervisadas que, con recursos finitos, tiene como objetivo crear un producto o servicio único.

Definición 2:oUn proyecto es una actividad que tiene un inicio, que

se lleva a cabo para conseguir unos objetivos definidos y tiene un final previsto.


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 cumplir para que el proyecto se lleve a cabo.


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


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

Debe tener un resultado único.


Fases de un proyecto

• Planificación y estimacionesInicio

• Seguimiento del ProyectoDesarrollo

• Comprobar que todo ha terminado con “éxito”Final


¿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

Consumiendo ingentes horas de mantenimiento

Idea de Meiler Page-Jones, 1985

09/09/2011

Débil Gestión del Proyecto


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


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

PLANIFICAR Y HACER EL SEGUIMIENTO

09/09/2011


¿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/2011


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

09/09/2011


Á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/2011


Indice



3. El Personal


3.2. El Equipo

4. El Producto

5. El Proceso



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

¿Cómo comienza un Proyecto?


¿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



Un chiste demasiado cierto …


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



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

usuarios, sugerencias, etc.)


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

2. Evaluar la viabilidad del proyecto analizando beneficios/gastos


Necesidad INTERNA


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


Necesidad EXTERNA


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


Necesidad EXTERNA


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

2 - Selección del Jefe de Proyecto


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

proyecto y lo actualiza cuando sea necesario.

3 – Inicio del Proyecto


Indice



3. El Personal


3.2. El Equipo

4. El Producto

5. El Proceso



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

A pesar de ello, normalmente NADIE en la organización PRESTA

ATENCIÓN AL PERSONAL

El personal


Indice



3. El Personal


3.2. El Equipo

4. El Producto

5. El Proceso



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.

Los Participantes


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 ParticipantesJefe de Proyecto


Indice



3. El Personal


3.2. El Equipo

4. El Producto

5. El Proceso



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


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.

Si quiere ser exponencialmente mejor: sea cooperativo.Anónimo

I.2.2 El EquipoEl Equipo


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

El Equipo


Organigramas de equipoDescentralizado controlado (DC) Líder de grupo permanente jefes secundarios en subtareas

Resolución de problemas en grupo. Implementación de subtareasasignada 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

09/09/2011

El Equipo


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

El Equipo


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

09/09/2011

El Equipo


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

El Equipo


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.

No todo grupo es un equipo y no todo equipo es eficiente.Glen Parker

El Equipo


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)

El Equipo


•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

•Continuas y repetidas exposiciones al fracaso

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

Establecer técnicas basadas en el equipo para la realimentación y resolución de problemas

El Equipo


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

El Equipo


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

El Equipo


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.

El Equipo


Indice



3. El Personal


3.2. El Equipo

4. El Producto

5. El Proceso



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

El Producto


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?

09/09/2011

El ProductoDefinición del ámbito


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 ProductoDefinición del ámbito


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 grado de descomposición).

I.3. El Producto

El ProductoDescripción del Problema


Indice



3. El Personal


3.2. El Equipo

4. El Producto

5. El Proceso



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, creando un plan que refleje las tareas necesarias para llevar a cabo las actividades del marco de trabajo.

El Proceso


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 recursosrequeridos 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 ProcesoEl Proceso


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.

El Proceso


Indice



3. El Personal


3.2. El Equipo

4. El Producto

5. El Proceso



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

Regla del 90-90: el primer 90 % de un sistema absorbe el 90% del esfuerzo y el tiempo asignados. El último 10% requiere el otro 90%!!!.

El Proyecto


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?

El Proyecto


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?

Una vez establecido el ámbito del proyecto, hay que definir una estrategia técnica y de gestión.

7. How much? ¿Cuánto de cada recurso se necesita?

Para responder a esta pregunta es necesario realizar estimaciones

I.5. El ProyectoEl Proyecto



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.

I.5. El ProyectoEl Proyecto


Tema 1: Conceptos de la Gestión de Proyectos SoftwarePS... · Pressman, R. S., Ingeniería del...

Documents

Transcript of Tema 1: Conceptos de la Gestión de Proyectos SoftwarePS... · Pressman, R. S., Ingeniería del...