Il BusinessAs is Modeling con UML

Ing. R. Turco

Copyright 2003 – R. Turco

1
Introduzione
Ogni attività umana, che è orientata alla realizzazione di un prodotto o di un servizio, ha dietro
di sé un’organizzazione, delle metodologie, delle procedure operative, degli strumenti ed un
workflow lavorativo.

Tutto questo costituisce un processo produttivo che, nell’ambito dell’organizzazione in gioco,

può essere più o meno formalizzato.

Lo studio dei processi produttivi software fa parte di quella scienza umana che è denominata
“Ingegneria del software”.

L’ingegneria del software è, in sostanza, una disciplina che, da punti di vista diversi,
tecnologico, manageriale, matematico ed economico, cerca di controllare quanto più è
possibile, tutte le variabili in gioco del processo produttivo del software.

Il suo obiettivo finale è, quindi, quello di eliminare o di ridurre al massimo le componenti

artigianali del processo produttivo per giungere ad una maggiore sistematicità, automazione,
ripetibilità della produzione del software.

Il software, difatti, è sviluppato, non è fabbricato.

Lo sviluppo software, quindi, potrebbe sembrare come il “gioco dei dadi”: sappiamo lanciarli
ma non sappiamo quale sarà il risultato del loro lancio! Difatti, in modo assoluto, non è
possibile dire quanto tempo durerà un progetto software o quale sarà la sua qualità o se avrà
successo.

Non esiste, quindi a priori, nessuna garanzia di successo, ma seguendo un approccio

metodologico opportuno si riesce, in realtà, a tendere al successo, in base ad azioni e check,
per successive approssimazioni e iterazioni.

E’ evidente che, fin quando, si ha a che fare con “opere d’intelletto”, come è per l’appunto la
produzione del software, non si può ottenere una sistematicità al 100% e si sarà di fronte,
almeno nel 20% dei casi, all’abilità del programmatore, alla sua genialità, alla sua competenza.

L’ideale, come sempre, si ottiene dalla giusta misura tra metodo, sistematicità, competenza e
genialità.

Se da una parte, nelle fasi innovative, la genialità e la competenza possono rappresentare

l’unico mezzo per fare un salto tecnologico che possa permettere una competitività maggiore,
negli altri casi di normale routine, è necessario mettere in campo una certa sistematicità,
finalizzata ad un collettivo che opera allo stesso modo, all’abbattimento delle criticità delle
varie fasi produttive, a misure per effettuare dei check di qualità, di avanzamento, etc.

La sfida, quindi, dell’ingegneria del software è ogni giorno accettata da quelli del settore per
progettare il sistema giusto, valutare, pianificare, dimensionare, etc.

Sebbene negli anni siano stati fatti enormi passi avanti, specie con l’Object Oriented, la
modellazione dei sistemi e la standardizzazione di linguaggi come UML, etc, ancor oggi può
essere difficile rilasciare al cliente finale il “sistema giusto”.

Va, quindi, messo a punto un metodo per arginare, sin dal primo momento, tale rischio. Il
problema è enormemente sentito nei progetti di riguardevoli dimensioni e con un numero
medio-grande di persone coinvolte.

2
Gli elementi critici di un processo produttivo
Esistono essenzialmente tre elementi critici, che “minano” la sistematicità della produzione del
software, ma che, se ben controllati, si trasformano nel “triangolo del successo” di un
progetto (fig. 1).

Stackholder

Processo Linguaggi e
strumenti

Fig. 1

Ogni vertice del triangolo è una criticità, a cui sono associati un certo numero di rischi ognuno
di entità e peso diverso, variabili nel tempo e dipendenti dal contesto e dalle condizioni al
contorno in gioco.

I provvedimenti presi per arginare le tre criticità determineranno l’efficacia dell’organizzazione

per il raggiungimento degli obiettivi e delle soluzioni giuste.

L’efficienza, invece, dovrà ottenersi col continuo miglioramento del processo produttivo,
“inizialmente progettato” ad hoc alle proprie esigenze e a quelle del cliente e/o del mercato
target.

Stakeholder

Gli stakeholder sono tutte le persone, in diversi settori e competenze, che possono influire sul
progetto direttamente o indirettamente: dal cliente al fornitore, dalla logistica alle strategie.

I motivi di fallimento riconducibili agli stakeholder sono:

 necessità del cliente mal comprese (“il sistema giusto”);
 requisiti che il cliente cambia troppo spesso;
 risorse fornite dal cliente non sufficienti;
 cliente che coopera scarsamente sui requisiti e su pianificazioni accettabili;
 clienti con attese non realistiche;
 sistema che non porta più benefici al business del cliente;
 skill delle persone del progetto non adeguate alle tecnologie, metodologie in gioco;
 fornitori non adeguati;
 organizzazione non adeguata;
 logistica non adatta;
 strategie scelte non adeguate;
 etc.

3
Per gli skill interni al progetto, Brooks (1987) afferma: “Ottimi progetti sono dovuti ad ottimi
sviluppatori” (E’, difatti, il prodotto alla fine che viene consegnato e deve funzionare come
serve al cliente!).

Brooks dice che un progetto dovrebbe:

 procurarsi degli ottimi sviluppatori (meglio se interni);
 fornire una formazione continua agli sviluppatori;
 incoraggiare uno scambio continuo, una cultura uniforme metodologica-tecnologica;
 rimuovere agli sviluppatori ostacoli e attività collaterali;
 offrire un ambiente stimolante;
 allineare, quanto possibile, gli interessi della persona con quelli dell’organizzazione;
 enfatizzare il lavoro di gruppo.

Altri suggerimenti vengono anche dall’XP [DR8].

Inutile dire che in realtà il progetto non dipende solo da ottimi skills interni: commerciale,
project manager, business analyst, progettisti, sviluppatori, collaudatori, technical writer,
installatori, etc. Ma anche da altri settori:
 la logistica (stanze, hardware, software, licenze, libri e manuali,tools etc);
 dal front-end progettuale/commerciale che deve isolare gli sviluppatori dal cliente;
 dall’assistenza tecnica;
 etc.

In ogni caso è elevato il numero di insuccessi dovuti a “necessità del cliente mal comprese”.

Ci poniamo come obiettivo, nel seguito, di analizzare un metodo per arginare tale rischio.

Processo produttivo
Cos’è un processo produttivo?

Un modello di processo permette:

 di stabilire la sequenza delle attività;
 di stabilire gli input e gli output di ognuna di esse;
 di assegnare le attività (responsabilità) alle persone;
 di stabilire criteri per monitorare lo stato di avanzamento delle attività, misurarne i
risultati e pianificare i progetti futuri.

Non esiste un processo standard che tutte le aziende possono seguire. Ogni azienda deve
trovare il proprio modello, seguirlo e migliorarlo nel tempo.

Il processo, inoltre, deve essere allineato con i mezzi, lo stato culturale ed il Know-how
dell’azienda e alle aspettative del cliente: né troppo avanti nel tempo, né obsoleto. Al crescere
del Know-how deve essere aggiornato.

Un processo dipende anche dalle dimensioni di un progetto. Un progetto di piccole dimensioni

non ha un forte bisogno di un processo produttivo formalizzato.

La formalizzazione del processo diventa una necessità per progetti di dimensione medio-
grande. Basta solo pensare alla rete di comunicazione che potrebbe essere necessaria in
assenza di formalizzazione di procedure, standard, etc.

Miglioramento dei processi nello sviluppo del software

ISO 9000
Il concetto base dello standard ISO 9000 è: “Un buon processo è una buona premessa per
ottenere un buon prodotto o un buon servizio”.

L’interesse dello standard è, quindi, sul processo produttivo.

4
Per l’ISO 9000 un’azienda deve tracciare con delle procedure come intende operare e, poi,
deve dimostrare di operare nel modo descritto nelle procedure stesse.

La finalità è ottenere un processo di qualità, secondo una metodologia che si riassume in:
Plan, Do, Check, Act, cioè pianificazione, azione, verifica, provvedimenti.

In altri termini l’ISO 9000 è uno standard che favorisce un processo iterativo, con feedback di
controllo per poter decidere un piano di miglioramento ogni volta.

Le tecniche di valutazione della maturità del proprio processo è sempre basato sul Capability
Maturity Model (CMM).

CAPABILITY MATURITY MODEL

Il CMM (Capability Maturity Model) è un modello introdotto dal Software Engineering Institute
(SEI) nel 1995.

Il modello permette di valutare il livello di maturità del proprio processo produttivo attraverso
delle domande.

I livelli di maturità definite dal CMM sono:

 Livello 1: iniziale
Processo non predicabile e non disciplinato, dipendente dalle persone presenti;
 Livello 2: ripetibile
Gestione del processo ripetibile con possibilità di prevedere costi, tempi
 Livello 3: definito
I processi di gestione e ingegnerizzazione sono specificati e seguiti
 Livello 4:gestito
Sono introdotte delle metriche per la valutazione ed il controllo del processo
 Livello 5: ottimizzato
Il processo è possibile migliorarlo ed è in evoluzione permanente

Col CMM esistono anche procedure di auto-valutazione (self-assessment), documentate dal

SEI.

Bisogna effettivamente, in modo critico, chiedersi se al 100% è possibile rispondere che un

certo livello lo si soddisfa pienamente.

Per passare da un livello all’altro potrebbero servire anni, ma non è certo ammissibile rimanere
sempre sullo stesso livello. D’altra parte il tempo rende le tecnologie e le metodologie
antiquate e, quindi, si può retrocedere nei livelli!!

Il principio è che: “Deve esistere un continuo tentativo di migliorare il proprio processo

produttivo”.

Linguaggi e strumenti

Il terzo elemento critico necessario da gestire è l’adozione di un linguaggio di modellazione e di

uno strumento al supporto di esso.

Attualmente esiste come linguaggio lo standard UML 1.4 che fornisce notazioni e semantica
dichiarativa (quali sono i bisogni oltre che come si procede per soddisfarli).

Con l’UML si possono creare modelli, visuali e non, con cui rappresentare il problema da
risolvere e documentare il tutto.

L’UML è uno strumento di comunicazione tra le persone del progetto e tra cliente e progetto.

5
L’UML da un insieme di viste del problema ed ha vari livelli di astrazione. Non sempre è
efficace. Spesso alcune viste non sono integrate. Tuttavia al momento è il miglior linguaggio
disponibile.

Oltre al linguaggio serve un CASE (Computer-Assisted Software Engineering) che permetta di

usare l’UML per creare modelli e che utilizzi un Repository dove centralizzare e condividere i
modelli con accesso multi-utente.

Il sistema giusto
Uno dei fattori di criticità, come abbiamo visto, è costituito dagli stakeholder. In [DR8] sono
discussi molti di essi.

Qui si vuole approfondire, attraverso una tecnica di risoluzione, uno dei tanti rischi legati agli
stakeholder; cioè la necessità di comprendere le esatte esigenze del cliente finale (end-user),
per poter realizzare “il sistema giusto”.

E’ in pratica uno dei rischi operativi da saper gestire.

Perché è un rischio?

Il problema è sentito maggiormente nei progetti di grosse dimensioni, quando, cioè, nel
tentativo di creare una “catena di produzione” si aggiungono gli sviluppatori ma ognuno di essi
non possiede una “visione generale”, ma ha solo il compito di implementare un insieme di
librerie, classi, componenti definite da un analista.

In questo caso gli sviluppatori, sulla base solo di qualche riunione, potrebbero comunque non
avere chiare tutte le reali esigenze del cliente, specie se le informazioni risiedono
essenzialmente in testa al cliente o a qualche analista.

Ognuno di questi sviluppatori potrebbe prendere delle piccole decisioni sul prodotto, che non
producono “bugs” ma che alla fine condizionano la flessibilità del sistema rispetto alle possibili
situazioni di business già prevedibili in generale.

Business as is Modeling - BaiM

Per capire che sistema costruire occorre focalizzarsi sul business del cliente com’è nella realtà e
richiede un’attiva partecipazione del cliente stesso.

La partecipazione attiva del cliente dovrebbe tendere a chiarire le strategie di business

dell’azienda in modo da poter introdurre nel prodotto la giusta flessibilità ed la giusta riusabilità
[DR7][DR9].

Per individuare “il sistema giusto”, il problema è, quindi, di capire:

 come il sistema darà valore al lavoro del cliente finale;
 in quale ambiente verrà rilasciato il sistema;
 chi userà il sistema (ruoli, responsabilità);
 come verrà usato il sistema;
 in che circostanza verrà usato il sistema.

Una metodologia che si occupa di analizzare questo è il “Business as is Modeling” (BaiM) che,
attraverso l’UML, ha come obiettivo di tracciare il modello del business del cliente.

Vantaggi del BaiM

Uno sviluppo è influenzato (vedi [DR8]) da almeno due constraint:
 il costo;
 la qualità

Usando il BaiM si ottengono i seguenti vantaggi sui costi:

6
  si ottiene il sistema giusto subito (“Get it right the first time”);
 si “accede” sempre agli utenti di business, perché le loro informazioni sono state
tracciate;
 i “bugs” di requisiti errati vengono individuati anticipatamente;

Usando il BaiM si ottengono i seguenti vantaggi sulla qualità:

 La struttura del software è in grado di assorbire meglio i cambiamenti di business,
anche perché la flessibilità è stata data al software là dove era prevedibile un
cambiamento o un ampliamento del business.
 Lo sviluppo del sistema è coerente, perché tutti hanno la stessa conoscenza del
business, della sua evoluzione e del glossario in gioco;
 Il BaiM diventa una leva per definire e migliorare il processo e la sua qualità.

Il metodo del BaiM

La notazione UML adottata dal BaiM è quella nella table 1.

Al di là della notazione particolare (Stereotipi o icone predefinite), il BaiM dell’UML utilizza:

1. Business Use Case Diagram;
2. Business Activity Diagram;
3. Business Class Diagram;
4. Business Interaction Diagram.

Business Use Case Diagram

Il Business Use Case Diagram (figure 1) rappresenta l’interazione tra dei “Business Actor”,
qualcuno o qualcosa esterno al business: fornitori, clienti, colleghi di altri dipartimenti, ed il
processo di business rappresentato dai suoi servizi offerti (“business use case”).

In questo caso si possono individuare anche degli attori interni (“business worker”), che sono
ruoli o insiemi di ruoli che interagiscono con altri business worker manipolando delle business
entità.

Il generico Business Use case è un insieme di azioni che producano valore ad un business
actor.

7
Business Activity Diagram
Un Business Activity Diagram (figure 2) traccia il business workflow e fornisce aspetti dinamici
di esso.
Con esso si ottiene una visione di:
 Cosa succede in un workflow;
 Quali attività sono fatte in parallelo;
 Se esistono azioni alternative in un workflow

Un Business Activity Diagram è possibile anche partizionarlo in colonne per ruoli e

responsabilità (UML swimlanes).

8
Nel Activity Diagram possono anche essere aggiunte le business entity coinvolte (figure 3).

9
Business Class Diagram
Il Business Class Diagram (figure 4) descrive la struttura statica del business. Ogni classe
descrive un business worker o un business entity, di conseguenza indica le relazioni tra
business worker e business entity.

Figure 4

Business Interaction Diagram

Possono essere usati sia il sequence che il collaboration diagram.

Tools per Business Modeling

Esistono molti tools che permettono il Business Modeling, spesso basta accontentarsi anche di
un tool che già si dispone es.: Rational Suite AnalystStudio oppure anche Visio di Microsoft.

Conclusioni
Il Business Modeling è una tecnica per ridurre il rischio di costruire il “sistema giusto”. Vale
senz’altro la pena utilizzarla per la creazione di grossi parti di sistema.

10
11
INDICE
Il BusinessAs is Modeling con UML ..................................................................................................... 1
Introduzione ......................................................................................................................................... 2
Gli elementi critici di un processo produttivo ...................................................................................... 3
Stakeholder....................................................................................................................................... 3
Processo produttivo .......................................................................................................................... 4
Miglioramento dei processi nello sviluppo del software ............................................................. 4
Linguaggi e strumenti ...................................................................................................................... 5
Il sistema giusto ................................................................................................................................... 6
Business as is Modeling - BaiM ........................................................................................................ 6
Vantaggi del BaiM ....................................................................................................................... 6
Il metodo del BaiM ...................................................................................................................... 7
Tools per Business Modeling ............................................................................................................. 10
Conclusioni ........................................................................................................................................ 10
Riferimenti ......................................................................................................................................... 13

12
Riferimenti
[DR1] Martin Fowler – UML Distilled – Prima edizione italiana
[DR2] Rosario Turco – Usabilità e ripetibilità dei processi produttivi software
[DR3] Rosario Turco – Modellare con l’UML ed i colori
[DR4] Robert C. Martin – Design Principles and Design Patterns
[DR5] Gamma, Helm, Johnson,Vlissides – Design Patterns – Elementi per il riuso di software a
oggetti – Prima edizione italiana
[DR6] Rosario Turco - Pattern e la “GRASP Oriented Analysis”
[DR7] Rosario Turco – Refactoring: la teoria in pratica
[DR8] Rosario Turco – Extreme Programming
[DR9] Rosario Turco – Disegno per il riuso con il riuso

13