 |
|
|
Enhanced Glossary on Software Process Technologies |
|
Enhanced Glossary on Software Process Technologies
(Brussels, 03/June/2002)
A-B-C-D-E-F-G-H-I-J-K-L-M-N-O-P-Q-R-S-T-U-V-W-X-Y-Z
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
- The variety of research areas that are simultaneously applying similar notions of process technologies but with different purposes, focuses and backgrounds. Although there is no official classification of the research areas applying process technologies, the surveys carried out by Totland and Conradi /Totland, 1995/ and Osterweil /Osterweil, 1999/ provide some structure. Totland and Conradi identified and classified 8 research areas applying process modeling technologies while Osterweil proposed 5 different process-specific domains relevant to process modeling formalisms. Both studies analyze the common issues among the different research groups. Independent of the exact number of research areas, it is a fact that for many years a diversity of well established communities have separately developed different vocabularies and are now working from different assumptions. Thus it seems unrealistic to establish a common platform to start redefining a unique consensual standard terminology.
- The dynamics of research and technology. Innovations in software process technologies are occurring with greater frequency. Evolution is an inherent feature which produces not only improvement in process technologies but also progress in its terminology. Nowadays, the dynamics and speed with which new terms are created, refined, modified and become outdated make it difficult to maintain an up-to-date collective terminology.
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":
- Year: The definitions in the "glossary" are ordered by year of publication of the source.
- Reference: Each definition has a link to the details of the reference of the publication with more information about the author, place of publication, etc.
- Whenever the text of a definition employs a term which is already included in the glossary, this term is presented with an active link to the user.
- Rationales: All the comments and indexes for a better clarification of a term which are done by "GDPA" and are not described in the original sources, are presented in the field "Rationales".
- Other Languages: Some terms have their equivalent names in German with an active link to the page with the description in German of the term. Please note that this equivalency is not absolute. Just as different authors define different meanings for the same term in the same language, there are also different meaning between the terms in different languages.
- Related terms in the glossary:
- Publications on this area:
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