Planification d'objets ou planification du flux d'utilisateurs - qui devrait être prioritaire?

Question

Lors du démarrage d'un nouveau logiciel, trouvez-vous plus utile de planifier d'abord l'interface et les cas d'utilisation, ou de définir les objets qui devront être construits?

Je peux voir un argument pour le premier en ce sens que vous devez savoir où vous allez avant de pouvoir y arriver. Mais quand je dis «cas d'utilisation de l'interface», j'entends un flux d'application TRES SPECIFIQUE. Fondamentalement, l'ensemble du logiciel sur papier. La seconde, la planification de la «grande image» programmatique, pourrait vous permettre d'éviter les goulots d'étranglement de développement potentiels. Il aide également à comprendre le flux d'applications et pourrait quelque peu modifier l'interaction de l'utilisateur. D'après vos expériences, quelle est la meilleure utilisation du temps à l'avant?

Answer 1

Je vois de fausses alternatives dans cette question.

Certains systèmes n'ont même pas d'interface utilisateur! Par conséquent, vous ne pouvez raisonnablement pas vous attendre à une seule réponse universellement applicable à cette question.

Dans de nombreux systèmes, il existe en réalité des modèles d'objet distincts pour la couche logique d'entreprise et la couche d'interface utilisateur, et il peut en effet y avoir plus d'une interface utilisateur. Par exemple, une interface utilisateur client fournie dans un navigateur et une application client épaisse pour l'équipe de support client.

Les cas d'utilisation et les interfaces utilisateur ne sont pas la même chose. Les premières questions peuvent être: "Parlez-moi de ce que vous devez faire lorsque vous créez un nouveau Wibble." Pas besoin de parler d'interface utilisateur du tout au début. Vous pouvez modéliser le scénario en termes de "Je veux que le système ...".

Pragmatiquement, lorsque vous dessinez des écrans, vous construisez probablement un modèle mental de Business Objects. Dans une simple analyse de rentabilisation, il se peut que vous n'ayez pas besoin de documenter ce modèle immédiatement. Dans des scénarios plus complexes, en particulier lorsque vous traitez avec des systèmes dorsaux hérités, vous trouverez bientôt le besoin de capturer une partie de ce modèle: "Donc, cet écran est sur Wibbles? Et à propos de leurs Zetules? Chaque Wibble a-t-elle sa propre Zetule? , Plusieurs! Et pouvons-nous les changer, les passer à d'autres Wibbles? Oh seulement les Zetules bleues sont transférables?.. "

Comme cela a été dit avant que ça va être interative et créatif Le premier modèle d'écran de coupe changera Vous découvrirez de plus en plus de bits noueux

Ma réponse explicite:. La meilleure utilisation du temps jusqu'à Les dragons se cachent dans l'inconnu Les gros dragons sont un risque, et se cachent dans des endroits difficiles.La gnarité est spécifique aux projets, parfois son interface utilisateur n'est pas le cas.En ce qui concerne les systèmes hérités en particulier, ce n'est généralement pas l'interface utilisateur. Vous passez le temps où le risque est

Answer 2

Je suggérerais certainement d'étaler d'abord le flux utilisateur, car il est si spécifique. Avec une interface utilisateur plus commune, il serait plus facile de planifier/deviner les objets. Cependant, puisque vous avez une spécification détaillée pour le flux d'applications, abordez-le d'abord, car les objets de planification trop tôt manqueront certainement la cible pour une bonne partie de la spécification.

Answer 3

Le flux utilisateur d'abord: vous créez un logiciel pour l'utilisateur. Une fois que vous savez ce que vous devez faire (l'ensemble de l'image), vous pouvez penser à la façon dont vous voulez le faire.

Answer 4

Elles peuvent se produire en parallèle et ne doivent pas nécessairement être terminées avant le début du codage. Avec le développement itératif, vous ne concevez pas nécessairement le logiciel entier sur le papier ou le modèle entier de classe.

Les interactions de l'utilisateur ont un impact sur le modèle de classe. Cependant, vous pouvez avoir suffisamment d'informations pour commencer à concevoir des couches architecturales avant que la conception de l'interaction de l'utilisateur ne soit terminée. Par exemple, le modèle de données peut être connu en totalité ou en partie avant que vous commenciez à concevoir des interactions spécifiques.

Les problèmes d'horaires peuvent rendre le travail en parallèle plus souhaitable, en particulier si plusieurs collaborateurs contribuent depuis le début.