Tema 5. Gestión de Proyectos (ISG3)

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


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


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


Presentación y Conceptos GeneralesIntroducción

Métodos y Sistemática

Buenas Prácticas

Open Up

Licencias, Software Libre y Empresa

Referencias


Introducción


Objetivo de proyecto

$


Dimensiones gestión proyectos

Alcance (Entregables)

Plazos (Tiempos)

Esfuerzo (Recursos)


Visión a 7.000 metros

Plan de ProyectoEntregable Facturable


Estimar, planificar, asignar,...

Puntos Función

COCOMO (II)

Delphi


Seguimiento

Métricas


¿Es esto gestión de proyectos?


O, ... ¿Esto?


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.


In-Comunicación


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%


¿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


Ingeniería

Ciencia

Aplicada a la resoluciónde problemas de interés

Tecnología

Balance económico yde oportunidad

Ingeniería

Nuevasnecesidades


Métodos y Sistemática


Respuesta Super Métodos (~'90)


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


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


Respuesta “La Agilidad” (~'00)


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


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.


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.


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.


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.


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


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.


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.


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.


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


Á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


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


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


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


Valor


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


Implantación (R.O.I)


Implantación (Éxito)


Implantación (Chasm)


Malinterpretaciones


Buenas Prácticas


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


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?


Granularidad de procesos


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


Planear Entregas Parciales

Minimizan el cash-flow

Minimizan riesgos

Facilitan replanificaciones

TerminaciónTerminaciónPlanificadaPlanificadaInicialmenteInicialmente

FASES e Hitos

Entregables Facturables


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”


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

http://www.amazon.com/gp/product/images/0201633612/ref=dp_image_0/103-2158338-1013418?ie=UTF8&n=283155&s=books


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


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


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

...


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


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


Open UP


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


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


¿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


penUP

Analista

Stakeholder

Jefe deProyecto

Arquitecto

Desarrollador

Probador


Colaboración y Objetivos (Niveles)


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


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


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


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


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)


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”



Stakeholder

Punto de Arranque del Proyecto

Identificar la Meta Final

Tu meta es encontrar un camino

desde Aquí hasta Allí



Stakeholder

Divide y Vencerás

1 2 3 4 5 6

Inicial

Plan de Proyecto

TerminaciónTerminaciónPlanificadaPlanificada

Camino Planificado



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


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


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.


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


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


Stakeholder


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


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


• 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

http://www.amazon.com/gp/product/images/0201633612/ref=dp_image_0/103-2158338-1013418?ie=UTF8&n=283155&s=books


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.


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


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


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


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


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.


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


Licencias, Software Libre y Empresa


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


Visiones del Software LibreÉtica y Derechos del Usuario

Modelo de Desarrollo Colaborativo


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


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


Popularidad de Licencias*

GNU/GPLGNU/LGPLBSDMITArtisticApache 2.0Otros

(*) Diciembre de 2006 (analizados > 30.000 proyectos) en Freshmeat.net


Compatibilidad de Licencias


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


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


La Estándarización Favorece S.L.


¿Qué software hay?


Repositorios e Índices

http://freshmeat.net/http://sourceforge.net/

http://freshmeat.net/

http://sourceforge.net/


Sistemas Operativos


Infraestructuras de red


Bases de Datos


Servidores de Aplicación


Escritorio


Ofimática


Colaboración y Navegación

Firefox

Thunderbird


Aplicaciones de Empresa


Seguridad


Modelos de Negocio


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


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


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


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)


¿Y para mí?


S.O. y Escritorio (Unbuntu / Kubuntu)


Ofimática (Open Office)


Ofimática (Colaboración)

Firefox

Thunderbird


Organización (FreeMind - Ideas)


Organización (GTD - ThinkingRock)


Planificación (OpenProj)


Gestión Proyectos (dotProject)


Diagramación (Umbrello - Dia)


Diagramación Técnica (QCAD)


Gestión Documental (Alfresco)


Referencias


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/

http://www.agilealliance.org/home

http://enterpriseunifiedprocess.info/

http://epf.eclipse.org/wikis/openup/

http://www.fsf.org/

http://opensource.org/


¡Gracias!.. ¿Preguntas?

[email protected]

Tema 5. Gestión de Proyectos (ISG3)

Documents

Transcript of Tema 5. Gestión de Proyectos (ISG3)