Ingegneria del software

Questo sito utilizza cookie, anche di terze parti. Se vuoi saperne di più leggi la nostra Cookie Policy. Scorrendo questa pagina o cliccando qualunque suo elemento acconsenti all’uso dei cookie.I testi seguenti sono di proprietà dei rispettivi autori che ringraziamo per l'opportunità che ci danno di far conoscere gratuitamente a studenti , docenti e agli utenti del web i loro testi per sole finalità illustrative didattiche e scientifiche.

Ingegneria del software

Analisi Funzioni ingegneria del software

A cura di Francesco de Benedetto

Premessa

Questa sezione fornisce informazioni di tipo generale sullo sviluppo di applicazioni che utilizzano il software come elemento fondamentale del processo di automazione. Ci si prefigge lo scopo di:

evidenziare i fattori fondamentali per lo sviluppo del software;
fornire criteri di valutazione tecnico-economica;
elencare le varie tecniche di sviluppo del software;
fornire elementi utili per l'azione di ciascuna di esse in riferimento alle varie esigenze.

La denominazione Ingegneria del software è legata alla necessità, nell’ambito del software, di adottare metodologie e di ottenere risultati con approcci assimilabili a quelli dell'ingegneria, dove l'approccio scientifico applicato ai risultati delle misure sperimentali consente di definire le leggi fondamentali che governano i fenomeni e di attuare pertanto un elevato livello di pianificazione, misura e controllo dell'intero processo di sviluppo.

Per una migliore comprensione di quanto segue è utile definire i seguenti temini:

- Il software è l'insieme completo dei programmi, delle procedure e della relativa documentazione associata ad un sistema, e in particolare ad un calcolatore.

- L'ingegneria è l'applicazione della scienza e della esperienza tramite cui le proprietà della materia e le sorgenti naturali di energia vengono asservite all'uomo in strutture, macchine, sistemi e processi.

- L'ingegneria del software è l'applicazione della scienza e della esperienza tramite cui le capacità dei calcolatori vengono asservite all'uomo per mezzo di programmi, di procedure e della relativa documentazione.

Le tecnologie di sviluppo del software

La quasi totalità dei software esistente al mondo (il cui valore è stimato pari a centinaia di miliardi di dollari) è stato sviluppato per servire fini istituzionali di aziende, società, enti, con tecniche di automazione che si prefiggevano due obbiettivi fondamentali:

l'incremento della qualità e dell'efficacia del lavoro svolto;
la riduzione dei costi.

Gli obbiettivi in questione sono stati raggiunti, anche se spesso molto parzialmente e in modo inefficace, con la messa in opera di progetti software.

Tali progetti, a differenza di altri riferiti a campi di applicazione svariati dell'ingegneria (edile, idraulica, urbanistica, ecc.) hanno mostrato le seguenti caratterizzazioni tipiche:

Le previsioni di costo sono risultate sovente clamorosamente errate
Le previsioni di tempo sono anch'esse risultate errate.
La qualità dei prodotti è spesso risultata scadente.
Le spese di mantenimento dei prodotti completati sono risultate oltremodo superiori al previsto.
L'aggiunta di ulteriori risorse a progetti in ritardo ha peggiorato la situazione.
In generale si sono riscontrati, nei responsabili dei progetti software, un ingiustificato ottimismo nonché una preparazione inadeguata nei confronti delle tre componenti che l'esperienza ha giudicato indispensabili ad una buona conduzione:
approccio ingegneristico
approccio economico
approccio umano nella gestione del personale coinvolto.

Inoltre, una volta completati, i progetti software si sono rivelati un elemento rigido del processo organizzativo automatizzato che è stato costruito - tramite essi - all'interno delle aziende. I mutamenti delle tecnologie di sviluppo dell'automazione considerano infatti il software come un “invariante”: il patrimonio dei programmi software non viene modificato a seguito di implementazioni dei calcolatori, in quanto le modifiche sarebbero troppo costose.

Ciò fa sì che, mentre l'hardware e il software di base dei calcolatori evolvono rapidamente su base sostitutiva (un calcolatore - o un sistema operativo - più moderno sostituisce un calcolatore - o un sistema operativo - obsoleto), il software applicativo predisposto dai programmatori delle aziende presenta notevoli vischiosità nei confronti del cambiamento: si scarta, infatti, l'evoluzione di tipo sostitutivo (che implicherebbe la riprogettazione con un software più moderno delle applicazioni già esistenti) e si opera in genere su base aggiuntiva (cioè si mantengono i vecchi progetti di automazione nelle tecnologie software in cui sono stati a suo tempo sviluppati e si adottano tecniche di sviluppo più avanzate per i nuovi progetti di automazione).
Ciò comporta alti costi per il mantenimento di applicazioni con tecnologie di sviluppo software diverse, e costringe i responsabili dei Sistemi informativi aziendali a dedicare a tale mantenimento ingenti risorse umane.

Esperienze molteplici sulle problematiche di mantenimento di progetti software già completati hanno condotto alla formulazione delle seguenti leggi empiriche:

Legge del continuo cambiamento:un prodotto software consegnato all'esercizio è soggetto ad evoluzione continua fino a che non si giudica che è preferibile dal punto di vista costi/ricavi congelarlo e riproggettarlo ex-novo;

Legge dell'entropia crescente:un prodotto software ha una non strutturazione intrinseca (entropia) che aumenta nel tempo per effetto della degenerazione strutturale che consegue dalla legge del continuo cambiamento; l'incremento entropico può essere annullato solo se viene svolto un lavoro di senso contrario che tende a ristrutturare il prodotto software. In pratica, si ha un decadimento progressivo del software prodotto che tende a rendere il software stesso sempre meno gestibile e controllabile.

Va inoltre tenuto conto che:

la produttività del personale addetto all'analisi e programmazione è valutabile con difficoltà: i livelli di efficacia variano di molto, specialmente in ambienti di lavoro in cui il livello organizzativo è modesto;

la qualità delle singole parti che compongono il software prodotto è spesso insoddisfacente: si evidenziano errori di mancata aderenza alle specifiche, di impostazione, di progettazione e di codifica, la cui gravità è tanto maggiore quanto più in là nel tempo gli errori stessi sono stati effettuati.

L'incapacità dei Sistemi informativi di far fronte alla domanda di automazione che proviene dall'interno delle aziende provoca un intervallo (gap) tra la domanda e l'offerta di sistemi software, che comporta un arretrato (backlog) oltretutto crescente nel tempo.

Taluni osservatori stimano il backlog pari a 2-4 anni: in media i Sistemi informativi dovrebbero cioè lavorare a pieno ritmo 2-4 anni (senza intraprendere la meccanizzazione d'ulteriori comparti dell'azienda) semplicemente per smaltire l'arretrato della domanda di automazione.
Va detto, infine, che il software prodotto per l'automazione di una funzione aziendale, anche se di buona qualità tecnica, talora non raggiunge gli obbiettivi prefissati. Le rilevazioni statistiche affermano che i sistemi software sviluppati:

solo nel 16% dei casi raggiungono gli obiettivi aziendali;
nel 28% dei casi hanno un utilizzo limitato, inferiore al 60% della loro effettiva possibilità;
nel 23% dei casi non vengono utilizzati a causa di resistenze interne aziendali;
nel 23% dei casi non provocano alcun aumento di efficacia né di efficienza;
nel 10% dei casi danno risultati di dubbia validità.

Nonostante le difficoltà esposte, l'osservazione dei fenomeni connessi con lo sviluppo del software ha condotto alla formulazione della seguente legge empirica:

Legge delle tendenze di fondo:i singoli eventi relativi allo sviluppo del software, anche se possono apparire completamente casuali sia sotto il profilo spaziale che temporale, sono sempre inquadrabili in regolarità statistiche che consentono di definire leggi di validità generale.

In altre parole, lo sviluppo del software - anche se caratterizzato da difficoltà notevoli per quanto concerne la pianificazione e il controllo - è gestibile con criteri scientifici che, a somiglianza delle applicazioni di ingegneria, si fondano su scienza ed esperienza.

Un primo fondamentale concetto che è necessario evidenziare in riferimento allo sviluppo del software è quello relativo al fatto che, a somiglianza di tutte le altre problematiche di progettazione. anche in questo caso si tratta di risolvere un problema caratterizzato da tre vincoli:

la prestazione
il tempo
il costo

L'aspetto più caratteristico di tale fenomeno consiste nel fatto che i vincoli possono variare di molto in corso d'opera alterando la fisionomia del progetto.

Infatti:

per quanto concerne la prestazione, essa può subire variazioni a causa della scarsa comprensione delle specifiche che si può avere tra gli utenti e i progettisti dei software: è possibile infatti, a causa delle differenti culture professionali, che si abbiano differenti percezioni delle specifiche funzionari o delle parole che le rappresentano. Inoltre l'approccio, sia da parte degli utenti che da parte dei progettisti, può essere ottimistico, in quanto non è raro che gli obbiettivi siano troppo ambiziosi e incoerenti con la capacità aziendale di produrre servizi di automazione. Infine, essendo la produzione del software un processo di notevole complessità, la frequenza di errori di progettazione è notevole e ciò può anche pesantemente influenzare la prestazione prevista; tali errori di progettazione possono essere intrinseci (cioè interni al processo di sviluppo del software) o anche causati da fattori esterni (variazione dell'ambiente hardware, del software di sviluppo, delle risorse umane che possono abbandonare il progetto per motivi vari, ecc.);
per quanto concerne i tempi di sviluppo, essi variano per ragioni molteplici fra cui una delle principali è quella della soverchia attenzione prestata agli aspetti tecnologici a scapito di una visione ragionevole e bilanciata di tutti gli aspetti del progetto. Tale approccio eccessivamente tecnologico, che si ritrova frequentemente nella pratica di lavoro, è sostenuto in massima parte dai fornitori di prodotti per motivi sostanzialmente estranei agli interessi delle aziende che sviluppano i progetti software; esso tuttavia trova alleati potenti nei responsabili aziendali dei Sistemi informativi (per motivi di prestigio) e nei progettisti (per un malinteso senso di professionalità che tende a privilegiare le tecnologie innovativi che scontano spesso peraltro tempi e costi maggiori in quanto necessitano di assestamenti e consolidamenti).

Un secondo elemento che fa slittare sovente le pianificazioni consiste nel fatto che le risorse (persone, calcolatori, ecc.) non sono disponibili nel momento in cui ciò è necessario. In tal caso si ricorre a soluzioni di surrogazione che, specie per quanto attiene al personale qualificato, possono comportare non solo allungamenti dei tempi, ma addirittura il fallimento di obbiettivi parziali. Ancora, sempre in riferimento al personale, possono emergere problemi relativi al fatto che i progettisti possono essere scarsamente interessati al progetto cui sono stati assegnati; ciò si traduce immediatamente in un allungamento dei tempi in quanto la motivazione è fattore essenziale di produttività. I progettisti possono infine cambiare nel corso del progetto: possono essere assegnati ad altro incarico, licenziarsi, ecc.; ciò è tanto più grave, in riferimento ai tempi di sviluppo del progetto, quanto più la conoscenza esclusiva del progetto medesimo si è accumulata sulle singole persone. Un ultimo elemento che fa slittare i tempi di completamente del progetto è la variazione delle specifiche funzionali; ciò non è infrequente ed è spesso dettato da motivazioni obbiettive (modifiche legislative, normative, regolamentari, variazioni delle condizioni di mercato, ecc.);

per quanto concerne i costi, essi sono in prima istanza direttamente correlati con i tempi di sviluppo: uno slittamento dei tempi comporta di necessità uno slittamento dei costi. Inoltre, per far approvare il progetto dalla direzione della azienda, è prassi sottostimare i costi («get the order and then will see» afferma pragmaticamente un proverbio statunitense).

Ancora, i costi possono esser sottostimati senza malizia in quanto si è all'inizio del ciclo di vita del progetto e, in tale fase, l'ordine di grandezza dell'errore di stima può essere molto ampio.

Ancora, ulteriori elementi possono far variare i costi quali le variazioni delle valute, del costo del lavoro, ecc.; tali elementi tuttavia rappresentano errori del secondo ordine rispetto a quelli che attengono alla valutazione dei contenuti del prodotto software da creare tramite l'esecuzione del progetto software: il massimo grado di incertezza infatti si ritrova nella valutazione della sostanza del prodotto e delle condizioni al contorno che vincolano l'esecuzione del progetto.

In riferimento a tale incertezza di valutazione e del rischio aziendale che ne consegue, i metodi dell'ingegneria, della economia, dell'organizzazione e della psicologia, che affrontano con criteri scientifici la materia, si prospettano come un valido supporto di scienza ed esperienza alla trattazione della misura, valutazione e controllo dei progetti di sviluppo del software.

Lo sviluppo di software con tecniche procedurali

Lo sviluppo di software avviene solitamente nelle aziende con tecniche procedurali, cioè con tecniche che utilizzano linguaggi di programmazione e di controllo costituiti da insiemi di istruzioni che i calcolatori devono eseguire secondo una sequenza precisa: tale sequenza può variare in dipendenza di condizioni che devono essere controllate; inoltre gruppi di istruzioni possono essere eseguiti ripetutamente.
Tale modo di operare ha caratterizzato e caratterizza tuttora gran parte degli ambienti di sviluppo software che si ritrovano nelle aziende. Esistono tuttavia tecniche più avanzata e che si ritrovano sia nell'ambiente dei microcalcolatori che in ambienti di produzione industriale del software dove la necessità di fornire un prodotto all'interno di un mercato concorrenziale obbliga i produttori ad adottare metodi rigorosi. Tali tecniche più avanzate si avvolgono dei seguenti linguaggi di programmazione:

Linguaggi procedurali strutturati che permettono i costruiti della progettazione strutturata ed evitano i trasferimenti di controllo all'interno dei programmi;
Linguaggi non procedurali che descrivono quali risultati debbano essere conseguiti ma non specificano la sequenza dei passi procedurali tramite cui detti risultati vanno raggiunti; tali linguaggi sono caratterizzati da sintassi estremamente variabili;
Linguaggi dichiarativi che descrivono una serie di fatti e consentono la formulazione di domande e la risoluzione di problemi che utilizzano i fatti; poiché non, specificano in modo completo la sequenza dei passi, i linguaggi dichiarativi costituiscono una sorta di linguaggi non procedurali;
Linguaggi basati su regole che descrivono una serie di fatti e di regole per la formulazione di domande e la risoluzione dei problemi; il comportamento di un programma scritto con tali linguaggi può essere variato cambiando le regole e i fatti;
Linguaggi orientati agli oggetti i quali consistono in dati e procedure per manipolare i dati e sono caratterizzati dalla circostanza che i messaggi inviati agli oggetti scatenano l'esecuzione delle procedure;
Linguaggi funzionari che sono costituiti da richiami di funzioni più che da istruzioni vere e proprie;
Linguaggi interattivi in cui un programma è il risultato di un dialogo interattivo tra l'utilizzatore e il software;
Linguaggi grafici in cui i programmi vengono costruiti interattivamente con tecniche grafiche che si basano su disegni preconfezionati (primitive).

Indagini recenti hanno rilevato che l'85% del software esistente presso le aziende è stato prodotto con tecniche procedurali, e precisamente:

- il 50% con metodologie tradizionali;
- il 35% con tecniche di tipo strutturato.

Tecniche procedurali di sviluppo del software

Le tecniche tradizionali e si avvolgono di:

diagrammi di flusso per descrivere graficamente il trasferimento dei dati dalle unità di input al calcolatore e da questo alle unità di output, nonché la sequenza temporale delle operazioni di un programma, indicando in particolare la scelta tra più alternative,
definizione grafica dei formati delle registrazioni (record) che compongono una unità logica di dati sottoposti ad elaborazione,
strutturazione dei programmi in un corpo centrale (main program) che funge da programma di controllo, e varie sezioni che svolgono funzioni elaborative (subroutine) e sono richiamate dal main program,
passaggio di dati tra il main program e le varie sezioni del programma.

Lo sviluppo dei programmi avviene, di norma, secondo il seguente iter:

Analisi delle esigenze dell'utente
Studio di fattibilità
Analisi funzionale (o amministrativa)
Analisi organica (o tecnica)
Programmazione
Messa a punto
Collaudo
Produzione della documentazione
Consegna all'esercizio

Il processo è essenzialmente seriale, essendo le possibilità di parallelizzazione delle attività possibili solo dopo le fasi di impostazione generale. Ciò comporta tempi lunghi di realizzazione per cui il prodotto finito è talora obsoleto rispetto alle esigenze dell'utente che, nel frattempo, hanno continuato ad evolvere.

L'esperienza ha dimostrato che le tecniche in esame comportano numerosi aspetti negativi, tra cui:

la disomogeneità nella qualità dei prodotti per la notevole libertà di progettazione lasciata ai programmatori;
la miscelazione nell'interno dello stesso programma di più funzioni, quali la definizione dei dati, la loro elaborazione, la gestione delle operazioni di input/output, la funzione di elaborazione applicativa ecc.;
la carenza di documentazione, prodotta posteriormente alla consegna dei software all'esercizio, o non prodotta affatto;
la carenza di momenti di controllo;
la carenza di impostazioni parametriche che conferirebbero al software la necessaria flessibilità nei confronti dell'evoluzione tecnico-applicativa.

Tutti questi elementi, oltre a comportare notevoli difficoltà gestionali in fase di regime, provocano errori in fase di sviluppo: il prodotto che si ottiene è pertanto di qualità modesta, e contiene guasti di progettazione e di codifica che vengono rilevati solo durante le fasi di messa a punto, collaudo ed esercizio.

È stato anche provato che la frequenza degli errori presenti in un programma aumenta all'aumentare del numero delle linee di codice e delle interrelazioni tra le parti in cui il programma stesso è stato suddiviso.

