| << |  <  |  >  | >> |

Indice

Introduzione                                              XV

PARTE PRIMA. IL PRODOTTO E IL PROCESSO                     1


Capitolo 1  Il prodotto                                    3

1.1 L'evoluzione del ruolo del software                    5
1.2 Il software                                            6
1.3 Il software: una crisi all'orizzonte?                 11
1.4 I miti del software                                   12
1.5 Riepilogo                                             15

Capitolo 2  Il processo                                   19

2.1 L'ingegneria del software: una tecnologia stratificata20
2.2 Il processo software                                  24
2.3 Modelli di processo                                   27
2.4 Il modello sequenziale lineare                        30
2.5 La prototipazione                                     32
2.6 Il modello RAD                                        34
2.7 Modelli evolutivi del processo software               35
2.8 Sviluppo a componenti                                 44
2.9 Il modello dei metodi formali                         46
2.10 Tecniche di quarta generazione                       46
2.11 Tecnologia di processo                               48
2.12 Prodotto e processo                                  48
2.13 Riepilogo                                            50

PARTE SECONDA. GESTIONE DEI PROGETTI SOFTWARE             55


Capitolo 3  La gestione dei progetti                      57

3.1 Il panorama gestionale                                58
3.2 Le persone                                            60
3.3 Il prodotto                                           68
3.4 Il processo                                           70
3.5 Il progetto                                           74
3.6 Il principio W5HH                                     75
3.7 Pratiche critiche                                     76
3.8 Riepilogo                                             77

Capitolo 4  Metriche di processo e di progetto            81

4.1 Misure, metriche e indicatori                         83
4.2 Le metriche di processo e di progetto                 84
4.3 Misurazione del software                              90
4.4 Combinazione di metriche diverse                      96
4.5 Metriche per la qualità del software                  98
4.6 Integrazione delle metriche nel processo software    101
4.7 Gestione delle variazioni: controllo del processo
    statistico                                           103
4.8 Valutazioni metriche per piccole aziende             107
4.9 Definizione di un programma di valutazione metrica
    del software                                         109
4.10 Riepilogo                                           111

Capitolo 5  Pianificazione del progetto software         117

5.1 Osservazioni sul fare stime                          118
5.2 Obiettivi della pianificazione di progetto           120
5.3 La portata del software                              120
5.4 Le risorse                                           125
5.5 Stime nei progetti software                          128
5.6 Tecniche di scomposizione                            129
5.7 Modelli empirici di stima                            137
5.8 La scelta tra sviluppo e acquisto                    141
5.9 Strumenti automatici di stima                        145
5.10 Riepilogo                                           145

Capitolo 6  Analisi e gestione dei rischi                149

6.1 Strategie reattive e preventive                      150
6.2 I rischi del software                                151
6.3 Individuazione dei rischi                            152
6.4 Proiezione dei rischi                                154
6.5 Raffinamento dei rischi                              160
6.6 Riduzione, sorveglianza e governo dei rischi         161
6.7 Sicurezza e pericoli                                 162
6.8 Il piano RMMM                                        163
6.9 Riepilogo                                            163

Capitolo 7  Pianificazione temporale e controllo dei

            progetti                                     169
7.1 Concetti fondamentali                                171
7.2 Relazione fra personale e lavoro                     174
7.3 Definizione dei compiti di un progetto software      177
7.4 Scelta dei compiti                                   181
7.5 Raffinamento dei compiti principali                  183
7.6 Definizione di un reticolo di compiti                185
7.7 Pianificazione temporale                             186
7.8 Analisi del valore acquisito                         191
7.9 Controllo degli errori                               193
7.10 Il piano di progetto                                194
7.11 Riepilogo                                           195

Capitolo 8  Garanzia di qualità del software             199

8.1 La qualità: concetti di base                         201
8.2 Il movimento per la qualità                          205
8.3 La garanzia di qualità del software                  206
8.4 Le revisioni del software                            209
8.5 Revisioni tecniche formali                           211
8.6 Strategie formali di SQA                             216
8.7 Garanzia di qualità su base statistica               216
8.8 Affidabilità del software                            219
8.9 Verifica degli errori nel software                   222
8.10 Gli standard ISO 9000 per la qualità                224
8.11 Il piano SQA                                        226
8.12 Riepilogo                                           227

