Colleluori Livio Prof. D'Ambrogio Sistemi Software - Introduzione

Colleluori Livio

Prof. D’Ambrogio

Sistemi Software - A.A. 2019/2020

Capitolo 1 - Introduzione

SwEng: Unconsummated Marriage: Software Engineering è la disciplina per la produzione del software secondo i principi dell’ingegneria (progettazione e validazione). È essenziale per fare del software un prodotto industriale. Se manca si incorre in scarsa qualità del prodotto e scarsa competitività (time overrun e cost overrun).

Software Engineering è una disciplina giovane, infatti:

- Per anni i costruttori di hardware hanno visto la produzione di software come attività banale, simile ad USO del calcolatore, che richiede principalmente abilità.

- Per anni l’abilità programmativa, la conoscenza delle ultime novità su linguaggi, interfacce etc è stata considerata sufficiente a fare un ingegnere del software.

- Per anni la software engineering è stata considerata una branca della teoria della programmazione (o informatica teorica).

Cose da far “sposare”:

- Ingegneri conoscano bene la teoria della programmazione. - Informatici teorici conoscano bene i principi dell’ingegneria.

Il Termine Software Engineering (SwEng) è stato coniato oltre 50 anni fa alla Conferenza NATO del 1968 a Garmisch, Germania, per testimoniare l’esigenza che il software fosse inquadrato all’interno di una disciplina ingegneristica.

La conferenza del ‘68 portò a diversi risultati:

- L’attività della programmazione non è né una scienza né una matematica, perché il programmatore non aggiunge conoscenza a conoscenza ma costruisce un PRODOTTO.

- Gli ingegneri devono basare sulla teoria della programmazione i loro principi di progettazione e convalida dei prodotti software.

- I problemi ed i rischi connessi alla produzione ed all’uso del software (bassa qualità, time e cost overrun) sono tipici dei prodotti costruiti da persone NON qualificate o, meglio, educate per altre professioni.

Aspetti tipici dell’Ingegneria del Software:

● ACCIDENTALI del prodotto software (superabili col progresso della tecnologia): ○ Di attitudine; ○ Di manutenzione; ○ Di specifica e progetto; ○ Di teaming;

● ESSENZIALI del prodotto software (NON superabili col progresso dei mezzi e conoscenze): ○ Complessità; ○ Conformità; ○ Cambiabilità; ○ Invisbilità;

● DI COSTO del prodotto software: ○ Costo verso dimensione (size); ○ Costo verso repliche; ○ Costo verso ampiezza di mercatto;

1/102

Ciclo di Vita del Software - 3 Stadi, 6 Fasi: La produzione del software è la somma dello sviluppo e della manutenzione.

Sviluppo SW = Sviluppo + Manutenzione

● Sviluppo (Stadio 1):

1. Requisiti; 2. Specifiche (o analisi dei requisiti). 3. Pianificazione; 4. Progetto (preliminare e dettagliato); 5. Codifica; 6. Integrazione;

● Manutenzione (Stadio 2):

- Copre circa il 60% dei costi del ciclo di vita;

● Dismissione (Stadio 3).

L’effetto delle Modifiche: L’effetto delle modifiche varia secondo la fase in cui vengono introdotte; in fasi avanzate, una modifica può comportare rivolgimenti che richiedono nuove risorse o correzioni importanti al progetto, cioè costi supplementari.

La FASE di TESTING: La fasi di testing non è esplicitamente menzionata tra le 6 fasi, perché non è una fase separata.

Il Testing è un’attività che ha luogo durante l’intero sviluppo, in 2 Modi:

1. Verifica (alla fine di ogni fase) = La fase è stata ben svolta? (are we building the product right?);

2. Validazione (alla fine dello sviluppo) = Il prodotto finale è buono? (are we building the right product?).

Defect Removal Efficiency (DRE): Il DRE fa riferimento alla percentuale di difetti trovati prima del rilascio del prodotto software. Se il team di sviluppo trova 900 difetti prima del rilascio e gli utenti trovano 100 difetti in un intervallo temporale standard a partire dalla data di rilascio (tipicamente 90 GIORNI) allora il valore di DRE è pari al 90%.

DRE = (# Difetti prima del rilascio)/(# Difetti dopo i 90gg dal rilascio) x 100 In base a statistiche del 2016, il DRE MEDIO negli USA è pari al 92% (i valori cambiano in base al modello di ciclo di vita).

Aspetti di Costo:

● Il costo è proporzionale al quadrato della dimensione (size): ○ C = a S2 ○ Fare due prodotti di size S/2 costa meno che farne uno di size S.

● Produrre una replica non costa nulla. ● Vendere un prodotto di size doppio per il mercato:

○ Richiede un prezzo 4 Volte superiore a parità di (ampiezza di) mercato; ○ Richiede un mercato (di ampiezza) 4 volte maggiore a parità di prezzo;

2/102

Definizioni: ● Prodotto Software (o brevemente Software o Sw) = Codice + Documentazione; ● Artefatto = prodotto SW intermedio:

○ Documento requisiti; ○ Documento di specifica; ○ Documento di progetto;

● Codice = Prodotto SW Finale; ● Sistema SW = Insieme organizzato di prodotti SW; ● Cliente = Soggetto che ordina il prodotto SW; ● Sviluppatore = soggetto che lo produce; ● Utente = Soggetto che lo usa; ● SW interno = cliente e sviluppatore coincidono; ● SW a contratto = cliente e sviluppatore sono soggetti differenti;

Aspetti di Affidabilità (SW Reliability): Informalmente è la credibilità del prodotto software. Formalmente è la probabilità che il prodotto software lavori “correttamente” in un determinato intervallo temporale;

● Difetto (defect): anomalia presente in un prodotto SW; ● Guasto (failure): comportamento anomalo del prodotto SW dovuto alla presenza di un

difetto; ● Errore: azione errata di chi (per ignoranza, distrazione, etc) introduce un difetto nel

prodotto SW; Intuitivamente si può dire che un prodotto software con molti difetti è poco affidabile. È allora chiaro che l’affidabilità del prodotto migliora via via che si riduce il numero di difetti.

Ovviamente l’affidabilità del software è frutto di una relazione non-semplice tra l’affidabilità osservata ed il numero di difetti latenti.

⇒ L’eliminare difetti dalle parti del prodotto raramente usate ha piccoli effetti sull’affidabilità osservata.

La regola 10-90: Esperimenti condotti su programmi di notevoli dimensioni mostrano che il 90% del tempo di esecuzione totale è spesso speso eseguendo solo il 10% delle istruzioni. Questo 10% è chiamato core (nucleo) del programma.

Il miglioramento dell’affidabilità per l’eliminazione di un difetto dipende dalla localizzazione del difetto (ovvero se appartiene o meno al nucleo del programma). Dunque, l’affidabilità osservata dipende da come è usato il prodotto in termini tecnici, dal suo profilo operativo (operational profile). Quindi, poichè utenti differenti usano il software secondo profili operativi diversi i difetti che si manifestano per un utente potrebbero non manifestarsi per l’altro.

Dunque l’affidabilità di un prodotto SW dipende dall’utente.

Confronto tra Affidabilità Hardware e Software:

I guasti SW: - Sono dovuti alla presenza di difetti nei programmi; - Il software non si consuma; I guasti HW sono quasi sempre dovuti a: - consumo/deterioramento dei componenti; - Qualche componente non si comporta più come specificato; - Qualche componente si rompe;

Esempi di difetti HW: - Un resistore si altera; - Un condensatore va in corto; - Una porta logica si blocca su 1 o su 0;

3/102

Per riparare un difetto HW si sostituisce il componente. I difetti Sw sono latenti, il sistema SW continua a guastarsi a meno che non si effettuino le dovute correzioni. A causa della differenza negli effetti dei difetti le metriche usate per l’affidabilità HW non sono estensibili al SW. Dopo la riparazione dell’HW la sua affidabilità torna come era. Dopo la riparazione del SW la sua affidabilità può aumentare o diminuire.

Obiettivo dell’affidabilità HW:

- Stabilità (cioè tenere la frequenza di guasto costante). Obiettivo dell’affidabilità SW:

- Crescita di affidabilità (cioè far decrescere la frequenza di guasto). Nella Realtà:

● Andamento frequenza di guasto hardware (effetto dell’eliminazione dei componenti difettosi prima, e dell’usura poi).

● Andamento frequenza di guasto software (effetto dell’eliminazione dei difetti prima, e dell’invecchiamento per manutenzione poi).

Disponibilità (SW Availability): È la percentuale del tempo che il SW è risultato usabile nel corso della sua vita. Dipende da 2 fattori:

1. Dal numero di guasti che si verificano; 2. Dal tempo necessario a ripararli;

Importanza di SW Reliability/Availability: Sono entrambe metriche importanti per sistemi in cui la caduta del servizio crea cadute di efficienza e sicurezza (perdite economiche e sociali, come ad esempio:

- Sistemi di trasporto; - Sistemi di governo del traffico aereo; - Sistemi di governo del volo; - Sistemi di produzione e distribuzione di energia; - Sistemi di comunicazione;

Nel corso degli anni la produzione del software ha seguito varie fasi: - fase di abilità, nella quale prevalgono gli aspetti di lavoro individuale e creativo; - fase artigianale, nella quale il software viene prodotto da piccoli gruppi specializzati, spesso di

alto livello di professionalità - fase industriale, nella quale l'attività di sviluppo e manutenzione del software viene pianificata

e coordinata, ed il lavoro del progettista viene sempre più supportato da strumenti automatici;

4/102

Lo Standard IEEE Std. 610.12 (1990): Lo standard IEEE Std. 610.12 (1990) ha formulato una definizione più completa:

1. Applicazione di un approccio sistematico, disciplinato e misurabile allo sviluppo, esercizio e manutenzione del software, cioè applicazione di principi ingegneristici al software.

2. Studio degli approcci di cui al punto 1. I metodi e le tecniche di Ingegneria del Software hanno lo scopo di fornire le risposte a diversi problemi, al fine di realizzare software con le desiderate caratteristiche di qualità, quali:

● Come assicurare la qualità del software che si produce? ● Come bilanciare la "domanda" crescente pur mantenendo il controllo del budget a

disposizione? ● Come aggiornare applicazioni vecchie (legacy) ma ancora necessarie? ● Come evitare tempi di consegna più lunghi di quelli pianificati? ● Come applicare con successo le nuove tecnologie software?

Miti (da sfatare) del Software: ● In caso di ritardo, basta aumentare il numero di programmatori; ● Una descrizione generica è sufficiente a scrivere i programmi. Eventuali modifiche si possono

facilmente effettuare in seguito; ● Una volta messo in opera il programma, il lavoro è finito; ● Non c'è modo di valutare la qualità fino a quando non si ha a disposizione il prodotto finale; ● L'ingegneria del software è costosa e rallenta la produzione;

5/102

Capitolo 2 - Il Processo Software

Processo Software - serie di attività necessarie alla realizzazione del prodotto software nei tempi, con i costi e con le desiderate caratteristiche di qualità. Nel suo contesto si applicano metodi, tecniche e strumenti; si creano prodotti (sia intermedi che finali); si stabilisce il controllo gestionale del progetto; si garantisce la qualità; si governano le modifiche.

Fasi del Processo Software: Il processo software segue un ciclo di vita che si articola in 3 stadi (sviluppo, manutenzione, dismissione).

● SVILUPPO (I STADIO): Si possono riconoscere due tipi di fasi:

- Fasi di tipo definizione: si occupano di “cosa” il software deve fornire. In queste fasi si definiscono i requisiti e si producono le specifiche.

- Fasi di tipo produzione: definiscono “come” realizzare quanto ottenuto con le fasi di definizione. In queste fasi si progetta il software, si codifica, si integra e si rilascia al cliente.

● MANUTENZIONE (II STADIO): Questo stadio è a supporto del software realizzato e prevede fasi di definizione e/o produzione al suo interno.

Durante ogni fase si procede ad effettuare il testing di quanto prodotto, mediante opportune tecniche di verifica e validazione (V&V) applicate sia ai prodotti intermedi che al prodotto finale. Tipi di Manutenzione possibili:

1. Manutenzione correttiva, che ha lo scopo di eliminare i difetti (fault) che producono guasti (failure) del software).

2. Manutenzione adattiva, che ha lo scopo di adattare il software ad eventuali cambiamenti a cui è sottoposto l’ambiente operativo per cui è stato sviluppato.

3. Manutenzione perfettiva, che ha lo scopo di estendere il software per accomodare funzionalità aggiuntive.

4. Manutenzione preventiva (o software reengineering), che consiste nell’effettuare modifiche che rendano più semplici le correzioni, gli adattamenti e le migliorie.

Definizione di Ciclo di Vita secondo lo IEEE Std 610-12:

- Intervallo di tempo che intercorre tra l’istante in cui nasce l’esigenza di costruire un prodotto software e l’istante in cui il prodotto viene dismesso.

- Include le fasi di definizione dei requisiti, specifica, pianificazione, progetto preliminare, progetto dettagliato, codifica, integrazione, testing, uso, manutenzione e dismissione.

Modelli di Ciclo di Vita: Il modello del ciclo di vita del software specifica la serie di fasi attraverso cui il prodotto software progredisce e l’ordine con cui vanno eseguite, dalla definizione dei requisiti alla dismissione. La scelta del modello dipende dalla natura dell’applicazione, dalla maturità dell’organizzazione, da metodi e tecnologie usate e da eventuali vincoli dettati dal cliente. L’assenza di un modello del ciclo di vita corrisponde ad una modalità di sviluppo detta “build & fix” (o “fix-it-later”), in cui il prodotto software viene sviluppato e successivamente rilavorato fino a soddisfare le necessità del cliente.

6/102

● BUILD & FIX:

● MODELLO WATERFALL:

○ Verification&Validation (V&V) nel WATERFALL:

7/102

● RAPID PROTOTYPING MODEL:

Prototipazione del software - Rapido sviluppo di software per richiedere o convalidare i requisiti.

Usi del Sistema a Prototipi: ● L'uso principale è aiutare clienti e sviluppatori a comprendere i requisiti del software

○ Richiesta di requisiti: gli utenti possono sperimentare un prototipo per vedere come il sistema supporta il loro lavoro

○ Convalida dei requisiti: il prototipo può rivelare errori e omissioni nei requisiti

● La prototipazione può essere considerata un'attività di riduzione del rischio che riduce i rischi relativi ai requisiti.

Vantaggi della Prototipazione:

● Sono esposti i fraintendimenti tra gli utenti del software e gli sviluppatori; ● Possono essere individuati servizi mancanti e servizi confusi; ● È disponibile un sistema di lavoro già da subito; ● Il prototipo può servire come base per derivare un software specifico; ● Il prototipo può supportare un training dell’utente e un test del prodotto;

Processo di Prototipazione: 1. Stabilire gli obiettivi del prototipo

(Prototyping plan) 2. Definire la funzionalità del

prototipo (Outline definition) 3. Sviluppo del prototipo

(Executable prototipe) 4. Valutazione del prototipo

(Evaluation report)

8/102

Prototipi come specifiche:

● Alcune parti dei requisiti (sicurezza - funzioni critiche) possono essere impossibili da essere prototipate e di conseguenza non appaiono nelle specifiche.

● Un’implementazione non ha status giuridico come contratto. ● I requisiti non-funzionali non possono essere testati adeguatamente in un prototipo del

software. Prototipazione Usa e Getta (THROW-AWAY)

● Un prototipo che solitamente è un’implementazione pratica del prodotto, è fatto per aiutare a scoprire i problemi di requisiti e scartarli. Il prodotto è successivamente sviluppato usando altri processi di sviluppo.

● Usato per ridurre il rischio di requisiti; ● Il prototipo è sviluppato da un requisito

iniziale, distribuito per esperimento ed infine scartato;

● Il prototipo usa e getta non dovrebbe essere considerato come un prodotto finale, alcune caratteristiche potrebbero essere state tralasciate, non c’è una specifica per la manutenzione a lungo termine, il prodotto sarà strutturato poveramente e difficile da essere mantenuto. Distribuzione del prototipo usa e getta:

● Gli sviluppatori possono essere costretti a distribuire un prototipo usa e getta come prodotto finale.

● Questo NON E’ CONSIGLIATO poiché: ○ Potrebbe essere impossibile mettere a punto il prototipo per soddisfare i

requisiti non-funzionali; ○ il prototipo è inevitabilmente non-documentato (senza documentazione -

undocumented); ○ la struttura sarà degradata (degraded) dai cambiamenti fatti durante lo

sviluppo; ○ i normali standard di qualità tecnico-organizzativi potrebbero non essere stati

applicati.

Key points della prototipazione: ● Un prototipo può essere utilizzato per dare agli utenti finali (end-users) un’impressione concreta

delle capacità del prodotto; ● La realizzazione dei prototipi sta diventando largamente utilizzata nello sviluppo del prodotto

dove lo sviluppo rapido è essenziale; ● Il prototipo usa e getta è utilizzato per capire i requisiti del prodotto; ● Il rapido sviluppo dei prototipi è essenziale. Questo potrebbe richiedere di tralasciare la

funzionalità o rilassare i limiti non-funzionali; ● La programmazione “visuale” (Visual Programming) è una parte intrinseca alla maggior parte

dei metodi di sviluppo del prototipo.

Programmazione visuale (visual programming): ● Linguaggi di scrittura come il “Visual

Basic” supportano programmazione visuale in cui il prototipo è sviluppato creando un’interfaccia utente dagli elementi standard e associando i componenti con questi elementi.

● Per supportare questo tipo di sviluppo esistono vaste librerie di componenti;

● Questi potrebbero essere fatti su misura per adattarsi ai requisiti della specifica applicazione;

9/102

Problemi con lo Sviluppo Visuale (visual development): ● Difficoltà a coordinare uno sviluppo basato sul team; ● Architettura software non esplicita; ● Dipendenze complicate tra le parti del programma possono causare problematiche

di manutenibilità; Processo di iterazione:

● I requisiti evolvono SEMPRE nel corso del progetto; dunque il processo di iterazione dove i primi passi sono rilavorati è sempre parte del processo per grandi prodotti;

● L’iterazione può essere applicata ad ognuno dei generici modelli di processo; ● Due approcci (connessi): Sviluppo incrementale e Sviluppo spiraliforme;

Sviluppo incrementale: ● Il prodotto è sviluppato e lanciato con incrementi dopo aver stabilito un’architettura

generale; ● I requisiti e le specifiche per ogni aggiunta possono essere sviluppati; ● Gli utenti possono sperimentare con gli incrementi (le aggiunte) consegnati mentre gli

altri vengono sviluppati. Pertanto questo serve come una forma di prototipo; ● Prevede di unire alcuni dei vantaggi della prototipazione ma con un processo

maggiormente gestibile ed una struttura migliore;

Modello incrementale: ● Il prodotto software viene sviluppato

e rilasciato per incrementi (build) successivi;

● Include aspetti tipici del modello basato su rapid prototyping (l’utente può sperimentare l’utilizzo del prodotto contenente gli incrementi consegnati, mentre i restanti sono ancora in fase di sviluppo;

● Si rivela efficace quando il cliente vuole continuamente verificare i progressi nello sviluppo del prodotto e quando i requisiti subiscono modifiche;

● Può essere realizzato in due versioni alternative: ■ Versione con overall architecture; ■ Versione senza overall architecture (più rischiosa).

→ Versione con overall architecture

10/102

→ Versione senza overall architecture

Impatto sui costi del software:

Confronto con modello a cascata:

Modello a cascata ● Requisiti “congelati” al termine della

fase di specifica; ● Feedback del cliente solo una volta

terminato lo sviluppo; ● Fasi condotte in rigida sequenza

(l’output di una costituisce input per la successiva);

● Prevede fasi di progetto dettagliato e codifica dell’intero prodotto;

● Team di sviluppo costituito da un numero elevato di persone;

Modello incrementale ● Requisiti suddivisi in classi di priorità e

facilmente modificabili; ● Continuo feedback da parte del

cliente durante lo sviluppo; ● Fasi che possono essere condotte in

parallelo; ● Progetto dettagliato e codifica

vengono effettuate sul singolo build; ● Differenti team di sviluppo, ciascuno di

piccole dimensioni;

11/102

Modello a spirale:

Modello a spirale semplificato:

(Versione lineare)

12/102

Modello full-spiral [Boehm, 1988]:

Gestione del rischio: ● La gestione del rischio si occupa di identificare i rischi e ideare piani per minimizzare il loro

effetto su un progetto; ● Un rischio è la probabilità che alcune circostanze avverse si verifichino ● Categorie di rischio :

○ I rischi connessi al progetto influenzano il programma (schedule) o le risorse ○ I rischi connessi al prodotto influenzano la qualità o la performance del software che si

sta sviluppando ○ I rischi aziendali influenzano lo sviluppo dell’organizzazione o il reperimento del

software

Categorie di rischi:

13/102

Processo di gestione del rischio: 1. Identificazione del rischio : Identificazione dei rischi connessi al progetto, al prodotto e dei

rischi aziendali 2. Analisi del rischio : Stima della probabilità e delle conseguenze di questi rischi 3. Pianificazione del rischio : Redigere piani per evitare o minimizzare gli effetti del rischio 4. Monitoraggio del rischio : Controllo del rischio per tutto il progetto

Identificazione del rischio: Tipologie di rischio: - Rischi tecnologici - Rischi riguardanti le persone - Rischi tecnico-organizzativi - Rischi legati agli strumenti - Rischi legati ai requisiti - Rischi di valutazione

14/102

Analisi del rischio: ● Stima la probabilità e la serietà di ogni rischio ● La probabilità del rischio può essere :

○ molto bassa (<10%) ○ bassa (10-25%) ○ moderata (25-50%) ○ alta (50-75%) ○ molto alta (>75%)

● Gli effetti del rischio possono essere catastrofici, gravi, tollerabili o insignificanti ● Identifica i rischi top-ten considerando tutti i rischi catastrofici e tutti i rischi gravi che

hanno più di una moderata probabilità di occorrenza e classifica questi rischi per ordine di importanza.

Pianificazione del rischio: ● Considera ogni rischio e sviluppa una strategia per gestire questo rischio; ● Strategie di elusione: la probabilità che il rischio possa presentarsi è ridotta; ● Strategie di minimizzazione: l’impatto del rischio sul progetto o prodotto sarà ridotto; ● Piani di emergenza: Se il rischio si presenta, i piani di emergenza sono strategie per

trattare con quel rischio;

Strategie di gestione del rischio:

15/102

Monitoraggio del rischio: ● Valuta ogni rischio identificato regolarmente per decidere se sta diventando più o

meno probabile; ● Per eseguire una valutazione guarda ai fattori di rischio; ● Valuta anche se gli effetti del rischio sono cambiati (in questo caso torna all’analisi del

rischio); ● Ogni rischio principale dovrebbe essere discusso ai meetings sulla gestione dello

sviluppo (management progress);

Fattori di rischio

Altri modelli: ● Modello object-oriented:

● Modello di ingegneria simultanea (o concorrente):

Ha come obiettivo la riduzione di tempi e costi di sviluppo mediante un approccio sistematico al progetto integrato e concorrente di un prodotto software e del processo ad esso associato. Le fasi di sviluppo coesistono invece di essere eseguite in sequenza.

● Modello basato su metodi formali:

Comprende una serie di attività che conducono alla specifica formale matematica del software al fine di eliminare ambiguità, incompletezze ed inconsistenze e facilitare la verifica dei programmi mediante l’applicazione di tecniche matematiche. La Cleanroom Software Engineering (1987) ne rappresenta un esempio di realizzazione, in cui viene enfatizzata la possibilità di rilevare i difetti del software in modo più tempestivo rispetto ai modelli tradizionali.

16/102

Il modello Microsoft: La Microsoft, come altre organizzazioni che sviluppano software commerciale, ha dovuto affrontare, fin dalla metà degli anni 80, problemi di incremento della qualità dei prodotti software e riduzione di tempi e costi di sviluppo. Per cercare di risolvere tali problemi si è adottato un processo che è al tempo stesso iterativo, incrementale e concorrente e che permette di esaltare le doti di creatività delle persone coinvolte nello sviluppo di prodotti software.

Approccio synch-and-stabilize:

● Si tratta dell’approccio attualmente usato da Microsoft; ● Tale approccio è basato su :

1. La sincronizzazione quotidiana delle attività svolte da persone che lavorano sia individualmente che all’interno di piccoli team (da 3 a 8 persone) mediante assemblaggio dei componenti software sviluppati (anche parzialmente) in un prodotto (daily build) che viene testato e corretto;

2. La stabilizzazione periodica del prodotto in incrementi (milestone) successivi durante l’avanzamento del progetto piuttosto che un’unica volta alla fine.

Ciclo di sviluppo a 3 fasi:

● Fase progettuale/di pianificazione: definisce la visione, la descrizione dettagliata e la tabella di marcia del prodotto;

● Fase di sviluppo: presenta lo sviluppo in 3/4 sottoprogetti sequenziali ognuno derivante da una pubblicazione importante (milestone release);

● Fase di stabilizzazione: test onnicomprensivi interni ed esterni, prodotto finale, consolidamento e invio;

Fase progettuale

Fase di sviluppo

17/102

Fase di stabilizzazione

Strategie e Principi: ● Strategia per definire prodotto e processo:

“considerare la creatività come elemento essenziale” Principi di realizzazione:

A. Dividere il progetto in milestone (da 3 a 4); B. Definire una “product vision” e produrre una specifica funzionale che evolverà

durante il progetto; C. Selezionare le funzionalità e le relative priorità in base alle necessità utente; D. Definire un’architettura modulare per replicare nel progetto la struttura del prodotto; E. Assegnare task elementari e limitare le risorse;

● Strategia per lo sviluppo e la consegna dei prodotti: “lavorare in parallelo con frequenti sincronizzazioni” Principi di realizzazione:

A. Definire team paralleli ed utilizzare daily build per la sincronizzazione; B. Avere sempre un prodotto da consegnare, con versioni per ogni piattaforma e

mercato; C. Usare lo stesso linguaggio di programmazione all’interno dello stesso sito di sviluppo; D. Testare continuamente il prodotto durante il suo sviluppo; E. Usare metriche per il supporto alle decisioni;

Milestones:

18/102

Modello del ciclo di sviluppo synch-and-stabilize:

Confronto tra modelli synch-and-stabilize e waterfall:

Il modello Netscape:

Anche alla Netscape si è adottato un modello di tipo synchronize-and-stabilize con opportuni adattamenti allo sviluppo di applicazioni Internet (browser e prodotti server): ● Dimensione dello staff: in media 1 tester ogni 3 sviluppatori (ma stessa produttività di Microsoft

nello sviluppo di prodotti comparabili); ● Processo:

○ scarso effort di pianificazione (tranne che su prodotti server); ○ documentazione incompleta; ○ scarso controllo sullo stato di avanzamento del progetto (lasciato all’esperienza e

all’influenza dei project manager); ○ scarso controllo su attività di ispezione del codice (code review); ○ pochi dati storici per il supporto alle decisioni;

19/102

Staffing:

Processo di sviluppo Netscape:

● Step 1: Requisiti del prodotto e proposta del progetto

○ Pianificazione anticipata del meeting (APM) tenuta per fare brainstorming di idee (marketing, sviluppo, esecutivo).

○ Si sviluppa la visione del prodotto, inizialmente dagli ingegneri più esperti, adesso principalmente dai responsabili di prodotto (product managers).

○ Della progettazione e scrittura di codice dagli ingegneri per esplorare tecnologie alternative o idee tecniche.

○ Documento dei requisiti del prodotto compilato dai responsabili del prodotto con l’aiuto degli sviluppatori.

○ Revisione non ufficiale di queste specifiche preliminari dagli ingegneri. ○ La specifica funzionale inizia dagli ingegneri, talvolta con l’aiuto dai

responsabili del prodotto. ○ Programma e piano di bilancio compilati dal settore commerciale ed

ingegneristico e discusso in modo non ufficiale con i dirigenti.

● Step 2: Prima revisione esecutiva ○ Documento di revisione esecutiva dei requisiti del prodotto, programma e

proposta di bilancio; ○ Piano modificato secondo le necessità;

● Step 3: Inizio della fase di sviluppo

○ Caratteristiche di design e scrittura in codice, lavoro di progettazione secondo le necessità;

○ Integrazione giornaliera dei componenti come sono creati e costruiti; ○ Lista dei problemi generati e inizio delle correzioni;

● Step 4: Revisione esecutiva provvisoria (se necessario)

Le specifiche funzionali dovrebbero essere complete a questo punto; ○ Correzione di metà strada nelle specifiche o risorse del progetto dove

necessario; ○ Problemi di coordinamento con altri prodotti o progetti discussi dove

necessario; ○ Continuo dello sviluppo;

● Step 5: Primo rilascio interno (alpha) (impiega approssimativamente sei settimane)

○ Lo sviluppo si arresta temporaneamente. ○ Intensivo debugging e testing del codice esistente; ○ Rilascio dell’Alpha per un feedback interno (o possibilmente un rilascio dello

sviluppatore); ○ Continua lo sviluppo; ○ Inserimento del feedback dell’utente; ○ Obiettivo completamento delle funzionalità (raramente conseguito,

nonostante i server in particolare cercano di essere il più completi possibile); ○ Una settimana per stabilizzare il rilascio beta;

20/102

● Step 6: Pubblicazione di beta 1 o test sul campo 1 (impiega approssimativamente sei settimane)

○ Ripetizione dei passi dello sviluppo e dei test nello step 5; ○ Gruppi server passano a test sul campo con clientela limitata piuttosto che

beta pubbliche;

● Step 7: Pubblicazione beta 2 e 3 (ogni beta impiega all’incirca sei settimane) ○ Ripetizione dei passi dello sviluppo come nello Step 5; ○ Congelamento dell’interfaccia utente milestone (UI freeze milestone); ○ Completamento della funzione dello status “mandatorio”, anche se sono

ancora concessi piccoli cambiamenti;

● Step 8: Completamento del codice ○ Nessuna aggiunta di codice eccetto quello per correggere i bug; le

caratteristiche sono funzionalmente complete;

● Step 9: Prova finale e rilascio ○ Ricerca degli errori (debugging) finale e stabilizzazione della versione di

rilascio; ○ Meetings di abilitazione con i dirigenti più esperti (senior) per la decisione del

lancio; ○ Rilascio per la produzione (RTM Release to manufacturing) e rilascio

commerciale;

Modello di Maturità delle Capacità (CMM Capability Maturity Model): Il SEI (Software Engineering Institute) ha predisposto a partire dal 1993 un modello per determinare il livello di maturità del processo software di un’organizzazione (ovvero una misura dell’efficacia globale dell'applicazione di tecniche di ingegneria del software). Il modello è basato su un questionario ed uno schema valutativo a cinque livelli. Ogni livello comprende tutte le caratteristiche definite per il livello precedente.

I 5 livelli del CMM:

Aree chiave del processo: Il CMM associa ad ogni livello di maturità alcune KPA (Key Process Area), tra le 18 definite, che descrivono le funzioni che devono essere presenti per garantire l’appartenenza ad un certo livello. Ogni KPA è descritta rispetto a :

- obiettivi - impegni e responsabilità da assumere - capacità e risorse necessarie per la realizzazione - attività da realizzare - metodi di “monitoring” della realizzazione - metodi di verifica della realizzazione

21/102

CMM KPAs:

Statistiche a febbraio 2000: La lista delle organizzazioni a livello 4 e 5 (maturità elevata) include :

- 71 organizzazioni negli USA, 44 a livello 4 (tra cui Oracle, NCR, Siemens Info Systems, IBM Global Services) e 27 organizzazioni a Livello 5 (tra cui Motorola, Lockeed-Martin, Booeing, Honeywell)

- 25 organizzazioni al di fuori degli USA, 1 a livello 4 in Australia, 14 a livello 4 in India, 10 a livello 5 in India

Numero di valutazione per paese (06/15):

22/102

Trends (Giugno 2015):

Capitolo 3 - Requisiti Software

Requisiti software (software requirements): descrizione dei servizi che un sistema software deve fornire, insieme ai vincoli da rispettare sia in fase di sviluppo che durante la fase di operatività del software.

def. IEEE Std 610.12 (1990):

A. Una condizione o capacità necessaria a un utente per risolvere un problema o raggiungere un obiettivo.

B. Una condizione o capacità che deve essere soddisfatta o posseduta da un sistema o componente di sistema per soddisfare un contratto, uno standard, una specifica o altro formalmente documento imposto.

C. Una rappresentazione documentata di una condizione o capacità come da definizione (A) o (B).

I requisiti vengono generati applicando un processo di ingegneria dei requisiti (requirements engineering).

Requirements abstraction (Davis, 1993):

“If a company wishes to let a contract for a large software development project, it must define its needs in a sufficiently abstract way that a solution is not pre-defined. The requirements must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organisation's needs. Once a contract has been awarded, the contractor must write a system definition for the client in more detail so that the client understands and can validate what the software will do. Both of these documents may be called the requirements document for the system” (Davis, 1993).

Tipi di requisiti: E’ possibile riconoscere diverse tipologie di requisiti:

1. Requisiti utente (user requirements): - descrizione in linguaggio naturale, con eventuale aggiunta di diagrammi, dei servizi

che il sistema deve fornire e dei vincoli operativi - sono scritti per (e con) il cliente

2. Requisiti di sistema (system requirements): - specificati mediante la stesura di un documento strutturato che descrive in modo

dettagliato i servizi che il sistema software deve fornire - il documento risultante costituisce un "contratto" tra cliente e fornitore

Definizioni:

● Cliente (customer, client), la persona od organizzazione che paga per la fornitura di un prodotto software;

● Fornitore (supplier, contractor), la persona od organizzazione che produce software per il cliente;

● Utente finale (end-user), la persona che interagisce direttamente con il prodotto software. Non corrisponde necessariamente al cliente;

23/102

Esempi di requisiti ● Requisito utente:

○ 1. Il sistema software deve fornire un mezzo per rappresentare e visualizzare file esterni generati da altri tool;

● Requisito di sistema: 1. L'utente deve avere la possibilità di definire il tipo dei file esterni; 2. Ad ogni tipo di file esterno deve essere associato il tool che lo ha generato; 3. Ogni tipo di file esterno deve essere rappresentato mediante una specifica icona sullo

schermo; 4. L'utente deve avere la possibilità di definire l'icona che rappresenta il tipo di file

esterno; 5. Quando l'utente seleziona un'icona che rappresenta un file esterno, deve poter essere

eseguito il tool in grado di visualizzare il file;

Chi legge i requisiti:

Categorie di requisiti:

● Requisiti funzionali: descrivono le funzionalità del sistema software, in termini di servizi che il sistema software deve fornire, di come il sistema software reagisce a specifici tipi di input e di come si comporta in situazioni particolari. Es.1 Il sistema software deve fornire un appropriato visualizzatore per i documenti memorizzati Es.2 L’utente deve essere in grado di effettuare ricerche sia sull’intero insieme di basi di dati che su un loro sottoinsieme Es.3 Ad ogni nuovo ordine deve essere associato un identificatore unico (Order_ID)

● Requisiti non funzionali: descrivono le proprietà del sistema software in relazione a determinati servizi o funzioni e possono anche essere relativi al processo:

● caratteristiche di efficienza, affidabilità, safety, ecc. ● caratteristiche del processo di sviluppo (standard di processo, uso di ambienti CASE,

linguaggi di programmazione, metodi di sviluppo, ecc.); ● caratteristiche esterne (interoperabilità con sistemi di altre organizzazioni, vincoli

legislativi, ecc.); Es.1 Il tempo di risposta del sistema all'inserimento della password utente deve essere inferiore a 10 sec; Es.2 I documenti di progetto (deliverable) devono essere conformi allo standard XYZ-ABC-12345; Es.3 Il sistema software non deve rilasciare ai suoi operatori nessuna informazione personale relativa ai clienti, tranne nominativo e identificatore;

● Requisiti di dominio:

requisiti derivati dal dominio applicativo del sistema software piuttosto che da necessità dettate dagli utenti

○ requisiti funzionali, nuovi o adattatati, relativi al particolare dominio applicativo ○ requisiti non funzionali, nuovi o adattati, relativi a standard esistenti o a procedure e

regolamenti da applicare Es.1 I documenti di rendiconto contabile, secondo la normativa XYZ.03, devono essere stampati alla ricezione e cancellati immediatamente Es.2 L'interfaccia utente per l'accesso al database magazzino deve essere conforme allo standard ZX.01

24/102

Problemi con i requisiti software: ● Ambiguità: requisiti interpretabili in modo differente;

○ Esempio 1: specificare un tempo senza fornire il riferimento al fuso orario (in un'applicazione che gestisce chiamate intercontinentali);

○ Esempio 2: significato di "appropriato visualizzatore ■ Interpretazione utente: visualizzatore specifico per ogni tipo di documento ■ Interpretazione sviluppatore: generico visualizzatore di testo che mostri il

contenuto del documento;

● Incompletezza: i requisiti non includono la descrizione di tutte le caratteristiche richieste;

● Inconsistenza: conflitti o contraddizioni nella descrizione delle caratteristiche del sistema; ○ Esempio:

■ Req 1: ogni form di input non deve contenere più di 5 campi editabili dall'utente

■ Req 2: nella form di input relativa all'inserimento dei dati anagrafici l'utente deve introdurre i seguenti dati: nome, cognome, anno di nascita, indirizzo, telefono, fax, e-mail

Verificabilità requisiti:

● I requisiti non funzionali espressi in modo generico dall'utente (es. il sistema software deve essere easy-to-use) possono risultare non quantificabili e difficili da verificare.

● E' quindi necessario esprimere i requisiti non funzionali usando una misura determinata che permetta di verificare quantitativamente se il requisito verrà soddisfatto dal sistema software.

Esempi di misure per requisiti:

Requisiti utente: Descrivono requisiti funzionali e non funzionali, espressi in modo da risultare comprensibili agli utenti del sistema sprovvisti di conoscenze tecniche. I requisiti utente sono generalmente espressi in linguaggio naturale, tenendo in considerazione alcune linee guida:

● Usare un formato standard per tutti i requisiti ● Usare il linguaggio naturale in modo consistente (es. uso di "deve" per requisiti

necessari e "dovrebbe" per requisiti desiderabili) ● Evidenziare le parti fondamentali di un requisito ● Evitare l'uso di termini tecnici

Esempio di Requisito Utente: 3.5.1 Aggiunta di nodi a un disegno 3.5.1.1 L'editor deve fornire agli utenti la possibilità di aggiungere nodi di un tipo specificato al proprio progetto. 3.5.1.2 La sequenza di azioni per aggiungere un nodo dovrebbe essere la seguente:

1. L'utente deve selezionare il tipo di nodo da aggiungere. 2. L'utente deve spostare il cursore sulla posizione approssimativa del nodo nel diagramma e indicare che il simbolo del nodo deve essere aggiunto in quel punto. 3. L'utente dovrebbe quindi trascinare il simbolo del nodo nella sua posizione finale.

25/102

Rationale: l'utente è la persona migliore per decidere dove posizionare un nodo sul diagramma. Questo approccio offre all'utente il controllo diretto sulla selezione e sul posizionamento del tipo di nodo. Specification: ECLIPSE/WS/Tools/DE/FS/Section 3.5.1

Requisiti di sistema (specifiche): Sono specifiche più dettagliate dei requisiti utente e sono usati come base per il progetto software. Possono essere espressi facendo uso di notazioni differenti.

Tipologie di nozioni:

● Structured natural language, questo approccio dipende dalla definizione di moduli o modelli standard per esprimere la specifica dei requisiti

● Program Description Languages (PDL), questo approccio utilizza un linguaggio come un linguaggio di programmazione (PDL, Linguaggio di descrizione del programma) ma con caratteristiche più astratte per specificare i requisiti definendo un modello operativo del sistema.

● Graphical notations, un linguaggio grafico, integrato da annotazioni di testo, viene utilizzato per definire i requisiti funzionali del sistema. Il linguaggio grafico viene utilizzato per definire i modelli di sistema

● Mathematical specifications, queste sono notazioni basate su concetti matematici come macchine o insiemi a stati finiti. Queste specifiche inequivocabili riducono gli argomenti tra cliente e appaltatore sulla funzionalità del sistema. Tuttavia, la maggior parte dei clienti non comprende le specifiche formali ed è riluttante ad accettarle come contratto di sistema.

Documento di Analisi Requisiti (o Documento di Specifica): Documento ufficiale che descrive in dettaglio le caratteristiche del sistema da sviluppare e include sia la definizione dei requisiti che la loro specifica. Descrive COSA il sistema deve fornire (dominio del problema) e non COME il sistema deve essere sviluppato (dominio della soluzione).

Gli utenti che lo caratterizzano sono: - System customers, specify the requirements and read them to check that they meet their

needs. They specify changes to the requirements - Managers, use the requirements document to plan a bid for the system nd to plan the system

development process - System engineers, use the requirements to understand what system is to be developed - System test engineers, use the requirements to develop validation tests for the system - System maintenance engineers, use the requirements to help understand the system and the

relationship between its parts Struttura del documento: - Preface, expected readership, version history, changes summary - Introduction, purpose, brief description of the system, interaction with other systems, scope

within the business context - Glossary, definition of technical terms used in the document - User requirements definition, functional and non-functional user requirements - System architecture, high-level overview of the system components - System requirements specification, functional and non-functional system requirements - System models, description of the relationships between the system components and the

system and its environment - System evolution, assumptions on which the system is based and anticipated changes

(hardware evolution, user needs changes, etc.) - Appendices, specific information related to the application which is being developed (ex. HW

and DB descriptions) - Index, table of contents, alphabetic index, list of diagrams, etc.

26/102

Capitolo 04 - Ingegneria dei requisiti

Ingegneria dei Requisiti: Il processo di ingegneria dei requisiti (requirements engineering) varia in base al dominio applicativo, alle persone coinvolte ed all'organizzazione che sviluppa il sistema software. Si può, però, individuare un insieme di attività generiche comuni a tutti i processi:

● Studio di fattibilità (feasibility study) ● Identificazione e analisi dei requisiti (req. elicitation and analysis) ● Specifica dei requisiti (req. specification) ● Convalida dei requisiti (req. validation) ● Gestione dei requisiti (req. management)

Nello specifico: 1. Studio di fattibilità:

Fase iniziale del processo di ingegneria dei requisiti, si basa su una descrizione sommaria del sistema software e delle necessità utente. Le informazioni necessarie per lo studio di fattibilità vengono raccolte da colloqui con:

● Client manager ● Ingegneri del software con esperienza nello specifico dominio applicativo ● Esperti delle tecnologie da utilizzare ● Utenti finali del sistema

Lo studio di fattibilità produce come risultato un report che stabilisce l'opportunità o meno di procedere allo sviluppo del sistema software. Domande tipiche dello studio di fattibilità:

● In che termini il sistema software contribuisce al raggiungimento degli obiettivi strategici del cliente?

● Può il sistema software essere sviluppato usando le tecnologie correnti e rispettando i vincoli di durata e costo complessivo?

● Può il sistema software essere integrato con altri sistemi già in uso? 2. Attività di identificazione e analisi dei requisiti:

Il team di sviluppo incontra il cliente e gli utenti finali al fine di identificare l'insieme dei requisiti utente, dalla cui analisi si generano i requisiti di sistema (specifiche). L'identificazione dei requisiti può coinvolgere personale che copre vari ruoli, sia all'interno dell'organizzazione del cliente che in altre organizzazioni o tra gli utenti finali. Il termine stakeholder viene usato per identificare tutti coloro che hanno un interesse diretto o indiretto sui requisiti del sistema software da sviluppare. Task:

● Comprensione del dominio: l'analista deve acquisire conoscenze sul dominio applicativo (es. se il sistema software deve supportare il lavoro di un ufficio postale, l'analista deve comprendere il funzionamento di un ufficio postale)

● Raccolta dei requisiti: mediante interazione con gli stakeholder si identificano i requisiti utente

● Classificazione: l'insieme dei requisiti raccolti viene suddiviso in sotto-insiemi coerenti di requisiti

● Risoluzione dei conflitti: eventuali contraddizioni e/o conflitti tra requisiti vanno identificati e risolti

● Assegnazione delle priorità: mediante interazione con gli stakeholder, ad ogni requisito o sotto-insiemi di requisiti va assegnata una classe di priorità

● Verifica dei requisiti: i requisiti vengono controllati per verificarne completezza e consistenza, in accordo a quanto richiesto dagli stakeholder

Tecniche di identificazione dei requisiti:

● Ethnography; ● Casi d'uso (basati su scenari); ● Prototipazione;

Tecniche di analisi (e specifica) dei requisiti: ● Semi-formali, basate su modelli del sistema e usate dai metodi di analisi strutturata o

analisi orientata agli oggetti ● Formali (basate su Petri Net, FSM, Z, etc.)

27/102

3. Convalida dei requisiti: La convalida dei requisiti è finalizzata ad accertare se il documento dei requisiti, ottenuto come risultato della fase di analisi, descrive realmente il sistema software che il cliente si aspetta. La scoperta di errori in questa fase è fondamentale per evitare costosi rework in fasi più avanzate del ciclo di vita. I controlli da effettuare includono:

● Validità ● Consistenza ● Completezza ● Realizzabilità ● Verificabilità

4. Tecniche di convalida dei requisiti:

Includono: ● Revisioni informali; ● Revisioni formali:

○ walkthrough; ○ ispezioni;

● Prototipazione; ● Generazione dei test-case; ● Analisi di consistenza automatizzata (per requisiti formali);

5. Gestione dei requisiti:

Processo di identificazione e controllo delle modifiche subite dai requisiti di un sistema software lungo il ciclo di vita. I requisiti di un sistema software possono essere classificati in termini della loro evoluzione come:

● Requisiti stabili (probabilità minima di essere modificati nel tempo) ● Requisiti volatili (probabilità elevata di essere modificati nel tempo):

○ mutabili (modifiche legate a cambiamenti nell'ambiente operativo) ○ emergenti (modifiche causate da una migliore comprensione del sistema

software) ○ consequenziali (modifiche legate all'introduzione di sistemi informatici nel

flusso di lavoro) ○ di compatibilità (modifiche legate a cambiamenti nei sistemi e nei processi

aziendali) Specifiche formali vs informali: La Specifica dei Requisiti è usata per:

● Definire le necessità dell'utente ● Definire le caratteristiche del sistema implementato ● Comprendere il sistema nelle attività di manutenzione

Le specifiche possono essere poste in maniera formale o in maniera informale. Le specifiche informali fanno uso di linguaggio naturale per descrivere i requisiti. Possono essere utilizzati diagrammi e tabelle per aumentare le informazioni. La sintassi e la semantica non sono formalmente definite.

Le specifiche formali usano linguaggi che hanno sintassi e semantica definite in modo formale e sono usate principalmente per sistemi safety-critical. Consentono animazione, simulazione e verifica di proprietà.

28/102

Specifiche formali con Petri Net:

Marked Petri Net (1):

Marked Petri Net (2):

Marked Petri Net (3)

29/102

Petri Net: esempio

Specifiche formali con Finite State Machine (FSM): esempio

Specifiche formali con linguaggio Z: La notazione Z è un linguaggio di specifica formale utilizzato per la descrizione e progettazione di sistemi informatici. Il suo nome deriva dalla teoria degli insiemi di Zermelo - Fraenkel. Consiste in un set di schemi, dove ogni schema Z ha il seguente formato:

30/102

Linguaggio Z: esempio di specifica di stato

Linguaggio Z: esempio di specifica di operazione

Specifiche semi-formali: modelli del sistema

Modello del sistema - rappresentazione astratta del sistema che facilita la comprensione delle proprietà del sistema e delle sue caratteristiche di funzionamento, prima che il sistema venga costruito. L'uso di modelli dei sistemi software è formalizzato all'interno di metodi di analisi dei requisiti (specifica) del software che fanno uso di tecniche semi-formali.

I metodi di analisi dei requisiti software sono di due tipi:

1. Metodi di analisi strutturata (o procedurale); 2. Metodi di analisi orientata agli oggetti;

Per descrivere completamente un sistema è necessario costruire vari modelli che rappresentino il sistema da vari punti di vista (informazioni, funzioni e comportamento dinamico).

Tipi di modelli del sistema:

Per descrivere la specifica semi-formale di un sistema software si usano 3 tipi di modelli:

1. Modello dei dati: rappresenta gli aspetti statici e strutturali relativi ai dati (data requirements):

● ERD (not UML); ● class diagram (UML);

2. Modello comportamentale: rappresenta gli aspetti funzionali del sistema (functional

requirements): ● data flow diagram (not UML);

31/102

● use case diagram (UML); ● activity diagram (UML); ● interaction diagram (UML);

3. Modello dinamico: rappresenta gli aspetti di “controllo” e di come le funzioni del modello comportamentale modificano i dati introdotti nel modello dei dati

● state diagram (UML);

Entity Relationship Diagram (ERD) [relazioni uno-a-molti]:

1. 2.

Data Flow Diagram (DFD):

Esempio di DFD: primo raffinamento

32/102

Esempio di DFD: secondo raffinamento

Structured System Analysis (SSA) (metodo di analisi strutturata): Metodo introdotto da Gane and Sarson (1979), è costituito da 9 step ed è basato sul concetto di step-wise refinement. Altri metodi di analisi strutturata:

● DeMarco (1978); ● Yourdon and Constantine (1979);

SSA: Step 1 (Draw the DFD)

Utilizzare il documento dei requisiti (o il prototipo) per: ● Identificare i flussi di dati ● Identificare l'origine e le destinazioni dei dati (dove i dati i flussi iniziano e finiscono,

rispettivamente) ● Identificare i processi che trasformano i dati

Affina il DFD aggiungendo nuovi flussi di dati o per aggiunta di dettagli ai flussi di dati esistenti.

SSA: Step 2 (Decide what Sections to Computerize and How)

Utilizzare l'analisi costi-benefici per decidere quali sezioni del DFD da automatizzare Decidi come informatizare: ● Operazioni batch ● Elaborazione online Esempio:

● Automatizza il posizionamento degli ordini in batch ● Automatizza la convalida degli ordini online

I prossimi 3 passaggi sono il perfezionamento graduale dei dati flussi, processi e archivi dati.

SSA: Step 3 (Determine the details of the data flows) Decidere quali elementi di dati devono essere inseriti nei vari flussi di dati Esempio:

L'ordine del flusso di dati può essere perfezionato come segue: ● order_identification ● Customer_details ● Package_details

33/102

Affinare gradualmente ciascun flusso: ● order_identification is a 12-digit integer ● customer_details consists of customer_name, customer_address, etc.

SSA: Step 4 (Define the logic of processes)

Esempio: costruisci l’albero decisionale per il processo give_educational_discount.

SSA: Step 5 (Determine the data stores) Definire il contenuto esatto di ogni store e relativi rappresentazione (formato specifico in una determinata programmazione linguaggio) Definire il livello di accesso mediante i data-immediate access diagram (DIAD) Esempio:

SSA: Step 6 (Define the physical resource)

Esempio: ● Per ogni file, specificare: nome file, organizzazione (sequenziale, indicizzato, ecc.),

supporto di memorizzazione, record, ?fino al livello del campo? ● If a DBMS is to be used, then the relevant information for each table is specified

SSA: Step 7 (Determine the Input/Output specifications)

● È necessario specificare i moduli di input (componenti e layout) ● Le schermate di output devono essere determinate in modo simile ● È necessario specificare anche l'output stampato (lunghezza e dettagli stimati)

SSA: Step 8 (Determine the sizing)

Calcolare: ● Volume di input (giornaliero o orario) ● Frequenza di ciascun rapporto stampato e relativa scadenza ● Dimensione e numero di record che devono passare tra la CPU e la memoria di massa ● Dimensione di ciascun file

SSA: Step 9 (Determine the hardware requirements)

Dalle informazioni sul dimensionamento specificate al passaggio 8, determinare: ● Requisiti di archiviazione di massa ● Requisiti di archiviazione di massa per il backup ● Caratteristiche dei terminali utente ● Caratteristiche dei dispositivi di output ● Adeguatezza dell'hardware esistente ● Costi dell'hardware da acquistare

34/102

SSA OUTPUT: Lo Step 9 è l'ultimo Step di SSA. Dopo l'approvazione da parte del cliente, il risultante documento di specifica viene consegnato al design team e il processo del software continua Svantaggi:

● SSA non può essere utilizzato per determinare i tempi di risposta ● Le dimensioni e il tempo della CPU non possono essere determinati con nessun grado

di precisione

35/102

Capitolo 05- Richiami OOP

Richiami su oggetti e OOP Un oggetto (object) è una entità caratterizzata da una struttura dati alla quale si associa l’insieme delle operazioni che è possibile compiere su di essa. Un oggetto può essere concreto (es: un file) o concettuale (es: una politica di scheduling) ⇒ Un’attività è dunque orientata agli oggetti se opera su di essi, come ad esempio:

● object-oriented analysis (OOA); ● object-oriented design (OOD); ● object-oriented programming (OOP);

Caratteristiche degli Oggetti:

● Classificazione (Classification) ● Identità (Identity) ● Ereditarietà (Inheritance) ● Polimorfismo (Polymorphism)

Classificazione degli Oggetti: Oggetti con identica struttura dati (attributes) ed operazioni (operations) sono raggruppati in classi (classes).

● Ogni oggetto è una istanza di una classe; ● Ogni oggetto contiene un riferimento implicito alla classe di appartenenza; ● Ogni oggetto condivide struttura dati ed operazioni con le altre istanze della sua classe di

appartenenza; ● L’istanziazione di un oggetto implica l’assegnamento di valori agli attributi;

Guardando nello specifico le caratteristiche:

1. Identità: ● Ogni oggetto ha una sua propria identità; ● Due oggetti sono entità distinte anche se

tutti i valori stanziati per gli attributi sono identici;

● Gli oggetti sono identificabili attraverso un riferimento esplicito (handle)

2. Ereditarietà: ● È la condivisione di attributi ed operazioni

tra classi in una qualche relazione gerarchica;

● Una classe può essere raffinata attraverso un insieme di sottoclassi (subclasses), costituendo una superclasse (superclass) delle suddette sottoclassi;

● Ogni sottoclasse eredita tutte le proprietà della relativa superclasse;

3. Polimorfismo: ● Oggetti appartenenti a classi in una qualche relazione gerarchica possono

condividere operazioni senza condividere forzatamente l’implementazione relativa ad ognuna di esse;

● Una operazione rappresenta una particolare manipolazione dei dati istanziati per un oggetto;

● Ci si riferisce all’implementazione di una operazione specifica per una particolare classe come ad un metodo (method) di tale classe;

● Ad una operazione possono essere associati più metodi che la implementano;

36/102

Vantaggi nell’utilizzo degli oggetti: Gli oggetti consentono di incrementare la qualità del software (in particolare riusabilità e manutenibilità), riducendo il TTM (Time To Market), grazie ai meccanismi di:

● Incapsulamento delle strutture dati (attributi) e delle operazioni (metodi) che le manipolano (encapsulation);

● Separazione tra la struttura dati propria di un oggetto e la struttura dati accessibile dall’esterno (information hiding);

● Astrazione del comportamento delle operazioni a prescindere dalla loro implementazione (abstraction);

● Condivisione di strutture dati ed operazioni, attraverso ereditarietà e polimorfismo (sharing);

Object Oriented Programming (OOP)

Dichiarazione di una classe:

OOP: istanziazione di un oggetto

L’istanziazione di un oggetto è resa possibile dall’apposito operatore new, attraverso il quale:

● Viene riservato spazio in memoria per l’oggetto;

● Viene generato il riferimento per l’oggetto;

L’operatore new richiama il costruttore della classe attraverso il quale è possibile inizializzare i valori degli attributi.

OOP: distruzione di un oggetto La distruzione di un oggetto consiste nel:

● liberare la memoria allocata per l’oggetto; ● eliminare il riferimento dell’oggetto;

La distruzione di un oggetto è ottenibile attraverso:

● Operatore delete (es: C++); ● Garbage collector (es: Java);

Prima che un oggetto venga realmente disallocato viene richiamato, qualora esista, il metodo distruttore, attraverso il quale è possibile specificare un insieme di operazioni da compiersi prima della distruzione.

37/102

OPP: data encapsulation

OOP: information hiding

Associazioni tra classi:

38/102

Ulteriori tipi di associazioni:

Associazione ternaria:

Association classes:

Associazioni qualificate:

39/102

Ereditarietà:

Aggregazione:

40/102

Capitolo 06 - OOA

Object Oriented Analysis (OAA): La fase di OOA definisce, secondo un approccio ad oggetti, COSA un prodotto software deve fare (mentre la fase di OOD definisce, sempre secondo un approccio ad oggetti, COME un prodotto software deve fare quanto specificato in fase di OOA).

OOA e OOD devono fornire, ciascuno dal proprio punto di vista, una rappresentazione corretta, completa e consistente degli:

● aspetti statici e strutturali relativi ai dati (modello dei dati); ● aspetti funzionali del sistema (modello comportamentale); ● aspetti di "controllo" e di come le funzioni del modello comportamentale modificano i dati

introdotti nel modello dei dati (modello dinamico);

Metodi di OOA: Un metodo di OOA definisce l'insieme di procedure, tecniche e strumenti per un approccio sistematico alla gestione e allo sviluppo della fase di OOA.

● L'input di un metodo di OOA è costituito dall'insieme dei requisiti utente (contenuti nel documento di analisi dei requisiti);

● L'output di un metodo di OOA è costituito dall'insieme dei modelli del sistema che definiscono la specifica del prodotto software (e che sono anch'essi contenuti nel documento di analisi dei requisiti);

● I metodi di OOA fanno principalmente uso di notazioni visuali (diagrammi), ma possono essere affiancati da metodi tradizionali per la definizione di requisiti di sistema di tipo testuale (in linguaggio naturale strutturato);

● Lo sviluppo dei modelli di OOA non è un processo sequenziale (prima modello dei dati, poi modello comportamentale, infine modello dinamico);

● La costruzione dei modelli avviene in parallelo, e ciascun modello fornisce informazioni utili per gli altri modelli;

● I metodi di OOA fanno uso di un approccio iterativo, con aggiunta di dettagli per raffinamenti successivi (iterazioni);

Alcuni metodi di OOA (e OOD):

● Catalysis: metodo OO particolarmente indicato per lo sviluppo di sistemi software a componenti distribui.

● Objectory: metodo ideato da I. Jacobson che fonda lo sviluppo di prodotti software ad oggetti sull’individuazione dei casi d’uso utente (use case driven).

● Shlaer/Mellor: metodo OO particolarmente indicato per lo sviluppo di sistemi software real-time.

● OMT (Object Modeling Technique): metodo sviluppato da J. Rumbaugh basato su tecniche di modellazione del software iterative. Pone in particolare risalto la fase di OOA.

● Booch: metodo basato su tecniche di modellazione del software iterative. Pone in particolare risalto la fase di OOD.

● Fusion: metodo sviluppato dalla HP a metà degli anni novanta. Rappresenta il primo tentativo di standardizzazione per lo sviluppo di software orientato agli oggetti. Si basa sulla fusione dei metodi OMT e Booch.

Notazioni per OOA (e OOD): Ciascun metodo di OOA (e OOD) fa uso di una propria notazione per la rappresentazione dei modelli del sistema. Al fine di unificare le notazioni per i metodi di OOA e OOD è stato introdotto il linguaggio UML (Unified Modeling Language), adottato nel 1997 come standard OMG (Object Management Group).

UML è un linguaggio standard per la descrizione di sistemi software (orientati agli oggetti). Si compone di nove formalismi di base (diagrammi con semantica e notazione data) e di un insieme di estensioni. UML è un linguaggio di descrizione, non è un metodo né definisce un processo.

Unified Software Development Process (in breve Unified Process) è un tentativo di standardizzazione di processo di sviluppo di sistemi orientati agli oggetti basato sull’uso di UML.

41/102

Diagrammi UML

Formalismi UML: I nove formalismi di base dello UML sono:

1. Use case diagram: Evidenziano la modalità (caso d’uso) con cui gli utenti (attori) utilizzano il sistema. Possono essere usati come supporto per la definizione dei requisiti utente.

2. Class diagram:

Consentono di rappresentare le classi con le relative proprietà (attributi, operazioni) e le associazioni che le legano.

3. State diagram:

Rappresentano il comportamento dinamico dei singoli oggetti di una classe in termini di stati possibili e transizioni di stato per effetto di eventi.

4. Activity diagram:

Sono particolari state diagram, in cui gli stati rappresentati rappresentano azioni in corso di esecuzione. Sono particolarmente indicati per la produzione di modelli di workflow.

5. Sequence diagram:

Evidenziano le interazioni (messaggi) che oggetti di classi diverse si scambiano nell’ambito di un determinato caso d’uso, ordinate in sequenza temporale. A differenza dei diagrammi di collaborazione, non evidenziano le relazioni tra oggetti.

6. Collaboration diagram: Descrivono le interazioni (messaggi) tra oggetti diversi, evidenziando le relazioni esistenti tra le singole istanze.

7. Object diagram:

Permettono di rappresentare gli oggetti e le relazioni tra essi nell’ambito di un determinato caso d’uso.

8. Component diagram: Evidenziano la strutturazione e le dipendenze esistenti tra componenti software.

9. Deployment diagram: Evidenziano le configurazioni dei nodi elaborativi di un sistema real time ed i componenti, processi ed oggetti assegnati a tali nodi.

42/102

Modello dai dati: Rappresenta da un punto di vista statico e strutturale l'organizzazione logica dei dati da elaborare. Le strutture dati sono definite mediante lo stato degli oggetti, che viene determinato dal valore assegnato ad attributi e associazioni. Il modello dei dati viene specificato mediante il formalismo dei class diagram che permette di definire:

● Classi ● Attributi di ciascuna classe ● Operazioni di ciascuna classe ● Associazioni tra classi

Il modello dei dati è di fondamentale importanza, visto che, secondo l'approccio ad oggetti, un sistema software è costituito da un insieme di oggetti (classificati) che collaborano Il modello dei dati viene costruito in modo iterativo ed incrementale. Si tratta di un processo creativo, in cui giocano un ruolo importante sia l'esperienza dell'analista che la comprensione del dominio applicativo. Durante la fase iniziale di costruzione del modello dei dati occorre concentrarsi sulle cosiddette entity classes, ovvero quelle classi che definiscono il dominio applicativo e che sono rilevanti per il sistema. Le control classes (che gestiscono la “logica” del sistema) e boundary classes (che rappresentano l'interfaccia utente) vengono introdotte successivamente, usando le informazioni del modello comportamentale. Le operazioni di ciascuna classe vengono identificate a partire dal modello comportamentale, per cui vengono inizialmente trascurate. Approcci per l’identificazione delle classi:

Sono: ● Noun phrase; ● Common class patterns; ● Use case driven; ● CRC; ● Mixed;

Nello specifico: 1. Approccio noun phrase:

Una frase nominale (noun phrase) è una frase in cui il sostantivo ha una prevalenza sulla parte verbale (sono frasi di tipo assertivo). I sostantivi delle frasi nominali usate per la stesura dei requisiti utente sono considerati candidate classes. La lista delle candidate classes viene suddivisa in tre gruppi:

● Irrelevant (non appartengono al dominio applicativo e quindi possono essere scartate);

● Relevant (evidenziano caratteristiche di entity classes); ● Fuzzy (non si hanno sufficienti informazioni per classificarle come relevant o irrelevant,

vanno analizzate successivamente); Si assume che l'insieme dei requisiti utente sia completo e corretto.

2. Approccio common class patterns:

Basato sulla teoria della classificazione, le candidate classes vengono identificate a partire da gruppi (pattern) di classi predefinite:

● Concept (es. Reservation) ● Events (es, Arrival) ● Organization (es. AirCompany) ● People (es. Passenger) ● Places (es. TravelOffice)

Non è un approccio sistematico, ma può rappresentare un’utile guida A differenza dell’approccio noun phrase, non si concentra sul documento dei requisiti utente. Può causare problemi di interpretazione dei nomi delle classi.

43/102

3. Approccio use case driven:

Si assume che: ● Siano già stati sviluppati gli use case diagram ( e possibilmente anche i sequence

diagram più significativi); ● Per ogni use case sia fornita una descrizione testuale dello scenario di funzionamento;

Simile all'approccio noun phrase (si considera l'insieme degli use case come insieme dei requisiti utente). Si assume che l'insieme degli use case sia completo e corretto. Approccio function-driven (o problem-driven secondo la terminologia object oriented).

4. Approccio CRC:

L'approccio CRC (Class – Responsibility Collaborators) è basato su riunioni in cui si fa uso di apposite card.

Ciascuna card rappresenta una classe e contiene tre compartimenti che identificano:

● Il nome della classe ● Le responsabilità assegnate alla classe ● Il nome di altre classi che collaborano con la classe

Le classi vengono identificate analizzando come gli oggetti collaborano per svolgere le funzioni di sistema

È un approccio utile per: ● Verifica di classi identificate con altri metodi ● Identificazione di attributi e operazioni di ciascuna

classe.

5. Approccio mixed:

Basato su elementi presenti in ciascuno degli approcci precedenti Un possibile scenario potrebbe essere il seguente: 1. L'insieme iniziale delle classi viene identificato in base all'esperienza dell'analista,

facendosi eventualmente guidare dall'approccio common class patterns 2. Altre classi possono essere aggiunte usando sia l'approccio noun phrase che

l'approccio use case driven (se gli use case diagram sono disponibili) 3. Infine l'approccio CRC può essere usato per verificare l'insieme delle classi identificate.

Linee guida per l’identificazione delle entità Classes:

1. Ogni classe deve avere un ben preciso statement of purpose; 2. Ogni classe deve prevedere un insieme di istanze (oggetti) – le cosiddette singleton classes

(per la quali si prevede una singola istanza) non sono di norma classificabili come entity classes 3. Ogni classe deve prevedere un insieme di attributi (non un singolo attributo); 4. Distinguere tra elementi che possono essere modellate come classi o come attributi; 5. Ogni classe deve prevedere un insieme di operazioni (anche se inizialmente le operazioni

vengono trascurate, i servizi che la classe mette a disposizione sono implicitamente derivabili dallo statement of purpose);

Casi di studio:

A. University Enrolment B. Video Store C. Contact Management D. Telemarketing

44/102

A. University Enrolment: Problem statement

● L’università offre: ○ Laurea e post laurea. ○ Studenti part-time o a tempo pieno.

● Struttura universitaria:

○ Divisioni contenenti dipartimenti ○ Ogni divisione amministra ogni laurea ○ La laurea può includere corsi di altre divisioni

● Sistema iscrizione all’università:

○ Programmi di studio personalizzati ○ Corsi obbligatori ○ Restrizioni

● Il sistema è tenuto a:

○ Dare assistenza nelle attività di pre iscrizione ○ Gestire le procedure di iscrizione

● Attività di pre iscrizione:

○ Mail-out: ○ - Valutazione esami semestre precedente ○ - Istruzioni per l’iscrizione

● Durante l’iscrizione: ○ Accettare i piani di studio proposti dagli studenti ○ Convalida prerequisiti, orari, dimensioni delle classi

B. Video Store: Problem statement 1. Noleggio di videocassette e dischi per i clienti; 2. Tutti i prodotti devono essere identificati da un codice a barre; 3. All’iscrizione deve essere associato al cliente un codice a barre; 4. I clienti possono effettuare prenotazioni; 5. Il negozio deve essere disponibile a rispondere alle richieste dei clienti, incluse

domande riguardo film non presenti in stock, ma ordinabili; C. Contact Management: Problem statement

1. L’azienda è costantemente alla ricerca di nuovi clienti; 2. Presenta un sistema di gestione dei contatti caratterizzata da:

● Potenziali clienti ● Clienti reali ● Clienti passati

3. The new contact management system to be developed internally and be available to all employees in the company, but with varying levels of access;

● Employees of Customer Services Department will take the ownership of the system

4. The system to permit flexible scheduling and re-scheduling of contactrelated activities so that the employees can successfully collaborate to win new customers and foster existing relationships;

D. Telemarketing: Problem statement

● Le associazioni di beneficenza vendono biglietti della lotteria per raccogliere fondi ○ Campagne a supporto di importanti cause di beneficenza ○ Sostenitori “passati” presi di mira attraverso il telemarketing

● Premi per: ○ Acquisti all’ingrosso ○ Attirare nuovi collaboratori

● La società non prende di mira casualmente i nuovi clienti utilizzando elenchi telefonici o mezzi simili;

● Applicazioni di telemarketing: ○ Supportare fino a cinquanta telemarketing funzionanti contemporaneamente ○ Pianificare le telefonate in base a priorità prestabilite e altri vincoli noti

45/102

○ Comporre le telefonate in programma ○ Riprogrammare connessioni non riuscite ○ Organizzare chiamate telefoniche ai sostenitori ○ Registrare i risultati della conversazione

Esempio A1 - University Enrolment: Considerare i seguenti requisiti per il sistema di iscrizione universitaria e identificare le classi candidate: ogni titolo universitario ha un numero di corsi obbligatori e un numero di corsi opzionali.

Altri requisiti: ● Ogni corso ha un determinato livello e ha un valore in

punti di credito; ● Un corso può far parte di qualsiasi laurea; ● Ogni laurea specifica il valore minimo totale dei punti di credito richiesto per il completamento

della laurea; ● Gli studenti possono combinare le offerte di corsi in programmi di studio adatti alle loro

esigenze individuali;

Esempio A.1 – University Enrolment (SOLUZIONE):

Esempio B.1 - Video Store: Considerare i seguenti requisiti per il sistema di archivio video e identificare le classi candidate:

● Il negozio di video tiene in magazzino una vasta libreria di titoli di film attuali e popolari. Un film particolare può essere tenuto su nastri o dischi video.

● I video sono in formato "Beta" o "VHS" ● I dischi video sono in formato DVD ● Ogni film ha un periodo di noleggio particolare (espresso

in giorni), con un canone di locazione per quel periodo ● Il negozio di video deve essere in grado di rispondere immediatamente a eventuali domande

sulla disponibilità delle scorte di un film e su come molti nastri e / o dischi sono disponibili per il noleggio

● Le condizioni attuali di ciascun nastro e disco devono essere conosciuto e registrato Esempio B.1 – Video Store (SOLUZIONE)

46/102

Esempio C.1 – Contact Management:

Considerare i seguenti requisiti per la gestione dei contatti sistema e identificazione delle classi candidate:

- Per "rimanere in contatto" con la base di clienti attuali e potenziali - Memorizzare nomi, numeri di telefono, indirizzi postali e di corriere, ecc. di organizzazioni e

persone in tali organizzazioni - Pianificare compiti ed eventi per i dipendenti in relazione alle persone da contattare - I dipendenti possono pianificare attività ed eventi per altri dipendenti o per se stessi - Un'attività è un gruppo di eventi che hanno luogo per ottenere un risultato (ad es. Per risolvere

il problema del cliente) - Tipici tipi di eventi sono: telefonata, visita, invio di un fax, organizzazione dell'allenamento

