-At present, software development in the automotive industry is characterized by frequent changes caused by new innovations, fast-growing system complexity, growing software portion in cars, changing business relationships. This dynamical environment demands for flexible software processes. In order to improve a software development process with respect to flexibility, it is necessary to characterize what kind of flexibility is required. Therefore, we defined a set of requirements for desired processes based on our process analysis in DaimlerChrys-ler's engineering departments and analysis of related contributions proposed in the literature. Based on this requirement the existed processes can be analyzed to identify its improvement potential. The application of the requirements is illustrated in the context of a case study.
——————————
Na highly dynamic environment which is chara cterized owadays, the automotive industry is confronted with by frequent changes due to innovations, business relationships or new product structures. One of the reasons for this trend is the fact that software has come to play a more and more important role in the automotive industry and will be the major source of innovation in the future. As software is a relatively new science, the corresponding new effective and efficient processes for software development which consider the mechanical and electrical engineering domains are needed. Especially important in such dynamic environments is flexibility: software engineers desire flex ible software development processes in order to be able to quickly react to the changes in the development environment.
The problem is that the processes proposed for development of large, complex, and safety-critical software are not flexible enough for our ever-changing environment. For example, last year our prescriptive issue tracking process was changed significantly three times. The reasons for the changes were newly gained knowledge during the application of the “old” process and the need for three departments to work together collaboratively.
The research question arising from the problem is basic: What should a flexible software development process look like? In order to define a flexible software development process, the requirements as to the process flexibility are first needed. These requirements should be defined in such ———————————————— a way as to be measurable enabling a systematic evaluation of the process flexibility. Consequently, a suitable support for the definition and evaluation of the process flexibility is called for.
In this paper, such a support is presented. It consists of an emergent knowledge base and a flexibility definition process. The emergent knowledge base provides generic knowledge related to the definition and evaluation of the process flexibility. The flexibility definition process defines the steps to be performed in order to define the process flexibility for a specific software development process.
The benefit of our approach is support, first, through the definition and evaluation of the process flexibility and, second, through the identification of process weaknesses and improvement potentials with respect to process flexibility.
This paper sets out both the emergent knowledge base and the flexibility definition process and introduces a case study for validation. It therefore targets project managers, software engineers, and process quality assurance staff who are interested in defining or evaluating process flexibility.
The remainder of the paper is structured as follows. Chapter 2 discusses related work. Chapter 3 defines the objectives of our research work. Chapter 4 presents our approach, viz. the support for the definition and the evaluation of process flexibility. In Chapter 5 our approach is illustrated by means of a case study. Finally, Chapter 6 summarizes the most important contributions of the paper and addresses future work. 2
ess. One is to employ a process assessment sta ndard such as SPICE [5][6]. Another way is the application of a defineyour-own-model approach such as the GQM measurement method [9].
The process assessment standards [5], [6], [8] characterize processes based on a reference model. This reference model typically defines the process capability levels and We aim to achieve the second goal with our learning the criteria that have to be fulfilled for a considered level. support: our objective is to be able to effectively and effiThe process assessments are then performed on the basis of ciently define and evaluate process flexibility in a measurthe criteria. The advantage of the standards lies in the fact able way. “Effective” means that the measurement program that they define the necessary criteria to be fulfilled in order covers all the aspects that are important for process flexibilto develop a product of the desired quality. The weak point ity from the project stakeholders’ point of view. “Efficient” of the standards considered is that they provide neither an means that the effort required for the definition of process explicit definition for process flexibility nor the criteria or flexibility should be as minimal as possible. We firmly bemetrics for the evaluation of process flexibility. lieve that reuse of the available knowledge and experience
To define process flexibility in a measurable way, a would contribute to a more effective and efficient evaluameasurement approach can be applied. As different con- tion of process flexibility. texts have different understandings of the process flexibil- We aim to achieve the third goal to make it clear how the ity, a define-your-own-model approach should be applied knowledge provided in the emergent knowledge base can [2]. The representative for define-your-own approaches is be reused for the definition and evaluation of a concrete the GQM method. project.
The GQM method is a goal-oriented measurement The benefit of our approach is a support for software enmethod according to which a measurement goal should be gineers, first, through the definition of requirements placed refined into metrics via questions. The advantage of the on process flexibility and, second, through the evaluation of GQM approach is that it allows the context and the project process flexibility. stakeholders’ views of the process flexibility to be considered. The key drawback of the method, however, is that it 4 LEARNING SUPPORT FOR THE EVALUATION OF calls for comprehensive knowledge and experience from measurement personnel. Unfortunately, a lot of companies PROCESS FLEXIBILITY do not have the experts with the necessary knowledge and experience. 4.1 The Informal Definition of Process Flexibility
The missing knowledge and experience needed to define Process flexibility is defined as the ability of a process to be and evaluate process flexibility can be gained by learning easily and quickly adaptable to a new situation. A new situation from past knowledge and experience. Several approaches can be caused through an innovation, a new business confor supporting the learning process have been proposed in nection, changes in product structure, or other factors. the area of artificial intelligence. For example, deriving a In order to make this key definition clear, the history of a process model based on logging of the activities of the peo- process, called issue tracking, is considered. The issue ple involved in the process [4] is one such method. These tracking process targets capturing of issues such as changes approaches address more the implementation aspect of in the product requirements, faults in the realization of the learning; yet before addressing the implementation aspect requirements or a decision to realize a specific feature earof process flexibility by learning, concrete requirements for lier than planned. Figure 1 illustrates the issue tracking process flexibility are needed. If process flexibility is to be process with respect to its four different phases. The procevaluated systematically, it needs to be measurable. There- ess is considered to be in another phase, if any process fore we aim at supporting a measurable definition and the changes are occurred. In the first phase, the issue tracking systematic evaluation of process flexibility by defining and process is described by two statuses “issue open” (i.e., a providing the following: new issue that needs to be remedied is identified) and “is• The generic knowledge related to the process flexibil- sue closed” (i.e. the issue has been remedied).
ity definition and evaluation. During the application of the issue tracking process • A process for the usage of the knowledge provided. (phase 1) for tracking the issues arising during the software development of an electrical device, for example, new experience is gained. Based on this experience, the issue track3 THE G OALS ing process is refined. The following steps are added: analyse an issue, confer with an expert, evaluate an issue, refuse the correction of the issue, assign the issue to a person responsible for it, remedy the issue, and verify the correction.
During the application of the issue tracking process in accordance with phase 2, the following modifications were found to be needed:
The assign step is modified: in this step not only the assignment of an issue to a responsible person is to be performed. Additionally, whether the issue is a software issue, a mechanical issue, or a hydraulic issue should be defined.
The goals of our proposed concept are threefold: • To define the term “process flexibility” informally. • To organize generic knowledge and experience related to the definition and evaluation of the process flexibility in the emergent knowledge base. • To define a process for the use of the emergent knowl
edge base.
We aim to achieve the first goal with our learning support, since the term “process flexibility” is not at all explicitly defined in the process assessment standards considered; however the industry needs such support for the definition and evaluation of process flexibility.
The process in the third phase shows the modifications. The emergence of the issue tracking process (phase 4) is caused by a need for inter-departmental collaborative working. To achieve a consistent process, an additional process step, confer, is first added and a transition from the assign* step to the close step is then omitted.
Referring to this example, process flexibility can be informally characterized by the ease to quickly • identify the need for a process modification. • understand what kind of process modification is needed.
• perform a required process modification.
1 The purpose and the content of the figure will be explained later.
In order to support the identification, the causes for the
process modification are analysed. As an input for the
identification of change drivers, the Aalst et al. autonomy of the
workflow change [
The modification encompasses the introduction of roles who initiate the process modification. The case study is performed in the context of the issue tracking process. Figure 2 indicates that our autonomy of changes distinguishes between the following change driving factors: market, software development legislation, new knowledge, technical experience, errors made during software development, and system failures.
These drivers are introduced by the roles: marketing department, client, customer, project manager, researcher, cooperation partner, development team or the system platform.
Based on the knowledge taken from Figure 2, six issue classes are distinguished: Issue class 1: issues caused through availability of new knowledge, experience or laws (initiated by researchers or developers).
Issue class 2: issues caused through a change in the internal organizational structure (initiated by the project manager).
Issue class 3: issues caused through a change in the external organizational structure (initiated by cooperation partners or by the project manager).
Issue class 4: issues caused through an incorrect implementation of the requirements from the product concept catalog (initiated by a product developer).
Issue class 5: issues caused through a change in product requirements (initiated by a customer/client or a marketing team).
Issue class 6: issues caused through system failures (initiated by the system platform).
The issue classes identified here are not to be seen as a silver bullet but as an emergent shopping list for the identification of the relevant process-specific issue classes. “Emergent” means that this set should be updated in line with the newly acquired knowledge and the experience gained from its application. Both the autonomy of the change drivers and the issue classes are intended to first help to quickly identify a need for a process modification provement of software development processes to achieve (e.g. by process monitoring with respect to relevant issue enhanced product quality. Nevertheless, improvement of classes). Second, the knowledge helps to define the issue software development processes with respect to flexibility classes that a given process should be especially flexible for. is a pivotal aspect, especially in such dynamic environments as we are faced with today. Unfortunately, such Understanding the Type of the Process Modification standards do not define the criteria or metrics for the In order to understand what kind of process modifications evaluation of the process flexibility. are needed, the software development process at hand It is for this reason that the GQM method [9] is applied for should be understandable for people involved in the proc- this purpose. We decided to utilize the GQM method, as it ess. This means, for example, that everybody should be able is a widely used measurement method that allows a goalto evaluate which activities have been carried out, which oriented identification of the desired criteria and metrics for ones are to be performed next, who should do which activi- process flexibility. To derive the desired criteria and metties, when the activities to be performed should be started, rics, the following activities are performed: and what kinds of resources are needed to perform the ac- The GQM goal is described with respect to its attributes tivities. (object: process, purpose: to define and to evaluate, focus: process flexibility, viewpoint: researcher, developer, manCarrying out the Process Modification ager, context: software development). Looking back at our issue tracking example (Fig. 1), we Based on the knowledge presented in Section 4.1 and focusnote that the modification is performed through executing ing on the GQM goal, the process flexibility is described by one or several of the following modification activities : four high-level questions. Then different aspects of each of 1. Removing an existing process step. the four questions are described by sub-questions. The 2. Adding a new process step. modification activities, autonomy of the drivers, and the 3. Modifying an existing process step. issue classes presented in Section 4.1 are taken into account 4. Changing the order of the process steps. in doing so with the focus on the GQM goal. This “decom5. Removing a transition between two process steps. position” (i.e. refinement of different aspects of the high 6. Adding a new transition. level question through sub-questions) is performed until Consequently, a flexible process is characterized by ease questions that are not concrete enough from our point of and speed of performance of modification activities. view are derived. The defined questions are the desired criteria. 4.2 Emergence Knowledge Base Finally, the metrics are assigned to the “concrete enough” questions. Metrics propose a scale for “answering” the In order to define and evaluate process flexibility system- questions. We proposed both qualitative and quantitative atically, it is important to understand four aspects: metrics. 1. The changes that can cause the process modifica- In this way, all the criteria and the metrics were defined.
tion. The proposed set of criteria and metric is a generic, reus2. The changes to which the process should be espe- able set. The approach for the reusage of the set will be discially sensitive. cussed later. 3. What the relevant stakeholders understand by a Organizing the Knowledge in the Knowledge Base flexible software development process (i.e. what are the criteria and metrics for the evaluation of the The knowledge and experience gained during the analyprocess flexibility). sis is stored in the emergent base with respect to the scheme 4. The constraints that are to be fulfilled (e.g. quality depicted in Figure 4. The scheme is adapted from the deassurance, documentation, product preparation). fine-your-own-model, the so-called SQUID model [7]. The SQUID model is employed, since it supports top-down deThe fourth aspect is essential as process flexibility is desired composition as defined by the GQM method. Figure 3 but may not negatively affect the product quality. There are shows that each criterion can either be decomposed in subprocess steps that have to be performed for this. The focus criteria that describe different aspects of the criterion in of the paper is, however, on the first three aspects. Conse- more detail or be made measurable through assignment of quently, the emergent knowledge base should provide the a measurement model. Each criterion is captured in the issue classes, the criteria and the metrics for the measurable emergent knowledge base as shown in Table 1. definition and evaluation of process flexibility, and the relevance of the criteria with respect to the issue classes. To achieve this knowledge, the criteria and metrics for the process flexibility are to be defined.
A set of criteria and metrics that might be relevant for the definition and evaluation of the process flexibility is needed. Before defining the desired set, existing process assessment standards [5], [6], [8] are considered. This is done because process assessment standards aim at the imFig. 3. Schema of the Emergent Knowledge Base
TABLE 1 EXERPT FROM THE EMERGENT KNOWLEDGE BASE The table indicates that each criterion in the emergent base is characterized by the reference to the father question. 4.3 Using the Emergent Knowledge Base
The emergent knowledge base provides the issue classes, criteria, and metrics for the definition and evaluation of process flexibility. In order to keep the contents of the emergent base up to date, it should continually be evaluated and updated. Consequently, the corresponding processes are needed. The focus of the paper is, however, the process flexibility definition process.
The objective of the process is to select and identify suitable criteria and measures for a given software development process by reusing the knowledge from the emergent knowledge base. An overview of the process is set out in Fig. 4. In the first process step, the relevant issue classes from the knowledge base are to be selected and the missing issue classes identified for a given specific software development process are to be identified.
The task of the second process step is to evaluate the issue classes for which the process should be especially flex ible. The evaluation is to be performed by all relevant process stakeholders (e.g. software developers, process quality assurance staff, etc.). The importance of the issue classes should be evaluated on the basis of the four-point scale: very important, important, somewhat important, and not important at all. Before evaluating the issue classes, the project stakeholders should understand which effect the representatives of the issue classes have and how often the changes occur.
In the third step, the appropriate criteria and metrics for the definition of the process flexibility are to be selected and identified. Which criteria are relevant for a given software development process is to be decided contingent on the importance of the issue classes. The relevant criteria and metrics are to be selected from the emergent base. The missing criteria can be identified in a top-down manner by application of the GQM method.
In the fourth step, a process flexibility model is to be produced. This should be done by first deleting the criteria and metrics not relevant for a given software development process from the decomposition tree. Second, the identified missing criteria and metrics have to be inserted into the decomposition tree with respect to the decomposition structure. Third, by specifying the criteria in the context of a given process. Finally, the relevance of missing criterion and metrics is to be evaluated on the same scale. The evaluation has to take the importance of the issue classes into account.
5.1 Application of Our Approach
As cited in the history of the sisue tracking process, the knowledge and experience we gain from the definition of issue tracking process lets us identify the following drivers for a process modification: 1. New experience, knowledge. 2. A change in the internal organizational structure. 3. A change in the external organizational structure. Consequently, when referring to the generic issue classes, the following issue classes are identified as issue tracking specific: Issue class 1: issues caused through availability of new knowledge or experience (initiated by developers). Issue class 2: issues caused through a change in the internal organizational structure (initiated by the project manager or developers).
Issue class 3: issues caused through a change in the external organizational structure (initiated by cooperation partners or by the project manager).
Based on the history of the issue tracking process, it is assumed that the issues from the first issue class have the greatest impact and the highest likelihood of occurrence.
The effects of the second and third issue classes are assumed to be relatively small, because, for example, due to the wish to cooperate with each other the cooperation partners usually try to achieve a consistent process with as few process modifications as possible. The occurrence likelihood for the issues from the second and third issue classes is low, as a rule. Therefore the second and third issue classes are evaluated as somewhat relevant.
Consequently, the issue tracking process should be especially flexible with respect to the newly gained knowledge and experience.
First, the relevance of the criteria and metrics provided by the emergent knowledge base is evaluated based on the scale very relevant, relevant, somewhat relevant, and not relevant at all. Second, the missing criteria and metrics are identified by application of the GQM approach in a manner similar to that set out in Section 4.2 for the context issue tracking process. The criteria and metrics provided in the emergent knowledge base serve as a support.
The process specific flexibility model is defined by • omitting criteria evaluated as non -relevant from the decomposition tree. For example, the criterion “Does the process have a high level of information hiding? (i.e., only the absolutely necessary information produced during a process step should be passed on)” is removed. The criterion is not relevant because, in the issue tracking process, the people involved in the process should be able to see the information of interest to them even if they do not necessarily have anything to do with the information. • adding missing criteria and metrics in the decomp osition tree with respect to its relationships to other tree criteria. For example, the criterion “How easy it is to quickly identify the risk and attractiveness of the implementation of a considered issue?“ is identified as missing and is, therefore, added in the decomposition tree. • specifying the criteria and metrics in the context of the issue tracking process, for example, the specification of the criterion “How complex is the process?” (based on our experience related to the issue tracking process): • An issue tracking process is very complex if it has more than ten process steps, more than eight different roles are involved in the process, and it is not defined hierarchically. • An issue tracking process is complex if it defines more than five process steps and has more than five different roles involved in the process. • An issue tracking process is non -complex if it has fewer than six process steps and has at most six different roles involved in the process, a clear responsibility concept, and few dependencies between process steps.
Thus, a flexibility model specific for the issue tracking process described in Fig. 1 is provided. Fig. 5 portrays an excerpt from the model. Fig. 5. An Excerpt from the Process Flexibility Model 5.2
Benefits of the Flexibility Model The benefits of the process flexibility model are outlined in the following.
We can evaluate the issue tracking process based on the criteria and metrics provided in the model. For example, the issue tracking process (phase 3) presented in Figure 1 can be evaluated as follows: • The process is complex, as it has nine activities and eight roles involved in the process; but the process is part of the process hierarchy and the maturity of the process is quite high. • The process is understandable, as it has a clear responsibility concept; but it has many dependencies (i.e. the synchronization and coordination points) between process steps. • The organization intends to perform the explicit process monitoring and has captureed the knowledge with respect to the attractiveness and the risk of an implementation of the issue.
The improvement potentials of the issue tracking process are as follows: • It would be helpful if the variants of the issue tracking process together with its context were provided in the emergent knowledge base. The reuse of the process variants would help to quickly modify the process. • An efficient re-reuse process would support a quick and easy identification of the kind and extent of the requisite process modification. • A tool-supported, regularly performed identification of the difference between the prescriptive issue tracking process and the activities performed by the developers would help to quickly identify the need for a process modification.
We achieve a definition of the requirements for the process flexibility. For example, in order to be flexible a process should flexibility is needed but may not have a negative impact on the final product quality. A further step is to analyze how much flexibility is permissible and whether the flexibility alternatives proposed are sufficient. • • • • • define what artifacts need to be developed, when the development of the artifacts should be started, who should develop which artifact, when an artifact should be finished, etc. be defined hierarchically in order to be well understandable and traceable for the people involved in the process. explicitly define process monitoring. explicitly define delta analysis between the prescriptive and currently performed processes. systematically package and reuse the acquired knowledge and experience related to process flexibility.
A present trend in software development is a highly dynamic environment. Such an environment is characterized by frequent changes caused by innovations, business relationships, and other factors. In order to be able to quickly [4] react to a change, software engineers wish to have flexible software development processes. And to be able to define flexible software development processes, the requirements placed on the process flexibility are needed. The requirements should be defined in such a way that they are meas- [5] urable in order to be able to evaluate whether a process is sufficiently flexible for a given software development environment. We have hence, in this paper, outlined our approach to support the research question “How can process flexibility be defined in a measurable way?”. [6]
For this purpose, we have first informally defined process flexibility, second an emergent knowledge base has been developed, and, third, a process for the measurable definition of the process flexibility has been derived. The informal definition of process flexibility was needed, as the [7] standards considered do not explicitly define the term. The emergent knowledge base aims at providing the knowledge related to the definition of process flexibility in a measurable way. We believe that the application of the knowledge provided would help to more effectively and efficiently [8] define the process flexibility for a concrete process. The flexibility definition process allows us to define the issues with respect to which the process should be especially flexible and, based on the evaluation of the issue's impor- [9] tance, to select and to identify the criteria and measures relevant for the process flexibility of a software development process at hand.
The knowledge stored in the experience base such as the flexibility definition process is validated and illustrated by means of a case study. The activities and the results gained in the case study are elaborated. We therefore feel that the work presented in the paper can be easily transferred into other business units and organizations and enable them to define the flexibility of their processes in a measurable way.
Our next steps in context of this work are first to explicitly define the constraints to be taken into account. This is essential as, in the automotive industry application domain,