1. Cap. 1<br />L’ingegneria del software è il settore dell’informatica che si occupa della creazione di sistemi software talmente grandi o complessi da dover essere realizzati da una o più squadre di ingegneri. L’IEEE Standard definisce l’ingegneria del software come l’applicazione di un approccio sistematico, disciplinato e quantificabile nello sviluppo, funzionamento e manutenzione del software.<br />Un sistema software è spesso un componente di un sistema più vasto. L’ingegneria del software è quindi parte di un’attività di progettazione di sistema molto più vasta in cui i requisiti del software interagiscono con i requisiti di altre parti del sistema durante la progettazione.<br />Il software diviene sempre di più la parte interna intelligente di vari sistemi, dalle televisioni agli aeroplani. Si parla, in tal caso, di software embedded.<br />L’ingegnere del software deve essere un buon programmatore, molto versato in strutture dati e algoritmi ed esperto in uno o più linguaggi di programmazione. Questi sono dei requisiti per la cosiddetta “programmazione in piccolo”, definita approssimativamente come la creazione di programmi che possono essere scritti interamente da un unico individuo. Ma un ingegnere del software è coinvolto anche nella “programmazione in grande”, cioè deve aver familiarità con più approcci di progetto, deve essere capace di tradurre richieste e desideri vaghi in precise specifiche, e anche di interagire con l’utente di un sistema nei termini dell’applicazione più che nel gergo tecnico degli informatici.<br />Il ciclo di vita del software<br />Il software subisce uno sviluppo e un’evoluzione, dall’idea iniziale di un possibile prodotto o sistema software fino a quando viene implementato e consegnato al cliente. Si dice che il software ha un ciclo di vita composto di varie fasi. Il modello tradizionale del ciclo di vita, chiamato “modello a cascata” è composto dalle seguenti fasi:<br />Analisi e specifica dei requisiti: viene intrapresa dopo aver compiuto uno studio di fattibilità per definire in modo preciso i costi e i benefici di un sistema software con lo scopo di identificare e documentare i requisiti del sistema. Nei casi in cui i requisiti non siano chiari, è necessario che vi sia ampia interazione tra cliente e lo sviluppatore. Questa fase deve portare alla creazione di manuali per gli utenti e alla progettazione dei test di sistema che saranno effettuati alla fine, prima della consegna del sistema.<br />Progettazione di sistema e sua specifica: una volta che i requisiti del sistema sono stati documentati, gli ingegneri del software progettano un sistema software che li soddisfi. Questa fase è a volte divisa in due sottofasi: il progetto architetturale e il progetto dettagliato. Il progetto architetturale affronta l’organizzazione globale del sistema in termini di componenti di alto livello e delle loro interazioni. Man mano che ci si addentra in livelli di progettazione sempre più dettagliati, i vari componenti vengono scomposti in moduli di basso livello, con interfacce definite in modo accurato. Tutti i livelli di progettazione vengono indicati in un documento di specifica che fornisce informazioni sulle decisioni di progettazione prese.<br />Codifica e test di modulo: in questa fase, l’ingegnere produce il codice che sarà consegnato al cliente sotto forma di un sistema funzionante. Anche altre fasi del ciclo di vita del software potranno portare allo sviluppo di codice, ad esempio per effettuare test, per sviluppare prototipi e test driver, ma in tutti questi casi il codice sviluppato sarà impiegato solamente dagli sviluppatori. Bisogna notare che i singoli moduli creati nella fase di codifica vengono testati prima di passare a quella successiva.<br />Interpretazione e test di sistema: tutti i moduli sviluppati e testati singolarmente nella fase precedente vengono in questa assemblati, integrati, e testati come un unico sistema.<br />Consegna e manutenzione: una volta che il sistema supera tutti i test, viene consegnato al cliente ed entra nella fase di manutenzione in cui vengono incorporate tutte le modifiche apportate al sistema dopo la prima consegna.<br />Cap. 2 – Il software: natura e qualità<br />Nelle discipline dell’ingegneria tradizionale, l’ingegnere dispone di strumenti per descrivere le qualità del prodotto in maniera distinta rispetto al progetto del prodotto stesso. Nell’ingegneria del software questa distinzione non è così chiara: le qualità di un prodotto software sono molte volte mescolate nelle specifiche, insieme alle qualità intrinseche del progetto. Queste qualità diventeranno i nostri obiettivi da perseguire nella pratica dell’ingegneria del software.<br />Classificazione delle qualità del software.<br />Esistono molte qualità desiderabili per il software; alcune si applicano sia al prodotto che al processo utilizzato per il suo sviluppo. L’utente richiede che il prodotto software sia affidabile, efficiente e facile da usare. Il produttore del software desidera che sia verificabile, manutenibile, portabile ed estendibile. Il manager di un progetto software desidera che il processo di sviluppo sa produttivo, prevedibile e facile da controllare.<br />Qualità interne ed esterne.<br />Possiamo dividere le qualità del software in due categorie: interne ed esterne. Le qualità esterne sono visibili agli utenti del sistema mentre le qualità interne riguardano gli sviluppatori. In generale gli utenti del software hanno interesse soltanto nelle qualità esterne, ma sono le qualità interne, che in larga misura hanno a che fare con la struttura del software, ad aiutare gli sviluppatori a raggiungere le qualità esterne.<br />Qualità del processo e qualità del prodotto.<br />Per realizzare un prodotto software si utilizza un processo. È possibile attribuire alcune qualità a un processo, anche se le qualità del processo sono spesso correlate con quelle del prodotto. Nell’affrontare le qualità del software è bene comunque cercare di distinguere tra qualità del processo e qualità del prodotto.<br />Il termine prodotto di solito si riferisce a quanto viene alla fine consegnato al committente. Il prodotto effettivamente visibile al committente consiste nel codice eseguibile e nei manuali utente, ma lo sviluppatore produce un numero elevato di altri artefatti, quali i documenti di specifica dei requisiti e di progetto, i dati di test e così via. Questi prodotti intermedi sono spesso soggetti agli stessi requisiti di qualità del prodotto finale. L’attività di gestione delle configurazioni (configuration management) costituisce quella parte del processo di produzione del software che affronta il problema di le relazioni tra tutti i diversi prodotti intermedi delle varie versioni di un prodotto.<br />Principali qualità del software.<br />Con riferimento alle classificazioni che abbiamo descritto analizziamo le più importanti qualità dei prodotti e dei processi software. I termini correttezza, affidabilità e robustezza sono strettamente correlati e insieme caratterizzano una qualità del software secondo la quale l’applicazione realizza la sua funzionalità attesa.<br />Correttezza<br />Un programma deve soddisfare la specifica dei suoi requisiti funzionali (functional requirements specification); esistono tuttavia altri requisiti, quelli di prestazioni e di scalabilità, i quali non fanno riferimento alle funzionalità del sistema. Un programma è funzionalmente corretto se si comporta secondo quanto stabilito dalle specifiche funzionali. Spesso si usa il termine “corretto” invece di “funzionalmente corretto”.<br />La definizione di correttezza assume che le specifiche del sistema siano disponibili e che sia possibile determinare in maniera non ambigua se un programma soddisfi le specifiche. La correttezza è un proprietà matematica che stabilisce l’equivalenza tra il software e la sua specifica.<br />Si può valutare la correttezza di un programma mediante vari metodi, alcuni basati su un approccio sperimentale (il testing), altri basati su un approccio analitico, come le ispezioni di codice o la verifica formale della sua correttezza.<br />Affidabilità<br />Il software è considerato affidabile nella misura in cui l’utente può fare affidamento sulle sue funzionalità. Si definisce affidabilità la probabilità che un software operi come atteso in un intervallo di tempo determinato.<br />La nozione di affidabilità è relativa. Se la conseguenza di un errore software non è grave, un software non corretto può continuare a essere considerato affidabile. È comune attendersi che i prodotti dell’ingegneria siano affidabili: quelli non affidabili di solito scompaiono velocemente dal mercato.<br />Gli errori di progettazione del software vengono spesso trattati come inevitabili e, quando troviamo errori in un’applicazione, invece di essere sorpresi, in un certo senso li accettiamo con una sorta di rassegnazione. Di solito i prodotti software sono accompagnati da un avvertimento, nel quale il produttore afferma che non si ritiene responsabile degli errori presenti nel prodotto e dagli eventuali danni che possono provocare.<br />Robustezza<br />Un programma è robusto se si comporta in modo accettabile anche in circostanze non previste nella specifica dei requisiti, per esempio quando vengono inseriti dati di input non corretti o in presenza di malfunzionamenti hardware. Un programma non è robusto se assume dati di ingresso perfetti e genera errore non recuperabile durante l’esecuzione. <br />La robustezza è una qualità difficile da descrivere: se potessimo definire esattamente che cosa occorrerebbe fare per rendere un’applicazione robusta, saremmo sempre capaci di specificare, in maniera completa, il comportamento che ci attendiamo da un programma, e pertanto la robustezza diventerebbe equivalente alla correttezza o all’affidabilità.<br />Possiamo dire che la robustezza e la correttezza sono caratteristiche strettamente correlate, senza che esista una linea divisoria netta tra le due. Se un requisito diventa parte della specifica, il suo soddisfacimento diventa un problema di correttezza; se invece lasciamo un requisito fuori dalla specifica, allora esso può diventare un problema di robustezza.<br />Prestazioni<br />È comune attendersi che un prodotto dell’ingegneria offra buone prestazioni. Diversamente da altre discipline, nell’ingegneria del software molte volte confondiamo le prestazioni con l’efficienza, malgrado questi termini non denotino esattamente le stesse caratteristiche. L’efficienza è una caratteristica interna che si riferisce al “peso” che un software ha sulle risorse del computer. La prestazione invece è una qualità esterna basata sui requisiti dell’utente. <br />Le prestazioni sono importanti in quanto influiscono sull’utilizzabilità di un sistema; infatti, se un sistema software è troppo lento, può ridurre la produttività dell’utente, magari fino al punto da non soddisfare più le sue esigenze. Se un sistema software utilizza troppo spazio su disco, potrebbe anche essere troppo costoso; se usa troppa memoria potrebbe rallentare la propria esecuzione mentre il sistema operativo cerca di bilanciare l’uso della memoria da parte delle varie applicazioni in esecuzione in quel momento.<br />Le prestazioni sono inoltre importanti in quanto influenzano la capacità di crescita (scalability) di un sistema software. Un algoritmo di complessità quadratica potrà funzionare per input di piccole dimensioni, ma di sicuro non funzionerà per input di grandi dimensioni. Ci sono vari modi per valutare le prestazioni di un sistema, ad esempio analizzando la complessità degli algoritmi usati. Vi è una teoria che classifica il funzionamento di un algoritmo nella situazione peggiore (worst case) e in quella media (average), in termini di tempo e spazio o in termini del numero di messaggi scambiati nei casi di sistemi distribuiti.<br />L’analisi di complessità degli algoritmi fornisce informazioni solo sui casi medio e peggiore, ma non fornisce alcuna informazioni specifica su di una determinata implementazione. Per avere informazioni più specifiche e dettagliate, possiamo usare le tecniche di valutazione delle prestazioni. I tre metodi principali per valutare le prestazioni di un sistema sono: misura(measurement), analisi (analysis) e simulazione (simulation).<br />Possiamo misurare le prestazioni reali di un sistema grazie a sistemi hardware e software di monitoraggio, che collezionano dati mentre il sistema è in esecuzione e quindi ci permettono di scoprire eventuali colli di bottiglia nel sistema. Il secondo approccio si basa sulla costruzione di un modello del prodotto e al suo successivo studio analitico. Il terzo approccio invece si basa sulla costruzione di un modello che simula il prodotto.<br />In alcuni progetti complessi, per i quali potrebbe non essere ovvia la raggiungibilità di determinati requisiti di prestazioni, ci si impegna a creare modelli per l’analisi delle prestazioni.<br />Usabilità<br />Un software è usabile (usable) o, più comunemente, user friendly, se i suoi lo reputano facile da utilizzare. Questa definizione riflette la natura soggettiva dell’usabilità. Le qualità che rendono un’applicazione user friendly ai principianti sono diverse da quelle desiderabili per gli utenti esperti.<br />L’interfaccia utente influisce molto sull’amichevolezza di un’applicazione. Comunque, esistono altri componenti, oltre all’interfaccia utente, che influiscono sul grado di usabilità di un’applicazione. Ad esempio, un sistema software embedded non ha alcuna interfaccia utente ma interagisce con componenti hardware o con altri software. In questo caso l’usabilità si basa sul grado di facilità di configurazione del software e di adattamento all’ambiente hardware circostante.<br />In generale, l’usabilità di un sistema dipende dalla coerenza e dalla prevedibilità della sua interfaccia nei confronti dell’utente o dell’operatore. Chiaramente altre qualità già precedentemente citate, come la correttezza e le prestazioni, influiscono sul livello di facilità d’uso. <br />L’usabilità è studiata anche dalla disciplina scientifica che si occupa del “fattore umano” (human factor) e i risultati sono estremamente importanti in molti ambiti dell’ingegneria.<br />La facilità d’uso in molte discipline ingegneristiche viene raggiunta con la standardizzazione dell’interfaccia uomo-macchina.<br />Verificabilità<br />È molto importante poter facilmente procedere alla verifica della correttezza e delle prestazioni di un sistema software: questa caratteristica è detta, appunto, verificabilità. Una tecnica comune per aumentare la verificabilità si basa sull’uso di software monitor (codice inserito nel software per mantenere sotto controllo determinati aspetti della qualità, come le prestazioni o la correttezza). Al fine di migliorare, fin dall’inizio, la verificabilità, si possono adottare metodi di progettazione modulare, norme sistematiche di codifica e l’uso di linguaggi di programmazione appropriati alla scrittura di codice ben strutturato.<br />Manutenibilità<br />Il termine “manutenzione del software” viene comunemente usato per indicare le modifiche effettuate su un software dopo il suo rilascio iniziale. Inizialmente, si riteneva che la manutenzione riguardasse esclusivamente l’eliminazione degli errori; tuttavia è stato dimostrato che la maggior parte del tempo per la manutenzione viene di fatto impiegato per migliorare il prodotto implementando caratteristiche che inizialmente non erano presenti nelle specifiche originali, o per correggere specifiche che erano state introdotte in maniera scorretta.<br />I fatti dimostrano che i costi della manutenzione superano il 60% dei costi totali del software. Per analizzare i fattori che influenzano tali costi è comune classificare la manutenzione del software in tre categorie: correttiva, adattativa e perfettiva.<br />La manutenzione correttiva riguarda la rimozione di errori residui presenti nel prodotto al momento del rilascio, come pure l’eliminazione di errori introdotti nel software durante l’attività di manutenzione stessa.<br />Le attività di manutenzione adattativa e perfettiva derivano dalle richieste di cambiamenti nel software e richiedono, da parte dell’applicazione, una capacità di evolvere come qualità fondamentale. Richiedono anche la capacità di anticipare i cambiamenti, quale principio generale che dovrebbe guidare l’ingegnere del software nello svolgimento delle attività progettuali.<br />La manutenzione adattativa riguarda le modifiche dell’applicazione in risposta a cambiamenti nell’ambiente come, per esempio, una nuova versione dell’hardware, del sistema operativo o del DBMS con il quale il software interagisce.<br />Infine, la manutenzione perfettiva riguarda i cambiamenti nel software per migliorarne alcune qualità. In questo caso i cambiamenti sono dovuti alla necessità di modificare le funzioni offerte dall’applicazione, aggiungerne di nuove, migliorare le prestazioni, renderne più facile l’utilizzo.<br />La manutenibilità può essere vista come un insieme di due diverse qualità: la riparabilità e l’evolviblità.<br />Riparabilità<br />Un sistema software è riparabile se i suoi difetti possono essere corretti con una quantità ragionevole di lavoro. Una tecnica per ottenere la riparabilità dei prodotti consiste nell’utilizzo di parti standard, facilmente sostituibili.<br />La riparabilità è influenzata anche dal numero di parti del prodotto. Un prodotto software che consiste di moduli ben progettati è più facile da analizzare e riparare di un sistema monolitico. Il semplice aumento del numero di moduli però non rende di per sé più riparabile un prodotto. È necessario scegliere la corretta struttura dei moduli, con le giuste interfacce che evitino l’insorgere di interconnessioni e interazioni troppo complesse tra moduli. <br />La riparabilità può essere migliorata anche attraverso l’uso di strumenti adeguati, come ad esempio i debugger, che possono aiutare ad isolare e riparare gli errori. Infine la riparabilità di un prodotto ne influenza l’affidabilità, e la necessità di riparabilità diminuisce con l’aumentare dell’affidabilità.<br />Evolvibilità<br />Come altri prodotti dell’ingegneria, i prodotti software sono modificati in continuazione al fine di fornire nuove funzioni o modificare quelle già esistenti. Il fatto che il software sia intrinsecamente duttile rende le modifiche molto facili da effettuare direttamente sull’implementazione. Esiste tuttavia una sostanziale differenza tra le modifiche nel campo software e le modifiche negli altri campi ingegneristici. Occorre osservare che i prodotti software di successo hanno una lunga vita. Il loro rilascio iniziale è il primo di una lunga serie di rilasci, ciascuno dei quali costituisce un passo nell’evoluzione del sistema. Se il software viene progettato avendo in mente la sua evoluzione e se ogni modifica viene progettata e poi messa in pratica attentamente, allora il software può effettivamente evolvere in maniera ordinata e controllata.<br />Riusabilità<br />La riusabilità è per molti aspetti simile all’evolvibilità. Nell’evoluzione di un prodotto, questo viene modificato per dare vita a una nuova versione; nel caso del riuso, questo viene utilizzato – magari con un numero inferiore di modifiche – per dar vita ad un prodotto diverso. La riusabilità può essere applicata a vari livelli di granularità – dall’intera applicazione a specifiche routine – tuttavia il concetto sembra applicarsi meglio ai componenti software piuttosto che ai prodotti completi.<br />Una delle finalità della programmazione object oriented è esattamente quella di raggiungere sia una migliore riusabilità che una migliore evolvibilità. Oltre ai componenti software, il concetto è applicabile in maniera più ampia e, a diversi livelli, può riguardare sia il prodotto sia il processo. In generale, qualunque artefatto del processo software, quale ad esempio la specifica dei requisiti, può essere reimpiegato. Pertanto, la possibilità di riusare questi artefatti, per intero o solo alcune parti, dipenderà da quanto sia modulare il progetto.<br />Portabilità<br />Il software è portabile se può essere eseguito in ambienti diversi. Il termine ambiente può riferirsi alla piattaforma hardware o all’ambiente software, come il particolare sistema operativo nel quale l’applicazione viene eseguita. La portabilità è economicamente importante, in quanto consente di ammortizzare gli investimenti in un sistema software su diversi ambienti e diverse generazioni dello stesso ambiente. <br />La portabilità può essere ottenuta modula rizzando il software, in modo tale che le dipendenze dall’ambiente vengano isolate in pochi minuti, modificabili in caso di trasporto del software in un ambiente diverso. A causa della proliferazione di sistemi distribuiti in rete, la portabilità ha assunto ulteriore importanza, in quanto gli ambienti di esecuzione, che consistono di diversi tipi di computer e sistemi operativi, sono per loro natura eterogenei.<br />Comprensibilità<br />Alcuni sistemi software sono più facili da capire da altri. La comprensibilità di un sistema software dipende in parte da come il software è progettato, ma in larga misura dipende dal problema affrontato dal software: alcuni problemi sono per loro natura più complessi di altri.<br />Durante l’attività di manutenzione di un software è fondamentale la comprensione dei programmi. Gli ingegneri che effettuano manutenzione passano gran parte del loro tempo a cercare di capire la logica dell’applicazione e solo una piccola porzione del loro tempo viene impiegata per effettuare i cambiamenti necessari. La comprensibilità è una qualità interna del prodotto che aiuta a raggiungere molte delle altre qualità, quali l’evolvibilità e la verificabilità. Da un punto di vista esterno, l’utente considera un sistema comprensibile se ha un comportamento prevedibile. La comprensibilità esterna è un fattore importante che contribuisce all’usabilità del prodotto.<br />Interoperabilità<br />L’interoperabilità si riferisce alla capacità di un sistema di coesistere e cooperare con altri sistemi come, ad esempio, la capacità di un sistema di elaborazione testi di incorporare un diagramma prodotto da un pacchetto grafico e la capacità del pacchetto grafico di rappresentare dati prodotti da un foglio elettronico, oppure la capacità del foglio elettronico di elaborare un’immagine acquisita da uno scanner.<br />L’interoperabilità è molto diffusa negli altri prodotti ingegneristici. Al contrario, i primi sistemi operativi dovettero essere modificati, talvolta in maniera molto significativa, prima che potessero essere utilizzati con nuovi tipi di dispositivi. La generazione di sistemi operativi cosiddetti plug-and-play tenta di risolvere questo problema individuando e interfacciandosi automaticamente con i nuovi dispositivi. L’ambiente UNIX, con le sue interfacce standard, offre un primo esempio di interoperabilità all’interno dello stesso ambiente.<br />Mediante l’interoperabilità, un produttore può sviluppare diversi prodotti e far sì che l’utente, se necessario, possa combinarli liberamente, scegliendo, di volta in volta, quali funzioni acquistare.<br />Un concetto correlato con l’interoperabilità è quello di sistema aperto, vale a dire una collezione estendibile di applicazioni scritte in modo indipendente tra di loro, ma che funzionano come un sistema integrato. Un importante requisito dei sistemi aperti è che possono essere aggiunte nuove funzionalità senza dover necessariamente fermare l’esecuzione del sistema.<br />Produttività<br />La produttività è una qualità del processo di produzione del software: ne indica l’efficienza e le prestazioni. Un processo efficiente dà luogo a una consegna più rapida del prodotto finale. Ciascun ingegnere produce software alla propria velocità, anche se ci sono molte variazioni tra individui con diverse capacità di programmazione. Quando gli individui sono parte del gruppo, la produttività del gruppo è una funzione della produttività degli individui. Il management del progetto cerca di organizzare i gruppi di lavoro e di adottare processi di sviluppo in modo tale da sfruttare al massimo la produttività individuale di ciascun membro.<br />La produttività del personale tecnico influenza la scelta del processo, e viceversa. Il riuso del software è una tecnica che migliora la produttività complessiva di un’organizzazione per un insieme di prodotti, ma il costo di sviluppo dei moduli riutilizzabili può essere ammortizzato solo attraverso lo sviluppo di più prodotti. La produttività del software è una caratteristica difficile da misurare, anche se riveste un grande interesse pratico, a causa dei costi crescenti dello sviluppo.<br />Tempestività<br />La tempestività è una qualità del processo che indica la capacità di rendere disponibile un prodotto al momento giusto. Al giorno d’oggi, soprattutto a causa dei mercati sempre più competitivi, i progetti software affrontano sfide ancora più stringenti in termini di tempo di sviluppo dei prodotti.<br />Di per sé la tempestività non è sempre una qualità utile, anche se talvolta arrivare in ritardo alla consegna di un prodotto può precludere interessanti opportunità di mercato. Non ha molto senso consegnare alla data prevista un prodotto privo di altre qualità, quali l’affidabilità e le prestazioni. Tuttavia alcuni sostengono che la consegna tempestiva di una versione preliminare di un prodotto, ancorché instabile, favorisca la successiva accettazione della versione finale.<br />La tempestività richiede un’attenta pianificazione temporale del processo, un’accurata stima delle attività e una specifica chiara degli obiettivi intermedi (milestone). Tutte le discipline ingegneristiche usano tecniche di gestione del progetto che favoriscono la tempestività. Esistono addirittura molti strumenti di gestione dei progetti, supportati dal computer, che facilitano queste attività. Un’altra difficoltà nel raggiungimento della tempestività nel processo software è costituita dalla continua evoluzione dei requisiti dell’utente. <br />Una tecnica per ottenere la tempestività è attraverso la consegna incrementale del prodotto (incremental delivery). Ovviamente, la possibilità di consegna incrementale dipende dalla capacità di spezzare l’insieme delle funzionalità richiede in sottoinsiemi che possono essere sviluppate successivamente. Tuttavia, un processo non incrementale impedisce la produzione di sottoinsiemi, anche se questi sottoinsiemi sono identificabili. Pertanto, è la combinazione di un prodotto che può essere spezzato in sottoinsiemi e di un processo incrementale che ci consente uno sviluppo tempestivo.<br />Visibilità<br />Un processo di sviluppo del software è visibile se tutti i passi successivi (step) e lo stato attuale sono documentati in modo chiaro. Un altro termine utilizzato per caratterizzare questa proprietà è trasparenza. L’idea è che i passi e lo stato del processo siano disponibili e facilmente accessibili per un esame esterno.<br />In molti progetti software, gli ingegneri e i manager non hanno una completa consapevolezza di quale sia, in ogni istante, lo stato del progetto. Alcuni ingegneri potrebbero essere nella fase di progetto, altri nella fase di codifica e altri ancora nella fase di testing. Ciò di per sé non genera inconvenienti; tuttavia se un ingegnere inizia la riprogettazione di una parte del codice immediatamente prima che venga da altri iniziato il test di integrazione, i rischi che possano sorgere problemi seri e che ciò possa causare forti ritardi sono ovviamente molto alti.<br />La visibilità consente agli ingegneri di soppesare l’impatto sul progetto complessivo delle proprie azioni e pertanto di guidarli nelle loro decisioni. Essa consente a tutti i membri di un gruppo di lavorare nella stessa direzione, piuttosto che, come spesso accade, in direzioni contrastanti.<br />La visibilità non è solo una qualità interna, ma anche esterna. Nello sviluppo di un progetto di luna durata sorgono spesso richieste relative allo stato corrente del progetto. Talvolta richieste giungono dal management interno all’organizzazione, al fine di un’ulteriore pianificazione del progetto.<br />Una delle maggiori difficoltà che si incontrano nella gestione di grossi progetti deriva dal ricambio di personale (turnover). In molti progetti software alcune informazioni critiche, relative ai requisiti del software o alle attività di progettazione, sono tramandate oralmente e sono note soltanto alle persone che hanno lavorato nel progetto fin dall’inizio, o dall’aggiunta di nuovi ingegneri al progetto, può generare grosse difficoltà. Infatti l’inserimento di nuove persone spesso riduce la produttività dell’intero progetto, dal momento che l’informazione tramandata oralmente viene trasferita lentamente alle nuove persone inserite nel gruppo di lavoro.<br />Requisiti di qualità in diverse aree applicative.<br />Le qualità descritte nei sono generiche, nel senso che si applicano a un qualunque sistema software. Il software viene però costruito al fine di automatizzare una specifica applicazione e quindi può essere caratterizzato sulla base dei requisiti dell’area applicativa.<br />Sistemi informativi<br />I sistemi informativi costituiscono una delle aree applicative più importanti dell’informatica; sono così chiamati in quanto il loro scopo primario è quello di gestire informazioni. I sistemi informativi hanno acquisito una grande importanza, in quanto l’informazione è diventata una risorsa sempre più preziosa. I dati gestiti da questi sistemi costituiscono spesso le risorse più significative di un’organizzazione. I dati riguardano sia i processi e le risorse interne all’impresa sia informazioni sul mondo esterno. I sistemi informativi sono applicazioni orientate alla gestione dei dati e possono essere caratterizzati in base al modo in cui i dati vengono elaborati. Alcune delle qualità che caratterizzano i sistemi informativi sono: integrità dei dati, sicurezza, disponibilità dei dati, prestazioni delle transazioni. I moderni sistemi informativi vanno in questa direzione: non solo supportano un facile accesso da parte degli utenti, ma addirittura ne incoraggiano il coinvolgimento nella creazione di alcune funzioni applicative.<br />Sistemi in tempo reale<br />I sistemi in tempo reale (real-time system) costituiscono un’altra importante categoria di sistemi software. La loro caratteristica principale è che debbono rispondere a determinati eventi entro un periodo di tempo predefinito e spesso molto limitato. I sistemi in tempo reale in genere si associano ai sistemi di automazione di fabbrica, ai sistemi di sorveglianza, etc. Tuttavia, i requisiti di risposta in tempo reale possono essere trovati anche in molte altre situazioni tradizionali. Un interessante esempio è dato dal software di gestione del mouse che si trova in ogni computer, il quale deve rispondere ai segnali di pressione del mouse (clic) entro un certo periodo di tempo. Mentre possiamo definire “orientati ai dati” i sistemi informativi, i sistemi in tempo reale si possono definire “orientati al controllo”.<br />Sistemi distribuiti<br />I progressi nell’ambito dell’hardware e delle tecnologie di rete hanno reso possibile costruire sistemi distribuiti, che consistono di macchine indipendenti o semi-indipendenti collegate da una rete di telecomunicazioni. Le reti a banda larga rendono possibile lo sviluppo di applicazioni distribuite in cui i diversi componenti sono eseguiti da computer diversi. Oltre alle qualità generiche del software descritte in precedenza, il software distribuito ne possiede altre peculiari. Ad esempio, l’ambiente di sviluppo deve supportare lo sviluppo dell’applicazione su una molteplicità di computer, sui quali gli utenti devono essere in grado di compilare, collegare e testare il codice.<br />La possibilità di caricare ed eseguire componenti su macchine diverse ha favorito lo sviluppo di nuovi linguaggi quali Java e C#. Java definisce un linguaggio intermedio (bytecode) che può essere interpretato in maniera efficiente su ogni computer del sistema distribuito. Uno degli aspetti interessanti dei sistemi distribuiti è che offrono nuove opportunità per il raggiungimento di alcune delle qualità analizzate in precedenza. Un’altra possibilità interessante consiste nello sfruttamento della tecnologia di mobilità del codice, vale a dire la possibilità che il codice migri sulla rete durante l’esecuzione. Il codice mobile ha un vantaggio, rispetto ai tradizionali sistemi client-server, che le connessioni di rete non sono necessarie in modo permanente per supportare le interazioni tra il client e il server. Ci possono inoltre essere vantaggi dal punto di vista delle prestazioni, se si trasferisce il codice al nodo che memorizza i dati sui quali il codice deve operare. Le applet Java sono un semplice esempio di codice mobile.<br />Sistemi embedded<br />I sistemi embedded sono sistemi nei quali il software è solo uno dei componenti e spesso non ha interfacce rivolte all’utente finale, ma verso altri componenti del sistema che esso controlla. Il software embedded viene usato in aerei, robot, elettrodomestici, automobili, cellulari, etc.<br />Ciò che distingue un sistema embedded rispetto agli altri tipi di software è proprio la mancanza di dispositivi di interfaccia rivolti a operatori umani, combinata con la presenza di interfacce verso altri tipi di dispositivi.<br />