requisiti

Parlare di architettura software ha senso solo quando si tratta di capire il livello di servizio richiesto e dare risposte misurabili ai requisiti. Tutto il resto è fuffa, sostiene Tom Gilb in questo video.

In ogni processo di sviluppo software pragmatico, requisiti e architettura evolvono insieme.

"The Twin Peaks of Requirements and Architecture" è il tema centrale del numero di marzo / aprile 2013 di IEEE Software.

Un backlog è una lista di cose da fare. Nel backlog dello sviluppo software, le cose da fare appartengono a diverse categorie: nuove funzionalità per gli utenti, adeguamenti tecnici, correzione di errori. Anche la riduzione del debito tecnico rientra tra le cose che è opportuno fare.

Un'utile visualizzazione delle diverse tipologie di attività è stata proposta da Claude Aubry.

Ecco una versione italiana del suo quadrante del backlog:

Gli aspetti "non funzionali" di un sistema software, come le prestazioni, i carichi e i volumi da sostenere, la sicurezza, l'usabilità, hanno un'importanza che viene spesso sottostimata.
L'attenzione dei progetti si concentra soprattutto sulle funzionalità, mentre le altre caratteristiche sono trascurate o definite in modo generico sia dagli stakeholder che dagli analisti IT.

Questa disattenzione è rischiosa, perché sono proprio gli aspetti non funzionali (o "attributi di qualità", come vengono chiamati negli ultimi anni) a influenzare e condizionare le scelte architetturali. E quando non vengono presi in considerazione all'inizio possono poi portare a scelte architetturali sbagliate, molto onerose da modificare quando i progetti sono in stato avanzato di sviluppo.

"Functionality and capability are critically important, but the architecture must be driven by the quality attributes. Specifying and addressing quality attributes early and evaluating the architecture to identify risks is key to success", come afferma Mike Gagliardi in un recente webinar del Software Engineering Institute, Architecting in a Complex World.

Interessante numero di Software Engineering Radio con un dialogo - intervista tra Christof Ebert e Frances Paulisch su Lean (software) development: utile complemento al Lean tutorial pubblicato da IEEE Software qualche mese fa, soprattutto per quanto riguarda la gestione dei requisiti in ambito lean.

Il filosofo greco Socrate affermava di essere come un'ostetrica, dato che cercava di portare alla luce le conoscenze che i suoi interlocutori portavano già dentro di sé, ma non avevano ancora chiare, non avevano ancora tirato fuori.

Lo faceva attraverso il dialogo, discutendo, come testimoniato dalle opere pubblicate dal suo allievo Platone. Facendo delle domande. Prima generali, poi via via più approfondite. Come deve fare chi vuole chiarire i requisiti per un sistema da sviluppare o fare evolvere.

Chiarire i requisiti è necessario, per chi li deve soddisfare. Li vogliamo precisi. Ma i requisiti non nascono già chiari, precisi, completi nella testa di qualcuno. Sono sempre il risultato di un dialogo, di un processo di interazione. Non potrebbe essere altrimenti.

Chi chiede il sistema, o la nuova versione del sistema (chiamiamolo “cliente”) ha un'esigenza e la manifesta. Ma non è, se non in casi particolari, un esperto di progettazione dei sistemi, non conosce tutti gli aspetti di cui è necessario tener conto per valutare fattibilità e impatto, non sa quanto possano costare le diverse soluzioni possibili per soddisfare la sua esigenza, non ha risorse infinite.

Il suo interlocutore (chiamiamolo “analista”) ha il compito di aiutarlo a chiarirsi le idee. Di aiutare il cliente a capire i costi e i benefici di ciò che sta chiedendo, i contro e i pro, i rischi e le opportunità. Dialogando.

Condurre il dialogo tra “analista” e “cliente” per chiarire i requisiti è un'arte, non una scienza. Un'arte che si apprende, con lo studio e con l'esperienza. Si tratta di fare le domande opportune, di usare un linguaggio comprensibile anche sugli aspetti meno intuitivi per chi non ha competenze tecniche, di stimolare la riflessione, di accompagnare i ragionamenti.

