Note pagina per pagina - ITALIANO

Pagina 1

  • Definizione di software: un programma che specifica istruzioni che un calcolatore deve eseguire per raggiungere uno scopo. Include anche documenti descrittivi (manuali, file di configurazione, file di installazione) prodotti durante le fasi di sviluppo. Include le caratteristiche strutturali, funzionali, non-funzionali e le configurazioni possibili. L’ingegneria del software è la disciplina che agisce globalmente su tutte le componenti del software per produrre software di qualità.
  • Classificazioni grossolane del software (scopo e ambito):
    • Software di sistema
    • Software applicativo
    • Software scientifico e tecnico
    • Software embedded
    • Software di produttività
    • Applicazioni Web
    • Software per l’intelligenza artificiale
  • STORIA (segnali di esperienza con software):
    • Therac-25 (1985-1987): pazienti irradiati da apparecchiatura di terapia; baco nel software di input; almeno 5 morti.
    • London Ambulance Service (1992): sistema automatico di invio SOS con scadenti tempi, ritardi di ore e circa 30 decessi; sistema poi dismesso.
    • Denver Airport Baggage System (1995): sistema software per smistamento bagagli; ritardi multipli; costo tentativo $1,1 milioni; progetto abbandonato.
    • Ariane 5 (1996): esplosione durante volo inaugurale a causa di overflow di buffer e segnale di autodistruzione ritenuto fuori rotta; costo $500 milioni.
    • Mars Climate Orbiter (1999): sonda smarrita per problemi di unità di misura non uniformi (metrico vs imperiale); perdita stimata $125 milioni.
    • Toyota Prius (2005): richiamo di >160.000 unità per errori nel software di controllo.
    • Knight Capital Group (2012): perdita $460 milioni a seguito di errore di trading.
    • Boeing 787 Dreamliner (2015): riavvii energetici non regolari e potenziale perdita di controllo.
    • Boeing 737 MAX (2019): problemi MCAS con due incidenti mortali, 346 morti.
  • Questioni generali sul software:
    • Anni ’50: primi linguaggi di alto livello (es. COBOL); i programmi diventano complessi.
    • Anni ’60-’70: crisi del software; le tecniche esistenti non scalano con l’aumento della potenza hardware.
    • Conferenze NATO (1968 Garmisch, 1969 Roma) posano le basi per una disciplina ingegneristica del software: nuove metodologie, forme e processi per trasformare la produzione in un’attività ingegneristica.
    • Le richieste di qualità del software seguono la tendenza di aumentare la complessità dei sistemi e la diffusione in nuovi domini: spesso i sistemi software falliscono o vengono cancellati durante lo sviluppo, e i rilasci sono spesso in ritardo e di qualità discutibile.
  • Definizione generale di ingegneria del software (inclusioni): include processi, metodi e strumenti per lo sviluppo economico e pianificato del software.

Pagina 2

  • Esempi continui di fallimenti software rilevanti menzionati:
    • Therac-25, London Ambulance Service, Denver Airport, Ariane 5, Mars Climate Orbiter, Toyota Prius, Knight Capital, Boeing 787 Dreamliner, 737 MAX.
  • Per quanto riguarda il software, si ribadisce l’evoluzione storica: dai linguaggi agli approcci di sviluppo; dalle conferenze NATO fino all’adozione di approcci ingegneristici; nonostante i progressi, moltissimi sistemi falliscono o vengono cancellati in fasi avanzate dello sviluppo.
  • Implicazioni etiche/pratiche: la qualità del software è cruciale in contesti ad alta criticità; la gestione delle pressioni di tempo e budget può compromettere la qualità.
  • Numeri e riferimenti: alcuni esempi includono costi e perdite notevoli: £1,1 milioni (LAS), $1 miliardo? (esempio non esplicito; citato come costi). Alcune cifre precise: $1,1 milioni (LAS); $125 milioni (Mars Climate Orbiter); $460 milioni (Knight Capital); 346 morti (737 MAX).
  • Linguaggio e disciplina: si rimarca la necessità di passare da attività “artigianali” a modalità ingegneristiche; le metodologie moderne prevedono processi iterativi ed evolutivi per gestire cambiamenti di requisiti e contesto.

Pagina 3

  • Continuazione della sezione STORIA e esempi citati, con particolare enfasi su:
    • Knight Capital e LA stabilità dell’architettura per evitare errori di trading ad alta frequenza.
    • Gli esempi mostrano come i cambiamenti in misurazione, controllo, e gestione del rischio di progetto possano portare a fallimenti o a perdite significative.
  • Riassunto degli elementi storici e impatti sul software engineering: la fragilità di sistemi complessi, la gestione delle misure e delle unità, e l’importanza della coerenza tra specifiche e implementazione.

