Saviez-vous que la maintenance représente 50 à 80 % du coût du produit global ? Eh bien, il le fait ! Et alors que la plupart des gestionnaires de projet sont assez bonnes au dimensionnement des nouvelles fonctions du produit, beaucoup sont terribles à estimer l'effort requis pour prendre en charge un produit une fois qu'il sera généralement disponible. Par conséquent, sont insuffisamment dotés de projets d'entretien, les entreprises ne peut pas répondre aux demandes des clients en temps opportun, et produits n'atteignent jamais payback.
Cet article présente une méthodologie pour la devinette et donc planifier pour la phase de maintenance des produits généralement disponibles. Mais d'abord, nous allons définir quelques termes importants pour la compréhension de cet article.
Entretien
Maintenance est définie comme étant l'effort associé à défaut de fixation dans un système logiciel après la disponibilité générale (GA). En d'autres termes, combien de mois de travail durera votre organisation afin de corriger les bugs découverts par vos clients dans le domaine ?
Entretien peut être subdivisée en trois sous-catégories.
Maintenance corrective consiste à corriger les bogues détectés dans le système une fois qu'il sera généralement disponible. Un exemple d'une activité de maintenance corrective est un développeur de fixer une méthode Java qui provoque une erreur de compilation.
Maintenance adaptative , il faut changer le système fonctionne dans un environnement différent comme une topologie de réseau différentes, plate-forme ou le système d'exploitation. Un exemple d'une activité de maintenance adaptative est un développeur de fixer une méthode Java qui fonctionne sur BEA WebLogic, mais pas sur IBM Websphere.
Maintenance perfective implique des changements qui permettent au logiciel répondre aux mêmes exigences, mais d'une manière plus acceptable. Par exemple, le concepteur peut changer code simplement pour rendre le système plus efficace et plus facile à entretenir.
Améliorations
Améliorations, aussi connu sous le nom des demandes de modification, sont définies comme étant l'effort associé à l'ajout de nouvelle fonctionnalité à un système de logiciel, ou modifier un système logiciel pour répondre aux nouvelles exigences non fonctionnelles.
Imaginez une application qui invite l'utilisateur à s'authentifier à l'aide d'un nom d'utilisateur et le mot de passe. Trucs assez standard, droite ? Peut-être, mais certains clients pouvez ajouter un troisième titre pour le mécanisme de mot de passe comme un domaine. D'autres pouvez le nom d'utilisateur pour se conformer à un modèle d'adresse de courriel. Enfin, d'autres pouvez l'application à mémoriser des informations d'identification de l'utilisateur au fil des séances, ainsi l'utilisateur authentifié automatiquement.
Prise en charge
Prise en charge est définie comme la somme des efforts de maintenance et améliorations effectuées après que le produit est GA En d'autres termes, la prise en charge inclut toutes les activités qui se passent une fois un produit est déclaré généralement disponible.
Méthodologie
Au début de ma carrière, j'ai réalisé que la simple règle de pouce pourrait être appliquée à l'estimation du coût de la prise en charge de certains projets. Par exemple, le coût annuel de prendre en charge un site Web statique après qu'il va vivre est plus ou moins équivalent au coût de le développer. En d'autres termes, si le développement d'un site Web statique des coûts de 10 000 $, vous pouvez vous attendre à dépenser 10 000 $ par année maintenant.
Il est très pratique de comprendre ces règles. Malheureusement, peu d'entre eux sont transférables. En d'autres termes, la même règle ne s'appliquerait pas à un site Web dynamique e-commerce activée réparti sur 3 niveaux.
Divers modèles ont été développés au fil des ans pour prévoir les coûts de maintenance basés sur la densité des défauts (courbe de Raleigh, analyse de Weibull), KLOC et KDSI et les efforts de développement. Malheureusement, ces modèles ne sont pas sans lacunes. Beaucoup d'entre eux sont très imprécis ou trop complexes à vous soucier de leur apprentissage. En fait, certains sont si complexes que vous devez acheter une application vaut des milliers de dollars et 100++ paramètres pour calculer l'effort nécessaire pour maintenir votre produit.
Après avoir étudié pendant une douzaine de modèles prévisionnels, il y a une seule méthodologie que je recommande fortement à n'importe quel débutant ou un chef de projet expérimenté.
Modèle de Boehm
Modèle de Boehm est largement reconnue dans l'industrie comme un modèle valable pour prédire les coûts de maintenance. Il est relativement simple à comprendre, et plus important encore, il vous permet d'affiner vos prévisions grâce aux multiplicateurs de coût qui seront expliquées plus loin dans cet article.
Formule de Boehm est le suivant :
AME = ACT X SDT, où
AME est l'effort d'entretien annuel mesuré en mois-personne
Le trafic annuel de changement, qui représente une fraction de la source du produit logiciel instructions faisant l'objet de changement au cours d'une année normale grâce à l'ajout ou la modification est
Traitement spécial et différencié est le temps de développement de logiciel en mois-personne
Dire un projet de logiciel requis 100 personnes/mois d'efforts de développement et on estime que 15 % du code sera changé dans une année normale. Estimation des effort de maintenance annuelle base (AME) est donc :
AME = 0,15 x 100 = 15 mois/personne
En d'autres termes, vous devez prévoir de dépenser 15 mois/homme d'effort par an pour maintenir ce projet de logiciel spécifique.
La base estimation de coût de maintenance annuel peut être affinée en juger de l'importance de chaque facteur qui influe sur le coût et en sélectionnant le coefficient de coût approprié. Le coût de l'entretien de base est ensuite multiplié par chaque coefficient de coût pour donner l'estimation de coût de maintenance révisé.
Dire dans l'ancien système, les facteurs ayant le plus d'effet sur les coûts de maintenance ont été produit complexité (CPLX), qui était très élevé, et la disponibilité du personnel de soutien avec application expérience (AEXP), qui a été très faible.
Si CPLX = 1.30 et AEXP = 1,29, puis :
AEM = 15 x 1.30 x 1.29 = 25,2 mois/personne
Améliorations de prévision
Le coût de maintenance révisé n'inclut pas l'impact des multiplicateurs coût mais ne pas inclure des améliorations de produit, également connu sous le nom des demandes de modification.
La mauvaise nouvelle est que les améliorations de prévision est extrêmement difficile parce qu'il faut que vous sachiez avance quelles capacités supplémentaires demanderont à vos futurs clients. La bonne nouvelle est que vous pouvez facturer vos clients pour toute amélioration que dont ils ont besoin. Par conséquent, une bonne organisation ne tient pas en compte les améliorations pour représenter un coût, mais plutôt une source de recettes supplémentaires.
Conclusion
Lors de la prévision des frais d'entretien d'un produit qui est généralement disponible, suivez ces conseils :
-Apprendre et utiliser cette version (simplifiée) de modèle de Boehm pour prévoir les coûts de maintenance.
-Suivre votre traitement spécial et différencié.
-Mesurer votre acte.
-Définir le coût des multiplicateurs pour affiner vos prévisions.
En outre, assurez-vous que vous avez une équipe de services professionnels pour exécuter les demandes de changement requis par vos clients, mais ne pas les traitez comme des coûts puisqu'ils sont en fait une source de revenus.
No comments:
Post a Comment