Method Engineering

"One motivation of the method engineering community is that, in practice, methods are most often not applied as such, but are constantly being adapted and extended. A goal of this community is therefore to provide flexible, customizable support for applying methods." (Problems versus solutions: the role of the application domain in software by Iris Vessey, presented at the seventh workshop on Empirical studies of programmers October 24 - 26, 1997 Alexandria, VA USA
- (http://www.acm.org/pubs/citations/proceedings/chi/266399/p233-vessey/ -- requires an account).

That paper quite nicely compares "application focused approaches of computing communities" of which MethodEngineering is one.

The reason why I wanted to mention this here was the notion of SituationalMethodEngineering that I have only a vague idea of, and couldn't find anything now - just recall that they have used GenreTheory? etc .. except that now I found the original publication: Kumar, K. and Welke, R. Method engineering: A proposal for situation specific methodology construction. Challenges and Strategies for Research in Systems Development. W.W. Kotterman, and J.A. Senn, Eds. John Wiley, Washington, D.C. 1992. - haven't gotten my hands on that but found a citetion in Reinventing methodology: who reads it and why? by Gezinus J. Hidding in Communications of the ACM Volume 40, Issue 11 (1997) (http://www.acm.org/pubs/citations/journals/cacm/1997-40-11/p102-hidding/)

This seems to be close to many things mentioned here, such as EveryoneShouldBeaMethodologist and RollingYourOwnMethodology - also AdaptiveMethodologies .. or what do you think?

Have these people actually recognized things similar to what AlistairCockburn often points out? (but years before?) One difference might be, that while Alistair's MethodologySpace concerns different needs for methodologies based on the size of the project, organization, criticality etc. these MethodEngineering people are more concerned with the ApplicationDomain - right? But does these approaches lead to the same, being the other sides of a one coin? Which would be definining methodologies so that they can be adapted .. or thinking differently about the whole issue (as the argument seems to often be on both sides).

Oh one one more potential difference (was reminded of this after checking the ApplicationDomain entry here): MethodEngineering people might be more so-called InformationSystems? people than SoftwareEngineering (not to mention actually developers/programmers..) which also may explain the emphasis on ApplicationDomain in organizational sense [which is the focus of information systems, or management information systems (MIS)] - i.e. that developing HealthCare?, NewMedia?, SpaceTravel? etc. systems (in the end: software?) if different (that's also where the GenreTheory?, mentioned earlier, comes in .. e.g. somebody suggested that WebInformationSystems? could be recognized as a genre and thereby methods could be adapted to it).

Does this make sense, or is it just part of the BigDesignUpFront?

Is this CategoryMethodology ? (sorry if not :-o)

ToniAlatalo


Good set of references - wish I could reach them all. I did read the Anderson Consulting article in the CACM, quite carefully, until I noticed the gaps in their work and the background agenda, at which point I put it away. The background assumption is that "method = process" (in my world, process is only 1/10 of a methodology), and the background agenda, as is natural with a large company like Anderson, is to make put the "building blocks" of the process online in a database so that the immediately needed process can be constructed on the fly.

Ernst & Young had an expert system to do this back in 1994. IBM put all its material online in a system they call(ed) WSDDM (pronounced "wisdom" and the acronym no doubt stands for ... Dynamic Development Methodology).

I'm afraid I just keep skirting further off to the side... process is now not only just 1/10 of methodology, I am now more inclined to designing an EcologyNotMethodology (with JimHighsmith). The process is useful as a training device for newcomers and to avoid confusion, but a process, per se, does not confer productivity gains. A good team will outweigh most differences in process design. The question is what to do about that, and what to do with big company's needs/interests. --AlistairCockburn


I'd totally agree that the process is not "it" (depending, of course, how defined..)

What is a methodology then, if not process?

In our work, we've been focusing on modelling .. or as method(ology) development people seem to call it, metamodelling, i.e. identifying what should be modelled when actually designing. So far we've done it on two fronts (with a web/hypermedia/mobility bias): adaptivity and security. An early attempt towards integration is at (http://owla.oulu.fi/publications/ht01-poster-submitted.pdf) - that kind of things would perhaps classify as techniques, or approaches?

Reading MethodologySpace again (loved the title "what does a methodology look like" there :) there's a lot about organizing (which has been totally outside our focus..), roles etc. I guess this is where EcologyNotMethodology comes in, as ecology is about individuals relationships to the environment, to each other, vice-versa etc?

Even the UML people have some kind of role descriptions nowadays and, related to that work, Kari Kivistö here at our department described in his thesis last year a process model (OOCS) with roles .. but I would think your approach would be quite different (if I understood what you meant with the ecology in first place).

ToniAlatalo


EditText of this page (last edited November 12, 2003) or FindPage with title or text search