jueves, 31 de julio de 2014

En testing también debemos gestionar los cambios


Por Nadia Soledad Cavalleri

Software Configuration Management (SCM) es una disciplina de la ingeniería de software que comprende el conjunto de actividades necesarias para identificar, administrar y controlar todos los elementos que constituyen un software, sus cambios y sus relaciones, definiendo mecanismos para gestionar las diferentes configuraciones y posibilitar la reproducción de cualquiera de éstas.

Cuando hablamos de SCM, en lo primero que tendemos a pensar, es en su aplicación a equipos, ambientes y prácticas de desarrollo. Probablemente, esto se deba a que SCM emergió como disciplina enfocada en la programación, sin cubrir otros aspectos del proceso de desarrollo de software. Pese a esto, debemos tomar dimensión de la importancia que SCM tiene en los equipos, ambientes y prácticas de testing.

Repasando estos tres aspectos, nos encontramos con que los equipos tradicionales de pruebas están conformados por diferentes roles, en general, un gerente o líder de pruebas, algunos analistas, diseñadores, automatizadores, testers, y por qué no, algunos otros colaboradores.

Cuando hablamos de ambientes de pruebas, nos referimos a las configuraciones y los artefactos. Entendiendo por configuraciones, al conjunto de hardware, software, base de datos, sistemas operativos, redes y permisos y, por artefactos, a los productos de las actividades, tales como, planes de prueba, casos de prueba, scripts, logs, mejoras, bugs y reportes.

Siguiendo las buenas prácticas de SCM, deberíamos identificar aquellos ítems propensos a cambiar. Todos los artefactos mencionados tienen esa cualidad ya que están fuertemente relacionados con productos de otras disciplinas, como análisis y desarrollo, que también cambian permanentemente. Por ejemplo, el plan de pruebas está directamente relacionado con el plan del proyecto, los casos de prueba dependen de los requerimientos o de la especificación de casos de uso, los script de pruebas y los logs de sus ejecuciones están asociados a una versión determinada del build así como los bugs son reportados y resueltos en versiones específicas. Entonces, si el plan del proyecto, las especificaciones y el software pueden cambiar ¿Por qué no va a cambiar su par asociado en testing?

A pesar de que la configuración parece la parte más estática, también es susceptible de cambios, por ejemplo, por la instalación de parches, la migración hacia diferentes versiones, la creación de usuarios, la asignación de roles, la modificación de permisos, etc. Todos estos son ejemplos de situaciones con las que nos topamos a diario y que evidencian que en testing también ocurren cambios y, por lo tanto, también hay que gestionarlos.

Pero SCM no implica solamente gestionar los cambios con un controlador de versiones. Su objetivo es un poco más ambicioso. Cuando hablamos de SCM también nos estamos refiriendo al trabajo en paralelo, a la posibilidad de restaurar configuraciones previas y a mantener la trazabilidad entre los artefactos, entre otras cosas.

La aplicación de todas estas prácticas es tan indispensable en testing como lo es en desarrollo. Por ejemplo, al probar, también trabajamos de manera concurrente, quizá porque mientras un miembro del equipo está diseñando un caso de prueba otro está ejecutando o quizá porque tenemos dos o más automatizadores que están desarrollando sus scripts al mismo tiempo. En este caso, los automatizadores comparten el código fuente utilizado para automatizar las pruebas de la misma manera que los desarrolladores comparten el código de la aplicación que están construyendo. Poder volver a una versión anterior, a nivel de configuración y no solo de código, también puede ser necesario si tenemos que reproducir un bug en la misma versión y configuración del software en la que fue detectado.

La trazabilidad no es un tema menor. Los productos de testing están asociados con productos generados por otras disciplinas. En el medio de los cambios, la trazabilidad es extremadamente importante porque nos permite mantener la integridad de los modelos, datos y documentación. Además nos ayuda a identificar unívocamente las pruebas asociadas a una versión de la aplicación o de cualquier otro artefacto.

Queda claro entonces que si reconocemos la importancia de SCM en los equipos, ambientes y prácticas de desarrollo debemos otorgarle el mismo peso a los equipos, ambientes y prácticas de testing porque tienen un modo similar de funcionamiento y, a pesar de que ambos equipos trabajen con diferentes artefactos, tienen que gestionar temas de similar envergadura.

lunes, 21 de julio de 2014

Certificación JAVA OCA SE 7

Una experiencia de certificación exitosa…

clip_image002La certificación es una manera efectiva de validar los conocimientos de una persona en un área específica. Certificarse le permite saber a nuestro empleador o futuro empleador que tenemos los conocimientos suficientes para poder operar una herramienta o administrar tareas. En este sentido, las certificaciones de Oracle son de las más valoradas en el mercado IT.

El roadmap de certificación en Java es muy amplio. Este documento se basa en la certificación de desarrollador Java, más específicamente en la certificación “Java OCA”.

En un sentido más amplio, el camino de certificación como desarrollador Java es el siguiente:

clip_image004

Estas certificaciones son conocidas también como:

clip_image006

Los temas del examen pueden ser consultados en los links de más abajo.

Diseño del examen

El código del examen es 1Z0-803, está en inglés, consta de 90 preguntas y tenemos 150 minutos para resolverlo (2 horas y media). El porcentaje de aprobación es de 63% (hace unos meses era de 77%), son 57 preguntas que deben estar correctas.

Las preguntas son del tipo Multiple-choice y si hay más de una opción verdadera y no la elegimos, toda la pregunta se considera errónea.

En la página del examen figura el precio.

Guía para certificarse

1) Conseguir el material de estudio.

2) Estudiar ;)

3) Comunicarle al tutor nuestra intención de certificarnos.

4) Presentarse a rendir.

5) Obtener la nota.

1) Conseguir el material de estudio.

Oracle nos provee de una guía oficial de estudio: “OCA Java SE 7 Programmer I Study Guide (Exam 1Z0-803) (Oracle Press)”.

En la biblioteca de Baufest está disponible la guía para ser consultada.

En la guía están identificados todos los temas del examen, con una explicación un tanto resumida. Personalmente lo encontré muy teórico y poco abarcativo.

Yo recomiendo especialmente los simuladores de exámenes (mock exam), hay varios trials para bajar (en la guía de estudio figuran varias urls), yo decidí comprar el de Enthuware: http://enthuware.com/index.php/mock-exams/oracle-certified-associate/java-programmer-certification-i

Viene con 584 preguntas y la justificación de las respuestas, de ahí saqué un montón de información importante.

Una de las falencias que encontré en la guía de estudio oficial es que no ahonda en todas las posibles combinaciones del uso de alguna característica del lenguaje.

Por ejemplo, algo bien básico que nos puede hacer equivocar, la declaración del método main, es: 

public static void main( String[] args), pero qué pasa si en vez de main ponemos Main?, bueno, eso es perfectamente válido. Va a compilar. Sólo que no es el mismo método main que se ejecuta cuando se ejecuta la clase, pero es válido. También es válido agregarle la palabra "final" adelante. Y esas cosas la guía no lo dice.

En fin, el simulador de examen es de un nivel difícil, pero nos asegura ir mejor preparados. En las simulaciones que hice, no saqué más del 71% y promedié un 66%, sin embargo en el examen había preguntas más fáciles que las del simulador. También había preguntas iguales, a tal punto que hasta el nombre de las variables era iguales a las del simulador.

Una cosa que me sorprendió es que en el examen real había muchas preguntas sobre arrays, cómo declarar múltiples dimensiones, etc. y en el simulador no hacían mucho hincapié en eso.

Y algo muy tedioso pero necesario, es estudiar el tema de las excepciones, había muchas preguntas sobre eso también.

Hay que tener en cuenta la precedencia de los operadores, y conocer las funciones posibles de String, StringBuilder, y las de ArrayCopy por ejemplo.

2) Estudiar ;)

3) Comunicarle al tutor nuestra intención de certificarnos.

En Baufest contamos con el rol “Tutor”, es una persona con experiencia en la empresa que nos asesora sobre diversos temas. Nos muestra el camino. En ese sentido, mi tutor se ocupó de hablar con “Desarrollo Profesional” quienes gestionaron el voucher para poder rendir. Me dijeron el día y la hora y me presenté en Buffa. Recomiendo ir con tiempo para poder repasar.

4) Presentarse a rendir.

Rendí el examen en Buffa sistemas http://www.bs.com.ar/ Es un instituto de sistemas donde además, tienen un acuerdo con Pearson VUE que es el que organiza las certificaciones de Oracle.

En este caso, vino la persona encargada de los exámenes, me hizo el check-in en Oracle, esto es, me sacó una foto y me hizo firmar una planilla.

Tuve que guardar la mochila, campera y celular en un armario.

Luego, me dirigí al "aula" donde había dos computadoras, el aula era muy chica, había lugar para sólo dos personas.

Preparó la máquina y empezó el examen.

El programa es bien básico, obviamente una vez iniciado no deja minimizarse ni abrir notepad ni calculadora. Para hacer las anotaciones me dieron unos "blocs borradores”: un papel oficio plastificado y un marcador para escribir arriba.

El programa nos va diciendo el número de pregunta en la que estamos y la cuenta regresiva del tiempo. Las preguntas que nos generan dudas las podemos marcar con una "x" y al final, se pueden revisar rápidamente.

Para pasar de pregunta demora unos dos segundos, así que si estás en la número 2 y querés revisar lo que pusiste en la 70, tenés que ir de una en una y lleva su tiempo.

5) Obtener la nota.

Una vez finalizado el examen, aparece una pantalla que nos dice que el resultado va a estar disponible dentro de 30mins. Pasado ese tiempo, nos llega un mail donde figuran las instrucciones para poder ver el resultado, esto significa que vamos a tener que entrar a education.oracle.com, registrarnos y verificar la cuenta por mail, luego hacer login y entrar a una opción que dice "New exam results", donde va a figurar el resultado del examen. Simplemente nos va a decir nuestro score, el mínimo de 63% para aprobar, nuestra foto, alguna información como el día, ids, etc. Y los "temas" en que nos equivocamos.

El certificado electrónico final está disponible luego de unas 48hs y el físico hay que pedir que lo manden por mail.

clip_image008

Certificado electrónico.

Links útiles:

  • JAVA OCA: http://education.oracle.com/ y poner en el buscador “Oracle Certified Associate, Java SE 7 Programmer”. Elegir el primer resultado que aparece.
  • JAVA OCP: http://education.oracle.com/ y poner en el buscador “Oracle Certified Professional, Java SE 7 Programmer”. Elegir el primer resultado que aparece.

Material de estudio:

Baufest valora la capacitación formal de sus profesionales, por eso apoya las certificaciones con beneficios sobre los exámenes y el cursado de los cursos. Además ofrece un Plan de certificaciones.

Autor:

clip_image010
Julián Haeberli

jueves, 17 de julio de 2014

9 tips para armar un buen plan de pruebas

Ya sea que debas crear un plan de pruebas por primera vez o seas un tester experto, nunca está de más recibir algunos consejos. A continuación, 9 consejos que nacen de la experiencia de haber hecho muchos planes de prueba en variados proyectos:


  • (1) Usar un template es bueno, pero ¡el template no está hecho en piedra!

Es muy útil usar un template de Plan de pruebas como guía pero no hay que aferrarse a rajatabla a la estructura propuesta. Los proyectos informáticos son muy variados y no existe el template universal. El template sirve como ayuda pero el índice lo determinará finalmente la información de la que necesitemos disponer para guiar el proceso de testing a lo largo del proyecto.

  • (2) El plan de pruebas no es el cronograma de tareas

Muchas personas confunden un plan de pruebas con dar un calendario de cuándo se ejecutarán las pruebas y de cuánto tiempo llevarán. El cronograma de las pruebas es una parte del plan pero el plan es mucho más que solo el calendario. El plan contiene adicionalmente información sobre qué actividades se realizarán como parte del proceso de testing, qué objetos serán ítems a testear, qué estrategias se aplicarán, que tipos de pruebas se harán, como así también deja explicitado qué aspectos quedarán fuera del proceso de testing y por qué. Esta información determina una estrategia general que guiará el proceso de pruebas a lo largo del proyecto y que no debería cambiar demasiado en el transcurso del mismo. El cronograma de las pruebas, por otro lado, muy probablemente sufrirá modificaciones durante el proyecto.

  •  (3) Listar explícitamente cuales son las actividades dentro del alcance del plan es tan importante como listar cuales estarán fuera del mismo.

Lo más probable es que las actividades clásicas de un proceso de pruebas, como ser el diseño de casos, la ejecución de pruebas funcionales, registración de su resultado, registración de los issues/bugs, su comunicación y seguimiento, estén dentro del alcance. Pero algunas actividades relacionadas al aseguramiento de la calidad, como ser la revisión de artefactos del proyecto (casos de uso, especificaciones, documentos de arquitectura, etc.) podría o no estar contemplada. Así mismo como las actividades de automatizar la ejecución de las pruebas, o de actualizar/generar el material de soporte, o de participar del monitoreo de issues/bugs luego del despliegue en producción, por ejemplo. Indicar explícitamente en el documento de plan de pruebas cuales actividades formarán parte del alcance y enumerar cuáles no, provee un marco para dimensionar el esfuerzo que requerirá el proyecto y permite manejar correctamente las expectativas del cliente.

  •  (4) La naturaleza del proyecto guiará el diseño de las pruebas

Desde el punto de vista del alcance de los objetos a probar (¿qué se testeará?) y del alcance de las pruebas (¿qué tipos de pruebas se ejecutarán?) no es lo mismo un proyecto de migración/upgrade que un proyecto de mantenimiento o agregado de funcionalidades que un proyecto donde se construye un software de cero. Más aun, dos proyectos de la misma naturaleza no necesariamente se testearán de la misma forma. El plan de pruebas debe estar alineado al plan de proyecto: después de todo ¡estamos trabajando en el mismo proyecto! y muchos aspectos intrínsecos del proyecto determinan aspectos relacionados a la planificación de las pruebas. Este análisis es parte de la actividad de planificar las pruebas y sus justificaciones deben quedar escritas en el plan de pruebas.

  •  (5) Es importante conocer el landscape del proyecto y como se administrarán los despliegues al momento de planificar los ciclos de prueba

Cuando pensamos en las actividades del proceso de pruebas, pensamos por ejemplo en la de ejecutar las pruebas. Sin embargo tenemos que recordar que esta actividad se repetirá muchas veces a lo largo del tiempo. Potencialmente tendremos una ejecución con cada despliegue. Es por ello que para poder calendarizar las pruebas o dar un cronograma probable debemos conocer ¿cuántos ambientes componen el landscape del proyecto? ¿En cuáles se ejecutarán pruebas? ¿Cómo se administrará el despliegue de las correcciones que hagan falta hacer? No es lo mismo un proyecto con varios ambientes de desarrollo locales que deben mergearse (en otro ambiente) para luego pasar a un ambiente de calidad interno para luego pasar a uno de pre-producción del cliente para finalmente llegar a producción, que un proyecto con un ambiente de desarrollo, uno de pruebas y uno de producción. No es lo mismo que el desarrollador tenga acceso al ambiente de pruebas y pueda ir impactando correcciones individualmente a tener planificados una cierta cantidad de despliegues por ambiente. La motivación de las pruebas cambiará (¿focalizo la prueba en la corrección? ¿Será necesario contemplar una regresión con cada corrección? ¿Cuántos ciclos de prueba puedo planificar?), los tipos de prueba que aplicaré en cada ciclo pueden variar, y todo esto impacta en las dependencias de las tareas, en su cronología y en la estimación del esfuerzo.

  •  (6) Cuando el cliente participa de las pruebas, incluirlo en el plan de pruebas

