ScrumOntoSPL: Collaborative Method of Agile Product Line Engineering for Software Resource Reuse

Abstract

Agile Product Line Engineering (APLE), a relatively new approach combining the two successful methods of Agile Software Development (ASD) and Software Product Lines (SPLs), makes product lines more responsive to ever-changing customer needs or market changes. However, SPLs often fail to keep up with market demand due to high coordination costs, slow development processes, and long release cycles in the case of frequent changes in business requirements; in agile software projects, the lack of a unified specification for describing requirements leads to high coordination costs and inconvenient requirement management. Some studies in the literature have proposed optimized approaches to integrate ASD and SPLs, but they still have not covered all aspects of APLE’s characteristics, and software resource reuse is rarely considered in these approaches during product line development. In view of this, we propose a collaborative framework of agile product line engineering for software resource reuse, namely ScrumOntoSPL. The ScrumOntoSPL approach efficiently merges ASD and SPL based on the agile method Scrum, SPL architecture, and ontology technology. In ScrumOntoSPL, uniform requirement specification is constructed by utilizing ontology, and the Matching Requirement with Component (MRC) process is designed to match product new requirements and software resources stored in a resource pool. In addition, we evaluated the proposed framework and approach with CMMI. In the end, a case study of a software development tool called IMC-Tool based on ScrumOntoSPL for a universal Instrument Microcontroller Chip (IMC) is discussed. The IMC-Tool case illustrates that the ScrumOntoSPL has the advantages of dynamically managing demand changes, enhancing software resource reuse, reducing coordination costs, and reducing time to market.

1. Introduction

With the accelerating growth of information technology, numerous products running information system software have been deeply applied to various industries. Due to the constantly increasing and sharply differentiated requirements among customer groups, manufacturers have to face the challenge of maintaining many product lines for each category of product. Traditional software development models cannot satisfy the needs of manufacturers, shortening the product line development cycle. Enhancing the reuse of product line software resources is an appropriate way to accelerate product development to address this challenge. Software resource reuse mainly includes requirement reuse, component reuse, modeling reuse, etc.

Currently, Agile Software Development (ASD) and Software Product Line (SPL) development have strengthened software resource reuse in the application of accelerating the development of software products, and they have shown great benefits in the software industry.

SPL development is a practice-based and plan-driven software development approach [1], and SPL engineering enables the large-scale manufacture of a series of associated products in the software industry [2]. An SPL consists of two main development processes, Domain Engineering (DE) and Application Engineering (AE). DE concerns the issue domain and defines the commonality and variability of an SPL’s products to establish characteristics and describe requirements for developing and managing reusable core resources; AE focuses on resource reuse and uses the variability to develop software products [3]. Although SPLs can quickly develop high-quality and complex software, SPLs often fail to keep up with market demands due to high coordination costs and a slow development process when business requirements change frequently. Therefore, we introduced an agile development framework named Scrum [4].

Scrum is an iterative framework of planning and guiding project processes and is characterized by short, iterative development cycles, reflection and introspection cycles, collaborative decision-making, rapid feedback, and a system for continuously integrating code changes into development [5]. In Scrum, the problems in the development process of SPLs can be effectively solved by using iterative and incremental methods to develop software products flexibly and quickly [6]. Therefore, numerous studies have explored the feasibility and benefits of implementing SPL within the Scrum framework [7], i.e., allowing Scrum and the SPL process to collaborate to address their own weaknesses and achieve their common goals: building and managing resources in the same domain, developing a suite of software products, and facilitating the reuse of software resources.

However, the software development approach to implementing SPLs in the Scrum framework still suffers from high coordination costs. Because software development is a complex process, the elements involved in each development process are knowledge representations marked or stored by all relevant personnel in different ways. Without a uniform definition and specification of knowledge representation, there is a deviation in the communication and understanding among product development-related personnel (including engineers, project managers, customers, etc.), which eventually leads to high coordination costs. To solve this problem, this paper introduces ontology technology, which is often used in computer science to formally capture the conceptualization and description of relationships [8], to address the problem of high coordination costs due to miscommunication between developers, customers, and other roles in the software development process.

In response to the lack of these approaches, this article suggests a collaborative development method based on APLE and ontology, called ScrumOntoSPL, and makes the following contributions:

• The proposed ScrumOntoSPL builds and exploits the SPL architecture in an iterative and additive way by successfully combining the agile method Scrum with SPLs, synergistically remedying the defects of each method and achieving their common goals: managing changes in requirements, improving software quality, reducing production costs, and shortening time to market.
• We established a uniform specification for describing requirements in ScrumOntoSPL using ontology in the agile environment and introduced requirement-matching criteria to classify the requirements of ontology. The ScrumOntoSPL method solves the interoperability problem caused by the inconsistency of concept understanding for different products, and it reduces coordination costs among multiple stakeholders.
• CMMI was introduced to theoretically evaluate our proposed framework and approach, and a case study of an actual ScrumOntoSPL application example of the design of a software development tool for the universal Instrument Microcontroller Chip (IMC) is discussed.

The rest of this paper is structured as follows. Section 2 introduces the related work of this paper. Section 3 presents the approach proposed in this paper. Section 4 evaluates the proposed approach. Section 5 introduces the application example of developing the IMC-Tool base on ScrumOntoSPL. Finally, Section 6 provides the conclusion.

2. Related Work

A large number of methods and approaches have been proposed to realize rapid development through resource reuse. Among them, the ASD and SPL methods have been shown to facilitate resource reuse and accelerate software development. Vale et al. [9] described a lightweight development process that combines SPL engineering and agile practices, following reflective and extractive approaches to construct series of product systems. Diaz et al. [10] proposed an Agile Product Line Architecture (APLA) to be applied in smart grids. The APLA process integrates a group of models for characterizing, recording, and tracking PLAs, and it includes an algorithm for navigating the PLA to modify the decision. Haidar et al. [11] proposed an agile framework for managing evolving profit and loss, aiming to address the deficiencies found in APLE while exploiting its strengths.

Kiani et al. [12,13] proposed an extension of Scrum to introduce the concept of system reusability. Granrath et al. [14] aim to form a new SE method by combining traditional systems engineering (SE) approaches with the agile development process of feature-driven development. In conclusion, although [9,10,11,12,13,14] combine the strengths of ASD and SPL to build and manage the same domain to develop various software products and collaboratively address the individual weaknesses to promote resource reuse, they still ignore the high coordination costs common to both ASD and SPL in the software development process.

In past decades, extensive research has studied the application methods of APLE and ontology in software systems. In [2], a requirement reuse method based on ontology and product lines is proposed, which consists of an ontology-based method of defining reusability requirements and a method for configuring requirements. In [15], an ontology-based software agile process, called the OntoSoft process, is proposed, which guides ontology-based software development by defining application scenarios and activities to develop ontology and software. Turchet et al. [16] proposed an ontology to represent knowledge related to Smart Musical Instruments (SMI), aiming to promote interoperability between SMI and heterogeneous SMI.

Kukkonen et al. [17] proposed the flow system ontology to describe the composition, mass flow, and energy flow of the flow system. Costa et al. [18] established human–computer interaction (HCI) ontology to clarify the main concepts involved in the HCI phenomenon and solve the semantic interoperability problem caused by the disunity of HCI system concepts. Adib et al. [19] proposed an ontology that is capable of gathering and evaluating user-related messages and using the most appropriate suggestions or directions to define a custom profile. In summary, the study shows that the use of ontology language to establish a uniform specification for describing requirements can improve the effective management and efficient reuse of resources and solve the high coordination cost and interoperability problems caused by the semantic barriers associated with the definition of operational terms and software development procedures.

3. ScrumOntoSPL Method

