Transcript Gestión de Proyectos

PROYECTO
SEGÚN EL R.A.E :
proyecto, ta.
(Del lat. proiectus).
1. adj. Geom. Representado en perspectiva.
2. m. Planta y disposición que se forma para la realización de un tratado, o para la
ejecución de algo de importancia.
3. m. Designio o pensamiento de ejecutar algo.
4. m. Conjunto de escritos, cálculos y dibujos que se hacen para dar idea de cómo
ha de ser y lo que ha de costar una obra de arquitectura o de ingeniería.
5. m. Primer esquema o plan de cualquier trabajo que se hace a veces como
prueba antes de darle la forma definitiva.
Proyecto Informático
El proyecto representa el enunciado de una intervención concreta de la
que se espera tener resultados que contribuyan al logro de los efectos
específicos que un programa define.
Como tal, expresa el nivel operativo del proceso de planificación, por lo
que sus metodologías y técnicas serán de uso habitual para los
profesionales de la Intervención social.
La informática, aun los grandes sistemas, era considerada mas como
una labor artesana, muy próxima al programador, que como una técnica
con necesidad de una planificación efectiva.
Este notable aumento de la complejidad de la informática ha sido la que
ha hecho necesario su consideración como proyecto, asociándose las
técnicas y procedimientos de diseño, planificación y gestión del
proyecto tradicional.
Gestión de Proyectos
Gestión
► La
Gestión de Proyectos implica la planificación,
supervisión, y control del personal, del proceso
y de los eventos que ocurren mientras
evoluciona el software desde la fase preliminar
a la implementación operacional.
► Se concentra en las 4P:




Personal
Producto
Proceso
Proyecto
Personal
Es la parte más importante
► A veces se da por descontado que es así y se actúa en contra
► Los participantes son:
 Gestores superiores (definen los aspectos del negocio)
 Gestores técnicos del proyecto (planifican, motivan,
organizan y controlan)
 Profesionales (Proporcionan las capacidades técnicas para
hacer un producto o aplicación )
 Clientes (Especifican los requisitos del proyecto o aplicación)
 Usuarios finales (Harán uso del software cuando haya sido
entregado)
►
Miembros del
equipo de
desarrollo
Organización del
equipo de desarrollo
► Jerárquico.
 Propuesta por primera vez por Harlan Mills y descrita en
1972.
 También se le conoce como equipo programador jefe
 El núcleo se compone de:
► Programador
o ingeniero en jefe. Planifica, coordina y revisa todas
las actividades técnicas del equipo.
► Personal técnico. Llevan a cabo las actividades de análisis y
desarrollo.
► Ingeniero de apoyo. Ayuda al ingeniero en jefe y puede sustituirle sin
perdida de continuidad del proyecto.
 Además existen especialistas que ayudan al ingeniero en
jefe. Por ejemplo, expertos en bases de datos,
comunicaciones, etc. Y un bibliotecario de software
(librarian), que puede colaborar con varios equipos a la vez
y se encarga de la documentación, listados fuente, ayuda a
recopilar datos de productividad y cataloga e indexa los
módulos u objetos reutilizables.
►
Organización de equipos
según Mantei
Descentralizado democrático (DD).
 No tiene un jefe permanente. Se nombran coordinadores de tareas a
corto plazo y se sustituyen por otros para diferentes tareas.
 Las decisiones y los enfoques se hacen por consenso.
 La comunicación entre los miembros del equipo es horizontal.
►
Descentralizado controlado (DC).
 Tiene un jefe definido que coordina tareas específicas y jefes
secundarios que tienen responsabilidades sobre subtareas.
 La solución de problemas es una actividad del grupo, pero la
implementación de soluciones se reparte entre los subgrupos por el jefe
de equipo.
 La comunicación entre subgrupos e individuos es horizontal.
 También hay comunicación vertical a lo largo de la jerarquía de control.
►
Centralizado controlado (CC).
 El jefe de equipo se encarga de la solución de problemas a alto nivel y la
coordinación interna del equipo.
 La comunicación entre el jefe y los miembros del equipo es vertical.
