Appunti di Ingegneria del software

Svantaggi

La divisione inflessibile del progetto in fasi distinte rende difficile rispondere alle mutevoli esigenze dei clienti. Pertanto, questo modello è appropriato solo quando i requisiti sono ben compresi e le modifiche saranno piuttosto limitate durante il processo di progettazione.

Si tenga anche conto del fatto che il ritorno ad una fase precedente costa tanto di più indietro verso fasi precedenti si deve ritornare. Pochissimi sistemi aziendali hanno requisiti stabili.

Il modello a cascata viene utilizzato principalmente per grandi progetti di ingegneria dei sistemi in cui un sistema viene sviluppato in diversi siti. In queste circostanze, la natura pianificata del modello a cascata aiuta a coordinare il lavoro.

Prototyping

Questo approccio intreccia le attività di specifica, sviluppo e convalida. Il sistema viene sviluppato come una serie di versioni (incrementi), ciascuna delle quali aggiunge nuove funzionalità alla versione precedente.

Ciascun incremento o

1. La versione del sistema incorpora qualcuna delle funzionalità richieste dal cliente.
2. In generale, gli incrementi iniziali del sistema includono la funzionalità più importante e urgente richiesta dal cliente.
3. Questo significa che il cliente o l'utente può valutare il sistema nelle prime fasi dello sviluppo per vedere se esso realizza ciò che è stato richiesto.
4. In caso contrario, deve essere modificato soltanto l'incremento corrente del sistema e, possibilmente, dovrà essere definita una nuova funzionalità per i successivi incrementi.

Prototyping esplorativo

L'obiettivo è lavorare con i clienti e far evolvere un sistema finale da delle specifiche iniziali. Dovrebbe iniziare con requisiti ben compresi, iniziando quindi da ciò che è chiaro e cercando di capire il resto.

Prototyping usa e getta

L'obiettivo è comprendere i requisiti di sistema (o un aspetto tecnico). Dovrebbe iniziare con

In grado di utilizzare e valutare il software prima di quanto sia possibile con un processo a cascata.

SVANTAGGI

• Il processo non è visibile. I manager devono avere delle consegne regolari per misurare i progressi.
• Se il sistema è sviluppato velocemente, non è economico produrre documentazione che rifletta ogni versione del sistema.
• La struttura dei sistemi tende a degradarsi quando vengono aggiunti nuovi incrementi. Ogni volta che viene aggiunta una nuova funzionalità, il codice diventa sempre più complicato, quindi diventa sempre più difficile e costoso aggiungere nuove funzionalità a un sistema. Per ridurre il livello di degrado strutturale e di complicazione del codice, i metodi agili suggeriscono un costante refactoring (miglioramento della struttura) del software.

193. Hybrid

Combinazione di modelli: un ciclo di vita waterfall con attività prototyping dove necessario.

4. Sviluppo di sistemi formali

Quando formulo le specifiche mediante un

linguaggio matematico che so via via trasformare inversioni successive che mi portano ad una descrizione di questa trasformazione in termini di un programma eseguibile e quindi garantisco che le specifiche siano contenute nel risultato. Una bella idea, ma di attuazione praticamente molto limitata, difficile, se non di fatto impossibile.

Formal transformations

T1 T2 T3 T4

Formal Executable

R1 R2 R3

specification program

P1 P2 P3 P4

Proofs of transformation correctness

PROBLEMI

Necessità di competenze specialistiche e formazione per applicare la tecnica. Difficile specificare formalmente alcuni aspetti del sistema come l'interfaccia utente e i sistemi interattivi in generale. Si riesce a fare per problemi 'giocattolo' e non per sistemi complessi.

APPLICABILITÀ

Sistemi critici, specialmente quelli in cui è necessario creare un caso di sicurezza prima che il sistema venga messo in funzione.

5. Sviluppo orientato al riutilizzo (basato su componenti)

Si basa sul semplice

consegna incrementale oa fasi.- Combina il Waterfall con il modello prototyping;

piuttosto che fornire il sistema come una singola consegna, lo sviluppo e la consegna sono suddivisi in incrementi (cioè un sottosistema dell'intero sistema, chiamato anche rilasci) con ogni incremento che fornisce parte della funzionalità richiesta;

ai requisiti degli utenti viene data la priorità e i requisiti con la priorità più alta sono inclusi nei primi incrementi;

una volta avviato lo sviluppo di un incremento, i suoi requisiti vengono congelati sebbene i requisiti e gli incrementi successivi possano continuare a evolversi.

Design system

Define outline

Assign requirements

requirements architecture

to increments

Integrate

Validate

Develop system

Validate increment

System incomplete

Rischio

La possibilità di perdite, lesioni o altre circostanze avverse o indesiderate, corrisponde ad una mancanza di informazione. Si utilizza

L'analisi dei rischi come strumento di decision making per procedere nello sviluppo di un progetto.

Modello risk-driven denominato modello a spirale (proposto da Barry Bohem - 1988).

• sviluppo a spirale: più un approccio generale che un modello specifico di ciclo di vita
• Il processo è rappresentato come una spirale piuttosto che come una sequenza di attività con backtracking
• Ogni anello della spirale rappresenta una fase del processo.
• Nessuna fase fissa come la specifica o il progetto: i loop nella spirale vengono scelti in base a ciò che è richiesto
• I rischi vengono esplicitamente valutati e risolti durante tutto il processo
• Si parte dalle attività che hanno il più alto livello di rischio.

Determine objectives Evaluate alternatives alternatives and identify, resolve risks constraints Risk analysis Risk analysis Risk Opera-analysis Prototype 3 tional protoype Prototype 2 Risk Proto-analysis REVIEW type 1 Requirements plan Simulations, models,

1. benchmarks
2. Life-cycle plan
3. Concept of Operation
4. S/W Product requirements
5. Detailed design
6. Design Requirement Development
7. Validation plan
8. Code Unit test Design
9. Integration V&V
10. Integration and test plan
11. Plan next phase test
12. Acceptance test
13. Develop, verify Service next-level product

Cause per cui un progetto di sviluppo software può fallire:

• Requisiti incompleti / vaghi, conflitti con le parti interessate
• Mancanza di coinvolgimento dell'utente, scarso input dell'utente
• Mancanza di risorse, abilità che non corrispondono al lavoro
• Aspettative non realistiche
• Scarsa gestione del progetto, pianificazione o stima dei costi
• Scarso supporto esecutivo
• Mancanza di comunicazione
• Modifica dei requisiti e delle specifiche
• Architettura scadente
• Rilevamento dei segnali di avviso di guasto in ritardo

Software project management

Un progetto (project) consiste, in senso generale, nell'organizzazione di azioni nel tempo per il perseguimento di uno scopo predefinito, attraverso le

Organizzazioni che sviluppano e acquistano il software. Inoltre, mantengono un team di sviluppo "felice" e "ben funzionante". La gestione del progetto è necessaria perché lo sviluppo del software è sempre soggetto a vincoli di budget e pianificazione stabiliti dall'organizzazione che sviluppa il software.

Distinzioni di gestione del software rispetto ad altre tecnologie:

• Il prodotto è immateriale
• Il prodotto è straordinariamente flessibile
• L'ingegneria del software non è riconosciuta come disciplina ingegneristica con lo stesso status dell'ingegneria meccanica, elettrica, ecc. ma più come programmatore.