Ingegneria del Software

Committente, avendo a disposizione

Committente, avendo a disposizione volta comprende un certo numero di attività.

Ciclo di vita di un software

Funzionalità minime ha la possibilità di - Guidato dai requisiti: basato quindi sugli concentrare i propri sforzi sul use cases.

• Definizione: definizione dei requisiti di raggiungimento di un grado di precisione - Modellabile visualmente: si può usare sistema, delle funzionalità relative ai ruoli di elevata. Documentare il SW con questo UML sistema, dei vincoli da rispettare. modello richiede meno sforzo organizzativo.
• Quality assessment built-in nel processo: la progettazione (design): strutturazione proprio per le brevi fasi di impl. / trasf. qualità cioè deve essere costruita man dell'architettura relativamente alle. Svantaggi: lo sforzo implementativo e di mano che il modello progredisce nelle varie componenti ed alle interfacce. revisione a livello di tempi diviene molto iterazioni, in modo tale da raggiungere la.
• Implementazione: sviluppo del codice e critico, in quanto nelle fasi successive al maturità nel più breve tempo possibile. Testing dei moduli, assemblaggio e primo progetto, si deve continuamente macrotesting. Lavorare oltre che all'ampliamento anche UML (Unified Modeling Language).
• Consegna: test di accettazione da parte alla revisione del lavoro precedente. Definisce diversi tipi di modello di cui i principali sono i seguenti (si chiamano del cliente e revisione.
• Evolutivo: basato su un waterfall ridotto a Il processo di sviluppo del SW è costituito formalismi grafici) livello di tempo, iterato fino al da tutto quanto è necessario per la raggiungimento delle specifiche finali, a creazione di sistemi di qualità a partire.

1. Classi e relazioni (CR)
2. Use cases
3. Attività
4. Stati
5. Oggetti
6. Sequenza
7. Collaborazione

Partire da un gruppo di requirements iniziali. Magari da una soluzione iniziale. La qualità 2. Use cases Vantaggi: permette un raffinamento dei di un prodotto dipende dalla qualità del 3. Attività modelli tramite prototipazione, molto utile processo produttivo. 4. Stati dal punto di vista dell'utente finale. È molto 5. Oggetti utile nel caso in cui i requisiti siano piuttosto.

Un processo di creazione del SW è un 6. Sequenza mutevoli. Insieme di attività, metodi, pratiche, e 7. Collaborazione Svantaggi: la semplicità di trasformazioni che le persone utilizzano per documentazione è ridotta rispetto allo sviluppo e la revisione del SW e delle Definisce praticamente 12 tipi di diagrammi, all'incrementale, in quanto le varie fasi di attività correlate (es. piani di progetto, divisi in 3 categorie: iterazione costringono all'integrazione delle progetto di documenti, codice, test cases documentazioni esistenti. ecc).

Prototipazione

Tipi di cicli di sviluppo di componente.

È una parziale implementazione di un - Diagrammi Strutturali: sono delle sistema, che aiuta l'utente finale a definizioni statiche di applicazioni, ed comprendere le funzionalità. includono i diagrammi di classe, di oggetto.

• Semplice: si codificano i requisiti e si sistema, che aiuta l'utente finale a definizioni statiche di applicazioni, ed debugga finché il tutto non funziona. Comprenderne le funzionalità. Includono i diagrammi di classe, di oggetto.

Vantaggi: tempo di startup ridotto al recupero dei requisiti), diagramma di minimo indispensabile, si può lavorare - Usa e getta: può essere utile per validare sequeza, diagramma di attività, diagramma direttamente.

Svantaggi: seri problemi di revisione, di un'interfaccia grafica o per testare le di collaborazione, e statechart diagram. Documentazione differita delle revisioni potenzialità di architetture difficilmente - Diagrammi di Management dei modelli: stesse ecc. riproducibili in scala completa, senza includono packages, sottosistemi e modelli.

Waterfall

Waterfall: approccio di tipo strettamente gerarchizzato, mirato a partire dalla definizione dei requisiti, progettazione, implementazione, trasferimento, ed operatività. Nelle fasi intermedie sono presenti delle consegne da parte di persone, e tutto il lavoro relativo ad ogni fase viene svolto da personale specializzato. Alla fine dell'implementazione vi è una consegna del SW nella versione originale, mentre la fase di operatività risente di un non perfetto bilanciamento in termini di tempo rispetto alle altre (troppo lunga).

Vantaggi: è molto semplice da utilizzare, in quanto la specializzazione permette una facile gestione delle competenze e dei ruoli.

Svantaggi: le fasi sono rigide e realizzate da personale specializzato. Nel momento in cui viene scoperto un baco in una fase preliminare in seguito alla consegna, è molto difficile riuscire a ripristinare il lavoro senza dover modificare una ingente mole di dati, e senza dover rovinare la torta a qualcuno. Difficile da conciliare la documentazione specifica emessa in ciascuna delle fasi. La visione tayloristica è poco versatile al momento della revisione.

Incrementale

Incrementale: simile alla waterfall rispetto al taylorismo delle fasi ma incrementale nel lavoro a livello di consegna in cui si considera l'implementazione corrente. Si passa da un'implementazione minima iniziale ad una sottoposta al testing, per un raffinamento ed un ampliamento progressivo nel tempo.

Vantaggi: lo sviluppo e la consegna sono incrementali, quindi risentono minimamente degli errori commessi, facilmente individuabili e correggibili nel processo.

Svantaggi: lo sforzo implementativo e di revisione a livello di tempi diviene molto critico, in quanto nelle fasi successive al progetto, si deve continuamente lavorare oltre che all'ampliamento anche alla revisione del lavoro precedente.

Evolutivo

Evolutivo: basato su un waterfall ridotto a livello di tempo, iterato fino al raggiungimento delle specifiche finali, a partire da un gruppo di requirements iniziali.

Vantaggi: permette un raffinamento dei modelli tramite prototipazione, molto utile dal punto di vista dell'utente finale. È molto utile nel caso in cui i requisiti siano piuttosto mutevoli.

Svantaggi: la semplicità di documentazione è ridotta rispetto all'incrementale, in quanto le varie fasi di iterazione costringono all'integrazione delle documentazioni esistenti.

Prototipazione usa e getta ed evoluzionaria

Usa e getta: può essere utile per validare un'interfaccia grafica o per testare le potenzialità di architetture difficilmente riproducibili in scala completa, senza sostenere dei costi molto ingenti di prototipazione.

Evoluzionario: capace di essere modificato nel tempo e somministrato nella sua interezza alla fine del processo evolutivo. Non è particolarmente rapido e può essere molto oneroso.

Verifica & Validazione

• Verifica: controllo della conformità rispetto ai requisiti.
• Validazione: conformità rispetto alle attese del committente.

Rational Unified Process (RUP)

Fasi: Inception (concezione) [INITIAL], Elaborazione [ELAB1+2], Costruzione [CONSTR1+2+3], Transizione [TRANS1+2], vengono riportate sulle ascisse.

Discipline: Business modeling, requirements, analysis & design, implementation test, Deployment, Configuration & Change management, Project management, Environment ecc. (riportate sulle ordinate).

Le varie discipline assumono ruoli e importanze differenti a seconda della fase in cui si considera il loro contributo.

Ogni tipo di attività è dedicata soprattutto a una fase ma partecipa anche se in modo trascurabile alle altre.

Iterativo ed incrementale: in quanto si procede per fasi e ad ogni fase si raggiunge una milestone, comprendendo un certo numero di attività.

Agile Software Development

• Individui ed interazioni al di sopra dei processi e degli strumenti.
• SW funzionante prima della documentazione comprensibile.
• Collaborazione dei consumatori al di sopra della negoziazione dei contratti.
• Risposta alle modifiche prima di ogni pianificazione possibile.

Model Driven Development

È la concezione di un modello di costruzione del SW basato sull'utilizzo di punti di vista astratti, trasformati in seguito in codice funzionante sia tramite l'utilizzo dell'automazione, sia manualmente. Questo tipo di discorso può introdurre dei fattori di crescente produttività e TTM ristretti, abilitando il lavoro ad alto livello in modo tale da rendere più facile la descrizione del SW a chi in realtà non è un esperto del settore.

Molto spesso la modellizzazione è basata sulla rappresentazione grafica delle informazioni tramite immagini, diagrammi ecc.

Nel momento in cui i modelli hanno una semantica operazionale, possono essere facilmente trasformati in prototipi, o in porzioni di applicazione.

Il principio fondamentale è quello di scrivere meno codice a mano, riutilizzando possibilmente quello che è stato già consolidato e testato in passato.

Analisi dei requisiti

Un requisito software è: