A spl management method and system based on scrum architecture and ontology technology

Abstract

The application belongs to the field of software development, and particularly relates to an SPL management method and system based on Scrum architecture and ontology technology, which comprises the following steps: constructing an SPL management system, a manager acquires user stories, adopts an ontology model to match the user stories, generates requirement characteristics, and adds the requirement characteristics to a requirement characteristic to-do list; acquiring a component unique identifier and a component name of the requirement characteristic ontology, searching for matching according to the component unique identifier and the component name in an information base, and generating a requirement matching list; comparing the matching degree of each component of the requirement matching list with a set matching threshold, constructing a project according to the comparison result, and developing a product according to the constructed project; the application takes Scrum architecture and the concept and technology of SPL as the center, focuses on the requirement analysis stage, proposes to use a well-defined unified requirement description specification, reduces large-scale preliminary design, and improves software resource reusability and customizability.

Description

Technical Field

[0001] This invention belongs to the field of software development, specifically relating to an SPL management method and system based on Scrum architecture and ontology technology. Background Technology

[0002] With the rapid development of information technology, products running information system software have been widely applied across various industries. The increasing diversity of user needs presents manufacturers with the challenge of numerous product lines. Traditional software development models can no longer meet manufacturers' needs for shortening product line development cycles. Strengthening the reuse of software resources across product lines is a reasonable approach to improving product development speed and solving this problem. Currently, software resource reuse mainly includes requirement reuse, component reuse, and model reuse. Agile Software Development (ASD) and Software Product Line (SPL) have significantly enhanced the reuse of software resources in accelerating software product development, demonstrating substantial benefits in the software industry.

[0003] SPL (Solution-Driven Programming) is a practice- or plan-driven software development methodology that enables the large-scale production of a series of related products in the software industry. SPL comprises two main development processes: Domain Engineering (DE) and Application Engineering (AE). DE focuses on the problem domain, defining the commonalities and variability of SPL products to establish characteristics and describe requirements for developing and managing reusable core resources. AE focuses on resource reuse and leverages variability to develop software products. While SPL can rapidly develop high-quality, complex software, it often suffers from high coordination costs and slow development and release cycles when business requirements frequently change, causing software products to fail to keep pace with market demands. Therefore, this invention introduces the agile development framework Scrum. Scrum is an iterative framework for planning and guiding project processes, characterized by short iterative development cycles, reflection and introspection cycles, collaborative decision-making, rapid feedback, and continuous integration of code changes into the developing system. In the Scrum development process, the use of iterative and incremental methods allows for flexible and rapid development of software products, effectively addressing the problems encountered in the SPL development process.

[0004] However, in agile software projects, because documentation is not a priority, there is a lack of unified requirements description standards, resulting in excessively high coordination costs and difficulties in requirements management. Therefore, numerous studies have explored the feasibility and benefits of implementing SPL within the Scrum framework, namely, collaboratively addressing each other's weaknesses to achieve common goals: building and managing resources in the same domain, developing a series of software products, and promoting the reuse of software resources. However, the software development method of implementing SPL within the Scrum framework still faces the problem of high coordination costs. Software development is a complex process; each software product is a knowledge representation marked or stored in different ways by all relevant personnel, leading to frequent misunderstandings among developers, customers, and other parties during communication regarding product requirements. Summary of the Invention

[0005] To address this issue, this invention introduces ontology; in computer science, ontology is often used to formally capture descriptions of concepts and relationships, reducing the high coordination costs caused by poor communication among developers, clients, and other parties during software development. This invention proposes an SPL management method based on the Scrum architecture and ontology technology, which includes:

[0006] S1: Build the SPL management system and initialize the system;

[0007] S2: The manager obtains user stories, matches them using an ontology model, generates requirement features, and adds the requirement features to the requirement feature to-do list;

