Sviluppo Software: dalla teoria alla pratica

(humor, ma sfortunatamente con solide radici nella realtà)

Teoria: Requisiti

5% #

Il committente fornisce le specifiche, colloquiando con degli specialisti che traducono le sue necessità in un documento di specifica che raccoglie i requisiti. Il documento dice cosa il cliente vuole.

Pratica: Requisiti

1%

"Sono andato 4 volte, ma il sig. Rossi, il responsabile EDP non c'era mai; la quinta volta l'ho trovato, ma mi ha detto che lui doveva fare assistenza all'amminstratore delegato che ha preso un virus per email. Allora mi ha indirizzato alla sua segretaria, che mi ha detto 'conosce i dettagli del problema meglio di me'. Allora ho parlato con lei e ho appuntato questi requisiti:

Il programma deve avere queste caratteristiche:

• deve essere bello perché l'amministratore ci tiene all'immagine
• deve essere facile da usare
• deve memorizzare i dati sul disco rigido
• deve gestire il magazzino.

"Ma non gli hai fatto altre domande?"

"Si, una tonnellata, ma mi ha risposto che non lo sapeva. Questo è tutto quello che ho pututo ottenere. Che facciamo?"

"Procediamo all'analisi, che altro vuoi fare?"

Teoria: Analisi:

15% ###

L'analista, esperto sia del dominio del problema che delle tecniche di programmazione, traduce i requisiti in un documento tecnico che spiega come verranno soddisfatti tutti i requisiti del committente, defininedo i dati e l'interfaccia utente.

Pratica: Analisi

2% #

"Quali conti deve fare questo programma?"

"Non lo so, non ce l'hanno detto. Nel contratto c'è un contatto per chiarimenti ma il numero che hano scritto è sempre occupato. Questi qui fanno tubature, e hanno un magazzino, vediamo un po' cosa fanno le altre ditte di tubature e scriviamolo"

"Quali dati ci vogliono?"

"Non ne ho idea. Non si riesce a sapere. Se chiedi ti dicono che hanno un magazzino, e che le merci hanno un costo, e una quantità... Scriviamo questo.

"Okkei, ma per quanto riguarda la facilità d'uso e la bellezza?"

"Beh scriviamo nell'analisi che deve essere bello e facile da usare... è una analisi! Ci penseranno i programmatori.

"Va bene, procediamo".

Teoria: Progetto:

30% ######

L'analisi viene tradotta in un modello software, realizzato con notazioni formali, che strutturano il sofware in modo che sia agevole tradurlo nel linguaggio di programmazione target.

Pratica: Progetto:

5% #

"Come va?"

"Senti io con questo coso, cioè CASE, non ci capisco niente. Se io provo a collegare questo diagramma da qui a qui, vedi che non si attacca all'altro diagramma"

"E se lo attacchi qui?"

"Uhmm oh si, lo tiene. Ma cosa è questo simbolo?"

"Non ho idea, però sembra che ci stia bene nel diagramma".

"Va bene, lasciamolo qui. E tu, hai provato a compilare il codice generato?"

"Si ma non va. Dà una tonnellata di errori. Il manuale dice che si deve modificare il 'template' ma io non so un accidente di Java. Che facciamo?"

"Il capo ha fretta e dice che non dobbiamo perdere troppo tempo con questi diagrammi. L'amministratore urla sempre che 'lui la carta non la paga', ma dobbiamo seguire la metodologia sennò non siamo nella procedure della qualità."

"Allora consegniamo i diagrammi, non diciamo ai programmatori che il CASE dovrebbe produre codice (tanto non lo guarderebbero neanche) e domani li facciamo cominciare a programmare."

Teoria: Codifica

30% ######

I programmatori implementano il progetto, seguendo gli algoritmi e le soluzioni indicate nell'analisi, e la struttura e l'architettura definita nel progetto.

Pratica: Codifica

94% ###################

"A che punto siete?"

"Stiamo ammattendo con le chiavi primarie, ogni volta che provi a cancellare un record dà eccezione. Il fatto è che è tutto generato dall'application server e quindi non abbiamo idea dove mettere le mani."

"Guarda che siete in ritardo. Parecchio"

"Guarda che non ci hanno passato il corso, e quindi ci siamo dovuti pure imparare il linguaggio da soli. E la licenza dell'application server è arrivata la settimana scorsa e sono tre mesi che andiamo avanti con il tomcat?

"Va bene, l'analisi è rispettata?"

"Nell'analisi ci hanno scritto che erano tubature, e invece erano laminati metallici, e lo abbiamo scoperto 'per caso' andando nel magazzino a vedere cosa c'era dentro. Hanno scritto che l'interfaccia doveva essere bella ed ergonomica, e hanno messo degli snapshot di Access come esempio, ma l'applicazione era web e non ci entrava nulla! Quell'analisi andrebbe bene per chiunque, sia che vogliate un gestionale che il software per guidare un robot su marte."

"Come è l'aderenza al progetto?"

"Nel progetto hanno scritto che un utente (vero) era una istanza della classe User, mescolando diagrammi delle classi e use case. C'è uno schema di database per un magazzino che comprende tabelle come "Notizie" e "WorkflowRedazione". C'è uno schema di deployment che collega un palmare a una scheda di rete fissa, e manca il router, ma ci sono tre server, due dei quali non sappiamo a cosa servono."

"Beh l'analisi l'ha fatta il cognato dell'amministratore delegato (che ha studiato giurisprudenza); il progetto l'ha fatto il figlio, che è 'laureando' in ingegneria informatica con 2 esami su 36? Dice sempre che Bill Gates non ha avuto tempo di laurearsi perché doveva lavorare?"

"Che altro potevamo o dovevamo fare?"

"Quello che avete fatto."

Teoria: Test:

20% ####

Il prodotto software realizzato, ben strutturato, con algoritmi già definiti, viene sottoposto a un test per correggere eventuali difetti di codifica. Il software viene infine collaudato dal committente.

Pratica: Test

5% #

"Cosa è successo al collaudo?"

"Appena l'amministratore ha visto le fotografie dei prodotti si è messo a urlare. Ha detto che avevamo sbagliato la tipologia di prodotto. Loro non fanno più laminati da due anni. Fanno rubinetti. Mi sa che abbiamo visto le giacenze di magazzino inventute. Per questo hanno voluto il programma! Perchè non sapevano che quello che producevano non corrispondeva a ciò che vendevano."

"E quindi, cosa cambia?"

"Cambia che i rubinetti hanno parecchi parametri in più, lo stoccaggio è completamente diverso, per non parlare della logistica che non ci azzecca per niente con quella fatta. I laminati li accatasti, i rubinetti no, e hanno anche l'imballaggio da gestire, oltre a cose che nemmeno ti immagini... E poi ha detto che è brutto da morire, che i colori non si intonano con l'immagine aziendale, che non è per niente facile da usare, e che voleva anche una animazione elegante quando si apre il programma così l'operatore si ricorda che lavora per una bella azienda."

"E il collaudo è finito così?"

"No, prima di cacciarci ci ha fatto annotare 12 pagine di richieste di modifiche. Ha detto che per lunedì devono essere pronte.".

Pratica: Modifiche (non previste dalla teoria):

60% #############

"Scusa, ma se qui cambio questa variabile qui, che succede?"

"Non ho idea."

"Ma non l'hai fatto tu il codice"

"Si ma l'ho cambiato 3 volte, a pagina 2 delle modiche diceva di fare una cosa, a pagina 7 un'altra cosa, e all'ultima pagina allullava la modifica di pagina due. Non mi ricordo più cosa ho fatto".

"Provo a cambiare qui e vediamo che succede?"

"Prova pure, tanto qui non ci si capisce più nulla. Peggio di così non può andare può solo migliorare...".

Pratica: Debug (non previsto dalla teoria)

170% ###################################

"E' successo di nuovo?"

"Si, appena ho corretto il baco della giacenza, non mi riportavano più i totali di magazzino, quindi forse quella variabile che hai aggiustato NON era quella che influiva"

"Il problema è che appena cambi una virgola, tutti i conti sballano"

"Suddai riproviamo con il debugger, sono solo le 4 del mattino..."

Pratica: Assistenza (non prevista dalla teoria)

6 mesi ####################################################################... etc etc

"E' sicura che ha messo il quantitativo giusto? Si? Lo ha messo tre volte? E ogni volta viene un numero diverso nella giacenza di magazzino?"

"No guardi, non è possibile che quando clicca su quel bottone compaia NullPointerException"

"Ok, proviamo insieme. Scelga la voce di menù 'Nuovo Articolo'. Come dice? Non compare la voce di menù? Compare la scritta 'translation missing'?"

"La stampante ha emesso 753 pagine con scritto solo ghirigori?"

Pratica: Causa in tribunale (non previsto dalla teoria):

5 anni

(senza barre per limiti dispazio)

"E il fornitore ha quindi caricato il mio cliente il 300% dei costi iniziali, fallendo completamente l'obiettivo della gestione del magazzino, e causando al mio cliente un danno incalcolabile al suo business. Infatti è stato incapace di ottimizzare le giacenze di magazzino (che hanno ancora laminati di parecchi anni fa), di smaltirle per tempo in modo da trasformare la sua produzine dalla rubinetteria e cogliere l'opportunità della riconversione al fiorente mercato della produzione di cornamuse..."