Categoría : Calidad

catch (Exception e) {}

Hola, me gustaría compartir con vosotros un viejo truco de los programadores Java. Cuando empezamos a hacer algo medio serio con el lenguaje, a la primera compilación nos encontramos con que el compilador nos molesta constantemente en lugares donde hemos invocado métodos de terceros, con mensajes como éste: unreported exception java.io.IOException; must be caught or […]

Leer Más →

Listado de características v/s Casos de Uso.

Se supone que cuando empezamos en un desarrollo tenemos un listado de características con lo que debe hacer el sistema y luego hacemos nuestros Casos de Uso. El tema es ¿Cuál debo hacer?, ¿Es mejor cumplir una característica completa? o ¿enfocarnos en los casos de uso?, la respuesta es “depende“.

Plantéo el siguiente escenario:

La aplicación debe :

  • Enviar un SMS que indique tiempo al cual se encuentra un Autobus desde un paradero al recibir un SMS con el siguiente formato: “Paradero LineadeAutoBus” Ej.: 105 591

Esto de “la aplicación debe” son nuestro Listado de Características.

Y como consecuencia de este Listado de Características obtenemos los famosos Casos de Uso, que serán nuestra compañía el resto del desarrollo.

Los Casos de Uso son:

¿Con que partimos para desarrollar?, pues tenemos las 2 alternativas:

  1. Realizar la Característica 1.
  2. Realizar un caso de uso.

Para decidir se considera el nivel de visibilidad comprometido, si el cliente tiene un poco de paciencia podemos partir por los casos de uso; si no partimos con la característica.

Estoy seguro que el desarrollo con casos de uso nos permitirá un diseño elegante desde un primer momento, pero que a lo mejor tardaremos un poco más en mostrar algo completo – recordemos que los clientes quieren resultados, no diagramas de Ingeniería que sólo nosotros entendemos – debemos hablarle en su lenguaje.

Si tenemos un poco más de tiempo conviene comenzar con los Casos de Uso, si no tratemos más “visual” el entregable y realizemos primero alguna de las características. Finalmente el producto tendrá la calidad de hacer lo que tiene que hacer, de haber aplicado principios de OO y la elegancia de los patrones de diseño.

Leer Más →

Cultura de Prototipos/Maquetas

Como todos sabemos – pero nos cuesta aceptarlo – la única constante en Desarrollo de Software es el cambio.

El maldito cambio, simplemente debemos ser más inteligentes: Tener en la cabeza que las cosas cambian y que nuestra obsesión por implementar funcionalidad lo antes posible con classes perfectas nos lleve a codificar de más.

¡Pero un momento!, ¿codificar de más?, si – aunque me costó creerlo mientras antes se empieza a escribir código más tarde finalizaremos el proyecto.

¿Por qué?, por que nuestra obsesión no considera que los cambios ocurrirán y que el cliente simplemente quería otra cosa, o se ajustó esta regla de negocio y tal, y tal, y tal, y tal …….

Solución: Cultura de Prototipo.

  1. Conversamos con el cliente.
  2. Formalizamos lo conversado en una Lista de Características.
  3. Revisamos con el cliente esta lista.
  4. Especificamos los requisitos de las características que tienen mayor prioridad.
  5. Hacemos un protipo – sin funcionalidad.
  6. Revisamos con el cliente el Prototipo/Maqueta (que tardamos a lo más 2 horas en hacerlo con HTML o drag&drop), revisamos la Lista de Características y así nos aseguramos que vamos bien con el cliente.
  7. Repetimos en cada iteración que sea necesario.
  8. Continuamos con los paso habituales de Desarrollo Iterativo e Incremental.

Se ve muy simplista, estoy de acuerdo, lo importante es que ya estamos listos para:

  1. Asegurar que el sistema hará lo que el cliente quiere.
  2. Aplicar principios de OO.
  3. Aplicar patrones de Diseño y le damos caracter de Ingeniería a la obra de arte.

En ese orden, funciona créanme!.

Con un gran amigo aprendimos que no hay que mostrar los diagramas de classes, ni nada parecido al cliente. Le mostramos los artefactos en su propio lenguaje: Un listado de características en el cual identifique cláramente lo que quería.

