Loading ...
Sorry, an error occurred while loading the content.
 

eXtreme Traceability (was Re: Lifecycle tool for extreme programming)

Expand Messages
  • Brad Appleton
    ... The less you work in a waterfa;lish-way, and the more you work in an agile fashion with very short feedback loops, the less necessary it becomes to make
    Message 1 of 74 , Mar 23, 2006
      dsrkkk wrote:
      > Whatever process we use, we need to track requirements, user stories
      > to design and test cases. The traceability provides obviously many
      > benefits. Why don't we automate traceabiliy? How can humanly track
      > these complex relationships? If we do manually, we may miss something.

      The less you work in a waterfa;lish-way, and the more you work in an
      agile fashion with very short feedback loops, the less necessary it
      becomes to make additional efforts to track/trace requirements.

      If I first do lots of requirements, then lots of design, then lots of
      code, etc., I have to "put the pieces together". The task I performed to
      write requirements was different from the one that did the design which
      was different from the one that did code, tests, etc.

      If I work in very short cycles (particularly using test-driven
      development), then an individual development task looks something like:
      - write a single test
      - write the code to pass the test and no more
      - refactor the code
      - commit my changes (Note I might commit my changes before refactoring too).

      If, when I commit my changes to the repository, a associate my "commit"
      with the name or id of the story the test was for, then I have a single,
      fine-grained change-task that went thru the complete cycle of
      specification, implementation/design, verification all in a matter of
      minutes for a single "commit" and user-story.

      Working in such fine-grained full-lifecycled tasks automatically
      associates all the elements that were created & updated as part of the
      task, which in turn is associated with a user-story. Ta da!!!!
      Traceability comes along for the ride almost automatically.

      From "Extreme Locality", in the Feb 2004 "Agile Times", pp.37-40
      (http://www.agilealliance.com/resources/agiletimes/agile_times_4.pdf)

      . . . . . . . . . . . . . . . . . . . .

      In Agile methods, we often hear a lot about the importance of
      simplicity: simple design; do the simplest thing that could possibly
      work; simple tools; minimal documentation ... Much of the documentation
      and artifacts created in larger software development methods is for the
      sake of capturing historical knowledge: the rhyme and reasons behind why
      something is there, or is designed a certain way.

      The desire for such information is often used to justify the need for
      formal traceability and additional documentation for the sake of
      maintainability and comprehension. Some very powerful and sophisticated
      tools exist to do this sort of thing. And yet, there are basic
      fundamental principles and simple tactics to apply that can eliminate
      much of this burden.

      WHENCE FORMAL TRACEABILITY?
      The mandate for formal traceability originated from the days of
      Department of Defense (DoD) development with very large systems that
      included both hardware and software, and encompassed many geographically
      dispersed teams collaborating together on different pieces of the whole
      system. The systems were often mission critical in that a typical “bug”
      might very likely result in catastrophic loss of some kind (loss of
      life, limb, livelihood, national security, or obscenely large sums of
      money/funding).

      At a high level, the purpose of formal traceability was three-fold:

      1. Aid project management by improving change *Impact* *Analysis* (to
      help estimate effort/cost, and assess risk)

      2. Help ensure *Product* *Conformance* to requirements specs (i.e.
      ensure the design covers every requirement, the implementation realizes
      every design element and every requirement)

      3. Help ensure *Process* *Compliance* (only the authorized individuals
      worked on the things [requirements, tasks, etc.] they were supposed to do)

      On a typical Agile project, there is a single team of typically less
      than two-dozen. And that team is likely to be working with less than 10
      million lines of code (probably less than 1 million). In such
      situations, many of the aforementioned needs for formal traceability can
      be satisfactorily ensured without the additional rigor and overhead of
      full-fledged formal requirements tracing.

      Rigorous traceability isn’t always necessary for the typical Agile
      project, except for the conformance auditing, which some Agile methods
      accomplish via test-driven design (TDD). A “coach” would be responsible
      for process conformance via good practices and good “teaming,” but
      likely would not need to have any kind of formal audit (unless obligated
      to do so by contract or by market demand or industry standards).

      Agile methodologies turn the knob up to 10 on product conformance by
      being close to the customer, by working on micro-sized
      changes/increments to ensure that minimal artifacts are produced (and
      hence with minimal reconciliation) and that communication feedback loops
      are small and tight. Fewer artifacts, better communication, pebble-sized
      change-tasks with frequent iterations tame the tiger of complexity!

      . . . . . . . . . . . . . . . . . . . .

      For more then you ever wanted to know about the why&wherefore behind
      traceability, see "The Trouble with Tracing: Traceability Dissected" at
      (http://www.cmcrossroads.com/article/44526)
      --
      Brad Appleton <brad {AT} bradapp.net>
      Agile CM Environments (http://blog.bradapp.net/)
      & Software CM Patterns (www.scmpatterns.com)
      "And miles to go before I sleep" -- Robert Frost
    • Ilja Preuss
      ... Or put a test page into FitNesse, called TestDoesFooSoThatBar . Cheers, Ilja
      Message 74 of 74 , Mar 28, 2006
        >> Thanks Roone. It is helpful. However, how do we manage change with
        >> storeis on cards? (Sometimes , we need to track the reason for
        >> change).
        >
        > To manage change with cards ,tear up one card and write
        > another. If you need to track the reason, type it into
        > Notepad or Microsoft Word, or Excel ...

        Or put a test page into FitNesse, called "TestDoesFooSoThatBar".

        Cheers, Ilja
      Your message has been successfully submitted and would be delivered to recipients shortly.