Capitolo 9  Gestione delle configurazioni software       233

9.1 Gestione delle configurazioni software               234
9.2 Il processo di gestione delle configurazioni         238
9.3 Individuazione degli oggetti nella configurazione    238
9.4 Controllo delle versioni                             241
9.5 Controllo del cambiamento                            242
9.6 Esami della configurazione                           247
9.7 Relazioni sulla situazione                           247
9.8 Standard di gestione delle configurazioni            248
9.9 Riepilogo                                            248

PARTE TERZA. METODI TRADIZIONALI PER
             L'INGEGNERIA DEL SOFTWARE                   253


Capitolo 10  Ingegneria dei sistemi informatici          255

10.1 Sistemi informatici                                 257
10.2 La gerarchia dei sistemi                            258
10.3 Ingegnerizzazione dei processi di lavoro:
     una panoramica                                      262
10.4 Ingegneria del prodotto: panoramica                 264
10.5 Ingegneria dei requisiti                            267
10.6 Modellazione di sistema                             272
10.7 Riepilogo                                           276

Capitolo 11  Analisi: concetti e principi                283

11.1 Analisi dei requisiti                               284
11.2 Individuazione dei requisiti per il software        286
11.3 Principi di analisi                                 295
11.4 Prototipazione                                      301
11.5 Specifica                                           303
11.6 Revisione della specifica                           306
11.7 Riepilogo                                           306

Capitolo 12  Modellazione concettuale                    311

12.1 Breve storia                                        313
12.2 Gli elementi del modello concettuale                313
12.3 Modellazione dei dati                               314
12.4 Modellazione funzionale e flusso delle informazioni 320
12.5 Modellazione del comportamento                      331
12.6 Meccanica dell'analisi strutturata                  332
12.7 Il dizionario dei dati                              343
12.8 Altri metodi di analisi                             345
12.9 Riepilogo                                           346

Capitolo 13  Concetti e principi di progettazione        351

13.1 La progettazione del software e l'ingegneria del
     software                                            352
13.2 Il processo di progettazione                        354
13.3 Principi di progettazione                           356
13.4 Concetti di progettazione                           357
13.5 Progettazione "effettivamente modulare"             369
13.6 Indicazioni progettuali per la modularità           372
13.7 Il modello progettuale                              374
13.8 Documentazione del progetto                         375
13.9 Riepilogo                                           376

Capitolo 14  La progettazione dell'architettura          381

14.1 L'architettura del software                         382
14.2 Progettazione dei dati                              384
14.3 Stili dell'architettura                             387
14.4 Analisi di progetti di architettura alternativi     392
14.5 Mappaggio dei requisiti in un'architettura software 395
14.6 Traduzione delle trasformazioni                     397
14.7 Traduzione delle transazioni                        407
14.8 Raffinamento del progetto dell'architettura         411
14.9 Riepilogo                                           414

Capitolo 15  Progettazione dell'interlaccia utente       419

15.1 Le regole d'oro                                     420
15.2 Progettazione dell'interfaccia utente               424
15.3 Analisi e modellazione delle operazioni             427
15.4 Attività di progettazione dell'interfaccia          429
15.5 Strumenti di implementazione                        434
15.6 Valutazione del progetto                            435
15.7 Riepilogo                                           437

Capitolo 16  La progettazione a livello dei componenti   441

16.1 La programmazione strutturata                       442
16.2 Confronto fra le notazioni di progettazione         451
16.3 Riepilogo                                           452

Capitolo 17  Tecniche di collaudo del software           455

17.1 Principi fondamentali                               456
17.2 Preparazione dei casi di prova                      461
17.3 Collaudo white-box                                  463
17.4 Collaudo per cammini di base                        463
17.5 Collaudo della struttura di controllo               472
17.6 Collaudo black-box                                  478
17.7 Collaudo di ambienti e applicazioni speciali        487
17.8 Riepilogo                                           491

Capitolo 18  Strategie di collaudo del software          495

18.1 Un approccio strategico al collaudo del software    496
18.2 Questioni strategiche                               502
18.3 Collaudo delle unità                                504
18.4 Collaudo di integrazione                            506
18.5 Prove di validazione                                514
18.6 Collaudo di sistema                                 516
18.7 L'arte del debugging                                518
18.8 Riepilogo                                           522