Pagina 4

  • Definizioni principali sull’Ingegneria del Software:
    • IEEE: Applicazione di un approccio sistematico, disciplinato e misurabile allo sviluppo, supporto e manutenzione del software.
    • Sommerville: disciplina ingegneristica che riguarda tutti gli aspetti della produzione del software; richiede un approccio sistematico, l’uso di strumenti adeguati e metodologie appropriate in base al problema, vincoli di sviluppo e risorse.
    • Ghezzi, Jazayeri, Mandrioli: branca della scienza dell’informazione per lo sviluppo di sistemi software di grandi dimensioni; il programming è attività individuale, l’ingegneria del software è attività di team.
    • Emmerich: branca dell’ingegneria dei sistemi che si concentra su obiettivi e limiti reali per i servizi forniti dai sistemi software; specifica di comportamenti, gestione delle specifiche e delle evoluzioni nel tempo; riguarda processi, metodi e strumenti per uno sviluppo economico e pianificato.
  • Quattro grandi aree/orientamenti di ingegneria del software: definizioni e ruoli dei diversi autori e scuole di pensiero.

Pagina 5

  • Le 4 P’s dello sviluppo software:
    1) People – stakeholder del progetto: Business Management, Project Management, Development Team, Customers, End Users.
    2) Product – la codebase e i relativi artefatti: è l’obiettivo finale da costruire; focus sull’elevata qualità degli artefatti (e.g., introduzione di tecniche OO) e non solo la documentazione.
    3) Project – le attività per produrre il prodotto: planning, requirements, design, implementation, testing, maintenance.
    4) Process – l’organizzazione delle attività: definisce come si lavora nello sviluppo; l’ingegneria del software ha affinato diversi modelli di processo; l’importanza del processo non è fine in sé ma serve a migliorare qualità ed economicità.

Pagina 6

  • Il processo di sviluppo non è fine di per sé; è necessario per migliorare qualità ed economicità; va osservato da diverse prospettive:
    • Activity perspective: definizione di cosa deve essere fatto.
    • Workflow perspective: sequenza e condizioni per avviare attività.
    • Data-flow perspective: flusso di informazioni tra le attività.
    • Role/Action perspective: chi fa cosa.
  • Processo e prodotto non sono due entità separate ma due facce della stessa medaglia; es. le informazioni sul processo contestualizzano il prodotto e definiscono contesto d’uso.
  • Ciclo di vita: stati che un ente attraversa dal concepimento alla dismissione; un processo di sviluppo definisce le strategie per gestire il ciclo di vita del prodotto.
  • PROCESS ACTIVITY: i processi software si distinguono per: workflow, attività e documenti/modelli prodotti.

Pagina 7

  • Comunicazione: definire cosa deve fare il sistema e i vincoli; esistono specifiche rivolte al customer o allo sviluppatore; task principali in ingegneria dei requisiti: studio di fattibilità, elicitation dei requisiti e analisi, specifica dei requisiti, validazione dei requisiti.
  • Modellazione: descrivere software, architettura, dati scambiati, componenti e interfacce; approcci di design: metodologie agili (riducono i modelli) vs metodologie strutturate (UML) che usano modelli grafici come: modello a oggetti, modello di sequenze, modello a transizione di stati, modello strutturale, modello del flusso dei dati.
  • Costruzione: implementazione OO e design patterns; verifica della conformità ai requisiti; tecniche di testing: statiche (ispezione) e dinamiche (testing); livelli di testing: unit, integrazione, sistema, accettazione (alpha/beta).
  • Manutenzione: evoluzioni correttive, adattive e perfettive; la gestione delle modifiche è una parte cruciale della manutenzione.

Pagina 8

  • Manutenzione: rilasci post-operativi; tipi di evoluzione (correttivo, adattivo, perfettivo); l’ingegneria del software fornisce liste di cose da fare per raggiungere obiettivi del prodotto.
  • Modelli di processo: definiscono l’approccio disciplinato per sviluppo, rilascio e manutenzione; esempi includono Cascata, UP, Scrum; esistono anche Spiral, RAD (Rapid Application Development), Extreme Programming; concetto generale: cosa, chi e come nelle attività; “quando” riguarda l’organizzazione temporale.
  • Prospettive di analisi: 4 prospettive comuni per i processi software: Activities, Workflow, Data/Artefacts, Role/Actions.
  • Cascata: inizialmente è stato molto usato; prevede una sequenzialità rigorosa tra requisiti, analisi, progettazione, implementazione, verifica e rilascio; feedback limitato e frequenti fermi nel progresso; è considerato meno efficace rispetto a processi iterativi.

Pagina 9

  • Processo a cascata criticità: presupposto che i requisiti siano prevedibili e stabili; i cambiamenti mediamente incidono sul progetto (studio Boehm & Papaccio: circa il 25% di cambiamento nei requisiti); nel software i cambiamenti sono la norma, non l’eccezione; ciò rende le pratiche cascade meno adeguate.
  • Metodi iterativi ed evolutivi: accettano cambiamenti e adattamenti di requisiti, modelli e piani sulla base di feedback; consentono di gestire i requisiti in modo parziale e incrementale; i vantaggi includono riduzione del rischio, maggiore adattabilità e maggiore probabilità di successo.
  • Sviluppo iterativo ed evolutivo: organizzazione in iterazioni fisse (es. 3 settimane); ogni iterazione produce sistema eseguibile, testabile anche se parziale; ogni iterazione include requisiti, progettazione, implementazione e test; feedback degli utenti e test (carico/usabilità) guidano successive iterazioni.
  • Prospettiva di architettura: l’architettura viene costruita in iterazioni iniziali per stabilizzare nucleo; gestione delle fasi come Rilascio incrementale e Sviluppo a spirale (Böhm, 1988) con gestione del rischio.

Pagina 10-11

  • UP (Unified Process): quattro fasi principali:
    1) Ideazione/Avvio: visione approssimativa, studio economico, portata, stime; fattibilità.
    2) Elaborazione: architettura del nucleo, mitigazione dei rischi principali, definizione di requisiti principali.
    3) Costruzione: iterazioni di implementazione degli elementi rimanenti.
    4) Transizione: beta test e rilascio; passaggio all’uso da parte degli utenti.
  • UP organizza le attività in discipline: business modelling (Modello di Dominio), requisiti (Modello di Casi d’Uso, Specifica Supplementare), progettazione (Modello di Progetto), implementazione, infrastruttura (strumenti e ambiente). Ogni iterazione genera una baseline: insieme di artefatti revisionati approvati che forniscono una base condivisa per lo sviluppo futuro; incrementi tra baseline.
  • UML: linguaggio di modellazione standardizzato utile per progettare sistemi complessi, comunicare tra team, documentare per la manutenzione. UML non è linguaggio di programmazione ma linguaggio grafico per rappresentare strutture, comportamenti e relazioni; MOF come meta-modello per UML2.

Pagina 21-25

  • UML è un linguaggio di modellazione con scopi: visualizzare, specificare, documentare, costruire. Elementi principali: diagrammi strutturali (classi, componenti, oggetti, distribuzione, pacchetti) e diagrammi comportamentali (casi d’uso, attività, stato) e diagrammi di interazione (sequenza, comunicazione, temporale, interazione generale).
  • Casi d’uso (Use Cases): storie scritte per scoprire e registrare requisiti; guidano analisi e progettazione orientata agli oggetti; non sono diagrammi ma testo; scenari descrivono sequenze specifiche di azioni; i casi d’uso descrivono obiettivi funzionali dal punto di vista degli attori.
  • Modello dei casi d’uso (UP): insieme di casi d’uso che descrivono le funzionalità del sistema e l’ambiente; include opzionalmente diagrammi UML ma sono documenti di testo; possono includere diagrammi UML che mostrano nomi di casi d’uso e attori e le relazioni.
  • Attori: ruoli esterni che interagiscono con il sistema; attori primari (utilizzano direttamente i servizi) e attori finali (desiderano che il sistema sia usato per raggiungere i propri obiettivi); attori di supporto, fuori scena, ecc.;
  • Formati di casi d’uso: breve (riassunto di un solo scenario principale), informale (più scenari), dettagliato (estensioni, precondizioni, post condizioni).
  • Sezioni di un caso d’uso dettagliato: preambolo, portata (scope), attori, obiettivi, estensioni, requisiti speciali (interfacce utente, requisiti di prestazioni, ecc.), tracciabilità.

