Hier finden Sie wissenschaftliche Publikationen aus den Fraunhofer-Instituten.

Implementing support for software processes in a process-centered software engineering environment

: Kobialka, H.-U.

urn:nbn:de:0011-b-731159 (940 KByte PDF)
MD5 Fingerprint: e810939ed65c9e5819971c857a1adc8f
Erstellt am: 31.07.2002

Element named row_ProjectData has starweb_type Output Field Repeater but ID not found in STAR Web Designer.
Sankt Augustin: GMD Forschungszentrum Informationstechnik, 1998, 202 S.
Zugl.: Cottbus, TU, Diss., 1998
GMD research series, 1998,15
ISBN: 3-88457-339-X
Dissertation, Elektronische Publikation
Fraunhofer AIS ( IAIS) ()

This thesis investigates how software processes (i.e. the way how software is developed) can be supported by a process-centered software engineering environment (PSEE). We focus on the implementation of process support and its change during enactment. We present a PSEE offering a set of services and process modeling languages (PMLs) tailored for process implementation and change. Current PMLs have great problems implementing sufficient support for state-of-the-art development processes. Their PSEEs impose a high entry barrier (i.e., the effort for switching to a PSEE is very high), and offer only limited support for incremental change during enactment. There are several reasons for this: Most PMLs and their PSEEs require a complete description of the process in terms of the PML in advance, and restrict all issues which have not been considered. Using today's PMLs, the description of a reasonable process becomes quite voluminous and complex. Size and complexity increase further if the PSEE lacks some basic terms or services, like task hierarchies, agendas, configuration management, or monitoring. Most PMLs stem from general purpose programming or specification languages. Changing of process models during enactment is hard and requires skills which can not be expected from a typical project leader. Processes are applied in an organization in several variations. Existing PSEEs demonstrate their capabilities with a singe process example. Most PSEEs permit instantiation of multiple processes, but cooperation between concurrent processes is only supported on a low level. Our approach consists of a PSEE, called ADDD, which offers a run-time environment for task execution based on an integrated configuration management system. The process engine is based on the event-trigger paradigm. The main issues are the following

- Projects can start using ADDD instantly and model their process support incrementally during enactment.
- Not the entire process has to be specified within the PML, but only those parts which should be supported or
controlled. In principle, developers are not restricted in their work unless explicitly stated otherwise.
- The main focus is on change during enactment. Concepts known from programming languages hindering
change have been excluded. We adopted event-trigger and customization technology. The process can be
driven and constrained by policies associated with tasks, similar to the "Strategy pattern" known from the field
of design patterns.
- Mastering change impact is of major concern. The effect of a policy can be limited to the associated task and ist
subtasks. Therefore, (change of) process support can be restricted to particular tasks according to their needs.

