Ingegneria del Software: breve introduzione

Ingegneria del software

Project Management

Si definisce project management  l’insieme delle attività aziendali, svolte tipicamente da una o più figure dedicate e specializzate dette project manager, volte all’analisi, progettazione, pianificazione e realizzazione degli obiettivi di un progetto, gestendolo in tutte le sue caratteristiche e fasi evolutive, nel rispetto di precisi vincoli.

Il project management da alcuni anni segue standard internazionali come PMI.

Gli obiettivi del Project Management sono:

• Dare una visione realistica del progetto, durante tutto il suo ciclo di vita

• Evidenziare situazioni critiche e proporre valide alternative in tempo utile

• Tracciare un quadro previsionale dell’evoluzione futura del progetto

• Assicurare la coerenza tra gli obiettivi parziali assegnati e quelli generali di progetto

Fasi di un progetto

Si definisce processo un insieme di attività coordinate rivolte ad un compito/scopo specifico.

All’interno di un progetto sono individuabili i seguenti processi:

  • Gruppo di processi di avvio;
  • Gruppo di processi di pianificazione;
  • Gruppo di processi di monitoraggio e controllo, che dovrebbero durare per tutta la fase esecutiva del progetto;
  • Gruppo di processi di chiusura;
  • Gruppo dei processi di esecuzione, mettono in pratica le attività descritte nella pianificazione;

Avviamento

Viene valutata la fattibilità (rispetto ai vincoli di tempo, budget, risorse a disposizione ecc.) dell’idea progettuale, definendo i risultati desiderati del progetto e a identificando i potenziali partner o stakeholder.  Alla fine di questa fase si ottiene generalmente un piano di progetto chiaro, che deve essere approvato da tutte le parti, in modo da evitare incomprensioni.

Pianificazione

Si stimano le risorse necessarie e si effettua una pianificazione temporale dell’intero progetto.

Esecuzione

Tutte le parti interessate nel progetto mettono in pratica le attività descritte nella pianificazione;

Controllo

Questa fase durerà tutta la fase di esecuzione. Vengono analizzati il rispetto di tempi, budget e risorse al fine di valutare e controllare  se si è in linea con i valori stimati;  Se ci sono scostamenti si passa nuovamente nella fase di pianificazione, e, subito dopo, di esecuzione.

Chiusura

Il prodotto finale viene ufficialmente consegnato e il progetto chiuso.

Strumenti per il project management

WBS

Si definisce WBS (Work Breakdown Structure) o Scomposizione Strutturata del Lavoro la scomposizione di una attività da compiere in tante attività più piccole o direttamente in azioni.

Deliverable

I deliverable sono i risultati del progetto. Possono essere:

• un prodotto o manufatto;

• la capacità di erogare un servizio;

• un risultato, come degli esiti o dei documenti.

Stakeholder

Per stakeholder si intendono tutte le persone che hanno un qualche interesse in un’organizzazione, in un progetto, in un servizio ecc…

Esempi di stakeholder sono:

• Clienti

• Partner

• Organi legislativi

• Impiegati

• Azionisti

• Proprietari

• Ecc…

OBS

Per OBS si intende la scomposizione dell’organizzazione in componenti elementari.

Le unità sono solitamente le singole persone ma possono anche rappresentare uffici o altre suddivisioni gerarchiche o funzionali dell’azienda.

In un progetto, di solito la OBS è creata dopo la WBS, in modo da poter individuare le responsabilità nelle singole attività assegnandole a specifiche persone o divisioni. La OBS non corrisponde necessariamente all’organigramma di un’azienda, ma può essere anche costruita ad hoc.

Il processo di integrazione fra WBS e OBS è rappresentato in figura

Dalla compilazione di questo schema si ottiene la matrice delle responsabilità.

Matrici di responsabilità

Le matrici di responsabilità, detta anche matrice RACI, esprime il ruolo che ogni persona o divisione organizzativa coinvolta nel processo assume relativamente alla fase indicata, in particolare si ha:

• R – ossia la persona o il ruolo o la divisione è responsabile della deliverable

(nel caso di progetto) o della attività (nel caso di processo). Quindi la persona o la

divisione è attivamente coinvolta con la propria opera nella attività.

• A – significa che la persona (o ruolo) approva la deliverable e quindi si assume la

responsabilità di tale approvazione “mettendoci la faccia”. Normalmente esiste solo

una persona responsabile (A) di approvare, mentre più persone possono contribuire

(R). I ruoli A ed R non sono mutuamente esclusivi: una persona può assumere

contemporaneamente i ruoli A ed R rispetto ad una certa fase.

• C – significa che la persona (o ruolo, o divisione) viene consultata sul rilascio della

deliverable.

• I – significa che la persona o il ruolo viene informata, non consultata, della deliverable.

Esempio:

Diagramma delle dipendenze e PERT

Il diagramma delle dipendenze definisce le dipendenze fra le  attività coinvolte nel processo.

Il grafo di progetto, chiamato anche diagramma a rete del progetto, è un grafo i cui nodi rappresentano attività da svolgere ed i cui archi esprimono condizionamenti tra attività. Oltre alle informazioni delle dipendenze fra attività ed azioni da un lato e risorse o regole dall’altro, esprime anche le informazioni di flusso logico.

Diagrammi di Gantt

