Aquest és un exemple de cóm funciona un desenvolupament “clàssic”. Encara no he aprofundit en els mètodes “agile” com per a poder saber fins a quin punt és millorable. Diguem que funciona, i que per tal de donar una visió dels diferents rols que un desenvolupador por exercir ens servirà.

La necessitat, o els requeriments
De bon matí arriba l’usuari i diu “tinc gana”.

error: qualsevol “pas documentat” d’un projecte ha de ser breu, però concret. “Tinc gana”, “vull menjar” i frases com aquesta només poden portar al desastre. Per exemple: l’analista demana una eina que permeti portar menjar a l’usuari. La resta del procés continua, fins que es posa en marxa l’eina. És un robot que surt de casa l’usuari, busca un restaurant, demana un menú de tres plats i el porta a l’usuari. L’usuari diu “jo només volia matar la gana, no em calen tres plats d’un restaurant, que a més se me’n va de pressupost”.

L’Anàlisi (antigament “anàlisi funcional”)
Quan es comença un projecte, la tasca de l’analista és determinar d’una manera prou concreta i clara les necessitats de l’usuari. En aquest cas, comença el procés amb una série de preguntes del tipus “molta o poca?”, “dolç o salat?”, “car o barat?”. D’aquest intercanvi d’informació en surt l’anàlisi: “ens cal xocolata”

El disseny (antigament “anàlisi orgànic”)
Partint de l’anàlisi, el dissenyador construeix sobre el paper una col·lecció d’elements que permeten arribar a l’objectiu. Un bon disseny condueix a un producte eficient i eficaç (de consum reduït, fàcil de mantenir, etc): “baixa a la botiga i porta xocolata”

El programa (antigament “programa”)
És el resultat final, allò tant esperat que permetrà a l’usuari satisfer la seva necessitat.

Les proves
Ens hem d’assegurar que el programa satisfà les necessitats del client i que ho fa de la manera més eficaç possible. Per això es porten a terme (un nombre de cops indeterminat en funció de l’organització del projecte, la metodologia o la grandària del mateix) les proves.

En un món ideal, les primeres proves es realitzen amb l’ajuda del que anomenem “jocs de proves”: un conjunt bàsic de dades i instruccions que permeten al programador veure que el programa que ha escrit satisfà, o sembla fer-ho, les necessitats de l’usuari. Si el joc de proves diu “ha de portar xocolata”, i l’eina porta plàtans, el programador ha de revisar i arreglar (o refer) el que calgui fins que l’eina proveeixi xocolata.
Un cop realitzades aquestes primeres proves, l’equip realitza una sèrie més exhaustiva de proves, forçant l’eina de tal manera que qualsevol punt feble aparegui i es pugui arreglar. Pot ser que l’eina hagi portat xocolata perquè era el primer que ha trobat, i si canviem algun paràmetre (la distribució de la botiga), potser el programa en comptes de buscar la xocolata porti el primer que trobi, que són tomàquets.

El cicle de desenvolupament
Durant tota la meva vida com a desenvolupador, i quan he tingut sort, el procés de construcció de les eines ha estat més o menys aquest, i sempre enfocant els esforços en produir i entregar la totalitat del projecte de cop. Però no té per què ser així. Es pot partir el desenvolupament en parts més petites, repetir el procés per a cadascuna d’elles i, ja per arrodonir-ho, fins i tot ciclar cada part: es fan les proves, l’usuari revisa i suggereix/demana canvis i/o millores, i es repeteix. Tants cops com calgui (o com permetin el temps i el pressupost) per a tantes parts com definim fins a tenir l’eina més completa possible.

Un projecte hauria de ser sobre un 90% de paper i un 10% de codi. PERÒ per “paper” entenem “disseny” i no “documentació”. Ja en parlarem.