Borland® StarTeam® 2006 - Borland Technical Publications

Beheben
Build
■ Er stellt die Änderungsanforderung für die spätere Bearbeitung zurück, z. B. für die nächste Version des
Produkts.
■ Er weist der Änderungsanforderung den Status Wie vorgesehen zu und gibt so an, dass sie nicht bearbeitet
werden muss. Wenn die Änderungsanforderung den Status Offen hat, werden keine automatischen Änderungen
vorgenommen. Wenn die Änderungsanforderung den Status Zurückgestellt oder Wie vorgesehen hat, wird
Adressiert in Build deaktiviert und die Zuständigkeit wird dem Benutzer zugewiesen, der die
Änderungsanforderung erstellt hat.
Vorgehensweise: Benutzer rufen die ihnen zugewiesenen Änderungsanforderungen mit dem Status Offen oder
Wird verarbeitet ab und führen pro Anforderung einen der folgenden Schritte aus:
■ Sie beheben das Problem im System und aktualisieren die Eigenschaften der jeweiligen
Änderungsanforderung. (Bearbeitete Änderungsanforderungen können die Statuswerte Nicht reproduzierbar,
Wie vorgesehen, Repariert, Dokumentiert oder Doppelt zugewiesen werden.)
■ Sie stellen die Änderungsanforderung für eine spätere Bearbeitung zurück, z. B. für die nächste Version des
Produkts.
Wenn der Änderungsanforderung der Status Repariert oder Dokumentiert zugewiesen ist, ändert sich die
Eigenschaft Adressiert in Build in Nächster Build. Hat die Anforderung einen anderen Lösungsstatus, ist die
Eigenschaft deaktiviert. Standardmäßig ist der Benutzer, der die Änderungsanforderung gesendet hat, dann für
das Testen der Lösung zuständig.
Wenn die Änderungsanforderung den Status Zurückgestellt hat, wird Adressiert in Build deaktiviert und die
Zuständigkeit wird in der Regel dem Benutzer zugewiesen, der die Änderungsanforderung erstellt hat.
Wer erstellt ein Projekt-Build? Der Build-Prozess in der Projektansicht kann formell oder informell sein. An einem
bestimmten Punkt wird allen aktuell in der Ansicht befindlichen Dateien usw. das Build-Label zugewiesen. In
der Regel wird es zunächst den compilierten Quellcode-Dateien usw. zugewiesen (und muss ggf. geändert
werden) und nicht den beim Build-Vorgang erzeugten ausführbaren Dateien.
Auswirkungen auf Änderungsanforderungen: Der Wert Nächster Build für die Eigenschaft Adressiert in Build
gelöster Änderungsanforderungen wird durch das Label des nächsten Builds ersetzt.
Hinweis: Wenn ein neues Build-Label auf einer alten Konfiguration und nicht auf der aktuellen Konfiguration
basiert, hat es keine Auswirkungen auf die Eigenschaft Adressiert in Build.
Wenn eine Änderungsanforderung an ihrer aktuellen Position nicht verzweigt ist, kann Nächster Builddurch ein
Build-Label einer anderen Ansicht ersetzt werden. Angenommen, Sie erstellen eine verzweigte untergeordnete
Ansicht oder geben einen Ordner aus einer Ansicht in einer anderen zur gemeinsamen Nutzung frei. Nächster
Buildist der Wert für die Eigenschaft Adressiert in Build einer Änderungsanforderung, die nicht verzweigt ist.
Wenn in der Quellansicht ein Build-Label erstellt wird, wird der Wert Nächster Builddurch den Namen des Build-
Labels unabhängig von dessen Position ersetzt.
Verifizieren* Die Person, die die Änderungsanforderung eingereicht hat, verifiziert den geänderten Code (in der Regel ein
Tester oder ein Mitarbeiter der Qualitätssicherung).
Schließen*
Vorgehensweise: Installieren Sie den Build, in dem die Lösung verifiziert werden soll, und überprüfen Sie, ob
die Änderungsanforderung erfolgreich behoben wurde. Führen Sie einen der folgenden Schritte aus:
■ Verifizieren Sie die Änderungsanforderung und kennzeichnen Sie sie als Verifiziert - Nicht reproduzierbar,
Verifiziert - Wie vorgesehen, Verifiziert - Repariert, Verifiziert - Dokumentiert oder Verifiziert - Doppelt.
■ Öffnen Sie die Änderungsanforderung neu und aktualisieren Sie die Einstellung für Letzter getesteter Build.
Wenn die Änderungsanforderung den Status Verifiziert hat, werden keine automatischen Änderungen
vorgenommen.
Wenn die Änderungsanforderung den Status Offen hat, ist das Feld Adressiert in Build leer. Wenn sich der
Status einer Änderungsanforderung von Behoben in Offen ändert, fällt sie in die Zuständigkeit des Benutzers,
der ihr den Status Repariert oder Dokumentiert zugewiesen hat.
In der Regel werden Änderungsanforderungen vom Teamleiter geschlossen.
Vorgehensweise: Der Teamleiter führt einen der folgenden Schritte aus:
Er überprüft und schließt die verifizierte Änderungsanforderung.
152