Que planifier avant de commencer le développement d'un projet? [fermé]

Supposons que j'ai reçu les spécifications d'un projet d'un client et qu'il est maintenant temps de commencer à le développer. Normalement, je commence simplement par le premier module (généralement l'enregistrement des utilisateurs), puis je passe d'un module au suivant. Je planifie seulement dans ma tête juste avant de commencer un module sur la façon dont ça va fonctionner, mais il n'y a pas de planification avant cela.

Cependant, je pense que ce serait mieux si je passais en revue les spécifications et planifiais comment le système allait fonctionner avant de le coder, par exemple quels sont les principaux composants, comment ils vont interagir, etc. Je suis juste Je ne sais pas exactement ce que je devrais planifier.

Pour donner une meilleure idée de ce que je demande, comment dois-je-

a) Diviser le projet en composants,

b) Planifier leurs interactions, par exemple dois-je faire des diagrammes de classes, écrire des tests unitaires, etc.?

Des idées?

Lorsque vous avez le privilège de démarrer un nouveau projet, vous avez une toile vierge - ce qui est à la fois passionnant et intimidant. Je travaille par itérations, et voici comment je répartis le travail:

• Commencez par les objectifs du projet. Les objectifs sont nécessairement les plus vagues, mais vous aident à vous concentrer sur ce que le client ou l'utilisateur a l'intention de faire avec le logiciel. À la fin de la journée, vous voulez atteindre ces objectifs - même si cela signifie abandonner certaines fonctionnalités vraiment cool.
• Ensuite, je commence à décomposer l'application en ses sous-domaines. Il y a probablement une centaine de façons différentes de le faire, c'est pourquoi nous commençons par les objectifs du projet. Nous voulons diviser l'application en quelques sous-systèmes connexes qui prennent en charge ces objectifs. Cela nous aide à nous concentrer sur la prochaine tâche.
• Identifiez comment et quand les sous-systèmes doivent interagir. Nous ne traitons pas les détails, juste les informations de haut niveau pour nous assurer d'avoir un système intégré de sous-systèmes. Vous avez besoin d'une idée générale de cela pour pouvoir étoffer les détails qui soutiennent les objectifs globaux du projet.
• Fournissez uniquement les détails du sous-système sur lequel je travaille actuellement (similaire à votre stratégie actuelle). Je sais déjà comment ce sous-système doit interagir avec d'autres sous-systèmes, mais je devrai peut-être trouver quelques alternatives pour que cela ait le plus de sens. Chaque sous-système est séparé par une interface, donc je peux ajuster l'implémentation autant que possible sans casser le système dans son ensemble.
• Examinez comment les choses sont implémentées dans mon sous-système actuel par rapport à la façon dont elles sont implémentées dans d'autres sous-systèmes. Chaque approche qui n'est pas cohérente est quelque chose que l'utilisateur doit apprendre. Ce n'est pas grave si nous parlons d'un tout nouveau concept. Pour des raisons de convivialité, nous ne voulons pas 5 façons différentes de supprimer les informations qui sont présentes simplement parce que nous étions paresseux. La réutilisation des mêmes éléments de l'interface utilisateur est le moyen le plus rapide de rendre l'application plus intuitive. Apprendre trois concepts est beaucoup plus facile que d'apprendre 20.

Essentiellement, cette approche de définition progressive d'un projet de très haut niveau à une conception plus détaillée m'a bien servi. Même les interactions entre les sous-systèmes s'affinent au fur et à mesure que vous essayez de les implémenter. C'est une bonne chose.

Je pense que ce serait mieux si je revoyais les spécifications

Droite. Bonne idée.

planifié comment le système allait fonctionner avant de le coder.

Bien. Faites-en plus.

quels sont les principaux composants,

Excellent.

comment ils vont interagir,

Correct.

Je ne sais pas exactement ce que je devrais planifier.

Comment pouvez-vous ne pas être sûr lorsque vous avez déjà répertorié un tas de choses? Si ce sont les choses qui vous préoccupent, pourquoi ne pas vous concentrer uniquement sur ces choses?

Lisez sur le modèle de vue 4 + 1: http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model

Pour en savoir plus sur le cadre Zachman: http://en.wikipedia.org/wiki/Zachman_Framework

C'est ce que vous devez planifier.

comment dois-je a) diviser le projet en composants,

Utilisez des modèles de conception largement adoptés pour d'autres projets similaires.

En cas de doute, lisez les plans J2EE pour les idées.

http://www.oracle.com/technetwork/java/javaee/blueprints/index.html

comment dois-je b) planifier leurs interactions, par exemple dois-je faire des diagrammes de classes, écrire des tests unitaires, etc.?

Oui. De bonnes idées, tout.

La chose la plus importante à faire: revoir les spécifications, interagir avec le client pour obtenir des spécifications plus raffinées.

Les exigences sont sans aucun doute incomplètes, vagues ou incorrectes. La plus grande perte de temps est de faire la mauvaise chose. Les clients ne sont pas des ingénieurs logiciels professionnels et on ne peut pas s'attendre à ce qu'ils développent un bon ensemble d'exigences.

Donc, vous devriez revoir les spécifications, interviewer le client et savoir si c'est ce dont il a vraiment besoin et ce qu'il veut, ce qu'il peut se permettre, etc.

Développer des cas de test / utilisation et revoir avec le client. Si une exigence n'est pas testable, jetez-la.

Développez la conception et assurez-vous que si toutes les pièces fonctionnent correctement, cela ferait en théorie ce dont vous avez besoin.

Développer un prototype d'architecture qui teste toutes les technologies à utiliser dans chaque couche mais ignore les fonctionnalités. Vous testez l'architecture, pas la spécification fonctionnelle. Avoir la mauvaise architecture signifie que vous devez tout réécrire, il est donc important d'avoir la bonne architecture. Assurez-vous qu'il peut répondre à vos exigences en termes de vitesse, d'efficacité, de sécurité, etc.

Vous voulez certainement avoir une conception en place avant de commencer à coder.

Une fois que vous avez cela, je préfère généralement faire d'abord une phase d'architecture initiale afin de définir la façon dont vos couches d'application s'emboîtent. Cela inclurait des éléments essentiels comme la sécurité et la journalisation.

Ensuite, je crée 1 fonctionnalité de haut en bas afin que vous ayez implémenté quelque chose complètement.

Ensuite, partez de là.

Tout

Planifiez tout, il est plus facile de le changer sur papier qu'une fois qu'une partie est déjà codée, vous obtenez une excellente base de documentation et de nombreux autres avantages.