Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Indice
RUP........................................................................................................................................................................... 3
Prospettiva statica: attività del RUP ..................................................................................................................... 3
Prospettiva dinamica: le fasi del RUP ................................................................................................................... 3
Distribuzione delle attività nelle fasi .................................................................................................................... 4
Buone pratiche RUP ............................................................................................................................................. 6
I modelli................................................................................................................................................................ 6
Processo centrato sull’architettura ...................................................................................................................... 8
Approccio guidato dai rischi ................................................................................................................................. 8
Documento di visione del sistema .......................................................................................................................... 10
Studio di fattibilità .................................................................................................................................................. 13
Analisi del contesto ................................................................................................................................................ 14
Use-cases ............................................................................................................................................................... 15
Attori .................................................................................................................................................................. 15
Definire e disegnare gli use-cases ...................................................................................................................... 16
Relazioni tra use-cases ....................................................................................................................................... 16
Use Case Overview Diagrams ............................................................................................................................. 18
Modellare il flusso di lavoro del sistema – Diagramma di attività .......................................................................... 19
Oggetti................................................................................................................................................................ 21
Segnali ................................................................................................................................................................ 21
Partizioni ............................................................................................................................................................ 22
Connettori .......................................................................................................................................................... 22
Regioni di espansione......................................................................................................................................... 22
Analisi nomi-verbi .................................................................................................................................................. 23
Schede CRC............................................................................................................................................................. 25
Classi di analisi – Entity -Control-Boundary Pattern ............................................................................................... 27
Diagramma delle classi (di progetto) ...................................................................................................................... 30
Visibilità .............................................................................................................................................................. 30
Attributi – lo stato della classe ........................................................................................................................... 31
Operazioni – il comportamento della classe ...................................................................................................... 32
Componenti statici di una classe ........................................................................................................................ 32
Relazioni tra classi .............................................................................................................................................. 32
Vincoli................................................................................................................................................................. 34
Classi astratte ..................................................................................................................................................... 34
Interfacce ........................................................................................................................................................... 35
Templates (o classi parametriche o generiche) .................................................................................................. 35
Diagramma dei packages ....................................................................................................................................... 37
Diagramma di sequenza ......................................................................................................................................... 39
Eventi, segnali e messaggi .................................................................................................................................. 39
Frammenti di sequenza ...................................................................................................................................... 40
Esempio .............................................................................................................................................................. 43
Piano dei test ......................................................................................................................................................... 46
Cosa chiedersi per redigere il piano ................................................................................................................... 46
Linee guida ......................................................................................................................................................... 46
Checklist ............................................................................................................................................................. 48
Tipi di test ........................................................................................................................................................... 49
Per approfondire ................................................................................................................................................ 50
Gestione dei rischi e garanzia di qualità ................................................................................................................. 51
Processo di gestione dei rischi............................................................................................................................ 51
Principi di Software Quality Assurance ............................................................................................................... 51
Gestione della configurazione del software (SCM) ............................................................................................. 52
Gestione dei rischi e della qualità ....................................................................................................................... 53
Link utili .............................................................................................................................................................. 53
Schema di Giovanni Ficarra basato sugli argomenti del corso di Ingegneria del software del professor Bottoni,
realizzato usando le sue dispense, i libri Software engineering e Learning UML e risorse online indicate per ogni
paragrafo.
Per contattarmi potete scrivere a giovannificarra95@gmail.com.
RUP
• Caratteristiche:
o Processo guidato dai casi d’uso
o Processo centrato sull’architettura
o Approccio guidato dai rischi
• Nelle prime due fasi si definisce l’ambito del progetto, si eliminano i rischi critici e si crea l’architettura
di base, le iterazioni producono raffinamenti
• Nella terza le iterazioni producono incrementi
• Il progetto è composto da mini-progetti, ognuno realizzato in un’iterazione
• Ogni iterazione prevede flussi di lavoro
Distribuzione delle attività nelle fasi
• Inception:
o Focus:
▪ Requirements: stabilire caso di business e contesto, raccogliere i requisiti principali
▪ Analysis: stabilire la fattibilità
▪ Design: progettare una prova di concetto o prototipi tecnici
▪ Implementation: costruire la prova di concetto o i prototipi tecnici
▪ Test: -
o Obiettivi:
▪ Stabilire la fattibilità del progetto
▪ Creare un caso di business
▪ Definire contesto del sistema e requisiti chiave
▪ Identificare i rischi critici
o Milestone:
▪ Ambito del sistema definito
▪ Requisiti chiave definiti e concordati con gli stakeholder
▪ Visione architetturale schematizzata
▪ Rischi valutati
▪ Caso di business creato
▪ Fattibilità confermata
▪ Stakeholder d’accordo con gli obiettivi del progetto
o Criterio essenziale: adeguatezza
• Elaboration:
o Focus:
▪ Requirements: rifinire il contesto del sistema e i requisiti
▪ Analysis: stabilire cosa costruire
▪ Design: creare una base stabile per l’architettura
▪ Implementation: costruire la base dell’architettura
▪ Test: testare la base dell’architettura
o Obiettivi:
▪ Creare una base dell’architettura eseguibile
▪ Rifinire i rischi e definire gli attributi di qualità
▪ Catturare gli use case dell’80% dei requisiti funzionali
▪ Creare un piano abbastanza dettagliato per la fase di construction
▪ Formulare un’offerta che includa risorse, tempo, strumentazione, staff, costo
o Milestone:
▪ Creata una base resistente, robusta ed eseguibile per l’architettura
▪ Aggiornata la valutazione dei rischi
▪ Creato un piano di progetto che permetta di formulare un’offerta realistica
▪ Verificato il caso di business rispetto al piano
▪ Stakeholder d’accordo su continuare
o Criterio essenziale: realizzabilità
• Construction:
o Focus:
▪ Requirements: scoprire requisiti mancanti
▪ Analysis: finire il modello di analisi
▪ Design: finire il modello di design
▪ Implementation: costruire la Capacità Operativa Iniziale
▪ Test: testare la Capacità Operativa Iniziale
o Obiettivi:
▪ Completare l’identificazione, la descrizione e la realizzazione degli use case
▪ Finire analisi, design, implementazione e test
▪ Mantenere l’integrità dell’architettura del sistema
▪ Revisionare la valutazione dei rischi
o Milestone:
▪ Prodotto pronto per il beta testing nell’ambiente dell’utente
o Criterio essenziale: operazionalità iniziale
• Transition:
o Focus:
▪ Requirements: -
▪ Analysis: -
▪ Design: modificare il design se nel beta testing emergono problemi
▪ Implementation: adattare il software all’ambiente dell’utente e correggere bug scoperti
nel beta testing
▪ Test: eseguire il beta testing e il test di accettazione nell’ambiente dell’utente
o Obiettivi:
▪ Correggere i difetti
▪ Preparare l’ambiente dell’utente per il nuovo software ed adattare il software per
operare in quell’ambiente
▪ Modificare il software se emergono problemi non previsti
▪ Creare manuali utente e altra documentazione
▪ Fornire consulenza al cliente
▪ Condurre revisioni post progetto
o Milestone:
▪ Completati beta testing, test di accettazione e correzione dei difetti
▪ Prodotto rilasciato agli utenti
o Criterio essenziale: operazionalità finale
I modelli
• Modello degli use case:
o Formato da attori e casi d’uso:
▪ Gli attori rappresentano i tipi di utenti, definiscono l’ambiente del sistema
▪ I casi d’uso rappresentano sequenze di azioni effettuate dal sistema per produrre
risultati di valore per un attore, descrivono i comportamenti desiderati
o Rappresenta i requisiti funzionali
o Evoluzione:
▪ Dal modello dei casi d’uso si passa al modello di analisi, e da lì a quello di progetto
▪ Classificatori (dotati di strutture e operazioni, descritti da statechart) e realizzazioni dei
casi d’uso
• Modello di analisi:
o Descrizione dettagliata dei requisiti
o Raffinamento dei casi d’uso con collaborazioni tra classificatori concettuali
o Permette di creare l’architettura
o Ha carattere temporaneo (vale per le prime iterazioni), viene mantenuto solo per grandi sistemi
o Costruzione (eventualmente usando schede CRC):
▪ Ogni use case è integrato tramite analisi nomi-verbi
▪ Le responsabilità egli use case sono date alle classi (le classi hanno responsabilità in
diversi casi d’uso e devono soddisfare ogni ruolo di collaborazione definito)
▪ Ogni use case è realizzato grazie alla collaborazione tra più elementi
• Modello di design:
o Modello gerarchico: esistono relazioni che attraversano la gerarchia
o Si possono tracciare le realizzazioni degli use case nelle realizzazioni del modello di analisi
o Le realizzazioni degli use case diventano stereotipi di collaborazioni
o Riferimento per l’implementazione
o Costruzione:
▪ Classi e realizzazioni use case progettate per sfruttare prodotti e tecnologie utilizzabili
▪ Raggruppamento classi di progetto in sottosistemi e definizione interfacce tra
sottosistemi
• Modello di deployment:
o Definizione dell’organizzazione fisica del Sistema come rete di nodi computazionali
o Verifica dell’implementabilità degli use case tramite componenti eseguiti sui nodi definiti
• Modello di implementazione:
o Costruzione:
▪ Pianificare le integrazioni del sistema per ogni iterazione
▪ Distribuire sistema e componenti eseguibili sui nodi del modello di deployment
▪ Implementare le classi e i sottosistemi di progetto, passando dalle classi al codice
▪ Fare test unitari sui componenti
o Le classi progettate sono implementate come insiemi di file component
o Le classi vengono compilate e collegate per produrre eseguibili
o Si procede in base alle priorità stabilite dagli use case
• Modello di test:
o Costruzione:
▪ Verifica che il Sistema implementi le funzionalità descritte negli use case e soddisfi I
requisiti di sistema
▪ Il modello di test è formato dai casi di test (ingressi, condizioni di esecuzione, risultati)
tracciabili ai casi d’uso
▪ Black box: test definiti dai casi d’uso
▪ White box: test definiti dalle realizzazioni
Esempio: https://www.utdallas.edu/~chung/RE/Presentations10F/Team-hope/1%20-%20VisionDoc.pdf
Studio di fattibilità
• Studio preliminare sulle implicazioni che il sistema avrà una volta costruito e sulla sua convenienza
• Per avere senso dovrebbe essere economico e veloce, per essere poi eventualmente approfondito in
seguito
• Contiene:
o Definizione preliminare del problema
o Possibili scenari che illustrino diverse strategie di soluzione
o Costi temi e modalità di sviluppo delle strategie
• Risponde a domande come:
o Il sistema contribuisce al raggiungimento degli obiettivi del destinatario a cui è rivolto? Qual è il
suo impatto?
o Quali sono i problemi con i processi attuali e come il sistema potrà risolverli?
o Può il sistema essere implementato con le tecnologie correnti (quali?) e con costi e tempi
"prevedibili" e accettabili?
o Quali abilità richiede la realizzazione del sistema?
o Può il sistema essere integrato con sistemi pre-esistenti?
o Le informazioni possono essere trasferite verso o da altre organizzazioni?
o Quali attività il sistema dovrà supportare e cosa potrà essere lasciato fuori?
• Considerati tali fattori, si conclude con una raccomandazione sul continuare o meno lo sviluppo del
sistema, in base a:
o Alternative possibili
o Risorse di denaro, tempo e abilità necessarie per l’attuazione del progetto
Analisi del contesto
• Si usa un diagramma del contesto del sistema per rappresentare i confini tra il sistema e il suo ambiente,
mostrando le entità che interagiscono col sistema stesso
• Il diagramma è una vista ad alto livello del sistema
• Vengono rappresentati input e output del sistema
• Non viene rappresentata la struttura interna del sistema
• Al centro vi è il sistema, circondato da ambienti, attività e altri sistemi che ci interagiscono
• Lo scopo è mettere l’attenzione su fattori esterni determinanti per lo sviluppo di requisiti e vincoli del
sistema
• Viene realizzato all’inizio per concordare sul campo su cui si sta lavorando, e dev’essere scritto in
linguaggio naturale per essere compreso anche dagli stakeholders
• Si usa un diagramma a building blocks, le cui componenti sono:
o Entità/attori: scatole etichettate, una al centro per il sistema e le altre intorno per gli attori
esterni
o Relazioni: linee etichettate tra il sistema e gli altri attori
• Gli alberi decisionali e la memorizzazione dei dati sono rappresentati negli schemi di flusso del sistema
• Gli attori esterni possono anche essere divisi in categorie:
o Attivi: attori dinamici che mirano al raggiungimento di obiettivi
o Passivi: attori statici che interagiscono raramente col sistema
o Cooperativi: attori utilizzati dal sistema per ottenere i risultati desiderati
o Autonomi/indipendenti: attori che influenzano indirettamente il sistema, ad esempio
imponendo vincoli
Da: https://en.wikipedia.org/wiki/System_context_diagram
Use-cases
• Rappresentano una situazione in cui il sistema è usato per soddisfare uno o più requisiti dell’utente
• Catturano una parte di funzionalità che il sistema fornisce
• Descrivono i requisiti di sistema dall’esterno
• Specificano solo ciò che il sistema dovrebbe fare: i requisiti funzionali
• Vi si possono assegnare priorità e rischi
o Per derivarne il carico di lavoro necessario per il sistema
o Per stabilire quali scartare o rimandare se sorgono problemi
• Rappresentano un valore tangibile per l’utente, quindi possono essere usati per tracciare il progresso
del progetto
• Aiutano a costruire situazioni e procedure per i test del sistema
• Si possono distinguere requisiti “shall” e “should”:
o I primi devono essere soddisfatti
o I secondi non sono critici ma desiderabili, se ci sono ritardi vengono sacrificati per primi
• Possono essere semplici o complessi
• Dalla prospettiva dell’utente rappresentano un uso completo del sistema, che comprende interazioni col
sistema ed output dal sistema
Attori
• Entità esterne al sistema che interagiscono col sistema
• Sono rappresentati con uno stick-man o una “stereotyped box”, con un’etichetta col nome (che deve
essere chiaro per i clienti e per i
designer del sistema)
• Possono essere persone o sistemi di
terze parti
• Sono scatole nere: non interessa
come funzionano e non possono
essere modificati
• Tra attori possono esistere particolari
relazioni, come quella di
generalizzazione: A generalizza B se
può fare tutto ciò che può fare B e
qualcosa in più
• Tricky actors:
o Il clock di sistema interagisce
col sistema invocandone
alcuni comportamenti, non è
influenzato dal design del
sistema, aiuta a mostrare che
il sistema svolge operazioni
in base al momento corrente
o Oltre agli utenti, come attori possono essere presenti figure professionali che si occupano di
installazione, revisione, manutenzione, aggiornamento… che possono avere diritti di veto, o
possono dover applicare requisiti non funzionali importanti, e se questi attori vengono
tralasciati tali aspetti del sistema non saranno documentati
Oggetti
• A volte degli oggetti sono importanti per il processo che si sta modellando
• Nel diagramma di attività si possono usare nodi oggetto per mostrare i dati che scorrono attraverso
un’attività, raffigurandoli come rettangoli
• Un nodo oggetto rappresenta un oggetto disponibile in un particolare punto nell’attività, si può usare
per mostrare che l’oggetto è usato, creato o modificato dalle azioni circostanti
• Si possono usare input pin o output pin per indicare un oggetto che va in input a un’azione o che è
l’output di un’azione, rispettivamente, disegnando un quadratino a sinistra dell’azione nel primo caso e
a destra nel secondo, al posto dell’oggetto, con sopra l’etichetta dell’oggetto
• Si può mostrare come viene ottenuto un oggetto specificando la trasformazione in una nota
• Si può mostrare il cambiamento di stato di un oggetto che passa attraverso un’attività scrivendo lo stato
tra parentesi quadre nel rettangolo del nodo oggetto
• I nodi oggetto possono essere input e output anche per intere attività (oltre che per singole azioni), in tal
caso sono disegnati a cavallo del confine dell’activity frame, e prendono il posto dei nodi iniziale e finale
Segnali
• Le attività possono coinvolgere persone, sistemi o processi esterni
• Nei diagrammi delle attività, i segnali rappresentano le interazioni con i partecipanti esterni
• I segnali sono messaggi che possono essere inviati o ricevuti
• Un segnale ricevuto sveglia un’azione, il ricevente sa come reagire e aspetta che arrivi un segnale ma
non sa esattamente quando
• Un segnale inviato è rivolto a un partecipante esterno, non modellato nel diagramma, che
probabilmente fa qualcosa in risposta al segnale
• Giunto ad un nodo invia segnale il sistema non aspetta una risposta per passare all’azione successiva: i
segnali sono inviati in maniera asincrona
• Giunto ad un nodo ricevi segnale il sistema aspetta che il segnale sia ricevuto per procedere
• Spesso si combinano nodi invia segnale e nodi ricevi segnale, perché bisogna aspettare la risposta a un
segnale che si è inviato, in tal caso l’effetto è quello di una chiamata sincrona, che aspetta una risposta
per procedere
• Un nodo ricevi segnale senza flusso entrante significa che l’attività resta in attesa di ricevere un segnale,
ed è lanciata solo quando questo avviene
Partizioni
• A volte un’attività può coinvolgere diversi partecipanti, le partizioni mostrano quale partecipante è
responsabile di quale azione
• Una partizione divide il diagramma in righe (o colonne), dette swimlanes (“corsie di nuoto”), che
contengono le azioni compiute da un partecipante
• La responsabilità di un’azione può essere mostrata anche usando annotazioni, scrivendo il nome del
partecipante tra parentesi nel nodo
Connettori
• I connettori servono a semplificare diagrammi con molte azioni, collegando due punti con un simbolo
anziché con una linea
• Si rappresentano con un cerchio contenente il suo nome, tipicamente di un solo carattere
• Si usano a coppie: uno con un arco entrante e una con un arco uscente, il secondo riprende da dove il
primo ha interrotto
Regioni di espansione
• Le regioni di espansione mostrano che le azioni in una regione sono eseguite per ogni elemento in una
collezione di input
• Si rappresentano con un grande rettangolo tratteggiato con gli angoli arrotondati e quattro quadratini
allineati su due lati, a rappresentare le collezioni di input e output
Analisi nomi-verbi
• Si analizza tutta la documentazione disponibile selezionando nomi e verbi:
o Nomi: potenziali classi o attributi
o Predicati nominali: potenziali classi o attributi
o Verbi: potenziali responsabilità di classe
• Un’altra possibile classificazione:
o Nomi propri: istanze
o Nomi comuni: classi/tipi/ruoli
o Doing verbs: metodi (verbi “dinamici”, che indicano azioni)
o Being verbs: strutture di classificazione (tipo essere, sembrare, stare)
(che roba sono?!)
o Having verbs: strutture di composizione (verbi che indicano possesso)
(vedi Composite structure diagram)
o Verbi di stato: condizioni di invarianza (tipo piacere, preferire, capire, dubitare, sapere)
o Verbi modali: semantica dei dati, precondizioni, postcondizioni, o condizioni di invarianza
(tipo volere, dovere, potere)
o Verbi transitivi: metodi
o Verbi intransitivi: eccezioni o eventi dipendenti dal tempo
o Aggettivi: valore di attributo o classe
o Frase aggettivale: associazione, operazione
(definizioni da qui e qui)
• Non esiste un’unica soluzione formalmente corretta, bisogna affidarsi all’intuizione e all’esperienza
• L’analisi mette al centro l’utente, di cui bisogna capire le intenzioni, esprimibili come postcondizioni
• Comprendere l’Ontologia permette di introdurre oggetti essenziali piuttosto che accidentali (importanti
piuttosto che arbitrari)
• Gli oggetti sono strutture concettuali rappresentanti astrazioni universali
• I giudizi importanti per l’analisi object-oriented sono:
o Qualità, che individua attributi, esprime proprietà accidentali difficilmente riutilizzabili
o Riflessione, che individua relazioni
o Categoria, che individua generalizzazioni, esprime astrazioni ad alto livello, essenziali
o Valore, che individua regole
• Gli attributi sono funzioni che prendono oggetti come valori, possono avere valori astratti/essenziali o
accidentali
• Un concetto dovrebbe essere astratto come classe se:
o Si possono dire diverse cose interessanti su di esso
o Ha proprietà non condivise da altre classi
o Ci sono affermazioni che distinguono questa classe da altre classi più ampie a cui essa
appartiene
o I confini del concetto sono imprecisi
o Il numero di delle classi complementari la cui unione è la naturale generalizzazione di questa è
basso
• Regola per distinguere oggetti essenziali: ciò che si può dire sull’oggetto è più che ciò che si può ottenere
elencando i suoi attributi e metodi, cosa è essenziale dipende dal contesto (e.g. non c’è molto da dire
sulla classe degli ‘impiegati che non sanno volare’ a meno che non ci si occupi di liee aeree)
• Oggetti con troppi metodi o attributi devono far pensare di essersi allontanati dalle necessità degli
utenti
• Bisogna considerare il riuso nella raccolta dei requisiti
• Analisi e progettazione sono arti creative: bisogna prendere percezione e intenzione degli utenti e
trasformarle, collaborando con loro
Da: http://uml-tutorials.trireme.com/uml_tutorial_4.htm
Schede CRC
• Metodo di brainstorming iterativo che coinvolge sviluppatori, esperti e committenti
• Servono a definire le classi principali e le loro interazioni all’inizio del progetto, e in seguito per
controllare lo sviluppo
• Class-Responsibility-Collaborator:
o Classe: collezione di oggetti simili (per gli oggetti più importanti)
o Responsabilità: compiti principali (ciò che una classe conosce o fa)
o Collaborazioni: altri oggetti che cooperano per soddisfare una responsabilità
• Descrizione:
o Un oggetto è una persona, un posto, una cosa, un evento o un concetto rilevanti per il sistema
o Possono includere anche superclassi e sottoclassi
o Per le classi usare nomi singolari semplici
o Una classe può cambiare il valore di ciò che sa, ma non di ciò che altre classi sanno
o Se una classe deve assolvere una responsabilità ma non ha abbastanza informazioni, si rivolge
alla classe che le ha, che diviene sua collaboratrice
o Una collaborazione può essere una richiesta di informazioni o una richiesta di fare qualcosa
• Utilizzo:
o Le schede vengono scritte su post-it e posizionate su un piano, dove la loro vicinanza fisica
rispecchia quella logica
o Qualcuno legge lo scenario di uno use case e gli altri mettono insieme gli oggetti che collaborano
alla sua realizzazione
o Quando un oggetto ne usa un altro, il secondo è detto collaboratore del primo
o Per eseguire degli “stress test” sulle schede, si può alterare lo scenario per vedere se il design
regge
o Si possono realizzare molte schede, eliminando quelle non utilizzate solo alla fine del processo:
nel frattempo si possono proporre più alternative, mettendo quelle momentaneamente scartate
su un lato
o Può essere utile scrivere decisioni chiave sull’allocazione delle responsabilità e disegnare
diagrammi per le interazioni più importanti
• Creare un modello CRC:
o Si può realizzare un modello CRC per ogni requisito o use-case
o Trovare le classi: identificare i blocchi di costruzione per l'applicazione, in genere le classi
principali sono 3-5
o Trovare le responsabilità: cosa fa una classe e quali informazioni bisogna mantenere che la
riguardano
o Definire i collaboratori: chiedersi per ogni responsabilità della classe se essa è in grado di
assolverla da sola (questo può portare ad aggiungere responsabilità ad altre classi o nuove
classi)
o Muovere in giro le carte: disporre vicine le schede di classi che collaborano, questo aiuta a capire
le relazioni tra le classi
o Procedendo con lo sviluppo del progetto si tornerà ad apportare modifiche ai modelli CRC
Da: http://alistair.cockburn.us/Using+CRC+cards, http://agilemodeling.com/artifacts/crcModel.htm
Classi di analisi – Entity -Control-Boundary Pattern
• L’Entity-Control-Boundary Pattern è una generalizzazione del Model-View-Controller pattern, usasto per
sistemi anziché per interfacce utente
• Si usano tre stereotipi:
o <<entity>>:
▪ Mantengono informazioni persistenti
▪ Tengono un comportamento organizzato attorno a un insieme di dati coeso
▪ Derivabili da classi di modelli di business o di dominio, ma più orientate al sistema
▪ Concetto strettamente legato a database o altri sistemi di gestione di dati
o <<boundary>>:
▪ Interazioni tra sistemi e attori
▪ Oggetti che si interfacciano con gli attori
▪ Rappresentano elementi del sistema che gestiscono le comunicazioni con gli elementi al
di fuori dell’area che si sta progettando (e.g. interfaccia utente o API)
▪ Prendono un segnale da utenti, altri sistemi o hardware e li consegna ad oggetti interni
▪ Inviano messaggi ad utenti, altri sistemi o hardware
▪ Raccolgono dati dagli attori e/o mostrano dati agli attori
o <<control>>:
▪ Mediano tra boundary ed entity
▪ Contengono la logica necessaria a gestire gli oggetti e le loro interazioni (algoritmi per
gestione e manipolazione dei dati)
▪ Potranno essere implementati come classi ma anche come semplici metodi
▪ Eseguono i flussi degli use case → sono associabili ai casi d’uso
▪ Boundary ed entity potrebbero realizzare uno use case senza bisogno di control
• Regole di comunicazione:
o Gli attori comunicano solo con le interfacce
o I boundary comunicano solo con control e attori
o Le entity comunicano solo con i control
o I control comunicano solo con boundary ed entity o con altri control
• Architettura esagonale:
o Gli attori interagiscono con i boundary
o I boundary inviano comandi ai control
o I control possono mandare richieste ai
boundary per ricevere più informazioni
dagli attori
o I control poi aggiornano le entity
o I boundary aggiornano se stessi quando
bisogna riflettere cambiamenti delle
entità
• Distinguere domini di problema e soluzione
• Minimizzare accoppiamento
• Introdurre ereditarietà solo se le gerarchie
esistono nel dominio
• Package:
o Raggruppa elementi in relazione
semantica
o Definisce confini semantici nel modello
o Fornisce unità per sviluppo parallelo (design)
o Fornisce namespace incapsulato con unicità di nomi
o Ogni elemento appartiene a uno e un solo package
o Contengono casi d'uso, classi di analisi, realizzazioni di casi d'uso
o Identificazione package d'analisi:
▪ Raggruppare cluster di classi coesi
▪ Trovare gerarchie di ereditarietà
▪ Casi d'uso per processo o attore possono indicare package
▪ Alta coesione dentro package
▪ Basso accoppiamento fra package
▪ Evitare package annidati
o In caso di dipendenze cicliche:
▪ Fondere in unico package
▪ Fattorizzare elementi comuni in nuovo package
▪ Fare attenzione all’orientamento delle associazioni
• Il modello di analisi definisce la struttura, anche architetturale
• Viene descritto in:
o Diagrammi di classi di analisi (classi di analisi che interagiscono per realizzare un caso d’uso)
o Diagrammi di interazione (collaborazioni e interazioni tra istanze che lo realizzano, istantanee
dell’esecuzione)
o Raffinamento di requisiti e casi d’uso
• Link:
o https://stackoverflow.com/questions/683825/in-uml-class-diagrams-what-are-boundary-
classes-control-classes-and-entity-cl
o http://www.ivencia.com/softwarearchitect/chapter1/chapter1_6.htm (utile anche dopo)
o ArchWebcast03_DaiCasiDUsoAlModello.pdf (utile anche dopo)
o http://www.cs.sjsu.edu/~pearce/modules/patterns/enterprise/ecb/ecb.htm
o http://epf.eclipse.org/wikis/openuppt/openup_basic/guidances/concepts/entity_control_boun
dary_pattern,_uF-QYEAhEdq_UJTvM1DM2Q.html
o https://youtu.be/sv6z9f_hU0E
o https://youtu.be/JU12_1DuTjI
o https://youtu.be/dgwUYMKoxnA
o https://youtu.be/oAvO6g9SRks
Diagramma delle classi (di progetto)
• Le classi sono il cuore di ogni sistema object-oriented
• Le classi descrivono i diversi tipi di oggetti che compongono la struttura di un sistema, e che soddisfano
le necessità espresse dagli use case
• I diagrammi delle classi mostrano le classi e le loro relazioni
• Cos’è una classe:
o È un tipo di qualcosa
o È come il progetto di come sarà costruito un oggetto, con le sue caratteristiche
o Ogni oggetto costruito da una classe è un’istanza della classe
o Comprende le informazioni di stato (attributi) e comportamento (operazioni) di un oggetto
o Scartare dettagli irrilevanti per un contesto si dice astrazione, ed è importante per avere un
buon punto di partenza quando si progettano le classi del sistema
o Il principio dell’incapsulamento dell’approccio object oriented allo sviluppo di sistemi prevede
un oggetto contenga i dati e le operazioni che lavorano su quei dati
o L’incapsulamento permette a una classe di nascondere dettagli di come funziona, così è
possibile modificare i dettagli interni senza che cambi nulla all’esterno
• Le classi in UML:
o In UML una classe è rappresentata da un rettangolo diviso in tre sezioni contenenti il nome
(obbligatoria), gli attributi e le operazioni della classe
o Il nome di una classe determina il tipo dell’oggetto che sarà istanziato in base ad essa
o Il diagramma delle interazioni mostra come gli oggetti lavorano insieme quando il sistema è in
funzione
Visibilità
• Usare le caratteristiche di visibilità permette di applicare l’incapsulamento, controllando l’accesso ad
attributi, operazioni, o intere classi
• Il simbolo della visibilità è posto prima del nome dell’attributo/operazione a cui si riferisce
• Public:
o Accessibile direttamente da ogni altra classe
o L’interfaccia di una classe pubblica consiste in attributi e operazioni pubblici, accessibili e
utilizzabili dalle altre classi
o Poiché le altre classi possono dipendere dall’interfaccia pubblica di una classe, questa deve
cambiare il meno possibile
o In genere è meglio evitare attributi pubblici, ma non sempre (e.g. se si tratta di costanti)
• Protected:
o Accessibile dai metodi della classe e delle sottoclassi
o Serve a permettere alle sottoclassi di accedere a un attributo o un’operazione della superclasse
senza aprirlo/a all’intero sistema
o [In Java anche le classi nel package possono accedere a campi protected]
• Package:
o Accessibile solo dalle classi nello stesso package
• Private:
o Accessibile solo dalla classe che lo contiene
o Utile se si intende cambiare un attributo o un’operazione senza modificare le classi che vi
accedono
o Gli attributi dovrebbero essere principalmente private o protected, molto raramente public
• Due attributi nella stessa classe non possono avere lo stesso nome
• Il tipo può essere o una classe o un tipo primitivo
• I nomi devono essere descrittivi e rispettare le convenzioni del linguaggio usato
• Se ad un attributo è applicata la proprietà readOnly, il suo valore non può essere cambiato dopo che il
suo valore iniziale è stato impostato [equivale a final in Java]
• Altre proprietà che un attributo può avere sono union, subsets, redefines e composite
• Molteplicità:
o Un attributo può rappresentare uno o più oggetti di un certo tipo
o [*] indica che un attributo può essere presente in qualsiasi quantità
o [a..b] indica che un attributo può essere presente da a a b volte
o In un attributo associated, il valore dal lato dell’attributo indica quanti di quegli attributi
saranno mantenuti nella classe, il valore dal lato della classe indica con quanti oggetti del tipo
della classe sarà associato l’attributo
o La proprietà unique impone che non ci possano essere due elementi uguali nell’insieme
associato a un attributo (è il default per gli attributi con molteplicità)
o La proprietà not unique indica che sono permessi i duplicati
o La proprietà ordered indica che gli elementi nell’insieme associato a un attributo sono
mantenuti con un certo ordine (il default è l’inverso)
• I parametri sono usati per specificare l’informazione fornita a un’operazione per permetterle di
completare il suo compito, comprendono nome e tipo
• Il tipo di ritorno è specificato dopo i due punti e indica il tipo dell’oggetto che sarà restituito
dall’operazione, non è necessario per i costruttori
Vincoli
• A volte si vogliono limitare i modi in cui una classe può operare, per esprimere questi vincoli si usa
l’Object Constraint Language
• Esistono tre tipi di vincoli applicabili ai membri delle classi:
o Invarianti:
▪ Vincoli che devono essere sempre veri, altrimenti il sistema si trova in uno stato non
valido
▪ Sono definiti sugli attributi delle classi
o Precondizioni:
▪ Vincoli definiti su un metodo e controllati prima che questo sia eseguito
▪ Sono usate per validare parametri di input di un metodo
o Postcondizioni:
▪ Vincoli definiti su un metodo e controllati dopo che questo è stato eseguito
▪ Sono usate per descrivere come i valori sono modificati da un metodo
• I vincoli possono essere indicati o tra parentesi graffe accanto al campo a cui si riferiscono o in una nota
a parte
Classi astratte
• A volte creando classi generiche si preferisce lasciare l’implementazione di alcune operazioni alle
sottoclassi che le specializzano, questa scelta si può indicare usando metodi astratti, scritti in corsivo
• Se una parte di una classe è dichiarata astratta, la classe stessa deve essere dichiarata astratta
scrivendone il nome in corsivo
• Una classe astratta non può essere istanziata
• Se una sottoclasse implementa tutti i metodi astratti della superclasse, divenendo concreta, può essere
istanziata
• Le classi astratte sono utili per definire comportamenti e attributi comuni
• Classi astratte e interfacce sono molto usate nel definire generici ruoli e comportamenti che formano i
design pattern
Interfacce
• Se si vogliono dichiarare metodi astratti per una classe che ha una sola relazione di ereditarietà, si può
usare un’interfaccia, al posto della classe
• Un’interfaccia è un insieme di operazioni senza implementazioni, come una classe astratta con solo
metodi astratti
• Le interfacce sono più sicure da usare delle classi astratte poiché evitano i problemi legati all’ereditarietà
multipla
• A volte le interfacce contengono attributi, generalmente statici e spesso costanti
• Non si può istanziare un’interfaccia
• Sono rappresentate con una notazione di classe stereotipata o con la loro notazione a cerchio:
• La classe che realizza (implementa) un’interfaccia si indica con una freccia tratteggiata verso l’interfaccia
nel primo caso e con un’associazione all’interfaccia nel secondo
• Se una classe realizza un’interfaccia ma non implementa tutti i suoi metodi, va dichiarata astratta
• Le interfacce sono perfette per separare il comportamento che una classe deve tenere da come questo è
realizzato
• Gli oggetti di una classe che implementa un’interfaccia possono essere chiamati col nome
dell’interfaccia, quindi altre classi possono dipendere dall’interfaccia piuttosto che dalle classi, il che è
positivo perché riduce l’accoppiamento delle classi
o Messaggio sincrono:
▪ Invocato quando il chiamante aspetta che il ricevente ritorni dall’invocazione del
messaggio
▪ In Java corrisponde all’invocazione di un metodo
o Messaggio asincrono:
▪ Necessario quando si vogliono lanciare più interazioni nello stesso momento, anche
senza aspettare che ritornino
▪ Il chiamante non aspetta che l’invocazione del messaggio ritorni prima di procedere
▪ In java viene implementato usando i thread
o Messaggio di ritorno:
▪ Si può usare (opzionalmente) alla fine di una activation bar per mostrare che il flusso di
controllo dell’attivazione ritorna al chiamante
▪ A livello implementativo corrisponde a raggiungere la fine di un metodo chiamando
esplicitamente il return
▪ Un partecipante può anche inviare un messaggio a se stesso, per dividere una grande
activation in pezzi più piccoli e gestibili
o Messaggi di creazione e distruzione:
▪ I partecipanti non vivono necessariamente per l’intera durata dell’interazione del
diagramma di sequenza, ma possono essere creati e distrutti col passaggio di messaggi
▪ Per mostrare che un partecipante è creato si può o passare un messaggio create(…) o
usare la notazione dropped participant box
▪ La cancellazione di un partecipante è mostrata dalla fine della sua lifeline con la croce di
cancellazione
▪ In Java la creazione corrisponde all’utilizzo di new, mentre non c’è un corrispettivo per
la distruzione esplicita, che viene effettuata dal garbage collector, in tal caso si può o
lasciare l’oggetto vivo ma inutilizzato o utilizzare una croce di distruzione senza metodo
associato
Frammenti di sequenza
• Serve a modellare cicli e flussi alternativi
• È rappresentato da una scatola che racchiude una porzione delle interazioni di un diagramma di
sequenza
• Alcuni tipi di frammento hanno bisogno di un parametro contenente una condizione di guardia
• Nell’angolo in alto a sinistra della scatola del frammento c’è un operatore che indica il tipo del
frammento:
o Operatore opt, frammento opzionale:
▪ Tutte le interazioni che contiene saranno eseguite in base al risultato della condizione di
guardia
▪ Utile in corrispondenza di una relazione <<extend>> in uno use case, ossia quando si
riusa un insieme di interazioni solo in certe condizioni
o Operatore ref, frammento di referenza:
▪ Rappresenta un riferimento a una porzione del diagramma che viene disegnato a parte
per non creare confusione
▪ Non ha bisogno di parametri
▪ È utile per riutilizzare un insieme di interazioni comuni
o Operatore assert, frammento di asserzione:
▪ Specifica che le interazioni che contiene devono avvenire esattamente come sono
indicate, altrimenti il frammento è dichiarato non valido e viene sollevata un’eccezone
▪ Utile per specificare che ogni passo di un’interazione deve avere successo (ad esempio
in una transazione)
o Operatore loop, frammento di ciclo:
▪ Prende come parametri il minimo e il massimo di iterazioni e una condizione di guardia
▪ Ripete le istruzioni che contiene un numero specificato di volte finché la condizione di
guardia risulta falsa
o Operatore break, frammento di interruzione o eccezione:
▪ Se la condizione di guardia è vera vengono eseguite le interazioni di questo frammento
anziché quelle restanti del frammento che lo racchiude (tipicamente un ciclo), da cui
quindi si esce
o Operatore alt:
▪ Prende come parametri una o più condizioni di guardia, compresa [else]
▪ Vengono eseguire interazioni che contiene in base a quale condizione di guardia risulta
vera per prima
o Operatore neg, frammento negativo (non valido):
▪ Dichiara che le interazioni in questo frammento non saranno eseguite
▪ Utile per “commentare” un insieme di interazioni prima di eliminarle definitivamente,
soprattutto se si ha un tool che esegue effettivamente il codice derivato dai diagrammi
▪ Può servire anche a indicare qualcosa che non va fatto
o Operatore par, frammento parallelo:
▪ Specifica che le interazioni che contiene possono essere eseguite in parallelo
▪ Indica che non serve rendere le operazioni thread-safe tramite locking
o Operatore region, frammento di regione critica:
▪ Indica che le interazioni che contiene sono parte di una regione critica
▪ Tipicamente una regione critica è un’area in cui partecipanti condivisi vengono
aggiornati
▪ Indica che occorre usare dei lock per evitare interleaving di interazioni parallele
o Altro: http://www.uml-diagrams.org/sequence-diagrams-combined-fragment.html
Esempio
Rappresentazione del procedimento per creare un nuovo account blog regolare:
1. come diagramma di use case;
2. come diagramma di attività;
3. come diagramma di sequenza base;
4. come diagramma di sequenza intermedio;
5. come diagramma di sequenza con frammenti – visione generale;
6. come diagramma di sequenza con frammenti – porzione per la selezione del tipo di account.
1.
2.
3.
4.
5.
6.
Piano dei test
• Il piano dei test descrive tutti gli sforzi necessari per lo svolgimento dei test nelle varie fasi del progetto:
la strategia, la pianificazione, i criteri di inizio e fine, i rischi e le relative soluzioni
• Dovrebbe essere cominciato quanto prima e sviluppato iterativamente, aggiungendo sezioni quando
l’informazione è disponibile
• Mettere in chiaro da subito requisiti, strategie e risorse necessarie velocizza revisione, feedback e
approvazione dei test
• Tipi di piano dei test:
o Master test plan: contiene informazioni ad alto livello, meno soggetto a cambiamenti
o Detailed test plan: contiene informazioni specifiche, è aggiornato col progredire del progetto
o Iteration test plan: contiene solo le informazioni su una certa iterazione
o Acceptance test plan: descrive le attività associate ai test di accettazione
Cosa chiedersi per redigere il piano
• Cosa devo testare? Descrizione: sistemi, applicazioni, hardware
• Quali funzioni testerò? Lista delle funzioni e descrizione del sistema e delle sue componenti separate
• Come le testerò? Strategia: tipi di test e loro applicazione agli oggetti da testare
• Quando le testerò? Sequenza di lavoro: preparazione ed effettuazione dei test, analisi dei risultati nel
contesto delle fasi di sviluppo pianificate
• Criteri di avvio dei test: piattaforma di test pronta, funzionalità richieste sviluppate, documentazione
disponibile
• Criteri di completamento dei test: i risultati dei test combaciano coi criteri di qualità del prodotto
• Quali sono l’ambiente del sistema, i requisiti per i test, i rischi e le loro soluzioni?
Linee guida
• Identificare i requisiti per il test:
o Indicano lo specifico target di un test
o Devono essere comportamenti osservabili e misurabili
o Non c’è un rapporto 1-1 tra use case + requisiti non funzionali e requisiti per i test
o I requisiti possono venire da use case, specifiche supplementari, requisiti di design, documento
di architettura…
o Requisiti per i test funzionali:
▪ Almeno uno da ogni use case
▪ Meglio uno da ogni flusso di ogni use case
o Requisiti per i test di performance:
▪ Si misura l’efficienza del target del test misurando il tempo di risposta e/o l’uso di
risorse, in diverse condizioni
▪ Vanno rintracciati nelle specifiche supplementari, in particolare dove si parla di tempo,
dove si confronta il comportamento di più elementi, o dell’applicazione sotto più
configurazioni, affidabilità operativa lungo un periodo di tempo, configurazioni o vincoli
▪ Bisogna ottenere almeno un requisito per ognuno degli elementi così individuati
o Requisiti per i test di affidabilità:
▪ Vanno rintracciati nelle specifiche supplementari, o nelle linee guida per interfaccia
utente, design e programmazione, in particolare dove si parla di affidabilità o resistenza
al fallimento, integrità e struttura del codice, utilizzo di risorse
▪ Bisogna ottenere almeno un requisito per ognuno degli elementi così individuati
• Valutare i rischi associati ai requisiti:
o Permette di assegnare una priorità ai test: gli use case che comportano maggiori rischi o che
hanno più probabilità di fallire dovrebbero essere testati per primi
o Identificare gli indicatori della gravità di rischio che saranno usati:
▪ H: rischio alto, non tollerabile; esposizione esterna dei server; la compagnia ha gravi
perdite finanziarie o di reputazione e responsabilità
▪ M: rischio medio, tollerabile ma non desiderabile; esposizione esterna minima; la
compagnia può soffrire finanziariamente, ma ha scarsa responsabilità e perdita di
reputazione
▪ L: rischio basso, tollerabile; esposizione esterna scarsa o assente; la compagnia ha
perdite finanziarie o responsabilità scarse o assenti; la reputazione della compagnia non
è toccata
o Scegliere la prospettiva in base alla quale assegnare gli indicatori di gravità di rischio:
▪ Effetto: l’impatto o la conseguenza del fallimento di un requisito; per determinarlo
rispondere alla domanda “cosa succederebbe se …?”
▪ Causa: un esito indesiderabile causato dal fallimento di un requisito; per determinarlo
rispondere alla domanda “come potrebbe succedere che …?”
▪ Probabilità: la probabilità che un requisito fallisca; determinata in base a tasso di
fallimento, tasso di cambiamento, complessità, origine
o In base alla prospettiva scelta, assegnare a ogni requisito da testare un indicatore di gravità di
rischio e giustificare la scelta
• Determinare il profilo operazionale dei requisiti:
o Identificare e descrivere gli indicatori dell’importanza del profilo operazionale:
▪ H: usato molto frequentemente o da molti attori o use case
▪ M: usato frequentemente o da diversi attori o use case
▪ L: usato infrequentemente o da pochi attori o use case
o Valutare:
▪ Il numero di volte che un attore/uno use case esegue il requisito in un periodo di tempo
▪ Il numero di attori/use case che eseguono il requisito
o In base a queste valutazioni, associare un indicatore ad ogni requisito e fornire una motivazione
• Stabilire le priorità dei test:
o Serve ad assicurare che:
▪ Lo sforzo dei test sia concentrato sui requisiti più appropriati
▪ I requisiti più critici, significativi o rischiosi siano affrontati al più presto
▪ Tutte le dipendenze siano considerate nel test
o Identificare e descrivere gli indicatori di priorità dei test:
▪ H: deve essere testato
▪ M: dovrebbe essere testato, ma solo dopo H
▪ L: potrebbe essere testato, ma solo dopo H ed M
o Considerare:
▪ Indicatore della gravità di rischio
▪ Indicatore dell’importanza del profilo operazionale
▪ Descrizione dell’attore
▪ Obbligazioni contrattuali
o Strategie per assegnare una priorità a un test:
▪ Usare l’indicatore più alto
▪ Indicare il fattore più importante e usare il suo indicatore
▪ Combinare gli indicatori di più fattori
▪ Calcolare una media pesata degli indicatori dei vari fattori
o In base a queste considerazioni e strategie, associare un indicatore ad ogni requisito e fornire
una motivazione
• Definire la strategia dei test:
o Descrive l’approccio generale e gli obiettivi di un test
o Deve contenere:
▪ Tipo del test e obiettivi: stabilire chiaramente il tipo del test e gli obiettivi del test
(specificando perché si sta svolgendo il test), così da ridurre la confusione e minimizzare
i fraintendimenti
▪ Stadio del test: stabilisce la fase in cui il test sarà eseguito (tipicamente i test funzionali
si svolgono in tutte le fasi, quelli di performance dei componenti in fase di test di unità e
di integrazione, quelli di performance di carico di lavoro e stress in fase di test di sistema
e di accettazione, quelli di affidabilità in fase di test di unità e di integrazione ed
eventualmente di sistema)
▪ Tecnica: descrive come i test saranno implementati ed eseguiti, le azioni da compiere
durante l’esecuzione dei test e i metodi usati per valutare i risultati
• Criteri di completamento:
o Servono ad identificare:
▪ La qualità del prodotto accettabile
▪ Quando i test sono stati completati con successo
o Devono includere:
▪ Funzioni, comportamenti o condizioni da misurare
▪ Metodi di misurazione
▪ Criteri o grado di conformità alla misura
• Considerazioni particolari: identificare influenze o dipendenze che potrebbero avere un impatto sullo
svolgimento dei test, tra cui:
o Risorse umane, come la necessità di personale esterno al gruppo dei test
o Vincoli, come la necessità di attrezzature
o Requisiti particolari, come schedulazione dei test o accesso al sistema
Checklist
• Il piano dei test identifica l’ambito dei test stabilendo:
o Stadi e tipi di test da implementare ed eseguire
o Caratteristiche e funzioni da testare e da non testare
o Assunzioni rischi e contingenze che possono avere effetti sui test
• Il piano dei test identifica gli artefatti usati per generare i contenuti del piano stesso
• Ogni requisito (come descritto in uno use case) ha associato un test o la motivazione per cui non è
necessario testarlo
• Ad ogni requisito è assegnata una priorità di test e un tipo di test
• Per ogni tipo di test è descritta una strategia, che comprende:
o Il nome del test e i suoi obiettivi
o Una descrizione di come il test sarà implementato ed eseguito
o Una descrizione dei criteri e dei metodi di misurazione usati per valutare la qualità del target del
test e per stabilire il completamento del test
• Tutte le risorse necessarie ad implementazione e svolgimento dei test sono state identificate (hardware,
software e personale)
• Il piano dei test comprende una lista di milestone che identificano le attività del progetto e i relativi test
• Il piano dei test identifica gli artefatti creati dalle attività di test, quando sono disponibili, come saranno
distribuiti, il loro contenuto e come vanno usati
Tipi di test
• Di componenti:
o Responsabilità dello sviluppatore
o Possono riguardare singole funzioni, classi (testare funzioni e attributi) o interfacce (cercare
errori di interfaccia o assunzioni non valide)
• Di sistema:
o Responsabilità di un gruppo di testing indipendente
o Basati sulle specifiche del sistema
o Di integrazione:
▪ Il gruppo di testing ha accesso al codice ed esegue i test mentre si integrano i
componenti
▪ Si cercano i problemi sorti dall’integrazione dei componenti
▪ Dall’alto in basso (aggiungendo elementi allo scheletro) o dal basso all’alto (integrazione
di componenti infrastrutturali con aggiunta di quelli funzionali)
▪ Approcci: convalida architetturale, dimostrazione di sistema, implementazione test,
osservazione test
o Di rilascio:
▪ Il gruppo di testing verifica il sistema completo, come black-box
▪ Test basato sulle specifiche del sistema e non sulla sua implementazione
• Per validazione:
o Servono a dimostrare che i requisiti sono soddisfatti
o Hanno successo quando mostrano che il sistema è corretto
• Per difetti:
o Servono a scoprire difetti o errori
o Hanno successo quando mostrano un difetto (di algoritmo, computazione, documentazione,
limite, temporizzazione, prestazioni, rispetto a standard)
• Prestazionali: si aumenta il carico di lavoro del sistema finché le prestazioni non sono inaccettabili
• Da sforzo: il sistema è portato oltre i limiti previsto per vedere come reagisce (il fallimento non
dev’essere catastrofico)
• Strutturali (white-box): si parte dalla conoscenza del programma per generare i casi di test, con
l’obiettivo di testare ogni istruzione
• Dei cammini: si cerca di testare ogni possibile cammino nel programma
Per approfondire
• http://sce.uhcl.edu/helm/RationalUnifiedProcess/process/modguide/md_tstpl.htm
• http://sce.uhcl.edu/helm/RationalUnifiedProcess/process/activity/chklists/ck_tstpl.htm
• https://www.utest.com/articles/how-to-create-a-test-plan
• https://www.ibm.com/developerworks/rational/library/04/r-3239/r-3239-pdf.pdf
• http://www.fit.vutbr.cz/study/courses/ITS/public/ieee829.html
Gestione dei rischi e garanzia di qualità
• Identificare i rischi ed elaborare un piano per minimizzarne l’effetto
• Tre aree di influenza:
o Di progetto: influenzano temporizzazione o risorse
o Di prodotto: influenzano qualità o prestazioni software
o Di business: influenzano l’organizzazione
Processo di gestione dei rischi
• Identificazione: elencare i potenziali rischi
o Tecnologici
o Legati a persone
o Organizzativi
o Nei requisiti
o Nelle stime
• Analisi: stabilire probabilità (molto bassa, bassa, moderata, alta, molto alta) ed effetti (catastrofici, seri,
tollerabili o insignificanti), assegnare priorità
• Pianificazione: evitare o minimizzare le conseguenze
o Tecniche:
▪ Avoid: eliminare il rischio o ritirarsi
▪ Reduce: ottimizzare, mitigare
▪ Retain: accettare e contabilizzare
▪ Transfer: esternalizzare o assicurare
o Per ogni rischio stabilire una strategia di gestione:
▪ Per evitare: ridurre la probabilità che il rischio si verifichi
▪ Per minimizzare: ridurre l’impatto del rischio
▪ Piani di contingenza: come trattare il rischio se emerge, scatenati da un trigger
• Osservazione: tenere sotto controllo i rischi durante il progetto, per valutare se ci siano cambiamenti
sulle probabilità o sugli effetti, usando opportuni indicatori
• Risk Mitigation, Monitoring, and Management:
o Ridurre in anticipo probabilità e impatto dei rischi
o Osservare fattori che indicano cambiamenti delle probabilità dei rischi
o Implementare piani di contingenza
• Per ogni rischio individuato bisogna indicare anche il trigger: la causa prima (condizione od evento) che
fa sì che il rischio si verifichi
Principi di Software Quality Assurance
• Approccio alla gestione della qualità
• Metodi e strumenti di software engineering efficaci
• Conduzione di revisioni tecniche, test multi-strato, misure, controlli
• Controllo di documentazione e aggiornamenti
• Procedure di adesione a standard
• La tracciabilità dai requisiti al codice è fondamentale per valutare la qualità
• Qualità del progetto:
o Analisi dei requisiti e delle specifiche
o Progetto architetturale dettagliato
o Fattori di qualità: produttività, visibilità, tempestività, qualità specifiche