-Un programa terminado contiene todos los defectos posiblesY los que no sean los que pusimos nosotros , es probable que se generen por el ambiente pero ...Que se manifiesten como fallas ...mmmm. sigue siendo una cuestión de probabilidades.-

Hace mas de 20 años cuando llego la ola de los formalismos , se hizo notable un tema: la fiabilidad del software . con mucho fundamento estadístico se proclamaba aspectos ingenierles en esta profesión. Me pareció fantástico que al fin los términos modelo , distribución , esperanza , muestra ... etc etc etc iban a ser parte del normal arsenal de conceptos del programador
Tema no apto para los programadores iluminados , menos para los que provenian de áreas no formales o sin nivel matemático.
Fue una oprotuna inspiracion , hoy en los centros de desarrollo de la ingenieria continua el debate

"El tamaño, la complejidad y la dependencia humana de los productos basados en software han crecido dramáticamente durante las últimas décadas. Los desarrolladores de software están luchando para entregar software confiable con un nivel aceptable de calidad, dentro del presupuesto y el cronograma dados.
Una medida de la calidad y confiabilidad del software es la cantidad de fallas residuales . Por lo tanto, los investigadores se están centrando en la identificación del número de
fallas presentes en el software o la identificación de los módulos del programa que son más
 probable que contenga fallas.
 Se han desarrollado muchos modelos usando varias técnicas. Se sigue un enfoque común para la predicción de fiabilidad del software utilizando datos de falla.
 La confiabilidad del software y la predicción de la calidad es altamente deseada por los promotores , desarrolladores, gerentes y usuarios finales. Detectando software las fallas al principio del desarrollo definitivamente mejorarán la confiabilidad y calidad de manera rentable."  A. K. Pandey and N. K. Goyal, Early Software Reliability Prediction, Studies in Fuzziness and Soft Computing" ...
...
"Los modelos de confiabilidad del software generalmente se refieren a estimar el número de
errores en un software parcialmente depurado. Las pruebas realizadas en el software resultan
 como : aceptado, condicionalmente aceptado o rechazado. La aceptación puede ser
basado en la cantidad de errores encontrados durante un período de tiempo seleccionado, en el número de caminos ejecutados del número total de caminos disponibles para ser ejecutados, o algun  otro criterio preestablecido. Una variedad de modelos de confiabilidad ahora compiten por
la atención del analista
Los modelos de confiabilidad de software se pueden categorizar ampliamente
como lo sugirió Pham (2006):
• Determinístico: utilizado para estudiar la cantidad de operadores y operandos distintos
así como las instrucciones de la máquina en el programa. Los dos  más comunes  son:
- La métrica de software de Halstead, basada en el no exclusivo. de operadores y operandos.
- Métrica de complejidad ciclomática de McCabe, basada en el número ciclomático V (G).
• Probabilistico: describe la ocurrencia de falla y / o el fenómeno de eliminación de fallas
del proceso de prueba como eventos probabilísticos con respecto al tiempo y / o prueba
esfuerzo. Algunos modelos probabilísticos comunes incluyen los siguientes (Pham 2006):
- Modelo de tasa de fallas (tiempos entre modelos de falla).
- Modelo de falla o conteo de fallas (modelos NHPP).
- Error o modelo de siembra de fallas.
- Modelo de crecimiento de confiabilidad, etc."
 Ajeet Kumar Pandey 2013
Aunque ninguna técnica puede determinar el número de errores restantes con precisión absoluta, la medición sistemática de la tasa a la que se están descubriendo nuevos errores proporciona una pista valiosa sobre la calidad del software. El principio básico de esta técnica es intuitivamente atractivo:
Cuanto mas defefctos hay en un programa , mas fácil es descubrirlos.

el numero de nuevos bugs por unida de tiempo de testeo , tiende a disminuir con el tiempo en la medida que los defectos de un programa son descubertos y solucionados.
Midiendo la tasa de decaimiento en el descubrimiento de defectos a travez del tiempo en un proyecto,el numero de bugs no detectados que quedan en un programa, puede ser inferidos con un alto grado de confianza
James Walsh Determining software quality .Computer languaje abril 1993

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"