Analisi dei Requisiti e Definizione delle Specifiche di un Sistema Informativo per il Production Planning nel Settore Moda-Abbigliamento

D

I

’E

S

,

T

C

RELAZIONE PER IL CONSEGUIMENTO DELLA LAUREA MAGISTRALE IN INGEGNERIA GESTIONALE

Analisi dei Requisiti e Definizione delle Specifiche di un

Sistema Informativo per il Production Planning nel

Settore Moda-Abbigliamento

SINTESI

RELATORI IL CANDIDATO

Prof. Ing. Riccardo Dulmin Mattia Colombi

Dipartimento di Ingegneria dell’Energia, colombimattia.it@gmail.com dei Sistemi, del Territorio e delle Costruzioni

Prof. Ing. Davide Aloini

Dipartimento di Ingegneria dell’Energia, dei Sistemi, del Territorio e delle Costruzioni Dott. Paolo Sarinelli

Sessione di Laurea del 19/07/2017 Anno Accademico 2016/2017

2

Analisi dei Requisiti e Definizione delle Specifiche di un Sistema Informativo per il Production Planning nel Settore Moda-Abbigliamento

Mattia Colombi

Sommario

Questa tesi è il risultato di un periodo di tirocinio presso un’Azienda IT che realizza sistemi informativi a supporto dei processi di supply chain management per il settore fashion e luxury retail. L’Azienda ha deciso di introdurre all’interno del proprio portafoglio prodotti una soluzione per poter estendere le funzionalità dell’attuale sistema di pianificazione proprietario riguardo il processo di programmazione e controllo della produzione.

Il presente elaborato riporta la fase di analisi svolta all’interno del progetto per la definizione della nuova soluzione informativa. Dopo una prima fase di analisi del contesto per l’individuazione dei requisiti è stato strutturato un metodo che ha portato alla definizione delle funzioni, delle rispettive logiche e dei dati necessari per la nuova soluzione informativa per la programmazione e il controllo della produzione. Il metodo utilizzato è stato formalizzato utilizzando gli strumenti messi a disposizione del linguaggio UML (unified model language). L’analisi svolta ha permesso di definire una soluzione le cui funzioni permettono un nuovo approccio alla pianificazione rispetto all’approccio tradizionale, oltre ad aver definito gli input per le successive fasi di sviluppo del software.

Abstract

This thesis work is the result of an internship at an IT Company that develops information systems to support supply chain management processes in fashion and luxury retail industry. The Company has decided to introduce within own applications portfolio for production planning a solution to extend short-term production planning and control functionalities. The following paper illustrates the analysis phase within the project to define the new information solution. After the first phase of context analysis to identify the requirements, a method has been structured to define the functions with their respective logics and data that the new information solution for short-term planning and control needed. Method has been formalized using UML (unified model language).

The analysis results define an information solution whose functions let to introduce a new approach to production planning compared to traditional approach, and also inputs for next project phases have been defined.

1

1. Introduzione

Il presente elaborato è il risultato di un periodo di tirocinio presso un’Azienda IT che realizza sistemi informativi a supporto dei processi di supply chain management per le aziende del settore Fashion e Luxury retail. L’Azienda presso la quale è stato svolto il tirocinio ha come obiettivo l’introduzione, all’interno del proprio portafoglio di soluzioni informative per il settore moda-abbigliamento, di un sistema informativo finalizzato al supporto dei processi di programmazione e controllo della produzione. L’Azienda richiede che la soluzione IT da definire si possa integrare con l’attuale suite applicativa dell’azienda, sia dal punto di vista dei processi, andando ad aggiungere e/o estendere le funzioni che supportano il processo di pianificazione, sia dal punto di vista dei dati da utilizzare. Il progetto si posiziona nella fase di analisi all’interno del ciclo vita del software e gli obiettivi del progetto sono:

 Definire le funzionalità per supportare i processi di programmazione, controllo e monitoraggio (strato delle regole di un sistema informativo)

 Definire i dati necessari e la loro struttura per le elaborazioni delle funzionalità prima definite (strato dei dati di un sistema informativo)