Capitolo 19  Metriche tecniche per il software           527

19.1 La qualità del software                             529
19.2 Un quadro di riferimento per le metriche tecniche
     del software                                        534
19.3 Metriche per il modello concettuale                 538
19.4 Metriche per il modello progettuale                 543
19.5 Metriche per il codice sorgente                     551
19.6 Metriche per il collaudo                            552
19.7 Metriche per la manutenzione                        553
19.8 Riepilogo                                           553

PARTE QUARTA. INGEGNERIA DEL SOFTWARE
              ORIENTATA AGLI OGGETTI                     559


Capitolo 20  Concetti e principi orientati agli oggetti  561

20.1 Il paradigma orientato agli oggetti                 562
20.2 Concetti orientati agli oggetti                     564
20.3 Individuazione degli elementi di un modello
     a oggetti                                           574
20.4 Gestione di progetti per software orientato agli
     oggetti                                             581
20.5 Riepilogo                                           587

Capitolo 21  Analisi orientata agli oggetti              591

21.1 Analisi orientata agli oggetti                      593
21.2 Analisi di dominio                                  597
21.3 Componenti generici del modello concettuale OO      600
21.4 Il processo di analisi OO                           601
21.5 Il modello oggetti-relazioni                        611
21.6 Il modello oggetti-comportamenti                    613
21.7 Riepilogo                                           619

Capitolo 22  Progettazione orientata agli oggetti        623

22.1 Progettazione di sistemi orientati agli oggetti     625
22.2 Il processo di progettazione di sistema             631
22.3 La progettazione degli oggetti                      638
22.4 Schemi progettuali (design pattern)                 644
22.5 Programmazione orientata agli oggetti               646
22.6 Riepilogo                                           647

Capitolo 23  Collaudo di sistemi orientati agli oggetti  653

23.1 Allargare la prospettiva                            654
23.2 Collaudo dei modelli concettuale e progettuale      656
23.3 Strategie di collaudo di sistemi orientati
     agli oggetti                                        658
23.4 Progettazione dei casi di prova per il software
     orientato agli oggetti                              660
23.5 Metodi di prova applicabili al livello delle classi 666
23.6 Progettazione di casi di prova interclasse          668
23.7 Riepilogo                                           671

Capitolo 24  Metriche tecniche per i sistemi orientati

             agli oggetti                                675
24.1 Scopi delle metriche orientate agli oggetti         676
24.2 La caratteristica distintiva delle metriche
     orientate agli oggetti                              677
24.3 Metriche per il modello progettuale orientato
     agli oggetti                                        679
24.4 Metriche orientate alle classi                      681
24.5 Metriche orientate alle operazioni                  687
24.6 Metriche per il collaudo orientato agli oggetti     687
24.7 Metriche per progetti orientati agli oggetti        688
24.8 Riepilogo                                           689

PARTE QUINTA. ARGOMENTI AVANZATI
              DI INGEGNERIA DEL SOFTWARE                 693


Capitolo 25  I metodi formali                            695

25.1 Concetti fondamentali                               696
25.2 Preliminari matematici                              704
25.3 Applicazione della notazione matematica alla
     specifica formale                                   710
25.4 Linguaggi di specifica formali                      712
25.5 L'uso di Z per rappresentare un componente software:
     un esempio                                          713
25.6 I dieci comandamenti dei metodi formali             715
25.7 Il futuro dei metodi formali                        716
25.8 Riepilogo                                           717

Capitolo 26  Ingegneria del software "in camera sterile" 721

26.1 La soluzione a camera sterile                       722
26.2 La specifica funzionale                             726
26.3 Progettazione in camera sterile                     730
26.4 Collaudo in camera sterile                          735
26.5 Riepilogo                                           738

Capitolo 27  L'ingegneria del software a componenti      743

27.1 Ingegnerizzazione di sistemi a componenti           745
27.2 Il processo di ingegneria del software a componenti 747
27.3 Ingegnerizzazione del dominio                       747
27.4 Sviluppo a componenti                               752
27.5 Classificazione e ricerca dei componenti            758
27.6 Aspetti economici dell'ingegneria del software
     a componenti                                        762
27.7 Riepilogo                                           765

Capitolo 28  Ingegneria del software per sistemi

             client/server                               769
