Methodologie

Unsere Methodik basiert auf agilen Tools und Dynamics 365 Sure Step, um den Produktlebenszyklus zu verwalten, Risiken zu reduzieren und die Effizienz in allen D365 (AX) Projekten zu verbessern

Wie arbeiten wir?

Die Qualität des Codes ist von grundlegender Bedeutung

Seien Sie gut vorbereitet, bevor Sie in die Programmierphase eintreten. Änderungen während der Entwicklung können von Vorteil sein, verlängern jedoch häufig den Prozess und können zu Problemen beim Projektabschluss führen. Sie sollten zur Designphase zurückkehren, bevor Sie die Programmierung ändern. Ein guter Projektmanager ist wichtig für die Aufrechterhaltung dieses Vorgehens.

Wie arbeiten wir?

Der Reverse-Effort-Ansatz

ANEGIS arbeitet nach einem einfachen Prinzip: Gutes Design ist der Schlüssel zum Erfolg. Dementsprechend stützen wir unsere Methodik auf den “Reverse-Effort”-Ansatz, den wir bei der Arbeit an Projekten mit 50 bis 27.000 Benutzern übernommen haben.

Die Korrelation zwischen Aufwand und Kosten wird nach der Entwicklungsphase relevant. Die Erfahrung hat gezeigt, dass mehr Zeit und Aufwand bei der Projektvorbereitung die Gesamtentwicklungskosten senken und das System plangemäß funktioniert.

Der reverse-effort-ansatz

Design-Zyklus

I

Anforderungen

  • Durchgeführt von: ANEGIS oder lokalen Ressourcen des Kunden
  • Input: Kundenideen und -anforderungen, GAP
  • Output: Dokumentation der funktionalen Anforderungen
II

Funktionales Design

  • Durchgeführt von: ANEGIS
  • Input: Dokumentation der funktionalen Anforderungen
  • Output: Dokumentation des funktionalen Designs
III

Technisches Design

  • Durchgeführt von: ANEGIS
  • Input: Dokumentation der funktionalen Anforderungen
  • Output: Dokumentation des technischen Designs
IV

Prototyp

  • Durchgeführt von: ANEGIS
  • Input: Dokumentation des technischen Designs
  • Output: vom Kunden akzeptierter Prototyp

Prozess der Programmentwicklung

1

Persönliches Treffen zur Design-Übergabe

Ein ANEGIS-Funktionsberater übergibt das Design an das Team für die technische Architektur.

2

Bewertung des Designs

Der technische Architekt prüft, ob der Entwurf alle erforderlichen Informationen enthält, einschließlich aller notwendigen Details, um mit der Entwicklung zu beginnen. Zudem überprüft er das Design im Hinblick auf Fehler und technische Prozeduren.

3

Design-Optimierung

Dies ist wahrscheinlich die entscheidendste Phase der Projektentwicklung. Der Kunde kann oft viel Geld sparen, indem er eine alternative, technisch einfachere Lösung vorschlägt, die dennoch die erforderlichen Schlüsselfunktionalitäten garantiert. Oft wird übersehen, dass sich in vielen Fällen grundlegende Optimierungen kaum von Standard-UI-Mustern oder der erneuten Nutzung von Standardanwendungen unterscheiden. Diese Fragen sollten sorgfältig geprüft werden, bevor man fortfährt.

4

Erstellung der technischen Spezifikation

Der Schlüssel zum Erstellen einer technischen Spezifikation besteht darin, sicherzustellen, dass der technische Architekt und die Programmierer übereinstimmen. Es ist wichtig, ein klares Design bereitzustellen und gleichzeitig zu gewährleisteten, dass der Entwickler angemessen informiert wird. Ein gut durchdachtes technisches Design verringert die Wahrscheinlichkeit kostspieliger Änderungen während der Software-Entwicklungsphase deutlich.

5

Treffen zur Freigabe des technischen Entwurfs

Die Lösungsarchitekten berichten über die funktionalen und technischen Spezifikationen. Es ist wichtig, Fragen zu stellen und das gegenseitige Verständnis von Berater und Entwickler sicherzustellen. Dieser Schritt vermeidet Missverständnisse und verhindert, dass der Entwickler etwas anderes erstellt als das, was von den Funktionsberatern entworfen wurde.

6

Erstellung des Prototyps

Durch das Erstellen von Prototypen kann der Benutzer sehen, was Berater entwerfen, bevor das Projekt in die Kernentwicklungsphase eintritt. Es ist eine Gelegenheit, letzte Änderungen vorzunehmen. Das Prototyping reduziert den Umfang der Änderungen, da hier das Design selbst geändert wird und nicht der Code.

7

Programmierung

Das Entwicklungsteam schreibt den Code gemäß der erstellten Spezifikation.

8

Qualitätskontrolle

Technische Architekten überprüfen den Code. Der von ANEGIS erstellte Code entspricht den höchsten Standards. Um sicherzustellen, dass diese Standards immer eingehalten werden, verwenden wir Microsoft Lifecycle Services Customisation Analysis.

