Ecologia del Software

bushido

Elenco (estremamente disordinato e prolisso) dei princìpi guida che cerchiamo di seguire come sviluppatori software e che speriamo di veder seguiti da chi si occupa del software che noi acquistiamo ed usiamo.

Ecosistema Software in Genere

Rispettare l’hardware

L’hardware non è tutto vostro. Lasciatene un po’ anche per gli altri.

Non impossessatevi di tutto lo spazio disco se non c’è ragione di farlo e soprattutto non fatelo mai senza prima aver chiesto autorizzazione all’utente.

Non lanciate operazioni che usano la CPU al 100% senza che ce sia veramente motivo e non fatelo senza prima aver avvertito l’utente.

Non occupate tutta la RAM disponibile. Se dovete caricare un file gigantesco, cercate di caricare solo le parti che vi servono. Avvertite l’utente prima di eseguire operazioni del genere.

Rispettare l’utente

Fate quello che l’utente vi dice di fare, anche se vi sembra assurdo. Avvertite e chiedete conferma, ma fate quello che vi viene chiesto di fare.

Non fate niente di diverso da quello che l’utente ha chiesto.

Non prendete iniziative che non siano state preventivamente autorizzate dall’utente (magari con un parametro di configurazione).

Non trattate l’utente da imbecille o da ignorante. Parecchi di loro sono più intelligenti e più colti di voi, anche se lavorano in settori molto diversi dall’informatica e con i computer sono delle frane.

Non tentate di ingannare l’utente.

Usare un sistema poco invadente per parlare all’utente

Se dovete informare l’utente di qualcosa, fatelo con qualcosa di poco invadente, come una “toast-style window”.

Se usate una dialog box bloccante, fate che sia per qualcosa che davvero deve impedire all’utente di compiere altre operazioni.

Rispettare il resto dell’ecosistema

La vostra applicazione vive all’interno di un ecosistema software vasto e complesso. Rispettatelo.

Rispettate il sistema operativo e gli altri sistemi operativi esistenti. Non fate nulla che crei difficoltà ad altri.

Rispettate la Rete, sia quella locale che Internet. Non fate nulla che crei problemi alle comunicazioni del vostro utente o di altre persone.

Rispettate le altre applicazioni, anche quelle che sono vostre concorrenti. Non fate nulla che possa creare loro problemi. Soprattutto, non rendete i vostri documenti illeggibili dalle altre applicazioni concorrenti.

Rispettate le persone, che siano vostri utenti o meno.

Non tagliate gli alberi

Non cancellate un progetto software esistente a meno che non ci siano ragioni serissime per farlo. Piuttosto, rilasciate il codice come Open Source e date vita ad un progetto indipendente. I vostri utenti più affezionati ve ne saranno grati.

Sistema Operativo

Installazione del sistema

Permettete all’utente di testare il sistema prima di installarlo (Live CD o installazione su chiavetta USB).

Permettete all’utente di usare la sua lingua sin dall’inizio, durante il test dal CD e durante l’installazione.

Assicuratevi che la traduzione della GUI sia corretta e comprensibile.

Mostrate all’utente com’è partizionato il suo disco e qual’è la configurazione hardware che il vostro sistema è in grado di vedere.

Fate scegliere all’utente come usare il disco (partizionamento e formattazione) ed il resto dell’hardware e consigliatelo nella scelta.

Rispettate meticolosamente gli altri sistemi installati ed il loro sistema di avviamento (il “bootloader”, cioè Lilo, GRUB, etc.). Se vi è possibile, accodatevi al bootloader già in uso. Installate il vostro bootloader solo se è davvero necessario e solo dopo aver ottenuto il consenso dell’utente.

Avviamento del sistema

Avviate il sistema più “piccolo” che vi è possibile e fatelo il più in fretta che potete. Eliminate tutto ciò che non è strettamente necessario. Lanciate più processi in parallelo ovunque sia possibile.

Non usate la strategia appena descritta per ingannare l’utente. Il sistema risultante dal bootstrap deve essere completo e funzionante. Non continuate a caricare software dopo aver visualizzato il desktop, con il solo risultato di rendere il sistema talmente lento da risultare inusabile.

Avviate solo il necessario

Una volta completato il bootstrap e visualizzato il desktop, avviate solo le applicazioni “auto-start” che sono realmente necessarie per il funzionamento del sistema e quelle che l’utente vi ha esplicitamente chiesto di avviare agendo sulla configurazione.

Non avviate servizi e applicazioni che ritenete “utili” o che servono solo a rendere visibili le vostre offerte commerciali ed i vostri servizi.

Shutdown del sistema

Chiudete il sistema nel minor tempo possibile. Se un’applicazione non risponde al SIGTERM, avvertite l’utente, aspettate 5 secondi e terminatela in altro modo.

Non usate lo shutdown come occasione per compiere operazioni di manutenzione, come l’installazione degli upgrade.

Aggiornamento del sistema

Fate un controllo quotidiano della presenza di aggiornamenti.

Permettete all’utente di rendere auto-installabili gli aggiornamenti critici e quelli di sicurezza dalla configurazione del sistema. NON permettete all’utente di rendere auto-installabili TUTTI gli aggiornamenti.

Avvertite sempre l’utente della presenza di aggiornamenti.

Chiedete sempre l’autorizzazione prima di installare gli aggiornamenti che non sono stati pre-autorizzati in configurazione.

Gli aggiornamenti vanno controllati ed installati dopo il bootstrap ma non subito dopo. Date il tempo all’utente di fare le cose per cui ha acceso il computer e poi parlategli degli aggiornamenti. Un’attesa di 10 o 15 minuti dal bootstrap del desktop va bene.

Fornire un sistema di salvataggio

Una installazione od un aggiornamento possono rendere il sistema inutilizzabile. Fornite al vostro utente un modo per tornare all’ultimo stato sicuramente funzionante del sistema.

Non basatevi solo sul disco fisso per queste cose. Il disco fisso può rompersi ma il vostro utente deve poter riprendere il suo lavoro entro la fine della giornata. Dategli modo di salvare il sistema su un supporto esterno.

Non date al vostro utente un sistema hardware privo dei dischi di installazione del sistema operativo. Il sistema potrebbe schiantarsi prima che l’utente abbia avuto modo di creare i dischi di ripristino.

Disinstallazione del sistema

Il vostro sistema operativo non è un elemento naturale del paesaggio, come una montagna od un fiume. È una normale applicazione software. Fate in modo che possa essere disinstallata senza dover riformattare il disco.

Usate sempre almeno due account

Usate sempre almeno due account diversi: uno di amministrazione ed uno di uso quotidiano.

L’utenza di uso quotidiano NON deve aver accesso alla configurazione di quegli aspetti del sistema operativo che riguardano anche altri utenti (software installato system-wide, parametri system-wide, etc.) e che influenzano il funzionamento dell’intero sistema (configurazione della rete, etc.).

Per questi scopi, e per installare software, deve essere utilizzata un’apposita utenza di amministrazione.

Permettete agli utenti di installare software personale solo all’interno delle loro home directory e solo se questo software non pretende di avere accesso a parametri globali del sistema, come i task di cron e la configurazione della rete.

Non eseguite mai nulla che trovate nella home directory di un utente con privilegi di amministrazione (script di automazione del desktop e roba simile).

Applicazioni

Installazione dell’applicazione

Fate in modo che la vostra installazione sia semplice e veloce.

Se esiste un sistema di gestione delle installazioni software (Debian APT, Microsoft MSI, etc.) usate quello. Non inventatene uno vostro a meno che non ci sia una ragione serissima per farlo.

Se possibile, fornite un vostro repository personale per i vostri pacchetti. Non gravate sui maintainer e sui packager delle distribuzioni.

Scaricate un pacchetto archiviato e compresso (tar.gz, deb, etc.) non una sequenza di file. NON usate il “check-out” di GIT, Subversion o cose simili come sistema di installazione. Create un pacchetto di “release” ed usate quello.

Salvate il pacchetto in un “repository” locale, per eventuali usi futuri (e permettete all’utente di ripulire questo repository locale in seguito).

Se è possibile, salvato lo stato corrente del sistema e rendete annullabile l’installazione.

Decomprimete il pacchetto ed eseguite uno script di installazione. Lo script deve controllare che esistano le condizioni necessarie per l’installazione: dipendenze soddisfatte, spazio disco, utenza “giusta” per l’installazione, etc. Se qualcosa non va, segnalatelo all’utente e cercate di risolvere la situazione (su autorizzazione dell’utente) prima di darci su.