Esempio C.1 – Contact Management (solution):

Example D.1 – Telemarketing: Considera la seguente descrizione testuale per i casi d'uso del sistema di telemarketing e identifica le classi candidate:

● Il telemarketer richiede al sistema di programmare e comporre la chiamata telefonica a un sostenitore;

● Una volta stabilita la connessione, il telemarketer offre biglietti della lotteria al tifoso. Durante una conversazione, potrebbe essere necessario che il telemarketer acceda e modifichi i dettagli della campagna e dei sostenitori (CRUD, create – read – update – delete)

● Infine, il telemarketer inserisce l'esito della conversazione, ovvero i risultati positivi o negativi dell'azione di telemarketing;

(Business Use Case Diagram) Esempio D.1 – Telemarketing (solution):

47/102

Linee guida per la specifica delle classi: ● Nomi di classe:

○ Associare ad ogni classe un nome significativo nello specifico dominio applicativo; ○ Adottare una convenzione standard per assegnare nomi alle classi, ad esempio:

nome singolare, parole multiple devono essere congiunte, con l'iniziale di ciascuna parola in carattere maiuscolo (es. PostalAddress);

○ Definire una lunghezza massima per i nomi delle classi (non più di 30 caratteri);

● Attributi e operazioni: ○ Considerare inizialmente solo attributi che caratterizzano possibili stati di interesse per

gli oggetti; ○ Adottare una convenzione standard per assegnare nomi agli attributi, ad esempio: le

parole devono essere scritte in carattere minuscolo, separate da un carattere di underscore (es. street_name);

○ Ritardare l'aggiunta di operazioni fino al momento in cui sia disponibile il modello comportamentale, da cui vanno derivate;

Esempio A.2 – University Enrolment (Riferito ad Esempio A.1):

Considerare i seguenti requisiti aggiuntivi dal documento Requisiti:

● La scelta dei corsi di uno studente può essere limitata da sovrapposizioni di orario e da limitazioni sul numero di studenti che possono essere iscritti all'attuale offerta di corsi.

Altri requisiti: ● Il piano di studio proposto da uno studente è inserito nel

sistema di iscrizione online; ● Il sistema verifica la coerenza del piano e segnala eventuali problemi; ● I problemi devono essere risolti con l'aiuto di un consulente accademico; ● Il piano finale di studio è soggetto all'approvazione accademica;

Esempio A.2 – University Enrolment (solution):

Esempio B.2 – Video Store (Riferito ad Esempio B.1): I requisiti aggiuntivi sono:

● Il costo del noleggio varia a seconda del supporto video: nastro

o disco (ma è lo stesso per le due categorie di nastri: Beta e VHS).

Altri requisiti:

● Il sistema dovrebbe contenere formati di archiviazione video futuri oltre a nastri VHS, nastri beta e dischi DVD

● I dipendenti utilizzano spesso un codice film, anziché il titolo del film, per identificare il film ● Lo stesso titolo del film può avere più di una uscita di registi diversi

48/102

Esempio B.2 – Video Store (solution):

Esempio C.2 – Contact Management (Riferito ad Esempio C.1): Informazioni aggiuntive: Un cliente è considerato corrente se esiste un contratto con quel cliente per la consegna dei nostri prodotti o servizi. La gestione dei contratti è tuttavia al di fuori dell'ambito del nostro sistema.

Altri requisiti:

● Rapporti sui contatti basati su indirizzi postali e di corriere (ad es. Trova tutti i clienti per codice postale);

● La data e l'ora della creazione dell'attività vengono registrate;

● Il "valore monetario" di un'attività può essere memorizzato; ● Gli eventi, per il dipendente, vengono visualizzati sullo schermo del dipendente in delle pagine

simili ad un calendario (un giorno per pagina). La priorità di ciascun evento (basso, medio o alto) si distingue visivamente sullo schermo

● Non tutti gli eventi hanno un "tempo utile" - alcuni sono "senza orario"; ● Il tempo di creazione dell'evento non può essere modificato; ● Vengono registrate la data e l'ora di completamento dell'evento; ● Il sistema memorizza le identificazioni dei dipendenti che hanno creato attività ed eventi, che

sono programmati per fare l'evento e che hanno completato l'evento;

Esempio C.2 – Contact Management (solution):

49/102

Esempio D.2 - Telemarketing (Riferito ad Esempio D.1): Considera le seguenti affermazioni aggiuntive:

● Ogni campagna ha un titolo generalmente utilizzato per fare riferimento ad esso;

● Ha un codice univoco per riferimento interno;

● Funziona per un periodo di tempo fisso;

● Subito dopo la chiusura della campagna, i premi vengono estratti e vengono avvisati i possessori dei biglietti vincenti;

● I biglietti sono numerati in modo univoco all'interno di ogni campagna: il numero totale di biglietti in una campagna, il numero di biglietti venduti finora e lo stato corrente di ciascun biglietto sono noti (ad esempio disponibili, ordinati, pagati, vincitore del premio);

● Per determinare le prestazioni dei telemarketing della società, vengono registrate la durata delle chiamate e i risultati delle chiamate riuscite (ad es. Risultanti in biglietti ordinati);

● Vengono mantenute ampie informazioni sui sostenitori: dettagli di contatto (indirizzo, numero di telefono, ecc.), dettagli storici come le prime e le date più recenti in cui un sostenitore aveva partecipato a una campagna, preferenze e vincoli di qualsiasi sostenitore noto (ad es. Tempi di non chiamata, normale numero di carta di credito);

● Le chiamate di telemarketing vengono effettuate in base alle loro priorità; ● Le chiamate senza risposta o in cui è stata trovata una segreteria telefonica vengono

riprogrammate: I tempi delle chiamate ripetute vengono alternati - Il numero di chiamate ripetute è limitato - I limiti possono essere diversi per i diversi tipi di chiamata (ad es. Una normale

chiamata di "sollecitazione" può avere un limite diverso rispetto a una chiamata per ricordare a un sostenitore di un pagamento in sospeso)

- I risultati delle chiamate sono classificati: successo (ad es. Biglietti ordinati), nessun successo, richiamata più tardi, nessuna risposta, attiva, segreteria telefonica, fax, numero errato, disconnessa.

Esempio D.2 – Telemarketing (solution):

Identificazione delle associazioni

● Alcuni attributi identificati con le classi rappresentano associazioni (ogni attributo di tipo non primitivo dovrebbe essere modellato come un’associazione alla classe che rappresenta quel tipo di dato);

● Ogni associazione ternaria dovrebbe essere rimpiazzata con un ciclo di associazioni binarie, per evitare problemi di interpretazione;

● Nei cicli di associazioni almeno un’associazione potrebbe essere eliminata e gestita come associazione derivata, anche se per problemi di efficienza spesso si introducono associazioni ridondanti;

50/102

Specifica delle associazioni:

- Per assegnare nomi alle associazioni adottare la stessa convenzione usata per gli attributi (le parole devono essere scritte in carattere minuscolo, separate da un carattere di underscore);

- Assegnare nomi di ruolo (rolename) alle estremità dell’associazione (i rolename diventano i nomi degli attributi nella classe all’estremità opposta dell’associazione);

- Determinare la molteplicità delle associazioni (ad entrambe le estremità); Esempio C.3 – Contact Management (Riferito ad Esempio C.1 e C.2): Si consideri, ad esempio, il requisito: il sistema consente di produrre vari rapporti sui nostri contatti basati su indirizzi postali e di corriere

Esempio C.3 – Contact Management (solution – 1):

Esempio C.3 – Contact Management (solution – 2)

51/102

Aggregazione: Rappresenta una relazione di tipo “whole-part” (Tutto-Parte, contenimento) tra una classe composta (superset class) e l’insieme di una o più classi componenti (subset classes).

Può assumere quattro differenti significati:

1. ExclusiveOwns (e.g. Book has Chapter, or Chapter is part of a Book) - Existence-dependency - Transitivity - Asymmetricity - Fixed property

2. Owns (e.g. Car has Tire) - No fixed property

3. Has (e.g. Division has Department) - No existence dependency - No fixed property

4. Member (e.g. Meeting has Chairperson) - No special properties except membership

Specifica di aggregazione in UML:

● Aggregation: ○ By-reference semantics ○ Diamante cavo (♢) ○ Corrisponde alle aggregazioni Has e Member

● Composition:

○ By-value semantics ○ Diamante solido (♦ ) ○ Corrisponde alle aggregazioni ExclusiveOwns e Owns

Esempio A.3 – University Enrolment (Riferito ad Esempio A.1 e A.2): Considerare i seguenti requisiti aggiuntivi:

● Curriculum accademico dello studente sia disponibile su richiesta ● Il curriculum può includere informazioni sui voti degli studenti in ogni corso a cui lo studente si è

iscritto (e non si è ritirato senza penalità) ● Ogni corso ha un docente universitario incaricato di un corso, ma anche altri docenti possono

insegnare in esso: ○ Potrebbe esserci un diverso docente responsabile di un corso ciascuno semestre; ○ Ci possono essere diversi docenti per ogni corso ogni semestre;

Esempio A.3 – University Enrolment (solution):

52/102

Ereditarietà (generalizzazione): Usata per rappresentare la condivisione di attributi ed operazioni tra classi. Le caratteristiche comuni sono modellate in una classe più generica (superclasse), che viene specializzata nell’insieme di sottoclassi. Una sottoclasse eredita attributi ed operazioni della superclasse. Caratteristiche:

● Sostituibilità: un oggetto della sottoclasse è un valore legale per una variabile avente come tipo la superclasse (es. una variabile di tipo Frutta può avere un oggetto di tipo Mela come suo valore).

● Polimorfismo: la stessa operazione può avere differenti implementazioni nelle sottoclassi. Specifica di ereditarietà in UML:

● Rappresenta relazioni di tipo: ○ “can-be” (Es. Student can be a TeachingAssistant); ○ “is-a-kind-of” (Es. TeachingAssistant is a kind of Student);

● Supporto ad ereditarietà multipla (Es. TeachingAssistant is also a kind of Teacher). ● Viene rappresentata in UML con una linea, che collega la sottoclasse con la

superclasse, avente una freccia diretta verso la superclasse.

Esempio B.3 – Video Store (Riferito ad Esempio B.1 e B.2): Le classi identificate nell'Esempio 4.5 implicano una gerarchia di generalizzazione radicata nella classe VideoMedium:

● Estendere il modello per includere le relazioni tra le classi e specificare le relazioni di generalizzazione

● Supponiamo che il Video Store debba sapere se un VideoTape è un nastro nuovo di zecca o è già stato registrato (questo può essere catturato da un attributo is_taped_over)

● Supponiamo anche che la capacità di archiviazione di un VideoDisk consenta di contenere più versioni dello stesso film, ognuna in una lingua diversa o con finali diversi Esempio B.3 – Video Store (solution):

Object Diagram: Rappresentazione grafica di istanze di classi, sono usati per:

● Modellare relazioni complesse tra classi (a scopo esemplificativo) ● Illustrare le modifiche ai singoli oggetti durante l’evoluzione del sistema ● Illustrare la collaborazione tra oggetti durante l’evoluzione del sistema

53/102

Esempio A.4 – University Enrolment: Mostra un Object Diagram con pochi oggetti che rappresentano le classi nell'esempio A.3

Modello Comportamentale:

● Rappresenta gli aspetti funzionali del sistema da un punto di vista operativo, evidenziando come gli oggetti collaborano ed interagiscono al fine di offrire i servizi che il sistema mette a disposizione.

● Fa uso di vari formalismi: ○ Use case diagram (per descrivere scenari di funzionamento) ○ Activity diagram (per descrivere il flusso di elaborazione) ○ Sequence diagram (per descrivere l'interazione tra gli oggetti) ○ Collaboration diagram (per descrivere l'interazione tra gli oggetti)

● Viene costruito in modo iterativo ed incrementale, usando le informazioni del modello dei dati, che a sua volta fa uso del modello comportamentale per identificare operazioni e classi aggiuntive (control classes e boundary classes).

Use Case Diagram:

● Può essere sviluppato a differenti livelli di astrazione (sia in fase di OOA che OOD). ● Durante la fase di OOA, si concentra su COSA il sistema deve fare (scenari di funzionamento). ● Un caso d'uso rappresenta:

○ Una funzionalità completa (flusso principale, sotto flussi e alternative) ○ Una funzionalità visibile dall'esterno ○ Un comportamento ortogonale (ogni use case viene eseguito in modo indipendente

dagli altri) ○ Una funzionalità originata da un attore del sistema (una volta originato, il caso d'uso

può interagire con altri attori) ○ Una funzionalità che produce un risultato significativo per un attore

Identificazione dei casi d'uso:

● A partire da: ○ Insieme dei requisiti utente; ○ Attori del sistema (insieme ai relativi obiettivi);

● L'identificazione può essere facilitata facendosi guidare dalle seguenti domande:

○ Quali sono i compiti principali svolti da ciascun attore? ○ Un attore accede o modifica l’informazione nel sistema? ○ L'attore rappresenta il tramite mediante cui il sistema viene informato di

modifiche apportate in altri sistemi? ○ L'attore deve essere informato di eventuali cambiamenti avvenuti nel

sistema?

● Durante la fase di OOA, i casi d'uso identificano le necessità degli attori del sistema;

54/102

Specifica di use case diagram:

● Rappresentazione grafica di attori, casi d'uso e relazioni ● Si possono rappresentare quattro tipi di relazioni:

○ Associazione (tra attore e caso d'uso); ○ Include (identificato dallo stereotype: «include»): un caso d'uso included è

sempre necessario per completare il caso d'uso con il quale è messo in relazione;

○ Extend (identificato dallo stereotype : «extend»): un caso d'uso extended può attivare il caso d'uso dal quale viene esteso (ma tale attivazione non è necessaria per completare il caso d’uso extended);

○ Generalizzazione;

Esempio A.5 – University Enrolment:

Esempio C.3 – Contact Management:

55/102

Esempio B.4 – Video Store

Esempio B.4 – Video Store (Rent Video):

Breve descrizione Un cliente desidera noleggiare un nastro o un disco video. A condizione che il cliente disponga di un account non insolvente, il nastro viene noleggiato una volta ricevuto il pagamento. Se il nastro non viene restituito in modo tempestivo, viene inviato al cliente un avviso in ritardo.

Attori Dipendente, dispositivo di scansione

Presupposti È possibile noleggiare nastro o disco video. Il cliente ha una tessera associativa. I dispositivi scanner funzionano correttamente. I dipendenti della reception sanno come utilizzare il sistema.

Main Flow

Un cliente può chiedere a un dipendente la disponibilità del video (incluso un video riservato) o può scegliere un nastro o un disco dagli scaffali. Il video e la tessera associativa vengono scansionati e qualsiasi dettaglio scaduto viene portato all'attenzione del dipendente. Il cliente può noleggiare fino a un massimo di otto video. Tuttavia, se la valutazione del cliente è "inaffidabile", viene richiesto un deposito di un periodo di noleggio per ogni nastro o disco. Una volta ricevuto l'importo da pagare, lo stock viene aggiornato e i nastri e i dischi vengono consegnati al cliente insieme alla ricevuta del noleggio. Il cliente paga in contanti, carta di credito o bonifico elettronico. Ogni record di noleggio memorizza le date di check-out e di scadenza insieme all'identificazione del dipendente. Viene creato un record di noleggio separato per ogni video noleggiato. Verrà generato un avviso scaduto per il cliente se un video non è stato restituito entro due giorni dalla data di scadenza e un secondo avviso dopo altri due giorni (e in quel momento il cliente viene indicato come "delinquente").

Alternative Flows

Un cliente non ha una tessera associativa. In questo caso, il caso il Maintain Customer può essere attivato per emettere una nuova carta. Un tentativo di noleggiare troppi video. Nessun video può essere noleggiato a causa della valutazione insolente del cliente. Non è possibile scansionare il supporto video o la tessera associativa perché sono danneggiati. Il trasferimento elettronico o il pagamento con carta di credito viene rifiutato.

Postconditions I video vengono noleggiati e il database viene aggiornato di conseguenza.

56/102

Esempio D.3 – Telemarketing

Activity Diagram:

● Rappresenta a vari livelli di astrazione il flusso di esecuzione, sia sequenziale che concorrente, in una applicazione object-oriented;

● E’ una variante degli state diagram, in cui gli stati rappresentano l’esecuzione di azioni e le transizioni sono attivate dal completamento di tali azioni;

● Usato principalmente in fase di OOD per rappresentare il flusso di esecuzione delle operazioni definite nel class diagram;

● In fase di OOA, viene usato per rappresentare il flusso delle attività nell’esecuzione di un caso d’uso (un caso d’uso può essere associato ad uno o più activity diagram);

● Poiché non vengono mostrati gli oggetti che eseguono le attività, può essere costruito anche in assenza del class diagram;

● In presenza del class diagram, ogni attività può essere associata ad una o più operazioni appartenenti ad una o più classi;

Specifica di activity diagram:

● Un evento (esterno) che origina un caso d’uso viene modellato come un evento che causa l’esecuzione di un activity diagram;

● Gli action state vengono identificati a partire dalla descrizione testuale dello scenario di funzionamento di un caso d’uso;

● Gli action state vengono quindi associati mediante transition lines (che possono essere controllate da guard conditions);

● Le transizioni in uscita da un action state vengono percorse quando l’action state viene completato (l’esecuzione procede da un action state al successivo);

● Un action state viene completato quando la sua elaborazione termina; ● Flussi concorrenti vengono modellati con barre di sincronizzazione (barre fork-join); ● Flussi alternativi vengono modellati con nodi decisionali (branch/merge diamonds); ● Eventi esterni non sono generalmente modellati;

57/102

Esempio B.5 – Video Store

Esempio B.5 – Video Store (fixed):

58/102

Esempio B.5 –Video Store (improved):

Diagrammi di interazione:

● Sequence diagram: ○ Descrive lo scambio di messaggi tra oggetti in ordine temporale ○ Usato principalmente in fase di OOA

● Collaboration diagram: ○ Descrive lo scambio di messaggi tra oggetti mediante relazioni tra gli oggetti stessi ○ Usato principalmente in fase di OOD

Sequence diagram e collaboration diagram permettono di identificare le operazioni delle classi nel class diagram Sequence diagram e collaboration diagram sono rappresentazioni equivalenti e possono essere generati in modo automatico l’uno dall’altro Specifica di sequence diagram:

● Le attività dell’activity diagram vengono mappate come messaggi (di tipo “richiesta esecuzione attività”) in un sequence diagram;

● Un messaggio può rappresentare: ○ Un signal:

■ Denota una chiamata di tipo asincrono ■ L’oggetto mittente continua l’esecuzione dopo aver inviato il

messaggio asincrono; ○ Una call:

■ Denota una chiamata di tipo sincrono; ■ L’oggetto mittente blocca l’esecuzione dopo aver inviato il

messaggio sincrono, in attesa della risposta da parte dell’oggetto destinatario (che può o meno contenere valori di ritorno);

59/102

Notazione per sequence diagram:

Esempio A.6 – University Enrolment

Interfaccia pubblica di classe:

● Definisce l’insieme di operazioni che la classe mette a disposizione delle altre classi ● Durante la fase di OOA, si determina la signature dell’operazione, che consiste di:

○ Nome dell’operazione ○ Lista degli argomenti formali ○ Tipo di ritorno

● Durante la fase di OOD, si definisce l’algoritmo che implementa l’operazione ● Un’operazione può avere:

● Instance scope ● Class (static) scope

○ Rappresentata con un carattere $ che precede il nome dell’operazione ○ Agisce su class object (classi con attributi static)

60/102

Identificazione delle operazioni: ● Dai sequence diagram; ● Ogni messaggio inviato ad un oggetto identifica un metodo della classe a cui appartiene tale

oggetto; ● Usando criteri aggiuntivi, come ad esempio il criterio CRUD, secondo cui ogni oggetto deve

supportare le seguenti operazioni primitive (CRUD operations): ○ Create (una nuova istanza) ○ Read (lo stato di un oggetto) ○ Update (lo stato di un oggetto) ○ Delete (l’oggetto stesso)

Esempio A.7 – University Enrolment: Fare riferimento agli esempi A.3 e A.6 e alle classi Course and CourseOffering. Derivare le operazioni dal diagramma delle sequenze e aggiungerle alle lezioni Course e CourseOffering.

Modello dinamico:

● Rappresenta il comportamento dinamico degli oggetti di una singola classe, in termini di stati possibili ed eventi e condizioni che originano transizioni di stato (assieme alle eventuali azioni da svolgere a seguito dell’evento verificatosi);

● Fa uso del formalismo State Diagrams; ● Viene costruito per ogni classe di controllo

(per le quali è interessante descrivere il comportamento dinamico);

● Usato principalmente per applicazioni scientifiche e realtime (meno frequentemente nello sviluppo di applicazioni gestionali);

Esempio B.5 – Video Store:

61/102

Gestione della complessità nei modelli di OOA: ● Nella fase di OOA per sistemi software di grandi dimensioni occorre gestire in modo opportuno

l'intrinseca complessità dei modelli; ● Le associazioni tra classi nel modello dei dati formano complesse reti di interconnessione, in cui

i cammini di comunicazione crescono in modo esponenziale con l'aggiunta di nuove classi; ● L'introduzione di gerarchie di classi permette di ridurre tale complessità da esponenziale a

polinomiale, grazie all'introduzione di opportuni strati di classi che vincolano la comunicazione tra classi appartenenti allo stesso strato o a strati adiacenti; Class diagram non stratificato:

Class diagram stratificato

62/102

UML Package: ● L'UML fornisce la nozione di package per rappresentare un gruppo di classi o di altri elementi

(ad esempio casi d'uso) ● I package possono essere annidati (il package esterno ha accesso ad ogni classe contenuta

all'interno dei package in esso annidati) ● Una classe può appartenere ad un solo package, ma può comunicare con classi

appartenenti ad altri package ● La comunicazione tra classi appartenenti a package differenti viene controllata mediante

dichiarazione di visibilità (private, protected, o public) delle classi all'interno dei package

Dipendenza tra package: La relazione di dipendenza non è specificata, ma sta ad indicare che eventuali modifiche a Package2 potrebbero richiedere modifiche di NestedPackage.

Package diagram:

● In UML non esiste il concetto di package diagram ● I package possono essere creati all'interno di:

○ Class diagram ○ Use case diagram

● Si possono specificare due tipi di relazioni tra package:

○ Generalization, implica anche dependency ○ Dependency, usage dependency, access dependency, visibility dependency

Approccio BCE:

● Boundary package (BCE): ○ Descrive classi i cui oggetti gestiscono l'interfaccia tra un attore ed il sistema ○ Le classi catturano una porzione dello stato del sistema e la presentano all'utente in

forma visuale;

● Control package (BCE): ○ Descrive classi i cui oggetti intercettano l'input dell'utente e controllano l'esecuzione di

uno scenario di funzionamento del sistema; ○ Le classi rappresentano azioni ed attività di uno use case;

● Entity package (BCE):

○ Descrive classi i cui oggetti gestiscono l'accesso alle entità fondamentali del sistema ○ Le classi corrispondono alle strutture dati gestite dal sistema;

Gerarchia di package BCE:

63/102

OOA ESERCIZI:

Sistema SW per Online Shopping: Requisiti utente ● Il sistema software deve supportare l’azienda X che vende computer online. ● I clienti che accedono al sistema possono scegliere di acquistare un computer in

configurazione standard o costruire una specifica configurazione selezionando i singoli elementi (ad es.: processore, disco, RAM, etc.).

● Per effettuare l’ordine, il cliente deve fornire le informazioni necessarie per la spedizione e per il pagamento.

● Il cliente può usare il sistema per verificare online lo stato dell’ordine. ● Il computer nella configurazione scelta viene inviato al cliente assieme alla relativa fattura (se

richiesta).

ESERCIZIO: Sviluppare la specifica secondo OOA: 1. Si produca inizialmente il modello dei dati costruendo un class diagram in cui le operazioni di

ciascuna classe possono essere omesse. Per ciascuna associazione devono invece essere specificate le molteplicità, mentre i nomi di ruolo possono essere omessi.

2. Successivamente, si produca una porzione di modello comportamentale identificando attori e casi d’uso e specificando la descrizione di un caso d’uso a scelta, sia in forma testuale che usando un activity diagram.

3. A partire dal caso d’uso identificato, si produca un sequence diagram che mostri una possibile interazione tra gli oggetti del sistema.

4. Infine, a partire dal sequence diagram, si produca un raffinamento del class diagram iniziale, identificando le operazioni ed eventuali classi, associazioni o attributi aggiuntivi.

Class Diagram (1):

64/102

Use Case Diagram (2):

Use Case Acquisto Computer Configurato (Descrizione testuale) (2):

65/102

Use Case Acquisto Computer Configurato (Descrizione flusso con activity diagram) (2):

Sequence Diagram (Visualizza configurazione corrente) (3):

66/102

Raffinamento Class Diagram (4):

Altri esercizi: Ripetere l’esercizio sviluppando i requisiti utente di altri sistemi software (si possono “inventare” ipotizzando di analizzare lo specifico dominio applicativo...) Ad esempio:

● Gestione filiali di una banca ● Gestione contratti di una compagnia di assicurazione ● Gestione scommesse sportive ● Gestione corsi universitari ● Gestione posta elettronica ● Etc.

67/102

Capitolo 07 - Pianificazione

Gestione di progetti software (Software Project Management): Lo sviluppo di un prodotto software e un’operazione complessa che richiede una specifica attività di gestione. La gestione di un progetto software implica la pianificazione, il monitoraggio ed il controllo di persone, processi ed eventi durante lo sviluppo del prodotto. Il Software Project Management Plan (SPMP) è il documento che guida la gestione di un progetto software.

Le 4P: La gestione efficace di un progetto software si fonda sulle "quattro P":

1. PERSONE, che rappresentano l'elemento più importante di un progetto software di successo (il SEI ha elaborato il People Management - Capability Maturity Model);

2. PRODOTTO, che identifica le caratteristiche del software che deve essere sviluppato (obiettivi, dati, funzioni, comportamenti principali, alternative, vincoli);

3. PROCESSO, che definisce il quadro di riferimento entro cui si stabilisce il piano complessivo di sviluppo del prodotto software;

4. PROGETTO, che definisce l'insieme delle attività da svolgere, identificando persone, compiti, tempi e costi;

Organizzazione dei Team:

1. Problema: sviluppare un prodotto software in 3 mesi con un impegno pianificato di 1 anno/uomo

2. Soluzione immediata: 4 sviluppatori che si suddividono il lavoro; 3. Realtà: i 4 sviluppatori potrebbero impiegare un anno ottenendo un prodotto di qualità

inferiore a quello risultante dal lavoro di un singolo sviluppatore; 4. Motivi:

○ Alcuni compiti non possono essere condivisi; ○ Necessita di frequenti interazioni;

L'aggiunta di uno sviluppatore potrebbe ritardare ulteriormente il progetto, a causa del periodo di formazione e dell'aumento delle interazioni (legge di Brooks, 1975).

Importanza del Software Project Management: Percentuale di progetti on-time, ritardati o cancellati del tutto a causa di costi/ritardi eccessivi o scarsa qualità Statistica elaborata su progetti USA dal 1984 al 2016:

68/102

Pianificazione di progetti software ● Obiettivo: definire un quadro di riferimento per controllare, determinare l'avanzamento ed

osservare lo sviluppo di un progetto software ● Motivazione: essere in grado di sviluppare prodotti software nei tempi e costi stabiliti, con le

desiderate caratteristiche di qualità ● Componenti fondamentali:

● Scoping (raggio d'azione): comprendere il problema ed il lavoro che deve essere svolto;

● Stime: prevedere tempi, costi e effort; ● Rischi: definire le modalità per l'analisi e la gestione dei rischi; ● Schedule: allocare le risorse disponibili e stabilire i punti di controllo nell'arco temporale

del progetto; ● Strategia di controllo: stabilire un quadro di riferimento per il controllo di qualità e per il

controllo dei cambiamenti; Stime nei progetti software: Le attività di stima di tempi, costi ed effort nei progetti software sono effettuate con gli obiettivi di:

● Ridurre al minimo il grado di incertezza ● Limitare i rischi comportati da una stima

Risulta quindi necessario usare tecniche per incrementare l'affidabilità e l’accuratezza di una stima. Le tecniche di stima possono basarsi su:

● Stime su progetti simili già completati (expert judgement by analogy); ● "Tecniche di scomposizione" (approccio bottom-up); ● Modelli algoritmici empirici;

Le tecniche di scomposizione utilizzano una strategia "divide et impera" e sono basate su:

● Stime dimensionali, ad es. LOC (Lines Of Code) o FP (Function Point); ● Suddivisione dei task e/o delle funzioni con relativa stima di allocazione dell'effort;

I modelli algoritmici empirici si basano su dati storici e su relazioni del tipo: d = f(vi)

Dove: - d è il valore da stimare (es. effort, costo, durata) - vi sono le variabili indipendenti (es. LOC o FP stimati)

Esempio di stima di LOC:

69/102

Function Point (FP): Function Point è una misura ponderata di funzionalità software proposta da Albrecht (1979~1983) e misura la quantità di funzionalità in un sistema basato sul sistema specifica (stima prima dell'implementazione). FP viene calcolato in due passaggi:

1. Calcolo di un Unadjusted Function point Count (UFC). 2. Moltiplicare l’UFC per Technical Complexity Factor (TCF).

L’FP finale risulta essere: FP = UFC x TCF

FP components:

FP count - categorie di dati: Conta per categorie di dati:

● Numero di file logici interni (Internal Logical Files ILF): un gruppo di dati o informazioni di controllo generate, utilizzato o gestito dal sistema software.

● Numero di file di interfaccia esterna (External Interface Files EIF): un gruppo di dati o informazioni di controllo passati o condivisi tra le applicazioni, ovvero interfacce leggibili meccanicamente ad altri sistemi e / o all'utente.

***Il termine "file" non significa file nel tradizionale senso di elaborazione dei dati. Se si riferisce a un gruppo di dati logicamente correlati e non non all’implementazione fisica di tali gruppi di dati.

FP count - categorie di transazione: Conta per categorie di transazioni:

● Numero di ingressi esterni (External Inputs EI). Quelle voci fornite dall'utente che descrivono dati distinti orientati all'applicazione, informazioni di controllo (come nomi di file e selezioni di menu) o output di altri sistemi che accedono a un'applicazione e cambiano lo stato dei suoi file logici interni.

● Numero di uscite esterne (External Outputs EO). Tutti i dati univoci o le informazioni di controllo prodotte da sistemi software, ad esempio report e messaggi.

● Numero di richieste esterne (External Inquiries EQ). Tutte le combinazioni di input / output uniche, in cui un input causa e genera un output immediato senza modifica di qualsiasi stato dei file logici interni.

70/102

Esempio - Spell Checker:

Esempio - FP Components: ● EI = 2 (external inputs): document filename, personal dictionary-name ● EO = 3 (external outputs): misspelled word report, number-of-words-processed

message, number-of-errors-so-far message ● EQ = 2 (external inquiries): words processed, errors so far ● EIF = 2 (external interface files): document file, personal dictionary ● ILF = 1 (internal logical files): dictionary

Esempio - UFC Assumi pesi di complessità media per ciascun elemento UFC = 55

71/102

Fattori di degree of influence: 1. Reliable back-up and recovery 2. Data communications 3. Distributed data processing 4. Performance 5. Heavily used configuration 6. Online data entry 7. Operational ease 8. Online update 9. Complex interface 10. Complex processing 11. Reusability 12. Installation ease 13. Multiple sites 14. Facilitate change

TCF (Technical Complexity Factor): Ad ogni fattore viene associato un valore intero compreso tra 0 (influenza irrilevante) e 5 (influenza essenziale), dove:

● 0 Non presente o nessuna influenza ● 1 Influenza accidentale ● 2 Influenza moderata ● 3 Influenza media ● 4 Influenza notevole ● 5 Forte influenza dappertutto

Il TFC può quindi essere calcolato come:

Il TCF varia da 0,65 (se tutti i Fj sono impostati su 0) a 1,35 (se tutti i Fj sono impostati su 5) → ± 35% di regolazione

Esempio TCF e FP: Supporre che:

→ TCF = 0.65 + 0.01(18+10) = 0.93 e FP = 55 ´ 0.93 ≈ 51

FP vs LOC: Numerosi studi hanno tentato di mettere in relazione le metriche LOC e FP (Jones 'backfiring, 1996). Il numero medio di istruzioni del codice sorgente per punto funzione è stato derivato da casi studio per numerosi linguaggi di programmazione. I linguaggi sono stati classificati in diversi livelli in base al rapporto tra LOC e FP.

72/102

Es. di modello algoritmico: COCOMO:

COCOMO (COnstructive COst MOdel) è il modello introdotto da Boehm (1981) per determinare il valore dell'effort. Il valore ottenuto per l'effort viene successivamente utilizzato per determinare durata e costi di sviluppo COCOMO comprende 3 modelli:

● Basic (per stime iniziali) ● Intermediate (usato dopo aver suddiviso il sistema in sottosistemi) ● Advanced (usato dopo aver suddiviso in moduli ciascun sottosistema)

La stima dell'effort viene effettuata a partire da:

● Stima delle dimensioni del progetto in KLOC ● Stima del modo di sviluppo del prodotto, che misura il livello intrinseco di difficoltà nello

sviluppo, tra: ○ organic (per prodotti di piccole dimensioni); ○ semidetached (per prodotti di dimensioni intermedie); ○ embedded (per prodotti complessi);

Nel 1995 è stato introdotto COCOMO II, più flessibile e sofisticato rispetto alla versione precedente.

Esempio d'uso di COCOMO (Modello intermediate, modo organic) Passo 1: determinare l'effort nominale usando la formula:

Effort nominale = 3.2 × (KLOC)^(1.05) MM Esempio: 3.2 × (33)1.05 = 126 MM

Passo 2: ottenere la stima dell'effort applicando un fattore moltiplicativo C basato su 15 cost drivers:

Effort E = Effort nominale × C Esempio: 126 × 1.15 = 145 MM

C (cost driver multiplier) si ottiene come produttoria dei cost driver Ci. Ogni Ci determina la complessità del fattore i che influenza il progetto e può assumere uno tra più valori assegnati con variazioni intorno al valore unitario (valore nominale).

Tabella di cost driver (Intermediate COCOMO):

73/102

COCOMO Time Schedule: Stima del tempo T alla consegna (product delivery):

● Modo organic T = 2.5 E^(0.38) (months M) ● Modo semi-detached T = 2.5 E^(0.35) ● Modo embedded T = 2.5 E^(0.32)

Stima dei costi di sviluppo: I costi di sviluppo (C) sono stimati allocando lo sforzo di sviluppo (E) su fasi e attività del personale, ad esempio:

● 16% di progettazione preliminare: ○ 50% project manager ○ 50% analista

● Progettazione, codifica e test dettagliati al 62%: ○ 75% programmatore / analista ○ 25% programmatore

● Integrazione del 22%: ○ 30% analista ○ 70% programmatore / analista

Il costo per persona al mese di ciascuna categoria di personale (ad es. Project manager, analista, programmatore, ecc.) viene quindi utilizzato per ottenere costi di sviluppo.

Pianificazione temporale: Dopo aver scelto il modello di processo, identificato i task da eseguire e stimato durata, costi ed effort, è necessario effettuare la pianificazione temporale ed il controllo dei progetti La pianificazione temporale consiste nel definire una "rete di task" in base ai seguenti principi fondamentali:

● Ripartizione: scomposizione di processo e prodotto in parti (task e funzioni) di dimensioni ragionevoli;

● Interdipendenza: identificazione delle dipendenze reciproche tra i task individuati; ● Allocazione di risorse: determinazione di numero di persone, effort e date di inizio/fine da

assegnare ad ogni task; ● Responsabilità definite: individuazione delle responsabilità assegnate a ciascun task ● Risultati previsti: definizione dei risultati prodotti al termine di ogni task; ● Punti di controllo (milestone): identificazione dei punti di controllo della qualità da associare al

singolo task o a gruppi di task;

Strumenti di pianificazione: 1. Diagramma PERT (Program Evaluation and Review Technique):

● Grafo in cui ogni nodo rappresenta un task ed ogni arco un legame di precedenza ● Consente di determinare:

○ Il cammino critico (sequenza di task che determina la durata minima di un progetto)

○ La stima del tempo di completamento di ciascun task, mediante applicazione di modelli statistici

○ I limiti temporali di inizio e termine di ciascun task

2. Carta di Gantt: ● Diagramma a barre che consente di visualizzare l'allocazione temporale dei task ● Non appare nessuna indicazione dei legami di precedenza, quindi viene integrata

con un diagramma PERT

Software Project Management Plan (SPMP):

74/102

Contenuti SPMP: Title page Signature page Change history Preface Table of contents List of figures List of tables

1. Overview 1.1 Project summary 1.1.1 Purpose, scope and objectives 1.1.2 Assumptions and constraints 1.1.3 Project deliverables 1.1.4 Schedule and budget summary 1.2 Evolution of the plan

2. References 3. Definitions 4. Project organization

4.1 External interfaces 4.2 Internal structure 4.3 Roles and responsibilities

5. Managerial process plans 5.1 Start-up plan 5.1.1 Estimation plan 5.1.2 Staffing plan 5.1.3 Resource acquisition plan 5.1.4 Project staff training plan 5.2 Work plan 5.2.1 Work activities 5.2.2 Schedule allocation 5.2.3 Resource allocation 5.2.4 Budget allocations 5.3 Control plan 5.3.1 Requirements control plan 5.3.2 Schedule control plan 5.3.3 Budget control plan 5.3.4 Quality control plan 5.3.5 Reporting plan 5.3.6 Metrics collection plan 5.4 Risk management plan 5.5 Closeout plan

6. Technical process plans 6.1 Process model 6.2 Methods, tools and techniques 6.3 Infrastructure plan 6.4 Product acceptance plan

7. Supporting process plans 7.1 Configuration management plan 7.2 Verification and validation plan 7.3 Documentation plan 7.4 Quality assurance plan 7.5 Reviews and audits 7.6 Problem resolution plan 7.7 Subcontractor management plan 7.8 Process improvement plan

8. Additional plans Annexes, Index

75/102

Business Process Management: Framework and Goals

Background: ● Le imprese forniscono prodotti e servizi ai propri clienti ● Ogni prodotto o servizio è il risultato di diverse attività svolte:

● Manualmente dai dipendenti ● Dipendenti con l'aiuto di sistemi di informazione ● Automaticamente dai sistemi di informazione

● Prodotti e servizi forniti in base agli obiettivi di amministrazione aziendale: ● Aumentare la soddisfazione del cliente ● Ridurre i costi ● Migliorare l'efficienza ● Ridurre i tempi di esecuzione ● Ridurre i tassi di errore

● Per raggiungere gli obiettivi aziendali, le risorse aziendali (dipendenti, sistemi informativi) devono lavorare insieme

Per raggiungere gli obiettivi aziendali dobbiamo: ● Organizzare tali attività ● Comprendere come le attività interagiscono tra loro

La soluzione: Business Processes → Facilitano la collaborazione tra risorse aziendali in modo efficiente ed efficace e possono essere gestiti efficacemente se sono descritti e documentati con modelli di processo

Business Process:

Business Process (BP) ● Una BP è un insieme di attività logicamente correlate che vengono eseguite in modo

coordinato; ● Queste attività svolgono congiuntamente un obiettivo aziendale; ● Una BP è costituita da eventi, attività e punti di decisione; ● Il risultato ha valore per almeno un cliente BP;

Flusso di lavoro o processo aziendale automatizzato

● Un processo automatizzato in tutto o in parte da un software sistema; ● Il sistema software trasferisce informazioni da un partecipante all'altro in base alle

dipendenze temporali e logiche nel modello di processo; Business Process Interactions: Ogni BP è eseguito da una singola organizzazione ma può richiedere qualche tipo di interazione con BP di altre organizzazioni:

Business Process Orchestration ● Le BP eseguite all'interno dell'organizzazione possono essere controllate in modo

centralizzato (simile a un'orchestra con il suo direttore)

Business Process Choreography ● BP che richiede l'interazione con BP di altre organizzazioni ● Sincronizzazione al passaggio del messaggio (simile ai ballerini che devono eseguire

una propria danza secondo una coreografia comune)

76/102

Business Process Key Concepts:

Business Process Management (BPM):

● Una migliore comprensione delle operazioni dell'azienda e dei loro rapporti può essere attuata dalla rappresentazione esplicita dei processi aziendali

● BPM è un approccio incentrato sui processi per migliorare le prestazioni combinando le tecnologie dell'informazione con le metodologie di processo e di governance

● BPM include concetti, metodi, tecniche e strumenti per supportare tutte le fasi del ciclo di vita di BP.

Altre discipline riguardano il miglioramento delle prestazioni organizzative: ● Total Quality Management (TQM):

○ Migliorare e sostenere continuamente la qualità di prodotti e servizi ○ Concentrarsi su prodotti e servizi, non sui processi

● Lean Production: ○ Eliminazione di attività di spreco che non aggiungono valore al cliente ○ Basso utilizzo della tecnologia dell'informazione

● Six Sigma: ○ Riduzione al minimo dei difetti (errori) utilizzando fortemente la misurazione dell'output

(soprattutto in termini di qualità) BPM ottiene l'approccio di miglioramento continuo di TQM, utilizza i principi e le tecniche di Lean e Six Sigma e li combina sfruttando le capacità della tecnologia dell'informazione. Stakeholders: Con il Business Process Management vengono prodotti numerosi artefatti, ognuno dei quali ha portata e livello di astrazione diversi in base agli stakeholders. Gli stakeholders possono essere raggruppati in diversi ruoli:

● Chief Process Officer: ○ Ruolo di gestione di alto livello; ○ Gestisce globalmente i BP dell'impresa;

● Business Engineer:

○ Esperto di domini; ○ Definisce gli obiettivi strategici dei BP;

● Process Designer:

○ Modelli BP che interagiscono con altri stakeholders interessati;

● Process Responsible: ○ È responsabile della gestione per la corretta esecuzione della BP;

● System Architect:

○ Imposta sistemi informativi per attuare BP;

● Developers: ○ Professionisti IT che implementano la BP nei sistemi;

● Process participants and workers:

○ Esegue le attività assegnate nell'istanza BP;

77/102

Business Process and Management: Esistono diversi tipi di processi aziendali in base al livello di gestione coinvolto

Business Process Levels: ● Organizational Business Processes:

○ Processi di alto livello; ○ Definire la funzionalità aziendale senza dettagli tecnici; ○ Generalmente definito in forma testuale con l'uso di tecniche semi formali (diagrammi

semplici);

● Operational Business Processes: ○ Definizione dei modelli BP; ○ Specificazione di attività e relazioni;

● Implemented Business Processes:

○ Comprende informazioni tecniche per attuare la BP su una piattaforma specifica; Business Process Lifecycle: Il ciclo di vita della BP consiste in fasi correlate tra loro secondo un modello di sviluppo a spirale. Ogni fase è composta da diverse attività con dipendenze logiche tra loro. Approcci incrementali ed evolutivi sono anche possibili per implementare il ciclo di vita della BP.

78/102

BP Lifecycle - Process Identification: Il primo passo per il team BPM è l'identificazione dei processi rilevanti e le relazioni tra loro (architettura di processo). Per determinare quale processo è rilevante, è necessario misurare il valore fornito da esso. Le misure delle prestazioni del processo devono essere chiaramente definite:

● Misure relative ai costi ● Misure relative al tempo ● Misure relative alla qualità (tassi di errore)

Process Identification è caratterizzato da due fasi:

1. Denominazione (Designation) 2. Valutazione (Evaluation)

Nessuna di queste fasi include lo sviluppo di modelli di processo dettagliati.

1) Designation Phase: Ottenere una comprensione dei processi dell'organizzazione e delle loro interrelazioni. Il numero di processi identificati nella fase di designazione deve costituire un giusto compromesso:

● Few processes: ogni processo ha un gran numero di operazioni, quindi una riprogettazione del processo potrebbe avere un grande impatto sull'efficacia dell'organizzazione, ma la riprogettazione del processo è più complessa;

● Many processes: l'impatto di una riprogettazione è minore ma è più facile

2) Evaluation Phase: I processi dovrebbero avere la priorità perché non sono ugualmente rilevanti. I processi che potrebbero creare perdite o rischi devono essere analizzati per il consolidamento, la disattivazione o l'eliminazione.

Criteri per valutare le fasi: ● Importance: selezionare i processi che hanno il maggiore impatto sugli

obiettivi strategici dell'azienda; ● Dysfunction: determinare i processi che hanno maggiori difficoltà poiché

questi processi traggono il massimo profitto dalle iniziative BPM; ● Feasibility: BPM dovrebbe concentrarsi su processi idonei da cui è ragionevole

aspettarsi benefici;

Process Architecture: Process architecture è un modello concettuale che mostra i processi e le relazioni tra i processi. Le relazioni tipiche riguardano consumatore-produttore, in particolare:

● L'output di un processo è l'input per un altro processo;

● Process architecture definisce diversi livelli di dettaglio per i rapporti tra produttori e consumatori;

● La sfida più importante è catturare i processi al primo livello;

79/102

Process Architecture Definition: Process Architecture può essere definita considerando due aspetti:

1. Case Type: ● Classificazione dei casi gestiti (cases managed) da un'organizzazione ● Un caso potrebbe essere un prodotto o un servizio fornito da un

organizzazione ai propri clienti 2. Function:

● Decomposizione (decomposition) dell'organizzazione ● Una funzione è qualcosa che fa l'organizzazione (acquisti, produzione,

vendita) Quando vengono identificati Case Type e Function, è possibile comporre una matrice dove un segno nella cella significa che la funzione corrispondente può essere eseguita per il tipo di caso corrispondente. Nella fase finale vengono selezionate le combinazioni di funzioni aziendali e tipi di casi che formano un processo aziendale.

Modeling: La modellazione è un modo per gestire la complessità che consente di:

● Comprendere il comportamento del mondo reale ● Identificare e prevenire problemi

Un modello è una rappresentazione astratta con l'intento di catturare aspetti specifici rispettando le seguenti proprietà:

● Mapping: il modello riflette gli aspetti chiave del mondo reale; ● Abstraction: il modello riprende solo gli aspetti rilevanti per il modello, astraendosi da quelli

irrilevanti; ● Purpose: il modello dipende dal pubblico di destinazione e vengono identificati due scopi

principali per la modellazione del processo;

BP Lifecycle - Process Modeling: La modellazione del processo (o scoperta del processo o progettazione del processo) mira a comprendere in dettaglio il processo aziendale. I risultati della modellazione dei processi sono uno o più così come i modelli di processo che documentano lo stato corrente di ogni processo rilevante. I modelli sono spesso diagrammi (diagrammi di flusso) per ridurre ambiguità del testo in formato libero:

● Il diagramma dovrebbe utilizzare una notazione comprensibile a tutti le parti interessate; ● È consentita una descrizione testuale complementare;

Process Modeling può essere eseguito in 4 fasi:

1. Setting Team: riunire una squadra per lavorare al processo 2. Gathering information: creare una comprensione del processo; 3. Modeling: dar luogo al modello del processo 4. Assuring quality: garantire che il modello soddisfi i criteri di qualità

Setting Team Process Modeling Roles: In generale, nel processo modellismo sono coinvolte due funzioni:

1. Process analysts: ● Hanno familiarità con i linguaggi di modellazione e i diagrammi ● Hanno una comprensione limitata del processo da “modellare” ● Dipendono dalle informazioni fornite dagli esperti del dominio

2. Domain experts: ● Hanno una conoscenza approfondita di come viene eseguito un processo ● Possono essere un partecipante al processo, un proprietario del processo o un

manager

80/102

● Non hanno familiarità con i linguaggi di modellazione → Process analysts e Domain experts hanno ruoli complementari

Gathering Information: È possibile identificare tre metodi di tecniche di ricerca per raccogliere informazioni:

1. Evidence based: analisi del documento, osservazione o scoperta automatica del processo

2. Interview based 3. Workshop based

I metodi differiscono l'uno dall'altro in termini di obiettività, ricchezza, consumo di tempo e immediatezza del feedback.

Modeling Method: Un processo può essere modellato seguendo 5 fasi:

1. Identify the process boundaries: definire l'ambito del processo identificando gli eventi che lo attivano e i possibili risultati del processo;

2. Identify activities and events: definire, senza considerare l’ordine, le attività principali e gli eventi intermedi;

3. Identify resources and their handovers: definire chi è responsabile delle attività; 4. Identify the control flow: definire quando e perché vengono eseguite attività ed

eventi, l'ordine, i punti decisionali, le ripetizioni; 5. Identify additional elements: estendere il modello con artefatti (documenti, dati di

input, dati di output, database) e gestori di eccezioni;

Business Process Modeling and MOF (Meta-Object Facility):

Nella modellazione, la complessità dei casi può essere gestita utilizzando diversi livelli di astrazione:

● Al livello inferiore c'è l'istanza/caso; ● Ai livelli superiori, i concetti sono sempre più astratti;

Una delle strutture di astrazione gerarchica più utilizzate è Model Object Facility (MOF) standard fornito da Object Management Group (OMG).

81/102

MOF overview: MOF si articola in 4 livelli:

Un metamodello è composto da entità e connessioni

Una sequenza è una relazione temporale tra due attività

Il processo è la sequenza dell'attività A e quindi dell'attività B

Processo aziendale reale

MOF hierarchy:

MOF and BPMN: Utilizzando lo stesso metamodello M3 (MOF), è possibile definire diversi metamodelli M2. Secondo MOF, OMG ha definito il metamodello M2 di Business Process Model and Notation (BPMN). BPMN utilizza una notazione grafica per progettare e documentare i processi aziendali.

BP Lifecycle - Process Analysis

● Individuare e analizzare le problematiche dei processi ● Comprendere le principali cause di esiti negativi, consente di identificare il modo

migliore per affrontare il problema ● L'output dell'analisi è una raccolta strutturata di file problemi ● Il problema dovrebbe essere quantificato utilizzando misurazioni delle prestazioni

Performance Measures: Generalmente le prestazioni del processo vengono misurate considerando 3 aspetti:

1. Tempo 2. Costo 3. Qualità

Ogni aspetto delle prestazioni può essere raffinato in diverse misure delle prestazioni del processo (Key Performance): indicatore KPI. KPI è la quantità che può essere calcolata in modo univoco a partire dalle informazioni di processo.

82/102

TEMPO - Time Measure: Il tempo è la misura delle prestazioni utilizzata più frequentemente. Il tempo di prestazione del processo può essere misurato in termini di:

- Cycle time or throughput time: tempo impiegato per gestire un caso dall'inizio alla fine o per la riprogettazione del processo;

- Processing time or service time: tempo impiegato dalle risorse (ad es. Partecipanti al processo o applicazioni software utilizzate dal processo) per la gestione del caso;

- Waiting time: Tempo trascorso in modalità inattiva, può includere il tempo di attesa (attesa della risorsa), l'attesa della sincronizzazione, l'attesa dell'input di un altro partecipante;

COSTO - Cost Measure: Può essere scomposto in:

● Costi Fissi: costi che non sono influenzati dall'intensità di lavorazione (Per esempio. uso dell'infrastruttura o manutenzione delle informazioni sistemi).

● Costi Variabili: costi correlati con una quantità variabile (Per esempio. livello di vendita, numero di beni acquistati, numero di nuovi assunti).

QUALITA’ - Quality Measure: La qualità può essere vista dal punto di vista del cliente e del partecipante, può quindi essere scomposta in:

● External quality: la soddisfazione del cliente in merito al prodotto o al processo; soddisfazione del prodotto in termini di specifiche o aspettative realizzazione; soddisfazione del processo in termini di come viene eseguito.

● Internal quality: qualità correlata al punto di vista del partecipante; livello di controllo in un'attività, quantità di variazioni nel processo.

Performance Measure Techniques ● Flow analysis: permette di stimare la performance complessiva di un processo dato lo

svolgimento delle sue attività ● Queuing theory: tecniche matematiche per analizzare i sistemi con “conflitti” di risorse ● Simulation: la simulazione esegue diverse istanze virtuali di un processo registrando

informazioni su ciascuna fase dell'esecuzione; produce statistiche relative a tempi di ciclo, tempi di attesa medi e utilizzo medio delle risorse

BP Lifecycle - Process Redesign: Individuazione e analisi delle misure correttiva per i problemi:

● Sono possibili più opzioni per risolvere un problema; ● I possibili rimedi vengono confrontati in termini di misurazioni delle prestazioni scelte;

Una volta compresi i problemi e identificati i potenziali rimedi, viene proposta una versione ridisegnata (to-be) del processo:

● Il processo to be è l'output principale della fase di riprogettazione del processo; ● Analisi e riprogettazione sono strettamente correlate (per ogni opzione di modifica in fase di

riprogettazione, è necessario eseguire l'analisi);

Process Redesign Challenge: Cambiare un processo non è facile:

● I lavoratori cambiano con difficoltà perché sono abituati a lavorare in un certo modo; ● Le modifiche potrebbero richiedere la modifica dei sistemi di informazione con costi

associati; ● I cambiamenti potrebbero interessare anche altre organizzazioni oltre a quella che

coordina il processo;

83/102

BP Lifecycle - Process Implementation: Nell'implementazione del processo vengono eseguite le modifiche necessarie per passare dal processo così com'è al processo come dovrebbe essere. L'implementazione del processo comporta 2 aspetti:

1. Organizational change management: Insieme di attività necessarie per cambiare il modo di lavorare dei partecipanti al processo;

2. Process automation: Sviluppo e implementazione di sistemi IT per l'esecuzione del processo to be;

1) Organizational Change Management: ● Spiegare le modifiche ai partecipanti al processo: è necessario spiegare quali

modifiche vengono introdotte e quali sono i vantaggi; ● Definire un piano di gestione del cambiamento: quando le modifiche avranno effetto

e come gestire la transizione; ● Formazione: insegnare il nuovo modo di lavorare e monitorare i cambiamenti;

BP Lifecycle - Process Monitoring: Monitoraggio e analisi dei dati rilevanti raccolti sul processo per identificare eventuali aggiustamenti:

● Stato del processo aziendale ● Eccezioni ● Tempi di esecuzione ● Utilizzo delle risorse

La gestione di un processo è uno sforzo continuo. Potrebbero essere necessari aggiustamenti per soddisfare le aspettative dei processi aziendali in termini di misure delle prestazioni e obiettivi di prestazione:

● Rilevamento di errori ricorrenti o deviazioni dal comportamento previsto; ● Individuazione dei rimedi;

84/102

Business Process Management: Technologies Architectures

Business Process Management System (BPMS): - Coordina un processo aziendale automatizzato per garantire che tutto il lavoro sia svolto al

momento giusto dalla risorsa giusta; - Per coordinare il processo, utilizza una descrizione esplicita del processo aziendale (modello di

processo); - Un BPMS può essere adattato a processi specifici di qualsiasi tipo;

BPMS Architecture: 1. Execution Engine:

● Crea istanze di processo eseguibili (chiamate anche casi)

● Distribuisce il lavoro ai partecipanti di processo al fine di eseguire un processo di business, dall'inizio alla fine

● Recupera e archivia automaticamente i dati per l'esecuzione del processo

● Delega attività ad applicazioni software all'interno dell'organizzazione

● Monitora lo stato di avanzamento di casi diversi

2. Process Modeling Tool: ● Consente agli utenti di creare e

modificare modelli di processo ● Consente di annotare i modelli di

processo con dati aggiuntivi (input e output di dati, partecipanti, misurazioni delle prestazioni)

● Memorizza, condivide e recupera i modelli di processo da un archivio di modelli di processo

● Può distribuire un modello di processo al motore per eseguirlo

3. Worklist Handler: ● Utilizzato per affidare gli elementi

di lavoro ai partecipanti ● Gestisce un elenco di elementi di

lavoro disponibili prodotti dal motore di esecuzione

● Quando un elemento di lavoro viene selezionato dalla lista di lavoro e avviato dal partecipante, sullo schermo viene visualizzato un modulo elettronico (check out)

● Quando il partecipante completa l'oggetto di lavoro, un segnale di completamento viene inviato al motore di esecuzione (check in)

4. External Services: ● Quando un'attività del processo

può essere eseguita in modo completamente automatico, il motore di esecuzione può semplicemente chiamare un'applicazione esterna (servizio esterno) per farlo

85/102

● L'applicazione esterna deve esporre un'interfaccia di servizio con cui il motore può interagire

● Una volta completato, il servizio restituirà il risultato al motore;

5. Administration and Monitoring Tools: ● Gli strumenti di amministrazione

vengono generalmente utilizzati in situazioni eccezionali, ad esempio per rimuovere elementi di lavoro obsoleti dal sistema

● Gli strumenti di monitoraggio possono essere utilizzati per ispezionare le prestazioni di un processo aziendale in esecuzione

● Gli strumenti di monitoraggio possono anche aggregare i dati di casi diversi

● BPMS registra l'esecuzione di un modello di processo passo dopo passo e i record possono essere esportati come registri di esecuzione;

Types of BPMS: La classificazione del BPMS porta a identificare 4 tipologie:

1. Groupware systems: consente agli utenti di condividere documenti e informazioni e di comunicare direttamente con altri utenti;

2. Ad hoc workflow systems: consente definizioni di processo al volo, incluso l'adattamento del processo durante la sua esecuzione per includere passaggi aggiuntivi;

3. Production workflow systems: lavoro indirizzato

sulla base del modello di processo, generalmente non offre dati (documenti, management);

4. Case handling systems: non richiede una

specifica completa del modello di processo, utilizza modelli di processo impliciti con un flusso convenzionale.

Advantages of BPMS: BPMS offre i seguenti vantaggi:

1. Riduzione del carico di lavoro (Workload reduction): ● BPMS automatizza parte del lavoro svolto dalle persone che automatizzando la

spedizione degli elementi di lavoro ● BPMS coordina l'ordine di esecuzione delle attività in base al modello di processo,

segnalando quando l'elemento di lavoro è stato completato ● BPMS raccoglie tutte le informazioni rilevanti necessarie per eseguire un'attività

2. Integrazione flessibile del sistema (Flexible system integration): ● BPMS semplifica la gestione della logica dei processi aziendali separando il codice

relativo alla logica aziendale dall'elaborazione dei dati ● Permette di aggiornare la descrizione di un processo aziendale senza dover

ispezionare il codice dell'applicazione 3. Chiarezza dell’esecuzione (Execution transparency):

● BPMS raccoglie tutte le informazioni e tiene traccia di come si svolge il processo, in termini di:

○ Informazioni operative, relative a casi recenti o in corso e rilevanti per la direzione o per i partecipanti al processo aziendale

○ Informazioni storiche, relative a casi completati e importanti per determinare le prestazioni del processo e la conformità alle regole aziendali

4. Applicazione delle regole (Rule enforcement): ● BPMS garantisce che il processo venga eseguito così come è stato progettato.

86/102

Software Architecture: L'architettura software riguarda l'organizzazione di elementi software e risorse di un sistema software. Gli elementi e le risorse del software sono rappresentati come sottosistemi con responsabilità e interazioni con altri sottosistemi. Questa:

● Descrive il comportamento esterno dei sottosistemi; ● Non descrive la struttura interna dei sottosistemi;

Early Systems Architectures: ● Anni '70: applicazioni sviluppate da zero

○ I programmatori devono codificare tutte le funzionalità di base e ricodificarle in tutte le applicazioni;

○ Le applicazioni implementano le funzionalità utilizzando le interfacce del sistema operativo;

● Anni '80: introduzione di interfacce di programmazione per la gestione dei dati

○ Inizialmente, le strutture di dati sono memorizzate come struttura di dati dell'applicazione;

○ I Database Management Systems (DBMS) forniscono funzionalità per consentire l'indipendenza dei dati;

● Anni '90: introduzione di interfacce utente grafiche (GUI) per facilitare l'interazione umana ○ I dipendenti sono diventati “lavoratori della conoscenza”;

Enterprise Applications: Le prime soluzioni (le prime fasi dell'elaborazione aziendale) erano basate sul sistema centrale che ospitava applicazioni monolitiche. Negli anni successivi furono sviluppati più sistemi applicativi, tipicamente uno per ciascuna funzionalità:

● Human resources management (HRM); ● Purchase order management (POM); ● Production planning (PP);

Il problema con quelle applicazioni orientate alla funzionalità era che ospitano related data

● Ad esempio lo stesso indirizzo cliente è stato memorizzato in diversi data store gestiti da diverse applicazioni.

● I cambiamenti sono stati difficili da implementare a causa di molteplici dipendenze di dati tra i sistemi.

87/102

Applications Integration: La maggior parte dei sistemi applicativi sono sviluppati indipendentemente l'uno dall'altro;

● Ogni applicazione memorizza i propri dati localmente; ● Problemi di eterogeneità dei dati si verificano se un dato logico viene archiviato più volte in

diverse applicazioni; ● Problemi di eterogeneità semantica si verificano se un attributo ha significati diversi tra le

applicazioni;

Tecnologie di integrazione dati sono utilizzate per far fronte a difficoltà sintattiche e semantiche. Point to Point Integration: Collegando direttamente ogni coppia di applicazioni, l'integrazione consiste in N x N interfacce da sviluppare.

● Qualsiasi cambiamento nell'applicazione richiede un adattamento delle interfacce che richiede notevoli risorse.

Centralized Integration: L'integrazione delle applicazioni aziendali può essere centralizzata utilizzando middleware orientato ai messaggi.

● Le applicazioni comunicano inviando e ricevendo messaggi.

Hub and Spoke: Middleware basato su un hub centralizzato con raggi direttamente collegati. Il middleware di integrazione rappresenta l'hub e le applicazioni da integrare sono i raggi.

● Le applicazioni interagiscono tra loro tramite l'hub di integrazione centralizzato ● Ogni applicazione richiede lo sviluppo di un adattatore dedicato all'hub;

88/102

Message Brokers: Utilizzato per realizzare un'integrazione di applicazioni hub e spoke Sistemi software che consentono di definire regole per la comunicazione tra applicazioni:

● Definizione in modo dichiarativo di come avviene la comunicazione tra le applicazioni ● Le modifiche possono essere specificate nell'hub centrale, piuttosto che codificando

nelle applicazioni Trasforma i messaggi per realizzare la mappatura dei dati tra le applicazioni:

● L'eterogeneità dei dati può essere gestita in modo centralizzato

Enterprise Services: Il service oriented computing è una delle principali tendenze. Il fattore chiave dell'orientamento al servizio è acquisire la funzionalità aziendale e fornirla come servizio in modo che i clienti possano utilizzarla. L'elaborazione orientata ai servizi utilizza interfacce ben specificate che si basano su linguaggi di definizione dell'interfaccia comuni.

Services and Service Oriented Architectures (SOA):

“Services are loosely coupled computing tasks communicating over the internet that play a growing part in business to business interactions. [...] We reserve the term service oriented for architectures that focus on how services are described and organized to support their dynamic, automated discovery and use”. (Steve Burbeck)

● I servizi acquisiscono funzionalità con un valore aziendale che li rende pronti per essere

utilizzati; ● I servizi comunicano su Internet; ● Elevata flessibilità attraverso la gestione dei tempi di esecuzione dei servizi;

Service oriented architectures (SOA) sono architetture software che forniscono un ambiente per la descrizione, la ricerca e il collegamento ai servizi software.

Advantages of SOA;

● Le imprese possono utilizzare servizi offerti da terzi e fornire servizi ad altre società che possono fornire servizi;

● Lo sviluppo di nuove applicazioni richiede meno sforzi; ● Le applicazioni esistenti possono essere facilmente adattate alle mutevoli esigenze

(riduzione dei costi di sviluppo e manutenzione);

SOA Roles; Il richiedente del servizio utilizza i servizi offerti dai fornitori di servizi tramite un registro dei servizi. Le interazioni tra i ruoli sono publish, request/reply, and bind:

1. Il fornitore di servizi pubblica le specifiche del servizio in un registro dei servizi 2. Il richiedente del servizio cerca i servizi adeguati nel registro dei servizi 3. Il registro del servizio fornisce al richiedente del servizio informazioni che consentono al

richiedente del servizio di collegarsi e richiamare il servizio 4. Il binding può essere statico (al momento dello sviluppo dell'applicazione) o dinamico

(al momento dell'esecuzione)

89/102

Web Service Realizzazione di elaborazione orientata ai servizi.

“I servizi Web sono applicazioni modulari autonome, auto descrittive che possono essere pubblicate, localizzate e richiamate attraverso il Web. I servizi Web eseguono funzioni, che possono essere qualsiasi cosa, da semplici richieste a complicati processi aziendali. Una volta distribuito un servizio Web, altre applicazioni (e altri servizi Web) possono rilevare e richiamare il servizio distribuito. La messaggistica XML viene utilizzata per interagire con un servizio Web.”

Un servizio Web implementa un'interfaccia che descrive una raccolta di operazioni accessibili tramite una rete utilizzando la messaggistica XML standard.

Web Service Standards: I servizi Web si basano su standard e raccomandazioni del World Wide Web Consortium, W3C:

- SOAP - WSDL - UDDI

SOAP: SOAP definisce un protocollo di messaggistica XML per la comunicazione dei servizi

● Utilizzato per lo scambio di dati strutturati e digitati tra le applicazioni ● È semplice e leggero e non definisce la semantica dell'applicazione

Un'unità di dati SOAP (SOAP message) può essere incorporata in vari protocolli di trasporto ● (HTTP) è il modo più importante per “invocare” un servizio Web, ma sono fattibili anche

i protocolli di posta (SMTP) e altri protocolli di trasporto

SOAP Message Format I messaggi SOAP sono istanze XML che hanno:

● Un elemento superiore obbligatorio denominato Envelope (container per Header e Body Elements);

● Un elemento opzionale chiamato Header (aggiunge ulteriori informazioni al destinatario (header entries));

● Un elemento obbligatorio denominato Body (contiene le informazioni sul messaggio (body entries));

90/102

WSDL: Web Services Description Language or WSDL introduce un formato per specificare i servizi Web e può essere utilizzato per specificare come utilizzare un servizio, ovvero un service contract (contratto di servizio). Questo contratto può essere separato in logical contract e physical contracts:

- Il logical contract definisce un'interfaccia pubblica formale del servizio (operazioni fornite, parametri delle operazioni e loro tipologie);

- Il physical contract viene utilizzato per l'associazione e specifica l'implementazione del servizio (formati dei messaggi, indirizzo di rete, trasporto);

- Possono esserci più physical contract per un servizio, consentendo a un cliente di selezionare quello che meglio soddisfa le sue capacità tecniche;

WSDL Interface Description WSDL è un documento XML con i seguenti elementi:

Element Name Description

Definitions Contenitore per tutti gli altri elementi

PortType Contiene le info supportate dal servizio Web

Operation Descrive in modo astratto una chiamata di servizio (può contenere un messaggio di input, un messaggio di output e opzionalmente messaggi di errore)

Message Descrizione astratta dei dati che vengono inviati ed è composta da unità logiche chiamate parti (part)

Part Ogni parte è associata ad un data type

Types Fornisce un contenitore per le definizioni del tipo di dati

Binding Fornisce specifiche concrete di protocollo e formato dati per un particolare tipo di porta

Port Descrive l'indirizzo di rete di un servizio

Service Collection of related ports

UDDI: Universal Description, Discovery e Integration, o UDDI, fornisce un'infrastruttura per pubblicare informazioni sui servizi e sui relativi provider L'interfaccia di programmazione dell'applicazione UDDI fornisce informazioni di accesso al registro, ad esempio, per registrare un servizio o per cercare servizi o fornitori di servizi appropriati.

91/102

Web Service Sequence: 1. Il fornitore di un servizio Web prepara il file WSDL del servizio

● I richiedenti del servizio accedono alla specifica WSDL utilizzando un registro del servizio

2. Il richiedente del servizio crea un messaggio SOAP, utilizzando le informazioni nel contratto logico della specifica WSDL

● Le informazioni sul physical contract vengono utilizzate per definire la codifica del messaggio e il protocollo di trasporto.

3. Il messaggio viene inviato all'endpoint di servizio specificato nel contratto fisico del WSDL

4. Il fornitore di servizi riceve il messaggio e invoca il software che implementa il servizio

92/102

Service Composition: Service Composition contiene un insieme di servizi, ognuno dei quali realizza un'attività di processo:

● Implementazione di workflows (business automatizzato). I processi sono un fattore chiave per realizzare composite applications. La struttura delle composite applications può essere espressa come un processo aziendale con le attività implementate dai servizi aziendali (process orchestration). I servizi aziendali realizzano le interazioni commerciali di più imprese:

● Questo tipo di interazione realizza un process choreography.

BPEL: Business Process Language for Web Services , WS BPEL, o BPEL, è lo standard nella composizione dei servizi Web. BPEL provides service compositions using a block structuring:

● I collegamenti possono essere utilizzati per definire le strutture di flusso. BPEL può essere utilizzato sia con abstract processes che con concrete processes. In particolare:

● Abstract processes, descrivono il comportamento visibile esternamente di un processo aziendale;

● Concrete processes, contengono tutte le informazioni necessarie per eseguire il servizio web;

BPEL Activities: ● Invoke, richiama un’operazione (con o senza messaggio di risposta) offerta da un

servizio Web; ● Receive, attende che arrivi un messaggio; ● Reply, invia una risposta ad un messaggio ricevuto; ● Wait, attende un periodo di tempo definito; ● Assign, assegna valori di dati alle variabili; ● Throw, utilizzato per la gestione delle eccezioni per indicare che si è verificato un

errore; ● Terminate, completa il processo;

BPEL Relationships: ● Sequence, sequenza ordinata di attività; ● Switch, utilizza un'espressione per selezionare una particolare attività da un insieme di

alternative; ● Pick, attende l'arrivo di un messaggio specifico o un evento di timeout; ● While, continua finché una condizione è vera; ● Flow, esecuzione simultanea di una serie di attività; ● Link, vincolo di esecuzione tra le attività;

Web Service Composition (Esempio): ● Dopo aver ricevuto un ordine di acquisto:

a. Viene calcolato il prezzo iniziale; b. Viene avviata la produzione; c. Il mittente è selezionato;

● Il prezzo finale dipende dal mittente selezionato e viene valutato dopo la selezione di questo ● Una volta selezionato il mittente, è possibile organizzare la logistica e la programmazione della

produzione dipende dall’organizzazione logistica; ● Processo con una sequenza di tre blocchi:

a. Due attività di processo (ricezione ordine di acquisto (Receive Purchase Order) ed elaborazione fattura (Invoice Processing));

b. Un blocco di flusso con sequenze di attività; ● Frecce dirette tra le attività

○ From the Decide on Shipper to the Complete Price Calculation ○ From the Arrange Logistics to the Complete Production Scheduling

93/102

Figura 1

Figura 2

● Il processo dell'ordine di acquisto viene richiamato ricevendo un messaggio di ordine di acquisto.

94/102

Service Task Execution Semantics:

Per le attività di servizio è necessario specificare i dettagli di comunicazione all'applicazione esterna che eseguirà l'attività:

● L'applicazione esterna fornisce un'interfaccia di servizio disponibile per il servizio ● L'interfaccia del servizio contiene una o più operazioni di servizio

Un’operazione può essere:

1. In-out operation (synchronous operation): ● Il servizio attende un messaggio di richiesta ● Il servizio esegue l'operazione ● Il servizio risponde con un messaggio di risposta o un messaggio di errore se qualcosa

va storto 2. In-only operation (asynchronous operation):

● Il servizio attende un messaggio di richiesta ● Il servizio esegue l'operazione ● Non è richiesto un messaggio di risposta

BPMN Service Task Execution:

● BPMN utilizza per impostazione predefinita la tecnologia dei servizi Web con WSDL 2.0 per implementare le interfacce dei servizi;

● È necessario importare nel modello BPMN uno o più documenti WSDL esterni; ● Dopo aver definito le interfacce di servizio, è necessario associare ciascuna attività di servizio a

un'operazione di servizio definita in un'interfaccia di servizio; ● In base al tipo di operazione (solo in out o in) i dati di input e di output facoltativi vengono

selezionati per calcolare il tipo di dati del servizio; ● Il motore BPMS copia l'input dei dati nel messaggio di richiesta e lo invia al servizio e, quando il

messaggio di risposta è arrivato, copia il contenuto della risposta nell'output dei dati;

95/102

Business Process Management: BPM in Open Source, ERP and industrial Platforms

OS workflow ● OS Workflow (OSWf) è un progetto Open Source; ● OSW può essere considerato un flusso di lavoro di "basso livello" di implementazione; ● Situazioni come "loop" e "conditions" che potrebbero essere rappresentate da un'icona

grafica, in altri sistemi di flusso di lavoro sono "codificate" in Osworkflow; ● Non è previsto che un utente non tecnico modifichi il flusso di lavoro; ● Il Wkf è considerato come un insieme di una o più azioni iniziali che fungono da punti di

ingresso nel flusso di lavoro e un insieme di passaggi e azioni che un'istanza di processo occuperà durante l'elaborazione del flusso di lavoro;

JPBM, processes orchestration:

● JBPM è un Business Process Management (BPM) Suite; ● Completamente open-source (distribuito con licenza Apache) e scritto in Java; ● Editor basato su Eclipse e web per supportare la creazione grafica (drag and drop); ● Persistenza collegabile e transazioni basate su JPA / JTA; ● Servizio di attività umane collegabile per includere attività che devono essere eseguite da

attori umani; ● Console di gestione che supporta la gestione delle istanze di processo, gli elenchi di attività, la

gestione dei moduli di attività e il reporting; ● Deposito di processi opzionale per distribuire il processo; ● Registrazione della cronologia (per interrogazioni / monitoraggio / analisi); ● Integrazione con Seam, Spring, OSGi, ecc.;

JPBM Architecture:

96/102

JPBM Editor:

SAP Business One Workflow: ● ERP Product Video Session

97/102

Business Process Management: Esercizi

BIZAGI, BPMN: Modeling a process

Start Event Indica dove inizia un particolare Processo. Non ha alcun “comportamento” particolare

Pool Contiene un singolo Processo (contiene il flusso della sequenza tra le attività). Un Processo è completamente contenuto in un pool, e di pool ce n’è sempre almeno uno

Lane Sottopartizione all’interno del Processo. Sono usate per elementi diversi come ruoli interni, posizioni, dipartimenti. Rappresentano aree funzionali che possono essere responsabili dei compiti

End Event Indica quando il Processo è terminato

Exclusive Gateway As divergence: viene utilizzato per creare percorsi alternativi all'interno del processo, ma solo uno viene scelto As convergence: viene utilizzato per unire percorsi alternativi

98/102

Exercise 01: Control Organization Recruitment

- Il processo inizia quando il Direttore riceve una lettera dall'Organismo di Controllo con la richiesta di informazioni specifiche. L'Amministratore inserisce il requisito nel sistema, assegna un dipendente a rispondere, indica la data di scadenza di questo requisito e specifica il periodo di tempo entro il quale il dipendente dovrebbe rispondere alla richiesta.

- La persona assegnata può vedere il tempo disponibile per presentare la relazione di risposta, esaminare l'intero caso e inserire una risposta alla richiesta.

- Successivamente, il Direttore dovrebbe esaminare la risposta data dall'utente assegnato, apportare eventuali modifiche e decidere se questa è la risposta definitiva da dare all'Organizzazione di controllo. Se la risposta non è definitiva, verrà generata una nuova attività per la persona assegnata. Ovvero, la persona che ha preparato la risposta dovrebbe riesaminare il caso, quindi correggere e completare la risposta.

- Se il Direttore è soddisfatto della risposta, la lettera di risposta viene generata, stampata e inviata all'Organizzazione di controllo.

Rappresentazione risultante:

99/102

Exercise 02: Management Evaluation - Come parte della politica delle risorse umane di un'azienda, ogni dipendente viene

periodicamente valutato per rivedere i propri obiettivi, traguardi, bonus e azioni correttive, se presenti.

- Secondo la politica aziendale, ogni dipendente viene valutato annualmente (per ogni anno di servizio svolto presso l'organizzazione) dal supervisore. Su base settimanale, il dipartimento delle risorse umane esamina quali dipendenti hanno completato un anno di servizio e li registra per la valutazione dei dipendenti. In questa procedura di registrazione, vengono registrati il dipartimento, il supervisore e altre informazioni sul dipendente.

- La valutazione inizia con un'autovalutazione in cui il dipendente valuta gli aspetti delle proprie prestazioni rilevanti per il proprio dipartimento. Questo viene trasmesso al supervisore che valuta gli stessi aspetti delle prestazioni e fornisce un feedback sui punti più deboli del dipendente. Il dipendente riceve il documento di valutazione e le raccomandazioni per il miglioramento.

- Infine, dopo aver terminato il gruppo di valutazioni per quella settimana, il direttore delle risorse umane genera ed esamina un rapporto di valutazione per identificare specifiche prestazioni o problemi comportamentali.

Progettare un diagramma di processo utilizzando lo standard BPMN.

Rappresentazioni risultanti:

100/102

Exercise 03: Strategic Plan - In un'azienda, ogni vicepresidente dovrebbe presentare un piano strategico all'amministratore

delegato che dovrebbe rivedere e consolidare un piano generale. - Per elaborare i piani, ogni vice presidente chiede ai suoi amministratori di fare un piano per

ogni area, indicando le linee guida generali. Una volta che ogni amministratore avrà finito, il vicepresidente esaminerà l’elaborato e, se necessario, lo modificherà.

- Quando tutti i piani degli amministratori saranno approvati, il vicepresidente li consoliderà e invierà un piano al CEO per la sua revisione.

Rappresentazioni risultanti:

101/102

BIBLIOGRAFIA Libro : https://dinus.ac.id/repository/docs/ajar/Sommerville-Software-Engineering-10ed.pdf

102/102

https://dinus.ac.id/repository/docs/ajar/Sommerville-Software-Engineering-10ed.pdf

Colleluori Livio Prof. D'Ambrogio Sistemi Software - Introduzione

Documents

Transcript of Colleluori Livio Prof. D'Ambrogio Sistemi Software - Introduzione