A pesar de todo esto siempre surgirán nuevos cambios, pero ya tendremos una arquitectura extensible y no hemos perdido horas de trabajo de implementación – No existen malos equipos, sólo malos líderes.

¿Si, te parece que eso lo implementemos en la próxima versión?

Leer Más →

Hacer pruebas es lo más ineficiente, pero peor es nada!.

Si es verdad, hacer pruebas es lo más ineficiente para controlar la Calidad de nuestro software. ¿Por qué?, muy simple: Los números no mienten.

Del 100% de los errores, se pueden encontrar tan sólo el 7% a través del compilador-Intérprete.

Algunas opiniones dicen que si como desarrolladores dependemos del Debug y el Compilador para encontrar errores – manifestados como Fallos o Defectos – en realidad es porque no sabemos desarrollar.

La cosa es : “Mientras antes observemos la calidad, más posibilidades se tiene de encontrar errores“.

Algunos datos empíricos gringos:

La distribución de defectos es:

      • 56% en Especificación de requisitos.
      • 27% en Diseño.
      • 7% en Implementación.
      • 10% Otros.

Los errores más importantes los cometemos al especificar requisitos, debemos recordar que una aplicación no está libre de errores si compila; sino que al no hacer lo que la aplicación debe hacer siguiendo las reglas de negocio.

No es buena práctica esperar a realizar las pruebas para comprobar la calidad, puesto que simplemente descubriremos menos errores.

Por otra parte los costos al finalizar un Proyecto y encontrar errores en cada Flujo de Trabajo es:

    • Especificación de requisitos : 82%
    • Diseño: 13%
    • Implementación: 1% (Si, 1 %).
    • Otros: 4%.

Imagínense que están entregando el Proyecto y no hace lo que se supone que debería hacer: ¿Quién está a cargo de especificar requisitos en tu equipo de trabajo? ….

Ahora si queremos corregir los errores, los costos son exponenciales mientras más tarde nos preocupemos de la calidad:

En un proyecto mediano

    • Corregir errores anteriores mientras Analizamos cuesta en promedio 200 Dólares.
    • Corregir errores anteriores mientras Diseñamos cuesta en promedio 500 Dólares.
    • Corregir errores anteriores mientras Codificamos cuesta en promedio 1200 Dólares.
    • Corregir errores anteriores mientras se hacen las Pruebas cuesta en promedio 5000 Dólares.
    • Corregir errores anteriores estando en Operación cuesta en promedio 15000 Dólares.

De verdad las pruebas no son suficientes y no son sinónimo de Control de Calidad.

Leer Más →

Calidad: Defectos v/s Fallos

Muchas veces hablamos o escuchamos “Hey, encontré estos errores en el sistema….”, ante esto podemos hacer 2 cosas inmediatas :

  1. Cuestionar nuestra existencia.
  2. Agradecer, pues nuestro Software una vez corregido será mejor.

Creo que la mejor opción es la 2, sin embargo para llegar a esto hemos cometido un error muy grave : “Hemos permitido que un defecto se convierta en un Fallo”.

A modo de aclarar conceptos debo decir que un :

  • Error: Lo comete un humano durante el Proceso de Desarrollo.
  • Defecto: Es la consecuencia de un error.
  • Falla: Es un defecto no detectado y que no está eliminado.
  • Fallo: Defecto que se manifiesta durante la ejecución.
  • Incidente: Comportamiento no esperado.

Evidentemente la mejor forma de que no ocurran fallos es evitar escribir con errores que produzcan defectos. Para aumentar la calidad de nuestro producto artístico de Ingeniería de Software debemos realizar un control estático; que en palabras simples no es que otra cosa que otro developer amigo revise el código (Si leerlo) y retroalimente tu trabajo.

Está comprobado que la calidad del Producto software aumenta inmediatamente si los desarrolladores sabemos que nuestros artefactos serán revisados (Leidos, comentados) por otras personas, en lo llamado Control estático.

Muchas personas relacionan la calidad del Producto con que pase las pruebas – Control dinámico – antes de entregarlo, error gigante!!!; el control estático es preventivo y es más eficiente pues obliga inmediatamente a implementar buenas prácticas.

La frase final de este Post es : ” Preocuparse de evitar y corregir los defectos antes que ocurran los fallos.

¿Comentarios?

Leer Más →