Pagina 26-27-28-29

  • Uso di UML in UP: i casi d’uso sono centrali, i requisiti funzionali sono registrati principalmente nei CASI D’USO; i casi d’uso guidano la pianificazione iterativa e la stima del progetto; test funzionali o di sistema corrispondono agli scenari dei casi d’uso.
  • Dettagli su attori e ruoli: Attore primario, Attore finale, Attore di supporto, Attore fuori scena; importanza di individuare interessi e obiettivi degli attori per definire i casi d’uso.
  • Livelli dei casi d’uso: livello utente (descrive scenari di business in termini di obiettivo utente) vs livello software (descrive i passi di supporto tecnico). L’attore finale coincide spesso con l’attore primario; a volte è un intermediario, come un cassiere POS.
  • Use Case e obiettivi: definiscono cosa serve agli utenti, non solo le funzioni; i casi d’uso forniscono un contesto utile per la definizione di requisiti; vengono scritti durante workshop di requisiti e iterativamente durante UP.

Pagina 30-31-32-33-34

  • Livelli, contenuti e formati: livello di obiettivo utente e livello di software; l’uso di portata amplia l’applicabilità (in aziende o organizzazioni). Pre-condizioni: condizioni da vere prima di iniziare lo scenario; post-condizioni: cosa deve essere vero al termine dello scenario di successo; scenari principali di successo descrivono flussi di base; estensioni descrivono scenari alternativi o di fallimento.
  • Estensioni: estensioni descrivono varianti e deviazioni rispetto allo scenario principale; possono essere abbastanza complesse; a volte si giustifica la creazione di casi d’uso separati.
  • Requisiti speciali: non funzionali, requisiti di qualità o vincoli; esempi includono interfacce utente, prestazioni, requisiti di localizzazione, robustezza in caso di mancanza di servizi remoti, requisiti di internazionalizzazione.
  • Applicare UML ai casi d’uso: diagrammi d’uso per mostrare attori e casi; diagrammi di attività e altri per la progettazione; l’output principale dei casi d’uso è testo e documentazione associata.
  • Dopo la trattazione di casi d’uso: discussione su come integrare i casi d’uso con i modelli di attività e le fasi di analisi/progettazione; UP incoraggia lo sviluppo guidato dai casi d’uso; la scrittura iniziale del Modello dei Casi d’uso in ideazione è ridotta (circa 10% dei casi) per i casi significativi di architettura; il resto viene sviluppato durante elaborazione.
  • Durante l’elaborazione si prevede 1-2 iterazioni temporizzate per implementare aree ad alto rischio e valore; feedback e test guidano la definizione futura dei requisiti.
  • Durante la costruzione, si prevedono iterazioni timeboxed per completare il sistema; minore necessità di casi d’uso maggiori rispetto all’elaborazione.

Pagina 35-36-37-38

  • Scrittura dei casi d’uso durante l’ideazione ed elaborazione:
    • Ideazione: la maggior parte dei casi d’uso non è in formato dettagliato; i casi di maggiore valore architetturale sono descritti brevemente.
    • Elaborazione: iterazioni timeboxed (es. 2-6 settimane?), con implementazione incrementale di parti rischiose; termine con la maggior parte dei casi d’uso in dettaglio.
    • Costruzione: iterazioni timeboxed molto brevi (es. 2 settimane) che completano il sistema; workshop sui requisiti meno frequenti.
  • Diagramma delle Classi: concetti base dell’oggetto, istanziazione; differenza tra classe e oggetto; definizione di visibilità e tipologie di nomi (UpperCamelCase per classi, lowerCamelCase per attributi e operazioni); differenze tra fase di analisi (cosa deve fare) e progettazione (come farlo). Si distinguono classi di analisi (concettuali) da classi di progetto (implementative).
  • Regole generali per classi di analisi: responsabilità limitate, coesione, dipendenza ridotta tra classi, evitare classi troppo complesse o onnipotenti; uso di tecniche come Nominale-Verbo e CRC (Class-Responsibility-Collaborators) per individuare classi.
  • Tecniche di individuazione: Analisi Nome-Verbo; CRC: Committenti e Analisti identificano oggetti e responsabilità; fase 2 riconsiderazione per determinare se post-it diventano classi o attributi.

Pagina 39-40-41-42

  • Classi di analisi vs progetazione:
    • Analisi: classi che modellano concetti chiave della realtà; responsabilità tipiche: 3-5 per classe; coesione e limitate ancora necessaria;
    • Progettazione: classi di progetto con dettagli su operazioni, visibilità, valori di inizializzazione; trasformazione di associazioni in relazioni di aggregazione/composizione; implementazione di classi di associazione; navigabilità.
  • Relazioni tra classi: associazioni, dipendenze, generalizzazione-specializzazione (ereditarietà). Distinzione tra associazione di analisi e di progettazione; nelle fasi di progettazione si raffinano le relazioni per rispettare le limitazioni dei linguaggi di programmazione.
  • Aggregazione vs composizione: differenza tra tutto/parte; composizione forte dove i componenti non esistono autonomamente; agrgegazione meno stretta; entrambe transitive e asimmetriche; presenza di parti e di livelli diversi (tuo/parte).
  • Classi collezione: gestione di insiemi di oggetti; ruoli relativi a gestione di collezioni; relazione con architetture basate su collezioni.
  • Relazioni reificate: alcune relazioni non sono direttamente rappresentabili in OO; si “reificano” come entità (es. iscrizione di studente a corso che può avere attributi come data iscrizione, voto).