Existen siete factores de un proyecto
que deben considerarse al planificar
el organigrama de equipos.
1.
2.
3.
4.
5.
6.
7.
Dificultad del problema.
Tamaño del programa en líneas de código o puntos
de función.
Tiempo de vida del equipo.
Grado en que el problema puede ser modularizado.
Calidad requerida y fiabilidad del sistema que se va a
construir.
Rigidez de la fecha de entrega.
Grado de comunicación requerido para el proyecto.
Tipo de
DD
Equipo
DC
CC
x
x
x
x
x
x
Dificultad
Alta
x
Pequeña
Tamaño
Grande
Pequeño
x
Duración del equipo
Corto
Largo
x
Modularidad
Alta
x
Baja
x
Alta
x
x
Fiabilidad
x
Baja
x
Fecha de entrega
Estricta
Flexible
x
x
x
Comunicación
Alta
Pequeña
x
x
x
Paradigmas de organización de
equipos según Constantine
►
►
►
►
Paradigma cerrado.
 Tiene jerarquía tradicional de autoridad similar al equipo CC.
 Trabajan bien cuando producen software similar a otros anteriores, pero
son menos innovadores.
Paradigma aleatorio.
 El equipo se estructura libremente y depende de la iniciativa individual
de los miembros.
 Son buenos cuando se requiere innovación o avances tecnológicos.
 Tienen problemas cuando se requiere un rendimiento ordenado.
Paradigma abierto.
 Estructura el equipo de forma que consiga algunos de los controles
asociados con el paradigma cerrado y mucha de la innovación del
paradigma aleatorio.
 El trabajo se desarrolla en colaboración, con mucha comunicación y
toma de decisiones consensuadas.
 Son adecuados para resolver problemas complejos, pero pueden no ser
tan eficientes como otros equipos.
Paradigma sincronizado.
 Se basa en la partición natural de un problema y organiza los miembros
del equipo para trabajar en partes del problema con poca comunicación
activa entre ellos.
Actividades del equipo de
desarrollo
► Comunicación
con el cliente.
► Planeación.
► Análisis
de riesgos.
► Ingeniería.
► Construcción y liberación.
► Evaluación del cliente.
Toxicidad de un equipo
1.
2.
3.
4.
5.
Atmósfera de trabajo frenética. Se gasta
mucha energía y se descentran los objetivos
Alta frustración por motivos tecnológicos o
personales
Procedimientos coordinados pobremente
Definición confusa de los roles
Continua y repetida exposición al fallo
Para pensar
► Cuanto
demora
► Ley
antes se empieza a programar: más se
de Brooks: Añade más gente a un proyecto
retrasado y harás que se retrase más
Producto
► Ámbito
del software
 Contexto. ¿Cómo encaja el software en el sistema?
 Objetivos. ¿Qué datos son visibles al cliente? ¿Qué
objetos de entrada son requeridos?
 Función y rendimiento. ¿Cómo transforma los datos
de entrada en salida? ¿Qué más hay que saber?
► Descomposición
del problema
 “Divide y triunfarás”
 Top Down
Proceso
► Modelo:






Secuencial Lineal
Cascada(*)
Espiral
Concurrente
Forma
4ta Generación
METODOLÓGIAS DEL
DESARROLLO DE SISTEMAS
DE INFORMACIÓN
METODO ESPIRAL
INTRODUCCIÓN


Son métodos que indican cómo hacer
más eficiente el desarrollo de sistemas
de información. Para ello suelen
estructurar en fases la vida de dichos
sistemas con el fin de facilitar su
planificación, desarrollo y
mantenimiento.
Las metodologías de desarrollo de
sistemas deben definir: objetivos,
fases, tareas, productos y
responsables, necesarios para la
correcta realización del proceso y su
seguimiento.
Los principales objetivos de una
metodología de desarrollo son:






Asegurar la uniformidad y calidad tanto
del desarrollo como del sistema en sí.
Satisfacer las necesidades de los
usuarios del sistema.
Conseguir un mayor nivel de
rendimiento y eficiencia del personal
asignado al desarrollo.
Ajustarse a los plazos y costes previstos
en la planificación.
Generar de forma adecuada la
documentación asociada a los sistemas.
Facilitar el mantenimiento posterior de
los sistemas.
METODO ESPIRAL



Es un modelo de ciclo de vida orientado a
riesgos que divide un proyecto software en
mini-proyectos.
Cada mini proyecto se centra en uno o más
riesgos importantes hasta que todos estén
controlados.
Después de controlar todos los riesgos más
importantes, el modelo en espiral finaliza
del mismo modo que el ciclo de vida en
cascada.(1)
1 .Nota:Cada fase tiene como resultado documentos que deben ser aprobados por
el usuario. Una fase no comienza hasta que termine la fase anterior y
generalmente se incluye la corrección de los problemas encontrados en fases
previas.
Método Desarrollo en Espiral

Funcionamiento:


Se parte de una escala pequeña en medio de la
espiral, se localizan los riesgos, se genera un plan
para manejar los riesgos, y a continuación se
establece una aproximación a la siguiente interacción.
Cada iteración supone que el proyecto pasa a una
escala superior. Se avanza un nivel en el Espiral, se
comprueba que se tiene lo que se desea, y después
se comienza a trabajar en el siguiente nivel:
Método Desarrollo en Espiral


Con cada iteración a través del espiral se
construye sucesivas versiones de software cada
vez más completas. En cada bucle alrededor del
espiral, la culminación del análisis de riesgo
resulta una decisión de “seguir” o “no seguir”.
Cada interacción en el método espiral lleva
consigo los seis pasos : determinar los objetivos,
las alternativas, los límites, la identificación de
riesgos, resolución de riesgos y evaluación de
alternativas.
Federratas:



Debemos de considerar la generación de
entregas de la iteración en el modelo
espiral, comprobando que son correctas.
En el modelo en espiral, las primeras
iteraciones son las menos costosas.
Supone menos gastos, desarrollar el
concepto de operación que realiza el
desarrollo de los requerimientos y
también es menos costoso desarrollar los
requerimientos que se llevarán acabo el
desarrollo del diseño, la implementación
del producto y la prueba del mismo.
En cada Cuadrante del Método espiral
se realiza las siguientes actividades:



Planificación:
Determinación de objetivos, alternativas,
restricciones, y elaboración del plan de
desarrollo para el ciclo actual.
Análisis de Riesgos:
Evaluación de las alternativas, identificación y
resolución de riesgos. Se decide si se sigue o
no con el proyecto
Ingeniería:
Desarrollo del producto siguiendo un modelo de
ciclo de vida : cascada, prototipo, etc.
Evaluación por el cliente, valoración de
resultados, etc.
Aplicación del desarrollo en
espiral al proyecto
En esta figura se
aprecia que el
desarrollo en espiral
esta formado por
ciclos divididos en
cuatro fases:
 Análisis de
requisitos,
 diseño e
implementación,
 pruebas
 y planificación del
próximo ciclo de
desarrollo.
Maduración del Proceso
► Comunicación
con el cliente
► Planificación
► Análisis
de riesgo
► Ingeniería
► Construcción y entrega




Construir
Probar
Instalar
Asistencia (Documentación y Formación)
► Evaluación
del cliente
Proyecto
Para gestionar un proyecto de software con éxito,
debemos comprender que puede ir mal y cómo
hacerlo bien
► Diez señales de peligro (7 indican fallo)
►
1. La gente del software no comprende las necesidades del
cliente
2. El ámbito del producto está definido pobremente
3. Los cambios están mal realizados
4. La tecnología elegida cambia
5. Las necesidades del negocio cambian
6. Las fechas de entrega no son realistas
7. Los usuarios se resisten
8. Se pierden los patrocinadores
9. No hay personal con las habilidades necesarias
10. Los gestores evitan prácticas y sabias lecciones
Cómo actúa un Gestor
► Empieza
con el pie derecho
 Comprende bien el problema
 Objetivos y expectativas realistas
► Mantenerse
► Seguimiento
► Tomar
decisiones inteligentes
► Análisis Post Mortem
Ejercicio
► Hacer
una planilla en Excel con el grupo de
proyecto
► Colocar personas y tareas en columnas y filas
► Definir :
►¿Quién
dirige?
►¿Quién hace cada tarea?
►¿Por qué la hace? Aclarar en la celda correspondiente