1. SSADM
2. Environment of analysis and design
3. Lo studio di fattibilità ( Planning )
4. Analisys
5. Design
6. Functional-point
7. Implementation
8. Testing & Integration
9. Maintenance

1. è l'abbreviazione di Structured System Analysis and Design Methodology
2. è un'insieme di standard e approcci per lo sviluppo di sistemi informativi
3. è spesso specificato come requisito per i progetti informatici governativi in UK
4. è di dominio pubblico ed è formalizato nello standard BS7738
5. è stato sviluppato dalla Learmonth Burchett Management Systems ( LBMS )
6. è totalmente basato sul metodo a cascata quindi non può essere troncato in compiti paralleli. I risultati di ogni fase d'analisi confluiscono nella fase successiva
7. divide il progetto in fasi, moduli, passaggi e compiti.
   
   Esistono tre moduli che vengono utilizzati per definire lo stesso sistema, ma in modo diverso:
   
   
   1. Data view → vengono utilizzati tutti i dati e le informazioni descrittive
   2. Process view → vengono formalizzati i processi o le azioni in dettaglio
   3. Event view → è una descrizione degli eventi del sistema, cioè i "trigger" che fanno partire i processi
8. Vantaggi
   
   
   1. tempistiche → consente di pianificare, gestire e controllare il progetto, sul divenire delle fasi del protocollo
   2. uso efficace delle competenze → fornisce una linea franca per l'integrazione e la comunicazioni tra i player ( shackholders, end-user, project manager, developer )
   3. ambiente di qualità → riduce gli errori come effetto di una gestione puntuale
   4. riduzione dei costi → separa la progettazione fisica e logica del sistema, che evita la revisione delle specifiche hardware-software

   SSADM si basa sulle tradizionali tecniche di programmazione strutturata. Utilizza un processo di progettazione formale che discende direttamente dalle metodologie a cascata. Questo processo tende a essere relativamente lento, ma esaustivo sia nel trovare che nel discutere ogni ragionevole esigenza e a generare una visione macchinosa, ma completa.
   
   In opposizione a tecniche RAD e agile che offrono un sistema smart ma non resiliente al tempo

9. Svantaggi
   
   
   1. eccessiva analisi → alcune implementazioni non richiedono necessariamente che ogni fase della metodologia sia applicata in modo rigoroso
   2. tempi di rilascio sul breve → la metodologia tende a un dispendio di risorse e una rapida obsolescienza del requisito, sono invece appannaggio di sistemi aziendali consolidadi o orientati a un processo d'analisi RAD e agile

SSADM prevede alcune fasi comuni che facilitano il passaggio dal concetto, al prototipo, all'ambiente di "Quality assurance".

1. lo studio di fattibilità → è una panoramica di alto livello del progetto e dei suoi benefici
   
   

   Cosa spera di ottenere lo sviluppo e quali problemi si propone di risolvere.

   Si svolge solitamente l'analisi costi-benefici
.
2. l'analisi dei requisiti → è un'indagine sulle opzioni tecnologiche e commerciali che delineano il processo specifico
   
   

   In questa fase gli sviluppatori di sistemi familiarizzano con il gergo tecnico delle aree aziendali e rivedono i requisiti sui dati e le esigenze del sistema. Si lavora sul confronto tra le funzionalità dell'ambiente attuale e quelle del sistema proposto

   End-User e stakeholders sono fortemente coinvolti nel processo
.
3. la specifica dei requisiti → le specifiche funzionali e non funzionali vengono identificate in dettaglio
   
   

   Si sceglie l'opzione di sviluppo che meglio soddisfa le esigenze degli utenti

   Inizia la progettazione logica del sistema, che prevede un'analisi costi-benefici sulle opzioni hardware
   
   
4. la progettazione logica → il nuovo sistema
   
   

   Vengono modellati i database, le funzioni di aggiornamento e cancellazione e i metodi di gestione sui processi informativi

5. la progettazione fisica → il nuovo sistema
   
   

   in questa fase, sia i dati che le opzioni di elaborazione, vengono convertite in un ambiente di "Quality assurance"

Dove nascono gli errori e le ambiguità nella progettazione di un sistema informativo ?

1. l'interazione con i fornitori di servizi per la stesura del documento di progetto, può cadere in una forma contradditoria e incompleta, lontano dalle esigenze stipulate con gli stakeholder ed end-user


2. l'utilizzo di sistemi aziendali consolidati può non essere esaustivo
   
   
   1. tecniche come → data flow e entity modelling, non inserite dentro una metodologia di sviluppo, possono creare uno strato funzionale generico ed eroneo tra le parti
3. i requisiti del sistema possono subire cambiamenti interni o esterni, non patuiti a priori.
4. i cambiamenti, da una notazione ad un'altra, da un piano ad un'altro del progetto, introducono errori