Pagina 43-44-45-46-47

  • Relazioni in UML: associazioni, dipendenze, navigabilità; associazioni bidirezionali; classi di associazione; dipendenze di uso, astrazione e permesso; generalizzazione e specializzazione; diamante in ereditarietà multipla e l’uso dell’ereditarietà virtuale per evitare ambiguità.
  • Modello di modello: concetti di modello e meta-modello; MOF come meta-modello di UML; UML2 definisce struttura e regole dei modelli; polimorfismo come capacità di oggetti di assumere comportamenti differenti a seconda del contesto; Blue prints su come utilizzare i concetti OO in contesti diversi.
  • Problema della classe base fragile: cambiamenti nella classe base possono provocare effetti indesiderati su tutte le classi derivate; cause includono accoppiamento forte, dipendenze da implementazioni concrete, mancanza di controllo su override; mitigazioni: preferire composizione e interfacce, astrarre le classi base, non esporre dettagli interni, contratti espliciti e test approfonditi.
  • Strategie per mitigare la classe base fragile: composizione vs ereditarietà, interfacce astratte, standard di codifica, e contratti espliciti. Il tema è importante per ridurre i rischi di evoluzione del software.

Pagina 48-49-50-51-52

  • Polimorfismo, generalizzazione e uso efficiente dell’ereditarietà:
    • Polimorfismo permette di invocare comportamenti comuni senza conoscere la concreta implementazione; dinamico binding.
    • Generalizzazione (ereditarietà) va usata con cautela; problemi di diamante richiedono ereditarietà virtuale o alternative come composizione con interfacce.
    • Ereditarietà multipla: possono nascere problemi di coerenza se le superclassi non sono semanticamente disgiunte; molti linguaggi OO non la supportano o la gestiscono con meccanismi particolari.
  • Approcci alternativi all’ereditarietà: composizione vs delega, con meccanismi come delega (has-a vs is-a), che permette riuso senza rigidità di una gerarchia.
  • Condurre una progettazione orientata agli oggetti continua in modo disciplinato: preferire interfacce e composizione, utilizzare GRASP e altre anti-patterns per assegnare responsabilità.
  • Comunicazione e qualità del software: qualità è una proprietà del prodotto; si distinguono qualità esterne (per gli utenti) e qualità interne (per lo sviluppo); metriche per misurare qualità: funzionalità corretta, affidabilità, robustezza, efficienza, usabilità, verificabilità, manutenibilità, riusabilità, portabilità, comprensibilità, interoperabilità.

Pagina 53-54-55

  • Principi di buona progettazione: programmare contro le interfacce, non contro implementazioni; favorire la composizione rispetto all’ereditarietà; meccanismo di delega; definizione di interfacce chiare e contratti espliciti; gestione delle relazioni di progetto e di analisi con relazioni di aggregazione/composizione; relazioni di progettazione includono navigabilità e molteplicità.
  • Classi annidate e assegnazioni di responsabilità: gestione di eventi, gestione di layout; relazioni di analisi vs progettazione.
  • Aggregazione e composizione: definizioni e differenze; regole di costruzione delle relazioni; definizione di attributi e ruoli nelle associazioni;
  • Conclusione: le relazioni di progettazione spesso richiedono trasformazioni da quelle di analisi (associazioni) a relazioni di aggregazione/composizione e implementazioni di classi di associazione; navigabilità va definita dal lato “tutto” verso “parte”.

