Failsafe products are a major motivation in industrial software teams. Here, we describe the field of automotive product engineering to illustrate the boundary conditions for the development of fail-safe automotive products and describe the standards and norms defining the requirements for the development of safety-critical embedded systems. The following sections describe general-purpose process models fulfilling these standards and norms, i.e. quality management, the Capability Maturity Model Integrated (CMMI), ASPICE and the V-Model development process, an international standard for developing software products.

The demand for software products in the automotive industry has been increasing exponentially over recent decades, making software engineering one of its critical success factors [2] . The extensive use of Electronic Control Units (ECUs) in vehicles today has already led to an average of 20 ECUs in smaller and even more than 70 ECUs in upper-class cars [3] . Developing complex features within a short time to market and with minimal engineering costs at very high quality are the challenges that have to be met. Besides functional complexity, some other specific characteristics for the automotive field are needed, especially:

- Code efficiency for an improved performance due to limitations of processor and memory resources.

- Code portability and traceability to ensure further development and variant handling.

- High availability and reliability to support safety-critical applications.

- Real-time operation.

- Network operation.

Project and process management are needed with a continuous development in respect to the availability of the corresponding processes, which are increasingly being used as a basis for order placement [4] . The development process has to describe all phases of the development lifecycle and describe all interactions of different engineering disciplines in the system. The process and the continuous improvement of the process are important parts of the software development. Figure 3 illustrates the most important phases of development process in an industrial software project, including the activities needed to manage and control the project [5] .

The crosscutting can be represented in matrices, using the concept of a Design Structure Matrix (DSM) [6] . This matrix shows the relation between source and target. These relations can have different types, such as usage and abstraction dependencies (e.g. realization, refinement and tracing [7] .

Different phases of development of life cycle could be represented as a source and target system. Each phase will be a source for the following phase, which represents the target. The source and target elements should be sorted such that the sources are represented by the row of the matrix, and the targets will be represented by the columns. Each cell of this matrix will be denoted with 1 if the source element (in the row) has a relation to the target element (in the column). It will be set to zero if there is no relation. Table 1 illustrates the dependency matrix of the system, as shown in Figure 4 .

To represent the development phases, a cascading pattern system will be used. For a system shown in Figure 5 , there are two patterns: between domains A and B, and between Domains B and C.

The target of the first pattern serves as source in the second pattern. Then, the transitivity dependency relation rel for source A, intermediate level B and target C, and #B is the number of elements in B is defined as follows [8] :

$\exists k\in \left(1,\cdots ,\#\text{B}\right):\left(\text{A}\left[i\right]\text{rel}\text{B}\left[k\right]\right)\wedge \left(\text{B}\left[k\right]\text{rel}\text{C}\left[m\right]\right)\Rightarrow \left(\text{A}\left[i\right]\text{rel}\text{C}\left[m\right]\right)$

Figure 6 represents a part of a DSM for different levels of development of life cycle. A defect in element M2 in the mapping (F2, M2) could be represented as:

impact (F2, M2) = change ((F2, M2), (M2, C2), (M2, C3)) + preserve ((F1, M1), (M1, C2), (M3, C3)).

The six mappings represented in the equation could involve changes in higher layers. In our example, it goes up to R1. The analysis of impact (F1, M1), impact (M1, C2) and impact (M3, C3) will involve the total change effect in the model. A change in the requirement level will include more impactful changes.

impact (R1, R1) = change ((R1, R1), (R1, F1), (F1, M1), (M1, C1), (M1, C2), (F1, M2), (M2, C2), (M2, C3), (R1, F2), (F2, M2), (M2, C2), (M2, C3), (F2, M3), (M3, C3), (M3, C4)) + preserve ( (R1, F2), (F1, M2)).

This example illustrates the possibility of changes. Such changes could include several levels up to the development level. Some changes will be difficult to analyze, like (M1, C2) and (M2, C2), and will be presented as a conflict. Such a conflict only occurs in case of a combination of scattering at one level and tangling in a subsequent level, resulting in multiple paths from initial source to final target elements.

The conflicts could be calculated in a way:

#conflicts = #changed + #preserved − #involved.

Table 2 illustrates the dependency matrix for the example of Figure 6 . There are 4 levels: R, F, M, and C, the cells’ value are shaded depending on the relations among the system components.

With experts’ knowledge and the effect of KPIs discussed in this study, a dependency matrix from Table 2 was developed and presented in Table 3 . The element value presents the dependency of the row on the column variable. Each cell represents the relationship between two components of the system, i.e. r1f2 represents the dependency between requirement (R1) and feature (F1) and c3c4 represents the dependency between the artefact (c3) and artefact (c4) in the system shown in Figure 6 .

This approach has to support project managers with their decisions from multiple domains; therefore, a specification of multiple domain-related specifications is needed. The approach has to trace all changes in the system throughout the project development lifecycle and document the reason for all changes in terms of feasibility, impact on other components, risk, effort, and schedule. The approach is classified into three knowledge sectors:

1) System model

The software has to be structured in a system model, where all artifacts in the software have to be presented in one or more graphical views, depending on the domains focused on the system. All artifacts, i.e. requirement, architecture, code, test and all non-functional artifacts (e.g. risk management and legacy standards and norms) are included and represented as nodes. The relationships among the nodes are presented as edges connecting these nodes to each other.

The traceability and crosscutting concerns were defined in previous section. A DSM has to represent the system elements from requirements down to implementation activities, as shown in Figure 6 . The DSM presents the relationships between these elements. Matrices can be constructed either “across rows” or “down columns,” depending on which direction is identified as forward process flow [9] . This overview presents a total view of the system. This view helps the decision makers to have better understanding of the system and make their decision to estimate the effort needed for changing any element in the system. The model is built in a hierarchical design; therefore, changing a component in the system will affect other components that are directly related, and other components that are not directly linked to the changed component may also be affected.

2) Dependability matrix

