Quick & dirty
Toda persona que produce soft para que los sistemas  concretos funcionen, alguna vez estuvo ante la alternativa.
El dilema es como "ser o no ser".
Hacer código limpio en términos académicos?  O escribir rápidamente algo que estamos seguros  que funcionara.
La intuición es que hicimos en el pasado algo parecido y funcionó.
Escribimos recordando gwbasic? O pensamos  en pascal?
Los que experimentaron el gwbasic interpretado saben de la adrenalina de avanzar y después encontrarse ante un "spaghetti" enredado básicamente por la invención de cientos  de variables "oportunistas" y de la idea absurda (que  siempre aparece)  de compactar código
He sido encargado muchas veces de asegurar viejos programas y he disfrutado de hacer desaparecer el basic interpretado que esta inyectado en modernos recursos.
Muchas  veces la simplificacion y estructuración consegyidas son enormes.
Pero algunas  veces encontré código simple y astuto haciendo cosas realmente complicadas y son irreemplazables
Finalmente ... quick & dirty es una alternativa válida siempre que no  este en el sweet spot, en el corazón de un código valioso y siempre y cuando las restricciones  de urgencia hayan sido las generadoras de esta alternativa

Reflexiones sobre el diseño

7 herejias

“El campo del diseño de soft tiene una lista de comprobados exitos.

Yo he sido un estudiante de métodos de diseño por cerca de 3 decadas.

A menudo yo he tratado de ejercitar los últimos métodos en situaciones  practicas de programación.

Ocasionalmente he tratado de servir como maestro. Honestamente no puedo informar de algún método que garantice el exito .

Los mejores harán que Ud haga las cosas mejor , pero …. El mejor puede dejarlo en la  via.

Si un dogma no mejora su trabajo , ud tiene la obligación de buscar otra mirada. Lo opuesto al dogma es la herejía.

Yo creo que sirve examinar algunos principios herejes de diseño, aunque estas herejias generalmente merecen su mala reputación. Al final …. Un análisis puede abrir su mente para nueveos enfoques. De malas , esto podrá reforzar su convicción de que no hay un camino confiable para diseñar  software “

P.J. Plauger , Computer lenguaje volumen 8 , number 2 febrero 1991, Programming on purpouse heresis of software design

Herejia 1 – si sabes exactamente como hacerlo , no esta mal hacerlo

Herejia 2 – Si nunca lo has hecho antes , TU NO sabes como hacerlo

Herejia 3 -  confía que: los clientes o analistas de sistemas te diran como hacerlo mal

Herejia 4 – Haga un prototipo del sistema para descubrir QUE NO HACER

Herejia 5 – Si no entiendes como aplicar un método de diseño. Probablemente no es su culpa

Herejia 6 – No tunees un sistema si puedes escapar sin tunearlo

Herejia 7 – No te metas en proyectos o trabajos que están demasiado lejos de tu nivel de experiencia 

El rol del Tester en las metodologías ágiles

fuente: la oficina de proyectos de informatica http://www.pmoinformatica.com/

Podemos definir el rol del Tester en las metodologías agiles por medio de las siguientes actividades:

-Entender, implementar y mantener actualizada la estrategia de pruebas Agile Testing.
-Trabajar con los dueños del producto (Product Owners) para definir los criterios de aceptación y las definiciones de “hecho” (Done) de las historias de usuario.
-Medir y reportar la cobertura de pruebas sobre todas las dimensiones de cobertura que sean aplicables.
-Asegurar que el equipo de trabajo use adecuadamente las herramientas de pruebas.
-Configurar, usar y gestionar los ambientes de pruebas y los datos de prueba.
-Desarrollar y ejecutar pruebas automatizadas y reportar los resultados al equipo.
-Reportar los errores (bugs) y trabajar con los desarrolladores en su resolución.
-Dar coaching a otros miembros del equipo en los aspectos relevantes al Testing.
-Asegurar que las actividades de Testing sean incluidas en la planificación de la iteración y de salidas a producción (Releases).
-Colaborar activamente con los desarrolladores e interesados de las áreas de negocio para clarificar los requerimientos, especialmente en lo referente a que estos puedan verificarse, su consistencia y completitud.
-Participar proactivamente en las reuniones diarias (Daily Standup), sesiones para el desarrollo de historias de usuario y en las retrospectivas, sugiriendo e implementando mejoras

Diseño : Formulacion del problema

⏃Si todas las soluciones fueran igualmente satisfactorias , NO EXISTIRIA EL PROBLEMA
⏃Si la solucion preferida es obvia desde el principio , NO EXISTE EL PROBLEMA
⏭El caso general requiere un estado inicial (A) y un estado final mas stisfactorio (B)
⏭Existen requerimientos que se "deben" cumplir (RESTRICCIONES)
⏭Siempre habra mas de un metodo del lleva A a B .Pero no todas las soluciones son igualmente deseables.Siempre existe una base de preferencia que se denominara CRITERIO.
⏭El numero de veces que se debe llevar A a B hace un difertente costo total.,
⏭Existe un periodo de tiempo requerido para obtener la transformacion

