la corretta descrizione del problema nell'opportuno linguaggio (formale) può molto spesso rappresentare la soluzione.
Parliamo di software: i requisiti sono una rappresentazione del problema; ma anche il design è una rappresentazione del problema. Lo è in quanto descrive (in modo dettagliato, si spera) il dominio del problema da risolvere, specificandone gli attori e le relazioni. Dove il documento dei requisiti è una descrizione passiva del problema, il design ne è una descrizione attiva.
Il software emerge da una descrizione (e quindi, da una comprensione) sempre più dettagliata del problema da risolvere.
Ahh, che bel post.
poi mi guardo attorno...
Concordo pienamente.
RispondiEliminaL'utilizzo di una formalizzazione atta alla descrizione di un problema è, a mio avviso, l'unica via per eliminare stupide incomprensioni e per smascherare immediatamente l'eventuale malafede delle persone. Come diceva Galileo: "parla solo di ciò che può essere misurato, e se qualcosa non è misurabile, rendila tale".
Dopo tutto il codice stesso è una formalizzazione molto spinta della descrizione di un problema. Formalizzazione, tra l'altro, che a livello sintattico può essere strettamente controllata. Io posso parlare russo ed il mio interlocutore può parlare giapponese, ma basta metterci a scrivere codice per capirci perfettamente. Ovviamente sto parlando di persone che non hanno bisogno di commenti per saper leggere ed interpretare il codice.
Poi anche io mi guardo in torno e... mahh!
Luca Ciciriello