tema 5. gestión de proyectos (isg3)
TRANSCRIPT
1Tema 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
2Tema 5. Gestión de Proyectos (ISG3)
Objetivos del TemaIntroducció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
3Tema 5. Gestión de Proyectos (ISG3)
Planificación1ª 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
4Tema 5. Gestión de Proyectos (ISG3)
Presentación y Conceptos GeneralesIntroducción
Métodos y Sistemática
Buenas Prácticas
Open Up
Licencias, Software Libre y Empresa
Referencias
7Tema 5. Gestión de Proyectos (ISG3)
Dimensiones gestión proyectos
Alcance (Entregables)
Plazos (Tiempos)
Esfuerzo (Recursos)
9Tema 5. Gestión de Proyectos (ISG3)
Estimar, planificar, asignar,...
Puntos Función
COCOMO (II)
Delphi
13Tema 5. Gestión de Proyectos (ISG3)
Imposibles
Este proyecto es importantísimo, pero no tienepresupuesto, ni documentación y además es paramañana. Por fin, esta es tu oportunidad paraimpresionar de verdad a todos.
15Tema 5. Gestión de Proyectos (ISG3)
Causas de proyectos fallidosRequisitos 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%
16Tema 5. Gestión de Proyectos (ISG3)
¿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
17Tema 5. Gestión de Proyectos (ISG3)
Ingeniería
Ciencia
Aplicada a la resoluciónde problemas de interés
Tecnología
Balance económico yde oportunidad
Ingeniería
Nuevasnecesidades
21Tema 5. Gestión de Proyectos (ISG3)
Problema inesperado “Featuritis”
Nunca 45,00%
Apenas 19,00%
A veces 16,00%A menudo 13,00%
Siempre 7,00%
© 2002/2006 The Standing Group International
23Tema 5. Gestión de Proyectos (ISG3)
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
24Tema 5. Gestión de Proyectos (ISG3)
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.
25Tema 5. Gestión de Proyectos (ISG3)
Software que funcioneLa 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.
26Tema 5. Gestión de Proyectos (ISG3)
Colaboración con el ClienteSe 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.
27Tema 5. Gestión de Proyectos (ISG3)
Respuesta al CambioLa 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.
28Tema 5. Gestión de Proyectos (ISG3)
El Manifiesto Ágil (2001)
Kent BeckKent Beck
Mike BeedleMike Beedle
Arie van BennekumArie van Bennekum
Alistair CockburnAlistair Cockburn
Ward CunninghamWard Cunningham
Martin FowlerMartin Fowler
James GrenningJames Grenning
Jim HighsmithJim Highsmith
Andrew HuntAndrew Hunt
Ron JeffriesRon Jeffries
Jon KernJon Kern
Brian MarickBrian Marick
Robert C. MartinRobert C. Martin
Steve MellorSteve Mellor
Ken SchwaberKen Schwaber
Jeff SutherlandJeff Sutherland
Dave ThomasDave Thomas
29Tema 5. Gestión de Proyectos (ISG3)
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.
30Tema 5. Gestión de Proyectos (ISG3)
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.
31Tema 5. Gestión de Proyectos (ISG3)
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.
32Tema 5. Gestión de Proyectos (ISG3)
Nuevas Técnicas
Refactorización (refactoring)Cambios en el diseño sobre el sistema implementado
Pruebas automáticasPruebas exhaustivas del sistema cuyos resultados se comparan con resultados esperados
Integración continuaAutomatización de la integración de sistemas de modo de permitir pruebas automáticas muy frecuentes
Gestión de configuraciónHecha de una forma especial para apoyar la interacción y la integración continua
33Tema 5. Gestión de Proyectos (ISG3)
Ágil vs Tradicional
Presenta cierta resistencia al cambioImpuesta internamente Impuesta externamente
El contrato es flexible Contrato prefijado
El cliente es parte del equipo de desarrolloEquipos pequeños y/o en contacto físico Grupos grandes y/o distribuidosPocos artefactos Numerosos artefactosPocos roles Numerosos rolesMenor énfasis en la arquitectura Arquitectura y modelos fundamentales
Basadas en heurísticas provenientes de prácticas de producción de código
Basadas en normas provenientes de estándares seguidos por el entorno de desarrollo
Especialmente preparados para cambios durante el proyecto
Proceso menos controlado, con pocos principios
Proceso muy controlado, con numerosas políticas y normas
El cliente interactúa formalmente en reuniones
34Tema 5. Gestión de Proyectos (ISG3)
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
35Tema 5. Gestión de Proyectos (ISG3)
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...
36Tema 5. Gestión de Proyectos (ISG3)
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
43Tema 5. Gestión de Proyectos (ISG3)
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.)
49Tema 5. Gestión de Proyectos (ISG3)
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, ...
50Tema 5. Gestión de Proyectos (ISG3)
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?
52Tema 5. Gestión de Proyectos (ISG3)
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
53Tema 5. Gestión de Proyectos (ISG3)
Planear Entregas Parciales
Minimizan el cash-flow
Minimizan riesgos
Facilitan replanificaciones
TerminaciónTerminaciónPlanificadaPlanificadaInicialmenteInicialmente
FASES e Hitos
Entregables Facturables
54Tema 5. Gestión de Proyectos (ISG3)
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”
55Tema 5. Gestión de Proyectos (ISG3)
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
56Tema 5. Gestión de Proyectos (ISG3)
Desarrollo basado en pruebas
Diseñar la soluciónDefinición de la interfaz a probar
Crear pruebas para la soluciónLas pruebas deben ejecutarse y fallar
Implementar la soluciónLas pruebas deben ejecutarse y pasarse ok
Trabajar en incrementos tan pequeños como sea posible
57Tema 5. Gestión de Proyectos (ISG3)
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
Refinarla Arquitectura
Diseñarla Solución
Implementar las pruebasde desarrollo
Implementarla Solución
Ejecutar las pruebasde desarrollo
58Tema 5. Gestión de Proyectos (ISG3)
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
...
59Tema 5. Gestión de Proyectos (ISG3)
Control adaptativo proyecto (ii)
Camino
Real
1 2 3 4 5 6
1 2 34
5 67
ActualizadoPlan de Proyecto
TerminaciónTerminaciónPlanificadaPlanificadaInicialmenteInicialmente
Espacio de Satisfacción del
StakeholderVisión y Alcance
Camino Inicial Planificado
Terminación Terminación RealReal
FASES e Iteraciones
Entregables Facturables
Criterios de EvaluaciónRiesgos
Registro de Pruebas
Lista de Work Items
Alta Prioridad
Baja Prioridad
Nuevos
Eliminados
Repriorizados
Requisitosbien definidos
Requisitosvagos
Implementados en Iteración
60Tema 5. Gestión de Proyectos (ISG3)
Control adaptativo proyecto (iii)
Lista de Work Items
Alta Prioridad
Baja Prioridad
Nuevos
Eliminados
Repriorizados
Requisitosbien definidos
Requisitosvagos
Implementados en Iteración
Nunca 45,00%
Apenas 19,00%
A veces 16,00%A menudo 13,00%
Siempre 7,00%
Ejemplos de indicadores:# Requisitos Implementados / Req. Totales / Iteración
# Req. Nuevos-Eliminados / Iteración
62Tema 5. Gestión de Proyectos (ISG3)
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
63Tema 5. Gestión de Proyectos (ISG3)
El Ecosistema EPF
Free Process
Content
Plug-ins
Free Process
Content
Plug-ins
Commercial
Process
Content
Plug-ins
Commercial
Process
Content
Plug-ins
Common Language & VocabularyCommon Language & Vocabulary
Open Source DevelopmentOpen Source Development
Inhouse
Content
Plug-ins
Inhouse
Content
Plug-ins
Basic Unified Process
Adapted from RUP
Basic Unified Process
Adapted from RUP ScrumScrum
Free Process
Content
Plug-ins
Free Process
Content
Plug-ins
Commercial
Process
Content
Plug-ins
Commercial
Process
Content
Plug-ins
Extensiones deExtensiones de HerramientasHerramientas
Vocabulario y Lenguaje ComunesVocabulario y Lenguaje Comunes
Desarrollo en Software de Fuentes AbiertasDesarrollo en Software de Fuentes Abiertas
Inhouse
Content
Plug-ins
Inhouse
Content
Plug-ins
OpenUP/Basic OpenUP/Basic Scrum
Ingeniería de
Software
Basada en
Aportar Valor
Arquitectura
Guiada por
Modelos
Open Unified Process (OpenUP)
Marco de TrabajoÁgil y Consolidado
● XP● Scrum
Otros Procesos ágiles● DSDM● AMDD
METAMODELO (Arquitectura de Método Unificado)METAMODELO (Arquitectura de Método Unificado)
ECLIPSEECLIPSE
Extensible, Adaptable, FlexibleExtensible, Adaptable, FlexibleUTILIDADES (de Autor, de Publicación)UTILIDADES (de Autor, de Publicación)
EXTENSIONESEXTENSIONES
●G. de ProyectosG. de Proyectos●G. de OperacionesG. de Operaciones●G. de SistemasG. de Sistemas
64Tema 5. Gestión de Proyectos (ISG3)
¿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
65Tema 5. Gestión de Proyectos (ISG3)
penUP
Analista
Stakeholder
Jefe deProyecto
Arquitecto
Desarrollador
Probador
66Tema 5. Gestión de Proyectos (ISG3)
penUP
Analista
Stakeholder
Jefe deProyecto
Arquitecto
Desarrollador
Probador
67Tema 5. Gestión de Proyectos (ISG3)
penUP
Analista
Stakeholder
Jefe deProyecto
Arquitecto
Desarrollador
Probador
68Tema 5. Gestión de Proyectos (ISG3)
penUP
Analista
Stakeholder
Jefe deProyecto
Arquitecto
Desarrollador
Probador
69Tema 5. Gestión de Proyectos (ISG3)
penUP
Analista
Stakeholder
Jefe deProyecto
Arquitecto
Desarrollador
Probador
70Tema 5. Gestión de Proyectos (ISG3)
penUP
Analista
Stakeholder
Jefe deProyecto
Arquitecto
Desarrollador
Probador
72Tema 5. Gestión de Proyectos (ISG3)
OpenUP se apoya en un conjunto de principios fundamentales:Colaborar para alinear los intereses y compartir el conocimientoEvolucionar para obtener continuamente realimentación y mejoras Equilibrar prioridades enfrentadas para miximizar el valor aportado al stakeholderEnfocarse en articular la arquitectura
Principios
73Tema 5. Gestión de Proyectos (ISG3)
ColaboraciónMantener un conocimiento común
Artefactos Clave: Visión, requisitos, arquitectura, plan de iteración
Fomentar un ambiente de confianzaGestionar por objetivos, derribar muros, comprender la perspectiva de los demás
Compartir responsabilidadesEl producto pertenece a todos, luego debemos ayudarnos unos a otros
Aprendizaje continuoDesarrollar capacidades técnicas y de colaboración, debemos ser estudiantes y profesores a la vez
Organizarse alrededor de la arquitecturaA medida que los equipos crecen, debemos tener equipos de equipos enfocados en pequeños componentes
74Tema 5. Gestión de Proyectos (ISG3)
Formas de los Requisitos
La Visión define el punto de vista del stakeholder sobre el productoLos 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 productoLos “Work Items” (elementos de trabajo) referencian requisitos del producto con más detalle
75Tema 5. Gestión de Proyectos (ISG3)
Definición Iterativa de Requisitos
La Visión define el productoLa 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ónLos Requisitos de Soporte se gestionan a lo largo de todo el ciclo de vida
76Tema 5. Gestión de Proyectos (ISG3)
Objetivo: Casos de PruebasCasos de Pruebas
Están alineados con requisitos y erroresEspecifican las condiciones que deben validarseEsbozan los datos necesarios
Por su parte los Script de Pruebas (de los subprocesos de la Solución)
Están alineados con los Casos de PruebasSon instucciones detalladas paso a pasoCoomplementados por datos de pruebasEs mejor que estén automatizados
Los Casos de Pruebas son una forma de “Test First Design (TFD)” (Diseño guiado por las pruebas)
77Tema 5. Gestión de Proyectos (ISG3)
Roles Orientados al Objetivo
AnalistaCaptura, organiza y prioriza requisitos
StakeholderConduce el objetivo; el proyecto debe satisfacer sus necesidades
ProbadorDefine los criterios para aceptar una solución
EL Jefe de Proyecto actualizará la Lista de “Work Items” con elementos (items) agrupados y priorizadosEl Arquitecto y el Desarrollador producirán una solución que cumpla con el “objetivo”
78Tema 5. Gestión de Proyectos (ISG3)
Espacio de Satisfacción del
Stakeholder
Punto de Arranque del Proyecto
Identificar la Meta Final
Tu meta es encontrar un camino
desde Aquí hasta Allí
79Tema 5. Gestión de Proyectos (ISG3)
Espacio de Satisfacción del
Stakeholder
Divide y Vencerás
1 2 3 4 5 6
Inicial
Plan de Proyecto
TerminaciónTerminaciónPlanificadaPlanificada
Camino Planificado
80Tema 5. Gestión de Proyectos (ISG3)
Espacio de Satisfacción del
Stakeholder
Hitos de Gestión
1 2 3 4 5 6
¿Comprendemosel problema?
¿Comprendemosla solución?¿Características
completadas?
¿Listopara
Liberar?
TerminaciónTerminaciónPlanificadaPlanificada
Planned Path
Comienzo Elaboración ConstrucciónTransición
81Tema 5. Gestión de Proyectos (ISG3)
Priorizar y Gestionar el Trabajo
Lista de Work Items
Alta Prioridad
Baja Prioridad
Se pueden añadir nuevos work itemsen cualquier momento
Se pueden eliminar work itemsen cualquier momento
Los work items se puedenrepriorizar en cualquier momento
Los work items de alta prioridaddeberían estar bien definidos
Los work items de baja prioridadpueden ser vagos
En cada iteración se implementanlos work items de mayor prioridad
82Tema 5. Gestión de Proyectos (ISG3)
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.
VelocidadUna medida de cuantos puntos se liberan (entregan) en cada iteración
Esfuerzo (días o horas):Estimación del esfuerzo real.
83Tema 5. Gestión de Proyectos (ISG3)
Planifica Tu IteraciónEspecifica la velocidad objetivo (deseada) y esboza los objetivos de la iteración en el Plan de IteraciónAnaliza el Work Item de mayor prioridad
Estima el esfuerzo en horasSi es demasiado grande para caber en la iteración, divídelo en work items menoresAñádelo al Plan de IteraciónAnaliza 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)
Lista de Work Items
●Objetivos de la Iteración●Lista de Work Items de la Iteración●Resultados de Medidas y Pruebas
Estimar y añadir al plan de iteración
Plan de Iteración
84Tema 5. Gestión de Proyectos (ISG3)
Camino Planificado
Conducción por Criterios de Evaluación de la Iteración
Camino
Real
1 2 3 4 5 6
1 2 34
5 67Actualizado
Plan de Proyecto
Terminación Terminación PlanificadaPlanificada
Espacio de Satisfacción del
Stakeholder
85Tema 5. Gestión de Proyectos (ISG3)
El Rol de la Arquitectura
Suministra el contexto para el diseño y la implementaciónSuministra una mitigación de riesgosMejora la “predictabilidad” del planDefinirla pronto, mejorarla y evolucionarla
86Tema 5. Gestión de Proyectos (ISG3)
La Arquitectura y los PrincipiosColaborar
La arquitectura ayuda a mantener un conjunto de conocimientos técnicos comunes
EquilibrarLas decisiones tomadas sobre la arquitectura son parte de un equilibrio para alcanzar el máximo beneficio para el stakeholder dentro de de las restricciones
EnfocarseUtiliza la arquitectura para resaltar las decisiones técnicas esenciales
EvolucionarLas evoluciones tempranas aseguran la viabilidad del producto y minimizan los riesgos
87Tema 5. Gestión de Proyectos (ISG3)
• 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
Representación de la Arquitectura
No se requieren documentos pesadosGran parte de la arquitectura se puede:
Seleccionar en vez de diseñarReferenciar en vez de describir
88Tema 5. Gestión de Proyectos (ISG3)
Diseño
PasosComprender los requisitos, identificar un escenarioIdentificar sus elementosDeterminar como colaboran esos elementosRefinar las decisiones, los aspectos internos del diseñoComunicarlo
¿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.
89Tema 5. Gestión de Proyectos (ISG3)
Desarrollo Guiado por Work Items
Seleccionar uno de los “work item” de los asignados a la actual iteraciónColaborar con el equipo si es necesario descomponerlo en otros menoresIdentificar 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 de sistema
90Tema 5. Gestión de Proyectos (ISG3)
Diseño basado en pruebas
Diseñar la soluciónDefinición de la interfaz a probar
Crear pruebas para la soluciónLas pruebas deben ejecutarse y fallar
Implementar la soluciónLas pruebas deben ejecutarse y pasarse ok
Trabajar en incrementos tan pequeños como sea posible
91Tema 5. Gestión de Proyectos (ISG3)
Diseño Basado en Pruebas
Las pruebas de desarrollo tejen la implementación de la solución
No se muestra en el dibujo los bucles cortos de realimentación
Refinarla Arquitectura
Diseñarla Solución
Implementar las pruebasde desarrollo
Implementarla Solución
Ejecutar las pruebasde desarrollo
92Tema 5. Gestión de Proyectos (ISG3)
Roles Relevantes a la Solución
DesarrolladorDiseña e implementa la solución
ArquitectoToma las decisiones técnicas claves y estructura la solución
ProbadorImplementa y conduce las pruebas que verifican la solución
EL Jefe de Proyecto monitoriza el desarrolloEl Stakeholder participa en la verificación de la soluciónEl Analista suministra información adicional
93Tema 5. Gestión de Proyectos (ISG3)
Ejemplo: Iteraciones en la PrácticaAsumiendo 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ón1-2 semanas de pruebas y cierre
Muchos miembros del equipo pueden hacer también diseño y codificación en la primera semanaLas integraciones semanales suelen probar el grado de avance; las integraciones quincenales suelen inyectar disciplina y repitabilidadLos 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 usoLos 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 ampliaEl 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ónLas fechas importan – se deben revisar siguiendo cada iteración de entrega. Las iteraciones estan constreñidas (timeboxed). Las Fases no.
94Tema 5. Gestión de Proyectos (ISG3)
Lecciones PrácticasEs 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 entregaSi reducimos las 1-2 semanas del periodo de cierre, se genera poca estabilidadEl ratio de adopción se ve afectado significativamente por la estabilidad de la iteración y por la facilidad para descargarlasExiste una tendencia de no documentar adecuadamente las nuevas funcionalidades que van en una iteración; esto dificulta establecer que cosas hay nuevas y excitantes
96Tema 5. Gestión de Proyectos (ISG3)
Un Poco de HistoriaOrígenes de la informática
Ciencia aplicadaAcceso a los fuentes, Rápida evolución (Algorítmica, ...)
'70 EnfrentamientoModelos de negocio propietario de pago por usoÉtica de los Hackers del M.I.T. (acceso al fuente).
'80 Free Software FoundationLicencia GPL (Software Libre).
'90 Iniciativa del Software de Fuentes AbiertasModelo de desarrollo cooperativo.Proliferan Licencias (OSI).
'00 Se extrapola a otros camposWikipedia, Conocimiento Libre, ...
97Tema 5. Gestión de Proyectos (ISG3)
Visiones del Software LibreÉtica y Derechos del Usuario
Modelo de Desarrollo Colaborativo
98Tema 5. Gestión de Proyectos (ISG3)
Free Software FoundationEl 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
99Tema 5. Gestión de Proyectos (ISG3)
Open Source InitiativeDesarrollador (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
100Tema 5. Gestión de Proyectos (ISG3)
Popularidad de Licencias*
GNU/GPLGNU/LGPLBSDMITArtisticApache 2.0Otros
(*) Diciembre de 2006 (analizados > 30.000 proyectos) en Freshmeat.net
102Tema 5. Gestión de Proyectos (ISG3)
Errores de InterpretaciónEl 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
103Tema 5. Gestión de Proyectos (ISG3)
S.L. Motor de InnovaciónCombina dos poderosos mecanismos de innovación
La competenciaTodos 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 productosCon un conjunto de empresas dándoles soporte
106Tema 5. Gestión de Proyectos (ISG3)
Repositorios e Índices
http://freshmeat.net/http://sourceforge.net/
117Tema 5. Gestión de Proyectos (ISG3)
Empresa DesarrolladoraCambios
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
118Tema 5. Gestión de Proyectos (ISG3)
Empresa IntegradoraCambios
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
119Tema 5. Gestión de Proyectos (ISG3)
Mantenimiento y SoporteCambios
Bajo coste de componentes
Acceso al código y su reparación
Traslada sólo sus costes y hay un amplio mercado
120Tema 5. Gestión de Proyectos (ISG3)
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
GadgetsDispositivos físicos con funciones soft avanzadas (Linksys)
Consultores
Aplicaciones que requieren servicios on-lineSe cobra por dichos servicios (Half-life)
133Tema 5. Gestión de Proyectos (ISG3)
ReferenciasManifesto 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/