Enhanced Glossary on Software Process Technologies  

The pencil for writing the Glossary

Enhanced Glossary on Software Process Technologies

(Brussels, 03/June/2002)

The software process area started as an autonomous discipline in the 1980's /Fuggetta, 2000/ reaching a vast growth of popularity in the 1990's. The significant number of workshops (ISPW, GI 5.1.1), conferences (ICSP, PROFES, EUROSPI) books (/Finkelstein, 1994/, /Garg, 1996/, /Derniame, 1998/, /El Eman, 1999/), tools/methodologies (CMM DSDM, FUSION, in-Step, Innovator, ProcessWise,VM-Tailor) and standards (ISO 12207, NATO AQAP-150, V-MODEL) devoted to process technologies which appeared in the last decade are an indicative of this. Albeit this number has decreased in the last months, process has conquered a essential and critical role in the software development. Precisely now, that the euphoria fades away and the community's attention is replaced by another vision, is time to decant the innovations and reasoning about them.

So far, there are plenty of publications reporting empirical studies on process technologies. Most of them are projects grown out of research work struggling for a place in the industrial and commercial setting, each one making its own claim of superiority. Indeed, the amount of factors to observe in process technologies is so burdensome that each claim is valid for the particular domain where it exerts influence. The first difficulty faced by engineers during the selection of the most appropriate technology for the specific needs of the project is where to find information about all these factors.

A Clear Conceptual and Terminological Framework

/Lonchamp, 1993/ GDPA....

The debate is lively. For instance, some papers relate success histories of companies ascending in the CMM scale /xxx, xxx, xxx/, but the company who gained the award for best quality product was classified in the lowest level of this scale /xxx/. What is correct, what is myth?

Back to the roots of the term

Consider, for example, the mythical waterfall model. Over and over again there are publications referring to the waterfall as an outdated model for not supporting software evolution. Frequently, they make the analogy with nature's waterfall: as the water falls down and never climbs up again, each phase of the software development should be performed once and then succeed to the next step without ever returning to a previous phase. Today we know that software development is not a straight-forward one-pass process of system development. Normally, it is necessary to go back to a previous phase and rework portions of the software artifacts. Whether the cause for returning on the process lays on the need to correct an error or a "natural evolution" described in Lehman's laws of evolution, the fact is that the simplistic view of software development which was imputed to the waterfall model makes it inoperative.

Surprisingly, the paper of Royce in 1970, which was the craddle of the waterfall model, described up-to-date concepts as prototyping and feedback loops. Actually, he didn't mentioned these words to refer to this concepts, but he envisaged the idea for applying them. His model was later known as "waterfall model" because of the appearance of the diagrams for representing the software development phases which looked like stones in a waterfall. James Moore /Moore, 1998/ alludes the defamation of the model by blaming the name associated to the model and emphasizing how important it is to find the correct word. He further comments that it might also have been convenient and appealing to the managers the use of the waterfall as a straightforward model where you "get it right the first time": controllable projects, great programmers, and it was easy to draw the complete model in one sheet only.

There is no evidence that the "waterfall myth" created to Royce's model was a conscious manipulation of the model to fit managers purposes. Probably, one of the causes for this repeatedly disregard to the original model for decades was due to the fact that the original paper was not easily accessible. At time when it was published, the common media for diffusion of innovation was slow comparing to the actual state of technology and was mostly paper-based. Managers were satisfied by reading and hearing about the waterfall model from mediators. It brought enough novelty to the usual try and error programming style. Besides that, it was extremely difficult to find out who invented this model and get details about its publication. Rather than defending the waterfall model, the intention of this document is to confirm the importance of having an accessible version the original definition of each term, not necessarily the original document, a transcription from the original definition suffices.

  • establish a solid basis for discussion and evolvement.
  • where to find the original definitions?
  • which one is the original definition?

    Different definitions for each term

    However, not only the original texts are sufficient for a comprehensive understanding of the concept. The redefinition of the term over time helps recapitulating the concept with a different perspective adding comparisons and enhancements to the present state. The terminology is not static and it progresses to accompany technology.

    Each term is presented in GDPA with the original text from different publications which are from significant relevance in the respective field of the term. The aim is to provide the authors varied points of views for each term. Some authors describe the same definition for a term with slight nuances, others employ different terms for the same description (similarity), and others use the same term with different meanings (overloading).

  • redefinition - clarification efforts

    Framework coverage

  • define the domain
  • intersecction with other areas - where to establish the limits
  • information is scattered The "glossary" in GDPA contains more than 1000 definitions on process technology. It encompasses a wide spectrum of technical terms: from the initial vocabulary of the 50's and 60's, followed by the classical terminology of the 70's and 80's until the trend jargons of the actuality.

    No consensus on the terminology?

    A consensus on the terminology and taxonomy of process technologies would significantly contribute to a better communication and understanding among the different research and interest groups. However, it may not be appropriate at the actual state of discourse due to the following main reasons:

  • the complexity of process technologies
  • the coexistence of several attitudes of mind and objectives /Lonchamp, 1993/
  • the evolution of the technology
  • the improvement of the know-how
  • the influence of related research areas
  • the unawareness of similar work

    Past efforts

    The idea of providing a framework for establishing a basis to clarify concepts and terminology on process technologies instead of defining a universal terminology is not novel /Conradi, 1992a/, /Feiler, 1993/. Nevertheless, most efforts tend to redefine concepts and terms incorporating recent trends rather than effectively reusing and comparing them.

    An accurate and pragmatic comparison is not a trivial task. It requires an extensive inspection of the definitions. Usually, each community has its own set of concepts and definitions, which is described by referencing other terms in a nested and recursive way. Thus, for understanding the meaning of one term, it is necessary to read and assimilate the meaning of all nested terms.

    GDPA endeavour

    * Provide a wide view
    * Information is scattered
    * Importance of the original definitions
    * Comments in the field "Rationales" rather than redefining the term
    * links to further publications for clarifying and deeper study on the terminology

    GDPA web page format

    The definitions in the "glossary": The "glossary" in GDPA is intended for use in academical research and teaching. No copy is allowed. Please see license conditions

    Undoubtedly, there are different positions about process technologies. Some practitioners criticise it on the grounds that it hampers progress and creativity. In the other extrem to this position, the firm adherents to the technology, seek out to detail the process almost to the level of software development automation, letting indeed no free space for originality. The majority see the software process as a medium for coordination and improvement. And finally, the late adopters, who are waiting for the results to evaluate the benefits before starting the implementation. The controversy is fierce, but in general the feedback is positive. The software process community is convinced that there is a direct relation between the quality of the software process and the quality of the developed software. But to what extend? At time of writing this document, there is no wide-known formula that express this relation.

    This page online  •  GDPA Online  •  Last Updated 27.June.2002 by C. Freericks