business modeling con uml

8/8/2019 Business Modeling con UML

1/13

1

Il BusinessAs is Modeling con UMLIng. R. Turco

Copyright 2003 R. Turco


2/13

2

Introduzione

Ogni attivit umana, che orientata alla realizzazione di un prodotto o di un servizio, ha dietrodi s unorganizzazione, delle metodologie, delle procedure operative, degli strumentied un

workflow lavorativo.

Tutto questo costituisce unprocesso produttivoche, nellambito dellorganizzazione in gioco,pu essere pi o meno formalizzato.

Lo studio dei processi produttivi software fa parte di quella scienza umana che denominataIngegneria del software.

Lingegneria 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 lanciarlima 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 avrsuccesso.

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 dintelletto, come per lappunto laproduzione del software, non si pu ottenere una sistematicit al 100% e si sar di fronte,almeno nel 20% dei casi, allabilit del programmatore, alla sua genialit, alla sua competenza.

Lideale, come sempre, si ottiene dalla giusta misura tra metodo, sistematicit, competenza egenialit.

Se da una parte, nelle fasi innovative, la genialit e la competenza possono rappresentarelunico 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, allabbattimento delle criticit dellevarie fasi produttive, a misure per effettuare dei check di qualit, di avanzamento, etc.

La sfida, quindi, dellingegneria 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 lObject Oriented, lamodellazione dei sistemi e la standardizzazione di linguaggi come UML, etc, ancor oggi puessere 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 numero

medio-grande di persone coinvolte.


3/13

3

Gli elementi critici di un processo produttivoEsistono essenzialmente tre elementi critici, che minano la sistematicit della produzione delsoftware, ma che, se ben controllati, si trasformano nel triangolo del successo di un

progetto (fig. 1).

Fig. 1

Ogni vertice del triangolo una criticit, a cui sono associati un certo numero di rischiognunodi 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 lefficaciadellorganizzazioneper il raggiungimento degli obiettivi e delle soluzioni giuste.

Lefficienza, invece, dovr ottenersi col continuo miglioramento del processo produttivo, inizialmente progettato ad hoc alle proprie esigenze e a quelle del cliente e/o del mercatotarget.

StakeholderGli 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; 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.

Stackholder

Processo Linguaggi estrumenti


4/13

4

Per gli skill interni al progetto, Brooks (1987) afferma: Ottimi progetti sono dovut i ad ottimisviluppatori (E, difatti, il prodotto alla fine che viene consegnato e deve funzionare comeserve 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 dellorganizzazione; enfatizzare il lavoro di gruppo.

Altri suggerimenti vengono anche dallXP [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; dallassistenza 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 produttivoCos 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 devetrovare il proprio modello, seguirlo e migliorarlo nel tempo.

Il processo, inoltre, deve essere allineato con i mezzi, lo stato culturale ed il Know-howdellazienda 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 dimensioninon ha un forte bisogno di unprocesso 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 inassenza 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 perottenere un buon prodotto o un buon servizio.

Linteresse dello standard , quindi, sul processo produttivo.


5/13

5

Per lISO 9000 unazienda 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 lISO 9000 uno standard che favorisce un processo iterativo, con feedback dicontrollo per poter decidere un piano di miglioramento ogni volta.

Le tecniche di valutazione della maturit del proprio processo sempre basato sul CapabilityMaturity Model (CMM).

CAPABILITY MATURITY MODELIl 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 dalSEI.

Bisogna effettivamente, in modo critico, chiedersi se al 100% possibile rispondere che uncerto livello lo si soddisfa pienamente.

Per passare da un livello allaltro potrebbero servire anni, ma non certo ammissibile rimaneresempre sullo stesso livello. Daltra parte il tempo rende le tecnologie e le metodologieantiquate e, quindi, si pu retrocedere nei livelli!!

Il principio che: Deve esistere un continuo tentativo di migliorare il proprio processoproduttivo.

Linguaggi e strumentiIl terzo elemento critico necessario da gestire ladozione di un linguaggio di modellazione e diuno strumento al supporto di esso.

Attualmente esiste come linguaggio lo standard UML 1.4 che fornisce notazionie semanticadichiarativa (quali sono i bisogni oltre che come si procede per soddisfarli).

Con lUML si possono creare modelli, visuali e non, con cui rappresentare il problema darisolvere e documentare il tutto.

LUML uno strumento di comunicazione tra le persone del progetto e tra cliente e progetto.


6/13

6

LUML 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 linguaggiodisponibile.

Oltre al linguaggio serve un CASE (Computer-Assisted Software Engineering) che permetta diusare lUML per creare modelli e che utilizzi un Repository dove centralizzare e condividere i

modelli con accesso multi-utente.

Il sistema giustoUno dei fattori di criticit, come abbiamo visto, costituito dagli stakeholder. In [DR8] sonodiscussi molti di essi.

Qui si vuole approfondire, attraverso una tecnica di risoluzione, uno dei tanti rischi legati aglistakeholder; 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, neltentativo di creare una catena di produzione si aggiungono gli sviluppatori ma ognuno di essinon possiede una visione generale, ma ha solo il compito di implementare un insieme dilibrerie, classi, componenti definite da un analista.

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

Ognuno di questi sviluppatori potrebbe prendere delle piccole decisioni sul prodotto, che nonproducono bugs ma che alla fine condizionano la flessibilit del sistema rispetto alle possibilisituazioni di business gi prevedibili in generale.

Business as is Modeling - BaiMPer capire che sistema costruire occorre focalizzarsi sul business del cliente com nella realt erichiede unattiva partecipazione del cliente stesso.

La partecipazione attiva del cliente dovrebbe tendere a chiarire le strategie di businessdellazienda 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 isModeling (BaiM) che,attraverso lUML, 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:


7/13

7

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 uncambiamento o un ampliamento del business.

Lo sviluppo del sistema coerente, perch tutti hanno la stessa conoscenza delbusiness, 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 dellUML utilizza:1. Business Use Case Diagram;2. Business Activity Diagram;3. Business Class Diagram;4. Business Interaction Diagram.

Business Use Case DiagramIl Business Use Case Diagram (figure 1) rappresenta linterazione tra dei Business Actor,qualcuno o qualcosa esterno al business: fornitori, clienti, colleghi di altri dipartimenti, ed ilprocesso di business rappresentato dai suoi servizi offerti (business use case).

In questo caso si possono individuare anche degli attori interni (business worker), che sonoruoli o insiemi di ruoli che interagiscono con altri business worker manipolando delle businessentit.

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

actor.


8/13

8

Business Activity DiagramUn Business Activity Diagram (figure 2) traccia il business workflow e fornisce aspetti dinamicidi 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 eresponsabilit (UML swimlanes).


9/13


10/13

10

Business Class DiagramIl Business Class Diagram (figure 4) descrive la struttura statica del business. Ogni classedescrive un business worker o un business entity, di conseguenza indica le relazioni trabusiness worker e business entity.

Figure 4

Business Interaction DiagramPossono 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.

ConclusioniIl Business Modeling una tecnica per ridurre il rischio di costruire il sistema giusto. Valesenzaltro la pena utilizzarla per la creazione di grossi parti di sistema.


11/13

11


12/13

12

INDICE

Il BusinessAs is Modeling con UML ..................................................................................................... 1

Introduzione ......................................................................................................................................... 2

Gli elementi critici di un processo produttivo ...................................................................................... 3

Stakeholder....................................................................................................................................... 3

Processo produttivo .......................................................................................................................... 4Miglioramento 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


13/13

13

Riferimenti[DR1] Martin Fowler UML Distilled Prima edizione italiana[DR2] Rosario Turco Usabilit e ripetibilit dei processi produttivi software[DR3] Rosario Turco Modellare con lUML 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 aoggetti 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

business modeling con uml

Documents