Sei sulla pagina 1di 19

KEL156

MARK JEFFERY

A&D High Tech (A):


Gestione di progetti di successo

Nei dodici anni trascorsi come responsabile di progetti tecnologici presso A&D High Tech,
Chris Johnson ha maturato una solida esperienza nella realizzazione dei progetti nei tempi e nei
costi previsti. Le sue tecniche di pianificazione, stima e programmazione dei progetti sono
diventate le best practices per l'azienda di prodotti informatici, con sede a St. Louis. Ha appena
guidato un team di progetto che ha rinnovato con successo i sistemi di supply chain in meno di
diciotto mesi. È particolarmente orgoglioso perché molti osservatori avevano dubitato che il
progetto potesse essere completato nei tempi. Come parte delle iniziative strategiche stabilite dal
suo CEO e fondatore Ted Walter, A&D non doveva essere seconda a nessuno nell'utilizzo della
tecnologia per aumentare l'efficienza operativa e ridurre i costi. Il progetto della supply chain ha
quindi ricevuto una notevole attenzione in seno al consiglio di amministrazione così come dai
concorrenti. Più volte a Johnson è stato chiesto di affrontare incarichi difficili, fondamentali per la
crescita e i profitti dell'azienda. È già stato indicato come successore del vicepresidente dell'e-
business, Chuck Gagler, in attesa del suo pensionamento. (Vedere l'Allegato 1 per
l'organigramma di A&D High Tech).

All'inizio di maggio 2003 Johnson riceve un messaggio urgente dal CIO dell'azienda, Matt
Webb. Webb c h i e d e a Johnson di unirsi a lui per una riunione con i dirigenti di A&D
per discutere del progetto di shop online dell'azienda. Johnson si rende conto che fino a quel
momento i vertici dell'azienda hanno praticamente ignorato Internet e il suo potenziale di vendita.
Ma la situazione stava per cambiare. Come ha spiegato Webb, il vicepresidente delle vendite di
A&D, Jeff White, aveva fatto notare all'amministratore delegato Ted Walter che A&D stava
perdendo il suo vantaggio competitivo non vendendo online. Di conseguenza, Walter aveva fatto
del progetto online shop la massima priorità dell'azienda. Walter voleva sapere se il progetto
poteva essere completato in tempo per le festività natalizie, quando il business ciclico di A&D è
tradizionalmente in crescita. L'attuale project manager, Eric Robertson, ha richiesto un congedo
di un mese a causa di un'emergenza familiare, proprio quando stava per iniziare a formulare il
piano del progetto e a prendere decisioni sul personale.

Johnson iniziò subito a pensare al modo migliore per garantire il successo del progetto di
shop online. Era preoccupato per il fatto che il tempo a disposizione per portare a termine questo
nuovo progetto fosse troppo poco. Era già maggio e la stagione delle vacanze si sarebbe
avvicinata presto. Data l'urgenza di Webb e Walter, Johnson sentiva già la pressione di dover
formulare raccomandazioni solide in tempi brevi.

©2006 della Kellogg School of Management, Northwestern University. Questo caso è stato preparato da Derek Yung '03 e Alex
Gershbeyn '03 sotto la supervisione del professor Mark Jeffery. I casi vengono sviluppati esclusivamente come base per la discussione
in classe. Alcuni fatti all'interno del caso sono stati modificati per motivi di riservatezza. I casi non sono intesi come avalli, fonti di
dati primari o illustrazioni di una gestione efficace o inefficace. Per ordinare copie o richiedere l'autorizzazione a riprodurre i
materiali, chiamare il numero 800- 545-7685 (o 617-783-7600 al di fuori degli Stati Uniti o del Canada) o inviare un'e-mail a
custserv@hbsp.harvard.edu. Nessuna parte di questa pubblicazione può essere riprodotta, memorizzata in un sistema di recupero,
utilizzata in un foglio elettronico o trasmessa in qualsiasi forma o con qualsiasi mezzo, elettronico, meccanico, di fotocopiatura,
registrazione o altro, senza l'autorizzazione della Kellogg School of Management.

KELLOG SCHOOL OF MANAGEMENT


1
Questo documento è autorizzato solo per l'uso nel corso di Strategia, Economia e Gestione del Progetto MAGISTRETTI presso il MIP Politecnico di Milano da Mar 2022 a
Sep
KEL156
A&D HIGH TECH (A)

Storia dell'azienda
A&D High Tech vende prodotti informatici, accessori e servizi a consumatori e piccole
imprese. L'azienda ha le sue radici a Lincoln, Nebraska, dove Ted Walter ha aperto il primo
negozio nel 1988. I prodotti su ordinazione di A&D erano molto innovativi all'epoca e sono stati i
primi a essere introdotti nel settore dei personal computer. Walter ha enfatizzato il servizio clienti
amichevole, un valore profondamente radicato nella cultura del Midwest, dove Walter ha vissuto
per tutta la vita. I ricavi di A&D sono cresciuti costantemente per dieci anni e si sono avvicinati ai
400 milioni di dollari nell'anno fiscale 2000. L'azienda era principalmente un'azienda regionale,
con oltre il 90% delle vendite provenienti da clienti degli Stati del Midwest. Tuttavia, Walter
sta strategicamente cercando di aumentare la distribuzione a livello nazionale.

Le vendite di A&D avvengono prevalentemente attraverso i punti vendita al dettaglio nei


centri commerciali del Midwest e attraverso gli ordini telefonici gestiti dal call center di
cinquanta persone a Lincoln. Prima del 1999, gli ordini di vendita al call center venivano scritti su
carta e poi passati agli impiegati addetti all'inserimento degli ordini. Questo comportava tempi più
lunghi per l'inserimento degli ordini, ritardi nelle spedizioni e una scarsa precisione. Di
conseguenza, gli addetti alle vendite dovevano spesso contattare i clienti per correggere gli errori
o per suggerire opzioni diverse a causa della carenza di scorte. In media, il 30% degli ordini
richiedeva la chiamata del cliente, rispetto a solo il 5% del principale concorrente di A&D.

Nel 1999 A&D ha implementato il suo primo sistema di pianificazione delle risorse aziendali
(ERP), utilizzando il software di J. D. Edwards. A&D ha scelto di utilizzare questo software
perché poteva essere personalizzato per gestire le migliaia di pezzi che A&D utilizzava per la
produzione. La personalizzazione ha richiesto l'intervento di numerosi consulenti esterni per la
progettazione e la realizzazione del sistema e, poiché questi ultimi hanno lasciato l'azienda subito
dopo l'implementazione del sistema, si temeva che potesse essere difficile da mantenere. Tuttavia,
il progetto è stato considerato un successo: dopo l'entrata in funzione dell'ERP, i richiami dei
clienti si sono ridotti a meno dell'1% degli ordini.

Nel 2001, visto il successo dell'implementazione dell'ERP, A&D ha deciso di investire


ulteriormente per migliorare i propri sistemi di gestione della supply chain, del processo di
pagamento, della gestione delle relazioni con i clienti (CRM) e della gestione degli ordini. È stata
avviata una serie di iniziative tecnologiche. A&D ha riscontrato benefici immediati in termini di
riduzione dei costi e un significativo ritorno sull'investimento nei progetti di supply chain e data
warehousing.

Caso aziendale
Nel 2002, di fronte a una concorrenza agguerrita e a margini in calo, A&D ha deciso di
esplorare nuovi segmenti di mercato per crescere. In particolare, si è concentrata sulle vendite via
Internet. Storicamente, A&D era stata restia ad adottare Internet come canale di vendita perché
non sembrava giocare a favore dei punti di forza delle vendite dell'azienda, ovvero la cordialità e
il servizio clienti. Tuttavia, poiché i prodotti di A&D si stavano avvicinando allo status di prodotti
di base, il costo del prodotto era in gran parte il fattore determinante per un cliente. Inoltre, i
concorrenti erano riusciti ad aumentare i loro ricavi e ad ottenere risparmi sulle spese generali,
amministrative e di vendita (SG&A) per ordine dopo aver iniziato a vendere tramite Internet.

2 KELLOG SCHOOL OF MANAGEMENT


Questo documento è autorizzato solo per l'uso nel corso di Strategia, Economia e Gestione del Progetto MAGISTRETTI presso il MIP Politecnico di Milano da Mar 2022 a
Sep
KEL156
A&D HIGH TECH (A)

Così, all'inizio del 2002, Ted Walter e il vicepresidente delle vendite Jeff White diedero il via
libera al CIO Webb per avviare il progetto di creazione di uno shop online.

Una delle prime decisioni che Webb ha dovuto prendere è stata "costruire o comprare". Uno
shop online sviluppato su misura avrebbe permesso ad A&D di creare esattamente ciò di cui
aveva bisogno, mentre un'opzione commerciale avrebbe potuto non soddisfare tutti i requisiti. Ad
esempio, il software commerciale (COTS) potrebbe non avere i formati, i processi di input, le
capacità di reporting e altri elementi necessari per far funzionare il programma in modo ottimale
per A&D. Inoltre, l'acquisto di un prodotto off the shelf potrebbe costringere A&D ad acquistare
funzionalità di cui non ha bisogno e che non utilizzerebbe.

D'altra parte, Webb si rendeva conto che un'applicazione commerciale poteva potenzialmente
costare molto meno di un'applicazione personalizzata. Tuttavia, non era sempre così, soprattutto
nei casi in cui l'applicazione commerciale richiedeva più del 10% di modifiche personalizzate per
soddisfare tutti i requisiti.

Webb sapeva che le domande chiave nella decisione di costruire o comprare erano:

• Erano disponibili risorse interne per la gestione del progetto, lo sviluppo del software, il
supporto hardware e la manutenzione a lungo termine?
• Quanto budget era disponibile per il progetto?
• Quanto erano unici i processi che la nuova applicazione avrebbe automatizzato?
• L'azienda pagherebbe per funzionalità software commerciali di cui non ha bisogno e che
non utilizzerebbe?

Nella sua analisi, Webb ha elencato alcuni fattori chiave che hanno portato alla decisione di
"costruire":

• I rischi e i costi "nascosti" dell'acquisto di software sono aumentati con l'aumentare della
necessità di personalizzare un pacchetto.
• La tecnologia dell'informazione (IT) potrebbe essere utilizzata come arma strategica e
punto di differenziazione, invece di cercare di tenere il passo.
• I potenziali vantaggi di un sistema integrato ma flessibile in un software personalizzato
(rispetto alla semplice integrazione di più fornitori) potrebbero essere significativi.
• Un sistema personalizzato potrebbe offrire un vantaggio competitivo.
• Gli elementi del pacchetto off the shelf soddisfacevano solo il 60 percento dei requisiti
funzionali di A&D.
• Alcuni fornitori di qualità e affermati si sono impegnati sul mercato, ma nessun
singolofornitore era un chiaro leader di mercato.

Dopo aver deliberato per un mese con i suoi top manager, Webb si è deciso per l'opzione
"costruire".

Storia del progetto


Webb ha creato un team cross-funzionale di sei persone per pianificare il progetto in base alla
sua decisione di "costruire" (vedi Allegato 1). Guidati da Eric Robertson, un giovane ma brillante
project manager IT, i componenti della pianificazione del team comprendevano:

KELLOG SCHOOL OF MANAGEMENT


3
Questo documento è autorizzato solo per l'uso nel corso di Strategia, Economia e Gestione del Progetto MAGISTRETTI presso il MIP Politecnico di Milano da Mar 2022 a
Sep
KEL156
A&D HIGH TECH (A)

• Definire i requisiti aziendali


• Definire i flussi di processo
• Creare i requisiti dell'architettura tecnica
• Costruire un semplice prototipo del sistema
• Creare la struttura di ripartizione del lavoro (WBS) per il progetto.
• Stimare l'impegno per ciascuno dei compiti della WBS.
• Definire le risorse disponibili per il progetto e assegnare le risorse ai compiti del progetto.
• Creare un programma con le dipendenze dei compiti e la corretta allocazione delle risorse.

Dopo quattro settimane, il team ha presentato i risultati al comitato direttivo. Di seguito è


riportato un riepilogo dei risultati di ciascuna attività di pianificazione.

REQUISITI AZIENDALI

L'ambito e i requisiti aziendali del shop online comprendevano nuovi ordini, ordini
aggiuntivi, modifiche dell'ordine, stato dell'ordine e acquisizione di contatti con le seguenti
funzionalità:

• Configurazione e prezzi
• Data di consegna basata sui tempi di consegna standard
• Elaborazione dei pagamenti in tempo reale
• Convalida al 100% dei dati richiesti
• Raccolta di dati prospettici sui clienti
• Integrazione con il back-end (ERP) per la produzione e la gestione degli ordini

L'alta dirigenza è stata irremovibile nel richiedere che il sistema incorporasse questo insieme
di funzionalità minime, poiché i clienti devono avere la stessa esperienza in tutti i canali di
vendita. Come ha detto Jeff White:
Una volta che un ordine è stato fatto e arriva a [J. D.] Edwards, non vedo perché
dobbiamo distinguere se il cliente ha fatto acquisti nei nostri negozi o se ha fatto
l'ordine al telefono o su Internet. Dovremmo servirli con la stessa cura e qualità che ci
si aspetta da A&D".

FLUSSO DI PROCESSO

L'introduzione delle vendite via Internet avrebbe avuto un impatto minimo sull'attuale
processo di A&D, in quanto sarebbe servita semplicemente come nuova facciata alle attività
esistenti. Infatti, tutte le attività esistenti rimarrano invariate. Le nuove attività di supporto alle
vendite via Internet, come la gestione delle eccezioni dovute a errori di sistema, sarebbero però
aggiunte alle procedure di supporto informatico.

ARCHITETTURA TECNICA

Poiché A&D commercializzava una gamma di prodotti con sistema operativo Windows 2000,
A&D aveva standardizzato tutte le applicazioni personalizzate per l'esecuzione su questa
piattaforma. L'architettura del shop online era a N livelli per una maggiore flessibilità e
scalabilità futura (vedi Allegato 2).

Il primo livello era quello del server Web. Il server Web era Microsoft Internet Information
Server (IIS). Gli script lato server dovevano essere codificati in MS Application Server Pages
(ASP). Il secondo livello era il server delle applicazioni. Il server delle applicazioni era Microsoft
4 KELLOG SCHOOL OF MANAGEMENT
Questo documento è autorizzato solo per l'uso nel corso di Strategia, Economia e Gestione del Progetto MAGISTRETTI presso il MIP Politecnico di Milano da Mar 2022 a
Sep
KEL156
A&D HIGH TECH (A)

Transaction Server (MTS). I componenti dell'applicazione avrebbero sfruttato Microsoft Site


Server e i componenti di Microsoft Site Server Commerce Edition.

I database per supportare l'applicazione dovevano essere eseguiti su Microsoft SQL Server. Il
livello di comunicazione era costituito dal middleware Microsoft Messaging Queue (MSMQ).
Attraverso MSMQ, l'applicazione avrebbe avuto accesso a J. D. Edwards. Esistevano altre
applicazioni e database di back-end, ma non sarebbero stati interfacciati dal shop online. Tutte le
licenze software erano già presenti in azienda, quindi Robertson non prevedeva di dover sostenere
alcuna spesa per l'acquisto di software.

INFRASTRUTTURA FISICA

L'infrastruttura fisica di A&D è stata pianificata in modo da essere abbastanza tipica per
un'azienda che svolge attività commerciali su Internet. Per garantire la sicurezza, sono stati
installati due firewall con una zona demilitarizzata (DMZ) nel mezzo (vedi Allegato 3). Nella
DMZ si trovavano i server accessibili da Internet e dai partner di A&D. Dietro il secondo firewall
si trovava la rete interna di A&D, o intranet. I server dietro questo secondo firewall erano
accessibili solo nella intranet. Il team di Robertson ha stimato che per il progetto sarebbero state
necessarie dodici workstation Windows 2000 (a 3.000 dollari l'una) e cinque server Windows
2000 (a 12.500 dollari l'uno).

PROTOTIPO

Il team di Robertson ha realizzato un prototipo, costituito da pagine HTML statiche, per


dimostrare l'interfaccia utente e il flusso generale dell'applicazione. L'Allegato 4 mostra una
stampa della pagina di conferma dell'ordine. Il prototipo è stato approvato dai vicepresidenti delle
vendite e del marketing e servirà come base per l'aspetto e la funzionalità dell'applicazione vera e
propria.

WBS DEL PROGETTO

Il team di Robertson ha creato una WBS completa che dettagliava tutte le attività da svolgere
per il progetto al 1 maggio 2003. Per la WBS completa si veda l'Allegato 5.

STIME DEI COMPITI

Le stime sono state create per ogni attività come parte dello sforzo di pianificazione. Il team
di Robertson aveva una certa esperienza nella stima dei progetti IT; quindi, era abbastanza sicuro
che la stima totale del progetto si sarebbe avvicinata ai dati reali. L'elenco delle stime per
ciascuna attività è riportato nell'Allegato 6.

RISORSE DEL PROGETTO

Tutte le risorse per il progetto erano state identificate, tranne gli sviluppatori di software. Per
gli sviluppatori interni di A&D, tradizionalmente si utilizzava una tariffa forfettaria di 75
dollari/ora a scopo di stima. Ma poiché non c'erano sviluppatori disponibili internamente,
Robertson aveva sollecitato un contratto di appalto, con l’azienda Ginevra, per occupare queste
posizioni. Per gli appaltatori, le tariffe variavano a seconda del livello di competenza e del loro
valore di mercato. Inoltre, le tariffe per gli straordinari degli appaltatori erano diverse da quelle
standard di A&D (per straordinari si intendevano più di otto ore di lavoro al giorno).

A maggio, Ginevra stava ancora identificando le risorse effettivamente necessarie, ma aveva


fornito le tariffe delle risorse in modo che Robertson potesse preparare le stime. Si veda
l'Allegato 7 per un elenco delle risorse e delle relative tariffe. Il team di Robertson ha anche
esaminato i compiti e li ha assegnati di conseguenza. Per l'assegnazione delle risorse si veda
l'Allegato 8.
KELLOG SCHOOL OF MANAGEMENT
5
Questo documento è autorizzato solo per l'uso nel corso di Strategia, Economia e Gestione del Progetto MAGISTRETTI presso il MIP Politecnico di Milano da Mar 2022 a
Sep
KEL156
A&D HIGH TECH (A)

PROGRAMMAZIONE DEL PROGETTO

Come fase finale della preparazione del piano di progetto, Robertson ha programmato tutte le
attività aggiungendo le dipendenze (o predecessori) e calcolando il ritardo di livellamento
necessario per allocare correttamente tutte le risorse. Per la pianificazione si veda l'Allegato 9.1

Riunione di revisione
Quando Johnson entrò nella sala conferenze quindici minuti prima dell'inizio della riunione
con i dirigenti di A&D per discutere del progetto del shop online, trovò Webb e Robertson già
presenti. Mentre gli altri partecipanti entravano nella stanza, Robertson stava esaminando una pila
di documenti, dandone una serie a ciascuno di loro. Jeff White, il vicepresidente delle vendite, e
Chuck Gagler, il vicepresidente dell’e-commerce, arrivarono proprio mentre Webb era pronto a
iniziare la riunione.

Webb illustrò lo scopo dell'incontro, che era quello di facilitare l'efficace transizione tra
Robertson e Johnson e di aggiornare i dirigenti sullo stato del progetto. Mentre Robertson
illustrava i dettagli del lavoro svolto dal suo team, Johnson cominciò a sentirsi più a suo agio. Ha
riconosciuto che Robertson aveva fatto bene a raccogliere tutti i dati rilevanti per creare un buon
piano di progetto. Nonostante la sfida di superare rapidamente la curva di apprendimento di un
nuovo progetto, Johnson si sentiva più tranquillo di poter presentare una raccomandazione
dettagliata con fatti concreti e potenziali problemi.

Al termine della riunione, Webb prese Johnson da parte e gli disse: "So che forse ti sto
chiedendo molto, ma ho davvero bisogno che tu metta a punto il piano entro la prossima
settimana. Walter vuole sapere se riusciamo a concludere l'operazione entro Natale".

1 I predecessori sono stati identificati utilizzando un Task ID. Questo è diverso dall'ID della WBS.

6 KELLOG SCHOOL OF MANAGEMENT


Questo documento è autorizzato solo per l'uso nel corso di Strategia, Economia e Gestione del Progetto MAGISTRETTI presso il MIP Politecnico di Milano da Mar 2022 a
Sep
KEL156
A&D HIGH TECH (A)

Allegato 1: Organigramma

Amministratore
delegato e fondatore
Ted Walter

Vice presidente Sales CIO


Jeff White Matt Webb

Vice presidente
ecommerce
Chuck Gagler

Responsabile vendite Project Manager Project Manager


Tod Fredson Chris Johnson Eric Robertson

Responsabile Test Responsabile Responsabile Responsabile


Kara Siposki Funzionale Sviluppo infrastrutture
Ryan Neff Marc Sanders Rick Burke

Functional Analyst
Tester Stacy Lyle DBA
Sviluppatore 1
Todd Eliason Sanjay Vohra
TBD

Sviluppatore 2
TBD

Sviluppatore 3
TBD

SCUOLA DI MANAGEMENT KELLOGG 7


Questo documento è autorizzato solo per l'uso nel corso di Strategia, Economia e Gestione del ProgettoMAGISTRETTI3 presso il MIP Politecnico di Milano da Mar 2022 a Sep
KEL156
A&D HIGH TECH (A)

Allegato 2: Architettura tecnica

Architettura Tecnica

IIS .

Componenti MTS ( MS Site Server


Commerce Edition)

Middleware (MS MQ)


IIS Supply chain (l2)

Financials (Peoplesoft)

HR (Peoplesoft)

Data warehousing
Componenti MTS (personalizzati)
Impose (Vertex)
IIS

DB dell’Applicazione
(MS SQUL Server)

8 SCUOLA DI MANAGEMENT KELLOGG

Questo documento è autorizzato solo per l'uso nel corso di Strategia, Economia e Gestione del ProgettoMAGISTRETTI3 presso il MIP Politecnico di Milano da Mar 2022 a Sep
KEL156
A&D HIGH TECH (A)

Allegato 3: Infrastruttura fisica I2Server Peoplesoft servers

Partner
esterni

DMZ
Firewall Firewall

Internet Intranet
J. D. Edwards

Server del magazzino

Server Vertex

Bilanciamento del carico webAltri server

Farm del server applicativo del shop online


Farm di server web

SCUOLA DI MANAGEMENT KELLOGG 9


Questo documento è autorizzato solo per l'uso nel corso di Strategia, Economia e Gestione del ProgettoMAGISTRETTI3 presso il MIP Politecnico di Milano da Mar 2022 a Sep
KEL156
A&D HIGH TECH (A)

Reperto 4: Prototipo

10 SCUOLA DI MANAGEMENT KELLOGG

Questo documento è autorizzato solo per l'uso nel corso di Strategia, Economia e Gestione del ProgettoMAGISTRETTI3 presso il MIP Politecnico di Milano da
Mar 2022 a Sep
KEL156
A&D HIGH TECH (A)

Allegato 5: Struttura di ripartizione del lavoro – Work Breakdown Structure (WBS)

WBS ID Nome Task

1 Progetto complessivo

1.1 Project management

1.1.1 Gestione del progetto

1.2 Requisiti di sistema

1.2.1 Raccogliere i requisiti business

1.2.2 Progettare i flussi dei processi aziendali

1.2.3 Finalizzare i requisiti tecnici

1.2.4 Creare requisiti operativi

1.2.5 Identificare le esigenze dell'infrastruttura tecnica

1.3 Requisiti del software

1.3.1 Creare i requisiti funzionali

1.3.1.1 Acquisizione del profilo del cliente

1.3.1.2 Visualizza e cerca nel catalogo dei prodotti

1.3.1.3 Aggiornamento e calcolo del carrello

1.3.1.4 Accettazione dei pagamenti

1.3.1.5 Invia l'ordine

1.3.1.6 Controllare la cronologia e lo stato degli ordini

1.3.2 Creare i requisiti dei dati

1.3.3 Creare i requisiti dell'interfaccia ERP

1.3.4 Creare i requisiti dell'interfaccia utente

1.4 Design dettagliato

1.4.1 Progettazione di pagine e componenti del profilo del cliente

1.4.2 Progettazione Visualizzazione e ricerca di pagine e componenti del catalogo prodotti

1.4.3 Progettazione Aggiornamento e calcolo del carrello

1.4.4 Progettazione di pagine e componenti per i pagamenti

1.4.5 Progettazione di pagine e componenti per l'invio di ordini

1.4.6 Design Controllare la cronologia degli ordini e le pagine di stato degli ordini

1.4.7 Progettazione del modello di dati logico e fisico

1.4.8 Progettazione dell'interfaccia ERP

1.5 Pianificazione dei test

1.5.1 Raccogliere i requisiti per i test

1.5.2 Creare il piano di test del sistema e i casi di test

1.5.3 Scrivere gli script di test del sistema

1.6 Infrastruttura tecnica

1.6.1 Creare un ambiente di sviluppo

1.6.2 Creare l'ambiente di test

1.6.3 Supporto all'ambiente di sviluppo

1.6.4 Supporto all'ambiente di test e all'implementazione

SCUOLA DI MANAGEMENT KELLOGG 11


Questo documento è autorizzato solo per l'uso nel corso di Strategia, Economia e Gestione del ProgettoMAGISTRETTI3 presso il MIP Politecnico di Milano da
Mar 2022 a Sep
KEL156
A&D HIGH TECH (A)

1.6.5 Supporto database

1.7 Sviluppo e test unità

1.7.1 Creare pagine e componenti per il profilo del cliente

1.7.2 Costruire le componenti di visualizzazione e di cerca prodotto nelle pagine del catalogo

1.7.3 Creazione di un carrello per l'aggiornamento e il calcolo

1.7.4 Creare pagine e componenti per i pagamenti

1.7.5 Creare pagine e componenti per l'invio di ordini

1.7.6 Creare pagine e componenti per il controllo della cronologia e dello stato dell'ordine

1.7.7 Costruire un modello di dati logico e fisico

1.7.8 Creare l'interfaccia ERP

1.7.9 Supporto allo sviluppo e all'assemblaggio Test

1.8 Test
1.8.1 Esecuzione di test di assemblaggio

1.8.1.1 Eseguire i test della fase 1

1.8.1.2 Eseguire i test di fase 2


1.8.2 Eseguire il test del sistema

1.8.3 Esecuzione di test di convalida

1.9 Rilascio
1.9.1 Implementare il sistema

1.9.2 Distribuzione in produzione

1.9.3 Conclusione del progetto

12 SCUOLA DI MANAGEMENT KELLOGG

Questo documento è autorizzato solo per l'uso nel corso di Strategia, Economia e Gestione del ProgettoMAGISTRETTI3 presso il MIP Politecnico di Milano da
Mar 2022 a Sep
KEL156
A&D HIGH TECH (A)

Allegato 6: Stime dei compiti


WBS ID Nome Task Stima del lavoro (giorni)

1 Progetto complessivo
1.1 Project management
1.1.1 Gestione del progetto 127
1.2 Requisiti di sistema
1.2.1 Raccogliere i requisiti business 8
1.2.2 Progettare i flussi dei processi aziendali 4
1.2.3 Finalizzare i requisiti tecnici 6
1.2.4 Creare requisiti operativi 15
1.2.5 Identificare le esigenze dell'infrastruttura tecnica 2
1.3 Requisiti del software
1.3.1 Creare i requisiti funzionali
1.3.1.1 Acquisizione del profilo del cliente 4
1.3.1.2 Visualizza e cerca nel catalogo dei prodotti 6
1.3.1.3 Aggiornamento e calcolo del carrello 3
1.3.1.4 Accettazione dei pagamenti 6
1.3.1.5 Invia l'ordine 4
1.3.1.6 Controllare la cronologia e lo stato degli ordini 3
1.3.2 Creare i requisiti dei dati 3
1.3.3 Creare i requisiti dell'interfaccia ERP 7
1.3.4 Creare i requisiti dell'interfaccia utente 4
1.4 Design dettagliato
1.4.1 Progettazione di pagine e componenti del profilo del cliente 13.5
Progettazione Visualizzazione e ricerca di pagine e componenti del 13.5
1.4.2
catalogo prodotti
1.4.3 Progettazione Aggiornamento e calcolo del carrello
6
1.4.4 Progettazione di pagine e componenti per i pagamenti 6
1.4.5 Progettazione di pagine e componenti per l'invio di ordini 16
Design Controllare la cronologia degli ordini e le pagine di stato degli 4
1.4.6
ordini
1.4.7 Progettazione del modello di dati logico e fisico
18
1.4.8 Progettazione dell'interfaccia ERP 20
1.5 Pianificazione dei test
1.5.1 Raccogliere i requisiti per i test 14
1.5.2 Creare il piano di test del sistema e i casi di test 20
1.5.3 Scrivere gli script di test del sistema 22
1.6 Infrastruttura tecnica
1.6.1 Creare un ambiente di sviluppo 20
1.6.2 Creare l'ambiente di test 34.2
1.6.3 Supporto all'ambiente di sviluppo 3.8
1.6.4 Supporto all'ambiente di test e all'implementazione 46
1.6.5 Supporto database 4.6
1.7 Sviluppo e test unità
1.7.1 Creare pagine e componenti per il profilo del cliente 13
Costruire le componenti di visualizzazione e di cerca prodotto nelle 12
1.7.2
pagine del catalogo
1.7.3 Creazione di un carrello per l'aggiornamento e il calcolo
7
1.7.4 Creare pagine e componenti per i pagamenti 6
1.7.5 Creare pagine e componenti per l'invio di ordini 24
Creare pagine e componenti per il controllo della cronologia e dello 6
1.7.6
stato dell'ordine
1.7.7 Costruire un modello di dati logico e fisico
15.5

SCUOLA DI MANAGEMENT KELLOGG 13


Questo documento è autorizzato solo per l'uso nel corso di Strategia, Economia e Gestione del ProgettoMAGISTRETTI3 presso il MIP Politecnico di Milano da
Mar 2022 a Sep
KEL156
A&D HIGH TECH (A)

1.7.8 Creare l'interfaccia ERP 18


1.7.9 Supporto allo sviluppo e all'assemblaggio Test 46
1.8 Test
1.8.1 Esecuzione di test di assemblaggio
1.8.1.1 Eseguire i test della fase 1 12
1.8.1.2 Eseguire i test di fase 2 20
1.8.2 Eseguire il test del sistema 160
1.8.3 Esecuzione di test di convalida 80
1.9 Rilascio
1.9.1 Implementare il sistema 80
1.9.2 Distribuzione in produzione 8
1.9.3 Conclusione del progetto 90

Allegato 7: Risorse
Nome della risorsa Tariffa standard Tariffa degli straordinari
Chris Johnson (Responsabile di progetto) $75,00/ora $75,00/ora
Ryan Neff (responsabile funzionale) $75,00/ora $75,00/ora
Stacy Lyle (Analista funzionale) $75,00/ora $75,00/ora
Rick Burke (responsabile dell'infrastruttura) $75,00/ora $75,00/ora

Marc Sanders (responsabile dello sviluppo) $75,00/ora $75,00/ora

Sviluppatore 1 (TBD) $165,00/ora $230,00/ora


Sanjay Vohra (DBA) $75,00/ora $75,00/ora
Kara Siposki (Test Lead) $75,00/ora $75,00/ora
Todd Eliason (Tester) $75,00/ora $75,00/ora

Sviluppatore 2 (TBD) $175,00/ora $250,00/ora

Sviluppatore 3 (TBD) $175,00/ora $250,00/ora

14 SCUOLA DI MANAGEMENT KELLOGG

Questo documento è autorizzato solo per l'uso nel corso di Strategia, Economia e Gestione del ProgettoMAGISTRETTI3 presso il MIP Politecnico di Milano da
Mar 2022 a Sep
Allegato 8: Assegnazione Risorse

WBS ID Nome Task Stima del Nome della risorsa


lavoro
(giorni)
1 Progetto complessivo
1.1 Project management
1.1.1 Gestione del progetto 127 Chris Johnson (Responsabile di progetto)
1.2 Requisiti di sistema
1.2.1 Raccogliere i requisiti business 8 Ryan Neff (responsabile funzionale), Stacy
Lyle(responsabile funzionale).
1.2.2 Progettare i flussi dei processi aziendali 4 Ryan Neff (responsabile funzionale), Stacy
Lyle(responsabile funzionale).
1.2.3 Finalizzare i requisiti tecnici 6 Rick Burke (responsabile
dell'infrastruttura)
1.2.4 Creare requisiti operativi 15 Ryan Neff (responsabile funzionale), Stacy
Lyle (responsabile funzionale), Rick Burke
(responsabile dell'infrastruttura)
1.2.5 Identificare le esigenze dell'infrastruttura tecnica 2 Rick Burke (responsabile
dell'infrastruttura)
1.3 Requisiti del software
1.3.1 Creare i requisiti funzionali
1.3.1.1 Acquisizione del profilo del cliente 4 Ryan Neff (responsabile funzionale)
1.3.1.2 Visualizza e cerca nel catalogo dei prodotti 6 Ryan Neff (responsabile funzionale)
1.3.1.3 Aggiornamento e calcolo del carrello 3 Ryan Neff (responsabile funzionale)
1.3.1.4 Accettazione dei pagamenti 6 Stacy Lyle (Analista funzionale)
1.3.1.5 Invia l'ordine 4 Ryan Neff (Responsabile funzionale)
1.3.1.6 Controllare la cronologia e lo stato degli ordini 3 Ryan Neff (Responsabile funzionale)
1.3.2 Creare i requisiti dei dati 3 Stacy Lyle (Analista funzionale)
1.3.3 Creare i requisiti dell'interfaccia ERP 7 Stacy Lyle (Analista funzionale)
1.3.4 Creare i requisiti dell'interfaccia utente 4 Stacy Lyle (Analista funzionale)
1.4 Design dettagliato
1.4.1 Progettazione di pagine e componenti del profilo del cliente 13.5 Marc Sanders (responsabile dello
sviluppo),Ryan Neff (responsabile
funzionale) [50%]
1.4.2 Progettazione Visualizzazione e ricerca di pagine e 13.5 Sviluppatore 1 (TBD), Ryan
componenti del catalogo prodotti Neff (responsabile
funzionale) [50%]
1.4.3 Progettazione Aggiornamento e calcolo del carrello 6 Sviluppatore 1 (TBD), Ryan Neff
(responsabilefunzionale)
1.4.4 Progettazione di pagine e componenti per i pagamenti 6 Marc Sanders (responsabile dello
sviluppo),Stacy Lyle (analista funzionale)
1.4.5 Progettazione di pagine e componenti per l'invio di ordini 16 Marc Sanders (responsabile dello
sviluppo), Ryan Neff (responsabile
funzionale)
1.4.6 Design Controllare la cronologia degli ordini e le pagine di 4 Marc Sanders (responsabile dello
stato degli ordini sviluppo),Ryan Neff (responsabile
funzionale)
1.4.7 Progettazione del modello di dati logico e fisico 18 Sanjay Vohra (DBA), Stacy Lyle (analista
funzionale)
1.4.8 Progettazione dell'interfaccia ERP 20 Sviluppatore 1 (TBD), Stacy Lyle (analista
funzionale)
1.5 Pianificazione dei test
1.5.1 Raccogliere i requisiti per i test 14 Kara Siposki (Test Lead), Todd Eliason
(Tester)

SCUOLA DI MANAGEMENT KELLOGG 15


Questo documento è autorizzato solo per l'uso nel corso di Strategia, Economia e Gestione del ProgettoMAGISTRETTI3 presso il MIP Politecnico di Milano da
Mar 2022 a Sep
1.5.2 Creare il piano di test del sistema e i casi di test 20 Kara Siposki (Test Lead), Todd Eliason
(Tester)
1.5.3 Scrivere gli script di test del sistema 22 Kara Siposki (Test Lead), Todd Eliason
(Tester)
1.6 Infrastruttura tecnica
1.6.1 Creare un ambiente di sviluppo 20 Rick Burke (responsabile
dell'infrastruttura)
1.6.2 Creare l'ambiente di test 34.2 Rick Burke (Responsabile Infrastruttura)
[90%]
1.6.3 Supporto all'ambiente di sviluppo 3.8 Rick Burke (Responsabile
dell'infrastruttura) [10%]
1.6.4 Supporto all'ambiente di test e all'implementazione 46 Rick Burke (Responsabile infrastruttura)
1.6.5 Supporto database 4.6 Sanjay Vohra (DBA) [10%]
1.7 Sviluppo e test unità
1.7.1 Creare pagine e componenti per il profilo del cliente 13 Sviluppatore 2 (TBD)
1.7.2 Costruire le componenti di visualizzazione e di cerca 12 Sviluppatore 3 (TBD)
prodotto nelle pagine del catalogo
1.7.3 Creazione di un carrello per l'aggiornamento e il calcolo 7 Sviluppatore 3 (TBD)
1.7.4 Creare pagine e componenti per i pagamenti 6 Sviluppatore 2 (TBD)
1.7.5 Creare pagine e componenti per l'invio di ordini 24 Sviluppatore 2 (TBD), Sviluppatore 3 (TBD)
1.7.6 Creare pagine e componenti per il controllo della 6 Marc Sanders (responsabile dello sviluppo)
cronologia e dello stato dell'ordine
1.7.7 Costruire un modello di dati logico e fisico 15.5 Sanjay Vohra (DBA) [50%]
1.7.8 Creare l'interfaccia ERP 18 Sviluppatore 1 (TBD)
1.7.9 Supporto allo sviluppo e all'assemblaggio Test 46 Ryan Neff (responsabile funzionale), Stacy
Lyle(responsabile funzionale).
1.8 Test
1.8.1 Esecuzione di test di assemblaggio
1.8.1.1 Eseguire i test della fase 1 12 Marc Sanders (responsabile dello sviluppo)
1.8.1.2 Eseguire i test di fase 2 20 Marc Sanders (responsabile dello
sviluppo),Sviluppatore 1 (TBD),
Sviluppatore 2 (TBD), Sviluppatore 3 (TBD)
1.8.2 Eseguire il test del sistema 160 Kara Siposki (Test Lead), Todd Eliason
(Tester), Marc Sanders (Development
Lead), Sviluppatore 1 (TBD), Sviluppatore
2 (TBD), Sviluppatore 3 (TBD), Ryan Neff
(Functional Lead),Stacy Lyle (Analista
funzionale)
1.8.3 Esecuzione di test di convalida 80 Kara Siposki (Test Lead), Todd Eliason
(Tester), Marc Sanders (Development
Lead), Sviluppatore 1 (TBD), Sviluppatore
2 (TBD), Sviluppatore 3 (TBD), Ryan Neff
(Functional Lead),Stacy Lyle (Analista
funzionale)
1.9 Rilascio
1.9.1 Implementare il sistema 80 Kara Siposki (Test Lead), Todd Eliason
(Tester), Marc Sanders (Development
Lead), Sviluppatore 1 (TBD), Sviluppatore
2 (TBD), Sviluppatore 3 (TBD), Ryan Neff
(Functional Lead),Stacy Lyle (Analista
funzionale)
1.9.2 Distribuzione in produzione 80 Kara Siposki (Test Lead), Todd Eliason
(Tester), Marc Sanders (Development
Lead), Sviluppatore 1 (TBD), Sviluppatore
2 (TBD), Sviluppatore 3 (TBD), Ryan Neff
(Functional Lead),Stacy Lyle (Analista
funzionale)
1.9.3 Conclusione del progetto 90 Kara Siposki (Test Lead), Todd Eliason
(Tester), Marc Sanders (Development
16 SCUOLA DI MANAGEMENT KELLOGG

Questo documento è autorizzato solo per l'uso nel corso di Strategia, Economia e Gestione del ProgettoMAGISTRETTI3 presso il MIP Politecnico di Milano da
Mar 2022 a Sep
Lead), Developer 1 (TBD), Developer 2
(TBD), Developer 3 (TBD), Ryan Neff
(Functional Lead), Stacy Lyle (Functional
Analyst), Rick Burke (Infrastructure Lead)

Allegato 9: Pianificazione
Stima del
Attività WBS Ritardo nel
Nome dell’attività lavoro Predecessori Nome della risorsa
ID ID livellamento (giorni)
(giorni)
1 1 Progetto complessivo 0

2 1.1 Project management 0

3 1.1.1 Gestione del progetto 127 0 59FF Chris Johnson (Responsabile di progetto)

4 1.2 Requisiti di sistema 0


Raccogliere i requisiti Ryan Neff (responsabile funzionale), Stacy
5 1.2.1 8 0
business Lyle (analista funzionale)
Progettare i flussi dei Ryan Neff (responsabile funzionale), Stacy
6 1.2.2 4 0 5
processi aziendali Lyle (analista funzionale)
7 1.2.3 Finalizzare i requisiti tecnici 6 0 Rick Burke (responsabile dell'infrastruttura)
Ryan Neff (responsabile funzionale), Stacy
8 1.2.4 Creare requisiti operativi 15 0 5, 6 Lyle (analista funzionale), Rick Burke
(responsabile infrastruttura)
Identificare le esigenze
9 1.2.5 2 0 7, 8 Rick Burke (responsabile dell'infrastruttura)
dell'infrastruttura tecnica
10 1.3 Requisiti del software 0

11 1.3.1 Creare i requisiti funzionali 0 5, 6, 8


1.3.1. Acquisizione del profilo del
12 4 0 Ryan Neff (responsabile funzionale)
1 cliente
1.3.1. Visualizza e cerca nel
13 6 5 Ryan Neff (responsabile funzionale)
2 catalogo dei prodotti
1.3.1. Aggiornamento e calcolo
14 3 0 13 Ryan Neff (responsabile funzionale)
3 del carrello
1.3.1. Accettazione dei
15 6 6 Stacy Lyle (Analista funzionale)
4 pagamenti
1.3.1.
16 Invia l'ordine 4 0 12, 13, 14, 15 Ryan Neff (responsabile funzionale)
5
1.3.1. Controllare la cronologia e
17 3 0 16 Ryan Neff (responsabile funzionale)
6 lo stato degli ordini
18 1.3.2 Creare i requisiti dei dati 3 0 12, 13 Stacy Lyle (Analista funzionale)
Creare i requisiti
19 1.3.3 7 0 16SS Stacy Lyle (Analista funzionale)
dell'interfaccia ERP
Creare i requisiti
20 1.3.4 4 0 11SS Stacy Lyle (Analista funzionale)
dell'interfaccia utente
21 1.4 Design dettagliato 0 10
Progettazione di pagine e
Marc Sanders (responsabile dello sviluppo),
22 1.4.1 componenti del profilo del 13.5 0
Ryan Neff (Responsabile funzionale) [50%]
cliente
Progettazione
Visualizzazione e ricerca di Sviluppatore 1 (TBD), Ryan Neff
23 1.4.2 13.5 0
pagine e componenti del (Responsabile funzionale) [50%]
catalogo prodotti
Progettazione
Sviluppatore 1 (TBD), Ryan Neff
24 1.4.3 Aggiornamento e calcolo 6 0 23
(responsabile funzionale)
del carrello
Progettazione di pagine e
Marc Sanders (responsabile dello sviluppo),
25 1.4.4 componenti per i 6 11
Stacy Lyle (Analista funzionale)
pagamenti

SCUOLA DI MANAGEMENT KELLOGG 17


Questo documento è autorizzato solo per l'uso nel corso di Strategia, Economia e Gestione del ProgettoMAGISTRETTI3 presso il MIP Politecnico di Milano da
Mar 2022 a Sep
Progettazione di pagine e
Marc Sanders (responsabile dello sviluppo),
26 1.4.5 componenti per l'invio di 16 0 22, 23, 24, 25
Ryan Neff (Responsabile funzionale)
ordini
Design Controllare la
Marc Sanders (responsabile dello sviluppo),
27 1.4.6 cronologia degli ordini e le 4 0 26
Ryan Neff (Responsabile funzionale)
pagine di stato degli ordini
Progettazione del modello Sanjay Vohra (DBA), Stacy Lyle (analista
28 1.4.7 18 0
di dati logico e fisico funzionale)
Progettazione Sviluppatore 1 (TBD), Stacy Lyle (Analista
29 1.4.8 20 0 22, 23, 24, 25
dell'interfaccia ERP funzionale)
30 1.5 Pianificazione dei test 0
Raccogliere i requisiti per i Kara Siposki (Test Lead), Todd Eliason
31 1.5.1 14 23 11
test (Tester)
Creare il piano di test del Kara Siposki (Test Lead), Todd Eliason
32 1.5.2 20 0 31, 21
sistema e i casi di test (Tester)
Scrivere gli script di test del Kara Siposki (Test Lead), Todd Eliason
33 1.5.3 22 0 32
sistema (Tester)
34 1.6 Infrastruttura tecnica 0
Creare un ambiente di
35 1.6.1 20 0 9 Rick Burke (responsabile dell'infrastruttura)
sviluppo
Rick Burke (Responsabile Infrastrutture)
36 1.6.2 Creare l'ambiente di test 34.2 0 35
[90%]
Supporto all'ambiente di Rick Burke (Responsabile Infrastrutture)
37 1.6.3 3.8 0 35
sviluppo [10%]
Supporto all'ambiente di
38 1.6.4 4,6 0 36 Rick Burke (responsabile dell'infrastruttura)
test e all'implementazione
39 1.6.5 Supporto database 4.6 0 47 Sanjay Vohra (DBA) [10%]

40 1.7 Sviluppo e test unità 0 35


Creare pagine e
41 1.7.1 componenti per il profilo 13 0 22 Sviluppatore 2 (TBD)
del cliente
Costruire le componenti di
visualizzazione e di cerca
42 1.7.2 12 0 23 Sviluppatore 3 (TBD)
prodotto nelle pagine del
catalogo
Creazione di un carrello per
43 1.7.3 7 0 24,22 Sviluppatore 3 (TBD)
l'aggiornamento e il calcolo
Creare pagine e
44 1.7.4 componenti per i 6 14 25 Sviluppatore 2 (TBD)
pagamenti
Creare pagine e
26, 41, 42,43,
45 1.7.5 componenti per l'invio di 24 0 Sviluppatore 2 (TBD), Sviluppatore 3 (TBD)
44
ordini
Creare pagine e
componenti per il controllo
46 1.7.6 6 0 27 Marc Sanders (responsabile dello sviluppo)
della cronologia e dello
stato dell'ordine
Costruire un modello di
47 1.7.7 15.5 0 28 Sanjay Vohra (DBA) [50%]
dati logico e fisico
48 1.7.8 Creare l'interfaccia ERP 18 0 29 Sviluppatore 1 (TBD)
Supporto allo sviluppo e Ryan Neff (responsabile funzionale), Stacy
49 1.7.9 46 0 21
all'assemblaggio Test Lyle ( Analista funzionale).
50 1.8 Test 0

51 1.8.1 Esecuzione di test di assemblaggio 0 31


1.8.1.
52 Eseguire i test della fase 1 12 0 41, 42, 43 Marc Sanders (responsabile dello sviluppo)
1
Marc Sanders (responsabile dello sviluppo),
1.8.1. 44, 45, 46,52,
53 Eseguire i test di fase 2 20 0 sviluppatore 1 (TBD), Sviluppatore 2 (TBD),
2 47, 48
Sviluppatore 3 (TBD)

18 SCUOLA DI MANAGEMENT KELLOGG

Questo documento è autorizzato solo per l'uso nel corso di Strategia, Economia e Gestione del ProgettoMAGISTRETTI3 presso il MIP Politecnico di Milano da
Mar 2022 a Sep
Kara Siposki (Test Lead), Todd Eliason
(Tester), Marc Sanders (Development
Lead), Sviluppatore 1 (TBD), Sviluppatore 2
54 1.8.2 Eseguire il test del sistema 160 0 51, 32, 33
(TBD), Sviluppatore 3 (TBD), Ryan Neff
(Responsabile funzionale), Stacy Lyle
(Analista funzionale)

Kara Siposki (Test Lead), Todd Eliason


(Tester), Marc
Esecuzione di test di
55 1.8.3 80 0 54
convalida Sanders (Development Lead), Sviluppatore
1 (TBD),
Sviluppatore 2 (TBD), Sviluppatore 3 (TBD),
Ryan Neff (Functional Lead), Stacy Lyle
(Analista funzionale)
56 1.9 Rilascio 0 50
Kara Siposki (Test Lead), Todd Eliason
(Tester), Marc Sanders (Development
Lead), Sviluppatore 1 (TBD), Sviluppatore 2
57 1.9.1 Implementare il sistema 80 0
(TBD), Sviluppatore 3 (TBD), Ryan Neff
(Responsabile funzionale), Stacy Lyle
(Analista funzionale)
Kara Siposki (Test Lead), Todd Eliason
(Tester), Marc Sanders (Development
Lead), Sviluppatore 1 (TBD), Sviluppatore 2
58 1.9.2 Distribuzione in produzione 8 0 57
(TBD), Sviluppatore 3 (TBD), Ryan Neff
(Responsabile funzionale), Stacy Lyle
(Analista funzionale)
Kara Siposki (Test Lead), Todd Eliason
(Tester), Marc Sanders (Development
Lead), Sviluppatore 1 (TBD), Sviluppatore 2
1.9.3 Conclusione del progetto (TBD), Sviluppatore 3 (TBD), Ryan Neff
59 90 0 58 (Responsabile funzionale), Stacy Lyle
(Analista funzionale), Rick Burke
(responsabile dell'infrastruttura)

SCUOLA DI MANAGEMENT KELLOGG 19


Questo documento è autorizzato solo per l'uso nel corso di Strategia, Economia e Gestione del ProgettoMAGISTRETTI3 presso il MIP Politecnico di Milano da
Mar 2022 a Sep

Potrebbero piacerti anche