Concevez-vous / dessinez-vous / dessinez-vous une solution de développement puis développez-vous? Si c'est le cas, comment? [fermé]

Question

Je travaille souvent avec des décideurs qui cherchent à mieux utiliser la technologie dans leurs activités. J'ai constaté qu'une image valait mieux que mille mots et que le prototypage d'un système dans un diagramme de quelque sorte prêtait toujours beaucoup à une discussion. J'ai utilisé Visio, UML (un peu), cartes conceptuelles, diagrammes de flux et WinForms simulés pour lancer la vision de ces sponsors afin de garantir que tout le monde est sur la même page. Je semble toujours être à la recherche de ce processus commun qui peut être utilisé pour associer la vision de l'entreprise au processus de développement, de sorte que nous aboutissions tous au même objectif, " quelque chose de fonctionnel qui résout un problème ". .

Je suis à la recherche de suggestions ou de notes Cliff sur la manière d’aborder le processus de conception de manière à ce qu’il fonctionne pour des applications dont le développement peut ne prendre qu’une semaine, mais qui peuvent également être utilisées pour englober des projets plus importants.

Je sais que cela va dans le domaine de UML, mais j’ai eu du mal à trouver un guide pour utiliser correctement les différents types de diagrammes, sans parler d’aider les utilisateurs professionnels à comprendre les diagrammes et à les comprendre.

Qu'est-ce que vous utilisez pour capturer une vision d'un système / application à présenter ensuite aux sponsors d'un projet? (avant d’écrire une seule ligne de code) ...

Answer 1

Papier ou tableau blanc!

Pour les développeurs isolés, je recommanderais le papier. Au moins au début, vous voudrez peut-être formaliser le document avec UML, mais je ne pense pas que ce soit nécessaire.

Pour un groupe de développeurs travaillant ensemble (physiquement), je recommanderais un tableau blanc. De cette façon, il est visible pour tous et chacun peut s’améliorer et contribuer. Encore une fois, vous voudrez peut-être formaliser à ce stade, mais je ne pense toujours pas que cela soit nécessaire

Quand j'ai commencé à faire de la programmation orientée objet (ou à concevoir un algorithme), je le faisais tout dans ma tête pendant le codage. Mais après avoir réalisé des projets complexes raisonnables, je vois vraiment l’avantage de tirer les interactions entre les différents objets d’un système.

Comme je fais des projets moi-même, j’utilise beaucoup de fiches pour la conception de classes et de papier pour leurs interactions. Le fait est qu'il doit être facile à changer. J'ai joué avec Dia, un éditeur de diagramme, pour utiliser UML, mais apporter des modifications est trop difficile. Je veux pouvoir faire des changements rapides pour pouvoir déterminer ce qui fonctionne le mieux.

Il vaut la peine de mentionner que TDD et la réalisation de projets "en pointe" [1] peuvent également aider à la conception d'un système.

[1] Extrait de Extreme Programming Adventures en C #, page 8:

  

"Spike" est un terme de programmation extrême   signifiant "expérience". Nous utilisons le mot   parce que nous pensons à une pointe en tant que   expérience rapide, presque brute force   visant à apprendre juste une chose.   Pensez à enfoncer un gros clou dans un   tableau.

Answer 2

Pour les tâches petites ou très limitées, je pense que les développeurs s'accordent presque universellement pour dire que toute sorte de diagramme est une étape inutile.

Toutefois, lorsque vous traitez avec un système plus grand et plus complexe, en particulier lorsque plusieurs processus doivent interagir ou qu'une logique métier complexe est nécessaire, Diagrammes d'activité de processus peut être extrêmement utile. Nous utilisons des méthodes agiles assez pures en développement et nous trouvons que ce sont presque le seul type de diagramme que nous utilisons. Il est étonnant de constater à quel point vous pouvez optimiser une conception de haut niveau simplement en disposant toutes les grandes pièces devant vous et en les connectant avec des lignes de flux. Je ne saurais trop insister sur l’importance d’adapter le diagramme à votre problème, et non l’inverse. Ainsi, même si le lien vous donne un bon point de départ, ajoutez simplement ce qui a du sens pour représenter votre système / problème.