Pagina 56-57-58-59-60

  • Relazioni avanzate: relazioni reificate, associazioni molti-a-molti, associazioni bidirezionali; classi di associazione; modellazione della concorrenza in UML: classi attive (Thread) soprattutto nei sistemi embedded; diagrammi di attività con nodi azione, nodi controllo e nodi oggetto; nodi azione includono input, output, condizioni; nodi controllo definiscono flussi decisionali e fork/join; nodi oggetto rappresentano dati o oggetti interagenti; archi segnano flussi di controllo e di oggetti.
  • UML e requisiti software: ingegneria dei requisiti, definizione di requisiti software, processi, contenuti tipici (modello di dominio, modello dei requisiti, modello dei casi d’uso, descrizione dell’architettura).
  • Architettura software: fase di progettazione richiede decisioni su strutture, componenti, connettori; architettura descrive controllo e comunicazione; viene influenzata da requisiti non funzionali: performance, security, safety, availability, maintainability, etc.;
  • Stili architetturali comuni: Layered, Shared Memory, Dataflow, Implicit Invocation, Peer-to-Peer; ognuno ha vantaggi e svantaggi a seconda del dominio (es. Layered facilita sviluppo incrementale; Shared Memory semplifica la gestione dei dati ma può creare colli di bottiglia e affidabilità).
  • Architetture tipiche: Layered (Client-Server), Shared Memory (Repository), Shared Memory con regole (Rule Based), Dataflow Styles (Batch-Sequencial, Pipe and Filter), Implicit Invocation (Publish-Subscribe e Event Based), Peer-to-Peer.

Pagina 61-62-63-64

  • Requisiti software: definizioni/qualità e linguaggi di specifica; secondo IEEE 1220-1998, un requisito è una dichiarazione che identifica una caratteristica o vincolo operativo, funzionale o di progettazione; deve essere univoco, testabile o misurabile e necessario per l’accettazione del prodotto.
  • Caratteristiche dei requisiti: chiarezza, completezza, testabilità, necessità, tracciabilità.
  • Classificazione basata sui livelli di dettaglio e sull’output atteso: requisiti utente, requisiti di sistema; requisiti funzionali, requisiti non funzionali (qualitativi, es. performance, usabilità, affidabilità), requisiti di dominio e requisiti di interfaccia.
  • Tecniche di definizione dei requisiti: informali (linguaggio naturale), semi-formali (notazioni grafiche, UML, pseudocodice) e formali (modelli matematici); uso di linguaggio non ambiguo; definire vincoli (OCL); linguaggi di modellazione e profili UML per estendere la semantica.
  • Ambiguità del linguaggio naturale: lessicale, sintattica, semantica e pragmatica; esempi di ambiguità.
  • Esempi di requisiti: interfacce utente, requisiti di sicurezza, requisiti di internazionalizzazione, requisiti di disponibilità.

Pagina 65-66-67-68

  • Importanza dei requisiti: strutturano lo sviluppo; permettono di capire esigenze utili, controllano fallimenti di progetto, aiutano a guidare soluzioni e priorità; l’elicitazione dei requisiti è cruciale.
  • Processo di ingegneria dei requisiti non è uniforme: comprende studio di fattibilità, elicitation, analisi, validazione e gestione delle modifiche; include l’individuazione di stakeholder, l’interazione tra analisti e clienti; considerazioni sui processi cognitivi: rimozione, distorsione, generalizzazione; attenzione ai termini (to/very/always) e contesto.
  • Tecniche principali di elicitation: workshop (Brainstorming, KJ Method, scenari iterativi), interviste (standardizzate, esplorative, non strutturate), focus group, osservazione etnografica, questionari, perspective-based reading, ecc.
  • Fasi tipiche della preparazione/esecuzione/follow-up di workshop: definire obiettivi, moderatore, minute-taker; apertura, conduzione, chiusura; follow-up con verbale, eventuali gap, azioni di chiarimento.

Pagina 69-70-71

  • Focus su interviste: obiettivo di massimizzare l’espressione dell’intervistato; differenza tra interviste standardizzate, esplorative, non strutturate; gestione di luogo, domande e follow-up; attenzione all’influenza dell’intervistatore.
  • Altri metodi di elicitation: focus groups, osservazione, questionari, prospettiva su documenti, brainstorming, KJ Method; uso combinato a seconda del contesto.
  • Vantaggi e limiti degli strumenti di elicitation: le interviste e le tecniche collaborative portano a una raccolta migliore dei requisiti ma comportano costi e necessità di facilitazione; workshop e scenari sono efficaci per l’ideazione e la definizione collaborativa ma richiedono tempo e partecipazione.

