J'ai programmé depuis quelques années et j'étudie maintenant la science informatique à l'université. Chaque fois que j'ai codé quelque chose, je l'ai fait en démarrant mon éditeur et en improvisant. Méthodes d'écriture, classes comme je vais. Bien sûr, j'y pense à l'avance, je sors du papier d'esquisse et écrivez mes idées, faites une petite liste de choses à faire, etc. Cela peut travailler pour écrire de petits bits de code ou logiciels simples et relativement petits, mais que diriez-vous de celles complexes?
Lorsque vous souhaitez faire un logiciel complexe, comment le planez-vous? Les architectes changent un bâtiment avant de commencer tout travail réel sur celui-ci et ils le font en suivant les normes suivantes. Je suppose que les programmeurs le font, mais je n'en ai jamais entendu parler. Quelles sont les méthodes, les outils et les étapes qui sont utilisées pour le faire.
Je ne veux pas d'opinions.
J'aimerais quelque chose de spécifique: graphiques? Plans? Outils? Techniques? Processus étape par étapes? ...
5 Réponses :
Blueprints Architectes un bâtiment avant de commencer tout travail réel, et ils le font selon les normes suivantes.
En effet, avec de nombreux domaines, il y a la connaissance exacte au préalable. Ce qui est en cause, quelles règles, quelles lois de la physique, quelles sont les règles à considérer. Voilà pourquoi il est possible de blueprint la chose jusqu'au dernier clou.
Avec le logiciel, il est très différent. Tu peux faire ce que tu veux. Vous pouvez rejoindre quelque chose et personne ne peut vous dire qu'il est bon ou mauvais. Parce qu'il n'y a pas de normes. Seul opinion subjective.
Chaque fois que je l'ai codé quelque chose, je l'ai fait en démarrant mon éditeur et improvise. méthodes d'écriture, des cours que je vais. Bien sûr, je pense à l'avance, je prends du papier croquis et d'écrire mes idées vers le bas, faire une petite liste de choses à faire, etc
Voilà comment ça fait habituellement. Vous pouvez expérimenter avec des cadres, des outils, des architectures avant de commencer le projet. Par exemple, faire quelques projets de test pour apprendre ce que vous devez essayer de « plan directeur » de votre logiciel avenir.
Je ne veux pas d'avis.
Chaque réponse est ici va être une opinion. Parce qu'il n'y a pas de normes pour revenir à. L'expérience et l'opinion.
Je Voudrais quelque chose de spécifique: les graphiques? Plans? Outils? Techniques? Étape par étapes processus?
Ce qui a fonctionné pour la plupart est:
Faire participer les utilisateurs dès le début dans votre projet. Collect régulièrement des commentaires pour ajuster votre cours.
Soyez agile et suivre une sorte de processus itératif. Tout d'abord, vous esquissez l'interface utilisateur. Obtenez les commentaires. Ensuite, vous mettre en œuvre des fonctionnalités générales. Avoir un retour. Ajustez votre cours. Mettre en œuvre quelques fonctionnalités supplémentaires. Etc. Tôt ou tard, il y aura assez de viande pour aller v.1.
Si vous avez besoin absolument des directives strictes, puis utilisez UML (Unified Modeling Language) des graphiques et des diagrammes et adopter le RUP (Rational Unified Process) ou ses analogues. Vous pouvez suivre Scrum , il y a aussi une activité d'organisation ivolved.
Tout d'abord, j'aime les cartes d'esprit pour visualiser ce que cette pièce de logiciel devrait faire et quelles sont les contraintes pertinentes (technologie, performance, points d'intégration, etc.). J'aime utiliser freemind (OSS) à cette fin. Je pense qu'il y a une grande différence entre simplement parler des exigences et les écrire, car ce dernier vous oblige à y penser plus précisément. Surtout si vous n'êtes pas familier avec le domaine problématique.
Au moment où je suis fait avec cela, j'ai généralement un très bon plan de choses dans ma tête et commencez tout de suite à coder. Sinon, je commence à dessiner des choses sur papier dans une notation pseudo-UML. UML est une langue de modélisation, spécifiquement destinée à cette fin. Il définit des représentations visuelles courantes pour les classes, les méthodes, les flux d'interactions, etc. Il n'est pas rare que votre conception changera un peu au fil du temps car votre aperçu du problème augmente tout en écrivant le code. Il est important de ne pas hésiter à adapter votre conception à chaque fois que cela se produit.
Selon la taille du problème à modeler, vous pouvez trouver utile d'utiliser un outil UML. Mais généralement, ils sont très rigueurs et non flexibles. Surtout lorsque je décide de changer la conception de mon code, mes diagrammes UML sortent de la synchronisation très rapidement. Ce que je fais vraiment, c'est le concepteur de classe Visual Studio, car cela fonctionne dans l'inverse, je peux déposer mon code dessus et génère une représentation visuelle (UML simple) de celui-ci.
+1 Mind Maps sont incroyables
Vous devriez probablement prendre une conférence sur l'ingénierie logicielle si vous êtes intéressé par le processus de conception et de développement du logiciel.
Les autres réponses ont déjà donné des notes avec ce respect; Cependant, un aspect important qui ne devrait pas être négligé est que avant de commencer votre conception, vous devez réellement écrire ce que votre logiciel est supposé faire sous une forme d'un Spécification des exigences logicielles :
Une spécification de configuration logicielle est une description complète de la comportement du système à être développé. Il comprend un ensemble d'utilisation des cas qui décrivent tous les Interactions Les utilisateurs auront avec les logiciels. Les cas d'utilisation sont également connus comme exigences fonctionnelles. Dans ajout aux cas d'utilisation, les SRS aussi contient non fonctionnel (ou exigences supplémentaires). Les exigences non fonctionnelles sont exigences qui imposent des contraintes sur la conception ou la mise en œuvre (telle comme ingénierie de la performance exigences, normes de qualité ou contraintes de conception).
Un tel document vous aide à rester concentré, d'obtenir clairement sur les cas d'utilisation réels, de trouver des défauts potentiels, de définir certains objectifs (par exemple en ce qui concerne la performance). La spécification sera également la base de la vérification de votre mise en œuvre finale (votre logiciel fait-il que ce qu'il est censé faire?) Et vous aider à créer des scénarios de test.
Mon processus "étape par étape" serait ceci:
Conseil du livre: Relâchez-le
La réponse standard Nexdays est plutôt simple: dessiner des diagrammes UML.
retour dans les années la réponse qui aurait été: "Draw Filks", "Dessinez des diagrammes de Nassi-Shneiderman", "Dessiner des diagrammes Warnier / Orr", "Dessinez des diagrammes de flux de données" ... etc
Ils seraient toutes bonnes réponses et mauvaises réponses en même temps. La réalité est qu'il n'y a pas de bonne réponse à la question pour la raison simple que personne ne sait vraiment quel logiciel est réellement .
Avant que les gens ne sautent sur ma gorge, laissez-moi vous expliquer ce que je veux dire.
Lorsqu'un architecte crée une impression bleue d'un bâtiment, le produit final est clair: ce sera une structure physique avec des murs, des portes, des fenêtres, etc. Notre architecte dessinera une ligne et dire: "Ceci est un mur" ; Dessinera une autre ligne et dire: "C'est le câble d'antenne TV du toit au sous-sol". En utilisant une convention sur les dimensions (la balance), les couleurs et les types de lignes, il sera capable de communiquer aux autres ce qui doit être construit et comment les choses correspondent ensemble.
Il pourrait y avoir un malentendu sur les détails, mais personne ne doute que le modèle 2D qu'ils examinent, représentent réellement un bâtiment. Même si plusieurs diagrammes sont nécessaires (par exemple un par plancher), il est assez facile de les raconter.
Pour un système logiciel, nous ne sommes pas encore à ce niveau! La première question est "Comment modéliserez-vous le logiciel"?
Si vous utilisez l'approche orientée objet, vous décrirez votre logiciel en tant que jeu d'objets appartenant à des "classes" qui sont liés les uns aux autres (comme décrit dans le "diagramme de classe"), avec un comportement donné ( un "diagramme d'état") et qui interagissent de certaines manières (comme décrit dans un ensemble de "diagrammes de collaboration").
Il n'y a pas de schéma unique qui vous montrera tous les aspects d'un système logiciel. C'est pourquoi UML comprend de nombreux types de diagrammes.
Si vous utilisez une approche structurée , vous décrirez votre système en tant que jeu de composants de traitement qui transforment leur entrée en sorties (un DFD) et en tant qu'entités de données définies (comme diagramme d'ER ).
Tout diagramme fonctionnera tant que sa signification est claire à toutes les parties concernées. En fait, il est courant de démarrer une session de design en dessinant deux boîtes sur le tableau blanc et une ligne qui disait: "OK, c'est le navigateur qui se connecte à notre serveur Web ...".
Le problème réside exactement dans ce que chaque diagramme signifie.
En réalité, nous avons un bon moyen courant de représenter la partie de données d'un système: un diagramme de relation d'entité (ou la "partie statique" d'un diagramme de classe) peut être directement traduit dans une base de données en direct. J'adresse cela au fait que les bases de données relationnelles sont fondées sur l'algèbre relationnelle et, en même temps, ils utilisent des concepts simples que quiconque peut saisir (tables, clés étrangères, rejoindre, ...). Toutes les autres représentations des données ont été essuyées (plus de bases de données hériatrycales autour!).
Ce que nous manquons est une vision commune et acceptée des aspects dynamiques du logiciel; une certaine opinion unificatrice qui serait à la fois théoriquement sain et non difficile à utiliser.
Cela dit ici est ma suggestion.
La réponse de chacun était utile, mais puisque je ne dois en choisir qu'un seul, le vôtre était le plus complet. Je suppose que je vais essayer d'apprendre UML et certains des diagrammes que vous avez mentionnés pour un début. Ensuite, je suppose que la partie importante est que vous ayez un moyen d'exprimer votre programme clairement pour vous et d'autres dans votre équipe.