Fate in modo che la vostra installazione possa essere eseguita dalla linea di comando. In questo modo potrà essere effettuata via SSH sui server e potrà essere eseguita automaticamente dal sistema di aggiornamento del sistema operativo usato dal vostro utente.

Interrompete l’installazione automatica per fare domande solo se è veramente, ma veramente necessario. Se potete usare un parametro di default ragionevole e rimandare le finezze ad una fase successiva, fatelo.

Loggate ogni cosa.

Alla fine del processo di installazione, se è davvero necessario, lanciate l’applicazione e chiedete all’utente di dedicarsi alla sua configurazione.

Non infastidite assolutamente MAI l’utente con stupide richieste relative alla licenza e/o con altre idiozie di marketing durante l’installazione. La vostra licenza è già pubblicata da qualche parte ed è già valida. Non è necessario ottenere dei click di accettazione esplicita. Se proprio non resistete, fate queste domande DOPO l’installazione, durante la fase di configurazione od al primo utilizzo.

Mai e poi mai permettevi di inserire pubblicità o cose simili in un processo di installazione sulla command line. Se proprio non resistete alla tentazione, inserite qualche slide nel processo di installazione grafico (GUI-based).

Limitare i TSR

I TSR (“Terminate and Stay Resident” program) avevano un senso nel medioevo, quando i sistemi operativi non disponevano ancora di un proprio sistema di monitoraggio degli eventi (in particolar modo di monitoraggio degli eventi del file system) e di un proprio sistema di scheduling (come “cron” su Unix). Al giorno d’oggi ne hanno veramente poco.

Se dovete eseguire un “task” ad intervalli regolari, affidatevi allapposito scheduler del sistema operativo ed eventualmente fornite una semplice interfaccia di configurazione dei vostri task.

Se dovete eseguire un “task” in risposta ad un vento, cercate di usare i monitor del sistema operativo e fornite una semplice interfaccia di configurazione.

Non usate un TSR se potete farne a meno: occupa inutilmente della memoria e può essere causa di problemi.

Rispettare il desktop

Non buttate le vostre icone sul desktop. Il desktop è il piano di lavoro dell’utente e deve restare pulito.

Tenete i vostri documenti in una “cartella” (“directory”) della “home directory” dell’utente.

Piazzate i file del vostro programma in una directory di “program files” (“programmi”), fuori dalla portata degli utenti.

Rispettare la icon tray

Non piazzate l’ennesima iconcina nella icon tray a meno che non ci sia una vera, ineludibile ragione per fare una cosa del genere. Per chi non lo sapesse, la icon tray è la parte destra della barra del desktop, quella dove si affollano le iconcine di ZoneAlarm, dell’antivirus e via dicendo.

Queste iconcine occupano spazio nella menu bar del desktop, confondono l’utente e spesso occupano risorse (RAM e CPU). Evitate di usarle fin dove è possibile.

Sono piuttosto rari i programmi che hanno veramente bisogno di restare attivi e/o visibili per tutto il tempo in questo modo. Quasi tutti i programmi possono essere configurati e controllati da un’apposita dialog box che può essere lanciata all’occorrenza.

Avviamento dell’applicazione

Lanciate la vostra applicazione solo quando l’utente vi chiede di farlo, in modo episodico (“al momento”) o sulla base di un parametro di configurazione che l’utente ha definito in precedenza.

Lanciate solo l’applicazione richiesta. Niente “accessori”.

Limitatevi a lanciare l’applicazione. Niente “task” che vengano eseguiti “di default” al momento del lancio. Ogni operazione deve essere richiesta dall’utente al momento o sulla base di un parametro di configurazione che l’utente ha esplicitamente definito in precedenza.

Fate in modo che il lancio avvenga nel minor tempo possibile.

Fate in modo che l’applicazione blocchi l’utente solo se è veramente necessario farlo.

Fate in modo che l’applicazione occupi solo lo spazio visivo che le è veramente necessario. Non lanciate mai un’applicazione in modalità “full screen”.

Shutdown dell’applicazione

Quando l’utente vi chiede di chiudere l’applicazione, chiudetela e basta. Non infastidite l’utente con domande che non sono veramente necessarie.

