Sviluppo di Windows 2000

Lo sviluppo di Windows 2000 iniziò nei primi mesi del 1997 e terminò nel dicembre 1999. Il nome in codice del progetto di sviluppo era NT 5.0.

Nel 1997, la Microsoft originariamente pianificò un successore univoco sia per Windows NT 4.0 che per Windows 98. Al PDC 1997, tenutosi nel settembre dello stesso anno, la Microsoft distribuì la Beta 1 ai partner (Build 1671.1) in entrambe le edizioni Workstation (più tardi rinominata in Professional) e Server. Nel 1998, al PDC 1998, che si svolse tra l'11 e il 15 ottobre, la Microsoft commercializzò la Beta 2 (Build 1877.1) ai partner, sempre in entrambe le edizioni Workstation e Server. Poco dopo, nel 27 ottobre, la Microsoft rinominò il sistema in Windows 2000.

Tra la fine del 1998 e l'inizio del 1999, la Microsoft commercializzò versioni beta del sistema operativo, il cui sviluppo culminò con la Beta 3 nell'aprile 1999 (Build 2031.1). Sempre nel 1999, supporto per il sistema sull'architettura DEC Alpha fu interrotto da Compaq dopo la distribuzione della Release Candidate 1 (RC1, Build 2072.1).

Sempre nel 1999, la società annunciò che Windows 2000 non avrebbe sostituito Windows 98 a causa di un suo aggiornamento ancora in stadio di sviluppo (la Second Edition) e il vero successore di Windows 98 era già stato appena pianificato (distribuito col nome di Windows Me). Tra il luglio e il novembre dello stesso anno, la Microsoft distribuì altre due Release Candidates (RC2 Build 2128.1 e RC3 2183.1) e finalmente, il 12 dicembre 1999, venne distribuita la versione RTM agli OEM, e al pubblico il 17 febbraio 2000.

Complessità del software

Analizzato secondo i parametri attuali, lo sviluppo di Windows 2000 non appare tanto mastodontico, ma ai tempi della sua progettazione si trattava del più grande software commerciale mai realizzato, composto da 29 milioni di righe di codice scritte principalmente in linguaggio C++. Qualcuno ha anche calcolato che se l'intero codice del sistema operativo venisse stampato, si otterrebbe una pila di carta alta quanto un palazzo di 19 piani.

Per comprendere come un software possa arrivare fino a una simile enormità, bisogna immaginarlo non come un oggetto monolitico, ma come un assemblaggio di blocchi interconnessi. Come detto, Windows 2000 ha inaugurato una vera rivoluzione nell'approccio ai sistemi operativi di Microsoft diventando, dopo la serie di Windows 9x (Windows 95 e Windows 98) uno dei propri sistemi maggiormente utilizzati (almeno fino all'arrivo di Windows XP, suo successore). Il nucleo del sistema è già grande di per sé, eppure è solo una parte di quel tutto rappresentato da Windows 2000; tra i componenti figurano anche il browser per Internet Explorer 6, il transaction processing (strumenti per aggiornare le informazioni pressoché istantaneamente, non appena vengono ricevuti nuovi dati) e una quantità di driver, collegati a periferiche come per esempio stampanti. Soltanto i driver sono formati da più di 8 milioni di linee di codice: uno di essi supera da solo un milione di linee.

Dunque non è concettualmente difficile capire come un sistema operativo con una pletora di componenti possa crescere fino a diventare un gigante digitale. Meno ovvi, tuttavia, sono i motivi per cui Microsoft ha scelto di intraprendere questa temeraria avventura di ingegneria del software e il modo in cui l'azienda, dopo aver preso una simile decisione, è stata in grado di realizzare il prodotto.

Verso un sistema operativo omnicomprensivo

I responsabili della Microsoft affermano che la motivazione che li ha spinti ad adottare un approccio omnicomprensivo nel progetto di Windows 2000 è semplice: lo hanno chiesto i clienti. Il vertice aziendale era ben consapevole che la complessità del software e i bachi aumentano grosso modo in progressione geometrica con la dimensione, ma i principali clienti, e specialmente le maggiori aziende a livello mondiale, avevano affermato la loro esigenza che certe funzionalità fossero incluse nel sistema operativo. La logica di fondo era controversa: non era chiaro se fosse più efficiente per Microsoft integrare un'ampia gamma di sottosistemi tutti in una volta anziché integrare soltanto le specifiche funzioni richieste da ciascun cliente. Alla fine si è trattato di un compromesso: il vantaggio è che l'OS svolge un numero molto elevato di funzioni (per lo meno rispetto al suo diretto predecessore Windows NT); il rischio è che l'OS diventi molto grande e potenzialmente lento, instabile e pieno di bachi (quello che in gergo viene chiamato bloatware).

