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.

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.

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.

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.

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