Discussion :

[Hibou57]

J'aurais aimé en faire un sondage, mais c'est difficile de trouver des termes de sondage adéquates pour cette question.

C'est une chose qui est dans mon esprit comme un concept, un but du processus de developpement logiciel, mais qui n'est pas une méthode de developpement, et je pense que ça peut être le point de départ d'une discussion interessante, si cela vous parle.... vous pouvez en tous les cas donner votre avis.

« On peut penser le developpement logiciel de sorte que même si un projet n'aboutie pas, alors des éléments d'aboutissements partiels de ce projet puissent être utiles/interessants en eux-même seuls (étude d'un sujet, discussions, documentations, récolte d'informations, ...) »

Ce que je veux dire dans cette idée, c'est que par exemple, on produit des choses pendant la tentative de réalisation d'un projet, mais que parfois il se peut que se projet doive être abandonner, ou mis en suspend pour une durée indeterminée pour des raisons diverses. On devrait toujours avoir ceci à l'esprit, et pour ne pas travailler pour rien donc, l'objectif à suivre lors de la tentative de réalisation d'un projet, ne devrait pas être seulement et uniquement l'aboutissement du projet. C'est à dire encore que pendant le processus de réalisation, on peut se pencher périodiquement sur la question de savoir si on a produit des choses utiles à quoique ce soit (même en dehors de l'utilité du projet lui-même).

Je donne un exemple qui n'est peut-être pas le meilleur, mais qui me vient à l'esprit comme ça. Par exemple, vous voulez concevoir un compilateur. C'est une tâche trés ardue et de longue haleine. Vous n'êtes pas certain(e) d'y aboutire. Mais vous pouvez aborder le projet en le segmentant, et en prevoyant par exemple des algorithmes d'analyse sémantique qui pourront être utile à un outil d'analyse utile ou qui pourront vous inspirer dans la réalisation d'un outil d'audit de sources, même si le compilateur n'aboutie pas.

Un autre exemple : vous voulez créer une bibliothèque d'interface pour le langage XYZ pour interfacer le système d'exploitation SuperMegaBidule. Vous n'êtes pas certain(e)s que cela aboutisse, mais la phase de récolte d'informations vous amêne à créer des documents fort-interessants pour la documentation de ce système, ou encore cela peut vous amenez à des reflexions sur les OS qui peuvent être utiles à quelqu'un(e) qui travail dans ce domaine.

Je ne sais pas si ces exemples vous aident à mieux percevoir l'idée de fond...

Est-ce que cette manière d'appréhender les choses, d'integrer l'incertitude de l'aboutissement d'un projet vous inspire des reflexions ?

Exprimez-vous librement

[djflex68]

La modélisation et la programmation objet répond à la problématique de réutilisation. Si le projet n'aboutit pas, on peut toujours (si on a bien fait son modèle) réutiliser les classes concues dans un autre contexte ...

[Hibou57]

Merci pour ta réponse djflex,

La POO est largement débordée par ce que j'entendais : elle ne comprends que des composants logiciels fonctionels, et ce dont je parlais est plus large que cela. Je parlais de *tout* ce qu'on peut produire pendant la conception d'un projet.

D'ailleurs, d'expérience je sais que l'objet a des limites rapidement atteintes en ce qui concerne la réutilisation. Il faut souvent en passer par d'autres choses plus abstraites, comme la documentation, la théorisation ; ou d'autres notions concrêtes, comme le design-pattern, ou même des alternatives aux objets sont parfois plus adéquates, comme les unités.

Je sort un peu du sujet, mais cela démontre les limites qu'il y-a à toujours tout ramener à la POO.

« Objet » n'est pas une formule magique, et la plus grande partie du travail fait en developpement n'a rien à voir avec la POO (elle est même presque accessoire dans le fond, et des alternatives toutes aussi viables et pratiques existent le plus souvent... même si c'est un peu abusé, c'est que je ressent d'expérience)

[Hephaistos007]

Voilà mon point de vue:

1) Tu traite de la capitalisation des efforts nécessaire au developpement logiciel.
2) Cette capitalisation est nécessaire pour une réutilisation ultérieure, mais cela n'est pas toujours possible.
3) Cette capitalisation intervient à chaque étape du cyle de développement du logiciel :

On peut capitaliser au stade de :
* Expression des besoins
* Analyse
* Conception & specification
* Implémentation
* Test
* Deploiement
* Maintenance

A chaque stade, on utilise des formalismes de représentation totalement différents. La capitalisation se fait dans ces formats respectifs.

4) Tout cela n'est pas nouveau. Ces réflexions ont été abordées en 1970 lors d'une conférence mondiale pour faire face à la fameuse "crise du logiciel".

[Hibou57]

Oops... dois-je en penser que j'ai dit une bétise ? :-p

Alors ça c'est interessant.... et alors ça a donné quelque chose d'interessant ?

Peut-être alors qu'on aurait un interet à se re-poser ces questions ? Parce que pour ce que j'en vois... ça me semble être bien loin des préoccupations principales dans le domaine (c'est pas pour rien si j'ai fini par poser cette question qui me trotine dans la tête de plus en plus).

Hum, le terme de capitalisation me semble bien approprié (mais je ne l'utilise jamais personellement, et quand je l'ai lu, j'ai cru que j'étais en train de lire autre chose).

C'était un genre de « Club de Rome » de l'informatique alors ? et à peut-prêt à la même époque...

Merci pour toutes ces infos trés utiles... je vais essayer d'en retrouver des restes avec les références que tu me donne.

... beh, je vais finir par me dire que j'ai un abonnement à ressortire les vieilleries lol. Sur un autre topic concernant les OS, on m'a fait remarqué que j'avais remonté un vieux truc sans interêts parce que trop vieux... mais moi je le trouvais trés interessant...

Bon Week-end monsieur 007

@+

[bruno_pages]

Au risque de jeter un pave dans ma marre, developper dans un but de reutilisation n'est pas toujours utile (en suposant comme le souligne '007' que cela soit 'vraiment' possible) et peut meme etre anti economique.

En fait ce qui compte c'est le temps passe a faire la chose. Le credo est souvent de developper 'generic' pour pouvoir reutiliser ou potentiellement modifier plus tard. Premierement, a moins de deja connaitre les evolutions futures, c'est un 'plan sur la commette'. Ensuite, si cela demande 3 fois plus de temps, alors mieux vaut ne pas faire reutilisable, on pourra pour le meme prix recommencer encore deux nouvelles fois (ce qui n'aura peut etre jamais lieu), sachant qu'en fait ce sera moins cher car se qui compte vraiment c'est l'experience acquise. Seul probleme, l'experience n'est pas transmissible :-)

Tout cela ne veut evidemment pas dire qu'il faut faire n'importe quoi n'importe comment ...

[Hephaistos007]

Au risque de jeter un pave dans ma marre, developper dans un but de reutilisation n'est pas toujours utile (en suposant comme le souligne '007' que cela soit 'vraiment' possible) et peut meme etre anti economique.

Oui, cela peut parfois être vrai mais ce n'est surement pas la tendance dominante. Un des buts de la réutilisation (mais pas le seul) est au contraire de diminuer les coûts.

Ensuite tu touches du doigt 2 approches très intérressantes qu'on appelle design by reuse et design for reuse. La première approche consiste à concevoir et développer par réutilisation maximale de briques logicielles prédéfinies. La seconde consiste à concevoir ces briques logicielles, c'est à dire s'appliquer à créer ces éléments réutilisables par des techniques particulières (les generics en sont une proposition). En fait chacune de ces approches concernent un acteur différent: le client a certaines préoccupations de réutilisation, le fournisseur en a d'autres.

Dans le monde du centré reutilisation, cette notion de client et de fournisseur est importante et se retrouve à tout les étapes du cycle de développement.