IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Qualité Discussion :

[Experience] Comment justifier une refonte architecturale ?


Sujet :

Qualité

  1. #1
    Membre confirmé

    Homme Profil pro
    Indépendant
    Inscrit en
    juin 2002
    Messages
    540
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Indépendant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juin 2002
    Messages : 540
    Points : 607
    Points
    607
    Par défaut [Experience] Comment justifier une refonte architecturale ?
    Bonjour à tous,

    Comment justifiez-vous le besoin de refonte architecturale d'une application ?

    Je m'explique:
    Les modèles, les besoins et les connaissances évoluent sans cesse et dans une vision à long terme, il peut s'averer judicieux de refondre l'architecture d'une application avant meme de connaitre l'ensemble des contraintes a venir: "openness", "flexibility", "scalability" ...

    Par exemple, un composant est de plus en plus utilisé au sein d'une equipe/entreprise alors qu'il n'avait ete concu que pour repondre a un ensemble de contraintes. Une vision a long terme serait de l'orienter service pour élargir son champ d'action.

    Aujourd'hui, le choix se pose donc entre une integration de k*x hommes*jours (k=nb de composants et x=cout moyen) et k*y+z hommes*jours ou z>x.

    Quelles sont vos experiences face a ce dilemne ? Comment justifiez vous hierarchiquement ce besoin de maniere marketing ?

    Ludo
    Fondateur Alien6 : Prescriptive Analytics & Machine Learning Software

  2. #2
    Expert éminent
    Avatar de djo.mos
    Profil pro
    Inscrit en
    octobre 2004
    Messages
    4 666
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : octobre 2004
    Messages : 4 666
    Points : 7 668
    Points
    7 668
    Par défaut
    La refonte architecturale, pour moi en tout cas, est une chose trés fréquente.

    Pour des petrits projets, pas de problèmes, je me lancais tout de suite dans la programmation, et au fur à mesure que des problèmes surviennent, je bricolais une solution (sale), le plus important etait de finir.

    Mais quand un jour, j'ai eu l'imbécile idée de developper un moteur 3D (Delphi, openGL), J'en ai vu des vertes et des pas mûres !
    A chaque fois que je voulais ajouter un effet ou une fonctionnalité, j'avais à réecrir d'énormes portions de code, pour que la chose marche.
    Ca m'a laissé un trés mauvais souvenir, et j'ai du abandonner aprés presque un an de travail pour aboutir à près de 15 Mo de code non fonctionnel !

    La refonte architecturale, peut être soit bénéfique, soit une chose à éviter, selon le cas :

    - si c'est au sein d'un même projet, on commence par une architecture, et au milieu du chemin, on décide de changer : ça implique que vous n'avez pas pris le temps de réfléchir avant de commencer à programmer, très mauvaise pratique

    - si c'est pour une mise à jour d'un ancien projet par exemple, là, ca ne peut qu'être bénéfique.

  3. #3
    Expert confirmé
    Avatar de Katyucha
    Femme Profil pro
    DevUxSecScrumOps Full Stack Bullshit
    Inscrit en
    mars 2004
    Messages
    3 287
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Irlande

    Informations professionnelles :
    Activité : DevUxSecScrumOps Full Stack Bullshit

    Informations forums :
    Inscription : mars 2004
    Messages : 3 287
    Points : 5 075
    Points
    5 075
    Par défaut
    La seule refonte architecturale que j'ai proposé, a été refusée...

    Un programme en VB/Access/shell Unix...etc, qui avait pris de grosses proportions, avec des ajouts un peu partout, qui passe plus dans la rubrique bricolage que programmation
    Impossible de le maintenir sans perdre énormément de temps, perte de données...etc

    Ma justification : On passe plus de temps à la maintenir, la reviser, relancer les divers scripts interfacés...etc qu'a refaire une application correcte, qui nous pose pas de problème, et qui en plus aura migré vers les besoins des utilisateurs, qui ont un peu glissé...

    Réponse du responsable :
    - On a acheté cher le programme, alors la direction informatique va refuser qu'on le jette et qu'on le refasse, surtout que ca touche d'autres directions...

    Je ne vois pas francement, ou informatiquement, ca péchait... ni pourquoi ma justification a été rejetée...surtout que je pense qu'elle tient la route...
    Peut etre, certaines personnes préfèrent ne rien faire, plutot que montrer une erreur précédente...
    Grave urgent !!!

  4. #4
    Modérateur
    Avatar de ggnore
    Profil pro
    Inscrit en
    juillet 2004
    Messages
    2 472
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France

    Informations forums :
    Inscription : juillet 2004
    Messages : 2 472
    Points : 4 029
    Points
    4 029
    Par défaut
    Le problème de la refonte architecturale, c'est le coût.
    Il faut réussir à justifier que la perte de temps immédiate engendrée par cette refonte fera vraiment gagner du temps et de l'argent par la suite.

    Le développement de nouvelles fonctionnalités sur un logiciel ancien est souvent rodée : on peut facilement estimer combien de temps va prendre telle ou telle fonctionnalité à rajouter.
    La refonte prend beaucoup de temps puisqu'il va sûrement falloir tout reprendre de zéro et tout recoder alors qu'on pourrait consacrer ce temps à rajouter de nouvelles fonctionnalités.

    Il faut des résultats rapides avec des coûts minimums. De plus une refonte implique que la personne à laquelle on accepte cette demande va forcément prendre du galon.
    C'est un peu comme donner un coup de pied dans une fourmilière.
    Je ne suis pas sûr d'avoir apporté grand chose dans ce message, mais ce dont je suis sûr c'est que réussir à justifier ce genre de chose n'est pas chose aisée.

    bon courage
    Toutes les vertus des hommes se perdent dans l’intérêt comme les fleuves se perdent dans la mer.
    N'oubliez pas de consulter les FAQ Linux et les cours et tutoriels Linux

  5. #5
    Expert éminent
    Avatar de neo.51
    Profil pro
    Inscrit en
    avril 2002
    Messages
    2 663
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations forums :
    Inscription : avril 2002
    Messages : 2 663
    Points : 6 599
    Points
    6 599
    Par défaut
    Citation Envoyé par ggnore
    Le problème de la refonte architecturale, c'est le coût.
    Tout à fait

    Mettons de coté les petits projets ou la refonte architecturale ne pose pas de problèmes particuliers car le cout n'est pas significatif.

    Pour un gros projet, la refonte architecturale à un coût significatif, que ce soit en heure de dev, en analyse, et en testing. Je pense que pour justifier un tel coût il faut profiter d'une évolution majeure de l'application. Parce que sinon, qui va payer le coût du changement d'architecture ? Ce n'est pas le genre d'investissement prioritaire dans une entreprise.

    Par contre à partir du moment où on a un besoin spécifique qui commence à devenir important en terme de temps de developpement, c'est là qu'il faut remettre en cause son architecture.
    Oui je dois répondre à tel besoin, mais quel besoin sont succeptible d'en découler ?
    Qu'est-ce qui actuellement va me faire perdre du temps en dev dans le développement de ces fonctionnalitées ? Que dois-je remettre en cause dans mon architecture pour implémenter plus facilement ces nouvelles fonctionnalitées ?


    Aprés y a remise en cause et remise en cause ... suivant les spécifications de départ et l'architecture de départ. On peu trés bien isoler certain composant et remettre en cause une partie de l'application. Le plus dur et de savoir où on doit s'arreter dans ce changement d'architecture... suivant la complexité des applications c'est plus ou moins évident.

    Pour en revenir au sujet qui est comment justifier une remise en cause de l'architecture, moi je présente souvent les choses comme ça :
    On a une applis qui marche mais qui n'est pas prévue/étudié pour ces nouvelles fonctionnalitées (sinon on voudrait pas revoir l'architecture).
    Soit :
    -On bricole un dev rapidement.
    -On prend un peu plus de temps pour revoir les composants qui ne sont pas adaptés à ces nouveaux développements.

    La solution 1 va plus vite, mais c'est là qu'il faut mettre en avant le fait que remettre en cause son architecture permettra de mieux faire évoluer l'application dans le futur. Et si on le fait pas maintenant, plus tard ça sera encore plus long (donc plus couteux) à faire. De plus un changement d'architecture permet de gagner en perf / temps de dev (pour les prochainnes versions à venir).

    C'est tout ça qu'il faut éssayer de quantifier

    Mais bon en principe une fois qu'on a galéré à la refonte de l'architecture de quelques projet, on réflechit plus à la conception
    Car le moins couteux et le plus rapide c'est de bien concevoir du premier coup

  6. #6
    Membre actif
    Profil pro
    Inscrit en
    mars 2003
    Messages
    292
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2003
    Messages : 292
    Points : 216
    Points
    216
    Par défaut
    une approche peut être un développement en parallele avec une équipe chargée de continuer avec l'ancienne architecture et une équipe qui va mettre en place petit à petit la nouvelle architecture, puis petit à petit porter les programmes qui s'appuie sur cette architecture. Les ressources de dév basculant au fur et à mesure sur la nouvelle architecture

    ça dépend évidemment du contexte, du nombre de personnes/logiciels qui utilisent cette architecture, si la société est de taille suffisament importante, etc., si les applis qui s'appuient sur cette architecture peuvent être intégrées petit à petit en évitant une approche big bang.

    et effectivement, suivant la taille du projet, la politique peut beaucoup jouer. Dès que les petits chefs se sentent dépassés/menacés, c'est peine perdu puisque c'est eux qui au final justifieront le coût auprès du grand manitou financier qui en général ne comprend pas tout à l'info

  7. #7
    Membre chevronné
    Avatar de Piotrek
    Homme Profil pro
    Développeur .NET
    Inscrit en
    mars 2004
    Messages
    869
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : mars 2004
    Messages : 869
    Points : 1 904
    Points
    1 904
    Par défaut
    Et il faut aussi considerer le risque qu'implique une refonte complete d'un systeme complexe...
    - Le systeme d'origine doit etre compris et tres bien compris
    - Les nouvelles possibilites doivent etre sondees et planifiees tres precisement, dire que "ca sera mieux" meme si on est tous d'accord, ca suffit pas (a quoi bon faire qq chose de nouveau pour que ca fasse pareil?)
    - Les delais de transition sont systematiquement sous-estimes
    - Les fonctionnalites redeveloppees peuvent ne pas etre a la hauteur de ce qu'il y avait precedement (cas classique du passage au web)
    - Le nouveau projet peut se planter pour Xmille raisons classiques

    Les seules possibilites que je vois c'est:
    - le besoin d'un avantage particulier impossible a realiser (ou trop tordu a realiser) dans le systeme d'origine (communication avec les clients ou fournisseurs, passage a l'ISO...)
    - La fusion/acquisition de la societe qui utilise le SI
    - Societes qui ont le besoin d'etre a la pointe et qui ont des cesterces a lancer par la fenetre

    Aussi puissant le marketing soit-il, il y a des choses qui ne peuvent pas passer

  8. #8
    Membre actif
    Profil pro
    Inscrit en
    mars 2003
    Messages
    292
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2003
    Messages : 292
    Points : 216
    Points
    216
    Par défaut
    Citation Envoyé par Piotrek
    Les fonctionnalites redeveloppees peuvent ne pas etre a la hauteur de ce qu'il y avait precedement
    Déjà entendu dans une société de gestion financière : volonté de se passer d'Excel. Vu la puissance d'Excel, le fait que dans la finance tout le monde connaît excel et sait faire ses propres macros en vba, la simplicité avec laquelle on peut plugger des composants et des dll de calculs mathématiques, ... même si effectivement excel pose parfois des problèmes de centralisation et de maintenance, on peut se demander si ce genre d'idées a été murement réfléchie.

    L'idée étant bien sûr que l'équipe informatique se charge de mettre à jour ce qui doit être mis à jour.
    1 Le coût va être très important
    2 l'organisation va être complètement différente
    3 il va falloir une très grande réactivité de l'informatique sans cela les utilisateurs qui veulent faire des choses rapides vont gueuler
    4 Comme tout le monde connaît excel, la moindre imperfection dans le nouveau soft, le moindre truc un peu moins pratique que l'ancien système, le moindre poil de couille de travers va être une occasion de se plaindre
    5 besoin de formation
    ...
    Peut-être même que les gens vont garder leur propre truc avec leurs propres développeurs privant ainsi la nouvelle architecture de plein de ressources mettant la nouvelle équipe dans une situation impossible.

    On pourrait continuer longtemps.

    C'est jouable mais c'est pas comme le rappelle Piotrek, c'est pas un truc que l'on fait comme ça ...

  9. #9
    mat.M
    Invité(e)
    Par défaut
    Citation Envoyé par Modjo

    Mais quand un jour, j'ai eu l'imbécile idée de developper un moteur 3D (Delphi, openGL), J'en ai vu des vertes et des pas mûres !
    A chaque fois que je voulais ajouter un effet ou une fonctionnalité, j'avais à réecrir d'énormes portions de code, pour que la chose marche.


    Cela tient plutôt de la méthodologie et analyse d'un projet.
    La POO et méchanismes comme l'héritage peuvent résoudre ce problème.
    On a une classe de base on veut rajouter des fonctionnalités alors on crée un e nouvelle entité hérité de la classe de base qui reçoit attributs et méthodes.

    Citation Envoyé par Katyucha
    La seule refonte architecturale que j'ai proposé, a été refusée...
    Piotrek et autres ont tout dit
    Si la DSI a refusé cela peut s'expliquer par le fait que les moyens financiers manquaient pour refondre l'application et qu'une solution informatique qui donne satisfaction, même largement bricolée et faite de bric et broc , c'est risqué de la refaire

    Déjà entendu dans une société de gestion financière : volonté de se passer d'Excel. Vu la puissance d'Excel, le fait que dans la finance tout le monde connaît excel et sait faire ses propres macros en vba, la simplicité avec laquelle on peut plugger des composants et des dll de calculs mathématiques, ... même si effectivement excel pose parfois des problèmes de centralisation et de maintenance, on peut se demander si ce genre d'idées a été murement réfléchie.
    Et dire qu'il ya un débat Open Office versus Ms Office
    C'est pas pour troller

  10. #10
    Rédacteur

    Avatar de Matthieu Brucher
    Profil pro
    Développeur HPC
    Inscrit en
    juillet 2005
    Messages
    9 810
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur HPC
    Secteur : Industrie

    Informations forums :
    Inscription : juillet 2005
    Messages : 9 810
    Points : 20 967
    Points
    20 967
    Par défaut
    On essaie aussi chez nous de demander une refonte de l'outil qui a été développé dans la maison depuis plus de 10 ans, programmé en C au départ sous Windows, puis sur des HPs, puis maintenant sur des Intel sous Linux. Un doctorant en avait tellement marre qu'il a développé depuis 0 une librairie graphique - http://imlib3D.sourceforge.net/ - et ce truc est vraiment génial. Sauf qu'étant donné qu'elle n'est pas vraiment compatible avec l'ancienne plate-forme, on a des espèces de ponts entre les 2 et ctte semaine, je me suis rendu compte que l'appel à certaines fonctions de l'outil de base faisait planter la sauvegarde des images avec ImLib3D !
    Tout ça pour dire que le plus gros problème en général, c'est le financement, mais aussi parfois la volonté d'imposer un mode de fonctionnement qui n'est pas optimal - par ex lier la librairie graphique à l'interface graphique -

  11. #11
    Membre confirmé

    Homme Profil pro
    Indépendant
    Inscrit en
    juin 2002
    Messages
    540
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Indépendant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juin 2002
    Messages : 540
    Points : 607
    Points
    607
    Par défaut
    En définitive et je suis heureux, la refonte a été acceptée et est en phase finale de développement (une centaine de jours/homme). A savoir que le contexte général de l'entreprise va dans ce sens.

    Le but était de proposer un framework de calcul générique accessible depuis des logiciels et composants tiers en lieu et place d'un simple composant interne (Justification 1). En cela, la refonte ouvre de nouveaux horizons pour les clients que je n'aurais jamais envisagé (Justification 2) et devient un élément de référence pour les futurs développement (Justification 3). Comme quoi, l'informatique a parfois de bons côtés; en bidouillant légèrement les estimations en terme de coût, la refonte n'aura pas coûter plus de jours/hommes que les améliorations requises à l'origine pour cette release (Justification 4) . C'est à dire qu'au lieu de modifier le code pour étendre les fonctionalités, il suffit de développer un plugin ou un client.

    Côté maintenance, un expert technique pourra s'approprier l'infrastructure générique lorsque des experts fonctionnels pourront maintenir leurs clients. A l'origine, les personnes en charge de maintenir ce code devaient avoir autant de compétences techniques que fonctionnelles.

    Ludo
    Fondateur Alien6 : Prescriptive Analytics & Machine Learning Software

Discussions similaires

  1. Réponses: 6
    Dernier message: 02/08/2012, 18h33
  2. comment remplacer une partie de texte dans un champs
    Par patlapi dans le forum Paradox
    Réponses: 4
    Dernier message: 20/11/2003, 15h38
  3. comment integer une animation swf dans une page
    Par naili dans le forum Intégration
    Réponses: 7
    Dernier message: 18/09/2002, 19h54
  4. Comment récupérer une adresse MAC ?
    Par psau dans le forum Développement
    Réponses: 7
    Dernier message: 19/07/2002, 18h26
  5. comment réduire une image jpeg (taille x*y)
    Par don-diego dans le forum C
    Réponses: 4
    Dernier message: 14/07/2002, 21h06

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo