|
Analisi
e progettazione object oriented
Analisi e progettazione
(design), un confine in crisi
L'ingegneria del software proponeva,
fino a pochi anni fa, una distinzione netta tra le attività di analisi
e design (progettazione):
- Analisi:
lo studio di cosa deve fare il sistema (punto di vista "logico")
- Design:
lo studio di come il sistema deve venire implementato (punto
di vista "tecnico").
Negli ultimi anni, questa distinzione
tradizionale è entrata in crisi:
- Il confine non è
preciso. Dove, effettivamente, dovrebbe fermarsi l'analisi? Dove iniziare
il design? Il diavolo sta nei dettagli.
- Il processo "a
cascata", sequenziale, in cui il design inizia solo al termine
dell'analisi e della validazione da parte del committente, funziona
quando il committente è in grado di fornire i requisiti in modo
chiaro e completo all'inizio del progetto, senza ripensamenti o aggiunte
successive; inoltre, affinché il processo sequenziale funzioni
è necessario che la specifica di analisi sia completa ed esaustiva.
Ciò ha portato al ripensamento
delle modalità di interazione tra committenti e progetti, alla consapevolezza
della necessità di una gestione sistematica dei requisiti, alla definizione
di modelli di sviluppo di tipo iterativo
e incrementale.
- Sul versante dei metodi,
all'approccio strutturato,
che proponeva tecniche distinte per l'analisi e per il design, si è
sostituito quello object oriented, nel quale le
tecniche per condurre le due attività sono in larga misura le stesse,
e la separazione viene risolta (vedere, a questo proposito, il Domain-Driven
Design proposto da Eric Evans).
Corsi e workshop:
|