Borland® StarTeam® 2006 - Borland Technical Publications
Borland® StarTeam® 2006 - Borland Technical Publications Borland® StarTeam® 2006 - Borland Technical Publications
Schritt 3: Die Person, die die Änderungsanforderung bearbeitet, ändert den Status in Wird verarbeitet. Nachdem diese Person die Änderungsanforderung bearbeitet hat, kann sie ihr einen der folgenden Statuswerte zuweisen: ♦ Repariert ♦ Dokumentiert ♦ Nicht reproduzierbar Schritt 4: In einem nächsten Schritt testet ein anderes Teammitglied (in der Regel ein Tester oder ein Mitarbeiter der Qualitätssicherung) den geänderten Code. So kann beispielsweise anhand eines Testfalls geprüft werden, ob das Problem tatsächlich behoben oder dokumentiert wurde bzw. nicht reproduzierbar ist. Diese Person weist der Änderungsanforderung anschließend einen der folgenden Statuswerte zu: ♦ Verifiziert - Wie vorgesehen ♦ Verifiziert - Nicht reproduzierbar ♦ Verifiziert - Dokumentiert ♦ Verifiziert - Repariert ♦ Verifiziert - Doppelt Schritt 5: Abschließend ändert ein weiteres Teammitglied den Status in Geschlossen. Diese Person kann abschließende Vorgänge ausführen, z. B. die Änderungsanforderung vor ihrem Abschluss erneut testen oder sie in einen Bericht aufnehmen, damit sie bei der nächsten Produktversion berücksichtigt wird. Bei den meisten der oben beschriebenen Schritte kann die Änderungsanforderung neu geöffnet und verarbeitet werden. Integrierter Workflow für Änderungsanforderungen StarTeam verfügt über einen integrierten Workflow für Änderungsanforderungen, der viele Werte für Änderungsanforderungen automatisch festlegt. Dieser integrierte Workflow ermittelt diese Einstellungen basierend auf der Einstellung im Feld Status für die Änderungsanforderung. Sie können dem Feld Status keine weiteren Werte zuweisen. Sie können sie aber gemäß den Präferenzen in Ihrem Unternehmen umbenennen. Sie können beispielsweise den Status Neuin den Status Neue Änderungsanforderungändern. Wenn Sie den Status einer Änderungsanforderung ändern, legt der integrierte Workflow automatisch die entsprechenden Eigenschaften fest. Wenn Sie den Status Neu, Offen oder Wird verarbeitet wählen, werden im Dropdown-Listenfeld Status sechs neue Statusoptionen angezeigt. Die folgenden sechs Optionen stehen zur Auswahl: ♦ Zurückgestellt ♦ Nicht reproduzierbar ♦ Wie vorgesehen ♦ Repariert ♦ Dokumentiert ♦ Doppelt 150
Lebenszyklus für Änderungsanforderungen Die obige Abbildung zeigt den Lebenszyklus für eine Änderungsanforderung mit dem anfänglichen Status Offen. Der Status wurde in Repariert geändert. Daraufhin fügte der integrierte Workflow automatisch das Statusfeld Verifiziert - Repariert hinzu. Abschließend wurde die Änderungsanforderung geschlossen, d. h. sie erhielt den Status Geschlossen (Repariert). Die Abbildung zeigt auch, dass Änderungsanforderungen während der Bearbeitung jederzeit neu geöffnet werden können. Dies lässt sich daran erkennen, dass von den drei Repariert-Statuswerten jeweils ein Pfeil zum Status Offen zeigt. Zusammenfassung der automatischen Workflows für Änderungsanforderungen In der folgenden Tabelle sind die in diesem Thema beschriebenen Schritte zur Bearbeitung von Änderungsanforderungen zusammengefasst. Dies umfasst auch die automatischen Workflow-Änderungen, die die Anwendung basierend auf derem Status an den Änderungsanforderungen vornimmt. Bearbeitung von Änderungsanforderungen Schritt Senden Zuweisen* Beschreibung Jeder Benutzer kann Änderungsanforderungen senden (in der Regel der Tester oder ein Mitarbeiter der Qualitätssicherung). Vorgehensweise: Klicken Sie auf das Register "Änderungsanforderung". Wählen Sie dann Neu im Menü "Änderungsanforderung" oder im Kontextmenü. Änderungsanforderungen haben die folgenden Standardeigenschaften (die Sie gegebenenfalls ändern können). Status: Neu Schweregrad: Niedrig Priorität: Keine Priorität Typ: Defekt Plattform: Alle Letzter getesteter Build: Aktueller Build-Label Eingegeben von: Derzeit bei der Anwendung angemeldete Person Einige andere Felder sind absichtlich leer. Manche Teamleiter lassen alle Änderungsanforderungen an den Stammordner senden und verteilen Sie dann per Drag-and-Drop in die entsprechenden untergeordneten Ordner. Vorgehensweise: Der Teamleiter ruft alle neuen Änderungsanforderungen ab und führt einen der folgenden Schritte aus: ■ Er öffnet die Änderungsanforderung und weist sie einem Entwickler, einem Co-Autor oder einem anderen Teammitglied zu. 151
- Seite 99 und 100: "Verzweigen bei Änderung" für den
- Seite 101 und 102: Varianzansicht Schreibgeschützte R
- Seite 103 und 104: Ansichtstyp Referenz im Gegensatz z
- Seite 105 und 106: StarDraw (Beispiel-Serverkonfigurat
- Seite 107 und 108: Übersicht über die Projektadminis
- Seite 109 und 110: Übersicht über Projekte In einem
- Seite 111 und 112: Vergleichen und Zusammenführen von
- Seite 113 und 114: Ordner Dieses Thema bietet eine Üb
- Seite 115 und 116: Arbeitsordner für den Stammordner
- Seite 117 und 118: ♦ Sie können beim Einchecken and
- Seite 119 und 120: Verwandte Verfahrensweisen Anforder
- Seite 121 und 122: Themen Themen sind Konversationen m
- Seite 123 und 124: Labels In der Versionskontrolle wir
- Seite 125 und 126: Ein Label kann an einzelne Ordner o
- Seite 127 und 128: Übersicht über Referenzen Ordner
- Seite 129 und 130: In der aktuellen Ansicht gemeinsam
- Seite 131 und 132: Big Product::Big Product::Big Produ
- Seite 133 und 134: ♦ Big Product::Big Product::Big P
- Seite 135 und 136: Durch Hinzufügen von Elementen zu
- Seite 137 und 138: Angenommen, Sie fügen eine Datei z
- Seite 139 und 140: ♦ ...............Big Product::Big
- Seite 141 und 142: Angenommen, alle Ansichten außer d
- Seite 143 und 144: Auswahlversion In der Spalte "Eleme
- Seite 145 und 146: Testen und Berichtserstellung Die T
- Seite 147 und 148: Verwandte Konzepte Änderungsanford
- Seite 149: Modell für die Verfolgung von Änd
- Seite 153 und 154: Er öffnet die Änderungsanforderun
- Seite 155 und 156: Berichte StarTeam bietet eine Vielz
- Seite 157 und 158: Diagramme Mit dem Cross-Platform Cl
- Seite 159 und 160: Felder StarTeamenthält sowohl allg
- Seite 161 und 162: Serverübergreifende Konfiguration/
- Seite 163 und 164: Serveradministrations-Tool Dieses T
- Seite 165 und 166: Anzeigefenster Wenn Sie über das M
- Seite 167 und 168: Cross-Platform-Client - Übersicht
- Seite 169 und 170: anzuzeigen, wählen Sie die Element
- Seite 171 und 172: ♦ Der Status von StarTeamMPX. Ein
- Seite 173 und 174: Diagrammlegende Die Diagrammlegende
- Seite 175 und 176: Der Layoutbereich des Formulars Der
- Seite 177 und 178: Ansichten vergleichen/zusammenführ
- Seite 179 und 180: ♦ Die Testperspektive enthält di
- Seite 181 und 182: Verwandte Konzepte Übersicht über
- Seite 183 und 184: Die Hauptversion von File Compare/M
- Seite 185 und 186: Ordner vergleichen/zusammenführen
- Seite 187 und 188: FCM-Menüs und -Symbolleiste Die ei
- Seite 189 und 190: Toolbar-Dienstprogramm Dieses Thema
- Seite 191 und 192: StarTeam Web Edition Dieser Abschni
- Seite 193 und 194: Komponentenregister Die Komponenten
- Seite 195 und 196: StarTeam Layout Designer-Benutzerob
- Seite 197 und 198: Borland Search Dieses Thema beschre
- Seite 199 und 200: Workflow Designer Dieses Thema besc
Lebenszyklus für Änderungsanforderungen<br />
Die obige Abbildung zeigt den Lebenszyklus für eine Änderungsanforderung mit dem anfänglichen Status Offen.<br />
Der Status wurde in Repariert geändert. Daraufhin fügte der integrierte Workflow automatisch das Statusfeld<br />
Verifiziert - Repariert hinzu. Abschließend wurde die Änderungsanforderung geschlossen, d. h. sie erhielt den Status<br />
Geschlossen (Repariert).<br />
Die Abbildung zeigt auch, dass Änderungsanforderungen während der Bearbeitung jederzeit neu geöffnet werden<br />
können. Dies lässt sich daran erkennen, dass von den drei Repariert-Statuswerten jeweils ein Pfeil zum Status<br />
Offen zeigt.<br />
Zusammenfassung der automatischen Workflows für Änderungsanforderungen<br />
In der folgenden Tabelle sind die in diesem Thema beschriebenen Schritte zur Bearbeitung von<br />
Änderungsanforderungen zusammengefasst. Dies umfasst auch die automatischen Workflow-Änderungen, die die<br />
Anwendung basierend auf derem Status an den Änderungsanforderungen vornimmt.<br />
Bearbeitung von Änderungsanforderungen<br />
Schritt<br />
Senden<br />
Zuweisen*<br />
Beschreibung<br />
Jeder Benutzer kann Änderungsanforderungen senden (in der Regel der Tester oder ein Mitarbeiter der<br />
Qualitätssicherung).<br />
Vorgehensweise: Klicken Sie auf das Register "Änderungsanforderung". Wählen Sie dann Neu im Menü<br />
"Änderungsanforderung" oder im Kontextmenü.<br />
Änderungsanforderungen haben die folgenden Standardeigenschaften (die Sie gegebenenfalls ändern<br />
können).<br />
Status: Neu<br />
Schweregrad: Niedrig<br />
Priorität: Keine Priorität<br />
Typ: Defekt<br />
Plattform: Alle<br />
Letzter getesteter Build: Aktueller Build-Label<br />
Eingegeben von: Derzeit bei der Anwendung angemeldete Person<br />
Einige andere Felder sind absichtlich leer. Manche Teamleiter lassen alle Änderungsanforderungen an den<br />
Stammordner senden und verteilen Sie dann per Drag-and-Drop in die entsprechenden untergeordneten<br />
Ordner.<br />
Vorgehensweise: Der Teamleiter ruft alle neuen Änderungsanforderungen ab und führt einen der folgenden<br />
Schritte aus:<br />
■ Er öffnet die Änderungsanforderung und weist sie einem Entwickler, einem Co-Autor oder einem anderen<br />
Teammitglied zu.<br />
151