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.
lunes, octubre 24, 2005
Ser jefe, Ser Lider IV – Los resultados de mi visión
Después de este mes pasado, en el cual tuve la oportunidad de liderar el equipo de arquitectura, me queda un muy buen sabor, una excelente experiencia y unas buenas relaciones con mis compañeros de trabajo.
Cuando reporté inicialmente esta experiencia aquí en el Día a Día, afirmé que la estrategia para lograr los objetivos consistiría en tres aspectos: lograr resultados verificables, apoyar al equipo por medio de la motivación y mantener una mi visión sólida.
Al cabo de este breve, pero muy enriquecedor lapso, me alegra que hubiera podido mantenerme en esos tres pilares de la siguiente manera:
1. Enfocarme en obtener resultados verificable
Para toda actividad que realizáramos, siempre busqué que existiera un entregable verificable, sea un documento, un producto de software, una reunión, etc. Con estos resultados verificables es más fácil medir el progreso del equipo, lo que mejora el desempeño y la motivación de todos, además, facilita el control de las actividades.
2. Apoyar a mi equipo por medio de la motivación.
Creo que esta estrategia es demasiado amplia, pues motivación es un área grande que puede ser vista desde muchos puntos de vista. Me enfoqué en el reconocimiento y la autogestión.
El reconocimiento lo desarrollé a través de los grupos primarios. En cada una de estas reuniones mencionaba los proyectos que íbamos desarrollando y el estado, haciendo una mención especial de los adelantos sobresalientes de cada miembro del equipo. Esta táctica fue sumamente eficiente para la motivación de un proyecto clave. Además, como efecto colateral se logró mejorar la comunicación y cada miembro del equipo conocía los proyectos y el estado de estos.
La autogestión la entendí como la capacidad que tiene cada uno de los miembros del equipo de planear y ejecutar sus actividades sin requerir gran supervisión. Esta táctica me permitió concentrarme en mis actividades, en la coordinación de los miembros y la gestión de recursos externos, así como la planeación de actividades futuras y la definición de caminos alternativos que facilitaran la llegada a resultados verificables.
3. Mantener una visión sólida
Respecto a este tema es importante mencionar que muchas veces hay que ser terco, pero cuando se presentan argumentos igualmente sólidos hay que reflexionar qué es lo mejor. Reitero mi opinión de no girar como una veleta, pero si estar dispuesto a cambiar siempre que existan argumentos suficientes. La terquedad por terquedad es tan mala como la incapacidad de mantenerse firme en una posición.
Finalmente quiero decir que ver la acción desde este lado de la barrera fue sumamente interesante. Me permitió, por ejemplo, conocer otras facetas de mis compañeros, conocer mejor sus fortalezas y debilidades. De igual manera, me permitió conocer cómo son las relaciones entre los miembros del equipo de ejecutivos y conocerlos en otras facetas. Ahora entiendo parte de sus actitudes, aunque no necesariamente las comparta.
En opinión de mis compañeros, tengo el perfil de líder, yo me siento seguro desarrollando este papel. Espero que pronto pueda desarrollar esta capacidad en un cargo de jefe.
Cuando reporté inicialmente esta experiencia aquí en el Día a Día, afirmé que la estrategia para lograr los objetivos consistiría en tres aspectos: lograr resultados verificables, apoyar al equipo por medio de la motivación y mantener una mi visión sólida.
Al cabo de este breve, pero muy enriquecedor lapso, me alegra que hubiera podido mantenerme en esos tres pilares de la siguiente manera:
1. Enfocarme en obtener resultados verificable
Para toda actividad que realizáramos, siempre busqué que existiera un entregable verificable, sea un documento, un producto de software, una reunión, etc. Con estos resultados verificables es más fácil medir el progreso del equipo, lo que mejora el desempeño y la motivación de todos, además, facilita el control de las actividades.
2. Apoyar a mi equipo por medio de la motivación.
Creo que esta estrategia es demasiado amplia, pues motivación es un área grande que puede ser vista desde muchos puntos de vista. Me enfoqué en el reconocimiento y la autogestión.
El reconocimiento lo desarrollé a través de los grupos primarios. En cada una de estas reuniones mencionaba los proyectos que íbamos desarrollando y el estado, haciendo una mención especial de los adelantos sobresalientes de cada miembro del equipo. Esta táctica fue sumamente eficiente para la motivación de un proyecto clave. Además, como efecto colateral se logró mejorar la comunicación y cada miembro del equipo conocía los proyectos y el estado de estos.
La autogestión la entendí como la capacidad que tiene cada uno de los miembros del equipo de planear y ejecutar sus actividades sin requerir gran supervisión. Esta táctica me permitió concentrarme en mis actividades, en la coordinación de los miembros y la gestión de recursos externos, así como la planeación de actividades futuras y la definición de caminos alternativos que facilitaran la llegada a resultados verificables.
3. Mantener una visión sólida
Respecto a este tema es importante mencionar que muchas veces hay que ser terco, pero cuando se presentan argumentos igualmente sólidos hay que reflexionar qué es lo mejor. Reitero mi opinión de no girar como una veleta, pero si estar dispuesto a cambiar siempre que existan argumentos suficientes. La terquedad por terquedad es tan mala como la incapacidad de mantenerse firme en una posición.
Finalmente quiero decir que ver la acción desde este lado de la barrera fue sumamente interesante. Me permitió, por ejemplo, conocer otras facetas de mis compañeros, conocer mejor sus fortalezas y debilidades. De igual manera, me permitió conocer cómo son las relaciones entre los miembros del equipo de ejecutivos y conocerlos en otras facetas. Ahora entiendo parte de sus actitudes, aunque no necesariamente las comparta.
En opinión de mis compañeros, tengo el perfil de líder, yo me siento seguro desarrollando este papel. Espero que pronto pueda desarrollar esta capacidad en un cargo de jefe.
martes, octubre 18, 2005
Histórico Concierto de Juanes en Medellín
El domingo 16 de octubre ocurrió un evento inolvidable para la cuidad de Medellín. Un concierto multitudinario realizado en plena Calle San Juan, con más de 100.000 espectadores y 5 bandas en concierto.
Como prefacio al cumpleaños 330 de la cuidad de Medellín, que dicho sea de paso es el 2 de noviembre, la alcaldía de Medellín, encabezada por el alcalde Sergio Fajardo y Juanes (Juan Esteban Aristizabal), le regalaron a Medellín un espectáculo lleno de música, de paz de esperanza y de agua.
Conseguir las boletas fue más o menos una odiosea, realmente no teníamos tiempo para ir a un CERCA y luego ir a La Alpujarra a reclamar un par de boletas, de manera que nos valimos de mi hermano y de una tía de mi esposa para que nos consiguieran un par de boletas. Como siempre, en eventos públicos, se arma una mafiecilla de intereses, para poder obtener las cosas se debe conocer a las personas correctas. Yo creo que eso pasa aquí en Medellín, aquí en Colombia, aquí en Suramérica, aquí en la tierra. Este tipo de comportamiento es inevitable en una sociedad numerosa y organizada.
Llegamos al sitio del concierto a las 15:30. El lugar no podría ser más simbólico. El corazón administrativo de la ciudad de Medellín y del departamento de Antioquia, es decir, lo que nosotros conocemos como La Alpujarra. Cerca de la alpujarra se encuentran: el edificio inteligente de EEPPM, el Parque de los Pies Descalzos, el Museo Interactivo de EEPPM, el Parque de la Luz, el Concejo de Medellín, la Alcaldía de Medellín, los despachos judiciales, la Gobernación de Antioquia, en fin, es el centro neurálgico de la administración pública de nuestra región.
Sobre toda la avenida San Juan, y justo después del deprimido, entre la carrera Carabobo y la Avenida del Ferrocarril, montaron una tarima enorme con pantallas gigantes y no se cuantos miles de vatios de potencia. Como el espacio del concierto era tan grande instalaron tres tarimas más con amplificación y pantallas gigante, que permitían que todos, hasta los últimos en llegar (como mi esposa y yo) disfrutáramos de un buen sonido y de la imagen de los artistas sobre el escenario.
El primero en aparecer fue el grupo Entre Tres, que a mi parecer no estuvo muy bien, pues sus canciones no era muy conocida, además el sonido no les funcionó también como esperábamos.
A continuación se presentó el maestro Octavio Mesa, un representante de la música guasca antioqueña. Esta música, aunque autóctona y muy popular, no es que disfrute mucho. El sonido tampoco fue un éxito y el maestro se quejaba de falta de retorno hasta el final. De todas manera fue un tanto emocionante porque Octavio Mesa es el elemento que articula el folclor antioqueño con la música moderna de Juanes.
La lluvia empezó a caer y compramos el par de bolsas plásticas más caras de nuestras vidas, dos medias bolsas por dos mil pesos. Además, esperábamos que las bolsas tuvieran forma de abrigo, pero no eran más que bolsas cortadas en dos. En fin...
Luego de esperar otro rato empezó a calentarse el ambiente con la buena música de Coffe Makers, una mezcla de Reggae y Ska muy agradable y entretenida. Tienen un par de canciones pegadas en la radio que alcanzamos a tararear y a disfrutar de verdad.
Aparecieron en escena, a eso de las 18:00 Tres de Corazón, una excelente banda local de Neo Punk. Con esta banda se prendieron los motores y el público realmente empezó a disfrutar de la fiesta. Mi esposa y yo empezamos a bailar y a brincar al ritmo de sus letras (cien por ciento, entre otras).
Después de una larga espera y con una incipiente lluvia, subió al escenario “El Patrón”, como lo llamaron los integrantes de Tres de Corazón. Juanes desplegó un espectáculo de luces, sonido y energía deslumbrante, que a pesar de la torrencial lluvia logró mover a 100.000 espectadores y calentar el ambiente de la fría noche. Una tras otra, sus canciones fueron coreadas, bailadas, saltadas y disfrutadas por toda la multitud, desde la humilde niña de La Sierra, hasta el hijo del político más importante de Antioquia.
A las 9:00 parecía terminado el concierto y la lluvia inclemente terminaba de enfriar el ambiente. Sin embargo, la multitud clamorosa aclamaba por una canción más: otra, otra, otra, otra. Después de cinco minutos de oscuridad en el escenario se presentó nuevamente Juanes y después de dedicarle una canción a su madre, aprovechó para grabar el video de su canción “Para Tu Amor”. El espectáculo de la gente registrado en el video seguramente será conmovedor, lástima que en el estribillo la gente no hubiera estado tan preparada como lo esperaba la producción del video.
Siguieron varias canciones más de su más reciente grabación “Mi Sangre” y, para mí, el momento del éxtasis se dio cuando entonó un himno de nuestra generación “Solo”. Un clásico del rock antioqueño que identifica a la generación X y que siempre, donde suena, es coreado y disfrutado.
El concierto finalizó cuando Juanes invitó al escenario a sus amigos: Mauricio “El Chicho” Serna, Víctor Hugo Aristizabal, el alcalde Sergio Fajardo y otros tanto que no logré reconocer ni por el noticiero. Junto con ellos y con la fuerza de 100.000 almas se entonó el himno de esta tierra, el himno Antioqueño, toda una joya para cerrar este espectáculo de paz, convivencia, tolerancia.
Gracias Juanes por este regalo a tu cuidad, gracias al Alcalde por la voluntad política para hacer cosas grandes y gracias a toda la gente de Medellín por disfrutar un espectáculo memorable e irrepetible.
Como prefacio al cumpleaños 330 de la cuidad de Medellín, que dicho sea de paso es el 2 de noviembre, la alcaldía de Medellín, encabezada por el alcalde Sergio Fajardo y Juanes (Juan Esteban Aristizabal), le regalaron a Medellín un espectáculo lleno de música, de paz de esperanza y de agua.
Conseguir las boletas fue más o menos una odiosea, realmente no teníamos tiempo para ir a un CERCA y luego ir a La Alpujarra a reclamar un par de boletas, de manera que nos valimos de mi hermano y de una tía de mi esposa para que nos consiguieran un par de boletas. Como siempre, en eventos públicos, se arma una mafiecilla de intereses, para poder obtener las cosas se debe conocer a las personas correctas. Yo creo que eso pasa aquí en Medellín, aquí en Colombia, aquí en Suramérica, aquí en la tierra. Este tipo de comportamiento es inevitable en una sociedad numerosa y organizada.
Llegamos al sitio del concierto a las 15:30. El lugar no podría ser más simbólico. El corazón administrativo de la ciudad de Medellín y del departamento de Antioquia, es decir, lo que nosotros conocemos como La Alpujarra. Cerca de la alpujarra se encuentran: el edificio inteligente de EEPPM, el Parque de los Pies Descalzos, el Museo Interactivo de EEPPM, el Parque de la Luz, el Concejo de Medellín, la Alcaldía de Medellín, los despachos judiciales, la Gobernación de Antioquia, en fin, es el centro neurálgico de la administración pública de nuestra región.
Sobre toda la avenida San Juan, y justo después del deprimido, entre la carrera Carabobo y la Avenida del Ferrocarril, montaron una tarima enorme con pantallas gigantes y no se cuantos miles de vatios de potencia. Como el espacio del concierto era tan grande instalaron tres tarimas más con amplificación y pantallas gigante, que permitían que todos, hasta los últimos en llegar (como mi esposa y yo) disfrutáramos de un buen sonido y de la imagen de los artistas sobre el escenario.
El primero en aparecer fue el grupo Entre Tres, que a mi parecer no estuvo muy bien, pues sus canciones no era muy conocida, además el sonido no les funcionó también como esperábamos.
A continuación se presentó el maestro Octavio Mesa, un representante de la música guasca antioqueña. Esta música, aunque autóctona y muy popular, no es que disfrute mucho. El sonido tampoco fue un éxito y el maestro se quejaba de falta de retorno hasta el final. De todas manera fue un tanto emocionante porque Octavio Mesa es el elemento que articula el folclor antioqueño con la música moderna de Juanes.
La lluvia empezó a caer y compramos el par de bolsas plásticas más caras de nuestras vidas, dos medias bolsas por dos mil pesos. Además, esperábamos que las bolsas tuvieran forma de abrigo, pero no eran más que bolsas cortadas en dos. En fin...
Luego de esperar otro rato empezó a calentarse el ambiente con la buena música de Coffe Makers, una mezcla de Reggae y Ska muy agradable y entretenida. Tienen un par de canciones pegadas en la radio que alcanzamos a tararear y a disfrutar de verdad.
Aparecieron en escena, a eso de las 18:00 Tres de Corazón, una excelente banda local de Neo Punk. Con esta banda se prendieron los motores y el público realmente empezó a disfrutar de la fiesta. Mi esposa y yo empezamos a bailar y a brincar al ritmo de sus letras (cien por ciento, entre otras).
Después de una larga espera y con una incipiente lluvia, subió al escenario “El Patrón”, como lo llamaron los integrantes de Tres de Corazón. Juanes desplegó un espectáculo de luces, sonido y energía deslumbrante, que a pesar de la torrencial lluvia logró mover a 100.000 espectadores y calentar el ambiente de la fría noche. Una tras otra, sus canciones fueron coreadas, bailadas, saltadas y disfrutadas por toda la multitud, desde la humilde niña de La Sierra, hasta el hijo del político más importante de Antioquia.
A las 9:00 parecía terminado el concierto y la lluvia inclemente terminaba de enfriar el ambiente. Sin embargo, la multitud clamorosa aclamaba por una canción más: otra, otra, otra, otra. Después de cinco minutos de oscuridad en el escenario se presentó nuevamente Juanes y después de dedicarle una canción a su madre, aprovechó para grabar el video de su canción “Para Tu Amor”. El espectáculo de la gente registrado en el video seguramente será conmovedor, lástima que en el estribillo la gente no hubiera estado tan preparada como lo esperaba la producción del video.
Siguieron varias canciones más de su más reciente grabación “Mi Sangre” y, para mí, el momento del éxtasis se dio cuando entonó un himno de nuestra generación “Solo”. Un clásico del rock antioqueño que identifica a la generación X y que siempre, donde suena, es coreado y disfrutado.
El concierto finalizó cuando Juanes invitó al escenario a sus amigos: Mauricio “El Chicho” Serna, Víctor Hugo Aristizabal, el alcalde Sergio Fajardo y otros tanto que no logré reconocer ni por el noticiero. Junto con ellos y con la fuerza de 100.000 almas se entonó el himno de esta tierra, el himno Antioqueño, toda una joya para cerrar este espectáculo de paz, convivencia, tolerancia.
Gracias Juanes por este regalo a tu cuidad, gracias al Alcalde por la voluntad política para hacer cosas grandes y gracias a toda la gente de Medellín por disfrutar un espectáculo memorable e irrepetible.
lunes, octubre 10, 2005
Conclusiones XXV Salón de Informática ACIS 2005
Pretendía relatar todo el evento de ACIS, sin embargo, creo que sería demasiado largo para el blog, y si alguien está interesado pues no creo que esté dispuesto a leer más de dos páginas sobre el tema. Por ello he decidido sintetizar todo el evento en las siguientes observaciones:
En el país se tiene cierta claridad sobre el rol del arquitecto de software. El sector académico tiene una definición más o menos formal mientras que el sector empresarial trata de hacer énfasis en una definición práctica.
Falta claridad sobre los niveles de los arquitectos de software, yo los clasifico en dos (y esta definición ya la he validado con varios colegas): el arquitecto empresarial y el arquitecto de soluciones. El primero se materializa en las empresas como Gerente de Tecnología de Información, es responsable de entender la estrategia del negocio y plantear una estrategia de TI acorde y que apalanque la visión del negocio. De otro lado el arquitecto de soluciones es un perfil un poco más técnico y orientado a proporcionar soluciones concretas.
Los proveedores de tecnología están concentrados en ofrecer soluciones de integración, ahora no se llaman EAI sino ESB. La idea es facilitar la integración de aplicaciones y procesos utilizando una middleware de integración. La piedra angular de esta estrategia es SOA.
SOA no es una tendencia pasajera, es una solución para los problemas concretos de muchas organizaciones. Es una arquitectura que irá evolucionando y que facilitará el mantenimiento de las aplicaciones. SOA plantea muchos retos, por ejemplo una metodología de desarrollo orientada a servicios, una metodología de administración del ciclo de desarrollo de servicios, una framework de pruebas y de administración de dependencias, entre otros.
Aunque existen visiones optimistas respecto al rol del arquitecto, existen visiones fundamentalmente negativas fundamentadas en la complejidad del trabajo. El argumento de los “complejistas”, como yo los he llamado, se basa en la idea que no existen fórmulas o soluciones preconstruidas para problemas realmente complejos, del tipo sistemas de mil casos de uso. El argumento en contra indica que ya existen muchas “buenas prácticas”, patrones en varios niveles (de codificación, de diseño, de arquitectura, empresariales) bien conocidos y comprobados, así como técnicas que mitigan muchos de los riesgos de los sistemas complejos. Los “complejistas” afirman que la única herramienta que mitiga el riesgo afrontado por un arquitecto es la experiencia. Creo que aquí falta dividir el problema para no enredarse demasiado.
Fue realmente una grata sorpresa conocer a personas que tienen conocimientos y experiencias sólidas en arquitectura de software. Se puede afirmar que en el país existe una fuerte base que seguramente facilitará el desarrollo de la industria de software, permitiendo afrontar o asimilar la competencia india y china.
Queda por definir si los chinos e indios serán aliados o competidores. Habrá que alinear la industria de software colombiana, a través de agremiaciones y posibles fusiones de empresas fuertes, de manera que se pueda enfrentar al músculo humano y financiero de las empresas de software extranjeras.
Lastimosamente no llevé mi cámara, por lo que tendré que esperar a que ACIS publique alguna foto del evento.
Estas son las conclusiones más importantes del evento. Para más información se puede referir a http://www.acis.org.co
En el país se tiene cierta claridad sobre el rol del arquitecto de software. El sector académico tiene una definición más o menos formal mientras que el sector empresarial trata de hacer énfasis en una definición práctica.
Falta claridad sobre los niveles de los arquitectos de software, yo los clasifico en dos (y esta definición ya la he validado con varios colegas): el arquitecto empresarial y el arquitecto de soluciones. El primero se materializa en las empresas como Gerente de Tecnología de Información, es responsable de entender la estrategia del negocio y plantear una estrategia de TI acorde y que apalanque la visión del negocio. De otro lado el arquitecto de soluciones es un perfil un poco más técnico y orientado a proporcionar soluciones concretas.
Los proveedores de tecnología están concentrados en ofrecer soluciones de integración, ahora no se llaman EAI sino ESB. La idea es facilitar la integración de aplicaciones y procesos utilizando una middleware de integración. La piedra angular de esta estrategia es SOA.
SOA no es una tendencia pasajera, es una solución para los problemas concretos de muchas organizaciones. Es una arquitectura que irá evolucionando y que facilitará el mantenimiento de las aplicaciones. SOA plantea muchos retos, por ejemplo una metodología de desarrollo orientada a servicios, una metodología de administración del ciclo de desarrollo de servicios, una framework de pruebas y de administración de dependencias, entre otros.
Aunque existen visiones optimistas respecto al rol del arquitecto, existen visiones fundamentalmente negativas fundamentadas en la complejidad del trabajo. El argumento de los “complejistas”, como yo los he llamado, se basa en la idea que no existen fórmulas o soluciones preconstruidas para problemas realmente complejos, del tipo sistemas de mil casos de uso. El argumento en contra indica que ya existen muchas “buenas prácticas”, patrones en varios niveles (de codificación, de diseño, de arquitectura, empresariales) bien conocidos y comprobados, así como técnicas que mitigan muchos de los riesgos de los sistemas complejos. Los “complejistas” afirman que la única herramienta que mitiga el riesgo afrontado por un arquitecto es la experiencia. Creo que aquí falta dividir el problema para no enredarse demasiado.
Fue realmente una grata sorpresa conocer a personas que tienen conocimientos y experiencias sólidas en arquitectura de software. Se puede afirmar que en el país existe una fuerte base que seguramente facilitará el desarrollo de la industria de software, permitiendo afrontar o asimilar la competencia india y china.
Queda por definir si los chinos e indios serán aliados o competidores. Habrá que alinear la industria de software colombiana, a través de agremiaciones y posibles fusiones de empresas fuertes, de manera que se pueda enfrentar al músculo humano y financiero de las empresas de software extranjeras.
Lastimosamente no llevé mi cámara, por lo que tendré que esperar a que ACIS publique alguna foto del evento.
Estas son las conclusiones más importantes del evento. Para más información se puede referir a http://www.acis.org.co
jueves, septiembre 29, 2005
XXV Salón de informática ACIS - Día 1
Llegué el día 28 las diez de la noche. Tomé un taxi directo al hotel, el Hotel Tequendama. Me habían hablado de este hotel, pues es, supuestamente donde se alojan presidentes y personajes importantes de la vida nacional.
La estada fue bastante normal, el hotel es clásico y bastante pretencioso, sin embargo las cosas se ven un poco viejas, por ejemplo los teléfonos, los ascensores, los radios, etc... La atención en el lobby fue bastante regular y ni siquiera el botones se ofreció a subir la maleta a mi habitación, así que lo hice yo.
Me acosté a las once de la noche y me desperté a las 7:30, así que sabía de antemano que llegaría un poco tarde a la primera sesión. Me arreglé rápidamente, bajé a desayunar al restaurante “El Virrey”. El restaurante es elegante, pero el buffet me pareció bastante regular, nuevamente comparando con mi experiencia en el Bogotá Plaza y el Hotel La Fontana. Al salir no me ofrecieron un taxi, así que tomé cualquiera de la calle.
El trayecto del hotel a la biblioteca Luis Ángel Arango es bastante corto, tomó unos 10 minutos, pero sobre todo, por el tráfico de la capital. El sector en el que se encuentra la biblioteca es bastante histórico, cerca se encuentran el museo del oro, la casa de la moneda, el palacio de justicia y el congreso de la república.
La biblioteca es enorme, muy bien organizado y con muchísimos auditorios. Finalmente y después de atravesar un laberinto sin señalización alguna, logré llegar al sitio del evento.
Me recibió una joven que luego me remitió a su compañero, este me pregunto mi nombre, a los que le respondí y además le entregué la invitación que me habían enviado por correo. Buscó en la lista y no me encontró, por lo que me dio una escarapela temporal de Hewllet Packard y un bonito portafolio de cuero negro, con las memorias, un block y un lapicero para tomar notas y el programa del evento.
Saludé a Jorge Arias, me dio la bienvenida y me indicó donde sentarme, pues en la parte delantera, en el costado izquierdo había gente de Medellín. Yo la verdad, no conocía a nadie.
La conferencia empezó con el “keynote” (ahora el término parece estar de moda) de los codirectores del evento Jorge Arias y Juan Carlos Cárdenas. Se centró en la definición académica de arquitecto y arquitectura. Lo más destacable de las presentaciones fue el enfoque que ellos definen del arquitecto y de la arquitectura: el arquitecto debe definir una arquitectura que satisfaga las necesidades de los clientes. Hablaron de la importancia de determinar cómo estaba posicionada una solución de software dentro de la cadena de valor del negocio y de la necesidad de estar alineada con la visión empresarial. Además, se mencionaron algunos frameworks de arquitectura como el de Zackman y eTOM, entre otros. Lo fundamental de los frameworks es que son guías para dimensionar problemas de negocio a través de diferentes perspectivas.
Me quedaron las siguientes dudas: ¿Acaso el arquitecto será capaz de dominar el negocio? ¿Acaso el arquitecto tendrá que ser un colectivo, es decir, un grupo de personas con conocimientos en varias áreas y con una visión integral del problema?
La presentación de Jorge Arias me pareció bastante aterrizada, mientras que la de Juan Carlos Cárdenas un poco abstracta y algo difícil de aterrizar a la realidad.
Seguidamente, Mauricio Álvarez, con la camiseta de Microsoft puesta (literalmente) hizo una presentación bastante amena y práctica. Sin embargo es la misma temática a la que estoy acostumbrado en los eventos de Microsoft, especialmente en el consejo de arquitectos en Medellín. Una de las frases más valiosas fue la relacionada con la sinergia: “La suma de las partes es mayor que las partes individuales”. No es que no la conociera, es que se puede obtener un corolarios: “La suma de unas partes es diferente a la suma de otras partes similares”. Con esto quiero decir que los modelos de arquitectura no funcionan igual en diferentes grupos, por lo que no existe una solución única y verdadera para todos los casos. Esto me hace pensar en las posibles fallas que pueda tener el modelo tecnológico que Suramericana podría compartir con sus aliados de negocio. Otra frase importante que refuerza el mensaje de la conferencia anterior fue que el punto de partida para una SOA no es la tecnología, es la definición de los procesos de negocio. Además mencionó unas reglas interesantes para una SOA: (1) los límites son explícitos (2) los servicios son autónomos (3) los servicios comparten esquemas y contratos, no clases (4) la compatibilidad de los servicios se logra si y solo si cumple con las mismas políticas. Además mencionó la necesidad de una metodología de análisis orientado a servicios.
Continuó Jaime Moreno. Este personaje presentó todo el proceso que habilitó a la Cámara de Comercio de Bogotá para definir una SOA. Fue muy interesante porque ofreció una visión desde el punto de vista empresarial, en donde realizaron un proceso riguroso y muy completo de definición de procesos y después de terminarlo definieron los servicios que debían ser implementados por medio de tecnología y que agregarían un gran valor al negocio. Le hice tres preguntas: ¿Qué experiencia tuvieron con la interoperabilidad entre servicios desarrollados en diferentes plataformas?¿Cómo medir los resultados en una organización matricial, por ejemplo, los resultados del oficial de seguridad? ¿Cómo resolvieron el problema de dependencia entre aplicaciones y servicios durante las pruebas de desarrollo y pruebas funcionales, especialmente en lo que tiene que ver con estabilidad del ambiente? Desafortunadamente no encontré respuestas satisfactorias. Me ofreció darme su tarjeta, lo cual le solicité durante el brake. No se ofreció a responderlas, trataré de contactarlo más adelante para ver si puedo obtener mejores respuestas.
Edgar, Andrés y yo fuimos a dar una vuelta cerca, pues inició la hora del almuerzo. Dimos una vuelta y me impresioné gratamente con los edificios, las construcciones, las calles. Esta parte de la cuidad es realmente bonito y tiene un estilo marcadamente europeo. Almorzamos en un restaurante argentino muy bonito y con muy buena comida, muy cerca de la biblioteca.
Al regresar asistí a la charla de Jitedra Pudri, la cual fue bastante jocosa, pero tan jocosa como poco interesante. Tal vez por la dificultad que tenía el expositor con el español o tal vez por la preparación de la presentación. Las ideas más interesantes fueron las siguientes: Tendencia a la simplificación, tendencia a la modularización, adaptitive business como modelo de madurez de una organización o departamento de IT. Además mencionó el white paper de Harvard Business Review, el que se refería al City Planning, que el fundamente para el equipo de arquitectura de Suramericana.
Después de Jitedra Pudri, continuó Raquel Anaya. Una presentación muy interesante pero bastante académica que mis compañeros criticaron mucho por su practicidad, no por su contenido per se. Hablo nuevamente de la idea del rol del arquitecto como factor equilibrante y mediador entre el negocio e IT. Mencionó el tema de tácticas de arquitectura, que me parece muy interesante, habló de ADL, MDA y por supuesto, el infaltable UML como lenguaje para todos nuestros problemas.
Nuevamente de vuelta al hotel, con un frío penetrante y después de saludar a un amigo que trabaja como consultar de SAP. Me fui caminando del parque central Bavaria hasta el hotel. Me perdí un poco pero llegué sin problemas.
Tengo que resaltar que el servicio de Internet aquí en hotel es bastante regular, pues los computadores son incómodos, aunque muy modernos y solo venden tarjetas de media hora y un día. Muy caras y poco prácticas.
Eso es todo por el día de hoy.
La estada fue bastante normal, el hotel es clásico y bastante pretencioso, sin embargo las cosas se ven un poco viejas, por ejemplo los teléfonos, los ascensores, los radios, etc... La atención en el lobby fue bastante regular y ni siquiera el botones se ofreció a subir la maleta a mi habitación, así que lo hice yo.
Me acosté a las once de la noche y me desperté a las 7:30, así que sabía de antemano que llegaría un poco tarde a la primera sesión. Me arreglé rápidamente, bajé a desayunar al restaurante “El Virrey”. El restaurante es elegante, pero el buffet me pareció bastante regular, nuevamente comparando con mi experiencia en el Bogotá Plaza y el Hotel La Fontana. Al salir no me ofrecieron un taxi, así que tomé cualquiera de la calle.
El trayecto del hotel a la biblioteca Luis Ángel Arango es bastante corto, tomó unos 10 minutos, pero sobre todo, por el tráfico de la capital. El sector en el que se encuentra la biblioteca es bastante histórico, cerca se encuentran el museo del oro, la casa de la moneda, el palacio de justicia y el congreso de la república.
La biblioteca es enorme, muy bien organizado y con muchísimos auditorios. Finalmente y después de atravesar un laberinto sin señalización alguna, logré llegar al sitio del evento.
Me recibió una joven que luego me remitió a su compañero, este me pregunto mi nombre, a los que le respondí y además le entregué la invitación que me habían enviado por correo. Buscó en la lista y no me encontró, por lo que me dio una escarapela temporal de Hewllet Packard y un bonito portafolio de cuero negro, con las memorias, un block y un lapicero para tomar notas y el programa del evento.
Saludé a Jorge Arias, me dio la bienvenida y me indicó donde sentarme, pues en la parte delantera, en el costado izquierdo había gente de Medellín. Yo la verdad, no conocía a nadie.
La conferencia empezó con el “keynote” (ahora el término parece estar de moda) de los codirectores del evento Jorge Arias y Juan Carlos Cárdenas. Se centró en la definición académica de arquitecto y arquitectura. Lo más destacable de las presentaciones fue el enfoque que ellos definen del arquitecto y de la arquitectura: el arquitecto debe definir una arquitectura que satisfaga las necesidades de los clientes. Hablaron de la importancia de determinar cómo estaba posicionada una solución de software dentro de la cadena de valor del negocio y de la necesidad de estar alineada con la visión empresarial. Además, se mencionaron algunos frameworks de arquitectura como el de Zackman y eTOM, entre otros. Lo fundamental de los frameworks es que son guías para dimensionar problemas de negocio a través de diferentes perspectivas.
Me quedaron las siguientes dudas: ¿Acaso el arquitecto será capaz de dominar el negocio? ¿Acaso el arquitecto tendrá que ser un colectivo, es decir, un grupo de personas con conocimientos en varias áreas y con una visión integral del problema?
La presentación de Jorge Arias me pareció bastante aterrizada, mientras que la de Juan Carlos Cárdenas un poco abstracta y algo difícil de aterrizar a la realidad.
Seguidamente, Mauricio Álvarez, con la camiseta de Microsoft puesta (literalmente) hizo una presentación bastante amena y práctica. Sin embargo es la misma temática a la que estoy acostumbrado en los eventos de Microsoft, especialmente en el consejo de arquitectos en Medellín. Una de las frases más valiosas fue la relacionada con la sinergia: “La suma de las partes es mayor que las partes individuales”. No es que no la conociera, es que se puede obtener un corolarios: “La suma de unas partes es diferente a la suma de otras partes similares”. Con esto quiero decir que los modelos de arquitectura no funcionan igual en diferentes grupos, por lo que no existe una solución única y verdadera para todos los casos. Esto me hace pensar en las posibles fallas que pueda tener el modelo tecnológico que Suramericana podría compartir con sus aliados de negocio. Otra frase importante que refuerza el mensaje de la conferencia anterior fue que el punto de partida para una SOA no es la tecnología, es la definición de los procesos de negocio. Además mencionó unas reglas interesantes para una SOA: (1) los límites son explícitos (2) los servicios son autónomos (3) los servicios comparten esquemas y contratos, no clases (4) la compatibilidad de los servicios se logra si y solo si cumple con las mismas políticas. Además mencionó la necesidad de una metodología de análisis orientado a servicios.
Continuó Jaime Moreno. Este personaje presentó todo el proceso que habilitó a la Cámara de Comercio de Bogotá para definir una SOA. Fue muy interesante porque ofreció una visión desde el punto de vista empresarial, en donde realizaron un proceso riguroso y muy completo de definición de procesos y después de terminarlo definieron los servicios que debían ser implementados por medio de tecnología y que agregarían un gran valor al negocio. Le hice tres preguntas: ¿Qué experiencia tuvieron con la interoperabilidad entre servicios desarrollados en diferentes plataformas?¿Cómo medir los resultados en una organización matricial, por ejemplo, los resultados del oficial de seguridad? ¿Cómo resolvieron el problema de dependencia entre aplicaciones y servicios durante las pruebas de desarrollo y pruebas funcionales, especialmente en lo que tiene que ver con estabilidad del ambiente? Desafortunadamente no encontré respuestas satisfactorias. Me ofreció darme su tarjeta, lo cual le solicité durante el brake. No se ofreció a responderlas, trataré de contactarlo más adelante para ver si puedo obtener mejores respuestas.
Edgar, Andrés y yo fuimos a dar una vuelta cerca, pues inició la hora del almuerzo. Dimos una vuelta y me impresioné gratamente con los edificios, las construcciones, las calles. Esta parte de la cuidad es realmente bonito y tiene un estilo marcadamente europeo. Almorzamos en un restaurante argentino muy bonito y con muy buena comida, muy cerca de la biblioteca.
Al regresar asistí a la charla de Jitedra Pudri, la cual fue bastante jocosa, pero tan jocosa como poco interesante. Tal vez por la dificultad que tenía el expositor con el español o tal vez por la preparación de la presentación. Las ideas más interesantes fueron las siguientes: Tendencia a la simplificación, tendencia a la modularización, adaptitive business como modelo de madurez de una organización o departamento de IT. Además mencionó el white paper de Harvard Business Review, el que se refería al City Planning, que el fundamente para el equipo de arquitectura de Suramericana.
Después de Jitedra Pudri, continuó Raquel Anaya. Una presentación muy interesante pero bastante académica que mis compañeros criticaron mucho por su practicidad, no por su contenido per se. Hablo nuevamente de la idea del rol del arquitecto como factor equilibrante y mediador entre el negocio e IT. Mencionó el tema de tácticas de arquitectura, que me parece muy interesante, habló de ADL, MDA y por supuesto, el infaltable UML como lenguaje para todos nuestros problemas.
Nuevamente de vuelta al hotel, con un frío penetrante y después de saludar a un amigo que trabaja como consultar de SAP. Me fui caminando del parque central Bavaria hasta el hotel. Me perdí un poco pero llegué sin problemas.
Tengo que resaltar que el servicio de Internet aquí en hotel es bastante regular, pues los computadores son incómodos, aunque muy modernos y solo venden tarjetas de media hora y un día. Muy caras y poco prácticas.
Eso es todo por el día de hoy.
viernes, septiembre 23, 2005
Ser jefe, ser líder III - De la teoría a la práctica
Ya he escrito un poco sobre mis observaciones respecto a ser líder y ser jefe (aquí y aquí). Ahora es mi turno de aplicar lo que he predicado. Tengo una oportunidad de cuatro semanas para experimentar lo que es ser jefe de un equipo de arquitectura. Tengo tres objetivos principales:
1. Enfocarme en obtener resultados verificables
2. Apoyar a mi equipo por medio de la motivación
3. Mantener una visión sólida
Con el primer objetivo pretendo lograr enfocar los esfuerzos, me refiero a que cuando no se tienen resultados verificables generalmente no se obtiene motivación tras completar una tarea. Además, en general, siempre se mide el desempeño de un jefe de equipo en términos de los resultados de su labor. Cuando un técnico de un equipo de fútbol no gana, lo cambian; cuando un alcalde no cumple con su programa, baja su popularidad; cuando un jefe de proyecto no logra un producto con las restricciones de los clientes, le es difícil liderar nuevos proyectos retadores
El segundo objetivo es muy importante para mi situación. Como no tengo mucha experiencia en el entorno en el que me desarrollo desde el punto de vista de “jefe”, necesito que las personas con que trabajo se encuentren motivadas para que desarrollen sus actividades eficientemente y pueda delegar muchas funciones con tranquilidad. Además, con la motivación podremos lograr mejores resultados.
Para mantener la motivación y para lograr resultados se necesita tener un visión clara del sueño que se quiere alcanzar, a pesar de los sutiles variaciones en las condiciones. Por ello se debe mantener una visión firme; es mejor tener un objetivo bien definido que ser como una veleta que cambia de dirección con la más mínima brisa.
Estaré reportando mis experiencias con la convicción de que haré una buena labor y que aprenderé mucho asumiendo el trabajo desde otro punto de vista.
1. Enfocarme en obtener resultados verificables
2. Apoyar a mi equipo por medio de la motivación
3. Mantener una visión sólida
Con el primer objetivo pretendo lograr enfocar los esfuerzos, me refiero a que cuando no se tienen resultados verificables generalmente no se obtiene motivación tras completar una tarea. Además, en general, siempre se mide el desempeño de un jefe de equipo en términos de los resultados de su labor. Cuando un técnico de un equipo de fútbol no gana, lo cambian; cuando un alcalde no cumple con su programa, baja su popularidad; cuando un jefe de proyecto no logra un producto con las restricciones de los clientes, le es difícil liderar nuevos proyectos retadores
El segundo objetivo es muy importante para mi situación. Como no tengo mucha experiencia en el entorno en el que me desarrollo desde el punto de vista de “jefe”, necesito que las personas con que trabajo se encuentren motivadas para que desarrollen sus actividades eficientemente y pueda delegar muchas funciones con tranquilidad. Además, con la motivación podremos lograr mejores resultados.
Para mantener la motivación y para lograr resultados se necesita tener un visión clara del sueño que se quiere alcanzar, a pesar de los sutiles variaciones en las condiciones. Por ello se debe mantener una visión firme; es mejor tener un objetivo bien definido que ser como una veleta que cambia de dirección con la más mínima brisa.
Estaré reportando mis experiencias con la convicción de que haré una buena labor y que aprenderé mucho asumiendo el trabajo desde otro punto de vista.
jueves, septiembre 08, 2005
Cuál es la diferencia entre un objetivo y un requisito?
Introducción
En el contexto de elicitación de requisitos es importante poder definir claramente los objetivos y los requisitos del sistema. Generalmente los objetivos provienen de la visión y a su vez los requisitos provienen de los objetivos.
Los Objetivos y los Requisitos
Los objetivos son requisitos de alto nivel que el sistema debe cumplir para satisfacer necesidades de negocio. Para indagar sobre los objetivos se deben hacer preguntas de este tipo:
¿Por qué se construye el sistema?
¿Qué beneficios espera del nuevo sistema?
¿Cómo se podría determinar que el nuevo sistema será exitoso?
Este tipo de pregunta permite que tanto clientes como usuarios identifiquen los objetivos del sistema en términos de negocio y no en términos de la solución.
Los requisitos son especificaciones de las características que el sistema debe tener para cumplir con esos objetivos, particular son:
· Una condición o capacidad que un usuario necesita para solucionar un problema
· Una condición o capacidad que debe tener un sistema o componente para satisfacer un contrato, una norma, una especificación u otro documento formal
Conclusión
Un objetivo está orientado a determinar los puntos que permitirán evaluar si el sistema será exitoso
Un requisitos es una condición o capacidad que un usuario necesita para solucionar un problema
Referencias
[Brooks 1995] F. P. Brooks, Jr. The Mythical Man-Month: Essays on Software Engineering Anniversary Edition. Addison-Wesley, 1995.
[Christel y Kang 1992] M. G. Christel y K. C. Kang. Issues in Requirements Elicitation. Technical Report CMU/SEI-92-TR-12, Software Engineering Institute, Carnegie Mellon University, 1992. Disponible en http://www.sei.cmu.edu .
[Davis 1990] A. M. Davis. The Analysis and Specification of Systems and Software Requirements. En Thayer y Dorfman [1990], páginas 119-144.
[Davis 1993] A. M. Davis. Software Requirements: Objects, Functions and States. Prentice-Hall, 2 a edición, 1993.
[DoD 1994] DoD. Military Standard 498: Software Development and Documentation. Departament of Defense of the United States of America, 1994. Disponible en. mil/mil std/498 win3.exe .
[Durán 2000] Durán, Amador. Un Entorno metodológico de Ingeniería de requisitos para Sistemas de Información. Tesis Doctoral. Sept. 2000.
[ESP 1996] ESPITI - European User Survey Results. Informe Técnico ESI-1996-TR95104, European Software Institute, 1996. Disponible en http://www.esi.es
[GAO 1979] Contracting for Computer Software Development: Serious Problems Require Management Attention to Avoid Wasting Additional Millions. Report FGMSD-80-4, U. S. Government Account Office, Noviembre 1979. Este documento es difícil de encontrar, pero está comentado y referenciado, entre otros, en [Davis 1993], [Christel y Kang 1992] y [Goguen 1994].
[Gause y Weinberg 1989] D. C. Gause y G. M. Weinberg. Exploring Requirements: Quality Before Design. Dorset House, 1989.
[Goguen 1994] J. A. Goguen. Requirements Engineering as the Reconciliation of Social and Technical Issues. En Requirements Engineering: Social and Technical Issues, páginas 165-199. Academic Press, 1994. Disponible en http://www.cse.ucsd.edu/˜goguen .
[Hsia et al. 1993] P. Hsia, A. Davis, y D. Kung. Status Report: Requirements Engineering. IEEE Software, 10(6), Noviembre 1993.
[IEEE 1996] IEEE. IEEE Guide for Developing System Requirements Specifications. IEEE/ANSI Standard 1233-1996, Institute of Electrical and Electronics Engineers, 1996.
[Pohl 1997] Pohl, Klaus. Requerimentes Engineeering: An Overview. Encyclopedia of computer Science and Technology, 36, 1997. Disponible en http://sunsite.informatik.rwth-aachen.de/CREWS/reports96.htm
[Pressman 1997] R. S. Pressman. Ingeniería del Software. Un Enfoque Práctico. McGraw-Hill, 4 a edición, 1997.
[Shaw 1990] . Shaw, M. Prospects for an Engineering Discipline of Software. IEEE Software, 7(6):15-24.
[TSG 1995] TSG. The CHAOS Report. The Standish Group, 1995. Disponible en http://www.standishgroup.com/chaos.html .
[Wieringa 1996] R. J. Wieringa. Requirements Engineering: Frameworks for Understanding. John Wiley & Sons, 1996.
En el contexto de elicitación de requisitos es importante poder definir claramente los objetivos y los requisitos del sistema. Generalmente los objetivos provienen de la visión y a su vez los requisitos provienen de los objetivos.
Los Objetivos y los Requisitos
Los objetivos son requisitos de alto nivel que el sistema debe cumplir para satisfacer necesidades de negocio. Para indagar sobre los objetivos se deben hacer preguntas de este tipo:
¿Por qué se construye el sistema?
¿Qué beneficios espera del nuevo sistema?
¿Cómo se podría determinar que el nuevo sistema será exitoso?
Este tipo de pregunta permite que tanto clientes como usuarios identifiquen los objetivos del sistema en términos de negocio y no en términos de la solución.
Los requisitos son especificaciones de las características que el sistema debe tener para cumplir con esos objetivos, particular son:
· Una condición o capacidad que un usuario necesita para solucionar un problema
· Una condición o capacidad que debe tener un sistema o componente para satisfacer un contrato, una norma, una especificación u otro documento formal
Conclusión
Un objetivo está orientado a determinar los puntos que permitirán evaluar si el sistema será exitoso
Un requisitos es una condición o capacidad que un usuario necesita para solucionar un problema
Referencias
[Brooks 1995] F. P. Brooks, Jr. The Mythical Man-Month: Essays on Software Engineering Anniversary Edition. Addison-Wesley, 1995.
[Christel y Kang 1992] M. G. Christel y K. C. Kang. Issues in Requirements Elicitation. Technical Report CMU/SEI-92-TR-12, Software Engineering Institute, Carnegie Mellon University, 1992. Disponible en http://www.sei.cmu.edu .
[Davis 1990] A. M. Davis. The Analysis and Specification of Systems and Software Requirements. En Thayer y Dorfman [1990], páginas 119-144.
[Davis 1993] A. M. Davis. Software Requirements: Objects, Functions and States. Prentice-Hall, 2 a edición, 1993.
[DoD 1994] DoD. Military Standard 498: Software Development and Documentation. Departament of Defense of the United States of America, 1994. Disponible en
[Durán 2000] Durán, Amador. Un Entorno metodológico de Ingeniería de requisitos para Sistemas de Información. Tesis Doctoral. Sept. 2000.
[ESP 1996] ESPITI - European User Survey Results. Informe Técnico ESI-1996-TR95104, European Software Institute, 1996. Disponible en http://www.esi.es
[GAO 1979] Contracting for Computer Software Development: Serious Problems Require Management Attention to Avoid Wasting Additional Millions. Report FGMSD-80-4, U. S. Government Account Office, Noviembre 1979. Este documento es difícil de encontrar, pero está comentado y referenciado, entre otros, en [Davis 1993], [Christel y Kang 1992] y [Goguen 1994].
[Gause y Weinberg 1989] D. C. Gause y G. M. Weinberg. Exploring Requirements: Quality Before Design. Dorset House, 1989.
[Goguen 1994] J. A. Goguen. Requirements Engineering as the Reconciliation of Social and Technical Issues. En Requirements Engineering: Social and Technical Issues, páginas 165-199. Academic Press, 1994. Disponible en http://www.cse.ucsd.edu/˜goguen .
[Hsia et al. 1993] P. Hsia, A. Davis, y D. Kung. Status Report: Requirements Engineering. IEEE Software, 10(6), Noviembre 1993.
[IEEE 1996] IEEE. IEEE Guide for Developing System Requirements Specifications. IEEE/ANSI Standard 1233-1996, Institute of Electrical and Electronics Engineers, 1996.
[Pohl 1997] Pohl, Klaus. Requerimentes Engineeering: An Overview. Encyclopedia of computer Science and Technology, 36, 1997. Disponible en http://sunsite.informatik.rwth-aachen.de/CREWS/reports96.htm
[Pressman 1997] R. S. Pressman. Ingeniería del Software. Un Enfoque Práctico. McGraw-Hill, 4 a edición, 1997.
[Shaw 1990] . Shaw, M. Prospects for an Engineering Discipline of Software. IEEE Software, 7(6):15-24.
[TSG 1995] TSG. The CHAOS Report. The Standish Group, 1995. Disponible en http://www.standishgroup.com/chaos.html .
[Wieringa 1996] R. J. Wieringa. Requirements Engineering: Frameworks for Understanding. John Wiley & Sons, 1996.
lunes, septiembre 05, 2005
El problema de la obsolescencia y Pair Programming como técnica de mitigarla
En las organización que tiene un departamento de desarrollo de software siempre ocurre lo que describiré a continuación y que tiene que ver con la “obsolescencia” del conocimiento que poseen las personas: cuando un analista ingresa siendo joven a una compañía, este posee los conocimientos y la mente fresca, de manera que es capaz de enfrentar e incorporar como parte de su conocimiento las últimas tendencias y las últimas tecnologías. Después de aproximadamente un año, el analista llega al tope de su productividad, pues conoce los procesos, las dependencias, las estructuras y demás sutilidades de la organización que facilitan su trabajo.
Sin embargo, el tiempo pasa y el desarrollo de la tecnología no se detiene. El sujeto de este artículo, el analista de desarrollo, se fija en sus compañeros mayores que conocen al dedillo el negocio y las maneras tecnológicas del negocio. Sin embargo, en el fondo siente que son “obsoletos” pues la tecnología que utilizan es anticuada. A pesar de esta “obsolescencia” muy a menudo recurre a su compañero mayor para que le aclare cómo utilizar cierta regla de negocio que le parece compleja, o como utilizar cierta estructura de datos. Como se nota, en analistas fresco llega a ser productivo con el apoyo del obsoleto, mientras que el analista “obsoleto” no gana ningún conocimiento fresco.
El tiempo pasa y aquel analista fresco empieza a madurar, empieza a conocer los detalles del negocio, las sutilidades de la organización y empieza a parecerse a aquellos analistas obsoletos, mientras observa cómo va llegando gente nueva con ideas refrescantes y tecnologías y tendencias de punta. Entonces el analista ya no está tan fresco y empieza a sentirse obsoleto.
Este ciclo es inevitable, pues el paso de la tecnología atropella, y a pesar de ser inquieto, autodidacta e innovador, se requiere tiempo para la familia, para el descanso, para los hobbies y para el trabajo. En el tiempo libre no se logra un nivel de renovación suficiente como para compararse con los analistas frescos.
Siempre que ocurren este tipo de situaciones se requiere la influencia de un ente externo que lo mitigue. En esta caso, mi propuesto consiste en la práctica de programación por pares predicada por la programación extrema.
En esta técnica el objetivo NO ES REPARTIR EL TRABAJO ENTRE DOS, por el contrario, es producir en conjunto. Tras esta técnica reside la idea de la sinergia, en la que el trabajo en conjunto es mayor que la suma del trabajo de las partes. En este caso, la sinergia logra disminuir el nivel de obsolescencia y, simultáneamente, disminuir la curva de aprendizaje de la particularidades de la organización; produciendo mejor software, probablemente, en un tiempo igual o un poco menor que el producido por dos personas por separado.
Mientras el analista fresco aporta la novedad, el analistas obsoleto aporta la experiencia. Mientras el analistas fresco se desespera por los resultados, el analista obsoleto mantiene el foco.
Cada parte tiene mucho para beneficiarse y por transitividad, la organización podrá obtener estos beneficios: mejores productos de software, disminución de curvas de aprendizaje, personal actualizado, sinergia y trabajo en equipo.
Sin embargo, el tiempo pasa y el desarrollo de la tecnología no se detiene. El sujeto de este artículo, el analista de desarrollo, se fija en sus compañeros mayores que conocen al dedillo el negocio y las maneras tecnológicas del negocio. Sin embargo, en el fondo siente que son “obsoletos” pues la tecnología que utilizan es anticuada. A pesar de esta “obsolescencia” muy a menudo recurre a su compañero mayor para que le aclare cómo utilizar cierta regla de negocio que le parece compleja, o como utilizar cierta estructura de datos. Como se nota, en analistas fresco llega a ser productivo con el apoyo del obsoleto, mientras que el analista “obsoleto” no gana ningún conocimiento fresco.
El tiempo pasa y aquel analista fresco empieza a madurar, empieza a conocer los detalles del negocio, las sutilidades de la organización y empieza a parecerse a aquellos analistas obsoletos, mientras observa cómo va llegando gente nueva con ideas refrescantes y tecnologías y tendencias de punta. Entonces el analista ya no está tan fresco y empieza a sentirse obsoleto.
Este ciclo es inevitable, pues el paso de la tecnología atropella, y a pesar de ser inquieto, autodidacta e innovador, se requiere tiempo para la familia, para el descanso, para los hobbies y para el trabajo. En el tiempo libre no se logra un nivel de renovación suficiente como para compararse con los analistas frescos.
Siempre que ocurren este tipo de situaciones se requiere la influencia de un ente externo que lo mitigue. En esta caso, mi propuesto consiste en la práctica de programación por pares predicada por la programación extrema.
En esta técnica el objetivo NO ES REPARTIR EL TRABAJO ENTRE DOS, por el contrario, es producir en conjunto. Tras esta técnica reside la idea de la sinergia, en la que el trabajo en conjunto es mayor que la suma del trabajo de las partes. En este caso, la sinergia logra disminuir el nivel de obsolescencia y, simultáneamente, disminuir la curva de aprendizaje de la particularidades de la organización; produciendo mejor software, probablemente, en un tiempo igual o un poco menor que el producido por dos personas por separado.
Mientras el analista fresco aporta la novedad, el analistas obsoleto aporta la experiencia. Mientras el analistas fresco se desespera por los resultados, el analista obsoleto mantiene el foco.
Cada parte tiene mucho para beneficiarse y por transitividad, la organización podrá obtener estos beneficios: mejores productos de software, disminución de curvas de aprendizaje, personal actualizado, sinergia y trabajo en equipo.
jueves, septiembre 01, 2005
Los Requisitos y la Calidad de Software
Recientemente, durante un taller de requisitos que estoy dictando, surgió la inquietud de qué tipos de requisitos afectan la calidad del software. Por un lado se aseguraba que la calidad estaba definida por los requisitos no funcionales, mientras que por otro lado se aseguraba que ambos tipos de requisitos afectaban la calidad del producto. La confusión, sobre todo, se encontraba en lo que se conoce como necesidades implícitas y explicitas. A continuación reúno algunas definiciones que ayudan a aclarar el tema.
Según el SWEBOK, los requisitos funcionales “... describen las funciones que el sistema ejecutará: por ejemplo la aplicación de un formato a un texto o la modulación de una señal...”
“Los requisitos no funcionales son aquellos que actúan como restricciones para la solución. Los requisitos no funcionales algunas veces se conocen como requisitos de restricción o requisitos de calidad”.
De otro lado [ISO/IEC JTC1/SC7, Software engineering - Product
quality - Quality Model, ISO, 2001], define calidad como “la totalidad de características de una entidad que soportan su habilidad de satisfacer las necesidades implícitas y explícitas”
De este modo se tiene que tanto los requisitos funcionales como los requisitos no funcionales soportan la habilidad de satisfacer las necesidad de los stakeholder, por lo tanto, ambos tipos de requisitos afectan la calidad de un producto de software.
Es necesario resaltar que cuando se elicitan requisitos funcionales, es necesario indagar sobre los requisitos de calidad, es decir, aquellas características que contribuirán a que el sistema se desempeñe como realmente se requiere. De nada sirve un sistema que es funcionalmente correcto pero que no soporta el número de usuarios necesario, el sistema operativo del cliente, o cumple con las regulaciones de seguridad de alguna organización.
Conclusión
Los requisitos no funcionales también se conocen como requisitos de calidad, son restricciones que debe cumplir el sistema y que complementan su funcionalidad. Tanto los requisitos funcionales como no funcionales afectan la calidad de un producto de software.
Referencias
Applying ISO/IEC 9126-1 Quality Model to Quality Requirements
Engineering on Critical Software
SWEBOK: Software Engineering Body Of Knolwledge
Según el SWEBOK, los requisitos funcionales “... describen las funciones que el sistema ejecutará: por ejemplo la aplicación de un formato a un texto o la modulación de una señal...”
“Los requisitos no funcionales son aquellos que actúan como restricciones para la solución. Los requisitos no funcionales algunas veces se conocen como requisitos de restricción o requisitos de calidad”.
De otro lado [ISO/IEC JTC1/SC7, Software engineering - Product
quality - Quality Model, ISO, 2001], define calidad como “la totalidad de características de una entidad que soportan su habilidad de satisfacer las necesidades implícitas y explícitas”
De este modo se tiene que tanto los requisitos funcionales como los requisitos no funcionales soportan la habilidad de satisfacer las necesidad de los stakeholder, por lo tanto, ambos tipos de requisitos afectan la calidad de un producto de software.
Es necesario resaltar que cuando se elicitan requisitos funcionales, es necesario indagar sobre los requisitos de calidad, es decir, aquellas características que contribuirán a que el sistema se desempeñe como realmente se requiere. De nada sirve un sistema que es funcionalmente correcto pero que no soporta el número de usuarios necesario, el sistema operativo del cliente, o cumple con las regulaciones de seguridad de alguna organización.
Conclusión
Los requisitos no funcionales también se conocen como requisitos de calidad, son restricciones que debe cumplir el sistema y que complementan su funcionalidad. Tanto los requisitos funcionales como no funcionales afectan la calidad de un producto de software.
Referencias
Engineering on Critical Software
miércoles, agosto 31, 2005
Precondiciones y Poscondiciones en los Casos de Uso
Es muy común confundir el uso de las precondiciones y poscondiciones en los casos de uso. Las precondiciones son confundidas con validaciones que hace el sistema durante el caso de uso, mientras que las poscondiciones se asumen como operaciones que hace el sistema después de la ejecución decaso de uso. Para aclarar un poco las cosas propongo las siguientes definiciones
Precondición
Fuente: Internet
Las precondiciones son los hechos que se han de cumplir para que el flujo de evento se pueda llevar a cabo.
Fuente: Wikipedia
La sección de precondiciones se usa para informar cualquier condición que DEBA ser verdadera cuando el usuario inicia el caso de uso. Sin embargo, no son eventos que inician el caso de uso.
Fuente: Craig Larman “Use Case Model: Writing Requirements in Context”
Las precondiciones declaran lo que DEBE ser siempre verdadero antes de iniciar el escenario en el cado de uso. Las precondiciones no son probadas dentro del caso de uso, son condiciones que se asumen verdaderas. Normalmente, una precondición implica un escenario de otro caso de uso que se ha completado satisfactoriamente, como por ejemplo la “autenticación”, o más general “el cajero se identificar y se autentica”.
Conclusión
Las precondiciones son un conjunto de condiciones que deben ser ciertas antes de iniciar el caso de uso. Es muy común que la precondición sea el resultado exitoso de un caso de uso anterior.
Poscondición
Fuente: Internet
Las poscondiciones son los hecho que se han de cumplir si el flujo de eventos normal se ha ejecutado correctamente.
Fuente: Wikipedia
La sección de poscondiciones resumen el estado de las cosas después de que el escenario se completa
Fuente: Craig Larman “Use Case Model: Writing Requirements in Context”
Las garantias de exito o poscondiciones declaran que DEBE ser verdadero cuando se completa exitosamente el caso de uso, sea a través de su escenario principal o a través de un flujo alternativo. La garantía debe cumplir las necesidades de todos los stakeholders
Conclusión
Las poscondiciones indican el estado final de las cosas después de que el caso de uso termine exitosamente a través de cualquiera de sus flujos. No son acciones del sistema sino resultados de acciones. Se deben tener en cuanta las necesidades de todos los stakeholders para la definición de las poscondiciones.
Referencias
Precondición
Fuente: Internet
Las precondiciones son los hechos que se han de cumplir para que el flujo de evento se pueda llevar a cabo.
Fuente: Wikipedia
La sección de precondiciones se usa para informar cualquier condición que DEBA ser verdadera cuando el usuario inicia el caso de uso. Sin embargo, no son eventos que inician el caso de uso.
Fuente: Craig Larman “Use Case Model: Writing Requirements in Context”
Las precondiciones declaran lo que DEBE ser siempre verdadero antes de iniciar el escenario en el cado de uso. Las precondiciones no son probadas dentro del caso de uso, son condiciones que se asumen verdaderas. Normalmente, una precondición implica un escenario de otro caso de uso que se ha completado satisfactoriamente, como por ejemplo la “autenticación”, o más general “el cajero se identificar y se autentica”.
Conclusión
Las precondiciones son un conjunto de condiciones que deben ser ciertas antes de iniciar el caso de uso. Es muy común que la precondición sea el resultado exitoso de un caso de uso anterior.
Poscondición
Fuente: Internet
Las poscondiciones son los hecho que se han de cumplir si el flujo de eventos normal se ha ejecutado correctamente.
Fuente: Wikipedia
La sección de poscondiciones resumen el estado de las cosas después de que el escenario se completa
Fuente: Craig Larman “Use Case Model: Writing Requirements in Context”
Las garantias de exito o poscondiciones declaran que DEBE ser verdadero cuando se completa exitosamente el caso de uso, sea a través de su escenario principal o a través de un flujo alternativo. La garantía debe cumplir las necesidades de todos los stakeholders
Conclusión
Las poscondiciones indican el estado final de las cosas después de que el caso de uso termine exitosamente a través de cualquiera de sus flujos. No son acciones del sistema sino resultados de acciones. Se deben tener en cuanta las necesidades de todos los stakeholders para la definición de las poscondiciones.
Referencias
viernes, agosto 26, 2005
Aplicación Masiva Desarrollada en Java
Become.com's Web Crawler: A Massively Scaled Java Technology Application.
Muy interesante este artículo en el que explican cómo fue posible implementar una plataforma de Crawlers capaces de indexar más de 3 billones de páginas en el lapso de una semana.
Aunque en general un proyecto como estos no sería implementado en Java, la experiencia en CEO de la compañía en otro proyecto similar le indicó que era una buena alternativa.
Este tipo de ejemplo son los que sorprenden y hacen replantear el estereotipo de las aplicaciones desarrolladas en Java
Artículo Original
Sitio web del Producto
Muy interesante este artículo en el que explican cómo fue posible implementar una plataforma de Crawlers capaces de indexar más de 3 billones de páginas en el lapso de una semana.
Aunque en general un proyecto como estos no sería implementado en Java, la experiencia en CEO de la compañía en otro proyecto similar le indicó que era una buena alternativa.
Este tipo de ejemplo son los que sorprenden y hacen replantear el estereotipo de las aplicaciones desarrolladas en Java
Artículo Original
Sitio web del Producto
miércoles, agosto 24, 2005
¿Hacia donde va Google?
No pretendo responder esta pregunta porque solo la gente de Google sabe para donde van, pero si quiero plantear una hipótesis basándome en las herramientas que han liberado.
Gmail es tanto un servicio correo, como un cliente de correo web. El servicio de correo es simplemente excelente, porque aun siendo gratuito ofrece una enorme capacidad y gran calidad en cuanto a estabilidad y disponibilidad. El cliente de correo es una de las aplicaciones Web más eficientes, elegantes incluso diría con inspiración en el iPod (por su limpieza de diseño y efectividad de utilización). Este cliente de correo web es sumamente ligero, tiene todas las características importantes de Outlook y sobretodo posee la capacidad de buscar con el poder de Google, lo que evita muchísimo trabajo de clasificación.
Google Desktop 2 es una herramienta que integra muchos servicios, obviamente en el corazón está su motor de búsqueda que, como una gran sorpresa, indexa el mail de Outlook y se integra con este. Además, permite ver fotos, mantenerse informado con los blogs favoritos, saber cómo va la bolsa de Estado Unidos, saber cuales son los temas más candentes de Internet. Además, provee una API que permite desarrollar plug-ins y de esta manera extender los servicios, algo que le encanta al mundo del Open Source.
GoogleTalk. Este es un capítulo aparte, pues se había especulado enormemente sobre la necesidad que Google proveyera un servicio de mensajería instantánea. Entrando en materia, el software es muy sencillo, siguiendo la filosofía de los demás productos, sin embargo, aun le faltan muchas características, tales como emoticons (gráficos que permiten expresar el estado de ánimo), video conferencia y teleconferencia.
Con estas herramientas, claramente Google va en curso de colisión contra Microsoft: Herramientas de productividad, herramientas de colaboración, herramientas de información. Google se va perfilando como una contrincante de Microsoft Office, que es el caballito de batalla de la empresa de Redmond.
Habrá que esperar al próximo año para ver qué otras herramientas de productividad nos ofrecerá esta dinámica compañía y cómo responderá Microsoft a esta afrenta directa.
¿Será posible una alianza Google Apple?
¿Será posible una distribución Google Linux?
¿Será posible una alianza Google StarOffice?
¿Será Google el siguiente Microsoft y Microsoft el siguiente IBM?
Gmail es tanto un servicio correo, como un cliente de correo web. El servicio de correo es simplemente excelente, porque aun siendo gratuito ofrece una enorme capacidad y gran calidad en cuanto a estabilidad y disponibilidad. El cliente de correo es una de las aplicaciones Web más eficientes, elegantes incluso diría con inspiración en el iPod (por su limpieza de diseño y efectividad de utilización). Este cliente de correo web es sumamente ligero, tiene todas las características importantes de Outlook y sobretodo posee la capacidad de buscar con el poder de Google, lo que evita muchísimo trabajo de clasificación.
Google Desktop 2 es una herramienta que integra muchos servicios, obviamente en el corazón está su motor de búsqueda que, como una gran sorpresa, indexa el mail de Outlook y se integra con este. Además, permite ver fotos, mantenerse informado con los blogs favoritos, saber cómo va la bolsa de Estado Unidos, saber cuales son los temas más candentes de Internet. Además, provee una API que permite desarrollar plug-ins y de esta manera extender los servicios, algo que le encanta al mundo del Open Source.
GoogleTalk. Este es un capítulo aparte, pues se había especulado enormemente sobre la necesidad que Google proveyera un servicio de mensajería instantánea. Entrando en materia, el software es muy sencillo, siguiendo la filosofía de los demás productos, sin embargo, aun le faltan muchas características, tales como emoticons (gráficos que permiten expresar el estado de ánimo), video conferencia y teleconferencia.
Con estas herramientas, claramente Google va en curso de colisión contra Microsoft: Herramientas de productividad, herramientas de colaboración, herramientas de información. Google se va perfilando como una contrincante de Microsoft Office, que es el caballito de batalla de la empresa de Redmond.
Habrá que esperar al próximo año para ver qué otras herramientas de productividad nos ofrecerá esta dinámica compañía y cómo responderá Microsoft a esta afrenta directa.
¿Será posible una alianza Google Apple?
¿Será posible una distribución Google Linux?
¿Será posible una alianza Google StarOffice?
¿Será Google el siguiente Microsoft y Microsoft el siguiente IBM?
lunes, agosto 22, 2005
Participación en el XXV Salón de Informática de ACIS
Este año me invitaron a participar en el XXV Salón de informática de ACIS, llamado "Arquitectura Empresariales de Software: Espejismos y Realidades". La invitación se debe a la experiencia que ha tenido mi compañía y a mi participación directa en todo el proceso. El salón se llevará a cabo en la cuidad de Bogotá, el 29 de Septiembre de 2005.
La conferencia que dictaré se llama "Implementación de una visión de Arquitectura: Experiencias y Resultados".
Además de mostrar nuestros resultado, espero poder tomar el pulso del progreso de la industria del software y, sobre todo, de los clientes de esta industria en este evento.
Actualizaré el blog con los resúmenes de las conferencias en la medida en que participe y me parezcan interesants.
Se puede encontrar más información aquí
La conferencia que dictaré se llama "Implementación de una visión de Arquitectura: Experiencias y Resultados".
Además de mostrar nuestros resultado, espero poder tomar el pulso del progreso de la industria del software y, sobre todo, de los clientes de esta industria en este evento.
Actualizaré el blog con los resúmenes de las conferencias en la medida en que participe y me parezcan interesants.
Se puede encontrar más información aquí
De la teoría a la práctica
El jueves pasado (2005/08/18) participé en la tertulia de Ingeniería de Software de la universidad EAFIT. El tema general de la tertulia tenía que ver con las herramientas utilizadas para la gestión, desarrollo y calidad de proyectos de software.
Los puntos más importantes, según mi criterio, fueron:
· Las diferencias entre las visiones del proveedor y del cliente de software
· La voluntad de compartir los conocimientos para lograr mejorar la competitividad de nuestra industria de software
En cuanto a las diferencias entre las visiones del cliente y del proveedor se puede resaltar que el cliente necesita software flexible, resultados rápidos y gran calidad. Aun que estas metas parecen contradictorias, esa es la realidad del negocio y el reto que se debe asumir. El proveedor, por su lado, está mentalizado que lo único constante en software es el cambio y para poder entregar soluciones flexibles necesita el conocimiento técnicos y las herramientas adecuadas.
Respecto a compartir el conocimiento, Raquel Anaya, la directora del grupo de investigación, mencionó algo muy importante: El uso de herramientas Open Source en nuestro medio ha ido desarrollando la cultura de compartir el conocimiento por el bien común. Ahora las empresas de desarrollo se encuentran enfocadas en la integración de herramientas Open Source para cubrir el ciclo completo de desarrollo. Honrando la licencia Open Source, deben liberar el resultado de su trabajo al público, por lo que el esfuerzo conjunto de la industria del software está orientado a mejorar este aspecto. Esperemos que llegue a buen término para el bien, tanto de clientes, como de proveedores.
Cuando este tipo de reuniones involucran a los actores reales del negocio, la discusión se hace más interesante y se enriquecen todos los participantes, especialmente lo estudiantes. La academia, sin lugar a dudas es fundamental, pero periódicamente debe acoger a la industria para verificar como los modelos académicos se adaptan a las realidades del medio.
Los puntos más importantes, según mi criterio, fueron:
· Las diferencias entre las visiones del proveedor y del cliente de software
· La voluntad de compartir los conocimientos para lograr mejorar la competitividad de nuestra industria de software
En cuanto a las diferencias entre las visiones del cliente y del proveedor se puede resaltar que el cliente necesita software flexible, resultados rápidos y gran calidad. Aun que estas metas parecen contradictorias, esa es la realidad del negocio y el reto que se debe asumir. El proveedor, por su lado, está mentalizado que lo único constante en software es el cambio y para poder entregar soluciones flexibles necesita el conocimiento técnicos y las herramientas adecuadas.
Respecto a compartir el conocimiento, Raquel Anaya, la directora del grupo de investigación, mencionó algo muy importante: El uso de herramientas Open Source en nuestro medio ha ido desarrollando la cultura de compartir el conocimiento por el bien común. Ahora las empresas de desarrollo se encuentran enfocadas en la integración de herramientas Open Source para cubrir el ciclo completo de desarrollo. Honrando la licencia Open Source, deben liberar el resultado de su trabajo al público, por lo que el esfuerzo conjunto de la industria del software está orientado a mejorar este aspecto. Esperemos que llegue a buen término para el bien, tanto de clientes, como de proveedores.
Cuando este tipo de reuniones involucran a los actores reales del negocio, la discusión se hace más interesante y se enriquecen todos los participantes, especialmente lo estudiantes. La academia, sin lugar a dudas es fundamental, pero periódicamente debe acoger a la industria para verificar como los modelos académicos se adaptan a las realidades del medio.
viernes, agosto 19, 2005
Ser jefe, ser Lider II
El tema del liderazgo es similar en todos entornos, sin embargo cada entorno tiene diferencias que hacen que ciertas características sean más importantes que otras.
Una forma de liderazgo muy efectiva en los ambientes de tecnología consiste en el conocimiento y la experiencia. Dentro de los equipos de desarrollo generalmente hay un líder técnico, este no tiene un cargo formalmente establecido, sino que a través de su experiencia y conocimiento logra establecer un liderazgo entre sus compañeros. Del otro lado de la balanza se encuentra el jefe del equipo, generalmente el coordinador o jefe de proyecto. El perfil del jefe del proyecto es más administrativo que técnico.
Para que el equipo se desempeñe adecuadamente el jefe de proyecto debe asumir un rol motivacional pues el liderazgo real del equipo se encuentra en la faceta técnica. Cuando un jefe de proyecto se involucra en la parte técnica, generalmente la acción es contraproducente causando un rechazo. En contraste, cuando el jefe del proyecto descubre los factores que motivan al equipo y a cada uno de sus integrantes, el equipo se desempeña adecuadamente.
Es responsabilidad del jefe del proyecto conformar un equipo de trabajo con un líder técnico, sino, el mismo tendrá que asumir esta responsabilidad que generalmente no le sienta bien.
En este caso se evidencia como el liderazgo no necesariamente va investido de una autoridad formal y sin embargo es efectivo
Parte I
Parte III
Una forma de liderazgo muy efectiva en los ambientes de tecnología consiste en el conocimiento y la experiencia. Dentro de los equipos de desarrollo generalmente hay un líder técnico, este no tiene un cargo formalmente establecido, sino que a través de su experiencia y conocimiento logra establecer un liderazgo entre sus compañeros. Del otro lado de la balanza se encuentra el jefe del equipo, generalmente el coordinador o jefe de proyecto. El perfil del jefe del proyecto es más administrativo que técnico.
Para que el equipo se desempeñe adecuadamente el jefe de proyecto debe asumir un rol motivacional pues el liderazgo real del equipo se encuentra en la faceta técnica. Cuando un jefe de proyecto se involucra en la parte técnica, generalmente la acción es contraproducente causando un rechazo. En contraste, cuando el jefe del proyecto descubre los factores que motivan al equipo y a cada uno de sus integrantes, el equipo se desempeña adecuadamente.
Es responsabilidad del jefe del proyecto conformar un equipo de trabajo con un líder técnico, sino, el mismo tendrá que asumir esta responsabilidad que generalmente no le sienta bien.
En este caso se evidencia como el liderazgo no necesariamente va investido de una autoridad formal y sin embargo es efectivo
miércoles, agosto 17, 2005
Luna de Miel en Panamá
El 30 de Julio de 2005 sucedió el evento más importante en mi vida, finalmente me casé con la mujer que adoro y con la que espero compartir mi tiempo por el resto de la vida.
Aquí, algunas fotos del hotel, de cuidad de Panamá y de una de las maravillas del mundo, el Canal de Panamá
Mi esposa y yo saliendo del centro de visitantes del Canal de Panamá
Mi esposa en centro de visitantes desde donde se pueden observar los barcos pasar a través de las esclusas de Miraflores
Ese soy yo aguantando el sol para poder ver esta maravilla del mundo funcionado.
El barco ingrasa al primer juego de esclusas de Miraflores
Una panorámica de la Ciudad e Panamá desde las tres islas o Amador, como también es conocido
Catedral del casco antigüo de Ciudad de Panamá
La moderna cuidad de Panamá y su zona bancaria
La playa del hotel, costa del oceano pacífico en Panamá. Desde aquí se debería trabajar siempre.
Una de la lindas piscinas del hotel
Mi esposa y yo después de unos buenos cocktails, mar y piscina.
Se nota la emoción por los postres
Vamos en el carrito de golf que recorre el hotel rumbo al lobby principal para tomar el transporte hacia el aeropueto internacional de Tocumen
Aquí, algunas fotos del hotel, de cuidad de Panamá y de una de las maravillas del mundo, el Canal de Panamá
Mi esposa y yo saliendo del centro de visitantes del Canal de Panamá
Mi esposa en centro de visitantes desde donde se pueden observar los barcos pasar a través de las esclusas de Miraflores
Ese soy yo aguantando el sol para poder ver esta maravilla del mundo funcionado.
El barco ingrasa al primer juego de esclusas de Miraflores
Una panorámica de la Ciudad e Panamá desde las tres islas o Amador, como también es conocido
Catedral del casco antigüo de Ciudad de Panamá
La moderna cuidad de Panamá y su zona bancaria
La playa del hotel, costa del oceano pacífico en Panamá. Desde aquí se debería trabajar siempre.
Una de la lindas piscinas del hotel
Mi esposa y yo después de unos buenos cocktails, mar y piscina.
Se nota la emoción por los postres
Vamos en el carrito de golf que recorre el hotel rumbo al lobby principal para tomar el transporte hacia el aeropueto internacional de Tocumen
Avances en la Guía de Arquitecto
Sigue el trabajo en la Guía del Arquitecto. No escribo todos los días pero si lo hago con frecuencia. Como va el trabajo todo indica que no será un libro sino un ensayo o un artículo.
Los capítulos o títulos que he desarrollado son
· Los valores del arquitecto
· Las habilidades del arquitecto
· La imagen del arquitecto
· Actividades recurrentes del arquitecto
Quisiera incluir un título más relacionado con el liderazgo y el estilo de liderazgo que puede asumir un arquitecto de software. Sería útil enriquecerlo con mis experiencias y las experiencias de otras personas dedicadas a esta interesante labor.
Los capítulos o títulos que he desarrollado son
· Los valores del arquitecto
· Las habilidades del arquitecto
· La imagen del arquitecto
· Actividades recurrentes del arquitecto
Quisiera incluir un título más relacionado con el liderazgo y el estilo de liderazgo que puede asumir un arquitecto de software. Sería útil enriquecerlo con mis experiencias y las experiencias de otras personas dedicadas a esta interesante labor.
Nueva Cara para Dia a Dia
Ya era hora de un cambio de look para el blog. El anterior ya me tenía un poco cansado, era algo monótono. Por ahora, estoy conforme con esta nueva plantilla.
La verdad no le he gastado mucho tiempo la cómo se ve el blog. En lo que si he invertido algo de tiempo es en probar AdSense de Google. Este es un servicio de avisos "inteligentes", pues muestra publicidad relacionada con la información contenida en el sistio. La verdad no he visto mucha relación de lo que he escrito con los anuncios que se generan, pero me gusta como se ve.
Además estoy utilizando un servicio de Hit Counter, para ver cuantas visitas tengo. Por ahora no es que este sea el blog más popular (de hecho, casi no lo es), pero es interesante ver cómo gente de todo el mundo visita este sitio, y sobre todo, cómo llegan aquí. Excelente esta herramienta gratuita.
Otra cosa que tengo pendiente es actualizar la foto de mi profile, porque la de FortuneCity no funciona muy bien, lo haré pronto.
La verdad no le he gastado mucho tiempo la cómo se ve el blog. En lo que si he invertido algo de tiempo es en probar AdSense de Google. Este es un servicio de avisos "inteligentes", pues muestra publicidad relacionada con la información contenida en el sistio. La verdad no he visto mucha relación de lo que he escrito con los anuncios que se generan, pero me gusta como se ve.
Además estoy utilizando un servicio de Hit Counter, para ver cuantas visitas tengo. Por ahora no es que este sea el blog más popular (de hecho, casi no lo es), pero es interesante ver cómo gente de todo el mundo visita este sitio, y sobre todo, cómo llegan aquí. Excelente esta herramienta gratuita.
Otra cosa que tengo pendiente es actualizar la foto de mi profile, porque la de FortuneCity no funciona muy bien, lo haré pronto.
martes, agosto 16, 2005
Plataforma Fácilmente Administrable
Introducción
¿Se ha preguntado alguna vez qué significa “Plataforma Administrable”? Bueno yo también he hecho y basándome en la funciones de la administración definidas académicamente, he planteado que significa “Plataformas Fácilmente Administrables”.
Plataforma Administrable
La plataforma tecnológica debe ser fácilmente administrable lo que implica lo siguiente:
· Fácil Planeación
· Fácil Organización
· Fácil Integración
· Fácil Dirección
· Fácil Control
Fácil Planeación
La plataforma debe proveer las estadísticas suficientes para facilitar la planeación de la capacidad requerida para soportar la operación del negocio.
Fácil Organización
La organización implica la definición de una estructura orientada a lograr los objetivos. En otras palabras, la infraestructura debe facilitar su organización física y lógica, de manera que se logren los objetivos del negocio.
Fácil Integración
Los elementos de la plataforma deben ser fácilmente integrables, de manera que cooperen para soportar la operación.
Fácil Dirección
Dirigir implica hacer correcciones durante la marcha. Estas correcciones pueden ser de capacidad, de organización, de integración o de funcionamiento en general. La plataforma debe poder ser dirigida fácilmente para lograr los objetivos de negocio.
Fácil Control
La plataforma debe proveer puntos de control, de manera que se puede monitorear su comportamiento y se puedan tomar decisiones aplicables en el corto plazo (dirección) o en el medio y largo plazo (planeación).
¿Se ha preguntado alguna vez qué significa “Plataforma Administrable”? Bueno yo también he hecho y basándome en la funciones de la administración definidas académicamente, he planteado que significa “Plataformas Fácilmente Administrables”.
Plataforma Administrable
La plataforma tecnológica debe ser fácilmente administrable lo que implica lo siguiente:
· Fácil Planeación
· Fácil Organización
· Fácil Integración
· Fácil Dirección
· Fácil Control
Fácil Planeación
La plataforma debe proveer las estadísticas suficientes para facilitar la planeación de la capacidad requerida para soportar la operación del negocio.
Fácil Organización
La organización implica la definición de una estructura orientada a lograr los objetivos. En otras palabras, la infraestructura debe facilitar su organización física y lógica, de manera que se logren los objetivos del negocio.
Fácil Integración
Los elementos de la plataforma deben ser fácilmente integrables, de manera que cooperen para soportar la operación.
Fácil Dirección
Dirigir implica hacer correcciones durante la marcha. Estas correcciones pueden ser de capacidad, de organización, de integración o de funcionamiento en general. La plataforma debe poder ser dirigida fácilmente para lograr los objetivos de negocio.
Fácil Control
La plataforma debe proveer puntos de control, de manera que se puede monitorear su comportamiento y se puedan tomar decisiones aplicables en el corto plazo (dirección) o en el medio y largo plazo (planeación).
Prácticas y Herramientas para la gestión aseguramiento de Calidad
Introducción
El resultado del proceso de desarrollo de software consiste en soluciones informáticas para problemas de negocio. La gestión y el aseguramiento de calidad de estas soluciones son clave para lograr los objetivos corporativos por los cuales el software fue concebido.
A través del proceso de desarrollo de software se deben llevar a cabo actividades que permitan verificar la calidad del producto que se está construyendo. Según la IEEE, existen atributos internos y externos de calidad. Los atributos internos son indicadores de los atributos externos, y estos últimos a su vez, predicen la calidad de uso del producto.
En esta charla se presentarán algunas de las practicas y herramientas relacionadas con la gestión y el aseguramiento de calidad del producto de software.
Atributos Internos
Evaluación de calidad en la especificación de requisitos de software
La evaluación de los requisitos está en un estado incipiente, pues se está desarrollando una metodología de elicitación de requisitos y una metodología de verificación de requisitos.
El objetivo de este proceso es lograr calificar el documento de especificación de requisitos de una manera objetiva. De acuerdo con las necesidades del negocio se aplicarán tres plantillas de evaluación y de acuerdo a la calificación obtenida por el documento, se continuará el desarrollo del sistema o se solicitará la revisión de las inconformidades.
La metodología está siendo desarrollada y se incluirá dentro del mapa de procesos de las gerencias de tecnología.
Evaluación de la arquitectura de software
Mediante la evaluación de la arquitectura de software se puede verificar en un estado temprano la estructura de un sistema y las principales prácticas que serán utilizadas para su desarrollo. Estas características son indicadores importantes que permiten vislumbrar la calidad técnica del producto, es decir, mediante los atributos internos de calidad se pueden predecir los atributos externos de calidad. La experiencia ha indicado que cuando un proveedor entrega un documento de arquitectura bien estructurado, claro, conciso, resaltando las prácticas y patrones que utilizará, el proveedor ha entendido el problema. Este entendimiento lo ha logrado desde el punto de vista funcional y no funcional y este documento es la evidencia de ello.
Cuando se recibe un documento de arquitectura poco estructurado, incompleto o poco claro, la experiencia indica que el proveedor no tiene el suficiente conocimiento técnica y que probablemente requerirá mayor nivel de seguimiento durante el proceso de diseño y construcción para lograr un producto adecuado.
Existe otro extremo que consiste en que el proveedor cuenta con experiencia técnica pero que no ha entendido adecuadamente el problema. En este caso, el proveedor genera la documentación directamente desde sus herramientas de diseño o herramientas CASE sin agregar valor alguno. En estas situaciones la documentación, más que una herramienta de análisis, se ha convertido en una formalidad lo que la hace muy poco útil y práctica.
Las herramientas utilizadas para este proceso de evaluación son:
· Un documento estándar de arquitectura de software basado en el modelo de 4+1 vistas. Este modelo es muy reconocido y fue recomendado por consultores de Oracle, Brasil.
· Una plantilla en Excel, en la cual se especifican cada uno de los items de evaluación que el analista de arquitectura tendrá en cuenta. Además, la plantilla indica el puntaje mínimo con el cual se aprueba la arquitectura del sistema.
· La evaluación final se entrega al proveedor con toda la explicación de cada una de las observaciones. Esta evaluación es una evidencia objetiva del proceso de calidad que podrá ser revisada en momentos posteriores.
Atributos Externos
Evaluación de calidad mediante pruebas técnicas del producto
Las pruebas técnicas de productos son necesarias debido a:
· La complejidad del ambiente de ejecución
· La convivencia otros productos
· Requisitos de gran eficiencia en el uso de recursos informáticos
· Requisitos de bajos tiempos de respuesta requeridos
Las pruebas técnicas que se realizan son tres:
Homologación
La homologación es el proceso mediante el cual se verifican los manuales y los medios de instalación. Los manuales requeridos para todo producto son:
· Manual de instalación del producto: Contiene las instrucciones detalladas para la instalación del producto
· Manual de pruebas: Es el manual que utilizan los operadores para verificar que un producto de software se encuentra operativo.
· Ficha técnica: Describe las características y requisitos técnicos necesarios para la operación del software.
Además, el proceso de homologación recibe el producto en medio digital, los instala y lo pruebas en el ambiente de pruebas.
Si el producto de software cumple con los requisitos, se instala y funciona adecuadamente, se obtiene la homologación del producto.
Pruebas de Telecomunicaciones
Esta prueba se realiza en un laboratorio que permite simular la latencia y el ancho de banda de todas las oficinas, desde canales de 56 Kbps hasta canales Giga.
Durante las pruebas de telecomunicaciones se verifica el consumo de ancho de banda. El consumo de ancho de banda es diferente para aplicaciones Web y para aplicaciones C/S. En aplicaciones web se impone una restricción por página, mientras que por la naturaleza de las aplicaciones C/S se impone una restricción por consulta.
Las inconformidades son registradas en el BugTracker. Si el producto no logra obtener los puntajes establecidos como política de la organización, no se le concede la certificación de telecomunicaciones y se pasa al ciclo de desarrollo nuevamente. Si el producto logra los puntajes establecidos, el producto obtiene la certificación de telecomunicaciones.
La experiencia indica que los productos que se desempeñan adecuadamente en telecomunicaciones tendrán un comportamiento adecuado en tiempo de respuesta y son menos propensos a sufrir problemas rendimiento.
Las herramientas utilizadas en este proceso son:
· Laboratorio de pruebas
· Simulador de canales
· Sniffer
· BugTracker
Pruebas de Bases de Datos
El objetivo de las pruebas de bases de datos es identificar posibles cuellos de botella debidos a queries ineficientes o estructuras de datos poco optimizadas.
Algunos puntos que se tienen en cuenta:
· Full scan de tablas, es decir, uso ineficiente de índices
· Bloqueos o deadlock
· Alto consumo de memoria
· Alto consumo de procesador
Las herramientas utilizadas en este proceso son:
· Consola de administración de base de datos
· Laboratorio de pruebas
· BugTracker
· Hoja de cálculo con el informe del DBA
Las inconformidades son registradas en el BugTracker y el producto debe ser corregido y preparado para el siguiente ciclo de pruebas. Si el producto cumple con todas las pruebas, entonces se le otorga el certificado de bases de datos y puede continuar el proceso.
Esta es una de las pruebas más críticas para un software, pues indica el comportamiento que el sistema tendrá y su estabilidad. Aunque el ambiente de pruebas pretende simular el ambiente de producción, este último es mucho más complejo y sensible, de manera que si existe una pequeña falla de base de datos es imperativo su corrección, de lo contrario el problema se convertirá en un problema superlativo que afectará de una manera importante al software.
Pruebas de Seguridad
Las pruebas de seguridad son un conjunto de pruebas encaminadas a lograr un nivel de seguridad adecuado, establecido por el área de seguridad informática.
Estas pruebas consisten en una batería de pruebas previamente diseñadas que abarcan desde el aseguramiento del medio de transporte pasando por técnicas de cross-site scripting y SQL Injection.
La batería de pruebas de seguridad no es divulgada. Los especialistas en seguridad las ejecutan y reportan el tema en el cual la aplicación debe mejorar, pero evitan divulgar la manera de explotar la vulnerabilidad.
Las herramientas utilizadas para las pruebas son:
· Laboratorio de pruebas
· Sniffers
· Reverse-Proxy
· Otras herramientas de seguridad
Pruebas de Estrés
Por experiencia, las pruebas de estrés son el ítem más importante de las pruebas técnicas, pues son estas las que exigen al máximo todo el conjunto de componentes del software y permiten hallar fallas estructurales que ponen en riesgo la viabilidad del software. En gran medida, una buena definición de la arquitectura del software evitará problemas en las pruebas de estrés, pero no lo garantiza.
La experiencia indica que para que el software se comporte bien bajo cargas extremas, su arquitectura debe ser sencilla y robusta, evitando complicaciones innecesarias y artificios inoficiosos.
Siempre, durante el diseño del software, se debe tener en cuenta el perfil de la aplicación, es decir, el nivel de transaccionalidad, el tamaño del público objetivo, la proporción de usuarios concurrentes y otros temas muy importantes que afectan la escalabilidad.
Aunque las pruebas de estrés nunca han logrado replicar la carga de los ambientes de producción, si logran detectar problemas estructurales que deben ser corregidos.
Las herramientas utilizadas son:
· Laboratorio de pruebas
· Herramienta de estrés de aplicaciones
· Sniffer
· Consolas de monitoreo
Durante una prueba de estrés se monitorean todos los frentes de manera conjunta; bases de datos, servidores de aplicaciones, otros repositorios de datos, redes, etc...
Si la aplicación logra mantener sus niveles de errores en cero al nivel de concurrencia objetivo la aplicación obtiene el certificado de pruebas de estrés. De lo contrario se registra la no conformidad en el BugTracker y se prepara un segundo ciclo de pruebas de estrés
Evaluación de calidad mediante ejecución de pruebas funcionales
Las pruebas funcionales son llevadas a cabo en de dos maneras: a través de testers y a través de usuarios del sistema.
Los casos de prueba son levantados durante el proceso de desarrollo de la aplicación y sobre todo, durante el proceso de homologación por el analista de calidad asignado para el producto.
Al finalizar el proceso de desarrollo, el analista de desarrollo debe certificar que el sistema pasa los casos de prueba levantados por el analista de pruebas. Después del proceso de homologación, en el cual se instala la aplicación en el ambiente de laboratorio, los testers o los usuarios finales ejecutan los casos de prueba y registran bug en el BugTracker. Se realizan las correcciones y se inicia un segundo ciclo de pruebas, después del cual se deben haber corregido estos problemas y el producto debe estar listo para su paso a producción.
La experiencia indica que cuando se han contratado el servicio de testing el proceso de pruebas funcionales ha sido muy efectivo, sin embargo, existen problemas importantes de costo. El esquema de testing se asemeja a un taxímetro, ya que cada hora que el tester pasa en las instalaciones de la compañía es facturada y si surgen inconvenientes de plataforma o de desarrollo, ese es tiempo facturado que no ha sido productivo en términos de pruebas.
En caso de un producto desarrollado a la medida, el software ya debió haber sido probado por el proveedor. Existe una corriente de pensamiento que asegura que el servicio de testing debe ser pagado por el proveedor sin cargo directo al cliente, pues este último espera un producto de calidad. Sin embargo persiste el esquema en el cual, aunque el producto es desarrollador a la medida, los testers corren por cuenta de la compañía.
Herramientas:
· Metodología de pruebas funcionales
· BugTracker
· Laboratorio de pruebas
Gestión de la Calidad
El ciclo PHVA (Planear, Hacer, Validar, Actuar) indica que después planear y hacer las cosas se requiere validar que el proceso sea efectivo y se debe actuar sobre el proceso para mejorarlo. En general, la herramienta fundamental para la gestión de calidad es el BugTracker, pues contiene la evidencia objetiva que permite obtener estadísticas sobre los niveles de calidad de los productos que diariamente se pruebas en la compañía.
Además de la gestión de la calidad durante el proceso de desarrollo, existe la gestión de la calidad posimplantación, es decir, cuando inicia el ciclo de mantenimiento. Este ciclo es vital, pues logra mantener el producto de software vigente. La gestión de la calidad del producto en ciclo de mantenimiento se logra a través de Tickets, que son incidentes reportados por los usuarios finales y que deben ser resueltos por los analistas con unos niveles de servicio previamente pactados.
Tanto los reportes del BugTracker como los Tickets son indicadores que entran en el proceso de evaluación de la gerencia, de los ejecutivos y de los analistas. Desde este punto de vista se gestiona el proceso de desarrollo y por lo tanto de la calidad de los productos de software.
El resultado del proceso de desarrollo de software consiste en soluciones informáticas para problemas de negocio. La gestión y el aseguramiento de calidad de estas soluciones son clave para lograr los objetivos corporativos por los cuales el software fue concebido.
A través del proceso de desarrollo de software se deben llevar a cabo actividades que permitan verificar la calidad del producto que se está construyendo. Según la IEEE, existen atributos internos y externos de calidad. Los atributos internos son indicadores de los atributos externos, y estos últimos a su vez, predicen la calidad de uso del producto.
En esta charla se presentarán algunas de las practicas y herramientas relacionadas con la gestión y el aseguramiento de calidad del producto de software.
Atributos Internos
Evaluación de calidad en la especificación de requisitos de software
La evaluación de los requisitos está en un estado incipiente, pues se está desarrollando una metodología de elicitación de requisitos y una metodología de verificación de requisitos.
El objetivo de este proceso es lograr calificar el documento de especificación de requisitos de una manera objetiva. De acuerdo con las necesidades del negocio se aplicarán tres plantillas de evaluación y de acuerdo a la calificación obtenida por el documento, se continuará el desarrollo del sistema o se solicitará la revisión de las inconformidades.
La metodología está siendo desarrollada y se incluirá dentro del mapa de procesos de las gerencias de tecnología.
Evaluación de la arquitectura de software
Mediante la evaluación de la arquitectura de software se puede verificar en un estado temprano la estructura de un sistema y las principales prácticas que serán utilizadas para su desarrollo. Estas características son indicadores importantes que permiten vislumbrar la calidad técnica del producto, es decir, mediante los atributos internos de calidad se pueden predecir los atributos externos de calidad. La experiencia ha indicado que cuando un proveedor entrega un documento de arquitectura bien estructurado, claro, conciso, resaltando las prácticas y patrones que utilizará, el proveedor ha entendido el problema. Este entendimiento lo ha logrado desde el punto de vista funcional y no funcional y este documento es la evidencia de ello.
Cuando se recibe un documento de arquitectura poco estructurado, incompleto o poco claro, la experiencia indica que el proveedor no tiene el suficiente conocimiento técnica y que probablemente requerirá mayor nivel de seguimiento durante el proceso de diseño y construcción para lograr un producto adecuado.
Existe otro extremo que consiste en que el proveedor cuenta con experiencia técnica pero que no ha entendido adecuadamente el problema. En este caso, el proveedor genera la documentación directamente desde sus herramientas de diseño o herramientas CASE sin agregar valor alguno. En estas situaciones la documentación, más que una herramienta de análisis, se ha convertido en una formalidad lo que la hace muy poco útil y práctica.
Las herramientas utilizadas para este proceso de evaluación son:
· Un documento estándar de arquitectura de software basado en el modelo de 4+1 vistas. Este modelo es muy reconocido y fue recomendado por consultores de Oracle, Brasil.
· Una plantilla en Excel, en la cual se especifican cada uno de los items de evaluación que el analista de arquitectura tendrá en cuenta. Además, la plantilla indica el puntaje mínimo con el cual se aprueba la arquitectura del sistema.
· La evaluación final se entrega al proveedor con toda la explicación de cada una de las observaciones. Esta evaluación es una evidencia objetiva del proceso de calidad que podrá ser revisada en momentos posteriores.
Atributos Externos
Evaluación de calidad mediante pruebas técnicas del producto
Las pruebas técnicas de productos son necesarias debido a:
· La complejidad del ambiente de ejecución
· La convivencia otros productos
· Requisitos de gran eficiencia en el uso de recursos informáticos
· Requisitos de bajos tiempos de respuesta requeridos
Las pruebas técnicas que se realizan son tres:
Homologación
La homologación es el proceso mediante el cual se verifican los manuales y los medios de instalación. Los manuales requeridos para todo producto son:
· Manual de instalación del producto: Contiene las instrucciones detalladas para la instalación del producto
· Manual de pruebas: Es el manual que utilizan los operadores para verificar que un producto de software se encuentra operativo.
· Ficha técnica: Describe las características y requisitos técnicos necesarios para la operación del software.
Además, el proceso de homologación recibe el producto en medio digital, los instala y lo pruebas en el ambiente de pruebas.
Si el producto de software cumple con los requisitos, se instala y funciona adecuadamente, se obtiene la homologación del producto.
Pruebas de Telecomunicaciones
Esta prueba se realiza en un laboratorio que permite simular la latencia y el ancho de banda de todas las oficinas, desde canales de 56 Kbps hasta canales Giga.
Durante las pruebas de telecomunicaciones se verifica el consumo de ancho de banda. El consumo de ancho de banda es diferente para aplicaciones Web y para aplicaciones C/S. En aplicaciones web se impone una restricción por página, mientras que por la naturaleza de las aplicaciones C/S se impone una restricción por consulta.
Las inconformidades son registradas en el BugTracker. Si el producto no logra obtener los puntajes establecidos como política de la organización, no se le concede la certificación de telecomunicaciones y se pasa al ciclo de desarrollo nuevamente. Si el producto logra los puntajes establecidos, el producto obtiene la certificación de telecomunicaciones.
La experiencia indica que los productos que se desempeñan adecuadamente en telecomunicaciones tendrán un comportamiento adecuado en tiempo de respuesta y son menos propensos a sufrir problemas rendimiento.
Las herramientas utilizadas en este proceso son:
· Laboratorio de pruebas
· Simulador de canales
· Sniffer
· BugTracker
Pruebas de Bases de Datos
El objetivo de las pruebas de bases de datos es identificar posibles cuellos de botella debidos a queries ineficientes o estructuras de datos poco optimizadas.
Algunos puntos que se tienen en cuenta:
· Full scan de tablas, es decir, uso ineficiente de índices
· Bloqueos o deadlock
· Alto consumo de memoria
· Alto consumo de procesador
Las herramientas utilizadas en este proceso son:
· Consola de administración de base de datos
· Laboratorio de pruebas
· BugTracker
· Hoja de cálculo con el informe del DBA
Las inconformidades son registradas en el BugTracker y el producto debe ser corregido y preparado para el siguiente ciclo de pruebas. Si el producto cumple con todas las pruebas, entonces se le otorga el certificado de bases de datos y puede continuar el proceso.
Esta es una de las pruebas más críticas para un software, pues indica el comportamiento que el sistema tendrá y su estabilidad. Aunque el ambiente de pruebas pretende simular el ambiente de producción, este último es mucho más complejo y sensible, de manera que si existe una pequeña falla de base de datos es imperativo su corrección, de lo contrario el problema se convertirá en un problema superlativo que afectará de una manera importante al software.
Pruebas de Seguridad
Las pruebas de seguridad son un conjunto de pruebas encaminadas a lograr un nivel de seguridad adecuado, establecido por el área de seguridad informática.
Estas pruebas consisten en una batería de pruebas previamente diseñadas que abarcan desde el aseguramiento del medio de transporte pasando por técnicas de cross-site scripting y SQL Injection.
La batería de pruebas de seguridad no es divulgada. Los especialistas en seguridad las ejecutan y reportan el tema en el cual la aplicación debe mejorar, pero evitan divulgar la manera de explotar la vulnerabilidad.
Las herramientas utilizadas para las pruebas son:
· Laboratorio de pruebas
· Sniffers
· Reverse-Proxy
· Otras herramientas de seguridad
Pruebas de Estrés
Por experiencia, las pruebas de estrés son el ítem más importante de las pruebas técnicas, pues son estas las que exigen al máximo todo el conjunto de componentes del software y permiten hallar fallas estructurales que ponen en riesgo la viabilidad del software. En gran medida, una buena definición de la arquitectura del software evitará problemas en las pruebas de estrés, pero no lo garantiza.
La experiencia indica que para que el software se comporte bien bajo cargas extremas, su arquitectura debe ser sencilla y robusta, evitando complicaciones innecesarias y artificios inoficiosos.
Siempre, durante el diseño del software, se debe tener en cuenta el perfil de la aplicación, es decir, el nivel de transaccionalidad, el tamaño del público objetivo, la proporción de usuarios concurrentes y otros temas muy importantes que afectan la escalabilidad.
Aunque las pruebas de estrés nunca han logrado replicar la carga de los ambientes de producción, si logran detectar problemas estructurales que deben ser corregidos.
Las herramientas utilizadas son:
· Laboratorio de pruebas
· Herramienta de estrés de aplicaciones
· Sniffer
· Consolas de monitoreo
Durante una prueba de estrés se monitorean todos los frentes de manera conjunta; bases de datos, servidores de aplicaciones, otros repositorios de datos, redes, etc...
Si la aplicación logra mantener sus niveles de errores en cero al nivel de concurrencia objetivo la aplicación obtiene el certificado de pruebas de estrés. De lo contrario se registra la no conformidad en el BugTracker y se prepara un segundo ciclo de pruebas de estrés
Evaluación de calidad mediante ejecución de pruebas funcionales
Las pruebas funcionales son llevadas a cabo en de dos maneras: a través de testers y a través de usuarios del sistema.
Los casos de prueba son levantados durante el proceso de desarrollo de la aplicación y sobre todo, durante el proceso de homologación por el analista de calidad asignado para el producto.
Al finalizar el proceso de desarrollo, el analista de desarrollo debe certificar que el sistema pasa los casos de prueba levantados por el analista de pruebas. Después del proceso de homologación, en el cual se instala la aplicación en el ambiente de laboratorio, los testers o los usuarios finales ejecutan los casos de prueba y registran bug en el BugTracker. Se realizan las correcciones y se inicia un segundo ciclo de pruebas, después del cual se deben haber corregido estos problemas y el producto debe estar listo para su paso a producción.
La experiencia indica que cuando se han contratado el servicio de testing el proceso de pruebas funcionales ha sido muy efectivo, sin embargo, existen problemas importantes de costo. El esquema de testing se asemeja a un taxímetro, ya que cada hora que el tester pasa en las instalaciones de la compañía es facturada y si surgen inconvenientes de plataforma o de desarrollo, ese es tiempo facturado que no ha sido productivo en términos de pruebas.
En caso de un producto desarrollado a la medida, el software ya debió haber sido probado por el proveedor. Existe una corriente de pensamiento que asegura que el servicio de testing debe ser pagado por el proveedor sin cargo directo al cliente, pues este último espera un producto de calidad. Sin embargo persiste el esquema en el cual, aunque el producto es desarrollador a la medida, los testers corren por cuenta de la compañía.
Herramientas:
· Metodología de pruebas funcionales
· BugTracker
· Laboratorio de pruebas
Gestión de la Calidad
El ciclo PHVA (Planear, Hacer, Validar, Actuar) indica que después planear y hacer las cosas se requiere validar que el proceso sea efectivo y se debe actuar sobre el proceso para mejorarlo. En general, la herramienta fundamental para la gestión de calidad es el BugTracker, pues contiene la evidencia objetiva que permite obtener estadísticas sobre los niveles de calidad de los productos que diariamente se pruebas en la compañía.
Además de la gestión de la calidad durante el proceso de desarrollo, existe la gestión de la calidad posimplantación, es decir, cuando inicia el ciclo de mantenimiento. Este ciclo es vital, pues logra mantener el producto de software vigente. La gestión de la calidad del producto en ciclo de mantenimiento se logra a través de Tickets, que son incidentes reportados por los usuarios finales y que deben ser resueltos por los analistas con unos niveles de servicio previamente pactados.
Tanto los reportes del BugTracker como los Tickets son indicadores que entran en el proceso de evaluación de la gerencia, de los ejecutivos y de los analistas. Desde este punto de vista se gestiona el proceso de desarrollo y por lo tanto de la calidad de los productos de software.
jueves, julio 28, 2005
Cómo documentar la arquitectura
Para un proyecto relacionado con metodología de desarrollo que estoy llevando a cabo, estoy planteando la forma de documentar la arquitectura de las aplicaciones. Este es un reto interesante porque el tipo de arquitectura y las habilidades de los analistas y los proveedores son muy diferentes. Por un lado, algunos tienen un conocimiento bastante profundo del tema mientras que otros no le ven el sentido a este tipo de documento.
Dentro de las referencia que he revisado, creo haber encontrado un buen punto de partida, que aunque muy formal, se puede modificar para que sea práctico. La plantilla de word puede ser descargada de aquí.
Además, he estado revisando el documento clásico de Kruchten de Rational Rose: “The 4+1 View Model of Software Architecture”. El contenido es interesante en cuanto a concepto, pero creo que la técnica es bastante anticuada.
La nueva tendencia es documentar las vistas según se necesite y utiliza el concepto de punto de vista para evidenciar cómo la solución arquitectónica abordará las problemática que los clientes quieren solucionar.
Dentro de las referencia que he revisado, creo haber encontrado un buen punto de partida, que aunque muy formal, se puede modificar para que sea práctico. La plantilla de word puede ser descargada de aquí.
Además, he estado revisando el documento clásico de Kruchten de Rational Rose: “The 4+1 View Model of Software Architecture”. El contenido es interesante en cuanto a concepto, pero creo que la técnica es bastante anticuada.
La nueva tendencia es documentar las vistas según se necesite y utiliza el concepto de punto de vista para evidenciar cómo la solución arquitectónica abordará las problemática que los clientes quieren solucionar.
martes, julio 26, 2005
Guía del Arquitecto
Tengo el proyecto de escribir un libro corto, y más que un libro corto, una guía para el arquitecto de software. El rol que debe ejecutar este persona es muy importante dentro de las organizaciones de TI y por ello se debe especificar de manera adecuada, no tanto las funciones, sino sus valores, su perfil y las habilidades que debe cultivar.
Con el fin de compartir la experiencia que tengo en el tema, especialmente para Colombia, voy a desarrollar la guía del arquitecto.
La idea fundamental es que el rol de arquitecto está por encima de la tecnología que utilice o prefiera, que son cosas distintas. El arquitecto utiliza ciertas tecnologías para lograr que los sistemas y la plataforma en general, solucione las necesidades de sus clientes.
Por lo tanto la guía será “agnóstica” en cuanto a tecnología, pero totalmente enfocada al rol como yo lo percibo.
Con el fin de compartir la experiencia que tengo en el tema, especialmente para Colombia, voy a desarrollar la guía del arquitecto.
La idea fundamental es que el rol de arquitecto está por encima de la tecnología que utilice o prefiera, que son cosas distintas. El arquitecto utiliza ciertas tecnologías para lograr que los sistemas y la plataforma en general, solucione las necesidades de sus clientes.
Por lo tanto la guía será “agnóstica” en cuanto a tecnología, pero totalmente enfocada al rol como yo lo percibo.
miércoles, marzo 23, 2005
26 años
Este mes cumplí 26 años. La verdad ha sido un poco complicado porque crucé una barrera sicológica, quiero decir: cuando uno cumple 25 todavía está jóven y te dicen: Feliz cumpleaños, como estas de joven. Ahora que cumplí 26 ya oí la frase: Feliz Cumpleaños y que cumplas muchos más.
Hablando en serio, creo que voy por buen camino y este siguiente año de mi vida tengo tres proyectos muy importantes de los cuales el matrimonio es el más importante y, que espero, sea el que me impulse aun más, para alcanzar mis metas.
Algo que a veces, por la rutina del trabajo y la comodidad de lo conocido, se olvida, son los sueño que se tenían desde muy joven o por qué no, desde niño. Ahora voy a retomar esos sueños y haré todo lo posible por hacerlos realidad.
Hablando en serio, creo que voy por buen camino y este siguiente año de mi vida tengo tres proyectos muy importantes de los cuales el matrimonio es el más importante y, que espero, sea el que me impulse aun más, para alcanzar mis metas.
Algo que a veces, por la rutina del trabajo y la comodidad de lo conocido, se olvida, son los sueño que se tenían desde muy joven o por qué no, desde niño. Ahora voy a retomar esos sueños y haré todo lo posible por hacerlos realidad.
lunes, febrero 28, 2005
Quiero/Odio a Colombia
A veces me levanto, veo las noticias y a pesar de la ola de atentados, robos, huelgas, corruptos, entre otros muchos males, me digo: Por este país vale la pena luchar. Salgo de mi casa y me dedico a trabajar duro, a tratar de demostrar bueno valores en la gente que me rodea y en general a luchar porque el país en donde nací salga adelante.
De pronto siento que me quitan una venda de los ojos y veo la realidad tal y como es. Una elite dispuesta a sacrificar la vida de los millones de colombianos, una elite concentrada en exprimir hasta la última gota de sudor, y peor, hasta la última gota de sangre, con el propósito de defender su estatus y su riqueza. Pasan por encima de la salud, de la dignidad, de la infancia, de la juventud, del honor, de la honestidad y hasta de la ley, con el fin de perpetuar su prebendas.
Una guerrilla sanguinaria, sin norte político, convertida en un cáncer cocalero y dedicada a la extorsión, a las matanzas, a las torturas, a la despreciable práctica del secuestro.
Unos paramilitares totalmente inhumanos, ladrones de tierras y ganado, apoyados por los terrateniente y, por qué no decirlo, cobijados por el ejército de la república. Que espectáculo tan deplorable y vergonzoso.
Peor aun, cuando pienso en que la esperanza está en las personas comunes, en los profesionales, en las personas educadas, veo como se replican las misma costumbres, o mejor dicho, los mismos nefastos vicios de "la elite": La exclusión, el arribismo, el consumismo, la mentira, la hipocresía, y lo que es peor, una cegues voluntaria hacia los males del país, una negación de su propia cultura y una estúpida perpetuación de lo mismo de siempre.
Es entonces cuando empiezo a odiar a este país, que no hace nada por cambiar, que se deja manipular como al poder de turno le dé la gana. ¡Es que los que tenemos las culpa de todo somos los que nos dejamos manejar como títeres! ¿Por qué no nos damos cuenta de eso? ¿Por qué votamos por los mismos de siempre, por la misma retórica añejada y mentirosa, por la violencia, por el capitalismo a ultranza? ¡Por qué lo permitimos!
Después de tanta rabia y dolor de patria, leo cómo nos ven los franceses: "como una nación de narcotraficantes y bandidos". Después pienso en cómo dejaron plantado a nuestro presidente en el congreso europeo, después veo como nos desprecian en la embajadas. Esta visión de nosotros a través de los ojos de los de afuera tiene que indicarnos algo, ¿Quién es tan ciego y tan sordo para ignorarlo? ¡Algo está muy mal, algo apesta aquí adentro! Y nosotros, inocentes y pensando en que somos maltratados nos limitamos en pensar que pobres de nosotros, que somos maltratados y discriminados por culpa de unos cuantos malos. ¿Unos cuantos malos? Yo pregunto ¿Quien tiene la culpa de no obligar al cambio? Pues nosotros mismos, pues nos aguantamos, y lo que es peor, perpetuamos la barbarie, la corrupción y la cultura de la "viveza".
Entonces, es cuando empiezo a pensar si esta país sí vale la pena. Si vale el miedo que se siente todos los días, la incertidumbre económica, el subdesarrollo y humillación y la intolerancia entres nosotros mismos.
De pronto siento que me quitan una venda de los ojos y veo la realidad tal y como es. Una elite dispuesta a sacrificar la vida de los millones de colombianos, una elite concentrada en exprimir hasta la última gota de sudor, y peor, hasta la última gota de sangre, con el propósito de defender su estatus y su riqueza. Pasan por encima de la salud, de la dignidad, de la infancia, de la juventud, del honor, de la honestidad y hasta de la ley, con el fin de perpetuar su prebendas.
Una guerrilla sanguinaria, sin norte político, convertida en un cáncer cocalero y dedicada a la extorsión, a las matanzas, a las torturas, a la despreciable práctica del secuestro.
Unos paramilitares totalmente inhumanos, ladrones de tierras y ganado, apoyados por los terrateniente y, por qué no decirlo, cobijados por el ejército de la república. Que espectáculo tan deplorable y vergonzoso.
Peor aun, cuando pienso en que la esperanza está en las personas comunes, en los profesionales, en las personas educadas, veo como se replican las misma costumbres, o mejor dicho, los mismos nefastos vicios de "la elite": La exclusión, el arribismo, el consumismo, la mentira, la hipocresía, y lo que es peor, una cegues voluntaria hacia los males del país, una negación de su propia cultura y una estúpida perpetuación de lo mismo de siempre.
Es entonces cuando empiezo a odiar a este país, que no hace nada por cambiar, que se deja manipular como al poder de turno le dé la gana. ¡Es que los que tenemos las culpa de todo somos los que nos dejamos manejar como títeres! ¿Por qué no nos damos cuenta de eso? ¿Por qué votamos por los mismos de siempre, por la misma retórica añejada y mentirosa, por la violencia, por el capitalismo a ultranza? ¡Por qué lo permitimos!
Después de tanta rabia y dolor de patria, leo cómo nos ven los franceses: "como una nación de narcotraficantes y bandidos". Después pienso en cómo dejaron plantado a nuestro presidente en el congreso europeo, después veo como nos desprecian en la embajadas. Esta visión de nosotros a través de los ojos de los de afuera tiene que indicarnos algo, ¿Quién es tan ciego y tan sordo para ignorarlo? ¡Algo está muy mal, algo apesta aquí adentro! Y nosotros, inocentes y pensando en que somos maltratados nos limitamos en pensar que pobres de nosotros, que somos maltratados y discriminados por culpa de unos cuantos malos. ¿Unos cuantos malos? Yo pregunto ¿Quien tiene la culpa de no obligar al cambio? Pues nosotros mismos, pues nos aguantamos, y lo que es peor, perpetuamos la barbarie, la corrupción y la cultura de la "viveza".
Entonces, es cuando empiezo a pensar si esta país sí vale la pena. Si vale el miedo que se siente todos los días, la incertidumbre económica, el subdesarrollo y humillación y la intolerancia entres nosotros mismos.
martes, febrero 22, 2005
Trabajo, trabajo, trabajo
Llevo tres semanas trabajando fuertemente para sacar la versión cinco de uno de mis proyectos a producción. Ha sido duro y muy complicado. Hoy finalmente, el sistema se comportó bien en producción y pienso que la migración se llevará a cabo mañana por la noche con la ayuda de los demás analistas. Esperamos que todo termine bien.
Hoy entregué la hoja de vida de Carolina para aprovechar una buena oportunidad que tenemos. Fue una sensación extraña porque, aunque me he preocupado por sus cosas desde hace mucho tiempo, ahora siento que esa oportunidad es una oportunidad compartida, es algo que sería bueno para los dos en conjunto. No quiero decir que antes no fuera bueno, sino que nuestros planes cercanos han cambiado la forma de ver las cosas. Muy extraño, pero muy bueno.
Para continuar con el tema del trabajo: Espero que cumpla las metas que tengo de preparar un portafolio de servicios para este año. Es una meta interesante pero con la ayuda de un compañero es probable que lo logremos.
Hoy entregué la hoja de vida de Carolina para aprovechar una buena oportunidad que tenemos. Fue una sensación extraña porque, aunque me he preocupado por sus cosas desde hace mucho tiempo, ahora siento que esa oportunidad es una oportunidad compartida, es algo que sería bueno para los dos en conjunto. No quiero decir que antes no fuera bueno, sino que nuestros planes cercanos han cambiado la forma de ver las cosas. Muy extraño, pero muy bueno.
Para continuar con el tema del trabajo: Espero que cumpla las metas que tengo de preparar un portafolio de servicios para este año. Es una meta interesante pero con la ayuda de un compañero es probable que lo logremos.
miércoles, febrero 16, 2005
EPICO - Esto lo debí hacer hace rato
Este es el link hacia la página de "El Colombiano" en donde registraron la noticia del premio que ganamos en Panamá en el marco de la Ibero American Science and Technology Education Consortium
El proyecto que desarrollamos durante casi dos años consistía en un robot programables más un entorno de desarrollo en el cual se programaba mediante un lenguaje natural. El paquete completo esta enfocado hacia la enseñanza de la programación a los niños.
Hubo varios involucrados en el proyecto, en donde mi papel principal tuvo que ver con la programación del PIC en sus fases iniciales, desarrollo de un sensor de luz y del desarrollo la transmisión infrarroja entre el computador y el robot utilizando la codificación Manchester.
El proyecto que desarrollamos durante casi dos años consistía en un robot programables más un entorno de desarrollo en el cual se programaba mediante un lenguaje natural. El paquete completo esta enfocado hacia la enseñanza de la programación a los niños.
Hubo varios involucrados en el proyecto, en donde mi papel principal tuvo que ver con la programación del PIC en sus fases iniciales, desarrollo de un sensor de luz y del desarrollo la transmisión infrarroja entre el computador y el robot utilizando la codificación Manchester.
martes, febrero 15, 2005
Viaje a Francia: Paris - Cote D'Azur - Euro Disney
Entre el 24 de diciembre de 2004 y el 9 de enero de 2005, estuve en Francia visitando a mi novia. Ella está haciendo una pasantía en un laboratorio de una importante universidad de París.
La Tour Eiffel. La edificación simbólica más reconocida en el mundo
El viaje lo dividimos en dos, primero, conociendo París. Es una cuidad increible. Es organizada, llena de cultura, llena de gusto, con un increible sistema de transporte másivo. Lo único malo de París es la frace "C'est Ferme", es decir, está cerrado. Lo curioso de la frase, es que cada vez que ibamos a visitar algo interesante, que ibas a ir a cine, o algún plan fuera de los típicos muses, la frase aparecía "C'est Ferme".
En segunda parte del viaje, tuvimos a inolvidable experiencia de viajar por la Cote d'Azur, es decir, la famosísima riviera francesa o Costa Azul. Primero viajamos de París a Marsella en TVG. El recorrido duró unas tres horas. Luego de Marsella viajamos a Nice, en donde tomamos una habitación en un hotel económico y excelente, el Baccarat.
Desde Nice puedios viajar a Mónaco, Nice y a Cannes, que en tren, no quedaban a más de 30 minutos.
Cervecería de Cannes. Una de las cosas que más me gustaron de Francia es la variedad de cervezas que puedes probar. En esta fotos estamos en una cervecería de Can. Pedimos una cerveza rubia y una de cidra.
Estas cuidades te halan y te obligan a disfrutar cada paso que das sobre sus calles. Llenas de colores, de gente; algunas, como Cannes y Mónaco, llenas de opulencia.
Carolina y yo llendo hacia la Isla Sante Margarite, en donde se encuentra el fuerte del hombre de las máscara de hierro. Esta isla queda a 15 minutos en ferri desde Cannes.
Vista panorámica desde la basílica de Marseille. Una impresionante catedral ubicada ena colina en medio de la cuidad. Desde las alturas Notre-Damme de la Garde (Nuestra Señor de la Guardia) vigila la entrada al puerto y los movimientos de la ciudad.
La Tour Eiffel. La edificación simbólica más reconocida en el mundo
El viaje lo dividimos en dos, primero, conociendo París. Es una cuidad increible. Es organizada, llena de cultura, llena de gusto, con un increible sistema de transporte másivo. Lo único malo de París es la frace "C'est Ferme", es decir, está cerrado. Lo curioso de la frase, es que cada vez que ibamos a visitar algo interesante, que ibas a ir a cine, o algún plan fuera de los típicos muses, la frase aparecía "C'est Ferme".
En segunda parte del viaje, tuvimos a inolvidable experiencia de viajar por la Cote d'Azur, es decir, la famosísima riviera francesa o Costa Azul. Primero viajamos de París a Marsella en TVG. El recorrido duró unas tres horas. Luego de Marsella viajamos a Nice, en donde tomamos una habitación en un hotel económico y excelente, el Baccarat.
Desde Nice puedios viajar a Mónaco, Nice y a Cannes, que en tren, no quedaban a más de 30 minutos.
Cervecería de Cannes. Una de las cosas que más me gustaron de Francia es la variedad de cervezas que puedes probar. En esta fotos estamos en una cervecería de Can. Pedimos una cerveza rubia y una de cidra.
Estas cuidades te halan y te obligan a disfrutar cada paso que das sobre sus calles. Llenas de colores, de gente; algunas, como Cannes y Mónaco, llenas de opulencia.
Carolina y yo llendo hacia la Isla Sante Margarite, en donde se encuentra el fuerte del hombre de las máscara de hierro. Esta isla queda a 15 minutos en ferri desde Cannes.
Vista panorámica desde la basílica de Marseille. Una impresionante catedral ubicada ena colina en medio de la cuidad. Desde las alturas Notre-Damme de la Garde (Nuestra Señor de la Guardia) vigila la entrada al puerto y los movimientos de la ciudad.
Suscribirse a:
Entradas (Atom)