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).
# Méthodes de conception, processus de développement et Open Source
Posté par hamster . En réponse au journal Conception et OpenSource. É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).