Cocomo – wikipedia

Cocomo ( Co nstructif Co St Pour du ) est un modèle de coût algorithmique utilisé dans le développement de logiciels pour l’estimation des coûts ou des efforts. Avec l’aide de fonctions mathématiques, une connexion entre certaines mesures logicielles et les coûts d’un projet est présentée.

Plusieurs paramètres spécifiques à l’entreprise se déroulent dans le calcul, qui détermine le nombre de mois personnels ou de personnes nécessaires pour mettre en œuvre un projet logiciel. La durée totale du projet peut également être estimée. Cocomo est basé sur une variété d’expérience qui dans la grande industrie, par ex. B. à Boeing, dans lequel le développement de logiciels a été fait. La procédure a été développée en 1981 par Barry W. Boehm, ingénieur logiciel chez Boeing.

Définitions et hypothèses [ Modifier | Modifier le texte source ]]

• Le principal facteur de coût (chauffeur de coût) pour le modèle est les internous de source prodiguée (DSI) du projet.
• La période de développement commence par le début de la conception du produit et se termine par l’achèvement de l’intégration du produit et du test d’acceptation. Les dépenses des autres phases sont déterminées séparément.
• Un mois de cocomo-mois-mois-Mois de l’anglais (SM) – consiste à 152 heures de travail (19 jours ouvrables avec 8 heures de travail chacun), un an de personnes de 12 hommes. Le mois de la personne prend des vacances et des congés de maladie.
• Le COMO assume une bonne gestion de la part des développeurs et des clients et présuppose que les temps improductifs sont maintenus aussi bas que possible.
• Cocomo suppose que la spécification des exigences ne se produit pas après la phase d’exigence. Un changement significatif dans la spécification entraîne également un changement dans l’estimation de l’effort.

Instructions de source livrées (DSI) [ Modifier | Modifier le texte source ]]

Comme base du calcul, le nombre de lignes de code à livrer doit être livré Kdsi (1000 (k) Instructions de source livrées [1 kdsi = 1000 instructions]). Comme Livré est uniquement mentionné, qui est également remis au client dans le cadre du produit. Cette définition exclut le code, qui a été écrit pour le logiciel de support ou pour les tests. L’estimation de cette taille dépend de nombreux facteurs (par exemple le langage de programmation) et n’est pas traité par Cocomo. Instructions de source correspondent aux instructions de l’ordinateur écrites et exécutables. En plus des commentaires, cette définition exclut également le code généré. Les instructions sont largement basées sur les cartes perforées alors communes. C’est ainsi que les instructions de Boehm ont défini dans son travail ^[d’abord] comme images de carte.
Les instructions source fournies ainsi que les lignes de code ou les points de fonction sont des mesures logicielles pour mesurer la taille du logiciel.

Déterminer la complexité [ Modifier | Modifier le texte source ]]

Ensuite, vous devez décider si vous travaillez sur un simple (mode organique “), moyen (” semi-détecté “) ou un projet complexe (” intégré “). Ces modes de projet sont des points centraux de Cocomo 81, qui représentent les différences dans le processus de travail dans les différents domaines de travail. Le choix du mode projet a un impact significatif sur le résultat du calcul – par lequel la formule du calcul reste la même et ne change que les coefficients.

Mode organique [ Modifier | Modifier le texte source ]]

Le mode organique correspond à des projets logiciels de petite à moyenne. La plupart des employés impliqués dans le projet ont déjà des expériences détaillées avec des projets similaires dans cette entreprise ainsi que les logiciels et le matériel utilisés. Cela garantit une faible contrôle de la communication, car les parties impliquées ont déjà une idée précise du produit à créer.
La documentation des spécifications et des interfaces n’est pas gérée strictement, ce qui signifie que les négociations à cet égard sont achevées plus rapidement et que l’effort supplémentaire qui en résulte (disonomies d’échelle) est maintenu bas. Les autres caractéristiques du mode organique sont les environnements de développement stables avec peu de nouvelles technologies, le besoin minimal de nouvelles innovations et peu de pression temporelle.

Mode semi-meur [ Modifier | Modifier le texte source ]]

Le mode semi-rage est destiné aux projets dont la taille et la complexité entre le mode organique et intégré doivent être réglées. Ce sont des projets de taille moyenne (entre 50 et 300 KDSI), dont les participants ont déjà un niveau d’expérience de taille moyenne dans le développement de ces systèmes ou dans lesquels l’équipe se compose de collègues expérimentés et inexpérimentés ou de l’équipe ne possède que dans une sous-zone. Les projets qui correspondent à ce mode sont plus complexes, nécessitent des routines d’interaction plus exigeantes et des interfaces flexibles.

Mode intégré [ Modifier | Modifier le texte source ]]

Le mode intégré est caractérisé par ses structures et directives serrées et inflexibles. Cela représente également la plus grande différence pour les deux autres, des modes guidés de manière assez lâche. Il vise en grande partie des projets pertinents en matière de sécurité (par exemple, les systèmes d’aide au vol, les systèmes pour les banques), qui sont donc très rigoureux en termes de changements de spécifications et d’interfaces. De plus, les projets en mode intégré sont généralement de nouveaux développements avec des projets prédécesseurs peu ou pas comparables. Pour cette raison, ces projets se caractérisent également par le fait qu’ils commencent par une analyse et une phase de conception relativement longues. Une fois ces phases terminées, autant de développeurs que possible sont chargés de mettre en œuvre et de tester le système. Ici, le test de projets intermédiaires (en montant de 8000 DSI) correspond au mode organique des grands projets (128 000 DSI).

Calculer l’effort [ Modifier | Modifier le texte source ]]

Le Effort PM dans Personnes est ensuite calculé comme un facteur m, multiplié par la puissance n du nombre métrique.

• simplement:
  ${displayStyle {matt {pm} = 2 {,} 4cdot {matt {kdsi}}; ^ {1 {,} 05}};$

  

• Medium-Heavy:
  ${DisplayStyle {matt {pm} = 3 {,} 0cdot {matt {kdsi}}; ^ {1 {,} 12}};$

  

• complexe:
  ${displayStyle {matt {pm} = 3 {,} 6cdot {matt {kdsi}}; ^ {1 {,} 20}}$

  

Exemple: Dans 100 KDSI, les mois de la personne sont vers 15 h pour un projet simple, vers 17 h pour un projet modéré et vers 21 h pour un projet complexe.

Durée du projet [ Modifier | Modifier le texte source ]]

Cependant, vous ne pouvez pas partager les mois de la personne d’un certain nombre de personnes pour terminer le produit plus rapidement. Les exemples servent souvent d’exemple – cela ne peut pas être abrégé à un mois en utilisant neuf femmes. Il y a certains processus qui doivent être séquentiels et plus les personnes se voient charger un projet, plus vous devez investir dans la communication.

Como parle de tdev, Il est temps de se développer (Temps de développement). Le Temps de développement TDEV dans Mois est ensuite calculé selon: selon le type de complexité:

• simplement:
  ${DisplayStyle {matt {tdev}} = 2 {,} 5cdot {matt {pm}}; ^ {0 {,} 38}$

  

• Medium-Heavy:
  ${DisplayStyle {matt {tdev}} = 2 {,} 5cdot {matt {pm}}; ^ {0 {,} 35}$

  

• complexe:
  ${DisplayStyle {matt {tdev}} = 2 {,} 5cdot {matt {pm}}; ^ {0 {,} 32}$

  

• Pour un projet simple Avec 100 KDSI, l’évaluation Cocomo fournit des PM = 302 mois et TDEV = 21,9 mois.
• Pour un Projet moyen Avec 100 KDSI, l’évaluation Cocomo fournit des PM = 521 mois et TDEV = 22,3 mois.
• Pour un projet complexe Avec 100 KDSI, l’évaluation Cocomo fournit des PM = 904 mois et TDEV = 22,1 mois.

La durée minimale du calcul Cocomo du TDEV est de huit mois.

Facteurs de moteur des coûts [ Modifier | Modifier le texte source ]]

La procédure de cocomo étendue (cocomo intermédiaire) prend en compte d’autres facteurs dits de conducteur de coûts qui réduisent ou augmentent la valeur de base calculée. Ceux-ci sont basés sur de nombreuses expériences qui ont été mesurées par les grandes entreprises. De tels facteurs comprennent:

• La fiabilité du système livré – une erreur est-elle seulement dérangeante ou met-elle en danger la vie humaine?
• Quelle est la taille de la base de données qui doit être créée?
• Dans quelle mesure les structures de traitement et de données d’entrée / sortie sont-elles complexes?
• À quelle vitesse le système doit-il fournir des résultats?
• Quelle est la quantité de stockage du système?
• À quelle fréquence vous attendez-vous à ce que le système soit adapté aux contrôles de trame externes? Ici, la gamme fluctue entre une fois par an et le mois.
• Facteurs d’équipe – Que pour l’expérience, les membres de l’équipe ont-ils dans l’analyse, dans le langage de programmation utilisé, avec des outils logiciels, avec ce matériel spécial?
• À quel point le calendrier est-il serré?

Le calcul suivant sert d’exemple de la quantité de ces facteurs qui influencent le résultat:

Le complexe, 128 KDSI, correspond à 1216 pm (calcul de base selon Cocomo).

Explication: Les facteurs individuels sont appliqués dans un “facteur global” et multipliés par les sous-jacents pour l’effort.
Formule: valeur adaptée = valeur de base * (fiabilité * complexité * exigence de mémoire * utilisation de l’outil * modèle)

Cependant, ces valeurs ne sont que l’expérience brute, chaque entreprise doit déterminer ses propres facteurs par la surveillance des coûts et l’analyse des projets créés jusqu’à présent.

Boehm Weist Darauf Hin, Dieses Modell Nicht Leichtfertig Anzuwenden: „Basic Cocomo est bon pour les estimations approximatives des coûts des logiciels, mais sa précision est nécessairement limitée en raison de son manque de facteurs pour tenir compte des différences dans les contraintes matérielles, la qualité et l’expérience du personnel, l’utilisation des outils et des techniques modernes et d’autres attributs de projet pour avoir une influence significative sur les coûts. ^[d’abord] (Le modèle COMO -BASIS est bien adapté à une estimation approximative de la taille des coûts du logiciel. La précision du modèle est nécessairement restreinte car elle manque de facteurs de différences dans le matériel utilisé, la qualité et l’expérience du personnel, l’utilisation d’outils et de technologies modernes et d’autres caractéristiques, qui sont connus pour avoir une influence significative sur les coûts.). Vous obtenez seulement un résultat relativement précis en tenant compte de plusieurs facteurs qui agissent sur le projet (voir les intermédiaires et le cocomo détaillé).

Il y a du cocomo [ Modifier | Modifier le texte source ]]

Ada Cocomo est un développement ultérieur de Cocomo 81-qui est très fortement façonné par le traitement par lots et le modèle de processus en cascade pour s’adapter à la mise en œuvre de TRW du modèle de processus ADA. Ce modèle comprend la gestion des risques, le squelette d’architecture, la mise en œuvre incrémentielle et les tests et les mesures logicielles uniformes. L’objectif principal du modèle est de réduire la tête souverain de communication, en évitant la révision tardive en raison des exigences instables. Les modifications de Cocomo 81 peuvent être divisées en trois catégories:

1. Améliorations générales de Cocomo: la plupart d’entre elles comprennent des ajustements aux facteurs de coût existants et supplémentaires. De nouveaux facteurs sont par exemple B. Sécurité et développement pour la réutilisabilité des logiciels.
2. Effets spécifiques à l’ADA: nouvelles règles pour compter les instructions (DSI) pour le langage de programmation ADA. Facteurs de coûts supplémentaires concernant l’expérience du langage de programmation.
3. Effets dus au modèle de processus ADA: ces effets ont un effet dans les exposants des équations de régression et sont dérivés des propriétés du modèle de processus ADA. Quatre facteurs de mise à l’échelle ont été introduits pour cela (expérience avec le modèle de processus ADA, minutie de conception au PDR (examen préliminaire de la conception), risques éliminés au PDR, volatilité des exigences). De plus, une méthode a été fournie pour apprécier l’effort de projets incrémentiels.

Le reste de Cocomo 81 est resté inchangé – la forme générale avec les différents modes, etc.

COCOMO 2 [ Modifier | Modifier le texte source ]]

Como II a également été développé, comme ses deux prédécesseurs, par Barry W. Boehm et publié pour la première fois en 1997. Cependant, la version officiellement connue est dans un livre en 2000 ^[2] Publié. Cocomo II représente les changements dans le développement de logiciels «modernes», avec des ajustements aux nouveaux modèles de processus de développement de logiciels et aux nouvelles méthodes de développement (par exemple, la programmation orientée objet). Comme dans Cocomo 81, trois types d’estimations différents sont à nouveau différenciés, mais la différence est qu’elle est de plus en plus liée au niveau de développement du projet. La subdivision en différents modes de projet a été distribuée ici.

Cet article ou section suivante n’est pas suffisamment équipé de supports (par exemple, avis individuels). Des informations sans preuves suffisantes pourraient bientôt être supprimées. Veuillez aider Wikipedia en recherchant les informations et Insérer de bonnes preuves.

Le modèle Cocomo n’est que très limité pour estimer l’effort d’un projet, car il est difficile d’apprécier les instructions de source sous-jacentes sur la base d’une spécification d’exigence. De plus, il n’est pas important que les logiciels dans les grandes langues modernes puissent souvent exprimer plus de lignes que les langues au moment où Cocomo a été développé. L’inexactitude de cette estimation rend cette méthode inutilisable pour l’estimation de l’effort. Les analyses de renouvellement des coefficients semblent montrer différentes valeurs ^[3] .

• Biographie – Barry W. Boehm
• 2 Center for Systems and Software Engineering, USC Viterbi School of Engineering, Archiviert VOM Original suis 16 décembre 2019 ; Récupéré le 6 septembre 2020 (Anglais, collection de successeurs et logiciels Cocomo).
• Procédure: Méthode Cocomo. Dans: Base de données de connaissances en génie logiciel. Vsek, www.software-kompetenz.de, Fraunhofer Iese, archivé à partir de Original suis 1. juin 2016 ; Récupéré le 6 septembre 2020 .

1. ↑ ^{un b} Barry Boehm. Économie du génie logiciel . Englewood Cliffs, NJ: Prentice-Hall, 1981, ISBN 0-13-822122-7
2. ↑ Barry Boehm, et al. Estimation des coûts logiciels avec Cocomo II (avec CD-ROM). Englewood Cliffs, NJ: Prentice-Hall, 2000, ISBN 0-13-026692-2
3. ↑ COCOMO: ne vaut pas une attention sérieuse. La forme du code, 19. Mai 2016, Récupéré le 4 novembre 2016 . Modèle: cite web / temporaire