I diagrammi di Gantt si dividono in due tipi:

  • diagramma di Gantt delle attività, l’asse orizzontale rappresenta il tempo e l’asse verticale le attività del progetto; le singole attività sono rappresentate come barre parallele all’asse temporale orizzontale;  permette di monitorare giorno per giorno l’andamento dei progetti.
  • diagramma di allocazione delle risorse o diagramma degli incarichi: l’asse verticale rappresenta le risorse e l’asse orizzontale il tempo. La barra rappresentano i periodi di occupazione delle singole risorse.

Fase di pianificazione e gestione

Mettendo insieme gli strumenti sinora visti, la fase di pianificazione è composta dai seguenti passi

1.  Creare la WBS;

2. Stabilire, attraverso la OBS, chi fa che cosa;

3. Assegnare gli incarichi alle persone, attraverso una matrice di responsabilità.

4. Creazione PERT, stabilendo la successione temporale delle attività;

5. Diagrammi di Gantt, mappare le attività su un calendario reale e verificare il carico e l’occupazione delle singole risorse;

6. Calcolare i costi complessivi, stabilendo il piano dei costi.

Il progetto informatico

Si definisce Ingegneria del software la disciplina che aiuta ad ingegnerizzare il processo di sviluppo del software

  • stabilendo delle regole
  • rendendolo più efficiente
  • applicando metodologie di project management

La struttura di base del progetto software comprende le seguenti fasi

  • Raccolta dei requisiti
  • Analisi
  • Progettazione
  • Implementazione (sviluppo)
  • Test
  • Installazione (messa in produzione)
  • Manutenzione (ordinaria ed evolutiva)

Raccolta dei requisiti ed Analisi

Si definisce requisito (o specifiche) una proprietà o una qualità che un prodotto software deve avere o soddisfare. Si possono avere requisiti:

  • Funzionali, proprietà che l’applicazione deve obbligatoriamente avere.
  • Non Funzionali, vincoli sul sistema o sul suo processo di sviluppo (es. “Questo documento dev’essere stampato su stampante a colori”).

Il progetto inizia con la fase di raccolta dei requisiti, tramite riunioni, interviste, etc, per formalizzare le richieste del cliente, i vincoli che il progetto deve rispettare e il contesto dove deve operare.

Le informazioni formalizzate nella fase di analisi rappresentano il punto di partenza per la progettazione di un prodotto software e per l’intero processo della sua realizzazione, validazione e manutenzione.

Questa fase è fondamentale per la buona riuscita di un progetto software, in quanto tutte le fasi successive si basano su queste informazioni.

Come mostrato, in chiave ironica, nella figura seguente, un errore eventualmente compiuto durante la fase di raccolta requisiti produce effetti sempre maggiori e sempre più costosi da correggere man mano che si procede con le fasi successive di progetto.

In progetti piccoli, l’analisi è quasi sempre una fase conclusa una volta per tutte all’inizio, in progetti grandi invece spesso l’analisi viene svolta iterativamente nel processo stesso.

Questa fase deve produrre dei documenti di analisi, talvolta chiamati anche documenti di specifica o semplicemente specifiche, che descrivono cosa il software deve fare, l’ambiente in cui opera e i vincoli che deve rispettare.

La fase di progettazione

Partendo dai risultati dell’analisi, la fase di progettazione deve produrre le istruzioni operative per la realizzazione effettiva del progetto informatico (implementazione). Le istruzioni devono avere il giusto livello di dettaglio ed essere espresse in forma di documenti strutturati.

Il risultato della progettazione è la definizione dell’architettura del sistema, cioè l’organizzazione strutturale del sistema stesso, che comprende i suoi componenti software, le proprietà visibili esternamente di ciascuno di essi (l’interfaccia dei componenti) e le relazioni fra le parti.

Nella fase di analisi il sistema è rappresentato in forma astratta e (teoricamente) indipendente dalla tecnologia. Nella progettazione si tiene conto anche di tutti i fattori relativi all’utilizzo della tecnologia utilizzata.

La fase di implementazione o scrittura del codice

La scrittura del codice sorgente, per quanto spesso poco considerata, rimane comunque la fase fondamentale di ogni progetto informatico. Se il codice viene scritto male, l’applicazione risultante funzionerà male.

Per questo molte metodologie di programmazione moderna tendono a fare diventare la fase di stesura di codice quella principale di tutto un progetto informatico (ad esempio Agile).

La fase di test

Una volta che il programma è stato implementato, occorre verificare che il suo funzionamento sia conforme alle specifiche state stabilite nella fase di analisi. Questo è lo scopo fondamentale della fase di test.

Se si supera questa fase si passa a quella successiva, altrimenti si segnalano le anomalie ai programmatori e si ritorna alla fase precedente.

La fase di avvio o entrata in produzione

In questa fase, anche detta di deployment,  il programma può entrare in produzione. Ossia si procede all’installazione e configurazione del prodotto software nell’infrastruttura di esecuzione utilizzabile dagli utenti, detta l’ambiente operativo o di produzione o di esercizio.

 Al termine di questa fase i programmi iniziano la propria vita operativa, durante la quale svolgono il compito per cui sono stati progettati, che può proseguire anche per molti anni.

La fase di manutenzione

Raramente un software, durante la sua vita operativa, non ha bisogno di interventi di correzione o di aggiunta funzionalità.

Si distingue in:

1. Manutenzione ordinaria, insieme di interventi necessari per correggere errori non rilevati durante la fase di test.

2. Manutenzione evolutiva, insieme di interventi  in cui si modificano funzionalità esistenti o se ne aggiungono di nuove.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *