BPriS: Disciplined Agile Delivery Planning Method Based on Work Items List Pattern Applied to Prioritized Semantically Coupled Software Functions Derived from Business Process Model and Software Functional Pattern

Abstract

Common practice in agile delivery planning is based on user requirements-related artifacts. However, an aspect of business process alignment to software product functions comes into focus in the phase of inception of enterprise-aware disciplined agile software projects. This research proposes a method for mapping business process model elements to sets of semantically coupled and prioritized software functions to obtain ordered software product backlog, i.e., work items list. These software functions are derived from primitive business processes and software functional patterns. The mapping table enables assignment of primitive business processes to categorized software functions. Derived and prioritized software functions are related to a work item list pattern according to selected technology implementation. This way, a prioritized work items list is formulated, which enables development iteration planning. This method could be useful in software functional design alternatives comparison, change management, multi-project integration of software modules to support business processes in information systems, etc. Feasibility of the proposed method has been demonstrated with a case study, related to the development of a billing and reporting software utilized in a private hospital. This case study shows usability of the proposed method in the case of two related development projects that enable software functionality enhancement.

1. Introduction

Agile software projects (ASFs) are conducted with an iterative and incremental approach [1], based on project scope definition [2] and project planning. According to Kula et al. [3], the most important factors that influence on-time delivery in large-scale agile software development are requirements refinement, task dependencies and organizational alignment. Bisikirskiene et al. [2] propose using multiple models and other forms in requirements elicitation to enable more precise formulation of the agile software development project scope—user stories, UML (Unified Modeling Language) use case diagram, UML activity model, domain class model, requirements list and SysML requirements.

Process-aware information systems (IS) are created to support, control or monitor business processes. Fitzgerald and Stol [4] propose a close relationship between business needs and continuous software engineering with the BizDev approach. The importance of business process modeling as an essence for software design within enterprise information systems has been particularly emphasized for data flow representation in the work of Aleryani [5]. Trkman et al. [6] introduce the BuPUS method that utilizes business process models in understanding relationships between user stories [6]. Agile software requirements prioritization includes estimation of the business value for each preliminary requirement, before the prioritization process with other relevant factors [7]. The Disciplined Agile Delivery (DAD) [8] framework includes enterprise awareness as one of the basic principles.

The business process model could be a basis for the definition of a software product scope and delivery planning, especially in enterprise-aware/process-aware information systems development. Previous research results did not provide a straightforward method to be conducted from business process models to work items list (WIL) for software development. This research contributes with a method that integrates business process models, software functional patterns (SFP) and work items list patterns (WILP) to support enterprise-aware software design and development planning within Disciplined Agile Delivery methodology. The key contributions of this research are related to the following:

• The concept of Disciplined Agile Functional Ordered Work Items List (DA-FOWIL)—includes an ordered work items list, based on software functions (SF) (derived from business processes and software functional patterns) and work items list patterns. The created DA-FOWIL work items list could be used in iterations planning of DA-based software development;
• The method BPriS (Disciplined Agile Delivery Planning Method Based on Work Items List Pattern Applied to Prioritized Semantically Coupled Software Functions Derived from Business Process Model and Software Functional Patterns)—for the creation of DA-FOWIL, based on business process model mapping to software functions, software development prioritization, semantic coupling of software functions, technology-dependent software functional patterns and work items list patterns.

The rest of this work is organized as follows: Section 2 provides a brief explanation of basic terms related to Disciplined Agile Delivery and business process modeling; Section 3 provides short literature review regarding business process mapping to software design, software semantic coupling, software functional patterns, agile software development planning and automation and agile software release planning and prioritization; Section 4 describes the proposed method; Section 5 illustrates the results of proposed method utilization applied in accounting software development in a private general hospital; Section 6 summarizes method feasibility and limitations; and Section 7 bring conclusions and future work directions.

2. Background

2.1. Disciplined Agile Delivery Approach

Disciplined Agile (DA) [9] is a strategic approach that enables using different agile methods in organization of any kind of work, to enable best fit and support improvements to Way of Working (WoW).

Disciplined Agile Delivery (DAD) [8] is a process decision framework with key characteristics: people first, goal-driven, hybrid agile, learning-oriented, full delivery lifecycle, solution-focused, risk-value lifecycle, enterprise aware. Disciplined Agile Delivery is closely related to IT solutions development and project management, with related activities in Portfolio Management, Program Management, Product Management and Release Management [9].

One of the frequently utilized agile methods with an appropriate lifecycle is Scrum-based DA methodology (DA Scrum) [10]. Agile Alliance defines Scrum (AA Scrum) as a process framework that could be used to manage product development [11]. Scrum-based DA (DA Scrum) keeps the same concepts, but it names it differently—instead of “product backlog” in AA Scrum [12], there is “work items list” in DA Scrum [10], and “sprint” in AA Scrum is named “iteration” in DA Scrum, while “sprint backlog” from AA Scrum is named “iteration backlog” in DA Scrum. The DA Scrum lifecycle is presented in Figure 1 with a business process model, visualized according to [10].

According to [13], product backlog is a list of activities (i.e., work items) related to new features, bug fixes or infrastructure changes that a team should perform to achieve a specific outcome—it is a single source of what teams works on, and it usually consists of work items in the format of user stories. According to [14], “requirements (product) backlog” is an ordered list of requirements that needs to be addressed, where top listed items should be considered with greater detail than lower-priority requirements at the bottom of the list. In earlier versions of Scrum, product backlog was a prioritized list of functional/usage requirements, often captured as user stories [14].

2.2. Business Process Modeling

Enterprise information systems consist of both software and hardware structures [15] that provide support to all business processes continuously [16]. There are two essential aspects within development of software for information systems—functionality and data [17]. There could be different software and hardware architectures proposed, but they should be evaluated in the business process context and business value for the company [18], via IT governance methods and tools [19], but also regarding stakeholders’ functional and non-functional requirements [15]. Business process mapping is used in information systems development, where it is relevant to keep the proper alignment between organizational business activities and events [20,21,22] supported by information systems elements [23]. Moreover, business process management (BPM) [24] is often closely related to utilization of information technologies in digital transformation of enterprises [25].

Enterprise business process modeling [26] is the most important element in the design of Enterprise Resource Planning (ERP) systems [27,28]. Business process mapping is considered as a technique for constructing a business process model [29], which shows relationships between activities, people, data and objects involved in the production of a specific output. Business process models are created in the process of business process mapping to represent the key activities in the organization, their connections with working environment and mutual collaboration, with respect to work roles assignments and responsibilities. Business process mapping has been used as a term to address presentation of enterprise organization and business processes in business process models [30], aiming to gain a better understanding of the organization [30] and management improvements [31]. According to [32], business processes in an enterprise can be categorized as management process, operational process and the supportive process. Operational processes enable implementation of the system’s purpose; supportive processes provide resources, while managerial processes define business rules and perform monitoring and regulation of other processes.

The essential elements of any business process model are activities/processes. Van Der Aalst et al. [33] introduce the term workflow schemas (workflow process definitions) as used to specify which activities need to be executed and in what order (i.e., the routing or control flow). Elementary activities (atomic) are connected with transitions, and they are performed by roles in organization, such as humans or devices, executed manually or by using applications. Russell et al. [11] define workflow model as a description of business process with sufficient detail to enable execution by workflow management system.

There are many techniques, process languages, notations and standards for modeling enterprise processes [27], such as Data Flow Diagrams (DFD) (Yourdon & Constantine [34], DeMarco [35], Gane & Sarson [36]), Integration Definition for function Modeling (IDEF0), Business Process Model and Notation (BPMN) [37], UML activity diagrams, Petri nets [38] and others [39]. Dijkman et al. [40] made a comparison and detailed presentation of different business process models. Figure 2a presents the abstract DFD, based on the Yourdon–DeMarco notation, with hierarchical organization, starting with the first, a context diagram and only one process, followed by series of other diagrams, representing the decomposition of processes and more details of their internal communication and data storage. Processes can be represented at diverse levels of complexity or as primitive processes, which are the smallest processing units, and they could not be further decomposed. Other types of business processes representation, i.e., business process diagrams, include internal organization of processes and data storages responsibilities by categorizing them under organizational units’ swim lanes. Figure 2b illustrates a business process diagram (similar to BPMN) with chronological organization of primitive business processes (PBP) and data stores (resources) in organizational swim-lanes, emphasizing the time-related mutual dependency of processes and the responsibility of organizational units. Figure 2a is an example of hierarchical decomposition of business processes and gradual inclusion of details, while Figure 2b is an example of algorithmic approach to business process model representation, where all business processes are presented.

3. Related Work

This paper focuses on several main areas of interest, which were also addressed in previous research: (1) business process mapping to software design, (2) software semantic coupling, (3) software functional patterns, (4) agile software development planning and automation and (5) agile software release planning and prioritization; (6) workflow patterns and software development work items list patterns.

3.1. Business Process Mapping to Software Design

Habba et al. [41] systematically analyze the relationship between business requirements, processes and software systems that support them. Roseman et al. [42] consider business process model from goals, context, structure and information technology application aspects. Recently, the use of IT solutions to support business processes is monitored by using process mining tools and algorithms [20].

To enable automation, business process models are transformed to particular BPm notations, such as XPDL [43], event-driven process chains [31], derivation of IDEF0 to BPEL4WS [44], communicative event diagram to state machines [45] and BPEL to BPMN [46].

To support appropriate software design and development, business process models are transformed into other types of models, such as data models [47], class diagrams [48] and use cases [49]. Business process models could be the basis for software user interface [50] or user interface flow model derivation [51]. BPM can be used in combination with other types of models (use cases) to enable software development and workflow automation [52]. Aleryani [5] compare Data Flow Diagrams (DFD) and UML use case diagrams to represent data flow within information systems development.

Aysolmaz and Demirörs [53] proposed a method for deriving user requirements for processes automation from BPM. Similarly, a business process model could be derived from early requirements analysis and created to adjust to information technology support, such as service-oriented software implementation [54]. Further efforts were made towards automated derivation of software services and web services from business process model repositories [55] with the use of semantic technology [56,57], such as in the case of Fundamental Business Process Modeling Language (FBPML) mapping to the Web Services Ontology (OWL-S) [58]. Since there are different BPM notations, a meta-model has been developed in [59], to represent a basis for derivation of web services that support grid-based service-oriented architectures.

Business process and activities mapping to software solutions could be considered at the architecture level [60], with business domain aligned to software components [61,62]. Dalal et al. [27] propose a framework for mapping enterprise process models into ERP software system layers: (1) Front-end layer (user-oriented graphical representation), (2) Back-end layer (formal representation of business processes automation support, with Petri nets). Trends in business process mapping to software design could be presented as directions toward mapping business architecture to a component-based software architecture [63] and service-oriented computing with web services [64]. Orchestration and choreography could be utilized by using Business Process Execution Language for Web Services (BPEL4WS) [65].

Dalal et al. [27] consider aspects of process improvements with business process reengineering [66] and technology advancements. Having business processes variability [67] considered, Roseman et al. [42] explore business process flexibility and context awareness. Cognini et al. [68] elaborate business process flexibility in the context of software systems perspective, while Jarzabek and Hitz [61] consider business processes evolution impact to component-based software development. Changes in business processes are particularly frequent in the business rules domain, so relating the evolving business rules to software design to keep the software useful has been addressed in [69].

Contemporary solutions in relating business processes to software functions are directed towards moving from Business Process Models to Process-oriented software systems [70] and from Process Modeling to Workflow Automation Infrastructure [71]. BPMN models are not considered as semantically rich enough, so Semantic Object Model (SOM) modeling is proposed to be used to present workflow for automation [72]. Recent research relates BPM with the developed software, source code [73] or executable solutions (example of service-based software [74]).

3.2. Software Semantic Coupling

Cohesion and coupling are two structural characteristics of a software solution that could be related to different software elements. Coupling could be determined at feature level [75], where each software feature implementation usually includes multiple classes, but mostly it is related to classes, organized in modules in object-oriented programming [76]. Ideally, there should be strong internal connections (cohesion) and weak external dependency (coupling) between classes in the same module—the opposite would lead to difficulties in maintenance [76].

Structural and semantic (text-based) aspects of coupling have been examined, and measurement approach and metrics were proposed in [76]. Bavota et al. [77] define several categories of coupling: structural, dynamic, semantic, and logical coupling among classes, where semantic coupling is detected as being part of source code vocabulary. Fregnan et al. [78] conducted systematic literature review where most frequently used categories of software coupling are extracted as: (a) structural coupling (relations in source code with code static inspection if called methods, inheritance and accessed variables); (b) dynamic coupling (determining relations between classes and methods in run-time); (c) semantic coupling (relations in source code based on code lexicon); (d) logical coupling (determined from entities that frequently changed together).

Some other terms related to coupling detection and measurements were proposed, such as from Poshyvanyk and Marcus [79] and Revelle et al. [75]. Poshyvanyk and Marcus [79] propose the term conceptual coupling, which could be determined from semantic information in source code comments and identifiers. Revelle et al. [75] propose feature coupling and appropriate metrics based on both structural (source code dependencies) and unstructured/semantics (comments, documentation, identifiers) parts of software.

Semantic coupling among classes in object-oriented software is usually based on extraction of words from classes, where classes are treated as documents and all non-keywords (identifiers, i.e., names of classes, methods, attributes, and comments) are considered to be placed in the software corpus (set of words for semantic processing) [80]. To process semantic coupling measurements, words are taken from software zones [76]: Java Doc documenting results, comments, member variables (attributes and properties) and (methods) signature zone. Semantic coupling (lexical similarity) between pairs of classes in object-oriented software was determined in a proposed algorithm for determining Semantic Coupling Matrix, based on extraction, tokenization (replacing words with tokens) and normalization of obtained results. Gethers and Poshyvanyk [81] propose an approach of treating similar words in a source code from different classes (treated as documents) as they belong to particular topic (set of concepts). They propose an approach for the utilization of Relational Topics Models in conceptual coupling measurements.

Coupling and cohesion in object-oriented systems has been addressed from measurement aspect and definition of appropriate metrics [82]. Metrics for combined structural and semantic coupling in object-oriented software has been proposed by Alenezi and Magel [83]. Conceptual coupling and cohesion were examined empirically by Újházi et al. [84], with prediction of possible errors in classes of large software systems. Not only classes, but also web services can be evaluated from the aspect of semantic relationships and coupling and this was examined in [85], based on utilization of Latent Semantic Index (LSI)—a well-known technique for measurement of semantic relationship between text-based documents.

3.3. Software Functional Patterns

Riehle and Züllighoven [86] define the concept of a pattern as an abstract form that keeps repeated in specific contexts—it consists of distinguishable components and their relations; it is used to create, identify or compare instances of this pattern. In [86], authors relate the term pattern to models and different variations in software development—conceptual patterns, design patterns and programming patterns. Usually, Unified Modeling Language (UML) is used to present software patterns [87]. Costa Seco et al. [88] propose rich template language OSTRICH that was designed to simplify creation of reusable software components. In [88], authors propose software template composition mechanism, based on templates nesting that promotes code reuse.

Software patterns are commonly related to design and organization of classes in object-oriented programming, and they are utilized as conventional guidelines during typical object-oriented software development [89]. Al-Obeidallah et al. [90] conducted a survey, in aim to systematize design pattern detection approaches and tools.

Software structural design patterns [91] could be automatically detected and measured, by mapping object-oriented code to the essential representation by using abstract object language (AOL), based on UML class diagram. This detection of software patterns (also named design recovery [92]) could be useful in code understanding, design-to-code traceability and quality assessment. Nguyen et al. [93] propose implementing graph-based mining of multiple object usage patterns, which could be useful to assist developers in programming, detecting usage anomalies and code smells. Software design patterns are extensible and used in software frameworks [94]. Very often, utilization of frameworks is hard due to lack of proper documentation, but sample-based extraction of concept-implementation templates (that use framework parts in implementation) was proposed in [95], as a means to speed up using existing classes from framework.

The use of business process models reached the maturity level, so they are analyzed from the aspect of business process models repositories and patterns [96]. Barros [97,98] propose encapsulating business knowledge and logic in high level business objects, which could be reused in different software projects, by inheritance, adding specific features and configuration. This way, based on business process patterns, Barros proposes creating business process frameworks that will enable reusable components to develop complex software solutions. Smirnov et al. [96] proposes the concept of action patterns as subset of activities within business processes that often appear together and could be assigned to business objects as software implementation. Action patterns could be related to different business domains.

Röder [99] proposes specifying usability features (commonly used software functions) as patterns and templates, to be collected in a catalog of use-case based specifications. These specifications are extended with additional explanation in which situations and how these software features can be integrated in larger systems. Software functional patterns are used to support development of different types of software (communication software [100]), particular software development approaches (parallel computing [101]) or software modules (security [102], user interface [103]). Software functional patterns are also used in creating software product lines, to preserve behavior of existing software products [104,105].

3.4. Agile Software Development Planning and Automation

Agile software development, in the context of iterative/incremental approach, induces the need for continuous planning [106], delivery and integration (CD/CI) activities [107]. Suomalainen et al. [106] emphasize that main elements of continuous planning in agile and lean development are organizational, strategic and business planning. Particularly for software development, integration of product data management (PDM), software configuration management (SCM), and customer relationship management (CRM) play an important role, especially for ERP software development [108].

There are several important aspects of software delivery planning, in relation to broader categories of software development planning, i.e., software project management—development scheduling [109,110], requirements elicitation and refinement [3], organizational support [107,111] and risk analysis in evolutionary requirements engineering and software delivery [112]. To enable continuous software delivery, the development process should be appropriately selected [113], the software architecture should be adjusted [114,115] and domain experts integrated in the software delivery pipeline [116]. Communication and coordination of client and vendor representatives [117] influence software development performance [110]. Neely and Stolt [113] emphasized the impact of the appropriate selection of software development process model (such as Scrum, Kanban, etc.) to the continuous delivery performance and described experiences in shifting from Scrum-based sprints to a continuous delivery approach.

The quality aspect of software delivery has been addressed in [118], with particular emphasis on using artificial intelligence tools to predict and improve software reliability and product quality. One of very important aspects that influence software delivery quality is related to organizational maturity, which is often assessed according to Capability Maturity Model (CMM) and Goal Question Metrics (GQM) approach, which enables setting of appropriate Key Process Metrics [119]. Different software metrics could be defined and appropriate data obtained from the agile software development process (such as from log files, to monitor or predict the process outcome, i.e., product quality [120].

Experiences from continuous software delivery practice have been presented with a case study of a large financial organization [115], where automation support to frequent requirements changes brings product releases with early discovery of errors, reduced cycle time, better adoption of coding standards and guidelines, but also better management of technical debts. Ska and Janani [107] conducted a comprehensive overview of continuous delivery and integration in the context of frequent changes in software development, with emphasis on automation of software development, version control and release processes, within the DevOps practice [121]. Steffens at al. [122] contribute with the proposed enhanced automated system for continuous software delivery support, improving flexibility and maintainability.

3.5. Agile Software Release Planning and Prioritization

Software release management approaches, methods and tools have evolved [123] from ad hoc to incremental, agile and continuous DevOps-based methods. Software release management is closely related to software requirements engineering (elicitation and prioritization) [7] as well as task/work items prioritization.

The software requirements elicitation and prioritization [124] are relevant activities that impact overall software quality [125]. Requirements could be obtained at the beginning of the software project [122], or periodically during the software project [126]; Sadiq and Shahid [124] analyze and evaluate different software requirements elicitation methods such as methods based on JAD (Joint Application Development), AHP (Analytical Hierarchy Process) and ontology framework.

Methods for prioritization of software requirements are related to dynamically conducted decisions regarding selection of requirements that should be considered to be addressed in the next release [126]. Asghar et al. [125] presented a short overview of existing techniques in software requirements prioritization: Case-based ranking (combining stakeholders’ preferences and machine learning results), Hierarchical Cumulative Voting (HCV) and Fuzzy Expert System, TOPSIS, Cost of Delay, Simple Additive Weighting or Weigers’ prioritization, etc. Software requirements could have diversity technology constraints, mutual dependency and conflicts, so Greer and Ruhe [126] propose a method, based on genetic algorithm utilization, to enable optimization in requirements management for release planning.

Prioritization of software requirements attracted special attention in agile software development. Racheva et al. [127] presented existing approaches in agile projects: round-the-group prioritization, multi-voting system, MoSCoW, pair-wise analysis, weighted criteria analysis, analytic hierarchy process AHP, dot voting, binary search tree, ranking based on product definition, planning game, quality functional deployment, Wieger’s matrix approach, mathematical programming techniques for release planning. Racheva et al. [127] also proposed a conceptual model for dynamic reprioritization of requirements, with key phases: (1) adding business value to items in features list, having knowledge and experience and work breakdown structure factors considered, (2) prioritization process having factors: project constraints, size measurement and effort estimation considered. Alkandari and Al-Shammeri [7] propose an integration of existing methods and requirement prioritization factors, aiming to support requirements evaluation in different aspects and models of agile software development process. The authors provided a categorization of existing methods: ordinal scale, ratio scale (AHP—Analytical Hierarchy Process AHP, absolute scale (Weigner’s method, VOP). They propose the following phases: (1) adding business value to requirements in the project backlog, (2) making prioritized project backlog based on requirements prioritization process and finally, (3) creating sprint backlog for each sprint. In these phases, they propose business value estimation (based on cost estimation, external change, importance), requirements prioritization (based on size/effect estimation), risk estimation (based on volatility, learning experience) and iteration planning requirements estimations (based on dependencies and project/iteration constraints).

Software requirements prioritization in industrial practice gained significant research focus, particularly regarding methods and criteria. Bakalova et al. [128] compared requirements prioritization methods from literature and industrial practice and proposed a conceptual model for agile prioritization process, where requirements value is estimated based on criteria and further prioritized in the project backlog. Daneva et al. [129] analyze agile requirements prioritization in large-scale outsourced system projects and draw conclusions that most used software requirements prioritization criteria are related to their dependencies, volatility, risk, effort and technical debt. Jarzębowicz and Sitko [130] presented results from an industrial survey about agile requirements prioritization in practice. According to [130], key aspects of requirements that were considered in prioritization are as follows: business value for customer, complexity and difficulty, interdependencies, stability and other, while most used prioritization techniques are as follows: MoSCoW, Numerical scale, Kano model, Timeboxing and budgeting and others. Borhan et al. [131] conducted an industrial survey with similar results—key criteria for software requirements prioritization were as follows: business value to customer, and complexity, while prioritization methods used in industrial environment are as follows: cost-value ranking, MoSCoW, Cumulative voting, Kano model and others.

Task prioritization in software development has been addressed in the work of Bugayenko et al. [132] with the systematic review analysis. The findings show that bugs-related and issues-related tasks, as well as “pull-request” tasks, gain more priority in software development, compared to other tasks. In Scrum-based agile projects, tasks are organized as work items of a product backlog [133,134]. Work items continually change [13] by adding/removing and order rearrangements, as the team obtains new and more precise requirements. Items from the top of the product backlog are selected to be processed [133]. Work items in a Product Backlog are prioritized according to different criteria. Bugayenko et al. [135] proposed an iterative approach based on the whole backlog with all items, to utilize Particle Swarm optimization to determine an optimization model for tasks prioritization and priority prediction in the backlog. Silva et al. [136] conducted a systematic review related to research in product backlog ordering approaches—the main results indicate the most important factors that are included in the work items prioritization: effort (measured with use case points and COSMIC function points), dependency (between user stories, between business processes and user stories with BuPUS method [6], precedence relationships, exclusion, etc.), business value (weights obtained from client) and risk. Automation in prioritizing tasks in software development could be beneficial [135], especially in the evaluation of work items based on complex calculations, collaboration and communication [126], as well as priority prediction [135].

3.6. Workflow Patterns and Software Development Work Items List Patterns

Workflow patterns are defined by Van Der Aalst et al. [33] as context-related business process workflow structures, proposed to represent certain business scenarios, which support business requirements elicitation by using workflow modeling languages or automation with workflow management systems. Van Der Aalst et al. [33] represent workflow patterns of different complexity and categorize them as basic control flow patterns (sequence, parallel split, synchronization, exclusive choice, simple merge), advanced branching and synchronization patterns (multi-choice, synchronizing merge, multi-merge, discriminator), structural patterns (arbitrary cycles, implicit termination), patterns involving multiple instances, state-based patterns (deferred choice, interleaved parallel routing, milestone), cancellation patterns (cancel activity, cancel case). Van Der Aalst et al. [33] also compared workflow management systems regarding support to previously presented control flow-based workflow patterns. Russell et al. [11] propose workflow resource patterns, considering resources as a human or non-human entity capable of performing work. These patterns are related to approaches to work items associated with specific resources for execution, and they are categorized as creation patterns (direct allocation, role-based allocation, deferred allocation, authorization, separation of duties, case handling, history-based allocation, capability-based allocation, organizational allocation, automatic execution), push patterns (distribution by offer, distribution by allocation, random allocation, round robin, shortest queue, early/late distribution), pull patterns (resource-initiated execution, system-determined work queue content, resource-determined work queue content), detour patterns, delegation, escalation, deallocation, suspension/resumption, skip, redo), auto-start patterns, visibility patterns, multiple resource patterns (simultaneous execution).

Work items in processes have been analyzed from the aspect of performance. Yingbo et al. [137] applied data mining to improve work parallelism detection, based on event logs, which can be used in workflow schedulers. Awad et al. [138] used process logs to detect and reorganize multi tasks for the same resource, based on two typical human work patterns—queuing and stacking. Ko et al. [139] propose a method to extract contract change reasons and altered work items by using natural language processing.

Speed and communication are particularly addressed in having work items handled in globally distributed software development, with a special focus on factors affecting delays [140]. Salaou et al. [141] consider software developer conversations/discussions during agile software development as a source to derive work patterns that indicate the reasons for delay of the project. Treude and Storey [142] propose tagging as a technique to categorize and organize work items—they enable finding tasks, articulation of work and information exchange in team-based software development. Mukherjee and Garg [143] addressed work items in collaborative software development, particularly regarding their update notifications. This is particularly important for software development professionals, since they are often engaged in multiple software projects. Using a machine learning-based approach is proposed in [143] to predict notifications from users that send work item updates and the needed action from the recipient.

A software development workflow model and project planning can be derived from the history of work items in past projects. Mockus [144] proposed a web-based prediction tool that enables project managers to select relevant past projects and adjust prediction of workflow items based on parameters (type of project, staffing, schedule) that represent the ongoing project. Perez-Rosero et al. [145] addressed software maintenance tasks, linking commits related to bug inducing and fixing into a single work item. Lämmel et al. [146] propose a work item prediction approach based on mining software development repositories, process mining and machine learning.

Work items lists were considered from the perspective of sorting (organizing) [147] or reordering [148]. Pichler and Edre [147] focused on strategies related to the organization (sorting) of work items into work lists assigned to different actors, aiming to improve key performance indicators regarding business process execution. The recommendation system is developed to compute suggestions on which work item should be selected in the next execution, and this system is based on structural, organizational, empirical and current workload information. Pflug and Rinderle-Ma [148] analyze how the reordering of work items in different general workflow patterns (not particularly related to software development) influence temporal performance and other performance parameters.

4. Materials and Methods

4.1. The Proposed Method

This research contributes with the method that enables, at the same time, business-oriented software functional design and enterprise-aware Disciplined Agile Delivery planning.

Overall input and output to the proposed method is presented in Figure 3. Input to the proposed method, BPriS, consists of the business process model (BPM), project scope (PS) definition, project implementation technology selection (PI), technology-dependent software functional patterns (SFP) and technology-dependent work items list patterns (WILP). The output is the work items list (WIL), having work items based on prioritized software functions. This type of method output is named Disciplined Agile Functional Ordered Work Items List (DA-FOWIL).

The essential idea of the proposed method is to map each primitive business process into set of software functions (according to a selected software functional pattern) and each software function is to be implemented by the set of work items (according to the selected work item list pattern). This way, the relationship between business processes to work items in the development of software that supports these business processes could be specified numerically as 1: M (many). The essential elements and results of the proposed BPriS method are presented in Figure 4. From this figure, it is obvious that the BPriS method proposes that for each (1) primitive business process from the business process model, there could be many (M) software functions to support it, and each software function could be implemented with many (M) work items.

The proposed BPriS method is performed with phases as presented in Figure 5. Figure 5 chronologically presents activities as steps to be followed in order to conduct the method. Each method step requires some input and produces output. These data are presented as being stored in data stores. Data stores have stereotypes to highlight the category—project (specific data related to particular project), pattern (abstract schema to be applied upon any project data) and method result (BPriS method artifact that contains results of the method application).

Application of the BPriS method is conducted by following the steps in phases:

• Phase 1—Obtaining an ordered list of primitive business processes from a business process model based on a project scope. Fageha and Aibinu [149] highlighted that the proper scope boundaries should be set with stakeholders’ participation in the definition of future product elements.
• Phase 2—Assigning each primitive business process to the set of semantically coupled software functions based on a selected software functional pattern;
• Phase 3—Categorization and relating assigned software functions between business processes in the mapping table;
• Phase 4—Creating and ordering of a work items list based on an ordered software functions list and selected work items list pattern.

Activities within BPriS method phases will be described in the following text.

4.2. Obtaining Ordered List of Primitive Business Processes from Business Process Model Based on Project Scope

To obtain the appropriate primitive business processes ordered list, several activities should be conducted:

• Initial categorization of enterprise business processes could be performed at the global level, according to Rajarathinam et al. [32] as management process, operational process and the supportive process. Figure 6 presents an abstract business process model with categorization of business processes according to [32], with addition of having both “core business” term proposed in this manuscript as synonym to “operational” business processes. This way, categorization from [32] was enhanced and visualized at Figure 6.

2.

Business processes segmentation, according to the project scope—some business process models are widely set to enable broader process context understanding. Usually, not all business processes will be automated, i.e., supported by software functions within the project scope. In such cases, there should be business processes segmentation conducted, where primitive business processes that are out of project scope should be eliminated from further processing in this method. (Figure 7).

3.

Selection of primitive processes within the project scope and their chronological ordering—extracted primitive business processes from previous phase should be ordered in a list, following a chronological order at the business process model, which follows the order of these processes in real organization.

Abstract example: according to Figure 7 (Business process model segmentation according to the project scope), the ordered list of primitive business processes is as follows:

• Process_1_1
• Process_2_1
• Process_2_2
• Process_2_3
• Process_2_4

4.3. Assigning Each Primitive Business Process to the Set of Semantically Coupled Software Functions Based on the Selected Software Functional Pattern

To create set of software functions assigned to primitive business processes, activities should be conducted:

• Selection of a software functional pattern, according to previously chosen technology for software implementation in the project. Software functional patterns consist of sets of abstract software functions mutually related for their functional purposes. This close relation between software functions enables their semantic coupling. Figure 8 presents an example of a software functional pattern, illustrated with an abstract UML use case diagram [150].
• Each primitive process from the list created in a previous phase is categorized as “input”, “processing” or “output” dominant.

Abstract example: according to previously presented abstract business process model in Figure 7, Process_1_1 and Process_3_1 could be categorized as “input”, Process_2_1, Process_2_2, Process_2_3 as “processing” and Process_2_4 as “output”.

3.

According to the classification (“input”, “output”, “processing”), items from the software functional pattern are attached to this primitive business process, to represent the software support. This way, the first type of semantic coupling between software functions is applied—mutual close interaction of software functions from the software functional pattern is transferred to the set of software functions that support each primitive business process.

Abstract example: for the abstract example of the business process model from Figure 7 and software functional pattern from Figure 8, Process_1_1 and Process_3_1 will have assigned “Data input” and other closely related software functions (upload, print record), Process_2_4 to set of data presentation software functions, while the others are assigned to “Data processing” and “additional print report” software functions.

Figure 8. UML use case diagram of an example of abstract software functional pattern.

Figure 8. UML use case diagram of an example of abstract software functional pattern.

4.4. Categorization and Relating Assigned Software Functions Between Business Processes in the Mapping Table

Each primitive business process and the corresponding set of assigned software functions are placed in the mapping table (

Table 1. Mapping table between primitive business processes and supporting software functions with examples of abstract software functions from software functional pattern presented at Figure 9.

PBP	PBP Type	First Priority SF	Second Priority SF	Precondition SF
Primitive business process 1	Input	Data input	Print record	Data input of basic (coding tables) data Data input from previous business process model first priority SF
Primitive business process 2	Output	Tabular data presentation	Tabular presentation options Record list options Single record options	Data input from previous business process model first priority SF
Primitive business process 3	Processing	Data processing	Print report Tabular data presentation	Data input from previous business process model first priority SF

PBP—primitive business process; SF—software function.

). One primitive business process is placed in one row in that table with all assigned software functions that support that business process.

Within placing primitive business processes and assigned set of software functions, there are two activities conducted:

• Categorization of software functions in one row—derived software functions belonging to one primitive business process-assigned set are organized in three categories: “precondition” (enables “first priority”), “first priority” (“need to have”), “second priority” (“nice to have”). In Figure 8, the “extend” stereotype represents the relationship between first priority functions (that are directly accessible by the user/actor at UML diagram) and “second” priority functions that extend the basic functionality. This categorization of first/second/precondition software functions represents the relationship with the business process supported by these software functions, not the implementation order.
• Relation between software functions from neighboring rows—primitive business process-assigned sets of software functions are symmetrically related: “precondition” software functions from the next row are related to “first priority“ software functions from previous row in the mapping table. This is the second type of semantic coupling—between software functions of neighbor business processes’ supporting software functions.

In the case of multiple separate software projects, each project could have a separate mapping table. In the case of multiple related software projects (within a broad scope of program development in the context of project management), this mapping table could be extended with an additional column (first column on the left) that is related to the name of the project. This way, business processes in these project scopes and assigned software functions for these multiple software projects could be integrated, and their dependency could be monitored and managed.

4.5. Creating and Ordering of Work Items List Based on Ordered Software Functions List and Selected Work Items List Pattern

To create DA-FOWIL, there are some activities that should be conducted.

• Ordering of derived software functions should be conducted in three levels;
• Selection of work items list pattern, according to the selected implementation technology for the project;
• Applying the selected work items list pattern to implement each software function from the ordered software functions list.

4.5.1. Ordering of Derived Software Functions

Ordering of derived software functions is presented with

Table 2. Ordering of software functions implementations by levels, according to BPriS method.

(I) Global Business Processes Level	(II) Business Process Model Level	(III) Set of Software Functions Mapped to a Single Primitive Process Level
Core business processes	Chronological (top down)	“Precondition” software functions
2. Supporting business processes	2. Heuristics: Left—right ordering for simultaneous processes	2. “First priority” software functions
3. Managerial business processes		3. ”Second priority” software functions

and Figure 9.

The three levels of software functions ordering, according to the BPriS method, are explained with details:

(I)

Global business processes level—according to categorization from [32], this method proposes that first priority should have business processes as the core business scope, the second priority being supporting processes and the third priority being managerial processes. Therefore, software functions derived from these groups of business processes should be arranged with this ordering.

(II)

Business process model level—part of business process model that is included in the project scope is ordered chronologically, so the first business process (top-most in visual presentation) is considered as first in the business process list. Sometimes, some processes are performed simultaneously. A possible approach to simultaneous business processes that are in the project scope with the same significance is to order them according to additional heuristic criteria (for example, leftmost is placed first).

(III)

Set of software functions mapped to a single primitive business process level—in the mapping table each primitive business process is assigned to a set of software functions, organized in three levels of priority. In the context of implementation ordering, “precondition” software functions should be implemented first, then “first priority” functions and finally “second priority” functions.

To visualize the proposed ordering of enterprise-aware software functions, Figure 9 presents the essence of the approach.

Figure 9. Abstract example of software functions ordering with BPriS method.

Figure 9. Abstract example of software functions ordering with BPriS method.

4.5.2. Selection of Work Items List Pattern and Assignment to Software Functions

Regarding final activities in DA-FOWIL creation, the BPriS method proposes:

• Information system that supports enterprise business processes is based on integration of software functions, where each could be implemented with different software architectures and technologies (programming techniques, approaches and languages) [16].
• Each work item in the WILP is related to the creation of a particular component from the selected software architecture.

  Table 3. Most commonly used software architectures as examples of WILP.

  Multi-Layered WILP	MVC, MVVM WILP	Microservices WILP
  (1) Data Layer (CRUD)	(1) Model	(1) Data access (CRUD)
  (2) Service Layer	(2) Controller	(2) Micro service logic
  (3) Business logic Layer	(3) View	(3) Micro services integration
  (4) Presentation layer	(4) View Model

  CRUD—Create, Read, Update, Delete operations, MVC—Model View Controller, MVVM—Model View ViewModel, WILP—Work Items List Pattern.

  presents basic components of the most commonly utilized software architectures, which could be used for WILP creation.

3.

Work items ordering in WILP follows the bottom-up principle in implementation of a software function: (1) data sources, (2) data access layer, (3) service layer, (4) business logic layer, (5) presentation layer.

4.

Each software function implementation is assigned to multiple ordered work items according to the selected WILP. The proposed structure of table that enables creating DA-FOWIL is presented at

Table 4. Table for creating DA-FOWIL as a result of BPriS method.

			DA-FOWIL
PBP	SF	OR	WI
<PBP data>	<SF data>	<OR data>	<WI data>

PBP—primitive business process, SF—software function derived from primitive business process, OR—Order of work item implementation WI—work items for software function implementation, based on selected WILP.

.

5. Case Study Results

5.1. Case Study Context

To present feasibility of the proposed BPriS method, a case study is presented in this section. The context of the case study is the development of accounting software that is related to billing records in a private general hospital “Sveti Jovan” (“St. John”) in Zrenjanin, Serbia [151]. This software solution was presented in [152], as a result of two recent software projects. The first project (Project 1) resulted in the billing software to support basic types of medical services expenses billing, and the second project (Project 2) enhanced previously developed software with the monthly reporting functions.

The key elements of user interface of this software solution, with the final version that is currently in use in this hospital, are presented in Figure 10 (data input form) and Figure 11 (form with data processing and print report software functions). For better understanding, these figures are screenshots from the English version of the original software (having Serbian labels that are in use in the hospital), which was presented in [152].

5.2. Results of BPriS Method Utilization with Holistic Approach

Particular software development, explained in Section 5.1., will be used to demonstrate the BPriS method’s applicability, with results that follow all methods’ phases and activities. In this case study, the BPriS method has been applied in all four phases, and in this subsection the holistic approach has been utilized to present results from the two mutually related software projects within joint artifacts. To apply the holistic approach for better understanding of the BPriS method, this subsection section provides results of BPriS method utilization as if the final version of software (as presented in Figure 10 and Figure 11) was developed within a single project. Section 5.2. presents details about particular project results and puts these results in the context of the BPriS method.

Phase 1 is related to “Obtaining ordered list of primitive business processes from business process model based on project scope”. Figure 12 presents a general business process model with the selected processes for the project scope—financial processes (billing) and quality management processes regarding financial reports. According to the BPriS method and [32], Figure 12 presents the proposed representation of all hospital business processes categorized to core business, supporting processes and management processes. Core hospital business processes are ambulance examinations, diagnostics, hospitalization and medical interventions and data from all of them have been collected in the medical services records data store. Supporting activities in a hospital are related to obtaining and maintaining all resources (human, material and financial). The most important management processes include those related to legislation management, standardization and quality management. Project scope of both projects includes software support to medical services billing activities (with bills records) within finance area and quality management with monthly billing reports support (with financial reports records). Therefore, the white area in Figure 12 shows extraction of particular processes as primitive processes that will be processed in phase 2: financial area-billing and quality management and reporting in the financial domain.

Phase 2 “Assigning each primitive business process to the set of semantically coupled software functions based on a selected software functional pattern” and Phase 3 “Categorization and relating assigned software functions between business processes in the mapping table” result in creating a mapping table with primitive business processes assigned to software functions that support them (

Table 5. Mapping table as a result of BPriS method in the case study project.

PBP	PBP Type	First Priority SF	Second Priority SF	Precondition SF
Finance (Billing)	Input	Billing data input	Bill print	Coding tables data input: types of documents, type of payment, banks, patients, patient’s employment companies Data input from previous business process: medical records—out of scope
Quality management and reporting (in financial domain)	Processing	Monthly billing report processing	Monthly billing report print	Billing data input

). Phase 2 includes activities of assigning each primitive business process to the set of software functions based on the selected software functional pattern. Phase 3 deals with utilization of the mapping table, aiming to perform categorization and relating software functions between business processes. Business processes extracted from phase 1 were included in the mapping table presented in Table 5. The software functional pattern that was utilized in this phase for this case study was used according to software functions from Figure 8. Primitive business processes are placed in the first column of the mapping table. The first business process is related to billing, and the essential type of primitive business process is the “Input” type. Data are obtained and recorded, so the first priority software function is related to billing data input. An additional software function to support this business process is the Bill print function, and it is placed in the second priority software function. Precondition software functions to billing data input are data input functions that enable data entry to coding tables, required for the billing data input as supporting data, such as type of financial document for the bill, type of payment, banks with accounts to be used for payment, patients’ data and patients’ employment companies (that will pay for medical bills). For the second business process, related to quality management and financial reporting regarding bills, the essential type of business process is the “Processing” type; therefore, first priority software function is related to calculations in monthly billing reports processing. Second priority function is related to the computed report print, while the precondition for the monthly billing reporting is to have appropriate data obtained for the calculation, which is to have billing data input. This way, the chronologically “previous” business process is placed in the mapping table in previous row and “next” business process is placed in the next row in the mapping table. The semantic coupling between software functions that support these software functions is obvious in this example—first priority software function of previous row is precondition in next row. By placing business processes and the assignment of appropriate software functions, phase 2 ends. By relating software functions assigned to each primitive business process, phase 3 ends. The results of phase 2 and phase 3 are presented in Table 5.

Phase 4 is related to creating and ordering the work items list based on ordered the software functions list and selected work items list pattern.

Table 6. Table with DA-FOWIL as a result of BPriS method in the case study project.

			DA-FOWIL
PBP	SF	OR	WI
Finance (Billing)	Example of coding table: types of documents data input	1	(1) Data Layer (CRUD) types of documents
		2	(2) Service Layer types of documents
		3	(3) Business logic Layer types of documents
		4	(4) Presentation layer types of documents
	The rest of coding tables data input	5–20	For each: “type of payment, banks, patients, patient’s employment companies” × 4 = 16
	Billing data input	21	(1) Data Layer (CRUD) Billing data
		22	(2) Service Layer Billing data
		23	(3) Business logic Layer Billing data
		24	(4) Presentation layer Billing data
	Bill print	25	(1) Data Layer (CRUD) Billing data
		26	(2) Service Layer Billing data
		27	(3) Business logic Layer Billing data
		28	(4) Presentation layer Billing data
Quality management and reporting (in financial domain	Monthly billing report processing	29	(1) Data Layer (CRUD) Monthly billing report
		30	(2) Service Layer Monthly billing report
		31	(3) Business logic Layer Monthly billing report
		32	(4) Presentation layer Monthly billing report
	Monthly billing report print	33	(1) Data Layer (CRUD) Monthly billing report
		34	(2) Service Layer Monthly billing report
		35	(3) Business logic Layer Monthly billing report
		36	(4) Presentation layer Monthly billing report

PBP—primitive business process, SF—software function, OR—Order of implementation, WI—work items.

. presents the created DA-FOWIL (consisting of work items and their order of application) based on software functions from Table 5. and the selected multi-layered software architecture components as a basis for work items list creation.

Table 6 presents results of phase 4 and consists of columns related to primitive business processes (PBP), software functions (SF), order of work items application (OR) and work item (WI). In this case study, multi-layered architecture is selected as a basis for work items list pattern from initial examples of work items patterns derived from most commonly used software architectures presented at Table 3. In this multi-layered WILP, there are four layers and in the BPriS methodology it is proposed that these layers should be developed with a bottom-up approach. Therefore, DataLayer with CRUD operations should be developed first, then service layer, business logic layer and finally presentation layer. At the level of set of software functions that support each business process, first priority in implementation, i.e., work items list is assigned to precondition software functions, then the “first priority” software functions that directly support the business process and finally the “second priority” software functions should be implemented. In this particular example, for the first business process (Finance—“Billing”), the order or software functions development should be (1) coding tables software functions development (example for coding table “types of documents” and others), (2) billing data input, (3) Bill print. The same principle is used with the second business process in this example, except that the precondition software function was already listed to be implemented, so only the “first priority” software function of report calculation and “second priority” software function of report print were included in Table 6 with appropriate DA-FOWIL items.

5.3. Results of BPriS Method Utilization with Incremental Approach—Two Related Projects

This subsection presents usability of the BPriS method for the two related software projects. Figure 13 presents a business process model with separate annotation of project scope for two projects. The project 1 scope is to develop billing software in a hospital, while the project 2 scope is to develop financial reporting software regarding billing in the hospital.

From Figure 13 it is obvious that there is clear relationship between results of these two projects—project 2 depends on results of project 1. This dependency is also presented in

Table 7. Extended mapping table for the two related projects as a result of the BPriS method in the case study.

Project	PBP	PBP Type	First Priority SF	Second Priority SF	Precondition SF
Project 1	Finance (Billing)	Input	Billing data input	Bill print	Coding tables data input: types of documents, type of payment, banks, patients, patient’s employment companies Data input from previous business process: medical records—out of scope
Project 2	Quality management and reporting (in financial domain)	Processing	Monthly billing report processing	Monthly billing report print	Billing data input

. This table is an extended version of mapping table presented in Table 6. The extension is related to the first column regarding the project name.

Table 8. Extended table with DA-FOWIL as a result of the BPriS method in the case study for two software projects.

				DA-FOWIL
PROJECT	PBP	SF	OR	WI
Project 1	Finance (Billing)	Example of coding table: types of documents data input	1	(1) Data Layer (CRUD) types of documents
			2	(2) Service Layer types of documents
			3	(3) Business logic Layer types of documents
			4	(4) Presentation layer types of documents
		The rest of coding tables data input	5–20	For each: “type of payment, banks, patients, patient’s employment companies” × 4 = 16
		Billing data input	21	(1) Data Layer (CRUD) Billing data
			22	(2) Service Layer Billing data
			23	(3) Business logic Layer Billing data
			24	(4) Presentation layer Billing data
		Bill print	25	(1) Data Layer (CRUD) Billing data
			26	(2) Service Layer Billing data
			27	(3) Business logic Layer Billing data
			28	(4) Presentation layer Billing data
Project 2	Quality management and reporting (in financial domain	Monthly billing report processing	29	(1) Data Layer (CRUD) Monthly billing report
			30	(2) Service Layer Monthly billing report
			31	(3) Business logic Layer Monthly billing report
			32	(4) Presentation layer Monthly billing report
		Monthly billing report print	33	(1) Data Layer (CRUD) Monthly billing report
			34	(2) Service Layer Monthly billing report
			35	(3) Business logic Layer Monthly billing report
			36	(4) Presentation layer Monthly billing report

presents DA-FOWIL for project 1 and project 2, based on mapping (Table 7) and selected multi-layered software architecture and work items list pattern.

The final structure of the software developed within both projects is presented with UML use case diagram (Figure 14) and component diagram (Figure 15).

Figure 14 presents UML use case diagram with software functions organized as follows:

• Coding tables input functions for data regarding hospitals, banks, patients, payment types, patients’ employers). These data are needed for billing input and the billing input depends on them, as annotated with stereotype “use”.
• “Billing input” with the “extend” dependency with “Bill print”. The “Bill print” function is an additional function that could be started after the billing input function is finished.
• “Billing recapitulation” is a processing software function that uses “Billing input” results and, therefore, it depends on this function as annotated with “use” stereotype. “Monthly billing report print” is an additional function that could be used after “Billing recapitulation” finishes; therefore, it is annotated as the “extend” dependency.

Coding tables input and billing input are software functions developed with project 1, while billing recapitulation was developed within project 2. Therefore, software functions (presented as use cases in Figure 14) have stereotypes according to the project where their development was included.

Figure 15 presents a component diagram of the developed software, with four layers and additional files. The software is developed by using Microsoft Visual Basic 6.0 (SP 5). The developed application uses Microsoft Access database version 1997 (“SvJovan.mdb”) and Crystal Report files (“*.rpt”) created with Seagate Software’s tool Crystal Reports for Visual Basic 4.6.1.0. Data Layer communicates with database with CRUD operations, Service Layer is a layer between backend and frontend, Presentation Layer contains presentation logic and user interface and could start rpt files regarding simple billing print (BillSpecification.rpt, Credit.rpt, Invoice.rpt). More complex reports are related to billing periodical summary calculations (recapitulation). For better clarity of presentation in Figure 15, these summary reports are simply named Monthly billing report.rpt, but (in the implementation there are multiple rpt files for different kinds of reports (as can be seen in Figure 11). Figure 15 also presents dependency between layers. It could be observed that the Business logic layer only reads data for calculating and reporting. Each layer has a stereotype with the project that implemented that component of the developed billing and reporting software.

6. Discussion

6.1. Contribution Compared to Existing Solutions

Key previous research results are compared to the contribution of this manuscript in

Table 9. Short comparison of key previous research results to the BPriS method and artifacts.

ASPECT	Ref. Contribution/Limitation	BPriS Method and Artifacts
Business process mapping to software design	Business process model mapping to use cases [49], software components [27,55,60,61,62,63,64] or solutions [73,74]	Mapping of primitive business process from business process model to sets of software functions—each primitive business process is assigned to prioritized set of software functions to support that business process Mapping table enables multiple designs for software support and their comparison
Software semantic coupling	Structural coupling of classes in object-oriented programming [77] Semantics extracted from identifiers (names) in code [79,80]	Semantic coupling of software functions: (1) within support to the same primitive process; (2) between chronologically neighbor processes
Software functional patterns	Conceptual, design and programming patterns [86], structural patterns [91] of classes in object-oriented programming [89] Software usability patterns [99] as commonly used software functions Functional patterns for software product lines [104,105] Software functional patterns to support development of different types (regarding implementation technology) of software [100,101,102,103]	Software functional patterns as typical functions for some type of software, supported by a particular technology (similar approach to [100,101,102,103]
Agile software development planning and automation	Software development process model, agile continuous planning [106], delivery and integration [107] Domain experts [116] and clients [117] to be included in the process Automation and DevOps practice [121,122]	Development planning based on business process model, software functional patterns and work items list patterns Table for mapping primitive business processes to prioritized sets of software functions Work items list patterns based on software architectures
Agile software release planning and prioritization	Requirements-based prioritization of work items list [125] Agile projects prioritization of software requirements [127] Task prioritization [132]—bug fixes gain more priority Task priority prediction [135] Product backlog ordering approaches [136] based on criteria: effort, dependency, business value, risks	Work items list prioritized according to business processes classification and segmentation, software functional patterns and prioritization in the mapping table, work items list patterns and software architecture-based prioritization with bottom-up approach
Workflow patterns	Patterns in organization of processes [33], useful for workflow management systems Action patterns in business process models that appear together and could be assigned to objects in software implementation [96]	BPriS method do not propose workflow patterns, since it is out of scope of this method (BPM is an input to BPriS method), workflow pattern from [32] is used for business process level of prioritization—(1) core, (2) supporting, (3) management
Software development work items list patterns	Extraction of software development workflow items from past projects and prediction of new workflow items [144] Sorting and reordering of work items and impact to performance [147,148]	BPriS method propose derivation of work items list items from business process model, software functional patterns and workflow items list pattern based on the selected technology Prioritization of work items list is based on: (1) business processes categorization and software development prioritization according to business process categories, (2) prioritization of software functions assigned to each process (first priority, second priority, preconditions), (3) bottom-up approach to software architecture elements that are included in the work items list pattern.

.

Table 9 briefly presents key related work and comparison to BPriS method contribution. Limitations of previous research results compared to the contribution in this manuscript are explained for each aspect:

• Business process mapping to software design—existing approaches do not address mapping between business process model primitive processes to software functions and do not enable multiple functional designs related to diversity of possible solutions within the same or different technologies. The BPriS method enables comparison and integration of different functional design solutions.
• Software semantic coupling—in previous research, coupling is related to structural and behavioral dependencies between classes in object-oriented programming, while semantics is related to texts in source code (identifiers). These approaches do not consider software functionality as a basis for semantic relationships. The BPriS method proposes semantic relationship between (1) software functions that support the same business process; (2) relationships between software functions of neighbor business processes.
• Software functional patterns—are recognized as needed in the software industry, to be abstracted as commonly used in software, particularly to support different types of software. The BPriS method is based on a similar approach using software functional patterns, and selection of software functional pattern is based on selection of technology for software project implementation. The BPriS method provides flexibility of software functional patterns selection and integration within the broader scope of software development for information systems.
• Agile software development planning and automation—research puts a focus on an environment of continuous planning, delivery and integration, with inclusion of domain experts and clients. The BPriS method goes further and makes an emphasis not only on requirements and domain experts’ knowledge (which could be informal, incomplete and ambiguous) but on a firmer basis—business process models, software functional patterns and work items patterns.
• Agile software release planning and prioritization—previous research works emphasize user requirements as a basis for software development planning, where work items and tasks are prioritized based on requirements evaluation and task evaluation for effort, dependency, business value and risks. The BPriS method proposes prioritization on (1) business process model level, (2) set of derived software functions level (first priority—directly support the business process need as input/output or processing software function, second priority—additional functions, precondition—enable data for first priority functions) (3) work items list pattern level (bottom up approach to develop software components).
• Workflow patterns—previous research results propose workflow patterns to enable workflow management systems automation, where particular subprocesses sets are extracted as action patterns to be supported by software components. The BPriS method uses categorization of enterprise business processes according to [32]. The BPriS method proposes the order of software development prioritization with this order: core, supporting and management business processes. Other workflow patterns could also be integrated with the BPriS method.
• Software development work items list patterns—previous research propose automated extraction of workflow items for software development from previous projects, their sorting, ordering, etc. Previous works did not mention the term “work items list pattern”, so in this manuscript this term was introduced. The BPriS method proposes using work items list patterns (created previously as an abstract model—manually or automated) to obtain ordered work items list for software development.

6.2. Feasibility and Validity of the BPriS Method

The feasibility of the proposed BPriS method has been demonstrated with a simple case study. Starting with the business process model, by applying software functional pattern and technology dependent ordered work items list pattern, this method enables both initial software functional design and implementation planning for enterprise-aware Disciplined Agile Delivery. Of course, in this case study, the work item list pattern is not presented with high granularity, but only with a general annotation to tasks related to the development of particular elements of software related to the selected software architecture. More precise work items could be specified, but in industrial practice, very often that is not needed with professionals who are skilled at knowing which subtasks to perform regarding particular software modules and technologies.

The validity of the BPris method could be evaluated with experiments that have a sample of students’ software projects, as well professional software projects from software companies. The BPriS method and relevant artifacts are proposed as a generally set method with framework. Therefore, better granularity of patterns (software functional pattern and work items list pattern) could be accomplished with automated detection and collection of software functional patterns and work items patterns, during applications development in software companies. Benefits of BPriS method utilization could be measured with significant metrics that are related to the development process performance and software product quality. However, there are also other benefits that could not be easily measured, such as support to design alternatives considerations, etc. Therefore, it is not easy to establish experimental setup and conduct a complete experiment to prove all of the BPriS method’s benefits when compared to other approaches. Particularly, the BPriS method contributes to an array of areas, which also makes it harder to conduct a comprehensive experiment with all contribution aspects included.

6.3. Usability, Limitations and Future Development of the BPriS Method

The proposed BPriS method could be utilized in different contexts:

• The case study in this manuscript demonstrated applicability to a small number of business processes, but the same procedure could be performed with any business process model complexity. In dealing with complex business process models, automation of BPriS method utilization could be very beneficial.
• The BPriS method proposes business process categorization according to [32], but it could be applied with any workflow pattern.
• Software architectures and development technologies change over time. The mapping table could be used to discuss different implementation alternatives (within the same or with different technologies) for the same software functions and for the support to the same primitive business processes.
• Information system solutions sometimes are integrated from software components created by using different technologies and architectures. Mapping table could be used to enable integration of diversity of software implementation solutions designs.
• Better insight into business processes and requirements are usually obtained dynamically during a project. Business processes change over time, due to changes in legislation or business strategy enforced by the market. Mapping table enables flexibility in software design support to different business processes. It is also a useful tool to record and monitor changes in business processes and software design support.
• Mapping table enables integration of results of software design from different software projects that are related in the broader scope of project management in the program management (long term development with multiple projects).
• Mapping table and DA-FOWIL enable organization of software development with multiple teams working on the same software solution. In software companies, teams are organized according to their specialties for particular software architecture modules—front end (presentation layer), back end (business logic layer), data layer, services layer etc…Mapping table and DA-FOWIL enables integrated and filtered (by particular work items list types—according to software architecture elements) presentation of software functions and work items.
• Limitations of the presented BPriS method could be related to:
• Business process model is created outside of BPriS method utilization. It could be created with diversity of workflow patterns. It is expected that the business process model is complete, correct and not ambiguous.
• Granulation of the software functional pattern and work items pattern—the proposed BPriS method was presented as a general framework with examples of software functional patterns and work items list patterns (based on software architecttures). More precise items could be derived from software development practice and available development technologies. In this manuscript, it was not necessary to present work items list patterns and the case study results with better granularity (more details about particular activities in creating elements of this solution), since software development professionals know what to do (what are the subtasks) when a particular task (work item) is presented with general level of details. For example, when the task is to make a data layer with CRUD operations for a “Types of documents” data table, it is obvious that there should be classes that have methods supporting each CRUD operation (Create, Read, Update, Delete) in collaboration with the database.
• Software functional pattern and work items list pattern depend on implementation technology that is available to software development team (according to technology availability and complexity, software team knowledge, experience and available resources for technology implementation).
• Diversity of software development projects—the BPriS method has been presented with utilization in development of new software product, but these are not the only types of software projects, such as enhancement of functional and non-functional aspects, i.e., different types of software maintenance projects, etc. However, the case study presented in this manuscript also presents the possible utilization of the method with project that focus on functional enhancements.
• Complexity of data structures and related software development subtasks granularity—currently, the BPriS method did not address data structures from business process models, but only business processes in software functions design. Having complex data structures included in the BPriS method could enhance granularity in derived work items list and better project planning.

Future improvements for the BPriS method could be in different aspects, to resolve limitations and improve usability. Some of the BPriS method improvement directions could be as follows:

• Development of software patterns and work items patterns that are related to other types of software features and activities.
• Development of more precise software functional patterns and work items list patterns, according to different technologies. Technology dependent software functional patterns and work items list patterns are more refined in real word software projects. They have more precise granulation, which depends on particular technologies, programming languages, databases and tools.
• Data stores (resources) with data records from business process models should be addressed for their structure, to obtain data substructures, which can be a basis to derive software functions to support coding tables.
• “Master—detail” or other more complex data relationships should be considered in software development activities, since not all complex types of software could require the same number and complexity of activities in implementation.
• Technology-dependent software functional patterns and work items list patterns could be obtained during software development. They can be collected by automated monitoring of different software projects to enable future software support.

7. Conclusions

Our paper contributes with a method to align business processes to software functions, with their semantic coupling and prioritization, to have enterprise-awareness included in the creation of disciplined agile project backlog, i.e., work items list. Utilization of this method includes both software functions design and delivery planning with prioritization of software functions and work items, according to the selected technology for implementation.

Future research could be directed towards different application areas. Since the information system of an enterprise usually includes a diversity of software modules, this method could also be applied to present design alternatives. In dynamic environment, where business processes repeatedly change, utilization of the proposed method could be beneficial in aim to gain the continual alignment of business process needs to software functions. Since software solutions support business processes, this method could also be used to examine if the existing software solution contributes to dynamic environment of software support to evolving business goals and to provide a strategic development roadmap to enterprise-aware software development and project planning.