En ce qui concerne le stockage, le tableau blanc peut s’avérer très utile pour la réflexion et l’affinement de l’idée, mais je dirais que l’électronique et un wiki sont préférables une fois que l’idée prend une forme définitive (OmniGraffle est le roi des diagrammes). si vous avez la chance d'utiliser un Mac au travail :). Avoir une zone où vous vider tous ces diagrammes peut être extrêmement utile pour quelqu'un de nouveau à comprendre rapidement une partie du système sans avoir à fouiller dans le code. De plus, comme les diagrammes d'activité représentent des blocs logiques plus grands, il n'est pas nécessaire de toujours les tenir à jour. Lorsque vous apportez un changement important à un système, alors oui, mais vous espérez probablement utiliser le diagramme existant pour planifier le changement malgré tout.

Answer 3

Découvrez les vues 4 + 1 de Kruchten.

Voici une façon de procéder.

1. Recueillez les cas d'utilisation dans un diagramme de cas d'utilisation. Cela montrera les acteurs et les cas d'utilisation. Le diagramme ne commence pas avec beaucoup de détails.

2. Donner la priorité aux cas d'utilisation pour se concentrer sur les cas d'utilisation de grande valeur.

3. Rédigez des récits. Si vous le souhaitez, vous pouvez dessiner des diagrammes d'activité.

Ce qui précède est totalement non technique. UML impose quelques règles sur les formes à utiliser, mais à part cela, vous pouvez décrire des éléments dans la terminologie de l'utilisateur final.

1. Vous pouvez effectuer une analyse de noms en dessinant des diagrammes de classes pour illustrer les entités et les relations. Au début, ceux-ci seront dans la terminologie de l'utilisateur. Pas de contenu technique geek.

2. Vous pouvez développer les diagrammes d'activité ou ajouter des diagrammes de séquence pour afficher le modèle de traitement. Cela commence par les descriptions non techniques du traitement par l'utilisateur final.

3. Vous pouvez parcourir les diagrammes de classe et d'activité pour passer de l'analyse à la conception. À un moment donné, vous serez sorti de l'analyse et du mode ingénierie. Les utilisateurs peuvent ne pas vouloir voir toutes ces images.

4. Vous pouvez dessiner des diagrammes de composants pour la vue de développement et des diagrammes de déploiement pour la vue physique. Ceux-ci seront également répétés à mesure que votre conception du système se développera et s’affinera.

Answer 4

Lors de la conception d'une application (je crée principalement des applications Web, mais cela s'applique aux autres), je crée généralement des user stories pour déterminer exactement ce dont l'utilisateur final a réellement besoin. Celles-ci constituent les "besoins métier" typiques.

Une fois les user stories définies, je crée des organigrammes qui présentent les chemins empruntés par les utilisateurs lors de l'utilisation de l'application.

Après cette étape (qui nécessite parfois un processus d’approbation), je crée des croquis d’interface (stylo / crayon et papier graphique) et commence la mise en page des bases de données. Ceci et la prochaine étape sont généralement le processus qui prend le plus de temps.

La prochaine étape consiste à prendre les croquis et à les transformer en structures filaires nettoyées. J'utilise OmniGraffle pour cette étape: il est à des années-lumière de Visio.

Après cela, vous voudrez peut-être créer des diagrammes UML typiques, ou une autre organisation d'objets / fonctionnalités, mais les hommes d'affaires ne se soucieront pas autant de ce genre de détails:)

Answer 5

Lorsque je conçois un dessin, je me dois de transmettre les idées proprement et simplement au public. Ce public est composé (généralement) de personnes différentes issues de milieux différents. Ce que je ne veux pas faire, c’est de passer en " mode d’enseignement " pour un modèle de conception particulier. Si je dois passer un temps considérable à expliquer à mon client ce que signifie la flèche avec la tête pleine et en quoi elle est différente de celle qui est creuse ou de la signification d'un carré par rapport à un cercle, je ne fais pas de progrès - du moins pas le progrès Je veux.

