Business Process Modeling: una metodologia per la definizione dei requisiti di un editor di
processi di business orientato allo standard OMG
11
tenutosi a Napoli il 4 e 5 ottobre 2007. È poi partito un progetto Eclipse Italia per
la definizione di un tool di modellazione dei processi.
“…il problema fondamentale è il grande distacco tra quelli che sono i processi di
business ed i prodotti di automazione dei processi di business in generale. Quello
che qui cerchiamo di fare è riuscire ad avere un linguaggio semplice che abbia una
tracciabilità del business sino all‟applicazione che lo supporta in modo da avere un
ciclo continuo. Ad oggi sono stati realizzati dei prodotti che richiedono al business
di adattarsi ad essi. Quello che invece stiamo cercando di fare è avere un ulteriore
passaggio: il business che fa adattare i prodotti. …è un sistema di modellazione
che permette di comprendere quelli che sono i requisiti dei sistemi a supporto dei
processi di business. …non è un tool per persone che hanno una laurea in
ingegneria elettronica o in computer science, ma è rivolto a persone che lavorano
nel business e che attraverso un tool del genere sono in grado di catturare la
conoscenza di come questi processi evolvono, quindi utilizzabile dagli esperti del
settore, da chi conosce il dominio”.
Le aziende richiedono sistemi informativi per supportare i loro processi di
business. Le ricerche nel campo dell‟ingegneria del software si concentrano
tipicamente sul processo di sviluppo, a cominciare dai requisiti di utente, e con il
business modeling spesso confuso con la modellazione del sistema software.
Ricercatori e professionisti hanno riconosciuto che aver chiari i processi di
business che un sistema informativo deve supportare, è la chiave per scoprire le
reali necessità dei suoi utenti. Essi sono stati a lungo interessati nella modellazione
dei processi delle organizzazioni allo scopo di capire, analizzare e migliorare i
modelli che spesso però risultavano poco chiari per essere utilizzati dagli ingegneri
del software. Secondo l‟analista di Forrester, Carey Schwaber, nel suo rapporto di
Settembre 2006 intitolato "Le radici del Problema: bassa qualità nei requisiti", "il
punto di riferimento nel processo della definizione dei requisiti è l‟analista di
business, una creatura ibrida capace di muoversi con facilità sia nel mondo del
Business Process Modeling: una metodologia per la definizione dei requisiti di un editor di
processi di business orientato allo standard OMG
12
business sia in quello della tecnologia. Ma molto spesso gli analisti di business non
riescono a svolgere questo ruolo e non ricevono un‟adeguata formazione". Sebbene
i passi da gigante nel campo dell‟ingegneria del software, la cattura dei requisiti
resta il passo più complicato e non completamente formalizzato [2]. Per capire
cosa un sistema software faccia o debba fare, abbiamo la necessità di catapultarci
all‟interno del contesto dei processi di business che supponiamo esso supporti. I
sostenitori della modellazione orientata agli oggetti affermano che i modelli ad
oggetti ci mettono in condizione di modellare il “mondo reale” in un modo che
tutti gli stakeholders ovvero tutti coloro che sono interessati al progetto (clienti e
progettisti) possano percepire. Gli esperti dell‟amministrazione del business si
sono a lungo interessati dei processi di business delle organizzazioni. Capire tali
processi permette di analizzarli, di identificare potenziali punti deboli o
inefficienze e ingegnerizzarli (o re-ingegnerizzarli) per eliminare tali mancanze
[3]. L‟avvento del commercio elettronico e dei sistemi di gestione dei workflows,
tra le altre cose, hanno condotto ad una convergenza di interessi e strumenti
all‟interno della comunità IT (Information Technology), con l‟unico scopo di
modellare i processi di business. Il commercio elettronico ha contribuito ad
aumentare l‟interesse verso la modellazione dei processi di business per due
motivi. Primo, le aziende che desiderano prendere parte al commercio elettronico
necessitano riprogettare i loro processi interni così che le complesse transazioni
interaziendali possono essere completamente automatizzate. Secondo, necessitano
di condividere i risultati delle elaborazioni di tali processi. Come risultato, sono
stati sviluppati un numero di linguaggi per la descrizione e il coordinamento dei
processi di business. A partire da una valutazione dei più importanti linguaggi di
modellazione dei processi di business, si vuole offrire al lettore una descrizione
dettagliata dei concetti utilizzati da chi fa business e la possibilità, a partire da essi,
di poter elaborare la maggior parte degli scenari di business. Infine si propone
un‟analisi dei requisiti di un editor capace di modellare tutti gli aspetti presenti in
un qualsiasi scenario di business.
Business Process Modeling: una metodologia per la definizione dei requisiti di un editor di
processi di business orientato allo standard OMG
13
Il lavoro è organizzato nel modo seguente:
Capitolo 1 – Una ontologia per il business e l’impresa
Un linguaggio comune che definisca la semantica dei concetti di business utilizzati
dalle imprese consente loro di interoperare. Ciò conduce alla ricerca di una
ontologia per il business e l‟impresa. I vocaboli del dominio per il processo, come
già osservato precedentemente, saranno differenti, dipendendo dal livello
dell‟organizzazione in cui i processi hanno luogo. Il capitolo definisce i concetti di
business process e business model. Dall‟analisi della letteratura esistente,
emergono nove “buildings blocks” che coprono i componenti di un business model
menzionati da almeno due autori. Il capitolo pone poi in risalto l‟allineamento tra
strategia, business organization e tecnologia. Il capitolo si conclude con
l‟introduzione di una serie di proposizioni che indicano come il concetto di
business model aiuta a realizzare tale allineamento e conseguentemente a
semplificare l‟ingegneria dei requisiti.
Capitolo 2 – Le quattro viste di Curtis e la Business Process Context Perspective
Data la complessità dei processi di business, i progettisti generalmente rendono
disponibili differenti viste di modellazione (modeling views), ciascuna incentrata
su di un aspetto del processo. Curtis identifica quattro viste, [4]. Il framework
risultante consiste allora di quattro prospettive (perspectives): organizzativa
(Organizational Perspective), funzionale (Functional Perspective),
comportamentale (Behavioral Perspective) e informativa (Informational
Perspective). Allo scopo di catturare importanti informazioni come gli obiettivi di
business o le misure eseguite per monitorare il processo, si estende il modello con
un‟ulteriore prospettiva, chiamata Business Process Context Perspective.
Business Process Modeling: una metodologia per la definizione dei requisiti di un editor di
processi di business orientato allo standard OMG
14
Capitolo 3 – La Business Perspective di UML 2 profile for Business Modeling
Il profilo UML 2 per la modellazione dei processi di business, si propone di fornire
i modelli del processo di business per gli sviluppatori di software in una notazione
well-known (ovvero riuso della notazione UML), presentare i modelli di business
process agli sviluppatori utilizzando tool UML, e infine sviluppare un
metamodello che copra gli aspetti comprensivi della teoria del business process,
includendone il contesto. Il metamodello fornisce due prospettive complementari:
la Business Perspective e la Sequence Perspective.
Capitolo 4 – Il Business Modeling nella metodologia Unified Scenario – Based
Design
Le aziende hanno necessità, oggi più di ieri, di utilizzare software che supporti i
loro processi di business per essere competitivi o per acquisire una posizione di
vantaggio nella competizione con le altre aziende. Da qui la necessità di creare
software che supporti gli obiettivi di business, e che si possa adattare facilmente
quando tali obiettivi cambiano. In ultimo, deve garantire un utilizzo senza
problemi da parte dell’end-user. Queste considerazioni hanno portato alla
metodologia USBD [5], [6], [7]. Essa sfrutta il fatto che i processi di business e gli
obiettivi sono modellati utilizzando lo stesso formalismo adottato per modellare il
sistema. Il risultato è una descrizione unica dell‟intero sistema (end–to–end), dalle
necessità del business ai prodotti software.
Capitolo 5 – I concetti di business rappresentati nei linguaggi di modellazione
L‟obiettivo di questo capitolo è catturare e formalizzare i principali elementi e/o
concetti di business, attraverso una valutazione dei più importanti linguaggi di
modellazione dei processi di business. I linguaggi sono classificati secondo le
“four perspectives” di Curtis et al. [4] ed in base al metamodello di carattere
Business Process Modeling: una metodologia per la definizione dei requisiti di un editor di
processi di business orientato allo standard OMG
15
generale di List-Korherr [8]. Quest‟ultimo è basato sulle quattro viste precedenti e
su una nuova prospettiva denominata Business Process Context Perspective. Tale
prospettiva offre una visione globale del processo descrivendone le principali
caratteristiche: gli obiettivi e la loro misurazione, gli elaborati, il proprietario del
processo, il tipo di processo e il tipo di cliente.
Capitolo 6 – Corrispondenza tra il Business Process Modeling Notation (BPMN) e
i diagrammi di attività Uml 2
Il Business Process Modeling Notation (BPMN) offre una notazione che è, tra i
linguaggi di modellazione esaminati, di più facile comprensione per tutti gli utenti
di business, dagli analisti di business che creano le prime bozze dei processi, agli
sviluppatori del software responsabili di implementare la tecnologia che eseguirà
quei processi, e in ultimo per tutti coloro che li gestiranno e li controlleranno. Allo
stesso tempo, si è visto che tale notazione non è in grado di rappresentare tutti i
concetti di business. Si potrebbe allora pensare di utilizzare la notazione all‟interno
di un UML profile in sostituzione dei diagrammi di attività. Il capitolo riporta di
seguito il mapping tra gli UML 2 activity diagram e la notazione BPMN. Pone poi
in risato il fatto che in USBD i Business Process Maps sono rappresentati come
diagrammi di attività UML, come anche i Business Process. In altri termini il
business modeling all‟interno della metodologia USBD è realizzato utilizzando tali
diagrammi.
Capitolo 7 – Il Business Motivation Model di Object Management Group (OMG)
Fondamentale per il Business Motivation Model (BMM) [9] è la nozione di
motivazione: se un‟azienda prescrive un certo approccio per la sua attività di
business, dovrebbe essere in grado di dire perché. Il BMM rende disponibile uno
schema o struttura per sviluppare, comunicare, e gestire progetti di business in un
Business Process Modeling: una metodologia per la definizione dei requisiti di un editor di
processi di business orientato allo standard OMG
16
modo organizzato. In particolare esso:
- Identifica i fattori che motivano l‟introduzione di un progetto di business
(business plan)
- Identifica o definisce gli elementi di un progetto di business.
- Indica come tutti questi fattori ed elementi sono in relazione tra loro.
Fra questi elementi vi sono quelli che forniscono il controllo e la direzione per il
business e cioè le business policies e le business rules. La struttura del BMM
fornisce le basi per la progettazione logica di tool per la memorizzazione, il cross-
referencing e il reporting degli elementi dei progetti di business di un‟azienda.
Capitolo 8 – Il linguaggio di business: il metamodello ed il vocabolario
Il capitolo introduce un metamodello ed un vocabolario per il linguaggio di
business. Si propongono le prospettive e le viste del metamodello e le relazioni tra
gli elementi di business. In ultimo si descrivono gli elementi di business alla base
del metamodello.
Capitolo 9 – Il progetto del Business Editor: Eclipse Process Framework (EPF)
Open Unified Process (OpenUP)
Open Unified Process (OpenUP) [10] è un nuovo progetto open source. Esso è
parte dell'Eclipse Process Framework (EPF) [11], sviluppato all'interno del
progetto open source Eclipse. OpenUP racchiude in sé i minimi e fondamentali
principi della progettazione e sviluppo cosiddetto agile. Il capitolo descrive le fasi
del ciclo di sviluppo del software, le discipline e i ruoli.
Business Process Modeling: una metodologia per la definizione dei requisiti di un editor di
processi di business orientato allo standard OMG
17
Capitolo 10 – Open Unified Process Disciplines: Requirements Discipline
L‟editor dovrà implementare i concetti di business introdotti sin qui ed in
particolare dovrà consentire una modellazione semplice e naturale dei processi di
business. Deve essere utilizzabile da qualsiasi azienda che ha necessità di definire e
gestire progetti di business. Ciò può comportare che diverse unità organizzative
nella stessa azienda utilizzino l‟editor, e ciascuna di esse può includere concetti
raffinati dagli elementi corrispondenti nelle unità organizzative di alto livello.
Sono interessate tutte le persone che fanno business e che devono essere in grado
di formulare la loro visione di business e di comunicare chiaramente cosa si
aspettano da coloro che lavorano in ambito IS. Ancora, può aiutare a migliorare
l‟ingegneria dei requisiti. Il capitolo affronta l‟analisi dei requisiti, che conclude il
lavoro svolto con la realizzazione di un documento di Vision, un glossario ed un
Use Case Model.
Conclusioni e sviluppi futuri
Ricevi informazioni sui nostri servizi, sulle offerte e non perdere news e consigli su università e lavoro.
