Re: [epf-dev] Another Unpublished Capability Pattern - Design Solution

["Jaana Nyfjord" <jaana@xxxxxxxxx>]

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@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/epf-dev
>