Il mondo delle Beta, parte 1: metodi di sviluppo e testing a confronto

Come richiesto da alcuni, oggi affrontiamo un argomento molto particolare e anche interessante: le Beta, e più in generale il processo di sviluppo che porta un software dalle prime righe di codice alla sua commercializzazione. Quante volte abbiamo sentito robe tipo “rilasciata la Beta del software Pippo”, “è stato effettuato il leak di una build del software Pluto”, “spediti gli inviti per il testing privato della prossima versione del software Paperino”, nei siti che si occupano di tecnologia ed informatica. In questa prima parte cercheremo di dipanare questa matassa, e di capire come funziona questo mondo, mettendo anche a confronto due modelli, i più famosi, probabilmente: Apple e Microsoft.

Come funziona il processo di sviluppo
Prima di metterci ad effettuare il confronto, è bene vedere un po’, senza scendere troppo nel tecnico, come funziona un processo di sviluppo generico. Chiaramente, uno che ha studiato informatica professionalmente la spiegherebbe molto meglio: ma quello che vogliamo farci è un concetto di base, non è necessario approfondire. All’inizio di tutto vi è la fase di pianificazione e di analisi, dove la nuova versione del software inizia ad essere studiata a tavolino per capire le funzionalità che dovrà avere, i requisiti che dovrà soddisfare e i problemi che dovrà risolvere rispetto alla precedente. Il tutto viene stabilito con riunioni tra gli sviluppatori, sondaggi tra clienti selezionati e concept, solo grafici o anche come codice funzionante, che dimostrino le intenzioni del team di sviluppo. Sempre nel corso di questa fase avviene l’organizzazione interna del team, suddiviso in sotto-team, ognuno incaricato di curare specifiche parti del prodotto: ciò avviene perlopiù per i progetti più grandi. Questa fase avviene spesso subito dopo il rilascio della versione precedente, se non addirittura con il processo di sviluppo della vecchia ancora in corso, seppur nelle sue battute finali: eh sì, le aziende non dormono sugli allori. Quando andiamo ad acquistare la nuova versione di un prodotto, già internamente stanno lavorando a quella successiva! Tale periodo può anche essere riassunto come pre-Alpha.

A seguito di questo periodo, si può dire inizia il lavoro vero e proprio sul codice: dai concept si passa alla compilazione. E’ il periodo Alpha, in cui le funzionalità pianificate prima vengono implementate nel prodotto, sia partendo dalla precedente versione oppure ricominciando da zero, basandosi sui requisiti definiti in precedenza e sui sondaggi. Durante la Alpha, il software è di solito incompleto, instabile e spesso anche abbastanza rozzo a livello grafico. In generale, la grafica di un prodotto viene curata più avanti, anche perché è un po’ il problema minore di tutto il ciclo di sviluppo. A volte le Alpha non vengono chiamate così, ma Milestone, pietre miliari. Di solito le Milestone avvengono per grandi progetti, in cui per ogni Milestone viene definito il livello di funzionalità da implementare. Di norma, il testing dei nuovi prodotti allo stadio Alpha è quasi sempre interno all’azienda, o al massimo allargato a pochi clienti selezionati. Vi sono poi i cosiddetti “leak”, ma di quelli ne parleremo nella parte 2.

Una volta che il codice è ritenuto sufficientemente maturo per passare a uno stadio di sviluppo più avanzato, si passa alla parte centrale dell’intero processo: la Beta. E’ qui che il prodotto diventa completo e viene raffinato, anche a livello grafico, per prepararlo a un testing pubblico, aperto a tutti, o comunque molto più esteso di prima. Talvolta, la Beta si suddivide in più parti: ad esempio, Beta 1 e Beta 2. Le differenze sono spesso nel tipo di testing, che può essere privato nella prima Beta e pubblico nella seconda. Oltre a ciò, possono esservi differenze in termini di funzionalità, con la Beta 2 che contiene funzioni più mature e stabili rispetto alla prima. In generale, nella Beta si prepara il prodotto per gli stadi finali di sviluppo. Il testing più allargato serve infatti per riscontrare tutti gli eventuali bug che possono dare noie successivamente.

Ottenuti i feedback, implementati eventuali suggerimenti e corretti i bug riscontrati, il prodotto si può definire completo a livello di funzionalità. Da lì in poi, solo bugfix. Entriamo nella fase di Release Candidate, uno stadio in cui il prodotto presenta tutte le caratteristiche previste per la versione finale, un aspetto grafico pressoché completo, e tutto ciò di cui ha bisogno è di tester volenterosi che lo spulcino per trovare tutti i bug più critici da sistemare prima del rilascio finale. Nello stesso periodo, si inizia a lavorare sulla documentazione del prodotto e, in caso di edizioni internazionali, alla sua traduzione.

Solo quando tutti i bug più critici sono stati sistemati, o in generale si scende sotto un livello di bug definito “accettabile”, il prodotto è considerato pronto e completo a livello di codice. A quel punto il software è dichiarato Release To Manufacturing, avviato alla distribuzione. Tutte le sistemazioni aggiuntive di bug sono rimandate ad aggiornamenti post-rilascio, mentre eventuali funzionalità da aggiungere saranno considerate nella pianificazione della versione successiva. Insomma, è un ciclo che non ha mai fine, a meno che l’azienda non decida di dismettere il prodotto, oppure l’azienda fallisca o venga venduta e in questo caso è l’acquirente a dismettere il prodotto.

Due metodi a confronto: Apple e Microsoft
Fatto questo excursus sul processo di sviluppo, andiamo a vedere come Apple e Microsoft sono organizzate a riguardo. Partendo da Cupertino, ci troviamo davanti a un processo abbastanza “lucchettato”, di cui poco si sa fino a quando non è l’azienda stessa a parlarne. A volte, come nel caso dell’evento “Back to the Mac”, il prodotto viene annunciato in una forma preliminare, senza distribuirne però una versione di test, non essendo considerato pronto allo scopo. Altre volte, come nel caso dei WWDC, alla presentazione, ma anche a sorpresa mesi dopo l’evento di presentazione, segue la diffusione di una Developer Preview. A questa, poi, ne possono seguire altre, come sta accadendo anche per Lion. In generale le Developer Preview possono essere definite le Beta del mondo Apple. A confondere le idee, a volte Apple usa il termine stesso di Beta per identificare le versioni di sviluppo. In generale, tutto il processo di Apple si svolge in un contesto ristretto, niente testing veramente pubblici, ma aperti solo agli sviluppatori paganti per l’apposito programma di testing. Il resto dell’utenza non ha generalmente voce in capitolo, e proverà il prodotto per la prima volta solo quando è in scatola. Il prodotto finito è quello considerato in Gold Master. La Gold Master può essere sia una sorta di Release Candidate che una sorta di Release To Manufacturing: il primo caso avviene quando vengono proposte più di una Gold Master, mentre nel secondo caso la prima fatta è considerata buona per la commercializzazione e non necessita di altri ritocchi prima di finire in scatola.

Di diametro quasi opposto è il processo Microsoft, ben dettagliato e conosciuto. Si inizia con le Milestone, in cui vengono immesse, build dopo build, le funzionalità previste per il prodotto, talvolta ben visibili, talvolta “bloccate” affinché esterni non le possano vedere. In caso di “leak”, infatti, così facendo viene, almeno temporaneamente, inibita la possibilità a coloro che scaricano la build di vedere tutto quanto su cui si sta lavorando internamente. Inoltre, è un vantaggio anche per proteggere le novità dagli occhi della concorrenza, che non può avere informazioni dettagliate su quanto è in sviluppo. Le Milestone vengono fatte testare sia internamente sia esternamente a un limitato numero di partner, perlopiù produttori di hardware e software, che devono assicurarsi la compatibilità dei loro prodotti. Può a volte capitare che una Milestone piuttosto avanzata venga rilasciata anche agli abbonati ai circuiti per sviluppatori e professionisti informatici, il più delle volte a seguito della presentazione del prodotto nel corso di una conferenza, come il PDC, che quest’anno in occasione di Windows 8 sembra essere destinato a cambiare nome. Dopo tutto ciò, arriva la Beta. Può essere unica oppure possono essere più Beta, in generale sono pubbliche e aperte praticamente a chiunque voglia provare il prodotto. Raccolti i feedback, si passa alla Release Candidate, in cui l’azienda di Redmond propone il prodotto in forma quasi finita e chiede gli ultimi pareri prima di poter procedere alla messa in Release To Manufacturing e quindi alla commercializzazione.

Quale dei due metodi è più efficiente? In generale, non vi è un vero e proprio vincitore. Quello di Apple è più ristretto e per certi versi anche meno libero, ma la ricezione di feedback da parte di soli sviluppatori consente di avere pareri di maggiore qualità. Quello di Microsoft, invece, è molto più allargato e libero, ma ciò si paga ovviamente con una maggiore dispersione e di conseguenza una minore qualità dei feedback ricevuti. A differenza di quello Apple, però, nel loro caso si può riscontrare l’uso del prodotto in una più ampia casistica di situazioni e configurazioni. Insomma, entrambi presentano pregi e difetti, in generale tutti un po’ concatenati tra loro: un pregio può far derivare un difetto, e un difetto può far derivare un pregio. Sono dunque semplicemente due filosofie di sviluppo diverse.

Nella seconda e ultima parte, prevista per settimana prossima, andremo a guardare più nel dettaglio tutto ciò che ruota attorno alle Beta, come i “leak”, le loro possibili conseguenze legali e il collezionismo di questi prodotti ancora in sviluppo.

Giovanni "il Razziatore"

Deputy - Ho a che fare con i computer da quando avevo 7 anni. Uso quotidianamente OS X dal 2011, ma non ho abbandonato Windows. Su mobile Android come principale e iOS su iPad. Scrivo su quasi tutto ciò che riguarda la tecnologia.

Commenti controllati Oltre a richiedere rispetto ed educazione, vi ricordiamo che tutti i commenti con un link entrano in coda di moderazione e possono passare diverse ore prima che un admin li attivi. Anche i punti senza uno spazio dopo possono essere considerati link causando lo stesso problema.