SlideShare a Scribd company logo
1 of 53
Download to read offline
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
Indice
Introduzione 1
1 Formalizzazione del problema 5
1.1 Terminologia . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Problema di base . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Classificazione del problema . . . . . . . . . . . . . . . . . . . 8
1.4 Dati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5 Modello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.5.1 Multitasking . . . . . . . . . . . . . . . . . . . . . . . . 15
2 Risoluzione 19
2.1 Approcci generali . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2 Approccio utilizzato . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.1 Approccio di Gurobi . . . . . . . . . . . . . . . . . . . 20
3 Test 23
3.1 Strumenti di gestione progetti . . . . . . . . . . . . . . . . . . 23
3.1.1 Diagramma di Gantt . . . . . . . . . . . . . . . . . . . 24
3.1.2 Carico delle risorse . . . . . . . . . . . . . . . . . . . . 24
3.2 PSPLIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.1 Analisi dei dati . . . . . . . . . . . . . . . . . . . . . . 25
3.2.2 Fase di test . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3 Cyberplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4 Risultati 31
4.1 Tempi computazionali . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Schedulazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5 Conclusioni 47
Bibliografia 49
i
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
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
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
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
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
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
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
• 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
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
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
• 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
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
• 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
– 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Figura 4.5: Gap delle istanze j60
Figura 4.6: Gap delle istanze j90
Figura 4.7: Gap delle istanze j120
36
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
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
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
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
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
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
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
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
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
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
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
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

More Related Content

Similar to Sviluppo e implementazione di un modello di ottimizzazione per un'efficiente schedulazione delle attività del personale

Stefano Bragaglia MSc Thesis, awarded as Best Italian thesis in AI 2009/2010
Stefano Bragaglia MSc Thesis, awarded as Best Italian thesis in AI 2009/2010Stefano Bragaglia MSc Thesis, awarded as Best Italian thesis in AI 2009/2010
Stefano Bragaglia MSc Thesis, awarded as Best Italian thesis in AI 2009/2010Stefano Bragaglia
 
Un sistema di persistenza per motori di workflow business-oriented BPMN
Un sistema di persistenza per motori di workflow business-oriented BPMNUn sistema di persistenza per motori di workflow business-oriented BPMN
Un sistema di persistenza per motori di workflow business-oriented BPMNAlessandro Segatto
 
Migrazione dei meccanismi di workflow di un sistema informativo assicurativo ...
Migrazione dei meccanismi di workflow di un sistema informativo assicurativo ...Migrazione dei meccanismi di workflow di un sistema informativo assicurativo ...
Migrazione dei meccanismi di workflow di un sistema informativo assicurativo ...Donato Clun
 
Studio e implementazione di uno strumento di configurazione e visualizzazione...
Studio e implementazione di uno strumento di configurazione e visualizzazione...Studio e implementazione di uno strumento di configurazione e visualizzazione...
Studio e implementazione di uno strumento di configurazione e visualizzazione...Matteo Miotto
 
Sviluppo e realizzazione di un sistema per la manipolazione di superfici trid...
Sviluppo e realizzazione di un sistema per la manipolazione di superfici trid...Sviluppo e realizzazione di un sistema per la manipolazione di superfici trid...
Sviluppo e realizzazione di un sistema per la manipolazione di superfici trid...Raffaele Bernardi
 
METIS D3.4: Workshop package versione finale: workshop per diversi livelli e ...
METIS D3.4: Workshop package versione finale: workshop per diversi livelli e ...METIS D3.4: Workshop package versione finale: workshop per diversi livelli e ...
METIS D3.4: Workshop package versione finale: workshop per diversi livelli e ...METIS-project
 
Presentazione tesi commenti
Presentazione tesi commentiPresentazione tesi commenti
Presentazione tesi commentiGabriele Paesani
 
Analisi e realizzazione di uno strumento per la verifica di conformità su sis...
Analisi e realizzazione di uno strumento per la verifica di conformità su sis...Analisi e realizzazione di uno strumento per la verifica di conformità su sis...
Analisi e realizzazione di uno strumento per la verifica di conformità su sis...Davide Bravin
 
Il Ciclo della Reattività Aziendale
Il Ciclo della Reattività AziendaleIl Ciclo della Reattività Aziendale
Il Ciclo della Reattività AziendaleEnrikGjoka
 
CaputiDomenicoMagistrale
CaputiDomenicoMagistraleCaputiDomenicoMagistrale
CaputiDomenicoMagistraleDomenico Caputi
 
Documentazione progetto software - IoSegnalo
Documentazione progetto software - IoSegnaloDocumentazione progetto software - IoSegnalo
Documentazione progetto software - IoSegnaloMarco Vaiano
 
Cloud Computing e Modelli di Business
Cloud Computing e Modelli di Business Cloud Computing e Modelli di Business
Cloud Computing e Modelli di Business Andrea Cavicchini
 
Analisi di prestazione dell'interprete tuProlog su piattaforma Java - Tesi
Analisi di prestazione dell'interprete tuProlog su piattaforma Java - TesiAnalisi di prestazione dell'interprete tuProlog su piattaforma Java - Tesi
Analisi di prestazione dell'interprete tuProlog su piattaforma Java - TesiMicheleDamian
 
Progettazione e sviluppo di un'applicazione web per la gestione di dati di at...
Progettazione e sviluppo di un'applicazione web per la gestione di dati di at...Progettazione e sviluppo di un'applicazione web per la gestione di dati di at...
Progettazione e sviluppo di un'applicazione web per la gestione di dati di at...daniel_zotti
 
LA SIMULAZIONE DINAMICA NELLA PROGETTAZIONE INTRA-LOGISTICA
LA SIMULAZIONE DINAMICA NELLA PROGETTAZIONE INTRA-LOGISTICALA SIMULAZIONE DINAMICA NELLA PROGETTAZIONE INTRA-LOGISTICA
LA SIMULAZIONE DINAMICA NELLA PROGETTAZIONE INTRA-LOGISTICAlogisticaefficiente
 
L'IMPRESA AGILE & MOBILE 2.0_Metodologia Agile Project Management (Ing. Rea)
L'IMPRESA AGILE & MOBILE 2.0_Metodologia Agile Project Management (Ing. Rea)L'IMPRESA AGILE & MOBILE 2.0_Metodologia Agile Project Management (Ing. Rea)
L'IMPRESA AGILE & MOBILE 2.0_Metodologia Agile Project Management (Ing. Rea)Pragma Management Systems S.r.l.
 
Analisi sperimentale comparativa dell’evolvibilità nei sistemi di evoluzione ...
Analisi sperimentale comparativa dell’evolvibilità nei sistemi di evoluzione ...Analisi sperimentale comparativa dell’evolvibilità nei sistemi di evoluzione ...
Analisi sperimentale comparativa dell’evolvibilità nei sistemi di evoluzione ...Danny Tagliapietra
 

Similar to Sviluppo e implementazione di un modello di ottimizzazione per un'efficiente schedulazione delle attività del personale (20)

Stefano Bragaglia MSc Thesis, awarded as Best Italian thesis in AI 2009/2010
Stefano Bragaglia MSc Thesis, awarded as Best Italian thesis in AI 2009/2010Stefano Bragaglia MSc Thesis, awarded as Best Italian thesis in AI 2009/2010
Stefano Bragaglia MSc Thesis, awarded as Best Italian thesis in AI 2009/2010
 
Un sistema di persistenza per motori di workflow business-oriented BPMN
Un sistema di persistenza per motori di workflow business-oriented BPMNUn sistema di persistenza per motori di workflow business-oriented BPMN
Un sistema di persistenza per motori di workflow business-oriented BPMN
 
Migrazione dei meccanismi di workflow di un sistema informativo assicurativo ...
Migrazione dei meccanismi di workflow di un sistema informativo assicurativo ...Migrazione dei meccanismi di workflow di un sistema informativo assicurativo ...
Migrazione dei meccanismi di workflow di un sistema informativo assicurativo ...
 
Studio e implementazione di uno strumento di configurazione e visualizzazione...
Studio e implementazione di uno strumento di configurazione e visualizzazione...Studio e implementazione di uno strumento di configurazione e visualizzazione...
Studio e implementazione di uno strumento di configurazione e visualizzazione...
 
Sviluppo e realizzazione di un sistema per la manipolazione di superfici trid...
Sviluppo e realizzazione di un sistema per la manipolazione di superfici trid...Sviluppo e realizzazione di un sistema per la manipolazione di superfici trid...
Sviluppo e realizzazione di un sistema per la manipolazione di superfici trid...
 
METIS D3.4: Workshop package versione finale: workshop per diversi livelli e ...
METIS D3.4: Workshop package versione finale: workshop per diversi livelli e ...METIS D3.4: Workshop package versione finale: workshop per diversi livelli e ...
METIS D3.4: Workshop package versione finale: workshop per diversi livelli e ...
 