Si c'est assez informel, je vais le dessiner sur un tableau blanc ou sur du papier - bloc et flèches simples tout au plus. Le but de la conception approximative à ce stade est de s'assurer que nous sommes sur la même page. Cela variera toutefois d'un client à l'autre.

S'il est plus formel, je pourrais extraire un outil UML et assembler des diagrammes, mais la plupart du temps, mes clients n'écrivent pas de logiciels et ne sont probablement que marginalement intéressants. Nous le conservons à la & bulle; bulle et ligne " niveau et peut constituer des listes à puces où des éclaircissements sont nécessaires. Mon client ne veut généralement pas voir les diagrammes de classes ou quelque chose du genre.

S'il faut montrer une interaction graphique, je vais combiner quelques prototypes de fenêtres simples dans Visual Studio: c'est simple et rapide. J'ai constaté que le client pouvait facilement comprendre ce qui se passait.

En résumé, je produis des dessins simples (dans un certain format) pouvant communiquer la conception aux parties intéressées et aux parties prenantes. Je m'assure de savoir ce que je veux que ce soit et surtout - ce dont ils ont besoin pour le faire, et j'en parle. En règle générale, il ne se mêle pas aux mauvaises herbes, car les gens s'y perdent et je trouve qu'il est trop peu de temps passé à tout schématiser. En fin de compte, si le client et moi (ainsi que toutes les autres parties concernées) sommes sur la même page après avoir discuté de la conception, je suis un gars heureux.

Answer 6

Je suis un gars agile, j'ai donc tendance à ne pas consacrer beaucoup de temps à la création de diagrammes. Il est certain que parfois, dessiner quelque chose sur un tableau blanc ou sur une serviette vous aidera à comprendre un problème ou une exigence en particulier, mais rien ne vaut le fait d’obtenir un logiciel fonctionnel devant un client pour qu’il puisse voir comment cela fonctionne. Si vous vous trouvez dans une situation où vos clients accepteraient des itérations et des démonstrations fréquentes au-delà de la conception initiale, je leur réponds. C’est encore mieux s’ils sont en mesure d’obtenir rapidement des commentaires en passant des tests unitaires ou d’intégration (quelque chose comme Fit fonctionne bien ici).

Je n'aime généralement pas les prototypes, parce que trop souvent, le prototype devient le produit final. J'ai eu la malchance de travailler sur un projet qui consistait essentiellement à étendre une offre commerciale qui se révélait être une "preuve de concept". qui a été emballé et vendu. Le projet a été annulé après la consignation de plus de 1 000 défauts dans l'application principale (sans compter les améliorations et les personnalisations sur lesquelles nous travaillions actuellement).

J’ai essayé d’utiliser UML et j’ai constaté qu’à moins que la personne qui regarde les diagrammes comprenne le langage UML, ils n’ont que peu d’aide. Les maquettes d'écran ne sont généralement pas une mauvaise idée, mais elles ne montrent que le côté de l'application qui affecte directement l'utilisateur. Vous n'avez donc pas beaucoup de temps pour tout ce qui n'est pas présenté. Bizarrement, des outils tels que le concepteur de flux de travail dans Visual Studio produisent des diagrammes assez clairs qui sont faciles à comprendre pour les non-développeurs. C'est donc un bon outil pour générer un flux de travail d'application principal, si votre application est suffisamment complexe pour en tirer profit.

Pourtant, parmi toutes les approches que j'ai utilisées au fil des ans, rien ne vaut un utilisateur qui met la main sur quelque chose pour vous dire à quel point vous comprenez bien le problème.

Answer 7

Je suggère de lire les articles de Joel sur les "Spécifications fonctionnelles indolores". La première partie s'intitule "Why Bother?" .

Nous utilisons Écrans de maquette au travail ("Prototypes d'écran rapides et faciles"). Il est facile de modifier les écrans et les mises au point indiquent clairement qu'il ne s'agit que d'un design.

Les maquettes sont ensuite incluses dans un document Word contenant la spécification.

