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

Traceability

Expand Messages
  • acockburn@aol.com
    In a message dated 3/11/2004 5:34:05 AM Mountain Standard Time, agileprojectmanagement@yahoogroups.com writes: - traceability is mandatory even with an agile
    Message 1 of 14 , Mar 11, 2004
      In a message dated 3/11/2004 5:34:05 AM Mountain Standard Time, agileprojectmanagement@yahoogroups.com writes:
      - traceability is mandatory even with an
      agile development team doing the coding. From this context a change in
      one system has serious impact on other systems - who approves of the
      change? Who gets to say no to the change? Who pays for the downstream
      costs of the upstream changes? Questions like that come out of the
      "impact analysis," in contexts where thee are conflicting but equally
      important interests.
      --->
      Hi, Glen --- Note you shifted from traceability to impact analysis, and not only that, but impact analysis across multiple systems.
       
      I have no trouble with the situation you mention, but it is not the same as "traceability from requirements to code."
       
      In my thinking, the requirements are organized along fundamentally different lines than code. One requirement touches classes in ways that are not obvious. Touching one class affect multiple requirements.  And coders are touching the classes all the time, changing the map from requirement to class multiple times a day.  Updating that map is a horrendous job.
       
      The part I'm questioning is... Why is it worth so much money to know the names of the classes implementing any one requirement? (Alternatively --- Just how much money is it worth to know that much information?  Isn't it cheaper to have programmers examine the system "on demand" when that information is really needed?)
      Actually my question is --- in what situation do you really need to know the names of the classes implementing any particular requirement (other than just at the moment of changing the code). 
       
      I believe that the question being asked by the business is, How expensive is it to make this requirements change?  And that question can be answered without requirements-to-code traceability machinery.
       
      Those are quite different from the question you are dealing with, which is: How many Systems change when this requirement changes?  The granularity involved is very different.
       
       
       
       
       
      ==============================================
      Alistair Cockburn
      President, Humans and Technology

      http://alistair.cockburn.us alistair.cockburn@...
      1814 E. Fort Douglas Circle, Salt Lake City, UT 84103
      Phone: 801.582-3162            Fax: 775.416.6457

      Author of
      "Surviving Object-Oriented Projects" (1998)
      "Writing Effective Use Cases" (Jolt Productivity Award 2001)
      "Agile Software Development" (Jolt Productivity Award 2002)

      "La perfection est atteinte non quand il ne reste rien a ajouter,
      mais quand il ne reste rien a enlever." (Saint-Exupery)
      ==============================================

    • Alleman, Glen B.
      Alistair , But it is traceability from requirements to code. That s the purpose of the traceability matrix, so the SQA and V&V folks can find where to put
      Message 2 of 14 , Mar 11, 2004

        Alistair ,

         

        But it is traceability from requirements to code. That’s the purpose of the traceability matrix, so the SQA and V&V folks can find where to put there acceptance tests. What changed? Requirements changes, implementation changes, integration changes.

         

        So the re-ask the question(s).

         

        Can traceability be agile – yes

        Does traceability add value – depends on the domain. For us it’s mandatory. For a small XP project doubtful.

         

        For the business to answer how expensive it is to make a change there are multiple parts to the answer:

        (1)     What’s impacted

        (2)     What has to change outside of the original change – traceability from requirements to code for new requirements resulting from the change. This happens here all the time, one requirements creates a conflict in another requirements or possible in another system.

        (3)     What new tests do I need now that I understand the changes?

        (4)     How do I get all these new test into the test cycle – IV&V mostly.

         

        Regarding your statement of why is it valuable to know the objects traced to the requirements? First there is a gap in concept. We here are interested in both the impact of the change at the macro level for staffing and resource allocation. But also if a module or even down to the object is impacted then the IV&V process is impacted. The Trojan Horse problem exists here as it would in banking and finance.  There there is value in knowing what modules or objects are impacted if said modules have fiduciary  impacts.

         

        So I’ll invert the question. If I have software that has health and safety or fiduciary impacts how would I trust the outcome of a change if I didn’t know which modules were involved in the change “before” I started down the change path?

         

        Glen B. Alleman

        -----Original Message-----
        From: acockburn@... [mailto:acockburn@...]
         Subject: [scrumdevelopment] Traceability

         

        In a message dated 3/11/2004 5:34:05 AM Mountain Standard Time, agileprojectmanagement@yahoogroups.com writes:

        - traceability is mandatory even with an
        agile development team doing the coding. From this context a change in
        one system has serious impact on other systems - who approves of the
        change? Who gets to say no to the change? Who pays for the downstream
        costs of the upstream changes? Questions like that come out of the
        "impact analysis," in contexts where thee are conflicting but equally
        important interests.

        --->

        Hi, Glen --- Note you shifted from traceability to impact analysis, and not only that, but impact analysis across multiple systems.

         

        I have no trouble with the situation you mention, but it is not the same as "traceability from requirements to code."

         

        In my thinking, the requirements are organized along fundamentally different lines than code. One requirement touches classes in ways that are not obvious. Touching one class affect multiple requirements.  And coders are touching the classes all the time, changing the map from requirement to class multiple times a day.  Updating that map is a horrendous job.

         

        The part I'm questioning is... Why is it worth so much money to know the names of the classes implementing any one requirement? (Alternatively --- Just how much money is it worth to know that much information?  Isn't it cheaper to have programmers examine the system "on demand" when that information is really needed?)

        Actually my question is --- in what situation do you really need to know the names of the classes implementing any particular requirement (other than just at the moment of changing the code). 

         

        I believe that the question being asked by the business is, How expensive is it to make this requirements change?  And that question can be answered without requirements-to-code traceability machinery.

         

        Those are quite different from the question you are dealing with, which is: How many Systems change when this requirement changes?  The granularity involved is very different.

         

         

      • Steven Gordon
        Glen, The requirement seems to be a way to predict which parts of the code (possibly, in several inter-releated systems) will be impacted by implementing a NEW
        Message 3 of 14 , Mar 11, 2004
          Glen,

          The requirement seems to be a way to predict which parts of the code (possibly, in several inter-releated systems) will be impacted by implementing a NEW requirement, not necessarily full traceability. How does knowing which parts of the code were involved in the implementation of OLD requirements help much at all?

          Presumably, one would also want to be able to compare the impacts of various alternative designs for the new requirement. Again how does knowing which parts of the code were involved in the implementation of OLD requirements help?

          Steven Gordon

          -----Original Message-----
          From: Alleman, Glen B. [mailto:glen.alleman@...]
          Sent: Thu 3/11/2004 10:20 AM
          To: scrumdevelopment@yahoogroups.com
          Cc:
          Subject: RE: [scrumdevelopment] Traceability



          Alistair ,



          But it is traceability from requirements to code. That’s the purpose of the traceability matrix, so the SQA and V&V folks can find where to put there acceptance tests. What changed? Requirements changes, implementation changes, integration changes.



          So the re-ask the question(s).



          Can traceability be agile – yes

          Does traceability add value – depends on the domain. For us it’s mandatory. For a small XP project doubtful.



          For the business to answer how expensive it is to make a change there are multiple parts to the answer:

          (1) What’s impacted

          (2) What has to change outside of the original change – traceability from requirements to code for new requirements resulting from the change. This happens here all the time, one requirements creates a conflict in another requirements or possible in another system.

          (3) What new tests do I need now that I understand the changes?

          (4) How do I get all these new test into the test cycle – IV&V mostly.



          Regarding your statement of why is it valuable to know the objects traced to the requirements? First there is a gap in concept. We here are interested in both the impact of the change at the macro level for staffing and resource allocation. But also if a module or even down to the object is impacted then the IV&V process is impacted. The Trojan Horse problem exists here as it would in banking and finance. There there is value in knowing what modules or objects are impacted if said modules have fiduciary impacts.



          So I’ll invert the question. If I have software that has health and safety or fiduciary impacts how would I trust the outcome of a change if I didn’t know which modules were involved in the change “before” I started down the change path?



          Glen B. Alleman

          -----Original Message-----
          From: acockburn@... [mailto:acockburn@...]
          Subject: [scrumdevelopment] Traceability



          In a message dated 3/11/2004 5:34:05 AM Mountain Standard Time, agileprojectmanagement@yahoogroups.com writes:

          - traceability is mandatory even with an
          agile development team doing the coding. From this context a change in
          one system has serious impact on other systems - who approves of the
          change? Who gets to say no to the change? Who pays for the downstream
          costs of the upstream changes? Questions like that come out of the
          "impact analysis," in contexts where thee are conflicting but equally
          important interests.

          --->

          Hi, Glen --- Note you shifted from traceability to impact analysis, and not only that, but impact analysis across multiple systems.



          I have no trouble with the situation you mention, but it is not the same as "traceability from requirements to code."



          In my thinking, the requirements are organized along fundamentally different lines than code. One requirement touches classes in ways that are not obvious. Touching one class affect multiple requirements. And coders are touching the classes all the time, changing the map from requirement to class multiple times a day. Updating that map is a horrendous job.



          The part I'm questioning is... Why is it worth so much money to know the names of the classes implementing any one requirement? (Alternatively --- Just how much money is it worth to know that much information? Isn't it cheaper to have programmers examine the system "on demand" when that information is really needed?)

          Actually my question is --- in what situation do you really need to know the names of the classes implementing any particular requirement (other than just at the moment of changing the code).



          I believe that the question being asked by the business is, How expensive is it to make this requirements change? And that question can be answered without requirements-to-code traceability machinery.



          Those are quite different from the question you are dealing with, which is: How many Systems change when this requirement changes? The granularity involved is very different.







          To Post a message, send it to: scrumdevelopment@...
          To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...



          Yahoo! Groups Sponsor
          ADVERTISEMENT
        • acockburn@aol.com
          In a message dated 3/11/2004 10:25:01 AM Mountain Standard Time, glen.alleman@rfets.gov writes: So I’ll invert the question. If I have software that has
          Message 4 of 14 , Mar 11, 2004
            In a message dated 3/11/2004 10:25:01 AM Mountain Standard Time, glen.alleman@... writes:

             

            So I’ll invert the question. If I have software that has health and safety or fiduciary impacts how would I trust the outcome of a change if I didn’t know which modules were involved in the change “before” I started down the change path?

            --->
            That question presupposes its answer.
            I counterpropose that you "discover" the modules involved in the change "as" you proceed down the change path.
             
            The question to be investigated / debated is which is cheaper --- to keep all the data so that the answer is available before starting down the change path, or to not keep the data and discover it each time.   ?
             
            Actually, there is another dimension to the question, which you bring up, namely --- what is the optimal granularity of the data that you keep to narrow the search?
             
            I can see keeping data on the order of: "This touches VB and data tables, but not the ..."
            I can't see keeping data on the order of: "This touches class Foo".  The reason for my skepticism of this latter is that when a programmer refactors Foo into Elf and Santa, then said programmer has to back into the question: what are all the requirements that touch Foo --- which of them now have to shift to Elf and which to Santa? and then update all that data.
             
            With programmers spending most of their days changing existing code, this is an outlandish amount of money to spend on the question, "Which requirements touch class Foo?"
             
            ==============================================
            Alistair Cockburn
            President, Humans and Technology

            http://alistair.cockburn.us alistair.cockburn@...
            1814 E. Fort Douglas Circle, Salt Lake City, UT 84103
            Phone: 801.582-3162            Fax: 775.416.6457

            Author of
            "Surviving Object-Oriented Projects" (1998)
            "Writing Effective Use Cases" (Jolt Productivity Award 2001)
            "Agile Software Development" (Jolt Productivity Award 2002)

            "La perfection est atteinte non quand il ne reste rien a ajouter,
            mais quand il ne reste rien a enlever." (Saint-Exupery)
            ==============================================

          • Alleman, Glen B.
            Steve, Good restatement. The term full is new and maybe clarifies the problem. What s the difference between full traceability and traceability? What s the
            Message 5 of 14 , Mar 11, 2004
              Steve,

              Good restatement. The term "full" is new and maybe clarifies the
              problem.

              What's the difference between full traceability and traceability? What's
              the different between traceability from requirements to code and
              traceability from requirements to test cases?

              As far as comparing the impacts it would help when we're quoting a cost,
              risk, safety assessment to the customer. We know which modules are
              untrustworthy from past changes. If we're in that section doing an SCR
              we would also know from metrics what the likelihood of a bad outcome is.
              Our apps are primarily data and decisions support for there are many
              times when a "bug" does not appear until some time much later, since
              full path testing is not the norm.

              Glen B. Alleman

              -----Original Message-----
              From: Steven Gordon [mailto:sagordon@...]
              Sent: Thursday, March 11, 2004 10:29 AM
              To: scrumdevelopment@yahoogroups.com
              Subject: RE: [scrumdevelopment] Traceability

              Glen,

              The requirement seems to be a way to predict which parts of the code
              (possibly, in several inter-releated systems) will be impacted by
              implementing a NEW requirement, not necessarily full traceability. How
              does knowing which parts of the code were involved in the implementation
              of OLD requirements help much at all?

              Presumably, one would also want to be able to compare the impacts of
              various alternative designs for the new requirement. Again how does
              knowing which parts of the code were involved in the implementation of
              OLD requirements help?

              Steven Gordon
            • Brad Appleton
              ... No - he didn t shift from traceability to impact analysis. impact analysis is one of the main reasons for traceability. Traceability does not mean
              Message 6 of 14 , Mar 11, 2004
                On Thu, Mar 11, 2004 at 12:03:22PM -0500, acockburn@... wrote:
                > Hi, Glen --- Note you shifted from traceability to impact analysis, and
                > not only that, but impact analysis across multiple systems.

                No - he didn't shift from traceability to impact
                analysis. impact analysis is one of the main reasons for
                traceability. Traceability does not mean "traceability from
                requirements to code". It means traceability from requirements
                THRU all intermediate artifacts/activities TO all deliverable
                artifacts and their dependencies. The main reason cited for
                for doing this is not merely for ensuring conformance to
                spec but for change impact analysis. And that was the main
                aspect of traceability mentioned in the post that began this
                thread. impact analysis is not separate from traceability,
                it is one of the main reasons given for it.

                > In my thinking, the requirements are organized along fundamentally
                > different lines than code. One requirement touches classes in ways that
                > are not obvious. Touching one class affect multiple requirements. And
                > coders are touching the classes all the time, changing the map from
                > requirement to class multiple times a day. Updating that map is a
                > horrendous job.

                Yup! That's but one of the many things that makes it hard, and horrific.

                > The part I'm questioning is... Why is it worth so much money to know the
                > names of the classes implementing any one requirement? (Alternatively
                > --- Just how much money is it worth to know that much information?
                > Isn't it cheaper to have programmers examine the system "on demand" when
                > that information is really needed?)
                > Actually my question is --- in what situation do you really need to know
                > the names of the classes implementing any particular requirement (other
                > than just at the moment of changing the code).

                I think you answered your question below.

                > I believe that the question being asked by the business is,
                > How expensive is it to make this requirements change? And
                > that question can be answered without requirements-to-code
                > traceability machinery.

                Yes it can. The issue is whether or not it can be answered
                better and more accurately and/or more quickly with traceability
                "machinery" and whether or not it makes enough difference to
                provide enough value to outweigh the costs (by winning the
                bid, or having more accurate estimates (to win later bids),
                and so on and so forth).

                > Those are quite different from the question you are dealing with,
                > which is: How many Systems change when this requirement changes?
                > The granularity involved is very different.

                Most definitely. Traceability has scale issues just like
                everything else. And when I no longer have one co-located
                team, and instead have to coordinate multiple teams working
                on multiple (sub)systems, then the "impact analysis" question
                isn't merely one of "which classes/files are related to this
                requirement" but one of "which entities at the 'appropriate'
                levels of scale are impacted by this requirement" and those
                entities may be teams and organizations that need to have
                their part of the estimate "farmed out" to them, or that need
                to be brought together to bring their knowledge of their part
                to help estimate the whole shmeer"

                So for most really large systems (and a great many government
                contracts) traceability isn't merely about artifacts, but about
                *architecture*, and Conway's Law applies so that it becomes
                very much about successful communication and collaboration to
                manage expectations!

                --
                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
              • Steven Gordon
                Maybe it is obvious to some of you, but I still do not see how the network of linkages from EXISTING requirements through tests and other intermediate
                Message 7 of 14 , Mar 11, 2004
                  Maybe it is obvious to some of you, but I still do not see how the network of linkages from EXISTING requirements through tests and other intermediate artifacts to the EXISTING code significantly helps in ascertaining the impact of implementing a NEW requirement.

                  -----Original Message-----
                  From: Brad Appleton [mailto:brad@...]
                  Sent: Thu 3/11/2004 11:17 AM
                  To: agileprojectmanagement@yahoogroups.com
                  Cc: scrumdevelopment@yahoogroups.com
                  Subject: [scrumdevelopment] Re: [APM] Traceability


                  On Thu, Mar 11, 2004 at 12:03:22PM -0500, acockburn@... wrote:
                  > Hi, Glen --- Note you shifted from traceability to impact analysis, and
                  > not only that, but impact analysis across multiple systems.

                  No - he didn't shift from traceability to impact
                  analysis. impact analysis is one of the main reasons for
                  traceability. Traceability does not mean "traceability from
                  requirements to code". It means traceability from requirements
                  THRU all intermediate artifacts/activities TO all deliverable
                  artifacts and their dependencies. The main reason cited for
                  for doing this is not merely for ensuring conformance to
                  spec but for change impact analysis. And that was the main
                  aspect of traceability mentioned in the post that began this
                  thread. impact analysis is not separate from traceability,
                  it is one of the main reasons given for it.
                • Alleman, Glen B.
                  Brad, Thank you. I get the feeling that this discussion is one of context and domain like all good argumentative discussions. Traceability as a process
                  Message 8 of 14 , Mar 11, 2004
                    Brad,

                    Thank you. I get the feeling that this discussion is one of context and
                    domain like all good argumentative discussions. Traceability as a
                    process provides many artifacts - impact assessment, effort assessments,
                    audit materials, test case coverage etc.

                    But if you start with the conjecture that it can add no value without
                    first asking in what context, then any and all answers are
                    unsatisfactory.

                    Your discussion below illuminates the gaps in domain. For a large
                    weapons systems development - say 10 millions of code - tractability of
                    requirements to code is how we get paid. Earned Value is the accounting
                    side, traceability is the auditor's tool for computing BCWP showing that
                    a requirements has been met with not only tests but deliverables into
                    the CM system.

                    Glen B. Alleman

                    -----Original Message-----
                    From: Brad Appleton [mailto:brad@...]
                    Sent: Thursday, March 11, 2004 11:18 AM
                    To: agileprojectmanagement@yahoogroups.com
                    Cc: scrumdevelopment@yahoogroups.com
                    Subject: [scrumdevelopment] Re: [APM] Traceability

                    On Thu, Mar 11, 2004 at 12:03:22PM -0500, acockburn@... wrote:
                    > Hi, Glen --- Note you shifted from traceability to impact analysis,
                    and
                    > not only that, but impact analysis across multiple systems.

                    No - he didn't shift from traceability to impact
                    analysis. impact analysis is one of the main reasons for
                    traceability. Traceability does not mean "traceability from
                    requirements to code". It means traceability from requirements
                    THRU all intermediate artifacts/activities TO all deliverable
                    artifacts and their dependencies. The main reason cited for
                    for doing this is not merely for ensuring conformance to
                    spec but for change impact analysis. And that was the main
                    aspect of traceability mentioned in the post that began this
                    thread. impact analysis is not separate from traceability,
                    it is one of the main reasons given for it.

                    > In my thinking, the requirements are organized along fundamentally
                    > different lines than code. One requirement touches classes in ways
                    that
                    > are not obvious. Touching one class affect multiple requirements. And
                    > coders are touching the classes all the time, changing the map from
                    > requirement to class multiple times a day. Updating that map is a
                    > horrendous job.

                    Yup! That's but one of the many things that makes it hard, and horrific.

                    > The part I'm questioning is... Why is it worth so much money to know
                    the
                    > names of the classes implementing any one requirement? (Alternatively
                    > --- Just how much money is it worth to know that much information?
                    > Isn't it cheaper to have programmers examine the system "on demand"
                    when
                    > that information is really needed?)
                    > Actually my question is --- in what situation do you really need to
                    know
                    > the names of the classes implementing any particular requirement
                    (other
                    > than just at the moment of changing the code).

                    I think you answered your question below.

                    > I believe that the question being asked by the business is,
                    > How expensive is it to make this requirements change? And
                    > that question can be answered without requirements-to-code
                    > traceability machinery.

                    Yes it can. The issue is whether or not it can be answered
                    better and more accurately and/or more quickly with traceability
                    "machinery" and whether or not it makes enough difference to
                    provide enough value to outweigh the costs (by winning the
                    bid, or having more accurate estimates (to win later bids),
                    and so on and so forth).

                    > Those are quite different from the question you are dealing with,
                    > which is: How many Systems change when this requirement changes?
                    > The granularity involved is very different.

                    Most definitely. Traceability has scale issues just like
                    everything else. And when I no longer have one co-located
                    team, and instead have to coordinate multiple teams working
                    on multiple (sub)systems, then the "impact analysis" question
                    isn't merely one of "which classes/files are related to this
                    requirement" but one of "which entities at the 'appropriate'
                    levels of scale are impacted by this requirement" and those
                    entities may be teams and organizations that need to have
                    their part of the estimate "farmed out" to them, or that need
                    to be brought together to bring their knowledge of their part
                    to help estimate the whole shmeer"

                    So for most really large systems (and a great many government
                    contracts) traceability isn't merely about artifacts, but about
                    *architecture*, and Conway's Law applies so that it becomes
                    very much about successful communication and collaboration to
                    manage expectations!

                    --
                    Brad Appleton
                  • Alleman, Glen B.
                    Steve, Let s pretent we have a traceabiity matirx for the current system. Now a new requirement comes along. Since this is a production system (I get to
                    Message 9 of 14 , Mar 11, 2004

                      Steve,

                       

                      Let’s pretent we have a traceabiity matirx for the current system. Now a new requirement comes along. Since this is a production system (I get to pretend in my own domain), I would like to know what other modeules would be impacted by this change. In Alistair’s example I want ot avoid tying requirments to methods, but say we did. Now I can answer the question, how many regression tests do I need, what data validation rules are impacted in the DB, stuff like that. Same goes for bug fixing in existing code.

                       

                      Glen B. Alleman

                       

                      -----Original Message-----
                      From: Steven Gordon [mailto:sagordon@...]
                      Sent: Thursday, March 11, 2004 11:26 AM
                      To: scrumdevelopment@yahoogroups.com
                      Subject: RE: [scrumdevelopment] Re: [APM] Traceability

                       

                      Maybe it is obvious to some of you, but I still do not see how the network of linkages from EXISTING requirements through tests and other intermediate artifacts to the EXISTING code significantly helps in ascertaining the impact of implementing a NEW requirement.

                      -----Original Message-----
                      From: Brad Appleton [mailto:brad@...]
                      Sent: Thu 3/11/2004 11:17 AM
                      To: agileprojectmanagement@yahoogroups.com
                      Cc: scrumdevelopment@yahoogroups.com
                      Subject: [scrumdevelopment] Re: [APM] Traceability

                      On Thu, Mar 11, 2004 at 12:03:22PM -0500, acockburn@... wrote:
                      > Hi, Glen --- Note you shifted from traceability to impact analysis, and
                      > not only that, but impact analysis across multiple systems.

                      No - he didn't shift from traceability to impact
                      analysis. impact analysis is one of  the main reasons for
                      traceability. Traceability does not mean "traceability from
                      requirements to code". It means traceability from requirements
                      THRU all intermediate artifacts/activities TO all deliverable
                      artifacts and their dependencies. The main reason cited for
                      for doing this is not merely for ensuring conformance to
                      spec but for change impact analysis. And that was the main
                      aspect of traceability mentioned in the post that began this
                      thread. impact analysis is not separate from traceability,
                      it is one of the main reasons given for it.

                    • Ron Jeffries
                      ... Unclear how knowing how something else is implemented tells you how something new is implemented. If that worked, we could use the matrix from the previous
                      Message 10 of 14 , Mar 11, 2004
                        On Thursday, March 11, 2004, at 1:30:22 PM, Alleman, Glen B. wrote:

                        > Let's pretent we have a traceabiity matirx for the current system. Now a
                        > new requirement comes along. Since this is a production system (I get to
                        > pretend in my own domain), I would like to know what other modeules
                        > would be impacted by this change. In Alistair's example I want ot avoid
                        > tying requirments to methods, but say we did. Now I can answer the
                        > question, how many regression tests do I need, what data validation
                        > rules are impacted in the DB, stuff like that. Same goes for bug fixing
                        > in existing code.

                        Unclear how knowing how something else is implemented tells you how
                        something new is implemented. If that worked, we could use the matrix from
                        the previous company. Which, by the way, would probably work just as well
                        ...

                        Ron Jeffries
                        www.XProgramming.com
                        A man hears what he wants to hear, and disregards the rest. -- Paul Simon
                      • Ron Jeffries
                        ... There is no disagreement that if it s required you have to do it. The discussion of interest is around whether it is worth doing. In what way would a
                        Message 11 of 14 , Mar 11, 2004
                          On Thursday, March 11, 2004, at 1:26:59 PM, Alleman, Glen B. wrote:

                          > Your discussion below illuminates the gaps in domain. For a large
                          > weapons systems development - say 10 millions of code - tractability of
                          > requirements to code is how we get paid. Earned Value is the accounting
                          > side, traceability is the auditor's tool for computing BCWP showing that
                          > a requirements has been met with not only tests but deliverables into
                          > the CM system.

                          There is no disagreement that if it's required you have to do it. The
                          discussion of interest is around whether it is worth doing.

                          In what way would a random matrix be outperformed by the one you do?

                          Ron Jeffries
                          www.XProgramming.com
                          Know what I pray for? The strength to change what I can, the inability to
                          accept what I can't and the incapacity to tell the difference. --Calvin and Hobbes
                        • Dan Rawsthorne
                          When was the last time you had a new requirement that didn t involve existing data or changing existing code? Or, looking at the requirements, didn t affect
                          Message 12 of 14 , Mar 11, 2004
                            When was the last time you had a new requirement that didn't involve
                            existing data or changing existing code? Or, looking at the requirements,
                            didn't affect some existing requirement that the analysts/customers/owners
                            overlooked?



                            Dan ;-)

                            Dan Rawsthorne, PhD, Sr. Consultant
                            <http://www.netobjectives.com> www.netobjectives.com
                            DrDan@...
                            office: 425-269-8628

                            Net Objectives' vision is effective software development without suffering.
                            Our mission is to assist software development teams in accomplishing this
                            through a combination of training and mentoring.

                            From: Steven Gordon [mailto:sagordon@...]


                            Maybe it is obvious to some of you, but I still do not see how the network
                            of linkages from EXISTING requirements through tests and other intermediate
                            artifacts to the EXISTING code significantly helps in ascertaining the
                            impact of implementing a NEW requirement.

                            -----Original Message-----
                            From: Brad Appleton [mailto:brad@...]
                            Sent: Thu 3/11/2004 11:17 AM
                            To: agileprojectmanagement@yahoogroups.com
                            Cc: scrumdevelopment@yahoogroups.com
                            Subject: [scrumdevelopment] Re: [APM] Traceability

                            On Thu, Mar 11, 2004 at 12:03:22PM -0500, acockburn@... wrote:
                            > Hi, Glen --- Note you shifted from traceability to impact analysis, and
                            > not only that, but impact analysis across multiple systems.

                            No - he didn't shift from traceability to impact
                            analysis. impact analysis is one of the main reasons for
                            traceability. Traceability does not mean "traceability from
                            requirements to code". It means traceability from requirements
                            THRU all intermediate artifacts/activities TO all deliverable
                            artifacts and their dependencies. The main reason cited for
                            for doing this is not merely for ensuring conformance to
                            spec but for change impact analysis. And that was the main
                            aspect of traceability mentioned in the post that began this
                            thread. impact analysis is not separate from traceability,
                            it is one of the main reasons given for it.
                          • David A Barrett
                            I know that I m in over my head in this discussion, but a couple of things occur to me. The first is that comparison of traceability to insurance is misguided.
                            Message 13 of 14 , Mar 11, 2004
                              I know that I'm in over my head in this discussion, but a couple of things
                              occur to me.

                              The first is that comparison of traceability to insurance is misguided.
                              Insurance is expected to kick in when disaster strikes and a traceability
                              matrix is not implemented in case of disaster. A better comparison might
                              be to someone who lives downtown in a big city and maintains a car. They
                              pay for parking, insurance and maintenance but have very few occasions to
                              actually drive anywhere. An examination of their use of the car over time
                              might indicate that it would be better for them to rent a car or take a
                              taxi on those occasions when they do need to use a car.

                              Second, it seems to me that a traceability matrix eventual hits the same
                              pitfalls that you encounter when using waterfall project methodologies on
                              large development projects. There is a kind of a "Hiesenberg Uncertainty
                              Principle" surrounding these activities which eventually makes them less
                              effective than people imagine. Sometimes it seems that the more time you
                              spend spec'ing and analysing a large project, the further away you are from
                              finishing the project and the more uncertainty you introduce into the
                              project. Furthermore, your feeling of certainty about the project grows
                              (you've spent more time analysing!) which only widens the gulf between what
                              you think you know, what you actually know and how much of that will be
                              relevant when the code is completed.

                              Does the same thing occur with a traceability matrix? Do you spend more
                              and more time maintaining it and watching it grow until it gets to the
                              point where it ceases to be a really useful tool? Is it a fallacy to think
                              that something as inherently complex as a computer system can be distilled
                              down to a matrix, or does it require someone with real knowledge of the
                              system to apply intelligence to the examination of a system to determine
                              the impact of a change?

                              Perhaps the real test is one question. If your career depended on giving
                              the most accurate answer to questions about the scope, impact and cost of
                              implementing a change would you consult the traceability matrix or would
                              you ask the systems analyst/programmer who knew the most about that aspect
                              of the system?


                              Dave Barrett
                            • Tiseo, Paul
                              ... As most analogies are. :) What I was trying to do is make a point that the benefit of traceability is not realized constantly, but in low-frequency events
                              Message 14 of 14 , Mar 11, 2004
                                > From: David A Barrett [mailto:dave.barrett@...]
                                > Sent: Thursday, March 11, 2004 3:24 PM
                                >
                                > The first is that comparison of traceability to insurance is misguided.

                                As most analogies are. :)

                                What I was trying to do is make a point that the benefit of traceability is
                                not realized constantly, but in low-frequency events that could potentially
                                never happen in a project's lifetime. When someone says most times they've
                                seen it done, it cost a lot and there was no benefit from it, it might be
                                because the reason to benefit from it never realized itself. Much like life
                                insurance looks worthless until it is exercised.

                                Your car analogy in this respect works also. However, it might be that not
                                having a car, and taking a subway, which got stuck in between stations and
                                caused you to miss your presentation for that new account worth a cool $1mil
                                might make you reconsider the relatively minute cost of a car, insurance and
                                parking space! :)

                                > Insurance is expected to kick in when disaster strikes and a traceability
                                > matrix is not implemented in case of disaster.

                                In fact, it is; it's just a much, *much* smaller disaster... :) A class
                                refactoring, a table column split, a protocol format re-specification, going
                                to IPv6... small disasters, really! :)

                                > Perhaps the real test is one question. If your career depended on giving
                                > the most accurate answer to questions about the scope, impact and cost of
                                > implementing a change would you consult the traceability matrix or would
                                > you ask the systems analyst/programmer who knew the most about that aspect
                                > of the system?

                                Well, it depends. Is the team working well with a good traceability process?
                                Is the systems guy still around? Does he remember what he did three years
                                ago when he worked on that section with enough accuracy? Will it take me
                                three days or three minutes to run tests on multiple systems because I've
                                changed from Novell's e-Dir to Microsoft's Active Directory? Will it take me
                                three days or three minutes to ask multiple system programmers, architects
                                and or coders because I've changed from Novell's e-Dir to Microsoft's Active
                                Directory? I don't think it is as clear-cut as "extremists" on either side
                                of the fence make it.

                                _________________________________
                                Paul Tiseo, Systems Programmer
                                Research Computing Facility
                                Mayo Clinic Jacksonville, Griffin 371
                                tiseo.paul@...
                              Your message has been successfully submitted and would be delivered to recipients shortly.