Presentazione tesi commenti
Presentazione tesi commentiPresentazione tesi commenti
Presentazione tesi commenti
 
Analisi e realizzazione di uno strumento per la verifica di conformità su sis...
Analisi e realizzazione di uno strumento per la verifica di conformità su sis...Analisi e realizzazione di uno strumento per la verifica di conformità su sis...
Analisi e realizzazione di uno strumento per la verifica di conformità su sis...
 
Semplicemente Agile
Semplicemente AgileSemplicemente Agile
Semplicemente Agile
 
Il Ciclo della Reattività Aziendale
Il Ciclo della Reattività AziendaleIl Ciclo della Reattività Aziendale
Il Ciclo della Reattività Aziendale
 
CaputiDomenicoMagistrale
CaputiDomenicoMagistraleCaputiDomenicoMagistrale
CaputiDomenicoMagistrale
 
Documentazione progetto software - IoSegnalo
Documentazione progetto software - IoSegnaloDocumentazione progetto software - IoSegnalo
Documentazione progetto software - IoSegnalo
 
Cloud Computing e Modelli di Business
Cloud Computing e Modelli di Business Cloud Computing e Modelli di Business
Cloud Computing e Modelli di Business
 
Analisi di prestazione dell'interprete tuProlog su piattaforma Java - Tesi
Analisi di prestazione dell'interprete tuProlog su piattaforma Java - TesiAnalisi di prestazione dell'interprete tuProlog su piattaforma Java - Tesi
Analisi di prestazione dell'interprete tuProlog su piattaforma Java - Tesi
 
Progettazione e sviluppo di un'applicazione web per la gestione di dati di at...
Progettazione e sviluppo di un'applicazione web per la gestione di dati di at...Progettazione e sviluppo di un'applicazione web per la gestione di dati di at...
Progettazione e sviluppo di un'applicazione web per la gestione di dati di at...
 
Compas Project
Compas ProjectCompas Project
Compas Project
 
LA SIMULAZIONE DINAMICA NELLA PROGETTAZIONE INTRA-LOGISTICA
LA SIMULAZIONE DINAMICA NELLA PROGETTAZIONE INTRA-LOGISTICALA SIMULAZIONE DINAMICA NELLA PROGETTAZIONE INTRA-LOGISTICA
LA SIMULAZIONE DINAMICA NELLA PROGETTAZIONE INTRA-LOGISTICA
 
TesiEtta
TesiEttaTesiEtta
TesiEtta
 
L'IMPRESA AGILE & MOBILE 2.0_Metodologia Agile Project Management (Ing. Rea)
L'IMPRESA AGILE & MOBILE 2.0_Metodologia Agile Project Management (Ing. Rea)L'IMPRESA AGILE & MOBILE 2.0_Metodologia Agile Project Management (Ing. Rea)
L'IMPRESA AGILE & MOBILE 2.0_Metodologia Agile Project Management (Ing. Rea)
 
Analisi sperimentale comparativa dell’evolvibilità nei sistemi di evoluzione ...
Analisi sperimentale comparativa dell’evolvibilità nei sistemi di evoluzione ...Analisi sperimentale comparativa dell’evolvibilità nei sistemi di evoluzione ...
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
  • 2.
  • 3. Indice Introduzione 1 1 Formalizzazione del problema 5 1.1 Terminologia . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2 Problema di base . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3 Classificazione del problema . . . . . . . . . . . . . . . . . . . 8 1.4 Dati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.5 Modello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.5.1 Multitasking . . . . . . . . . . . . . . . . . . . . . . . . 15 2 Risoluzione 19 2.1 Approcci generali . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.2 Approccio utilizzato . . . . . . . . . . . . . . . . . . . . . . . 20 2.2.1 Approccio di Gurobi . . . . . . . . . . . . . . . . . . . 20 3 Test 23 3.1 Strumenti di gestione progetti . . . . . . . . . . . . . . . . . . 23 3.1.1 Diagramma di Gantt . . . . . . . . . . . . . . . . . . . 24 3.1.2 Carico delle risorse . . . . . . . . . . . . . . . . . . . . 24 3.2 PSPLIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.2.1 Analisi dei dati . . . . . . . . . . . . . . . . . . . . . . 25 3.2.2 Fase di test . . . . . . . . . . . . . . . . . . . . . . . . 27 3.3 Cyberplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4 Risultati 31 4.1 Tempi computazionali . . . . . . . . . . . . . . . . . . . . . . 31 4.2 Schedulazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5 Conclusioni 47 Bibliografia 49 i
  • 4.
  • 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