La tipologia degli errori si mantiene - statisticamente - sui seguenti valori:

il 45% di errori di impostazione;
il 25% di errori derivati da errori o imprecisioni precedenti;
il 20% di errori di codifica nel linguaggio di programmazione;
il 10% di errori di altro tipo.

provato inoltre che la frequenza degli errori aumenta all'aumentare delle dimensioni del programma e del numero delle interrelazioni tra le varie parti del programma stesso.

Infine, il costo di rimozione degli errori è tanto più alto quanto più tardi nel ciclo di sviluppo del software l'errore viene scoperto. Dall'esperienza si è tratto che, fatto convenzionalmente uguale ad 1 il costo di rimozione di un errore scoperto in fase di progettazione, i costi relativi di rimozione del medesimo errore scoperto nelle fasi successive assommano a:

4     se l'errore è scoperto in fase di prova del singolo programma;
9     se l'errore è scoperto in fase di prova del sottosistema di cui fa parte il singolo programma;
15     se l'errore è scoperto in fase di prova del sistema di cui fa parte il sottosistema;
30     se l'errore è scoperto in fase di esercizio.

Nonostante la indicata progressione dei costi di rimozione degli errori nel corso dell'evoluzione temporale del progetto di sviluppo del software, le tecniche di prevenzione e di rimozione degli errori sono in genere molto elementari: le prime si basano sull'affidamento dei programmi più complessi al personale di maggiore esperienza e capacità; le seconde consistono in una verifica sperimentale del comportamento del programma in fase di collaudo con riferimento alla casistica di eventi che si ritiene più probabile.

Le dimensioni dei programmi influenzano inoltre drasticamente la produttività: più i progetti software (e quindi i programmi relativi) sono ampi, e minore è la produttività del personale; ciò deve ascriversi alla difficoltà di gestione delle interrelazioni fra più persone che cresce con il numero di esse in maniera più che proporzionale.

1 metodi artigianali di produzione del software ora descritti sono oltremodo frequenti: il 50% del software esistente risulta confezionato in tal modo con linguaggi procedurali (COBOL, Assembler, Basic, FORTRAN, C, ecc.); tali linguaggi consentono ai programmatori notevoli libertà nella progettazione e ciò si traduce nell'ottenimento di prodotti software diversificati per quanto riguarda la qualità.

La caratteristica positiva delle tecniche tradizionali risiede in una buona motivazione del personale: il relativo valore aziendale è notevole e può talora far premio su altri aspetti di natura tecnologica.

Tecniche avanzate di sviluppo del software

Le società che producono software come bene industriale e le aziende particolarmente avanzate nella produzione di sistemi informativi, utilizzano tecniche di produzione del software che, pur rimanendo procedurali sono da considerare avanzate, in quanto basate su una pianificazione accurata del processo di sviluppo e su misure e controlli di qualità molto rigorosi.

Ciclo di vita del software

Tutte le tecniche adottate - comunemente denominate ingegneria del software - mirano alla riduzione delle complessità e dei costi di produzione del software, nonché alla facilità di utilizzo nella fase di esercizio del software prodotto. Una caratteristica tipica di queste tecniche è quella di riferirsi al ciclo di vita dei software, cioè alla scomposizione del processo di produzione del software in una sequenza ordinata di fasi temporali, precisamente definite. Tali fasi che compongono il cosiddetto modello a cascata (waterfall model) del ciclo di vita del software hanno due caratteristiche fondamentali:

ciascuna fase ha una parte finale che attua un processo di verifica e di controllo di validità per eliminare il massimo numero di errori relativi a quella fase;

per quanto possibile, la messa a punto di ciascuna fase interessa solo la fase successiva.

Le varie fasi e i processi di verifica e controllo di validità sono definibili nel modo seguente.

Per quanto riguarda le fasi:

Studio di fattibilità: la definizione della architettura di un prodotto software che viene stimato migliore degli altri per la fattibilità dei ciclo di vita e per la superiorità funzionale.
Specifiche: la definizione completa e convalidata delle funzioni richieste, delle interfacce e delle prestazioni del prodotto software.
Progettazione del prodotto: la specifica completa e convalidata dell'architettura hardware e software, delle strutture di controllo e della struttura dei dati di tipo generale, unicamente agli altri componenti fondamentali quali i documenti di pianificazione e le bozze dei manuali per gli utenti.
Progettazione di dettaglio: la specifica completa e convalidata della struttura di controllo, della struttura dei dati, delle interfacce, delle ampiezze in gioco, degli algoritmi fondamentali e delle caratteristiche di base di ciascun programma.
Codifica: l'insieme completo e verificato di tutti i programmi componenti il prodotto.
Integrazione: il prodotto software funzionante, completo di tutti i programmi componenti.
Inserimento nell'ambiente: il prodotto software disponibile per essere operativo, inserito nell'ambiente hardware e software generale, completo di tutte le parti di conversione dati, installazioni di software di base e di apparecchiatura, addestramento utenti ed operatori.
Consegna all'esercizio e mantenimento: il prodotto software completamente operativo, ottimizzato e flessibile nei confronti dell'evoluzione tecnica ed applicativa.

Per quanto riguarda i processi:

Verifica: il controllo della corrispondenza tra le specifiche e il prodotto software; in pratica risponde alla seguente domanda: si sta costruendo esattamente il prodotto software?
Controllo di validità: il controllo della corrispondenza tra il prodotto software e il suo scopo funzionale; in pratica risponde alla domanda: si sta costruendo il prodotto software esatto?

Oltre a quello indicato esistono ulteriori modelli di cicli di vita del software, a livelli di dettaglio variabili, in ognuno dei quali tuttavia ogni fase svolge un ruolo autonomo, non sovrapponibile con gli altri, e controllabile.

Una caratterizzazione tipica del ciclo di vita viene fornita dalla curva che indica il personale necessario nelle varie fasi di sviluppo del software; tale curva, chiamata curva del ciclo di vita o di Raleigh, è diversa a seconda delle tecniche e dei linguaggi di programmazione usati e fornisce una immediata percezione visiva del costo in risorse dei progetto software nel suo momento più critico in cui deve essere effettuato il massimo s forzo - e- del tempo globale di sviluppo.

Qualità del software

Il processo che struttura la produzione del software con un modello standard quale il ciclo di vita è rigidamente sequenziale, e pertanto piuttosto pesante nella fase di impianto organizzativo i vantaggi si ritrovano a posteriori, in quanto vengono minimizzati gli errori che intervengono nelle prime fasi del processo medesimo e che sono responsabili della maggior parte dei difetti di un prodotto software.
L'ingegneria del software interviene nel processo di analisi e di programmazione, nel modo descritto nei paragrafi successivi. Ai fini della prevenzione degli errori, sono inoltre applicate particolari metodologie di verifica, compiute tramite ispezioni del software (inspection) o creazioni di percorsi logici che. ne provano la correttezza funzionate (walkthrough); per essere efficaci le verifiche vanno effettuate da personale diverso, da quello che ha sviluppato il software, e devono prescindere da ogni valutazione di quest'ultimo personale, per ottenere la necessaria collaborazione.
Le tecniche di prevenzione degli errori migliorano sensibilmente, la qualità del prodotto software. Si. passa, infatti, da 10-50 difetti per migliaio di istruzioni a 0,2-0,4: gli errori. vengono cioè diminuiti di, 25-250 volte.

Ispezioni (inspection)

Le ispezioni costituiscono un mezzo semplice ed economico per rilevare gli errori di progettazione e di codifica. Vengono effettuate da un gruppo di lavoro composto da tre persone:

il moderatore: è il conduttore del gruppo, e di norma non ha partecipato al progetto da ispezionare;

il codificatore: è il programmatore responsabile della codifica;
il collaudatore: è il programmatore responsabile dei programmi di prova che verificano la validità dei prodotto.

Il gruppo esegue un processo così articolato:

Analisi generale (tutto il gruppo): il progettista descrive al gruppo la materia da ispezionare, e il moderatore definisce le aree critiche da sottoporre a verifica (le zone in cui si sono scoperti più errori ne contengono probabilmente altri).

Preparazione (individuale): ciascun componente del gruppo cerca di comprendere la progettazione, il suo scopo e la sua logica, concentrandosi sulle aree che si considerano più probabilmente soggette ad errori.

Ispezione (tutto il gruppo): il codificatone descrive il modo con cui ha codificato la progettazione; obbiettivo di questa fase è trovare gli errori.

Ricostruzione: tutti gli errori e i problemi rilevati dalla fase di ispezione vengono risolti dal progettista o dal codificatore.

Valutazione finale: viene fornito un giudizio globale sulla qualità dei software sotto esame; se è stato ricostruito più del 5%, il moderatore deciderà se sottoporre il software ad una ispezione totale ancora più. approfondita, ovvero se è il caso di riprogettarlo ex-novo.

Walk-through

