Procesos de Software www.kybele.urjc.es
Tema 1: Conceptos de la Gestión de Proyectos
Software
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.
Procesos de Software www.kybele.urjc.es
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
Procesos de Software www.kybele.urjc.es
¿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.
Procesos de Software www.kybele.urjc.es
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.
Procesos de Software www.kybele.urjc.es
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
Procesos de Software www.kybele.urjc.es
¿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.
Procesos de Software www.kybele.urjc.es
Fases de un proyecto
• Planificación y estimacionesInicio
• Seguimiento del ProyectoDesarrollo
• Comprobar que todo ha terminado con “éxito”Final
Procesos de Software www.kybele.urjc.es
¿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
Procesos de Software www.kybele.urjc.es
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
Procesos de Software www.kybele.urjc.es
¿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
Procesos de Software www.kybele.urjc.es
¿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
Procesos de Software www.kybele.urjc.es
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
Procesos de Software www.kybele.urjc.es
Á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
Procesos de Software www.kybele.urjc.es
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
Procesos de Software www.kybele.urjc.es
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?
Procesos de Software www.kybele.urjc.es
¿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
¿Cómo comienza un Proyecto?
Procesos de Software www.kybele.urjc.es
Un chiste demasiado cierto …
Procesos de Software www.kybele.urjc.es
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
¿Cómo comienza un Proyecto?
Procesos de Software www.kybele.urjc.es
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.)
Procesos de Software www.kybele.urjc.es
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
1 - Decisión de emprender el proyecto
Necesidad INTERNA
Procesos de Software www.kybele.urjc.es
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
Necesidad EXTERNA
Procesos de Software www.kybele.urjc.es
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
Necesidad EXTERNA
Procesos de Software www.kybele.urjc.es
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
Procesos de Software www.kybele.urjc.es
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
Procesos de Software www.kybele.urjc.es
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
Procesos de Software www.kybele.urjc.es
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
Procesos de Software www.kybele.urjc.es
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
Procesos de Software www.kybele.urjc.es
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
Procesos de Software www.kybele.urjc.es
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
Procesos de Software www.kybele.urjc.es
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
Procesos de Software www.kybele.urjc.es
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
Procesos de Software www.kybele.urjc.es
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
Procesos de Software www.kybele.urjc.es
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
Procesos de Software www.kybele.urjc.es
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
Procesos de Software www.kybele.urjc.es
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
Procesos de Software www.kybele.urjc.es
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
Procesos de Software www.kybele.urjc.es
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
Procesos de Software www.kybele.urjc.es
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
Procesos de Software www.kybele.urjc.es
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
Procesos de Software www.kybele.urjc.es
•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
Procesos de Software www.kybele.urjc.es
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
Procesos de Software www.kybele.urjc.es
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
Procesos de Software www.kybele.urjc.es
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
Procesos de Software www.kybele.urjc.es
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
Procesos de Software www.kybele.urjc.es
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
Procesos de Software www.kybele.urjc.es
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
Procesos de Software www.kybele.urjc.es
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
Procesos de Software www.kybele.urjc.es
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
Procesos de Software www.kybele.urjc.es
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
Procesos de Software www.kybele.urjc.es
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
Procesos de Software www.kybele.urjc.es
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
Procesos de Software www.kybele.urjc.es
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
Procesos de Software www.kybele.urjc.es
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
Procesos de Software www.kybele.urjc.es
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
Procesos de Software www.kybele.urjc.es
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
Procesos de Software www.kybele.urjc.es
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
¿Cómo debe actuar un director de proyecto?
Procesos de Software www.kybele.urjc.es
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
¿Cómo debe actuar un director de proyecto?
Top Related