A continuación un simple ejemplo de lo que podría ser un entorno de desarrollo para N desarrolladores trabajando conjuntamente en el desarrollo de un aplicativo sobre AgilePoint BPM, y con la gestión de código fuente de la aplicación mediante Team Foundation Server.
El entorno del desarrollador que podría distribuirse facilmente mediante máquinas virtuales, cuenta con todo lo necesario para la construcción. Visual Studio 2008 SP1 + Framework 3.5 SP1 para trabajar con las últimas versiones estables y consolidadas en el mercado de tecnología .NET. En el caso de estar trabajando en el desarrollo de aplicaciones web, un IIS local donde desplegar las aplicaciones web y hacer las pertinentes pruebas de desarrollo y debugs. A Visual Studio se le incorpora el plugin AgilePoint Developer para el desarrollo a medida de nuevos AgileWorks, AgileParts y AgileConnectors. Finalmente se cuenta con la disponibilidad de Microsoft Visio 2007 más el plugin AgilePoint Envision, para el desarrollo en local de las plantillas (flujos de trabajo) de AgilePoint.
En el repositorio central se almacena todo el código fuente generado por los desarrolladores mediante el uso de Team Foundation Server, que garantiza la trazabilidad del código, gestión de versiones, etc; además de poder convertirse en una herramienta de gestión y control centralizado del trabajo asociado al desarrollador. Asignación de trabajo mediante el uso de Work Items, y el control de los bugs existentes en la aplicación son algunas de sus capacidades. Al mismo tiempo, mientras el uso de Sharepoint, permite crear fácilmente portales asociados a cada uno de los proyectos en desarrollo, donde el equipo de construcción puede compartir documentación de forma centralizada y todo tipo de información de gestión o técnica asociada a cada uno de los proyectos. Debemos tener en cuenta que este entorno deberá mantener también el control de versiones asociado a las plantillas de Visio que se vayan generando mediante NVision.
El entorno de desarrollo de Agilepoint, que centraliza tanto el AgilePoint Server, la gestión web del mismo a través del Enterprise Manager, y el interfaz de servicios web que permite gestionar de forma remota y transparente el acceso a las facilidades que provee el motor de Agilepoint.
Finalmente se expone un último entorno, representativo de cada tipo de aplicación, que no hace más que definir la posible existencia de un tercer entorno de integración, necesario para el desarrollo de la aplicación, como otros servicios de comunicación u otros aplicativos existentes en el sistema sobre los que nuestra aplicación en desarrollo deba integrarse.
Hasta el momento solo habíamos hablado de malas y buenas prácticas que estaban asociadas a labores de construcción de bajo nivel, pero, éstas, aunque siendo sin duda malas prácticas, quedan bajo la sombra que provocan otras prácticas de dudosa viabilidad que se llevan a cabo en niveles más altos, y sobre las que el impacto en un proyecto de desarrollo de software es aún mucho más pesado.
Un ejemplo muy claro es el incluir en un documento de descripción de la funcionalidad (Documento funcional o de Requerimientos o como estéis más acostumbrado a llamarlo), descripciones que tienen que ver con la parte técnica. Si además de describir cómo ha de comportarse algo funcionalmente, incluimos la pantalla asociada a la funcionalidad en el mismo documento, y además describimos lo que tiene que hacer la pantalla (si pulso aquí se desplegará un menú, si hago botón derecho me saldrán las opciones “juan” y “pedro”, si paso el ratón por encima de la zona central se mostrará un aviso indicando el nombre del formulario…) estamos haciendo el documento funcional totalmente dependiente de la tecnología a emplear, cuando este último debería limitarse únicamente a describir el negocio de la aplicación.
De ahí que, bajo mi punto de vista, así como el uso de diferentes capas a la hora de definir una arquitectura de software es una buena herramienta de diseño, aplicar el mismo concepto a la documentación funcional también lo es.
Sería interesante entonces trabajar a dos niveles. Inicialmente crear el documento estrictamente funcional, desarrollado por un analista o experto en el negocio incluyendo en el mismo casos de uso, requerimientos y reglas del negocio. A partir de ahí, y tras análisis del documento funcional, un perfil algo más técnico, con conocimientos de usabilidad y de arquitectura de software, debería evaluar la documentación y proponer (además de una arquitectura de software adecuada para el tipo de funcionalidad requerida), cómo orientar la funcionalidad a la pantalla que va a ver el usuario, creando los prototipos pertinentes, bajo la perspectiva de la tecnología seleccionada para la solución.
Y es que en más ocasiones de las que nos gustaría, en el mundo del software nos encontramos con situaciones que responden comunmente al siguiente símil.
Juan tiene un clavo y Pedro un destornillador. Juntos, quieren conseguir clavar el clavo en una tabla. Alberto, un amigo de ambos, tiene un martillo y también sabe usar el destornillador.
Antes de comenzar el trabajo Juan y Pedro se reunen; y tras descartar el pedirle el martillo a Alberto, por motivos que desconocemos, deciden clavar el clavo en la tabla con el destornillador.
Alberto, que participa como observador en la reunión, analiza la situación y transmite a Juan y Pedro sus conclusiones:
Si intentan clavar el clavo con el destornillador, puede que al final lo claven, ahora bien, al no ser la herramienta más adecuada, van a necesitar invertir muchos recursos para conseguirlo, ya que van a enfrentarse a innumerables problemas.
Si lo clavan, seguramente o quede el clavo torcido, o acaben rompiendo el destornillador.
Si saben que yo tengo un martillo, y que sé clavar clavos con él, ¿por qué no me lo piden?
A partir de aquí aparecen las tres vertientes de la historia:
Juan y Pedro le piden el martillo a Alberto. El clavo se clava y todos son felices. (Esta no suele ocurrir).
Juan y Pedro proceden con su idea inicial. Un año más tarde de lo previsto la mitad del clavo y torcido está casi clavado en la tabla. El destornillador ya no sirve. (Esta os sonará más).
Juan, Pedro y Alberto siguen la reunión hablando de más alternativas, de las expectativas y necesidades de cada uno. Finalmente, caen en la cuenta que a Juan no le importa quitar algo de la superficie de su clavo (donde debería golpear el martillo), ya que la final lo que quiere es clavar el clavo y eso no le afecta a su objetivo. Curiosamente el hueco que dejan en la superficie del clavo es el suficiente para que encaje el destornillador y conseguir así, sin apenas esfuerzos extra respecto al martillo, clavar el nuevo tornillo, salido tras manipular el clavo, con el destornillador. (Esta tampoco suele ocurrir).
Para los menos imaginativos o exhaustos tras una dura jornada de trabajo, una pista: la historia la ha escrito Alberto.
A pesar de lo poco que me deja últimamente el trabajo el ir añadiendo artítulos, parece que el número de visitas se está manteniendo e incluso subiendo ligeramente la media.
Eso ha hecho que la página haya adquirido en los últimos días el Page Rank 5 de Google.
La última subida, que fue a 4, se dio el 14/01/2009 y parece que menos de un año después las cosas siguen mejorando.
Simplemente seguir insistiendo en los agradecimientos, ya que con vuestras visitas y vuestros comentarios a los artítulos, sois los que estáis haciendo que cada día este blog se encuentre cada vez mejor posicionado.
En esta ocasión, os dejo un link a una página muy orientada al mundo de la consultoría y donde los que trabajéis en este ámbito os vais a sentir muy identificados con los artículos ahí expuestos.
La idea de incoporar un documento de Estándar de Codificación y Trabajo, empezó hace cosa de un año. El objetivo principal era el de plasmar un pequeño ejemplo de cómo definir un documento de este tipo y qué partido se le podía sacar, así como pequeñas ideas de qué elementos son “estandarizables” dentro del desarrollo de una aplicación.
El documento intenta cumplir un objetivo más didáctico que otra cosa, espero que os sirva para aportaros algunas ideas.
En esta versión, que se lanza aún como beta ya que los conceptos se han incorporado únicamente de forma parcial, se describen las siguientes casuísticas:
Nuevas cláusulas asociadas a la vista, como es el criterio a seguir a la hora de aplicar hojas de estilo.
Restructuración del apartado destinado al uso de la arquitectura de N-Capas, ampliándolo, y definiendo los accesos a seguir para cada una de las capas a aplicar. Se describen las orientaciones al respecto de la capa de acceso datos y la capa de datos
Y es que a la hora de acceder a una base de datos tenemos tantas opciones que muchas veces lo complicado es intentar decidir cuál de todas resulta la mejor para nuestro proyecto y/o organización.
Trabajando con .NET los dos motores de base de datos más empleados son SQL Server y Oracle, y para acceder a ellos desde una de nuestras aplicaciones podemos pasar desde utilizar los drivers propios de Microsoft para acceder a ambos gestores, con clases propuestas por el propio framework, podemos acceder a oracle a traves de los Oracle Data Access Components (ODAC) para .NET, podemos usar Datasets Tipados con sus correspondientes TableAdapter para aliviar algo el tiempo de construcción… utilizar patrones de acceso a datos como DAO+DTO… y un largo etcétera que puede pasar por soluciones caseras más o menos elaboradas, aplicaciones de otros patrones de acceso a datos como puede ser Active Record o herramientas de acceso a datos orientadas entidades como el nuevo Microsoft Entity Framework y la versión de Hibernate para .NET, NHibernate. Para más diversión, incluso pueden emplearse combinaciones de alguna de las herramientas descritas en el párrafo, intentando ajustar el esfuerzo de construcción a nuestro proyecto y, lo más complicado de todo, a nuestra planificación
Pues ante toda esta lista interminable de herramientas, cada una con sus pros y sus contras, añado y expongo a continuación las ventajas aportadas por otra más, las Enterprise Library con su funcionalidad de acceso a datos: Data Access Application Block.
¿Qué nos aporta el Data Access Application Block?
Pues una de las principales ventajas que aporta el framework es que permite con la misma codificación atacar a diferentes gestores de bases de datos, es decir, tras preparar el acceso a datos de nuestra aplicación con enterprise library, podríamos ser capaces sin cambiar ni una línea de código (no os toméis esto al pie de la letra, que seguro que algo habrá que cambiar aunque sea mínimo), de pasar de atacar a un SQL Server a un Oracle. Esta puede ser una gran ventaja si estáis preparando un producto al que dependiendo del cliente al que se lo vendáis tengáis que garantizar el soporte de ambos gestores, porque por ejemplo alguno de vuestros clientes esté casado con Oracle y otro con SQL Server. Con un sólo desarrollo de vuestra capa de acceso a datos cubriréis toda la casuística (menos los procedimientos almacenados, claro, que os va a tocar picarlos dos veces ).
Otras ventajas a tener en cuenta son la facilidad de configuración. Una vez instaladas las enterprise library disponemos de una pequeña aplicación que apuntándola al Web.Config o App.Config de nuestro aplicativo permite editar las propiedades de conexión de manera visual. Pudiendo configurar el proveedor de la conexión, tipos de autenticación y más parámetros propios de una conexión a datos de forma muy cómoda y sencilla.
Una vez configurada la conexión, con una línea como la siguiente conectamos con el gestor, independientemente de cuál sea (DataBase y DataBaseFactory son clases del Data Access Application Block).
Y para recorrer el datareader, pues como siempre, utilizando el método Read y luego en el registro sobre el que trabajamos obteniendo el dato a través del identificador de la columna.
Como véis es rápido y sencillo (no tanto para los que os toque trabajar contra Oracle, ya que os vais a necesitar conocer algún truquillo extra), y os ayuda a mantener una total independencia con el gestor de base de datos.
Bajo mi humilde opinión, Data Access Application Block podría ser un buen candidato a herramienta de acceso a datos corporativo en cuanto al desarrollo de soluciones .NET.
Ya hemos hablado anteriormente de otras herramientas para trabajar con TFS de forma remota (como el Team Foundation Sidekicks), sin necesidad de trabajar con el propio cliente integrado en Visual Studio, y que aportan funcionalidades añadidas respecto a esta última versión.
A continuación detallo una más, TeamPrise, nunca viene mal tener diversidad para elegir.
En esta ocasión este va a ser un post que en lugar de explicar o dar a conocer algo va a intentar lo contrario, que intentéis compartir vuestra experiencia al respecto de un tema que llevo planteándome hace tiempo y que a nivel laboral también me he encontrado en alguna ocasión.
Como sabréis, hoy en día el BPM esta de moda, y son muchas las empresas privadas e instituciones públicas que quieren apostar por este tipo de sistemas. Para proyectos con un presupuesto y alcance suficiente, se intenta abordar el problema adquiriendo productos desarrollados por otros proveedores especializados en este tipo de producto. El problema aparece en proyectos de menor alcance, donde la inversión por un BPM con la tipología que os comentaba hace un momento, no es viable.
A partir de aquí se me ocurren dos alternativas:
* Encontrar una solución BPM, que aunque no cuente con toda la funcionalidad y el nivel de soporte de un producto estandar, pueda atender a las demandas del alcance necesario, de manera gratuita, es decir, un producto de software libre.
* Para desarrollos .NET, partir de la definicion base de Workflow Foundation y extenderla a base de enfocar recursos propios de la empresa a este respecto, con la idea de crear un producto que puede ser reutilizado en otros proyectos de la misma empresa.
Enfocándome en el segundo punto, que es la finalidad del post, mi duda al respecto es si alguno de vosotros se ha tenido que enfrentar a un problema similar, y cuál ha sido su experiencia al respecto. Es decir, partiendo del funcionamient basico de Workflow Foundation, ampliar sus capacidades con requerimientos basicos de un BPM, como podria ser una asignacion de tareas a usuarios, grupos de usuarios, perfiles roles (con sus correspondientes paneles de administracion para el mantenimiento) a actividades. Y lograr crear actividades con límite de tiempo de ejecución o de finalización masiva (como podrian ser las confirmaciones de entrega, o las recepciones de documentación… hemos hablado sobradamente de esto en el especial de motores de flujo). Todo esto, por supuesto, en su sistema basado en persistencia en base de datos. No estamos hablando de flujos que duren horas, si no en flujos que pueden durar, semanas, días, meses y hasta años.
En su momento realicé investigación por mi parte, y encontre ciertas dificultades en el modelo de persistencia y tracking de Workflow Foundation respecto sobre todo a la poca documentacion que encontre que me fuera de utilidad. Se habla mucho de PersistenceService y TrackingService y de la capacidad de ampliar el modelo, pero a nivel de persistencia en base de datos, es de locos enterarse para qué sirve cada una de las tablas que se genera para la persistencia y cada uno de los campos de la misma. Y sin esa base clara, poco se va a poder avanzar para ampliar el funcionamiento.
De ahí que en este caso sea yo quien solicita vuestra ayuda, cualquier ayuda que podais aportar respecto a BPM’s de software libre y la posibilidad de embarcarse en el proyecto de ampliar las capacidades de Workflow Foundation. Será más que bienvenida.
