Dans quelle mesure le prototypage est-il le premier stade de développement?

J'ai suivi des cours de conception de logiciels au cours des derniers semestres, et même si je vois l'avantage de beaucoup de formalisme, j'ai l'impression que cela ne me dit rien sur le programme lui-même:

• Vous ne pouvez pas dire comment le programme va fonctionner à partir de la spécification de cas d'utilisation, même s'il explique ce que le programme peut faire.
• Vous ne pouvez rien dire sur l'expérience utilisateur à partir du document d'exigences, même s'il peut inclure des exigences de qualité.
• Les diagrammes de séquence décrivent bien le fonctionnement du logiciel en tant que pile d'appels, mais sont très limités et donnent une vue très partielle du système global.
• Les diagrammes de classes sont parfaits pour décrire la façon dont le système est construit, mais ils sont totalement inutiles pour vous aider à comprendre ce que le logiciel doit être.

Où se situe le fond de tout ce formalisme: à quoi ressemble le programme, comment fonctionne-t-il et quelle expérience il donne? N'est-il pas plus logique de concevoir à partir de cela? N'est-il pas préférable de comprendre comment le programme devrait fonctionner via un prototype et de s'efforcer de le mettre en œuvre pour de vrai?

Je sais que je souffre probablement de l'enseignement du génie par des théoriciens, mais je dois demander, font-ils cela dans l'industrie? Comment les gens peuvent-ils déterminer ce qu'est réellement le programme, et non à quoi il devrait être conforme? Est-ce que les gens prototypent beaucoup ou utilisent-ils principalement des outils formels comme UML et je n'ai pas encore compris comment les utiliser?

Si nous construisons une application GUI, nous créons presque TOUJOURS un prototype ou POC (proof-of-concept). Nous déterminerons le vocabulaire visuel de l'application. Nous impliquons généralement nos clients à mi-chemin du POC et nous nous assurons qu'ils comprennent quel est le but et sur quoi ils devraient se concentrer. Je n'ai jamais regretté d'avoir produit un prototype. Assurez-vous simplement que vous n'essayez pas de transformer le code du prototype en code de production, démarrez le code de production à partir de zéro en fonction de ce que vous avez appris du prototype.

Cela dit, nous ne réalisons presque jamais de prototype d'applications côté serveur (services, middleware, etc.). Je ne vois pas vraiment le retour sur investissement pour cela (sauf si vous faites de nouvelles technologies et devez prouver différents concepts).

Dans le monde des affaires, cela compte beaucoup

Moi aussi, je pense que jusqu'à ce que vous arriviez dans le monde des affaires. Ensuite, ce n'est plus assez simple pour simplement prendre les exigences et aller de l'avant et construire.

C'est dans les affaires que les diagrammes de flux utilisateur et les prototypes lo-fi ont vraiment du sens.

Le fonctionnement du "programme" est probablement la partie la plus facile. Dans les applications LOB (Line Of Business), la plupart ne sont que CRUD. Le défi réside dans la logique et les règles métier . C'est là que les diagrammes de flux utilisateur et les flux de processus métier deviennent extrêmement importants pour comprendre et planifier efficacement.

Que voulez-vous dire par le fonctionnement du programme? Vous semblez rechercher des détails d'implémentation exacts dans autre chose que l'implémentation finale spécifique, ce qui n'a pas de sens. Les éléments de niveau supérieur sont censés guider la mise en œuvre et non la déterminer.

D'après mon expérience, le prototypage est quelque peu rare. Cependant, cela m'a certainement été enseigné conjointement avec les spécifications, les exigences, l'architecture, etc., et cela peut être très utile.

Quant à «ce que doit être le logiciel», c'est LA condition requise. Vous semblez manquer le point entier.

Les interfaces sont souvent esquissées à l'avance et des cas d'utilisation peuvent être utilisés pour le "flux" d'interface. L'expérience utilisateur ne manque pas du tout. Si vous sentez qu'il manque un élément, faites autre chose que vos professeurs n'ont pas mentionné. Le design ne consiste pas en un ensemble clair de règles transmises du ciel.

Mon observation personnelle est que le prototypage reçoit beaucoup de paroles, mais trop souvent, le prototype, une fois qu'il montre des signes de vie, est simplement renommé `` Beta '' ou, pire encore, v1.0.

il existe deux types de prototypage - trois, en fait:

1. nous construisons des prototypes pour affiner la conception et réduire les risques avant de débuter le "vrai" codage (Ingénierie)

2. nous construisons le projet comme une série de prototypes raffinés (Agile)

3. nous construisons un prototype et l'expédions dès qu'il fonctionne (Cowboy)

Ce que vous recherchez s'appelle la spécification - vous pouvez lire une description de cela ici dans l'un des articles de Joel

http://www.joelonsoftware.com/articles/fog0000000035.html

Un prototype peut également être considéré comme «l'itération 0» de ce que vous devez faire. Il remplit plusieurs choses:

• Cela prouve que le concept peut être fait. Cela peut être à votre patron ou à un client payant.
• Il vous permet d'identifier les éléments qui peuvent être difficiles à atteindre pour atteindre la force de production et vous donne une idée générale de la quantité de travail nécessaire.
• Vous avez en fait du code qui fait quelque chose . C'est extrêmement important!

Dans l'ensemble, le prototype devrait très probablement être utile pour la construction du produit final, sauf si vous avez constaté qu'une approche complètement différente est nécessaire.