La vista de despliegue muestra en donde se ejecutan los componentes del sotware, entonces para poder documentar en donde, primero hay que decumentar qué, es decir, los componentes. Para hacerlo encontré un documento excelente que explica estrategias de documentación la vista de componentes o “Componentes & Connectors”, como ellos la llaman. Es un documento del SEI (Software Engineering Institute). La URL es la siguiente: http://www.sei.cmu.edu/publications/documents/04.reports/04tr008.html
Además, existe un ejemplo muy práctico en http://www.agilemodeling.com/artifacts/deploymentDiagram.htm, con explicaciones que aclaran qué vale la pena documentar en la mayoría de situaciones.
Hasta ahora, mi experiencia con UML indica que no es un lenguaje trivial, no porque su simbología sea compleja, sino por las sutilezas de su semántica. Hay que ser un experto en UML para que se cumpla aquel slogan de que” UML es un lenguaje que disminuye la ambigüedad”. El problema más importante es que no solamente quien diseña debe ser experto en UML, para que el mensaje llegue sin ruido quien lee debe tener ese mismo nivel de conocimiento.
[1] IVERS, CLEMENTS, et. all. "Documenting Component and Connector Views with UML 2.0". Software Engineering Institute. 2004.
[2] AMBLER, Scott. "The Object Primer 3rd Edition: Agile Model Driven Development with UML 2". Cambridge University Press. 2004.
jueves, diciembre 15, 2005
miércoles, diciembre 14, 2005
Procesos asíncronos
Desde hace algún tiempo he descubierto que los procesos asíncronos son muy adecuados en muchas circunstancias de procesamiento. A medida que se van encontrando situaciones reales para las cuales este tipo de procesamiento es adecuado, se descubren nuevas ventajas y nuevas desventajas. Una de las desventajas más importantes consisten en que los procesos asíncronos, a diferencia de los procesos sincrónicos necesitan dejar un rastro de ejecución y además una interfaz administrativa para consultar y tomar decisiones sobre las excepciones registradas en este rastro (o log de ejecución).
A primera vista, esta administración adicional hace menos factible el uso de procesamiento asíncrono, pero muchas veces esta funcionalidad adicional ofrece una mayor flexibilidad, facilita el monitoreo y permite conocer el estado o la evolución del servicio.
El procesamiento asíncrono es una buena alternativa para ciertas soluciones, como todo, debe aplicarse donde realmente tenga sentido, aplicarlo por estar “de moda” puede tener el efecto contrario: complicar la interacción en el usuario y el sistema, demorar un proceso que requiere información en línea y agregar complejidad administrativa.
A primera vista, esta administración adicional hace menos factible el uso de procesamiento asíncrono, pero muchas veces esta funcionalidad adicional ofrece una mayor flexibilidad, facilita el monitoreo y permite conocer el estado o la evolución del servicio.
El procesamiento asíncrono es una buena alternativa para ciertas soluciones, como todo, debe aplicarse donde realmente tenga sentido, aplicarlo por estar “de moda” puede tener el efecto contrario: complicar la interacción en el usuario y el sistema, demorar un proceso que requiere información en línea y agregar complejidad administrativa.
martes, diciembre 13, 2005
Metodología de desarrollo de software y nivel de madurez del proceso
Implantar una metodología de desarrollo de software puede ser algo complicado si no se tiene un horizonte, sino se sabe hacia donde se quiere ir y que nivel de madurez se quiere lograr.
Alguien desprevenido diría que todo el que desarrollo software quisiera alcanzar el mayor nivel de madurez posible. El problema es que alcanzar cada nivel de madurez tiene un costo importante, requiere entrenamiento, planeación, control, ejecución y otras cosas más. Además, cada nivel de madurez tiene ciertos beneficios específicos.
El primer paso para implantar una metodología es tener el deseo y estar convencido que es lo que se necesita para mejorar, si no existe este compromiso, como mínimo, en el nivel gerencia, el proyecto tiene un gran riesgo de fracaso.
Después de tener el compromiso debe levantar el mapa de procesos que servirá como carta de navegación. Los procesos de una compañía reflejan la cultura organizacional y las mejores prácticas que se han identificado con el tiempo; una metodología de desarrollo no debe ser disruptiva en este sentido, debe formalizar y mejorar los procesos actuales y evitar causar un alto impacto sobre la estructura organizacional.
Creo muy recomendable, el acompañamiento del proceso de implantación de una metodología por parte de una empresa de consultoría con amplia experiencia práctica en el tema, evitando complejidades académicas y aprovechando sus experiencias. El perfil de la empresa de consultoría incluiría características como agilidad, practicidad, conocimiento, evidencia de proyectos exitosos y sería muy deseable una certificación CMMI.
Finalmente, la metodología personalizada para la organización debe ser ajustada durante su tiempo de “producción”, por lo tanto, en esta fase de ajuste se debe estar conciente que no es perfecta y que se necesita la retroalimentación de sus usuarios.
El punto más álgido de todo el proceso es la auditorio y control. Se necesita comprobar que el proceso de desarrollo se está llevando a cabo de acuerdo con la metodología que tanto trabaja a costado. Para ello hay dos estrategias: el seguimiento a través de indicadores y las auditorias a los proyectos. La definición de los indicadores es fundamental, de manera que se pueda evidenciar objetivamente el comportamiento de la organización y verificar una progresión en la calidad, la productividad o en general las metas que se fijen. Las auditorias son acciones más detalladas que permiten verificar mediante evidencias concretas (a través de entregables, por ejemplo) que los pasos definidos por la metodología se cumplen y se cumplen como se supone deberían ser.
Para concluir, creo que una metodología es importante como medio de estandarizar el proceso de desarrollo de software, logrando monitorear y controlar el desempeño de la organización IT. Una vez se logre controlar, es decir, saber el estado actual, es deseable tener un modelo de referencia de madurez que sirva como mapa de navegación para el futuro y facilitar el establecimiento de metas claras y pasos concretos de mejoramiento.
Alguien desprevenido diría que todo el que desarrollo software quisiera alcanzar el mayor nivel de madurez posible. El problema es que alcanzar cada nivel de madurez tiene un costo importante, requiere entrenamiento, planeación, control, ejecución y otras cosas más. Además, cada nivel de madurez tiene ciertos beneficios específicos.
El primer paso para implantar una metodología es tener el deseo y estar convencido que es lo que se necesita para mejorar, si no existe este compromiso, como mínimo, en el nivel gerencia, el proyecto tiene un gran riesgo de fracaso.
Después de tener el compromiso debe levantar el mapa de procesos que servirá como carta de navegación. Los procesos de una compañía reflejan la cultura organizacional y las mejores prácticas que se han identificado con el tiempo; una metodología de desarrollo no debe ser disruptiva en este sentido, debe formalizar y mejorar los procesos actuales y evitar causar un alto impacto sobre la estructura organizacional.
Creo muy recomendable, el acompañamiento del proceso de implantación de una metodología por parte de una empresa de consultoría con amplia experiencia práctica en el tema, evitando complejidades académicas y aprovechando sus experiencias. El perfil de la empresa de consultoría incluiría características como agilidad, practicidad, conocimiento, evidencia de proyectos exitosos y sería muy deseable una certificación CMMI.
Finalmente, la metodología personalizada para la organización debe ser ajustada durante su tiempo de “producción”, por lo tanto, en esta fase de ajuste se debe estar conciente que no es perfecta y que se necesita la retroalimentación de sus usuarios.
El punto más álgido de todo el proceso es la auditorio y control. Se necesita comprobar que el proceso de desarrollo se está llevando a cabo de acuerdo con la metodología que tanto trabaja a costado. Para ello hay dos estrategias: el seguimiento a través de indicadores y las auditorias a los proyectos. La definición de los indicadores es fundamental, de manera que se pueda evidenciar objetivamente el comportamiento de la organización y verificar una progresión en la calidad, la productividad o en general las metas que se fijen. Las auditorias son acciones más detalladas que permiten verificar mediante evidencias concretas (a través de entregables, por ejemplo) que los pasos definidos por la metodología se cumplen y se cumplen como se supone deberían ser.
Para concluir, creo que una metodología es importante como medio de estandarizar el proceso de desarrollo de software, logrando monitorear y controlar el desempeño de la organización IT. Una vez se logre controlar, es decir, saber el estado actual, es deseable tener un modelo de referencia de madurez que sirva como mapa de navegación para el futuro y facilitar el establecimiento de metas claras y pasos concretos de mejoramiento.
lunes, diciembre 12, 2005
Modelos de Madurez para SOA (Service Oriented Architecture)
Hay un tema muy interesante que está ganando popularidad y es el modelo de madurez para SOA. SOA, además de ser un término de moda (buzzword), es una aproximación arquitectónica para resolver los problemas de reusabililidad, flexibilidad y visibilidad de los sistemas de software que soportan las operaciones de las compañías.
Sobre SOA hay muchísima información, lo gracioso es que se convirtió en un término de mercadeo por lo que la información se convirtió en desinformación. Ahora, existe una tendencia muy interesante hacia la formalización del concepto (aclaro que el concepto no es que sea nuevo, su amplia adopción y soporte por parte de proveedores de tecnología si lo es).
Desde mi punto de vista existen tres puntos débiles de SOA: una metodología de desarrollo orientada a servicios, el control del ciclo de vida de un servicio y la evaluación de la madurez de adopción de SOA en una organización.
Las metodologías de desarrollo son un tema actualmente bien estudiado y documentado. Existen muchas y de muchos sabores, muchas tendencias y hasta “fundamentalismos” como por ejemplo los defensores de “agil” versus los defensores de BUFD (Big Up-Front Design). Leáse Martín Fowler versus Joel Spolsky, por ejemplo.
Las metodologías de desarrollo definen claramente los flujos de trabajo, los responsables, entregables, disciplinas, prácticas y otras cosas, sin embargo, durante el proceso se ignora frecuentemente el tema de servicios, lo que genera aplicaciones un poco monolíticas o si se tiene suerte, el arquitecto del sistema divide el software en componentes. Desafortunadamente un servicio es de grano grueso comparado con un componente; un servicio ejecuta una actividad completa de negocio, a diferencia de un componente que tiene un conjunto de métodos que presta servicios muy específicos, por ejemplo consulta de valores de acciones, conversión de tasa y monedas extranjeras, entre otros. Una metodología que tenga en cuenta la existencia de servicios debería identificarlos como tal y verificar qué servicios existen para ser reutilizados en el proyecto. Algunos pueden pensar que esta es una actividad de arquitectura, pero yo pienso que como los servicios son de nivel de negocio valdría la pena subir esta actividad a nivel de metodología y tenerla en cuenta a través de todo el proceso, inclusive durante el levantamiento de requisitos.
El ciclo de vida de un servicio inicia en su especificación, sigue con su construcción, pruebas, publicación, mantenimiento, reutilización, monitoreo y posiblemente, muerte. No existen herramientas muy populares orientadas facilitar este proceso, existen orientadas a WebServices, sin embargo faltan muchas características importantes. Una de estas características es la matriz de dependencia, es decir, la matriz que indica quien está o han consumido un servicio. Este dato es fundamental para el ciclo de vida del servicio, especialmente durante la fase productiva del servicio. Lo único que es seguro en software es que los requisitos cambiarán, como los requisitos de negocio cambias los servicio cambian. La administración de este cambio es fundamental para lograr estabilidad en una SOA, de lo contrario tendrá un caos generalizado. Saber qué impacto tendrá el cambio en un servicio proveerá herramientas para coordinar los cambios, proyectar tiempos y costos y ofrecer seguridad al negocio.
Por último, un modelo de madurez para SOA beneficiaría a las empresas que se embarcaron o que piensan adoptar una iniciativa SOA. Les permitiría medirse y plantearse metas de mejoramiento, ubicándose objetivamente en un nivel. Además permitiría tomar decisiones tecnológicas fundamentadas en las capacidades actuales y las capacidades deseadas, podría ayudar a enfocar esfuerzos organizacionales, gerenciales y personales. Organizacionales pues SOA no es solo una iniciativa exclusivamente tecnológica, gerenciales pues requiere un cambio de enfoque en las gerencias de IT y personales porque las personas de TI involucradas en este tipo de proyectos deben capacitarse y cambiar esquemas de pensamiento.
Sobre SOA hay muchísima información, lo gracioso es que se convirtió en un término de mercadeo por lo que la información se convirtió en desinformación. Ahora, existe una tendencia muy interesante hacia la formalización del concepto (aclaro que el concepto no es que sea nuevo, su amplia adopción y soporte por parte de proveedores de tecnología si lo es).
Desde mi punto de vista existen tres puntos débiles de SOA: una metodología de desarrollo orientada a servicios, el control del ciclo de vida de un servicio y la evaluación de la madurez de adopción de SOA en una organización.
Las metodologías de desarrollo son un tema actualmente bien estudiado y documentado. Existen muchas y de muchos sabores, muchas tendencias y hasta “fundamentalismos” como por ejemplo los defensores de “agil” versus los defensores de BUFD (Big Up-Front Design). Leáse Martín Fowler versus Joel Spolsky, por ejemplo.
Las metodologías de desarrollo definen claramente los flujos de trabajo, los responsables, entregables, disciplinas, prácticas y otras cosas, sin embargo, durante el proceso se ignora frecuentemente el tema de servicios, lo que genera aplicaciones un poco monolíticas o si se tiene suerte, el arquitecto del sistema divide el software en componentes. Desafortunadamente un servicio es de grano grueso comparado con un componente; un servicio ejecuta una actividad completa de negocio, a diferencia de un componente que tiene un conjunto de métodos que presta servicios muy específicos, por ejemplo consulta de valores de acciones, conversión de tasa y monedas extranjeras, entre otros. Una metodología que tenga en cuenta la existencia de servicios debería identificarlos como tal y verificar qué servicios existen para ser reutilizados en el proyecto. Algunos pueden pensar que esta es una actividad de arquitectura, pero yo pienso que como los servicios son de nivel de negocio valdría la pena subir esta actividad a nivel de metodología y tenerla en cuenta a través de todo el proceso, inclusive durante el levantamiento de requisitos.
El ciclo de vida de un servicio inicia en su especificación, sigue con su construcción, pruebas, publicación, mantenimiento, reutilización, monitoreo y posiblemente, muerte. No existen herramientas muy populares orientadas facilitar este proceso, existen orientadas a WebServices, sin embargo faltan muchas características importantes. Una de estas características es la matriz de dependencia, es decir, la matriz que indica quien está o han consumido un servicio. Este dato es fundamental para el ciclo de vida del servicio, especialmente durante la fase productiva del servicio. Lo único que es seguro en software es que los requisitos cambiarán, como los requisitos de negocio cambias los servicio cambian. La administración de este cambio es fundamental para lograr estabilidad en una SOA, de lo contrario tendrá un caos generalizado. Saber qué impacto tendrá el cambio en un servicio proveerá herramientas para coordinar los cambios, proyectar tiempos y costos y ofrecer seguridad al negocio.
Por último, un modelo de madurez para SOA beneficiaría a las empresas que se embarcaron o que piensan adoptar una iniciativa SOA. Les permitiría medirse y plantearse metas de mejoramiento, ubicándose objetivamente en un nivel. Además permitiría tomar decisiones tecnológicas fundamentadas en las capacidades actuales y las capacidades deseadas, podría ayudar a enfocar esfuerzos organizacionales, gerenciales y personales. Organizacionales pues SOA no es solo una iniciativa exclusivamente tecnológica, gerenciales pues requiere un cambio de enfoque en las gerencias de IT y personales porque las personas de TI involucradas en este tipo de proyectos deben capacitarse y cambiar esquemas de pensamiento.
martes, diciembre 06, 2005
Business Process Management (BPM) y Business Process Análisis (BPA)
Existe una fuerte tendencia en las grandes empresas a especificar mejor sus procesos de negocio y de apoyo. La idea con esto es lograr mejorar eficiencia, eficacia, manejar indicadores y otra muchas características. Yo creo que el principal beneficio consiste en documentar el conocimiento de la organización y sus mejores prácticas, que sin lugar a duda están en la manera en que funcionan sus procesos. Como respuesta a estas necesidades los proveedores de software han desarrollado productos que se pueden categorizar como BPM y BPA.
Generalmente existen dos fuerzas que inician procesos BPM y BPA, la que yo llamo fuerza hacia arriba se origina en una arquitectura orientada a servicios en la que se tiene la capacidad de componer aplicaciones a partir de servicios. Cuando se logra un nivel de madurez interesante, se empieza a pensar en componer procesos de negocio e incluso, darle al usuario de negocio la capacidad de definir los procesos a partir de servicios existentes. La capacidad más importante de este tipo de aproximación es la automatización, es una solución más orientada a IT que al negocio y la iniciativa generalmente se origina en estas áreas.
Cuando las iniciativas de especificación de procesos se inicia desde el área de negocio, es decir, cuando el enfoque es de arriba hacia abajo, lo que se espera son obtener las caracterizaciones de los procesos, herramientas de modelado de procesos orientadas al usuario del negocio, herramientas de simulación y análisis y en ultima instancia, una posible automatización del proceso.
Creo que hace falta un punto intermedio, pues las herramientas tipo BPM son muy orientadas a IT, mientras que las BPA son muy orientadas a la documentación de los procesos. Una herramienta intermedia permitiría que IT contara con una infraestructura técnica importante para desarrollar una SAO, mientras que los usuarios de negocio podrían diseñar, simular, analizar procesos de negocio, para luego implementarlos con piezas de software reales y con interacción humana donde fuere necesario.
Generalmente existen dos fuerzas que inician procesos BPM y BPA, la que yo llamo fuerza hacia arriba se origina en una arquitectura orientada a servicios en la que se tiene la capacidad de componer aplicaciones a partir de servicios. Cuando se logra un nivel de madurez interesante, se empieza a pensar en componer procesos de negocio e incluso, darle al usuario de negocio la capacidad de definir los procesos a partir de servicios existentes. La capacidad más importante de este tipo de aproximación es la automatización, es una solución más orientada a IT que al negocio y la iniciativa generalmente se origina en estas áreas.
Cuando las iniciativas de especificación de procesos se inicia desde el área de negocio, es decir, cuando el enfoque es de arriba hacia abajo, lo que se espera son obtener las caracterizaciones de los procesos, herramientas de modelado de procesos orientadas al usuario del negocio, herramientas de simulación y análisis y en ultima instancia, una posible automatización del proceso.
Creo que hace falta un punto intermedio, pues las herramientas tipo BPM son muy orientadas a IT, mientras que las BPA son muy orientadas a la documentación de los procesos. Una herramienta intermedia permitiría que IT contara con una infraestructura técnica importante para desarrollar una SAO, mientras que los usuarios de negocio podrían diseñar, simular, analizar procesos de negocio, para luego implementarlos con piezas de software reales y con interacción humana donde fuere necesario.
Suscribirse a:
Entradas (Atom)