Ingegneria del software. Introduzione



Scaricare 356.77 Kb.
Pagina1/6
02.02.2018
Dimensione del file356.77 Kb.
  1   2   3   4   5   6

Ingegneria del software . Introduzione

 Cosa è il software?

Il software non è solo un insieme di linee di codice ma comprende anche tutta la documentazione, i case test ed i manuali. Il software implementa una macchina che deve interagire con l’ambiente esterno.

Gli ingegneri del software devono essere capaci di capire ed analizzare gli ambienti esterni.

Gli ambienti esterni sono il posto dove trovare i requisiti.
 Prodotti generici vs Prodotti specifici

I prodotti generici sono dei software prodotti da aziende e utilizzati da un ampio bacino di utenza diversificato. I prodotti specifici sono software sviluppati ad hoc per uno specifico cliente, visionato dallo stesso. La fetta maggiore della spesa è nei prodotti generici ma il maggior sforzo di sviluppo è nei prodotti specifici.


 Programma vs prodotto software

Un programma è una semplice applicazione sviluppata, testata e usata dallo stesso sviluppatore. Il prodotto software viene sviluppato per terzi, è un software industriale che ha un costo di circa 10 volte superiore ad un normale programma e deve essere corredato di documentazione, manuali e case test.

L’approccio singolo non è scalabile per grandi progetti.

 

Costi

Il costo del software viene calcolato in base alle ore di lavoro (manpower), al software e all’ hardware utilizzato e altre risorse di supporto. Il costo (espresso in mesi/uomo) della manutenzione è superiore a quello di produzione.

 

Manutenzione

Il software dopo il suo rilascio, specie se lo stesso ha una vita lunga, ha bisogno di alcune fasi di manutenzione. Per manutenzione intendiamo sia la correzione di eventuali bug, sia l’estensione/modifica di alcune caratteristiche. Il costo della manutenzione è più elevato rispetto a quello di produzione.

 

Software engineering

Disciplina che cerca di fornire le regole per il processo di produzione del software. Lo scopo dell’ingegneria del software è di pianificare, progettare, sviluppare il software tramite lavoro di gruppo. E’ possibile che vengono rilasciate più versioni del prodotto software. Tale attività ha senso per progetti di grosse dimensioni e di notevole complessità ove si rende necessaria la pianificazione.
 Differenza tra software engineering e computer science (Ingegneria del Software e Informatica)

Mentre la computer science si occupa di creare e ottimizzare algoritmi e si occupa degli aspetti teorici dell’informatica, il software engineering si occupa della pianificazione e della progettazione con la finalità di ottenere un prodotto software.

 

Fondamenti dell’ingegneria del software

L’ingegneria del software si occupa principalmente di tre aspetti fondamentali:



  • I principi;

  • I metodi e le metodologie;

  • Strumenti, procedure e paradigmi.

 

