1 Requirements for Flexible Software Development Processes O. Jaufman, A. Dold, T. Haeberlein, C. Schlumpberger, M. Stupperich Abstract — 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 current processes can be analyzed to identify its improvement potential. The application of the requirements is illustrated in the context of a case study. Index Terms — Process flexibility, requirements, c ase study, software development —————————— u —————————— 1 INTRODUCTION N owadays, the automotive industry is confronted with a highly dynamic environment which is chara cterized by frequent changes due to innovations (e.g., new • what the strategy to perform the process adapta- tion is, and, accordingly, if a process adaptation is needed switch strategy for a gear), business relationships (e.g., new For an effective reaction the benefit of performing the rea c- international collaboration), and new experiences (e.g., a tion activities (1)-(4) must be higher than the effort required project team follows a prescriptive process and recognizes to perform the activities. The problem is that classical that the process is not really efficient to perform module methods proposed for embedded software development testing). One of the reasons for this trend is that software (e.g., V-Model [3], RUP [1]) are not flexible enough for a has come to play a more and more important role in the frequently changing environment. Automotive companies automotive industry and will be the major source of inno- usually follow plan driven methods for software develop- vation in the future. In order to be able to quickly react to ment (e.g., for control devices). The consequence of the ap- the changes in the development environment, flexible soft- plication of inflexible processes is that project teams are not ware development processes are needed. able to quickly react to changes, therefore, project teams are By a software development process we understand a set of pressed for time often resulting in fire-fighting and over- partial causal and constrained activities performed by pro- time. Therefore, there is a demand for more flexible proc- ject team to produce software. The process constraints de- esses to better support our engineering departments. To fine milestones to deliver product artifacts to the customer, address this point, agile methods [1] have been considered. maturity level of the artifacts, and activities have to be per- Unfortunately, agile methods do not clearly define how to formed to insure the quality of end product and satisfy the deal with process constraints. In our environment, the customer. The abstraction level of activities’ specification process constraints are milestones to which artifacts are to depends on project team’s needs. be delivered, maturity of artifacts at given milestones, By a flexible process we understand a process that allows changes to be considered since a given milestones, man- the organization to react quickly and effectively to predict- agement and communication structure etc. These aspects able and non -predictable changes in business und devel- are important for long (e.g., 36 months) large (e.g., hun- opment environment. dreds of people coming from several organizations) pro- A quick reaction is characterized by the ability to quickly jects, with constant budget and constant ground functional- identify ity as it is the case in automotive industry. These aspects • whether a process adaptation (e.g., process refine- are important in order to better plan and control the project. ment, remove of some constraints etc.) is needed The planning and control is necessary in order to be able in • what kind of process adaptation is required time to develop required functionality in given budget con- • what the extent of the required process adaptation is straints. Agile methods do not address the process constraints, • O. Jaufman is with the DaimlerChrysler AG, Ulm, HPC U800, E-mail: because they usually aim on small project teams and as- Olga.Jaufman@DaimlerChrysler.com. • A. Dold is with the DaimlerChrysler AG, Ulm, HPC U800, E-mail: A- sume the project team members being very experienced xel.Dold @DaimlerChrysler.com. people who are able to very well plan and organize the ir- • T. Haeberlein is with the DaimlerChrysler AG, Ulm, HPC U800, E-mail: work. In the large projects, in which very safety criticall Tobias. Haeberlein @DaimlerChrysler.com. software should be developed, there is no person which can • C. Schlumpberger is with the DaimlerChrysler AG, Ulm, HPC U800, E- mail: Claudia. Schlumpberger @DaimlerChrysler.com. in deep understand the work performed by all team mem- • M. Stupperich is with the DaimlerChrysler AG, Ulm, HPC U800, E-mail: bers in order to be able to communicate with right persons Michael.Stupperich@DaimlerChrysler.com. 2 QUATIC’2004 PROCEEDINGS in write time, to deliever the right products of the right ma- • fault tolerant (i.e., process is iterative and it is pos- turity to the right time. Therefore the research question aris- sible from each step to go back by using existing ing is fundamental: What should a flexible software devel- recovery mechanisms). opment process look like? In order to answer this question we investigate the requirements for process flexibility in • corresponds to the terminology and the way of this paper. This is done as following. Chapter 2 outlines the thinking of team members. derivation of the requirements for process flexibility within the domain “automotive software”. Related work used as Definition of flexibility level: Based on results of the proc- input for the requirements definition is discussed at rele- ess monitoring, levels of process flexibility are defined and vant places throughout the paper. In Chapter 3, the applica- the flexibility level relevant for our specific software devel- tion of the requirements to a specific process is illustrated opment process is identified. Figure 2 shows four levels of by means of a case study. Finally, Chapter 4 summarizes flexibility. Waterfall processes belong to the process class the most important contributions of the paper and ad- having “no flexibility” level (see curve 1). Here it is exactly dresses future work. known what should be done and no (or very few) change drivers (such as new gained experience, users’ faults) are available. An example for such processes is an administra- 2 R EQUIREMENTS FOR P ROCESSES tive process. The iterative processes, where the activities to Our main objective is to provide a specific set of require- be performed and the sequence of activities are exactly ments for needed process flexibility. In order to derive the known belong to the process class having “adaptability” requirements, four steps illustrated in Figure 1 are per- level. The terminology of such process activities and role formed. concept are adaptable to a project team. An example for such kind of processes is a process for development of well Definition Litera- Systematic Evalua- known products. of flexibil- ture derivation tion of Processes where for parts of the process it is not really ity levels research of req. req. known, what are the activities to be performed and what is the optimal order of the activities belong to the process class having “partial emergence” level of flexibility(see Process Requireme Analysis of curve 3). Furthermore, the software development process Analysis nts & evaluation usually becomes more stringent in the course of the project. Constraints results This class of flexibility corresponds to the needs of Daim- lerChrysler’s engineering departments, because about 80% Fig. 1. Steps performed of the process aspects are predefined by the norms and standards for software development (e.g., SPICE [4], quality gates etc) and only about 20% of process aspects could be Process Analysis software processes at DaimlerChrysler defined by the project team. are analyzed in order to better understand why existing software development processes are considered as inflex i- ble by the software development team. In addition, inter- views with project teams were performed. We identified that project teams desire to be able to modify the prescrip- tive software development process during the project in order to be able to perform their work more effectively and efficiently. The reason for this desire is that it is not possible to decide what is the most effective way of performing the development and management activities at the beginning of the project. In addition, the project teams in our engi- neering departments desire to have their process more flexible at the start of the project, in order to adequately react to many changes coming at the start of the project. First, in the course of project, their software development process should be more stringent, because, empirically, Fig. 2. Flexibility levels there are lesser changes here. By a flexible process, the pro- ject team understands a process Processes, were it is not really known at all, how the proc- • that provides a clear overview about the activities ess should be performed belong to the fourth class “total to be performed, if a change event (e.g., it is identi- emergence” (see curve 4). An example for processes having fied that developers are not able in time to remedy fourth flexibility level is the processes applied for devel- their faults) occurs. opment of innovation at research centers. • allows the project team to perform their work in Literature Research: after we have determined what kind the usual way as far as possible. of flexibility we need in our company, the flexibility and JAUFMAN ET AL.: REQUIREMENTS FOR FLEXIBLE SOFTWARE DEVELOPMENT PR OCESSES 3 agility contributions provided in the literature are ana- pendencies between process modules should be as low as lyzed. Because it is widely assumed that agile methods possible. (e.g., XP [1]) provide more flexibility than plan driven Req. 6 - Parameterization methods (e.g., V-Model [3], RUP [6]). The XP, the V-Model, the predictable process changes should be taken as parame- and the RUP are analyzed with respect to flexibility. We ter (e.g., number of verification activities varies depending found out that XP provides flexibility by focusing on time on safety criticality of product component). schedule and clear definition of roles and of responsibili- ties. The competence to decide about activities to be per- Req. 7 - Iterations formed and artifacts to be delivered is subject to the project the process should be iterative in order to be able to team members. In contrast to the XP, the V-Model pre- quickly react to the change drivers (e.g., developers’ scribes activities to be performed and artifacts to be deliv- faults). ered. The V-model allows tailoring the activities to be per- Req. 8 - Tailor ability formed and the artifacts to be delivered to a given context. Furthermore, the applicability of flexibility related aspects the process should be tailored on the application domain, organization structure, terminology and the way of think- (e.g., change drivers, types of changes etc.) found in the ing of the project team in order to have acceptance by the literature [2], [7] to the context “software development processes” are investigated by means of a case study. These project team. concepts are taken as an input for the systematical deriva- Requirements for process application tion of requirements related to process flexibility. Req. 1 - Learning Systematic derivation of requirements and constraints for the process should support systematical learning from past process flexibility are systematically identified following the experience and knowledge, in order to better (1) estimate GQM method [5] based on the knowledge gained in the previ- risks, benefits, and costs of a process adaptation and (2) in- ous steps. It is distinguished between require ments for process tegrate gained knowledge and experience in the process. definition, process application, and domain constraints. The domain constraints are considered, in order to provide as far as Req. 2 - Communication possible realistic requirements on the processes in domain the process should support a good (i.e., open and honest) “automotive software development”. communication in the project team in order to quickly identify a need for a process modification and to correctly Requirements for process definition perform the needed modifications. Req. 1 - Priorisation Req. 3 - Modeling Language the process should distinguish between core activities (that the process should be modeled by a modeling language must be performed), special activities (that should be per- that supports quick and easy adaptation. formed), and nice to have activities (that can be per- formed). This is needed to be able to quickly react on time Req. 4 - Tool Support pressure. the process should be supported by a tool that allows to quickly adapt the process. Req. 2 - Hierarchy the process should be modeled in a hierarchical way in or- Req. 5 - Revision der to be transparent. the operational process should be revised each two weeks and if needed adapted to a new situation. Req. 3 - Traceability the process should be traceable (vertical and horizontal), in Req. 6 - Process Constraints order to be able to quickly understand what kind of process manager should define only “must” constraints on the adaptation is needed, if a change happens. Vertical trace- software development process and let as much as possible ability means that the relationships between different ab- developers’ freedom to perform their operational work in straction levels of the process are clear. Horizontal trace- desired way. ability means that the relationships between different views on the process are clear (e.g., between a project Domain constraints manager view and a view of a tester) Con. 1- Quality Gates Req. 4 - Views and Roles quality gates (i.e., milestones) to which product artefacts the process should provide different views on the process should be developed (e.g., by quality gate A lab tested (e.g., view for project manager, view for tester etc.) and software should be provided). The quality gates have to be clear responsibility concept, in order to be more transpar- considered, because quality gate method is used for auto- ent and understandable for a project team. motive software development at DaimlerChrysler. Req. 5 - Modularity Con. 2 – SPICE Compatibility the process should be modular in order to support an easy activities to be performed must be compatible with SPICE and quick process adaptation. The process modules should standard [I98] (e.g., reviews, tests). The compatibility with have as much as possible cohesion. The number of de- SPICE is desired, because it is the actual standard in our context. 4 QUATIC’2004 PROCEEDINGS Evaluation of the requirements and constraints Finally, we performed Steps 3 and 4 of the Evaluation Process: Based on the interview results we generated the In order to make sure that the theses meet the needs of pro- stakeholder-specific and final process model. The final model ject teams, interviews with 5 project managers, 2 quality is derived by aggregation of role specific constraints based on manager and 6 developers from different engineering de- the arithmetic method. This is done as following: to each scale partments, and workshops with 16 experts in the domain value a number is assigned: very important=3, important=2, “process design” are performed. This is done following the somewhat important=1, and not important at all=0. Then for process shown in Figure 8. each requirement and constraint, the evaluation values given by stakeholders are added and divided by number of the val- ues. Fig. 4 and Fig. 5 show the stakeholder-specific models for the Project Manager and the Developer, respectively. Figure 12 shows the final model. (Due to space constraints these figures show only excerpts of the models.) Process Process Process Domain Fig. 3. Evaluation Process ... Priori- Traca- View & Process ... Modeling Commu- Quality The evaluation process consists of four main steps: (1) Pre- pare role specific questionnaires, (2) Interview stake- Somewhat important holders, (3) Generate stakeholder specific process models, Fig. 4. Developer role-specific Process Suitability Model (Example) (4) Generate project specific stakeholders process model. The first step is to identify those stakeholders that are con- Process sidered in the project specific software development proc- Process Domain Process esses. Potential stakeholders are project managers, quality assurance managers, developers, etc. Priori- Traca- View & Process Learning ... Commu- ... Quality SPICE The second step is to interview individual representatives Somewhat important from the selected stakeholder groups. The objective of these interviews is to identify those theses for processes that are Fig. 5 Manager role-specific Process Suitability Model (Example) important from the viewpoint of the stakeholder group. There- fore, structured interviews are held, in which each stakeholder rates the importance of the requirements and constraints de- Process fined in the previous section. To support these interviews, the Process Process Domain interviewer derives a questionnaire based on knowledge of the knowledge base. For each thesis its name and definition is Priori- Traca - View & Process Learning ... Commu- Modeling ... Quality SPICE given, as well as a 4-point-importance scale. An excerpt from such a questionnaire is shown in Table 1. Figure 1: Project-specific Process Suitability Model (Example) Table 1: Exerpt from the questionnaire These models show for example that the developers’ process theses related to process definition (e.g., provide dif- ferent role and views, prioritize of activities) play a larger role than for the manager. Also it can be observed that the devel- oper would prefer different process models than the project manager. These visualizations help to make different views explicit and allow a focused discussion on what kind of proc- esses is desired. 3 A C ASE STUDY In order to detect whether the set derived from the knowl- In order to evaluate our requirements and constraints, we per- edge base is complete, the interviewees are asked about miss- formed a case study in the context of Software Issue Tracking ing theses that are to be considered. process applied at DaimlerChrysler’s engineering depart- Additionally, stakeholder-specific process models are ments. The issue tracking process consists of activities pre- generated. As multiple stakeholders’ groups are interviewed, sented in Figure 3. The first activity in the process is to “cap- the individual viewpoints are integrated. The aggregated an- ture” an issue. Here customer, supplier, or another authorized swers are visualized in a colored quality tree: the colors indi- member of project team generates a request form for his issue cate whether requirements or constraints are rated as very im- and fills out the form. An issue can be a fault, a requirement’s portant, important, or somewhat important. Theses that were change, or a new requirement. rated as not important at all are not included. JAUFMAN ET AL.: REQUIREMENTS FOR FLEXIBLE SOFTWARE DEVELOPMENT PR OCESSES 5 Fig. 1. Software issue tracking process TABLE 2: EVALUATION RESULTS After the form is filled out, a responsible system expert de- cides whether the issue is a software, electronic, actuator, or 4 S UMMARY AND F UTURE WORK gear issue, and assigns the issue to personal responsible for the Present software development is characterized by frequent issue. If the issue is a software issue, a responsible expert ana- changes caused by new innovations, fast-growing system lyzes the risk and the effort to remedy the issue. Based on this complexity, growing software portion in cars, changing busi- analysis, the change control board decides whether the issue ness relationships. So, in order to develop software effectively, should be remedied. If the decision is positive, a responsible more flexible processes are needed. Ignoring process flexibil- developer remedies the issue. This implementation is verified ity can make software developers not follow the prescriptive by the system expert. If the implementation is correct, change process, because it does not reflect the most effective and effi- management decides when the issue is to integrate in the sys- cient way of performing and supporting the development. tem and close the issue. In order to improve the process flexibility, explicit re - The evaluation of issue tracking process is performed in quirements for the process flexibility are needed. In this paper, two phases. In the first phase, the importance of the re- we have presented and discussed a set of process flexibility quirements and constraints is evaluated by users of issue requirements together with constraints which are specific for tracking process based on the scale: very important (3), im- the automotive industry. This set is not to be considered as “a portant (2), somewhat important (1), and not important at golden set of requirements” but rather as knowledge that all (0). The aggregation of the importance values is per- should be adaptable on the specific context. In order to make formed by the method “arithmetic middle value”. In the such an adaptation easier, a case study is performed. second phase, researchers evaluated the issue tracking In a similar manner, existing software development proc- process with respect to the requirements and constraints esses can be analyzed, in order to identify the realization ideas based on the scale (+: fully fulfilled, o: partly fulfilled, -: not on how a flexible process should look like. Based on the ideas, fulfilled). Each evaluation is qualitatively argued as follow- improvements for the software development processes per- ing: for example first requirement is not fulfilled, because formed at DaimlerChrysler’s engineering departments will be issue tracking process does not distinguish between core proposed. activities (that must be performed), specific activities (e.g., that should be performed in order to be conform to third SPICE level), and nice to have activities. The results of this REFERENCES evaluation are visualized in Table 1 and are explained as [1] Boehm, B. and Turner, R., Balancing Agility and Discipline: A Guide for the Perplexed, Addison Wesley, 2004. following. [2] Bylesjo, H. Modeling Output Flexibility in process industry, Per- Table 2 shows the requirements for process definition in the formance Measurement Conference, 2000. second row of the first top line, the requirements for proc- [3] Droschel, W., Wiemers, H. Das V-Modell 97, Der Standard für die Entwicklung von IT-Systemen mit Anleitung für den ess application in the third row of the first top line, and Praxiseinsatz, Oldenbourg, 2000. finally, the domain constraints in the fourth top line. In the [4] ISO/IEC TR 15504-2:1998(E), ISO Standard. Information technol- third line, the importance of the requirements and con- ogy — Software process assessment — Part 2: A reference model straints for issue tracking process from process users’ point for processes and process capability, ISO/IEC, 1998. [5] Rombach, R. Practical benefits of goal-oriented measurement. In of view is presented. In the fourth line, the evaluation’ re- N. Fenton and B. Littlewood, editors, Software Reliability and sults of the issue tracking process with respect to require- Metrics. Elsevier Applied Science, London, 1991. ments and constraints are presented. [6] Versteegen, G. Projektmanagement mit dem Rational Unified Based on the evaluation results, the process improvement po- Process, Springer Verlag, Berlin, 2000. [7] Wadhwa, S. Flexagility and Agility For Enterprise Synchroniza- tential needed from process users’ point of view can be identi tion: Knowledge and Innovation Management Towards Flexagil- fied. For example, hierarchical process modeling and explicit ity, Studies in Informatics and Control, Vol. 12, No. 2 June 2003. learning from past experience seem to be important and not fulfilled by the process.