Non sono inclusi nel project scope: processi di gestione della domanda, del magazzino, di pianificazione aggregata. Sono esclusi anche i processi di pianificazione operativa già ampiamente supportati dalle funzioni di sistemi informativi proprietari dell’Azienda IT. Nel presente elaborato viene descritta la metodologia utilizzata per conseguire gli obiettivi del progetto. Le fasi del metodo utilizzato sono rappresentate in Figura 1 e descritte nei capitoli seguenti. Le analisi svolte sono state formalizzate tramite UML (unified model language), linguaggio di modellazione e

specifica basato sul paradigma orientato agli oggetti nella progettazione e sviluppo software, il quale mette a disposizione vari strumenti e diagrammi che permettono di descrivere un software dal punto di vista strutturale, comportamentale e architetturale.

Figura 1 Analisi del Contesto

Analisi dei processi di produzione Analisi dei processi di

Programmazione e Controllo Analisi dei SI per la Programmazione e

Controllo Posizionamento del Progetto rispetto al processo di pianificazione

Analisi dei Requisiti

Requisiti per la Programmazione della Produzione Requisiti per il Controllo della Programmazione Requisiti per il Monitoraggio della Produzione

Analisi delle Funzioni

Riesame dei Casi d’Uso Definizione delle Funzioni Definizione della Logica Formalizzazione Requisiti (Casi d’Uso) Posizionamento della

Nuova Soluzione rispetto ad altri SI

Analisi della Struttura del Sistema

Definizione dei Dati

Definizione delle relazioni tra i Dati

2

2. Analisi del Contesto

Al fine di definire i requisiti della Nuova Soluzione IT, è necessario prima analizzare il contesto in cui l’applicativo verrà utilizzato. L’analisi del contesto ha interessato due macro aree:  Analisi delle caratteristiche del settore moda-abbigliamento, svolta prendendo a

riferimento i processi di produzione e di pianificazione di una azienda cliente tipo dell’Azienda IT;

 Analisi delle soluzioni informative esistenti per la programmazione e il controllo della produzione.

2.1 Processi Azienda Caso Studio

L’analisi in questione riguarda un’azienda che realizza prodotti d’abbigliamento sia su commessa per i grandi nomi della moda che per la realizzazione di una propria collezione.

2.1.1 Produzione

L’analisi dei processi di produzione è stata svolta al fine di individuare elementi caratterizzanti da tenere in considerazione dal punto di vista di un sistema informativo. L’azienda Caso Studio è caratterizzata dalla produzione di un’elevata varietà di articoli ma ognuno dei quali realizzato in piccoli volumi. Per questi motivi la produzione è organizzata a lotti. Le caratteristiche evidenziate del processo di produzione sono:

 Operazioni ripetitive all’interno del singolo lotto, ma la sequenza e le operazioni coinvolte possono variare notevolmente da un lotto all’altro.

 Produzione organizzata per departments (centri di lavoro).

 Alcune fasi di produzione sono affidate a terzisti (conto lavoro): riguardano le operazioni svolte nel cutting e washing department, ovvero le fasi col più alto grado di automazione. Sono svolte internamente gran parte delle operazioni manuali, soprattutto per le fasi che troviamo nel sewing department.

2.1.2 Pianificazione e Controllo della Produzione

Anche in questo caso l’analisi è stata svolta per individuare caratteristiche fondamentali per il sistema informativo, ma risulta particolarmente importante anche per individuare l’area di competenza del progetto all’interno del processo di pianificazione (vedi Figura 2 a fine descrizione). La pianificazione riguarda sia le risorse per la realizzazione della collezione che le risorse per le commesse. Il processo di pianificazione è diviso in lungo, medio e breve periodo e viene ripetuto per ogni collezione. La pianificazione di lungo periodo, prendendo a riferimento la collezione primavera/estate, ha inizio a maggio dell’anno precedente. Dopo che

3

sono stati realizzati i sample, definito il catalogo e svolte le analisi previsionali sulle vendite, l’output fondamentale di questa fase è un piano di acquisti per i materiali principali. Il piano definito è un vincolo per le fasi successive di pianificazione. La Pianificazione di Medio Periodo ha inizio dal mese di settembre ed è affiancata dalla campagna vendite (ottobre-dicembre) che permette di ottenere dati reali sull’andamento della domanda per aggiornare le previsioni. La pianificazione di medio periodo è caratterizzata da:

 Piano di produzione “al buio”: è il primo piano ed è definito per pianificare la produzione di circa il 40% delle previsioni di vendita. In funzione di questo piano vengono generati gli ordini di acquisto per gli altri componenti. Gli ordini di acquisto successivamente vengono emessi con cadenza regolare (due settimane) in funzione dell’andamento della domanda (campagna vendite) e rappresentano un vincolo per i piani di produzione che verranno definiti successivamente.

 Piano di Produzione “a regime”: quando si rileva che con il piano “al buio” non è più possibile soddisfare la domanda, si determinano dei piani a regime che permette di definire le quantità da realizzare entro le date di spedizione predefinite. I piani a regime, a differenza di quelli al buio, sono aggiornati in funzione dell’andamento della domanda. Alla pianificazione della propria collezione è affiancata la pianificazione per la realizzazione delle commesse richieste dai clienti moda. In questo caso risulta fondamentale definire una data di completamento

fattibile e, quindi, avere una certa flessibilità produttiva. La Pianificazione di Breve Periodo si ha ogni volta che viene confermato un piano di produzione. Vengono definiti gli ordini di produzione (articolo, quantità per taglia,

colore, data di

completamento) tenendo conto di una serie di informazioni come il lot size. Devono essere sequenziate

4

realizzazione dell’oggetto dell’ordine di produzione sfruttando le informazioni dei cicli di lavoro (fasi, risorse (departments), tempi), e distinte base. Sono definiti ordini di produzione per: collezione, commesse, sample (sia per catalogo che per commesse) e ordini per domanda straordinaria. Il Processo di Controllo affianca il processo di pianificazione e permette di prendere decisioni fattibili in termini di capacità produttiva, considerando che per l’importanza strategica circa il 60% è destinata alle commesse, di disponibilità materiali, considerando i vincoli degli ordini dei materiali principali per il piano al buio e anche degli ordini dei componenti per i piani a regime. Tramite il controllo l’azienda è capace anche di perseguire i propri obiettivi di capacità e di risposta al cliente rispettivamente per la propria collezione e per le commesse. Il Monitoraggio, invece, consente che ciò che è stato pianificato sia rispettato in fase di realizzazione controllando diversi parametri relativi all’avanzamento degli ordini di produzione.

2.2 Sistemi Informativi

Per l’analisi dei sistemi informativi sono stati presi a riferimento i processi di Supply Chain Management descritti dal modello SCOR (Supply Chain Operations Reference) e rispetto a questi sono stati posizionati i sistemi informativi descritti in letteratura. I sistemi che supportano i processi di interesse per il progetto sono risultati essere i sistemi ERP (Enterprise Resource Planning), APS (Advanced Planning and Scheduling) e MES (Manufacturing Execution System).

2.2.1 ERP

Dall’analisi riguardo all’utilizzo dei sistemi ERP nelle aziende è emerso che:

 I sistemi ERP pur offrendo un’ampia copertura funzionale riguardo i processi di pianificazione non garantiscono un grado di specializzazione tale da rispondere con efficienze, efficacia e flessibilità alle esigenze delle aziende manifatturiere.

 I sistemi ERP grazie alla loro estensione funzionale governano le anagrafiche di base e rappresentano il baricentro del sistema informativo aziendale attorno ai quali si collocano spesso altri Enterprise System che integrano soluzione specializzate nella gestione, pianificazione e controllo della produzione, come i sistemi APS e MES

2.2.2 APS e MES

L’analisi delle caratteristiche di questi sistemi ha fatto emergere le funzionalità (avanzate rispetto ai sistemi ERP) che mettono a disposizione per il processo di pianificazione. Le

5

funzionalità emerse sono riportate nella tabella seguente e sono evidenziate le funzionalità che possono essere di interesse per la Nuova Soluzione IT coerentemente col project scope.

Tabella 1

In seguito a quanto emerso dall’analisi delle soluzioni informative, tenendo sempre presente gli obiettivi e il project scope, è stato possibile posizionare la Nuova Soluzione IT come un Sistema APS per i processi di pianificazione di medio/breve periodo con alcune caratteristiche dei sistemi MES. Viste le caratteristiche di interesse, è stato possibile ricercare altre soluzioni verticali per il settore moda-abbigliamento presenti sul mercato e comparare le funzioni che hanno integrato.

3. Requisiti

I requisiti funzionali per la Nuova Soluzione IT sono stati definiti sfruttando le informazioni acquisite dall’analisi del contesto e l’esperienza maturata dall’Azienda IT nel settore. Il primo passo per la definizione dei requisiti è stato individuare i desiderata (requisiti funzionali emersi dall’analisi del contesto) e poi “tradurli” utilizzando gli strumenti messi a disposizione dal linguaggio UML per ottenere i requisiti formalizzati. Il primo strumento utilizzato è stato lo Use Case Diagram, per il quale è necessario individuare:

 Il Sistema, vengono definiti i confini all’interno del quale opera la soluzione informativa; Funzioni - caratteristiche

Sistema APS

Funzioni - caratteristiche Sistema MES

Nome Descrizione Nome Descrizione

Demand Planning Strumento di analisi ed

elaborazione domanda Coordinamento “monte - valle” Trasferimento all’interno dei piani definiti dai sistemi ERP/APS

MPS/inventory optimization Strumento di analisi ed

elaborazione domanda Coordinamento “valle - monte” Allineamento dei sistemi informativi con i dati degli avanzamenti

MRP Strumenti di

nettificazione Documentazione per gli operatori

ATP e CPT Strumenti di

nettificazione

Capacity Planning Strumento di datazione Dispatching real-time Display in reparto che presentano la lista dei job ordinati secondo i piani rilasciati.

Capacity Scheduling Strumento di datazione Raccolta dei dati dal campo (shop-floor) Control area Estendibilità delle anagrafiche ERP e parametrizzazione Flessibilità ed adattabilità ai vari contesti produttivi Alerting se presente

scostamenti Control area Ambiente di scenari

simulativi

Interfacciabile con i reparti produttivi

6

 Gli Attori, chi o cosa interagisce col sistema (persone o altri sistemi): Responsabile della pianificazione della produzione, responsabile produzione, operatore shop-floor, responsabile vendite, ERP.

 I Casi d’uso, una sequenza di operazioni che il sistema esegue interagendo con gli attori:

a. Richiedi Prog. produzione g. Simula il Paino m. Visualizza Piano Giacenze b. Genera il Piano Fasi di Prod. h. Conferma il Piano n. Controllo conformità Prog. c. Genera il legame OdP - OdV i. Allinea Dati ERP o. Inserire dati avanzamenti d. Genera legame OdP SL - PF j. Genera il Piano Carico risorse p. Controllo Avanzamenti e. Visualizza il Piano delle Fasi k. Visualizza Piano di Carico q. Visualizza alert (da “n” e “p”) f. Modifica il Piano l. Genera il P. disp. Giacenze r. Carica Dati ERP

Prima di realizzare lo Use Case Diagram (Figura 3) è stata fatta una verifica sui casi d’uso tramite una matrice di tracciabilità per verificare che i desiderata siano stati coperti interamente dai casi d’uso. Una volta verificato questo, tramite il diagramma dei casi d’uso sono stati

rappresentati i legami tra attori e casi d’uso, e i legami di dipendenza tra i casi d’uso appartenenti al sistema, quali:

 Legami di inclusione: l’inclusione avviene in ogni istanza e non è opzionale  Legame di estensione: esprime un comportamento supplementare, opzionale.

Non è stato ritenuto necessario l’uso di legami di generalizzazione al fine della rappresentazione. Per ogni caso d’uso ritenuto rilevante è stata definita una specifica dei casi d’uso, all’interno della quale viene descritta una sequenza di operazioni, per ognuna delle quali è specificato come è coinvolto l’Utente e il Sistema.

7

4. Analisi delle Funzioni

In questa fase di analisi si passa dai requisiti funzionali (il “cosa”) alla definizione delle funzioni da implementare nelle Nuova Soluzione IT e delle rispettive logiche (il “come”). Il processo utilizzato per definire le funzioni da implementare nella Nuova Soluzione IT ha seguito i seguenti passi:

 Riesame dei casi d’uso: al fine di controllare la correttezza e la completezza delle informazioni raccolte nel diagramma dei casi d’uso e nelle rispettive specifiche.

 Individuazione dei dati: il riesame è stato utilizzato anche per individuare, per ogni caso d’uso, sia i dati necessari per svolgere quanto descritto nelle specifiche che i dati che ci si aspetta che vengano generati da ogni caso d’uso.

 Definizione delle Funzioni: dalla descrizione delle attività nelle specifiche, considerando i dati che ogni cosa d’uso deve generare e considerando inoltre le informazioni raccolte nell’analisi del contesto riguardo le funzioni dei sistemi APS presenti sul mercato, sono state definite le funzioni necessarie per ogni caso d’uso