Answer 8

De Blockbusting conceptuel: guide des idées meilleures de James L. Adams:

  

Les blocages intellectuels entraînent une   choix inefficace de tactiques mentales   ou une pénurie de intellectuelle   munition. . . . 1. Résoudre le   problème d'utilisation d'une langue incorrecte   (verbal, mathématique, visuel) - comme   en essayant de résoudre un problème   mathématiquement quand il peut plus facilement   être accompli visuellement

(p. 71, 3e édition)

Inutile de dire que si vous choisissez d’utiliser des diagrammes pour capturer des idées qui pourraient être mieux capturées par les mathématiques, c’est tout aussi mauvais. Bien entendu, le truc consiste à trouver le bon langage pour exprimer à la fois le problème et la solution. Et, bien sûr, il peut être approprié d’utiliser plusieurs langues pour exprimer à la fois le problème et la solution.

Ce que je veux dire, c'est que vous supposez que les diagrammes sont la meilleure voie à suivre. Je ne suis pas sûr de vouloir accepter cette hypothèse. Vous obtiendrez peut-être une meilleure réponse (et le client sera peut-être plus satisfait du résultat) via une autre méthode d’exigence de cadrage et de conceptions proposées.

À propos, le conceptuel Blockbusting est une lecture vivement recommandée.

Answer 9

Le conseil UML fonctionne bien si vous travaillez sur un grand & amp; projet aversion pour le risque avec beaucoup de parties prenantes et avec beaucoup de contributeurs. Même sur ces projets, il est vraiment utile de développer un prototype à montrer aux décideurs. Généralement, il suffit de les guider dans l'interface utilisateur et une histoire d'utilisateur typique suffit. Cela dit, il convient de garder à l’esprit que le fait de se concentrer sur l’interface utilisateur pour que les décideurs aient tendance à leur faire négliger certains problèmes d’arrière-plan importants tels que les validations, les règles commerciales et l’intégrité des données. Ils auront tendance à considérer ces problèmes comme "techniques". questions plutôt que des décisions d'affaires.

Si, par contre, vous travaillez sur un projet Agile permettant de modifier rapidement le code (et d'annuler rapidement les erreurs), vous pourrez peut-être créer un prototype évolutif avec tous les travaux. L'architecture de votre application doit être suffisamment souple et souple pour permettre un changement rapide (par exemple, un modèle de conception d'objets nus ou un MVC de type Rails). Il est utile d’avoir une culture de développement qui encourage l’expérimentation et reconnaît que BDUF n’est pas un prédicteur du succès des logiciels.

Answer 10

Les vues 4 + 1 ne conviennent qu'aux techniciens. Et seulement s'ils sont assez intéressés. Vous vous souvenez de la douzaine de fois où vous avez eu du mal à discuter de diagrammes de cas d'utilisation avec le client?

La seule chose que j'ai trouvée qui fonctionne avec tout le monde est en fait de leur montrer les écrans de votre application. Vous avez dit vous-même: une image vaut mille mots.

Curieusement, deux approches ont fonctionné pour moi:

1. Présentez aux utilisateurs un manuel utilisateur complet (avant même le début du développement), OU
2. Utilisez des maquettes qui ne ressemblent pas du tout à une application terminée: discutez d'abord des écrans principaux de votre application. Lorsque vous êtes satisfait, continuez en discutant des maquettes mais un scénario à la fois.

Pour l'option (1), vous pouvez utiliser ce que vous voulez, cela n'a pas vraiment d'importance.

Pour l'option (2), il est tout à fait possible de commencer avec un stylo et du papier. Mais vous ferez vite mieux d’utiliser un outil de maquette spécialisé (dès que vous aurez besoin de modifier, de maintenir ou d’organiser vos maquettes).

J'ai fini par écrire mon propre outil de maquette en 2005, il est devenu très populaire: MockupScreens

Et voici la liste la plus complète des outils de simulation que je connaisse. La plupart d'entre elles sont gratuites: http://c2.com/cgi/wiki?GuiPrototypingTools