¿El cliente participará de las pruebas? ¿Conviene involucrarlo de forma temprana? ¿Quiénes del lado del cliente harán pruebas? ¿En qué ambiente/s? ¿Debo contemplar horas de los recursos del proyecto para acompañar las pruebas del cliente? El conocimiento de los stakeholders, de qué tanta confianza nos tiene, de cuán firme o cambiante es en sus definiciones, de cuántas serán las personas que participen de la aceptación del producto, de si podrán hacer las pruebas por si mismos o requerirán guía/soporte del equipo del proyecto, de cómo se manejarán los potenciales bugs que puedan identificar, nos determinará aspectos que afectan la planificación de las pruebas. Las estrategias que se aplicarán deben indicarse en el plan de pruebas. Esto permite que la estimación resultante se asemeje a la realidad lo más posible respecto del esfuerzo que requerirá el proceso de pruebas.

  •  (7) Hablar un lenguaje común

¿Qué entendemos por objeto ítem de prueba? ¿Qué entendemos por caso de prueba? ¿Qué entendemos por ciclo de prueba? ¿Qué es una prueba de estrés, o de carga? No siempre todos los lectores del plan de pruebas le darán el significado que quiere transmitir quien escribe el plan de pruebas a las palabras y términos que usa el equipo de pruebas. Disponer de un glosario que acompañe el plan de pruebas es una buena práctica para que todas las personas que participan del proyecto entiendan lo mismo al momento de leer el plan de pruebas.

  •  (8) Comunicarlo

El plan de pruebas tiene como audiencia principal al equipo de pruebas porque es quien se compromete a llevarlo a cabo pero es importante comunicarlo al resto del equipo del proyecto. Debe ser revisado con el líder de proyecto quien tiene la visión del proyecto y de cómo lo administrará. Debe ser comunicado al equipo de desarrolladores, pues debemos estar todos de acuerdo en los objetos ítems de las pruebas (que deberían coincidir o serán un subconjunto de los que serán construidos). En algunos casos, a consideración del líder de proyecto, puede compartirse también con los stakeholders usuarios del proyecto, con quienes se podrán validar los criterios de aceptación y compartir la planificación de los ciclos de prueba de los usuarios.

  • (9) Mantenerlo actualizado o, dicho de otra manera: hacerlo para usarlo

Como todos los artefactos de la ingeniería de software, hacerlo para que quede perdido en una carpeta, desactualizado, sin haberse aplicado en el proyecto ninguna de las estrategias definidas es tirar el esfuerzo de haberlo hecho a la basura. El plan de pruebas se generará al inicio del proyecto, cuando aún no hay nada construido ni testeable. Muchas cosas pueden pasar hasta el momento en que efectivamente se ejecuta un ciclo de pruebas (¡ya conocemos el dinamismo de los proyectos!), estrategias del proyecto que determinaron aspectos del plan de pruebas pudieron verse afectados. Es por ello que el plan de pruebas debe ir siendo modificado según sucedan los acontecimientos. Mantenerlo actualizado sirve para poder identificar nuevos riesgos relacionados a lo comprometido originalmente, para poder definir nuevas estrategias o desestimar las que ya no apliquen. Para poder ir ajustando la estimación original del esfuerzo que será necesario para llevar a cabo las pruebas del proyecto de forma tal que se asemeje a la realidad lo mejor posible.

¡Gracias por tu contribución Cecilia Briozzo!

















jueves, 10 de julio de 2014

DYNAMICS CRM 2011 – DATOS ÚTILES

Microsoft Dynamics CRM es una herramienta software para Gestión de las Relaciones con Clientes (en inglés Customer Relationship Management) desarrollado por Microsoft.

Forma parte de la familia de software empresarial Microsoft Dynamics.

Desarrollar customizaciones de este sistema puede tornarse algo tedioso si no se conoce en detalle el SDK del mismo.

En este post se pretende dar una guía para dar los primeros pasos en la customizacion de este producto.

Como crear un proyecto de Dynamics CRM 2011 en Visual Studio

Existe un template de proyecto para Visual Studio (2010 en adelante) que nos provee de un entorno que nos facilita generar y organizar nuestro código.

Se listan a continuación una serie de pasos para la implementación del mismo:

1. Bajar e Instalar el SDK desde:

http://www.microsoft.com/en-us/download/details.aspx?id=24004

2. Instalar el Developer Toolkit desde:

SDK\Tools\DeveloperToolkit

3. Abrir Visual Studio. Hacer click File à New à Project

4. Seleccionar Dynamics CRM como tipo de proyecto

clip_image003

5. Elegir el nombre del proyecto y hacer click en el botón “OK”

6. Ingresar datos relevantes en la ventana de conexión al Server de Dynamics CRM:

clip_image005

NOTA: Después de completar las credenciales y apretar el botón Log On, se habilitaran las organizaciones a las cual su usuario tiene acceso.

Luego de seleccionar la organización, se habilitaran las soluciones contenidas en su interior. La solución elegida será la contenedora de nuestros archivos al momento de hacer deploy desde el proyecto de Visual Studio

7. Firmar el Proyecto de Plugins:

a. Click derecho sobre el proyecto “Plugins”

b. Click sobre la opción “Propiedades”. Se abrirá la siguiente ventana:

clip_image007

c. Click sobre el tab “Signing”

d. Tildar el check box “Sign the assembly”

e. Seleccionar la opcion “New”

clip_image009

f. Completar los campos asignándole un nombre a la firma, así como también un password

Cómo Manejar los Web Resources desde Visual Studio

El template de desarrollo de Dynamics CRM 2011 para Visual Studio, nos da la posibilidad de agregar los Web Resources existentes en nuestro entorno de Dynamics CRM a nuestro proyecto.

Agregar un Web Resource al Proyecto de Visual Studio

Detallamos aquí los pasos para hacerlo:

1. Abrir el menú “CRM Explorer”

2. Hacer click sobre la Organización

3. Desplegar el menú de Web Resources

clip_image011

4. Click derecho sobre el Web Resource que se quiere agregar al proyecto de VS.

5. Click sobre “Add to packaging project”

clip_image013

Una vez hecho esto, tendremos acceso desde el “Project Explorer” a todos los WR que hayamos agregado al proyecto.

clip_image015

NOTA: Cada vez que hagamos Deploy del proyecto, por defecto también se hará deploy de todos los Web Resources.

Se recomienda cambiar la propiedad “Build Action” del Web Resource a “none” para que esto no suceda.

clip_image017

Implementar Modificaciones en Dynamics CRM

Existen varias formas de implementar los cambios realizados en el código de los Web Resources.

Describiremos aquí dos procedimientos que son válidos y uno que no lo es.

INVALIDO – Copiar el código dentro del “Text Editor” de la UI de Dynamics

En antiguas versiones de Dynamics CRM no existían los Web Resources.

La implementación de código Javascript se hacía embebiendo el código en una sección que la UI de CRM nos otorgaba para tal fin.

Al parecer, muchos desarrolladores siguieron con la misma costumbre de “Copiar y Pegar” el código en Dynamics CRM 2011.

Esto no se debe hacer, ya que a partir del Rollup update 8, este “Editor de Texto” nos trunca el código en 2000 caracteres.

clip_image019

RECOMENDADO – Implementar las Modificaciones Desde el Archivo con el Código Fuente

Este procedimiento es fácil y nos da la seguridad de que estamos implementado exactamente las modificaciones que queremos implementar.

Tiene como ventajas que es claro, rápido y transparente.

Tiene como desventaja que es un poco tedioso para implementaciones masivas (muchos Web Resources al mismo tiempo).

Detallamos cómo hacerlo:

1. Abrir el CRM Explorer.

2. Hacer doble Click sobre el Web Resource a Actualizar.

(Esto abrirá la ventana del Web Resource dentro de nuestro entorno de VS)

clip_image021

3. Abrir desde el Project Explorer el archivo con el código fuente.

4. Click derecho sobre la solapa del archivo.

5. Click sobre la opción “Copy full path”

clip_image023

6. Click sobre el botón “Browse…” en la ventana del Web Resource (CRM UI)

7. Pegar el path copiado.

8. Click sobre el botón “Save”

9. Click sobre el botón “Publish”

VÁLIDO – Deploy del Proyecto

Al hacer Deploy del proyecto (Ver Sección 5), todos los web resources cuya propiedad “Build Action” sea “CRM WebResource” serán implementados en nuestro entorno de Dynamics CRM.

Para que los cambios cobren efecto, se deberá hacer un “Publish” desde la UI de Dynamics CRM.

Este procedimiento tiene como ventaja la posibilidad de hacer Deploy de muchos web resources al mismo tiempo.

Como desventaja lidiamos con que, al hacer deploy,,si no especificamos lo contario, estamos implementando tanto web resources, como plugins, como implementaciones Silverlight y todo lo que tengamos en nuestro proyecto.

En general, tomar todos los recaudos para que únicamente se implemente el código que queremos se torna tedioso.

Además, suele tardar más tiempo que el procedimiento anteriormente descripto.

Cómo Crear Plugins en Dynamics CRM 2011 usando Visual Studio

1. Abrir el menú “CRM Explorer”

2. Hacer click sobre la Organización

3. Desplegar el menú de entidades

clip_image025

4. Click derecho sobre la entidad para la cual se quiere generar un plugin

5. Click sobre la opción “Create Plugin”

clip_image027

Se abrirá una ventana en la cual se deberá configurar el plugin a crear.

Dicha ventana la describiremos a continuación:

clip_image029

a. Message: Es el “Mensaje” o “Step” en el cual se va a atachar el plugin. Es decir, que evento va a disparar la ejecución del plugin. Los de uso más extendido son:

i. Update: Los plugins registrados en este Step se dispararan cuando un registro haya sido actualizado

ii. Create: Los plugins registrados en este Step se dispararan cuando un registro haya sido creado.

iii. Assign: Los plugins registrados en este Step se dispararan cuando un registro haya sido asignado a un usuario distinto al que lo está actualmente.

iv. Delete: Los plugins registrados en este Step se dispararan cuando un registro haya sido borrado.

v. Retrieve: Los plugins registrados en este Step se dispararan cuando Dynamics hace la solicitud de un registro a la base de datos.

b. Run in Context: Al hacer click en este menú, se despliega una lista de todos los usuarios contenidos en la organización de crm y además una opcion, que viene seleccionada por defecto, llamada “Calling User”.