I controlli denominati walk-through sono effettuati con criteri non formali e variabili da caso a caso. In genere si attuano tramite una fase di preparazione, una fase di analisi dei percorsi logici nell'ambito dei programmi, una fase di valutazione delle alternative di progettazione e una fase di correzione errori o di ricostruzione. Non si avvale di un moderatore, né di ruoli definiti espletati dai, partecipanti al gruppo, di verifica; non utilizza metodologie particolari per la ricerca di errori, e non è finalizzato alla creazione di figure professionali atte alla valutazione della qualità del software.

Tecniche avanzate di analisi

Le tecniche avanzate di analisi riguardano la prima fase del ciclo di vita del software e sono sostanzialmente orientate a fornire le specifiche dei sistemi che si desidera costruire.
Il prodotto dell'analisi è dato dalle specifiche, cioè dalla chiara definizione delle richieste degli. utenti e dei relativi vincoli espliciti o impliciti. Le specifiche devono essere complete, coerenti, comprensibili, riconducibili alle richieste, non ambigue, modificabili ed esplicabili tramite una documentazione scritta.

Sono stati predisposti numerosi metodi di definizione delle specifiche; di seguito sono riportati i più noti.

Analisi strutturata dei sistemi (SSA)

L'analisi strutturata dei sistemi (Structured System Analysis SSA) è basata su quattro strumenti fondamentali:

I diagrammi di flusso dei dati (indicano le trasformazioni dei dati tra i vari processi, possono essere espansi in vari livelli di dettaglio).
Il dizionario dei dati (registra le caratteristiche e le interrelazioni dei dati tra loro)
L’analisi per l'accesso immediato (definisce la struttura dei dati in un data base, e le operazioni che possono essere effettuate su di essi).
Il linguaggio di progettazione dei programmi e le tabelle decisionali (usate per definire i procedimenti logici che avvengono in ciascun processo).

La tecnica SSA è soddisfacente per quanto riguarda la definizione e progettazione dei dati, ma, diventa estremamente complessa per quanto riguarda la definizione dei processi, a causa del loro numero e delle complicate interrelazioni intercorrenti; tra i processi stessi.

Tecnica strutturata di analisi e progettazione (SADT)

La tecnica strutturata di analisi e progettazione (Structured Analysis and Design Technique SADT) è uno strumento generale di modellistica, usato anche al di fuori dei problemi di Elaborazione Automatica dei Dati.

Un diagramma SADT può definire processi o dati. Nei diagrammi che definiscono processi, i dati e i vincoli sono indicati da frecce; esse, nei confronti dei processi, hanno il seguente significato convenzionale:

ï freccia da sinistra:       input
ò freccia dall'alto:            vincolo
ð freccia verso destra:    output
ñ freccia da sotto:            meccanismo che fa scattare l'esecuzione del processo

Ciascun processo può essere esploso in ulteriori processi secondo una struttura gerarchica, fino a che il modello non è completamente definito; analogamente accade per i dati, che possono essere scomposti in livelli successivi.

Il SADT ha fornito risultati soddisfacenti, in quanto è una vera e propria metodologia per l'analisi e la definizione delle specifiche, e pertanto costituisce un elemento notevole di formazione professionale; peraltro la sua eccessiva generalità fa sì che il passaggio dalla definizione delle specifiche alla scrittura del software sia piuttosto oneroso. Inoltre richiede un notevole sforzo di apprendimento per quanto riguarda l'approccio ai problemi e la comprensione dei simbolismi.

Linguaggio di impostazione dei problemi (PSL)

Il linguaggio di impostazione dei problemi (Program Statement Language PSL) è un linguaggi o formale per la definizione dei problemi, usato in concomitanza con un analizzatore (Problem Statement Analyzer-PSA); PSL e PSA forniscono tabulati che rilevano le incoerenze, indicano il flusso dei dati ed evidenziano le necessarie informazioni di gestione e controllo.
Il PSL definisce più di 20 tipi di oggetti, e più di 50 tipi di relazioni tra di essi; è molto utile come strumento di documentazione per il progettista, poiché indica le azioni che devono essere intraprese nell'ambito delle procedure e la scomposizione gerarchica del sistema.
Ha tuttavia una sintassi molto complessa, di non semplice utilizzo.

Ingresso - Elaborazione - Uscita gerarchica (HIPO)

La tecnica di ingresso – elaborazione - uscita gerarchica (Hierarchical-Input-Processing-Output HIPO) fu sviluppata inizialmente dalla società IBM come supporto di documentazione.
L'HIPO è costituito da una serie di diagrammi organizzati gerarchicamente, in cui ciascun modulo elaborativo ha un input e un output esplicito; un modulo può contenere o una descrizione dei passi che devono essere effettuati, o una sequenza procedurale che indica il processo logico.
L'HIPO enfatizza la struttura funzionale del problema e delle soluzioni, e conferisce maggiore importanza ai dati che non ai flussi di controllo. È diffuso, in quanto è facile da apprendere e da utilizzare; è usato tuttavia più come metodo informale di documentazione che come tecnica di definizione delle specifiche di progettazione.

Casuale:..................... un modulo in cui non ci sono relazioni significative tra le sue parti

Logica:....................... un modulo che esegue una serie di funzioni collegate

Temporale................. un modulo che esegue una serie di funzioni collegate anche nel tempo

Comunicativa:.......... un modulo che e segue una serie di funzioni collegate logicamente e atte all'utilizzo dei dati

Funzionale:............... un modulo che esegue una singola e ben definita funzione

Livello crescente di coesione Livello crescente di qualità

Progettazione strutturata secondo Myers

La progettazione strutturata suddivide il problema da automatizzare in sottoproblemi e conseguentemente il relativo programma in sottoprogrammi elementari o moduli.

Secondo Myers, le caratteristiche fondamentali di un modulo sono:

la sua coesione (che è una qualità interna, del modulo e costituisce un indice di interdipendenza delle sue singole parti);
il suo accoppiamento (che è una qualità estrema del modulo e costituisce un indice alla sua dipendenza dagli altri).