Per fortuna, alcuni decenni di esperienze nello sviluppo dei sistemi hanno messo a disposizione degli analisti delle tecniche valide, come i workshop sui requisiti, l'analisi degli scenari di operatività utente (casi d'uso), la quantificazione dei livelli di servizio sugli aspetti non funzionali (prestazioni, carichi, sicurezza, …), la valutazione di prototipi delle interfacce utente.

Queste tecniche possono aiutare l'analista a svolgere la propria attività maieutica, a guidare il chiarimento dei requisiti in modo non solo efficace, ma anche rapido ed efficiente, perché il tempo e le risorse che abbiamo a disposizione per chiarire i requisiti sono sempre più limitati.

E sono tutte tecniche basate sul dialogo, sulla formulazione di domande, sull'analisi delle risposte (feedback), sul fare emergere velocemente punti di attenzione e sull'aumento progressivo del livello di precisione e di chiarezza.

Il rapporto tra requisiti, casi d'uso e test è centrale per lo sviluppo software.

L'individuazione e la descrizione dei casi d'uso sono attività molto efficaci per agevolare la scoperta dei requisiti, e per favorire una validazione degli scenari di utilizzo da parte degli stakeholder. Ma i casi d'uso, in sé, non sono requisiti, e certamente non sono sufficienti per scoprire tutti i requisiti.

D'altro lato, la definizione precoce dei test di accettazione è eccellente per eliminare le ambiguità dai requisiti, perché costringe a precisarli. Ma i test non possono essere sostituiti ai requisiti.

Il rapporto tra requisiti, casi d'uso e test (oggetto dei miei corsi "Gestione dei requisiti con i casi d'uso" e "Test di sistema e di accettazione") è descritto in dettaglio da Bertrand Meyer. Vale la pena leggere tutto il suo intervento, di cui riporto il passo centrale:

"The insight, which has significantly improved the practice of software development, is that the regression test suite is a key asset of a project and that tests should be run throughout. The bad advice is to ditch upfront requirements and specifications in favor of tests. The property that tests lack and specifications possess is generality. A test is an instance; a thousand tests can never be more than a thousand instances. [...] the relationship is not symmetric: one can generate tests from a specification, but not the other way around.

The same relationship holds between use cases and requirements. It is stunning to see how many people think that use cases (scenarios) are a form of requirements. As requirements they are as useless as one or ten values are to defining a function. Use cases are a way to complement the requirements by describing the system’s behavior in selected important cases. A kind of reality check, to ensure that whatever abstract aims have been defined for the system it still covers the cases known to be of immediate interest. But to rely on use cases as requirements means that you will get a system that will satisfy the use cases — and possibly little else."

Da anni sono sul mercato numerosi strumenti specifici per la gestione dei requisiti nei progetti di sistema e di software.

Un sondaggio (agosto 2012) di Method & Tools conferma però la sensazione che siano poco usati. Il sondaggio, come quasi tutti quelli fatti via web, è certo poco scientifico, ma la base di 329 risposte è abbastanza significativa.

Cos'è un'insalata? Come dovrebbe essere un'insalata?

Bertrand Meyer prova a dare risposta a queste domande dal punto di vista di un analista che lavori alla specifica dei requisiti software (SRS).

Attenzione alle esigenze e ai requisiti degli utenti? Usabilità dei sistemi?

Un caso da manuale: Trenitalia.

Non voglio parlare del servizio agli utenti sui treni, inqualificabile (e non certo per colpa del personale viaggiante, poveretti).

Neppure del rinnovo delle stazioni, con il peggioramento delle condizioni per i viaggiatori (sempre meno posti a sedere, sparizione delle fontanelle, continui bombardamenti pubblicitari dai monitor, a fronte di poche e tardive segnalazioni utili).

Ciò che trovo davvero incredibile è il nuovo sistema di consultazione dell'orario e di prenotazione via internet.

Non è più possibile vedere il percorso di viaggio con le fermate intermedie.

Non è più possibile sapere se è permesso il trasporto biciclette.

Non è più possibile sapere se è previsto il trasporto di persone con handicap fisici.

Anzi, sì, è possibile. Ma solo sul sito (in italiano) delle ferrovie tedesche:
http://www.bahn.com/i/view/ITA/it/index.shtml

L'ho scoperto grazie a questo articolo.

---

Aggiornamento. Trenitalia torna al vecchio orario. Naturalmente, non un cenno di comunicazione agli utenti del servizio.

---