Este campo determina si el plugin deberá ejecutarse sin importar que usuario dispare el evento (Calling User) o solo si es disparado por un usuario en particular.

c. Pipeline Stage: En Dynamics, además de elegir en que evento vamos a atachar un plugin, debemos explicitar también un “Pipeline Stage”.

Cada evento, en CRM, está compuesto en realidad de dos eventos:

i. Pre-Operation: Se dispara antes de que los cambios en el registro hayan impactado en la base de datos.

ii. Post-Operation: Se dispara después de que los cambios hayan impactado en la base de datos.

d. Pre Image Alias: Si completamos este campo, entonces, se generara automáticamente en el plugin, un objeto del tipo Entidad conteniendo el valor de los atributos que hayamos seleccionado como parámetros ANTES de haberse producidos los cambios que dispararon el plugin..

e. Post Image Alias: Si completamos este campo, entonces, se generara automáticamente en el plugin, un objeto del tipo Entidad conteniendo el valor de los atributos que hayamos seleccionado como parámetros DESPUES de haberse producidos los cambios que dispararon el plugin.

f. Class: Nombre de la clase.

g. Deployment: Desde este atributo se determina en que cliente de Dynamics CRM – ya sea Server Only, Outlook only o ambos - se hará deploy del plugin en cuestión.

6. Hacer click en el botón “OK”.

Se generara una clase dentro del proyecto “Plugins”.

Esta clase hereda de Plugin, que a su vez implementa la interfaz IPlugin, definida en el SDK de Dynamics.

Consideraciones y consejos para el desarrollo de Plugins en Dynamics CRM

Como instanciar el registro siendo modificado

En Dynamics, podemos instanciar un objeto que contenga la modelización del registro cuya modificación disparo el plugin.

Para instanciar un objeto del tipo Entity / EntityReference se deberán utilizar las siguiente líneas de código:

1.

clip_image030

Para los siguientes Steps: Create, Update, Delete.

2. Para el step Assign:

a.

clip_image031

Registro en cuestion:

b. Registro que fue asignado como responsable del registro en cuestión:

clip_image032

Como hacer Deploy de los plugins en Dynamics CRM desde Visual Studio

clip_image034

1. Cerciorarse de que el archivo “RegisterFile.crmregister” no se encuentra bloqueado ni tomado por otro usuario.

2. En el Solution Explorer, hacer click derecho sobre el proyecto “CrmPackage”

3. Hacer click en la opción “Deploy”

Una vez hecho esto, nos aparecerá un icono, en la barra inferior del VS, indicando el estado del proceso. Una vez finalizado, se leerá la leyenda “Deploy Succeeded”.

Exportar / Importar Plugins desde CRM

Una vez instalados los plugins desde VS, se puede acceder a ellos desde CRM.

Visual Studio implementa los plugins en CRM creando:

clip_image001 Un archivo <<NombreDelProyexto>>.dll por cada proyecto del que se hace deploy.

clip_image001[1] Un archivo <<NombreDeLaClaseDelPlugin>> por cada plugin que hayamos registrado en el RegisterFIle.crmregister

Para importar / exportar los plugins se los debe agregar a una solución de Dynamics CRM y proceder mediante el circuito nativo para importar / exportar soluciones.

Dynamics CRM 2011 y Javascript

Al desarrollar customizaciones para Dynamics CRM 2011 nos encontraremos con que muchas de ellas se deben desarrollar utilizando javascript.

Para ello contamos con distintas librerías que nos ayudan a realizar dichas customizaciones.

Describiremos a continuación una de las más útiles.

XRMServiceToolkit.js

Link de descarga: http://xrmservicetoolkit.codeplex.com/releases

Esta librería nos da una fácil implementación de cosas como:

clip_image001[2] Métodos comunes: Cambios en el formulario de CRM (deshabilitar y / ocultar campos, obtener valores de campos, etc).

clip_image001[3] Métodos Rest Endpoint: Crear, consultar, actualizar campos, etc.

clip_image001[4] Métodos Soap: Crear, consultar, actualizar campos, etc.

clip_image001[5] Métodos complementarios: Configurar OptionSets dependientes uno de otros, Agregar Tooltip a campos, Agregar vistas filtradas a Lookups, etc.


Crear un Registro
clip_image035

Hacer Retrieve de un Registro
clip_image036
Actualizar un Registro
clip_image037
Eliminar un Registro
clip_image038

Asociar dos Registros
clip_image039
Desasociar dos Registros
clip_image040
RetrieveMultiple
clip_image041

Ejecutar una consulta FETCHXML
clip_image042

Ejecutar una consulta por atributo
clip_image043

Xrm.Page Object Model

Microsoft Dynamics CRM introduce un nuevo modelo de objeto para interactuar con su entorno: “Xrm.Page”.

Este modelo de objeto permite, entre estas cosas:

clip_image001[6] Mostrar / Ocultar elementos de la UI.

clip_image001[7] Soportar controles múltiples por atributo.

clip_image001[8] Soportar formularios múltiples por entidad.

clip_image001[9] Manipular ítems de navegación entre formularios.

Es importante destacar que este objeto únicamente incluye en sus colecciones a los atributos que fueron materializados como un campo en el formulario. Por lo tanto, si un atributo existe, pero no está incluido como un campo en el formulario, el Xrm.Page Object Model no lo incluirá en sus colecciones.