ALM/TFS

ANEGIS verwendet Visual Studio Application Lifecycle Management (ALM), um den Produktlebenszyklus zu verwalten, wodurch das Risiko verringert und die Effizienz gesteigert wird.

ANEGIS verwendet Visual Studio Application Lifecycle Management (ALM), um den Produktlebenszyklus zu verwalten, wodurch das Risiko verringert und die Effizienz gesteigert wird.Mit dem Visual Studio Team Foundation Server (TFS) können wir bewährte Methoden für das  Management des Produktlebenszyklus anwenden: Quellcodeverwaltung in Teams, Programmierung, Kompilieren und Testen von Anwendungen, Projektplanung, Nachverfolgung von Arbeiten und Berichterstattung über den Arbeitsfortschritt. TFS bietet Versionskontrolle, Build-System, CMMI, Scrum, agile Planungstools und Metriken für die Verwaltung von Software-Entwicklungsprojekten. ANEGIS ist eines der wenigen Unternehmen, das Microsoft Dynamics AX implementiert, das TFS verwendet und über funktionierende Build-Skripte verfügt.

Code Management

Unabhängig davon, ob das Softwareprojekt groß oder klein ist, verwendet ANEGIS die Versionskontrolle so früh wie möglich im Lebenszyklus eines Projekts. Bei kleinen Projekten wird sie verwendet, um die jeweilige Produktivität zu verbessern und schwierige Probleme zu lösen. Bei der Arbeit in einem Team oder bei komplexen Projekten verwendet ANEGIS ein gemeinsames Dateisystem mit Versionskontrolle, um die Zusammenarbeit und Transparenz zu verbessern.

Team Foundation Version Control (TFVC) ist ein zentrales System zur Versionskontrolle. Normalerweise haben Teammitglieder nur eine Version jeder Datei auf ihrem Gerät. Historische Daten werden nur auf dem Server gespeichert. Darüber hinaus basieren Verzweigungen auf Pfaden und werden auf dem Server erstellt. ANEGIS arbeitet in einer verteilten Umgebung. Dies bedeutet, dass jeder Programmierer eine persönliche virtuelle Maschine mit der installierten Microsoft Dynamics AX 2012 Server-Umgebung besitzt. Die virtuellen Maschinen werden vom Hyper-V Manager verwaltet.

Die Anzahl der virtuellen Maschinen auf dem PC jedes Entwicklers ist mit der Anzahl der betreuten Kunden verbunden, sollte jedoch drei oder vier gleichzeitig nicht überschreiten. ANEGIS verwendet eines der beiden von TFVC bereitgestellten Modelle: Auschecken / Einchecken in Serverarbeitsbereichen. Bevor Änderungen vorgenommen werden, checken die Teammitglieder die Dateien öffentlich aus. Bei den meisten Vorgängen müssen die Entwickler  mit dem Server verbunden sein.

Build-umgebung

Mit Team Foundation Build erstellt und verwaltet ANEGIS Build-Prozesse, die Anwendungen automatisch kompilieren und testen.

Zusätzlich zur Microsoft Dynamics-Modelldatei ermöglicht dieser Prozess die Erstellung einer Protokolldatei, die die gesamte Beschreibung des Erstellungsprozesses und ein Testergebnis enthält. ANEGIS verwendet das Build-System, um eine Strategie der kontinuierlichen Integration zu unterstützen und noch strengere Qualitätsprüfungen durchzuführen. Dies verhindert, dass ein Code mit schlechter Qualität den Build „bricht“.

Build-umgebung

Arbeitsmanagement

Das zentrale Element eines jeden Implementierungsprojekts in TFS ist ein Artefakt namens „Teamprojekt“. Es enthält eine gut organisierte hierarchische Struktur aller abhängigen Arbeitselemente, in der alle zur Projektrealisierung erforderlichen Informationen beschrieben sind.

Elemente wie: Funktionen, Änderungsanforderungen und Fehler bedeuten einen gewissen Arbeitsaufwand für die Systemimplementierung. Nach Abschluss des Überprüfungsprozesses werden Anpassungen vorgenommen und in die finale Entwicklung integriert. Testfälle umfassen manuelle Tests jeder Anforderung.

Arbeitsmanagement

Test-Management

ANEGIS verwendet das Programm Microsoft Test Manager, das im ALM-Tool (Application Lifecycle Management) enthalten ist, um Testpläne zu definieren und zu verwalten. Diese Testpläne werden auf dem Team Foundation Server (TFS) gespeichert und sind eng in dessen Build integriert.

Während des Testprozesses können Fehler zur weiteren Analyse gespeichert werden. Wenn der Fehler nachgewiesen ist, wird eine neue Anforderung erstellt und die entsprechende Programmieraufgabe ermittelt. Das Testmanagement umfasst die folgenden Schritte: Planen, Erstellen, Ausführen, Verfolgen von Ergebnissen und Reagieren.

Test-management
🡱