Archivi categoria: requisiti

Software Quality Requirements

Il numero di IEEE Software di Marzo-Aprile 2008 ha come tema centrale la gestione dei requisiti di qualità.

Tra gli spunti, un confronto tra Tom Gilb e Alistair Cockburn sulla precisazione i requisiti. Gilb sostiene l’esigenza di quantificare, Cockburn ritiene che in un contesto agile non sia il caso di farlo, e che in alcuni casi possa risultare dannoso.
A differenza di quanto normalmente accade, l’esito del confronto non è per nulla conciliatorio, segno di un contrasto profondo tra i rispettivi punti di vista.

CrossTalk, marzo 2008

Nel numero di marzo 2008 di CrossTalk (“The Journal of Defense Software Engineering”, la rivista software dei militari USA), tra le altre cose:

– Un articolo di Ellen Gottesdiener su “Good Practices for Developing User Requirements”. L’aspetto più interessante è un elenco di modelli utilizzabili per rappresentare i requisiti utente.

– Un articolo di David Coe che riporta dati sperimentali, per quanto in ambito universitario, sull’uso degli Use Case Points.

La partecipazione degli utenti ai progetti

Erica L. Wagner and Gabriele Piccoli:”Moving Beyond User Participation to Achieve Successful IS Design” in Communications of the ACM, december 2007

L’articolo mette in luce con estrema chiarezza uno dei nodi principali dello sviluppo software.

“We suggest that rather than fighting human nature by trying to force the participation of user groups throughout a project, we should broaden our thinking about development and implementation methodologies to reflect what happens in practice. We find that in practice user participation can be most powerful after ‘go live’ when users are truly engaged.

[…] we acknowledge it will be difficult to fully engage users before the software begins to affect their daily lives, which are generally at ‘go live.’ Yet, we are not suggesting there is no value in user involvement via prototyping or phased roll-out techniques. When properly implemented, these techniques can help increase communication, provide some valuable feedback in the design process, and generally improve goodwill on the user side. But it is critical to recognize that trying to force engagement of user groups throughout a project goes against human nature. We should therefore expand our thinking about the stages of the systems development life cycle, and incorporate this broadened perspective into whichever methodology is used.
We need to recognize that implementation extends beyond “flipping the switch.” Legitimizing the post-implementation activities that are often kept as a shameful secret — a sign of project failure — will help to manage expectations and avoid much of the conflict that erodes trust between the user community, project champions, and the development team by more naturally mimicking human behavior.

[…] It is time to speak honestly about the gap between our intentions to build working systems and our ability to do so in practice. This gap is typically not caused by a lack of effort on behalf of developers or users, but rather is the result of misdirected efforts. The systems development and implementation process will continue to be overly challenging if we work against the tide by trying to make users fit our theories of how and when they should participate in development initiatives.”

Boehm – Requirements Volatility

Communications of the ACM, October 2006

Barry Boehm One-size-fits-all Methods: the Wrong Solution to new Problems

Requirements Volatility ratings for stable embedded devices are still in the 0.1% to 0.3% per-month range, but the counterpart ratings for rapidly changing competition-driven applications are often in the 10% to 30% per-month range.

L’utilizzo del prodotto fa emergere nuovi requisiti

da “Mondo Digitale” anno V n° 2 – Giugno 2006 – articolo “La comunità virtuale degli esaminatori ECDL”, di Daniela Maria Ricco, Giuseppe Giliberto, Giuliano Russo, pag.51:

“[…]l’uso di strumenti e le modalità di esecuzione dei compiti si influenzano a vicenda. Carroll e Campbell [Carroll J.M., Campbell R.L.: Artifacts a psycological theories: The case of human-computer interaction. In “Behaviour and Information Technology”, 1989 – sic -] hanno messo in evidenza il carattere circolare della relazione artefatti-compiti (task-artifact cycle): le persone svolgono determinati compiti, con maggiore o minore soddisfazione, usando determinati strumenti. I nuovi strumenti, una volta adottati, alterano i compiti per cui vennero progettati e modificano le situazioni in cui i compiti venivano svolti in precedenza. In questo modo lo strumento nuovo crea un nuovo compito e una nuova situazione sociale in cui si svolge il compito. Questi ultimi generano poi a loro volta il bisogno di ulteriori miglioramenti che sarebbero possibili grazie ad una nuova famiglia di artefatti da inventare per svolgere meglio il nuovo compito e così via.”

In “Communications of the ACM”, June 2006, l’articolo “A Systematic Approach in Managing Post-Deployment System Changes”, di David Kang e Roger Chiang, affronta l’argomento in modo più operativo, e fornisce indicazioni utili per un’implementazione organizzativa della gestione dei cambiamenti.

Mary Poppendieck insiste ripetutamente sull’esigenza di passare da una visione per progetti ad una visione di product development.