Tema 5. Gestión de Proyectos (ISG3)

Transcripción

1 Tema 5. Gestión de Proyectos (ISG3) Antonio José Sáenz Albanés (C.T.O) Reconocimiento No Comercial Compartir Igual España 1

2 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 2

3 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 3

4 Presentación y Conceptos Generales Introducción Métodos y Sistemática Buenas Prácticas Open Up Licencias, Software Libre y Empresa Referencias 4

5 Introducción 5

6 Objetivo de proyecto $ 6

7 Dimensiones gestión proyectos Alcance (Entregables) Plazos (Tiempos) Esfuerzo (Recursos) 7

8 Visión a metros Plan de Proyecto Entregable Facturable 8

9 Estimar, planificar, asignar,... Puntos Función COCOMO (II) Delphi 9

10 Seguimiento Métricas 10

11 Es esto gestión de proyectos? 11

12 O,... Esto? 12

13 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. 13

14 In-Comunicación 14

15 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% 15

16 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 16

17 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 17

18 Métodos y Sistemática 18

19 Respuesta Super Métodos (~'90) 19

20 Procesos, Tareas, Métodos, Ciclos,... 20

21 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 21

22 Respuesta La Agilidad (~'00) 22

23 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 23

24 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. 24

25 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. 25

26 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. 26

27 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. 27

28 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 28

29 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. 29

30 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. 30

31 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. 31

32 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 32

33 Á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 33

34 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 34

35 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... 35

36 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 36

37 Valor 37

38 Valor 38

39 Valor 39

40 Valor 40

41 Valor 41

42 Valor 42

43 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.) 43

44 Implantación (R.O.I) 44

45 Implantación (Éxito) 45

46 Implantación (Chasm) 46

47 Malinterpretaciones 47

48 Buenas Prácticas 48

49 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,... 49

50 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? 50

51 Granularidad de procesos 51

52 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 52

53 Planear Entregas Parciales Minimizan el cash-flow Minimizan riesgos Facilitan replanificaciones Entregables Facturables Terminación Planificada Inicialmente FASES e Hitos 53

54 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 54

55 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 55

56 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 56

57 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 57

58 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... 58

59 Control adaptativo proyecto (ii) Terminación Planificada Inicialmente Entregables Facturables Terminación Real FASES e Iteraciones Camino Inicial Planificado Plan de Proyecto Actualizado Alta Prioridad Camino 4 Real 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 59

60 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 60

61 Open UP 61

62 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 62

63 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

64 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 64

65 Analista Stakeholder Probador Desarrollador penup Jefe de Proyecto Arquitecto 65

66 Analista Stakeholder Probador Desarrollador penup Jefe de Proyecto Arquitecto 66

67 Analista Stakeholder Probador Desarrollador penup Jefe de Proyecto Arquitecto 67

68 Analista Stakeholder Probador Desarrollador penup Jefe de Proyecto Arquitecto 68

69 Analista Stakeholder Probador Desarrollador penup Jefe de Proyecto Arquitecto 69

70 Analista Stakeholder Probador Desarrollador penup Jefe de Proyecto Arquitecto 70

71 Colaboración y Objetivos (Niveles) 71

72 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 72

73 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 73

74 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 74

75 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 75

76 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) 76

77 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 77

78 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 78

79 Divide y Vencerás Terminación Planificada Camino Planificado Inicial Plan de Proyecto Espacio de Satisfacción del Stakeholder 79

80 Hitos de Gestión Terminación Planificada 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 80

81 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 81

82 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. 82

83 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 83

84 Conducción por Criterios de Evaluación de la Iteración Terminación Planificada Camino Planificado 1 Actualizado 2 3 Camino 4 Real Espacio de Satisfacción del Stakeholder Plan de Proyecto 84

85 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 85

86 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 86

87 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 87

88 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. 88

89 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

90 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 90

91 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 91

92 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 92

93 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. 93

94 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 94

95 Licencias, Software Libre y Empresa 95

96 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,... 96

97 Visiones del Software Libre Ética y Derechos del Usuario Modelo de Desarrollo Colaborativo 97

98 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 98

99 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 99

100 Popularidad de Licencias* GNU/GPL GNU/LGPL BSD MIT Artistic Apache 2.0 Otros (*) Diciembre de 2006 (analizados > proyectos) en Freshmeat.net 100

101 Compatibilidad de Licencias 101

102 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 102

103 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 103

104 La Estándarización Favorece S.L. 104

105 Qué software hay? 105

106 Repositorios e Índices

107 Sistemas Operativos 107

108 Infraestructuras de red 108

109 Bases de Datos 109

110 Servidores de Aplicación 110

111 Escritorio 111

112 Ofimática 112

113 Colaboración y Navegación Thunderbird Firefox 113

114 Aplicaciones de Empresa 114

115 Seguridad 115

116 Modelos de Negocio 116

117 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

118 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 118

119 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 119

120 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) 120

121 Y para mí? 121

122 S.O. y Escritorio (Unbuntu / Kubuntu) 122

123 Ofimática (Open Office) 123

124 Ofimática (Colaboración) Firefox Thunderbird 124

125 Organización (FreeMind - Ideas) 125

126 Organización (GTD - ThinkingRock) 126

127 Planificación (OpenProj) 127

128 Gestión Proyectos (dotproject) 128

129 Diagramación (Umbrello - Dia) 129

130 Diagramación Técnica (QCAD) 130

131 Gestión Documental (Alfresco) 131

132 Referencias 132

133 Referencias Manifesto for Agile Software Development. The Agile Alliance. Agile Modeling / EUP Open UP Free Software Foundation Open Source Initiative Agile Testing

134 Gracias!.. Preguntas? 134