Übersicht über den ALM-Arbeitsprozess

Im ALM-Arbeitsprozess werden Anforderungen durch abgeschlossene Tasks und Aktivitäten aufgelöst.

Das ALM-Schema (Application Lifecycle Management) und die ALM-Pakete bieten einen vordefinierten Prozess, der es Ihnen ermöglicht, die Arbeit Ihres Teams an einem Produktrelease mit Rational ClearQuest zu überwachen. ALM verwendet definierte Rollen, Satztypen und Statusübergangsmodelle, die die Verwaltung des Softwareentwicklungsprozesses vereinfachen, von der Übergabe der Anforderungen über die Entwicklung, das Build-Management bis hin zum Testen.

Ein typischer ALM-Prozess läuft ab wie folgt:

  1. Ein Stakeholder übergibt eine Anforderung bezüglich eines Softwareprojekts. Der Stakeholder kann ein Entwickler, Tester, Autor, Trainer, Produktmanager, Mitarbeiter der Kundenunterstützung, ein anderes Mitglied des Projektteams oder ein Benutzer des Produkts sein. Eine Anforderung kann eine Änderung am Softwareprojekt einleiten. Eine Anforderung kann sich auf einen Fehler, einen Verbesserungsvorschlag oder eine Task beziehen.
  2. Das Triage-Team überprüft die Anforderung und entscheidet, ob sie akzeptiert oder zurückgewiesen werden soll. Wird die Anforderung akzeptiert, erstellt der Triage-Administrator eine oder mehrere Tasks (eine Task pro Projekt). Diese Tasks beschreiben abstrakt die Arbeitsvorgänge, die zur Erfüllung der Anforderung erforderlich sind.
  3. Der Entwicklungsleiter jedes Projekts überprüft die Task und bewertet die Arbeitsvorgänge, die für ihre Implementierung erforderlich sind. Dann aktiviert der Entwicklungsleiter die Task und erstellt zu ihrer Fertigstellung Aktivitäten wie die folgenden:
    • Entwicklungsaktivität (Dev)
    • Testaktivität (Test)
    • Aktivität zur Beurteilung der Dokumentation (Doc Assess)

    Der Entwicklungsleiter ordnet die Entwicklungsaktivität einem Entwickler zu.

  4. Der Testleiter überprüft die Task- und die Testaktivität und ordnet die Testaktivität dann einem Tester zu. Der Dokumentationsleiter überprüft die Testaktivität und die Aktivität zur Beurteilung der Dokumentation und ordnet letztere dann einem Autor zu.
  5. Der Entwickler arbeitet an der Entwicklungsaktivität und nimmt alle notwendigen Änderungen an Dateien vor. Dann versetzt der Entwickler die Entwicklungsaktivität in den Status "Completed".
  6. Der Releaseentwickler erstellt einen neuen Datensatz für eine Referenzkonfiguration, der die neu abgeschlossene Aktivität und die ihr zugeordnete Änderungsmenge auswählt.
  7. Der Releaseentwickler erstellt das Projekt mit der neu erstellten Referenzkonfiguration. Er erstellt einen Build-Datensatz, der die verwendete Referenzkonfiguration angibt und anzeigt, ob der Build erfolgreich war oder fehlgeschlagen ist.
  8. Der Tester installiert und testet den Build. Wenn der Build alle Tests erfolgreich durchlaufen hat, versetzt der Tester die Testaktivität in den Status "Completed".
  9. Der Autor beurteilt die Auswirkungen der Task auf die Dokumentation und nimmt alle notwendigen Änderungen vor. Der Autor versetzt dann die Aktivität zur Beurteilung des Dokumentationsbedarfs in den Status "Completed".
  10. Der Testleiter überprüft die Task, stellt fest, dass die notwendigen Aktivitäten abgeschlossen wurden, und versetzt die Task in den Status "Completed". Alternativ dazu kann der Testleiter zusätzliche Aktivitäten oder Kommentare zu vorhandenen Aktivitäten erstellen, falls weitere Arbeitsvorgänge erforderlich sind.
  11. Der Stakeholder, der die Anforderung übergeben hat, überprüft diese und sieht, dass eine oder mehrere zugeordnete Tasks abgeschlossen wurden. Der Stakeholder kann die Task öffnen und die Auflösung der Task überprüfen. Im Formular des Taskdatensatzes kann der Stakeholder die zugeordneten Aktivitäten öffnen und die Details zu den Entwicklungs-, Dokumentations- und Testvorgängen, die zum Abschluss der Task ausgeführt wurden, abrufen. Sind die Angaben zufriedenstellend, akzeptiert der Stakeholder die Anforderung, wodurch sie in den Status "Completed" versetzt wird. Ist das nicht der Fall, kann der Stakeholder die Anforderung zurückweisen und einen Kommentar zur Task abgeben, der weitere Arbeitsanweisungen für den Testleiter enthält. Der Testleiter wird per E-Mail benachrichtigt.

Feedback