Appunti di Sistemi Software

Sistemi software

Aspetti tipici dell'ingegneria del software

Possono essere accidentali del prodotto software: di attitudine, di manutenzione, di specifica e progetto, di teaming. Inoltre, possono essere essenziali del prodotto software: complessità, conformità, cambiabilità, invisibilità. Inoltre, possono essere di costo del prodotto software: costo verso dimensioni, repliche, ampiezza di mercato.

Inoltre abbiamo gli aspetti di affidabilità: informalmente ossia credibilità del prodotto software, formalmente ossia probabilità che il prodotto software lavori correttamente in un determinato intervallo di tempo. Un prodotto software con molti difetti è poco affidabile ed è chiaro che l'affidabilità del prodotto migliora riducendo il numero di difetti. C'è una relazione non semplice tra affidabilità osservata e numero di difetti latenti.

La regola 10-90 tratta esperimenti condotti su programmi di grandi dimensioni che mostrano che il 90% del tempo di esecuzione totale è speso eseguendo solo il 10% delle istruzioni; quest'ultimo è chiamato core ossia nucleo del programma.

Il miglioramento dell'affidabilità per l'eliminazione di un difetto dipende dalla localizzazione del difetto, ovvero se appartiene o meno al nucleo del programma. Dunque, l'affidabilità osservata dipende da come hai usato il prodotto in termini tecnici e dal suo profilo operativo. Dunque, dei difetti che si manifestano per un utente potrebbero non manifestarsi per l'altro, e dunque possiamo concludere che l'affidabilità di un prodotto software dipende dall'utente.

Mentre i guasti del software sono dovuti alla presenza di difetti nei programmi e il software non si consuma, i guasti dell'hardware sono sempre dovuti all'usura dei componenti. Ed è per questo che le metriche usate per l'affidabilità dell'hardware non sono sensibili al software. Dopo la riparazione dell'hardware la sua affidabilità torna com'era, mentre dopo la riparazione del software la sua affidabilità può aumentare o diminuire.

I difetti software sono latenti in quanto il software continua a guastarsi a meno che non si corregga. L'affidabilità nell'hardware ha come obiettivo la stabilità, dunque tenere la frequenza di guasto costante, mentre nel software l'obiettivo è la crescita dell'affidabilità, cioè far decrescere la frequenza dei guasti.

Inoltre, abbiamo gli aspetti di disponibilità ossia la percentuale di tempo che il software è risultato stabile nel corso della sua vita. Questi dipendono dal numero di guasti che si verificano e dal tempo necessario ripararli.

Costo e size

Costo e size sono in relazione quadratica tra loro (C=aS²). Ciò significa che produrre due prodotti di costo S/2 costa meno che produrne uno di size S (aS²/2 < aS²). Inoltre, a parità di prezzo serve un mercato quattro volte più ampio e a parità di mercato serve un prezzo quattro volte più alto. Produrre una copia non costa nulla a prescindere dal size.

Processo software

Consiste nella serie di attività necessarie alla realizzazione del prodotto software nei tempi, con i costi e con le desiderate caratteristiche di qualità. Nel suo contesto:

• Si applicano metodi, tecniche e strumenti
• Si creano prodotti (sia intermedi che finali)
• Si stabilisce il controllo gestionale del progetto
• Si garantisce la qualità
• Si governano le modifiche

Ciclo di vita del software

Consiste nell'intervallo di tempo che intercorre tra l'istante in cui nasce l'esigenza di costruire un prodotto software e l'istante in cui il prodotto viene dismesso, includendo le fasi di definizione dei requisiti, specifica, pianificazione, progetto preliminare, progetto dettagliato, codifica, integrazione, testing, uso, manutenzione e dismissione.

Abbiamo 3 stadi:

