Evaluando Modelos

La responsabilidad de emitir un concepto, desde un punto de vista objetivo y profesional. Uno  sabe la necesita que se pretendía resolver, pero aun así no sabe por dónde empezar, a veces la lista de chequeo es más fácil. Cumple no cumple, como dijo un compañero en clase ¡esto es binario!

La práctica de alejarse un poco desligar sus conceptos, hacerse el ignorante en el tema para ver que tanto le enseña el modelo, igual el cerebro te juega la pasada, como dicen uno no se hace el loco, ¡se hace el cuerdo! 

La semana pasada han sido cuatro días revisando entregables, actas. La tarea no es fácil se requiere el diagnóstico si el diseño da respuesta  a las preguntas de negocio para que a partir de este se retome el proyecto, desde la fase de construcción, leyendo los criterios de aceptación pues no se puede pedir más de lo que en ese momento se pactó. Si claro, el negocio es dinámico pero si en ese momento no se incluyó  ahora no se puede evaluar contra nuevas reglas, el usuario solo ve el front end, él quiere que las cifras concilien quiere poder tener indicadores más complejos, la realidad es que si no está la fuente incluida en el modelo no se va a poder tener en la capa de explotación. Pero entonces viene  la pregunta cúal es el porcentaje en el que el  modelo cumple lo requerido, pero es que de 54 preguntas de negocio solo no responde a 9, por eso el diseño se aceptó parcialmente sujeto a  verificación en fase de desarrollo [se justifica el área técnica que avalo el pago de la fase].

Entonces el subdirector de desarrollo organizacional dice: un momento, pensemos en un corte de tela que llevo al sastre le pido un modelo de manga larga, cuello en V… termino sus especificaciones, me fui y volví al mes, la moda cambio ya no la quiero manga larga la quiero manga corta, el sastre me dice: si señor claro el corte nos sigue funcionando solo que ahora pues recortamos acá, puntada acá y listo! Toma aire el subdirector de desarrollo organizacional cosa diferente si llego al mes y le digo no ahora la quiero estilo globo no a la cintura sino a la cadera, el sastre me dirá no con este corte de tela no puedo hacer ese ajuste no me alcanza.

Ahora la coordinadora del área funcional, no, a mí con el BI, me pasa como cuando me dicen tenemos para comprarle un carro, entonces yo no pedí el Renault 4, yo pedí el Ferrari!, la interrumpe el analista de BI y le dice no es que más fácil piensa en una receta de arroz mínimo necesitamos de 4 elementos  arroz + condimento + agua+ aceite  y a cocinarlo, si pero si tengo 2 elementos de cuatro, ya no puedo hacer el arroz!

El pobre SubDirector del área misional quien es el mayor interesado en el proyecto dice a mí lo único que me queda claro es que: Me pongo la camisa, me como un arroz y me voy en el Ferrari!  Ah ahora, ese día quiz y clase de: “que debemos tener en cuenta al evaluar un modelo”

Por eso como digo,  no sufro de locura, ¡la disfruto!

Respecto al Manual de referencia de UML

Para pensar del diseño de un sistema,  dice el libro Un arquitecto utiliza modelos en papel, sobre un computador, o como construcciones tridimensionales, para visualizar y experimentar con posibles diseños. Pero esta es la mejor: La simplicidad de crear y de modificar modelos pequeños permite pensamiento creativo e innovación con poco coste.

Pienso si realmente se ha tomado la tarea en serio del uso del modelo, de potenciar ese ¿para qué nos sirve? el explorar varias vistas de arquitecturas y soluciones de diseño fácilmente antes de adelantar en tareas de más detalle.  A veces por estar concentrados en el producto final a donde se quiere llegar se echa de menos el proceso para conseguir un buen producto. Como dijo el monje sentado al lado de la montaña viendo el paisaje: hay que gozarse todo el camino. 

Se recibe una instrucción y empieza la carrera, hay que escribir hay que rallar,  al final bee## suena la corneta hay que entregar. Y eso que lo gozado nadie nos lo quita, ja ja. Es en serio es un entrenamiento mental, hay qué cambiar la forma de pensar en el diseño del sistema, hay que retar otra vez el cerebro, hay que tomar el tiempo para darnos ¡el espacio de pensar!   Que aflore el pensamiento de ingenio (ah ve que cómico ingeniero suena parecido). Vuelvo a los momentos educativos con dana, la escena de Big Hero  cuando Hiro  luego de arrugar muchos papeles no da con la idea su hermano le sacude le pone de cabeza y le dice cambia de ángulo.  Tenemos que cambiar de ángulo una y otra vez, tenemos que dejar que pensar que todo es  en sus marcas listos y fuera! La carrera la inventamos nosotros, el terreno lo tenemos que analizar antes, lo peor es que a pesar que podamos echar mano a una buena todo terreno a un plano satelital, nosotros  empezamos a pie limpio.

Por esto permitámosle al modelo ocuparse de la complejidad,  que logre el nivel de comprensión requerido sin que sea un mar de detalles insignificantes, al representar conceptos del mundo real hay que generar la habilidad de distinguir entre las cosas relevantes del mundo real y las relevantes del diseño. Bueno el manual esta fácil de leer y como le gustan los cuentos a dana con dibujitos.

La última capa, la descripción

Tolstoi: “Describe tu aldea y serás universal”

 

Descripción: La información en sí.

 Las categorías se corresponden con las agrupaciones de reglas explícitas o implícitas en función del contexto en el que ocurran. Un objeto que va a ser categorizado recibe apoyo de varias fuentes (reglas) con diferentes condiciones, hay una descripción a ser categorizada.

La descripción: “es pequeño, peludo, suave; tan blando por fuera,  que se diría todo de  algodón…”  Esta descripción les permite a muchos niños mediante un proceso de inducción categórica   pensar en “Platero y yo”, en un burrito, un libro. O talvez en la hora de ir a la cama.

Esta misma acción de generar una descripción, facilita el proceso mental de categorizar, de asociar un concepto. De tal forma que  si hay una realidad  que no se reconoce como un prototipo almacenado,  es decir, si algo no es p.ej. ni una piedra, ni una bola de alcanfor, ni un caramelo,  por algún lenguaje descriptivo puede encontrar una  denominación genérica que suministre una aproximación o una pista  para dar con la categoría: " es una cosa pequeña redonda y blanca"; "es como una bola"

Por eso la frase de Tolstoi hay títulos cuya sola mención provocan en el público un desencadenamiento de asociaciones, con lo que llega a saberse, más o menos, a qué atenerse. Nombres propios, singularidades, que designan mundos y que en su sencillez abstracta resultan abarcadores por su poder de síntesis.

Hasta un próxima entrada.

Los procesos de categorización

Una función que ya está presente desde que somos muy niños, por lo tanto tiene un rol muy importante en la representación del conocimiento, siempre estamos categorizando, realizando construcciones semánticas, que son nuestros tipos de conceptos (categorización conceptual) y no es más que el modo como nuestra mente representa y elabora información.

Sin categorías y modelos nuestras explicaciones se pierden en una miríada de detalles no siempre significativos. Cuando supe que Danita llegaba a mi vida, pensaba como se interpreta el mundo, el sentido de vida, desde el útero de la madre y como con cada cambio biológico empieza a formar su modelo de mundo. El ser humano está en actividad constante, sensibles a cada cambio en nuestro entorno: imágenes, sonidos, movimientos..., cada objeto o evento del entorno presenta numerosos atributos relativos a cualidades formales o funcionales.

Nuestra mente estaría completamente abrumada si, desde las primeras fases del desarrollo, no pudiese iniciar a organizar este mar de estimulaciones en esquemas, progresivamente siempre más articulados y complejos, a través de los cuales gestionar una relación con el ambiente material y relacional.

A la base del desarrollo de todos los procesos psicológicos y cognitivos, entonces, está la capacidad de operar sobre los estímulos para organizarlos en categorías. Y pasa de una asociación analógica de características o atributos a categorización dictada por los principios de la lógica. Entonces sigo con el hilo de Dana, y me acuerdo de la película  que ahora está en su rutina de volver a ver, una y dos, y creo que vamos por la veinteava vez, “Intensamente –el retorno repetición 21”, es un bonito ejemplo de como las experiencias tenían sus categorías(pensamientos centrales) para almacenarlas y esquema para recuperarlas en algún momento dado, así un sentimiento de seguridad  está en la categoría: isla familiar,  las bromas en la isla de las tonterías, sus actividades deportivas en la isla del hockey.

Por eso los ingenieros nos estresan las pruebas psicotécnicas, y di lo primero que se te viene a la cabeza cuando te ponen una imagen al frente, no es más que pretender ubicar en un patrón de comportamiento debido a como  se realiza la categorización de la imagen, cada cuadro es una categoría, entonces si dibujas debe estar centrado, tener piso ser ascendente, por la Meta categoría en un Pensamiento Positivo, Personalidad creativa en fin, así la empresa tendrá su insumo para saber si se adapta  a la categorización de su personal, está buscando un líder, un desarrollador..?

Bueno  si vemos cada concepto aterrizado a la cotidianidad es un poco más sencillo.

Continuando con OpenUP

  "Somos arquitectos de nuestro propio destino."

Albert Einstein

 Esa si es una frase más filosófica, es cierto nos preocupa la arquitectura del sistema, se leen y repiten patrones, a veces de manera mecánica así si ese arquitectura centrada en los datos a no es de capas, y el proyecto más importante que es la vida, en ese no se aterrizan los conceptos, te cambian el contexto y la cosa ya empieza a tambalear. Uh  cásate con tu arquitectura de prisa y arrepiéntete en tu tiempo libre [Barry boehm]

El considerar diferentes alternativas arquitectónicas en una etapa en la que hacer cambios al diseño todavía es relativamente fácil, claro se nos pasa el tiempo y después los controles de cambio son súper costosos, uh pero para la vida humana a veces no es tan fácil hay que desaprender para poder realmente dar un nuevo paso, el ego humano no permite quitar el componente “mi”.

Bueno pero como el titulo lo indica, quiero dejar otros conceptos que desarrolla OpenUp, disponibles en su sitio:

Sin un fundamento arquitectónico, un sistema evolucionará en una forma ineficiente y casual. Tal sistema frecuentemente presenta dificultades para evolucionar, reutilizarse o integrarse sin una reconstrucción sustancial. Esto también dificulta organizar el equipo o comunicar las ideas sin el enfoque técnico común que la arquitectura proporciona.

Cree la arquitectura para lo que usted conoce hoy

Como Albert Einstein dijo, haga cada cosa tan simple como sea posible pero no más simple. Los proyectos de software tienen recursos restringidos, y el deseo de los desarrolladores por crear soluciones elegantes podría llevar a un sistema de mayor complejidad de la que los stakeholders solicitan. Los esfuerzos de corregir en un futuro un sistema en un ambiente turbulento o incierto probablemente conducirán a un código sobrecargado, mientras se aumentan los sobrecostos con poco beneficio real que mostrar por esto.

Cree arquitecturas que se orienten a las necesidades reales de los stakeholders y provean la flexibilidad apropiada y apresúrese por los requisitos como se conocen hoy. Evite el deseo, sin importar que tan bien intencionado sea, de especular sobre requisitos futuros y por eso sobre dimensionar la arquitectura: si usted tiene la habilidad para hacer la arquitectura de algo hoy, entonces claramente usted podrá también tener la habilidad de hacer esta arquitectura mañana cuando usted realmente necesite hacerla.

Sobrelleve la complejidad elevando el nivel de abstracción

El software es complejo, y las personas tienen una capacidad limitada para sobrellevar la complejidad. A medida que un sistema se hace grande, empieza a ser difícil para el equipo desarrollar una comprensión común del sistema, porque es difícil ver todo el panorama completo.

Por consiguiente, use modelos que eleven el nivel de abstracción enfocándose en problemas importantes de alto nivel, tales como relaciones y patrones, en lugar de sumergirse en los detalles. Modelar realza el nivel de abstracción y permite al sistema ser más fácil de entender desde diferentes perspectivas.

Permita al problema dirigir la solución

La arquitectura podría empezar a ser difícil de mantener y adaptar a las nuevas necesidades de los stakeholders cuando la tecnología, en lugar del problema, dirige la solución

Permita que las necesidades de los stakeholders guíen la arquitectura. 

Organice la arquitectura con bajo acoplamiento, componentes altamente cohesionados

Un alto acoplamiento entre componentes hace un sistema frágil y difícil de entender. El software es costoso de crear, de modo que si existen componentes que pueden ser reutilizados, estos pueden reducir el esfuerzo requerido para crear el sistema.

Organice la arquitectura del sistema en los componentes que maximizan la cohesión y minimizan el acoplamiento. Esto mejora la comprensión, incrementa la flexibilidad e incrementa las oportunidades de reutilización.

Reutilice recursos existentes

Es malgastador construir lo que usted puede simplemente reutilizar, descargar o aún comprar.