Chiedete conferma della chiusura solo se è necessario salvare lo stato di un documento o lo stato dell’applicazione.

Chiudete l’applicazione nel minor tempo possibile. Non mostrate dialog box, messaggini od altri elementi visivi a meno che non sia assolutamente necessario. Registrate eventuali problemi negli appositi file di log, senza infastidire l’utente.

Non usate la fase di chiusura come un’occasione per effettuare operazioni di manutenzione.

Assicuratevi di aver rilasciato tutte le risorse che erano occupate.

Non lasciate sporcizia dietro di voi, né visibile (desktop), né invisibile (RAM).

Aggiornamento dell’applicazione

Fate in modo che la vostra applicazione sia in grado di rilevare da sola l’esistenza di eventuali aggiornamenti e di installarli attingendo direttamente alla vostra fonte, senza passare attraverso altri “maintainer” o altri “packager”.

Fate in modo che la vostra applicazione controlli l’esistenza degli aggiornamenti all’avvio, con una operazione non bloccante e che sia la più veloce possibile.

Fate in modo che il sistema di gestione degli aggiornamento sia pienamente configurabile dall’utente e che questo sistema di configurazione sia comprensibile.

Non installate mai nulla senza che l’utente vi abbia fornito la necessaria autorizzazione. L’autorizzazione ad installare aggiornamenti di sicurezza ed aggiornamenti critici deve poter essere stabilita da un parametro di configurazione, in modo che la vostra applicazione possa procedere in modo automatico. Viceversa, l’installazione di aggiornamenti non critici (nuovi temi grafici, plugin, etc.) e l’installazione di nuove versioni dell’applicazione devono sempre essere autorizzate in modo esplicito, al momento.

Salvate l’ultima versione funzionante prima di aggiornare e fornite all’utente un modo per annullare i cambiamenti prodotti dall’aggiornamento. Dite all’utente dove avete salvato questa roba e fornitegli uno strumento per eliminarla (dopo aver collaudato la nuova versione) e liberare spazio sul disco.

Fate in modo che l’aggiornamento sia il più veloce possibile.

Non conservate copia di ogni schifezza sul disco dell’utente. Rimpiazzate le vecchie librerie con le nuove e liberate spazio disco ovunque sia possibile.

Disinstallazione dell’applicazione

Fate in modo che la vostra disinstallazione sia completa. Non lasciate dietro di voi nulla che possa essere cancellato. Conservate solo i documenti creati dall’utente. Rimuovete anche i parametri di configurazione della vostra applicazione sul sistema operativo (task di cron, elementi del registry, etc.), o, al massimo, salvateli in un apposito script di re-installazione zippato.

Fate in modo che la disinstallazione sia veloce. La più veloce possibile.

Chiedete sempre conferma prima di disinstallare.

Durante la disinstallazione, dite all’utente dove può trovare i suoi documenti.

L’applicazione deve ascoltare

Fate in modo che la vostra applicazione resti in ascolto di quello che succede. Fatele leggere un file ad intervalli regolari, fatela ascoltare su una porta TCP/IP o fate in modo che reagisca a qualche segnale del sistema operativo ma, in ogni caso, fate in modo che sia possibile comunicare con essa. Deve essere sempre possibile comunicare con la vostra applicazione, almeno per terminarla, anche se si tratta di un’applicazione pensata per svolgere compiti di background in modo “unattended”.

Ovviamente, fate in modo che sia raggiungibile e controllabile solo da un’utenza abilitata a farlo.

Sviluppo Software

Rispettare le convenzioni

Rispettate le convenzioni esistenti, a tutti i livelli.

Se una rete locale si chiama “rete locale” o “LAN”, chiamatela “rete locale” o “LAN” nella vostra applicazione. NON chiamatela “rete casalinga” o cose simili. Se la configurazione di un account di posta elettronica richiede di configurare i server SMTP e POP3/IMAP4, ognuno con username, password e parametri di comunicazione (TLS, etc.), fornite un’unica dialog box per ogni account che permetta di configurare il server SMTP ed il server POP3/IMAP4, ognuno con i suoi parametri. NON fornite all’utente un “wizard” che pretende di guidarlo in “migliorare le relazioni sociali con i vostri amici attraverso l’uso di strumenti tecnologici di ultima generazione” e che pretende di farlo chiedendogli nome, cognome e numero di scarpe per poi pescare il resto delle informazioni necessarie Dio-solo-sa-dove.