• Sviluppo (stadio 1) = 6 fasi: Requisiti, Specifiche (o analisi dei requisiti), Pianificazione, Progetto (preliminare e dettagliato), Codifica, Integrazione. In generale riconosciamo due tipi di fase nello sviluppo: quella di definizione e quella di produzione. La prima si occupa di cosa il software deve fornire e si definiscono dunque requisiti e si producono le specifiche. La seconda definisce come realizzare quanto ottenuto nella definizione, andando a progettare il software, codificandolo, integrandolo e rilasciandolo al cliente.
• Manutenzione (stadio 2) che copre circa il 60% dei costi del ciclo di vita. Questo stadio è a supporto del software realizzato e prevede le fasi di definizione e produzione al suo interno. La manutenzione può essere: correttiva se ha lo scopo di eliminare i difetti che producono i guasti del software, adattiva se ha lo scopo di adattare il software ad eventuali cambiamenti dell'ambiente operativo, perfettiva se ha lo scopo di estendere il software per funzionalità aggiuntive, preventiva se ha lo scopo di effettuare modifiche che rendono più semplici le correzioni o gli adattamenti.
• Dismissione (stadio 3).

Durante ogni fase si procede ad effettuare il testing di quanto prodotto mediante opportune tecniche di verifica e validazione applicate sia ai prodotti intermedi che al prodotto finale. Questo non è esplicitamente menzionato tra le 6 fasi ma non è una fase separata ed è una attività che ha luogo durante l'intero sviluppo in due modi: verifica alla fine di ogni fase o validazione alla fine dello sviluppo.

Modelli CDV software

Il modello del ciclo di vita del software specifica la serie di fasi attraverso cui il prodotto software progredisce e l'ordine con cui vanno eseguite, dalla definizione dei requisiti alla dismissione. La scelta del modello dipende dalla natura dell'applicazione, dalla maturità dell'organizzazione, da metodi e tecnologie usate e da eventuali vincoli dettati dal cliente. L'assenza di un modello del ciclo di vita corrisponde ad una modalità di sviluppo detta "build & fix" (o "fix-it-later"), in cui il prodotto software viene sviluppato e successivamente rilavorato fino a soddisfare le necessità del cliente.

Defect removal efficiency

Fa riferimento alla percentuale di difetti trovati prima del rilascio del prodotto software. Il DRE medio negli Stati Uniti è al 92% ma i valori cambiano in base al modello del ciclo di vita.

Definizioni

• Prodotto software = Codice + Documentazione.
• Artefatto = prodotto software intermedio: documento requisiti, documento di specifica, documento di progetto.
• Codice = prodotto software finale.
• Sistema software = insieme organizzato di prodotti software.
• Cliente = soggetto che ordina il prodotto software.
• Sviluppatore = soggetto che lo produce.
• Utente = soggetto che lo usa.
• Software interno = cliente e sviluppatore coincidono.
• Software a contratto = cliente e sviluppatore sono soggetti differenti.
• Difetto: anomalia presente in un prodotto software.
• Guasto: comportamento anomalo del prodotto software dovuto alla presenza di un difetto.
• Errore: azione errata di chi introduce un difetto nel prodotto software.
• Cliente (customer, client) = la persona od organizzazione che paga per la fornitura di un prodotto software.
• Fornitore (supplier, contractor) = la persona od organizzazione che produce software per il cliente.
• Utente finale (end-user) = la persona che interagisce direttamente con il prodotto software che non corrisponde necessariamente al cliente.

Conclusioni

Nel corso degli anni la produzione software ha eseguito varie fasi: la fase di abilità nella quale prevalgono gli aspetti di lavoro individuale creativo, la fase artigianale nella quale il software viene prodotto da piccoli gruppi di professionisti specializzati, fase industriale nella quale l'attività di sviluppo e manutenzione del software viene pianificata e coordinata e il lavoro del progettista viene sempre più supportato da strumenti automatici. Il software può essere considerato come un insieme di elementi che formano una configurazione di programmi documenti e dati multimediali, viene realizzato dall’ingegnere applicando un approccio ingegneristico che conduca a risultati di alta qualità. Il software deve essere dunque ingegnerizzato, non deve consumarsi ma è complesso invisibile e cambiabile. I metodi e le tecniche di ingegneria del software hanno lo scopo di fornire le risposte a tali problemi al fine di realizzare software con le desiderate caratteristiche di qualità.

Software prototyping

Rapido sviluppo di software per richiedere o convalidare i requisiti. L'uso principale dei prototipi è di aiutare i clienti e gli sviluppatori a comprendere i requisiti software attraverso:

• Richiesta di requisiti in cui gli utenti possono sperimentare un prototipo per vedere come il sistema supporta il loro lavoro
• Convalida dei requisiti in cui il prototipo può rivelare errori e omissioni nei requisiti.

La prototipazione può essere considerata un'attività di riduzione del rischio che riduce i rischi relativi ai requisiti. I vantaggi della prototyping:

• Le incomprensioni tra utenti e gli sviluppatori sono esposte
• Potrebbero essere rilevati servizi mancanti e potrebbero essere identificati servizi confusi
• Un sistema funzionante è disponibile all'inizio del processo in cui il prototipo può servire come base per derivare una specifica del software
• Il prototipo può supportare la formazione dell'utente e il test del prodotto.

Alcune parti dei requisiti (ad es. sicurezza critica, funzioni) potrebbero essere impossibili da prototipare e quindi non compaiono nelle specifiche. I requisiti non funzionali non possono essere adeguatamente testati in un prototipo di software.

Punti chiave del prototipo: È possibile utilizzare un prototipo per dare un’impressione concreta agli utenti finali delle capacità del prodotto. Il prototipo viene sempre più utilizzato per lo sviluppo del prodotto in cui lo sviluppo rapido è essenziale. La prototipazione usa e getta viene utilizzata per comprendere i requisiti del prodotto. La programmazione visiva è parte integrante della maggior parte dei metodi di sviluppo del prototipo.

Throw-away prototyping

Un prototipo che di solito è un'implementazione pratica del prodotto viene prodotto per aiutare a scoprire i problemi dei requisiti e quindi scartato. Il prodotto viene quindi sviluppato utilizzando alcuni altri processi di sviluppo. Il prototipo è sviluppato da un requisito iniziale, consegnato per esperimento e quindi scartato. Il throw-away prototyping NON deve essere considerato come un prodotto finale. Alcune caratteristiche potrebbero essere state escluse e non ci sono specifiche per la manutenzione a lungo termine. Il prodotto sarà scarsamente strutturato e difficile da mantenere. Gli sviluppatori possono essere sotto pressione per fornire un prototipo throw-away come prodotto finale. Questo non è raccomandato in quanto:

• Potrebbe non essere possibile mettere a punto il prototipo
• Il prototipo è inevitabilmente privo di documenti
• La struttura verrà degradata dalle modifiche apportate durante lo sviluppo
• I normali standard di qualità organizzativa potrebbero non essere stati applicati.

Programmazione visiva

I linguaggi di scripting come Visual Basic supportano la programmazione visiva in cui il prototipo viene sviluppato creando un'interfaccia utente da elementi standard e associando componenti a questi elementi. Una vasta libreria di componenti esiste a supportare questo tipo di sviluppo, questi possono essere personalizzati per adattarsi ai requisiti specifici. Problemi con lo sviluppo visivo:

• Difficile coordinare lo sviluppo basato su team
• Nessuna architettura software esplicita
• Dipendenze complesse tra le parti del programma possono causare problemi di manutenibilità.

Processo iterativo

I requisiti si evolvono SEMPRE nel corso di un progetto, quindi l'iterazione del processo in cui vengono rielaborate le fasi precedenti fa sempre parte del processo per i prodotti di grandi dimensioni. L'iterazione può essere applicata a qualsiasi generico modello di processo, abbiamo due approcci (correlati) ossia sviluppo incrementale e sviluppo a spirale.

Modello incrementale

Il prodotto è sviluppato e consegnato in incrementi dopo aver stabilito un'architettura complessiva. I requisiti e le specifiche possono essere sviluppati per ogni incremento. Gli utenti possono sperimentare gli incrementi forniti mentre altri sono in fase di sviluppo, pertanto questi servono come una forma di prototipo. Permette di combinare alcuni dei vantaggi della prototipazione ma con un processo più gestibile e una struttura migliore.

Il prodotto software viene sviluppato e rilasciato per incrementi successivi. Include aspetti tipici del modello basato su rapid prototyping (l’utente può sperimentare l’utilizzo del prodotto contenente gli incrementi consegnati, mentre i restanti sono ancora in fase di sviluppo). Si rivela efficace quando il cliente vuole continuamente verificare i progressi nello sviluppo del prodotto e quando i requisiti subiscono modifiche. Può essere realizzato in due versioni alternative ossia versione con overall architecture e versione senza (più rischiosa).

Costo: In generale, il costo di un prodotto software è in relazione quadratica con il size del prodotto stesso (C=aS²). Nel caso del modello incrementale nel quale il prodotto viene rilasciato per incrementi successivi, possiamo avere una riduzione di costo perché se è vero che produrre due software di size S/2 costa meno che produrne uno solo di size S, allora producendo il software per piccoli incrementi successivi il costo totale dovrebbe scendere.

Confronto cascata e incrementale

Risk management

La gestione dei rischi si occupa dell'identificazione dei rischi e della stesura di piani per minimizzare il loro effetto su un progetto. Un rischio è una probabilità che si verifichino alcune circostanze avverse. Categorie di rischio:

• I rischi del progetto influiscono sul programma o sulle risorse
• I rischi del prodotto influiscono sulla qualità o sulle prestazioni del software in fase di sviluppo
• I rischi aziendali incidono sull'organizzazione che sviluppa o acquista il software.

Il processo del risk management consiste nel:

• Identificazione del rischio (Identificare i rischi di progetto, prodotto e business)
• Analisi del rischio (Valutare la probabilità e le conseguenze associati a ciascun rischio identificato nella fase precedente)
• Pianificazione del rischio (Elaborare piani per evitare o ridurre al minimo gli effetti del rischio)
• Monitoraggio del rischio (Monitorare i rischi durante il progetto).

Identificazione del rischio ovvero possibilità tipi di rischio:

• Tecnologia (il database utilizzato nel sistema non può elaborare tutte le transazioni al secondo previste, i componenti software che devono essere riutilizzati contengono difetti che ne limitano la funzionalità)
• Persone (è impossibile assumere personale con le competenze richieste, il personale chiave è malato e non disponibile nei momenti critici, la formazione richiesta per il personale non è disponibile)
• Organizzazione (l'organizzazione viene ristrutturata in modo tale che i diversi responsabili siano responsabili del progetto, i problemi finanziari organizzativi impongono riduzioni del budget del progetto)
• Strumenti (il codice generato dagli strumenti CASE è inefficiente. Gli strumenti CASE non possono essere integrati)
• Requisiti (vengono proposte modifiche ai requisiti che richiedono importanti rilavorazioni di progettazione, i clienti non comprendono l'impatto delle modifiche ai requisiti)
• Stima (il tempo necessario per sviluppare il software è sottovalutato. Il tasso di riparazione dei difetti è sottovalutato, la dimensione del software è sottovalutata).

Analisi del rischio ossia valutare la probabilità e la gravità di ciascun rischio, la probabilità di rischio può essere molto basso (<10%), basso (10-25%), moderato (25-50%), alto (50-75%) molto alto (> 75%) e gli effetti del rischio possono essere catastrofici, gravi, tollerabili o insignificanti (identificare ad esempio i primi dieci rischi considerando tutti i rischi catastrofici e tutti i rischi gravi che hanno una probabilità di insorgenza più che moderata per poi classificare tali rischi in ordine di importanza).

Pianificazione del rischio ossia considerare ogni rischio e sviluppare una strategia per gestirlo:

• Strategie di elusione (la probabilità che insorga il rischio è ridotta)
• Strategie di minimizzazione (L'impatto del rischio sul progetto o sul prodotto sarà ridotto)
• Piani di emergenza (Se sorge il rischio, i piani di emergenza sono strategie per affrontare tale rischio).

Strategie di gestione del rischio:

• Problemi finanziari organizzativi (preparare un documento informativo per l'alta dirigenza che mostra come il progetto sta dando un contributo molto importante agli obiettivi del business)
• Problemi di assunzione (Avvisare il cliente delle potenziali difficoltà e della possibilità di ritardi, indagare sui componenti di acquisto)
• Malattia del personale (riorganizza il team in modo che vi sia una maggiore sovrapposizione di lavoro e le persone quindi capiscano il lavoro reciproco)
• Componenti difettosi (Sostituire i componenti potenzialmente difettosi con componenti acquistati di affidabilità nota)
• Modifiche ai requisiti (Deriva le informazioni sulla tracciabilità per valutare l'impatto dei cambiamenti dei requisiti, massimizza le informazioni nascoste).