Pregunta

He estado tomando algunos cursos de diseño de software en los últimos semestres, y aunque veo el beneficio en gran parte del formalismo, siento que no me dice nada sobre el programa en sí:

  • No puede decir cómo va a funcionar el programa desde la especificación del caso de uso, a pesar de que discute lo que el programa puede hacer.
  • No puede contar nada sobre la experiencia del usuario del documento de requisitos, a pesar de que puede incluir requisitos de calidad.
  • Los diagramas de secuencia son una buena descripción de cómo funciona el software como pila de llamadas, pero son muy limitadas y ofrecen una visión muy parcial del sistema general.
  • Los diagramas de clases son excelentes para describir cómo se construye el sistema, pero son completamente inútiles para ayudarlo a descubrir cuál debe ser el software.

¿En qué parte de este formalismo está el resultado final: cómo se ve, opera el programa y qué experiencia da? ¿No tiene más sentido diseñar eso? ¿No es mejor descubrir cómo debería funcionar el programa a través de un prototipo y esforzarse por implementarlo de verdad?

Sé que probablemente estoy sufriendo por los teóricos que les enseñan ingeniería, pero necesito preguntar, ¿hacen esto en la industria? ¿Cómo descubren las personas cuál es realmente el programa, no a qué debería ajustarse? ¿Las personas prototizan mucho, o usan principalmente las herramientas formales como UML y todavía no podía entenderlas?

No hay solución correcta

Licenciado bajo: CC-BY-SA con atribución
scroll top