Usare i nomi convenzionali canonici

Se una cosa ha già un nome, largamente conosciuto ed utilizzato, non dategliene un altro. Una rete locale si chiama “rete locale”, non “spazio di comunicazione aziendale digitale”.

Lasciate il marketing dove deve stare: altrove.

Rispettare gli standard

Se esiste uno standard, de jure o de facto, rispettatelo. Rispettatelo alla lettera.

Date precedenza agli standard de jure, a meno che non siano così assurdi da rendere la vita impossibile all’utente.

In alcuni casi è possibile supportare più di uno standard, magari lo standard de jure e quello de facto. Se vi è possibile farlo, fatelo.

Rendete chiaro all’utente quale standard sta usando e permettetegli di configurare questa scelta come preferisce, con un’interfaccia chiara e comprensibile.

Rendere tutto configurabile

Fate in modo che ogni aspetto della vostra applicazione sia esplicitamente configurabile, anche se esistono dei default ragionevoli da applicare. Le cose di uso quotidiano dovrebbero essere configurabili attraverso un’apposita interfaccia grafica. Il resto attraverso un appositi file di configurazione.

Non usate un database (“registry”) o altre diavolerie là dove potete usare un file di configurazione. Non usate XML dove potete usare qualcosa di più semplice (.INI). Non eseguite script scritti in linguaggi di scripting (Ruby, PHP, etc.) per effettuare la configurazione dell’applicazione: è pericoloso.

Ovunque possiate, cercate di fornire dei parametri di configurazione di default ragionevoli e sicuri.

Rendere la configurazione accessibile

Fate in modo che il sistema di configurazione della vostra applicazione sia facilmente accessibile. Piazzate una voce nel menù del desktop manager (Gnome, KDE, Windows Explorer, etc.) e/o una voce nella barra dei menù della vostra applicazione.

Rendere il sistema esplorabile

Rendete la vostra applicazione e/o il vostro sistema facilmente esplorabile. Rendete visibili le funzionalità che sono disponibili nella barra dei menù e nelle dialog box.

Spiegate a cosa servono i vari comandi e le varie opzioni. Nella GUI c’è spazio per due righe di testo.

Inserite dei “tooltip” o delle “tooltip box” con le spiegazioni del caso.

Usate il sistema di documentazione del vostro sistema operativo (“F1”, “Help”, etc.) ed aggiungete una pagina di spiegazioni per ogni elemento del vostro sistema.

La dove è possibile, permettete all’utente di fare i suoi esperimenti senza fare danni. Rendete le operazioni annullabili e dite all’utente che sono annullabili.

Spiegate cosa fa un wizard prima che venga lanciato, in modo che l’utente sappia cosa aspettarsi.

Rendete esplicitamente visibili e verificabili i cambiamenti.

Rendere il sistema comprensibile

Fate in modo che il sistema abbia una struttura comprensibile, sia a livello di struttura “informativa” (“logica”) che di struttura “visiva” (“grafica”).

Se un insieme di dati ha per sua natura una struttura ad albero, rendetela visibile come albero. Non usate una sequenza di elenchi apparentemente privi di relazioni reciproche.

Se un insieme di dati ha per sua natura una struttura ad elenco, rendete visibile questo elenco. Non usate una diavoleria che rende visibile solo una voce alla volta.

Rendete visibili (e comprensibili) le relazioni tra le parti.

Rendere il sistema comunicante

Fate in modo che la vostra applicazione possa comunicare con altre applicazioni, in entrata ed in uscita.

Quasi tutti i sistemi operativi moderni forniscono un apposito sistema di comunicazione interno per questo scopo (Dbus di Linux e cose simili). Usatelo.

Ovviamente, non eseguite comandi che non provengano da fonti affidabili e non inoltrate comandi pericolosi ad altre applicazioni senza aver prima ottenuto l’autorizzazione esplicita dell’utente. Loggate ogni operazione.

Rendere i dati trasferibili

Fate in modo che i documenti creati dalla vostra applicazione siano utilizzabili anche dalle altre applicazioni simili.

Fornite un sistema di esportazione e di importazione dei dati.