Por consiguiente, haga cada esfuerzo para reutilizar recursos existentes. Los desarrolladores son frecuentemente renuentes a reutilizar recursos, porque estos recursos no se ajustan exactamente a sus necesidades o esos recursos tienen poca calidad. Este preparado para balancear el ahorro que usted puede realizar usando un recurso existente, aún si el recurso requiere cambiar la arquitectura o suavizar una restricción.

Apalanque la arquitectura como una herramienta colaborativa

La falta de un entendimiento común de los desarrolladores acerca de un sistema, conduce a la indecisión y a opiniones contrarias entre los desarrolladores y se puede paralizar el proyecto rápidamente. Los desarrolladores pueden tener diferentes modelos mentales del sistema y trabajar propósitos cruzados el uno del otro.

Cómo  también me identifico con otra frases de Einstein "Un estómago vacío, es un mal consejero." Así que voy a comer alguito, hasta la siguiente entrada

OpenUp, un sitio que volví a encontrar

 

"Dos cosas son infinitas: el universo y la estupidez humana;

y yo no estoy seguro sobre el universo."  

Albert Einstein

La mente creativa, el ingenio humano para buscar otro camino, siempre me ha causado risa cuando sale uno de la oficina  y el problema sigue en backend procesándose, ese hilo no muere hasta recibir respuesta,  entonces como si se hubiese olvidado estas en otra actividad y de pronto viene la idea, la solución y como loco hablas en voz alta “¡claro que estupidez ahí está el error!”.

 Estos días he seguido leyendo sobre arquitectura y me he acordado de páginas que alguna vez leí, y tome como fuente de trabajo, analizando que los conceptos los hemos trabajado aplicado, aun así cuando la pregunta viene formulada en un marco diferente nos enredamos. Entonces en ese cuestionamiento llego mi dejavu mental  “La arquitectura del software es un concepto fácil de entender y que la mayoría de los ingenieros intuitivamente siente, especialmente con un poco de experiencia, pero es precisamente difícil de definir. En particular es difícil marcar una línea en lo que es diseño y arquitectura. La arquitectura es un aspecto del diseño que se concentra en algunas características específicas.” Dónde lo había leído, si la página que hoy volví a recordar abrí el explorador http://epf.eclipse.org/wikis/openupsp/,  a leer un poco de OpenUP, quise traer al blog algunos de los conceptos,

 

OpenUP se basa en cuatro principios básicos que se apoyan mutuamente:

Colaborar para alinear los intereses y un entendimiento compartido

Desarrollar prácticas que fomenten un ambiente de equipo saludable. Un ambiente de equipo saludable permite la colaboración efectiva, lo cual encuadra los intereses de los participantes del proyecto (equipo de desarrollo, aseguramiento de la calidad, stakeholders del producto, clientes) y ayuda a los participantes del proyecto a desarrollar un entendimiento compartido del proyecto.

Balancear las prioridades en contradicción para maximizar el valor de los stakeholder

Los sistemas necesitan ser desarrollado por equilibrar las diferencias y algunas veces perspectivas contradictorias. Por ejemplo, ¿usted prefiere minimizar el costo reutilizando una capacidad existente o hace un desarrollo personalizado de la capacidad para que haga exactamente lo que usted quiere?

Por consiguiente, los participantes del proyecto y los stakeholders deben colaborar para desarrollar una solución que maximice el beneficio de los stakeholders y cumpla con las restricciones planteadas en el proyecto. Lograr un balance es un proceso dinámico porque si los stakeholders y los participantes del proyecto aprenden más acerca del sistema, entonces sus prioridades y restricciones cambian.

Enfocarse en articular la arquitectura

Sin un fundamento arquitectónico, un sistema evolucionará en una forma ineficiente y casual. Tal sistema frecuentemente presenta dificultades para evolucionar, reutilizarse o integrarse sin una reconstrucción sustancial. Esto también dificulta organizar el equipo o comunicar las ideas sin el enfoque técnico común que la arquitectura proporciona.

Por consiguiente, use la arquitectura como un punto focal para que los desarrolladores alineen sus intereses e ideas, articulando las decisiones técnicas esenciales a través de una arquitectura creciente.

Evolucionar para obtener continuamente retroalimentación y progreso

Usualmente no es posible conocer todas las necesidades de los stakeholders, ser consciente de todos los riesgos, comprender todas las tecnologías del proyecto, en otros factores, es probable que cambien durante la vida del proyecto. Por consiguiente, divida el proyecto en mini proyectos, iteraciones encajadas en tiempo para demostrar valor incremental y obtener retroalimentación temprana y continua.

 Por ahora solo es el re encuentro.