domingo, 30 de agosto de 2015

Fabrica de sofware. A propósito de la ISO/IEC 25000 Guide to SQuaRE


 
En un proyecto nos paso, era metodología de fabrica de software, el insumo para el equipo de desarrollo eran  objetos puntuales a construir con restricciones y características específicas para su proceso de integración, al liberar al equipo de pruebas las incidencias eran mínimas, pero cuando llegamos a entregar e implementar en el cliente; los conceptos de negocio estaban errados y eso fue un caos total se tuvo que re definir y reconstruir estructuras de datos, entonces que paso con la calidad en cada fase de la fabrica.  Toma fuerza la pregunta: ¿Es suficiente la calidad de los procesos de desarrollo para asegurar la calidad del producto del software?
 

 
ISO/IEC 25000 constituye una serie de normas basadas en ISO/IEC 9126 y en ISO/IEC 14598 cuyo objetivo principal es guiar el desarrollo de los productos de software mediante la especificación de requisitos y evaluación de características de calidad.



 
Luego volví a pensar si la fábrica es certificada en cada una de sus componentes porque sigue pasando lo de la imagen inicial, algunos autores como Kitchenham B. coinciden: "Hay poca evidencia de que la conformidad con estándares de proceso garanticen buenos productos. De hecho las críticas a esta visión sugieren que los  estándares de procesos sólo garantizan uniformidades en las salidas”.

En el tema opino que la fábrica  puede saber hacer, tener con qué, elegir el socio o proveedor de manera adecuada, ejercer responsabilidad por el producto/servicio, comprometerse en asegurar la calidad, adoptar procesos y guías.  Pero si no está en continua retroalimentación con el negocio el modelo puede fallar, asi que  les dejo  otra imagen que encontré en la web:

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 

Vida y arquitectura.


Comprando un nuevo computador,  validar la arquitectura de la máquina, uh ah  sí claro es que depende para que lo necesita, usted es ¿diseñador gráfico?  ¿Es desarrollador? , ¿Es escritor?

Al pensar la elección  del colegio de mi hija, se debe analizar  los componentes que incluyen en el colegio en su plan educativo institucional, cómo se relaciona con el entorno para lograr sus objetivos, si comparte los intereses  y patrones de enseñanza   que busco.

Haciendo una lista de chequeo de los programas que requiero instalar  o actualizar, en la tareíta de volver a configurar un entorno de desarrollo, ¿es compatible con la arquitectura del S.O?, los requerimientos de hardware… ups como que eso de la arquitectura del equipo es ¡más que un nombre!

Entonces es un tema que a diario utilizamos empíricamente estamos exponiendo requerimientos, criterios de aceptación; estamos modelando; analizando arquitecturas sociales, educativas, de infraestructura. Y como todo con el instinto colombiano ese mismo que nuestros abuelos nos transmitieron, más allá del no te juntes con extraños, el sembrado de patilla no se recoge de una se divide por cortes, ah sí divide y vencerás. Para escoger una patilla buena se debe analizar el sonido al darle un pequeño golpe… para ir de pesca se debía analizar hasta la posición de la luna claro sin ningún telescopio solo por su reflejo sobre el Orinoco.

Bueno hoy existen marcos de referencia, estándares que guían la tarea de definir, describir una arquitectura.  Entonces en el entorno empresarial se nombra TOGAF, en el gobierno IT4+,   la ISO 42010. Ya no tenemos que ver la luna. Aunque a veces se diga que el arquitecto estaba en la luna cuando aprobó la arquitectura del proyecto  o sistema.

La ISO 42010 sustenta los requisitos generales de la estandarización en un modelo conceptual para la descripción de la arquitectura, puntos de vista de la arquitectura marco de trabajo para la arquitectura, el lenguaje para la descripción de arquitecturas.