Per le funzioni individuate sono state definite le logiche con le quali, a partire dai dati ricevuti, le funzioni elaborano gli output. La logica delle funzioni è descritta utilizzando un diagramma di flusso “parlante” che verrà poi utilizzato come punto di partenza per un diagramma di flusso “rigoroso” e rappresentativo delle logiche di programmazione in fase di progettazione (activity diagram UML). Lo scopo del diagramma di flusso utilizzato è quello di descrivere la logica con un linguaggio di alto livello, mettendo in evidenza i dati principali che vengono utilizzati e generati nel processo di elaborazione, e i percorsi alternativi che la logica di elaborazione può intraprendere. Utilizzando un diagramma di flusso di questo tipo è stato anche possibile verificare la completezza dei dati considerati in fase di riesame dei casi d’uso.

5. Analisi della Struttura del Sistema

Dopo aver definito le funzioni e la loro logica come richiesto dagli obiettivi, è stata definita una prima struttura dei dati utilizzando per la rappresentazione il Class Diagram, un diagramma UML che mostra la struttura del sistema, cioè il tipo di oggetti che lo compongono e le relative relazioni (statiche). Più precisamente, in questa fase viene definito un Class Diagram di analisi, ovvero una versione meno dettagliata rispetto a quella di progetto (vedi 6.3 Sviluppi Futuri). Il Class Diagram di analisi è stato definito nel seguente modo.

 Individuazione delle Classi: l’individuazione delle classi in una prima fase può essere svolta raccogliendo in categorie i dati individuati nelle precedenti analisi e definendo per ogni

8

categoria una classe. In realtà il raggruppamento dei dati è già disponibile, infatti, andando a prendere i dati contenuti nel ERP proprietario dell’Azienda IT (l’integrazione dei dati era un requisito del progetto), i dati sono già strutturati. Quindi è stato necessario andare a definire le classi per i dati caratteristici della Nuova Soluzione IT che permettono di implementare le funzioni definite in precedenza, e sono:

 Parametri Configurazione Piano  Avanzamenti

 Estensioni Ciclo di Lavoro  Piano Fasi di Produzione  Piano Capacità risorse  Piano disponibilità Giacenze

 Assegnazione degli attributi: la rappresentazione delle classi tramite UML prevede che per ogni classe siano elencati gli attributi che fanno parte della classe. Gli attributi sono, in questa fase di analisi, i dati individuati in precedenza.

 Definizione delle Relazioni tra Classi: per il Class Diagram di analisi sono state definite le relazioni di associazione tra le classi e definite le molteplicità delle relazioni. Le tipologie di relazioni rappresentabili nel diagramma delle classi sono molteplici. In questa fase è stata preferita una rappresentazione più semplice utilizzando solo le relazioni di associazione e di raggruppamento. Le altre tipologie di relazione sono necessarie in fase di progettazione, dove serve un grado di formalizzazione maggiore (vedi 6.3 Sviluppi Futuri).

Figura 4

Il risultato (una parte) è rappresentato in Figura 4. Associato al Class DIagram di analisi è stato realizzato un Sequence Diagram. Quest’ultimo è un diagramma UML di tipo comportamentale che descrive le interazioni tra gli oggetti (istanze delle classi) nel tempo. Il Sequence Diagram è realizzato solitamente in fase di progettazione in funzione del Class Diagram di progetto. In questa fase è stato realizzato un Sequence Diagram per dare un’informazione dinamica sulle interazioni tra le classi, oltre a quella statica del Classi Diagram. Il Sequence Diagram si sviluppa

9

verticalmente in funzione del tempo. In questa fase non si hanno informazioni sulle prestazioni delle elaborazioni, ma utilizzando la stessa scala per operazioni simili può essere fatto un primo confronto tra la complessità di scenari diversi. Tramite il Sequence Diagram di analisi è possibile rappresentare le interazioni e i momenti in cui le classi interagiscono, per questo motivo anche se definito in fase di analisi è un’informazione di supporto per la definizione delle operazioni delle classi (vedi 6.3 Sviluppi Futuri)

6. Conclusioni

6.1 Supporto della Nuova Soluzione IT al Processo di Pianificazione

