(IS3-2008-09) Gestion de Proyectos - Parte I

Gestión de Proyectos I:
Conceptos y principios básicos
INGENIERÍA DEL SOFTWARE
CURSO 2008‐2009
Introducción
2
y “He visitado decenas de tiendas comerciales, tanto buenas como
malas, y he observado registros de gerentes de procesamiento
de datos, de nuevo, tanto buenos como malos. Con mucha
frecuencia he visto con horror como dichos gerentes luchaban
inútilmente con proyectos de pesadilla, sufriendo por fechas
límites imposibles o por sistemas ya entregados que indignaron
a sus usuarios y devoraron enormes cantidades de tiempo de
mantenimiento”.
Idea de Meiler Page-Jones
Ingeniería del Software Curso 2008‐2009
Para
Para obtener
obtener mas
mas informacion,
informacion, registrese
registrese aqui
aqui
http://edpformacion.co.cc
Introducción
3
9¿Qué
Qué es? La GP involucra la planificación, supervisión y control del personal, el
proceso y los eventos que ocurren mientras el SW evoluciona desde una idea
preliminar hasta una implementación operativa.
9¿Quié
Quién la hace? TODOS gestionan.
• Ingenieros del Software: Gestiona sus actividades diarias; planifica, supervisa y
controla labores técnicas.
• Gestores de Proyecto.: Planifican, supervisan y controlan el trabajo del equipo
de Ing. SW.
• Gerentes: Coordinan la relación entre el negocio y los profesionales del
software.
9¿Por qué
Por qué es importante? La construcción de SW involucra a mucha gente que
trabaja durante mucho tiempo Æ Actividad compleja que necesita ser gestionada.
Gestión de Proyectos:
Ámbito de la gestión
4
y La gestión eficaz de un proyecto software se centra en:
{ Personal Æ importante esfuerzo humano:
Ingeniería del software eficaz
{ Producto Æ comunicación con el cliente para conocer el problema:
“Mal inicio = Problema equivocado”
{ Proceso Æ uso eficiente de métodos, técnicas y recursos:
Modelo/Ciclo de vida. Dependerá el producto y personal
{ Proyecto Æ importancia del plan del proyecto. Se debe estimar el
tiempo y esfuerzo necesario, estimar productos de trabajo, definir
puntos de control y supervisión.
Para
Para obtener
obtener mas
mas informacion,
registrese aqui
aqui
Personal
5
y El Modelo de Madurez (Software Engineering Institute)
define las siguientes prácticas clave para atraer, aumentar,
motivar y retener TALENTO:
¾ Reclutamiento
¾ Selección
¾ Gestión del desempeño
¾ Formación
¾ Retribución
¾ Desarrollo de la carrera
¾ Diseño de la organización y el trabajo
¾ Desarrollo de la cultura de equipo
Personal
6
y Esfuerzo humano. Características:
{ Bien remunerado Æ
Bien remunerado retribución
{ Cualificado Æ talento, entrenamiento, preparación
{ Motivado Æ espíritu de equipo, ambiente de trabajo
{ Considerado
y Éxito = alta eficacia en la práctica de ingeniería de
software
Para
Para obtener
obtener mas
mas informacion,
registrese aqui
aqui
Personal
7
y Factor humano: aspecto más importante de la gestión.
Factor humano
y Participantes:
{ Gestores superiores Æ aspectos de negocio
{ Gestores (técnicos) del proyecto Æ planificar, motivar, organizar y
controlar a los profesionales
{ Profesionales Æ capacidades técnicas
{ Clientes Æ especificación de requisitos y detalles
{ Usuarios finales Æ interacción con el producto/solución software
y Separación/Asignación de responsabilidades
y Maximizar habilidades y capacidades Å Jefe de Proyecto
Personal – Jefes de Proyecto
8
y Buen técnico ≠ Buen jefe
{ “En una jerarquía, todo empleado tiende a ascender hasta su nivel
de incompetencia”. Lawrence J. Peter
y Objetivo principal: hacer ver al equipo la importancia de
la calidad del producto en desarrollo
Para
Para obtener
obtener mas
mas informacion,
registrese aqui
aqui
Personal – Jefes de Proyecto
9
Trabajo en Grupo
Habilidades de un JP
Personal – Equipo de Software
10
y Definición
{ Estructura organizada del personal de desarrollo de software
encargada de la implementación de una solución
y 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
Para
Para obtener
obtener mas
mas informacion,
registrese aqui
aqui
11
y Criterios de formación de equipos:
(factores de planificación del organigrama)
{ Dificultad del problema.
{ Tamaño de la solución (LC o PF)
{ Tiempo que el equipo estará junto
{ Grado de modularidad del problema
{ Nº de personas por equipo. Niveles de preparación
{ Calidad y fiabilidad requeridas
{ Rigidez de la fecha de entrega
{ Grado de comunicación requerido
12
y Organigramas de equipo
{ Descentralizado democrá
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)
Para
Para obtener
obtener mas
mas informacion,
registrese aqui
aqui
13
{ 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
14
{ 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
Para
Para obtener
obtener mas
mas informacion,
registrese aqui
aqui
15
y 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
16
y Paradigmas de organización
{ 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
Para
Para obtener
obtener mas
mas informacion,
registrese aqui
aqui
17
y Paradigmas de organización
{ Paradigma abierto
Ù Mezcla entre paradigmas “cerrado” y “aleatorio”
Ù Mucha comunicación, colaboración. Decisiones consensuadas
Ù Problemas complejos pero rendimiento no muy eficiente
{ Paradigma sincronizado
Ù Alto grado de fraccionamiento del problema
Ù Compartimentar al personal del equipo
Ù Poca comunicación
18
Caso Práctico de Gestión de Equipos
Para
Para obtener
obtener mas
mas informacion,
registrese aqui
aqui
Personal – Coordinación y Comunicación
19
y Problemas MUY habituales de proyectos
{ Escala: Tamaño grande = complejidad, confusión, dificultades de
Escala
coordinación
{ Incertidumbre: Multitud de cambios
Incertidumbre
{ Interoperabilidad: Compatibilidad de SW nuevo con el anterior
Interoperabilidad
y Soluciones
{ Métodos para coordinar a los miembros del equipo
{ Mecanismos de comunicación
Ù Formales
Ù Informales
Personal – Coordinación y Comunicación
20
y Técnicas para la coordinación de proyectos
{ Formal, enfoque impersonal
Formal impersonal
Ù Documentos, planificaciones, seguimiento de errores
Ù Entregas (código + informe), control de versiones, cambios
{ Formal, procedimientos interpersonales
Formal interpersonales
Ù Actividades de garantía de calidad
Ù Reuniones e inspecciones de estado, diseño y/o código
{ Informal, procedimientos interpersonales
Informal interpersonales
Ù Reuniones de divulgación de información (sesiones de grupo)
{ Comunicació
Comunicación electró
n electrónica
Ù Videoconferencia, mail, boletines
{ Red interpersonal
Ù Discusiones/Reuniones con personal ajeno al proyecto
Para
Para obtener
obtener mas
mas informacion,
registrese aqui
aqui
Producto – Ámbito del problema
21
La primera actividad de gestió
La primera actividad de gestión de un proyecto software es
determinar el á
determinar el ámbito del software (¡¡¡ Incluso antes que la
estimació
estimación cuantitativa!!!)
{ 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 problema
22
y El ámbito NO debe definirse de manera AMBIGUA y debe ser comprensible
tanto a nivel de gestión como a nivel técnico.
y 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).
Para
Para obtener
obtener mas
mas informacion,
registrese aqui
aqui
Producto
23
y Problema inicial
{ Se requieren estimaciones y un plan organizado de abordaje del
problema
{ No se dispone de información sólida
y Actividades
{ Definir el ámbito del problema
{ Descomponer el problema
y Objetivo
{ Conseguir información sólida y consistente para elaborar un plan
Producto – Descomposición del Problema
24
y Análisis de los requisitos del SW
{ DFDs, E/R, Diagramas de despliegue UML…
y Áreas de descomposición
{ Funcionalidad que debe entregarse
{ Proceso que se empleará para entregarla
y Estrategia Æ Divide y vencerás
{ Niveles de particionamiento
{ Refinamiento
Para
Para obtener
obtener mas
mas informacion,
registrese aqui
aqui
Proceso
25
y Tareas iniciales
{ Seleccionar el modelo de proceso
modelo de proceso. Aspectos a tener en cuenta:
Ù Clientes y usuarios
Ù Características del producto en si
Ù Entorno del proyecto y equipo de desarrollo
{ Establecer plan
plan genérico de actividades estructurales (dependientes del
modelo). Estas actividades constituyen un marco de trabajo que deberá
adaptarse a cada proyecto en concreto.
{ Descomposició
Descomposición del proceso en tareas requeridas a los miembros del
equipo de desarrollo
y Resultado
{ Plan completo con las tareas concretas para cubrir las actividades
estructurales
Proceso
26
y Maduración del producto y el proceso
{ Estudio de las tareas del proyecto aplicando las actividades
estructurales
{ Asignación de la funcionalidad del problema a las tareas del
proyecto (matriz)
{ Estimación de recursos para cada función/tarea en
Ù Tiempo
Ù Fechas de inicio y terminación
Ù Productos a fabricar
Para
Para obtener
obtener mas
mas informacion,
registrese aqui
aqui
Proceso
27
y Maduración del producto y el proceso. Ejemplo
{ Actividades estructurales
Ù Comunicación con el cliente
Ù Planificación
Ù Análisis del riesgo
Ù Ingeniería
Ù Construcción y entrega
Ù Evaluación del cliente
Proceso
28
y Maduración del producto y el proceso. Ejemplo
{ Actividades estructurales: 9
{ Tareas (refinamiento de la actividad “Comunicación con el cliente”)
Ù Lista de aspectos a clarificar
Ù Reunión con el cliente para resolverlos.
Ù Desarrollo conjunto del ámbito del proyecto
Ù Revisar el alcance del proyecto
Ù Modificar el alcance
Para
Para obtener
obtener mas
mas informacion,
registrese aqui
aqui
Proyecto
29
y Éxito de la gestión: comprender qué puede ir mal y cómo

hacerlo bien
y 10 señales que indican que un proyecto está en peligro
{ Miembros del equipo no comprenden lo que quiere el cliente
{ Ámbito del producto mal/escasamente definido
{ Cambios mal realizados/documentados
{ Cambios de tecnología
{ Cambios en las necesidades del negocio
{ Fechas de entrega no realistas
{ Incomprensión por parte de los usuarios
{ Pérdida de patrocinadores
{ Equipo de proyecto no tiene las habilidades apropiadas
{ Los gestores (y desarrolladores) no implementan/siguen buenas prácticas
Proyecto
30
Cómo debe actuar un gestor de Proyecto
Enfoque de sentido común (Reel, 1999):
1. Comenzar con el pie derecho
o Entender bien el problema a resolver. Definir objetivos y expectativas
realistas
o Constituir el equipo correcto. Dar al equipo la autonomía, autoridad y
tecnología necesarios para hacer el trabajo
2. Mantener el ímpetu
o Proporcionar incentivos que mantengan los reveses del personal en el
mínimo absoluto
o El equipo debe de resaltar la calidad de cada tarea que realice
o Los gestores deben de mantenerse alejados del equipo: este debe ser
autónomo.
Para
Para obtener
obtener mas
mas informacion,
registrese aqui
aqui
Proyecto
31
3. Seguimiento del progreso
o Mediante la elaboración de productos de trabajo (modelos, código, pruebas,
etc.) y su aprobación (mediante revisiones técnicas formales)
o Además se pueden aplicar medidas del proyecto
4. Tomar decisiones inteligentes
o 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. Realizar un análisis de resultados
o Establecer mecanismos para extraer lecciones aprendidas de cada proyecto
o 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.
Bibliografía
32
y Roger S. Pressman. Ingeniería del Software: Un enfoque práctico. Capítulo 3.
Ed. McGraw Hill. 5ª edición.2002
y M. Piattini et al. Análisis y Diseño detallado de Aplicaciones Informáticas de
Gestión. Ed. Ra‐Ma. 1996
Para
Para obtener
obtener mas
mas informacion,
registrese aqui
aqui

(IS3-2008-09) Gestion de Proyectos - Parte I

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

(IS3-2008-09) Gestion de Proyectos - Parte I

Uploaded by

Copyright:

Available Formats

Gestión de Proyectos I:

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

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

y Éxito de la gestión: comprender qué puede ir mal y cómo

You might also like