TOGAF es un esquema (o marco de trabajo) de Arquitectura Empresarial que proporciona un enfoque para el diseño, planificación, implementación y gobierno de una arquitectura empresarial de información. Esta arquitectura está modelada, por lo general, en cuatro niveles o dimensiones: Negocios, Tecnología (TI), Datos y Aplicaciones. Cuenta con un conjunto de arquitecturas base que buscan facilitarle al equipo de arquitectos cómo definir el estado actual y futuro de la arquitectura.
Por su parte el gobierno se une al esfuerzo y creó un nodo de Arquitectura TI, escenario creado con el fin de definir prioridades de innovación, para desarrollar proyectos de TI, orientados a servir de guía en la aplicación de la estrategia organizacional a nivel de las entidades públicas en Colombia, con base en la Arquitectura de Referencia de Gobierno en línea. La arquitectura de TI, como lineamientos y principios de diseño de sistemas, busca definir estrategias tecnológicas que agreguen valor. Así, orientada al uso y apropiación de las TIC en las entidades públicas, busca el uso eficiente de recursos y una óptima prestación de servicios a los ciudadanos, incrementando el potencial de reutilización entre entidades del sector público, reduciendo la duplicidad y los costos. Teniendo en cuenta que una arquitectura de referencia define unas reglas de diseño para la estructura y los componentes de arquitecturas definidas en contextos, se busca aplicar la arquitectura de referencia de Gobierno en línea a través de los modelos de Arquitecturas de TI en un contexto específico. AH! Qué bonito suena, ¿la conocemos?, de estos cuales hemos leído o apropiado “bueno no solo para el quiz de modelado”, como dice  en control disciplinario el desconocimiento de la norma no nos libra de la responsabilidad.

Bueno el nodo está abierto  y disponible desde el ministerio de tecnologías MINTIC,  abierto a recibir aportes  es un reto contribuir desde nuestra formación en nuestro gobierno, en nuestra empresa, en nuestra casa, o seguimos viendo la luna. Es cierto que el hombre llego a la luna, pero cuantos años han pasado donde quedo la evolución, seguimos re inventando la rueda, ¡ahí les dejo ese trompo!

sábado, 22 de agosto de 2015

Ahora si Patrones de GRASP


Ah por la tarea de falsear el cero…

Patrones de Software para la asignación General de Responsabilidad GRASP.

El nombre sugiere la importancia de 
aprehender (grasping en ingles) 
estos principios para diseñar con 

éxito el software orientado a objetos.

GRASP consta de 9 patrones que le ayudan con el aspecto fundamental de la OO Diseño, que está asignando responsabilidades a los objetos.

Las responsabilidades están relacionadas con las obligaciones de un objeto en cuanto a su comportamiento.



Los nueve patrones GRASP son:

5 patrones Principales que son:

-          Experto: 
-          Creador:
-          Alta cohesión.
-          Bajo acoplamiento.
-          Controlador.



Y 4 patrones GRASP adicionales que son:

-          Fabricación Pura.
-          Polimorfismo.
-          Indirección.
-          No hables con extraños.

Huy ese último si es pura sabiduría de abuela colombiana "No hables con extraños...". Bueno a seguir leyendo. Por ahora se acuerdan de la mojarra hay que prepararla!. Hasta el próximo blog.


Un MODELO de pescado



La llamada que no puede faltar al medio día,  hola princesita ¿almorzaste?
  • -          Del otro lado, no mama
  • -          Por qué no si era pescadito a ti te gusta el pescado
  • -          Eso no era pescado ...
  • -          Si  señorita era pescado.  Pienso si filete de tilapia
  • -          No, donde están los ojitos, donde están esas cosas con las que nada, donde está la colita. Ese no es un pescado  ¡Uds. son muy torpes al comprar un pescado!

Tiene toda la razón,  su modelo mental de pescado no correspondía a la imagen que veía en el plato:



 
Lo que esperaba mi hija









 

Lo que estaba en el plato

Conclusión: Decepción.

 Esto nos ha pasado en otras instancias de vida y profesionales.  El símil del requerimiento que ingreso a fábrica de desarrollo vs  el producto final construido.  La pregunta  regresa cuando inician los controles de cambio, en la escala de responsabilidad en fabrica  se inicia el juego de tingo tango haber a quien le queda en la mano -donde estuvo el punto de fallo-, para gestionar ese conocimiento para futuros desarrollos.

Siempre me he cuestionado como se ha  trabajado en la mejora tanto de la arquitectura de las aplicaciones y su refactorización, así como en la mejora de la cooperación entre el llamado negocio y los equipos de desarrollo.   En los RFC no faltaba la frase “aplicar las mejores prácticas”.  Es que en el documento estaba, si ve aquí dice: aplicar ¡las mejores prácticas! Entonces pasa la pelota y ¡tango! Y el negocio dice “Aquí el experto es Usted”. Y era claro si el responsable de abstraer los conceptos de negocio pensaba en el filete de pescado mientras el usuario le describía el pescado con ojos, colita y esas cosas con las que ¡nada!

Y ya que hablamos de mejores prácticas  y patrones (a propósito de la tarea de patrones de GRASP, bueno ese será un próximo blog, ah claro hay que falsear ese cero prometido en clase por no responder). Ahora pienso más las habilidades lingüísticas claves en el trabajo del desarrollador. 

Los patrones de conversación  para obtener un mejor conocimiento de los expertos de dominio, los tipo de preguntas que deberían prohibirse ahí la frase de - La calidad de la información obtenida indica la calidad de las preguntas formuladas -. Los patrones de conversación planteados como  una estrategia bien formulada que ayude a clarificar y entender las necesidades reales del interesado.  Preguntas de calidad, Navegación a través de una conversación, permanecer centrado en  hilo central de conversación, extracción de conocimiento a partir de la información que recopiló durante una conversación. En un curso de SCRUM ante la tarea de escribir historias de usuario vino esa parálisis mental de cómo sintetizar como escribir esa idea en un Post-it,  me acuerdo que nos entregaron de diferentes colores unos aun más pequeños que otros, pero eso no fue de mucha ayuda.

Haciendo la tarea anterior llegue a un párrafo que me pareció cierto pero que no asumimos a ratos en el día a día por  dar una respuesta se obvian la relación natural de los datos. La jerarquía DIKW (Datos, Información, Conocimiento, sabiduría), hace parte de una de las teorías del conocimiento que intenta estructurar y explicar cómo la información pasa por un proceso en el que empezamos teniendo datos aislados; y terminamos adquiriendo un cierto nivel de sabiduría partiendo de estos datos.

Entonces personalmente creo, que el reto en el camino hacia adquirir el nivel de sabiduría, esta en realizar gestión del conocimiento adquirido para aplicarlo de la mejor manera posible en el futuro, pero en no en el mundo difuso y tan ambiguo “con las mejores prácticas, ahí dice”, fundamentados en conocimiento histórico, en un método.

Por ahora a la plaza y a comprar: será mojarra, esa tiene ojitos colita y esa cosa con la que ¡nadan!

lunes, 17 de agosto de 2015

La renovación permanente del conocimiento

Ahí  estábamos   tratando de ubicar  a los convocados a la reunión para ir de una sede a otra, y me preguntaba para qué era la reunión, siendo honestos era la  única que no lo sabía el título del calendario  era Esquema de Servicios de ACD, el arquitecto decía es por su entrega antes de irse al periodo de vacaciones su pupilo junior asintió con la cabeza,  mi compañera de  desarrollo decía es por el decreto  que se está desarrollando. Pensaba o el título asignado al calendario era inadecuado o su nivel de abstracción era altísimo.  

Para dar inicio a la reunión se une un asesor y un coordinador,  por fin el tema de la reunión se debe a la necesidad de negocio sin atender por la dirección de gestión de tecnologías,  los asistentes concuerdan: claro el usuario busca su solución con los recursos que tiene a la mano, lo cual es inaceptable para la dirección puesto que el área misional sigue generando soluciones aisladas replicando bases de datos.  Una mano alzada y viene otro aporte:  No se puede decir si este servicio se duplica hasta conocer realmente la necesidad de negocio porque el servicio actual es uno a uno y el nuevo es masivo, alguien fue directo en las reglas de la consulta equiparándolas con los servicios desarrollados, argumentando: para cada coordinación la manera de caracterizar un evasor es diferente y los servicios construidos están orientados a denuncias. Entonces surgió la frase de la reunión:   “señores es claro que el negocio no conoce el  modelo de su información”  tenemos que empezar por ahí.