Jerarquía

Como se muestra en el siguiente diagrama, Xrm.Page provee un namespace para tres objetos descriptos en la siguiente tabla:

Objeto

Descripción

context

Provee métodos para hacer un retrieve de información específica de una organización, un usuario, o parámetros que fueron pasados al formulario a través de una QueryString.

data

Provee acceso a la información de la entidad.

ui

Contiene métodos para hacer un retrieve de información de la UI. Además, brinda acceso a distintos sub componentes del formulario

clip_image045

Métodos Útiles

Acción

Sintaxis

Notas

Obtener el valor de un campo.

Xrm.Page.getAttribute("<<NombreDelCampo>>").getValue()

Obtener el texto de la opción seleccionada en un OptionSet

Xrm.Page.getAttribute("<<NombreDelCampo>>").getSelectedOption().text

Setear el Valor de un campo

Xrm.Page.getAttribute("<<NombreDelCampo>>").setValue(<<Nuevo Valor>>)

Establecer el modo de submit de un campo

Xrm.Page.getAttribute(("<<NombreDelCampo>>").setSubmitMode(("<<SubmitLevet>>")

Submit Levels:

•always

•never

•dirty

Establecer el nivel de requerimiento del campo

Xrm.Page.getAttribute(("<<NombreDelCampo>>"). setRequiredLevel("<<NivelDeRequerimiento>>")

Nivel de Requerimiento:

•none

•required

•recommended

Deshabilitar / Habilitar un control

Xrm.Page.getControl("<<NombreDelCampo>>").setDisabled(true);

•true à Deshabilitado

•false àHabilitado

Obtener Id del usuario logueado

Xrm.Page.context.getUserId()

Obtener Url del Server

Xrm.Page.context.getServerUrl()

Obtener Id del registro en el cual se está ejecutando el script

Xrm.Page.data.entity.getId()

Cambiar de formulario

Xrm.Page.ui.formSelector.items.get("<<NumeroDeFormulario>>").navigate()

Identificar si el formulario es de creación, actualización, etc.

Xrm.Page.ui.getFormType()

•Si devuelve 1 à El contexto del formulario es de creación.

Si Devuelve 2 àEl contexto del formulario es de actualización.

Interrumpir el evento “Save” del formulario

(Habiendo pasado el contexto del evento como parámetro “event”)

event.getEventArgs().preventDefault();

ClientGlobalContext.js.aspx

Esta librería es nativa de Dynamics CRM 2011 y nos brinda un acceso a la información del contexto en el cual se esté ejecutando un web resource.

La función ClientGlobalContext devuelve el mismo objeto encontrado en Xrm.Page.context.

Cuando se esté programando un web resource javascript para un formulario, se deberá usar el objeto Xrm.Page.context.

Cuando se necesite información del contexto fuera del formulario (por ejemplo, en un web resource .html embebido en el formulario), se deberá incluir una referencia a ClientGlobalContext.js.aspx.

….Enjoy coding!

Referencias

1. http://msdn.microsoft.com/en-us/library/hh372957.aspx, Developer Toolkit for Microsoft Dynamics CRM.

2. http://xrmservicetoolkit.codeplex.com , XrmServiceToolkit - A Microsoft Dynamics CRM 2011 & CRM 2013 JavaScript Library.

3. http://msdn.microsoft.com/en-us/library/gg328541.aspx , GetGlobalContext Function.

4. http://msdn.microsoft.com/en-us/library/gg328474.aspx, Xrm.Page Objetc Model.

5. http://blogs.msdn.com/b/arpita/archive/2012/02/19/microsoft-dynamics-crm-2011-force-submit-on-a-disabled-field-or-read-only-field.aspx

6. http://es.wikipedia.org/wiki/Microsoft_Dynamics_CRM, ¿Qué es Microsoft Dynamics CRM?

¡Gracias por tu contribución Santiago Díaz!

martes, 8 de julio de 2014

6 Razones para Gestionar el Portafolio de los Proyectos

Usualmente las organizaciones se ven en el dilema de implementar alguna forma de gestionar el portafolio de proyectos. Ante esta situación vale la pena preguntarse:
·         ¿Realmente la organización lo necesita?
·         ¿Cuáles son los síntomas organizacionales que denotan la necesidad de gestionar el portafolio de los proyectos?
·         ¿Cuál es el valor agregado que aporta al negocio?
·         ¿Cuáles son los beneficios directos de gestionar el portafolio?

Este artículo desarrolla seis razones claves para tomar una decisión sobre la administración de portafolios de una organización.

1.      Alinear la ejecución de los proyectos con la visión estratégica del negocio.

Los proyectos representan objetivos que, al cumplirse satisfactoriamente, acercan a la compañía hacia sus metas organizacionales. Pero, ¿qué sucede cuando más de un proyecto comparte objetivos con otros? ¿Cuál de ellos aporta más valor a la estrategia del negocio? Cuando hay dos proyectos en ejecución y se debe cancelar uno, ¿por cuál  se decide sin provocar desvíos irreparables en la estrategia definida por la organización?

Para responder estas preguntas es necesario utilizar herramientas y técnicas que permitan a los decisores de la organización seleccionar la mejor alternativa. Las herramientas más utilizadas son: definir criterios de selección de proyectos, disponer de indicadores de control y seguimiento del comportamiento del portafolio, diseñar e implementar un tablero de control central (Balanced Scorecard) del portafolio.


2.      Brindar indicadores de seguimiento útiles para la toma de decisión.

Los indicadores del portafolio definidos deben facilitar la toma de decisiones para brindar al decisor la posibilidad de seleccionar una alternativa posible antes de llegar al caos o una situación no deseada. En este punto, los indicadores no sólo deben representar la realidad del portafolio y de los proyectos en particular sino además la del propósito de negocio que persiguen.

La organización debe preguntarse: ¿La productividad de los proyectos es la esperada? ¿El proceso de toma de decisiones está sustentado en indicadores fiables y defendibles? ¿Los indicadores utilizados son objetivos? ¿Los indicadores utilizados facilitan la toma de decisiones?


3.      Generar  pronósticos de rendimiento de los proyectos para acortar el proceso de toma de decisiones.

Al momento de tomar decisiones sobre el portafolio de proyectos es necesario considerar su comportamiento para las dimensiones de recursos humanos, finanzas, gestión del valor al negocio y del estado general de salud de los proyectos. Para lograrlo, es necesario disponer no sólo de la información actual sino del pronóstico. Cuando esta información no es generada es recomendable utilizar herramientas de análisis de escenarios para poder conjugar una o más variables y analizar así una proyección del portafolio considerando tal o cual decisión.

La organización debe preguntarse: Al momento de tomar decisiones sobre los proyectos, ¿consideramos el impacto global del portafolio? ¿Disponemos de las herramientas necesarias para interpretar los pronósticos de los proyectos? ¿Es posible disponer la información de los proyectos sin procesarla una y otra vez de la misma manera? ¿Disponemos de técnicas y herramientas que faciliten la previsibilidad del rendimiento de los proyectos?


4.      Brindar información a la gerencia, mandos medios y líderes de forma consolidada y en tiempo y forma.

La generación de informes, reportes y tableros de control no sólo permite acercar adecuadamente la información a una audiencia específica; además permite acortar los tiempos de decisión. Para esto, es importante que cada organización disponga de los procesos y canales de comunicación claramente definidos.

Las dimensiones de apertura de información son: estado financiero, planificación, gestión de recursos humanos,  gestión del alcance, gestión de tecnología empleada y calendarización.

La organización debe responderse: ¿Disponemos de informes y reportes acordes a cada audiencia? ¿La información está disponible cuando se la necesita? ¿La información se encuentra específicamente orientada a la toma de decisiones o hay que re procesarla para luego interpretarla? ¿La información está disponible en el vocabulario adecuado de gestión?

5.      Minimizar y eliminar los problemas de planificación de recursos humanos compartidos entre proyectos.

Gestionar los recursos humanos no es una tarea sencilla y suele perder importancia cuando sólo se considera esta actividad al momento de la asignación a los proyectos, perdiendo así la visión global del comportamiento del portafolio en su conjunto.

La clave es gestionar la capacidad y la asignación de los recursos durante todo el ciclo de vida del portafolio de proyectos:

ü  Gestionar capacidad: la organización debe saber cuál es su capacidad plena de esfuerzo disponible para emplear los recursos existentes. Esto permite a las compañías determinar qué cantidad de trabajo puede ejecutar. Además, debe saber cuál es la secuencia más adecuada de locación (seleccionar y disponer) de los recursos, resguardando el solapamiento y la ausencia de asignación. Para este punto, es de suma importancia que la organización disponga de una base centralizada de cuáles son los roles genéricos que poseen las personas; estos roles son los que en su conjunto determinan si la organización dispone o no de las capacidad para cubrir los requerimientos de los proyectos.

ü  Gestionar la asignación: se espera que la organización disponga no sólo de  personas sino de habilidades correctas, esto es, el perfil más conveniente para el proyecto más adecuado.

La organización debe preguntarse: ¿Disponemos de la capacidad necesaria para cumplir con la demanda? ¿Existe una correcta asignación de la persona adecuada al proyecto correcto? ¿Existen problemas recurrentes de sobre asignación de recursos a los proyectos? ¿Los recursos son asignados a tiempo a los proyectos?


6.      Reducir la curva de aprendizaje al momento de ejecutar proyectos de características similares.

Al momento de gestionar el portafolio en su conjunto es vital favorecer su gestión, brindando herramientas y técnicas a los líderes en búsqueda de una ejecución de proyectos eficiente y eficaz. Desde esta concepción, se debe disponer de procesos de gestión definidos y normalizados, gestionar el conocimiento elaborado desde los proyectos, y gestionar los riesgos organizacionales que pueden afectar al portafolio.

Al disponer de procesos definidos es posible Gestionar el Valor (creación y captura) del conocimiento que generan los proyectos. El propósito final es lograr una reducción de la curva de aprendizaje y compartir el valor que generan los proyectos en términos de nuevas capacidades (procesos, skills, cultura) y recursos (capital, infraestructura, información).


La organización debe preguntarse ¿Estamos cometiendo los mismos errores una y otra vez en cada proyecto? ¿Existen riesgos comunes entre los  proyectos que no están siendo gestionados? ¿Estamos retrasando proyectos por no gestionar el conocimiento organizacional? ¿Disponemos de una base única de conocimiento generado desde y para los proyectos de la organización?


¡Gracias por tu contribución Matías Barrios!