Competence Areas
In my past positions in industry and acedemia I built up competencies in the following areas- Software Engineering
- Embedded Systems
- Web Technologies
- Databases
- Project Management
- Requirements Engineering
- State of the practice and process improvement. Read more ...
- How to improve the quality of natural language requirements? Read more ...
- Using Formal Methods. Read more ...
- Component-based Software Development
- The need for logical components. Read more ...
- Selecting commercial-off-the-shelf components. Read more...
- Software Product Lines
- How to test a family of related systems? Read more ...
- How to assess the maturity of industrial practices in product line engineering? Read more ...
- Empirical Software Engineering (SE)
- Technology transfer needs validated SE techniques. Read more ...
Requirements Engineering - State of the Practice and Process Improvement
Little is known about requirements engineering practices in small and medium enterprises (SMEs). I have analyzed the state-of-the practice and problems of an accidental sample of 10 Small and Medium Enterprises (SMEs) observed in a workshop with practitioners from these SMEs. For example, the majority of the participating SMEs (9 out of 10) develop market-driven systems, and a software requirements specification (SRS) does not exist, but just a collection of meeting minutes and presentation slides and later on a user manual. Consequently, these SMEs spend a lot of time on testing, because in order to create test cases the first task of the test personnel is often to elicit the requirements again. Some SMEs try to use the user manual as an SRS, but encounter problems, because it is not detailed enough and exceptions are usually not stated in a user manual. The workshop participants were presented with a set of current requirements engineering principles, techniques, methods, and tools. Important concepts were motivated by small case studies and experiments, which we employed as a vehicle for motivating process changes.
The full study including the practitioner's judgment of RE technologies can be found in: . “Requirements Engineering in Small and Midsize Enterprises: State-of-the-practice, Problems, Solutions, and Technology Transfer.” Requirements Engineering Journal, 3(2):84-90, 1998. Extended version of [Kamsties1998a].
Software engineering improvement methodologies, such as the CMM, methodologies help in the identification of key practices to be improved, but they do not provide guidance on how to improve a specific practice like the specification of software requirements. In contrast, requirements engineering research and practice offers a wide variety of methods and techniques for specific software requirements practices, but little guidance on how and when to establish them within an organization. Barbara Paech and I developed the requirements-specific assessment and improvement method RE-KIT-FRAIME. This method bridges the gap between improvement and requirements practices in two ways. It ties the building-up of requirements practices to an overall improvement method and it gives guidance on how to choose and design a particular practice. We have applied RE-KIT-FRAIME principles in two industrial projects.
The improvement method RE-KIT-FRAIME and the lessons learned are described in: . “Goal-oriented Improvement of Requirements Processes.” In E. Georgiadou; G. King; P. Pouyioutas; M. Ross & G. Staples, editors, Proceedings of the 5th International Conference on Software Process Improvement Research, Education and Training (INSPIRE 2000, London, UK, September 7-8), pages 169-182. Quality Special Interest Group of the British Computer Society, 2000. Download
Requirements Engineering - Improving the Quality of Natural Language Requirements
In industrial requirements engineering (RE), natural language is the most frequently used representation in which to state requirements that are to be met by information technology products or services. Natural language is universal, flexible, widespread, but unfortunately also inherently ambiguous. Ambiguous requirements are a serious problem in software development, because often stakeholders are not even aware that there is an ambiguity. Each gets from reading the requirements an understanding that differs from that of others, without recognizing this difference. Consequently, the software developers design and implement a system that does not behave as intended by the customer. Components fail to interact properly, because the same requirement was allocated to different components, and the different developers of the components have interpreted the requirement differently. These disagreements might result in disastrous software failures.
To my experience, ambiguity is a more complex phenomenon than is often recognized in the literature and practice. Requirements ambiguities caused by simple linguistic ambiguities, such as different readings of a sentence due to prepositional phrase (“The product shall show the weather for the next twenty-four hours.”), do usually not impose problems. In the requirements documents that I have investigated, software engineering ambiguities account for the majority of ambiguities. A software engineering (SE) ambiguity arises from the context of a requirement (i.e., it depends on the reader's background). This context can be subdivided into several domains, for instance theapplication domain , e.g., the organizational environment of the system under specification and the behaviors of external agents. Consider the following requirement about a continuously varying water level in a tank: "Shut off the pumps if the water level remains above 100 meters for more than 4 seconds". At least four interpretations are possible.
A checklist of different types of requirements ambiguities and according examples can be found in: . “Taming Ambiguity in Natural Language Requirements.” In Proceedings of the 13th International Conference on Software & Systems Engineering and their Applications (ICSSEA 2000, Paris, France, December 5-8), volume 2, Centre d'Étude pour la Maîtrise des Systèmes et du Logiciel (CMSL-CNAM), France, 2000. Download
What is the impact of ambiguous requirements on further software development? How many ambiguities can be detected at later stages? What happens to those ambiguities that are not detected? I have performed an empirical study, which indicates that ambiguities are recognized less often, but are resolved unconsciously more often than other types of defects. This is a serious problem, because the contextual knowledge of customers and software developers usually differ. Thus, implicit assumptions are likely to be wrong when a system is complex. A considerable percentage of ambiguities that were not recognized were misinterpreted (30%). That is, ambiguity leads to inconsistencies between code and requirements.
See for more details about the study: . “An Empirical Investigation of Requirements Specification Languages: Detecting Defects while Formalizing Requirements.” In John Krogstie; Ken Siau & Terry Halpin, editors, Information Modeling Methods and Methodologies, pages 125-147. IDEA Book Group, 2005.
The results of this empirical study motivated me to develop new techniques for detecting ambiguities, which are based on inspections (reviews) and scenario-based reading. Ambiguities depend on the context, i.e., an effective technique must be tailored towards a particular application domain.
A generic reading technique for inspecting requirements documents and its tailoring for event-driven systems, is described in: . “Detecting Ambiguities in Requirements Documents Using Inspections.” In Mark Lawford & David L. Parnas, editors, Proceedings of the 1st Workshop on Inspection in Software Engineering (WISE'01, Paris, France, July 23), pages 68-80. Software Quality Research Lab, McMaster University, Canada, 2001. Proceedings available at: http://www.cas.mcmaster.ca/wise/wise01. Download
The effectiveness of tailored reading techniques was shown in a series of controlled experiments: . Surfacing Ambiguity in Natural Language Requirements. PhD Theses in Experimental Software Engineering, volume 5, Fraunhofer IRB Verlag, Stuttgart, 2001. ISBN 978-3-8167-5903-4.
Another strategy to reduce the level of ambiguity is to avoid ambiguity in requirements by avoiding typical ambiguity traps, such as the use of seemingly unambiguous words such as "all", "each", "and", "or", etc.. Even more precision can be reached by using unambiguous sentence patterns when writing requirements.
Dan Berry, M. Krieger, and I have written an 80-page handbook, which is about writing software requirements specifications: . “From Contract Drafting to Software Specification: Linguistic Sources of Ambiguity - A Handbook.” University of Waterloo, Ontario, Canada, November 2003. Version 1.0. Download
A student of Dan Berry and me, Christian Denger, exploited the idea of using sentence patterns in natural language requirements documents in his Master thesis. The focus is on event-driven systems: . “Higher Quality Requirements Specifications through Natural Languages Patterns.” In Proceedings of the IEEE International Conference on Software - Science, Technology & Engineering (SwSTE'03, Hertzeliyah, Israel, November 4-5), pages 80-89. IEEE Computer Society Press, 2003.
Requirements Engineering - Using Formal Methods
Today's competitive pressure among software organizations and society's increasing dependence on software have led to a strengthened focus on software quality. The community not longer tolerates that software is released in the belief that it isn't possible to develop zero-defect software. When considering embedded real-time systems, it must be recognized that not only the company itself but also humans' lives heavily depend on software with certified quality (e.g., imagine defects in safety critical applications like reactor shutdown or air traffic systems).
To assure the high quality of embedded real-time software, various formal methods supporting software development have been published. Cleanroom originally proposed by H.D. Mills allows the development of near-zero-defect software with certifiable quality by using formal techniques, organizational principles, and statistical quality control. The application of Cleanroom has shown remarkable results. So NASA/SEL, IBM, Ericsson, and various other organizations have recognized that not only productivity and product quality can be increased, but effort and failure rates can also be decreased by applying the Cleanroom principles.
Christian Bunse and I identified a number of weaknesses in the early phases of Cleanroom: . “Cleanroom Software Engineering: A Requirements Engineer's View.” In Proceedings of the 3rd International Conference on Cleanroom Software Engineering Practices (IC-CSEP, College Park, Maryland, USA, October 10-11), Q-Labs Inc., USA, 1996.
We described the combination of two industrially proven methods, SCR Requirements and Cleanroom Software Engineering, to form a seamless method for the formal specification and design of real-time systems. SCR documents functional and non-functional requirements such as timing and precision using a tabular notation of mathematical functions. . “Integrating SCR Requirements into Cleanroom Software Engineering.” In Graeme Smith & Q-Labs, editors, Proceedings of the 1st ISEW Cleanroom Workshop (held with ICSE-18, Berlin, Germany, March 25-29), pages 41-52. IEEE Computer Society Press, 1996. Download
Component-based Software Development - The Need for Logical Components
With the general move towards component-based development there is a growing interest in using the UML for modeling components and component-based systems. Although the UML supports the concept of components, the current UML view of components (Version 1.3) is rather limited, focusing exclusively on modeling components as binary modules ("a physical, replaceable part of a system that packages implementation"). Component diagrams are therefore currently used only to describe low-level, implementation artifacts such as source-code, binaries, and executables. Components in the UML are therefore targeted at the level of physical component technologies such as .NET and J2EE/EJB respectively.
In their full generality, however, components can be used to represent large software modules that can constitute systems in their own right. Complex, large grained components of this form cannot adequately be described by a simple box with simple relationships to other components. On the contrary, such components are better regarded as "conventional" systems and described in terms of their own sets of diagrams and models. Using the UML to model all forms of components across the full software lifecycle therefore warrants the application of a consistent set ofmodeling principles backed up by appropriate methodological support.
In the following book chapter, we identify the four core modeling principles which characterize component based development at the model level, and describe how they relate to well known foundations of software engineering: . “Principles of UML-Based Component Modeling.” In Sergio de Cesare; Mark Lycett & Robert Macredie, editors, Development of Component-Based Information Systems, pages 70-85. M.E. Sharpe Inc., 2005.
The KobrA method, developed at Fraunhofer IESE, represents a synthesis of well-known software engineering technologies, including product line development, component-based development, requirements engineering, and quality modeling. Thus, the method is aimed at providing a systematic approach to the development of high-quality, component-based frameworks and applications.
The KobrA method is described in: . Component-Based Product Line Engineering with UML. Addison-Wesley, 2001. ISBN 978-0-201-73791-2.
Component-based Software Development - Component Selection
Software reuse is one approach to face today's competition in software industry. Several component reuse strategies can be distinguished, buying a commercial off-the-shelf (COTS) component, mining existing assets, and commissioning. We have developed an approach for selecting a COTS component, which is primarily geared towards software product lines (see below), but can be used also for single system development. Similar to component development, component selection must be guided by a systematic process in order to make sure that the identified component really fits into its context, i.e., fulfills functional and quality expectations, is compatible to the overall architecture, and satisfies a wide range of organizational issues, such as the trustworthiness of the manufacturer in case of a COTS component.
COTS selection from the requirements' perspective is described in: . “Anforderungsbasierte Selektion von COTS-Komponenten.” In Günter Böckle; Peter Knauber; Klaus Pohl & Klaus Schmid, editors, Produktfamilien - Methoden, Einführung und Praxis, chapter 8, pages 93-108. d.punkt, Heidelberg, 2004.
COTS selection from an architectural point of view is described in: . “Considering Variability in a System Family's Architecture During COTS Evaluation.” In Xavier Franch & Daniel Port, editors, Proceedings of the 5th International Conference on COTS-Based Software Systems (ICCBSS 2005, Bilbao, Spain, February 7-11), Lecture Notes in Computer Science, volume 3412, pages 223-235. Springer, 2005.
Software Product Lines - How to Test a Family of Related Systems?
Software product line engineering (PLE) is an emerging discipline. Industrial experience has shown that many systems we see today, such as mobile phones or electronic control units in cars, can be developed more efficiently using a PLE approach. A product line is defined as "a set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way".PLE is the pro-active, constructive reuse of assets for customer specific products, with the aim to increase product quality and at the same time to decrease development effort and cost.
PLE has two main distinguishing features compared to single system development: (1) separation of two development processes, domain and application engineering, and (2) the explicit modeling of the variability of the product line. In domain engineering, the commonality and the variability of the product family are defined and a common architecture is developed. Shared assets are implemented so that the commonality can be exploited during application engineering. During application engineering, individual, customer-specific software products are being developed by selecting, configuring, and adapting these shared assets. Variability is the ability of an asset to be adaptable; it allows individualizing shared assets to specific needs.
An introduction into software product lines can be found in: . “Einleitung.” In Günter Böckle; Peter Knauber; Klaus Pohl & Klaus Schmid, editors, Produktfamilien - Methoden, Einführung und Praxis, chapter 1, pages 3-11. d.punkt, Heidelberg, 2004. Download
Because of these new features, PLE requires a complete new bunch of techniques for all phases of software development. Testing a product line is particularly difficult, because the variation points in the product line assets introduce another magnitude of complexity to the possible behaviors to be tested in domain engineering. Testing each application separately in application engineering is often too expensive.
I have proposed a new, reuse-oriented approach to product line testing: . “Testing Variabilities in Use Case Models.” In Frank van der Linden, editors, Proceedings of the 5th International Workshop on Product Family Engineering (PFE-5, Siena, Italy, November 4-6), Lecture Notes in Computer Science, volume 3014, pages 6-18. Springer, 2003.
We developed a complete technique for product line testing, which bases on the above-mentioned approach: . “Anforderungsbasiertes Testen.” In Günter Böckle; Peter Knauber; Klaus Pohl & Klaus Schmid, editors, Produktfamilien - Methoden, Einführung und Praxis, chapter 10, pages 119-136. d.punkt, Heidelberg, 2004.
The technique for product line testing was successfully introduced at Siemens Medical Systems for testing a product line of radiology systems : . “Test von Software-Produktvarianten - ein Erfahrungsbericht.” In H.H. Adelsberger; S. Eicker; H. Krcmar & others, editors, Tagungsband der Multikonferenz Wirtschaftsinformatik (MKWI 2004, 10. März Essen), volume 1, Akademische Verlagsgesellschaft aka, Berlin, 2004.
Software Product Lines - How to Assess the Maturity of Industrial Practices in Product Line Engineering?
Software product line engineering (for an introduction read more...) also requires a new capability evaluation model, because the available models, such as the CMMI, do not consider the specific PFE characteristics and their organization and business implications. In cooperation with Philips and Nokia, we have developed an evaluation framework for family development. The framework serves for benchmarking the organization against others, enables assessments for single organizations, and provides directions for improvement. As there are 4 groups of development concerns (BAPO = Business, Architecture, Process, Organization) we have identified 4 distinct evaluation scales. Evaluation of an organization will lead to a profile with separate values for each of the 4 scales. Dependent on the organization context there will be an optimum profile for that organization. The organization may use the framework to find whether it has the optimum profile, or if not which actions should be done in order to reach the optimum.
The evaluation model for product lines is described in: . “Software Product Family Evaluation.” In Robert Nord, editors, Proceedings of the 3rd International Software Product Line Conference (SPLC-3, Boston, MA, USA, August 30 - September 2), Lecture Notes in Computer Science, volume 3154, pages 110-129. Springer, 2004.
Empirical Software Engineering (SE) - Technology Transfer Needs Validated SE Techniques
The transfer of software engineering technology to industry is plagued with many problems, which can be attributed to some degree to the lack of empirical evidence. First, new technologies are often rejected by project personnel, since these are considered not well adapted to project needs and, thus, are perceived as not beneficial. Second, new technologies are bypassed under project pressure since project personnel are not convinced enough of the benefits and project management does not support technologies. Third, past project experiences are not reused in new projects because benefits were not demonstrated explicitly and, thus, religious beliefs win.
Experiments can be performed for scientific learning, teaching, training, or technology/process evaluation and optimization purposes. The degree of control over independent variables decides whether a controlled experiment or a case study is appropriate. A controlled experiment requires high level, and low difficulty of control, a case study must be performed otherwise. This decision has also an impact on the style of data gained and the type of statistical analysis. Controlled experiments are better in establishing causal relationships, while the conclusions from case studies are limited to the particular conditions of the study.
Chris Lott and I developed and conducted a controlled experiment to convince students of the principle of early quality assurance. That is, to use code reading for defect-detection rather than relying entirely on black-box and white-box testing: . “An Empirical Evaluation of Three Defect-Detection Techniques.” In Wilhelm Schäfer & Pere Botella, editors, Proceedings of the 5th European Software Engineering Conference (ESEC'95, Sitges, Spain, September 25-28), Lecture Notes in Computer Science, volume 989, pages 362-383. Springer, 1995.
The technical report contains most of the experiment materials: . “An Empirical Evaluation of Three Defect-Detection Techniques.” ISERN 95-02, Department of Computer Science, University of Kaiserslautern, Germany, May 1995. Contains experiment materials; available from ISERN. Download. The replication package is available from the authors.
It is a common belief in requirements engineering that requirements should describe only the externally visible behavior of a software system. However, when it comes to requirements modeling, notations such as UML often suggest describing the behavior of a software system through the behavior of its constituting components. I designed and conducted a controlled experiment in which we investigate the impact of specification styles (black-box and white-box) on the understandability of the requirements specifications from the customer's viewpoint: . “A Controlled Experiment to Evaluate How Styles Affect the Understandability of Requirements Specifications.” Information and Software Technology, 45(14):955-965, November 2003. The experiment package is available from the authors.
and