www.softwareparadiso.it

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.

Torna all'indice di come fare per ulteriori delucidazioni sulla tua ricerca.