Hallo,

wenn ihr Software (je nach Entwicklungsprozess) gemäß einer einer Spezifikation bzw. einer priorisierten Sammlung von Anforderungen (priorisierte User Stories im Backlog bei Scrum) implementiert, dokumentiert ihr dann auch direkt im Code welche Anforderung die definition einer Methode, Klasse, Interface motiviert hat?

Wenn ja, wie macht ihr dass? Hierzu hätte man ja (wie immer) mehrere Möglichkeiten.
Z.Bsp. könnte man die Anforderungen im Code über einen Kommentar oder über Source-Level Annotations (bei Java) oder Attributes (bei .Net) referenzieren.

Die letzte Möglichkeit hätte dann den Vorteil, dass man mit gegebenen Sprach- / Laufzeitmitteln (Reflection etc.) die Strukturen in gewissen Grenzen auf Umsetzung der einzelnen Anforderungen prüfen könnte.

Was haltet ihr davon?

Gruß Tom

Hi Tom

Wir nutzen für das Anforderungstracking unsere eigene Software sowie den TFS von Microsoft.
Beim TFS hat man die Möglichkeit beim Einchecken des Codes das entsprechende Workitem (Bug oder eben eine User Story) zu verlinken und hat so auch wie der umgekehrten Bezug von der User Story zum Ergebnis, da an der User Story alle Changesets (beinhaltet alle geänderten Dateien und wird beim Checkin erzeugt) hängen und man so auch noch verfolgen kann, welche Änderung durch welchen Code in die Anwendung gekommen ist

Hi Nico,

danke für deine Antwort Das (TFS) geht mir noch nicht weitgenug Das geht unter mit Eclipse / Mylyn und jedem Issue Tracker genauso. Ich würde gerne ermitteln, ob eine bestimmte Anforderung in Code realisiert wurde bzw. welche Codestellen davon berührt werden (das ist aufwendig -> hier wird beim annotieren einiges an Disziplin verlangt). Außerdem würde ich gerne bei Tests wissen welche "Features / Anforderungen" von einem Test abgedeckt werden. Das geht natürlich alles z.b. via grep über sourcen / APT (in Java).... btw. wie heißt denn das APT äquivalent unter .Net? Laut http://en.wikipedia.org/wiki/Attribu...ed_programming gibts da wohl nichts... na ja PostSharp (http://www.sharpcrafters.com/) bietet schon einiges in der Richtung (Extensible Compiler))

Na ja, ich schau mal noch ein wenig weiter.

Gruß Tom

Hi Tom

Zitat von Thomas Darimont

Ich würde gerne ermitteln, ob eine bestimmte Anforderung in Code realisiert wurde bzw. welche Codestellen davon berührt werden (das ist aufwendig -> hier wird beim annotieren einiges an Disziplin verlangt). Außerdem würde ich gerne bei Tests wissen welche "Features / Anforderungen" von einem Test abgedeckt werden.

Also aus meiner Sicht geht das schon
Über die Zuordnung der Workitems zum Changeset weißt du, welche Codezeilen für eine bestimmt Anforderung geändert wurden. Werden die Testfälle auch im TFS gepflegt (Test Lab), welche den Anforderungen zugeordnet werden können, kriegst du auch raus, welche Test durchgeführt werden sollten, wenn der entsprechende Code geändert wird

@APT
Da kann ich dir leider nix zu sagen. Ich seh es nur teilweise als etwas problematisch solche Infos im Code zu geben (wenn ich es richtig verstanden hab ), da der Overhead an Informationen doch zunimmt

Hi Tom
Ich weiss nicht ob dir das viel nützt, aber ich erzähle dir mal grob wie wir es in der letzten Firma gemacht haben:
Jede Aufgabe (User Story, Bug, etc) war mit einem Commit verknüpft und jeder Commit mit einer Aufgabe.
Die Verwaltung der Aufgaben lief im Brower und hatte direkten Zugriff auf svn (Ich weiss leider nicht mehr wie diese Verwaltung hiess). Wenn man nun wissen wollte was für eine Aufgabe geändert wurde konnte man aus der Aufgabe heraus direkt in den verlinkten commit springen und dann einen Dif zum davorliegenden commit machen und sah somit alle Änderungen die durch diese Aufgabe entstanden.
Da wir das fast nie brauchten war es auch nicht perfekt (z.b. mehrere commits für eine Aufgabe, mehrere Klicks bis man zum Dif kommt). Aber man könnte das ganze auch mit Tags verknüpfen und den Dif-Aufruf müsste man eigentlich auch direkt als Link in die Aufgabe platzieren können.

Grüsse
jeipack