1 Introduction and Overview S.1
- 1.1 Features of Process-centered Software Engineering Environments S.2
- 1.2 Problem Statement S.4
- 1.3 Approach presented in this Thesis S.7
- 1.3.1 Implementation of Process Support differs from Process Modeling S.8
- 1.3.2 Process Implementation requires special Concepts S.8
- 1.4 Overview S.10
2 Process Support during Enactment S.11
- 2.1 What can be expected from Process Support? S.12
- 2.1.1 Process Monitoring S.13
- 2.1.2 Process Guidance S.14
- 2.1.3 Process Automation S.14
- 2.1.4 Process Enforcement S.16
- 2.2 Handling of Process Support S.16
- 2.3 An Overview of some existing PSEEs S.18
- 2.4 A comparative View on PSEE Technology S.31
- 2.4.1 Set up for file-based Software Development S.32
- 2.4.2 Implementation of Process Support S.33
- 2.4.3 Process Enactment S.37
- 2.4.4 Process Change during Enactment S.39
- 2.5 Trends and Open Issues S.41
- 2.5.1 Common Trends in PSEEs S.41
- 2.5.1 a) PSEEs become reactive S.41
- 2.5.1 b) More and more Predefined Process Entities are offered S.42
- 2.5.1 c) Processes become visible S.43
- 2.5.1 d) Dynamic Instantiation eases Process Evolution S.44
- 2.5.2 Open Issues in Process Implementation S.45
- 2.5.2 a) Supporting partial known Processes in an incremental way S.45
- 2.5.2 b) Enabling Change during Process Enactment S.46
- 2.6 Concluding Remarks S.49
3 A PSEE supporting Process Implementation and Change S.51
- 3.1 Basic Concepts and Terminology S.53
- 3.1.1 Task Management S.55
- 3.1.2 Configuration Management S.59
- 3.1.3 Tool Integration S.62
- 3.1.4 Events and Triggers S.63
- 3.2 Describing Process Support in ADDD S.67
- 3.2.1 The ADDD Kernel S.68
- 3.2.2 Definition of Process-specific Artifact Classes S.69
- 3.2.3 Policies S.72
- 3.2.3 a) Customization of System Functionality S.73
- 3.2.3 b) Triggers defined in Policies S.74
- 3.2.3 c) Process Procedures S.78
- 3.2.3 d) Incremental Redefinition of Policies in a Task Hierarchy S.79
- 3.2.4 Checklist Definition S.80
- 3.2.5 User Interfaces S.82
- 3.3 Applying the Concepts of ADDD to Process Support S.84
- 3.4 A Methodology for designing Process Support in ADDD S.88
- 3.5 Process Change during Enactment S.90
- 3.5.1 Changing the State of Enactment S.90
- 3.5.2 Change of Policies S.92
- 3.5.3 Conclusions on Change Impact S.93
- 3.6 Assessment of ADDD according to Section 2.4 S.94
- 3.7 Concluding Remarks S.96
4 Implementation of Process Support S.99
- 4.1 Workflow in the ISPW9 Example S.100
- 4.1.1 User roles S.100
- 4.1.2 Task Structure S.102
- 4.1.3 Automation and Consistency Checking S.103
- 4.2 Traceability in the ISPW9 Example S.106
- 4.2.1 The Information Model S.106
- 4.2.2 Process-specific Views S.108
- 4.3 Support for the ISPW9 Base Scenario S.109
- 4.4 Statistics S.119
- 4.5 Comparison with ISPW9 Support written in other PMLs S.121
- 4.6 Concluding Remarks S.121
5 Evaluation of the Concepts of ADDD S.123
- 5.1 Process Support S.123
- 5.1.1 Dynamically evolving Task-Networks S.124
- 5.1.2 Modeling Process Interfaces S.126
- 5.1.3 Modeling Reactive Process Support S.128
- 5.1.4 Controlling the Effects of multiple Processes S.129
- 5.1.5 Integration with Configuration Management S.130
- 5.2 Understanding Process Descriptions and Change S.131
- 5.2.1 Core Concepts and Abstractions S.131
- 5.2.1 a) Essential Concepts and Abstractions S.132
- 5.2.1 b) Secondary Concepts and Abstractions S.132
- 5.2.2 Modularization and Management of Process Descriptions S.135
- 5.3 Process Change during Enactment S.138
- 5.3.1 Schema Evolution S.138
- 5.3.2 Direct Manipulation of the Enactment State S.139
- 5.3.3 Semantics of Enactment and Change S.139
- 5.3.4 Design for Change S.140
- 5.3.5 Local Process Autonomy S.141
- 5.4 Conclusions S.142
6 Conclusions and Future Trends S.145
- 6.1 Main Features S.145
- 6.2 Enabling Concepts S.147
- 6.3 Lessons learned S.148
- 6.4 Further Evaluation S.149
- 6.5 Future Trends S.150
- Literature S.152
Appendix A: The ISPW9 Example S.163
Appendix B: Supporting the ISPW9 Example in ADDD S.167
Appendix C: Syntax of Policy Triggers S.183
Appendix D: Checkin/Checkout in File Workspaces S.187