Riferimento: Sommerville, Software Engineering, 10 ed., Chapter 2

Un processo software è un insieme strutturato di attività necessarie per sviluppare un sistema software. Si noti che stiamo parlando di un “processo software” — non di un “processo di sviluppo software.”

Ci sono molti tipi diversi di processi software, ma ognuno di essi coinvolge questi quattro tipi di attività fondamentali:

• Specifica del software – definire ciò che il sistema dovrebbe fare;
• Progettazione e implementazione del software – definire l’organizzazione del sistema e implementare il sistema;
• Convalida del software – controllare che faccia ciò che il cliente vuole;
• Evoluzione del software – cambiare il sistema in risposta al cambiamento delle esigenze del cliente.

Un modello di processo software è una rappresentazione astratta di un processo. Presenta una descrizione di un processo da una prospettiva particolare. Quando descriviamo e discutiamo i processi software, di solito parliamo delle attività in questi processi come specificare un modello di dati, progettare un’interfaccia utente, ecc. e l’ordine di queste attività.Le descrizioni dei processi possono anche includere:

• Prodotti, che sono i risultati di un’attività di processo;
• Ruoli, che riflettono le responsabilità delle persone coinvolte nel processo;
• Pre- e post-conduzioni, che sono dichiarazioni che sono vere prima e dopo che un’attività di processo è stata attuata o un prodotto prodotto prodotto.

I processi guidati dal piano sono processi in cui tutte le attività del processo sono pianificate in anticipo e il progresso è misurato rispetto a questo piano. Nei processi agili, la pianificazione è incrementale ed è più facile cambiare il processo per riflettere le mutevoli esigenze del cliente. In pratica, la maggior parte dei processi pratici include elementi di entrambi gli approcci pianificati e agili.

Il modello a cascata Modello guidato dal piano. Fasi separate e distinte di specificazione, progettazione del software, implementazione, test e manutenzione. Sviluppo incrementale Le specifiche, lo sviluppo e la validazione sono intrecciati. Il sistema è sviluppato come una serie di versioni (incrementi), con ogni versione che aggiunge funzionalità alla versione precedente. Può essere guidato dal piano o agile. Integrazione e configurazione Basato sull’esistenza di un numero significativo di componenti/sistemi riutilizzabili. Il processo di sviluppo del sistema si concentra sull’integrazione di questi componenti in un sistema piuttosto che svilupparli da zero. Può essere guidato dal piano o agile.

In pratica, la maggior parte dei grandi sistemi sono sviluppati usando un processo che incorpora elementi di tutti questi modelli.

Ci sono fasi separate identificate nel modello a cascata:

Analisi e definizione dei requisiti I servizi, i vincoli e gli obiettivi del sistema sono stabiliti consultando gli utenti del sistema. Sono poi definiti in dettaglio e servono come specifica di sistema. Progettazione del sistema e del software Il processo di progettazione dei sistemi assegna i requisiti ai sistemi hardware o software stabilendo un’architettura generale del sistema. La progettazione del software comporta l’identificazione e la descrizione delle astrazioni fondamentali del sistema software e le loro relazioni. Implementazione e test delle unità Durante questa fase, il design del software viene realizzato come un insieme di programmi o unità di programma. Il test delle unità comporta la verifica che ogni unità soddisfi le sue specifiche. Integrazione e test del sistema Le singole unità di programma o i programmi sono integrati e testati come un sistema completo per assicurare che i requisiti del software siano stati soddisfatti. Dopo il test, il sistema software viene consegnato al cliente. Funzionamento e manutenzione Normalmente (anche se non necessariamente), questa è la fase del ciclo di vita più lunga. Il sistema viene installato e messo in uso pratico. La manutenzione comporta la correzione degli errori che non sono stati scoperti nelle fasi precedenti del ciclo di vita, il miglioramento dell’implementazione delle unità del sistema e il potenziamento dei servizi del sistema man mano che vengono scoperti nuovi requisiti.

Il principale svantaggio del modello a cascata è la difficoltà di accogliere i cambiamenti dopo che il processo è in corso. In linea di principio, una fase deve essere completata prima di passare alla fase successiva. I problemi del modello a cascata includono:

Difficile affrontare il cambiamento La partizione inflessibile del progetto in fasi distinte rende difficile rispondere ai requisiti del cliente che cambiano.Pertanto, questo modello è appropriato solo quando i requisiti sono ben compresi e i cambiamenti saranno abbastanza limitati durante il processo di progettazione. Pochi sistemi di business hanno requisiti stabili. Poche applicazioni nel mondo reale Il modello a cascata è usato per lo più per grandi progetti di ingegneria dei sistemi dove un sistema è sviluppato in diversi siti.In queste circostanze, la natura guidata dal piano del modello a cascata aiuta a coordinare il lavoro.

Benefici dello sviluppo incrementale:

Basso costo dei cambiamenti Il costo di accomodare i requisiti del cliente che cambiano è ridotto. La quantità di analisi e documentazione che deve essere rifatta è molto inferiore a quella richiesta dal modello a cascata. Feedback frequente È più facile ottenere il feedback del cliente sul lavoro di sviluppo che è stato fatto. I clienti possono commentare le dimostrazioni del software e vedere quanto è stato implementato. Consegna più rapida È possibile una consegna più rapida e la distribuzione di software utile al cliente. I clienti sono in grado di usare e ottenere valore dal software prima di quanto sia possibile con un processo a cascata.

Problemi con lo sviluppo incrementale (dal punto di vista della gestione):

Il processo non è visibile I manager hanno bisogno di deliverable regolari per misurare i progressi. Se i sistemi sono sviluppati rapidamente, non è conveniente produrre documenti che riflettono ogni versione del sistema. La struttura del sistema tende a degradarsi man mano che vengono aggiunti nuovi incrementi Se non si spende tempo e denaro nel refactoring per migliorare il software, il cambiamento regolare tende a corrompere la sua struttura. Incorporare ulteriori modifiche al software diventa sempre più difficile e costoso.

Questo approccio è basato sul riuso sistematico dove i sistemi sono integrati da componenti esistenti o sistemi COTS (Commercial-off-the-shelf).Le fasi del processo includono:

• Analisi dei componenti;
• Modifica dei requisiti;
• Design del sistema con riutilizzo;
• Sviluppo e integrazione.

Il riuso è ora l’approccio standard per costruire molti tipi di sistemi aziendali.

Tipi di componenti software:

• Servizi web che sono sviluppati secondo standard di servizio e che sono disponibili per l’invocazione remota.
• Collezioni di oggetti che sono sviluppati come un pacchetto da integrare con un framework di componenti come .NET o J2EE.
• Sistemi stand-alone commercial-off-the-shelf (COTS) che sono configurati per l’uso in un particolare ambiente.

I processi software reali sono sequenze intrecciate di attività tecniche, collaborative e manageriali con l’obiettivo generale di specificare, progettare, implementare e testare un sistema software.

Le quattro attività di base del processo di specificazione, sviluppo, validazione ed evoluzione sono organizzate diversamente nei diversi processi di sviluppo. Nel modello a cascata, sono organizzate in sequenza, mentre nello sviluppo incrementale sono intrecciate.

Specifica del software Il processo di stabilire quali servizi sono richiesti e i vincoli sul funzionamento e lo sviluppo del sistema. Processo di ingegneria dei requisiti:

• Studio di fattibilità: è tecnicamente e finanziariamente fattibile costruire il sistema?
• Elicitazione e analisi dei requisiti: cosa richiedono o si aspettano dal sistema gli stakeholder del sistema?
• Specificazione dei requisiti: definire i requisiti in dettaglio
• Convalida dei requisiti: controllare la validità dei requisiti

Progettazione e realizzazione del software Il processo di conversione delle specifiche del sistema in un sistema eseguibile.

• Progettazione del software: progettare una struttura software che realizzi la specifica;
• Implementazione: tradurre questa struttura in un programma eseguibile;

Le attività di progettazione e implementazione sono strettamente correlate e possono essere intrecciate. Le attività di progettazione includono:

• Progettazione architettonica: identificare la struttura generale del sistema, i componenti principali (talvolta chiamati sottosistemi o moduli), le loro relazioni e come sono distribuiti.
• Progettazione dell’interfaccia: definire le interfacce tra i componenti del sistema.
• Progettazione dei componenti: prendere ogni componente del sistema e progettare il suo funzionamento.
• Progettazione di database: progettare le strutture di dati del sistema e come queste devono essere rappresentate in un database.

Convalida del software La verifica e la convalida (V & V) hanno lo scopo di dimostrare che un sistema è conforme alle sue specifiche e soddisfa i requisiti del cliente del sistema.

• Validazione: stiamo costruendo il prodotto giusto (ciò che il cliente vuole)?
• Verifica: stiamo costruendo il prodotto giusto?

V & V comporta processi di controllo e revisione e test di sistema. Il test di sistema implica l’esecuzione del sistema con casi di test che sono derivati dalla specifica dei dati reali che devono essere elaborati dal sistema. Il test è l’attività V & V più comunemente usata e comprende le seguenti fasi:

• Sviluppo o test dei componenti: i singoli componenti sono testati indipendentemente; i componenti possono essere funzioni o oggetti o raggruppamenti coerenti di queste entità.
• Test del sistema: test del sistema nel suo complesso, il test delle proprietà emergenti è particolarmente importante.
• Test di accettazione: test con i dati del cliente per verificare che il sistema soddisfi le esigenze del cliente.

Evoluzione del software Il software è intrinsecamente flessibile e può cambiare. Sebbene ci sia stata una demarcazione tra sviluppo ed evoluzione (manutenzione), questa è sempre più irrilevante poiché sempre meno sistemi sono completamente nuovi.

Il cambiamento è inevitabile in tutti i grandi progetti software.I cambiamenti del business portano a nuovi e modificati requisiti di sistemaLe nuove tecnologie aprono nuove possibilità per migliorare le implementazioni.Le piattaforme che cambiano richiedono modifiche all’applicazione.Il cambiamento porta alla rielaborazione quindi i costi del cambiamento includono sia la rielaborazione (es.Il cambiamento porta alla rielaborazione, quindi i costi del cambiamento includono sia la rielaborazione (ad es. ri-analisi dei requisiti) che i costi di implementazione della nuova funzionalità.

Due strategie per ridurre i costi della rielaborazione:

Evitare il cambiamento Il processo software include attività che possono anticipare possibili cambiamenti prima che sia necessaria una significativa rielaborazione. Per esempio, un sistema prototipo può essere sviluppato per mostrare alcune caratteristiche chiave del sistema ai clienti. Tolleranza al cambiamento Il processo è progettato in modo che i cambiamenti possano essere accolti a costi relativamente bassi, il che normalmente comporta qualche forma di sviluppo incrementale. I cambiamenti proposti possono essere implementati in incrementi che non sono ancora stati sviluppati. Se questo è impossibile, allora solo un singolo incremento (una piccola parte del sistema) può essere alterato per incorporare il cambiamento.

Un prototipo è una versione iniziale di un sistema usato per dimostrare concetti e provare opzioni di progettazione. Un prototipo può essere usato in:

• Il processo di ingegneria dei requisiti per aiutare con l’elicitazione e la validazione dei requisiti;
• Nei processi di design per esplorare opzioni e sviluppare un design dell’interfaccia utente;
• Nel processo di test per eseguire test back-to-back.

Benefici della prototipazione:

• Miglioramento dell’usabilità del sistema.
• Una corrispondenza più vicina ai bisogni reali degli utenti.
• Miglioramento della qualità del design.
• Miglioramento della mantenibilità.
• Riduzione dello sforzo di sviluppo.

I prototipi possono essere basati su linguaggi o strumenti di prototipazione rapida. Possono comportare l’esclusione di funzionalità:

• Il prototipo dovrebbe concentrarsi su aree del prodotto che non sono ben comprese;
• Il controllo e il recupero degli errori possono non essere inclusi nel prototipo;
• Focalizzarsi su requisiti funzionali piuttosto che non funzionali come l’affidabilità e la sicurezza.

I prototipi dovrebbero essere scartati dopo lo sviluppo perché non sono una buona base per un sistema di produzione:

• Può essere impossibile mettere a punto il sistema per soddisfare i requisiti non funzionali;
• I prototipi normalmente non sono documentati;
• La struttura del prototipo è solitamente degradata da rapidi cambiamenti;
• Il prototipo probabilmente non soddisfa i normali standard di qualità organizzativi.

Piuttosto che consegnare il sistema come una singola consegna, lo sviluppo e la consegna sono suddivisi in incrementi con ogni incremento che consegna parte della funzionalità richiesta.Una volta che lo sviluppo di un incremento è iniziato, i requisiti sono congelati anche se i requisiti per gli incrementi successivi possono continuare ad evolversi.

Svantaggi della consegna incrementale:

• Il valore del cliente può essere consegnato con ogni incremento così la funzionalità del sistema è disponibile prima.
• Gli incrementi iniziali agiscono come un prototipo per aiutare ad ottenere i requisiti per gli incrementi successivi.
• Minore rischio di fallimento generale del progetto.
• I servizi di sistema ad alta priorità tendono a ricevere la maggior parte dei test.

Problemi della consegna incrementale:

• Molti sistemi richiedono un insieme di strutture di base che sono usate da diverse parti del sistema. Poiché i requisiti non sono definiti in dettaglio fino a quando un incremento deve essere implementato, può essere difficile identificare strutture comuni che sono necessarie per tutti gli incrementi.
• L’essenza dei processi iterativi è che le specifiche sono sviluppate insieme al software. Tuttavia, questo è in conflitto con il modello di approvvigionamento di molte organizzazioni, dove la specifica completa del sistema è parte del contratto di sviluppo del sistema.

Molte aziende di software si sono rivolte al miglioramento dei processi software come un modo per migliorare la qualità del loro software, ridurre i costi o accelerare i processi di sviluppo. Il miglioramento dei processi significa comprendere i processi esistenti e cambiare questi processi per aumentare la qualità del prodotto e/o ridurre i costi e i tempi di sviluppo.

Approccio della maturità dei processi Si concentra sul miglioramento della gestione dei processi e dei progetti e sull’introduzione di buone pratiche di ingegneria del software. Il livello di maturità del processo riflette la misura in cui le buone pratiche tecniche e di gestione sono state adottate nei processi di sviluppo del software dell’organizzazione. Approccio agile Si concentra sullo sviluppo iterativo e sulla riduzione delle spese generali nel processo del software. Le caratteristiche principali dei metodi agili sono la consegna rapida di funzionalità e la reattività alle mutevoli esigenze del cliente.

Le attività di miglioramento del processo formano un ciclo continuo con un ciclo di feedback:

• Misurare uno o più attributi del processo o prodotto software. Queste misurazioni formano una linea di base che aiuta a decidere se i miglioramenti del processo sono stati efficaci.
• Analizzare il processo corrente e identificare eventuali colli di bottiglia.
• Cambiare il processo per affrontare alcune delle debolezze del processo identificate. Questi vengono introdotti e il ciclo riprende per raccogliere dati sull’efficacia dei cambiamenti.

Misurazione del processo

• Ove possibile, i dati quantitativi del processo dovrebbero essere raccolti.
• Le misurazioni del processo dovrebbero essere usate per valutare i miglioramenti del processo.
• Le misurazioni possono includere:
  • Tempo impiegato per completare le attività del processo, per es.Ad esempio, il tempo di calendario o lo sforzo per completare un’attività o un processo.
  • Risorse richieste per i processi o le attività, ad esempio lo sforzo totale in giorni-persona.
  • Numero di occorrenze di un particolare evento, ad esempio il numero di difetti scoperti.

Il modello di maturità delle capacità SEI

• Iniziale: Essenzialmente non controllato
• Ripetibile: Procedure di gestione del prodotto definite e utilizzate
• Definite: Procedure e strategie di gestione dei processi definite e utilizzate
• Gestito: Strategie di gestione della qualità definite e utilizzate
• Ottimizzazione: Strategie di miglioramento dei processi definite e utilizzate