Bueno yo seguía con la inquietud de porque estaba ahí  el decreto fue asignado para desarrollo a otra compañera yo estaba a cargo de un proceso misional macro de comportamiento del sistema de aportes parafiscales y le entendí  al usuario que el nuevo requerimiento es un hijo del macro proceso pero que este iba a entrar por el BPM, y entonces  ¡ah sí!  Tenemos un BPM que está  próximo a entrar a producción  el cual modela los procesos del área misional  entre ellos el que estaba en discusión, respecto a las fuentes también están contempladas en el proyecto de Inteligencia de Negocio el cual tiene un diseño aprobado por el área misional, sin olvidar el tan cuestionado CORE.

! Deja vu! vuelvo a pensar en la frase que concluye la reunión: “señores es claro que el negocio no conoce el  modelo de su información”   tenemos que empezar por ahí.  Me quede con esa idea en la cabeza.  Pregunte al grupo quien de los presentes conocía el negocio, y ahí estuvo la respuesta de porque estábamos ahí: la asesora dice cada uno de ustedes conoce un pedazo, acá esta denuncias, caracterización de evasores, seguimiento a administradoras, BPM y liquidador. Pregunte esto porque cuando conocí del requerimiento lo había interpretado diferente, entonces pregunte ¿Cual es la necesidad actual del usuario?, la respuesta  fue que cambio, pregunte ¿El proceso ya fue validado por estrategia porque en la última reunión hace casi 11 meses se había determinado que el proceso tenia flujos que ya existían en el BPM y servicios que se podían re utilizar?.  La respuesta fue que no conocían realmente la solución que el usuario dio, que se debía solicitar el requerimiento y que teníamos esa tarea,  pero que por favor estableciéramos una mesa de trabajo de tal manera que antes de 8 días que el arquitecto se va de vacaciones tengamos un  modelo...

Tres horas después estoy sentada en un laboratorio escuchando la  presentación de la clase Modelado y gestión de la información,  me pierdo en el tablero creo que ese mundo es la organización y que cada uno tiene su propia versión del concepto de negocio, pienso en la pregunta de quien posee la verdad si es que hay tantas aristas por conocer, luego viene la frase que me vuelve al aula de clase "La información como sujeto de investigación", pienso en ese sujeto de investigación entonces mi  objeto de investigación es la información esa misma  información que será percibida por una determinada conciencia, esa conciencia que está en evaluación ahora mismo en esta aula de clase, si se titubea para dar un concepto que se ha manejado tanto tiempo “el mundo” y como se percibe. Y    dado que el conocimiento se da de una manera subjetiva, se necesita del consenso para volverlo objetivo. Todo conocimiento está invadido de parcialidad, cada sujeto cuenta las cosas según su propia experiencia. La historia completa está hecha de lo que vio cada uno de los sujetos que fueron testigos de ella, como garantizar que el modelo es aplicable a diferentes  marcos de referencia, entonces no hay un modelo  realmente universal, no se puede llegar al modelo de negocio que garantice la aprehensión de los diferentes conceptos de negocio,  entonces no todo se conoce desde el principio, es un rompecabezas que hay que ir armando.

Vuelve otra frase en medio del taller: para que inventar la rueda; viene la epistemología la gnoseología a aportar sus estudios para organizar este lío de ideas. Acá estamos en el aula  preguntando  si algo se puede conocer o no se puede conocer y el proceso para el conocimiento, después de conocerlo como modelarlo, cómo validar ese modelo. Re interpretando ese modelo a la luz de su contacto con él,  como despojar esa parte humana en ese acto y ser mas objetivo en ese que a  hacer, como apropiar elementos del investigador en el concepto, bueno vamos a ver ese avance y espero que se vea reflejado en los sistemas que estamos  modelando en nuestro quehacer profesional.  por eso estamos acá de nuevo en un aula la necesidad de la renovación permanente del conocimiento.