|
|
 |
 |
Il concetti di base di ambedue i metodi sono essenzialmente i seguenti:
- L'attività di analisi o sviluppo seguiva un precorso pre-ordinato. Prima si faceva una cosa e successivamente sulla base di quelle decisioni o attività di procedeva alla cosa successiva. Tale modo di procedere si chiama metodologia waterfall. Si contrasta con una metodologia a prototipi e a ricicli dove si fanno delle cose e poi si rifanno sulla base di quanto si è imparato nella prima stesura.
- Ogni attività di analisi doveva produrre della documentazione.
- Per documentazione non si intendeva affatto un testo indicizzato e completo come un articolo o un libro, ma spezzoni di testo su un singolo argomento. Ad esempio in fase di analisi un documento poteva contenere la formula per calcolare il pmc di un titolo. Il tipico documento non superava le tre pagine scritte a mano. Un testo più esteso veniva spezzato in sotto-testi.
- Questi spezzoni di testo dovevano essere archiviati, indicizzati e nominati. In pratica ogni singolo foglio aveva un codice documento (ad esempio di documenti con codice DATA10 descrivevano un data base) e un nome (ad esempio fglaang).
- Si dovevano creare dei documenti indice che riepilogavano su una sola riga i documenti prodotti.
- Quando una certa attività richiedeva dei documenti di input---ad esempio scrivere un programma---si predisponevano dei pacchetti che raccoglievano tutti i documenti rilevanti alla stesura di quel programma.
- Le relazioni o documenti riassuntivi erano dei documenti (in mssi del gruppo doc) strutturati con un indice. Erano analoghi ai nostri manuali della Sim. Venivano compilati rileggendo e rielaborando i documenti staccati che erano stati prodotti.
Ovviamente all'epoca della matita vi erano notevoli inconvenienti:
- L'editing si faceva con la gomma, per cui di rado si scriveva di getto.
- Era necessaria una tediosa attività di archiviazione e indicizzazione dei singoli documenti.
- Era necessaria una tediosa attività di fotocopiatura dei documenti se si voleva distribuire ad altri una parte della documentazione.
- Era molto complicato censire e gestire i riferimenti incrociati tra i diversi documenti. Al punto che io e Michele facemmo fare un piccolo sistema sul mainframe, in SQL, per gestire i documenti. Aveva due tabelle:
- La prima censiva i documenti (campi: tipo; nome; titolo), ad esempio: "DATA10"; "FGLAANG.KEY"; "Anagrafiche Generali".
- La seconda tabella gestiva i riferimenti tra documenti e aveva due chiavi:
- Il documento contenitore: tipo; nome.
- Il documento contenuto: tipo; nome.
- Con questa semplice struttura si producono i due elenchi base:
- Used by.
- Where used.
- In quanto ogni campo era censito da un documento (es.: "DATE10"; "EGL0001"; "Identificativo anagrafica") un tracciato non era altro che un elenco "used by".
- La struttura era molto complessa da navigare e un'utente finale non era in grado di farlo.
- Quando si preparavano le relazioni (docxxx) queste pur derivando dai testi della documentazione di fatto dovevano essere riscritte per intero.
Per converso vi erano notevoli vantaggi:
- Quando si aveva un'informazione questa poteva essere documentata senza preoccuparsi di definirne il contesto.
- L'informazione veniva censita come si presentava.
- Più persone potevano raccogliere autonomamente informazioni diverse e censirle.
- Al momento di tirare le fila si creavano gli indici e si organizzavano le informazioni censite.
|