La création d'un document de conception de logiciel après le développement peut-elle se justifier?

Je travaille actuellement sur mon diplôme pour mes études "Développement de logiciels", dans lesquelles je dois développer individuellement des logiciels complexes dans une entreprise externe. Tout cela doit être fait de manière structurée, en créant tous les documents correspondants.

Pour ce projet, j'ai choisi de travailler avec les documents standard IEEE: Software Requirements Document (SRS), Software Architecture Documents (SAD) et Software Design Document (SDD). Bien qu'enseigné autrement à l'école, pour ce projet, j'ai choisi de créer le SDD après le développement (au lieu d'avant). Mon raisonnement est le suivant:

L'entreprise dans laquelle je fais mon stage m'a donné pour instruction de créer un logiciel complexe, répondant à un certain ensemble d'exigences, de manière expérimentale. En raison de la liberté qu'ils m'ont donnée dans la définition du projet, presque rien n'est certain à l'avance, et il est préférable de le rencontrer en expérimentant dans le processus de développement. De plus, je crée le logiciel de manière individuelle , cela n'aurait aucun avantage pour quiconque dans l'entreprise de faire cette conception de logiciel au préalable. Le faire à l'avance me coûtera juste beaucoup de temps pour le changer plus tard, car je peux être certain qu'avec les incertitudes du projet, la conception que je fais au préalable devra être beaucoup modifiée . Cela me semble contre-productif.

Est-ce une bonne justification pour créer le SDD après le développement? Sinon, y aurait-il une bonne justification à cela?

Edit: La raison de créer ensuite le SDD serait que les futurs développeurs continuent sur le projet. Je ne vais pas être en mesure de terminer l'ensemble du projet au cours de ma période de remise des diplômes, donc les autres développeurs devront continuer sur la base de code actuelle.

Dans IEEE Std 1016 Section 3.1 Conception logicielle en contexte, vous pouvez trouver ce paragraphe:

Un SDD peut être préparé et utilisé dans diverses situations de conception. En règle générale, un SDD est prêt à prendre en charge le développement d'un élément logiciel pour résoudre un problème, où ce problème a été exprimé en termes d'un ensemble d'exigences. Le contenu du SDD peut alors être retracé à ces exigences. Dans d'autres cas, un SDD est prêt à comprendre un système existant sans documentation de conception. Dans de tels cas, une DDS est préparée de telle sorte que les informations d'intérêt soient saisies, organisées, présentées et diffusées à toutes les parties intéressées. Ces informations d'intérêt peuvent être utilisées pour la planification, l'analyse, la mise en œuvre et l'évolution du système logiciel, en identifiant et en traitant les problèmes de conception essentiels.

Les auteurs de IEEE Std 1016 reconnaissent qu'un SDD ne peut pas être créé à l'avance. Un peut être créé après que le système logiciel existe afin de capturer des informations pour les parties intéressées.

La section 1.1 Champ d'application fournit également des informations intéressantes:

Cette norme ne prescrit pas de méthodologies spécifiques pour la conception, la gestion de la configuration ou l'assurance qualité.

Dans le cadre de ces questions, les mots clés sont "gestion de configuration". La gestion de la configuration s'applique non seulement au système logiciel en cours de création, mais à toute documentation associée.

Dans votre situation personnelle et dans de nombreuses situations, créer un SDD à l'avance est un gaspillage. La réponse de David Arno est presque ce que je considérerais comme la bonne réponse. La véritable conception de votre système logiciel est le code. Cependant, vous "créez le SDD avant" ou "créez le SDD après" ne sont pas vos seules options. Vous avez une troisième option - faire évoluer le SDD avec le système logiciel.

Si vous suivez une norme telle que IEEE Std 1016, vous avez des exigences pour un SDD. Plus précisément, la section 4 de cette norme définit le contenu dont vous disposez. Pendant que vous travaillez sur les décisions de conception, commencez à créer les différents points de vue, vues et superpositions. Lorsque vous prenez des décisions, saisissez la justification de leur conception.

Cela permettra aux parties intéressées de suivre l'évolution de la conception du logiciel sans avoir à fouiller dans le code. Bien sûr, les gens peuvent avoir des commentaires ou des suggestions. Si vous mettez à jour le SDD, ils peuvent suivre vos progrès et donner un retour sur l'approche tôt, que vous pouvez ensuite intégrer au produit ainsi qu'au SDD. Lorsque vous quittez le projet, si le code du logiciel et le SDD sont synchronisés, quelqu'un devrait pouvoir facilement embarquer et reprendre le travail.

Si tout ce que vous recherchez dans le SDD est de communiquer le design avec les autres, alors oui, vous pouvez le créer après le développement. La seule chose est que cela s'appelle alors la documentation.

Cependant, je voudrais souligner qu'un SDD peut également servir un autre objectif. Il peut également vous aider à raisonner sur la conception et à vous assurer que vous "échouez rapidement". C'est une bonne chose, surtout si beaucoup de choses sont incertaines à l'avance, car vous pouvez ignorer très tôt les approches qui ne fonctionneraient pas tout au long de la mise en œuvre. Cela peut également vous empêcher de vous concentrer sur les détails techniques trop tôt, en ne codant rien jusqu'à ce que vous ayez compris le design.

Je vous conseille de faire au moins une tentative de SDD au préalable. Si vous rencontrez des choses où vous ne savez pas comment les choses fonctionneraient, vous pouvez alors faire de petits prototypes des problèmes que vous essayez de résoudre. Cela vous donnera de l'expérience dans la résolution des problèmes spécifiques de votre projet qui bénéficieront à long terme de la qualité de la solution complète.

Le seul vrai document de conception détaillée que vous créerez est le code. Il indique précisément au compilateur comment créer votre application. En tant que tel, votre conception ne peut pas être terminée avant cette dernière version avant l'expédition.

Tout autre document de conception que vous créez, tel qu'un SDD, devra être mis à jour une fois votre conception (code) terminée. Par conséquent, il existe une raison impérieuse d'écrire le SDD par la suite: vous ne devez le faire qu'une seule fois.

Le contre-argument évident est "combien de fois écrivez-vous vraiment un SDD après l'événement"? L'application est livrée, vous ne voudrez donc probablement pas passer du temps à documenter à ce stade. Mais cela s'applique également à la mise à jour d'une version existante. Quel est le pire, pas de SDD ou un SDD qui ne va pas et auquel on ne peut pas faire confiance?

Il y a cependant deux raisons de l'écrire à l'avance. Tout d'abord, cela peut être une obligation pour vous de le faire (pas sympa, mais cela arrive). Deuxièmement, la création d'un tel document peut vous aider à formuler une stratégie globale pour la conception. Mais cela peut tout aussi bien se faire en dessinant des images, en griffonnant des notes, etc. de manière informelle. Et comme il faudra réécrire plus tard, l'approche «rapide et sale» de ce processus de conception de macros à l'avance présente de nombreux avantages.

Pour moi, ce ne serait pas une bonne argumentation.

Si vraiment nécessaire, je dirais avec un fort accent sur le développement de prototypes pour une meilleure compréhension d'un domaine de problème inconnu. Cependant, même dans ces cas, certains éléments de conception seraient utiles auparavant.

Il y a tout de même lieu de le faire dès le départ . Parce que vous faites cela pour apprendre à écrire des documents comme celui-ci. Ignorer ce travail car il n'est peut-être pas nécessaire à 100% ici signifie que vous sautez votre apprentissage.

Un compromis pourrait être de l'écrire lors de la mise en œuvre. Avant chaque composant / module / écran ou autre subdivision de votre programme, vous devez y penser comment vous allez le faire. Ensuite, vous ajoutez vos décisions à votre document de conception, puis les implémentez.

Si quelque chose change par la suite, vous mettez à jour le document.

Cela présente plusieurs avantages par rapport à l'écriture après coup:

• Vous apprendrez à maintenir les documents de conception à jour lorsque les exigences changent, une habitude utile

• Vous apprendrez à penser à la conception avant la mise en œuvre

• Ce n'est pas aussi ennuyeux que de rédiger des documents de conception après coup.

• Si vous manquez de temps, vous aurez un document de conception décrivant ce que vous avez jusqu'à présent afin que d'autres puissent continuer votre travail

• Ce n'est pas beaucoup de travail supplémentaire de cette façon

• Au cours de votre projet, vous ne savez peut-être pas pourquoi vous avez fait quelque chose de cette façon il y a deux mois, et vous aurez vos notes à vous dire.

Document de conception du système, un enregistrement des exigences de base et des mises à jour (nouvelles fonctionnalités) à mesure que le projet avance avec de nouveaux attributs de conception et de solution. Maintenu jusqu'à la livraison du projet / de la solution. Utile, il communique à toutes les personnes concernées.