Cuprum · IDS - Interaction Design Solutions

Cuprum (Cu, il rame nella tavola periodica) è uno degli assistenti costruiti su Alchemy, dedicato a un solo compito: la modellazione dei casi d’uso, basata sullo Use Case 2.0 di Jacobson e Cockburn ed estesa con ciò che ai team serve davvero attorno ad esso.

La chat e il modello appaiono fianco a fianco

Cuprum propone le modifiche nella chat e il modello si aggiorna proprio accanto, così si vede esattamente cosa è cambiato e perché, senza cambiare contesto.

Il pannello chat di Cuprum che propone nuove business rule per un caso d'uso, accanto all'artefatto modificabile nel workspace

Ogni proposta è verificabile prima che venga applicata

Ogni modifica fatta da Cuprum può venir mostrata come un diff esplicito — prima e dopo, fianco a fianco — con un ripristino a un clic, così niente finisce nel modello senza che una persona veda esattamente cosa è cambiato.

La vista diff di Cuprum che mostra le business rule aggiunte dall'assistente, con un confronto prima/dopo e un'opzione di ripristino prima di accettare le modifiche

Quattro modi in cui Cuprum lavora con voi

Crea, ma mai alle vostre spalle

Aggiunge, modifica, rinomina, rimuove. Dite “e se” o “supponiamo” e Cuprum resta a mani ferme, restituendo una proposta invece che una modifica. Questo lo rende un compagno di pensiero, non un pilota automatico, così l’AI slop non si infila mai nel backlog.

Bozza, revisione, apprendimento a richiesta

Trasforma appunti e trascrizioni in una prima bozza. Chiede cosa manca o è incoerente. Chiedete “a che punto sono?” o “come si usa X?” in qualsiasi momento e ottenete una risposta costruita sul vostro modello, non un tutorial generico.

Uno sport di squadra, non un assolo

Più persone lavorano sullo stesso modello insieme a Cuprum, nello stesso momento. I commenti restano proprio dove nasce la discussione, e ogni suggerimento valutato modella il modo in cui Cuprum lavora con il vostro team la volta successiva.

Si inserisce in come lavorate già

Raggiungibile da dentro una lavagna Miro invece che solo dalla propria interfaccia. Esporta sui vostri template. Parla la lingua che il vostro team usa davvero.

Perché la modellazione dei casi d’uso ripaga

Comprare certezza prima di comprare codice

Il linguaggio di business fa discutere finalmente della stessa cosa chi finanzia il progetto e chi lo costruisce, prima del terzo mese, non dopo. Criteri di accettazione abbastanza specifici da firmare. Casi limite portati alla luce mentre costa ancora poco correggerli, proprio quelli che decidono in silenzio se il prodotto finito sarà piacevole da usare o se avremo evitato sorprese spiacevoli.

Un buon modello dei casi d’uso consente di verificare se si è capito il problema prima di scrivere una riga di codice, il primo dei tre pilastri fondamentali dello sviluppo software: capire il problema, costruire il software e verificare che risolva il problema.

Sapere quando è lo strumento giusto

Ripaga su sistemi interattivi e guidati dagli attori, dove più stakeholder devono concordare e la gestione dei fallimenti conta quanto il percorso principale. Metodo da evitare per puri algoritmi o un’idea che ha ancora bisogno di un prototipo più che di una specifica. Una volta scritto, lo stesso modello dei casi d’uso serve a vari soggetti interessati: gli analisti che lo validano, architetti e sviluppatori che costruiscono a partire da esso, i tester che derivano i test di accettazione direttamente dagli scenari.