[0008] S3: Obtain the unique identifier and name of the component of the requirement feature ontology, and search for a match in the information database based on the unique identifier and name of the component. If no match is found, create a new component and add the new component to the product to-do list; if a match is found, sort the retrieved results by matching degree and generate a requirement matching list.

[0009] S4: Compare the matching degree of each component in the requirement matching list with the set matching threshold. If the matching degree is less than the matching threshold, add the requirement feature ontology to the product to-do list. Otherwise, search the component library by matching ontology. If the corresponding code component is found, add the requirement feature ontology and its similar code component to the SPL to-do list. If no corresponding code component is found, remove the item from the requirement matching list.

[0010] S5: Repeat steps S3 to S4 until the current requirement feature to-do list is cleared. Then, the Scrum expert convenes a Sprint planning meeting with all personnel to obtain the Sprint goals and the Sprint to-do list.

[0011] S6: DE uses the product backlog to develop variable resources and product line architectures and adds them to the repository;

[0012] S7: AE uses the SPL to-do list to iteratively develop new products.

[0013] Preferably, the process of matching user stories using an ontology model and ontology rules includes: preprocessing user data, which includes data cleaning and completion; extracting ontology fragments from the preprocessed data using ontology rules; wherein the ontology rules include concept rules, data type attribute rules, object attribute rules, hierarchical relationship rules, axiom rules, and instance rules, where concept rules are used to extract the conceptual features of the preprocessed user stories, data type attribute rules are used to extract the data type attributes of the user stories, object attribute rules are used to extract the object attributes of the user stories, hierarchical relationship rules are used to extract the hierarchical relationship features of the user stories, axiom rules are used to extract the axiom features of the user stories, and instance rules are used to extract the instances of the user stories; matching the concepts in the ontology fragments according to the concepts in the ontology model, and aggregating all ontology fragments with the same probability to generate requirement features.

[0014] Ideally, the manager is a Scrum role responsible for managing the to-do list and prioritizing it, and tracking product development.

[0015] Preferably, the Scrum expert is a Scrum role, responsible for assisting the project team in implementing an agile product line development and management process based on Scrum, SPL, and ontology.

[0016] Preferably, the Sprint planning meeting is a meeting attended by Scrum experts and the development team to plan the features to be implemented in the current Sprint.

[0017] An SPL management system based on Scrum architecture and ontology technology includes: a system management module, a requirements management module, and a product development module;

[0018] The system management module is used to manage user accounts, operation permissions, and data permissions. When the project starts, it enters team member information and assigns corresponding roles and related role permissions to team members, including user management, role management, menu management, and group management functions.

[0019] The requirement management module is used for the systematic management of reusable requirements; that is, the product owner uses feature forms to obtain user stories, and with the help of requirement workflow, requirement analysis, and requirement traceability management, refines, itemizes, and prioritizes product requirements.

[0020] The product development module is used to manage the work stages of the product development process, and realizes the functions of task management, component uploading, iterative development, and product delivery.

[0021] The beneficial effects of this invention are:

[0022] This invention proposes an SPL management method based on Scrum architecture and ontology technology. Centered on the concepts and technologies of Scrum architecture and SPL, it focuses on the requirements analysis phase. It proposes to use a well-defined unified requirements description specification to reduce large-scale early design, improve the reusability and customizability of software resources, and make software development more flexible and adaptable to changes. By adopting ontology technology, it reduces misunderstandings that may arise during communication between software developers, customers, and other parties. Attached Figure Description

[0023] Figure 1 This is an overview diagram of an SPL management method based on Scrum architecture and ontology technology according to the present invention;

[0024] Figure 2 This is an overview diagram of the DE development sub-process of the present invention;

[0025] Figure 3 This is an overview diagram of the AE development sub-process of the present invention;

[0026] Figure 4 This is an architecture diagram of the SPL management system based on Scrum architecture and ontology technology in an embodiment of the present invention;

[0027] Figure 5 This is a schematic diagram illustrating the key concepts of the IMC-O ontology in an embodiment of the present invention;