Competencia

Dos Gladiadores luchan en un circo .

El resultado estara determinado por el uso que cada uno haga de cuatro recursos:

Armas:  Bienes y servicios ofrecidos a los clientes

Imaginacion: diseño de productos ,  posicionamiento , distribucion

Fuerza :recursos financieros

Agilidad: busqueda de nichos o nuevos mercados
A estos clasico factores yo agrego:
-Entrenamiento :preparacion y experiencia en enfrentar situaciones analogas
-Capacidad de Formulacion de la Situacion Problema: capacidad identificar el dominio y los recursos de la competencia  para  orientar (desde el principio) los otros recursos eficientemente

4 tips de la relacion cliente-consultor (visto en rules.ssw.com.au)

➤A menudo los clientes nos llaman para un trabajo corto ...
Ud. necesita s hacerles saber que les sera computado el pequeño tiempo
"si fuera tan poco como 5 minutos lo haría sin preguntar nada..... Pero  necesitare investigar un poco. Mi primera impresión es que podría ocuparme un par de horas
Si eso es así , necesito que me autorice a avanzar.
Hagamelo saber...
-------------------
➤Ud. Evita facturar donde sea posible y  resuelve los problemas  rápido a medida que suceden?
La parte mas indeseable de la consultoría es tratar con clientes que no pagan por sus servicios
Es importante que los clientes sean advertidos desde el principio que es lo que sera cobrado y que no. De ese modo ellos nunca recibirán una factura que no están esperando y entonces estarán contentos de pagarla.
Si un temas se nos viene, asegúrese de llegar a un acuerdo rápidamente. no deje que se encamine a una falta de satisfacción y las personas se empantanen en ocupar tiempo trabajando con la incertidumbre si el cliente pagara o no
Si alguien mas necesita ser consultado por la aprobacion , contactase inmediata mente
----------------------------------
➤sabes la diferencia entre una reunión para acordar propósitos y un a revisión de especificaciones?
reunión para acordar ... gratis
-información a cerca de nuestros antecedentes
-información a cerca de lo que podemos hacer por ellos
-fijar proximos pasos
reunión para revisar especificaciones  ... se factura
-habrá un documento de metas , planes  y estimaciones
------------------------------
➤si ya es un cliente: llamarlo antes de enviarle una comunicacion de presupuesto
"De lo que hablamos hoy , acá te mando una estimación programada para el trabajo que hablamos. Podrás identificar todas sus partes. Estaré contento de discutir esas estimaciones contigo, por lo tanto puede llamarme"

Matriz Conceptual de Procesos

La transformación de datos disponibles en información de alguna utilidad para la empresa , se hace fundamentada en conceptos estructurados eficientemente para obtener los beneficios pregonados.

Un soft tiene validez solo por los beneficios que aporta. Esos beneficios son mensurables y determinados por la "ciencia" que los fundamentan.

Esta estructura elegida, ha mostrado gran utilidad para aprovechar conocimiento (conceptos , know how) de diferentes disciplinas (ínter y transdisciplinarios.)

Imaginemos cada celda como un "tanque o repositorio" de reglas, teorías , requisitos , especificaciones , buenas practicas, patrones , experiencia exitosa especifica, etc que colabora al objetivo de disponer la información necesaria para alcanzar los fines seleccionados con la efectividad , eficiencia y eficacia requerida.

Cuando incorporamos  estos conceptos en nuestro soft ? en la etapa de especificación y diseño es el estadio de mayor rendimiento. Obviamente en el desarrollo reusamos/incorporamos código probado

  

Escrito por Leonardo De Seta

El acoplamiento y la cohesión juegan un rol central en el diseño de software. Yourdon y Constantine, en su obra clásica Diseño Estructurado, identifican que el objetivo del diseño es minimizar los costos. El costo del software está determinado por el costo de mantenimiento, y el costo del mantenimiento está determinado por el costo de los cambios que surgen en el sistema. Un diseño de software efectivo minimiza la probabilidad de que se propaguen los cambios. Los cambios que involucran a un único elemento son menos costosos y más predecibles que los cambios a un elemento que requieren cambiar dos más, y luego tres...

El costo esperado del cambio se puede reducir prestando especial atención a dos factores: el acoplamiento entre los elementos y la cohesión dentro de los elementos.

(El diseño de software también es importante para incrementar o acelerar las ganancias, pero las ganancias no están directamente conectadas al acoplamiento y la cohesión)

Acoplamiento

Dos elementos están acoplados en la medida en el que los cambios en uno tienden a necesitar cambios en el otro. Por ejemplo, la comunicación por red entre dos sistemas está acoplada respecto a cambios en el protocolo - si un sistema necesita ambiar el protocolo, el otro va a necesitar cambiar también. El acoplamiento entre los elementos es un conductor de cambios.

El acoplamiento propaga los cambios

Hablamos de acoplamiento (y cohesión) en términos de cambios particulares. Esta no es la definición estándar. El acoplamiento suele definirse como una propiedad estática: dos elementos están temporalmente acoplados si, por ejemplo, la secuencia invocante entre ellos está restringida. Estas propiedades estáticas son sólo costo potencial: si no ocurre ningún evento que dispare el acoplamiento, el costo nunca ocurre.

Un sistema podría estar acoplado a un proveedor de bases de datos específico, al utilizar características propias de ese proveedor (por ejemplo, de Oracle). Un cambio en la base de datos va a provocar cambios al sistema. Sin embargo, si la base de datos nunca cambia, entonces el acoplamiento es sólo potencial. Evaluar el costo del acoplamiento con precisión requiere de la evaluación del grupo de cambios que son realmente requeridos en el sistema. Y esto sólo puede hacerse a posteriori. Evaluar los costos en retrospectiva requiere estimar la probabilidad de los tipos de cambios que se propagarían a través de relaciones.

La relación entre el acoplamiento y el costo del cambio funciona en ambos sentidos. Los cambios que parecen ser más costosos van a ser menos probables que se elijan para hacer. Al romper el acomplamiento se crean oportunidades para nuevos tipos de cambios, antes imposibles de pensar.

Hay mucho más para decir sobre los distintos tipos de acomplamiento, y los tipos de cambios que se propagan. El concepto fundamental es que los elementos en un diseño no deben estar acoplados con respecto a los cambios que realmente van a ocurrir. Esto mantiene contenido al costo de los cambios.

Cohesión

El acoplamiento mide la dispersión del cambio a través de los elementos. La cohesión mide el costo del cambio dentro de un elemento. Un elemento es cohesivo a medida que cambia el elemento entero cuando el sistema necesita cambiar.

Un elemento puede tener poca cohesión tanto por ser muy grande o muy pequeño. Un elemento muy pequeño, que resuelve sólo una parte del problema, va a necesitar estar acoplado a otros elementos para resolver las otras partes del problema. Si cambia la solución se va a necesitar cambiar todos los elementos. Un elemento que resuelve muchos problemas sólo va a necesitar cambiarse en parte. Esto es más riesgoso y más costoso que cambiar un elemento completo, porque primero se necesita averiguar qué parte del elemento debe cambiarse, y luego probar que las partes sin cambios del elemento realmente sigan sin cambios. Los elementos cohesivos, que se reemplazan en su totalidad, no tienen estos costos.

La estrategia de aislar los cambios es una forma de inducir la cohesión antes de hacer un cambio; por ejemplo, extraer la parte de un método que necesita cambiarse dentro de un método propio antes de hacer el cambio.

Balance

Una de las cosas que hace divertido al diseño es que necesita ser balanceado. Si los elementos son muy grandes, cada cambio va a ser más costoso de lo que necesita ser. Si los elementos son muy chicos, los cambios van a esparcirse por todo el sistema. Y la optimización del diseño ocurre sobre un flujo impredecible de cambios.

Los elementos que son muy grandes tienden a multiplicar el costo del cambio: N * C. Los cambios que se propagan a través de los elementos pueden resultar potencialmente más caros: C ^ N. (Estas fórmulas son simplificadas y a modo de ejemplo, no para usar literalmente). Esto sugiere que debe invertirse más tiempo en reducir el acoplamiento.

El gran desafio del diseño es reducir el acoplamiento de forma no costosa. Si un elemento puede aislarse de un cambio probable que ocurra en otro elemento a un costo razonable, entonces es mejor hacerlo antes que después. Romper con otras formas de acoplamiento va a resultar más costoso y puede resultar mejor dejarlo hasta que ocurra el evento de cambio. Nuevamente, lo divertido del diseño es justamente la imprecisión de este análisis.

Como los cambios son impredecibles se hace imposible determinar de forma estática el "mejor" diseño para un sistema. Siempre va a ocurrir algún cambio que se propague por el sistema. Lo importante es crear diseños que disminuyan el costo de los cambios, sabiendo que nunca es posible llegar al costo cero.

Tomado de Dosideas.com

GRADOS DE LIBERTAD DE UN PROGRAMA (acoplamiento)

-El exe no tienen configuracion +1

-El exe  se invoca desde cualquier lado  +1

-Los datos generados  no son compartidos +1

-Los datos  utilizados no son compartidos +1

-La ejecucion del exe no necesita de parametros +1

-Los datos pueden estar en  ubicacion diferente de donde esta el exe +1

-Los datos de configuracion no son compartidos +1

 Total de grados de libertad del EXE =7

-El exe  tienen archivo de configuracion -1

-El exe se ejecuta desde donde se invoca -1

-Los datos generados y utilizados son compartidos -1

-Se utilizan datos compartidos ,generados por otros exe -1

-La ejecucion del exe necesita de parametros -1

-Los datos de configuracion son compartidos -1

-El directorio de datos debe ser el directorio del exe -1


Total de grados de libertad del EXE =0
Mas grados de libertad .... mayor independencia , mayor mantenibilidad ,