Myers distingue cinque livelli di coesione, dal livello più basso (tipico di un modulo in cui non ci sono relazioni significative tra le singole parti) al livello più alto (tipico di un modulo che esegue una singola e ben definita funzione). Ovviamente la qualità interna del modulo è tanto maggiore quanto maggiore è il suo livello di coesione. La qualità esterna del modulo è invece. tanto maggiore. quanto, minore è la sua dipendenza dagli altri. Myers distingue a tale proposito 5 livelli di accoppiamento che vanno da una situazione pessima (in cui un modulo fa direttamente riferimento al contenuto dell'altro) ad una situazione ottimale (in cui i moduli comunicano tra di loro scambiandosi solo i dati necessari a svolgere la funzione prevista).

Il metodo di Myers ha il vantaggio di fornire una guida razionale alla progettazione di programmi e alla valutazione della qualità dei moduli; peraltro, il formalismo adottato non consente di individuare l'ordine di esecuzione dei moduli ne il loro punto di richiamo.

Contenuto:................ un modulo che fa direttamente riferimento al contenuto di un altro

Comune:.................... un modulo che fa riferimento a dati in una area comune

Esterno:..................... un modulo che fa riferimento a dati dichiarati esterni

Controllo:................. un modulo che controlla esplicitamente la funzione di un altro

Dati:........................... un modulo che si collega con altri attraverso il solo scambio di dati

Livello decrescente di accoppiamento Livello crescente di qualità

Progettazione strutturata secondo Jackson

La progettazione strutturata secondo Jackson si basa su tre osservazioni fondamentali:

La struttura del programma deve essere strettamente aderente alla struttura del problema.
Per la maggior parte dei sistemi, il problema si può sostanzialmente ridurre alla creazione della struttura di collegamento tra struttura di input e struttura di output.
Un metodo di progettazione, per avere successo, deve poter essere appreso ed utilizzato facilmente da un numero elevato di progettisti di medio livello.

In pratica il metodo di Jackson è orientato a costruire una struttura di programma in base alle strutture di input e di output e a collegare le due strutture nei punti appropriati. Esso si rivela tuttavia semplice solo nella trattazione di problemi semplici, è molto dipendente dalle modifiche nella struttura di input e di output, e fornisce scarso aiuto nella analisi e definizione delle specifiche.

Tecniche avanzate di programmazione

Le tecniche avanzate di programmazione si basano sulle idee teorizzate da Dijkstra intorno agli anni '60, formulate successivamente da Bohm e Jacopini, raccolte da Mills nel 1972, e qui brevemente riassunte:

Teorema della struttura: ogni programma è riconducibile a tre sole operazioni logiche (sequenza, scelta e interazione) ed è rappresentabile con una combinazione dei relativi diagrammi di flusso.

Corollario «top-down»: i programmi strutturati possono essere scritti o letti in modo tale che la correttezza logica di un segmento di programma dipende solo dai segmenti già scritti o letti precedentemente, e dalle specifiche funzionari degli ulteriori segmenti a cui si fa riferimento.

Teorema della correttezza: la verifica della correttezza logica di un programma strutturato può essere attuata tramite una serie di controlli di tipo matematico sulle funzioni che lo compongono.

Teorema dell'espansione: una struttura funzionale è sempre definita dalle strutture funzionari di ordine superiore; ciò permette di scomporre un qualsiasi problema in specifiche funzionari a livello di dettaglio crescente.

Programmazione strutturata secondo Warnier

Warnier fonda il proprio metodo sulla teoria degli insiemi, sull'algebra booleana e sulle tavole decisionali ed articola la strutturazione di un programma in tre fasi:

studio della struttura dei dati di output e di input, con individuazione dell'organizzazione dei programma tramite scomposizione del problema in insiemi elementari di trattamento;
individuazione e costruzione dell'insieme ordinato dei comandi operativi da assegnare a ciascuna sequenza logica e quindi all'intero programma;
codifica.

Nella prima fase, con un procedimento rigorosamente dall'alto verso il basso (top-down), si ottengono:

le tavole di scomposizione del flusso logico di uscita (FLU) (a cui viene data molta importanza perché rappresentano l'obbiettivo del programma);
le tavole di scomposizione del flusso logico di entrata (FLE);
le tavole di scomposizione del programma (PROG);
i diagrammi delle sequenze (FLOW).

Nella seconda fase si ottengono:

le tavole delle condizioni;
le tavole degli ordini operativi di calcolo e di output;
le tavole degli ordini operativi del programma.

Gli ordini poi vengono scomposti nelle seguenti categorie:

preparazione dei calcoli e calcoli effettivi;
preparazione dell'output e output effettivo;
input effettivo;
preparazione delle condizioni e dei dati di controllo.

Nella terza fase i programmatori, tramite un qualsiasi linguaggio di programmazione, traducono l'elenco ordinato dei comandi operativi in istruzioni simboliche.

Viene conservata la seguente documentazione:

PROG, FLOW, tavole degli ordini operativi, liste di compilazione, enunciato del problema (costituito dalla descrizione fisica degli archivi e dei record da elaborare e delle operazioni da svolgere su di essi).

Wamier usa, per la stesura di PROG e FLOW, strumenti grafici molto evidenti che rappresentano le seguenti funzioni:

funzioni di base
sequenza elementare (insieme elementare minimo ordinato, di comandi operativi eseguiti consecutivamente, lo stesso numero di volte, al verificarsi delle stesse condizioni);
divaricazione d'azione;
congiunzione d'azione;

funzioni composte
struttura ripetitiva (composta dagli elementi TESTA, CORPO, CODA dove gli elementi TESTA e CODA vengono eseguiti incondizionatamente una volta sola, rispettivamente all'inizio e alla fine della struttura, e l'elemento CORPO viene eseguito un numero variabile di volte, a seconda del valore di una condizione A il cui valore logico può variare nell'ambito del CORPO);

struttura alternativa (composta dagli elementi TESTA, CORPO-1, CORPO-2, CODA, dove gli elementi TESTA e CODA vengono eseguiti incondizionatamente una volta sola, rispettivamente all'inizio e alla fine della struttura, mentre gli elementi CORPO-1 e CORPO-2 vengono eseguiti una sola volta, o mai, in maniera mutuamente esclusiva).

L'opera di Warnier è fondamentalmente orientata a produrre programmi corretti sotto il profilo logico, e a proporre al personale di programmazione regole precise di comportamento; l'approccio è incondizionatamente topdown, ed è preceduto dall'analisi delle strutture dei dati. La qualità del software che si ottiene è soddisfacente dal punto di vista dell'isolamento funzionale e della chiarezza struttuale.

Programmazione strutturata secondo Jackson

Il metodo di Jackson fa derivare la costruzione dei programmi dalle strutture dei dati che essi elaborano, prevede regole standard che guidano il progettista e si basa sui seguenti tre criteri:

I programmi devono possedere una struttura gerarchica e la loro scomposizione in sotto-programmi deve avvenire parallelamente ad una analoga suddivisione del problema da risolvere;

Nell'ambito di ciascun livello di scomposizione si deve far riferimento unicamente ai 3 componenti logici fondamentali (sequenza, scelta, iterazione) per la costruzione della struttura gerarchica del programma;

La progettazione del programma deve corrispondere ad un modello del mondo reale costruito attraverso la struttura dei dati.

Il metodo si attua secondo le seguenti fasi:

definizione della struttura dei dati;
costruzione della struttura del programma dalle strutture dei dati e dei processi di elaborazione;
individuazione delle operazioni elementari che devono essere eseguite, e loro allocazione nella struttura del programma;
pseudo-codifica (schematic-logic) della struttura del programma;
traduzione della pseudo-codifica nel linguaggio di programmazione (con metodi manuali, o automaticamente tramite un pre-compilatore).

Il metodo di Jackson comprende una strumentazione grafica che esalta il concetto top-down della strutturazione gerarchica dei problemi;
Il metodo di Jackson garantisce un rigoroso approccio deduttivo, la costante aderenza della struttura del programma alla struttura dei dati e l'autodocumentazione (tramite lo schematic-logic). Presenta tuttavia taluni limiti che

Lo sviluppo del software con tecniche non procedurali

Per tecniche non procedurali si intendono alcune metodologie di sviluppo del software la cui fondamentale caratteristica é la facilità di uso; dette metodologie per contro, richiedono un utilizzo intenso delle risorse del calcolatore, per l'alto valore semantico dei linguaggi usati. Le prestazioni in macchina pertanto sono basse e comportano, a parità di problema trattato rispetto a linguaggi di programmazione procedurali, l'uso di calcolatori di maggiore potenza.

I linguaggi della 4a generazione

I linguaggi della 4a generazione hanno una struttura orientata a fornire risposte immediate ai problemi di automazione. Un programma scritto in uno di quei linguaggi descrive l'obbiettivo di automazione da raggiungere, e non le modalità tecniche secondo cui detto obbiettivo va conseguito (come nei linguaggi procedurali tipo Assembler, COBOL, PL/I, ecc.).

I linguaggi della 4a generazione sono relativamente facili da usare, hanno una sintassi ed una grammatica simile a quella della lingua inglese, e sono spesso integrati con Data Base Management System (DBMS), cioè con quei sistemi software progettati per gestire le basi di dati, fornendo ad una pluralità di utenti servizi di organizzazione, accesso e controllo ai dati stessi (vedi la sezione Basi di dati). L'integrazione in questione è molto importante, in quanto un DBMS permette operazioni sofisticate sui dati, arricchendo notevolmente la capacità semantica dei linguaggi di 4a generazione.

Una ulteriore funzione che, di norma, accompagna i linguaggi di 4a generazione è la produzione automatica - sui video terminali - dei formati per le operazioni di immissione/emissione dati.

Il vantaggio fondamentale dei linguaggi della 4a generazione consiste nell'incremento drastico di produttività (si realizzano talora tempi di sviluppo del software inferiori di 10-40 volte rispetto a quelli ipotizzabili con tecniche procedurali), che permette una sensibile riduzione dei costi di produzione del software.

Peraltro il personale di analisi e programmazione non apprezza la logica semplice e predeterminata di tali prodotti, ritenendola limitativa della libertà di progettazione e poco aderente alla realtà aziendale che tratta - di norma con tecniche complesse - volumi elevati di dati.

Un ulteriore svantaggio dei generatori di programmi è il limitato livello di integrazione con il software esistente, che comporta talora la necessità di interfacciamenti.

I prototipi

La tecnica di predisporre prototipi del software si ritrova nei linguaggi di 4a generazione, nel generatori di applicazione e nei data base relazionali.

Consiste nell'identificare le esigenze in base alle valutazioni dell’utente, sviluppare un modello di lavoro, farlo funzionare, raffinarlo in base alle valutazioni dell'utente, ed eventualmente convertirlo in una struttura di esercizio utilizzando tecniche convenzionali. Ne deriva una concezione del ciclo di vita del software coerente con la natura sostanzialmente organizzativa del software stesso, che deve essere sviluppato in modo interattivo tenendo conto delle valutazioni degli utilizzatori.
I vantaggi dei prototipi consistono nella comprensione immediata delle implicazioni organizzativi che conseguono all'adozione effettiva del software da arte degli utenti, nella progettazione interattiva (con valutazioni immediate degli aspetti di funzionalità delle applicazioni automatizzate), nel miglioramento della produttività in fase di progettazione, e nel minor onere di mantenimento, da ascrivere al migliorato livello di qualità del prodotto.
Peraltro i prototipi mal si prestano alla trattazione di sistemi software ampi; inoltre la documentazione e la qualità dei software - soprattutto nei riguardi dell'efficienza - risultano spesso carenti.

L'approvvigionamento di software dall'esterno

L'approvvigionamento di software dall'esterno viene effettuato da parte dei Sistemi informativi in riferimento alle esigenze di:

smaltimento dell'arretrato;
smorzamento di punte di carico di lavoro;
esecuzione di lavori di bassa qualità (ad esempio conversione di programmi da un linguaggio ad un altro, senza modifica dei contenuti);
esecuzione di lavori di alta qualità richiedenti competenze che non si ritrovano nel Sistema informativo.

I vantaggi di tale approccio consistono sostanzialmente nella riduzione dei costi (normalmente lo sviluppo del software effettuato da società specializzate è molto meno oneroso di quello effettuato dalle aziende: negli USA, in media, 1 dollaro/istruzione rispetto ad 8 dollari/istruzione) e nella rapidità dei risultati, da ascrivere alla maggiore competenza che il personale della società specializzata ha nella produzione del software.

Gli inconvenienti si ritrovano fondamentalmente nella necessità di far gestire l'evoluzione del prodotto software all'esterno dell'azienda: gli sviluppi susseguenti alla consegna del prodotto vanno infatti regolati con contratti suppletivi, a volte più onerosi del contratto iniziale.

Commesse di software

Le commesse di software consistono nella produzione di software su misura da parte di ditte specializzate, (software-house); tale software viene prodotto su specifiche fornite dal committente e concordate con la software-house. Il ricorso alla collaborazione esterna presenta taluni vantaggi, quali l'ottenimento di un prodotto software di migliore qualità ed affidabilità, lo smistamento delle risorse di personale interno ad attività di maggior impegno aziendale, e la ricaduta professionale interna che si ottiene dal contatto con ambienti di livello professionale più elevato.
Per contro si hanno taluni svantaggi quali una minore autonomia nella conduzione dei lavori, una minore flessibilità nella ridefinizione delle specifiche iniziali, e la probabilità di condizionamenti esterni all'azienda in fase di esercizio del prodotto commissionato.
Nell'assegnazione della commessa, converrà pertanto che l'azienda committente si provveda di alcune garanzie e pertanto definisca le specifiche del prodotto che intende ottenere, delinei l’architettura dei sistemi hardware, software e di telecomunicazioni entro i cui ambiti il prodotto deve operare, gli standard aziendali, i metodi di progettazione e collaudo, i linguaggi di programmazione, le problematiche di recovery e di restart nonché quelle di integrità e riservatezza dei dati.
La valutazione delle offerte si effettuerà tramite una apposita griglia di parametri che deve fornire elementi di scelta delle varie alternative. È evidente che, nel caso di una commessa di software all'esterno, l'azienda è obbligata ad instaurare un negozio giuridico con una altra parte; ciò implica l'assunzione esplicita di responsabilità e la necessità di definire in modo preciso l'oggetto del contratto e le sue modalità. Le norme contrattuali devono specificare: l'oggetto dei rapporto giuridico, e in particolare il lavoro da svolgere; le modalità di realizzazione e le condizioni di consegna; la parte economica, con particolare riferimento alle clausole penali; le condizioni generali in termini di proprietà materiale ed intellettuale del software, di responsabilità, di recesso, proroga, arbitrato, risarcimento danni, ecc.
Il collaudo del prodotto è un elemento fondamentale della valutazione e quindi del rapporto giuridico che si instaura tra committente e fornitore; ad esso deve essere subordinato il pagamento di una quota parte del prezzo. In questa materia sono determinati i riferimenti al Codice Civile e in particolare all'art. 1341 (condizioni generali del contratto), all'art. 1659 e segg. (appalto), all'art. 1671 (recesso), all'art. 2229.e segg. (professioni intellettuali).

Sistemi chiavi in mano

Quando la richiesta di servizi all'esterno riguarda un sistema di elaborazione completo di tutte le sue componenti (hardware, software, telecomunicazioni) si parla di sistemi «chiavi in mano» (turn-key system). In tal caso, il committente demanda al fornitore ogni completa responsabilità di approvvigionamento o produzione di beni o servizi necessari per il conseguimento di un obbiettivo di automazione.
Per i sistemi chiavi in mano, valgono le considerazioni espresse per le commesse di software; è da notare in questo caso una separazione più netta delle responsabilità tra committente e, fornitore, che sovente giova alla instaurazione di un corretto negozio giuridico tra le parti.

Valutazione e scelta di package

La scelta di sostituire lo sviluppo del software applicativo con l'acquisizione di package cioè di programmi preconfezionati di tipo generalizzato, eventualmente da personalizzare, è suggerita principalmente dall'obbiettivo di ridurre i costi e di ottenere maggiori benefici in tempi brevi.

L'aderenza alle esigenze aziendali può sovente non essere soddisfatta dal package; in tal caso è necessario personalizzare i package stessi, con un costo variabile con il grado di personalizzazione; se il grado di personalizzazione è significativo (è sufficiente un 5-10%), il ritorno all'investimento effettuato si abbassa, e si può raggiungere il punto di convenienza rispetto allo sviluppo del software in proprio.

I benefici attesi crescono all'inizio fortemente con il grado di personalizzazione del package; quindi si arrestano, per poi impennarsi definitivamente in corrispondenza di un grado di personalizzazione pressoché totale; il ritorno effettivo dell'investimento decresce invece linearmente con il grado di personalizzazione.

Il prodotto fondamentale nella scelta dei package è quello di una appropriata valutazione: le numerose tecniche esistenti tendono ad esaminare il prodotto nel suo assieme con un approccio di tipo sintetico, oppure a decomporlo nei suoi costituenti con un approccio di tipo analitico; molto utilizzata - e più probante - è la predisposizione di un lavoro campione che fornisce, oltre a indicazioni di funzionalità e prestazioni, anche informazioni fondamentali circa la facilità di uso.

I maggiori vantaggi che si conseguono con i package consistono nella migliore qualità della fase di definizione delle esigenze (occorre definire le specifiche per poter operare la scelta di un package); nella rapidità dell'installazione e dell'ottenimento dei risultati di automazione'; nella migliore qualità ed affidabilità del software e della relativa documentazione; nella drastica riduzione dei costi (da 3 a 5 volte quelli dello sviluppo interno), e nella immediata valutazione delle prestazioni del prodotto.

Per contro, i principali svantaggi consistono nella frequente necessità di modifiche dei package, da ascrivere a bisogni di automazione ulteriori e susseguenti; nelle difficoltà di effettuare valutazioni appropriata, nelle problematiche di accettazione da parte del personale interno dedicato allo sviluppo del software, ed infine nella inesperienza di trattative commerciali della specie. L'adozione dei package può rappresentare una via economica e rapida per ottenere quei risultati di qualità media che costituiscono una gran parte della domanda di informatica nelle aziende.

Lo sviluppo di software effettuato dagli utenti finali

La rapida e capillare diffusione della microelettronica, la comparsa sul mercato dei personal computer e dei package, ha recentemente permesso lo sviluppo del software direttamente da parte degli utenti finali.

Sviluppo su mainframe

Lo sviluppo di software su mainframe ad opera degli utenti finali consiste sostanzialmente nella elaborazione tramite linguaggi di 4a generazione di dati centrali (estrazioni e aggregazioni di dati, creazioni di stralci, ordinamenti, calcoli, interrogazioni).
Lo sviluppo è tipicamente interattivo e fa uso intensivo di prototipi. Applicazioni frequenti sono quelle relative al calcolo scientifico, alla modellistica, alla simulazione, all'analisi dei dati.
I vantaggi consistono nella rapidità dello sviluppo, nella rispondenza agli obbiettivi di automazione - realizzata tramite l'interattività - e nell'accettazione entusiastica da parte degli utenti, che sentono il proprio lavoro in maniera imprenditoriale e non subordinata.
Gli svantaggi consistono nell'imprevedibilità del carico che si riserva sui calcolatori centrali, con- la conseguente necessità di alti investimenti in apparecchiatura; tale fenomeno è esasperato dalla scarsa competenza informatica degli utenti finali che producono software molto efficace ma poco efficiente; tale fenomeno tuttavia tende ad essere attenuato dal sempre migliore rapporto prestazioni/prezzo derivante dall'innovazione tecnologica.

Sviluppo su minicomputer e microcomputer

I minicomputer sono particolarmente idonei allo sviluppo di software da parte degli utenti finali.
I dati utilizzati possono essere di provenienza locale o centrale: nel primo caso i dati sono ammessi nei minicomputer/microcomputer direttamente in periferia; nel secondo caso, sono attinti dai mainframe tramite una connessione fisica e logica tra mainframe e minicomputer/microcomputer che realizza la funzione di trasferimento dei dati (file transfer).
Le applicazioni sono trattate con linguaggi tradizionali con linguaggi di 4a generazione, ovvero con package di gestione dati o del tipo foglio elettronico (spread sheet) che evidenziano sul video una struttura tabellare atta a gestire informazioni numeriche, alfabetiche o funzionali.
Importanti sono le implicazioni sul piano organizzativo: i dati e le capacità di elaborazione vengono decentrati; cresce l'efficacia di tutto il software aziendale che viene attuato anche su base decentrata, e risulta pertanto insensibile ai disservizi delle strutture centralizzate. Cresce parimenti l'utilizzo dell'automazione, che passa da una professione specialistica ad una metodologia comune di lavoro per tutto il personale aziendale. A ciò fa riscontro una attenuazione del controllo centralizzato dell'automazione.

Valutazione dei prodotti software per gli utenti finali

I prodotti software per gli utenti finali sono inquadrabili nelle seguenti categorie:

prodotti integrati per personal computer;
linguaggi di interrogazione (query language) e generatori di tabulati (report generator);
generatori di grafici;
generatori di applicazioni,
supporti alle decisioni.

La produzione di applicazioni da parte degli utenti finali (che ha ritmi di sviluppo maggiori di quella originata dal Sistema informativo) si può in larga misura ascrivere alla maggiore semantica dei prodotti software utilizzati rispetto a quelli tradizionali. I prodotti software per gli utenti finali sono infatti caratterizzati dai seguenti elementi:

uso del linguaggio naturale;
uso di interfacce diversificate a seconda del livello di esperienza dell 9 utente;
uso di menu che definiscono le scelte possibili;
uso di programmi di stimolo (prompter) che concentrano l'attenzione su aspetti significativi;
uso di spiegazioni (help) di aiuto alla comprensione;
uso di programmi di autoistruzione;
uso di finestre video multiple che permettono la gestione contemporanea di più problemi;
uso di simboli grafici (icone) di percezione immediata;
uso di opzioni standard (default option) intelligenti che consentono anche all'utente più inesperto un uso efficace e razionale del sistema;
uso di un dispositivo (mouse) sensibile al movimento sul piano della scrivania, che determina il movimento di un. segnale di controllo sul video (tale dispositivo sostituisce in modo molto più semplice e immediato, la tastiera, per gran parte delle funzioni);
controllo degli errori e loro eventuale correzione;
interazione rapida con le immagini e i dati contenuti nel video.

Sulla base degli elementi sopra riportati, va effettuata la valutazione della qualità di un prodotto software per l'utente finale. Essa va integrata dalla considerazione di tutta una serie di aspetti generali che non interessano l'utente finale, ma i gestori. dei sistemi, e riguardano problematiche di integrazione, economie di scala, ecc.

La valutazione tecnico-economica e la conduzione dei progetti di sviluppo del software

La metrica del software

Come abbiamo già visto, qualsiasi tipo di progettazione deve misurarsi con i tre vincoli fondamentali che rispondono ai concetti di prestazione, costi e tempi.
Nel caso dello sviluppo di progetti software la problematico viene esasperata da una serie di vincoli ulteriori che influenzano i precedenti in modo talmente variabile che gli intervalli di incertezza aumentano di molto.
Sorge quindi spontanea l'esigenza di concepire ed utilizzare metodi di misura e controllo della produzione nonché di stima dell'impegno e della durata della progettazione: ne discende tutta una letteratura di metrica del software di cui sono qui riassunte le risultanze fondamentali.
Certo è che tali metodi debbono, su base statistico-matematica, fornire sufficienti risposte ad una serie di domande che sono tipiche della progettazione del software.
Tali domande attengono all'analisi delle esigenze dell'utenza, alla definizione delle specifiche, alla progettazione di massima, alla progettazione dettagliata, allo sviluppo, ai collaudi, alla manutenzione correttiva, adattativa ed evolutiva, alla sostituzione infine del prodotto software al termine del suo ciclo di vita.
Sarebbe utile avere, perlomeno entro gradi di confidenza conosciuti, risposte a tali domande già a livello dello studio di fattibilità in modo da avere gli elementi sufficienti per poter decidere di dare attuazione al 'progetto di sviluppo del software.
Ciò è conseguibile sia con. una penetrazione appropriata nel ciclo di vita che non sia tanto avanzata da comportare costi elevati né tanto limitata da offrire informazioni poco attendibili, sia con l'utilizzo di metodi di stima i quali, pur seguendo tecniche differenziate si badano pur sempre, sull'esperienza pregressa.

Di seguito è esposta una rassegna dei metodi di stima dell'impegno e della durata dei progetti software che sono più usati.
È intuitivo comunque che tali metodi dovranno tener debito e proporzionato conto di molti aspetti, essi sono qui di seguito elencati:

Caratteristiche del prodotto software che si vuole sviluppare

Esse attengono fondamentalmente al contenuto del prodotto e in particolare: alla dimensione dei prodotto in termini di numero di istruzioni da scrivere, moduli software da progettare, ampiezza dei dati da trattare, alla integrazione organizzativa, funzionale e tecnica che il prodotto avrà con gli altri prodotti già esistenti in azienda; alla qualità nel senso di affidabilità, correttezza, efficacia, efficienza, comprensibilità, coerenza, apertura nei confronti dell'evoluzione, riusabilità, portabilità, ecc.

Caratteristiche dell'ambiente costituito dall'utenza

Esse attengono fondamentalmente alla definizione delle specifiche, alla definizione di uno studio di fattibilità che esprima i costi e i benefici dei progetto, al livello di coinvolgimento dell'utenza, all'atteggiamento che gli utenti hanno nei confronti dell'innovazione tecnologica e dei metodi di progettazione.

c) Caratteristiche del progetto
Esse attengono fondamentalmente: alle scadenze di tempo fissate, al budget pianificato, al tipo di processo produttivo scelto (sequenziale, strutturato, consolidato, innovativo, ecc.).

d) Caratteristiche dell'ambiente di produzione
Esse attengono fondamentalmente al numero e alla qualità delle risorse umane assegnate al progetto e ai mezzi di produzione intesi nel senso dell'efficacia degli strumenti (calcolatori per i test, posti di lavoro attrezzati per programmatori, linguaggi di programmazione, editor, generatori di programmi, software per la gestione delle basi di dati, librerie automatiche di programmi, ecc.) ai fini dell'ottenimento rapido ed efficiente del prodotto software.

I metodi che saranno esposti saranno quindi caratterizzati da una serie di parametri connessi in modo essenzialmente statistico con gli aspetti indicati.

È da considerare tuttavia che la attendibilità del metodo di stima è direttamente correlata con la scelta dei parametri veramente essenziali e che comunque il numero di essi non Può essere molto elevato per motivi di precisione della stima, semplicità e speditezza del metodo.

I Metodi classici di stima dei costi

Un metodo usuale di stima dei costi di progettazione di un prodotto software è quello che va sotto la denominazione: «top-down». Esso si basa sulla valutazione delle proprietà globali del prodotto (definite dai benefici ottenibili e coerenti con il budget), sul calcolo del costo relativo e sulla suddivisione progressiva di detto costo tra le varie componenti, del prodotto secondo una logica sostanzialmente gerarchica che procede dall'alto, verso il basso e mutua le valutazioni dall'esperienza pregressa.
Tale metodo si rivela utile per quanto attiene la pianificazione di massima di un progetto, ma può incorrere in errori di ampiezza molto grande in quanto possono essere trascurati fattori anche essenziali; inoltre si può verificare il fenomeno della identificazione dei costi con i benefici (in pratica i costi si espandono fino ad identificarsi in termini finanziari con i benefici ottenibili). Un altro metodo, anch'esso usuale, è quello. denominato «bottom-up» che procede con logica inversa.

Il prodotto software viene pertanto suddiviso in componenti elementari di cui da parte dei progettisti viene definito, in base all'esperienza o per analogia, il costo; quindi si effettua una sommatoria dei costi elementari e si ottiene il costo totale.

Il metodo si rivela efficace solo se si è in fase avanzata del ciclo di vita del software (in pratica per poter effettuare le stime elementari è necessario arrivare fino alla progettazione di dettaglio); tuttavia il metodo schematizza semplicisticamente con una logica gerarchica le interrelazioni che sussistono tra i componenti del prodotto software; ciò può comportare errori anche se di grandezza minore rispetto a quelli del metodo precedente.

Ulteriori metodi di stima che vanno sotto il nome di metodi classici sono quelli che si basano sugli standard di produttività tipici dell'ambiente aziendale di produzione del software o delle società fornitrici di servizi, sulle analogie rispetto a situazioni similari, sulle valutazioni comparate fatte da più progettisti o da esperti.

Il pregio dei metodi classici consiste nella semplicità e nella correlazione diretta con il buon senso comune; il difetto fondamentale consiste nel fatto che essi non sono «costruttivi» nel senso che l'esperienza accumulata non viene registrata, sistematizzata e resa disponibile a tutto l'ambiente aziendale: essa è nella più parte dei casi di tipo personale e non comporta un incremento nel tempo della precisione della stima.

Infine in genere nella produzione del software non vengono valutati i costi relativi alla rimozione degli errori sia in fase di sviluppo che in fase di esercizio: ciò porta a non evidenziare una quota non trascurabile di costo che, specie in ambienti artigianali di produzione del software riscontrabili nei Sistemi informativi aziendali, può arrivare fino al 30% dei costi totali. Ciò è da ascrivere ad un errato concetto di produttività intesa secondo teorie economiche adottate meccanicisticamente e che utilizzano indici di produzione per unità di lavoro o di costo piuttosto che secondo il senso comune che tende a raggiungere presto e bene un obbiettivo.

A ciò si deve necessariamente aggiungere l'impatto dovuto ai fattori umani; mai si dovrebbe dimenticare infatti che la produzione di un prodotto ad opera di un progetto (di cui - come già indicato - la predisposizione del software è solo una parte) è una attività condotta da un gruppo di individui con competenze e caratteristiche professionali ed umane diverse con intense comunicazioni interpersonali.

Tale aspetto che vincola fortemente sia la produttività che addirittura la riuscita del progetto, viene, sovente e a torto trascurato; ad esso viene pertanto dedicato il prossimo paragrafo.

I fattori umani

L'influenza della strumentazione tecnica sulla produttività del personale

La strumentazione tecnica a disposizione del personale addetto allo sviluppo del software può influenzare notevolmente la produttività.
Lo strumento tecnico principe è rappresentato dal linguaggio di sviluppo utilizzato; tanto più il linguaggio di sviluppo é dotato di potenza semantica per la rappresentazione e, risoluzione dei problemi, tanto più sarà alta la produttività del personale il quale potrà concentrarsi sul «problem solving» piuttosto che sul tecnicismi connessi a detta attività.

La produttività dei settori di produzione del software è anche influenzata dalla strumentazione hardware che caratterizza l'ambiente di sviluppo.

Infatti è stato dimostrato sperimentalmente che la produttività dei programmatori è molto sensibile al tempo di risposta del calcolatore alle transazioni interattive tipiche del lavoro di programmazione di messa a punto dei programmi.

In pratica si ottiene che le condizioni migliori di sviluppo dei progetti software si hanno quando il tempo di risposta del calcolatore è minore di 0,2 sec; questo risultato è tipico dei processi interattivi dove la rapidità di funzionamento delle infrastrutture.

Notevoli miglioramenti di produttività sono stati anche osservati in riferimento alla facilità di utilizzo dei terminali da parte dei programmatori.

La preponderanza del fattore costituito dal personale aspetto a tutti gli altri fattori di produzione del software

Tuttavia il fattore fondamentale per l'ottenimento di alti livelli di produttività e di qualità del software è costituito dal personale.
Ciò è naturale se si pensa al fatto che lo sviluppo del software è, come più volte indicato, una attività intellettuale e personale da parte di un gruppo di individui i quali, per raggiungere l'obbiettivo devono avere intensi e proficui rapporti interpersonali.
Ne consegue che le tecniche manageriali e psicologiche di corretta gestione del gruppo sono essenziali per, l'ottenimento di un buon prodotto nei tempi stabiliti e nell'ambito dei costi previsti.

La legge della «qualità contro la quantità»

«È meglio avere poche persone di alto livello che molte di livello medio o basso».
Questo principio (peraltro poco applicato nella pratica aziendale) deriva dall’esperienza.
In molti campi di attività osservati il 20% del personale produce circa il 50% del prodotto mentre il 50% del personale produce appena il 20% del prodotto; il restante 30% del personale produce il restante 30%.

La legge della «persona giusta al posto giusto»

«È necessario collocare le persone in posizioni coerenti con le loro aspirazioni e capacità».
Anche questo principio viene spesso poco praticato presso le aziende che attuano invece per vincoli normativi, opportunità aziendali o carenze manageriali il cosiddetto Principio di Peter: «in una gerarchia ciascun impiegato tende a raggiungere il proprio livello di
incompetenza».

Il Principio di Peter viene seguito sovente per quello che riguarda le carriere dei programmatori meritevoli che vengono promossi in posizioni di management anche se la loro massima aspirazione in media è quella dello sviluppo professionale.

La legge della «realizzazione del personale»

«Una azienda migliora nel lungo termine se aiuta il proprio personale a realizzarsi».

Tale legge si basa sulle osservazioni di Manslow:

le persone, quando si realizzano, raggiungono la vetta più alta nella gerarchia dei bisogni;
le persone non sono motivate da bisogni di alto livello quando quelli più elementari non sono soddisfatti;
i bisogni soddisfatti non agiscono come elementi di motivazione.

Nel campo dello sviluppo dei software un buon metodo per aiutare le persone a realizzarsi è quello di permettere loro uno sviluppo professionale elevato.

Le aziende tuttavia si comportano spesso in modo opposto e si attengono sovente a comportamenti schematizzabili secondo le seguenti leggi:

«Il Principio inverso dì Peter»: le persone vanno a finire in posizioni organizzativi in cui diventano insostituibili e lì rimangono per sempre decadendo continuamente (tale situazione si riscontra frequentemente nei programmatori addetti al mantenimento dei software).
«Il Principio di Paul»: le persone vanno a finire in posizioni organizzative in cui le loro competenze tecniche diventano obsolete in 5 anni (tale situazione si riscontra frequentemente per i responsabili dei progetti software e per gli analisti).

La legge dell'«armonia del gruppo»

«Le persone che fanno parte di un gruppo devono essere scelte in modo da armonizzarsi e complimentarsi vicendevolmente».
Tale legge tende a moderare la legge della «qualità contro quantità» che può provocare, se attuata senza - buon senso, frizioni notevoli tra elementi di personale di qualificazione elevata. £ molto importante l'aspetto della complementazione: infatti nell'ambito di un gruppo esiste sempre una diversificazione di ruoli che va assolta da personale diversificato: la simbiosi fra questi elementi di differente livello produce risultati globali di gruppo molto efficaci.

La legge della «motivazione»

«La motivazione del personale è un fattore essenziale per il raggiungimento degli obbiettivi».
La motivazione va infatti considerata come il fattore di maggiore importanza per quanto attiene alla produttività.
Un buon approccio al problema della motivazione del personale addetto allo sviluppo del software consiste nel comprendere gli obbiettivi a cui detto personale tende e nello strutturare l'organizzazione aziendale per soddisfarli.

Caratteristiche ideali del personale da adibire alla progettazione del software

La caratteristica che si ritiene fondamentale nel campo della progettazione del software é la volontà realizzativa; ciò può apparire ovvio e banale in quanto tale elemento è matrice comune ed essenziale di tutte quelle attività dive lo. scopo viene raggiunto solo in base ad uno sforzo intellettivo. messo in moto da un atteggiamento volontaristico; la progettazione. del software non sfugge a questa legge di carattere generale che ha ben poche eccezioni e di ciò fa fede l'enorme discrepanza di produttività aderente ad individui cioè, dotati delle medesime capacità intellettuali e doti culturali, sono differenziabili solo dal punto di vista della volontà realizzativa.
Altra caratteristica veramente essenziale è quella che si può esprimere sotto il termine di capacità percettiva; essa è definibile come l'abilità tutta particolare dell'uomo a rilevare, nell’ambito degli schemi di riconoscimento usati nella realtà circostante, qualsiasi elemento non corrispondente alle strutture logiche o formali precedentemente memorizzate.
Tale caratteristica è ovviamente connessa la abilità mnemonica; per essere valida, tale capacità deve essere non solo di tipo associativo e ad elaborazione similare di sequenze uditive o visive, ma deve anche essere in grado di riconoscere strutture analoghe o analogamente trasferibili.

Inoltre si ritiene condizionante la capacità logica; essa è definibile come l'attitudine a sviluppare da una serie di premesse certe una sequenza di considerazioni i cui effetti finali rispettino i principi fondamentali della logica quali ad esempio il principio di non contraddizione, del terzo escluso, ecc.
Tale facoltà che è da ascrivere fondamentalmente a cause naturali, può nondimeno essere di molto coltivata tramite lo studio e l'esercizio dell'algebra booleana e della logica formale.

Ulteriore caratteristica essenziale è la capacità numerica; essa consiste come intuibile - nella possibilità di sviluppare ragionamenti di tipo aritmetico in maniera rapida e corretta cogliendo con la maggiore immediatezza possibile il punto fondamentale di risoluzione dei quesiti e dei problemi proposti; anche in tale caso si hanno notevolissime opportunità di coltivazione di questa attitudine, ma resta comunque la considerazione che essa fa comunque capo a facoltà naturali primitive o acquisite in epoca scolare.
Alle caratteristiche indicate, che si ritengono in questa sede fondamentali, fanno comunque corona un'altra serie di elementi essenziali che concorrono in maniera molto determinante a realizzare il conseguimento degli obbiettivi. Essi sono una generale attitudine all'apprendimento, una naturale curiosità scientifica, un ordine mentale estrinsecabile anche in aspetti esterni, la capacità di schematizzazione tramite strutture numeriche e grafiche e da ultimo la capacità di operare proficuamente nell'ambito di gruppi di lavoro, intesa principalmente nel senso di disponibilità nei confronti dei colleghi.
Una caratteristica che non è precipua degli ambienti di progettazione ma è insita in ogni disciplina, è infine la correttezza e la deontologia professionale che anche in questa materia si estrinseca secondo i consueti schemi di etica comportamentale che non è lecito né proficuo trascurare.

Fonte: http://www.francescodebenedetto.it/informatica/manuali/ingsoftware.doc
Sito web: http://www.francescodebenedetto.it/
autore: Francesco de Benedetto