Process Domain

A characterization, or preferably a definition of the contexts where a process is likely to be successful.

MichaelJackson asserted that in order to be successful, a method needs to fit/ be tailored accordingly to a ProblemFrame.

Most processes are not defined in terms of a specific class of problems. Some of them define their domain by other means (like size of the team, style of programming - ex: ObjectOriented). It is unclear whether such characterizations are as useful, or are a equivalent or even a better alternative to MJ's requirement that a process should fit a class of problems.

Processes that I have trouble finding their domains at all: WaterFall, Spiral, XP, RUP. Maybe I'm just wrong but apparently they don't specify their domain. -- CostinCozianu

Discussion

AlistairCockburn says, in SurvivingObjectOrientedProjects, "I present the following methodology outline for a medium-sized Production project in an industrial setting. The characteristics of such a project are the following: 20-40 people, 1-2 years duration, time-to-market is important, not life-critical, need to keep costs down and to communicate with present and future staff." That seems pretty explicit to me. In AgileSoftwareDevelopment, he goes further, and gives a name for each of several different methodologies whose target domain he describes.

The question is whether the characterization of the method's domain is accurate and/or meaningful, because it describes secondary aspects of the project and not the problem. It doesn't necessarily means that MJ has to be right, maybe processes are better if they fit the characteristics of the project and not of the problem, but maybe not.

[[Refactoring note : I might have wrongly asserted in NoProcess, NoProcessDiscussion that "no methodologist whatsoever" designed his process to fit a specific class of problems. I certainly was wrong, and I'm sorry for creating the confusion.]]

thanks

Indeed, the next discussion centers around MichaelJackson's words above, their interpretation and correctness. He wrote (according to the quote above): "a method needs to fit/ be tailored accordingly to a ProblemFrame."

The first author above then extended that to, "Most processes are not defined in terms of a specific class of problems. Some of them define their domain by other means (like size of the team, style of programming)."

First of all, the writer is correct: most processes are indeed written as though they could be applied absolutely anywhere anytime. And that is clearly WRONG. So wrong indeed that let's just move to more interesting topics...

For a methodology, the word ProblemFrame does not limit itself to "problem being solved by the team", but rather "characteristics of the situation." There are several people hotly discussing which aspects of the situation should be used to characterize the ProblemFrame for a methodology.

RobertGlass has about 11 dimensions he is using. LukeHohmann named half a dozen in his book, JourneyOfaSoftwareProfessional?. I used 3 in my book AgileSoftwareDevelopment and the paper MethodologyPerProject?. I've since concluded that 11 is too few and 3 is too many... which poses an interesting conundrum (as they say).

For me, still #1 in selecting the domain of a process is #ofPeople multiplied by communication distance. That drives so much. RobertGlass likes to include things like experience of the group, subject area (embedded / real-time / shrink-wrap / web-site etc), degree of correctness needed, age of the technology, and stuff like that. I concur that each is important, but not so important that we should try to make the full 11^11 chart of all possible combinations. We can't, anyway.

So the thing to do, as far as I can see, it to simply announce where a process has worked and what might limit it's use. For different processes, the indices will be different. For example, one group of 35 people was doing the Y2K conversion of a suite of COBOL and assembler language programs. Another group of 35 was building Marriott Hotels' new web site. The processes the were using were both defined and of course totally different. Two people were doing a Java web-based program. Different again. etc. XP was applicable for the last of those three, but not the first two (both for team size and technology reasons).

By the way, RUP is not a process, but a process library or process framework. One is supposed to subset the library to get the instance to be used. -- AlistairCockburn

moved from ArchitectureDefinitions

FWIW, I think MichaelJackson does a very good job of describing the separation between ProblemDomain and SolutionDomain. It was a real eye-opener for me. -- RobertDiFalco