Archive for Febrero, 2007

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

Viernes, Febrero 16th, 2007
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.

Tags: , ,
Posted in Calidad, Casos de Uso, Diseño, Noticias internas, Requisitos | No Comments »

Cultura de Prototipos/Maquetas

Jueves, Febrero 15th, 2007
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?

Tags: , ,
Posted in Calidad, Diseño, Noticias internas | No Comments »

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

Jueves, Febrero 15th, 2007
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.

Tags: , ,
Posted in Calidad, Costos, Noticias internas, Pruebas | No Comments »

Como tener Log en PHP5 y no morir en el intento

Jueves, Febrero 15th, 2007
Log?,

/**
* Classe: Log
* Responsabilidades: Escribe los Logs de usuario en la carpeta log/
* Colaboradores: No tiene.
* Patron: Singleton.
* Uso Principal: Log::getInstance()->addEntry('Mensaje','Classe que invoca','Metodo que invoca',$editMode);
*
* @author Leo Barrientos C. leobarrientos@opendesarrollo.cl
* @copyright GNU
*/

Esta classe genera un log por día en la carpeta log y en modo testMode=true guarda el archivo añadiéndole un .test al final.

Además usa un patrón singletón por lo que la llamada es con el famoso "::" y muy simple:

include_once("Log.class.php");
Log::getInstance()->addEntry('Test','No class','No Method', false);

El diagrama de Classes es el siguiente:


Puedes descargar el archivo haciendo click(Con el mouse) aqui.

Tags: , ,
Posted in Catch, Diseño, Implementación, Noticias internas, Patrones, Try, php5 | No Comments »

Principio de Single Responsibility

Jueves, Febrero 15th, 2007
¿Qué sucede cuando tenemos alguna classe y unos de sus métodos no "suena bien"?, pues es tiempo de aplicar los principios de la orientación a objetos.

En esta oportunidad mostraré un ejemplo del Principio de Single Responsability(SRP).

Supongamos que tenemos una classe Almacen de un sistema de Inventario de Productos, el diagrama de Classes inicial se muestra en la figura 1.


Figura 1: Diagrama de Clases Rev 1.

Pues bien, vamos a aplicar "elegancia" al Diagrama de Classes aplicando el SRP llenando la siguiente tabla:

Classe: Almacén

El almacén __________________

En el espacio vamos agregando los métodos y acomodando el lenguage a ver si tiene sentido en las reglas del negocio de nuestra aplicación.

Classe: Almacén
  • En el almacén se puede agregar un Item.
  • Del almacén se puede remover un Item.
  • El almacén imprime el Inventario.
  • El almacén puede despachar envíos.

¿Hay alguna frase que no tenga sentido con lo que entendemos que hace un almacén? Claro que si:

  1. El almacén no imprime un inventario, lo que hace es devolver la información de todos los items que están en él o sea el Inventario; o mejor aún una lista de Items(List, Collection o array, lo que sea.).
  2. El almacén no despacha envíos, lo que si despacha envíos es un Despachador que solicita ciertos items al almacén.
Con esto, reconocemos los sustantivos y acciones y actualizamos nuestro Diagrama.

Figura 2: Diagrama de Clases Rev 2.

Bueno, ahora revisemos si esto tiene sentido:

Classe: Almacén
  • En el almacén se puede agregar un Item.
  • Del almacén se puede remover un Item.
Classe: Despachador
  • El despachador puede despachar envíos.
Classe: Inventario
  • El Inventario se imprime.

Si, tiene sentido!.

Ahora pseudo codifiquemos un test para ver si funciona:

Caso de Prueba: Imprimir el Inventario actual.

inventario = new Inventario();
inventario.imprimirInventario();
inventario = null;

Si funcionará , pues con UML definimos que el método imprimirInventario depende del método getItems del Almacén y recibirá correctamente el contenido actual del almacén.

¿Comentarios?.

Tags: , ,
Posted in Diseño, Noticias internas, Orientación a objetos, Principios | No Comments »

Calidad: Defectos v/s Fallos

Jueves, Febrero 15th, 2007
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?

Tags: , ,
Posted in Calidad, Noticias internas, defectos, fallos | No Comments »