Riprendendo il processo di pianificazione dell’Azienda Caso Studio descritto nell’analisi del contesto, sono state posizionate le funzioni nel processo di pianificazione per evidenziare in quale fase della pianificazione possono essere utilizzate le funzioni definite in fase di analisi. Gli aspetti rilevanti che emergono sono:

 Molte funzioni si concentrano nella fase di scheduling: le funzioni interessate permettono di prendere decisioni fattibili in merito al sequenziamento delle fasi di produzione fattibili.  La funzione Planning KPI Simulation fa da legame tra la pianificazione di medio e breve periodo: la funzione non permette una generazione automatica degli ordini di produzione, ma di mettere a disposizione dell’utente tutte le informazioni utili per prendere decisioni a riguardo, dando all’utente la possibilità di definire uno o più ordini fittizi e di valutarne l’impatto sugli ordini di produzione confermati in termini di tempi, capacità produttiva e disponibilità materiali.

6.2 Nuovo Approccio alla Pianificazione

La possibilità di avere tutte le informazioni necessarie, anche in fase di pianificazione di medio periodo, permette di superare la logica tradizionale di pianificazione di closed-loop MRP (pianificazione gerarchica) e di passare alla logica Concurrent Planning, grazie all’integrazione di tre aree informative: strumenti di analisi ed elaborazione della domanda, strumenti di nettificazione (bilanciamento bisogni-disponibilità) e strumenti di datazione. Questo è possibile tramite sistemi APS più avanzati, ovvero che supportano l’intero processo di pianificazione. La Nuova Soluzione IT, coerentemente con quanto definito nel project scope, si concentra sulla pianificazione di breve e in parte di medio periodo, quindi propone un approccio al Concurrent Planning limitato rispetto al caso teorico. La limitazione sta nel fatto che si debba utilizzare la domanda elaborata da un altro sistema, il cui risultato è comunque contenuto nel ERP, e inserire il dato all’interno della Nuova Soluzione IT definendo degli ordini di produzione che ricalcano

10

le caratteristiche della domanda, tramite la funzione di simulazione. L’analisi del nuovo approccio di pianificazione ha permesso di descrivere uno scenario in cui la logica di Concurrent Planning è applicata sfruttando le funzioni della nuova soluzione informativa. A questo si può aggiungere un ulteriore cambio della logica di pianificazione, detto plan-while-executing, che guarda la possibilità di prendere decisione in merito alla pianificazione (modifiche) in funzione dei dati di ritorno sugli avanzamenti di produzione.

6.3 Sviluppi Futuri

Dopo la fase di analisi seguirà la progettazione e lo sviluppo della Nuova Soluzione IT. Gli output prodotti in fase di analisi risultano particolarmente importanti per l’attività di progettazione rivolta alla definizione della struttura dei dati, la quale è formalizzata tramite un Class Diagram di Progetto. Quest’ultimo si differenzia da quello di analisi per un grado di formalizzazione più elevato dovuto anche alle scelte tecniche di carattere infrastrutturale fatte in questa fase. Il processo che permette di definire un Class Diagram di progetto è un processo iterativo che prevede la definizione di:

 Nome della Classe: si basa sulle classi del Class Diagram di analisi, devono essere aggiunte le classi di servizio, ovvero classi infrastrutturali che dipendono dall’ambiente esecutivo.  Attributi: sono i dati che descrivono le classi, vengono ripresi quelli definiti in fase di analisi

dettagliando il tipo di attributo e il tipo di visibilità dell’attributo tra le classi.

 Operazioni: sono funzioni che possono essere applicate all’oggetto (istanza di una classe), tutti gli oggetti di una classe condividono le stesse operazioni. Sono definite sfruttando le informazioni del Sequence Diagram di analisi (poi aggiornato in fase di progettazione di pari passo con quello delle classi). Activity e Statechart Diagram (formalizzazione dei diagrammi di flusso di analisi), insieme ai casi d’uso, risultano importanti anche per definire i metodi, i quali descrivono l’implementazione delle operazioni tramite algoritmi. Gli algoritmi possono essere rappresentati tramite Activity Diagram.

 Relazioni tra classi: definite partendo da quelle descritte nel Class Diagram di analisi, ma con un livello di dettaglio maggiore.

Un diagramma delle Classi ben strutturato può essere tradotto in un linguaggio di programmazione seguendo determinate regole in fase di sviluppo. Con un set limitato di dati verrà realizzata una demo per svolgere dei test case definiti sulla base dei casi d’uso.