Peut-être que je poste ça au mauvais endroit mais je me posais pas mal de questions sur le rapport qu'entretient l'opensource et les méthodes de conception.
En effet, je suis étudiant, et j'apprends en ce moment à dompter le cycle en V et à jongler avec l'UML. Cependant, je ne vois rien de tout ça sur les sites des projets OpenSource.
Alors je me demandais si c'était utilisé ou pas ?
Si ces diagrammes sont jalousement gardés pour que les créateurs du soft soit les seuls à pouvoir modifier facilement leur code pour des clients potentiels ?
Si certains travaillent sur de gros projets ( eclipse, apache, openoffice.org,mozilla, ...), je me demandais comment ça se passait sur des gros projets opensource ?
Journal Conception et OpenSource
16
jan.
2005
# Méthodes de conception, processus de développement et Open Source
Posté par hamster . Évalué à 10.
Tu commence par parler du cycle en V. On est donc dans le domaine des processus de développent. Au niveau OpenSource, il y a un proverbe : "Release Early, Release often" (sortez tot, sortez souvent). Ce type de démarche est absolument antinomique des cycles en V (ou W, et autre joyeusetées), mais à à rapprocher des cycles itératifs et des méthodes agiles.
Bien sur, les développeurs n'ont pas une extreme rigueur sur ces processus, mais il y a tout de même des lignes de conduité générales, des habitudes prises par chacun, qui aboutissent à un processus modélisable (j'ai déjà modéliser le processus d'intégration des patchs du noyau linux en SPEM). Ces processus existent donc, mais sont très faiblement directifs pour que le projet reste très souple.
Après au niveau d'UML, tu parles ici d'expression d'arhcitecture. UML est un langage d'expression d'architecture. Il est utilisé dans le milieu industriel, et peu (je dit bien peu, car ce n'est pas nul non plus) dans les logiciels open sources. Cela est plus du à des habitudes de programmation code-centric, ou le code fait fois, alors qu'UML, pour que ce soit utilisable, se doit d'être utilisé de manière model-centric (cf. l'approche MDA promue par l'OMG). Par contre, d'autres outils sont utilisé. Je pense à des choses comme doxygen qui permettent de remonter des information du source pour obtenir un "model".
Enfin, les développeur openSource utilisent des outils collaboratifs tel que les mailing list pour communiquer, et font donc régulièrement des descriptions textuelles (ou en ascii-art) de leurs architectures, qui sont ensuite publiés sur des référentiels documentaires (allez fouillers dans les CVS, ou dans les fichiers publiés sur sourceforge, on trouve souvent ce genre de choses).
[^] # Re: Méthodes de conception, processus de développement et Open Source
Posté par Philippe F (site web personnel) . Évalué à 2.
L"objet des methodologies de developpement est d'encadrer un projet, de pouvoir mieux le planifier, de deceler des problemes, de bien preparer toutes les etapes du developpement et de la vie des produits et aussi d'avoir la certif ISO 9001 (tracabilite des specs, des plans de tests, des resultats, evaluation du risque, ...)
Toutes ces choses sont necessaires en entreprise, mais beaucoup moins importantes pour un projet open source.
Une toute petite equipe de dev n'a pas besoin de conception formelle pour faire du logiciel. Si mplayer prend un mois de plus a sortir, c'est pas grave. Et si au dernier moment, l'auteur decide de ne pas mettre la fonctionnalite X ou Y, c'est pas grave. Et il peut prendre la decision en 1 minute, il n'a pas besoin de se justifier, planning a l'appui. Comme c'est lui qui fait a la fois la conception, le codage, les tests et le planning, il n'a pas besoin de specs ecrites formelles.
Sinon, d'un point de vue perso, je trouve UML et tous les autres machins completement inutil, tout au moins dans mon travail. Ca fait 5 ans que je suis dans le logiciel et je n'ai jamais eu besoin d'UML. J'arrive encore a faire ma conception sur un bout de papier et comme mes logiciels font un peu moins de 50 000 lignes, il n'y a pas besoin de passer du temps a formaliser la conception. En plus, je reste persuade que le code reste quand meme un important facteur de pilotage d'un projet de dev et que cet aspect est occulte dans des methodlogies UML.
Je prefere netteemnt les methodes agiles comme XP et je regrette que le monde de l'open source n'en utilise pas plus, notamment en ce qui conerne les tests unitaires.
# Hum
Posté par cho7 (site web personnel) . Évalué à 1.
Alors je me demandais si c'était utilisé ou pas ?
je répond :
Oui bien sur !!
Je ne suis pas un fervent pro-analyse, mais faut reconnaitre que parfois une bonne analyse évite tout un tas de problèmes auxquels on aurait pas pensés avant.
Puis les codes sont ainsi souvent plus facilement modifiable, on ne doit plus tout recoder pour rajouter une fonction horloge a laquelle on n'avait pas pensé plus tot
Donc je peux affirmer sans me tromper que ton apprentissage de l'uml ne te sera pas inutile, c'est un même un élément essentiel pour travailler en entreprise (tu seras content quand l'équipe d'analyse t'aura remis un cahier rempli de diagramme de classe, de use case, etc, et que tu sauras les lire :) )
[^] # Re: Hum
Posté par Louis Nyffenegger . Évalué à 2.
En effet, si on sait vite comment est fait quelque chose, c'est plus facile de le réparer ou de l'améliorer.
Et donc si une avancée majeure dans le monde de l'opensource ne serait pas de publier ce genre d'information ou de les créer. Et ça augmenterait surement la réutilisabilité du code.
Quand au cycle en V, je me demandais si c'était compatible avec un développement opensource.
[^] # Re: Il y a d'autres raisons
Posté par gourgou . Évalué à 3.
Mais il y a un « mais », bien entendu ! On passe souvent trop vite sur le fait qu'un travail collectif n'est pas qu'une somme de travaux individuels, et on ne se rend donc pas compte que les individus, à leur échelle, n'ont pas forcément les mêmes objectifs (pas forcément avoués non plus) que la communauté à laquelle ils se veulent appartenir.
En un peu moins verbeux, un peu plus clair et un poil plus violent : un « free hacker », pris isolément, cherche assez souvent la reconnaissance de ses pairs. Pour l'obtenir, il faut que le reste de la communauté ait à passer par lui pour obtenir telle ou telle information... on pourrait même dire « connaissance ». S'il veut conserver cette reconnaissance, pour rester dans le coup, il ne peut que difficilement se permettre de rendre son savoir aussi public qu'il le prétend.
Résultat, l'idée répandue que pondre de la doc, ça fait perdre beaucoup de temps de codage, alors que « toute l'info est déjà dans le code, n'importe qui peut la faire, la doc » (1), sert en fait de plus sombres (in-)intentions. Je ne dis pas que c'est forcément conscient, mais il n'empêche qu'on a beau être programmeur, on se retrouve parfois à fouiller du code complètement imbitable. Je n'irais pas jusqu'à hurler à l'obfuscation, mais bon... sans analyse, on a l'architecture logicielle branlante qu'on mérite, aussi. ;)
Pour une explication un peu plus « propre » du phénomène, je ne saurais que conseiller vivement de jeter un oeil aux travaux de Thomas Basset :
http://thomasbasset.net/dea.php(...)
Pour ceux qui préfèrent la télé, sa conf à l'install party de l'ENS Cachan, en 2003, a été enregistrée (attention au mal de mer ;) :
ftp://ftp.crans.org/pub/Install-party/Thomas_Basset.ogm(...) (100Mo, plus de choix
sur http://install-party.ens-cachan.fr/index.php?p=photos(...) )
(1) Un exemple criant dans les sources (ou presque) du noyau : l'introduction de Documentation/sysctl/README.
# bof..
Posté par Nicolas Bernard (site web personnel) . Évalué à 6.
La philosophie O.S. utilise plutôt le principe KISS (Keep It Simple, Stupid), de manière récursive et fractale s'il le faut.
Ceci dit, peut-être que si ces méthodes étaient plus utilisées, il n'y aurait pas besoin pour la plupart des projets qui marchent de passer par une phase de remise à zero en recomençant from scratch avec une meilleure archi...
[^] # Re: bof..
Posté par Benjamin (site web personnel) . Évalué à 2.
grandiose, c'est redistribuable comme phrase ? paske je la mettrais bien dans mon quote of the day celle là tellement elle est belle ...
[^] # Re: bof..
Posté par Snark_Boojum . Évalué à 1.
Le principe de base, c'est le KISS ("Keep It Stupid Simple") (ie: "Faire complètement simple").
Quand quelqu'un s'en éloigne, on le rappelle à l'ordre: KISS! ("Keep It Simple, Stupid!") (ie: "Faire simple, andouille!").
Snark
[^] # Re: bof..
Posté par Nicolas Bernard (site web personnel) . Évalué à 2.
Tous mes commentaires sont dans le domaine public, avec tout ce que ça implique.
[^] # Re: bof..
Posté par gc (site web personnel) . Évalué à 4.
Il y a premièrement beaucoup d'étudiants qui n'ont pas beaucoup d'expérience qui développent des logiciels libres et qui sont des "programmeurs intuitifs" qui ont appris la programmation tout seul, deuxièmement beaucoup de "petits logiciels" pour lesquels une spec claire et précise paraît moins utile, et enfin troisièmement beaucoup de logiciels qui sont des copies de logiciels existants pour lesquels les specs sont donc déjà claires : copier.
À première vue on peut penser qu'une spec c'est un truc chiant à faire, qui prend du temps et qui est inutile. Il ne faut pas oublier les autres intérêts d'une spec : c'est aussi un outil de communication vers les autres départements de l'entreprise (pour qu'ils soient au courant de la situation du produit dans 3/6/9 mois) et vers les clients (pour qu'ils voient si ça correspond à ce qu'ils veulent et anticipent de leur côté l'évolution de leur interface/utilisation). Le cycle en V a toute sa place ici. Ces deux aspects effectivement n'ont rien à faire dans les projets libres. Mais il y a aussi un autre intérêt : forcer une réflexion de plus haut niveau et être un outil de communication dans les équipes de développement. C'est utile mais pas dans les petits projets libres.
Enfin j'ajouterai que dans mon expérience personnelle (ingénieur en informatique, professionnel depuis presque 5 ans, et auteur de logiciels libres de seconde/troisième importance) je n'ai jamais réussi à faire correctement des specs détaillées, et de m'en tenir à celles-ci : au moment des spécifications je n'arrive tout simplement pas à "voir" toutes les implications de tous les choix. Au moment du codage je dois changer des choses. J'ai toujours pensé que la raison c'était que je n'étais pas assez fort. Certains m'ont dit que c'est une question d'expérience. Bref, donc maintenant je fuie les "spécs détaillées auxquelles on se tient" pour privilégier des approches de spécs partielles (les spécs fonctionnelles, celles qui décrivent l'interface utilisateur) ou les specs livrées après implémentation partielle. Mais bon je n'ai jamais participé à une équipe de développement avec beaucoup de gens qui travaillent tous sur la même chose.
# A lire absolument ...
Posté par Matthieu Moy (site web personnel) . Évalué à 5.
http://www.linux-france.org/article/these/cathedrale-bazar/cathedra(...)
# Haut de page
Posté par Louis Nyffenegger . Évalué à 1.
Car j'aimerais bien avoir l'avis d'autres personnes et ça me parait un sujet de débat intéressant.
[^] # Re: Haut de page
Posté par BAud (site web personnel) . Évalué à 2.
en revanche en journal public avec une bonne accroche, ça peut déchaîner les foules et rester plus longtemps en haut
perso, ça m'intéresserait aussi : je me (re-)mets l'uml avec umbrello
je vais bientôt publier 2-3 schémas... (avec le source, comme ça ils seront en GPL j'espère)
et j'ai compilé une liste de quelques outils
http://wiki.eagle-usb.org/wakka.php?wiki=ModelizationTools(...) (quelques uns orientés base de données...) si vous en avez d'autres ?
# XP
Posté par Yann KLIS (site web personnel) . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.