BPMN, cliente, psicologia, stakeholder, utente

L’analisi dei processi e la rimozione degli utenti

Durante le attività di formazione possono venire alla luce cose strane, come avvenne anni fa in un Ente pubblico.

Stavo tenendo una sessione del corso “Analisi dei processi di business con BPMN”. BPMN – Business Process Model and Notation – è la notazione standard internazionale per rappresentare i processi organizzativi.

Avevo, come sempre nei miei corsi, proposto una serie di esercitazioni su casi pratici di modellazione dei processi, relativi ai processi che prevedevano un’interazione dell’Ente con soggetti esterni (cittadini, aziende).

In processi di questo tipo (BPMN li chiama “processi collaborativi”) lo scambio di comunicazioni tra i soggetti che interagiscono tra loro è ovviamente centrale.

I partecipanti alla sessione erano parecchi, e come faccio abitualmente li avevo organizzati a coppie per svolgere le esercitazioni.

Analizzando e discutendo i risultati degli esercizi si notava una cosa comune: tutte le coppie avevano modellato in dettaglio il processo, evidenziando con cura le attività di ogni ufficio e le comunicazioni. Venivano dettagliate sia le comunicazioni tra gli uffici interni dell’Ente che quelle con altri Enti della Pubblica Amministrazione.

Nessuna coppia aveva invece rappresentato le interazioni con gli utenti, cioè coloro che chiedevano i servizi all’Ente. Intendiamoci: le richieste che davano inizio all’iter delle pratiche erano indicate; ciò che mancava completamente erano le comunicazioni da e verso gli utenti, che semplicemente non venivano presi in considerazione in quanto partecipanti al processo. Una vera e propria rimozione degli utenti.

Il caso, cioè che tutti i partecipanti a quella sessione del corso avessero compiuto la medesima omissione, era estremo. L’errore invece è più frequente, e accade anche nel settore privato, non solo nella Pubblica Amministrazione: modelliamo il processo dal punto di vista della nostra organizzazione, tenendo in poca considerazione le esigenze e le possibili criticità che deve affrontare chi interagisce con noi.

La rimozione degli utenti (o dei clienti) è un errore che si paga, perché si rischia di trascurare aspetti critici dal punto di vista di chi è esterno alla propria organizzazione, con ricadute negative sul livello di servizio del processo.

Analisi dei processi di business con BPMN – https://corsi.analisi-disegno.com/corsi/corso-analisi-processi-bpmn/

analisi, intelligenza artificiale (AI)

Usare l’intelligenza artificiale nelle attività di analisi

Tutti usiamo gli strumenti di intelligenza artificiale generativa, quella che nel mondo viene siglata come AI (nel Bel Paese, IA).

Siamo portati a usarli in molti modi. Quando facciamo le ricerche con Google. Quando usiamo una delle tante app che ci capita di usare – oggi molte app integrano funzionalità AI, quantomeno per non sembrare obsolete. E, naturalmente, quando usiamo i Chatbot per dialogare con i LLM (Large Language Models).

Nelle attività di analisi dei sistemi i Chatbot sono uno strumento utile. Che, come tutti gli strumenti, può essere usato bene o male, meglio o peggio.

Ma l’AI (i Chatbot, gli LLM) è uno strumento ad alto potenziale, quindi i suoi effetti possono essere molto positivi, oppure no. Va usato sapendolo usare, con maestria. Perché altrimenti può portare fuori strada.

Ci sono infatti alcune caratteristiche dei Chatbot che spingono a usarli sempre di più.

L’utilizzo è molto semplice, anche per i bambini e per chi per incapacità potrebbe usarli a proprio danno. Danno risposte con un linguaggio chiaro e comprensibile. Sono progettati per soddisfarci, per darci ragione, per confermarci nelle nostre opinioni e nei nostri ragionamenti. Queste caratteristiche sono rischiose, sia per gli individui che per la società.

Ma per l’analisi dei sistemi i Chatbot e i LLM sono estremamente utili, se li si usa in modo appropriato. E si può imparare a usarli bene.

Il mio corso “AI per analisti IT – L’intelligenza artificiale generativa al servizio dell’analisi” – https://corsi.analisi-disegno.com/corsi/ai-per-analisti-it/ – è strutturato in due parti.