Pagina 72-73-74-75

  • Formati e contenuti di requisiti: ID, Nome, Descrizione, Sorgente, Stato, Criteri di accettazione, Dipendenze, Priorità (MoSCoW). Il formato VOLERE come schema per la raccolta e gestione dei requisiti: Identificativo, Titolo, Tipologia (Funzionale, Non funzionale, Vincoli, Requisiti di transizione), Descrizione, Motivazione, Origine, Criteri di accettazione, Dipendenze, Priorità, Impatto, Tracciabilità.
  • Linguaggio e legibilità: usare linguaggio non tecnico dove possibile; spiegare i concetti con esempi/analogie; evidenziare ruoli e responsabilità; enfatizzare i requisiti con formati (grassetto, corsivo, colori) per scopi di documentazione.
  • Processo di gestione dei requisiti: differenza tra requisiti stabili vs volatili; originano tra stakeholder e contesto di business; gestione della variabilità tramite processi di gestione delle modifiche (gestione delle richieste, valutazione costi, approvazione, implementazione, monitoraggio).
  • Tecnologie CASE e strumenti di tracciabilità: repository centralizzato; tracciabilità automatizzata; versioning; generazione di report; definizione di matrici di tracciabilità tra sorgenti, requisiti, disegni, moduli, test, ecc.

Pagina 76-77-78-79-80

  • Strumenti e formati avanzati:
    • FORMAT VOLERE: definizione strutturata dei requisiti (ID, Titolo, Tipo, Descrizione, Motivazione, Origine, Criteri di accettazione, Dipendenze, Priorità, Impatto, Tracciabilità).
    • Esempi di contenuti: ID, Nome, Descrizione, Sorgente, Stato, Criteri di accettazione, Dipendenze, Priorità (MoSCoW), Impatto, Tracciabilità.
    • Use case e casi d’uso: differenze tra formato breve, informale e dettagliato; proporzione di utilizzi in UP (scrittura iniziale in ideazione, proseguendo in elaborazione); ruoli di baseline e incrementi.
  • Requisiti di modello e documentazione: linee guida su come strutturare i contenuti, come garantire coerenza e tracciabilità; uso di esempi pratici per requisiti utente e requisiti di sistema.

Pagina 81-82-83-84-85-86

  • Differenze tra requisiti e documentazione: esiste una tensione tra documentazione dettagliata e flessibilità necessaria nelle metodologie agili; i requisiti vengono spesso catturati in forma più leggera come User Stories, backlog e acceptance criteria.
  • Validazione dei requisiti: controlli di validità, consistenza, completezza, concretezza e verificabilità; tecniche di validazione includono revisioni, ispezioni, verifiche formali; obbiettivo è garantire che i requisiti siano efficaci e implementabili.
  • Gestione delle modifiche: processo di gestione delle modifiche per evitare destabilizzazione; definire fasi: raccolta, valutazione, approvazione/rifiuto, implementazione, monitoraggio; validare l’effetto delle modifiche con test e revisioni.
  • Tracciabilità: meccanismi di tracciabilità tra requisiti, specifiche, test e codice; uso di matrici o CASE tools; supporto all’analisi di impatto per cambiamenti.

Pagina 87-88-89-90-91-92

  • Petri Nets: modello matematico per descrivere sistemi dinamici e con concorrenza; componenti principali: Places (posizioni), Transitions, Arcs, Token, M0 (marcatura iniziale). Definizione formale: PN =

    PN = igl\langle P, T, F, W, M_0 \bigr\rangle
    dove P è l’insieme di posti, T transizioni, F relazione di flusso, W peso di F, M0 marcatura iniziale; esecuzione non deterministica: più transizioni possono essere abilitate contemporaneamente; comportamento dipende dall’ordine di attivazioni.

  • Diagrammi di attività (Activity Diagrams): modellano flussi di lavoro e azioni attraverso nodi azione, nodi controllo e nodi oggetto; relazioni con le regole di Petri (token, condizioni, pre/post-condizioni); elementi chiave: azioni, controllo, oggetti, condizioni di guardia.

  • Diagrammi di flusso di attività: nodi azione (operazioni), nodi controllo (decisoni, fork, join), nodi oggetto (dati) e archi di controllo/oggetti; regole di attivazione e postcondizioni; uso di pin per raggruppare attività e semplificare diagrammi.

  • GRASP (General Responsibility Assignment Software Patterns): insieme di pattern per assegnare responsabilità; esempi: Creator, Information Expert, Low Coupling, High Cohesion, Controller, Pure Fabrication, Indirection, etc.

  • RDD (Responsibility-Driven Development): progettazione guidata dalle responsabilità; definisce responsabilità delle classi in termini di “fare” e “conoscere”; iterare su assegnazioni tra classi per bilanciare coesione e accoppiamento.

  • Up-splash: le attività di design includono gerarchie di responsabilità, definizioni di classi di analisi e di progetto; l’obiettivo è avere classi coese e con basso accoppiamento; la transizione dall’analisi al progetto va pianificata.

Pagina 93-94-95-96-97-98-99-100

  • Dettagli sui pattern GRASP:
    • Creator: assegna la responsabilità di creare nuove istanze; criteri: chi contiene o aggrega oggetti di tipo A, chi possiede dati iniziali per creare A; vantaggi: basso accoppiamento; controindicazioni: può essere complesso e portare a eccessiva creazione.
    • Information Expert: assegna responsabilità all’oggetto che possiede le informazioni necessarie; LR-G (Low Representation Gap) come motivazione; scarsa coesione e potenziali accoppiamenti elevati se si esagera.
    • Low Coupling: riduzione dell’accoppiamento tra classi; supporta riuso e flessibilità; controindicazioni: potrebbe essere necessario un certo accoppiamento per interfacce stabili.
    • High Cohesion: mantenere responsabilità strettamente correlate; controindicazioni: potrebbe richiedere più planning o complessità.
    • Controller: responsabilità di gestione di eventi di sistema; evita che l’interfaccia utente gestisca direttamente la logica; controindicazioni: i controller possono diventare molto complessi (gonfi).
    • Pure Fabrication: creazione di classi non appartenenti al dominio per mantenere alta coesione e basso accoppiamento; rischi di separazione errata dalle similitudini funzionanti; vantaggi: riuso.
    • Delega (Indirection): mediazione tra due oggetti via intermediario per ridurre accoppiamento; esempi di pattern: Adapter, Façade, Observer, Proxy; controindicazioni: introduzione di livello di astrazione che può rendere il flusso di controllo meno chiaro.
    • Protected Variations: proteggere le variazioni degli elementi tramite un’interfaccia stabile; trasformazione in un guscio protetto; vantaggi: riuso e manutenibilità, ma potrebbe introdurre complessità.
  • Qualità software: definizione (proprietà, caratteristiche); suddivisioni: qualità del prodotto (internal vs external) e qualità di processo; metriche: come misurare qualità (funzionalità, affidabilità, robustezza, efficienza, usabilità, verificabilità, manutenibilità, riusabilità, portabilità, comprensibilità, interoperabilità).
  • Architettura e qualità QoS: qualità di servizio è influenzata da architetture; obiettivi di qualità includono performance, security, safety, availability, maintainability, portability, etc.; l’architettura può essere scelta per supportare QoS tramite layering, dataflow patterns, e other decisions.

Pagina 101-102-103-104-105-106-107-108-109-110-111-112-113-114-115-116-117-118-119-120

  • Qualità del software (continua):
    • Metriche: una metrica è una quantità misurabile che consente di definire quanto un software o processo soddisfi una proprietà; misurazioni possono essere dirette o indirette; i fattori ambientali o soggettivi degli utenti possono influenzare le misure; è necessario definire un processo di misurazione accurato per garantire confrontabilità tra misure.
    • Requisiti qualitativi: suddivisi in requisiti di prodotto (funzionali e non funzionali), requisiti organizzativi, requisiti esterni e requisiti di interfaccia; le metriche possono variare a seconda del dominio (es. SIS – sistemi software-intensivi).
    • Metriche specifiche: corretta conformità funzionale (functional compliance), affidabilità (MTBF), robustezza, efficienza, usabilità, verificabilità, manutenibilità, riusabilità, portabilità, comprensibilità, interoperabilità.
    • Allied topics: processi di verifica e validazione (V&V): ispezioni statiche, testing dinamico, unit/static tests, validazione dell’utente, alpha/beta testing; debugging e gestione dei difetti con tecniche di correzione, rintracciabilità e gestione delle modifiche.
    • Evoluzione del software e costi: le fasi di specifica, progettazione, implementazione, manutenzione hanno costi variabili; l’evoluzione continua a incidere sui costi complessivi, con una rapportata enfasi sul mantenimento e sull’adattamento ai requisiti.
  • L’importanza della gestione dell’architettura: le decisioni architetturali hanno impatti sul QoS, tra cui performance, security, safety, availability, maintainability; le architetture “layered” e altre pattern influenzano la manutenibilità e l’evoluzione.
  • Riepilogo concettuale: la disciplina implica gestione di requisiti, progettazione, implementazione, test e manutenzione; le metodologie moderne (UP, Scrum, Spiral) sono implementazioni diverse ma condividono valori come gestione iterativa e gestione dei rischi; l’obiettivo è fornire una base per lo sviluppo di sistemi software complessi e affidabili, con una gestione efficiente di requisiti volatili e una architettura solida.