28.1 La struttura dei sistemi c1ient/server              770
28.2 Ingegneria del software per sistemi c1ient/server   777
28.3 Questioni di modellazione concettuale               777
28.4 Progettazione di sistemi c1ient/server              778
28.5 Aspetti relativi al collaudo                        783
28.6 Riepilogo                                           786

Capitolo 29  Ingegneria del Web                          791

29.1 Gli attributi delle applicazioni basate sul Web     793
29.2 Il processo di ingegneria del Web                   797
29.3 Una struttura di base per l'ingegneria del Web      797
29.4 Formulazione e analisi di sistemi basati sul Web    799
29.5 Progettazione di applicazioni Web                   801
29.6 Collaudo delle applicazioni Web                     809
29.7 Problemi gestionali                                 810
29.8 Riepilogo                                           817

Capitolo 30  Reingegnerizzazione                         823

30.1 Reingegnerizzazione del processo aziendale          825
30.2 Reingegnerizzazione del software                    828
30.3 Reverse engineering                                 833
30.4 Ristrutturazione                                    837
30.5 Forward engineering                                 839
30.6 Aspetti economici del reverse engineering           843
30.7 Riepilogo                                           844

Capitolo 31  CASE                                        849

31.1 Che cos'è il CASE?                                  850
31.2 I mattoni del CASE                                  850
31.3 Una tassonomia degli strumenti CASE                 853
31.4 Ambienti CASE integrati                             858
31.5 L'architettura di integrazione                      859
31.6 Il repository CASE                                  861
31.7 Riepilogo                                           865

Capitolo 32  Il futuro                                   869

32.1 L'importanza del software: un nuovo punto di vista  870
32.2 La portata del mutamento                            871
32.3 Le persone e la costruzione di sistemi              871
32.4 Il "nuovo" processo di ingegneria del software      873
32.5 Nuovi modi di rappresentare l'informazione          874
32.6 La tecnologia come guida                            875
32.7 Commento conclusivo                                 876

Indice analitico                                         878
 

| << |  <  |  >  | >> |

Pagina XV

Nei venti anni trascorsi dalla prima edizione di questo volume, l'ingegneria del software si è evoluta trasformandosi da una vaga idea praticata da un numero relativamente ridotto di adepti per diventare una legittima disciplina dell'ingegneria. Oggi ha acquisito legittimità come disciplina degna di un serio impegno di ricerca, uno studio coscienzioso e un acceso dibattito. Nell'attività professionale il titolo di ingegnere del software ha sostituito il termine programmatore. I modelli di processo software, i metodi di ingegneria del software e gli strumenti di sviluppo sono stati adottati con successo in un ampia gamma di applicazioni.

Manager e professionisti riconoscono che esiste l'esigenza di un approccio più disciplinato al software ma continuano a scontrarsi sul modo in cui deve essere applicata questa disciplina. Molte persone e molte aziende continuano a sviluppare software senza criterio, anche quando devono realizzare sistemi di supporto per le tecnologie più avanzate oggi disponibili. Molti studenti e professionisti non conoscono neppure i metodi di progettazione più moderni. A risentirne è proprio la qualità del software. Inoltre, continua l'acceso e controverso dibattito sulla vera natura dell'ingegneria del software; lo studio prosegue tra i contrasti. Sono cambiate le attitudini, sono stati compiuti dei progressi, ma rimane parecchio da fare perché questa disciplina raggiunga una piena maturità.

La terza edizione di Principi di ingegneria del software (la quinta edizione americana) vuole rappresentare una guida per una disciplina ancora in fase di maturazione. Come le edizioni precedenti, anche questa si rivolge sia agli studenti che ai professionisti, mantenendo la propria validità come guida per i professionisti e come ampia introduzione per gli studenti degli ultimi anni universitari o dei primi anni dopo la laurea.

| << |  <  |  >  | >> |

Pagina 12

La malattia del software si può in gran parte far risalire a una mitologia nata agli inizi dell'informatica. Diversamente dai miti antichi, che spesso elargiscono lezioni degne di attenzione, i miti del software hanno diffuso disinformazione e confusione. Alcune loro caratteristiche li rendono insidiosi: in genere hanno la forma di affermazioni ragionevoli (talvolta non prive di elementi di verità), sono intuitivamente condivisibili e sono spesso stati diffusi da esperti del settore.

Oggi i professionisti riconoscono per lo più che quei miti non sono altro che atteggiamenti fuorvianti, che hanno provocato seri problemi a dirigenti e tecnici nella stessa misura. Con tutto ciò, sradicare abitudini e convinzioni è difficile e ancora oggi molti credono ad alcuni di quei miti.

Miti del management I manager con responsabilità legate al software, come in tutti gli altri campi, sono spesso sotto pressione per il budget, le scadenze e la qualità. Come un naufrago che si aggrappa a un fuscello, il manager software si aggrappa spesso ai miti che alleggeriscono la pressione, almeno temporaneamente.

"In assenza di standard significativo, una nuova industria come quella del software comincia a dipendere dal folclore." Tom De Marco

Mito Abbiamo già interi volumi di standard e procedure da seguire nello sviluppo. Non c'è forse tutto l'indispensabile?

Realtà Gli standard possono esistere, ma sono applicati? I programmatori li conoscono? Quegli standard riflettono i metodi moderni di sviluppo del software? Sono completi? È stato ottimizzato in modo da migliorare i tempi di consegna pur mantenendo l'attenzione sulla qualità? In molti casi reali, la risposta a tutte queste domande è "No".

Mito Abbiamo i più moderni strumenti di sviluppo. Dopo tutto, acquistiamo sempre i computer più recenti.

Realtà Lo sviluppo di software di alta qualità richiede ben più dell'ultimo modello di mainframe, workstation o personal computer. Gli strumenti di CASE (ingegneria del software assistita dal computer) sono più importanti dell'hardware per ottenere alta qualità e produttività; tuttavia, la più parte degli sviluppatori non se ne serve realmente.