In this section, we present a software development method based on APLE and ontology, named ScrumOntoSPL. First, the method establishes a uniform specification for describing requirements with ontology technology to eliminate the problem of high coordination costs among agile teams. Second, it enables the dynamic management of requirements changes and improves product quality by reusing existing components of the product line to create new variants. Finally, ScrumOntoSPL remains a customer-centric agile delivery approach derived from the agile approach, and it addresses the problem of a long software development cycle and a slow release process. This section introduces this method by considering its main activities.

3.1. Ontology Specification for Describing Requirements

We used the ontology language to establish a uniform specification for describing requirements, which aims to provide the corresponding knowledge base for the reuse of software resources. The ScrumOntoSPL method will use the ontology model and ontology instance in the knowledge base to support user demand acquisition and variability management.

3.1.1. Definition of Ontology Model

The ontology model definition includes the following steps: (i) specification: identifying the domain, related terms, and objectives; (ii) conceptualization: creating a glossary of terms from which categories are created; (iii) formalization: using tools to create ontology models. A generic model of the ontology is shown in Figure 1. A detailed ontology model definition is presented in Section 5.2.

3.1.2. Ontology Mapping Rules

The ontology mapping routine takes the preprocessed user requirements as input and extracts different ontology components using mapping rules. The mapping rules are classified into six parts: concepts, data type attributes, object attributes, hierarchical relationships, axioms, and instances [20], as shown in Figure 2. Finally, all components created in the mapping routine are collected to generate the OWL ontology instance.

3.2. ScrumOntoSPL Methodology

The ScrumOntoSPL overview is shown in Figure 3. It is composed of three phases: pre-game, sprint execution, and release. All the roles, tasks, and events in ScrumOntoSPL are elaborated as follows.

3.2.1. Product Owner

The product owner (PO) is a Scrum role that manages requirements and their prioritization and tracks product development processes. The PO understands the customer’s requirements and their corresponding operational values, which the PO transforms into a product backlog [13].

In the ScrumOntoSPL approach, the PO analyzes requirements and provides feedback on what the customer wants to do by selecting or building the appropriate requirements with a tool. Then, requirements engineering is started and initiated. The tool performs ontology mapping to obtain the user requirements ontology instance and generates a feature backlog, which is a list of requirement ontology instances.

3.2.2. Feature Backlog

The Feature Backlog is a set of requirement ontology collected from the PO using visual tools. The Feature Backlog can start the development process and use the user requirement ontology as input to searches the information base.

3.2.3. Information Base

The information base is similar to a central repository and includes the descriptions and implementations of software resources from the entire project, such as the requirement ontology, software components, etc. In this paper, the information base mainly consists of the knowledge base and component base. The knowledge base is mainly used to store and distinguish the variable requirements and new requirements. The component base is used to reuse software components.

3.2.4. Matching Requirements with Components

In software development, it is critical to identify similar and variable requirements. Thus, in ScrumOntoSPL, we divided the requirements in the Feature Backlog into two predefined groups, namely the new requirement group and the variable requirement group, by matching the ontology instances in the knowledge base. First, the requirements are initially classified into two categories, i.e., new requirements and variable requirements, according to the component’s unique identifier and the component’s name. If there is no component in the information base matching the requirement, the requirement is assigned to a new requirement group, which would be directly appended to the Product Backlog; if the requirement matches some component, it will enter the Matching Requirement with Component (MRC) process to perform semantic matching, the retrieved results will be sorted by similarity to generate the Requirement-Matching Backlog (RMB), and the requirements will be temporarily assigned to the variable requirement group.

In the MRC process, we define a threshold expressed as α for the secondary division of requirements. The α is predefined in percentages and is small in the beginning, and α can gradually increase as the size of the RMB decreases. To generate the RMB, we use the distance-based (path length and depth) semantic similarity measure proposed by Li et al. [21] to calculate the similarity of attributes between ontology concepts, which can be used as the basis for ranking the RMB. The similarity can be obtained using

$$s\left({\phi }_1,{\phi }_2\right)=e^{-\gamma l}·\frac{e^{\mu h}-e^{-\mu h}}{e^{\mu h}+e^{-\mu h}},$$

(1)

where ${\phi }_1$ and ${\phi }_2$ represent two attribute words from the same concept of different entities, and $\gamma \in \left[\mathrm{0,1}\right]$ and $\mu \in \left[\mathrm{0,1}\right]$ are the parameters of the shortest path length and depth, respectively. The optimal values of $\mathsf{\gamma }$ and $\mathsf{\mu }$ depend on the used knowledge base, as described in [21]. After the attribute similarity between the variable requirement entity and the entity in the information base is obtained, the variable requirement group can be further divided, that is, if the similarity is less than α, the variable requirement will be added to the new demand group (Product Backlog) as an unrealized new requirement; if the similarity is greater than α, then the information base is searched for an entity, i.e., a component, according to the similar ontology concept. If the component including code resources is found, the variable requirement and resources will be added to the SPL Backlog. If the corresponding code resource is not found, the item in the RMB is removed, the MRC procedure is executed again, and then the new α is obtained. When one MRC process is completed, the next requirement entity is retrieved from the Feature Backlog, and the next MRC process begins, a cycle that continues until the current Feature Backlog is clear and the Scrum process begins.

During the pre-game phase, the tool server will capture the requirements of the software product based on the PO input. The output of this pre-planning is to produce a product backlog and an SPL backlog, which are used to accumulate new and variable requirements, respectively [22].

3.2.5. Product Backlog

The Product Backlog is a prioritized list composed of user requirements, and it reflects the PO’s vision of the product to be designed [23]. It consistently evolves during the product development process. In our approach, the DE team uses the Product Backlog to exploit product-specific requirements or new requirements. The item number of the Product Backlog decreases gradually with successive iterations until the final product version is issued.

3.2.6. SPL Backlog

The AE team utilizes the SPL Backlog to reuse core resources. The SPL Backlog is similar in nature and structure to the Product Backlog, but it includes the requirements associated with reusable core resources, that is, requirements, features, and functions that will change, fix, and enhance the existing resources in future releases. After each iteration, the number of items in the SPL Backlog is reduced as well.

3.2.7. Sprint Planning

Sprint Planning is a session involving the Scrum Master (SM) and the Development Team that determines the Sprint Goal and Sprint Backlog for planning the functions to be implemented in the current Sprint and places the tasks for this plan in the Sprint Backlog. The Sprint is the core of Scrum, and with a limited duration of one month or less (maximum duration is no more than 8 h), it is used to build a usable and potentially published product increment. These questions are addressed in Sprint Planning: “How to complete the Sprint to generate the increment”; “What can the increment brought by the Sprint provide”. At this point, the pre-game phase is over, and the development team then works following the Scrum process, which starts with Sprint Planning and ends with the review meeting.

3.2.8. Sprint Backlog

The Sprint Backlog contains a list of SPL Backlogs and Product Backlogs and a plan for incremental delivery and realistic Sprint Goals. The DE team and the AE team each have a Sprint Backlog for which they have each picked a group of tasks from the tasks assigned to it (in the Sprint Planning phase) for execution in the present iteration. The development team believes they can and promises to accomplish these tasks in the Sprint.

3.2.9. Sprint Execution

Under the guidance of the SM, the development team performs the required tasks to complete the selected functionality. Each Sprint consists of two sub-processes, the first for DE and the second for AE. These sub-processes support the evolutionary definition of variability, the modeling and design of work PL architectures, the development of reusable core resource sets, and the spinoff of SPL work artifacts.

3.2.10. Domain Engineering

After constructing the Sprint Backlog, DE will conduct a 4-week iteration to develop new resources and add them to the repository as reusable resources. The product line architecture and new resources produced in the DE phase will be incrementally merged in each sprint.

3.2.11. Application Engineering

Ideally, after the 4-week iteration in DE phase, the information base can provide resources meeting all the requirements, but in practice, resources often require further development. The AE team will use original or supplementary resources, which involve the selection and application of specific product requirements. The AE phase will receive product increments.

3.2.12. Daily Scrum

The Daily Scrum is a single 15-min session that a Sprint holds each day, asking each team participant to answer three questions, “What is done”, “What to do”, and “How to stop losses”, to make a plan for the next 24 h. The purpose of the daily meeting is to optimize team collaboration and performance and to arrange team progress.

3.2.13. Review and Retrospective

When summarizing the Sprint, a Review and Retrospective session is conducted to identify the improvement areas, which will be applied in the following Sprint. The review meetings are used to review product increments generated on the Sprint and to adjust the Sprint Backlog as needed, which leads to the refinement of the Sprint Backlog. The Retrospective meetings provide an opportunity for the team to self-examine themselves and develop a schedule for implementing changes in the next Sprint.

4. Evaluation

This section measures the results of our method and related work and explains the contribution of this method.

We selected the Capability Maturity Model Integration (CMMI) method [24] to evaluate the related work of the ScrumOntoSPL method. CMMI is a standard training and evaluation scheme for measuring the Capacity Level (CL) [25] of the development process. As shown in

Table 1. Four CLs of CMMI and the significance of their evaluation.

CL	Meaning	Description
0	Incomplete	Inconsistency in performance.
1	Initial	Solving performance problems.
2	Managed	Determine and monitor progress toward project performance goals.
3	Defined	Focuses on achieving both project and organizational performance objectives.

, we selected four CLs to identify and evaluate our approach in the following three steps.

In the first step, CMMI guidance refers to a Process Area (PA), that is, clustering related development processes. As shown in Figure 3, each phase of the method flow contains several keywords from the Scrum, SPL, and ontology models. Using the method of Takhom A et al. [26], we extracted a series of keywords that influence the behavior of the system.

Table 2. Mapping the keywords of Scrum, SPL, and ScrumOntoSPL to the PA of CMMI.

Abbr.	Process Area	Keyword
OPD	Organizational Process Definition	(K1) PO (K2) Tools and techniques (K3) Source Selection/Build (K4) Info Base (K5) Requirement-Matching Criteria
RD	Requirements Development	(K6) Mapping Rules (K7) DE
PI	Product Integration	(K8) Feature Backlog (K9) SPL Backlog SPL (K10) Product Backlog (K11) Sprint Planning (K12) AE
IPM	Integrated Project Management	(K13) Sprint Backlog (K14) Review and Retrospective (K15) Daily Scrum

shows the mapping results.

In the second step, we described the capabilities and performance of the development process through CL. As shown in

Table 3. The comparison table of related works considering keywords in Scrum, SPL, and ontology models with CMMI.

Keyword (K) for Developing Process with Capability Level 3		Capability Level of the Keywords Mapping Scrum, SPL, and Ontology Models with CMMI
Process Area	Keyword	Scrum	SPL	OntSRDT	OntoSoft	APLE	ScrumOntoSPL
OPD	K1	2	2	2	2	2	2
	K2	0	0	2	0	0	2
	K3	1	1	3	1	1	3
	K4	0	3	3	3	3	3
	K5	0	0	3	0	1	3
RD	K6	0	0	0	3	1	3
	K7	0	3	3	0	3	3
PI	K8	0	0	0	0	1	2
	K9	0	0	0	0	1	2
	K10	2	0	2	2	2	2
	K11	2	0	0	2	2	2
	K12	2	2	2	1	2	3
IPM	K13	2	0	0	2	2	2
	K14	2	1	1	2	2	2
	K15	2	0	0	2	2	2

, CL using the CMMI standard describes the six agile methods, including Scrum, SPL, APLE [13], OntSRDT [2], OntoSoft [16], and ScrumOntoSPL.

In the third step, we measured the grey relation between the software development methods based on Scrum, SPL, and ontology and keywords with capability level 3 according to the Gray Relation Analysis (GRA) method proposed by Deng [27]. The GRA can be used to quantitatively describe and compare system development and change trends. It can be used to analyze the degree of geometric similarity between the reference data column and several comparison data columns to judge whether the connection is strong or not, and it also reflects the degree of association between the curves. The specific calculation process of the GRA is represented as follows.

First, the characteristic sequence and the mother sequence are determined. The characteristic sequence, i.e., evaluation object, is defined as Formula (2), and the mother sequence, i.e., evaluation standard, is defined as Formula (3). Second, a dimensionless process on the index data is performed with Formulas (4) and (5). Dimensionless processing is carried out utilizing averaging, which is suitable for data with no obvious upward or downward trend. Third, the correlation coefficient $\mathsf{\varsigma }$ is calculated using Formulas (6)–(9), where the φ is the resolution coefficient, the $∆\mathrm{m}\mathrm{i}\mathrm{n}$ is the two-stage minimum difference, the $∆\mathrm{m}\mathrm{a}\mathrm{x}$ is the two-stage maximum difference, and the ${∆}_{\mathrm{i}\mathrm{k}}$ is the absolute difference between each point on the curve of each comparison sequence ${\mathrm{X}}_{\mathrm{i}}$ and each point on the curve of the mother sequence ${\mathrm{X}}_0$. Fourth, the relevance parameter $\mathsf{\delta }$ is calculated with Formula (10). Finally, the GRA results are evaluated using the principle that the greater the relevance, the better the evaluation result is.

$${[\mathrm{Y}}_1^{\prime }\cdots {\mathrm{Y}}_{\mathrm{n}}^{\prime }]=\left[\begin{array}{ccc}{\mathrm{y}}_1^{\prime }\left(1\right)& \cdots & {\mathrm{y}}_{\mathrm{n}}^{\prime }\left(1\right)\\ ⋮& \ddots & ⋮\\ {\mathrm{y}}_1^{\prime }\left(\mathrm{m}\right)& \cdots & {\mathrm{y}}_{\mathrm{n}}^{\prime }\left(\mathrm{m}\right)\end{array}\right],$$

(2)

$${\mathrm{Y}}_0^{\prime }={\left({\mathrm{y}}_0^{\prime }\left(1\right),{\mathrm{y}}_0^{\prime }\left(2\right),\cdots ,{\mathrm{y}}_0^{\prime }\left(\mathrm{m}\right)\right)}^{\mathrm{T}},$$

(3)

$$YD=\left(y\left(1\right)d,y\left(2\right)d,\cdots ,y\left(n\right)d\right),$$

(4)

$$y\left(k\right)=\frac{y\left(k\right)}{\stackrel{-}{y}},\stackrel{-}{y}\ne 0;k=1,2,\cdots n,$$

(5)

$$\varsigma \left(y_0\left(k\right),y_i\left(k\right)\right)=\frac{∆min+\phi ∆max}{{∆}_{ik}+\phi ∆max},$$

(6)

$$∆min=\genfrac{}{}{0pt}{}{min}{i}\genfrac{}{}{0pt}{}{min}{k}\left|y_0\left(k\right)-y_i\left(k\right)\right|,$$

(7)

$$∆max=\genfrac{}{}{0pt}{}{max}{i}\genfrac{}{}{0pt}{}{max}{k}\left|y_0\left(k\right)-y_i\left(k\right)\right|,$$

(8)

$${∆}_{ik}=\left|y_0\left(k\right)-y_i\left(k\right)\right|,$$

(9)

$${\delta }_{0i}=\frac{1}{N}{\sum }_{k=1}^N{\varsigma }_{ik}.$$

(10)

Here, we took OntSRDT as an example to further illustrate how to evaluate the relevant work in three steps. First, we analyzed the PA of the Sprint Backlog (K13), examination and review (K14), and daily Scrum meetings (K15) on OntSRDT (Table 2). Second, IPM aims to manage projects and stakeholder interventions according to a clipped, self-organized, and standard process (i.e., an aggregated, integrated, and well-defined process). The assessment results of the IPM (Table 3) show that the CL scores were 0, 1, and 0 for K13, K14, and K15, respectively. In the third step, the grey relation degree of the IPM for OntSRDT calculated using the GRA method is 44.40.

By comparing and analyzing the results, we found that our ScrumOntoSPL is very close to the CL 3 development processes in terms of the performance of each PA.

The grey relational degree between the six agile methods (Scrum, SPL, OntSRDT, OntoSoft, APLE, and ScrumOntoSPL) and the methods with capability level 3 are shown in

Table 4. Grey relational degrees between six agile methods (Scrum, SPL, OntSRDT, OntoSoft, APLE, and ScrumOntoSPL) and the methods with capability level 3.

	Scrum	SPL	OntSRDT	OntoSoft	APLE	ScrumOntoSPL
OPD	58.50	68.50	97.80	68.50	76.50	97.80
RD	0	33.30	33.30	33.30	50.00	100.00
PI	71.70	60.00	62.90	73.30	87.00	93.40
IPM	100.00	44.40	44.40	100.00	100.00	100.00

. To further compare the six agile methods, Figure 4 demonstrates the grey relational degree in histogram format. Table 4 and Figure 4 show that SPL, OntSRDT, OntoSoft, APLE, and ScrumOntoSPL provide development processes at CMMI capability level 3, covering all four PAs: Organizational Process Definition (OPD), Requirements Development (RD), Product Integration (PI), and Integrated Project Management (IPM). In addition, it can be seen from Figure 4 that both Scrum and SPLs have their own advantages, which can compensate for the weaknesses of the other methods, that is, Scrum can make up for the deficiencies of SPLs in PI and IPM, and SPLs can make up for the deficiencies of Scrum in OPD and RD. By comparing the OPD scores of OntSRDT and SPL, OntoSoft, and Scrum, it can be concluded that ontology can effectively improve OPD; our ScrumOntoSPL process is very close to the CL 3 development processes in terms of the performance of each PA; the grey relational degrees of ScrumOntoSPL in OPD, RD, PI, and IPM are higher than those of other methods. Therefore, the ScrumOntoSPL collaborative method is better than other methods to support companies in the implementation of software projects with a set of management principles and to guarantee the completion of projects.

5. Application Example

In this section, we describe a study of our proposed method by an example of application, which covers the whole software development process for the instrument product line based on the universal Instrument Microcontroller Chip (IMC). As a dedicated chip with highly integrated core functions of instrument devices, the IMC supports manufacturers in developing a series of differentiated instrument products. There is an urgent demand for reusing software resources during product line development. The ScrumOntoSPL method proposed in this paper can meet this requirement well, whereupon we developed a tool named IMC-Tool based on the ScrumOntoSPL method to assist project members in agile product line engineering. In the following subsections, we will shortly present the application context of IMC-Tool, show how to implement each activity specified in the ScrumOntoSPL approach, and finally, obtain the instrument product software corresponding to specific requirements.

5.1. Application Context

In the traditional development mode of instruments, engineers have to design a lot of different hardware interface circuits, driver software, function modules, and so on for each instrument product according to its own specific requirements. In this way, the software system coupling degree is high, and the software resources are difficult to manage scientifically and reuse efficiently.

The IMC-Tool aims to combine the ScrumOntoSPL approach with the necessary development services for instrument software and provide communicability for stakeholders. The IMC-Tool supports the quick development of a series of instrument products with the same core chip but different peripherals. According to the required information for heterogeneous peripherals, the IMC-Tool is used to customize and instantiate the semantic model and then parse the model instances to get the software codes from the reusable resources pool. Then, through customization or adjustment on the existing codes, the required components are iteratively generated, and finally, the instrument software with specific requirements is generated. Subsequently, we show how to apply the activities specified in the ScrumOntoSPL methodology to achieve this goal.

5.2. Ontology Model Building

We referred to a large number of existing models to establish the IMC domain ontology model IMC-O and explain its concept. Domain ontologies are defined to eliminate the divergence in concepts and terminology for achieving, sharing, and reusing consensus knowledge among multiple stakeholders. The IMC-O model mainly describes the non-functional properties of IMC software components, and it can be used to derive a more refined ontology for instrument software components. Figure 5 explains the key concepts of the IMC-O ontology.

The open source Protégé [28] tool is used in our work, as it enables users to build, visualize, manipulate, and preserve ontologies in multiple forms by supporting multiple ontology languages and providing a toolset for constructing domain models and knowledge-based ontology programs. Figure 6 shows a screenshot of the IMC-O ontology in Protégé, with the category hierarchy on the left and the pictorial representations of that hierarchy on the right.

Figure 7 shows the ontology instance of the IMC instrument in the knowledge base. The instrument is equipped with the HART, FF, and PROFIBUS industrial communication protocols, and the device ID is encoded with Ecode [29]. From the model example, it can be seen that the components of the instrument device include LCD and SPI components, which correspond to LCD driver and SPI driver software resources, respectively. The IMC-Tool can obtain heterogeneous peripheral information through the instance of the IMC-O model.

5.3. Development Process

Figure 8 shows the main interface of the IMC-Tool applying the ScrumOntoSPL approach proposed in this paper. The process of developing instrument product software using the IMC-Tool is presented as follows.

Step 1: The PO obtains the instrumentation product requirements from customer claims, performs requirement analysis, and creates the corresponding projects, products, and work items in IMC-Tool.

Step 2: Through ontology and work item mapping, IMC-Tool obtains the customized IMC-O model instances, as shown in Figure 7. Then, IMC-Tool implements the MRC process of mapping the ontology instances belonging to the IMCComponent and requirements to finally generate the SPL Backlog and Product Backlog. The PO can view the SPL Backlog and Product Backlog in the web interface.

Step 3: After obtaining the SPL Backlog and Product Backlog, the PO gathers all members to carry out the Sprint Planning process, in which the PO plans the functions to be realized in the current Sprint, its iteration time, and finally puts the planned tasks in the Sprint Backlog.

Step 4: After the completion of Sprint Planning, the development team gets the work items in the current Sprint and iteratively executes them. During each iteration, the PO can capture the current development progress of each product from the tool and hold daily meetings until the final product is delivered.

Step 5: When all of the work items are completed in the current Sprint, the PO obtains the final delivery product.

Step 6: After the product is delivered, the PO obtains customer feedback and holds a review and retrospective session to propose a plan for improvement in the next Sprint.

In conclusion, the case of the IMC-Tool shows that the ScrumOntoSPL method can dynamically manage multi-party collaborative development processes and changes to product development requirements, reuse software resources, rapidly develop software for product lines, and share the common understanding of ontology models among different developers or computer systems to reduce high coordination costs.

6. Discussion and Conclusions

To enhance the reuse of software resources, ScrumOntoSPL, a collaborative method of agile product line engineering based on APLE and ontology, is proposed in this paper. The proposed approach addresses the shortcomings of ASD and SPL. First, ScrumOntoSPL successfully combines the agile method Scrum with SPL by building and developing reusable software resources iteratively and incrementally. Second, it constructs a unified specification for describing requirements based on ontology in an agile environment, which solves the interoperability problem caused by conceptual inconsistencies and reduces the coordination costs between developers and customers. Finally, CMMI is introduced to evaluate our proposed method and further demonstrate that ScrumOntoSPL can support software resources reuse more comprehensively compared to other similar methods. In addition, we developed the IMC-Tool to apply the proposed method, and the case study provides empirical evidence for the feasibility of the ScrumOntoSPL method. In the IMC-Tool case, the construction and reuse of ontology model is a great challenge for the ScrumOntoSPL method, as it involves the semantic description of specific software fields by using an ontology model. In addition, how to measure the stability and reusability of an ontology model is an important issue in the IMC-Tool case. In conclusion, ScrumOntoSPL provides a collaborative method of agile product line engineering for software resource reuse, which can quickly match new product requirements and existing software resources and accelerate the speed of product development. Due to the limited time allotted for this study, there are still some deficiencies in the design of the proposed method. In future work, we will further improve our scheme, carry out more elaborate use cases, and solve the issues identified during the implementation.