Nella prima parte del corso vengono presentati e sperimentati i pattern di Prompt Engineering utili per formulare le richieste ai LLM in modo da ottenere risposte adeguate. Sono pattern che possono essere utili in ogni ambito, professionale o no, e che costituiscono la base per ottenere risposte adeguate alle proprie esigenze.

Nella seconda parte viene poi approfondito l’uso degli LLM nelle attività proprie degli analisti IT: la gestione dei requisiti, la definizione dei processi, la specifica delle funzionalità, la modellazione dei dati, la progettazione dei prototipi di interfaccia utente, la definizione dei casi di test funzionali.

comunicazione, intelligenza artificiale (AI)

Scrivere con l’aiuto dell’AI? Dipende da cosa si vuole

Scrivere con l’aiuto dell’AI è comodo, veloce, ci permette di non pensare troppo. E questo è il punto.

A volte dobbiamo produrre un documento poco importante. Poco importante in assoluto, o poco importante per noi. In questi casi l’AI è utile.

Altre volte dobbiamo o vogliamo scrivere un testo – anche se minimo, un email, un messaggio – che ci importa, che ci interessa, che vogliamo esprima il nostro pensiero.

Anzi. A volte (spesso) è proprio scrivendo che il nostro pensiero si forma, proprio mentre cerchiamo di trovare le parole per esprimerlo. Addirittura, per molti, è l’atto fisico di scrivere su carta che contribuisce a ragionare, ancora meglio che digitando su una tastiera.

Delegare la scrittura all’AI, se quello che vogliamo scrivere ci interessa, può significare delegare il pensiero, il ragionamento. Verrà fuori un testo pulito – l’AI compone testi corretti nella grammatica e nella sintassi – ma certamente meno personale di quello che avremmo scritto noi.

Un articolo di Mike Elgan su Computerworld mette anche in guardia su qualche rischio aggiuntivo: “How AI is changing your mind“: https://www.computerworld.com/article/4144537/how-ai-is-changing-your-mind.html

Comunque l’AI c’è, e scrivere con l’AI può essere comodo e utile, soprattutto quando dobbiamo produrre un documento poco importante per noi. Ma quando la usiamo conviene usarla bene, e controllare i risultati che ha prodotto prima di pubblicarli come nostri.

È quello che insegno nei miei due corsi sull’AI:

“Prompt Engineering – usare al meglio l’AI generativa”, è rivolto a chiunque la usi, e illustra i pattern più utili per sfruttarla in modo efficace – https://corsi.analisi-disegno.com/corsi/corso-prompt-engineering/

“AI per analisti IT” è invece il corso specifico per l’uso dell’AI da parte di chi sviluppa sistemi software – https://corsi.analisi-disegno.com/corsi/ai-per-analisti-it/

analisi, intelligenza artificiale (AI), software engineering

Gli agenti AI, le specifiche di analisi e l’organizzazione dello sviluppo

L’uso degli agenti AI per lo sviluppo software porta a un cambiamento profondo nel software engineering. Anche se la dimensione, gli ambiti e gli impatti di questo cambiamento non sono ancora del tutto chiari.

La trasformazione riguarda aspetti sia tecnici che organizzativi, impatta sui ruoli, le competenze richieste alle persone, le metodologie.

I punti aperti sono molti, ed è difficile formulare previsioni sul futuro. Ma alcune domande importanti stanno prendendo corpo, come è emerso dai resoconti dell’incontro su “The Future of Software Engineering” organizzato da Thoughtworks.

Ciò comunque appare chiaro è che le attività di analisi dei sistemi, in particolare la definizione delle specifiche, stanno assumendo un ruolo ancora più essenziale di quello, già importante, che rivestivano nell’ingegneria del software tradizionale.

È il tema centrale del mio corso “AI per analisti IT”: https://corsi.analisi-disegno.com/corsi/ai-per-analisti-it/

intelligenza artificiale (AI), software engineering

LLM e Software Engineering

Secondo Dario Amodei, CEO di Anthropic (l’azienda di Claude) gli LLM saranno entro pochi mesi in grado di svolgere in autonomia ed efficacemente il grosso delle attività di software engineering. Già oggi, ha affermato in un incontro recente, i progettisti della mia azienda delegano ai modelli quasi tutte le attività di realizzazione.

Ma l’ingegneria del software (e dei sistemi) non è solo realizzazione. Restano centrali la comprensione delle esigenze, l’analisi dei processi organizzativi in cui i sistemi vanno integrati, la definizione dei requisiti del sistema da realizzare, la valutazione sui pro e sui contro delle ipotesi alternative di progettazione.

Tutti temi trattati nel mio corso “AI per analisti IT”: https://corsi.analisi-disegno.com/corsi/ai-per-analisti-it/ , dove vengono spiegate le tecniche per usare il supporto degli LLM nelle attività di analisi e progettazione.

Qui il video dell’incontro a Davos, condotto da The Economist con Dario Amodei e con Demis Hassabis di Google:

agile, analisi, architettura software, UML

Tre interviste interessanti

Tre interviste interessanti:

Kent Beck (ideatore di Extreme Programming, del Test Driven Development e di molte pratiche che caratterizzano i processi agili):

Grady Booch (che ha dato contributi fondamentali all’approccio Object Oriented ed è uno degli autori di UML – Unified Modeling Language):

Martin Fowler (ideatore dei Pattern di analisi e delle tecniche di Refactoring):

analisi, requisiti

Controllo automatico delle specifiche dei requisiti

Comprendere e specificare in modo adeguato i requisiti di un sistema è essenziale. Essenziale per essere sicuri di aver capito nel dettaglio le esigenze di chi vuole il sistema e di chi dovrà usarlo. E per fornire indicazioni precise a chi dovrà implementare i requisiti e verificare (con il testing) che siano stati soddisfatti.

Quindi la formazione degli analisti che devono lavorare sui requisiti è necessaria (https://corsi.analisi-disegno.com/), ma non è sufficiente a garantire che le specifiche dei requisiti prodotte nei progetti siano sempre adegate.

Ma come verificare se le specifiche dei requisiti sono adeguate? Se rispettano i criteri (prive di ambiguità, complete, … – https://analisi-disegno.com/2024/05/27/come-scrivere-i-requisiti-la-guida-di-incose/) che vengono considerati fondamentali per garantire la qualità dei requisiti?

Un articolo su IEEE Computer ripercorre la storia dei tentativi di costruire strumenti automatici per il controllo della qualità dei requisiti:

“Requirements Specification Automated Quality Analysis: Past, Present, and Future“, di Dylan Porter, Joanna F. DeFranco, Phil Laplante.

casi d'uso

Casi d’uso 3.0

Ivar Jacobson, l’ideatore del concetto di Casi d’uso (Use Cases) ha pubblicato un nuovo aggiornamento alla teoria – poche innovazioni, ma qualche chiarimento utile.

Lo spunto per la nuova pubblicazione deriva dalla collaborazione di Jacobson con Alistair Cockburm, altro autore che aveva contribuito a diffondere il concetto di Caso d’uso.

I due hanno pubblicato un breve articolo, “Use Case Foundation”, che sintetizza i concetti fondamentali della tecnica, con una definizione di Caso d’uso opportunamente semplificata:

A use case is all the ways of using a system
to achieve a goal of a particular user.

L’articolo “Use Case Foundation” si può leggere qui e qui.

Jacobson ha anche pubblicato un ebook, che elabora l’aggiornamento teorico “Use Case 3.0” e che può essere richiesto sul sito della sua azienda.

software engineering

SWEBOK 4.0

La versione 4.0 della “Guide to the Software Engineering Body of Knowledge” è stata pubblicata dalla IEEE Computer Society.

Il Software Engineering Body of Knowledge (SWEBOK) è un insieme di linee guida e di pratiche che definiscono le competenze e le conoscenze necessarie per i professionisti nell’ingegneria del software.

Copre tutti i vari aspetti dello sviluppo software, e serve come riferimento per la formazione e la certificazione dei professionisti, promuovendo standard elevati e una comprensione comune delle pratiche di ingegneria del software.

La nuova versione comprende importanti aggiornamenti sulla definizione delle architetture software, sulla sicurezza e sulle pratiche attuali, come l’uso dell’intelligenza artificiale.

La si può scaricare a questo indirizzo: https://www.computer.org/education/bodies-of-knowledge/software-engineering/v4https://www.computer.org/education/bodies-of-knowledge/software-engineering/v4