Se possibile, cercate di rendere esportabile/importabile anche la configurazione.

Limitarsi alle operazioni necessarie o utili

Nella progettazione e nella implementazione della vostra applicazione, limitatevi a rendere possibili le operazioni che sono realmente necessarie od almeno davvero utili.

Fatevi consigliare dai vostri utenti su questo punto.

Un’applicazione semplice ed essenziale è più facile da implementare e da rendere sicura, è più facile da comprendere e da usare. Inoltre, usa meno risorse ed è più veloce.

Limitare l’uso delle risorse

L’ottimizzazione del codice è l’ultima fase di un processo produttivo ma deve pur sempre essere effettuata.

Cercate di usare meno CPU, meno RAM e meno bandwith possibile.

Questo è particolarmente vero se scrivete codice per dispositivi mobili (smartphone e cose simili).

Limitare l’uso di operazioni in background

Limitate l’esecuzione di operazioni in background al minimo indispensabile. Sottraggono risorse alle operazioni che l’utente sta svolgendo in foreground, a volte fino a rendere il sistema inusabile.

Se proprio dovete svolgere operazioni di questo tipo, per ragioni di manutenzione, cercate di farlo quando l’utente non c’è ed è attivo lo screensaver. Molti sistemi operativi forniscono un evento di sistema per sapere quando parte lo screensaver e le funzionalità necessarie per eseguire task in background senza risvegliare il sistema.

Fate in modo che queste operazioni durino il meno possibile (al massimo qualche minuto), anche a costo di usare tutta la CPU e tutta la RAM disponibile. Se necessario, spezzatele in più task.

Fate in modo che queste operazione vengano eseguite il più raramente possibile (una volta al giorno, al massimo).

Se non potete fare diversamente, fate in modo che usino solo una parte della CPU e della RAM disponibili (con “nice” di Unix, per esempio)

Limitare l’interfaccia al necessario

Limitate le dimensioni dell’interfaccia a ciò che è necessario. Non occupate tutto il desktop se non è necessario. Non fate uso di una “main window” tradizionale se potete facilmente usare una semplice dialog box.

Limitate il numero dei componenti dell’interfaccia al necessario.

Limitate la profondità dei menù e l’affollamento delle dialog box al minimo indispensabile.

Non rinunciate però alla chiarezza ed alla comprensibilità per inseguire l’essenzialità. Se sono necessari quattro livelli di menù per rendere chiara la relazione tra i vari comandi, usate quattro livelli. Se è necessaria una dialog box con 22 elementi per riflettere una realtà complessa, fatene uso.

Se è troppo grosso, taglialo in due

Se la realtà che cercate di rappresentare è molto complessa, cercate di suddividerla in sezioni più maneggevoli. Tre dialog box con sette od otto elementi ognuna sono meglio di una sola dialog box con 22 elementi. Un unico wizard ben organizzato è meglio di tre dialog box indipendenti che trattano lo stesso inscindibile argomento.

Non infastidire l’utente con domande non necessarie

Non chiedete all’utente cose che non sono necessarie. Molte scelte dipendono strettamente da altre. Una volta definito il livello più alto, prendete voi le decisioni dei livelli più bassi.

Informate l’utente, spiegate cosa avete fatto e dategli modo di sovrascrivere le vostre decisioni ma non rompetegli le scatole con domande non necessarie e che lo metterebbero inutilmente in ansia.

Non chiedere all’utente cose che non può sapere

Non chiedete all’utente se una certa operazione è sicura. Non può saperlo.

Cercate piuttosto di spiegare brevemente i rischi e fate la cosa che vi sembra più opportuna dopo aver ottenuto l’autorizzazione dell’utente.

Non chiedete all’utente se il parametro K1 deve avere il valore 7 o 251. Non può saperlo.

Se proprio è necessario, spiegategli dove andare a cercare informazioni. Usate una pagina di documentazione (“help”). Usate dei link al web. Al giorno d’oggi sono quasi sempre raggiungibili.

Prendete le decisioni che vi spettano e chiedete all’utente di partecipare solo quando può farlo.

Rapporto con l’Utente

Non infastidire l’utente con la pubblicità

Mai e poi mai infastidire l’utente con delle dialog box, dei pop-up, delle toast-like windows o altre “pagine pubblicitarie” mentre sta lavorando.

