Casi d’uso, inclusioni, estensioni

La mia guida alla scrittura dei casi d’uso è sempre molto usata, così come la relativa template.

Periodicamente ricevo delle richieste di chiarimento su aspetti particolari, e la più recente contiene una serie di domande interessanti, che meritano risposte pubbliche.

  • La verifica della  pre-condizione per un caso d’uso è automatica, oppure è necessario inserire all’inizio dello scenario dei passi per la sua verifica?
    Non è automatica, nel senso che non viene effettuata automaticamente da uno strumento; si dà per implicita e non va descritta nel testo degli scenari.
  • Posso documentare i casi d’uso “di estensione” e quelli “di inclusione”  con lo stesso template utilizzato per documentare qualunque altro caso d’uso?
    Sì.
  • Come qualunque altro caso d’uso, quelli “di inclusione” hanno le loro pre-condizioni e trigger ( stimolo di attivazione) che devono verificarsi affinché possano partire? Oppure quando richiamati dal caso d’uso base, partono direttamente?
    I casi d’uso di inclusione non sono casi d’uso veri e propri, ma solo frammenti di caso d’uso. Quindi vengono sempre attivati da altri casi d’uso.
  • Come qualunque altro caso d’uso, quelli di “estensione” hanno le loro pre-condizioni e trigger ( stimolo di attivazione) che devono verificarsi insieme alla relazione di extend affinché possano partire? Oppure quando richiamati dal caso d’uso base, viene verificata solo la condizione di extend?
    Anche i casi d’uso di estensione sono solo frammenti di casi d’uso, ma a differenza di quelli di inclusione non vengono “richiamati”.  Il caso d’uso base ignora le proprie estensioni, definisce solo degli extension point a cui i casi d’uso di estensione fanno riferimento.
  • La verifica della condizione di extend è automatica, oppure è necessario inserire dei passi per la sua verifica, all’inizio dello scenario del caso d’uso di estensione ?
    Anche qui, la verifica non è automatica, ma si dà per implicita.
  • La precondizione e la condizione di extend possono coincidere(stessa condizione), in alcune situazioni?
    Le precondizioni vanno definite per i casi d’uso base, e specificano una condizione necessaria per raggiungere l’obiettivo del caso d’uso. Ogni caso d’uso “reale” (base) ha un obiettivo da conseguire, mentre i frammenti di caso d’uso (inclusioni, estensioni, specializzazioni) non hanno obiettivi autonomi propri, sono semplicemente porzioni di attività che si preferisce descrivere in modo separato. Quindi definire precondizioni per i frammenti di caso d’uso è una forzatura.
  • Nel documentare il caso d’uso di estensione con il template, posso aggiungere un’apposita sezione in cui riportare la condizione di extend?
    Sì, anche se io preferisco usare per questo il primo passo del relativo scenario.
  • Posso inserire all’interno di un caso di estensione più comportamenti, uno per ogni extension point del caso d’uso base?
    Ogni caso d’uso di estensione è collegato ad un unico extension point del caso d’uso base a cui si riferisce.
  • Se ho un caso d’uso di estensione con più comportamenti, dovrò utilizzare una pre-condizione per ogni scenario di comportamento oppure un unica precondizione per tutti? In altri termini la precondizione ha senso solo a livello di caso d’uso oppure anche per ogni singolo comportamento previsto all’interno del caso d’uso di estensione?
    La precondizione ha senso solo a livello di caso d’uso complessivo.
  • Cosa intende quando afferma che il caso d’uso è completo? ( paragrafo 4.3.3 e 6.2 di “Linee guida UML-Casi d’uso)
    Un caso d’uso è completo quando in caso di successo raggiunge il suo obiettivo, e quando, anche in caso di insuccesso, lascia comunque il sistema in uno stato consistente.

 

L’illusione del controllo

Lo stile da pubblicità comparativa, inaugurato nel software design dal Manifesto Agile (è meglio X rispetto a Y, è meglio W rispetto a Z, …) è ancora attuale.

Un uso recente in I Prefer This Over That di Elizabeth Endrickson:

I prefer:

  • – Recovery over Perfection
  • – Predictability over Commitment
  • – Safety Nets over Change Control
  • – Collaboration over Handoffs

Endrickson spiega che la realtà dello sviluppo, del rilascio e dell’uso dei prodotti è sempre più dinamica di quanto pensiamo, anche quando ci illudiamo di controllarla tramite processi ben definiti e che riteniamo affidabili. Le sorprese sono comunque dietro l’angolo.

“When we design processes that attempt to corral reality into a neat little box, we set ourselves up for failure. Such systems are brittle. We may feel in control, but it’s an illusion. The real world is not constrained by our imagined boundaries. There are surprises just around the corner.

We can’t control the surprises. But we can be ready for them.”

Progettare database NoSQL

La progettazione dei DB relazionali segue tecniche consolidate, che bilanciano criteri di efficienza e manutenibilità / evoluzione nel tempo.

Al contrario, la progettazione dei database NoSQL viene perlopiù effettuata puntando unicamente sulle prestazioni. Ma si possono adottare correttivi per migliorare anche la gestione aziendale dei database NoSQL, argomenta Jack Vaughan in “New thinking needed in IT to make NoSQL data modeling process work“.

Product manager – responsabile di prodotto

Quali sono le responsabilità di un Product Manager? Cosa lo differenzia da un responsabile di progetto? In quale posizione della gerarchia organizzativa dovrebbe trovarsi?

E soprattutto, quali caratteristiche, quali competenze bisogna possedere per essere un buon responsabile di prodotto? Serve una formazione appropriata, sostiene Ellen Chisa in “Evolution of the Product Manager“, ACM Queue, october 2014.

Criticità dei backup

I backup sono necessari, e sono critici sia per i singoli individui che per le organizzazioni. Figuriamoci per uno stato.

L’Estonia, che ha già subìto attacchi informatici nel 2007, si sta preparando a fronteggiarne altri possibili in futuro, come racconta questo articolo di The Economist: “How to back up a country“.

Alcune delle lezioni apprese dagli estoni in questo progetto sono familiari, anche se ardue da mettere in pratica:

“the better data and networks are organised, the better the system is documented, and the more standardised and up-to-date the software, the easier it is to back up and restore.”

Exploratory Testing 3.0

Una ridefinizione della pratica di testing esplorativo è stata proposta da James Bach e Michael Bolton , per superare la distinzione tra  il “testing guidato da script” e, appunto,  il “testing esplorativo”:

we now define all testing as exploratory.  Our definition of testing is now this:

“Testing is the process of evaluating a product by learning about it through exploration and experimentation, which includes: questioning, study, modeling, observation and inference, output checking, etc.”

Secondo il loro punto di vista, il testing guidato da script può essere solo uno strumento tattico da usare in particolari situazioni, ma è come un ospite in casa d’altri, un elemento estraneo al vero e proprio testing.

di Adriano Comai, per lo sviluppo software.