Hi all, I believe that you make a very valid and important point here. I have not been involved in this discussion previously, but I think that your reasoning makes sense as OpenUP is supposed to be adaptable. However, I would like to raise one concern. If we decide to create a CP for a"non-TDD-version", then what impact would this have on the rest of the CPs? I mean, if there is one such "non-TDD" CP, then I imagine that we must also consider all other CPs and determine which of them should be extended with a "non-XX" version in order to be consistent throughout OpenUP, or ...?
Cheers Jaana N. hiho, > > > > There was another side topic of discussion about how strict OpenUP > treats a certain aspect of the process. And that is, does the process > "enforce" TDD. > > > > Version 0.9 of the process had the work on developer tests going on in > parallel with the implementation of the solution. Then there was > Concept: Test-first Design promoting the technique. > > > > The default version 1.0 has a very explicit TDD workflow in the > Capability Pattern: Develop Solution. A Guideline: Test-first Design > was also added to give more detail on the technique. > > > > There has been discussion that some places just adopting agile > techniques might not have the tool support and habits that work with > TDD. Do we want to have the process so explicitly prescribing the > technique that someone will look at it and say "well, I don't see myself > working that way, so I guess it is not the process for me"? > > > > With that in mind, I created a Capability Pattern with the element name > develop_solution_no_tdd. Each version of the Develop Solution Increment > capability pattern has an overview of the workflow in the Main > Description. The default one has very explicit TDD verbiage along the > lines of "The tests are run up front and, in failing, clearly define the > criteria to determine if the implementation works as intended." The > non-TDD one is more casual saying "Once the organization of the > technical solution is clear, the development and testing of the > implementation ensues." > > > > Like the Iteration Template described in a previous message, this > non-default CP is in the repository and not in the default published > site. But it supports the notion that OpenUP promotes TDD and that is > the preferred way to build software, but it is not enforced such that > non-TDD implementation should be characterized as "not doing OpenUP". > > > > I am distinctly out on a limb here and I welcome feedback. > > > > Even if we agree that there should be a non-enforced-TDD version of this > capability pattern, I think my first draft needs work. Below I have > pasted the standard 1.0 version of the workflow and then my non-TDD one. > As you can see, the default one has benefited from some good work by Jim > Ruehlin stressing that the design can be revisited for refactoring once > the tests pass. That nuance is lost on my crappy version. > > > > > ----------------- b > > > > > > > > Current drafty Non-TDD version > > > > > > > > Standard develop_solution > > > > > > _______________________________________________ > epf-dev mailing list > epf-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/epf-dev > _______________________________________________ epf-dev mailing list epf-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/epf-dev
