- 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.
——————————
Na highly dynamic environment which is chara cterized owadays, the automotive industry is confronted with by frequent changes due to innovations (e.g., new switch strategy for a gear), business relationships (e.g., new international collaboration), and new experiences (e.g., a project team follows a prescriptive process and recognizes that the process is not really efficient to perform module testing). One of the reasons for this trend is 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. In order to be able to quickly react to the changes in the development environment, flexible software development processes are needed.
By a software development process we understand a set of partial causal and constrained activities performed by project team to produce software. The process constraints define milestones to deliver product artifacts to the customer, maturity level of the artifacts, and activities have to be performed to insure the quality of end product and satisfy the customer. The abstraction level of activities’ specification depends on project team’s needs.
A quick reaction is characterized by the ability to quickly identify • whether a process adaptation (e.g., process refinement, remove of some constraints etc.) is needed • what kind of process adaptation is required • what the extent of the required process adaptation is • what the strategy to perform the process adaptation is, and, accordingly, if a process adaptation is needed
For an effective reaction the benefit of performing the rea ction activities (1)-(4) must be higher than the effort required to perform the activities. The problem is that classical methods proposed for embedded software development (e.g., V-Model [3], RUP [1]) are not flexible enough for a frequently changing environment. Automotive companies usually follow plan driven methods for software development (e.g., for control devices). The consequence of the application of inflexible processes is that project teams are not able to quickly react to changes, therefore, project teams are pressed for time often resulting in fire-fighting and overtime. Therefore, there is a demand for more flexible processes to better support our engineering departments. To address this point, agile methods [1] have been considered. Unfortunately, agile methods do not clearly define how to deal with process constraints. In our environment, the process constraints are milestones to which artifacts are to be delivered, maturity of artifacts at given milestones, changes to be considered since a given milestones, management and communication structure etc. These aspects are important for long (e.g., 36 months) large (e.g., hundreds of people coming from several organizations) projects, with constant budget and constant ground functionality as it is the case in automotive industry. These aspects are important in order to better plan and control the project.
time to develop required functionality in given budget constraints.
Agile methods do not address the process constraints, because they usually aim on small project teams and assume the project team members being very experienced people who are able to very well plan and organize the irwork. In the large projects, in which very safety criticall software should be developed, there is no person which can in deep understand the work performed by all team members in order to be able to communicate with right persons in write time, to deliever the right products of the right maturity to the right time. Therefore the research question arising is fundamental: What should a flexible software development process look like? In order to answer this question we investigate the requirements for process flexibility in this paper. This is done as following. Chapter 2 outlines the derivation of the requirements for process flexibility within the domain “automotive software”. Related work used as input for the requirements definition is discussed at relevant places throughout the paper. In Chapter 3, the application of the requirements to a specific process is illustrated by means of a case study. Finally, Chapter 4 summarizes the most important contributions of the paper and addresses future work.
Process Analysis software processes at DaimlerChrysler are analyzed in order to better understand why existing software development processes are considered as inflex ible by the software development team. In addition, interviews with project teams were performed. We identified that project teams desire to be able to modify the prescriptive 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 engineering 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, there are lesser changes here. By a flexible process, the project team understands a process • that provides a clear overview about the activities to be performed, if a change event (e.g., it is identified that developers are not able in time to remedy their faults) occurs. • • fault tolerant (i.e., process is iterative and it is possible from each step to go back by using existing recovery mechanisms). corresponds to the terminology and the way of thinking of team members.
Definition of flexibility level: Based on results of the process monitoring, levels of process flexibility are defined and the flexibility level relevant for our specific software development process is identified. Figure 2 shows four levels of flexibility. Waterfall processes belong to the process class having “no flexibility” level (see curve 1). Here it is exactly 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 administrative process. The iterative processes, where the activities to be performed and the sequence of activities are exactly known belong to the process class having “adaptability” level. The terminology of such process activities and role concept are adaptable to a project team. An example for such kind of processes is a process for development of well known products.
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 curve 3). Furthermore, the software development process usually becomes more stringent in the course of the project.
lerChrysler’s engineering departments, because about 80% 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 defined by the project team. Processes, were it is not really known at all, how the process should be performed belong to the fourth class “total emergence” (see curve 4). An example for processes having fourth flexibility level is the processes applied for development of innovation at research centers. • allows the project team to perform their work in the usual way as far as possible.
of flexibility we need in our company, the flexibility and agility contributions provided in the literature are analyzed. Because it is widely assumed that agile methods (e.g., XP [1]) provide more flexibility than plan driven methods (e.g., V-Model [3], RUP [6]). The XP, the V-Model, and the RUP are analyzed with respect to flexibility. We found out that XP provides flexibility by focusing on time schedule and clear definition of roles and of responsibilities. The competence to decide about activities to be performed and artifacts to be delivered is subject to the project team members. In contrast to the XP, the V-Model prescribes activities to be performed and artifacts to be delivered. The V-model allows tailoring the activities to be performed and the artifacts to be delivered to a given context.
(e.g., change drivers, types of changes etc.) found in the literature [2], [7] to the context “software development processes” are investigated by means of a case study. These concepts are taken as an input for the systematical derivation of requirements related to process flexibility. Systematic derivation of requirements and constraints for process flexibility are systematically identified following the
ous steps. It is distinguished between require ments for process definition, process application, and domain constraints. The domain constraints are considered, in order to provide as far as possible realistic requirements on the processes in domain “automotive software development”.
Requirements for process definition
the process should distinguish between core activities (that must be performed), special activities (that should be performed), and nice to have activities (that can be performed). This is needed to be able to quickly react on time pressure.
the process should be modeled in a hierarch ical way in order to be transparent.
Req. 3 - Traceability the process should be traceable (vertical and horizontal), in order to be able to quickly understand what kind of process adaptation is needed, if a change happens. Vertical traceability means that the relationships between different abstraction levels of the process are clear. Horizontal traceability means that the relationships between different views on the process are clear (e.g., between a project manager view and a view of a tester)
the process should provide different views on the process (e.g., view for project manager, view for tester etc.) and clear responsibility concept, in order to be more transparent and understandable for a project team.
the process should be modular in order to support an easy and quick process adaptation. The process modules should have as much as possible cohesion. The number of dependencies between process modules should be as low as possible.
the process should be tailored on the application domain, organization structure, terminology and the way of thin king of the project team in order to have acceptance by the project team.
Requirements for process application
the process should support systematical learning from past experience and knowledge, in order to better (1) estimate risks, benefits, and costs of a process adaptation and (2) integrate gained knowledge and experience in the process.
the process should support a good (i.e., open and honest) communication in the project team in order to quickly identify a need for a process modification and to correctly perform the needed modifications.
manager should define only “must” constraints on the software development process and let as much as possible developers’ freedom to perform their operational work in desired way.
Domain constraint s
quality gates (i.e., milestones) to which product artefacts should be developed (e.g., by quality gate A lab tested software should be provided). The quality gates have to be considered, because quality gate method is used for automotive software development at DaimlerChrysler.
activities to be performed must be compatible with SPICE standard [I98] (e.g., reviews, tests). The compatibility with
Evaluation of the requirements and constraints
ject teams, interviews with 5 project managers, 2 quality manager and 6 developers from different engineering departments, and workshops with 16 experts in the domain “process design” are performed. This is done following the process shown in Figure 8.
The second step is to interview individual representatives from the selected stakeholder groups. The objective of these interviews is to identify those theses for processes that are important from the viewpoint of the stakeholder group. Therefore, structured interviews are held, in which each stakeholder rates the importance of the requirements and constraints defined in the previous section. To support these interviews, the interviewer derives a questionnaire based on knowledge of the knowledge base. For each thesis its name and definition is given, as well as a 4-point-importance scale. An excerpt from such a questionnaire is shown in Table 1.
edge base is complete, the interviewees are asked about missing theses that are to be considered.
Additionally, stakeholder-specific process models are generated. As multiple stakeholders’ groups are interviewed, the individual viewpoints are integrated. The aggregated answers are visualized in a colored quality tree: the colors indicate whether requirements or constraints are rated as very important, important, or somewhat important . Theses that were rated as not important at all are not included.
Process: Based on the interview results we generated the stakeholder-specific and final process model. The final model is derived by aggregation of role specific constraints based on the arithmetic method. This is done as following: to each scale value a number is assigned: very important=3, important=2, somewhat important=1, and not important at all=0. Then for each requirement and constraint, the evaluation values given by stakeholders are added and divided by number of the values.
Fig. 4 and Fig. 5 show the stakeholder-specific models for the
Process Priori
Traca
View &
Process
Domain Quality Fig. 4. Developer role-specific Process Suitability Model (Example) Process
Process Modelin.g.. Commu- ...
Somewhat important Process
Process Process Domain Priori
Traca
View &
Process
Learning... Commu- ... Quality SPICE Somewhat important Fig. 5 Manager role-specific Process Suitability Model (Example) Process
Process Process Domain Priori
Traca- View &
Process Learning ... Commu- Modeling ... Quality SPICE These models show for example that the developers’ process theses related to process definition (e.g., provide different role and views, prioritize of activities) play a larger role than for the manager. Also it can be observed that the developer 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 pro cesses is desired.
In order to evaluate our requirements and constraints, we performed a case study in the context of Software Issue Tracking process applied at DaimlerChrysler’s engineering departments. The issue tracking process consists of activities presented in Figure 3. The first activity in the process is to “capture” an issue. Here customer, supplier, or another authorized member of project team generates a request form for his issue and fills out the form. An issue can be a fault, a requirement’s change, or a new requirement. After the form is filled out, a responsible system expert decides whether the issue is a software, electronic, actuator, or 4 SUMMARY AND FUTURE 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 busianalysis, 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 flexibildeveloper remedies the issue. This imple mentation 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 effimanagement 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 reThe 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 procprocess 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 pering: 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 following. [2] BGyuliedsejof,oHrt.hMe oPdereplilnegxeOd,uAtpdudtisFolenxWibielsitlyeyi,n2p00ro4.cess industry, PerTable 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 ess application in the third row of the first top line, and PErnatxwisiceki nlusantgz, OvldoennboITu-rSgy, s2t0e0m0.en mit Anleitung für den finally, the domain constraints in the fourth top line. In the [4] ISO/IEC TR 15504-2:1998(E), ISO Standard. Information technolthird 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. of view is presented. In the fourth line, the evaluation’ re- [5] RNo. mFebnatcohn, Ra.nPdraBc.tiLciatltlebwenoeofdit,s eodfitgoorasl,-oSroieftnwteadremReealsiaubreilmityenat.nIdn 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 Synchronizatential needed from process users’ point of view can be identi tion: Knowledge and Innovation Management Towards Flexagilfied. 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.