Analisi sperimentale comparativa dell’evolvibilità nei sistemi di evoluzione ...
Sviluppo e implementazione di un modello di ottimizzazione per un'efficiente schedulazione delle attività del personale
1. Università degli Studi di Trieste
Dipartimento di Ingegneria e Architettura
Corso di Studi in Ingegneria Elettronica e Informatica
Tesi di Laurea Magistrale
Sviluppo e implementazione di un modello
di ottimizzazione per un’efficiente
schedulazione delle attività del personale
Laureanda:
Marzia Paschini
Relatore: prof. Lorenzo Castelli
Correlatore: dott. Alex Dagri
Correlatore: dott. Andrea Gasparin
ANNO ACCADEMICO 2022–2023
5. Introduzione
In tutti gli ambiti odierni, uno degli aspetti chiave, ma anche più delicati, è la
capacità di organizzare al meglio impegni e scadenze nel tempo, assegnandole
in maniera efficiente alle risorse disponibili. Conosciuto come “schedulazio-
ne”, questo processo decisionale è stato ampiamente studiato negli ultimi
decenni, in ragione della sua rilevanza.
In particolare, il contesto dei servizi è sempre più dinamico e ciò rende
la progettazione di una schedulazione, che assicuri sia correttezza sia presta-
zioni ottimali, una sfida complessa da affrontare. Questo scenario implica
la necessità di un processo efficiente e ottimale di assegnazione delle risorse
umane a specifici turni di lavoro o compiti, indipendentemente dalla situa-
zione. Un repentino cambiamento nelle disponibilità di una risorsa, una
scadenza critica da rispettare o un improvviso mutamento negli obiettivi da
raggiungere potrebbe comportare il malfunzionamento della schedulazione,
con conseguenze disastrose sull’intero sistema di cui essa fa parte. Tale argo-
mento assume una rilevanza cruciale per qualsiasi soggetto, quali un’azienda,
un’associazione o anche un sistema di dimensioni più contenute, chiamato a
gestire un insieme di risorse per produrre dei risultati, a prescindere da quali
essi siano.
1
6. Mentre le tecnologie di ottimizzazione, come i software risolutori, si stan-
no sviluppando sempre più rapidamente, lo sviluppo teorico della schedu-
lazione non progredisce allo stesso ritmo. In collaborazione con l’azienda
Cybertec S.R.L., tramite questo elaborato viene presentata una nuova for-
mulazione di un modello di ottimizzazione che produce una schedulazione,
specificamente per risolvere una forma particolare del Resource Constrained
Project Scheduling Problem: lo scopo è trovare una soluzione per schedulare
le attività nel tempo, allocando le risorse necessarie ma vincolate alla loro
capacità, che non può essere ecceduta. Il modello si dimostra efficiente e
innovativo e viene, inoltre, descritto tramite una dettagliata analisi.
Obiettivo di questa tesi è dunque una ricerca di spunti innovativi, che
potrebbero rendere ancora più efficienti software quali Resilient Service Plan-
ner (RSP) di Cyberplan. I project manager che utilizzano tali applicativi
potrebbero, quindi, ottenere in brevi tempi delle schedule precise, con una
conseguente organizzazione migliore dei vari progetti a cui lavorano.
Questo elaborato è strutturato come indicato in seguito. Nel primo ca-
pitolo si delinea il problema in modo dettagliato, illustrando le sue carat-
teristiche, e si introduce il modello matematico di ottimizzazione associato.
Nel secondo capitolo viene illustrato il metodo di risoluzione impiegato, im-
plementato attraverso la realizzazione del modello, con una dettagliata de-
scrizione delle tecniche utilizzate. Nel terzo capitolo viene descritta la fase
di test dell’implementazione del modello. Nel quarto capitolo sono presen-
tati i risultati ottenuti. Infine, nell’ultimo capitolo, vengono riportate le
conclusioni.
2
7. Stato dell’arte
La schedulazione è un argomento largamente studiato da molto tempo, co-
me anche uno dei suoi casi particolari, appena citato, ovvero il Resource
Constrained Project Scheduling Problem (RCPSP). Come affermato già nel
2013 [1], questo argomento continua a essere di forte interesse sia per il mon-
do accademico sia per il mondo industriale. Per quest’ultimo, l’importanza
di trovare soluzioni migliori è evidente: l’organizzazione di tutti i progetti
all’interno di un’azienda ne influenza la produttività e, quindi, il benessere
da essa derivato.
Nel corso degli anni in letteratura [2], per trattare i casi reali, sono state
formalizzate diverse categorie di risorse, utilizzate nelle schedulazioni di qual-
siasi ambito: rinnovabili, non rinnovabili e parzialmente rinnovabili. Tratta-
re una risorsa non rinnovabile significa che, una volta utilizzata per tutta la
sua capacità, essa non sarà più disponibile perché sarà effettivamente esau-
rita. La capacità delle risorse rinnovabili, invece, si rigenera ad ogni unità
temporale. Infine, le risorse parzialmente rinnovabili sono caratterizzate dal-
la capacità rinnovata solo in determinati momenti, durante il lasso di tempo
considerato. Alcuni esempi di risorse rinnovabili sono le persone e alcuni tipi
di equipaggiamento che esse potrebbero utilizzare, mentre esempi di risorse
non rinnovabili (e parzialmente rinnovabili) sono i budget economici e i ma-
teriali grezzi. Questa caratteristica delle risorse è fondamentale, in quanto
cambia notevolmente la difficoltà del problema, nonché i vincoli critici. Basti
pensare a come ci si pone diversamente per idearee una schedulazione con
dipendenti di un’azienda oppure una lavorazione di un materiale grezzo, co-
3
8. me il petrolio. Si può quindi pensare che altre tipologie di risorse verranno
formalizzate in futuro.
Complessità del problema
RCPSP è stato dichiarato nel 1983 [3] come NP-difficile da risolvere, ovvero è
Non-deterministic Polynomial-time difficile. Ciò significa che non sono noti
degli algoritmi a tempo polinomiale per risolvere tale problema. Risolvere
un problema NP-difficile con un algoritmo polinomiale sarebbe un risultato
rivoluzionario e avrebbe profonde implicazioni nella teoria della complessità
computazionale, ma non è il caso di questo elaborato.
A seguito di questo risultato matematico, diversi algoritmi esatti sono sta-
ti utilizzati per tentare di risolvere il problema, ma tutti hanno dimostrato
di riuscire a risolvere solo delle piccole istanze in un periodo di tempo accet-
tabile. Perciò, moltissimi studiosi si sono impegnati a cercare delle euristiche
che lo risolvessero in un tempo ragionevole, al prezzo, però, di sacrificare
l’ottimalità della soluzione. Si sono cosı̀ ottenute delle soluzioni anche alle
grandi istanze, ma non precise e, dunque, che vanno a discapito dell’utilizzo
efficiente delle risorse.
Questo lavoro propone un approccio alla risoluzione del problema che garan-
tisce, in un breve arco di tempo, risultati ottimi. Tuttavia, la natura del pro-
blema rimane invariata, e quindi la soluzione suggerita è ottimale per istanze
di dimensioni moderate. È preferibile ottenere risultati ottimali per casi di
tale volume, che siano più rappresentativi delle situazioni reali, piuttosto che
risultati mediocri per istanze eccessivamente grandi e non realistiche.
4
9. Capitolo 1
Formalizzazione del problema
Viene presentata in primo luogo una descrizione dello strumento in analisi.
Uno schedulatore è un sistema che, grazie ad algoritmi e logiche matemati-
che, ottimizza i processi di produzione. La caratteristica fondamentale dello
schedulatore legato all’ambito dei servizi risiede nei vincoli e nei limiti dati
da eventuali richieste temporali dei clienti e dalla capacità produttiva. Il
risultato prodotto dallo schedulatore è la generazione di un piano di attività
per le singole risorse che partecipano ai vari progetti previsti.
1.1 Terminologia
Per affrontare il tema dell’elaborato, occorre specificare prima qualche termi-
ne tecnico. Come affermato nell’introduzione di uno dei libri più importan-
ti [4] nello studio della stessa, la “schedulazione” è un processo decisionale
utilizzato regolarmente nelle industrie manifuttariere e di servizi. Gli elemen-
ti principali all’interno della schedulazione sono le “risorse” e le “attività”: le
5
10. prime possono essere dei macchinari oppure delle persone, le seconde possono
essere un insieme di operazioni da eseguire oppure delle singole operazioni,
dipende da quanto si sceglie di andare nel dettaglio. Nel processo di ge-
nerazione di una schedulazione, l’obiettivo può essere singolo oppure si può
desiderare di raggiungerne diversi, a seconda delle necessità. Ad esempio,
potrebbe essere cruciale rispettare una scadenza specifica per un progetto o
mantenere i costi al di sotto di una soglia prefissata di budget. Questo porta
a riconoscere la varietà di problemi di schedulazione esistenti, ognuno con
molteplici caratteristiche che richiedono una definizione accurata.
L’obiettivo della schedulazione che considera questo elaborato è la mini-
mizzazione del project makespan, ovvero della durata temporale del progetto,
dall’inizio della prima attività fino al termine dell’ultima. Si vuole, infatti,
che il progetto abbia la minore durata complessiva possibile. Le date limite
del progetto sono dette release date (la data di inizio) e due date (la data
di scadenza). L’orizzonte temporale è il periodo di tempo durante il quale
si prevede lo svolgimento del progetto da schedulare, infatti esso contiene le
date appena descritte.
1.2 Problema di base
In letteratura, il corrispondente problema di base considerato è il Resource
Constrained Project Scheduling Problem (RCPSP), una sottoclasse di un ti-
pico Problema di Schedulazione, poiché incorpora le restrizioni di risorse nel
contesto della schedulazione dei progetti. Queste limitazioni caratterizzano
fortemente il problema e ne aumentano la complessità. Infatti, nei classici
6
11. problemi di schedulazione, l’obiettivo è assegnare le attività a determinati
intervalli di tempo in modo da ottimizzare un certo criterio, come la mini-
mizzazione del tempo totale di esecuzione o il rispetto di scadenze critiche,
senza tenere conto che le risorse possono non essere disponibili in certi mo-
menti.
In questo studio vengono modellate le seguenti caratteristiche:
• sono considerate soltanto le cosiddette risorse rinnovabili, ovvero risor-
se utilizzate e rilasciate nel corso del tempo, ad esempio i macchinari
e il personale aziendale, la cui capacità si “ricarica” al termine di ogni
unità temporale
• le risorse sono multi-skilled, ovvero hanno diverse skill per svolgere
diversi compiti
• si considera la variante deterministica del problema, quindi le infor-
mazioni necessarie per produrre la schedulazione sono note a priori;
l’allocazione delle risorse e l’esecuzione delle attività sono completa-
mente prevedibili, i risultati sono ripetibili se le condizioni e l’input
rimangono uguali
• le attività sono pre-emptive, ovvero possono essere interrotte durante
la loro esecuzione ed essere riprese in seguito
• le attività possono essere relazionate tra loro tramite relazioni di di-
pendenza del tipo Finish to Start (FS), ovvero l’attività che succede
il suo precedecessore può iniziare solo una volta che il predecessore ha
terminato
7
12. • le risorse possono lavorare in multi-tasking, ovvero eseguendo più di
un’attività nel corso di un’unità temporale
• in base alle skill, una o più attività possono essere svolte da più di una
risorsa
• una volta che una risorsa comincia a lavorare a un’attività, ne conti-
nuerà l’esecuzione fino al suo termine
Come descritto nel capitolo precedente, è importante evidenziare come l’uti-
lizzo delle sole risorse rinnovabili renda il problema notevolmente diverso dai
problemi che, invece, fanno uso di una diversa tipologia di risorse.
1.3 Classificazione del problema
Secondo la notazione classica utilizzata nei problemi di schedulazione, come
descritto nel libro più noto nell’ambito [4], questo specifico caso è dichiarato
come Rm | prmp | Cmax. Il significato di queste sigle è il seguente:
- sono considerate delle risorse non correlate tra loro (Rm), poiché sono
indipendenti l’una dall’altra e possono avere capacità diverse
- le attività sono pre-emptive (prmp)
- come obiettivo da minimizzare si considera il makespan (Cmax), ovve-
ro la durata dell’intero progetto dall’inizio della prima attività fino al
completamento dell’ultima
La schedulazione viene effettuata prima che il progetto inizi e assegna auto-
maticamente ogni attività a una o più risorse.
8
13. Tra i vari problemi di schedulazione, rappresentati tramite la Fig. 1.1,
quello studiato è dunque un problema che gestisce risorse umane, con un
obiettivo temporale, con parametri deterministici e che utilizza metodi riso-
lutivi esatti.
Figura 1.1: Tipologie di problemi di schedulazione
Il problema considerato in questo studio riguarda il singolo progetto e
si parla di Single Mode RCPSP (SMRCPSP) perché viene considerata, per
ogni attività, una sola modalità di esecuzione della stessa, ovvero un’unica
combinazione di risorse che vi lavorano con determinate unità.
Come anticipato nell’introduzione, RCPSP è un problema di schedulazio-
ne largamente studiato. La tipica modellazione riguardante i dati di input
è stata riproposta molto similmente, con le sole differenze dell’insieme del-
le skill Q e dei fattori riguardanti la limitazione per il multi-tasking e la
lavorazione “multi-risorsa”. Un altro punto distintivo del problema è la ca-
ratteristica delle attività di poter essere pre-emptive. Casi simili, infatti, non
9
14. sono stati frequentemente affrontati, quindi questo studio mira a riempire
questo gap. Inoltre, è importante precisare come questa caratteristica renda
il problema più complesso.
Anche i limiti imposti dalle date del progetto, per cui le attività non
possono iniziare prima di una certa data e non possono finire prima di un’altra
data, non sono stati utilizzati molto in letteratura. Queste considerazioni
comportano, nel modello a seguire, dei vincoli che sono molto importanti
se si pensa ai casi reali. In particolare, la scadenza di un progetto è un
importante fattore nella schedulazione dello stesso, dunque non rispettarla
può portare, in alcune situazioni, a conseguenze gravi.
1.4 Dati
Esaminando un progetto, i dati in ingresso per il modello considerati sono i
seguenti:
• T = {0, 1, . . . , h} è l’orizzonte temporale discreto, ovvero il periodo di
tempo durante il quale il progetto sarà completato
• D ∈ T è l’unità temporale di scadenza di consegna del progetto, ovvero
entro questa data tutte le attività del progetto devono essere state
completate
• S ∈ T è l’unità temporale di inizio del progetto
• J è l’insieme delle attività che costituiscono il progetto
10
15. • j = 0, 1, . . . , ¯
J, ¯
J + 1 con j ∈ J è un’attività , con j = 0 e j = ¯
J + 1
attività fittizie che hanno tempo di elaborazione e consumo di risorse
nulli, in quanto rappresentano l’inizio e la fine dello svolgimento del
progetto
• Fj è lo sforzo che richiede l’attività j, ovvero il numero di ore necessarie
a completarla
• Zj è il numero massimo di risorse fissate che possono lavorare in paral-
lelo sull’attività j
• A ⊆ J × J è l’insieme delle relazioni di precedenza tra le attività,
ovvero l’attività j non può iniziare prima che i suoi precedecessori Pj ⊆
A siano stati completamente eseguiti
• K è l’insieme delle risorse allocabili per il progetto
• k = 1, . . . , K̄ con k ∈ K è una risorsa
• Rkt è la capacità della risorsa k, ovvero la quantità di risorsa disponibile
nell’unità temporale t
• Ujk è l’unità di risorsa k richiesta per eseguire l’attività j in ogni t in
cui è eseguita
• Q è l’insieme delle skill, ovvero definisce quale o quali attività ogni
risorsa può svolgere
• Vk è il massimo numero di attività su cui una risorsa può lavorare in
ogni unità temporale
11
16. Tutti i parametri appena elencati sono numeri interi positivi.
La formulazione proposta introduce diverse innovazioni rispetto alla tipica
struttura del RCPSP, comunemente adottata nei documenti scientifici riguar-
danti questo argomento. Tra le novità principali si distinguono le seguenti
variabili decisionali: la variabile continua z e le variabili intere sj ed ej; que-
ste ultime rivestono un ruolo cruciale nell’efficienza del modello. Inoltre, tra
i parametri di input, vi sono il fattore di massimo “multi-risorsa” Zj e il
fattore di massimo “multi-tasking” Vk. Questi specifici parametri sono stati
introdotti al fine di rendere il problema di ottimizzazione più aderente alla
realtà e alle esigenze dei lavoratori umani.
1.5 Modello
L’approccio risolutivo affrontato in questo studio prevede l’utilizzo della Pro-
grammazione Lineare (LP), secondo cui il modello costruito è caratterizzato
dalla funzione obiettivo e dai vincoli lineari. In particolare, viene considera-
to il caso della Programmazione Lineare Intera Mista (MILP), in quanto le
variabili decisionali utilizzate sono intere e continue.
• Funzione obiettivo: minimizzazione del project makespan del progetto
min makespan (1.1)
12
17. • Variabili decisionali:
xjkt =
1, se l’attività j è eseguita dalla risorsa k nell’unità temporale t
0, altrimenti
(1.2)
z ∈ R (1.3)
sj ∈ Z è l’istante di inizio dell’attività j (1.4)
ej ∈ Z è l’istante di termine dell’attività j (1.5)
• Vincoli:
– minimizzare il makespan corrisponde a minimizzare il tempo di
completamento delle attività del progetto
min z (1.6)
ej ≤ z ∀j ∈ J (1.7)
– ogni attività j riceve la quantità di elaborazione necessaria
X
k∈K
X
t∈T
xjkt · Ujk = Fj ∀j ∈ J (1.8)
– una risorsa k non può mai eccedere la sua capacità nel bucket
temporale τ, con τ = [tx, ty] e tx, ty ∈ T
X
j∈J
X
t∈τ
xjkt · Ujk ≤ Rkτ ∀k ∈ K (1.9)
13
18. – l’istante di inizio di un’attività delimita “a sinistra” la sequenza
di xjkt che indica l’attività in esecuzione
sj ≤ t · xjkt ∀(j, k) ∈ Q, ∀t ∈ T con xjkt = 1 (1.10)
– l’istante di termine di un’attività delimita “a destra” la sequenza
di xjkt che indica l’attività in esecuzione
ej ≥ (t + 1) · xjkt ∀(j, k) ∈ Q, ∀t ∈ T con xjkt = 1 (1.11)
– se un’attività j è dipendente da un suo predecessore i, allora j
non può iniziare prima che i abbia terminato
ei ≤ sj ∀j ∈ J , ∀i ∈ Pj (1.12)
– un’attività ha bisogno di una sola skill con livello di abilità minimo
xjkt = 0 ∀j ∈ J, ∀k ∈ K, ∀t ∈ T tali che (j, k) /
∈ Q (1.13)
– tutte le attività del progetto devono iniziare dopo la data S di
inizio del progetto e finire prima della data di scadenza D del
progetto
sj ≥ S ∀j ∈ J (1.14)
ej ≤ D ∀j ∈ J (1.15)
– controllo sul multi-tasking delle risorse: una risorsa k non deve
14
19. lavorare su troppe attività in contemporanea
X
j∈J
xjkt ≤ Vk ∀k ∈ K, ∀t ∈ T (1.16)
– controllo sulla multirisorsa: un’attività j non deve coinvolgere
troppe risorse in contemporanea
X
k∈K
xjkt ≤ Zj ∀j ∈ J , ∀t ∈ T (1.17)
Tramite i vincoli (Eq. 1.16) e (Eq. 1.17) non si permette uno sfruttamento
delle risorse e nemmeno un eccessivo lavoro sulla singola attività, che risul-
terebbe in un calo della produttività invece che in un miglioramento. Tali
vincoli sono un’importante novità, proposta da questo modello, legata agli
innovativi fattori Zj e Vk presentati precedemente.
I vincoli (Eq. 1.10) vengono riscritti utilizzando il metodo del Big M :
sj ≤ t · xjkt + (1 − xjkt) · M ∀(j, k) ∈ Q, ∀t ∈ T (1.18)
con la costante M = 100, in modo da permettere l’implementazione del
vincolo in maniera lineare.
1.5.1 Multitasking
In questo studio è considerato anche l’aspetto del multi-tasking delle risorse,
ovvero la loro capacità di eseguire “contemporaneamente” più di un’attività.
Nello specifico caso delle persone che eseguono le attività, viene inteso che
15
20. una risorsa esegue delle attività in determinate unità temporali, ad esempio
i giorni, con decisione propria di come gestirsi nel dettaglio, ad esempio le
ore.
Diversi sono sia i vantaggi sia gli svantaggi dell’aspetto del multi-tasking.
Da un lato, si può ottenere una riduzione del tempo di completamento del
progetto che coinvolge le varie attività, mentre dall’altro lato per le risorse
può essere difficoltoso lavorare in questa modalità. In particolare, alcuni
studi [5] hanno affrontato questi aspetti, considerando come il multi-tasking
influenzasse le prestazioni di alcuni analisti (ovvero le risorse) e proponendo
una modellazione apposita.
Possono anche essere fatte delle considerazioni intuitive:
• il multi-tasking può portare a una maggiore dispersione dell’attenzione,
poiché la risorsa potrebbe dover costantemente passare da un compito
all’altro
• questi continui passaggi da un compito all’altro richiedono tempo (il
cosiddetto resumption lag [5]) e sforzo cognitivo, con conseguente ridu-
zione complessiva dell’efficienza e della produttività della risorsa
• il multi-tasking può quindi aumentare i livelli di stress e affaticamento,
portando alla risorsa una sensazione di sovraccarico di lavoro
A livello di formulazione matematica del modello, il multi-tasking è sta-
to permesso ma è stato sottoposto alla condizione dei vincoli (Eq. 1.16).
La scelta di utilizzare un valore cablato è stata motivata dalla semplicità.
In particolare, per “valore cablato” si intende l’utilizzo di un valore costan-
te di una variabile. In questo studio, sono stati utilizzati dei piccoli valori
16
21. come 3, 4 e 5, ad esempio, per il fattore massimo del multi-tasking e per
il fattore massimo del multi-risorsa. Un’idea per determinare il fattore del
multi-tasking in maniera flessibile e meglio adattabile al singolo progetto, ad
esempio, potrebbe essere quella di considerare se la risorsa sta lavorando ad
altre attività appartenenti ad altri progetti. In questo caso, non si utilizze-
rebbe nei vincoli (Eq. 1.16) il valore cablato Vk, bensı̀ si calcolerebbe per
ogni risorsa un valore specifico.
Un’altra idea potrebbe prevedere l’aggiunta di un attributo alle attività, ov-
vero l’urgenza, che potrebbe comportare diversi pesi alle attività e quindi
modificare il modello, sempre nei vincoli (Eq. 1.16).
17
22.
23. Capitolo 2
Risoluzione
2.1 Approcci generali
Per risolvere i problemi della tipologia discussa in questo lavoro, ovvero i
problemi di programmazione lineare intera mista (MILP), sono comunemente
utilizzati due tipi di approcci: le tecniche dei cutting planes e le tecniche
branch-and-bound. La tecnica MILP può essere efficacemente impiegata per
ottimizzare l’efficienza operativa di organizzazioni anche complesse, tenendo
conto delle richieste e delle capacità delle risorse, nonché di possibili regole
aziendali critiche. Indipendentemente dalle specifiche applicazioni in cui essa
viene impiegata, gli approcci risolutivi utilizzati sono gli stessi e vengono in
seguito descritti.
Le tecniche dei cutting planes producono un rilassamento del programma
intero, aggiungendo dei vincoli lineari che devono essere soddisfatti dalle
variabili intere. In questo modo, l’insieme delle delle soluzioni possibili viene
maggiormente vincolato senza che siano escluse le soluzioni intere. Viene
19
24. poi avviata la ricerca della soluzione, che termina quando ne viene trovata
una intera che è ottima per l’IP originale. Se, invece, non viene trovata tale
soluzione, si aggiungono ulteriori vincoli lineari e si procede nuovamente con
la sua ricerca.
Le tecniche branch-and-bound costituiscono un approccio avanzato per
affrontare la completa enumerazione di soluzioni, applicabile a numerosi pro-
blemi combinatori. La fase di branching corrisponde a un partizionamento
dello spazio delle soluzioni ed è utile poiché, in seguito, ogni parte sia con-
siderata separatamente. La fase di bounding si riferisce alla determinazione
di lower bounds per le varie parti. L’obiettivo è trascurare le porzioni di
soluzioni che presentano un lower bound sull’obiettivo maggiore rispetto a
una soluzione già identificata in un’altra suddivisione.
2.2 Approccio utilizzato
Per affrontare il problema, è stato implementato il modello in Python uti-
lizzando Gurobi come risolutore. Esso fa uso di un algoritmo esatto, per
risolvere il problema. Di seguito viene descritto come questo ottimizzatore
agisce.
2.2.1 Approccio di Gurobi
Gurobi adotta una strategia specifica in base al problema da affrontare e,
nel caso descritto, ha utilizzato una forma avanzata della tecnica branch-
and-cut. La tecnica base combina i due approcci descritti a inizio capitolo.
Questa procedura, infatti, si basa su un processo iniziale di rilassamento
20
25. lineare del problema, in cui le variabili possono assumere valori continui.
Successivamente, il problema viene suddiviso in sotto-problemi più piccoli
attraverso la tecnica del branching. Durante la risoluzione dei sotto-problemi,
l’ottimizzatore esplora le possibili soluzioni, riducendo progressivamente lo
spazio di ricerca attraverso criteri di lower bound e upper bound.
Alcune caratteristiche del risolutore in questione sono la fase di presolve,
il best bound e il gap. La fase di presolve consiste in una riduzione del
problema prima dell’applicazione dell’algoritmo di risoluzione. Ad esempio,
si sostituiscono alcuni valori di variabili o si effettuano delle piccole operazioni
ad alcuni vincoli. Naturalmente, questa fase mantiene il problema risultante
equivalente a quello in ingresso, che viene solamente ridotto. I valori di best
bound e gap sono utilizzati da Gurobi, durante la risoluzione, per capire
quando fermarsi. Il primo è il minimo dei valori obiettivo ottimi tra tutti
nodi correnti. Il secondo è la differenza tra l’upper e il lower bound: quando
il gap è zero, significa che si ha raggiunto la soluzione ottima. Il gap è stato
un valore attentamente osservato e ricercato nella fase di testing, poiché una
delle caratteristiche fondamentali del modello è la produzione di schedule
precise, ovvero con gap il più piccolo possibile.
21
26.
27. Capitolo 3
Test
Il modello è stato testato, prima con dei dati di riferimento utilizzati spesso in
letteratura, poi con dati di Cyberplan. Oltre ai risultati in termini di tempo
di computazione, la correttezza è stata verificata tramite alcuni strumenti
utilizzati nel contesto della gestione dei progetti.
3.1 Strumenti di gestione progetti
Nell’ambito della pianificazione e della schedulazione dei progetti, degli im-
portanti strumenti grafici sono solitamente utilizzati. Tramite essi, infatti,
è possibile avere sia il quadro generale del progetto sia modo di analizzare
diversi dettagli.
Nei seguenti paragrafi, vengono presentati e descritti due strumenti che
sono stati utilizzati, durante questo studio, per verificare la correttezza dei
risultati e analizzarli nel dettaglio. Si tratta di due rappresentazioni grafiche
dei progetti, con scopi e caratteristiche leggermente diversi.
23
28. 3.1.1 Diagramma di Gantt
Uno degli strumenti principali utilizzati nella gestione dei progetti è il dia-
gramma di Gantt. Si tratta di un diagramma a barre, basato sull’asse tem-
porale come ascissa e sull’insieme delle attività come ordinata. Un project
manager può visualizzare quando l’esecuzione dell’attività è iniziata, quando
essa termina e in quali specifici momenti è effettivamente eseguita. Trami-
te un software apposito, ad esempio Cyberplan, è possibile interagire con il
diagramma di Gantt per ottenere, tramite delle viste specifiche, ulteriori in-
formazioni. È importante, infatti, poter identificare quali risorse lavorano a
quali attività, quante ore vi sono state assegnate nello specifico, la quantità
di carico delle risorse e le dipendenze tra le attività. Per un project ma-
nager, in particolare, è importante utilizzare tale strumento per pianificare,
monitorare e comunicare efficacemente lo stato del progetto.
Tale diagramma è stato, dunque, uno strumento fondamentale durante il
corso di questo studio e, tramite qualche esempio, a seguire saranno mostrate
delle schedule prodotte dall’implementazione del modello.
3.1.2 Carico delle risorse
Un altro importante strumento visivo utilizzato nell’ambito del project mana-
gement è quello adibito a mostrare il carico delle risorse. Vengono utilizzati
degli istogrammi che rappresentano la capacità e il carico di ogni singola
risorsa in un singolo bucket temporale. Tramite Cyberplan, ad esempio,
è possibile scegliere se visualizzare il carico in una particolare granularità
temporale, ad esempio giornaliero, settimanale, mensile, annuale e via cosı̀.
24
29. Solitamente, l’asse orizzontale rappresenta il tempo, mentre sull’asse verti-
cale vengono rappresentati il carico e la capacità di una singola risorsa. In
particolare per questo studio, controllare questi istogrammi ha permesso di
verificare che non si realizzassero sovraccarichi delle risorse. Ciò significa
schedulare le attività nel tempo, in modo da non superare la capacità delle
risorse in nessun bucket temporale. Il sovraccarico, di solito, è raffigurato in
rosso, il carico in ocra e la capacità in verde. Si può anche rappresentare il
carico del progetto o dell’attività selezionata. Un project manager, dunque,
può chiaramente identificare se accadono dei sovraccarichi oppure sei sotto-
carichi nell’allocazione delle risorse per le varie attività a cui esse lavorano,
anche nel caso di più progetti.
3.2 PSPLIB
Come punto di riferimento iniziale, è stato utilizzato un dataset disponibile
online, il Project Scheduling Problem Library (PSPLIB) [6]. Si tratta di un
dataset largamente utilizzato in letteratura, infatti citato dalla maggioranza
dei paper rivolti allo studio della schedulazione in ambito servizi.
3.2.1 Analisi dei dati
È importante apportare una breve descrizione di questo dataset, in quanto
esso è stato utile per capire quali fossero le prestazioni del modello, ma non
ci si è potuti basare totalmente su questi ultimi, a seguire la motivazione. I
dati sono raccolti in diverse istanze, che sono categorizzate in base al numero
di attività del singolo progetto: 30, 60, 90 e 120. Quasi tutti i dati di
25
30. cui il modello necessita erano già presenti all’interno del dataset, è stato
necessario soltanto aggiungere i dati numerici per i fattori di multi-risorsa
e multi-tasking. In ogni singola istanza variano il numero di attività e le
specifiche precedenze tra di esse. Di conseguenza, le istanze non presentano
lo stesso tipo di rete e, quindi, nemmeno lo stesso tipo di difficoltà.
È essenziale sottolineare che tali esempi non riflettono in modo accu-
rato le situazioni reali, soprattutto perché, indipendentemente dal numero
di attività, il numero di risorse rimane costante per ogni istanza, ossia 4.
In contrasto con questa semplificazione, soprattutto nelle grandi aziende, la
quantità di risorse disponibili è notevolmente maggiore. Inoltre, anche i dati
relativi alle capacità delle risorse non sono descritti e motivati nel detta-
glio, quindi è stato necessario eseguire un’interpretazione e diverse prove. La
considerazione di questi due fattori relativi alle risorse risulta cruciale per
definire la dimensione e la complessità del problema. Pertanto, è possibile
comprendere che, considerando scenari più aderenti alla realtà, il problema
si rivela notevolmente più ampio e complesso.
Un’altra importante considerazione da fare riguarda i dati di inizio e
termine del progetto. Sebbene nel dataset essi siano dichiarati, relativamente
a ogni singola istanza, le formulazioni dei paper disponibili in letteratura non
ne tengono conto. In questo studio, invece, questo è stato considerato, come
rappresentato nei vincoli (Eq. 1.14) e (Eq. 1.15).
26
31. 3.2.2 Fase di test
I test sono stati eseguiti inizialmente solo tramite editor e cosı̀ sono stati
proseguiti per tenere conto dei tempi di computazione. In seguito, i dati di
PSPLIB sono stati importanti in Cyberplan e, dopo l’esecuzione dell’imple-
mentazione del modello, le schedule sono state visualizzate tramite diagram-
mi di Gantt e carico delle risorse. Un esempio è riportato nella Fig. 3.1.
La retta verticale rossa segna il “giorno di oggi”, nell’esempio posto al 19
febbraio 2024.
Figura 3.1: Diagramma di Gantt
Da questo esempio raffigurato è possibile fare diverse osservazioni. In
primo luogo, sono stati esclusi i fine settimana dalla rappresentazione perché
sono ipotizzati come giorni non lavorativi per le risorse, quindi si considera la
settimana lavorativa dal lunedı̀ al venerdı̀. È possibile notare come si verifichi
27
32. la pre-emption in alcune attività, ad esempio nelle attività con identificativi
5, 10, 13 e 16. L’effettiva esecuzione delle attività è rappresentata tramite i
rettangoli, che hanno un colore specifico a seconda della risorsa relativa (R0
giallo, R1 verde, R2 blu, R3 rosso). La loro dimensione è proporzionata alle
ore assegnate di giorno in giorno: maggiore è il numero di ore che la risorsa
impiega a svolgere l’attività in giorno e maggiore è l’area del rettangolo. Nella
Fig. 3.2 è mostrato nel dettaglio il punto appena spiegato: per l’attività 2,
la risorsa R0 lavora 2 ore in più rispetto all’attività R1.
Figura 3.2: Pre-emptions per l’attività 2 del progetto j3012 1
Le capacità delle stesse risorse della Fig. 3.2, ovvero R0 e R1, sono
verificate tramite il grafico del carico, illustrato in Fig. 3.3. Le capacità,
che sono rispettivamente 8 e 9 ore al giorno per le risorse R0 e R1, sono
rappresentate in verde, mentre il carico è rappresentato in rosso. Le barre
rosse non superano mai in altezza le barre verdi, ovvero non si verifica mai
un sovraccarico delle risorse in questione.
Figura 3.3: Carico delle risorse R0 e R1 nel progetto j3012 1
28
33. 3.3 Cyberplan
Successivamente, sono stati testati anche dei dati di alcuni progetti contenu-
ti all’interno del database del software Cyberplan. Questi dati si avvicinano
alla realtà maggiormente rispetto a quelli di PSPLIB e, inoltre, hanno dimo-
strato ulteriormente l’efficacia dell’implementazione del modello proposto.
L’utilizzo degli strumenti grafici, citati a inizio capitolo, è stato fondamen-
tale per verificare la correttezza dei risultati sia tramite quadro generale sia
nel dettaglio.
29
34.
35. Capitolo 4
Risultati
I risultati dell’implementazione del modello sono stati analizzati come pre-
stazioni, in termini computazionali, e come schedulazioni.
4.1 Tempi computazionali
Nella tabella 4.1 sono rappresentati i risultati ottenuti dal test sui dati di
PSPLIB. Tali esiti sono stati utili per testare il modello con istanze di varie
dimensioni e complessità, ottenendo i tempi di computazione. Le diverse
relazioni di precedenza tra le attività, le capacità delle risorse e le diverse
unità di risorsa richieste per svolgere le attività rendono, infatti, il problema
di complessità diversa da caso a caso.
Nella prima colonna della tabella sono elencati i “tipi” di istanze, ovvero
in base al numero di attività. Come dimensioni delle istanze, nella seconda
colonna sono mostrati il numero medio di vincoli e il numero medio delle
variabili delle istanze dello stesso “tipo”. Il numero medio varia da tipo a
31
36. tipo, in base al numero di istanze risultate feasible, ovvero risolvibili con
almeno una soluzione che soddisfa tutti i vincoli del problema. Nei casi di
j30 e j60 sono state utilizzate circa 400 istanze ciascuno, per j90 circa 250 e
per j120 circa 60. Nelle colonne successive sono illustrati i diversi tempi di
computazione ottenuti: il tempo medio, il tempo migliore e il tempo peggiore.
Nell’ultima colonna sono riportati i gap: il migliore e il peggiore.
Computation Times Gap
Instances Dimension Average Best Worst Best Worst
j30 38k × 28k 8.83 s 0.16 s 85.61 s 0% 0%
j60 146k × 108k 149.48 s 0.48 s 3204.51 s 0% 6.25%
j90 296k × 216k 506.55 s 1.82 s 3270.93 s 0% 9.3%
j120 412k × 287k 1627.74 s 40.70 s 3600.48 s 0% 9.61%
Tabella 4.1: Risultati dei test sulle istanze di PSPLIB.
È stato impostato il tempo limite di un’ora per l’ottimizzazione. In al-
cuni casi, si è verificato che, già dopo pochi minuti, si raggiungesse un cer-
to gap (inferiore al 10%), ma la computazione continuasse senza ulteriori
miglioramenti per il resto dell’ora prestabilita. Per queste istanze, è stato
considerato il tempo di ottimizzazione pari al tempo necessario per raggiun-
gere tale gap. Questa decisione si basa sull’osservazione che, in alcuni casi,
il gap desiderato viene raggiunto rapidamente dopo l’avvio del processo di
ottimizzazione, indicando una rapida convergenza dell’algoritmo verso solu-
zioni prossime all’ottimo. Tuttavia, nonostante il gap desiderato sia stato
inizialmente raggiunto, la computazione continua per l’intera durata dell’ora
32
37. senza miglioramenti significativi ulteriori. Ciò suggerisce che l’algoritmo ha
già trovato una soluzione soddisfacente per il problema in tempi relativamen-
te brevi. Nel contesto del project management, ottenere una soluzione con
gap inferiore al 10% entro un’ora è indice di un ottimo risultato. È importan-
te sottolineare che, molto probabilmente, impostando un tempo limite più
esteso o richiedendo un gap minore, è possibile ottenere soluzioni di qualità
superiore, ovvero più vicine all’ottimo.
Esaminando i tempi computazionali ottenuti, si possono fare le seguenti
considerazioni. Nella Fig. 4.1 si può osservare il grafico a dispersione dei
tempi computazionali delle istanze j30 ed è evidente come la grandissima
maggioranza delle istanze abbia un tempo di computazione inferiore ai 20
secondi. Solo pochissime istanze di questa classe richiedono appena più di
un minuto.
Figura 4.1: Grafico a dispersione dei tempi computazionali delle istanze j30
Riguardo alle istanze della classe j60, i risultati computazionali sono raf-
figurati nella Fig. 4.2. I tempi sono più lunghi rispetto a quelli ottenuti con
33
38. j30, con la prevalenza delle istanze risolte entro i 500 secondi, ovvero 8 minuti.
Figura 4.2: Grafico a dispersione dei tempi computazionali delle istanze j60
Per le istanze della classe j90 si può notare come la tendenza della mag-
gior parte dei tempi di computazione bassi si continui a verificare, come per
i j60 entro gli 8 minuti. C’è un numero maggiore di istanze con tempi di
computazione tra i 500 secondi e i 2000 secondi, ovvero tra gli 8 minuti e i
33 minuti.
Infine, per le istanze della classe j120 la differenza tra i tempi di computa-
zione si nota maggiormente, come riportato in Fig. 4.4.
34
39. Figura 4.3: Grafico a dispersione dei tempi computazionali delle istanze j90
Figura 4.4: Grafico a dispersione dei tempi computazionali delle istanze j120
Per una migliore visualizzazione di quanto in maggior numero siano le
istanze con gap molto basso, sono proposti i grafici riportati nelle Fig. 4.5,
Fig. 4.6 e Fig. 4.7. Per le istanze j30 non era necessario questo ulteriore
grafico, in quanto tutte le istanze sono state risolte all’ottimo, ovvero con
gap 0%.
35
40. Figura 4.5: Gap delle istanze j60
Figura 4.6: Gap delle istanze j90
Figura 4.7: Gap delle istanze j120
36
41. 4.2 Schedulazioni
Le schedule ottenute sono state analizzate nel dettaglio tramite il software
Cyberplan. È stata utilizzata, in particolare, l’istanza di PSPLIB denomi-
nata j3012 1. La scelta è stata motivata dal minor numero di attività, tra
le varie classi delle istanze di PSPLIB, e quindi migliore visibilità comples-
siva del progetto. Nelle rappresentazioni delle Fig. 4.8 (ovvero la Fig. 3.1
nella sezione precedente) e Fig. 4.9 sono visualizzati, rispettivamente, il dia-
gramma di Gantt delle attività del progetto e l’istogramma del carico delle
risorse. Si possono notare diversi dettagli. In primo luogo, come rappresen-
tato in Fig. 4.8, per ogni attività, non si verificano assegnamenti a molte
risorse, anzi diverse sono svolte solo da una o due risorse, anche se in base
ai dati di input sarebbero possibili più assegnamenti. Inoltre, alcune attività
vengono interrotte e riprese qualche giorno dopo, come da caratteristica del-
la pre-emption. Lo si può vedere tramite i rettangoli colorati all’interno dei
rettangoli azzurri: i primi rappresentanto l’effettiva esecuzione da parte delle
risorse (con un colore specifico per ogni risorsa), i secondi rappresentano le
varie attività. Maggiore è la dimensione del rettangolo rappresentante l’ede-
cuzione e maggiore è il numero di ore giornaliere che la corrispettiva risorsa
impiega a svolgere l’attività relativa. Riguardo alla Fig. 4.9, l’istogramma
del carico delle risorse mostra una distribuzione modesta: le risorse non la-
vorano in tutte le giornate e la loro capacità è utilizzata per intero solo in
pochi giorni, ad esempio solo il 5 e l’11 marzo per la risorsa R1, mentre per
R0 non accade mai. Ciò risulta particolarmente per la terza risorsa (R2), in
quanto non le è assegnata alcuna attività durante la prima metà della durata
37
42. del progetto.
Figura 4.8: Diagramma di Gantt dell’istanza j3012 1
Figura 4.9: Istogramma del carico delle risorse dell’istanza j3012 1
38
43. Diverse modifiche dei dati in input sono state apportate, per analizzare
come “reagisse” lo schedulatore. Come prima cosa, è stata modificata la
durata di un’attività che, inizialmente veniva assegnata solo a una risorsa,
ma in seguito alla modifica ha utilizzato tutte le risorse disponibili. La durata
dell’attività con identificativo 1 è stata incrementata da 2 ore a 140 ore, con
conseguente ritardo nel completamento del progetto di un giorno, come è
possibile vedere in Fig. 4.10. Come è possibile notare dalla Fig. 4.11, il
carico delle risorse è aumentato rispetto al caso precedente, soprattutto per
la terza risorsa.
Figura 4.10: Diagramma di Gantt dell’istanza j3012 1 modificata per l’attività 1
39
44. Figura 4.11: Istogramma del carico delle risorse dell’istanza j3012 1 modificata per
l’attività 1
Un’ulteriore modifica è stata apportata per quanto riguarda le unità di
risorsa richieste dalle varie attività. Portandole tutte al massimo, ovvero
ogni attività può utilizzare ogni risorsa per il 100% della sua capacità, si
può analizzare come lo schedulatore decide di effettuare gli assegnamenti.
Nelle immagini riportate nelle Fig. 4.12 e Fig. 4.13 sono visibili i risultati.
È subito evidente il largo anticipo con cui termina il progetto, rispetto ai
casi precedenti: invece di essere completato nella prima metà di marzo, esso
termina l’ultimo giorno di febbraio. Si nota come si verifichino poche pre-
emption e pochi casi di multi-risorsa, ovvero una stessa attività eseguita
da più risorse. L’istogramma del carico delle risorse è più “omogeneo” e
“concentrato”, ma le risorse non sono ancora utilizzate per l’intero delle loro
capacità.
40
45. Figura 4.12: Diagramma di Gantt dell’istanza j3012 1 con unità di risorsa massime
Figura 4.13: Istogramma del carico delle risorse dell’istanza j3012 1 con unità di risorsa
massime
41
46. Raddoppiando la durata di tutte le attività, dalle Fig. 4.14 e Fig. 4.15 si
può osservare come, naturalmente, il progetto venga prolungato fino ai primi
giorni di marzo e come si verifichino più casi di pre-emption e multi-risorsa.
È evidente che non si verifica più il multi-tasking da parte delle risorse, quindi
lo schedulatore preferisce assegnare per intero della sua capacità ogni risor-
sa possibile, invece di soddividerle in multiple assegnazioni all’interno della
stessa unità temporale.
Figura 4.14: Diagramma di Gantt dell’istanza j3012 1 con le durate raddoppiate di
tutte le attività
42
47. Figura 4.15: Istogramma del carico delle risorse dell’istanza j3012 1 con le durate rad-
doppiate di tutte le attività
Raddoppiando ulteriormente la durata di tutte le attività, ovvero quadru-
plicando le durate originali, il progetto viene prolungato ancora e si verificano
sempre più casi di pre-emption e multi-risorsa. Si può quindi concludere che
questi due elementi della schedulazione dipendono dalle caratteristiche delle
attività presenti. I risultati sono visibili nelle immagini Fig. 4.16 e Fig. 4.17.
43
48. Figura 4.16: Diagramma di Gantt dell’istanza j3012 1 con le durate quadruplicate di
tutte le attività
Figura 4.17: Istogramma del carico delle risorse dell’istanza j3012 1 con le durate qua-
druplicate di tutte le attività
44
49. A livello di tempo di computazione, è interessante evidenziare come esso
aumenti progressivamente, a seguito di tutte le modifiche apportate ai dati
in ingresso. A parità di risorse (sia numero, sia capacità), di date limite del
progetto e di fattori massimi prestabiliti, la durata delle attività ha conse-
guenze importanti per il tempo di computazione dell’implementazione del
modello.
Istanze Tempo di computazione
Originale 2.55 s
Durate raddoppiate 36.53 s
Durate quadruplicate 156.08 s
Tabella 4.2: Confronti dei tempi di computazione dell’istanza j3012 1 a se-
guito delle modifiche.
45
50.
51. Capitolo 5
Conclusioni
Questo elaborato propone un innovativo modello di ottimizzazione matemati-
ca finalizzato a generare un’efficiente schedulazione delle attività del persona-
le. Il duplice obiettivo è stato quindi raggiunto: la schedulazione si avvicina
notevolmente all’ottimo, se non addirittura raggiungendolo, e ciò è stato ot-
tenuto in un breve tempo di computazione. Rispetto alle formulazioni già
presenti nella letteratura, questo modello che risolve il cosiddetto Resource
Constrained Project Scheduling Problem introduce l’utilizzo di alcune nuove
variabili decisionali e di due nuovi parametri in input, con conseguenti vinco-
li. La schedulazione risolutiva tiene quindi conto maggiormente delle esigenze
dei lavoratori, in modo da non permetterne uno sfruttamento o un sovracca-
rico di lavoro, e promuovendo la produttività complessiva aziendale mediante
il controllo del numero eccessivo di lavoratori su una singola attività.
Tuttavia, è importante considerare alcune limitazioni del presente stu-
dio. Una delle limitazioni principali potrebbe essere la scelta semplificata
di utilizzare dei valori “cablati” (ovvero decisi e fissati a priori, prima del-
47
52. la produzione della schedulazione) per i fattori di massimo multi-tasking e
multi-risorsa. Inoltre, ci sono alcune direzioni future che meritano ulteriori
esplorazioni. Ad esempio, sarebbe interessante svolgere un’analisi di sensiti-
vità, per investigare in modo più dettagliato come la variazione dei parametri
di input influenzi la schedulazione prodotta. A seguito di tale analisi, sarebbe
di grande innovazione e utilità riuscire a sviluppare un framework in grado
di implementare una schedulazione resiliente, ovvero che, indipendentemente
dalle perturbazioni che potrebbero subire i dati in input, restituisca un risul-
tato il più possibile vicino all’ottimo. In conclusione, i risultati presentati nel
capitolo precedente dimostrano che il modello proposto e la sua implemen-
tazione offrono delle valide schedulazioni, sia in termini di ottimalità della
soluzione sia per il breve tempo di computazione necessario.
48
53. Bibliografia
[1] A. Karam, S. Lazarova-Molnar, Recent Trends in Solving the Determi-
nistic Resource Constrained Project Scheduling Problem, Research Gate,
(2013).
[2] M. Gomez Sanchez, E. Lalla-Ruiz, A. Fernandez Gil, C. Castro, S.
Voss, Resource-constrained multi-project scheduling problem: A survey,
European Journal of Operational Research, (2022).
[3] J. Blazewicz, J.K. Lenstra, A.H.G.Rinnooy Kan, Scheduling subject to
resource constraints: classification and complexity, Discrete Applied
Mathematics, (1983).
[4] M. L. Pinedo, Scheduling: Theory, Algorithms, and Systems, Springer,
Fourth Edition, (2010).
[5] V. F. Cavalcante, C. H. Cordonha, R. G. Herrmann, A Resource Con-
strained Project Scheduling Problem with Bounded Multitasking, IFAC
Proceedings Volumes, (2013).
[6] PSPLIB Dataset disponibile online: https://www.om-db.wi.tum.de/
psplib/main.html
49