Con il termine "ingegneria del software" si intende quella disciplina che si occupa dei processi produttivi e delle metodologie di sviluppo finalizzate alla realizzazione di sistemi software. In questa pagina viene presentata una panoramica sugli obiettivi dell'ingegneria del software in riferimento alle principali aree in cui questa disciplina può essere suddivisa.
L'ingegneria del software si propone una serie di obiettivi legati all'evoluzione dello sviluppo del software (inteso come attività industriale) sia da un punto di vista tecnologico che metodologico.
Una definizione più formale dell'ingegneria del software è quella data dall'IEEE
Il testo di riferimento per lo studio dell'ingegneria del software è lo SWEBOK (Software Engineering Body Of Knowledge). Si tratta di un documento pubblicato da un apposito comitato fondato dai maggiori enti internazionali sulla materia (IEEE e ACM). Esso identifica dieci aree della conoscenza relative all'ingegneria del software. Di seguito vengono elencate tali aree e tra parentesi viene fornito un esempio di argomento di interesse per quel'area:
L'ingegneria del software identifica una formalizzazione del processo di realizzazione e di manutenzione di un sistema informativo. Si parla spesso di "ciclo di vita" di un software, concetto che ha assunto con il passare dei decenni un'importanza sempre più elevata, spostando l'idea di software come manufatto verso un'idea di prodotto industriale.
Una definizione più formale dell'ingegneria del software è quella data dall'IEEE
Computer Society che definisce questa disciplina come:
- L’applicazione di un sistematico, disciplinato e quantificabile approccio allo sviluppo, all’operatività e alla manutenzione del software;
- Lo studio degli approcci definiti al punto precedente.
Il testo di riferimento per lo studio dell'ingegneria del software è lo SWEBOK (Software Engineering Body Of Knowledge). Si tratta di un documento pubblicato da un apposito comitato fondato dai maggiori enti internazionali sulla materia (IEEE e ACM). Esso identifica dieci aree della conoscenza relative all'ingegneria del software. Di seguito vengono elencate tali aree e tra parentesi viene fornito un esempio di argomento di interesse per quel'area:- Requisiti del software (ad es., raccolta e specifica dei requisiti)
- Progettazione del software (ad es., progettazione orientata agli oggetti, architetture software, progettazione architetturale, architettura dei sistemi distribuiti, architetture applicative, ingegneria del software basata su componenti)
- Costruzione del software (ad es., programmazione orientata agli oggetti)
- Verifica del software (ad es., tecniche di test)
- Manutenzione del software (ad es., reverse engineering)
- Gestione delle configurazioni del software (ad es., gestione e rilascio di versioni del software)
- Gestione dell'ingegneria del software (ad es., pianificazione di progetti software)
- Processi dell'ingegneria del software (ad es., definizione e gestione di processi software, come ad esempio UP)
- Strumenti e metodi dell'ingegneria del software (ad es., strumenti CASE)
- Qualità del software (ad es., processi per la gestione della qualità del software).
L'ingegneria del software identifica una formalizzazione del processo di realizzazione e di manutenzione di un sistema informativo. Si parla spesso di "ciclo di vita" di un software, concetto che ha assunto con il passare dei decenni un'importanza sempre più elevata, spostando l'idea di software come manufatto verso un'idea di prodotto industriale.
La necessità di creare una scienza che si occupi della realizzazione dei sistemi informativi nasce dalla necessità di sviluppare prodotti sempre più complessi ed evoluti che rispondano a esigenze di correttezza del processo realizzativo e di facile manutenzione.
Il software come prodotto industriale diventa anche oggetto di un attento esame per estendere le capacità di realizzazione dello stesso. Si cercano quindi di identificare nella realizzazione del software, quegli obbiettivi a cui tengono le industrie del software, come qualità del software realizzato e soprattutto di rilasciare un prodotto perfettamente documentato e facilmente "manutenibile". L'ingegneria del software, si preoccupa effettivamente di concretizzare queste esigenze, cercando di definire modelli che permettano a team di tecnici di realizzare in cooperazione prodotti sempre più evoluti e di qualità.
L'ingegneria del software definisce quindi un insieme di processi, ovvero sequenze di fasi che individuano tappe specifiche nella realizzazione di un sistema software tutte documentate e ispezionabili, che offrano in sostanza perfetta visibilità alla diversa tipologia degli utenti del sistema, per il controllo dei singoli prodotti e/o per l'eventuale manutenzione.
Requisiti del software
A mio avviso, una delle cose più difficili è spiegare a qualcuno che cos'è un requisito software. In questi anni sono state coniate numerose definizioni da varie organizzazioni e da numerosi esperti di ingegneria del software. Quella che secondo me descrive meglio che cos'è un requisito è quella formulata da Alan Davis nel 2005:
Nel 2006, Robert Martin, affermò che: "Ciò che non è testabile non serve. Se avete un requisito e non potete provare di averlo soddisfatto, allora non è un requisito". Questa frase completa la definizione di requisito in quanto chiarisce il concetto di "osservabile dall'esterno" presente nella definizione di Davis.
Sebbene sia di importanza decisiva soprattutto nelle fasi iniziali di un progetto, si tratta di un processo che accompagna tutto il ciclo di vita del software. Gestire i requisiti significa in sostanza:
"Un requisito è una caratteristica di un sistema desiderato,
osservabile dall’esterno."
osservabile dall’esterno."
Nel 2006, Robert Martin, affermò che: "Ciò che non è testabile non serve. Se avete un requisito e non potete provare di averlo soddisfatto, allora non è un requisito". Questa frase completa la definizione di requisito in quanto chiarisce il concetto di "osservabile dall'esterno" presente nella definizione di Davis.
La Gestione dei Requisiti è determinante per il miglioramento dello sviluppo del software e per il successo dei progetti. Infatti è raccomandata come prima "key process area" nel Capability Maturity Model del SEI e dalle linee guida ISO 9I requisiti devono essere documentati ed espressi in modo coerente, non ambiguo e verificabile.
La specifica dei requisiti deve essere chiara sia per gli utenti che per i progettisti.
La documentazione deve essere facilmente accessibile per tutti gli attori coinvolti (team di progetto, committenti, utenti).000.
La specifica dei requisiti deve essere chiara sia per gli utenti che per i progettisti.
La documentazione deve essere facilmente accessibile per tutti gli attori coinvolti (team di progetto, committenti, utenti).000.
La Gestione dei Requisiti è stata ideata principalmente per migliorare lo sviluppo del software, ridurre i costi e i rischi correlati alla sua costruzione.
Sebbene sia di importanza decisiva soprattutto nelle fasi iniziali di un progetto, si tratta di un processo che accompagna tutto il ciclo di vita del software. Gestire i requisiti significa in sostanza:
- Definire i requisiti
- Scoprire i requisiti: Si tratta di indagare le necessità dei clienti / utenti e determinare i requisiti che possono essere opportunamente implementati nel sistema per soddisfare tali necessità.
La tecnica principale per la scoperta dei requisiti consiste nell'identificazione dei casi d'uso, ovvero delle modalità di utilizzo del sistema da parte dei suoi utilizzatori (attori) per eseguire specifiche funzionalità del sistema stesso; - Analizzare i requisiti: Si tratta di analizzare, raffinare e valutare i requisiti raccolti in modo da assicurarsi che siano comprensibili per tutti gli stakeholder ed individuare eventuali errori, omissioni o altre carenze.
L'obiettivo è quello di sviluppare i requisiti a livelli di qualità e di dettaglio sufficienti per poter formulare una o più ipotesi di soluzione per il prodotto da realizzare, effettuare stime realistiche del progetto e procedere con la progettazione e la realizzazione del prodotto stesso; - Specificare i requisiti: I requisiti devono essere documentati ed espressi in modo coerente, non ambiguo e verificabile. La specifica dei requisiti deve essere chiara sia per gli utenti che per i progettisti. La documentazione deve essere facilmente accessibile per tutti gli attori coinvolti (team di progetto, committenti, utenti).
- Verificare i requisiti: Occorre effettuare con i clienti una revisione dei requisiti documentati, per esaminarne l'accuratezza e la completezza, prima di procedere all'approvazione degli stessi.
- Gestire l'evoluzione dei requisiti
- Gestire l'evoluzione dei requisiti richiede la definizione di un vero e proprio processo di controllo e approvazione delle modifiche richieste. Le principali attività richieste sono:
- mantenere traccia e storia di ogni requisito e delle sue variazioni
- determinare quali dipendenze tra i requisiti sia utile tracciare
- stabilire relazioni di tracciabilità tra i requisiti e i casi d'uso, tra i casi d'uso e i prodotti dello sviluppo
- gestire la versione dei requisiti.
Di seguito alcuni riferimenti utili per la comprensione e la gestione dei requisiti:
- Nel seguente link troverete una guida ricca di domande ed esempi per individuare i requisiti software: Requisiti-by-Example
- Un template di documentazione requisiti per progetti in cui sia necessaria poca formalità: template-doc-requisiti
- Lo standard ISO 25010 per la classificazione dei requisiti. FOCUS-TBD
Progettazione del software
(ad es., progettazione orientata agli oggetti, architetture software,
Costruzione del software
(ad es., programmazione orientata agli oggetti)ù
Verifica del software
(ad es., tecniche di test)
Manutenzione del software
(ad es., reverse engineering)
Gestione delle configurazioni del software
(ad es., gestione e rilascio di versioni del software)
Gestione dell'ingegneria del software
(ad es., pianificazione di progetti software)
Processi dell'ingegneria del software
(ad es., definizione e gestione di processi software, come ad esempio UP)
Strumenti e metodi dell'ingegneria del software
(ad es., strumenti CASE)
Qualità del software
(ad es., processi per la gestione della qualità del software).
Post