Per la pubblicità c’è il web. Usate quello (ed anche quello senza sommergere l’utente con le vostre pop-up).

Non tentare di confondere l’utente

Presentate sempre ogni cosa per ciò che realmente è.

Se è pubblicità, scrivete in cima alla finestra PUBBLICITA’ a caratteri cubitali.

Se un programma cancella il disco fisso, chiamatelo “distruttore di disco fisso” non “miglior amico dell’utente”.

Se un programma non fa nulla di utile, chiamatelo “programma inutile”, non “grazioso gadget”.

Non tentare di “appioppare” qualcosa all’utente

Mai e poi mai far credere all’utente che deve comprare qualcosa se può decidere liberamente di NON acquistarlo.

Questa si chiama “frode in commercio” ed è punita dalla legge.

Non ingannare l’utente

Mai e poi mai far credere all’utente che un programma fa una cosa diversa da quella che realmente fa.

Se il vostro programma NON serve a rimuovere i worm, non spacciatelo per un worm remover.

Se il vostro programma installa qualcosa, non fate credere all’utente che serve solo a visualizzare un immagine.

Rispettare la volontà dell’utente

Se l’utente vi dice di fare qualcosa, fatelo. È lui il padrone della macchina.

Avvertitelo dei rischi e chiedete conferma, ma fate quello che vi dice di fare.

Informare l’utente

Mantenete l’utente informato delle vostre intenzioni e di ciò che sta succedendo. Avvertitelo di eventuali errori o difficoltà. Non nascondete nulla.

Tuttavia, a meno che non si tratti di qualcosa di veramente grave e/o urgente, cercate di un usare il metodo meno invadente di cui disponete per comunicare con l’utente (una toast-like window, per esempio).

Chiedere conferma per le operazioni pericolose

Chiedete sempre conferma per le operazioni che possono danneggiare il sistema o che possono aprire falle di sicurezza.

Tuttavia, limitatevi a chiedere conferma per le operazioni davvero pericolose e per quelle mai compiute prima. Non infastidite l’utente con continui allarmi.

Non chiedete autorizzazioni ad un utente che è già autorizzato

Se l’utente amministratore del sistema decide di compiere un’operazione pericolosa, pensateci due volte prima di chiedergli di ri-autenticarsi (digitando la sua password) e farsi ri-autorizzare dal sistema. L’amministratore, per definizione, è già autorizzato a compiere queste operazioni e voi dovreste eseguirle senza rompere le scatole. I vostri controlli di sicurezza avrebbero dovuto aver luogo prima, al momento dell’autenticazione dell’amministratore.

Se proprio non sapete resistere, chiedete all’amministratore di ri-autenticarsi solo per operazioni che potrebbero essere davvero la conseguenza di un attacco e per quelle che permettono di installare software o di cambiare la configurazione del sistema in punti davvero critici per la sicurezza.

Rendere visibile il percorso futuro di un’operazione complessa

Quando avviate una procedura che prevede più passi e/o che comporta conseguenze future non del tutto intuitive (una lunga attesa, dei cambiamenti radicali nell’aspetto del sistema, etc.), cercate di rendere chiaro quali saranno i passaggi dell’operazione e quali saranno le sue conseguenze.

Fate uso di un’anteprima della procedura e/o dei cambiamenti, se possibile.

Rendere visibili le operazioni

Ogni volta che apportate una modifica e/o che eseguite un’operazione, cercate di rendere evidente quello che sta succedendo. L’utente si aspetta un feedback visivo. Non lasciatelo privo di questo feedback, se vi è possibile.

Rendere reversibili le operazioni

Se vi è possibile (e quasi sempre lo è), salvate lo stato del sistema e rendete reversibili (annullabili) le vostre operazioni. Gli errori umani sono inevitabili. Fate in modo che non siano anche irreversibili.

Non esporre funzionalità pericolose se non è necessario

Esponete all’esterno solo le funzionalità che devono essere davvero accessibili dall’esterno e comunque assicuratevi che siano accessibili solo agli utenti autorizzati.

In particolare, NON rendete disponibile un linguaggio di programmazione (un interprete di script) all’interno di un programma più complesso se non ce n’è davvero motivo. Soprattutto, non rendete disponibile in questo modo un linguaggio “full-blown” e/o “general purpose” come Ruby, Python o cose simili. Usate piuttosto una versione “stripped-down” di questi interpreti e rimuovete tutte le funzionalità pericolose (accesso al file system e cose simili).

Limitate lo “scope” (“orizzonte visivo”) di questo interprete di linguaggio all’universo rappresentato dalla vostra applicazione. Non concedetegli un accesso al resto del sistema (almeno, non senza avvertire l’utente e chiedere autorizzazione).

Se avete bisogno di un vostro ambiente di esecuzione per i vostri script (CPU, spazio disco, RAM, etc.), allora createvi la vostra macchina virtuale o la vostra sandbox personale ed eseguite i vostri script all’interno di essa, in completo isolamento rispetto al resto del sistema.

Avvertite l’utente e chiedete autorizzazione ogni volta che dovete uscire dalla vostra sandbox e accedere al sistema ospite.

Se proprio dovete rendere disponibili delle funzionalità di scripting come queste, rendetele disabilitabili dalla configurazione e fate partire il sistema con lo scripting disabilitato. Rendete questa configurazione facilmente reperibile e facilmente utilizzabile.

Se è necessario esporre funzionalità pericolose, proteggere l’accesso

Se proprio dovete rendere disponibili delle funzionalità pericolose, assicuratevi che siano accessibili solo agli utenti autorizzati. Nel dubbio, chiedete all’utente di ri-autenticarsi.

Identificare l’utente

Assicuratevi che l’utente a cui concedete di effettuare un’operazione, qualunque operazione, sia davvero la persona che dice di essere.

Affidatevi al sistema di autenticazione/autorizzazione del sistema ospite se esiste. Diversamente, createne uno voi. In ogni caso, identificate l’utente e assicuratevi di gestire in modo corretto le autorizzazioni di accesso.

Usate il sistema di autenticazione più adatto all’applicazione. Non sempre può bastare una coppia username/password.

Registrare le operazioni

Registrate sempre ogni operazione rilevante ed ogni errore. Tutti i sistemi attuali forniscono un ampio e sofisticato supporto al logging. Usatelo.

Registrare gli errori

Registrate ogni errore nel file di log e se avete una mezza idea di cosa può averlo prodotto accodate la vostra spiegazione al messaggio.

Informare gli sviluppatori degli errori rilevati

Cercate di informare gli sviluppatori di tutti gli errori critici. Ovviamente chiedete autorizzazione all’utente prima di spedire messaggi.

Parlare con gli utenti

Cercate di restare in contatto con gli utenti. Ascoltate le loro osservazioni ed i loro consigli. Cercate di capire di cosa hanno bisogno e di soddisfare le loro richieste.

Tuttavia, non delegate a loro l’arduo compito di progettare l’applicazione od anche solo quello di definirne le funzionalità. Non è il loro mestiere.

Implementare ciò che serve

Cercate di implementare tutto e soltanto ciò che serve davvero. Niente lacune e niente fronzoli.

Le lacune obbligano a dei workaround ineleganti e pericolosi.

I fronzoli creano confusione e rallentano il processo di apprendimento.

Rendere visibili i punti deboli

Se siete al corrente di un punto debole, di una falla di sicurezza o di qualunque altro problema, rendetelo visibile e documentatelo. Non nascondete una cosa del genere all’utente.

Conclusioni

E, in conclusione:

Se vedi un errore, correggilo

Questo elenco è brutto, prolisso, disordinato e pieno di ripetizioni ma è pubblicato sotto licenza Creative Commons. Puoi prenderlo, modificarlo, correggerlo, riordinarlo, arricchirlo, ripulirlo e ripubblicarlo dove e come ti pare. Hai solo l’obbligo di dire dove lo hai trovato.

Alessandro Bottoni

L’immagine di copertina è una rappresentazione visiva dei sette principi base del Bushido e proviene da Flickr:

flickr.com/photos/fighter-arts/4128715978/

Ovviamente, è coperta da licenza Creative Commons

Comments
One Response to “Ecologia del Software”
  1. spongeball scrive:

    praticamente tante di queste cose linux le fa già mentre windows il contrario… e proprio per questo chi inizia ad usare linux capisce la differenza e malvolentieri o per niente torna a windows.

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

%d blogger cliccano Mi Piace per questo: