Sei sulla pagina 1di 19

UNIVERSITÀ
DEGLI
STUDI
DI
BARI
“ALDO
MORO”


FACOLTÀ
DI
SCIENZE
MATEMATICHE
FISICHE
E
NATURALI

CORSO
DI
LAUREA:

INFORMATICA
E
TECNOLOGIE
PER
LA
PRODUZIONE
DEL
SOFTWARE


ORCHESTRAZIONE
DI
RISORSE
UMANE
NEL
BPM

Gestione
dinamica
feature‐based
delle
organizzazioni
nella

piattaforma
openwork®


Relatore:

Prof.
Giovanni
Semeraro

Correlatore:
 Candidato:

Dott.
Gianpiero
Bongallino
 Michele
Filannino

BPM


Business
Process
Management:
Disciplina
che

studia
l’insieme
delle
a1vità
necessarie
per

definire,
o1mizzare,
monitorare
ed
integrare
i

processi
aziendali,
al
fine
di
creare
un
processo

orientato
a
rendere
efficiente
ed
efficace
il
business

di
un’organizzazione.


Processo:
Insieme
delle
a1vità
eseguite
da
persone

e/o
sistemi,
che
scatenate
da
un
evento,
producono

un
risultato.

2

Principali
Standard


Al
fine
di
fornire
un
punto
di
riferimento
unico

per
rappresentare
graficamente
processi
e

garanDre
l’interoperabilità
tra
i
soEware
di
BPM,

sono
staD
introdo1
degli
standard:


Business
Process
 XML
Process

Modeling
Notation
 DeUinition
Language


3

openwork®


 
Consente
di
disegnare
ed
eseguire
processi.

 
Estende
il
dominio
applicaDvo
di
un
classico

BPM
alle
organizzazioni
ed
ai
documenD.

 
GesDone
dei
Processi;

 
GesDone
dei
DocumenD;

Processi

 
GesDone
dell’Organizzazione;


Organizzazione
 DocumenD


4

openwork®:
Partecipan9


I
Dpi
di
partecipanD
assegnabili
ad
un’a1vità
di

un
processo
sono:

 

Unità
organizzaDva;

 

Ruolo;

 

Operatore;

 

Gruppo
StaDco;

 

Partecipante
RelaDvo.


5

openwork®:
Organizzazione


6

openwork®:
Gruppo
Sta9co


7

Scopo
della
tesi


 

Formalizzare
il
conceXo
di
gesDone
dinamica

feature‐based
delle
organizzazioni
;

 

Approfondire
le
problemaDche
della
gesDone

dinamica
all’interno
del
framework
openwork®

di
prossima
generazione.


8

Gruppo
dinamico


Si
basa
su
un
assunto
teorico
essenziale:


“Una
qualsivoglia
a.vità
è
assegnata
ad
un

qualsivoglia
operatore
in
virtù
delle
sue

capacità/conoscenze/competenze.”


Il
manager
che
assegna
l’a1vità
X
all’operatore
Y

lo
fa
poiché
riconosce
nell’operatore
Y
i
requisiD

per
poter
compiere
l’a1vità
X”.

9

Gruppo
dinamico


Contenitore
di
enDtà
organizzaDve
eterogenee

che
soddisfano
parDcolari
requisiD.


Obie1vo:

 
“Gli
operatori
che
hanno
più
di
25
anni,

o1ma

conoscenza
di
C++
e
capacità
di
comprensione

della
lingua
tedesca”;

 
“Le
unità
organizzaDve
che
si
trovano
a

Milano”.

10

Gruppo
dinamico


Ogni
singola
enDtà
organizzaDva
si
arricchisce
di

feature
(aXributo‐valore).
Il
set
di
aXribuD

uDlizzabili
dipende
dalla
parDcolare
piaXaforma

e
può
cambiare
da
installazione
ad
installazione.


Il
gruppo
dinamico
è
una
terna
siffaXa:

 

nome;

 

descrizione;

 

espressione.


11

Gruppo
dinamico


L’espressione
è
una
regola
formale
composta
da:

 

operandi
(con
le
loro
feature):

• 

Ruoli;

• 

Operatori;

• 

Gruppi
staDci;

• 

Unità
OrganizzaDve;

 

ed
operatori:

• 

algebrici
[+,
‐,
*,
/,
%,
…];

• 

logici
[AND,
OR,
NOT,
…];

• 

di
confronto
[=,
<>,
<=,
>=,
<,
>,
…].

12

Expression
Engine


Nella
nuova
generazione
di
openwork®

l’espressione
sarà
valutata
da
un
opportuno

Expression
Engine
basato
su
Spring.NET

ApplicaDon
Framework.


13

Expression
Engine


Esso
deve:

 

Valutare
la
correXezza
formale
di
una

espressione;

 

ResDtuire
un
valore
di
verità
a
seconda
che

un
parDcolare
operatore
soddisfi
una

parDcolare
espressione;

 

ResDtuire
l’insieme
degli
operatori
a
seconda

della
espressione
fornita
(solo
in
caso
di

parDcolari
a1vità);

14

Riflessioni


Quando
l’expression
engine
deve
essere

chiamato
a
valutare
l’espressione?
Se
la
si

valutasse
troppo
presto,
si
correrebbe
il
rischio

di
assegnare
l’a1vità
ad
operatori
che
non

soddisfano
più
i
requisiD.


Soluzione:
Quando
l’operatore
si
logga

nell’applicazione,
richiede
di
verificare
la
sua

appartenenza
al
gruppo
dinamico.

15

Riflessioni


Un’a1vità
che
ha
come
partecipante
un
Gruppo

Dinamico
non
è
deXo
che
possa
essere
sempre

eseguita;
in
altri
termini
il
Gruppo
Dinamico

potrebbe
essere
vuoto.
In
un
dato
momento

nessun
operatore
potrebbe
soddisfare
i
requisiD.


Soluzione:
L’a1vità
rimarrà
in
aXesa
fino
a
che

almeno
un
operatore
non
soddisfi
i
requisiD

richiesD
e
prenda
in
carico
l’a1vità.

16

Conclusioni


La
definizione
di
un’architeXura
per
la
gesDone

dinamica
delle
risorse
umane
come
quella
qui

presentata
è
un
importante
e
pionerisDco
punto

di
svolta
per
qualsiasi
soEware
di
BPM.


La
prossima
generazione
di
openwork®

beneficerà
di
questa
componente.


17

Sviluppi
futuri


 

Estendere
l’uso
delle
espressioni
a
tuXe
le

enDtà
coinvolte
nel
soEware
di
BPM,
senza

limitarsi
al
solo
dominio
di
Organizzazione.

 

Implementazione
di
un
sistema
di
Informa9on

Retrieval
che
consenta
all’utente
finale
di

scrivere
la
regola
formale
di
un
gruppo
dinamico

in
linguaggio
naturale
e
lasci
alla
piaXaforma
il

compito
di
estrarre
le
enDtà
organizzaDve

opportune.

18

Grazie