Domanda

Ho seguito alcuni corsi di progettazione di software negli ultimi semestri e mentre vedo il vantaggio in gran parte del formalismo, sento che non mi dice nulla sul programma stesso:

  • Non puoi dire come funzionerà il programma dalle specifiche del caso d'uso, anche se discute cosa può fare il programma.
  • Non è possibile raccontare nulla sull'esperienza dell'utente dal documento dei requisiti, anche se può includere requisiti di qualità.
  • I diagrammi di sequenza sono una buona descrizione di come il software funziona come stack di chiamata, ma sono molto limitati e offrono una visione altamente parziale del sistema generale.
  • I diagrammi di classe sono ottimi per descrivere come è costruito il sistema, ma sono assolutamente inutili nell'aiutare a capire cosa deve essere il software.

Dove in tutto questo formalismo è la linea di fondo: come appare il programma, opera e quale esperienza offre? Non ha più senso progettarlo? Non è meglio capire come il programma dovrebbe funzionare tramite un prototipo e sforzarsi di implementarlo in realtà?

So che probabilmente sto soffrendo di essere insegnati ingegneria dai teorici, ma devo chiedere, lo fanno nel settore? Come fanno le persone a capire cos'è effettivamente il programma, non a cosa dovrebbe conformarsi? Le persone prototipano molto o usano principalmente gli strumenti formali come UML e non ho ancora capito di usarle?

Nessuna soluzione corretta

Autorizzato sotto: CC-BY-SA insieme a attribuzione
scroll top