[0028] Figure 6 This is an example of the IMC-O ontology in an embodiment of the present invention;

[0029] Figure 7 This is a flowchart illustrating how the ontology model and ontology rules of this invention match user stories. Detailed Implementation

[0030] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0031] An SPL management method based on Scrum architecture and ontology technology, the method includes:

[0032] S1: Build the SPL management system and initialize the system;

[0033] S2: The manager obtains user stories, matches them using an ontology model, generates requirement features, and adds the requirement features to the requirement feature to-do list;

[0034] S3: Obtain the unique identifier and name of the component of the requirement feature ontology, and search for a match in the information database based on the unique identifier and name of the component. If no match is found, create a new component and add the new component to the product to-do list; if a match is found, sort the retrieved results by matching degree and generate a requirement matching list.

[0035] S4: Compare the matching degree of each component in the requirement matching list with the set matching threshold. If the matching degree is less than the matching threshold, add the requirement feature ontology to the product to-do list. Otherwise, search the component library by matching ontology. If the corresponding code component is found, add the requirement feature ontology and its similar code component to the SPL to-do list. If no corresponding code component is found, remove the item from the requirement matching list.

[0036] S5: Repeat steps S3 to S4 until the current requirement feature to-do list is cleared. Then, the Scrum expert convenes a Sprint planning meeting with all personnel to obtain the Sprint goals and the Sprint to-do list.

[0037] S6: DE uses the product backlog to develop variable resources and product line architectures and adds them to the repository;

[0038] S7: AE uses the SPL to-do list to iteratively develop new products.

[0039] A specific implementation of an SPL management method based on Scrum architecture and ontology technology, such as... Figure 1As shown, firstly, the SPL management method based on the Scrum architecture and ontology technology establishes a unified requirement description specification through ontology, eliminating the high coordination costs between agile teams; secondly, it creates new variants by refactoring existing components of the product line, enabling dynamic management of requirement changes and improving product quality; finally, it retains the customer-centric agile delivery method derived from agile methodologies, solving the problems of long software development cycles and slow release processes. The development process of this method is as follows: the product owner obtains user stories and performs requirement analysis, using tools to select or build corresponding requirements to provide feedback on user stories; the product owner compiles a product backlog and an SPL backlog to accumulate new and variable requirements; the Scrum expert convenes all project team members for a Sprint planning meeting, where the iteration tasks for this Sprint are determined; the DE and AE development phases iteratively develop software resources and deliverables; after a Sprint is completed, the Scrum expert convenes all personnel for a review and retrospective meeting.

[0040] like Figure 2 As shown, after receiving tasks from the Sprint backlog, the domain team will conduct iterative development for four weeks. The domain team will build the work product line architecture and develop new resources. The work product line architecture is developed incrementally using work products from the Sprint Backlog, including only currently required functionality. The work product line architecture will have variable, generic components, with the implementation of variable functionality handled by the application team. As new resources are added to the repository, the work product line architecture will be updated in further iterations, keeping the system in sync with evolving requirements. If the domain team receives a request from the application team, it can extend the product line architecture. New resources developed during this phase will be added to the repository as reusable core resources for reuse in other projects. In the DE phase, the work product line architecture and new resources will be incrementally merged in each Sprint.

[0041] like Figure 3 As shown, after receiving tasks from the Sprint backlog, the Application Engineer (AE) will begin a four-week iterative development phase alongside the Domain Engineer (DE). Ideally, the software resources within the work product line can cover all requirements, but in most real-world scenarios, further development is needed. This additional development occurs during this phase. Therefore, this is the actual development phase. The application team will build individual or specific products using reusable resources. This involves selecting and applying the necessary variations for a specific product. Reusable resources may already exist and will be reused as is or adapted. In addition, the application team can request the domain team to expand the product line. If the domain team accepts the request, product-specific requirements will be developed as new resources according to the application team's request. The result of the AE phase is: product increments.

[0042] The process of matching user stories using an ontology model includes: preprocessing user data, which includes data cleaning and completion; extracting ontology fragments from the preprocessed data using the ontology model; wherein the ontology model includes concept rules, data type attribute rules, object attribute rules, hierarchical relationship rules, axiom rules, and instance rules. Concept rules are used to extract the conceptual features of the preprocessed user stories, data type attribute rules are used to extract the data type attributes of the user stories, object attribute rules are used to extract the object attributes of the user stories, hierarchical relationship rules are used to extract the hierarchical relationship features of the user stories, axiom rules are used to extract the axiom features of the user stories, and instance rules are used to extract the instances of the user stories; matching the concepts in the ontology fragments according to the concepts in the ontology model, and aggregating all ontology fragments with the same probability to generate requirement features.

[0043] Specifically, the process of extracting ontology fragments from preprocessed data using an ontology model includes:

[0044] Step 1: Perform a top-down tag pair query on the preprocessed data and create instances; specifically, this includes: querying tag pairs from top to bottom in the preprocessed data, and then creating corresponding instances using the ontology generator. For example, through... <imccomponent>< / imccomponent> The tag is used to extract the concept IMCComponent contained in the ontology, and a concept instance is created through the ontology producer.

[0045] Step 2: Obtain the data corresponding to the tag pairs; filter out the object attribute tags, obtain the object attributes based on the object attribute tags, and add the object attributes to the concept instance.

[0046] For example, the data corresponding to the tag pair includes <imccomponent>< / imccomponent> The next tag pair is <hasserviceoperationproperties>< / hasserviceoperationproperties> All tag pairs describing object attributes are <hasxxx>< / hasxxx> The label pairs are used to obtain the object property hasServiceOperationProperties, which is then added to the created IMCComponent concept instance.

[0047] Step 3: Repeat the query in Step 2 until the query is found. <serviceoperationproperties>< / serviceoperationproperties> Then repeat step one to create the corresponding ServiceOperationProperties instance, and link the object properties to the ServiceOperationProperties instance to obtain the hierarchical relationship characteristics between instances.

[0048] Step 4: Repeat the query in Step 2 until the query is complete. <operatinginformation>< / operatinginformation>If no tag pair for the object property is found, the found tag pair will be used as the data type property operatingInformation of ServiceOperationProperties.

[0049] Step 5: Repeat the query in Step 2 to query the attribute value of the data type property "Memory serviceinterface", create an instance of "Memory service interface", and specify the type as "operatingInformation".

[0050] Step 6: Once all tag pairs have been queried, generate an ontology fragment.

[0051] In this embodiment, the process of calculating the matching degree includes: randomly selecting two component entities from the demand matching list; selecting two corresponding nodes from the two entities, and calculating the matching degree of the two nodes using the distance-based Jaccard coefficient; calculating the mean of the matching degrees of all nodes, and using this mean as the matching degree of the two components. The formula for calculating the matching degree of two nodes is:

[0052]

[0053] Where K represents the matching value, v 11 v represents the first node in the first set of ontology concept instances. 21 S represents the first node in the second set of ontology concept instances, and S represents the node matching value K(v) describing the attribute and attribute value. 11 ,v 21 The function of ), e t Represents ontology The data type attribute of a single node, f t e t The attribute value, e c Represents ontology The data type attribute of a single node, f c e c The attribute value, K sim K represents a function based on path length and depth. Jaccard Let Jaccard coefficient represent the shortest path length parameter, γ represent the shortest path depth parameter, and l represent e. t ,e c The shortest path length in the semantic network, where h is the depth of the words contained in the selected semantic network.

[0054] The formula for calculating the matching degree between two components is:

[0055]

[0056] in, Indicates the first component. The second component is represented by N, the total number of nodes is represented by K, and v represents the matching value. 1k v represents the k-th node in the first set of ontology concept instances. 2k This represents the k-th node in the second set of ontology concept instances.

[0057] An SPL management system based on Scrum architecture and ontology technology, such as Figure 4 As shown, the system includes: a system management module, a requirements management module, and a product development module. The system management module manages user accounts, operation permissions, and data permissions, such as assigning roles and related permissions to system users. Its main functions include user management, role management, menu management, and group management. The requirements management module publishes, stores, and manages requirements resource information, and performs task publishing, iteration planning, and task allocation for requirements. The product development module manages the work stages of the product development process, specifically including component uploading, task management, iterative development, and product delivery. Furthermore, it involves tracking the progress of the development process, mainly including Sprint meetings and progress burn-down charts.

[0058] like Figure 5 As shown, this paper establishes the IMC-O domain ontology model for Instrument Microcontroller Chip (IMC) by referencing numerous existing models and explains its concepts. Defining a domain ontology aims to eliminate discrepancies in the concepts and terminology of software requirements, achieve consensus knowledge, and facilitate sharing and reuse among multiple stakeholders. The IMC-O model primarily describes the non-functional attributes of IMC software components, and IMC-O can be used to derive more refined instrument software component ontologs.

[0059] like Figure 6 As shown, a box represents an instance, which can contain attributes, and an edge represents an object attribute that describes the relationship between two instances. Multiple instances can constitute an instrument device instance. Figure 6 (a) represents instrumentation equipment instances, primarily consisting of equipment ID instances and software component instances. The attributes of an equipment ID instance include: identification system and ID encoding. Figure 6(b) Software component instances, mainly including service operation instances and service class instances. Service operation instances include service object information instances, whose attributes include peripheral function descriptions and service constraint information. Service class instances include function information instances, manufacturing information instances, runtime information instances, component granularity instances, and component type instances; function information instances include function description instances, whose attributes include communication protocol, peripheral driver, and functional module; manufacturing information instances include component information instances, whose attributes include component name, component version, development language, and component provider; component information instances' attributes include identification system and ID encoding; runtime information instances' attributes include hardware environment and software environment.

[0060] like Figure 7 As shown, the process of matching user stories using the ontology model and ontology rules includes the following steps: First, user stories are preprocessed, and then different ontology fragments are extracted using mapping rules. The mapping rules consist of six parts: concepts, data type attributes, object attributes, hierarchical relationships, axioms, and instances. These rules analyze the user stories and transform them into corresponding ontology fragments. Finally, the concepts in the ontology fragments are matched according to the concepts in the ontology model, and ontology fragments with the same concepts are collected to generate a feature requirement ontology.

[0061] The above-described embodiments further illustrate the purpose, technical solution, and advantages of the present invention. It should be understood that the above-described embodiments are merely preferred embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made to the present invention within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. An SPL management method based on Scrum architecture and ontology technology, characterized in that, include: S1: Build the SPL management system and initialize the system; S2: The manager obtains user stories, matches them using an ontology model, generates requirement features, and adds the requirement features to the requirement feature to-do list; S3: Obtain the unique identifier and name of the component of the requirement feature ontology, and search for a match in the information database based on the unique identifier and name of the component. If no match is found, create a new component and add the new component to the product to-do list. If a match is found, the retrieved results will be sorted by matching degree, and a list of required matches will be generated. S4: Compare the matching degree of each component in the requirement matching list with the set matching threshold. If the matching degree is less than the matching threshold, add the requirement feature ontology to the product to-do list. Otherwise, search the component library by matching ontology. If the corresponding code component is found, add the requirement feature ontology and its similar code component to the SPL to-do list. If no corresponding code component is found, remove the item from the requirement matching list. S5: Repeat steps S3 to S4 until the current requirement feature to-do list is cleared. Then, the Scrum expert convenes a Sprint planning meeting with all personnel to obtain the Sprint goals and the Sprint to-do list. S6: DE uses the product backlog to develop variable resources and product line architectures and adds them to the repository; S7: AE uses the SPL to-do list to iteratively develop new products.

2. The SPL management method based on Scrum architecture and ontology technology according to claim 1, characterized in that, The process of matching user stories using an ontology model includes: preprocessing user data, which includes data cleaning and completion; extracting ontology fragments from the preprocessed data using the ontology model; wherein the ontology model includes concept rules, data type attribute rules, object attribute rules, hierarchical relationship rules, axiom rules, and instance rules. Concept rules are used to extract the conceptual features of the preprocessed user stories, data type attribute rules are used to extract the data type attributes of the user stories, object attribute rules are used to extract the object attributes of the user stories, hierarchical relationship rules are used to extract the hierarchical relationship features of the user stories, axiom rules are used to extract the axiom features of the user stories, and instance rules are used to extract the instances of the user stories; matching the concepts in the ontology fragments according to the concepts in the ontology model, and aggregating all ontology fragments with the same probability to generate requirement features.

3. The SPL management method based on Scrum architecture and ontology technology according to claim 1, characterized in that, The process of calculating the matching degree includes: randomly selecting two component entities from the demand matching list; selecting two corresponding nodes from the two entities and calculating the matching degree of the two nodes using the distance-based Jaccard coefficient; calculating the mean of the matching degrees of all nodes and using this mean as the matching degree of the two components.

4. The SPL management method based on Scrum architecture and ontology technology according to claim 3, characterized in that, The formula for calculating the matching degree between two nodes is: Where K represents the matching value, v 11 v represents the first node in the first set of ontology concept instances. 21 S represents the first node in the second set of ontology concept instances, and S represents the node matching value K(v) describing the attribute and attribute value. 11 ,v 21 The function of e t Represents ontology The data type attribute of a single node, f t e t The attribute value, e c Represents ontology The data type attribute of a single node, f c e c The attribute value, K sim K represents a function based on path length and depth. Jaccard Let Jaccard coefficient represent the shortest path length parameter, γ represent the shortest path depth parameter, and l represent e. t ,e c The shortest path length in the semantic network, where h is the depth of the words contained in the selected semantic network.

5. The SPL management method based on Scrum architecture and ontology technology according to claim 3, characterized in that, The formula for calculating the matching degree between two components is: in, Indicates the first component. The second component is represented by N, the total number of nodes is represented by K, and v represents the matching value. 1k v represents the k-th node in the first set of ontology concept instances. 2k This represents the k-th node in the second set of ontology concept instances.

6. The SPL management method based on Scrum architecture and ontology technology according to claim 1, characterized in that, The manager is a Scrum role responsible for managing the backlog of tasks and prioritizing them, and tracking product development.

7. The SPL management method based on Scrum architecture and ontology technology according to claim 1, characterized in that, A Scrum expert is a Scrum role responsible for assisting the project team in implementing an agile product line development and management process based on Scrum, SPL, and ontology.

8. The SPL management method based on Scrum architecture and ontology technology according to claim 1, characterized in that, The Sprint Planning Meeting is a meeting attended by Scrum experts and the development team to plan the features to be implemented in the current Sprint.

9. An SPL management system based on Scrum architecture and ontology technology, the system being used to execute any one of the SPL management methods based on Scrum architecture and ontology technology as described in claims 1 to 8, characterized in that, It includes: a system management module, a requirements management module, and a product development module; The system management module is used to manage user accounts, operation permissions, and data permissions. When the project starts, it enters team member information and assigns corresponding roles and related role permissions to team members, including user management, role management, menu management, and group management functions. The requirement management module is used for the systematic management of reusable requirements; that is, the product owner uses feature forms to obtain user stories, and with the help of requirement workflow, requirement analysis, and requirement traceability management, refines, items, and prioritizes product requirements. The product development module is used to manage the work stages of the product development process, and realizes the functions of task management, component uploading, iterative development, and product delivery.

Images