[APPUNTI DI INFORMATICA] - L'Analisi del Progetto 1/3

[APPUNTI DI INFORMATICA] - L'Analisi del Progetto 1/3 postato il 21/03/2016 09:07:14 nel forum programmazione, gdrcd, open source, hosting

Ciao a tutti,
iniziamo con questo primo passo dove la capacità del futuro gestore di saper comunicare le proprie necessità o saper tradurre su carta le proprie idee ed esigenze diviene fondamentale.

Esiste una regola aurea piuttosto semplice: se si riesce a spiegare il funzionamento di una procedura, allora vuol dire che questa è traducibile in un linguaggio di programmazione. Ovvero: se riesci a pensarlo vuol dire che si può fare.

Entriamo maggiormente nel dettaglio esaminando quelle che sono le due filosofie principali nell'ingegneria del software: top-down e bottom-up.

Queste due definizioni possono essere riassunte in poche parole:

top-down: si imbastisce il progetto creandone una vista completa, lasciando in un secondo tempo lo sviluppo dei moduli secondari (sottolivelli), deefinendo ogni aspetto prima di iniziare la vera codifica.

bottom-up: si inizia prima dal piccolo, da tutti i moduli che saranno compresi nel progetto futuro, scendendo nel dettaglio di ognuno di essi risalendo man mano fino allo schema generale.

Come si evince da quanto sopra, è chiaro che entramebi gli approcci abbiano vantaggi e svantaggi: il top-down permette di avere una chiara visione d'insieme e di sapere quale sia il risultato finale ancora prima di aver terminato la codifica ma non permette di effettuare test se non attraverso procedure di esclusione elaborate. Solitamente l'approccio top-down non permette modifiche sostanziali al progetto ma una volta terminata la definizione e codifica di tutti i sottolivelli (moduli) il progetto sarà pronto.

Nell'appoccio bottom-up si ha la possibilità di definire con cura ogni singolo aspetto ed effettuare test puntuali su ogni modulo ma questo potrebbe allontanare la visione d'insieme e creare problematiche, soprattutto nell'integrazione nel progetto e suo completamento che, ovviamente, sarà terminato quando tutti i moduli saranno funzionanti; il grosso vantaggio è poter vedere crescere il progetto in tempo reale, effettuare modifiche ed aggiunte in piena libertà.

Seppur quanto sopra esposto sembri difficile, basti pensare al seguente esempio:

il gestore, usando Photoshop o similari, prepara uno screenshot della chat "come vorrei che fosse" consegnandolo allo sviluppatore; quest'ultimo potrà cominciare subito ad implementare i sottolivelli (moduli) seguendo lo screenshot proposto. Questo permette di lavoare più celermente, avendo già chiaro in mente cosa il gestore voglia ma al contempo, in caso di modifiche, sarà da riorganizzare il codice. Questo è un esempio di approccio top-down per la chat ma bottom-up per il progetto intero in quanto vi è la definizione di un solo modulo (la chat).

"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live."

- Martin Golding

quota

Pagine → 1

soizora

SCRIVI

21/03/2016 11:56:57

Per molto tempo mi sono posto la questione se era meglio iniziare progettando tutto l'insieme e poi finendo i moduli tutti in una volta, o creare poco per volta i vari componenti e vedere quel che ne esce.

La conclusione che ne ho tratto è:dipende. Dipende da vari fattori, come il tempo a disposizione le proprie competenze, la complessità del progetto. In linea generale preferisco un sistema misto, una certa via di mezzo tra le due, basata sempre su una delle due metodologie ma a secondo delle necessità anche con grossi elementi della seconda.