Principi

  • Rigore: precisione e accuratezza

  • Formalità: oltre il rigore fondamento matematico

  • Separazione di aspetti diversi: affrontare separatamente i vari lati di un problema complesso

  • Modularità: dividere un problema in sottoproblemi

  • Astrazione:si identificano gli aspetti fondamentali in un certo istante, ignorando gli altri

  • Scalabilità: anticipazione del cambiamento (la progettazione deve favorire l'evoluzione del software

  • Generalità: tentare di risolvere il problema nel suo caso generale

  • Incrementalità: lavorare a fasi di sviluppo, ognuna delle quali viene terminata con il rilascio di una release, anche se piccola

 

Metodi e metodologie

Un metodo è un particolare procedimento per risolvere problemi specifici, mentre la metodologia è un’insieme di principi e metodi che serve per garantire la correttezza e l’efficacia della soluzione al problema.

 

Strumenti, procedure e paradigmi

Uno strumento (tool) è un artefatto che viene usato per fare qualcosa in modo migliore. Una procedura è una combinazione di strumenti e metodi finalizzati alla realizzazione di un prodotto.

Un paradigma è un particolare approccio o una filosofia per fare qualcosa (Stile).
 Processo Software

Un processo software è un insieme organizzato di attività finalizzate alla costruzione di un prodotto  da parte del team di sviluppo. Utilizzando metodi, tecniche, metodologie e strumenti.

E' suddiviso in varie fasi secondo uno schema di riferimento (CVS: Cliclo di vita del Software).

Viene descritto da un modello che descrive la maturità del processo: informale, semiformale o formale.

 CASE (computer-aided software engineering)

Definizione: Sistemi software che intendono fornire uno sviluppo automatico per le attività di un processo software.

 Upper-CASE: Strumenti che supportano le attività delle fase di analisi, specifica dei requisiti e progettazione di un processo software. ES. Ration Rose, StarUML, etc.

 Lover-CASE: Strumenti che supportano le attività delle fasi finali del processo, come programmazzione, testing e debunggin ES. Eclipse
 Qualità del software

La qualità può essere riferita sia al prodotto che al processo applicato per ottenere il risultato finale.

Un particolare modello di qualità (modello di McCall) dice che la qualità si basa su i seguenti tre aspetti principali:


  • Revisione: manutenibilità,  flessibilità e verificabilità (deve rispettare i requisiti del cliente)

  • Transizione: portabilità, riusabilità, interoperabilità (capacità del sistema di interagire con altri sistemi esistenti)

  • Operatività: correttezza (conformità dello stesso rispetto ai requisiti), affidabilità, efficienza (tempo di risposta o uso della memoria), usabilità, integrità (capacità di sopportare attacchi alla sicurezza).


Cicli di vita del software

Occorre capire qual è il ciclo di vita del software e come gestirlo in maniera corretta.

Il ciclo di vita comprende le fasi di produzione a partire da quando si decide di utilizzare un software e comprende la manutenzione e la dismissione, anche se non tutti i software seguono il ciclo di vita fino in fondo.

Un processo software è un insieme organizzato di attività finalizzate ad ottenere il prodotto da parte di un team di sviluppo utilizzando metodo, tecniche, metodologie e strumenti.

 Il processo viene suddiviso in fasi in base ad uno schema di riferimento (ciclo di vita del software).

 

Modello di ciclo di vita del software (CVS)

E’ una caratterizzazione descrittiva o prescrittiva di come un sistema software viene o dovrebbe essere sviluppato.

Esistono vari modelli di CVS:

   • Waterfall (Modello a Cascata)


  • Spiral model (Modello a Spirale)

   • Prototyping (Modello basato su Prototipi)

            • Prototipazione Throw-Away (Usa e Getta)

            • Prototipazione Evolutiva

   • Sviluppo Evolutivo (Incremental delivery)

   • Trasformazionale

   • Sviluppo a componenti (Basato sul riuso sistematico dei componenti)

   • Sviluppo incrementale

            • Modelli Incrementali

            • Modelli Iterativi

     • Verification & Validation a  Retroazione (Feadback)

   • Modello a V
   Molti aspetti influenzano la definizione del modello:

   • specificità dell’organizzazione produttrice

   • know-how

   • area applicativa e particolare progetto

   • strumenti di supporto

   • diversi ruoli produttore/ committente

 

Le fasi principali di un qualsiasi ciclo di vita del software sono le seguenti:



  • Definizione (si occupa del cosa).
    Determinazione dei requisiti, informazioni da elaborare, comportamento del sistema, criteri di validazione, vincoli progettuali.

  • Sviluppo(si occupa del come)
    Definizione del progetto, dell’architettura software, traduzione del progetto nel linguaggio di programmazione, collaudi.

  • Manutenzione(si occupa delle modifiche)
    Miglioramenti, correzioni, prevenzione, adattamenti.


Modello a cascata (Waterfall Model)

Il modello identifica le fasi e le attività da svolgere durante il progetto del software. Trae ispirazione

dalle attività ingegneristiche tradizionali.

L’idea è descrivere con chiarezza l’output di ogni fase che diventa l’input della fase successiva.
Definisce che il processo segua una progressione sequenziale di fasi senza ricicli, al fine di controllare meglio tempi e costi. Inoltre definisce e separa le varie fasi e attività del processo in modo da minimizzare la sovrapposizione tra di esse. Ad ogni fase viene prodotto un semilavorato con la relativa documentazione e lo stesso viene passato alla fase successiva (milestore). I prodotti ottenuti da una fase non possono essere modificati durante il processo di elaborazione delle fasi successive (non è possibile tornare indietro).
Si adatta bene quando il sistema da sviluppare non cambia, cioè quando ci sono pochi imprevisti. Per cui risulta poco adatto ai sistemi software.



Organizzazione sequenziale: fasi alte del processo

Studio di fattibilità

Effettua una valutazione preliminare dei costi e dei requisiti in collaborazione con il committente. L’obiettivo è quello di decidere la fattibilità del progetto, valutarne i costi, i tempi necessari e le modalità di sviluppo:


• Analisi costi/benefici: Valutazione preliminare dei costi e dei benefici di un’applicazione, per
stabilire se si debba avviarne lo sviluppo, quali siano le alternative possibili, quali le scelte più
ragionevoli, e quali le risorse finanziarie e umane necessarie per l’attuazione del progetto.
• Si sceglie se il prodotto deve essere realizzato oppure comprato, si valutano risorse alternative
• Si produce un documento con lo studio di fattibilità con:


  • descrizione dei problemi (necessità dell’utente)




  • scenario delle soluzioni possibili (si cominciano ad abbozzare alcune soluzioni tecniche)




  • costi per le differenti soluzioni

Qui si decide se andare avanti o meno con lo sviluppo del software.


Output: documento di fattibilità.
Analisi e specifica dei requisiti

• Si analizza il dominio in cui l’applicazione opererà (ambiente, vincoli di natura tecnologica,…)

• Si identificano i requisiti: si stabiliscono funzionalità (requisiti funzionali), vincoli e

obiettivi consultando gli utenti (tipicamente il committente).

Un modo possibile di descrivere i requisiti funzionali consiste nel fornire una versione iniziale del Manuale Utente.

• Si derivano le specifiche per il software: richiede un’interazione con l’utente ed una

comprensione delle proprietà del dominio.

• Viene prodotto il RASD (Requirements Analisys and Specification Document) che deve essere compatto,

conciso e consistente

Nella fase di analisi dei requisiti e delle specifiche ci si deve concentrare sui seguenti punti (le 5 w)

• Who (chi userà il sistema)

• Why (perché deve essere sviluppato e perché gli utenti dovrebbero usarlo)

• What vs HOW (cosa apporterà il sistema, e non come deve essere fornita)

• Where (dove sarà usato, su quale architettura)

• When (quando e per quanto tempo sarà usato)

Il RASD (Requirements analysis and specification document o documento di specifica dei requisiti): dovrà essere: preciso, completo e consistente e potrà includere un manuale utente preliminare.


In questa fase viene anche definito il Piano di Test di Sistema (PTS) che descrive le modalità con cui, al termine dello sviluppo, nella fase di integrazione, si possa verificare il sistema sviluppato rispetto ai requisiti fissati.

Anche questo documento andrebbe sottoscritto dal committente

Output: documento di specifica dei requisiti (RASD).
Progettazione (Design)

Si definisce la struttura del software e il sistema viene scomposto in componenti e moduli:

• moduli

• relazioni

• interazioni (da cui capisco il comportamento a run-time del sistema)

Si descrivono le funzioni che il sistema deve svolgere, ciascuna delle quali verrà trasformata in uno o più programmi eseguibili; l’obiettivo è scomporre il problema in sottoproblemi in modo da ridurne la complessità

L'architettura software può essere composta da moduli, evidenziando quali siano le funzionalità

offerte dai diversi moduli e le relazioni tra i moduli

Il risultato dell’attività di progettazione è il Documento di Specifiche di Progetto (DSP) nel quale la definizione dell’architettura software può anche essere data in maniera rigorosa, o addirittura formale, usando opportuni linguaggi di specifica di progetto
Output: Scomposizione del sistema in moduli e definizione dei linguaggi e formalismi tramite il Documento di specifica di Progetto(DPS)


  • Organizzazione sequenziale: fasi basse del processo

  • Programmazione e test di unità (Codifica e testing delle unità)

  • Ogni modulo viene codificato nel linguaggio e testato separatamente dagli altri.

Il progetto viene realizzato come insieme di programmi o unità di programmi (moduli).

• Ogni modulo è implementato usando il linguaggio di programmazione scelto

• Ogni modulo è testato singolarmente dallo sviluppatore (in isolamento)

Il testing delle unità serve per verificare che ciascuna soddisfi le specifiche richieste.
Il prodotto è:

• Codice sorgente dei singoli moduli

• Risultati dei test fatti sul codice sorgente (dati di ingresso ed output)

• Documentazione (commenti, scelte tecniche…)


Integrazione e testing del sistema

I moduli vengono integrati tra loro e vengono testate le loro interazioni. Viene rilasciata una beta release (release esterna) oppure una alpha release (release interna) per testare al meglio il sistema.

Alfa e Beta test

• Alfa test quando il sistema è rilasciato per l’uso, ma all’interno dell’organizzazione del produttore

• Beta test quando si ha un rilascio controllato a pochi e selezionati utenti del prodotto

L'output è: Integrazione dei moduli per comporre il sistema vero e proprio e rilascio di Beta o Alpha release


Deployment (Distribuzione)

Rilascio del prodotto al cliente allo scopo è distribuire l’applicazione e gestire le diverse installazioni e configurazioni tra i vari clienti. Prima era fatta on site, adesso può anche essere fatta in remoto


Manutenzione

La Manutenzione gestisce l’evoluzione del software, comporta la correzione degli errori che non erano stati scoperti nelle fasi precedenti, migliorando la realizzazione delle unità del sistema ed aumentando i servizi forniti man mano che si richiedono nuovi requisiti.

È la fase più lunga del ciclo di vita di un prodotto software (oltre il 50% dei costi complessivi del ciclo di vita). Circa l’80% del budget IT(information tecnology) è speso in manutenzione.

PRECISAZIONI


  1. EVOLUZIONE

Perché un software dovrebbe evolvere? I motivi possono essere molteplici.

• Cambiamenti del contesto (esempio € vs £)

• Cambiamento nei requisiti

• Specifiche sbagliate

• Requisiti sconosciuti in anticipo


  1. TIPOLOGIE DI CAMBIAMENTI:

• Correttivi (software bacato) ~ 20%

• Adattativi (ci si deve adattare a cambiamenti nel sistema o nell’ambiente) ~ 20%

• Migliorativi (per avere delle funzionalità in più) ~ 50%


  1. BUONE ABITUDINI

Prima modificare il progetto, poi l’implementazione applicando le modifiche in modo consistente in tutti i documenti.


  1. COME FRONTEGGIARE L’EVOLUZIONE

L’obiettivo è anticipare i cambiamenti. Il software deve essere generato per rimanere aperto, deve essere possibile cambiarlo in modo semplice dopo che è stato sviluppato. I cambiamenti devono essere facilmente realizzabili ed a basso costo. Non bisogna confondere evoluzione con correzione .

Spesso il software non è stato progettato per essere modificato facilmente, si apportano modifiche

intervenendo direttamente sui programmi, senza modificare, se è il caso, la documentazione di

progetto e di test, la specifica dei requisiti, etc.


Un problema molto sentito dai produttori di software è quello di “recuperare” le applicazioni esistenti.

La re-ingegnerizzazione del software (reverse engineering) consiste nella possibilità di riportare

software ormai poco strutturato e non documentato in uno stato in cui sia possibile poi ripartire in

modo sistematico nella manutenzione




  1. DATI SUGLI ERRORI

• Ispezioni sistematiche possono trovare fino al 50-75% degli errori.

• Moduli con un controllo di flusso complesso possono facilmente contenere più errori.

• Spesso i test coprono soltanto il 50% del codice.

• Il codice distribuito contiene il 10% degli errori trovati nel testing.

• Gli errori iniziali sono scoperti tardi ed il costo per eliminarli aumenta con il passare del tempo.

• Eliminare errori da un grosso sistema costa più (4-10 volte) che in un sistema piccolo.

• L’eliminazione di errori introduce nuovi errori.

• I grossi sistemi tendono a stabilizzarsi ad un certo livello di inperfezione.


Pro e contro del modello a cascata

Pro Facile da comprendere e applicare

Contro

  • L’interazione con il cliente avviene solo all’inizio e alla fine del ciclo.

  • I requisiti dell’utente vengono scoperti solo alla fine.

  • Se il prodotto non ha soddisfatto tutti i requisiti, alla fine del ciclo, è necessario iniziare daccapo tutto il processo.

Modello a spirale

Proposto per supportare l’ analisi dei rischi è un modello di tipo ciclico, dove il raggio della spirale rappresenta il costo accumulato durante lo svolgimento del progetto.

Ogni ciclo della spirale rappresenta una fase del processo di sviluppo:

il più interno può essere lo studio di fattibilità, il successivo la definizione dei requisiti, il

successivo ancora la progettazione, etc.
Non sono definite fasi a priori e man mano che si cicla nella spirale, i costi aumentano.

Ogni ciclo della spirale passa attraverso i quadranti del piano che rappresentano i seguenti passi logici:

I. determinazione di obiettivi, alternative e vincoli

II. valutazione di alternative, identificazione e risoluzione di rischi

ad esempio sviluppo di un prototipo per validare i requisiti

III. sviluppo e verifica del prossimo livello del prodotto.



  • modello evolutivo, se i rischi riguardanti l'interfaccia utente sono dominanti;

  • modello cascata se è l'integrabilità del sistema il rischio maggiore;

  • modello trasformazionale, se la sicurezza è più importante

IV. pianificazione della fase successiva

si decide se continuare con un altro ciclo della spirale


Una caratteristica importante di questo modello è il fatto che i rischi vengono presi seriamente in considerazione e che ogni fine ciclo produce una deliverables(release funzionanti alle quali mancano alcune funzionalità). In un certo senso può essere visto come un modello a cascata iterato più volte.

Costituisce un meta- modello dei processi software, cioè un modello per descrivere modelli

Non è detto che per un ciclo della spirale si adotti un solo modello di sviluppo
Può descrivere uno sviluppo incrementale, in cui ogni incremento corrisponde a un ciclo di spirale

Può descrivere il modello a cascata (quadranti I e II corrispondenti alla fase di studio di fattibilità e

alla pianificazione del progetto; quadrante III corrisponde al ciclo produttivo)

Differisce dagli altri modelli perché considera esplicitamente il fattore rischio.

Boehm suggerisce di considerare, per ciascun ciclo, le seguenti voci:

• Obiettivi

• Vincoli

• Alternative

• Rischi

• Soluzioni per i rischi

• Risultati

• Piani


• Decisioni
Vantaggi

Rende esplicita la gestione dei rischi, focalizza l’attenzione sul riuso, determina errori in fasi iniziali, aiuta a considerare gli aspetti della qualità e integra sviluppo e manutenzione.



Svantaggi

Richiede un aumento nei tempi di sviluppo, delle persone con capacità di identificare i rischi, una gestione maggiore del team di sviluppo e quindi anche un costo maggiore.



Scopo dell’ ingegneria del software

  • Migliorare la qualità del prodotto e del processo software

  • Portabilità su sistemi legacy

Un sistema legacy (ereditato, che è un lascito del passato) è un sistema informatico, un'applicazione o un componente obsoleto, che continua ad essere usato poiché l'utente (tipicamente un'organizzazione) non intende o non può rimpiazzarlo.



Project management

Il project management racchiude le attività necessarie per assicurare che un progetto software venga sviluppato rispettando le scadenze e gli standard.

Le entità fisiche che prendono parte al project management sono:


  • Business manager: definiscono i termini economici del progetto

  • Project manager: panificano, motivano, organizzano e controllano lo sviluppo, stimano il costo del progetto, selezionano il team di sviluppo, stendono i rapporti e le presentazioni.

  • Practitioners: hanno competenze tecniche per realizzare il sistema

  • Customers (clienti): specificano i requisiti del software da sviluppare

  • End users (utenti): gli utenti che interagiscono con il sistema



Team di sviluppo

Esistono vari tipi di team di sviluppo qui di seguito indicati:



  • Democratico decentralizzato

Assenza di un leader permanente (possono esistere dei leader a rotazione), consenso di gruppo, organizzazione orizzontale.

Vantaggi: individuazione degli errori, adatto a problemi difficili.

Svantaggi: difficile da imporre, non è scalabile.


  • Controllato decentralizzato

Vi è un leader che controlla e coordina il lavoro ed assegna i problemi ai gruppi a lui sottomessi. I sottogruppi hanno un leader e sono composti da 2 a 5 persone. I leader dei sottogruppi possono comunicare tra loro come anche i membri dei sottogruppi possono comunicare in maniera orizzontale.


  • Controllato centralizzato

Vi è un leader che decide sulle soluzioni e la organizzazione dei gruppi. Ogni gruppo ha un proprio leader che assegna e controlla il lavoro dei componenti. I leader dei gruppi non comunicano tra loro ma possono comunicare solo con il loro capo. I membri dei gruppi non comunicano tra loro ma solo con il capo gruppo.



Identificare gli attori
System design
Concetti di riuso
Ottimizzare i cammini di accesso alle informazioni


  1   2   3   4   5   6


©astratto.info 2017
invia messaggio

    Pagina principale