L'analista è l'ingegnere che progetta una applicazione software e cura tutto ciò che stà intorno a tale applicazione. Infatti è compito precipuo dell'ingegnere calcolare tutte le eventualità in modo che l'abitazione piuttosto che la nave, la centrale piuttosto che l'elettrodomestico siano in grado di funzionare. Il progetto del software non è un esercizio di logica astratta ma un disegno completo calato nella realtà.
Poiché l'analista prepara i programmi con tutti gli annessi e connessi, egli è l'autore di un sistema informativo che è da fare ex-novo oppure è da aggiornare perché già preesistente.
Questa ultima eventualità è assai comune nel nostro settore ed impegnativa. Qui viene tralasciata, ci riserviamo di riparlarne in un successivo approfondimento. In tutti i casi il sistema informativo ha le caratteristiche illustrate nella risposta 16 cui rimandiamo.L'analista viene interessato dal committente, prepara le specifiche di progetto e le trasmette al tecnico che realizza l'opera e che è il programmatore, il sistemista, l'amministratore dei dati ecc.
Fig 1
L'analista opera in settori di nicchia i quali trattano problematiche particolari, ad esempio il calcolo logico, l'elaborazione linguistica, il controllo dei processi, il controllo di satelliti ecc. Il committente e tutti coloro che utilizzano il software sono mediamente esperti di Informatica, magari hanno sviluppate capacità di analisi. Grazie a questo lavoro di squadra gli impegni dell'analista sono meno gravi di quanto si potrebbe credere.
L'analista opera anche nei settori a carattere generale cioè banche, industrie, ministeri, istituti ecc. Questi ambienti danno il maggior volume di lavoro e costituiscono il settore tecnicamente più impegnativo ed anche più vasto. Il termine 'carattere generale' vuol dire che nelle aziende si effettuano elaborazioni di ogni specie: calcoli contabili ed anche elaborazioni grafiche, visuali, testuali. I tecnici adottano le tecniche generali che sono quelle strutturate, vedi Cobol, Pascal, Basic ecc.; e quelle ad oggetti, vedi Java, C++ (vedi risposta 20 ). I lavori talora non sembrano tecnicamente impegnativi, ma la professionalità dell'analista viene messa a dura prova per due motivi.
I) - Il committente e coloro che dovranno utilizzare il computer non sono di regola preparati. Spesso partono da una esigenza generica. Non hanno le idee per nulla chiare, presentano un panorama frantumato, disordinato, parziale e chiedono una soluzione. Il professionista ha il doppio compito di :
-
Far esprimere al meglio i suoi interlocutori e portare alla luce in modo compiuto le esigenze effettive.
-
Prospettare varie ipotesi di soluzione e discuterne i pro ed i contro.
II) - L'analista non si deve limitare alla parte tecnologica ma a tutto il sistema informativo che comprende massicciamente elementi umani e che richiede accorgimenti organizzativi non banali e che solo una collaudata esperienza professionale riesce a risolvere.
III) - La comprensione dei fattori umani è ancora più importante quando si prepara un prodotto da immettere sul mercato. In questo caso i gusti della clientela determinano il successo soltanto se sono stati interpretati felicemente.
Data la straordinaria importanza di questi problemi professionali continueremo a riferci al secondo settore trascurando i settori specialistici nominati per primi.
Le capacità professionali dell'analista risultano di fondamentale importanza sia di fronte al committente interno all'azienda sia a quello esterno. Infatti un analista può lavorare per un dirigente della sua stessa azienda oppure per quello di un'altra ditta.
I margini decisionali non sempre sono ampi come noi continueremo a considerare per ragioni espositive. Talora ci sono richieste precise e circostanziate e l'analista deve mettere in atto quanto gli viene prefigurato. Ciò non invalida il quadro complessivo ed i punti A) e B) che abbiamo sopra tracciato.
L'ingegnere non è abile nel parlare come l'avvocato o l'umanista, le qualità del suo lavoro emergono di regola dagli schemi di progetto che sono sia strumenti di lavoro sia mezzi di comunicazione. L'analista d'azienda si rivolge al committente ed ai tecnici cioè alla destra ed alla sinistra della Figura 1. Poiché il suo progetto è articolato e poiché ha interlocutori assai diversi, usa parecchi diagrammi i quali mettono in luce lati differenti e diverse sfaccettature. Questa ricchezza di schemi è presente in tutti i settori ingegneristici. Sulla base degli standard più comuni riporto i diagrammi di uso corrente.
Le tre fasce orizzontali riportano i documenti necessari rispettivamente:
allo studio di fattibilità
,alla cosidetta macro-analisi
ed alla successiva micro-analisi.
Gli schemi A danno il profilo generale dell'opera e sono la base per discutere l'investimento. Hanno un valore introduttivo a tutta l'opera.
I documenti A1 sono preparatori alla programmazione strutturata; i documenti A2 alla programmazione ad oggetti.
I documenti B danno i particolari finali per il lavoro specifico dei tecnici.
In
conclusione A riporta gli aspetti generali che sono indipendenti
dalla tecnologia, mentre A1
e B1
riguardano la
programmazione strutturata,
A2
e B2
quella ad oggetti. Nello schema
non ci sono i diagrammi per progettare le basi di dati, i files, gli
archivi. Aggiungiamo per completezza che in giro ci sono molte varianti
grafiche e qualche azienda adotta uno o più schemi propri.
Diamo ora
qualche illustrazione.
* * *
Obbiettivi del Committente e dell'Applicazione - Questo documento è diviso in due parti. Elenca le necessità da cui parte il committente nella parte superiore. In quella inferiore fa la lista delle principali funzioni svolte dal pacchetto software come risposta alle esigenze sopra riportate. Perché vanno compilati ?
Il sistema informativo per sua natura svolge i compiti più diversi: fa statistiche, gestioni, calcoli, controlli ecc. ecc. Inoltre le richieste del committente possono mutare improvvisamente per i motivi più diversi ed impredicibili (vedi risposta 16). Tutto ciò costituisce il primo enorme ostacolo per un chiaro rapporto professionale e questo documento è fondamentale sia in termini realizzativi sia contrattuali. Gli obbiettivi generali dell'opera danno il primo punto fermo per il futuro. Come esempio supponiamo che una azienda voglia facilitare i venditori che si muovono continuamente sul territorio. Vuole mettere a loro disposizione i contratti e le forniture archiviate nelle filiali zonali via Internet. Inoltre permette di registrare un contratto direttamente in formato elettronico mentre finora veniva trasmesso via fax con ritardi ed errori perché poi la filiale lo doveva trascrivere sul Data Base.
Diagramma
di Contesto -
Riporta
l'applicazione con gli enti o attori che lo utilizzeranno.
Questo documento stabilisce l'organizzazione del sistema informativo così
come verrà realizzato. Talora comprende un solo attore, ma più di
frequente ce ne sono diversi ed il disegno richiama con precisione i loro
ruoli e corresponsabilità grazie ai piccoli numeri il cui significato si
capirà meglio col successivo documento. Nell'esempio Consul.exe è il nome
del pacchetto software che sarà fornito; il Venditore e la Filiale sono
gli enti. Accanto ad ogni freccia c'è il tipo di informazione che viene
scambiata con il programma.
Lista
degli Eventi -
Riporta le azioni di
ciascun attore dettagliando così il precedente schema. In pratica i vari
documenti si chiariscono l'uno con l'altro.
I termini
temporali chiariscono il livello di servizio e dunque
gli impegni che vengono onorati con l'opera. Ad esempio il
Venditore non può consultare l'applicazione quando vuole ma soltanto dalle
8 alle 18. Al di fuori di questo periodo il sistema non è disponibile.
Diagramma del Dialogo - Il committente spesso sente il bisogno di percepire l'opera prima che venga realizzata. Nel settore edile, l'architetto crea un modellino di plastica con piantine e pupazzetti. Anche l'analista prepara il prototipo dell'applicazione che dà in anticipo una sensazione del lavoro finito. Per definizione il prototipo mostra l'esterno e tutto ciò che è direttamente percepibile, dunque nel nostro settore si illustra il colloquio uomo/machina. In pratica si scrive un programmino apposito ma poiché questo ha un certo costo, in alternativa l'analista descrive il susseguirsi delle schermate con il diagramma del dialogo. Ogni rettangono riporta un elemento comunicativo (= finestra, pannello, ecc.), le frecce sono i comandi che fanno passare dall'uno all'altro. Illustriamo il colloquio che riguarda l'operatore di filiare quando immette i dati della fornitura. Il programma Consul presenta la schermata di apertura della connessione Telnet (vedi punto b degli obbiettivi). Quindi l'addetto batte il tasto per immettere i dati generali della fornitura. Dopo la data ed il cliente, registra i particolari di ciascun materiale fornito e ripete l'operazione finché è necessario. Chiude quando ha finito.
Questi
primi quattro documenti si completano l'un l'altro. Sulla
carta chiariscono il
profilo del sistema informativo che verrà messo in piedi. Vengono illustrati
al committente e, se li approva, il lavoro sarà realizzato dietro la loro
guida che è chiara e priva di ambiguità.
Anche quando si compra un pacchetto software questi documenti sono necessari. In altri termini si devono fissare gli obbiettivi, il contesto, gli eventi relativi al pacchetto comperato. Le aziende che hanno creduto di semplificare l'analisi sono andate incontro a cocenti fallimenti perché la definizione generale dell'opera è ineludibile. Il programma è un tassello, seppure centrale, dell'intero sistema informativo, dunque non basta acquistarlo per avere automaticamente il tutto.
Man mano che l'analista entra nei dettagli, usa i documenti A1, B1, A2 e B2 che richiedono un discorso tecnico più complesso e che qui non possiamo articolare.
Tuttavia il lettore trova cenni alla pseudocodifica e ad altri schemi nelle risposte 23, 38 e 39. Spiegazioni più organiche si trovano nei libri riportati in testa alla rubrica "Capire l'Informatica".