La crescente richiesta di energia e l'aumento dell'impatto negativo di una sempre più diffusa adozione di servizi IT sono alla base di un "green movement" con focus su progettazione e implementazione di soluzioni IT green.
Le emissioni annue di anidride carbonica, che hanno superato i 9 miliardi di tonnellate, il livello più alto nella storia dell'umanità e superiore del 49% ai livelli del 1990, sono per circa il 2% attribuibili ai sistemi IT, per cui una riduzione dei consumi energetici di questi sistemi porterebbe a un beneficio non risolutivo ma comunque importante. Parlando di consumi, l'attenzione è sempre stata tradizionalmente rivolta ai sistemi hardware, ma questi sono controllati da componenti software che se anche non consumano energia impattano comunque sull'uso dell'hardware, configurandosi come "consumatori" indiretti.
La centralità del software
La crescente onnipresenza di sistemi software complessi ha iniziato ad un certo punto a richiamare l'attenzione dei progettisti su safety e security come requisiti "non funzionali", cioè non parte delle funzionalità per cui un software viene concepito, unitamente ad altri requisiti quali efficienza, affidabilità e usabilità. Per quanto safety e security siano termini entrambi traducibili con "sicurezza", la Safety implica la salvaguardia o la protezione da eventi o circostanze generalmente indipendenti da precise volontà che comportano alta potenzialità lesiva in funzione del tipo di attività svolta, mentre la Security implica la salvaguardia o la protezione da attacchi, aggressioni, danni contro la persona o i beni, perpetrati volontariamente da singoli o gruppi di persone con l'intenzione di nuocere. Dato che in ambito IT si parla di Cyber Security, come insieme di procedure e soluzioni miste hardware/software atte a proteggere le aziende da attacchi perpetrati da hacker, si può attribuire a security il significato di protezione contro attività criminali e a safety quello di prevenzione di incidenti o protezione contro gli effetti di tali incidenti. Ciò premesso, safety e security sono caratteristiche che hanno iniziato a essere sistematicamente incluse nel software engineering una volte visto che i sistemi software possono essere causa di incidenti gravi, con danni a persone e impianti, lavorando su algoritmi di security a partire da quando hanno iniziato a diffondersi furti di dati e di identità e frodi finanziarie, e ci è voluto del tempo prima che queste caratteristiche fossero incluse negli standard; per esempio nell'IEEE Standard 830-1998 (Recommended Practice for Software Requirements Specifications), safety e security sono solo menzionate, evidenziate invece nelle più recenti norme ISO/IEC/IEEE 29148:2011. Negli anni successivi al 2000 i sistemi software diventano centrali per le attività di molti settori della società industriale, come risorse embedded che permettono la vita quotidiana e lavorativa che conosciamo. Si potrebbe anche affermare la centralità dei sistemi elettronici nelle loro molteplici manifestazioni funzionali, ma senza un contenuto software un PC, uno smartphone o un tablet sono solo pezzi di plastica, vetro e silicio senza vita. Tutto è iniziato negli anni '70, con l'avvento della microelettronica e dei microprocessori, che hanno sostituito la logica cablata basata sul controllo anche sofisticato di segnali elettrici, con una logica programmabile, dove il software conferisce un preciso comportamento funzionale a una logica su silicio e da qui al sistema per cui questa logica è stata progettata.
Esigenza di sostenibilità
Non è certo implicito nell'innovazione tecnologica un impatto negativo sull'ambiente, conseguenza invece del sommarsi nell'ambito delle strutture sociali che abbiamo creato di azioni individuali che spesso privilegiano una convenienza immediata e locale piuttosto che una responsabilità globale. Volendo passare a un approccio sostenibile, molti settori della società dovranno ripensare le loro modalità operative, e l'ubiquità del software offre un'occasione praticamente unica per intervenire su attività industriali impattanti e tra loro interconnesse. Ma perchè ciò avvenga la sostenibilità ambientale deve essere esplicitamente considerata come requisito non funzionale primario nel processo di ingegnerizzazione del software, unitamente a safety, security, efficienza, affidabilità e usabilità: in tal modo si metterebbe a disposizione dei progettisti software un grande potenziale per rendere più sostenibile il processo di continua e esaperata modernizzazione della società. Si inizia del resto a parlare di "sociotechnical IT systems", ambito in cui non ci si limita a una semplice ottimizzazione dell'esistente, privilegiando un passaggio dal tradizionale software engineering a una specie di "transition engineering" quale disciplina emergente finalizzata a supportare il cambiamento degli attuali sistemi non sostenibili ad altri più attenti all'ambiente, pena un continuo degrado che a un certo punto non si riuscirà più a gestire.
Una situazione complessa
In occasione dell'United Nations Earth Summit del 1992 era stata ratificata da 192 Paesi la Convenzione Quadro delle Nazioni Unite sui cambiamenti climatici (United Nations Framework Convention on Climate Change), ma pochi l'hanno poi applicata, e di limitato pratico utilizzo sono anche le raccomandazioni scaturite dalla Rio+20 Conference del 2012. A questo punto ci si potrebbe chiedere: perchè non si riesce a imboccare una strada per salvare il nostro pianeta? Certamente il problema è estremamente complesso, ma questo non impedisce che si debba fare qualcosa. E qui entrano in gioco i sistemi software, meglio dire i "sustainably engineered software systems" che potrebbero veicolare verso stili di vita più sostenibili influenzando direttamente il contesto (persone e infrastrutture) in cui tali sistemi agiscono. I sistemi software hanno un impatto talmente significativo sulla nostra vita quotidiana che un cambiamento verso una maggiore sostenibilità ambientale può propagarsi ad altri sistemi con cui interagiscono, ampliando gli effetti benefici. Ma come supportare la sostenibilità tramite uno sviluppo diverso del software? Quale le tecniche da inventare? Problematiche del genere, si sostiene da più parti, sono già state affrontate quando si è iniziato a integrare safety e security, quindi si può far riferimento a questi requisiti non funzionali per individuare come comportarsi in merito al nuovo requisito di sostenibilità. Detto diversamente, tutta una serie di concetti relativi a safety e security possono essere applicati alla "sustainability". Per esempio la safety è una proprietà emergente, nel senso che si manifesta quando i componenti di un sistema interagiscono con un ambiente, con un preciso contesto, cioè quando un sistema è in uso, a differenza di una caratteristica inerente, esibita già a livello statico: detto diversamente, un sistema software non è di per sè insicuro, ma può diventarlo nel suo ambiente di applicazione. Anche la sostenibilità è una proprietà emergente, anche se non completamente, dovendo variamente manifestarsi per esempio in funzione del comportamento umano. La security è il grado di resistenza a tentativi di danneggiamento di informazioni o anche il grado di protezione che si riesce a garantire alle informazion, e una politica di sicurezza consiste in un insieme di norme e pratiche che regolano il modo in cui un'organizzazione gestisce, protegge e distribuisce informazioni sensibili, e un meccanismo similare di politiche e requisiti è necessario per supportare e rafforzare la sostenibilità ambientale.
Miti ed equivoci
Molti miti ed equivoci che riguardano safety e security si ritrovano nella sostenibilità. Il primo è senz'altro quello di una conflittualità con gli obiettivi economici di un'azienda. Per esempio, nel caso della safety si pensa ancora che vi possa essere un conflitto con gli obiettivi economici di un'azienda, quasi si trattasse di una palla al piede, senza considerare che invece è un prerequisito senza il quale si possono manifestare rischi elevati sul lungo termine. Un'analoga percezione negativa si ha con la sostenibilità senza considerare che questa conflittualità deriva semplicemente dal fatto che le aziende non devono pagare per le emissioni che producono nei processi manifatturieri: se questi costi dovessero essere tenuti in conto, la sostenibilità diventerebbe parte integrante del conto economico. Altro equivoco quello per cui safety, security e sostenibilità sono da trattarsi come separate da altre caratteristiche qualitative. I relativi requisiti sono sostituiti da vincoli solution-specific senza tener conto di tutta una serie di aspetti correlati, da cui soluzioni non ottimizzate dato che non si guarda ai requisiti reali nel loro complesso. Come esempio emblematico per la sostenibilità, si dovrebbero comunque applicare meccanismi di risparmio energetico senza soffermarsi ad analizzare quali siano i processi che richiedono tali meccanismi, esplorando sia l'intero spazio delle problematiche che il completo dominio delle applicazioni per individuare la soluzione ottimale.
