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

Why Traceability? Can it be Agile?

Expand Messages
  • Brad Appleton
    I was reading a book review of Practical Software Engineering at www.therationaledge.com and it said something about the importance of traceability : [begin
    Message 1 of 51 , Mar 10, 2004
    • 0 Attachment
      I was reading a book review of "Practical Software Engineering"
      at www.therationaledge.com and it said something about the
      "importance of traceability":

      [begin excerpt]

      Emphasizes the importance of traceability
      -----------------------------------------
      Throughout the book, Manassis discusses the importance of
      requirements traceability. The last chapter, “Traceability at
      Work,” demonstrates how traceability helps to keep projects
      on track and on schedule. The greatest practical function
      of traceability, he claims, is that it facilitates impact
      analysis. It allows you to predict and identify what will
      change if you modify the system at any level.

      For example, with traceability you can:

      * Identify the source of inputs for each artifact.
      * Include traceability information as part of an artifact
      where appropriate (e.g., in many UML model diagrams).
      * Use techniques that help you link two artifacts to each other.
      For example, you can see how to link the .NET role-based
      security attributes in code with the UML use-case model,
      actor diagram, and sequence diagrams, through the role-based
      security matrix.
      * Whenever you make a code change, identify all artifacts you
      need to change, and understand how to make those changes.

      [end of excerpt]

      In the past, I've mention the three main uses/needs for traceability:
      1. Assist change impact analysis (and hence estimation accuracy)
      2. Ensure conformance to specs
      3. Mandated (by legal/contractual obligation or market industry)

      Most of the time it comes up on this list, people use or assume
      the 2nd item above and claim its not needed in XP/Agile when I
      can show that all my tests pass and all my tests are easily
      traceable to the corresponding story (I think part of this is
      also not calling a development task "done" until it passes
      the tests). I also think that is largely true!

      As I look at the impact-analysis use of traceability as described
      above, one of the first things that strikes me is that its very
      "up front" thinking instead of adaptive. It tries to predict what
      will/might happen instead of using feedback upon executable results
      to see what does happen.

      I think a more adaptive approach would say: create or simulate
      the change in an isolated environment, observe see what happens,
      then respond to it. If I could do such a "simulation" - would
      traceability for the purpose of impact analysis be obsolete?
      (do I really need to know which artifacts/entities are touched
      if I know what the effects are? Is it still useful for estimation?)

      What might be a TDD-way of doing such an executable impact
      analysis that didn't take significantly more time to do than to
      simply "mock up" all or part of the requested change? (or to
      help me find out all the areas of code that would be touched?)

      How could I answer the question "what physical [files/classes] and
      functional [stories] characteristics are impacted if I add/change
      this story or part of a story?" and how can I answer that in an
      agile fashion with small and tight rapid-feedback loops that gave
      me back an answer without adding too much additional time to my
      estimation activity? [I can see how a really nice MDD environment
      could be helpful here]

      The second question (which really should be the first question)
      is, do I really need to answer the "impact" question in the
      first place? How much does it help me and my customer to be
      able to do that? How much would it improve my estimates, my
      team's velocity, our ability to collaborate, and give rapid
      executable feedback to our customer if I could do this thing?
      [I don't have any ready answers for this - am interested in
      opinions from those who actually have or had had this ability
      in previous projects (agile or otherwise) and how much their
      agile project's would truly benefit from it (or not).

      Functionally speaking - why is impact an issue at all? I think
      its because it presumably reveals key insights as to the cost
      of making the change. But what if my code is maximally well
      factored AT ALL TIMES? What if my functional architecture
      (e.g., classes, interfaces, packages) my physical architecture
      (e.g., files, directories, headers) could:
      - maximize encapsulation and localization
      - easily correlate my abstractions (e.g., domain objects)
      with their corresponding stories/use-cases (as opposed
      to trying to trace at the finer-grained level of
      line-item requirements and routines/lines of code)
      and hence to their corresponding tests

      If I aggressively manage and minimize dependencies thru
      refactoring and encapsulation, and if I worry about tracing
      only at a more coarse-grained level of stories (features)
      to abstractions (classes/interfaces), might that not be
      enough? Might that be "barely sufficient" to meet most
      mandatory/obligatory requirements for formal traceability?

      And in the cases where it didn't, how might I take a
      simulation/TDD-based approach to impact analysis and
      effort estimation for a requested change?

      I gave a presentation on "Agile SCM" last week, and several
      in the audience asked be about "traceability", and how
      to meet mandated traceability in an "agile" fashion (especially
      now that things like Sarbanes-Oxley are prompting increasingly
      more shops to mandate - a phenomenon which several in the
      audience seemed to agree has already started and is growing).

      I suggested that agile projects address concerns of traceability
      by doing things like:
      - Having tests directly traceable to stories (sometimes even
      on the same card)
      - Minimizing the number of artifacts produce (fewer items means
      fewer items and fewer inter-relationships to track and manage)
      - Knowing which stories (features) each "commit" is for, and being
      able to associate them in the version-control tool if necessary
      in order to automate code-level traceability (e.g., a checkin comment)
      - Aggressively managing dependencies with (encapsulation/refactoring)
      - Using concepts of domain-driven design to ensure the easy correlation
      between stories and objects.
      - Managing traceability at the level of stories (feature or use-case)
      and objects instead of individual line-item requirements and
      lines of code (something which good encapsulation makes possible
      because low-coupling and high-cohesion increase the odds that
      few other objects will be impacted, but the few that are might
      impacted throughout)

      At the time I said that, I hadn't yet pondered the simulation/TDD-based
      approach for traceability hinted at above (nor of the applicability of
      Mock-Objects and even AOP to ease t he ability to do so comprehensively).
      I would be very interested in hearing if others have done it, or of
      how it might be done.

      --
      Brad Appleton <brad@...> www.bradapp.net
      Software CM Patterns (www.scmpatterns.com)
      Effective Teamwork, Practical Integration
      "And miles to go before I sleep." -- Robert Frost
    • Anthony Williams
      ... I passed on the question, and my interpretation was correct --- the technical assessment basically means someone knowledgeable about the system sits down
      Message 51 of 51 , Mar 29, 2004
      • 0 Attachment
        Anthony Williams <anthony_w.geo@...> writes:

        > "Jeff Grigg" <jeffgrigg@...> writes:
        >
        >> --- Anthony Williams <anthony_w.geo@y...> wrote:
        >>> This is not how they currently do it, though --- they use
        >>> their traceability matrix to identify which code modules
        >>> are affected by a change, and which requirements are
        >>> impacted by changes to those code modules.
        >>
        >> What do they do if the new requirement isn't an existing
        >> requirement? Where do they find it in the tracability matrix?
        >
        > In order for a change to be approved, they have to undertake a "technical
        > assessment" to evaluate feasibility, cost, risk, impact on the production
        > environment, etc., as well as a "business assessment" to evaluate how this
        > will impact on users, and the benefits to the business/cost of not doing it,
        > etc.
        >
        > I guess they cover it with the "technical assessment" --- somehow they
        > identify which code modules need changing, and then use the traceability
        > matrix to find knock-on effects. I'll pass on the question.

        I passed on the question, and my interpretation was correct --- the "technical
        assessment" basically means someone knowledgeable about the system sits down
        and has a thought about the consequences of the change for the new
        feature. This is most likely the original developer, and in some cases they
        might be the only person qualified to do this.

        Consequently, if this person instead made the change (in a test environment,
        *not* on production code), and watched which tests fail, then this would be
        sufficient, and probably more accurate than "thinking very hard".

        Anthony
        --
        Anthony Williams
        Senior Software Engineer, Beran Instruments Ltd.
      Your message has been successfully submitted and would be delivered to recipients shortly.