Variablen

In diesem Thema werden dieAufwandsrechnerVariablen dokumentiert. Sie können diese so konfigurieren, dass sie den Anforderungen Ihres Unternehmens entsprechen. Wenn Sie fertig sind, klicken Sie auf der Symbolleiste oben auf dem Bildschirm auf Speichern, um die Änderungen zu speichern.

Allgemeine Variablen

Diese Variablen passen den Bericht auf hoher Ebene an, indem projektspezifische Informationen definiert werden.

Name des Kunden. Der Name des Unternehmens, das beim Auswertungsexport verwendet werden soll.

Anzahl der Anwendungen im gesamten Portfolio. Die Gesamtzahl der Anwendungen, die Sie auf die neue Plattform migrieren möchten. Dieser Wert ist standardmäßig die Anzahl der Anwendungen, die Sie bereits in AppDNA importiert haben. Sie können dies erhöhen, um die Größe Ihres tatsächlichen Anwendungsportfolios widerzuspiegeln. AppDNA extrapoliert dann den Aufwand, das gesamte Portfolio aus den Ergebnissen für die Probe zu migrieren.

Währung — Die Währung, die in der Auswertung verwendet werden soll. In der Regel geben Sie dies mit dem dreistelligen Währungscode aus. Eine Liste der internationalen Währungscodes finden Sie unter http://www.xe.com/iso4217.php.

Arbeitszeit pro Tag. Die Anzahl der Stunden in einem typischen Arbeitstag. Dies wirkt sich auf alle Zeitberechnungen aus und kann dazu beitragen, die Genauigkeit der Zeitschätzungen zu verbessern.

Durchschnittliche Arbeitstage in einem Monat. Die durchschnittliche Anzahl der Tage in einem Arbeitsmonat. Dies ermöglicht eine weitere Verfeinerung der Zeitschätzungen.

Ohne AppDNA-Variablen

Diese Variablen helfen bei der Genauigkeit der Projektschätzung, wenn AppDNA nicht verwendet wird. Dieser Abschnitt enthält die Standardwerte und einige Alternativen zusammen mit einer Erläuterung, wann sie geeignet sind.

Rauchtestzeit. Die Zeit in Stunden, um einen Erstinstallations- und Durchführungstest durchzuführen, der allgemein als “Rauchtest” bezeichnet wird. Dies ist normalerweise kein vertiefter Test.

  • Standardwert: 8 - Durchschnittliche Zeit zum Abschließen der ersten Testphase ohne Abhängigkeiten von externen Parteien oder Prozessen.
  • Alternative A: 24 - Wenn unternehmensspezifische Prozesse berücksichtigt werden sollen. Zum Beispiel, wenn der Rauchtest einen Teil des Zertifizierungsprozesses der Anwendung umfasst und so gibt es Zeitzuordnungen für die Expertise des Anwendungseigentümers für Installation, Dokumentation und Erstprüfung.
  • Alternative B: 4 - Leichtes Rauchtestverfahren mit automatischer Installation und einem Ausführungsskript, um die Funktionalität nur auf einem sehr hohen Niveau zu testen.

Anwendungen, bei denen erwartet wird, dass Probleme auftreten. Die Anzahl der Anwendungen, bei denen erwartet wird, dass Emissionen als Prozentsatz des Portfolios auftreten. Der Standardwert beträgt 30%, der aus einer Vielzahl von Marktquellen abgeleitet wird, von Analysten bis hin zu technischem Feedback. Dies variiert von Organisation zu Organisation basierend auf unternehmensspezifischen Prozessen und Anwendungsbereitschaft.  

Anwendungen, bei denen erwartet wird, dass es sich um Ausnahmenhandelt. Definiert den Prozentsatz der Anwendungen, die nicht korrigiert werden können oder wenn eine Entscheidung getroffen wurde, nicht zu beheben. Diese Variable kann sich aufgrund des Alters des Anwendungsportfolios dramatisch ändern. Ein älteres Portfolio weist in der Regel einen größeren Prozentsatz inkompatibler Anwendungen auf als ein neues Portfolio.

  • Standardwert: 10% - Basierend auf empirischen Anwendungsrationalisierungsdaten, Unternehmen “End-of-Life” irgendwo zwischen 10 und 30 %, abhängig von Unternehmensinitiativen. Die Inkompatibilität der Anwendung ist oft ein wichtiger Treiber bei der Pensionierungsentscheidung. Wenn Variablen wie das Portfolio-Alter unbekannt sind, sollte der Standardwert verwendet werden.
  • Alternative A: 35% — Unternehmensspezifische Mandate rund um das Application Lifecycle Management können eine aggressive Ausscheidungsinitiative für Anwendungen festlegen, die an Desktop-Migrationen und Aktualisierungen gebunden ist.
  • Alternative B: 5% — Unternehmensspezifische Mandate können auch dazu beitragen, dass alle Anwendungen migriert werden, unabhängig von den für ihre Unterstützung erforderlichen Mischungen von Plattformen.

Zeit, um die Ursache eines Fehlers zu identifizieren und zu beheben - Dies ist eine pro Anwendung Schätzung, wie lange es in Stunden dauert, um einen Fehler zu identifizieren und ihn zu beheben, wenn AppDNA nicht verwendet wird.

  • Standardwert: 24 - Durchschnittliche Zeit, die mit einem typischen manuellen Prozess im Zusammenhang mit Anwendungstests und -beseitigung ohne externe Abhängigkeiten verbunden ist. Single Point of Test und Sanierung.
  • Alternative: 60 - Durchschnittliche Zeit, in der zusätzliche unternehmensspezifische Prozesse berücksichtigt werden sollen - wie Expertise des Anwendungseigentümers für die Installation, ausführliche Anwendungsprüfung, Anwendung-zu-OS-Image-Tests von Baseline bis Gold Images, mit allen Permutationen in zwischen.

Mit AppDNA-Variablen

AppDNA verwendet diese Variablen, um Zeit und Kosten für die Handhabung des Portfolios zu schätzen, wenn AppDNA verwendet wird.

Anwendungen mit MSI-Installationspaket. Geben Sie diesen Wert als Prozentsatz des gesamten Portfolios ein. Sie importieren Windows-Anwendungen in AppDNA mit ihren Installationspaketen. Dies können MSI-Installationspakete, App-V .sft- oder .appv-Dateien oder jede andere Art von Installationsdateien sein. MSIs und .sft- und appv-Dateien sind einfacher zu importieren als andere Arten von Installationspaketen. Effort Calculator berücksichtigt die hier eingegebene Zahl bei der Schätzung der Zeit, die AppDNA benötigt, um die Anwendungen zu verarbeiten.

AppDNA Lizenzkosten. Diese Variable kann optional verwendet werden, um eine genauere Kostenaufschlüsselung in den ROI-Ergebnissen zu ermöglichen.

Personalvariablen

Diese Variablen beeinflussen die Berechnungen mit und ohne AppDNA.

Staging-Zeit. Die durchschnittliche Zeit (in Stunden), um eine Anwendung in der Zielumgebung zu installieren und sicherzustellen, dass sie ausgeführt wird. Der Standardwert beträgt 2 Stunden.

Größe des Behebungsteams. Die Anzahl der Mitarbeiter, die sich im Behebungsteam für das Projekt befinden. Dies hängt von der Größe des Anwendungsportfolios ab. In der Regel gibt es je 250 Anwendungen einen Behebungsspezialisten. Der Standardwert ist 3.

Größe des Test-/Staging-Teams. Die Anzahl der Mitarbeiter, die sich im Test- und/oder Stagingteam für das Projekt befinden. Dies hängt von der Größe des Anwendungsportfolios ab. Typischerweise gibt es je 100 Anwendungen einen Tester/Stager. Der Standardwert ist 5.

Korrekturkosten pro Tag. Die durchschnittlichen Kosten pro Tag des Sanierungspersonals.

Tester/Stager Kosten pro Tag. Die durchschnittlichen Kosten pro Tag von Testern und Stagern.

Projektmanager-Kosten pro Tag. Die durchschnittlichen Kosten pro Tag von Projektmanagern.

Test- und Behebungsvariablen

Der Abschnitt “Test- und Behebungsvariablen” enthält ein Raster, in dem Sie die Zeit eingeben können, die zum Beheben und Testen von Anwendungen unterschiedlicher Komplexität erforderlich ist. Geben Sie die Zeit in Stunden ein.

Behebungszeit. Geben Sie die durchschnittliche Anzahl von Stunden ein, die für die Behebung von Anwendungen mit den verschiedenen Komplexitäten benötigt werden.

AppDNA-Komplementartabelle

Die Zeilen stellen die Komplexität von Anwendungen dar. AppDNA misst die Komplexität der Anwendung in Bezug auf die Anzahl der Dateien und Registrierungseinträge. Konfigurierbare Schwellenwerte legen fest, ob eine Anwendung als einfach, normal oder komplex betrachtet wird. Sie können die Schwellenwerte in den Berichtseinstellungen konfigurieren. Weitere Informationen finden Sie unter Berichtseinstellungen.

Die Spalten stellen die Komplexität der Korrektur dar. AppDNA identifiziert Probleme in Anwendungen, indem während des Analyseprozesses ausgefeilte heuristische Algorithmen ausgeführt werden. Jeder Algorithmus identifiziert ein bestimmtes Problem und verfügt über eine empfohlene Behebungsaktion, um dieses Problem zu verringern. Der Aufwand, der mit diesen Aktionen verbunden ist, wird als einfach, mittel oder hart kategorisiert. Der Gesamtbehebungsaufwand für eine Anwendung basiert auf dem höchsten Aufwand, der mit den Algorithmen verbunden ist, die die Anwendung auslöst. Sie können die Behebungsaktionen optional im Bildschirm Algorithmusgruppen konfigurieren. Weitere Informationen finden Sie unter Konfigurieren von Algorithmen.

Testzeit. Geben Sie die durchschnittliche Anzahl von Stunden ein, die zum Testen von Anwendungen unterschiedlicher Komplexität benötigt werden.

Wenn Sie die Variablen eingegeben haben, klicken Sie auf der Symbolleiste oben im Bildschirm auf Speichern, um die Änderungen zu speichern.