| Come
distinguere |
...tra
qualità... |
...e
inutilità |
| Scopi
del software |
Ogni
software nasce con due scopi:
1) risolvere
qualche problema;
2) accelerarne
la soluzione in modo automatico. E' pertanto indispensabile che un pacchetto
applicativo sia utilizzabile con immediatezza non solo da chi conosce precisamente
i dati, i passaggi della elaborazione ed i risultati richiesti, ma anche
da chi di tali elementi sa solo i legami principali. Se risponde a queste
caratteristiche il software può raggiungere entrambi i suoi scopi. |
Un
software che non affronta un determinato problema, ma che cerca molte e
diverse soluzioni a problemi diversi è "generico" e non può
trattare a fondo ogni singolo tema. Tradisce il primo scopo del software
e fornisce risultati difficilmente inseribili in una relazione di stampa:
non è consigliabile per chi lavora con i programmi in modo professionale.
Ugualmente
un simile pacchetto non può essere veloce nell'elaborazione se non
per trovare pochi risultati e non esaustivi del problema. |
| Risoluzione
di problemi |
Un
problema viene risolto quando:
1) si
semplificano i termini della sua trattazione in senso qualitativo;
2) si
riducono gli elementi in senso quantitativo.
I termini
divengono più familiari se sono sotto il controllo del software
che presenta liste di dati tra cui scegliere, fornisce spiegazioni in linea
su di essi, non accetta valori non significativi, guida l'operatore in
difficoltà, indica eventuali errori non solo nella fase di input,
ma anche in quella di output, garantisce il raggiungimento di un risultato
apprezzabile.
I dati
da introdurre si riducono quando il software prevede automaticamente le
associazioni logiche tra gli elementi dispensandone dalla digitazione,
consente la copia di valori simili anche in senso matriciale, presenta
quantità preimpostate. |
Un
problema non viene risolto quando i termini della sua trattazione sono
chiari solo per lo sviluppatore e non possono essere affrontati da un operatore
qualificato, ma non esperto del problema: quanti studi tecnici di ingegneri
e architetti hanno dei geometri tra i collaboratori?
Ugualmente
resta il problema se, oltre alle difficoltà nella introduzione dei
dati qualitativi, non sono previsti metodi per ridurre la quantità
dei dati da immettere. Anche l'apertura di files archiviati con la possibilità
di correggere le parti da modificare per una nuova elaborazione può
essere d'aiuto per eliminare le grandi quantità di dati ripetitivi.
Nello sviluppo di un software non è sufficiente conoscere bene il
problema da elaborare, ma anche la logica associativa dei dati di input
e dei valori da preimpostare. |
| Accelerazione
della soluzione |
Nello
stesso tempo la soluzione del problema viene accelerata se, oltre alla
fase di input, è stata costruita con efficienza la struttura elaborativa
del software. Con il progressivo aumento della velocità dei computers
potrebbe apparire non influente la qualità del codice di un programma.
Iin realtà ciò è vero solo per i pacchetti che gestiscono
poche quantità di dati e comunque anche in questi casi è
importante visualizzare i risultati con immediatezza. E' dimostrato che,
per soluzioni che prevedono parecchie correzioni in fase di input, una
elaborazione più lenta, anche di pochi secondi, crea fastidio nell'operatore.
Figurarsi per programmi con centinaia o migliaia di dati. |
La
velocità dei moderni elaboratori viene frustrata se i metodi utilizzati
nel codice di programmazione si disenteressano di raggiungere i risultati
con il minor numero possibile di operazioni matematiche e logiche. E' un
grave errore pensare che ci si possa adagiare sulle capacità elaborative
e di memoria del computer: esso è un mezzo che va saputo impiegare.
Un proverbio dice che "lo strumento è mezzo sonatore": è
comunque necessaria l'altra metà per avere risultati accettabili.
Si potrebbe
dire che è inutile avere una Ferrari se poi la si usa per trasportarci
i mattoni e il cemento per costruire un muro. Il software deve essere ben
più veloce di una elaborazione manuale del problema: non sempre
succede. |
| Un
esempio |
Per
spiegare con un semplice esempio questo fatto ci si può riferire
al metodo delle "successive bisezioni" (o del "semintervallo"). Se si deve
trovare un determinato valore in un intervallo si procede in questo modo:
1) si
divide l'intervallo in due parti uguali;
2) se
il centro coindice con il valore cercato il problema è risolto altrimenti...
3) si
confronta dove cade il valore da cercare, se nella prima o nella seconda
metà e si torna al punto 1.
Con
pochi passaggi si può trovare la radice di una equazione non lineare
(normalmente una sola nei problemi strutturali). Diversamente si dovrebbe
effettuare un ciclo partendo dall'inizio dell'intervallo ed iterando le
operazioni con successivi incrementi.
Le due
strade sono di diversa lunghezza temporale: una sezione in cemento armato
potrebbe essere progettata o verificata in tempi molto diversi, anche dieci
volte in più. Con dieci correzioni dei dati di input si potrebbe
arrivare a cento volte il tempo necessario. |
Se
invece di trovare la radice di una equazione non lineare con il metodo
delle "successive bisezioni", si procedesse con un ciclo iterativo e con
il continuo confronto dei risultati si attuerebbe un metodo più
facile da scriversi in codice, ma anche una elaborazione più lenta
e molto meno tecnica. Chi usa il software sarà sempre ignaro delle
soluzioni adottate nelle istruzioni che non vengono viste, ma ne subirà
le conseguenze ogni volta che lo adopererà. Ma se è difficile
controllare quale codice sia più logico nella sua stesura vi è
una spia del metodo lavorativo di chi lo produce: le finestre visualizzabili
con i rispettivi oggetti grafici. Se anche queste sono organizzate in maniera
che si giudica poco logica è molto probabile che anche il codice
è impostato nella stessa maniera: è difficile pensare che
la stessa persona, il responsabile dello sviluppo del pacchetto, controlli
differentemente due aspetti ugualmente importanti del software. Quale tecnico
progetterebbe una casa sgraziata esternamente e meravigliosa all'interno
o viceversa? |
| I
risultati |
I
risultati di una elaborazione devono essere esaustivi, ma senza indulgere
alla ripetitività e comunque in risalto vanno sempre portati i valori
più significativi per la soluzione del problema. A video devono
essere visualizzati con immediatezza quelli che più interessano
con l'indicazione evidente della conclusione. Il feed back deve essere
sempre possibile: controllare, correggere, rielaborare. In queste tre operazioni
risiede il lavoro di affinamento verso una soluzione ideale. Un programma
ben costruito consente in ogni caso di poter ripetere e confrontare continuamente
più soluzioni possibili: non bisogna mai dimenticare che è
l'uomo che risolve un problema, il computer è solo un suo strumento.
Un programma che fornisce in maniera automatica o quasi delle soluzioni
non è un buon programma ed il problema viene affrontato in modo
superficiale e non professionalmente. |
Quando
si ottengono dei risultati minimi o poco chiari, quando ugualmente non
sono chiare le operazioni che li hanno generati e non sono discusse in
una eventuale relazione stampata si è certamente di fronte ad un
programma di pessima qualità. Se non sono possibili le modifiche
senza dover ridigitare tutto e senza visualizzare in modo istantaneo o
quasi i conseguenti risultati si è ugualmente in presenza di un
pacchetto poco versatile e praticamente inutile. Allo stesso modo
un programma che fornisce risultati di cui non si è certi dell'attendibilità
non è utile. In questo caso rientrano soprattutto i pacchetti copiati
o di cui non si ha una garanzia scritta o di cui non si conosce il produttore.
Sarebbe buona norma, in quanto nessun software può garantire la
completa bontà dei risultati, effettuare dei controlli finali sulla
elaborazione eseguita oltre ad almeno una verifica manuale di essa. |
| L'interfaccia
utente |
L'interfaccia
utente è l'insieme degli oggetti grafici visualizzati sul video
quando si lancia un software e con i quali si può in genere interagire.
Più immediata è la loro comprensione e maggiori sono le possibilità
di affezionarsi al programma.
Nella
costruzione delle finestre lo sviluppatore deve essere non solo un tecnico
del linguaggio di programmazione, ma anche un fine psicologo: un esempio.
Gli americani visualizzano i numeri partendo dall'alto e scendendo in basso,
il numero uno è in posizione più alta. E questo avviene nelle
proprietà degli oggetti da inserire nelle finestre di un programma.
Se il pacchetto va sul mercato italiano un ingegnere trova difficoltà
a leggere i piani di un edificio in senso inverso: per noi il primo piano
sta più in basso del secondo! Il programmatore deve avere l'accortezza
di invertire i valori delle proprietà di questi oggetti per non
creare inutili disagi.
Gli
stessi colori parlano: al caldo associamo il rosso perchè rosso
è il fuoco, come al freddo associamo il blu o il verde. Nelle finestre
di un programma anche le composizioni grafiche hanno il loro valore psicologico. |
Un
buon software deve essere scritto non solo da un esperto nel problema affrontato,
ma anche da un esperto nel tipo di linguaggio usato. Sarebbe ottimale che
fosse un'unica persona per mantenere comunque sempre la stessa logica compositiva,
per effettuare utilmente gli aggiornamenti e per fornire un'assistenza
continuata e puntuale. Inoltre se lo sviluppatore non conosce la psicologia
dell'utilizzatore non realizzerà mai una elegante ed efficiente
interfaccia utente. In mancanza di questi requisiti il software può
essere distribuito, grazie anche a mirate campagne pubblicitarie, ma sarà
un programma di scarsa qualità e verso il quale non scatterà
la familiarità richiesta per l'operatore. In questi casi sarebbe
meglio rivolgersi a software house non di grandi dimensioni dove il pacchetto
non viene prodotto in modo spersonalizzato, ma rispecchia quasi sempre
l'esperienza, la capacità, la cultura, la logica, la personalità,
la sensibilità di un unico programmatore.
Avere
in licenza un simile software è garanzia di qualità o comunque
di rapporto diretto sviluppatore-utilizzatore. |
| La
guida |
La
guida di un programma e le spiegazioni in genere devono essere concise,
semplici, chiare. E' dimostrato che un operatore abbandona o usa raramente
un software che appare incomprensibile non solo per sè stesso, ma
anche e soprattutto per la sua guida. Del resto quando occorrono molte
parole per parlare di un argomento vuol dire che quell'argomento è
di difficile comprensione e ciò contrasta con gli scopi del software.
Una lunga guida non viene letta e digerita facilmente, una guida complessa
crea quei problemi, in un altro campo, che il software dovrebbe risolvere.
In entrambi i casi si tratta di una pessima costruzione del pacchetto. |
E'
opinione comune che una caratteristica utile di un programma è la
guida in linea, ma è vero esattamente il contrario. Un buon software
dovrebbe non aver bisogno di nessuna guida in quanto già di per
sè stesso dovrebbe essere comprensibile e di immediato utilizzo.
Questo è un limite ideale e pertanto bisogna avere una guida con
caratteristiche precise (vedi a lato). Se è necessaria una guida
della guida vuol dire che abbiamo comprato un programma inutile. Per comprenderne
il funzionamento dovremmo spendere tanto tempo da rendere assurdo il raggiungimento
dei due scopi del software. Dalla guida si capisce se tutto il pacchetto
è costruito secondo logica. |
| Il prezzo |
Il
prezzo di un software comprende non solo i costi di produzione, ma anche
quelli pubblicitari compresi i demo. Dunque si paga talora di più
non per la qualità intrinseca, ma per spese affrontate dal produttore
che non hanno molto a che vedere con il prodotto in senso tecnico. Ma se
ciò vale in senso generale bisogna aggiungere una considerazione
particolare di maggiore importanza: diversi prodotti che risolvono lo stesso
problema possono costare anche molto diversamente fra loro. Vanno valutati
allora non solo i temi affrontati, ma quanto fin qui detto: l'interfaccia
utente, la logica di costruzione, la guida, la gestione dei dati, la qualità
dei risultati ed infine anche l'assistenza. |
Un
prezzo basso non giustifica comunque la convenienza economica all'acquisto.
Sono numerosi i software in commercio che, talora quasi regalati, usano
sistemi antiquati o non sono aggiornati al rispetto delle norme vigenti
o non sono tecnicamente all'avanguardia. Il più delle volte ci si
trova di fronte a pacchetti di qualità scadente in senso generico
verso i quali non nasce una sorta di feeling che lo fa sentire come un
oggetto proprio: un pò come ci si affeziona ad una automobile di
pregio. Che cosa più del software è di aiuto in uno studio
tecnico? Il software va considerato come un compagno di lavoro: instancabile,
economico, preciso e... non ricorre mai al sindacato! |
| L'assistenza |
L'assistenza
è importante perchè ogni programma ha una sua peculiarità
e comunque esso viene costruito per fornire soluzioni testate nel maggior
numero possibile, ma mai completamente. Ogni programma può contenere
anche un piccolo errore (persino i sistemi operativi dei nostri computers
ne contengono) che potrebbe creare un qualche malfunzionamento. In ogni
caso ci si trova di fronte a procedure delicate anche per quanto riguarda
la lettura/scrittura dei dati. Una buona assistenza interviene celermente
e risolve i problemi riscontrati da chi utilizza anche per la prima volta
un software. |
Nel
campo dell'assistenza non bisogna scegliere chi può fornire solo
informazioni generiche o di ulteriore difficile interpretazione. Molti
call center di rinomate società finanziarie non sono in grado di
aiutare i loro clienti in difficoltà il più delle volte perchè
le informazioni degli operatori al telefono sono di seconda mano. Solo
con produttori a livello familiare o quasi si possono avere contatti chiari
e precisi. All'aumentare delle dimensioni dell'azienda fornitrice del software
aumentano anche i problemi dell'assistenza, a maggior ragione quando chi
produce non è lo stesso che distribuisce. |
