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

Traceability is NOT Trustability (was Re: Traceability)

Expand Messages
  • Brad Appleton
    ... Thanks for the link! Looks like good stuff (and free too :-) ... Someday soon I ll be blogging on this subject at http://blog.bradapp.net I m planning on
    Message 1 of 114 , Mar 8 11:49 PM
    • 0 Attachment
      Jason Gorman wrote on the agilemodeling YahooGroup:
      > On the subject of traceability, I just posted chapter
      > 4 of my UML for Managers e-Book that discusses
      > enterprise architecture and traceability at
      > <http://www.parlezuml.com/e-books/umlformanagers/index.htm>

      Thanks for the link! Looks like good stuff (and free too :-)

      > I share Scott [Ambler]'s view to the larger
      > extent. Traceability is a nice idea (like true MDA)
      > that appeals strongly to senior managers because they
      > believe it will give them better control over change. The
      > reality is that you'd be just as well-served to ask the
      > developers how long they think that change will take.

      Someday soon I'll be blogging on this subject at

      I'm planning on calling it something like "Traceability
      is NOT Trustability" or something similar with the same
      1st+last words.

      > My only caveat is that, at the enterprise level, you
      > need to know which developers to ask - which means
      > knowing which system(s) might be affected by a change
      > to the business architecture. I believe traceability
      > from business goals to business processes is useful
      > in enterprise change programs, and also from business
      > processes to system use cases (or user stories, or
      > features, or whatever). That way, we can gain a bird's
      > eye view of what parts of the business and its IT systems
      > will need to change, which helps us to know who we have
      > to ask to get the work done.

      To me, this supports my own conclusion that traceability
      is often desired because its presumed to somehow give us
      "TRUSTability", but that's really an illusion.

      Traceability is useful to the extent that it facilitates
      more effective communication & interaction between
      individuals, teams, and stakeholders. It is the people and
      the quality of their interactions that provide the desired

      So to the extent that traceability helps us more quickly
      identify the right people to interact with and the
      right information to initiate that interaction, it can
      be extremely useful. Beyond that, unless unintrusively
      automated, it can quickly turn into "busy work" with
      very high "friction" on development of new functionality
      realized as "working software".

      To that end, I have a few slides in a presentation I
      gave on "Agile Configuration Management Environments"

      (see slides 24-25) that talk about "Lean Traceability",
      and a big part of that is using encapsulation, modularity,
      and dependency management (a.k.a refactoring) to track
      at the coarse-grained level rather than a fine-grained
      one. This alone can reduce the traceability burden by 1-2
      orders of magnitude.

      There is a more detailed discussion of the same things
      near the end of the paper "The Agile Difference for SCM"
      at <http://www.cmcrossroads.com/article/34375>

      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
    • Dean Wampler
      This is true. Although I m a big proponent of AOP, it s important to use the best tools for the job. However, where AOP can be used beyond the capabilities of
      Message 114 of 114 , Jun 6, 2005
      • 0 Attachment
        This is true. Although I'm a big proponent of AOP, it's important to use
        the best tools for the job.

        However, where AOP can be used beyond the capabilities of normal code
        coverage tools is to gather metrics on non-trivial state transistions.
        For example, it's one thing to know that line N of class C got executed
        20 times or that the test run spent 5% of its time inside method M.
        Tools like AspectJ let you write tests that gather metrics like,
        "measure the count/time of M while inside the 'control flow' of method
        M2 (that is, M2 is lower on the stack)," or "count the times M is
        executed after M2 was executed and before method M3 is executed." (There
        are probably other non-AOP tools that do this, too, just to be fair ;)

        How does this work? Briefly, AspectJ (and most other AOP systems) has a
        language for selecting points of execution in the code (e.g., method
        calls, object creation, variable accesses, etc.) and a way to invoke
        executable code when those points
        are reached. So, for these examples, you specify a set of these points
        that match the criteria you want, then write Java/AJ code that gathers
        the data you want, when these points are reached.


        Jeff Grigg wrote:

        >--- "Jeff Grigg" <jeffgrigg@c...> wrote:
        > snip...
        >It occurs to me that this is essentially a code coverage question,
        >except reported by test instead of reported as an overall coverage
        >percentage. Maybe clover or some other code coverage tool could be
        >used to build traceability matrices.
      Your message has been successfully submitted and would be delivered to recipients shortly.