AppDNA

Variables

Cette rubrique documente lesOutil de calcul des effortsvariables. Vous pouvez les configurer pour répondre aux besoins de votre entreprise. Lorsque vous avez terminé, cliquez sur Enregistrer dans la barre d’outils en haut de l’écran pour enregistrer les modifications.

Variables générales

Ces variables personnalisent le rapport à un niveau élevé en définissant des informations spécifiques au projet.

Nom du client. Nom de la société à utiliser dans l’exportation du rapport.

Nombre de demandes dans le portefeuille complet. Nombre total d’applications que vous souhaitez migrer vers la nouvelle plate-forme. Cette valeur correspond par défaut au nombre d’applications que vous avez déjà importées dans AppDNA. Vous pouvez augmenter cette valeur pour refléter la taille de votre portefeuille d’applications réel. AppDNA extrapole ensuite l’effort de migration de l’ensemble du portefeuille à partir des résultats de l’échantillon.

Devise — Devise à utiliser dans l’état. Généralement, vous exprimez cela en utilisant le code de devise à trois caractères. Reportez-vous à la section http://www.xe.com/iso4217.php pour obtenir la liste des codes de devise internationaux.

Heures de travail par jour. Le nombre d’heures d’une journée de travail typique. Cela affecte tous les calculs relatifs au temps et peut aider à améliorer la précision des estimations de temps.

Nombre moyen de jours ouvrables dans un mois. Nombre moyen de jours au cours d’un mois de travail. Cela permet d’affiner davantage les estimations de temps.

Sans variables AppDNA

Ces variables aident à l’exactitude de l’estimation du projet lorsque l’ADNAPP n’est pas utilisé. Cette section fournit les valeurs par défaut et quelques alternatives ainsi que des explications sur le moment où elles peuvent être appropriées.

Temps de test de fumée. Temps en heures pour effectuer un essai initial d’installation et d’exécution, communément appelé « essai de fumée ». Il ne s’agit généralement pas d’un test approfondi.

  • Valeur par défaut : 8 - Temps moyen pour terminer la phase de test initiale sans dépendances avec des parties ou des processus externes.
  • Variante A : 24 - Lorsque les processus propres à l’entreprise doivent être pris en compte. Par exemple, lorsque l’essai de fumée comprend une partie du processus de certification de la demande et qu’il y a donc des crédits de temps pour l’expertise du propriétaire de la demande pour l’installation, la documentation et les essais initiaux.
  • Alternative B : 4 - Processus de test de fumée léger avec installation automatisée et script d’exécution pour tester les fonctionnalités à un niveau très élevé seulement.

Lesapplications qui sont censées avoir des problèmes. Nombre de demandes qui devraient présenter des problèmes en pourcentage du portefeuille. La valeur par défaut est de 30 %, qui est dérivée de diverses sources de marché, des analystes aux commentaires d’engagement technique. Cela varie d’une organisation à l’autre en fonction des processus propres à l’entreprise et de la préparation des applications.  

Applications qui devraient être des exceptions. Définit le pourcentage de demandes qui ne peuvent pas être corrigées ou lorsqu’une décision a été prise de ne pas y remédier. Cette variable peut changer radicalement en fonction de l’âge du portefeuille d’applications. Un portefeuille plus ancien a généralement un pourcentage plus élevé d’applications incompatibles qu’un nouveau portefeuille.

  • Valeur par défaut : 10 % - Selon les données empiriques de rationalisation des applications, les organisations « fin de vie » entre 10 % et 30 %, selon les initiatives de l’entreprise. L’incompatibilité des applications est souvent un facteur clé dans la décision de retraite. Si des variables telles que l’âge du portefeuille sont inconnues, la valeur par défaut doit être utilisée.
  • Alternative A : 35% - Les mandats propres à l’entreprise en matière de gestion du cycle de vie des applications peuvent stipuler une initiative de retrait des applications agressive liée aux migrations et aux actualisations des postes de travail.
  • Alternative B : 5% - Les mandats propres à l’entreprise peuvent également être orientés vers la migration de toutes les applications, quel que soit le mélange de plates-formes nécessaire pour les prendre en charge.

Temps pour identifier la cause d’une défaillance et la résoudre - Il s’ agit d’une estimation par application du temps en heures qu’il faut généralement pour identifier une défaillance et le corriger lorsque AppDNA n’est pas utilisé.

  • Valeur par défaut : 24 - Temps moyen associé à un processus manuel typique autour du test et de la correction des applications sans dépendances externes. Point unique de test et de correction.
  • Alternative : 60 - Temps moyen de prise en compte des processus spécifiques à l’entreprise - tels que l’expertise du propriétaire de l’application pour l’installation, les tests approfondis application-application à application, les tests d’image application-système d’exploitation de la ligne de base aux images or, avec toutes les permutations dans entre.

Avec les variables AppDNA

AppDNA utilise ces variables pour estimer le temps et les coûts de gestion du portefeuille lorsque AppDNA est utilisé.

Applications qui ont un package d’installation MSI. Saisissez cette valeur sous forme de pourcentage de l’ensemble du portefeuille. Vous importez des applications Windows dans AppDNA à l’aide de leurs packages d’installation. Il peut s’agir de packages d’installation MSI, de fichiers App-V .sft ou .appv, ou de tout autre type de fichiers d’installation. Les MSI et les fichiers .sft et .appv sont plus simples à importer que les autres types de packages d’installation. Le calculateur d’effort prend en compte le chiffre saisi ici lors de l’estimation du temps qu’AppDNA prendra pour traiter les demandes.

Coût de licence AppDNA. Cette variable peut éventuellement être utilisée pour fournir une ventilation des coûts plus précise dans les résultats du retour sur investissement.

Variables de dotation en personnel

Ces variables affectent les calculs avec et sans AppDNA.

Heure de mise en scène. Durée moyenne (en heures) d’installation d’une application dans l’environnement cible et de s’assurer qu’elle est en cours d’exécution. La valeur par défaut est 2 heures.

Taille de l’équipe d’assainissement. Nombre d’employés qui font partie de l’équipe d’assainissement du projet. Cela dépend de la taille du portefeuille d’applications. En règle générale, il y a un spécialiste de correction pour 250 applications. La valeur par défaut est 3.

Taille de l’équipe de test/mise en scène. Le nombre d’employés qui font partie de l’équipe d’essai et/ou de mise en scène du projet. Cela dépend de la taille du portefeuille d’applications. Généralement, il y a un testeur/stager pour 100 applications. La valeur par défaut est 5.

Coût de l’assainissement par jour. Coût moyen par jour du personnel d’assainissement.

Coût du testeur/stager par jour. Le coût moyen par jour des testeurs et des stagers.

Coût du chef de projet par jour. Coût moyen par jour des gestionnaires de projet.

Variables de test et de correction

La section des variables de test et de correction fournit une grille dans laquelle vous pouvez entrer le temps nécessaire pour corriger et tester des applications de différentes complexités. Entrez l’heure en heures.

Temps de correction. Entrez le nombre moyen d’heures qu’il faut pour corriger les applications des différentes complexités.

Table de complécité AppDNA

Les lignes représentent la complexité des applications. AppDNA mesure la complexité des applications en termes de nombre de fichiers et d’entrées de registre. Les seuils configurables définissent si une application est considérée comme simple, normale ou complexe. Vous pouvez configurer les seuils dans Paramètres de rapport. Pour plus d’informations, reportez-vous à la section Paramètres de reporting.

Les colonnes représentent la complexité de la correction. AppDNA identifie les problèmes dans les applications en exécutant des algorithmes heuristiques sophistiqués pendant le processus d’analyse. Chaque algorithme identifie un problème spécifique et propose une action de correction recommandée pour atténuer ce problème. L’effort associé à ces actions est classé comme facile, moyen ou dur. L’effort de correction global pour une application est basé sur l’effort le plus élevé associé aux algorithmes déclenchés par l’application. Vous pouvez éventuellement configurer les actions de correction dans l’écran Groupes d’algorithmes. Pour plus d’informations, reportez-vous à la section Configurer les algorithmes.

Temps de test. Entrez le nombre moyen d’heures qu’il faut pour tester des applications de différentes complexités.

Lorsque vous avez terminé de saisir les variables, cliquez sur Enregistrer dans la barre d’outils en haut de l’écran pour enregistrer les modifications.

Variables