gestión de proyectos - kybele.etsii.urjc.esis... · ingeniería del software de gestión Índice...

Ingeniería del Software de Gestión www.kybele.es

Marcos López Sanz Ingeniería del Software de Gestión

Tema 4: Gestión de Proyectos.

Conceptos y Principios Básicos


Índice

Introducción

o Cómo comienza un Proyecto

o El Personal

o El Producto

o El Proceso

o El Proyecto


Introducción

¿Qué es un Proyecto?

Definición 1:

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:

Un proyecto es una actividad que tiene un inicio, que se lleva a cabo para conseguir unos objetivos definidos y tiene un final previsto.


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.

Introducción

¿Qué es un Proyecto?


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

Introducción

Esquema de un 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

Introducción

¿Cómo debe ser un buen Proyecto?


• Planificación y estimaciones

Inicio

• Seguimiento del Proyecto

Desarrollo

• Comprobar que todo ha terminado con “éxito”

Final

Introducción

Fases de un Proyecto


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 Meilir Page-Jones (1985)

Débil Gestión del Proyecto

Introducción

¿Por qué la gestión de un Proyecto?


Introducción

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 Mito: “man-month: a unit of work proportional to the number of people working

multiplied by the time that they work” “La adición de personal a un proyecto informático, de hecho lo retrasa”


Introducción

Una realidad demasiado cierta


Introducción

¿Qué es la gestión de un proyecto?

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 de un proyecto


Introducción

Lo que involucra la gestión de Proyectos

¿Quién la hace? Ingeniero de Software: Gestiona sus actividades diarias;

planifica, supervisa y controla labores técnicas

Gestores de Proyecto: Planifican, supervisan y controlan el trabajo del equipo de IS

Gestores Ejecutivos: Coordinan la relación entre el negocio y los profesionales del software

¿Por qué es importante?: La construcción de software involucra a mucha gente

que trabaja durante mucho tiempo

Actividad compleja que necesita ser gestionada

¡TODOS GESTIONAN!


Introducción

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.


Introducción

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


Introducción

Ámbito de la gestión

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

Personal Producto

Proyecto Proceso


Introducción

¿Cuál es el producto obtenido (de la gestión)?

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 puedo estar seguro de que lo he hecho correctamente? Cuando haya entregado un producto: De alta calidad En tiempo Dentro del presupuesto

16


Introducción

Liderazgo

Un BUEN líder 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


Índice

o Introducción

Cómo comienza un Proyecto

Decisión de Emprender un Proyecto

Selección del Jefe de Proyecto

Inicio del Proyecto

o El Personal

o El Producto

o El Proceso

o El Proyecto


Gestión de Proyectos

¿Cómo comienza un 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.)




1. Decisión de emprender el proyecto Necesidad INTERNA: Priorización de proyectos:

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

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: Obtener una idea clara de lo que se pretende hacer

Evaluar la viabilidad del proyecto analizando beneficios/gastos




1. Decisión de emprender el proyecto Necesidad EXTERNA: 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:

Obtener una idea clara de las necesidades del cliente Definir y analizar los requisitos del sistema (Informe de Necesidades) 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




1. Decisión de emprender el proyecto Necesidad EXTERNA: Criterios para tomar la decisión de emprender o no un

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

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)




2. Selección del jefe de proyecto 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 e interpersonales

Gestión




3. Inicio del 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

El jefe de proyecto controla las actividades en función del plan de proyecto y lo actualiza cuando sea necesario




3. Inicio del proyecto

El PLAN DEL PROYECTO 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 para subcontratistas

Interacción con el cliente, etc.


Índice

o Introducción


El Personal

Madurez del Proceso de Software

Los participantes – Jefe de Proyecto

El equipo

o El Producto

o El Proceso

o El Proyecto


Personal

Madurez del Proceso de Sw

Modelo de madurez Proceso que nos muestra y explica el camino de una organización para alcanzar

la excelencia en la gestión de proyectos a través de diversos niveles de madurez Ofrece una estructura para comparar el grado de desarrollo de la capacidad de

la administración de proyectos existente en la organización

Modelos: CMMI-SW (Modelo Integrado de Madurez de la Capacidad de Software) MMCGP (Modelo de Madurez de la Capacidad de Gestión del Personal).

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

El MMCGP define las siguientes prácticas clave: Reclutamiento Selección Entrenamiento Selección de la carrera Desarrollo de la cultura de equipo Gestión del desempeño Retribución Diseño de la organización y el trabajo


Personal

Los participantes

Taxonomía de participantes en un proceso de software:

Gestores ejecutivos

Gestores (técnicos) del proyecto

Profesionales

Clientes

Usuarios


Habilidades deseables para un jefe de proyecto

Influencia y

Relación Liderazgo y

motivación

Ideas o

innovación

Resolución de

problemas

Gestión

Fomento de la

cultura de equipo

Visión de negocio

Comprensión

técnica

Presteza y

decisión

Versatilidad y

flexibilidad

Integridad Previsión

Personal

Jefes de Proyecto


Personal

Jefes de Proyecto

Buen técnico ≠ Buen jefe “En una jerarquía, todo empleado tiende a ascender hasta su nivel de

incompetencia”. Lawrence J. Peter “Las compañías tienden a ascender sistemáticamente a sus empleados

menos competentes a cargos directivos para limitar así la cantidad de daño que son capaces de provoca”. Scott Adams

Modelo de gestión (habilidades del jefe de proyecto):

Motivación. Adecuar la producción conforme a las mejores capacidades de cada empleado

Organización. Adecuar/Crear procesos para llevar el concepto inicial al producto final

Ideas/Innovación. Motivar al personal para aportar ideas dentro de los límites del proyecto

Objetivo principal: hacer ver al equipo la importancia de la calidad

del producto en desarrollo


Personal

Jefes de Proyecto

Dilbert’s Principle

Scott Adams. Feb 5, 1995.

http://dilbert.com/fast/1995-02-05/


Personal

Equipo de Software

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


Personal

Equipo de Software

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 Vida del equipo Grado de modularidad del problema. Calidad y confiabilidad requeridos para el sistema Rigidez en las fechas de entrega. Grado de sociabilidad (comunicación) que requiere el proyecto.


Personal

Excelencia

Si quiere ser cada vez mejor: sea competitivo. Si quiere ser exponencialmente mejor: sea cooperativo.

Anónimo


Personal

Equipo de Software

Organigramas de equipo

Descentralizado democrático (DD)

Descentralizado controlado (DC)

Centralizado controlado (CC)


Personal

Equipo de Software: Organigramas de Equipo

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)


Personal


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


Personal


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


Personal


Impacto de los factores de organización

DD DC CC

Dificultad Alta Baja Baja

Tamaño Pequeño Grande Grande

Duración del equipo Largo Corto Corto

Modularidad Baja Alta Alta

Fiabilidad Alta Alta Baja

Fecha de entrega Flexible Flexible Estricta

Comunicación Alta Baja Baja


Personal

Equipo de Software: Paradigmas de Organización

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


Personal


Paradigmas de organización (Constatine, 1993):

Paradigma abierto

Estructura mixta: mantiene controles del cerrado y permite innovación del 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


Personal


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.


Personal

Cohesión del Equipo

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


Personal

Equipo de Software

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


Personal

Coordinación y Comunicación

Problemas MUY habituales de proyectos Escala: Tamaño grande = complejidad, confusión,

dificultades de coordinación Incertidumbre: Multitud de cambios Interoperabilidad: Compatibilidad de SW nuevo con el

anterior

Soluciones Métodos para coordinar a los miembros del equipo Mecanismos de comunicación:

Formales Informales


Personal

Coordinación y Comunicación

Técnicas para la coordinación de proyectos Formal, enfoque impersonal

Documentos, planificaciones, seguimiento de errores Entregas (código + informe), control de versiones, cambios

Formal, procedimientos interpersonales Actividades de garantía de calidad Reuniones e inspecciones de estado, diseño y/o código

Informal, procedimientos interpersonales Reuniones de divulgación de información (sesiones de grupo)

Comunicación electrónica Videoconferencia, mail, boletines

Red interpersonal Discusiones/Reuniones con personal ajeno al proyecto


Índice

o Introducción


o El Personal

El Producto

Definición del ámbito

Descripción del Problema

o El Proceso

o El Proyecto


Producto

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


Producto Ámbito del software

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?


Producto Ámbito del software

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

Anotando las limitaciones o restricciones

Describiendo los factores que reducen riesgos


Producto Descomposición del Problema

Análisis de los requisitos del SW DFDs, E/R, Diagramas de despliegue UML…

Áreas de descomposición Funcionalidad que debe entregarse

Proceso a seguir

Estrategia Divide y vencerás Niveles de particionamiento

Refinamiento


Índice

o Introducción


o El Personal

o El Producto

El Proceso

o El Proyecto


Proceso

Existen unas actividades que caracterizan el proceso SW 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


Proceso

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.


Proceso

La planificación del proyecto comienza combinando el producto con el proceso: 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 gestor de proyecto 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.


Proceso

Flexibilidad para elegir el modelo de proceso que mejor se adapte al proyecto. Ejemplos:< Proyecto pequeño y similar a 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

Elegido el modelo de proceso, el marco de trabajo se adapta

El marco de trabajo del proceso es invariable Sin embargo, las tareas de trabajo real varían


Índice

o Introducción


o El Personal

o El Producto

o El Proceso

El Proyecto

Prácticas de gestión recomendadas


Proyecto


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

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

No hay error: cualquier planificación nace condenada a no cumplirse


Proyecto


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


Proyecto

¿Cómo debe actuar un director de proyecto?

Enfoque de sentido común (Reel, 1999):

Comience con el pie derecho

Mantenga el ímpetu

Rastree el progreso

Tome decisiones inteligentes

Realice un análisis de resultados


Proyecto


El principio W5HH (Boehm, 1996):

Why? ¿Porqué se desarrolla el sistema?.

What? ¿Qué se hará?.

When? ¿Cuándo se hará?

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

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

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

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


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


Bibliografía

Roger S. Pressman. Ingeniería del Software: Un enfoque práctico. Capítulo 3. Ed. McGraw Hill. 5ª edición.2002

M. Piattini et al. Análisis y Diseño detallado de Aplicaciones Informáticas de Gestión. Ed. Ra-Ma. 1996

gestión de proyectos - kybele.etsii.urjc.esis... · ingeniería del software de gestión Índice...

Documents