1. Escribir la presentación en PowerPoint no es preparar la presentación. Una presentación es un discurso que tiene como objetivo informar y persuadir a un público. Este objetivo no se logra con ideas plasmadas como frases en viñetas, se logra con un discurso bien estructurado y articulado. El primer paso para una presentación es escribir el contenido de la misma en un procesador de texto.
2. Los efectos, las transiciones, las animaciones, solo deben usarse para apoyar la expresión de la idea. PowerPoint ofrece una amplia variedad de opciones gráficas que pueden beneficiar, o más comúnmente, perjudicar una presentación. ¿Quién no ha visto el efecto de "aparición" usado en una presentación? Es terrible: el presentador no sabe cuantas veces hacer clic para que la diapositiva se despliegue completamente, y cuando lo hace, se pasa por error a la siguiente. El auditorio pierde la concentración y el presentador el hilo de su argumento. El resultado neto sobre el público es negativo con respecto al objetivo del presentador.
3. Los errores ortográficos y semánticos disminuyen el impacto de un buen argumento. Imagínese en una presentación en la cual le están ofreciendo un servicio de consultoría, ahora imagine que el proveedor está sosteniendo un buen argumento, ha logrado quebrar el hielo y despertar el interés de todos. Los asistentes están atentos y de repente, en la siguiente diapositiva aparece la frase "Un jiro en su extrategia de seguridad". ¿Con qué credibilidad cuenta ahora el presentador?
4. Agenda, Introducción, desarrollo, conclusiones, resumen. Al preparar una presentación, tener en cuenta estas fases ayuda a organizar el trabajo. La agenda presenta los temas que van a ser tratados, debe incluir el tiempo total de la presentación y, si participan varias personas, los momentos de su participación. Esto ayuda a coordinar a los presentadores y a que la audiencia esté preparada para los cambios y para la duración, diminuyendo la ansiedad y mejorando su concentración. La introducción no es el resumen de la presentación, esta sección contextualiza al auditorio, establece el tono y abre la puerta para el desarrollo de la presentación. Las conclusiones son los mensajes que el presentador quiere dejar claros, es la impresión en la retina del auditorio. El resumen permite que el auditorio repase mentalmente el contenido de la presentación y determine cuales puntos quedaron claros y cuales no.
5. La práctica hace al encantador de serpientes. Un fórmula exitosa para el una presentación débil es no practicar la presentación. Improvisar efectivamente es un arte dominado por muy pocos. Asegúrese de realizar la presentación a un conjunto de personas de confianza, con ello podrá comprobar usted mismo que tan convincente es su presentación y qué tan estructurada está. Sus compañeros podrán realizarle críticas constructivas y resaltar los puntos débiles y confusos.
Finalmente, un poco de suerte también ayuda.
jueves, agosto 31, 2006
viernes, agosto 04, 2006
Documentación de Integración de Aplicaciones
Estoy seguro de que un muchas compañías (no orientadas al desarrollo de software) la mayoría de sus proyectos nuevos tiene que ver con la integración de aplicaciones existentes a diferencia de desarrollar sistemas nuevos que apoyen verticalmente un producto. Esta situación se da por muchas razones, entre ellas el hecho que las compañías hoy en día se orientan más a procesos de negocio que ha verticales de producto, pues contiene más valor para el cliente (y para la compañía) ofrecer por ejemplo una administración de riesgos que un seguro de vida, uno de autos y uno de hogar; ofrecer un mantenimiento de vehículo que un cambio de llantas, un cambio de aceite y una revisión de gases. En fin, hoy las compañías se preocupan por entregar mayor valor en forma de servicios que entregar productos puntuales.
De igual manera hay razones técnicas para que en las áreas de TI pensemos y ofrezcamos a nuestros clientes (las áreas de negocio, en este caso) integración entre aplicaciones y no aplicaciones verticales y monolíticas. Entre estas razones se encuentra el hecho que ya tenemos mucha lógica de negocio probada y flexible. Estos componentes pueden reutilizase en diferentes situaciones ajustando algunos parámetros o haciendo pequeñas adecuaciones. La reutilización disminuye los costos de desarrollo y mantenimiento, estos últimos siendo los más importantes.
Hasta aquí todo muy bonito y de alto nivel. Ahora, cuando nos remangamos la camisa y empezamos a trabajar como ingenieros de software, es cuando empezamos a encontrar dificultades. En este artículo corto quiero reseñar el problema del análisis de proyectos de integración y presentar, de manera muy resumida, la solución que he encontrado más adecuada.
En los proyectos de integración existen dos formas de analizar el problema: las aplicaciones que intervienen en el proceso y las integraciones entre dichas aplicaciones. A las primeras se les llaman frentes de trabajo, a las segundas, simplemente integraciones.
Generalmente, un frente ya se encuentra maduro, tiene unos usuarios líderes que conocen del negocio y los analistas dueños del software conocen bien los detalles de la implementación. Un frente recibe un conjunto de requerimientos, generalmente como un documento de especificación de requisitos. El frente realiza sus ajustes y está preparado para especificar los puntos de integración. Hasta aquí el proceso común y corriente que venimos haciendo desde hace ya mucho tiempo.
Las integraciones son un poco diferentes en el sentido que no son un producto concreto, sino que se materializan en las colaboraciones que ocurren de manera ordenada y con un conjunto de reglas semánticas específicas entre dos o más sistemas. La lógica de integración se encuentra en las aplicaciones involucradas en la interacción (y si existe un software de integración, allí también existirá lógica de integración). El análisis y el diseño de las integraciones requiere que un equipo del proyecto que se responsabilice por la coordinación, acuerdo y documentación de cada integración. El equipo de integración no necesariamente es quien realiza las actividades pero si tiene la responsabilidad de que las cosas se hagan y sobre todo, de la comunicación clara y oportuna entre todas las partes.
Para documentar las integraciones recomiendo utilizar dos tipos de diagrama UML: el diagrama de actividades y el diagrama de secuencia. El diagrama de actividades puede usarse en integraciones complejas que requieren muchas condiciones. Los carriles (o swinlanes) representan a los sistemas que se están integrando y las actividades a las operaciones que un sistema particular ejecuta. Las integraciones al nivel de datos se modelan utilizando DataStores, las invocaciones a métodos (WebServices, RPC, DCOM, Corba, etc.) se modela con Control Flows entre actividades. En cada “flecha” se deben documentar los parámetros y las reglas o semántica de la invocación. En las actividades se documenta la operación que se realiza, la entrada que se espera y la salida que se genera.
Cuando ocurre una integración que no tiene muchas condiciones, resulta más útil y expresivo (por el tema de la ubicación de los mensajes en el tiempo) el diagrama de secuencia. En este diagrama, los sistemas son los objetos que se pasan mensajes. Los mensajes contienen los parámetros y la semántica. Una ventaja de estos diagramas es que si se utiliza una buena herramienta se obtendrá “gratuitamente” cada uno de los métodos de integración de los sistemas.
La elaboración de los diagramas tiene dos objetivos fundamentales: el análisis de la integración y la generación documentación suficiente para realizar pruebas de integración. El análisis es una actividad importante, pues una cosa es contar en palabras cómo debe ser la integración y otra modelar con mayor detalle las interacciones entre los sistemas. En esta segunda situación se descubren aspectos que no se habían tenido en cuenta y se aclaran conceptos entre los integrantes de la integración. Este es un ejercicio grupal, nunca un ejercicio individual; con esto quiero decir que no debe existir el “Arquitecto” todo poderoso e infalible que dicta como se realizan las integraciones. Todo lo contrario, este es un proceso de construcción colectiva.
La generación de documentación es un punto crítico, pues es muy diferente probar un frente (mediante casos de prueba levantados a partir de los casos de uso del sistema) comparado con probar un proceso integrado de negocio. Las integraciones quedarán documentadas como diagramas de actividades y diagramas de secuencia, con comentarios en los mensajes o en los pasos de control y con notas sobre las actividades o sobre los objetos que participan en las interacciones. La estrategia que considero más acertada consiste en que los diseñadores de pruebas entiendan los diagramas y tomen los sistemas de un escenario de integración como cajas negras. El resultado de esta estrategia son casos de prueba de tipo: conjunto de datos de prueba, procesamiento y resultado o comportamiento esperado.
Mi conclusión principal es la necesidad de conformar un equipo con la responsabilidad específica del análisis y documentación de las integraciones, de otro modo la comunicación estará llena de ruido y por lo tanto la probabilidad de éxito del proyecto se verá seriamente afectada.
De igual manera hay razones técnicas para que en las áreas de TI pensemos y ofrezcamos a nuestros clientes (las áreas de negocio, en este caso) integración entre aplicaciones y no aplicaciones verticales y monolíticas. Entre estas razones se encuentra el hecho que ya tenemos mucha lógica de negocio probada y flexible. Estos componentes pueden reutilizase en diferentes situaciones ajustando algunos parámetros o haciendo pequeñas adecuaciones. La reutilización disminuye los costos de desarrollo y mantenimiento, estos últimos siendo los más importantes.
Hasta aquí todo muy bonito y de alto nivel. Ahora, cuando nos remangamos la camisa y empezamos a trabajar como ingenieros de software, es cuando empezamos a encontrar dificultades. En este artículo corto quiero reseñar el problema del análisis de proyectos de integración y presentar, de manera muy resumida, la solución que he encontrado más adecuada.
En los proyectos de integración existen dos formas de analizar el problema: las aplicaciones que intervienen en el proceso y las integraciones entre dichas aplicaciones. A las primeras se les llaman frentes de trabajo, a las segundas, simplemente integraciones.
Generalmente, un frente ya se encuentra maduro, tiene unos usuarios líderes que conocen del negocio y los analistas dueños del software conocen bien los detalles de la implementación. Un frente recibe un conjunto de requerimientos, generalmente como un documento de especificación de requisitos. El frente realiza sus ajustes y está preparado para especificar los puntos de integración. Hasta aquí el proceso común y corriente que venimos haciendo desde hace ya mucho tiempo.
Las integraciones son un poco diferentes en el sentido que no son un producto concreto, sino que se materializan en las colaboraciones que ocurren de manera ordenada y con un conjunto de reglas semánticas específicas entre dos o más sistemas. La lógica de integración se encuentra en las aplicaciones involucradas en la interacción (y si existe un software de integración, allí también existirá lógica de integración). El análisis y el diseño de las integraciones requiere que un equipo del proyecto que se responsabilice por la coordinación, acuerdo y documentación de cada integración. El equipo de integración no necesariamente es quien realiza las actividades pero si tiene la responsabilidad de que las cosas se hagan y sobre todo, de la comunicación clara y oportuna entre todas las partes.
Para documentar las integraciones recomiendo utilizar dos tipos de diagrama UML: el diagrama de actividades y el diagrama de secuencia. El diagrama de actividades puede usarse en integraciones complejas que requieren muchas condiciones. Los carriles (o swinlanes) representan a los sistemas que se están integrando y las actividades a las operaciones que un sistema particular ejecuta. Las integraciones al nivel de datos se modelan utilizando DataStores, las invocaciones a métodos (WebServices, RPC, DCOM, Corba, etc.) se modela con Control Flows entre actividades. En cada “flecha” se deben documentar los parámetros y las reglas o semántica de la invocación. En las actividades se documenta la operación que se realiza, la entrada que se espera y la salida que se genera.
Cuando ocurre una integración que no tiene muchas condiciones, resulta más útil y expresivo (por el tema de la ubicación de los mensajes en el tiempo) el diagrama de secuencia. En este diagrama, los sistemas son los objetos que se pasan mensajes. Los mensajes contienen los parámetros y la semántica. Una ventaja de estos diagramas es que si se utiliza una buena herramienta se obtendrá “gratuitamente” cada uno de los métodos de integración de los sistemas.
La elaboración de los diagramas tiene dos objetivos fundamentales: el análisis de la integración y la generación documentación suficiente para realizar pruebas de integración. El análisis es una actividad importante, pues una cosa es contar en palabras cómo debe ser la integración y otra modelar con mayor detalle las interacciones entre los sistemas. En esta segunda situación se descubren aspectos que no se habían tenido en cuenta y se aclaran conceptos entre los integrantes de la integración. Este es un ejercicio grupal, nunca un ejercicio individual; con esto quiero decir que no debe existir el “Arquitecto” todo poderoso e infalible que dicta como se realizan las integraciones. Todo lo contrario, este es un proceso de construcción colectiva.
La generación de documentación es un punto crítico, pues es muy diferente probar un frente (mediante casos de prueba levantados a partir de los casos de uso del sistema) comparado con probar un proceso integrado de negocio. Las integraciones quedarán documentadas como diagramas de actividades y diagramas de secuencia, con comentarios en los mensajes o en los pasos de control y con notas sobre las actividades o sobre los objetos que participan en las interacciones. La estrategia que considero más acertada consiste en que los diseñadores de pruebas entiendan los diagramas y tomen los sistemas de un escenario de integración como cajas negras. El resultado de esta estrategia son casos de prueba de tipo: conjunto de datos de prueba, procesamiento y resultado o comportamiento esperado.
Mi conclusión principal es la necesidad de conformar un equipo con la responsabilidad específica del análisis y documentación de las integraciones, de otro modo la comunicación estará llena de ruido y por lo tanto la probabilidad de éxito del proyecto se verá seriamente afectada.
Suscribirse a:
Entradas (Atom)