Je lisais, Facts and Fallacies of Software Engineering, qui a une section de maintenance. Depuis, je suis développeur de maintenance depuis des années maintenant, j'ai présenté des faits très intéressants. En voici trois.
- Fait 41: La maintenance consomme généralement 40 à 80% (en moyenne, 60%) des coûts des logiciels. Par conséquent, c'est probablement la phase de cycle de vie la plus importante du logiciel.
- Fait 42: L'amélioration est responsable d'environ 60% des coûts de maintenance des logiciels. La correction d'erreur est d'environ 17%. Par conséquent, la maintenance logicielle consiste principalement à ajouter de nouvelles fonctionnalités aux anciens logiciels, et non à les réparer.
- Fait 45: Un meilleur développement de l'ingénierie logicielle entraîne plus de maintenance, pas moins.
Celui-ci était contre-intuitif, il s'avère qu'un bon logiciel a plus de maintenance, car il est facile à changer. Par conséquent, il reste en service plus longtemps, ce qui entraîne, oui, plus de changements.
Quel paradigme (tel que fonctionnel, orienté objet, procédural) a la meilleure maintenabilité, et existe-t-il des recherches à l'appui?
maintenance
maintainability
KaizenSoze
la source
la source
Réponses:
Je pense que vous constaterez que les paradigmes tels que fonctionnel, OO et procédural ne correspondent probablement pas à la maintenabilité du logiciel de manière significative.
Ce que vous pourriez trouver les corellations suivantes beaucoup plus clairement avec la maintenabilité du logiciel:
Niveau de collecte des exigences et d'ingénierie des exigences
Bonnes pratiques de développement: (couplage lâche, haute cohésion, tests unitaires, YAGNI ...)
Ingénieurs logiciels qualifiés et qualifiés (ils valent 10 fois plus qu'un crétin)
Équipe d'AQ technique qualifiée et organisée
Bonne gestion de projet dirigée par des chefs de projet compétents (Encore plus difficile à trouver que les développeurs de logiciels qualifiés à mon humble avis)
Bons propriétaires de produits ou gestionnaires d'applications, leadership solide, bonne direction à long terme, bons retours aux équipes de projet, vision globale.
la source
Vous semblez voir cela à partir du montant de la maintenance et non du pourcentage des coûts. Un bon logiciel qui a plus de fonctionnalités ajoutées est juste une plus grande quantité de logiciels. Si le pourcentage de maintenance est fixe (car il s'agissait d'un bon logiciel et nous supposons que les fonctionnalités supplémentaires ont été ajoutées en tant que bon logiciel), le montant augmentera. C'est juste un plus gros morceau de tarte avec le même nombre de tranches.
Selon ce que vous demandez, il importe que le "bon" logiciel soit écrit en: code fonctionnel, POO ou procédural. Est-ce que donner à quelqu'un une scie électrique guidée au laser permettra d'économiser du bois si la personne ne sait pas mesurer?
la source