The crosscutting approach is used to describe the system model as a matrix. Each node has a value that describes the relationship between this node and other nodes in the system. This matrix describes the dependability and how strong is the relationships among the system nodes. High node value means that the component in the row of the matrix depends strongly on the component presented in the column of the matrix, where low value describes a weak dependability of the component.

Change request in an element of the matrix could lead to high effort on other elements in the system. The node value is a description of the effectiveness of a change effort in all affected elements, e.g. the node C2R has a value of four, which presents a high node value and means that C2 is strongly dependent on R, any change in R could lead to a change in C2. On the other side, the value in node C2M3 is zero that means that C2 is not dependent on F3 change in F3 zero effort for C2.

The DSM will be constructed in an “across rows” fashion [10] . Non-zero entries indicate a relationship between two elements that the row element depends on the column element. The relationships among the different nodes in the system and the strength of this relation are analyzed using crosscutting principles, as illustrated in Table 4 .

3) Weight vector

The weighting value is a measure for the effort needed for the change in an element of the system as element own effort. This weighting value depends on the complexity of the element. To find this complexity, an adapted Halstead method is used. The software development and defect correction models support the estimation approach by parameters that directly affect the effort of change. This effort depends on the process and quality assurance used throughout the development lifecycle.

4) Complexity factor of change

Effort of changes is dependent on the complexity of the system and the change needed. In order to estimate the effort of change needed in a system, the complexity of change included in a system has to be estimated. Halstead model [11] [12] is used in this study to estimate the complexity. Halstead model has been in use for years to estimate the complexity of software code [13] [14] . Halstead’s metrics are based on interpreting the source code as a sequence of tokens and classifying each token to be an operator or an operand.

The effort to implement (E) or understand a program is proportional to the volume (V) and to the difficulty (D) level of the program is present in Equation (1):

$E=V\ast D$ (1)

Equation (1) could be used to estimate the effort for development of systems containing several models. The effort of change in a module is estimated as in Equation (2):

Effort = Complexity × Weight [hour] (2)

In order to use Halstead model in estimation of software effort in a project, the metrics could be obtained as Equation (3):

$\text{Complexity}=\left(N_1+N_2\right)\cdot {\log }_2\left(N_3+N_4\right)$ (3)

where:

N₁: Number of component;

N₂: Number of input for module;

N₃: Number of different component types;

N₄: Number of output for modules.

Change request and defect in a software, depending on the system complexity, the number of modules in the system and the interfaces among the modules in system to be changed. Therefore, a change in module leads to different changes in other module because of their dependability on each other and the interfaces among the module. The DSM matrix presents the complexity and the connectivity among the different modules in system. The complexity of each module has to be estimated with Halstead model as in Equation (3).

The effort of change in a module is estimated as:

$\text{Effort}={\displaystyle \sum \text{Complexity}\times \text{Weight}\left[\text{hour}\right]}$ (4)

5) Weighing of change

Industrial software development has to ensure the quality and more different metrics in software before releasing the software and the product. Several processes have to be used to cover all the important properties of the product. The development could be done in different phases by different teams. Adapting new change request in a software system could have huge effort more than the effort needed for code implementation. Estimating the effort needed for adapting a change or fixing a defect in software system has to focus on all activities described in the process. This section presents and analyses the development process in automotive industrial domain and presents a model to estimate the weight of change considering all activities needed as standard process. This model supports the project manager to estimate the effort of change in a complex software. The effort of change in a module is estimated as in Equation (4).

This study used some standard methods, e.g. crosscutting concern and Halstead, to build the estimation system, they were adapted to this use. The new KPIs needed for the system were analyzed and described as a new technique in the study. Figure 5 describes the steps to estimate the effort of changes in software project, the own technique is bordered with a red square.