Mito Se siamo in ritardo, possiamo sempre recuperare aumentando il numero di programmatori (concetto dell'orda mongola).

Realtà Lo sviluppo di software non è un processo meccanico come la produzione manifatturiera. Per citare Brooks (1975), "aggiungere persone a un progetto software in ritardo lo rallenta ulteriormente". A prima vista, questa affermazione può suonare controintuitiva, ma si deve considerare che i nuovi arrivati devono essere addestrati da chi lavorava già al progetto, togliendo così risorse allo sviluppo effettivo. È possibile inserire nuovo personale in un progetto, ma solo in modo pianificato e coordinato.

RIFERIMENTO La Software Project Managers Network all'indirizzo www.spmn.com aiuterà a sfatare questi ed altri miti.

Mito Se decido di far realizzare un progetto software a una terza parte, posso restare tranquillo perché tutto il lavoro verrà svolto esternamente.

Realtà Se un'organizzazione non sa come gestire e controllare internamente i progetti software, inevitabilmente incontrerà problemi se deciderà di fornire all'esterno lo sviluppo.

Miti della clientela Il cliente che chiede un prodotto software può essere il collega della stanza accanto, un reparto dell'azienda, il settore vendite o un'azienda esterna che lo ha commissionato. Spesso il cliente crede ai miti sul software perché manager e tecnici del settore fanno ben poco per eliminare la disinformazione. I miti generano nella clientela aspettative falsate e, di conseguenza, insoddisfazione nei confronti degli sviluppatori.

NOTA Si deve lavorare duramente per comprendere ciò che si deve fare prima di iniziare. Si può non essere in grado di individuare tutti i dettagli, ma più se ne sa e meno rischi si corrono.

Mito Un'affermazione generica degli scopi è sufficiente per cominciare a scrivere i programmi; i dettagli si possono trattare in seguito.

Realtà Una insufficiente descrizione preliminare è la causa principale di fallimento di un progetto software. La descrizione formale e dettagliata del dominio dei dati, delle funzioni, delle prestazioni, dell'interfaccia, dei vincoli progettuali e dei criteri di validazione è essenziale. Tutti questi aspetti si possono stabilire solo dopo una approfondita comunicazione fra cliente e sviluppatore.

Mito I requisiti di un progetto mutano di continuo, ma i mutamenti si gestiscono agevolmente grazie alla flessibilità del software.

Realtà È vero che i requisiti cambiano, ma l'effetto delle modifiche varia secondo la fase in cui vengono introdotte, come è illustrato nella Figura 1.3. Se si dedica particolare attenzione alla definizione preliminare, le richieste di modifiche nelle prime fasi si soddisfano facilmente: il cliente ha modo di esaminare i requisiti e di richiedere modifiche, senza effetti pesanti sui costi. L'effetto di modifiche richieste durante la fase di progettazione cresce rapidamente. Le risorse sono state già allocate e si è stabilita la cornice del progetto. Una modifica può comportare rivolgimenti che richiedono nuove risorse e correzioni importanti al progetto, cioè costi supplementari. Le modifiche alla funzionalità, alle prestazioni, all'interfaccia o ad altre caratteristiche durante l'implementazione (stesura del codice e collaudo) hanno un effetto pesante sui costi. Le modifiche richieste dopo l'entrata in esercizio del software possono rivelarsi più costose di un ordine di grandezza rispetto alle stesse modifiche richieste nelle fasi precedenti.

RIFERIMENTO La gestione e il controllo dei cambiamenti sono considerati in dettaglio nel Capitolo 9.

Miti del programmatore I miti ancora popolari fra i programmatori sono stati alimentati in 50 anni di cultura della programmazione. In origine la programmazione era considerata un'attività artigianale: le abitudini e le credenze sono dure a morire.

Mito Una volta scritto e messo in opera il programma, il nostro lavoro è finito.

Realtà È stato detto: "Prima cominci a stendere il codice, più tempo impiegherai a terminare il programma". Alcuni dati relativi all'industria (Lientz, 1980, Jones, 1991 e Putman, 1997) indicano che tra il 60 e l'80% del lavoro speso su un programma avviene dopo la consegna della prima versione al cliente.

Mito Fino a quando il programma non è in condizione di essere eseguito, non c'è modo di valutarne la qualità.

Realtà Uno dei metodi più efficaci di esame della qualità del software, la revisione tecnica formale, si applica già dall'inizio di un progetto. Le revisioni, descritte nel Capitolo 8, sono un "filtro della qualità", rivelatosi più efficace del collaudo nel rilevare alcuni tipi di errori del software.

Mito Il solo prodotto di un progetto concluso è il programma funzionante.

Realtà Un programma funzionante è solo una parte di una configurazione software che comprende più elementi. La documentazione è il fondamento di uno sviluppo riuscito e, cosa più importante, è la guida dell'attività di manutenzione.

Mito L'ingegneria del software ci farà scrivere un'inutile e voluminosa documentazione che inevitabilmente rallenterà le cose.

Realtà L'ingegneria del software non prevede la creazione di documenti. Si occupa di creare qualità. Una migliore qualità porta a minor lavoro. E un minor lavoro porta a tempi di consegna più rapidi.

| << |  <  |  >  | >> |

Pagina 871

I progressi nell'informatica, negli ultimi cinquant'anni, sono stati sospinti dai progressi nelle scienze "materiali": fisica, chimica, scienza dei materiali e ingegneria. Nel prossimo futuro, progressi significativi in campo informatico potrebbero arrivare anche dalle scienze "umane": psicologia, neurofisiologia, sociologia, filosofia e altre. È molto difficile prevedere quale sia il periodo di gestazione per le innovazioni di questa origine.

"La miglior cosa che si può dire del futuro è il fatto che arriva un giorno alla volta." Abraham Lincoln

L'influenza delle scienze umane può contribuire a indirizzare la ricerca orientata all'informatica nelle scienze materiali. Ad esempio, la progettazione dei computer futuri potrebbe risultare guidata più dalle concezioni sulla fisiologia del cervello che dalle conoscenze di microelettronica.

I cambiamenti destinati a incidere sull'ingegneria del software nel prossimo decennio proverranno da quattro direzioni: (1) le persone che svolgono il proprio lavoro; (2) il processo che esse adottano; (3) la natura delle informazioni; (4) la tecnologia sottostante. Nei prossimi paragrafi si esaminano in dettaglio questi elementi: persone, processo, informazioni e tecnologia.

| << |  <  |  >  | >> |

Pagina 871

Il software per i sistemi ad alta tecnologia diventa sempre più complesso e la dimensione dei programmi cresce in proporzione. La rapida crescita delle dimensioni del programma "medio" presenterebbe pochi problemi se non fosse per un fatto: quando aumentano le dimensioni di un programma, aumenta anche il numero di persone che devono realizzarlo. L'esperienza suggerisce che, al crescere delle dimensioni di un team, la produttività totale soffre. Una possibile soluzione consiste nel formare diversi team (Capitolo 3), suddividendo le persone in piccoli gruppi di lavoro. Sorge così un nuovo problema: se aumenta il numero dei team, la comunicazione fra di essi si fa complessa e laboriosa quanto la comunicazione fra gli individui. Non solo: la comunicazione (fra individui o fra team) tende a diventare inefficiente: si spende troppo tempo per trasferire un contenuto informativo relativamente modesto, mentre spesso le informazioni significative si perdono per strada.

Se si vuole affrontare seriamente questo dilemma comunicativo, nell'ambito dell'ingegneria del software, occorre ripensare alla radice i modi di comunicazione fra singoli e fra gruppi.

| << |  <  |  >  | >> |

Pagina 873

Si possono ragionevolmente caratterizzare i primi vent'anni dell'ingegneria del software come l'era del "pensiero lineare". Sospinta dal modello classico del ciclo di vita, l'ingegneria del software veniva affrontata come attività lineare, nella quale una serie sequenziale di passi si svolge al fine di risolvere un problema complesso. Tuttavia, le soluzioni lineari allo sviluppo di software sono opposte al modo in cui si costruisce effettivamente la maggior parte dei sistemi. Nella realtà, i sistemi complessi si evolvono iterativamente e in modo incrementale. Per questo motivo, un largo settore della comunità dell'ingegneria del software si sta spostando verso modelli evolutivi dello sviluppo di software.

I modelli evolutivi di processo riconoscono il ruolo dell'incertezza, preponderante nella maggior parte dei progetti; riconoscono che le scadenze sono spesso impossibili da rispettare e che in questi casi l'iterazione permette di consegnare versioni progressivamente più complete del prodotto. I modelli evolutivi pongono l'accento sulla necessità di una progressione nei lavorati, dell'analisi dei rischi, della pianificazione e della revisione dei piani, della reazione del cliente.

| << |  <  |  >  | >> |

Pagina 874

Negli ultimi vent'anni è avvenuta una sottile transizione nella terminologia con la quale si descrive lo sviluppo di software per il mondo degli affari. Vent'anni fa, per descrivere l'uso dei computer in ambito aziendale, il termine preferito era "elaborazione di dati". Oggi il suo posto è stato preso da un'altra espressione: "tecnologia dell'informazione", che indica la stessa cosa, ma con un lieve spostamento d'accento. L'enfasi non è più solo sul trattamento di grandi quantità di dati, ma piuttosto sull'estrazione di informazioni utili da quei dati. Ovviamente, questo è sempre stato l'obiettivo, ma il mutamento della terminologia riflette un mutamento ben più importante, di ordine "gestionale".

In ogni discussione sulle applicazioni del software, le parole "dati" e "informazioni" compaiono ripetutamente. La parola "conoscenza" si affaccia nelle applicazioni dell'intelligenza artificiale, ma è di impiego relativamente raro. Quasi nessuno si occupa della "saggezza" nell'ambito dell'informatica.

I dati sono informazioni allo stato grezzo: una collezione di fatti che dobbiamo elaborare per dar loro un senso. L'informazione nasce dall'associare più fatti in un dato contesto. La conoscenza consiste nell'associare l'informazione ricavata in un contesto con quella ricavata in un contesto diverso. La saggezza, infine, consiste nel ricavare principi generali da conoscenze disparate. Questi quattro punti di vista sulla "informazione" sono schematizzati nella Figura 32.1.

"La saggezza è quella dote che ci consente di utilizzare la conoscenza a vantaggio di noi stessi e degli altri." Thomas J. Watson

Oggi, la grande maggioranza del software è destinata a elaborare dati o informazioni. Gli ingegneri del software del ventunesimo secolo dovranno occuparsi di sistemi che elaborano la conoscenza. La conoscenza è bidimensionale; le informazioni raccolte su vari argomenti, correlati o no, vengono collegate a formare un corpus di fatti, chiamato conoscenza. Il nocciolo della questione sta nella capacità di trovare connessioni non sempre evidenti fra informazioni provenienti da fonti diverse e nel combinare quelle informazioni in modo da produrre qualche vantaggio.

| << |  <  |