Archivos Mensuales: septiembre 2007

Las habilidades de un Jefe de proyectos

En mi trabajo estamos buscando un jefe de proyectos, por lo que tuvimos que redactar alguna descripción del perfil de este Rol. En ese trabajo me mandaron la siguiente tabla de habilidades que debería tener un jefe de proyecto.

Me pareció muy completa y precisa por lo que la comparto en este POST. No tengo clara la fuente, por eso no la cito.

El Project Manager por el alcance de sus funciones, del equipo y recursos que administra, y por las variables y escenarios que se presentan, debería tener en mayor o menor grado algunas de las siguientes habilidades:

 

Skill

Breve descripción

Coping

Capacidad de tener una actitud madura ante conflictos y al resolver problemas.

Tolerance of ambiguity

Capacidad de tomar decisiones sin tener suficiente información. Usualmente son
situaciones de incertidumbre.

Decisiveness

Capacidad para tomar decisiones y aceptar compromisos. Los compromisos siempre son
asumidos.

Spoken Communication

Capacidad para hablar en público y presentar información, tanto en escenarios
positivos como negativos.

Assertiveness

Capacidad de expresar opiniones ya sean a favor o en contra a una posición, siempre
manteniendo el punto de vista propio.

Energizing

Capacidad de crear un buen ambiente y transmitir energía positiva.

Policy & Procedures

Capacidad de adaptarse fácilmente a los procedimientos y política de la empresa.

Alertness

Capacidad de estar alerta ante los entornos externos, y cómo este afectan al trabajo del
grupo.

Analytical Problem Solving

Capacidad de razonamiento y uso de un proceso lógico analítico para resolver un
problema, identificar las posibles soluciones y elegir la más adecuada.

Goal Setting

Capacidad para establecer metas realistas, objetivos y su definición.

Written Communication

Capacidad para comunicarse de forma correcta a través de la escritura. Permite
transmitir las ideas y conseguir los objetivos planteados.

Commitment to Risk

Capacidad de compromiso ante un objetivo, asignación o meta, manteniendo una actitud
positiva y con motivación.

Organization & Planning

Capacidad para organizar tareas, personas en un calendario y realizar el
correspondiente seguimiento.

Creativity

Capacidad para buscar soluciones creativas e innovadoras a problemas que se presenten
en el proyecto.

Interaction

Capacidad de comunicación cálida, transmitiendo seguridad y motivación al equipo de
trabajo.

Perceptivity

Capacidad para interpretar la comunicación verbal y no verbal de las otras personas. De
esta forma se puede conocer sus necesidades y opiniones.

Versatility

Capacidad “camaleónica” de poder cambiar opiniones, ideas, para poder
conseguir objetivos.

Reading the system

Capacidad para entender el funcionamiento interno de una organización, de tal forma que
se puedan conseguir objetivos específicos. Esto sucede con mayor frecuencia en empresas públicas donde existe burocracia y muchos niveles de aprobación.

Team Building

Capacidad para trabajar y formentar equipos de trabajo, creando entornos apropiados con el fin de conseguir un objetivo en común.

Decision Making & Problem Solving

Capacidad de tomar decisiones con razonamiento, dejando de un lado el aspecto emocional.

Leadership

Capacidad de influencia y hacer que las otras personas te sigan hacia un fin en común.

 

 

Anuncios

Andrés Calamaro presenta nuevo disco en concierto en Chile

Como les conté hace un tiempo (en este POST) viene por fin Andrés Calamaro a Chile el 6 de diciembre. La última vez que vino fue el año 1997, hace 10 años!!! , a presentar su disco "Alta Suciedad" en la sala SCD.

Ahora, presentará su nuevo disco "La lengua Popular" que tiene 12 temas.

 

Está vez vendrá con una banda telonera llamada Fito y Fitipaldis, que es española pero yo no la conozco.

Salu2

Windows Workflow Foundation, Rule Engine III

Introducción

En los 2 POST anteriores he tratado el tema del motor de reglas de Windows Workflow Foundation. El primero es una introducción que permite entender el concepto de RuleSet y cómo usarlo en un Workflow. El segundo explica cómo funciona el tema de las dependencias de las reglas y la manera de administrar las re evaluaciones por cambios de las condiciones de validación.