Tradizionalmente i sistemi operativi svolgono solo un numero limitato di compiti, come per esempio l'allocazione di risorse quali la memoria del computer, a seconda che l'OS sia progettato per personal computer, per la gestione di reti oppure per un'altra applicazione specialistica. Windows 2000 adotta un metodo alternativo; è un OS singolo che permette diversi utilizzi, fornendo quindi la stessa gestione della sicurezza e gli stessi servizi di sistema a un numero enorme di computer, dai laptop fino ai server cooperanti in cluster nei centri di elaborazioni dati di grandi organizzazioni. Il vantaggio teorico è che gli utilizzatori devono imparare un solo programma (anche se di mole colossale) per una gran varietà di sistemi e applicazioni.

Procedura di sviluppo passo-passo

Insieme con un nuovo modo di concepire i sistemi operativi, Microsoft ha dovuto inventare una diversa metodologia per lo sviluppo del software. In particolare, gli strumenti per simulare le modalità di funzionamento del software sono stati di utilità limitata. A differenza di altri progetti di grandi dimensioni infatti, in questa nuova impresa di Microsoft i modelli in scala si sono rivelati pressoché inutili. Un aspetto importante è che, al livello di dimensioni e complessità di Windows 2000, la scrittura del codice non è stata l'attività centrale. In effetti, le prove e il debugging hanno occupato il 90% - 95% del lavoro.

La maggiore sfida nella realizzazione di Windows 2000, tuttavia, non è stata tecnica. Dato che ogni componente del gruppo possedeva una conoscenza molto specialistica, un grande ricambio del personale avrebbe avuto effetti devastanti sul progetto, iniziato nel 1996. Un modo essenziale per tenere insieme lo staff di Windows 2000 è stato riuscire a creare un senso di famiglia: un compito non facile in un progetto di tali dimensioni. Si pensi a questi numeri: complessivamente lo sviluppo ha impiegato 4200 persone, tra cui 2000 appartenenti al personale Microsoft, 800 impiegati dei partner di Microsoft (per esempio Intel) che hanno lavorato a tempo pieno presso la sede dell'azienda a Redmond, nello Stato di Washington, e 1400 consulenti. Altri 1500 dipendenti Microsoft e consulenti lavoravano su Windows 2000 altrove, negli Stati Uniti e in altre parti del mondo, specialmente in Israele e in India, e utilizzavano gli strumenti di sviluppo e di prova della rete globale Microsoft per coordinare i loro sforzi con la sede principale.

Così, ogni venerdì pomeriggio, l'intero gruppo Windows 2000 si riuniva nella tavola calda dell'azienda, il solo locale a Redmond che potesse contenere diverse migliaia di persone. In parte punto della situazione settimanale, in parte riunione per stimolare la motivazione, questi incontri servivano sia per mantenere uno spirito di gruppo sia per tenere ben informato il personale.

Risoluzione sistematica dei bug rilevati

A causa dell'importanza critica delle prove e del debugging, un gruppo di 50 o 60 dirigenti si riuniva alle 9 del mattino ogni giorno della settimana (e anche il sabato e la domenica, quando si avvicinava una scadenza) per esaminare i report quotidiani degli errori trovati nel codice di Windows 2000. Questi bachi provenivano dalle fonti più svariate: fornitori di software indipendenti che dall'esterno sviluppavano applicazioni che avrebbero dovuto girare con Windows; clienti selezionati presso i cosiddetti beta site, che effettuavano le prove nelle situazioni reali in cui il software sarebbe stato poi utilizzato; test interni alla Microsoft, che impiegavano una grande percentuale dei sistemi aziendali; e prove fatte in altri paesi.

In queste riunioni l'impatto di ciascun baco era attentamente valutato, secondo un approccio che mirava a verificare quanti danni avrebbe potuto eventualmente causare, e se le correzioni avrebbero potuto introdurre nuovi problemi, oltre ovviamente a quale programmatore si sarebbe occupato di risolverlo. Il baco veniva quindi preso in carico da Sanjay Jejurikar, coordinatore del Dipartimento prove, che lo assegnava a uno dei 25 gruppi dedicati ciascuno a una diversa tipologia di errore. Essi registravano su un database la gravità del baco e poi apportavano le correzioni necessarie. Fatto questo, il codice modificato veniva inviato al Build Lab, il centro dell'attività di prova di Windows 2000.

Il Build Lab, l'edificio dei test

Per assicurarsi che Windows 2000 funzionasse correttamente su ogni possibile configurazione hardware, le molteplici stanze del Build Lab contenevano almeno un esemplare di qualunque tipo di sistema, memoria, scheda modem, scheda Internet e ogni altro dispositivo elettronico esistente. Tanto per fare un esempio, nei computer del Build Lab vi erano circa 1200 configurazioni solo per quanto riguarda le schede video. Per consentire al gruppo di prova di produrre una versione modificata di Windows 2000 ogni giorno, Microsoft imponeva un orario rigido per le revisioni da apportare al codice. Le modifiche giornaliere (tipicamente in numero di circa 250) venivano sottoposte tra le 13 e le 16. Dopo questa scadenza, al Build Lab si iniziava a modificare il codice, e la nuova emissione, la "build", avveniva solitamente tra le 18 e le 20. Quest'ultima versione di Windows 2000 era quindi pronta per essere scaricata sulla rete interna aziendale. Inoltre, entro le 21, il Build Lab produceva e distribuiva circa 2000 CD del software. Prima delle 7 del mattino dopo, il build verification test, che verificava la stabilità della build del giorno precedente, era già in corso.

Ottenere questo risultato non è stato facile. Il ciclo di test giornalieri terminava intorno alle 15:30 e tutti i commenti e le critiche successive a quest'ora venivano raccolti per la riunione del giorno dopo. Un punto di riferimento per capire quanto fosse intensa questa attività di prova: in un giorno, il personale si scambiava mediamente circa 90000 e-mail relative al progetto.

Ulteriori sessioni di test

Ulteriori test per mettere alla prova il software in condizioni simili agli ambienti reali venivano eseguiti in cicli di una o due settimane. Ogni sei settimane, quei grandi moduli il cui codice risultava completamente verificato venivano valutati un'ultima volta e quindi chiusi. Il codice, tuttavia, non era chiuso in un cassetto una volta per tutte. Se veniva scoperto un ulteriore baco, Microsoft lo correggeva, anche se questo comportava altri test, per assicurarsi che la correzione non desse origine a problemi in altre parti del programma che erano già state ultimate.

I bug, documentati, ma lasciati consapevolmente nel codice

Tuttavia, non tutti i bachi sono stati corretti. In un sistema software di queste dimensioni, occorre sempre considerare il rischio che la correzione di un errore possa avere un impatto in qualche altra parte del sistema. Secondo quanto è stato riferito, Microsoft effettuava sempre la correzione di quattro tipi di bachi: quelli che provocavano blocchi del sistema, introducevano falle nella sicurezza, creavano problemi Y2K (i famosi millennium bug) oppure impedivano all'utente l'accesso a qualche tipo di servizio. Altri tipi di anomalia che l'azienda non riteneva valesse la pena di eliminare comprendevano quelli che si verificano soltanto in situazioni poco comuni, che riguardano solo un piccolo numero di clienti. Microsoft documentava questi tipi di errore e conservava le possibili correzioni, in modo che potessero essere fornite ai clienti che ne avevano bisogno.

In condizioni ideali (e in progetti che sviluppano software più semplice) l'idea di lasciare consapevolmente alcuni bachi sembra impensabile, ma Windows 2000 rappresenta una realtà estrema di ingegneria del software. Un sistema di tale grandezza non può essere privo di difetti; può soltanto essere verificato e documentato nel modo più completo possibile nei limiti del tempo a disposizione. L'ultima e più massiccia parte del test non è avvenuta all'interno della Microsoft, ma nei beta site dei principali clienti e partner, tra cui figuravano migliaia di ditte produttori delle componenti hardware o delle applicazioni software complementari. L'ultima versione di prova di Windows 2000 è stata distribuita in 23 linguaggi e 130 distinti dialetti presso 300.000 sedi di aziende situate in oltre 50 nazioni.

Voci correlate

• Windows 2000