An ontology for software development methodologies and endeavours
- Publication Type:
- Chapter
- Citation:
- Ontologies for Software Engineering and Software Technology, 2006, pp. 123 - 151
- Issue Date:
- 2006-12-01
Closed Access
| Filename | Description | Size | |||
|---|---|---|---|---|---|
| 2006005069OK.pdf | 330.4 kB |
Copyright Clearance Process
- Recently Added
- In Progress
- Closed Access
This item is closed access and not available.
Software development is a complex activity that usually involves people, organisations and technologies with very diverse characteristics. People's expectations and skills vary greatly; organisations' capability and financial constraints are diverse; and technologies keep changing and breaking through at an increasing pace. In such a context, the successful construction of a piece of software that adds value to all involved stakeholders proves difficult. As in any other complex enterprise, lack of a common vocabulary and, more generally, a common worldview, are major causes of misunderstanding and cross-talking, which, in turn, easily lead to unfulfilled expectations and stakeholder disappointment. Nowadays, software controls life-critical as well as mundane devices, from lifts to aeroplanes to telephone exchanges. In this regard, unfulfilled expectations in a piece of software usually mean faulty functionality, decreased robustness or reliability, or some other manifestation of weakened quality. For this reason, utilising a common set of concepts, as well as a common set of terms to refer to these concepts, is crucial for the development of high-quality software. It can be argued that fewer misunderstandings and misinterpretations will arise in any communication process when the involved parties use an agreed-upon, well-defined conceptual base. For the sake of common sense, this common conceptual base, or ontology, must have the following properties: It must be complete, so that no area of software development lacks coverage. It must be unambiguous, so that misinterpretations are avoided. It must be taken from the appropriate domain, so that concepts are familiar and intuitive to their users. It must be as generic as possible, so that different usages in different contexts are possible. It must be extensible, so that new concepts can be added to it without breaking the existing ones. Completeness can be achieved by looking at the different activities performed within software development enterprises, and by ensuring that the ontology covers all of them. Ambiguity can be avoided by providing simple and concise definitions for each concept, as well as a semi-formal model of the complete ontology. This semi-formal model is, in our case, an object-oriented class model that shows the structure of the ontology. Intuitiveness can be obtained by looking at the different communities that participate in software development enterprises and by providing a conceptual subset particularly adapted for each of them. For example, a computer programmer does not use the same concepts as a project manager. Genericity can be attained by keeping the ontology as small and as simple as possible, and by trying to remove from it, rather than add to it, as many concepts as possible. The aim is to achieve maximum expressiveness by being minimal. Finally, the ontology can be made extensible by providing the appropriate mechanisms and anchor points from which to add new concepts. In our case, the mechanism is strongly based in standard objectoriented mechanisms such as subtyping. Many authors and efforts have proposed metamodels or frameworks that partially define ontologies for software development. For example, the popular UML [21, 22] defines the concepts that a software developer may use in order to describe a system (such as Class, Attribute and Operation). Standards such as ISO/IEC 12207 [14] and 15288 [15] describe the process that software developers may follow in order to design and build a system and, in doing so, make use of an implicitly defined set of concepts (such as Process and Outcome). OPEN [6] and SPEM [23] specify the relevant concepts that may be used in order to describe a process to be followed by software developers (such as Activity and Iteration). ISO/IEC 15504 [16] and CMMI [27] define the relevant concepts to perform capability or maturity assessment (such as Process and Task). Each of these approaches defines a cohesive set of concepts that, although useful in its local domain, is not complete, unambiguous, intuitive, generic and extensible enough as to qualify as an ontology for software development. This chapter introduces an ontology for software development that exhibits all the above-mentioned properties, and which has been constructed by taking the best bits of the above-mentioned standards and organising them into a completely new architecture. This ontology contains a metamodel plus the necessary architectural infrastructure to enable method engineers and software developers to successfully interact with a common conceptual framework. © 2006 Springer-Verlag Berlin Heidelberg.
Please use this identifier to cite or link to this item: