tag:blogger.com,1999:blog-168343072024-03-12T20:57:07.967-07:00Gestionando la Plataforma Tecnológica de su OrganizaciónPrácticas, realidades y experiencias en arquitectura empresarial, arquitectura de software, gestión de proyectos y portafolios, desarrollo de software y gerencia de tecnología para grandes organizacionespedrogthttp://www.blogger.com/profile/05607207848250087678noreply@blogger.comBlogger12125tag:blogger.com,1999:blog-16834307.post-58575864845057164152015-04-05T22:45:00.001-07:002015-04-05T22:45:16.603-07:00¿Terminator una ficción?<table><tbody>
<tr><td><img src="http://cdn.bloody-disgusting.com/wp-content/uploads/2015/01/Screen-shot-2015-01-29-at-11.11.34-AM-620x400.png" height="206" id="irc_mi" style="margin-top: 11px;" width="320" />
</td><td>La verdad que la inteligencia artificial (IA) nunca me pareció demasiado inteligente y vi materias en pregrado y posgrado donde programé redes neuronales, algoritmos genéticos y muchas otras tendencias. En realidad me parecían algoritmos demasiado específicos que resolvían problemas demasiado específicos en un espacio demasiado acotado. Así que, Terminator siempre me pareció una súper ficción… hasta ayer!.
<br />
<br />
Recientemente escuchaba a Bill Gates haciendo una alerta sobre los peligros de la IA, me pareció
</td></tr>
</tbody></table>
exagerado pero si lo dice Bill… También esta semana leía un artículo de Wozniak (fundador de Apple) sumamente preocupado por el tema, diciendo que las máquinas son más poderosas analizando y resolviendo y no tardará mucho en que tomen roles gerenciales en las organizaciones y eventualmente… se deshagan de los humanos. Me pareció exagerado.
<br />
<br />
Ayer manejaba de un punto a 30 Km de mi destino en una ciudad que no conozco en hora pico. Siguiendo las indicaciones de Waze llegué en 25 minutos, sin nunca agarrar tráfico, pasé por un sinfín de callecitas y cruces que ni los vaquianos hubieran conectado, minimizó el número de semáforos y llegué al destino sin perderme y en tiempo y distancia óptima. WOW!.
<br />
<br />
No me quedó más que pensar en Wozniack… Por otro lado no tardarán en llegar los carros que no necesitan chofer, lo que será una mejora en el tráfico y esos carros con la inteligencia de los mapas y el tiempo real del tráfico serán insuperables, ¿quién querrá un taxista humano? ¡Yo no!.
<br />
<br />
La verdadera inteligencia Terminator no está en los algoritmos clásicos de IA, está en los sistemas que hacemos en el día a día, que ahora gracias a Internet logran conectarse en tiempo real con múltiples fuentes de datos y tomar decisiones acertadas.
<br />
<br />
Aparte esta semana seguía un hashtag patrocinado por Nokia #maketechhuman. Me sonaba inicialmente a usabilidad, tecnología ergonómica, agradable… no… se refiere a darle comportamientos humanos a los sistemas, toma de decisiones, predicciones sobre qué va a ocurrir, etc… están invirtiendo fuertemente en el tema.
<br />
<br />
Debemos temerle al futuro que pronostica Terminator? ya no me parece tan descabellado, al menos les llegará pronto a los choferes...
<br />
<br />
P.
<br />
<br />
PD: El Governator en las redes sociales es un rock star… increíble a sus 60 toda la energía que transmite.
pedrogthttp://www.blogger.com/profile/05607207848250087678noreply@blogger.com0tag:blogger.com,1999:blog-16834307.post-59389422457883291222012-07-29T06:09:00.001-07:002012-07-30T18:53:16.294-07:00Todos seremos genios... Hablando de Big Data<div align="center;">
<table><tbody>
<tr><td><img border="0" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjGQBkaZEbPwM-caFnkameO7rGo5V4zKYr0o9Y2R8857CDQUwiJkBPs3mBB228ocPhDTBMOHF4vdK9rXXZ6TRYbGI7zZe-0CSIz5GTey9isAjWpTAi1aB88qRZVG7rQsLKhg6_j/s200/chloe.jpg" width="133" />
</td><td><img border="0" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgbsSGmpEMopmjRG0sjyCSm6UkGL5V8JwLYQTYGcZ2sqpvJ4rlbqKmEKujvwZsoDFyuhgZRlq0yYgWx00S7g6C41Ld_Ova_Pcb3tCNW8EoIc0U8UTt2xYlIklt4gpP7mrZru3CL/s1600/cm.jpg" />
</td><td><img border="0" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhsco6-z30JqNqLllYIBimQ2Nz6tbHeodeLmroXcZzgmrmoT4u04kwfDdAy4ncCFZBcLP0fMLOSfaK_9AAVMmQxa06rTODaPhPUS-PF4BuotxFba_I9Guny7uKdcCO_ofg-njRU/s200/Birkoff-la-femme-nikita-883245_299_350.jpg" width="182" />
</td></tr>
</tbody></table>
</div>
<br />
En toda película de investigación o espionaje hay un personaje especialista en tecnología de gruesos lentes y escaso bronceado que suele ser capaz de averiguar cualquier cosa de cualquier persona. Intereses, gustos, ubicación, historial de compras y muchas otras cosas están disponibles en minutos tecleando algunos comandos. Típicamente esta información es clave para que luego unos investigadores armados hasta los dientes le echen el guante al individuo.<br />
<br />
En los últimos años con el surgimiento de las redes sociales se creó el caldo de cultivo para que las propias personas publicaran continuamente toda esa información que alguna vez requirió a un genio para buscarla y consolidarla. Una persona sale de casa y activa en <a href="http://www.waze.com/">Waze</a> su ruta, luego al llegar a su destino y hace checkin en <a href="http://www.foursquare.com/">Foursquare</a>, al salir hace un review del lugar. Más allá de eso tiene en <a href="http://www.linkedin.com/">Linkedin</a> su historia y competencias, en <a href="http://www.facebook.com/">Facebook</a> sus amigos y fotos y hasta <a href="http://www.twitter.com/">tuitea</a> lo que piensa u opina.<br />
<br />
Más allá de la buena o mala configuración de permisos que tú le des a toda esa información en cada plataforma, la información está allí en mayor o menor grado, disponible para ser usada.<br />
<br />
El concepto de Big Data inicia como una aproximación técnica para hacer posible el análisis de toda la gran cantidad de información que generan las empresas, para encontrar tendencias y análisis de valor para el negocio. Un ejemplo de que Big Data es realmente es "Big": <br />
<ul>
<li>Walmart maneja más de un millón de transacciones de clientes por hora, estas son almacenadas en bases de datos que se estiman tienen más de 2.5 petabytes - el equivalente a 167 veces la information contenida en todos los libros de la librería del congreso de USA.</li>
<li><a href="http://www.facebook.com/">Facebook</a> almacena más de 40 billones de fotos.</li>
</ul>
Trabajar con toda esta información es un reto debido a su volumen, variedad y múltiples orígenes. Hoy en día hay un auge tremendo de tecnologías de hardware y software para manejar, analizar, consolidar y poner a disposición el uso de lo que se podría llamar Big Data.<br />
<br />
En los últimos meses se han presentado más usos prácticos como la creación de los mecanismos para lograr el análisis y consolidación de toda esa información de las redes sociales y ponerla a disposición de personas o empresas para, en principio, poder entender mejor a sus clientes o potenciales clientes y venderle según sus intereses. Continuamente están apareciendo startups que aprovechan esta disciplina para llevar servicios de usuario final con transacciones financieras, tendencias de mercado o consumo, etc.<br />
<br />
Dentro poco tiempo todos podremos tener al alcance de la mano un poco de esa genialidad que aún vemos en los expertos de las películas y acceder en tiempo record información consolidada de múltiples fuentes sobre algo o alguien. De los genios no se preocupen, ya encontrarán trabajo inventando la nueva ola tecnológica que aún no conocemos<br />
<br />
En los últimos meses he trabajado en <a href="http://www.dbaccess.com/">DBAccess</a> en preparar una oferta de servicio que permite a las empresas entender qué tipo de información puede ser relevante y construir los mecanismos para extraer, consolidar y visualizar, aportando el negocio un beneficio que hasta ahora parecía difícil de alcanzar. Aún el uso de la información de las redes sociales es incipiente a nivel mundial, pero los resultados iniciales hablan de información muy valiosa.<br />
<br />
Ref:<br />
- Los personajes de la foto; Chloe de 24, de Criminal Minds y Birkoff de Femme Nikita.<br />
- Los datos de Walmart y Facebook tomados de <a href="http://www.wikipedia.org/">wikipedia</a>pedrogthttp://www.blogger.com/profile/05607207848250087678noreply@blogger.com0tag:blogger.com,1999:blog-16834307.post-43260976860703234602011-07-25T20:51:00.000-07:002011-07-25T21:19:02.148-07:008 Áreas de Acción para agregar Valor al Negocio desde TIEn el entorno innovador de la actualidad las organizaciones requieren agilidad para el cambio, agilidad para responder a los nuevos retos que el negocio se plantea. Por años firmas como Gartner vienen reportando resultados de encuestas a ejecutivos de grandes empresas que ven a sus áreas de tecnología como un inhibidor al cambio, como un elemento que resta agilidad a sus organizaciones.<br />
<br />
Es una constante equivocación la aproximación a la tecnología como un fin en sí mismo. Esta forma de proceder de algunos gerentes embarca a la organización en inversiones para incorporar tecnología, tendencias o enfoques de moda que no necesariamente agregan un beneficio claro al negocio. Escuchamos año tras año iniciativas de las áreas tecnológicas sin un impacto de negocio esperado y claramente definido. Existen muchas iniciativas de la tecnología por la tecnología que podrían presentarse como ejemplo.<br />
<br />
Los portafolios ejecutados por tecnología deben tener como objetivo apalancar las iniciativas del negocio, brindar la información necesaria para la toma de decisiones y habilitar la plataforma tecnológica para el cambio.<br />
<br />
Planteo 8 áreas de acción para la definición de iniciativas que agreguen valor al negocio. Sean proyectos de desarrollo o procura de sistemas, planteamientos de arquitectura, migraciones tecnológicas o mantenimiento de componentes existentes, valide si su proyecto se alinea con alguna de estas áreas, si la respuesta es no entonces piense nuevamente si el negocio justifica esta inversión.<br />
<br />
<b>1. Iniciativas y metas del negocio</b><br />
Cada período el negocio se plantea metas concretas de productividad, ingreso o eficiencia. También se plantea iniciativas estratégicas para adaptarse al entorno o para establecer una ventaja comparativa. Es la misión de toda la organización trabajar en torno a esas metas y colaborar desde su área.<br />
Las áreas de tecnología deben comprender las metas del negocio y utilizar el presupuesto en la forma que mejor apalanque esos resultados.<br />
<br />
<b>2. Mantenimientos que consumen el presupuesto </b><br />
Toda organización tiene componentes tecnológicos que período tras período, consumen un porcentaje importante de los recursos sin que se genere mayor beneficio al negocio, tampoco representan soluciones de raíz que disminuyan la inversión requerida para siguientes períodos. Son los verdaderos agujeros negros en la planificación presupuestaria de tecnología.<br />
Si está trabajando en cambiar y efectivamente resolver una de estas realidades entonces hará un aporte importante al negocio al garantizar holgura en el presupuesto para próximos períodos.<br />
<br />
<b>3. Quiebres entre tecnología y negocio </b><br />
En toda organización existen temas de discusión archi-conocidos en la mesa negocio - tecnología. Promesas incumplidas por años, sistemas inestables que dificultan la operación, necesidades de automatización no atendidas por nombrar algunas de las causas más comunes. En la realidad de una organización estos temas tienen nombre y apellido, asomarlos en la reunión despierta pasiones o dispara la ironía y el sarcasmo.<br />
Solucionar estas causas de quiebre mejorará con seguridad el servicio y la satisfacción del usuario, por ende el soporte al negocio.<br />
<br />
<b>4. Riesgos Operacionales/Financieros </b><br />
Con más frecuencia de lo que me gustaría veo en las plataformas tecnológicas de las empresas que visito, sistemas críticos para el negocio que operan bajo unos niveles de incertidumbre y riesgos muy alto.<br />
Trabajar en la mitigación o eliminación de estos riesgos protege al negocio de pérdidas económicas, problemas operaciones o incumplimiento de los acuerdos de servicio.<br />
<br />
<b>5. Vistas de información necesarias</b><br />
Hemos escuchado múltiples veces el reclamo de algún ejecutivo porque no tiene de forma oportuna o confiable una información crítica para el negocio. Existen organizaciones que dedican áreas enteras a generar manualmente las vistas de información y reportes ejecutivos que el negocio requiere y que las complejas y costosas plataformas tecnológicas con las que cuentan son incapaces de generar.<br />
<br />
Ofrecer información oportuna y confiable para la toma de decisiones es una de las principales funciones de la tecnología. Trabajar en generar las vistas de información necesaria dará agilidad al negocio. <br />
<b>6. Áreas más dinámicas del negocio </b><br />
Existen áreas de negocio en cada organización que son más sensibles al cambio, por la creación de nuevos productos, por impacto de nuevas regulaciones o por ser un negocio en continua trasformación. De la agilidad con que la plataforma tecnológica pueda adaptarse y apalancar el cambio en estas áreas dependerá en buena medida la agilidad de la organización.<br />
Las áreas de tecnología deben trabajar en mejorar la agilidad de las plataformas que soportan las áreas más dinámicas del negocio.<br />
<br />
<b>7. Elementos tecnológicos/información que le restan agilidad a la organización </b><br />
Toda plataforma tecnológica cuenta con algunos componentes que suelen estar en el camino crítico de múltiples iniciativas, dificultando el avance, aumentando el esfuerzo requerido y elevando la complejidad. Pueden ser sistemas legacy, repositorios con datos poco confiables o tecnologías desconocidas. Son pesos en las piernas que nos impiden correr.<br />
Invertir en eliminar efectivamente los puntos que nos restan agilidad traerá retorno para la organización al disminuir esfuerzos futuros y al ganar agilidad para adaptarse a los cambios.<br />
<br />
<b>8. Potencial de reducir complejidad o heterogeneidad</b><br />
<b> </b>La heterogeneidad eleva los costos porque se multiplica la inversión de mantenimiento en hardware, software y personal por los diferentes conocimientos requeridos. La heterogeneidad cuesta en el presente y en el futuro, disminuye el potencial de reutilización y racionalización, iniciativas como la virtualización se ven afectadas. En el abanico de tecnologías y soluciones de una organización menos es más.<br />
Simplificar la plataforma a través de la disminución de la heterogeneidad tecnológica debe ser un objetivo recurrente comprendido por todos los equipos del área.pedrogthttp://www.blogger.com/profile/05607207848250087678noreply@blogger.com0tag:blogger.com,1999:blog-16834307.post-61788078916051500602010-11-27T06:15:00.000-08:002010-11-27T09:15:10.587-08:00Mitos sobre la Arquitectura de SoftwareEn este post me refiero por Arquitectura específicamente a la Arquitectura de Solución. La que se diseña para la construcción de un producto de software.<br />
<br />
<b>Mito 1: La arquitectura de un sistema es Documentación</b><br />
<br />
Típicamente la palabra documentación trae una carga negativa de juicios que nos llevan a pensar que es algo repetitivo, que se hace posteriormente para cumplir, que agrega poco valor en general. Bajo esa definición de documentación la arquitectura definitivamente no lo es. La arquitectura se enfoca en diseñar efectivamente la solución a construir y en mucho menor grado en la posterior formalización de estos diseños. Diseñar la arquitectura de la solución en etapas tempranas acorta los tiempos de construcción, evita el retrabajo, mejora la mantenibilidad del sistema resultante y sienta bases sólidas para cumplir los atributos de calidad que el negocio requiere.<br />
<br />
Construirías una casa si ver antes la maqueta y los planos?.<br />
<br />
<b>Mito 2: Sólo aplica para sistemas grandes y complejos</b><br />
<br />
Antes de poner un bloque debes saber dónde se deben poner bloques y con qué objetivo, esto aplica independientemente de si construirás una pared, una casa o un edificio. Lo que suele ocurrir es que para sistemas muy pequeños la arquitectura es obvia o tradicional, mientras que para sistemas grandes hay muchas alternativas a considerar. En un sistema grande la arquitectura es difícil de comprender y asimilar en su totalidad. Todo sistema independientemente de su tamaño requiere una arquitectura, en muchos casos vale reutilizar una conocida.<br />
<br />
Para un sistema web en el que sólo haces login y llenas dos formularios, definirías típicamente una arquitectura de este estilo; una capa de interfaz, una capa de acceso a repositorio, algún componente de fachada entre estas capas, algunos objetos de negocio en los que viaja la información y excepciones para el manejo de errores. Podríamos pintar un par de diagramas de clase y un diagrama de secuencia con la interacción de los componentes. A eso le agregamos una selección de tecnología a usar y Voila! tenemos una arquitectura hecha en 5 minutos para un sistema que se programa en medio día. Necesitábamos una arquitectura? por supuesto que si!.<br />
<br />
He escuchado muchas veces decir "nosotros no necesitamos arquitectura porque todos los sistemas los hacemos igual y son sencillos"... ahh entonces reutilizan siempre la misma arquitectura que ya tienen diseñada y todos la conocen bien. Tienen un activo de conocimiento intangible y no se han dado cuenta.<br />
<br />
<b>Mito 3: La arquitectura no tiene nada que ver con el negocio</b><br />
<br />
La arquitectura debe diseñarse justamente para garantizar que la solución de cumplimiento a las necesidades de negocio. En un proceso formal partes por definir metas para la arquitectura en función de una norma como ISO-9126 de atributos de calidad de software. Seguridad, rendimiento, tolerancia a fallas, etc, etc... son atributos de calidad que se establecen dadas las necesidades del negocio, de la arquitectura de la solución depende lograr o no su cumplimiento y por lo tanto que el negocio cuente con la herramienta adecuada.<br />
<br />
Definiciones como la del SEI (<a href="http://www.sei.cmu.edu/architecture/index.cfm">http://www.sei.cmu.edu/architecture/index.cfm</a>) que establece en su formato de arquitectura los Stakeholder's Viewpoints, definen estrategias para acercar el documento de arquitectura a los involucrados del negocio, definiendo la trazabilidad entre las expectativas de estos y el diseño planteado para cumplirla.<br />
<br />
La tendencia es que cada vez más la arquitectura es visible al negocio. Así como los planos y maquetas en ingeniería civil son de mucho interés para quien solicita la construcción de una casa. Aprendamos de la madurez de la ingeniería civil y sus 2000 años de ventaja sobre la ingeniería de software, construirían su casa sin comprender antes la arquitectura planteada? definitivamente no.<br />
<br />
<b>Mito 4: la arquitectura es necesaria o no según la tecnología a utilizar o el conocimiento del equipo sobre la tecnología que aplica</b><br />
<br />
La arquitectura parte de un diseño agnóstico a la tecnología, que puede ser implementado y desplegado en diversas tecnologías y plataformas según lo que mejor se adecue a la necesidad o los skills con que el equipo cuente. No hay tecnologías que requieran o no arquitecturas, lo que ocurre es que algunas establecen en mayor o menor grado una arquitectura de referencia, incluso las herramientas de construcción te pueden llevar de la mano a implementar un estilo arquitectónico particular.<br />
<br />
Si se desea construir una solución mantenible y en base a mejores prácticas el diseño debe hacerse haciendo uso de los elementos del estilo arquitectónico que la tecnología propone, aprovechando sus capacidades.<br />
<br />
El diseño de la solución en función de las necesidades del negocio siempre es necesario. La arquitectura debe proponer estrategias claras para cubrir los atributos de calidad esperados del sistema y las expectativas del negocio, apalancándose en las fortalezas que plantea la tecnología utilizada.<br />
<br />
<b>Mito 5: Es un documento complejo que sólo consume el propio arquitecto</b><br />
<br />
El diseño de arquitectura tiene implicaciones directas en presupuesto, en costos de operación del procesos de negocio que soporta o automatiza, en la agilidad y efectividad que tendrán sus operarios, en la capacidad de aprovechar ese activo en futuros retos de negocio o nuevos productos. También otros impactos más técnicos como la mantenibilidad a futuro, la convivencia con otros elemento de la plataforma tecnológica o la capacidad que el equipo actual tenga para hacerse cargo de su mantenimiento.<br />
<br />
Es de gran utilidad la analogía con la ingeniería civil en este punto. Al construir un edificio los que solicitan la obra y que luego usarán el edificio desean estar involucrados en entender el diseño que se seguirá. Maquetas y planos son herramientas efectivas de comunicación entre los arquitectos e ingenieros y quienes contratan labora. Estar involucrados en estos diseños garantizará que la obra cubra las expectativas.<br />
<br />
Es necesario entender la construcción de sistemas de software como ingeniería, son obras en las que se invierten grandes cantidades de dinero y producen un activo que será utilizado por años. Según métricas conocidas más del 60% del costo de un sistema durante todo su ciclo de vida se produce después que es puesto en producción y este costo depende en gran medida de la arquitectura que se haya diseñado.<br />
<br />
<b>En resumen…</b><br />
1) La Arquitectura de Software no es opcional, puede ser más o menos compleja.<br />
2) Es de gran valor ($$) que los responsables del negocio que solicitan la construcción de un producto de software se involucren en la evaluación de su arquitectura.pedrogthttp://www.blogger.com/profile/05607207848250087678noreply@blogger.com1tag:blogger.com,1999:blog-16834307.post-84986910573990750642009-11-02T06:17:00.000-08:002009-11-02T06:33:07.524-08:00Niveles de actuación; el ser y el hacer, la persona y el proceso...Comento dos frases que para mí son trascendentes y que tienen mucho impacto en mi forma de abordar muchas situaciones en el día a día.<br /><br />La primera la escuché de un instructor del <a href="http://www.sei.cmu.edu/">SEI</a> en un curso de <a href="http://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration">CMMi</a>: "no fallan las personas, fallan los procesos".<br />La segunda de un amigo de quien tuve la oportunidad de acercarme, sólo un poco, al <a href="http://es.wikipedia.org/wiki/Coaching_Ontol%C3%B3gico">couching ontológico</a>; la distinción entre el ser y el hacer.<br /><br />Estas dos sencillas experiencias son en realidad herramientas poderosas de cara a lograr resultados personales, profesionales y organizacionales. Si bien desde el punto de vista personal el tema es particularmente profundo, me limito aquí al ámbito profesional y organizacional.<br /><br /><a href="http://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration">CMMi</a> plantea un modelo de madurez organizacional y como todo modelo de madurez basado en procesos persigue la consecución de los resultados de forma independiente a las personas, a través de la definición de prácticas bien documentadas, formación y controles de calidad. En un escenario como éste; no fallan las personas, fallan los procesos!.<br /><br />La segunda es una distinción básica entre dos cosas muy diferentes y que normalmente encontramos colapsadas en cada frase impune, en cada juicio emitido, cada vez que el orgullo no nos deja mejorar. El ser nos representa como individuos, lo que somos, nuestra historia, nuestro potencial, nuestros valores. El hacer habla de acciones específicas, que ocurren en un momento del tiempo.<br /><br />Para ilustrar la idea que quiero transmitir, peco tal vez de mezclar un poco peras y manzanas y defino tres niveles de actuación; ser, hacer y diseñar.<br /><br />Generar un resultado satisfactorio depende de haber ejecutado correctamente la acción correcta. Siendo así y dado que estamos hablando en un nivel organizacional, no sólo debemos saber ejecutar correctamente la acción prevista sino que esa acción previamente diseñada y definida también debe ser correcta. Muchos ejemplos existen de resultados no exitosos cuando se ejecutó la acción prevista, pero que no necesariamente era la indicada en esa situación. Esta realidad abre un espacio para la crítica de las prácticas y los procesos, sin que sea mezclada con la actuación de una persona que ejecutó una acción prevista y que no dio el resultado esperado. Cuestionar una práctica es posible sin que quienes la ejecutan se sientan atacados, ni quienes la cuestionan los ataquen. Esta posibilidad es la diferencia entre hacer y diseñar, dos estados de actuación posibles y necesarios que se complementan.<br /><br />Todo lo anterior para el lector puede ser tan obvio como revelador, dependiendo de su experiencia. Para mí es necesario transmitir el mensaje al ver frecuentemente que profesionales se sienten atacados cuando las prácticas que ejecutan por diseño son sometidas a revisión. Son procesos que deberían promover ellos mismos y participar abiertamente para mejorar sus resultados. Una cosa es la persona, otra cosa es el proceso, es responsabilidad de cada persona comprometerse con la mejora continua de los procesos que ejecuta.<br /><br />La segunda distinción se mueve más en un ámbito personal, pero que manejada correctamente facilita y mejora de forma inmediata las comunicaciones y relaciones en un plano profesional y organizacional. Cada persona debe ser valorada en su ser, como individuo, y esto no debe mezclarse con sus actuaciones en un ámbito profesional. La mayoría de las desventuras de un tradicional empleado son producto de cuestionamientos a su ser por parte de un tradicional jefe cuando los resultados en un ambiente laboral no son los esperados. Un profesional puede ser tachado de incompetente, de flojo o de irresponsable por no lograr un resultado esperado, todos estos juicios que afectan a la persona en su ser, son equivocados al no estar dirigidos a las acciones específicas que no fueron acertadas, generando un efecto contraproducente en el rendimiento y deteriorando a puntos irrecuperables las relaciones humanas. Los juicios al ser de una persona, en realidad hablan de la incompetencia de quien los emite para manejar niveles básicos de respeto y comunicación.<br /><br />En un ambiente emocionalmente sano y maduro las personas comunican sus opiniones o emiten juicios en función de acciones específicas, sin afectar el ser de nadie. Abriendo el espacio para la aceptación de la crítica y el compromiso a la mejora, haciéndose cargo desde el mismo mensaje en que la persona que lo recibe es valiosa en su ser y que eso no está siendo cuesitonado.<br /><br />En <a href="http://www.dbaccess.com">DBAccess</a> estas distinciones o prácticas están planteadas en el ambiente, y su aplicación nos deja la experiencia de la alta complejidad que tiene su transmisión e implantación en un contexto de constante crecimiento. Esto es posible sólo a través de un liderazgo integral consistente en toda la organización.<br /><br />El mensaje es en realidad una invitación a incorporar estas distinciones en el día a día, a través de evitar hablar impunemente colapsando los diferentes niveles de actuación.pedrogthttp://www.blogger.com/profile/05607207848250087678noreply@blogger.com1tag:blogger.com,1999:blog-16834307.post-61874901547629724062009-05-23T05:55:00.000-07:002009-05-23T16:48:17.337-07:00El Proyecto y el Producto<span style=";font-family:arial;font-size:100%;" >Veo una constante confusión en los equipos de desarrollos de software y en general en las disciplinas de TI entre el proyecto y el producto. No tener estas distinciones claras y no saber separar estos dos contextos tiene un impacto directo en la mantenibilidad, en costos, al verse reflejada en la documentación de los sistemas y de las organizaciones.<br /><br />Una analogía que me ha ayudado a explicar este fenómeno, como casi siempre tomada de la ingeniería civil. <i>Imaginen que van a una ciudad y para ubicarse piden el mapa de vías. La expectativa esta clara para todos, puede ir de un plan en papel a un GPS, con mayor o menor información asociada es en el fondo lo mismo, una imagen de todas las calles, vías y avenidas en una determinada región. Imaginen por un momento que en vez de recibir esto les dan la documentación de todos los proyectos de ingeniería civil realizados sobre la vialidad de la ciudad durante los últimos 40 años; el proyecto de construcción de un puente, el de asfaltado de una calle, el de ensanchado de una autopista, etc., con la expectativa que ustedes sean capaces de deducir de ahí el mapa vial de la ciudad. </i>Ante estas realidades es que hay que recordar que no debemos desesperar, la ingeniería civil nos tiene 2.000 años de ventaja.<br /><br />Tengo la certeza que la mayoría de las organizaciones no son capaces de dar su mapa de vías en el contexto tecnológico. También que nuestras disciplinas (desarrollo de software, arquitectura empresarial, etc.) seguirán su progreso acelerado en los próximos años y alcanzarán y superarán estos niveles obvios.<br /><br />Siguiendo con el proyecto y el producto, lo abordo en tres escenarios diferentes y tres ejemplos.<br /><br /><b>El Proyecto y el Sistema<br /></b><br />Un sistema de información inicia su ciclo de vida una vez que entra en producción y termina una vez que es descontinuado (o desenchufado) unos años después. Durante este periodo típicamente pasa por múltiples proyectos que lo completan, adaptan, evolucionan y sobre todo reparan. Al arrancar cualquiera de los proyectos sobre el sistema, el caso típico es que el equipo mantenedor se encuentra con la situación de la analogía inicial, para entender su funcionalidad y su arquitectura el equipo debe reconstruir la historia de los proyectos anteriores cuando en realidad esto no agrega ningún valor para ejecutar la tarea del momento. Si agrega valor es precisamente porque la documentación funcional y de arquitectura del sistema no es suficientemente completa.<br /><br />Una aplicación o componente de software en general debe contar tanto de documentación funcional como de arquitectura que permita comprender qué hace, </span><span style=";font-family:arial;font-size:100%;" >para qué lo hace, </span><span style=";font-family:arial;font-size:100%;" >cómo lo hace y por qué se decidió que lo hiciera de esa forma. Contando con esta información el equipo se enfrenta a un problema con baja incertidumbre y puede tomar acciones;<br /></span><ul><li><span style=";font-family:arial;font-size:100%;" >Disminuyendo drásticamente el riesgo de afectar el funcionamiento.</span></li><li><span style=";font-family:arial;font-size:100%;" > Disminuyendo drásticamente el tiempo de análisis requerido para iniciar el mantenimiento y por ende el costo del proyecto.</span></li><li><span style=";font-family:arial;font-size:100%;" >Disminuyendo el riesgo de incluir elementos que no cumplen los lineamientos de diseño del sistema.</span></li></ul><span style=";font-family:arial;font-size:100%;" > Adicionalmente se aumenta la posibilidad de reutilizar diseños y componentes, en este sistema y otros, al permitir entender rápidamente los elementos que conforman el sistema.<br /><br />En resumen el mensaje que quiero transmitir es que lo importante no es el proyecto, es el producto resultante. Poco valor tendrá el proyecto que terminó en menor tiempo pero que dejó la realidad que disparará los costos del próximo proyecto sobre el mismo producto. El valor de la información del proyecto es temporal o circunstancial, mientras<br />que el producto es un activo de la organización y su valor dependerá entre otras cosas de la calidad de la información que le acompañe.<br /><br />Estos son algunos casos específicos donde he visto mezclados el proyecto y el producto.<br /></span><ul><li><span style=";font-family:arial;font-size:100%;" >Como parte de un proyecto se hace un documento de visión (utilizando como metodología PU) que define nuevas características a incorporar a una plataforma existente, pero no se actualiza el documento funcional original (como el de casos de uso). Lo mismo podría ocurrir en metodologías ágiles si haces por ejemplo nuevos <span style="font-style: italic;">user stories</span> y no los agregas al repositorio de los existentes.<br /></span></li><li><span style=";font-family:arial;font-size:100%;" >Cualquier cambio de índole tecnológico que no actualiza el documento de arquitectura, luego por ejemplo tomarían días en averiguar qué frameworks se utilizan, en qué versiones y con qué fines.</span></li></ul><span style=";font-family:arial;font-size:100%;" >A partir de estos momentos comienza la historia de tener que reconstruir proyectos para entender el sistema.<br /><br /></span><span style="font-weight: bold;font-family:arial;font-size:100%;" >El Proyecto y los Sistemas</span><span style="font-weight: bold;font-family:arial;font-size:100%;" ><br /><br /></span><span style=";font-family:arial;font-size:100%;" >Lo mismo que ocurre con con un proyecto que afecta un sistema, ocurre con un proyecto que afecta o produce varios sistemas. Se generan documentos en el contexto del proyecto que hablan de múltiples sistemas, haciendo la información aún más densa y compleja de entender.<br /><br />Se debe asegurar en estos proyectos dejar la información actualizada de cada sistema.<br /><br /></span><span style="font-weight: bold;font-family:arial;font-size:100%;" ><span>El Proyecto y la Organización</span></span><span style=";font-family:arial;font-size:100%;" ><br /><br />Una situación similar a la que describo en el contexto de sistemas, se me presentó recientemente con procesos de negocio de una organización.<br /><br />En proyectos orientados a atender necesidades de negocio, es muy posible que se vean afectados los procesos de la organización. Toda organización debe tener sus procesos documentados y difundidos. Cualquier cambio sobre estos implica acciones de difusión, entrenamiento, cambios en sistemas, etc. Pueden y existen grupos de consultores que no ven los procesos más allá del proyecto y donde los cambios a estos quedan sólo en los documentos del proyecto, creando un riesgo importante de operación en la organización. Esto puede ocurrir<br />en organizaciones pequeñas o inmaduras donde el uso de procesos no está institucionalizado.<br /><br /><br />Estas situaciones suelen ocurrir por ingenuidad sobre la realidad de la vida de un sistema al pensar sólo en el proyecto actual y no en los futuros, por falta de experiencia y/o por comodidad. En cualquier caso se disminuye el valor del activo y se dispara el costo de futuros mantenimientos.</span><span style=";font-family:arial;font-size:100%;" ><br /></span>pedrogthttp://www.blogger.com/profile/05607207848250087678noreply@blogger.com0tag:blogger.com,1999:blog-16834307.post-16795926334295829442007-07-30T20:42:00.000-07:002009-05-23T14:42:51.743-07:00DBAccess en Ciberespacio Radio<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjzdI-ldNdKQWM8fKqJ4Wgdbb2cSiJRzMKs8s5hw4-ncQzhAhTGintv2j720udJh5stO16Vol9b1M3atu7-RuJCmSM-aLi4C7hq3YdFaiPLlJHWLapAzocRnD2vhWkmlSuYhbVb/s400/DSC05709_web.jpg"><img style="margin: 0pt 10px 10px 0pt; float: left; cursor: pointer; width: 220px; height: 166px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjzdI-ldNdKQWM8fKqJ4Wgdbb2cSiJRzMKs8s5hw4-ncQzhAhTGintv2j720udJh5stO16Vol9b1M3atu7-RuJCmSM-aLi4C7hq3YdFaiPLlJHWLapAzocRnD2vhWkmlSuYhbVb/s400/DSC05709_web.jpg" alt="" border="0" /></a><br /><span style="font-size:100%;"><span style="font-family:arial;">Entrevista con Edgar Rincón. En su estilo incisivo hizo una entrevista bien amena y fresca.</span> </span><br /><br /><object width="200" height="20"><param name="movie" value="http://static.boomp3.com/player.swf?id=5a153cc1a67b"><param name="wmode" value="transparent"><embed src="http://static.boomp3.com/player.swf?id=5a153cc1a67b" type="application/x-shockwave-flash" wmode="transparent" width="200" height="20"></embed></object>pedrogthttp://www.blogger.com/profile/05607207848250087678noreply@blogger.com0tag:blogger.com,1999:blog-16834307.post-24404822183693799062007-07-24T22:52:00.000-07:002009-05-23T14:41:04.312-07:00Tips para construcción de diagramas de clases útiles y legibles<span style="font-size:100%;"><span style="font-family:arial;">Escribo en este post uno de los temas más recurrentes y de más utilidad en clases, revisiones de pares, recomendaciones de diseño, revisiones de documentos de arquitectura y en general en cualquier momento donde aparezca un diagrama de clases.</span><span style="font-family:arial;"><br /><br />Hago una recopilación de los tips y observaciones que surgen continuamente y que teniéndolos en cuenta se mejora significativamente la calidad y utilidad de los diagramas.<br /><br /></span><span style="font-weight: bold;font-family:arial;" >El error más común: Relaciones conceptuales</span><span style="font-family:arial;"><br /><br />En muchos casos un modelo conceptual, que representa el espacio del problema, se utiliza como base para la identificación de clases. Las relaciones que se presentan en un modelo conceptual suelen ser acciones o interacciones de elementos en el mundo real. Por ejemplo en el modelo conceptual de un sistema de inscripciones de un ente educativo, seguramente consiguiremos una relación inscribe entre los conceptos de Estudiante y Materia.<br /><br /></span></span><div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgtScKUfCRYWqt8l5crgGgf0QcoJJZn40xI4H77T8Mn4gjmH6186h7KcVuxCF0RHuY6TCscnvHEe3WdQi4661kjyD7sFDtW362kprGeejjEfmInIGAm8tSkzLdT5SG_mUbkGFqG/s1600-h/diagrama+de+clases.gif"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgtScKUfCRYWqt8l5crgGgf0QcoJJZn40xI4H77T8Mn4gjmH6186h7KcVuxCF0RHuY6TCscnvHEe3WdQi4661kjyD7sFDtW362kprGeejjEfmInIGAm8tSkzLdT5SG_mUbkGFqG/s200/diagrama+de+clases.gif" alt="" id="BLOGGER_PHOTO_ID_5090912859335274930" border="0" /></a><span style="font-size:100%;"><span style="font-family:arial;"><span style="font-weight: bold;font-size:85%;" >Figura 1: Modelo Conceptual</span></span></span><br /></div><span style="font-size:100%;"><span style="font-family:arial;">En el modelamiento de un diagrama conceptual ésto es perfectamente válido. Ahora cuando se habla de relaciones entre clases, una relación inscribe entre las clases Estudiante y Materia tiene un significado bien específico y está relacionado directamente con la implementación.<br /><br /></span></span><div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhODt5p4-VgrHJSkRvG4kc5XEHmqgyyTY4kJ6p5rg7cNaI4HFyH8JRtgMtSRE8bk22zaiUd-ZUiOHa3aDneQriks5ZV3rX06J7KRdzoytxiwkHC7jYgGJTMqfKjfLEl5E__8iA4/s1600-h/diagrama+conceptual.gif"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhODt5p4-VgrHJSkRvG4kc5XEHmqgyyTY4kJ6p5rg7cNaI4HFyH8JRtgMtSRE8bk22zaiUd-ZUiOHa3aDneQriks5ZV3rX06J7KRdzoytxiwkHC7jYgGJTMqfKjfLEl5E__8iA4/s200/diagrama+conceptual.gif" alt="" id="BLOGGER_PHOTO_ID_5090912575867433378" border="0" /></a><span style="font-size:100%;"><span style="font-family:arial;"><span style="font-weight: bold;font-size:85%;" >Figura 2: Diagrama de Clases</span></span></span><br /></div> <span style="font-size:100%;"><span style="font-family:arial;">La relación de la figura 2 establece que en la clase Materia existe un método llamado <span style="font-size:85%;"><span style="font-family:courier new;">inscribe</span></span> y que este método es invocado en algún momento por la clase Estudiante. Hay que estar claros con lo que se está expresando y hacerlo concientemente.<br /><br />Si por ejemplo asumimos que un componente, capa de software o servicio es responsable de un contrato de registro de la inscripción de una materia y ofrece una operación o método con firma:<br /><span style=";font-family:courier new;font-size:85%;" > void inscribirMateria(Estudiante estudiante, Materia nuevaMateria)<br /> throws InscripciónDuplicadaException</span><br />Este servicio en su implementación podría hacer una serie de validaciones y luego acceder a un repositorio y almacenar la formalización de la inscripción de la materia.<br />En este caso la clase Estudiante nunca invocaría un método inscribir de la clase Materia e inclusoeste método podría no existir, aunque sea cierta la relación conceptual entre ambas clases. En un diagrama de clases, de acuerdo a la implementación planteada, sería un error colocarla en un diagrama de clases.<br /><br /></span><span style="font-weight: bold;font-family:arial;" >Tipos de relaciones:</span></span><span style="font-weight: bold;font-size:100%;" ><span style="font-family:arial;"> estáticas vs. dinámicas</span></span><span style="font-size:100%;"><span style="font-family:arial;"><br /><br />Las relaciones entre dos clases pueden ser clasificadas en dos tipos, estáticas y dinámicas.<br /><br />Las relaciones estáticas son aquellas que definen estructuralmente a la clase, básicamente en los lenguaes OO utilizados actualmente se definen tres tipos; extensión o herencia, agregación y composición. No es el objeto de este artículo explicar estas relaciones, hay múltiples fuentes disponibles.<br /><br /></span></span><span style="font-size:100%;"><span style="font-family:arial;">Las relaciones dinámicas son las que definen la interacción de la clase con otras, invocaciones que desde la clase se hace a métodos de otra clase. Un ejemplo de relación dinámica se define en la Figura 2.<br /></span></span><span style="font-size:100%;"><span style="font-family:arial;"><br />El tip que se presenta a continuación se basa en esta definición teórica para hacer una recomendación concreta en la construcción de diagramas.<br /><br /></span><span style="font-weight: bold;font-family:arial;" >No llene el diagrama de clases con relaciones dinámicas descontextualizadas<br /><br /></span><span style="font-family:arial;">Las relaciones dinámicas se dan en el contexto de la ejecución de una operación, servicio o contrato específico. Una clase que participa en la realización de múltiples operaciones, probablemente contará con múltiples invocaciones a otras clases, subconjuntos de todas estas relaciones (invocaciones) participan en la relización de una cada operación específica.<br /><br />Si en un diagrama de clases, adicionalmente a las relaciones estáticas, colocamos todas las relaciones dinámicas que se dan entre las clases del diagrama (es decir, todas las relaciones por cada vez que una clase llama a un método de otra clase) entonces terminaremos con un diagrama sobrecargado, de aquellos que solemos llamar <span style="font-style: italic;">spaghetti diagram</span>.<br /></span></span><div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://blogs.zdnet.com/images/SysCallIIS.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 200px;" src="http://blogs.zdnet.com/images/SysCallIIS.jpg" alt="" border="0" /></a><span style="font-size:100%;"><span style="font-family:arial;"></span></span><span style="font-size:100%;"><span style="font-family:arial;"><span style="font-weight: bold;font-size:85%;" >Figura 4: Espagueti inentendible... encontré un buen ejemplo buscando imágenes en la red.</span></span></span><br /></div><span style="font-family:arial;"><br />Cuando se presenta un diagrama de clases, lo más recomendable es presentar la estructura utilizando sólo las relaciones estáticas. Las relaciones dinámicas recomiendo presentarlas en su debido contexto, por ejemplo utilizando un diagrama de secuencias o colaboración para cada operación o servicio. De esta forma se apreciará claramente la interacción entre las diferentes clases e incluso objetos, para lograr la realización de una operación.<br /><br />Seguir esta recomendación mejora significativamente la utilidad de la documentación para el equipo que hará mantenimiento del sistema en construcción, disminuyendo así los costos de soporte y mantenimiento a futuro.</span><span style="font-size:100%;"><br /></span>pedrogthttp://www.blogger.com/profile/05607207848250087678noreply@blogger.com3tag:blogger.com,1999:blog-16834307.post-38790575114783543972007-07-22T19:06:00.000-07:002009-05-23T14:42:29.388-07:00Re Re Re Re Re Reconversión Monetaria<span style="font-family:arial;">La metodología para afrontar el impacto de la reconversión monetaria en las plataformas tecnológicas que definimos </span><span style="font-family:arial;">en la Unidad de Arquitectura e Innovación de</span><span style="font-family:arial;"> <a href="http://www.dbaccess.com/">DBAccess,</a> ha sido mercadeada efectiva y masivamente por el equipo de la Unidad de Mercadeo. Numerosas notas de prensa, presentaciones y entrevistas has sido muestra de la acogida que ha recibido en el mercado. Yo por mi lado, de vocero del tema, repito una y otra vez como el conejito de las pilas...<br /><br />Recopilación de enlaces y entrevistas.<br /><br /></span><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgY9A0nxadOhe6cJVlQjkvGgqsTzFmKunaHzYKYuvjTx9GROMTKIQutfaXCdpySusSUa9mfWFf6BQcEgNUuGdw7B43VXVbKofN0IOUqrFZcOcRZSydyygLMmxNQj-_zvKXqrypv/s400/altadensidad01.jpg"><img style="margin: 0pt 10px 10px 0pt; float: left; cursor: pointer; width: 200px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgY9A0nxadOhe6cJVlQjkvGgqsTzFmKunaHzYKYuvjTx9GROMTKIQutfaXCdpySusSUa9mfWFf6BQcEgNUuGdw7B43VXVbKofN0IOUqrFZcOcRZSydyygLMmxNQj-_zvKXqrypv/s400/altadensidad01.jpg" alt="" border="0" /></a><span style="font-family:arial;">Entrevista televisada para <a href="http://www.altadensidad.com/">Alta Densidad</a> - <a href="http://www.globovision.com/">Globovisión</a>.<br />La entrevista fue en un formato de preguntas y respuestas que después serán editadas. El fondo verde al mejor estilo de Matrix fue una nota divertida. Espero a que salga el programa en TV para ver qué fondo le colocan.<br /><a href="http://red-dbaccess.blogspot.com/2007/07/dbaccess-en-alta-densidad.html">http://red-dbaccess.blogspot.com/2007/07/dbaccess-en-alta-densidad.html</a><br /><br /></span><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjfUp7L9AXhSjL_xyYyA8LGLGQeWa7DJBKrJ7gq1lOd28NjLdZRSzQrY1mZvcgYQrW20fZYe-m3LgH6b7QsSiCTs98tTXLRyUo18qY6WNbHhoEmWMfsMswIqVW2Kzzc5ODcI08M/s200/cavedatos01.jpg"><img style="margin: 0pt 10px 10px 0pt; float: left; cursor: pointer; width: 120px; height: 161px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjfUp7L9AXhSjL_xyYyA8LGLGQeWa7DJBKrJ7gq1lOd28NjLdZRSzQrY1mZvcgYQrW20fZYe-m3LgH6b7QsSiCTs98tTXLRyUo18qY6WNbHhoEmWMfsMswIqVW2Kzzc5ODcI08M/s200/cavedatos01.jpg" alt="" border="0" /></a><span style="font-family:arial;"><a href="http://www.dbaccess.com/">DBAccess </a>habla sobre los efectos de la reconversión monetaria sobre las plataformas TI en foro de <a href="http://www.cavedatos.org.ve/">CAVEDATOS </a>7/11/2007:<br /></span><div style="text-align: left;"><span style="font-family:arial;"><a href="http://red-dbaccess.blogspot.com/2007/07/dbacces-en-foro-de-cavedatos-sobre.html">http://red-dbaccess.blogspot.com/2007/07/dbacces-en-foro-de-cavedatos-sobre.html</a><br /></span><a style="font-family: arial;" href="http://www.ciberespacio.com.ve/site/p_detalle_evento.asp?id_evento=7639&id_submodulo=24">http://www.ciberespacio.com.ve/site/p_detalle_evento.asp?id_evento=7639&id_submodulo=24</a><br /></div><br /><span style="font-family:arial;">Nuestra estrategia para la reconversión monetaria en <a href="http://www.cwv.com.ve/">ComputerWorld </a>(Junio 2007):</span> <a style="font-family: arial;" href="http://red-dbaccess.blogspot.com/2007/07/nuestra-estrategia-para-la-reconversin.html">http://red-dbaccess.blogspot.com/2007/07/nuestra-estrategia-para-la-reconversin.html</a><br /><a style="font-family: arial;" href="http://www.dbaccess.com/multimedia/computerworld-4-6-07-reconversion.pdf">Leer nota completa en ComputerWorld Venezuela (.pdf)</a><br /><br /><span style="font-family:arial;">La conversión al bolívar fuerte tiene fuerte impacto en los sistemas informáticos:<br /></span><a href="http://enbytes.com/noticias/reconversionI.htm"><span style="font-family:arial;">http://enbytes.com/noticias/reconversionI.htm</span></a><br /><br /><span style="font-family:arial;">Igual al anterior pero publicado por Conapri:<br /></span><a href="http://www.conapri.org/ArticleDetailIV.asp?CategoryId=14563&ArticleId=282506"><span style="font-family:arial;">http://www.conapri.org/ArticleDetailIV.asp?CategoryId=14563&ArticleId=282506</span></a><br /><br /><span style="font-family:arial;"><a href="http://www.cantv.net/">CANTV.Net</a>: <a href="http://www.dbaccess.com/">DBAccess </a>habla sobre los efectos de la reconversión monetaria:<br /></span><a href="http://www.cantv.net/ciencia/resena.asp?id=141181&cat=2&Fresena=TRUE"><span style="font-family:arial;">http://www.cantv.net/ciencia/resena.asp?id=141181&cat=2&Fresena=TRUE</span></a><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEggJCAf22j0lPbUVlqOM1aSl1nkfVp0jjH_w9pNjci19iaSev4ScwUo-SpxP2meney8Xs4w33QnOQkuRdIAHQbexeFrAmpka27A-UHhQAmSztoc-zh5zQSu3VxN4b58VA1v6iMu/s400/DSC05228_blog.jpg"><img style="margin: 0pt 10px 10px 0pt; float: left; cursor: pointer; width: 190px; height: 144px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEggJCAf22j0lPbUVlqOM1aSl1nkfVp0jjH_w9pNjci19iaSev4ScwUo-SpxP2meney8Xs4w33QnOQkuRdIAHQbexeFrAmpka27A-UHhQAmSztoc-zh5zQSu3VxN4b58VA1v6iMu/s400/DSC05228_blog.jpg" alt="" border="0" /></a><span style=";font-family:arial;font-size:100%;" ><a href="http://ww.dbaccess.com/">DBAccess </a>en <a href="http://www.altadensidad.com/">Alta Densidad</a> - Radio. Entrevista por Carlos Monzón a ser transmitida en el <a href="http://es.wikipedia.org/wiki/Circuito_X">Circuito X</a>.</span><br /><br /><br /><br /><br /><span style="font-size:100%;"><br /><br /><a style="font-family: arial;" href="http://red-dbaccess.blogspot.com/2007/05/dbaccess-en-alta-densidad.html">http://red-dbaccess.blogspot.com/2007/05/dbaccess-en-alta-densidad.html</a><br /><span style="font-family:arial;">Escuche la entrevista:</span></span><br /><object width="200" height="20"><param name="movie" value="http://static.boomp3.com/player.swf?id=3e9bd0401f3a"><param name="wmode" value="transparent"><embed src="http://static.boomp3.com/player.swf?id=3e9bd0401f3a" type="application/x-shockwave-flash" wmode="transparent" width="200" height="20"></embed></object>pedrogthttp://www.blogger.com/profile/05607207848250087678noreply@blogger.com0tag:blogger.com,1999:blog-16834307.post-75889751542703928612007-06-17T20:33:00.000-07:002009-05-23T14:41:56.016-07:00Póngase en los zapatos de los otros roles!<span style="font-family:arial;">Es una práctica que viene con la experiencia y el conocimiento del proceso completo, la capacidad de ponerse con cierta frecuencia en el lugar de otros roles del equipo que ejecuta un proyecto de ingeniería de software.</span><br /><br /><span style="font-family:arial;">Hago en este texto un análisis rol por rol, indicando el beneficio que puede traer ubicarse en la posición de otros.</span><br /><br /><span style="font-weight: bold;font-family:arial;" >Analista de Requerimientos</span><br /><br /><span style="font-family:arial;">Es sumamente útil para el analista de requerimientos, al momento de especificar características del sistema o funcionalidades en forma de casos de uso, ubicarse en la posición del equipo de desarrollo y de los encargados del diseño de casos de prueba. Analizar su producto desde esta posición le permitirá evaluar si el nivel de especificidad es suficiente para que el requerimiento pase de forma fluida a las siguientes etapas del ciclo de desarrollo.</span><br /><ul style="font-family: arial;"><li>Están claras las restricciones que impone el negocio?</li><li>Los datos que se manejarán están totalmente claros? longitudes, alcance, etc.</li><li>El perfil de los usuarios está claramente descrito?</li><li>Los puntos de integración con otros sistemas fueron analizados y documentados?</li></ul><span style="font-weight: bold;font-family:arial;" >Equipo de Desarrollo</span><br /><br /><span style="font-family:arial;">Uno de los problemas más comunes en el área, es que un equipo de desarrollo encargado de mantenimiento consiga una implementación pobremente documentada, sin indicativos de los elementos relacionados con el mantenimiento de una funcionalidad en particular o las decisiones de diseño involucradas.</span><br /><span style="font-family:arial;">Un desarrollador que trabaja en la implementación de un caso de uso debe, como parte integral de su trabajo, ubicarse en la posición de un desarrollador que llega al proyecto en un futuro sin el contexto que él posee, y que deba incorporar un cambio de requerimiento en la funcionalidad en la que el trabaja.</span><br /><ul style="font-family: arial;"><li>Cuáles son los elementos/componentes que participan en la realización de esa funcionalidad?</li><li>Qué reglas o restricciones de negocio están involucradas?</li><li>Está el código lo suficientemente claro y refactorizado para facilitar el proceso de lectura y comprensión?</li></ul><span style="font-family:arial;">Está ampliamente documentado los altos costos de mantenimiento en que se puede incurrir en caso de no contar con los insumos necesarios en esta etapa.</span><br /><br /><span style="font-weight: bold;font-family:arial;" >Arquitecto</span><br /><br /><span style="font-family:arial;">Los arquitectos deben diseñar los lineamientos de construcción de un sistema teniendo en cuenta que su producto debe ser lo suficientemente claro y completo, para que diferentes equipos de desarrollo puedan producir un sistema implementado de la misma forma. El arquitecto debe ubicarse en el rol del desarrollador y tratar de implementar un caso de uso sobre esa arquitectura, con el objetivo de identificar los puntos que aún quedan abiertos y la conveniencia de las decisiones de diseño que se plasmaron en la arquitectura.</span><br /><ul style="font-family: arial;"><li>La arquitectura habilita un desarrollo ágil?</li><li>Está clara la distribución de las responsabilidades en los diferentes componentes?</li><li>Están claros los lineamientos de manejo de errores?</li></ul><br /><span style="font-family:arial;">En general, el colocarse en la posición de otro, permite evaluar el producto que se ha producido obviando el contexto o conocimiento que una persona tiene sobre ese producto, permitiendo evaluar objetivamente si se ha dejado la suficiente información documentada.</span>pedrogthttp://www.blogger.com/profile/05607207848250087678noreply@blogger.com0tag:blogger.com,1999:blog-16834307.post-60855288892530945892007-06-03T22:02:00.000-07:002009-05-23T14:41:39.333-07:00Práctica de Peer Reviews<p style="color: rgb(0, 0, 0);" class="MsoNormal"><span style=";font-family:Arial;font-size:100%;" ><span lang="ES-VE" style="font-family:Arial;">Hay dos temas que motivan este escrito. El primero es la experiencia de haber pasado por varios <a href="http://en.wikipedia.org/wiki/Peer_review">peer reviews</a> en los últimos días, donde me sentí en cada una de esas sesiones aplicando repetitivamente las mismas prácticas. Fueron efectivas y lo han sido desde hace algún tiempo, así que considero vale la pena identificar cuáles son y compartirlas. La segunda motivación nace de una pregunta que he realizado en varias oportunidades a mis alumnos de Ingeniería de Software de la <a href="http://www.usb.ve/">USB</a>; ¿si comparan el código que ustedes están produciendo actualmente con el de un equipo de desarrolladores con amplia experiencia produciendo software de calidad mundial, en qué se diferenciaría?. Creo que ambos temas están muy relacionados y son claves en la calidad técnica del software.<o:p></o:p></span></span></p> <p style="color: rgb(0, 0, 0);" class="MsoNormal"><span style=";font-family:Arial;font-size:100%;" ><span lang="ES-VE" style="font-family:Arial;">El ojo de un experto en su área de experticia, busca de forma natural las anomalías o carencias que pueda tener el producto en cuestión. ¿Cuáles son esas anomalías o carencias que se deben identificar en el código fuente y que deben saltar a la vista del ojo experto en una inspección de código?.<o:p></o:p></span></span></p> <p style="color: rgb(0, 0, 0);" class="MsoNormal"><span style=";font-family:Arial;font-size:100%;" ><span lang="ES-VE" style="font-family:Arial;">La revisión que suelo aplicar va en dos bloques. El primero relacionado con la correcta y clara definición de lineamientos de diseño y de arquitectura y por supuesto su cumplimiento. El segundo se enfoca en el cumplimiento de la funcionalidad establecida y la búsqueda de defectos.<o:p><br /></o:p></span></span></p> <p style="color: rgb(0, 0, 0);" class="MsoNormal"><span style="font-size:100%;"><b style=""><span style="font-family:Arial;"><span style="font-weight: bold;font-family:Arial;" lang="ES-VE">Bloque de lineamientos de arquitectura<o:p><br /></o:p></span></span></b></span></p> <p style="color: rgb(0, 0, 0);" class="MsoNormal"><span style=";font-family:Arial;font-size:100%;" ><span lang="ES-VE" style="font-family:Arial;">El diseño de la arquitectura de un sistema debe abarcar una serie de aspectos básicos que garanticen uniformidad en la implementación del sistema. Particularmente en las revisiones me fijo en los siguientes; Capas, Asignación de responsabilidades, Uso de patrones, Componentización de alto nivel, Manejo de excepciones y Generación de trazas para auditoría. Claro que hay otros, pero si se cumplen éstos seguramente tendremos una arquitectura bastante sólida.<o:p></o:p></span></span></p> <p style="color: rgb(0, 0, 0);" class="MsoNormal"><span style=";font-family:Arial;font-size:100%;" ><span lang="ES-VE" style="font-family:Arial;">Una secuencia de acciones para realizar la revisión en base a estos parámetros podría ser la siguiente:<o:p></o:p></span></span></p> <ul style="color: rgb(0, 0, 0);"><li><span style=";font-family:Arial;font-size:100%;" ><span lang="ES-VE" style="font-family:Arial;">Buscar que en el documento de arquitectura estén claramente definidas las capas del sistema. Si la solución está compuesta por varios sistemas, aplica la secuencia a cada una.<o:p></o:p></span></span></li><li><span style=";font-family:Arial;font-size:100%;" ><span lang="ES-VE" style="font-family:Arial;">Debe establecerse para cada capa quiénes son los responsables en recibir las comunicaciones, en comunicarse con otras capas y cuál es el lenguaje que hablarán las capas entre si (tipos de datos simples, objetos de negocio, etc.).<o:p></o:p></span></span></li><li><span style=";font-family:Arial;font-size:100%;" ><span lang="ES-VE" style="font-family:Arial;">Las responsabilidades en cada nivel de la arquitectura lógica deben estar claras y ser consistentes. Quién valida parámetros de otra capa, quién crea objetos de negocio, quién interactúa con cada ente externo, quién interactúa con el repositorio, quién contiene la lógica de reglas de negocio, son algunas de las muchas preguntas que siempre es útil hacerse y cuyas respuestas deben estar claras.<o:p></o:p></span></span></li><li><span style=";font-family:Arial;font-size:100%;" ><span lang="ES-VE" style="font-family:Arial;">Qué patrones se están usando y por qué?. Qué piezas o componentes considera las más complejas? qué patrones usan éstas?, si no usan ninguno hay alguno que podría ayudar?.<o:p></o:p></span></span></li><li><span style=";font-family:Arial;font-size:100%;" ><span lang="ES-VE" style="font-family:Arial;">Siempre debemos poder mostrar una vista de componentes y debe estar claro cómo interactúan entre ellos, sus interfaces y responsabilidades.<o:p></o:p></span></span></li><li><span style=";font-family:Arial;font-size:100%;" ><span lang="ES-VE" style="font-family:Arial;">Debe en el documento de arquitectura o su equivalente estar un diagrama de clases de las excepciones a utilizar y estar definido cómo y cuándo se utilizarán, también debe estar definido de quién es la responsabilidad de capturarla en cada caso. Cuáles son posibles extender y cuáles no.<o:p></o:p></span></span></li><li><span style=";font-family:Arial;font-size:100%;" ><span lang="ES-VE" style="font-family:Arial;">Quién ha tenido la experiencia de tener que mantener un sistema en producción ha aprendido la utilidad de las trazas de auditoría de primera mano. Debe estar claro cuál es la estrategia a seguir en las trazas, en qué puntos deben generarse siempre, en cuáles es opcional, cuántos niveles se utilizarán y qué tipo de mensajes van en cada uno.<o:p></o:p></span></span></li><li><span style=";font-family:Arial;font-size:100%;" ><span lang="ES-VE" style="font-family:Arial;">Para validar posteriormente que todo lo anterior que está en la documentación se cumpla efectivamente en la implementación, se seleccionan un par de funcionalidades (casos de uso), y se revisan siguiendo su código fuente tal como lo haría durante su ejecución, desde las capas superiores a las inferiores. <o:p></o:p></span></span></li></ul><span style="color: rgb(0, 0, 0);font-family:Arial;font-size:100%;" ><span lang="ES-VE" style="font-family:Arial;">Para todos los puntos anteriores las respuestas deben estar en la documentación, sino están y alguien debe explicarlo entonces está incompleta. Cada respuesta que alguien da debe anotarse y luego incorporarse al documento correspondiente. Es una buena forma de identificar los puntos de mejora de la documentación.<o:p></o:p></span></span> <p style="color: rgb(0, 0, 0);" class="MsoNormal"><span style=";font-family:Arial;font-size:100%;" ><span lang="ES-VE" style="font-family:Arial;">De contar con la disponibilidad de tiempo suficiente, podrían tomar en cuenta otros aspectos como Paquetes, Idioma del código fuente (es común y poco deseable el <a href="http://en.wikipedia.org/wiki/Spanglish">spanglish</a>) y Uniformidad en los nombres.<o:p></o:p></span></span></p> <p style="color: rgb(0, 0, 0);" class="MsoNormal"><span style=";font-family:Arial;font-size:100%;" ><span lang="ES-VE" style="font-family:Arial;">Este primer bloque de prácticas se aplica cuando se realizan las primeras inspecciones de un proyecto. En sucesivas sesiones, cuando ya se ha garantizado que la arquitectura y los lineamientos de diseño están suficientemente maduros, la actividad puede enfocarse sólo en el segundo bloque.<o:p></o:p></span></span></p> <p style="color: rgb(0, 0, 0);" class="MsoNormal"><span style="font-size:100%;"><b style=""><span style="font-family:Arial;"><span style="font-weight: bold;font-family:Arial;" lang="ES-VE">Bloque de búsqueda de defectos<o:p></o:p></span></span></b></span></p> <p style="color: rgb(0, 0, 0);" class="MsoNormal"><span style=";font-family:Arial;font-size:100%;" ><span lang="ES-VE" style="font-family:Arial;">En el segundo bloque se revisa un conjunto de casos de uso o funcionalidades seleccionadas, el objetivo es verificar que la implementación efectivamente cumple con los requerimientos establecidos y tratar de identificar potenciales defectos.<o:p></o:p></span></span></p> <p style="color: rgb(0, 0, 0);" class="MsoNormal"><span style=";font-family:Arial;font-size:100%;" ><span lang="ES-VE" style="font-family:Arial;">La revisión al igual que en el bloque anterior es recomendable hacerla siguiendo el código fuente tal como se ejecutaría, línea a línea.</span></span></p><p style="color: rgb(0, 0, 0);" class="MsoNormal"><span style=";font-family:Arial;font-size:100%;" ><span lang="ES-VE" style="font-family:Arial;">Durante estas revisiones tenga siempre en mente los lineamientos validados en el primer bloque, siempre es posible encontrar puntos donde no se cumple lo establecido y es pertinente alertar para que sea corregido.</span></span><br /><span style=";font-family:Arial;font-size:100%;" ><span lang="ES-VE" style="font-family:Arial;"><o:p></o:p></span></span></p> <p style="color: rgb(0, 0, 0);" class="MsoNormal"><span style=";font-family:Arial;font-size:100%;" ><span lang="ES-VE" style="font-family:Arial;">Qué relación tiene lo anterior con la pregunta inicial sobre la diferencia del código fuente de un grupo de estudiantes con el de un equipo de desarrollo experto?, creo que los puntos del primer bloque son los principales diferenciales, ya que son continuamente reforzados por la experiencia.</span></span></p><p style="color: rgb(0, 0, 0);" class="MsoNormal"><span style=";font-family:Arial;font-size:100%;" ><span lang="ES-VE" style="font-family:Arial;"><a href="http://en.wikipedia.org/wiki/Peer_review">Peer Reviews</a> es todo un tema y existe amplia bibliografía al respecto, <a href="http://www.amazon.com/Peer-Reviews-Software-Practical-Guide/dp/0201734850">Peer Reviews in Software</a> de <a href="http://www.processimpact.com/bio.shtml">Karl Wiegers</a> es una muy buena opción para adquirir una base metodológica en el tema.</span></span></p><p style="color: rgb(0, 0, 0);" class="MsoNormal"><span style=";font-family:Arial;font-size:100%;" ><span lang="ES-VE" style="font-family:Arial;"><br /></span></span></p>pedrogthttp://www.blogger.com/profile/05607207848250087678noreply@blogger.com2tag:blogger.com,1999:blog-16834307.post-20222090810924691352007-05-23T23:09:00.000-07:002009-05-23T14:42:11.543-07:00Entrevista sobre Reconversión Monetaria en Jazz 95.5 FM<span style="font-size:100%;"><span style="font-family:arial;">Participación en el programa </span><a style="font-family: arial;" href="http://www.tecnologiahechapalabra.com/">Tecnología hecha palabra</a><span style="font-family:arial;">, transmitido por la emisora </span><span style="font-weight: bold;font-family:arial;" >Jazz 95.5 FM</span><span style="font-family:arial;"> y </span></span><span style="font-size:100%;"><span style="font-family:arial;">moderado por Peter Cernik</span></span><span style="font-size:100%;"><span style="font-family:arial;">, para hablar de la estrategia que propone <a href="http://www.dbaccess.com/">DBAccess</a> como solución a las adecuaciones necesarias producto de la reconversión monetaria en Venezuela. Participamos Jesús Maceira y yo, el programa se efectuó el día 22/05/2007 a las 9:30 pm. </span></span><span style="font-size:100%;"><a style="font-family: arial;" href="http://www.dbaccess.com/multimedia/tecnologia_hecha_palabra.mp3">El audio de la transmisión</a>.<br /></span><span style="font-size:100%;"><span style="font-family:arial;"><br /><a href="http://red-dbaccess.blogspot.com/2007/05/dbaccess-habla-de-reconversin-monetaria.html">Artículo relacionado en el blog de DBAccess</a>.<br /></span></span>pedrogthttp://www.blogger.com/profile/05607207848250087678noreply@blogger.com0