Comments (5)
  • Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

1 LuizCesar commented Permalink

Andy, <br /> Congratulations for your series. I read all posts and I liked very much, but I think the only way to capture the knowledge is practicing...only reading the concepts is not enough. So I suggest you to write about the pratical application of this concepts. <div>&nbsp;</div> Thanks. <div>&nbsp;</div> Luiz Cesar.

2 AndyGurd commented Permalink

Thank you for your feedback Luiz, I'm glad you're enjoying the series - there are more parts to follow. I completely agree that practice is the best way to learn and that examples of where techniques have been applied are very powerful. We'll look at doing a follow-up series on practical application experiences.

3 QA1-Skip commented Permalink

In the V-model of development, I advocated traceability. It wasa neat way to tie up loose ends after months of development. Now that we have more agile delivery, I question the value of tracing. When we are defining, designing, building, and testing software in short increments, how does traceability help me to deliver a better solution more quickly with a happier team?

4 AndyGurd commented Permalink

Hi Skip, thank you for your question. I've had lots of discussion and debate both within IBM, with industry experts and with clients around the topic of agile, requirements management and traceability, and it raises some interesting questions. What relationships do you still need to maintain between artifacts in your more agile approach? How do you maintain the big picture of what the systems/application does and how it does it, that lives beyond an iteration/sprint? What we've found is if you think of the V-model as an information model, rather than a process model, it's equally applicable in agile approaches as well as waterfall or hybrid waterfall-iterative approaches. When you create the artifacts and relationships and in what order will be different, but as a system of record the artifacts and their relationships will likely still exist and the relationships will still look like the V-model. Traceability must be done as part of the analysis, design, implement, test, build and deploy activities rather than as an after thought. Tools should create implicit relationships when a workflow is enacted and also make it very simple to create, maintain and utilize explicit relationships so that traceability is a benefit not an overhead. Whether you're following a waterfall or agile approach I believe traceability helps you provide context and rationale for design decisions, more quickly and easily track down sources of defects and identify all potentially impacted artifacts and components when a change request is evaluated.

5 KeithCollyer commented Permalink

Andy gets it exactly right here. Since I first came across the V-model, I have treated it as an information model rather than a process model, even though it is usually defined as the latter. In fact, I would argue that traceability is the only possible way that you can understand the relationships between the information that you are creating. A "traditional" approach involves a fairly linear development of information. This means that, at a gross level, it is relatively easy to keep track of where information comes from - though of course traceability is still needed at the detail level. Agile development is naturally more accumulative. It still has to create the same artifacts, and the relationships between those artifacts are the same as they are for traditional development. So why would you not want traceability? In fact, the need is even more pressing as there is no necessary relationship between what you do in one timebox and the next. The only way you can understand the connectedness of the information that you create is through traceability