Tema 5. Gestión de Proyectos (ISG3)

Tema 5. Gestión de Proyectos
(ISG3)
Antonio José Sáenz Albanés (C.T.O)
Reconocimiento – No Comercial – Compartir Igual - 2.5 - España
Tema 5. Gestión de Proyectos (ISG3)
1
Objetivos del Tema
Introducción a la Gestión de Proyectos
Gestión de Proyectos Pequeños y Medianos
Buenas Prácticas y Agilidad
El Modelo Open Source como Prueba de Concepto
Aplicación a la Práctica de la Asignatura
Tema 5. Gestión de Proyectos (ISG3)
2
Planificación
1ª Clase: Presentación y Conceptos Generales
2ª Clase: Concreción en Entorno de Trabajo
3ª Clase: Revisión de Avance y Dudas
4ª Clase: Defensa y Evaluación Metodológica
Tema 5. Gestión de Proyectos (ISG3)
3
Presentación y Conceptos Generales
Introducción
Métodos y Sistemática
Buenas Prácticas
Open Up
Licencias, Software Libre y Empresa
Referencias
Tema 5. Gestión de Proyectos (ISG3)
4
Introducción
Tema 5. Gestión de Proyectos (ISG3)
5
Objetivo de proyecto
$
Tema 5. Gestión de Proyectos (ISG3)
6
Dimensiones gestión proyectos
Alcance (Entregables)
Plazos (Tiempos)
Esfuerzo (Recursos)
Tema 5. Gestión de Proyectos (ISG3)
7
Visión a 7.000 metros
Plan de Proyecto
Entregable Facturable
Tema 5. Gestión de Proyectos (ISG3)
8
Estimar, planificar, asignar,...
Puntos Función
COCOMO (II)
Delphi
Tema 5. Gestión de Proyectos (ISG3)
9
Seguimiento
Métricas
Tema 5. Gestión de Proyectos (ISG3)
10
¿Es esto gestión de proyectos?
Tema 5. Gestión de Proyectos (ISG3)
11
O, ... ¿Esto?
Tema 5. Gestión de Proyectos (ISG3)
12
Imposibles
Este proyecto es importantísimo, pero no tiene
presupuesto, ni documentación y además es para
mañana. Por fin, esta es tu oportunidad para
impresionar de verdad a todos.
Tema 5. Gestión de Proyectos (ISG3)
13
In-Comunicación
Tema 5. Gestión de Proyectos (ISG3)
14
Causas de proyectos fallidos
Requisitos incompletos: 13%
Falta de participación del cliente: 12%
Recursos inadecuados: 11%
El usuario pide un imposible: 10%
Falta de soporte de gestión: 9%
Cambios en los requisitos: 9%
Planning incorrecto: 8%
Tema 5. Gestión de Proyectos (ISG3)
15
¿Gestión de Proyectos?
La gestión de proyectos en la ingeniería del
software requiere de mecanismos que le permitan
la CONDUCCIÓN del proyecto hacia su éxito.
Entre dichos mecanismos se encuentran:
Sistemática
Procesos
Indicadores (métricas) de gestión
Sentido común, o en su defecto BUENAS
PRÁCTICAS
Tema 5. Gestión de Proyectos (ISG3)
16
Ingeniería
Nuevas
necesidades
Ciencia
Aplicada a la resolución
de problemas de interés
Tecnología
Balance económico y
de oportunidad
Ingeniería
Tema 5. Gestión de Proyectos (ISG3)
17
Métodos y Sistemática
Tema 5. Gestión de Proyectos (ISG3)
18
Respuesta Super Métodos (~'90)
Tema 5. Gestión de Proyectos (ISG3)
19
Procesos, Tareas, Métodos, Ciclos,...
Tema 5. Gestión de Proyectos (ISG3)
20
Problema inesperado “Featuritis”
Nunca 45,00%
Siempre 7,00%
Apenas 19,00%
A menudo 13,00%
A veces 16,00%
© 2002/2006 The Standing Group International
Tema 5. Gestión de Proyectos (ISG3)
21
Respuesta “La Agilidad” (~'00)
Tema 5. Gestión de Proyectos (ISG3)
22
El Manifiesto Ágil (2001)
Estamos descubriendo mejores formas de desarrollar
software, haciéndolo y ayudando a otros a hacerlo. En este
trabajo hemos concluido en valorar:
Individuos e interacciones sobre procesos y
herramientas
Software que funcione sobre documentación detallada
Colaboración con el cliente sobre negociación de
contratos
Respuesta al cambio sobre seguimiento de un plan
Es decir, mientras que encontramos valiosos los términos de
la derecha, consideramos más valiosos los de la izquierda
Tema 5. Gestión de Proyectos (ISG3)
23
Individuos e Interacciones
La gente es el principal factor de éxito de un
proyecto software.
Es más importante construir un buen equipo que
construir el entorno.
Muchas veces se comete el error de construir
primero el entorno y esperar que el equipo se
adapte automáticamente.
Es mejor crear el equipo y que éste configure su
propio entorno de desarrollo en base a sus
necesidades.
Tema 5. Gestión de Proyectos (ISG3)
24
Software que funcione
La regla a seguir es “no producir documentos a
menos que sean necesarios de forma inmediata
para tomar un decisión importante”.
Estos documentos deben ser cortos y centrarse en
lo fundamental.
Tema 5. Gestión de Proyectos (ISG3)
25
Colaboración con el Cliente
Se propone que exista una interacción constante
entre el cliente y el equipo de desarrollo.
Esta colaboración entre ambos será la que marque
la marcha del proyecto y asegure su éxito.
Tema 5. Gestión de Proyectos (ISG3)
26
Respuesta al Cambio
La habilidad de responder a los cambios que
puedan surgir a los largo del proyecto (cambios en
los requisitos, en la tecnología, en el equipo, etc.)
determina también e l éxito o fracaso del mismo.
Por lo tanto, la planificación no debe ser estricta
sino flexible y abierta.
Tema 5. Gestión de Proyectos (ISG3)
27
El Manifiesto Ágil (2001)
Kent Beck
Andrew Hunt
Mike Beedle
Ron Jeffries
Arie van Bennekum
Jon Kern
Alistair Cockburn
Brian Marick
Ward Cunningham
Robert C. Martin
Martin Fowler
Steve Mellor
James Grenning
Ken Schwaber
Jim Highsmith
Jeff Sutherland
Dave Thomas
Tema 5. Gestión de Proyectos (ISG3)
28
Principios (i)
Prioridad de satisfacer al cliente a través de la
entrega temprana y continua de software de valor.
Dar la bienvenida a los cambios de requisitos,
incluso al final del desarrollo. Los procesos ágiles
usan el cambio para darle una ventaja competitiva
al cliente.
Entregas frecuentes de software que funcione,
desde cada dos semanas a cada dos meses, con
preferencia el el ritmo más rápido.
Los responsables del negocio y los desarrolladores
deben trabajar juntos durante todo el proyecto.
Tema 5. Gestión de Proyectos (ISG3)
29
Principios (ii)
Contruir proyectos con personas motivadas. Deles
el ambiente y el apoyo que necesitan, y confíe en
que harán su trabajo.
La forma más eficiente y efectiva de traspasar
información hacia y desde un equipo de desarrollo
es la conversación cara-a-cara.
El software que funcione es la principal medida de
avance.
Los procesos ágiles promueven el desarrollo
sostenible. Los auspiciadores, desarrolladores y
usuarios deben ser capaces de mantener un paso
constante indefinidamente.
Tema 5. Gestión de Proyectos (ISG3)
30
Principios (y iii)
La atención constante por la excelencia técnica y
el buen diseño aumenta la agilidad.
La simplicidad --el arte de maximizar la cantidad
de trabajo no hecho-- es esencial.
Las mejores arquitecturas, requisitos y diseños
emergen de los equipos auto-organizados
A intervalos regulares, el equipo reflexiona sobre
cómo hacerse más efectivo, luego afina y ajusta
su comportamiento según eso.
Tema 5. Gestión de Proyectos (ISG3)
31
Nuevas Técnicas
Refactorización (refactoring)
Cambios en el diseño sobre el sistema implementado
Pruebas automáticas
Pruebas exhaustivas del sistema cuyos resultados se
comparan con resultados esperados
Integración continua
Automatización de la integración de sistemas de modo de
permitir pruebas automáticas muy frecuentes
Gestión de configuración
Hecha de una forma especial para apoyar la interacción y
la integración continua
Tema 5. Gestión de Proyectos (ISG3)
32
Ágil vs Tradicional
Basadas en heurísticas provenientes de
prácticas de producción de código
Especialmente preparados para cambios
durante el proyecto
Impuesta internamente
Proceso menos controlado, con pocos
principios
El contrato es flexible
Basadas en normas provenientes de
estándares seguidos por el entorno de
desarrollo
Presenta cierta resistencia al cambio
Impuesta externamente
Proceso muy controlado, con numerosas
políticas y normas
Contrato prefijado
El cliente interactúa formalmente en
El cliente es parte del equipo de desarrollo reuniones
Equipos pequeños y/o en contacto físico Grupos grandes y/o distribuidos
Pocos artefactos
Numerosos artefactos
Pocos roles
Numerosos roles
Menor énfasis en la arquitectura
Arquitectura y modelos fundamentales
Tema 5. Gestión de Proyectos (ISG3)
33
Arquitectura (Cascada)
Se diseña una arquitectura apropiada para todos
los requisitos
Respuesta a cambios:
Difícil o fácil según encaje en la arquitectura
Difícil de explicar las diferencias del impacto al cliente
Esto genera desconfianza
Tema 5. Gestión de Proyectos (ISG3)
34
Arquitectura (Evolutiva)
Se reconoce que existirán cambios
Arquitecturas flexibles
Basadas en Mensajes
Desacople Interfaz / Implementación, ...
Problemas
Arquitecturas más complejas
Difícil predecir cambios
Aún así no acepta todos los cambios...
Tema 5. Gestión de Proyectos (ISG3)
35
Arquitectura (Ágil)
Se parte de arquitectura simple enfocada a
requisitos de primera iteración
La arquitectura puede cambiar si no se adapta al
cambio de requisitos
Tema 5. Gestión de Proyectos (ISG3)
36
Valor
Tema 5. Gestión de Proyectos (ISG3)
37
Valor
Tema 5. Gestión de Proyectos (ISG3)
38
Valor
Tema 5. Gestión de Proyectos (ISG3)
39
Valor
Tema 5. Gestión de Proyectos (ISG3)
40
Valor
Tema 5. Gestión de Proyectos (ISG3)
41
Valor
Tema 5. Gestión de Proyectos (ISG3)
42
XP (Coste de los Cambios)
“El error es usualmente 100 veces más caro de
corregir en la fase de mantenimiento que en la
fase de requisitos.” (Barry Boehm, Software Engineering
Economics, 1981, p. 40.)
Tema 5. Gestión de Proyectos (ISG3)
43
Implantación (R.O.I)
Tema 5. Gestión de Proyectos (ISG3)
44
Implantación (Éxito)
Tema 5. Gestión de Proyectos (ISG3)
45
Implantación (Chasm)
Tema 5. Gestión de Proyectos (ISG3)
46
Malinterpretaciones
Tema 5. Gestión de Proyectos (ISG3)
47
Buenas Prácticas
Tema 5. Gestión de Proyectos (ISG3)
48
Modelar la actividad por procesos
Con adecuada periodicidad
Facilitan el uso de indicadores
Enfocan las métricas
Permiten especializaciones y control de
granularidad
Seleccionando de “metodologías” de suficiente
uso
Métrica v3; (R/E/Open/Agile/Basic) UP; ITIL, ...
Tema 5. Gestión de Proyectos (ISG3)
49
Un poco sobre métricas
Dinámica
1.Plantear meta
2.Selección indicador
1.“Accionable”
2.Suficiente periodicidad
3.Valor Objetivo y márgenes
4.Plantear acciones
5.Evaluar indicadores
6.Replantear acciones
¿minimizan $ global?
Tema 5. Gestión de Proyectos (ISG3)
50
Granularidad de procesos
Tema 5. Gestión de Proyectos (ISG3)
51
Gestión Requisitos Formal
Gestionar:
Interlocutores
Validaciones
Cambios
Indicador objetivo ;-)?
Ejemplos de indicadores:
# Requisitos identificados
# Requisitos modelados formalmente (casos de uso, etc.)
# Requisitos validados por el cliente
Tema 5. Gestión de Proyectos (ISG3)
52
Planear Entregas Parciales
Minimizan el cash-flow
Minimizan riesgos
Facilitan replanificaciones
Entregables Facturables
Terminación
Planificada
Inicialmente
FASES e Hitos
Tema 5. Gestión de Proyectos (ISG3)
53
Modelar vs. Documentar (i)
Modelar: aprender / comunicar / reutilizar
Documentar: entregable contractual
Problemas
Los mismos artefactos (son costosos)
Cuidado con los indicadores / métricas
Buena Práctica: Modelar lo imprescindible
Reutilizar Frameworks, patrones como guía de
lectura y documentar sólo las diferencias, Técnicas
de código “legible”
Tema 5. Gestión de Proyectos (ISG3)
54
Modelar vs. Documentar (ii)
Arquitectura / Análisis / Diseño
Ejemplos de indicadores:
# subsistemas modelados por patrones
# modelos reutilizados
# modelos no basados en patrones
• Vamos a usar el Patrón “Cadena de
Responsabilidad” para “tal cosa”
• Hemos seleccionado Oracle porque cumple los
requisitos de prestaciones y el cliente ya tiene
licencia y administradores cualificados
• Vamos a aplicar la siguiente arquitectura de
red.
• Estamos aplicando estos esquemas J2EE
• Distribuiremos los componentes entre las capas
de la siguiente manera
Tema 5. Gestión de Proyectos (ISG3)
55
Desarrollo basado en pruebas
Diseñar la solución
Definición de la interfaz a probar
Crear pruebas para la solución
Las pruebas deben ejecutarse y fallar
Implementar la solución
Las pruebas deben ejecutarse y
pasarse ok
Trabajar en incrementos tan pequeños
como sea posible
Tema 5. Gestión de Proyectos (ISG3)
56
Desarrollo basado en pruebas (ii)
Las pruebas de desarrollo tejen la
implementación de la solución
No se muestra los bucles cortos
de realimentación
Ejemplos de indicadores:
# Tests por requisito funcional
# Tests verificados por iteración
# Requisitos sin Test
Refinar
la Arquitectura
Diseñar
la Solución
Implementar las pruebas
de desarrollo
Implementar
la Solución
Ejecutar las pruebas
de desarrollo
Tema 5. Gestión de Proyectos (ISG3)
57
Control adaptativo proyecto (i)
Indicadores globales objetivo
< # “funcionalidades” no usadas
< $ por h.h. inútiles
< Coste por riesgos
Basados en indicadores de avance
Requiere suficiente granularidad
Gestión priorizada de requisitos
Iteraciones verificadas
...
Tema 5. Gestión de Proyectos (ISG3)
58
Control adaptativo proyecto (ii)
Terminación
Planificada
Inicialmente
Entregables Facturables
Terminación
Real
FASES e Iteraciones
2
1
3
4
5
6
Camino Inicial Planificado
1
2
3
Plan de Proyecto
Actualizado
Alta Prioridad
Camino
4
Real
5
6
7
Implementados en Iteración
Requisitos
bien definidos
Visión y Alcance
Nuevos
Repriorizados
Requisitos
vagos
Eliminados
Baja Prioridad
Espacio de
Satisfacción del
Stakeholder
Criterios de Evaluación
Riesgos
Registro de Pruebas
Lista de Work Items
Tema 5. Gestión de Proyectos (ISG3)
59
Control adaptativo proyecto (iii)
Alta Prioridad
Implementados en Iteración
Requisitos
bien definidos
Nuevos
Repriorizados
Requisitos
vagos
Eliminados
Baja Prioridad
Nunca 45,00%
Lista de Work Items
Ejemplos de indicadores:
Siempre 7,00%
Apenas 19,00%
# Requisitos Implementados / Req.
Totales / Iteración
A menudo 13,00%
A veces 16,00%
# Req. Nuevos-Eliminados / Iteración
Tema 5. Gestión de Proyectos (ISG3)
60
Open UP
Tema 5. Gestión de Proyectos (ISG3)
61
El Proyecto “Eclipse Process Framework (EPF)”
Suministra un ecosistema abierto y colaborativo
para la evolución de los procesos de desarrollo de
software
Suministra ejemplos de prácticas, configuración
de procesos y un metamodelo, que se pueden
usar de fundamento para una gran variedad de
procesos que sirvan para abordar las necesidades
de las Tecnologías de la Información
Utiliza a la comunidad de Eclipse para ganar
amplia aceptación del marco de trabajo
Tema 5. Gestión de Proyectos (ISG3)
62
El Ecosistema EPF
Inhouse
Content
EXTENSIONES
G.
G.
●G.
●
●
de
de
de
Proyectos
Operaciones
Sistemas
Plug-ins
Free Process
Content
Plug-ins
Open Unified Process (OpenUP)
Ingeniería de
Software
Commercial
Process
Arquitectura
Basada en
Guiada por
Aportar
Valor
Basic Unified
Process
OpenUP/Basic
Adapted
Adapted from
from RUP
RUP
Content
Plug-ins
Modelos
Marco de Trabajo
Ágil y Consolidado
Scrum
Otros Procesos ágiles
●
●
XP
Scrum
●
DSDM
●
AMDD
Extensible, Adaptable, FlexibleUTILIDADES (de Autor, de Publicación)
Extensiones de
Herramientas
Vocabulario
y Lenguaje
Comunes METAMODELO (Arquitectura de Método Unificado)
Common
Language
& Vocabulary
Desarrollo
enDevelopment
Software
de Fuentes
Abiertas
Open Source
Tema
5. Gestión
de
ECLIPSE
Proyectos
(ISG3)
63
¿Qué es OpenUP?
Un proceso iterativo de desarrollo de software que es mínimo,
completo y extensible.
• Mínimo – sólo incluye lo fundamental
• Completo – se puede considerar como un proceso para construir
sistemas enteros
• Extensible – se puede utilizar como el fundamento sobre el que
incorporar y adaptar procesos a medida que se necesiten
Tema 5. Gestión de Proyectos (ISG3)
64
Analista
Stakeholder
Probador
Desarrollador
penUP
Jefe de
Proyecto
Arquitecto
Tema 5. Gestión de Proyectos (ISG3)
65
Analista
Stakeholder
Probador
Desarrollador
penUP
Jefe de
Proyecto
Arquitecto
Tema 5. Gestión de Proyectos (ISG3)
66
Analista
Stakeholder
Probador
Desarrollador
penUP
Jefe de
Proyecto
Arquitecto
Tema 5. Gestión de Proyectos (ISG3)
67
Analista
Stakeholder
Probador
Desarrollador
penUP
Jefe de
Proyecto
Arquitecto
Tema 5. Gestión de Proyectos (ISG3)
68
Analista
Stakeholder
Probador
Desarrollador
penUP
Jefe de
Proyecto
Arquitecto
Tema 5. Gestión de Proyectos (ISG3)
69
Analista
Stakeholder
Probador
Desarrollador
penUP
Jefe de
Proyecto
Arquitecto
Tema 5. Gestión de Proyectos (ISG3)
70
Colaboración y Objetivos (Niveles)
Tema 5. Gestión de Proyectos (ISG3)
71
Principios
OpenUP se apoya en un conjunto de principios
fundamentales:
Colaborar para alinear los intereses y compartir
el conocimiento
Evolucionar para obtener continuamente
realimentación y mejoras
Equilibrar prioridades enfrentadas para
miximizar el valor aportado al stakeholder
Enfocarse en articular la arquitectura
Tema 5. Gestión de Proyectos (ISG3)
72
Colaboración
Mantener un conocimiento común
Artefactos Clave: Visión, requisitos, arquitectura, plan de iteración
Fomentar un ambiente de confianza
Gestionar por objetivos, derribar muros, comprender la
perspectiva de los demás
Compartir responsabilidades
El producto pertenece a todos, luego debemos ayudarnos unos a
otros
Aprendizaje continuo
Desarrollar capacidades técnicas y de colaboración, debemos ser
estudiantes y profesores a la vez
Organizarse alrededor de la arquitectura
A medida que los equipos crecen, debemos tener equipos de
equipos enfocados en pequeños componentes
Tema 5. Gestión de Proyectos (ISG3)
73
Formas de los Requisitos
La Visión define el punto de vista del stakeholder
sobre el producto
Los Casos de Uso definen escenarios de usuario
Cualquier requisitos basado en escenarios lo haría
Los Requisitos de Soporte cubren aspectos
técnicos y otros no referentes al uso del producto
Los “Work Items” (elementos de trabajo)
referencian requisitos del producto con más
detalle
Tema 5. Gestión de Proyectos (ISG3)
74
Definición Iterativa de Requisitos
La Visión define el producto
La identificación de los Casos de Uso define el
alcance de una release (versión, liberación)
Los detalles de los casos de uso conducen el
trabajo dentro de una iteración
Los Requisitos de Soporte se gestionan a lo largo
de todo el ciclo de vida
Tema 5. Gestión de Proyectos (ISG3)
75
Objetivo: Casos de Pruebas
Casos de Pruebas
Están alineados con requisitos y errores
Especifican las condiciones que deben validarse
Esbozan los datos necesarios
Por su parte los Script de Pruebas (de los subprocesos de
la Solución)
Están alineados con los Casos de Pruebas
Son instucciones detalladas paso a paso
Coomplementados por datos de pruebas
Es mejor que estén automatizados
Los Casos de Pruebas son una forma de “Test First Design
(TFD)” (Diseño guiado por las pruebas)
Tema 5. Gestión de Proyectos (ISG3)
76
Roles Orientados al Objetivo
Analista
Captura, organiza y prioriza requisitos
Stakeholder
Conduce el objetivo; el proyecto debe satisfacer
sus necesidades
Probador
Define los criterios para aceptar una solución
EL Jefe de Proyecto actualizará la Lista de “Work Items”
con elementos (items) agrupados y priorizados
El Arquitecto y el Desarrollador producirán una solución
que cumpla con el “objetivo”
Tema 5. Gestión de Proyectos (ISG3)
77
Identificar la Meta Final
Tu meta es encontrar un camino
desde Aquí hasta Allí
Punto de Arranque del
Proyecto
Espacio de
Satisfacción del
Stakeholder
Tema 5. Gestión de Proyectos (ISG3)
78
Divide y Vencerás
Terminación
Planificada
1
2
3
4
5
6
Camino Planificado
Inicial
Plan de Proyecto
Espacio de
Satisfacción del
Stakeholder
Tema 5. Gestión de Proyectos (ISG3)
79
Hitos de Gestión
Terminación
Planificada
1
3
2
4
5
6
Planned Path
Comienzo Elaboración
Construcción
Transición
¿Comprendemos ¿Comprendemos
el problema?
la solución?¿Características¿Listo
completadas? para
Liberar?
Espacio de
Satisfacción del
Stakeholder
Tema 5. Gestión de Proyectos (ISG3)
80
Priorizar y Gestionar el Trabajo
Alta Prioridad
Los work items de alta prioridad
deberían estar bien definidos
Los work items de baja prioridad
pueden ser vagos
En cada iteración se implementan
los work items de mayor prioridad
Se pueden añadir nuevos work items
en cualquier momento
Los work items se pueden
repriorizar en cualquier momento
Se pueden eliminar work items
en cualquier momento
Baja Prioridad
Lista de Work Items
Tema 5. Gestión de Proyectos (ISG3)
81
Conceptos Clave: Estimación Ágil
Tamaño (puntos):
Para cada work item, esimamos lo grande que es.
Nos enfocamos en su tamaño relativo, así que es
clave ser consistentes dentro de nuestra lista de
work items.
Velocidad
Una medida de cuantos puntos se liberan
(entregan) en cada iteración
Esfuerzo (días o horas):
Estimación del esfuerzo real.
Tema 5. Gestión de Proyectos (ISG3)
82
Planifica Tu Iteración
Especifica la velocidad objetivo (deseada) y esboza los objetivos de la
iteración en el Plan de Iteración
Analiza el Work Item de mayor prioridad
Estima el esfuerzo en horas
Si es demasiado grande para caber en la iteración, divídelo en work items menores
Añádelo al Plan de Iteración
Analiza el siguiente work item por orden de prioridad hasta que el Plan de Iteración
esta “lleno”
Especifica las pruebas y otros criterios de “evaluación” (assessment)
Estimar y añadir
al plan de iteración
Objetivos de la Iteración
●Lista de Work Items de la Iteración
●Resultados de Medidas y Pruebas
●
Plan de Iteración
Lista de Work Items
Tema 5. Gestión de Proyectos (ISG3)
83
Conducción por Criterios de Evaluación de la
Iteración
Terminación
Planificada
2
1
3
4
5
6
Camino Planificado
1
Actualizado
2
3
Camino
4
Real
5
6
7 Espacio de
Satisfacción del
Stakeholder
Plan de Proyecto
Tema 5. Gestión de Proyectos (ISG3)
84
El Rol de la Arquitectura
Suministra el contexto para el diseño y la
implementación
Suministra una mitigación de riesgos
Mejora la “predictabilidad” del plan
Definirla pronto, mejorarla y evolucionarla
Tema 5. Gestión de Proyectos (ISG3)
85
La Arquitectura y los Principios
Colaborar
La arquitectura ayuda a mantener un conjunto de conocimientos
técnicos comunes
Equilibrar
Las decisiones tomadas sobre la arquitectura son parte de un
equilibrio para alcanzar el máximo beneficio para el stakeholder
dentro de de las restricciones
Enfocarse
Utiliza la arquitectura para resaltar las decisiones técnicas
esenciales
Evolucionar
Las evoluciones tempranas aseguran la viabilidad del producto y
minimizan los riesgos
Tema 5. Gestión de Proyectos (ISG3)
86
Representación de la Arquitectura
No se requieren documentos pesados
Gran parte de la arquitectura se puede:
Seleccionar en vez de diseñar
Referenciar en vez de describir
• Vamos a usar el Patrón “Cadena de Responsabilidad”
para “tal cosa”
• Hemos seleccionado Oracle porque cumple los
requisitos de prestaciones y el cliente ya tiene
licencia y administradores cualificados
• Vamos a aplicar la siguiente arquitectura de red.
• Estamos aplicando estos esquemas J2EE
• Distribuiremos los componentes entre las capas de
la siguiente manera
Tema 5. Gestión de Proyectos (ISG3)
87
Diseño
Pasos
Comprender los requisitos, identificar un escenario
Identificar sus elementos
Determinar como colaboran esos elementos
Refinar las decisiones, los aspectos internos del
diseño
Comunicarlo
¿Aprueba un análisis?
Si es apropiado.
¿Diseño visual?
Si es apropiado.
¿Usar una herramienta de diseño?
Si es apropiado.
¿Diseño de larga duración?
Si es apropiado.
Tema 5. Gestión de Proyectos (ISG3)
88
Desarrollo Guiado por Work Items
Seleccionar uno de los “work item” de los
asignados a la actual iteración
Colaborar con el equipo si es necesario
descomponerlo en otros menores
Identificar el contexto de requisitos
Adjuntos: Casos de uso, requisitos de soporte,
información de “bugs” errores, casos de prueba
Recolectar cualquier información adicional
Repetir hasta completar:
Construir una pequeña solución que se verifique
con pruebas de desarrollo (developer tests)
Comprobar que se ha completado utilizando las
puebas deTema
sistema
5. Gestión de Proyectos (ISG3)
89
Diseño basado en pruebas
Diseñar la solución
Definición de la interfaz a probar
Crear pruebas para la solución
Las pruebas deben ejecutarse y
fallar
Implementar la solución
Las pruebas deben ejecutarse y
pasarse ok
Trabajar en incrementos tan
pequeños como sea posible
Tema 5. Gestión de Proyectos (ISG3)
90
Diseño Basado en Pruebas
Las pruebas de
desarrollo tejen la
implementación de la
solución
Refinar
la Arquitectura
Diseñar
la Solución
No se muestra en el
dibujo los bucles cortos
de realimentación
Implementar las pruebas
de desarrollo
Implementar
la Solución
Ejecutar las pruebas
de desarrollo
Tema 5. Gestión de Proyectos (ISG3)
91
Roles Relevantes a la Solución
Desarrollador
Diseña e implementa la solución
Arquitecto
Toma las decisiones técnicas claves y estructura la
solución
Probador
Implementa y conduce las pruebas que verifican la
solución
EL Jefe de Proyecto monitoriza el desarrollo
El Stakeholder participa en la verificación de la solución
El Analista suministra información adicional
Tema 5. Gestión de Proyectos (ISG3)
92
Ejemplo: Iteraciones en la Práctica
Asumiendo iteraciones de ~6 semanas de duración:
1 semana de planificación, análisis y diseño
3-4 semanas de diseño y codificación
1-2 semanas de pruebas y cierre
Muchos miembros del equipo pueden hacer también diseño y codificación en
la primera semana
Las integraciones semanales suelen probar el grado de avance; las
integraciones quincenales suelen inyectar disciplina y repitabilidad
Los temas de alto nivel y los artefactos de objetivo para cada iteración los
deciden los líderes de desarrollo basándose en criterios de negocio y
escenarios de casos de uso
Los planes detallados de la iteración los suministran los equipos del
componente (enlazando cada línea con el caso de uso y escenario)
La integración resultante de la iteración se contrasta contra los casos de uso
y se publican para tener una visibilidad más amplia
El contenido importa – se debe inyectar contenido interesante en cada
iteración planificada para asegurar su adopción y progresión a traves de
cada integración de iteración
Las fechas importan – se deben revisar siguiendo cada iteración de entrega.
Las iteraciones estan constreñidas (timeboxed). Las Fases no.
Tema 5. Gestión de Proyectos (ISG3)
93
Lecciones Prácticas
Es fácil, incluso tentador deslizar funciones de una iteración a la siguiente;
esto inevitablemente termina en un colapso a medida que nos acercamos a
la entrega
Si reducimos las 1-2 semanas del periodo de cierre, se genera poca
estabilidad
El ratio de adopción se ve afectado significativamente por la estabilidad de la
iteración y por la facilidad para descargarlas
Existe una tendencia de no documentar adecuadamente las nuevas
funcionalidades que van en una iteración; esto dificulta establecer que cosas
hay nuevas y excitantes
Tema 5. Gestión de Proyectos (ISG3)
94
Licencias, Software Libre y Empresa
Tema 5. Gestión de Proyectos (ISG3)
95
Un Poco de Historia
Orígenes de la informática
Ciencia aplicada
Acceso a los fuentes, Rápida evolución (Algorítmica, ...)
'70 Enfrentamiento
Modelos de negocio propietario de pago por uso
Ética de los Hackers del M.I.T. (acceso al fuente).
'80 Free Software Foundation
Licencia GPL (Software Libre).
'90 Iniciativa del Software de Fuentes Abiertas
Modelo de desarrollo cooperativo.
Proliferan Licencias (OSI).
'00 Se extrapola a otros campos
Wikipedia, Conocimiento Libre, ...
Tema 5. Gestión de Proyectos (ISG3)
96
Visiones del Software Libre
Ética y Derechos del
Usuario
Modelo de Desarrollo
Colaborativo
Tema 5. Gestión de Proyectos (ISG3)
97
Free Software Foundation
El uso de Software Libre concede DERECHOS
Uso libre
Adaptación (acceso al código fuente)
Redistribución
Mejorar y compartir sus mejoras
Protecciones Adicionales (GPLv3)
Anti-Tivoización
Anti-Restricción de Derechos Digitales (DRM)
Patentes
Tema 5. Gestión de Proyectos (ISG3)
98
Open Source Initiative
Desarrollador (Fuentes Abiertas)
Redistribución
Acceso al fuente
Modificación
Integridad del código del autor
No discriminación de personas
No discriminación de uso
Licencia “distribuible”
Licencia no atada al producto
No impedir del uso con otros productos
Licencia tecnológicamente neutra
Tema 5. Gestión de Proyectos (ISG3)
99
Popularidad de Licencias*
GNU/GPL
GNU/LGPL
BSD
MIT
Artistic
Apache 2.0
Otros
(*) Diciembre de 2006 (analizados > 30.000 proyectos) en Freshmeat.net
Tema 5. Gestión de Proyectos (ISG3)
100
Compatibilidad de Licencias
Tema 5. Gestión de Proyectos (ISG3)
101
Errores de Interpretación
El software libre es gratis
Cuesta dinero y se puede exigir dinero por él
Hay mucho software gratis que no es libre (IE)
El software libre es “de dominio público”
Copyright del autor y licencia asociada
Debo hacer siempre público el código fuente
No, sólo a quién se lo suministro
Es de baja calidad (porque es gratis)
No, prima la calidad frente al ciclo de “nuevas
prestaciones” y obsolescencia controlada
Tema 5. Gestión de Proyectos (ISG3)
102
S.L. Motor de Innovación
Combina dos poderosos mecanismos de
innovación
La competencia
Todos los contendientes emplean el mismo conjunto de
programas de partida, sin exclusividades.
La cooperación (incluso entre empresas rivales)
Todos los contendientes disponen de la mejoras que cada
uno ha aportado al conjunto de partida.
Cambio de ecosistema
Desde un contexto favorable a los monopolios de
empresa
Hacia otro favorable a los monopolios de productos
Con un conjunto de empresas dándoles soporte
Tema 5. Gestión de Proyectos (ISG3)
103
La Estándarización Favorece S.L.
Tema 5. Gestión de Proyectos (ISG3)
104
¿Qué software hay?
Tema 5. Gestión de Proyectos (ISG3)
105
Repositorios e Índices
http://sourceforge.net/
http://freshmeat.net/
Tema 5. Gestión de Proyectos (ISG3)
106
Sistemas Operativos
Tema 5. Gestión de Proyectos (ISG3)
107
Infraestructuras de red
Tema 5. Gestión de Proyectos (ISG3)
108
Bases de Datos
Tema 5. Gestión de Proyectos (ISG3)
109
Servidores de Aplicación
Tema 5. Gestión de Proyectos (ISG3)
110
Escritorio
Tema 5. Gestión de Proyectos (ISG3)
111
Ofimática
Tema 5. Gestión de Proyectos (ISG3)
112
Colaboración y Navegación
Thunderbird
Firefox
Tema 5. Gestión de Proyectos (ISG3)
113
Aplicaciones de Empresa
Tema 5. Gestión de Proyectos (ISG3)
114
Seguridad
Tema 5. Gestión de Proyectos (ISG3)
115
Modelos de Negocio
Tema 5. Gestión de Proyectos (ISG3)
116
Empresa Desarrolladora
Cambios
Puede competir sin importar su tamaño.
Tecnología punta muy barata.
Puede aprovechar el trabajo de su competencia.
Puede conseguir la colaboración de la comunidad, a bajo
coste.
Canal de distribución barato, efectivo y global.
Puede convertir sus productos en aplicaciones de
referencia.
¿Ingresos?
Juega con ventaja al conocer su producto
Marketing de calidad técnica
Desarrollos a medida e integraciones
Canal de
soporte
a medida
Tema
5. Gestión
de Proyectos (ISG3)
117
Empresa Integradora
Cambios
Gran variedad y disponibilidad de componentes a bajo
coste
No traslada al cliente costes de licencia, sólo por su
trabajo
Puede modificar los “componentes” para encajarlos mejor
o aprovechar sus características
Se aproxima a la empresa desarrolladora
Tema 5. Gestión de Proyectos (ISG3)
118
Mantenimiento y Soporte
Cambios
Bajo coste de componentes
Acceso al código y su reparación
Traslada sólo sus costes y hay un amplio mercado
Tema 5. Gestión de Proyectos (ISG3)
119
Otros Modelos de Negocio
Empaquetadores (Ubuntu, Red Hat)
Loss Leaders (Novell – Ximian)
Crea un producto libre
Tiene amplia base de usuarios
Vende soporte y adaptaciones
Gadgets
Dispositivos físicos con funciones soft avanzadas (Linksys)
Consultores
Aplicaciones que requieren servicios on-line
Se cobra por dichos servicios (Half-life)
Tema 5. Gestión de Proyectos (ISG3)
120
¿Y para mí?
Tema 5. Gestión de Proyectos (ISG3)
121
S.O. y Escritorio (Unbuntu / Kubuntu)
Tema 5. Gestión de Proyectos (ISG3)
122
Ofimática (Open Office)
Tema 5. Gestión de Proyectos (ISG3)
123
Ofimática (Colaboración)
Firefox
Thunderbird
Tema 5. Gestión de Proyectos (ISG3)
124
Organización (FreeMind - Ideas)
Tema 5. Gestión de Proyectos (ISG3)
125
Organización (GTD - ThinkingRock)
Tema 5. Gestión de Proyectos (ISG3)
126
Planificación (OpenProj)
Tema 5. Gestión de Proyectos (ISG3)
127
Gestión Proyectos (dotProject)
Tema 5. Gestión de Proyectos (ISG3)
128
Diagramación (Umbrello - Dia)
Tema 5. Gestión de Proyectos (ISG3)
129
Diagramación Técnica (QCAD)
Tema 5. Gestión de Proyectos (ISG3)
130
Gestión Documental (Alfresco)
Tema 5. Gestión de Proyectos (ISG3)
131
Referencias
Tema 5. Gestión de Proyectos (ISG3)
132
Referencias
Manifesto for Agile Software Development. http://www.agilealliance.org/
The Agile Alliance. http://www.agilealliance.org/home
Agile Modeling / EUP http://enterpriseunifiedprocess.info, http://www.agilemodelling.com
Open UP http://epf.eclipse.org/wikis/openup/
Free Software Foundation http://www.fsf.org
Open Source Initiative http://opensource.org
Agile Testing. http://www.testing.com/agile/
Tema 5. Gestión de Proyectos (ISG3)
133
¡Gracias!.. ¿Preguntas?
us@ajsa.net
Tema 5. Gestión de Proyectos (ISG3)
134