| Realizzazione sistemi informatici aziendali |
Aree di conoscenza (KNOWLEDGE AREAS)
1. Area Pianificazione (Plan)
Si riferisce all'analisi dei requisiti e alla pianificazione dell'utilizzo di tecnologie informatiche, ed è quindi strettamente connessa ai processi gestionali e alla definizione delle necessità aziendali in ambito ICT inquadrate in una prospettiva strategica. Elementi importanti all'interno di questa area sono ad esempio le nozioni tradizionali di organizzazione aziendale, ritorno d'investimento, finanziamento, rischio, ecc.
2. Area Realizzazione (Build)
Comprende i processi di specifica, sviluppo e acquisizione di sistemi informatici. Il nodo centrale dell'area è costituito dagli aspetti tradizionali dello sviluppo, implementazione ed integrazione dei sistemi informatici.
3. Area Esercizio (Operate)
L'area operativa riguarda l'installazione, la supervisione e la manutenzione di sistemi informatici. E' caratterizzata da argomenti come la gestione di reti, la gestione di aggiornamenti e ampliamenti, il supporto agli utenti, ecc.
ED realizza di sistemi informatici aziendali ad alta scalabilità per il governo di tutte le operatività di processo - enterprise resource planning(ERP) -, basati su interfacce browser e database, che includono in modo integrato tutte le funzionalità richieste dal Cliente:
Pacchetti di contabilità
Applicativi per l'analisi del mercato e di benchmarking
Gestori del parco clienti (CRM Customer relationship management)
Figura 1 - Modello applicabile alla evoluzione di mercato del prodotto software
|
| Approfondimento tecnico |
Sempre con riferimento allo schema a cascata, le frecce superiori indicano la sequenza con cui si susseguono le varie fasi, mentre quelle nella parte inferiore di ciascun blocco indicano che talune informazioni vengono riportate dal successore al predecessore secondo un processo iterattivo, per esempio per consentire la modifica di un requisito a monte o la correzione di un errore. Ogni fase del progetto termina con una review, nella quale viene rivisitata criticamente tutta l'attività della fase stessa, ed analizzata la pianificazione di quella successiva.
La chiusura di ciascuna di queste rivisitazioni costituisce solitamente una pietra miliare per l'intero progetto. Per ciascuna delle fasi sopra desrcitte, vengono nel seguito brevemente riportati strutture e contenuti tipici dei relativi documenti.
URD: definizione e raccolta dei requisiti utente
Introduzione: scopo del documento, ambito del progetto, definizione e acronimi usati, documenti di riferimento e presentazione della struttura del documento.
Descrizione generale: essa dovrebbe includere informazioni come:
Prospettiva del prodotto: viene illustrata l'origine e l'eventuale evoluzione al termine del progetto.
Caratteristiche dell'utente: l'utilizzatore ed il committente sono descritti per meglio comprendere le necessità.
Vincoli generali: talvolta alcune scelte sono imposte dal committente o dall'ambiente esterno, come per esempio la macchina da impiegare, il sistema di sviluppo da utilizzare o le interfacce già esistenti.
Ipotesi e dipendenze: lo sviluppo può supporre l'esistenza di certe funzionalità o interfacce che non sono al momento disponibili o esistenti.
Ambiente operativo: descrive il mondo in cui il sistema si troverà ad operare; vengono tipicamente referenziate anche le interfacce verso l'esterno.
Requisiti specifici: questa parte costituisce il nocciolo del documento e deve contenere la completa elencazione di tutti i requisiti del sistema, in modo preciso e verificabile; ogni genericità deve essere evitata. Essi si possono dividere in:
Funzionalità ed operatività richieste dall'utente.
Vincoli su come il software deve essere costruito e come deve operare. Contengone richieste quali modificabilità, portabilità, disponibilità, sicurezza, standard da rispettare.
SRD: definizione dei requisiti software
Introduzione: scopo del documento, ambito del progetto, definizioni ed acronimi usati, documenti di riferimento e presentazione della struttura del documento.
Descrizione generale: contiene informazioni di carattere generale quali:
Relazione con altri progetti: vi possono essere altri sviluppi cui l'attuale si riallaccia, ed altri che ne potrebbero dipendere.
Funzioni e scopo: relativi al prodotto oggetto del progetto attuale.
Ambito: considerazioni relative all'ambiente:
- dove il prodotto verrà impiegato
- chi ne sarà l'utilizzatore
- su quale hardware dovrà essere eseguito
- quale sistema operativo supporterà il programma
- caratteristiche del sistema di sviluppo, del relativo sistema operativo e strumenti disponibili.
Relazione con altri sistemi: per chiarire se il sistema:
- sarà indipendente
- sarà un sottosistema di uno più ampio, di cui descrivere le caratteristiche e la struttura
- sostituirà un altro programma
|
| Strumenti per lo sviluppo di sistemi |
Lo sviluppo di software comprende una serie di fasi ed un'intensa elaborazione di informazioni.
In particolare, il legame che esiste a livello informativo tra le diverse fasi di sviluppo, in particolare la rintracciabilità dei requisiti sia in avanti (durante il flusso di progettazione) sia all'indietro (per esempio, nel caso di modifiche tardive). L'utilizzo di strumenti adeguati consente una gestione completa di tutto l'insieme delle attività e delle informazioni relative al prodotto.
A tale proposito, si parla genericamente di CASE (Computer-Aided Software Engineering) per |
|
|
Sistemi di supporto ale decisioni
Programmi per la gestione dei progetti ed il coordinamento di gruppi e risorse.
Come ogni strumento aziendale, anche il software vive le varie fasi di evoluzione ( Figura 1 - Modello applicabile alla evoluzione di mercato del prodotto software). Si può quindi far riferimento classicamente ai periodi di introduzione, evoluzione e crescita, maturità ed obsolescenza che caratterizzano il modello di mercato generalmente valido in ambito commerciale.
In misura forse maggiore di ogni altro tipo di prodotto, il software va poi soggetto ad un mutamento significativamente veloce nele condizioni applicative e nelle funzionalità richieste dai clienti stessi, così che sorgono nel corso della sua stessa vita esigenze di miglioramento, adattamento e più in generale, di modifica.
Tutto questo, unitamente alla sua natura intrinsecamente complessa, comporta una necessaria razionalizzazione dei processi di concezione, sviluppo, rilascio, evoluzione e manutenzione del software. In tale contesto, si parla di un vero e proprio ciclo di vita, suddiviso in fasi, all'interno delle quali vengono svolte le atività di concezione, studio di fatibilità, progettazione, sviluppo, verifica, rilascio, manutenzione e altre, tutte strettamente correlate col prodotto stesso. E' a questo punto che la ns società, con l'esperienza maturata in più di dieci anni di attività nel settore informatico, ha deciso di impiegare il termine più ampio di sistema, proprio per includere il concetto di complessità che intrinsecamente esso ha nell'ambito di questa trattazione; in tal caso si parlerà di sviluppo di sistemi.
Si può quindi definire quello che è per noi il sistema per il Cliente ( Figura 2 - Modello ED per lo sviluppo di sistemi). 
Figura 2 - Modello ED per lo sviluppo di sistemi
|
Vincoli generali: ovvero cosa limiterà lo sviluppatore nelle sue atività.
Modello logico: questo schema funzionale sarà di riferimento per la generazione dei requisiti funzionali; è di solito raccomandabile un approccio dall'alto al basso (top-down) per la scomposizione delle funzionalità.
Requisiti specifici: raggruppabili in:
Funzionali: descrivono "cosa" il sistema deve fare, senza pore vincoli sul "come", a meno che questi ultimi siano imposti dall'esterno o dal committente.
Prestazionali: sono espressi in modo misurabile, come per tempi di risposta, velocità di elaborazione, ecc.
Interafacce: elementi hardware e software con cui il sitstema deve interagire scambiando informazioni.
Operativi: indicano come il sistema interagirà con l'operatore (man-machine interface) in termini di schermate, messaggi di erore, aiuti in linea.
Risorse: ovvero i limiti superiori in termini di potenza di calcolo, memoria centrale, spazio su disco, ecc., che possono condizionare eventuaòli ampliamenti futuri.
Verifica: cioè il software verrà verificato, includendo eventualmente l'uso di simulatori, particolari vettori di input o condizioni operative di rilievo.
Accettazione: come il sistema verrà convalidato.
Documentazione: quali manuali o informazioni dovranno essere preparati per il rilascio.
Sicurezza: in termini di riservatezza, integrità e disponibilità del sistema.
Portabilità: su quali altri sistemi operativi o macchine è richiesto che il sistema possa essere fato funzionare (con modifiche ragionevoli).
Qualità: elencazione di standard applicabili, o vincoli qualitativi sull'impiego di personale esterno o subfornitori.
Affidabilità: quale livello di probabilità di buon funzionamento viene richiesto in condizioni operative concordate. Si impiegano metriche quali il tempo medio tra due guasti successivi (Mean Time To Failure) e la percentuale di disponibilità del sistema, in congiunzione con classificazioni sulla gravità (severity) del guasto/malfunzionamento.
Manutenibilità: l'attitudine del sistema a supportare attività di modifica, dovute alla introduzione di nuovi requisiti e funzionalità, o alla eliminazione di errori.
Sicurezza d'impiego (safety): in termini di limitazione dei rischi per persone e cose di valore.
Rintracciabilità dei requisiti: una matrice che consenta di "mappare" i requisiti dell'URD rispetto a quelli dell'SRD.
ADD: disegno architetturale
Introduzione: scopo del documento, ambito del progetto, definizione e acronimi usati, documenti di riferimento e presentazione della struttura del documento.
Generalità del sistema: breve introduzione al sistema. Può riassumere i costi ed i benefici della struttura del sitema adottata.
Contesto del sistema: descrizione della relazione del sistema col mondo esterno (interfacce esterne).
Progetto di sistema: contiene:
Metodo: il metodo adottato viene citato e spiegato brevemente.
Scomposizione: vengono elencati i componenti individuati. La loro relazione gerarchica, di controllo ed i flussi di dati sono evidenziati. Possono essere adottati opportuni metodi rappresentativi.
Descrizione dei componenti: essi vengono individualmente descritti in modo dettagliato nei seguenti termini:
Identificatore: ogni componente deve essere univocamente riferibile
Tipo: sottintende una classificazione di tutti i tipi di componenti
Scopo: ovvero l'ambito di applicazione
|
indicare i programmi che consentono di rendere più agevole tutta la filiera di produzione in ambito software.
Un ruolo tuto particolare è poi rivestito dagli strumenti di reverse engineering, in quanto consentono di ripercorrere in senso inverso la strada dello sviluppo: di solito vengono impiegati per generare, o ricosruire, una documentazione lacunosa o inesistente. Non esiste una soluzione univoca sulla scelta degli strumenti; tuttavia risulta essenziale, per ciascuna fase, tenere ben presente quali sono le necessità in materia ed i vincoli imposti (sviluppo individuale o di gruppo, in modo locale o remoto, limitazioni di |
|
|
| Sviluppo a cascata |
Figura 3 - Schema di sviluppo software a cascata
Per la realizzazione dei ns. sistemi aziendali, utiliziamo una metodologia riassunta in uno schema a cascata che rappresenta la sequenza logica delle attività (Figura 3 - Schema di sviluppo software a cascata).
Gli acronimi impiegati hanno il seguente significato:
UR: User Requirements (Phase), consiste di tute quelle attività volte a raccogliere e formalizzare i requisiti del committente, designandone l'importanza, e verificandone la compatibilità con vincoli imposti, come l'ambiente di operatività del sistema; il documento che riassume queste informazioni e costituisce l'outpu della fase è detto URD (User Requirements Document).
SR: Software Requirements (Phase), in cui vengono derivati, a partire dall'URD, i requisiti specifici del software. Viene del sistema realizzato un modello, che ne descrive funzionalità e prestazioni. il risultato della fase è l'SRD (Software Requirements Document).
AD: Architectural Design (Phase), nella quale viene definito il modello fisico insieme ai maggiori costituenti del sistema. L'esito della fase è l'ADD (Archittectural Design Document).
DD: Detailed Design (Phase), consente di definire i moduli, effettuare la stesura del codice, le attività di test a livello di unità, di integrazione e di sistema. L'outputdi questa fase consiste nel DDD(Detailed Design Document), del codice e del SUM Software User Manual).
TR: Transfer (Phase), include l'installazione del sistema, e le verifiche preliminari di accettazione. Genera in uscita l'STD (Software Transfer Document).
OM: Operations and Maintenance (Phase): prevede i test finali di accettazione, l'operatività, la manutenzione del codice e della documentazione. L'uscita di questa fase è il PHD (Project History Document).
|
Funzione: le caratteristiche operative
Subordinati: sotto-componeti
Dipendenze: la referenza gerarchica verso l'alto
Interfacce: attraverso quali "parametri" si relaziona con gli altri componenti
Risorse: in termini di mmoria, capacità di calcolo
Riferimenti
Elaborazione
Dati
Stime di fattibilità: valutazione dei possibili ostacoli di natura tecnica; vengono anche descritti i requisiti di infrastruttura per la costruzione e l'operatività del sistema.
Matrice di rintracciabilità: riferisce ciascun componente rispetto al corrispondente requisito software contenuto nel documento SRD.
DDD: disegno di dettaglio e codifica
Generalità:
Introduzione: scopo del documento, ambito del progetto, definizione e acronimi usati, documenti di riferimento e presentazione della struttura del documento.
Standard:
di progetto
di documentazione
di programmazione
convenzioni: per denominare file, programmi, moduli, ecc.
strumenti (tools) di sviluppo.
Specifiche dei componenti
Appendice A: Listati codice sorgente
Appendice B: Matrice di rintracciabilità dei componenti ripetto ai corrispondenti requisiti software.
SUM: manualistica d'uso
Introduzione:
Destinatari del documento
Applicabilità: versione di riferimento
Scopo: del manuale e del sofware
Utilizzo del documento
Documenti collegati
Convenzioni (simboli, stili, sintassi adottati)
Rapportistica dei problemi
Panoramica:
Processo supportato dal sistema
Principi del processo
Utilità del sistema
Relazione utente-sistema Istruzioni per l'uso Riferimenti operativi: elenco delle funzionalità
Appendice A: Errori procedure di recupero
Appendice B: Glossario
Appendice C: Indice.
STD: trasferimento del prodotto (implementation, o alestimento operativo) Introduzione: scopo del documento, ambito del progetto, definizione e acronimi usati, documenti di riferimento e presentazione della struttura del documento.
Procedure d'installazione
Procedure di build (approntamento)
Lista di configurazione del prodotto
Rapporto di accettazione
Rapporti dei problemi
Richieste di modifica Rapporti di modifica
PHD :storia del progetto
Descrizione del progetto
Gestione del progetto:
Approccio contrattuale
Organizzazione
Metodi
Pianificazione
Produzione del software:
Codifica: stima ed effettiva quantità prodotta
Documentazione
Risorse umane: stimate ed effettivamente usate
Risorse macchina: stimate ed effettivamente usate
Analisi produttività
Assicurazione qualità
Costi e finanze
Conclusioni
Prestazioni del sistema nella fase operativa.
|
tempistiche e di budget). Vi sono alcune attività molto importanti che si svolgono contemporaneamente alla durata di tutta la vita del prodotto; esse richiedono una elevata competenza sia tecnica che gestionale e strumenti oportuni per la loro gestione:
la pianificazione: ogni fase viene preceduta da un piano che ne prevede i tempi, i costi, l'impegno di risorse umane e tecnologiche.
la gestione della qualità complessiva: include l definizione della politica e delle procedure da seguire nel corso di tutto il progetto. |
|