Ahora voy a mostrar algo que es muy potente. Hasta ahora, las reglas de negocio se encuentran compiladas dentro del Assembly del Workflow. La consecuencia de esto es que es necesario para cambiar las reglas volver a compilar. Esto es un contra sentido, porque la idea de desacoplar las reglas de código de programación es poder tener una separación clara de el código del Wrokflow de las reglas.

En este Post voy a tratar de explicar cómo usar una pieza de software de terceros que permite poner el RuleSet de negocio en una base de datos y así cambiar las reglas sin volver a compilar.

Separar las Reglas de Negocio del Assembly

Lo primero que debo presisar es que voy a utilizar un software de terceros llamado “External RuleSet Toolkit”[1]. Este código es de ejemplo y demuestra como almacenar en SQL el RuleSet. Además trae una interfaz Windows Forms para modificar las reglas en la DB y así los Workflow no son alterados por cambios en las reglas de negocio.

Lo primero que hay que entender es la arquitectura de esta solución. El siguiente diagrama muestra un WorkflowRuntime que tiene 3 instancias de Workflow corriendo. Cada una de esas instancias tiene una Custom Activity llamada “Custom Policy Activity”, que se encarga de obtener el RuleSet desde la base de datos a través del servicio “RuleSet Services”. Este Servicio debe ser agregado al WorkflowRuntime para que esta actividad de Políticas cutomizada pueda comunicarse con el RuleSet Repository que esta en la base de datos.

 

Imagen 1.

Además de los componentes para el Workflow este ejemplo de código trae el RuleSet Designer que es una interfaz gráfica para administrar los elementos del RuleSet Repository. Esta interfaz se muestra en la imagen 2.

Imagen 2.

¿Cómo se Instala?

Para poder usar el componente se deben cumplir con el proceso de instalación. Estos no los voy a explicar porque están perfectamente detallados en el manual de instalación de este ejemplo de código.

Ejemplo de Uso 1

Para usar este componente vamos a importar el RuleSet que usamos en el primer ejemplo del primer post de esta serie. Como sabemos las reglas de guardan en un archivo de extensión .rule. Usando la aplicación RuleSet Designer vamos a importar el archivo wfReglasEjemplo_1.rule que está en este ejemplo de código [2]. Una vez importado grabamos el RuleSet para que así quede persistente en la base de datos.

Ahora, creamos un Workflow secuencial y le agregamos la actividad customizada PolicyFromService que es la que enlaza con las reglas de la base de datos a través del Servicio. El workflow se ve como la siguiente imagen.

Imagen 3.

Las propiedades de la actividad PolicyFromService  son:

1.- RuleSet Name: nombre del juego de reglas a usar.

2.- Major Version: numero de verison.

3.- Menor Version: número de sub versión.

EL RuleSet de nuestro ejemplo se llama Rule Set1. LA versión es la por defecto 1.0.

Ahora para que esto funcione debemos incluir el servicio de comunicaciones con el repositorio de la reglas en la base de datos. Para eso al runtime del Workflow agregamos el Servicio RuleSet Services. Para esto agregamos el siguiente código.

workflowRuntime.AddService(new RuleSetService());

Código 1.

Con esto tenemos listo nuestro ejemplo. Si lo ejecutamos obtenemos el resultado A=15, B=5, C=5, D=2 y E=7.  Las reglas para hacer los cambios de los valores los leyó desde la base de datos!!!!!.

Ejemplo de Uso 2

Ahora, vamos a cambiar los valores para comprobar que descaplamos las reglas del Assembly. Para ello usamos la herramienta RuleSet Designer. Lo que haremos es mantener dos versiones de las reglas, así dependiendo de un valor usaremos una u otra regla.

Primero creamos una copia de las reglas, para eso usamos la función copy. Al hacer eso, nos aparece una nueva versión que por defecto es la versión 2.0. Usando la opción de Edit Rule, nos aparece el mismo formulario usamos antes para cambiar las reglas de Rule Set.

Si cambiamos las reglas y las grabamos en la base de datos el workflow inmediatamente comenzará a evaluar con el nuevo set de Reglas. Los valores de las reglas del segundo ejemplo son:

  • Regla_4: IF this.A == 15 THEN this.B = 5
  • Regla_3: IF this.C == 5 THEN this.B = 10
  • Regla_2: IF this.D == 2 THEN this.A = 15
  • Regla_1: IF this.B == 5 THEN this.E = 7000

Código 3: Reglas Ejemplo II                      

Las Reglas versión 2.0 se muestran en la siguiente imagen.

Imagen: Reglas Versión 2.0

Los resultados obtenidos al usar las reglas 2.0 son A=15, B=5, C=5, D=2 y E=7000, y para esto no tuvimos que compilar.

Buenos eso es, espero lo encuentren de tanta utilidad como yo!.

El ejemplo de este POST pueden descargarlo desde aquí.

Salu2

Referencias

[1] External RuleSet Toolkit, http://wf.netfx3.com/files/folders/rules_samples/entry309.aspx

[2] Ejemplo de código de Reglas, http://desarrollo.datco.cl/materialpublico/Test2_Reglas.zip

 

Windows Workflow Foundation, Rule Engine II

Introducción

Siguiendo con esta secuencia de POST orientados a tratar de explicar cómo funciona el motor de Reglas de Windows Workflow Foundation. En el primer POST tenemos se explica cómo funcionan la evaluación de reglas de un RulesSet y cómo se re evalúan por defecto.

En este pequeño POST trataré de explicar cómo se puede controlar la ejecución de reglas atómicas del RuleSet sin dependencia entre ellas. La idea es que en algunos escenarios complejos, quien escribe las reglas necesita tener mayor control sobre el comportamiento de las re evaluaciones, específicamente limitar la cantidad de reevaluaciones. Con esto se busca evitar loops infinitos, resultados erróneos por iteraciones de las reglas y algo no menor, mejorar el desempeño.

Control de dependencias de Reglas (Forward Chaining Control)

En nivel de control que permite Windows Workflow Foundation se puede configurar en dos puntos:

  • Conjunto de Reglas (RuleSet): con la propiedad Chaining Behavior.
  • En cada Regla (Rule): con la propiedad Reevaluation Behaivor.

Chaining Behavior

Esta propiedad actua a nivel de RuleSet, y tiene las siguientes tres posibilidades:

1. Full Chaining: este es el comportamiento por defecto que está descrito en el primero post de esta serie. Pueden verlo aquí.

2. Explicit Update Only: está opción deshabilita las dependencias implícitas y por atributos, dejando la posibilidad solo a las explicitas declaradas usando Update.

Un ejemplo sería con el RuleSet del código 1 y los métodos del código 2 utilizando Chaining Behavior con el valor por defecto Full Chaining el valor de salida de las variables A, B, C, D y E son 15, 5, 5, 2 y 7 respectivamente.

Ahora si se cambia la propiedad Chaining Behavior a Explicit Update Only, el resultado cambia a 15, 0, 5, 2, 0. Esto ocurre porque en este modo de se ignoran las dependencias declaradas como atributos.

  • Regla_1: IF this.B == 5 THEN this.CambiarE(7)
  • Regla_2: IF this.D == 2 THEN this.CambiarA(15)
  • Regla_3: IF this.C == 15 THEN this.CambiarB(10)
  • Regla_4: IF this.A == 15 THEN this.CambiarB(5)

Código 1

 

private int A = 0;

private int B = 0;

private int C = 5;

private int D = 2;

private int E = 0;

//Omitido el resto del código….Ver el proyecto de ejemplo

[RuleWrite("B")]

private void CambiarB(int valor)

{

    this.B = valor;

}

[RuleWrite("A")]

private void CambiarA(int valor)

{

    this.A = valor;

}

[RuleWrite("E")]

private void CambiarE(int valor)

{

    this.E = valor;

}

Código 2

Para poder obtener el mismo comportamiento que en la primera prueba tenemos que cambiar el RueSet a lo mostrado en el código 3.

 

  • Regla_1: IF this.B == 5 THEN this.CambiarE(7)
  • Regla_2: IF this.D == 2 THEN this.CambiarA(15) Update("this/A")
  • Regla_3: IF this.C == 15 THEN this.CambiarB(10)
  • Regla_4: IF this.A == 15 THEN this.CambiarB(5)

Código 3

Al poner la dependencia de forma explícita entonces el motor de reglas cuando evalúa la regla 2, re evalúa a regla 4. El resultado obtenido es 15, 5, 5, 2 y 7 respectivamente.

3. Sequiencial: esta es la opción final y lo que hace es forzar a que el motor realice las evaluaciones en un orden línea estricto, es decir no re evalúa las dependencias.

Si al ejemplo anterior, le cambiamos el valor a Secuencial, entonces obtenemos el resultado 15, 0 ,5, 2 y 0 porque no hay re evaluación de la Regla 4

 

Reevaluation Behavior Property

Está propiedad se aplica a  nivel de Reglas y permite la re evaluación o no de la regla. Los valore posibles son:

  • ·         Always: es el  comportamiento descrito hasta ahora y el que viene por defecto.
  • ·         Never: al marcar una regla con Never está ejecutará las acciones THEN o ELSE sólo una vez según corresponda.

En el ejemplo anterior, si la Regla 4 es marcada con Never entonces los valores de salida con 15, 0, 5, 2 y 0 porque la Regla 4 no se re evaluó.

Función Halt

Está función es muy interesante porque permite controlar la ejecución de dependencias entre reglas relacionadas. Al incluir Halt en la acción THEN o ELSE, entonces el RuleSet retorna de manera inmediata el control al código que lo invocó.

Con lo expuesto en este POST más el primer POST de RULE ENGINE ya se puede echar a volar la imaginación y buscar las aplicaciones prácticas de está tecnología. Yo ya la uso en proyectos Reales.

Espero seguir con otro Post (esto solo es una expresión de deseo) que muestra otros aspectos de Rules Engine de Windows Workflow Foundation.

EL código fuente del ejemplo mostrado se puede descargar desde aquí.

Salu2

Windows Workflow Foundation, Rule Engine I

Introducción

La tecnología DotNet Framework 3.0 tiene un componente para implementar Workflow’s[0] llamado Windows Workflow Foundation [1]. Este no es un producto de Workflow sino un motor de workflow más herramientas para los desarrolladores para que construyan sus propias soluciones de Workflow.

Dentro de las cosas más interesantes que veo en WF se encuentra su motor de Reglas de negocio (Rule Engine)[2].

Rules Engine permite hacer desde evaluación de condiciones lógicas hasta la definición y evaluación de complejas reglas que conforman políticas. En este post voy a tratar de explicar cómo se implementan esas políticas y cómo podemos usarlas en nuestros Worklows.

Lo primero que hay que entender es que las políticas son definidas por un conjunto de reglas semánticas llamado RuleSet. Estas reglas son del estilo If/Then/Else. Para poder invocar desde un Workflow la evaluación de un RuleSet se usa la actividad Policy[3].

Procedimiento de evaluación de las Reglas

Las Reglas que componen un RuleSet tienen una propiedad llamada Priority, que permite asignarle una prioridad a cada regla. El procedimiento de Evaluación del RuleSet es el siguiente:

  1. La regla de mayor prioridad se evalúa y ejecuta la acción del Then o Else.
  2. Si la acción (Then o Else) cambia el valor de un campo o propiedad que es usado por una regla anterior en la lista de reglas, esa regla afectada por el cambio se re evalúa.
  3. La siguiente regla de la lista se evalúa y ejecuta la acción del Then o Else.

Veamos el siguiente ejemplo. Tenemos un Workflow sencillo de 3 Actividades, el que se muestra en la imagen 1. La primera actividad muestra los valores de las variables A, B, C, D, E en la consola. La segunda actividad es una Política que tiene 4 reglas que están priorizadas y la última muestra los valores después de aplicar el RuleSet de reglas.

Imagen 1: Workflow de Ejemplo y RuleSet.

El RuleSet se ve en la imagen 1. Las reglas se ejecutan desde la mayor prioridad (4) hasta la menor (1). El proceso en que se ejecutan las reglas es el siguiente:

  1. Regla_4: Falso
  2. Regla_3: Verdadero entonces B = 10.
  3. Regla_2: Verdadero entonces A=15.
    1. Como cambio A la Regla_4 se re evalua. Regla_4: Verdadero entonces B=5.
  4. Regla_1: Verdadero entonces E=7.

Quedando cuando se ejecutan los valores mostrados en la imagen 2 en color Rojo.

Imagen 2: resultados.

Las dependencias entre las reglas son identificadas de tres maneras por el Rules Engine:

  1. Dependencia implícita.

    Este tipo de dependencia es la que vimos en el ejemplo 1, donde las acciones cambian valores que se usan en otras reglas.  

  2. Dependencia por atributos.

    La dependencia por atributos es usado en reglas que llaman a métodos en el Workflow. Como llama a un método no tiene como deducir implícitamente que reglas debe ReEvaluar. Para usar este tipo de dependencia se debe usar uno de estos tres atributos en el método:

  • RuleRead: Este quiere decir que el método lee un valor usado en el RuleSet
  • RuleWrite: Este atributo indica que en ese método el valor indicado es modificado.
  • RuleInvoke: Este atributo le indica al motor que el método llama a otro método.

Veamos un ejemplo para que sea más simple de entender. Tenemos un Workflow igual al anterior pero con el RuleSet mostrado en la imagen 3. Las reglas son las mismas que antes, pero en vez de cambiar los valores de las propiedades A,B, C, D y E directamente en la acción de la regla se invoca a un método.

El código de cada uno de los métodos invocados desde el RuleSet se muestra en el código 1.

Pueden ver en la imagen 4 que el resultado de la evaluación es el mismo que en ejemplo de reglas implícitas porque se hacen los mismos cambios de valores pero en métodos decorados con los atributos que le dan al motor de regla la información necesaria para actuar.

Imagen 3

[RuleWrite("B")]

private void CambiarB(int valor)

{

this.B = valor;

}

[RuleWrite("A")]

private void CambiarA(int valor)

{

this.A = valor;

}

[RuleWrite("E")]

private void CambiarE(int valor)

{

this.E = valor;

}

Código 1.

  1. Dependencia Explicita

    La dependencia explicita se basa e declarar uno mismo los cambios que ocurren al ejecutar una acción. Para ello se usa la instrucción Update de esta forma Update("this/A") por ejemplo para indicarle al motor que el valor de la propiedad A cambio.

    La única ventaja que he encontrado en la dependencia explicita es que se puede hacer por ejemplo esto Update("this/OrdenCompra/*") que le indica al motor que todos los atributos de la orden de compra cambian con esa acción. Esto es notable!!.

    El próximo ejemplo se muestra en la imagen 4. Las reglas contienen ahora en la acción la directiva Update. El código de los métodos ya no tiene la directiva RuleWrite, por lo que el motor se entera del cambio de manera explícita. El código de los métodos de cambio, sin el atributo, se muestra en el código 2.

    Por último el resultado sigue siendo el mismo!!! Y se muestra en la imagen 4.

    Imagen 4.

private void CambiarB(int valor)

{

this.B = valor;

}

private void CambiarA(int valor)

{

this.A = valor;

}

private void CambiarE(int valor)

{

this.E = valor;

}

Código 2.

Imagen 4

El motor de reglas es mucho más potente de lo que se muestra en este POST, espero seguir explicando cómo funciona en una serie de post que quiero hacer sobre Windows Forkflow Foundation Rules Engine.

El código fuente de los ejemplos pueden descargarlos dese este Link

Salu2

Referencias

[0] Sistemas de Workflow, http://es.wikipedia.org/wiki/Sistemas_de_workflow

[1] Windows Workflow Foundation, http://msdn2.microsoft.com/en-us/netframework/aa663328.aspx

[2] Introduction to the Windows Workflow Foundation Rules Engine, http://msdn2.microsoft.com/en-us/library/aa480193.aspx

[3] Introducing Microsoft Windows Workflow Foundation: An Early Look , http://msdn2.microsoft.com/en-us/library/aa480215.aspx

Microsoft TechNet & MSDN Briefing, Código de Ejemplo

Hoy 4 de septiembre hicimos con Luis y Mauricio una conferencia de procesos de negocio soportados por Windows Workflow Foundation y Windows Comunication Foundation.

En esta presentación mostré ejemplos básicos de WF que pueden descargar desde aquí.

Además al final mostramos una demo de una seguradora de autos que el proceso de venta es llevado adelante en WF. Este ejemplo pueden bajarlo desde acá (Parte WF).

Como siempre es un gusto participar de estos eventos, además quedo contento por la cantidad de preguntas que mi hicieron. Se nota que hay interés en la materia.

Por último la PPT (parte WF) pueden bajarla desde aquí.

Salu2