OODA Loop

Aunque el modelo de OODA Loop fue desarrollado para proyectos militares, se está aplicando en la actualidad como metodología de implantación de soluciones de gestión en tiempo real en las organizaciones.

El OODA Loop se compone de cuatro pasos: observación, orientación, decisión y acción. La organización que sea capaz de recorrer el "Loop" en menos tiempo, es decir aquella que sea más ágil, alcanzará una ventaja competitiva. Por tanto la variable tiempo, es el centro de la estrategia en esta metodología.

• El primer paso es el de observación. Se trata de llevar a cabo procesos de adquisición y comunicación de la información existente en el entorno.

• El segundo paso es el de orientación. Es el más importante porque es en éste donde se analiza, entiende e interpreta la información que se ha recogido y tiene incidencia directa en los dos pasos siguientes. Durante esta fase se describe el entorno encontrado, se analizan las posiciones de los agentes y se abstraen los principales patrones de comportamiento, amenazas y oportunidades.

• En el paso de decisión, se desarrollan diferentes planes de actuación partiendo de la información recogida y analizada en los pasos anteriores.

• En el último paso, el de acción, se llevan a cabo los planes diseñados y se analizan los resultados obtenidos que son favorables, no favorables o indeterminados. Estos resultados son de nuevo observados y el ciclo comienza de nuevo.
  

Como en la mayoría de las metodologías y modelos propuestos para este tipo de entorno, los pasos propuestos no tienen por qué ser realizados siempre. Lo ideal es que exista un conocimiento previo y exhaustivo del entorno, por lo que no debería ser necesario realizar las fases de orientación y decisión. Pero todos sabemos que esto no siempre es así, por lo que en las organizaciones que decicen utilizar este modelo es recomendable empezar siempre por el principio y desarrollar por completo los cuatro pasos.

¿Qué es PRINCE2?

PRINCE (PRojects IN Controlled Environments) o proyectos en entornos controlados es un método estándar para la gestión efeciente de proyectos. PRINCE fue desarrollado por la CCTA (Central Computer and Telecommunications Agency) y en su primera versión se basa en otro método de gestión de proyectos llamado PROMPTII al que PRINCE sustituye en 1989 como el estándar utilizado en todos los proyectos de sistemas de información del gobierno británico.

Es en 1996 cuando se publica la versión de PRINCE2, que además de mejorar la versión anterior, se convierte en un método genérico para la gestión de proyectos, válido para todos los entornos, no solo para proyectos TIC (Tecnologías de Información y Comunicaciones) de la Administración Pública.

Actualmente PRINCE2 es un estándar de facto ampliamente usado por el gobierno del Reino Unido y muy reconocido y utilizado en el sector privado británico. Poco a poco, su uso también se está haciendo importante en los países de la Commonwealth y de forma más discreta en el resto de Europa.

La última versión de PRINCE2 es del año 2009 y en ella se estructura el método en cuatro partes: temas (en la versión del 2005 se denominaban componentes), procesos, técnicas y roles.

Los temas son áreas de conocimiento que deben aplicarse al proyecto cuando corresponda. Son 7 y entre ellos se encuentran los procesos de negocio, organización, calidad, planes, riesgo,
control del cambio y progreso.

Estos temas son implementados mediante los procesos, que son los elementos que explican qué debe ocurrir y cuándo a lo largo del ciclo de vida del proyecto. Se definen 8 procesos entre los que se encuentran los de comenzar un proyecto, iniciarlo, dirigirlo, controlar una fase, la gestión de suministro de producto, la gestión del límite de las fases y el cierre del proyecto.

Además existen 40 subprocesos asociados a los procesos que constan de sus correspondientes acciones normativas.

Las técnicas ofrecidas son métodos de trabajo de uso opcional que PRINCE2 recomienda. Estas son la planificación basada en producto (Product-based planning) y la revisión de la calidad (Quality review).

Por último se definen hasta un total de 10 tipos de roles que pueden intervenir en un proyecto. Algunos ejemplos son: el jefe de proyecto, el jefe de equipo, el responsable de soporte, el
usuario, etc.

Criterios de selección de un socio tecnológico

Cuando es necesario desarrollar un proyecto contando con la intervención de un integrador de sistemas o ingeniería, los clientes finales tienen dudas acerca de cuáles son los criterios que deben seguirse para llevar a cabo una correcta selección que asegure el éxito del proyecto.

En esta entrada, damos algunas recomendaciones para realizar una correcta elección del socio tecnológico que facilite el desarrollo del proyecto.

• Realizar la selección de forma directa, sin la inclusión de agentes externos.
• Contratar una compañía que tenga un tamaño semejante (recursos, facturación) a la organización en la que se va a desarrollar el proyecto.
• Seleccionar un socio tecnológico que pueda probar su conocimiento y experiencia en proyectos similares (utilizando las mismas tecnologías y conociendo el mismo tipo de procesos) y que pueda demostrar que las personas que van a participar en el proyecto son las adecuadas para llevar a cabo la implantación. Es decir, esto evitará o disminuirá la posibilidad de que se lleve a cabo la subcontratación de las tareas de implantación por parte del socio tecnológico a una empresa tercera.
• Contar con socios tecnológicos que cuya gestión interna sea avalada por certificados de calidad.
• Apostar por socios tecnológicos que además de conocimientos técnicos tengan conocimientos suficientes para realizar una gestión integral del proyecto y si es posible con experiencias en organizaciones pertenecientes al mismo sector.
• Contar con socios que puedan probar su solvencia financiera y su permanencia en el mercado a medio/largo plazo.

Recomendación. Blog Héctor Montenegro.

Os dejo este enlace para los que no conozcáis el blog de Héctor Montenegro (NTO de Microsoft Ibérica):

http://blogs.technet.com/hectormontenegro/archive/2009/12/09/10-razones-para-no-elegir-software-de-fuentes-abiertas-en-la-educaci-n.aspx

Aunque os recomiendo el blog en general, este enlace os lleva a una entrada que me ha parecido muy interesante ya que se da un punto de vista distinto al expuesto en el informe titulado “10 Razones para elegir Software de Fuentes Abiertas en la educación” de la Fundación CENATIC (http://www.cenatic.es/).

Aunque la discusión se centra en los proyectos Escuela 2.0, seguro que todos vosotros podéis extrapolar muchos de los argumentos expuestos en un sentido y en otro a vuestros propios entornos, ya que se trata de la eterna discusión también en el sector industrial.
aa

Gestión de proyectos (y II)

La gestión de proyectos ha evolucionado durante los últimos años, convirtiéndose en una disciplina utilizada habitualmente en toda iniciativa en la que exista un grupo de trabajo que tiene que
realizar una serie de actividades con el propósito de alcanzar un determinado resultado. Existe multitud de bibliografía, así como diferentes enfoques y metodologías que ayudan a realizar una gestión de proyectos eficiente. Independientemente de sus rasgos diferenciales, todos
estos enfoques y metodologías deben considerar que la base de la gestión de proyectos consiste en optimizar o manejar de forma óptima las siguientes tres restricciones: necesidades, tiempo y
coste.

• La correcta definición de las necesidades que debe cubrir un proyecto, se realiza a través de las especificaciones de proyecto. Estas especificaciones pueden no ser óptimamente satisfechas por diferentes motivos: falta de comunicación entre las partes implicadas, desequilibrio entre las expectativas creadas por parte del cliente, errores en la definición de necesidades, errores en las actividades de ejecución del proyecto, etc.

• El tiempo se gestiona óptimamente realizando una buena planificación temporal de las actividades que hay que desarrollar para cubrir las necesidades. Entre las causas que pueden provocar que la planificación temporal no se realice en las fechas especificadas se encuentran: la falta de recursos para realizar determinadas actividades (que provocan por tanto retrasos en el desarrollo del proyecto), la dedicación parcial (no comprometida) que llevan a cabo los recursos asignados para el desarrollo de las tareas de proyecto o la aparición de nuevas funcionalidades no contempladas en la especificación inicial.

• El coste implica realizar estas actividades con los recursos y presupuesto inicialmente establecidos. Esta restricción puede desviarse también por diferentes motivos: mal uso de los recursos disponibles, asunción del desarrollo un proyecto por un coste inferior al inicialmente determinado (teniendo en cuenta su alcance real), estimaciones iniciales de coste optimistas, etc.m
  

Información mantenida por el sistema operativo

Prácticamente todos los sistemas operativos actuales mantienen información sobre las diferentes tareas que se están ejecutando en el sistema y sobre la utilización que se está haciendo de sus recursos. El otro día uno de vosotros me preguntaba si esa información es fiable para hacer una evaluación de rendimiento exhaustiva del sistema.

La respuesta es afirmativa. Aunque la finalidad de mantener esta información no es proporcionar una herramienta de medida de rendimiento, el sistema de información del SO realiza funciones similares a las de cualquier monitor. La información típica que suele mantener el SO incluye la utilización de la CPU y de la memoria, el número de tareas en el sistema, el tiempo de inicio y de finalización de cada tarea, el tiempo que cada tarea ha pasado realmente en el procesador, etc. Hay que tener en cuenta que el sistema operativo no suele mantener información acerca de la longitud de las colas de ejecución de los distintos recursos (no sólo del procesador), del número de eventos relacionados con las funciones de E/S o del número de cambios de contexto, sólo por poner algunos ejemplos.

La principal ventaja de utilizar este tipo de información es que no hace falta desarrollar código específico para realizar las medidas de rendimiento, pero la principal desventaja es la sobrecarga que el acceso a esta información mantenida por el sistema operativo puede suponer para el sistema dependiendo de la frecuencia con la que se realice.

Gestión de proyectos (I)

El Project Management Institut (PMI) define la gestión de proyectos (project management) como la aplicación de conocimientos, habilidades, herramientas y técnicas que permiten planificar, organizar y gestionar recursos materiales, tecnológicos y/o humanos, con el fin de obtener eficientemente (en términos de alcance, tiempo y coste) los objetivos generales y específicos establecidos en un proyecto.

Además de esta definición propuesta por el PMI (Project Management Institute), otras organizaciones como la American Society for the Advancement of Project Management, la Global Alliance for Project Performance Standards o la PMForum , tienen como propósito principal, estandarizar y difundir los conceptos asociados a la gestión de proyectos así como las mejores prácticas realizadas en distintos sectores y tipologías de proyecto.

La gestión de proyectos tiene sus orígenes en los trabajos realizados principalmente por Henry L. Gantt. De este autor se destacan dos obras, "Work, wages, and profits" y "Organizing for Work" en las que se recoge una herramienta básica que sigue siendo hoy utilizada para la gestión de proyectos que es el diagrama de Gantt.

Este diagrama permite identificar todos los grupos de tareas, tareas individuales e hitos establecidos para desarrollar un proyecto, asignándoles un tiempo previsto de dedicación. Es una herramienta que permite analizar fácilmente la relación existente entre la carga de trabajo asignada y el tiempo previsto para completar dicha carga.

Este diagrama propicia la aparición de otras herramientas de gestión de proyectos como los CPM (Critical Path Method) o los grafos PERT (Program Evaluation and Review Technique), en los que, a diferencia del de Gantt, las actividades y recursos tienen relaciones de dependencia entre sí y en ambos casos, se persigue calcular la ruta crítica del proyecto y sus holguras.

Es decir, teniendo en cuenta estas dependencias, ambas técnicas son utilizadas para determinar el tiempo más corto en el que es posible completar el proyecto. Existe una ruta crítica y rutas alternativas para ejecutar todas las actividades. La diferencia de tiempo entre la ruta crítica y el resto de rutas, es lo que se define como holgura, siendo nula para la ruta crítica.
aa
m

Imagen de Sistema Único

Ya hemos comentado en entradas anteriores que las arquitecturas de memoria distribuida tipo cluster o grid tienen que utilizar comunicación explícita entre procesos y suelen presentar dos problemas: la falta de imagen de sistema único y la dificultad de equilibrar la carga de trabajo.

Para solucionar el problema de la falta de imagen de único es necesario instalar un middleware sobre el sistema operativo local instalado en cada uno de los nodos que componen el sistema o parchear/modificar estos sistemas operativos locales para que funcionen como un sistema operativo distribuido.

En cualquiera de los dos casos, la intención es proporcionar una capa intermedia entre los usuarios y sus aplicaciones, además, la imagen de sistema único se favorece si existe un punto de entrada único a la arquitectura y un punto de control y gestión de la arquitectura también único. Pero es necesario que esa capa intermedia proporcione los siguientes servicios:

• Espacio de procesos único.
• Sistema de planificación de trabajos único.
• Sistema de ficheros único.
• Espacio de E/S único.
• Interfaz de usuario único.
  

Y todavía no existe ninguna herramienta que permita, tanto al administrador como a los usuarios, ver una arquitectura de memoria distribuida como un sistema de cómputo único fuertemente acoplado, aunque cada vez nos acercamos más.
aa