Business Modeling con UML

1

Il Business

As is

Modeling con UML

Ing. R. Turco

–

R. Turco

2

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 componentiartigianali 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 approcciometodologico 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 perprogettare 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. Ilproblema è enormemente sentito nei progetti di riguardevoli dimensioni e con un numeromedio-grande di persone coinvolte.

3

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 unprogetto (fig. 1).

Fig. 1

Ogni vertice del triangolo è una criticità, a cui sono associati un certo numero di

rischi

ognunodi entità e peso diverso, variabili nel tempo e dipendenti dal contesto e dalle condizioni alcontorno 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 sulprogetto 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;