Predictive Decision Support for Iterative Industrial Systems Engineering: Integrating Agile–Model-Based Systems Engineering With Multicriteria Risk Assessment

Industrial systems development requires coordination between technical design, software implementation, and operational deployment. In manufacturing enterprises, these activities may involve production-related software, enterprise resource planning (ERP) modules, legacy equipment interfaces, data migration, and verification tasks shared by several engineering teams. A release may satisfy its local functional requirements while remaining dependent on an unfinished interface or an unresolved acceptance test elsewhere. Development decisions must therefore account for both the condition of individual work packages and their relationships within the wider industrial system. Model-based systems engineering (MBSE) offers a means of organizing these relationships, with applications extending to chemicals and materials manufacturing [1].

The difficulty becomes more pronounced when development proceeds through successive iterations. Requirements are clarified as operational users examine early releases, integration tests reveal previously unrecognized dependencies, and resource availability changes during execution. A modification to a production-reporting module, for example, may require revisions to shared data definitions, additional interface testing, and changes to the deployment sequence. Although the modification originates within one work package, its consequences extend across engineering and operational responsibilities. A revised schedule records some of these consequences, but managers must still decide which response is technically feasible and how its implications for delivery, expenditure, and risk should be assessed.

MBSE provides an engineering reference for these decisions by relating requirements, subsystem interfaces, and verification activities. Its usefulness nevertheless depends on the questions asked of the model and the information maintained within it. Research evaluating MBSE distinguishes perceived value from the metrics and evidence needed to substantiate that value [2]. Organizational adoption studies also identify implementation considerations extending beyond the choice of modeling tools [3]. These distinctions matter for project management: the presence of a system model does not establish how an emerging problem should be addressed. Decision support requires an explicit connection between the modeled dependencies, the available management responses, and the evidence used to compare them.

Agile approaches introduce review intervals at which priorities and development commitments can be reconsidered. Recent research has examined the definition of agile project management [4] and the application of agile development across interconnected teams and activities [5]. In industrial systems engineering, this flexibility must coexist with requirements baselines, interface control, resource limits, and formal acceptance conditions. A team may revise its backlog within an iteration, but a change affecting production data or a shared equipment interface can require approval across several engineering functions. Iterative planning consequently needs both a mechanism for responding to new information and a system-level basis for determining which responses remain acceptable.

Predictive analytics can inform this process by estimating future delays or risk exposure from project records. The use of artificial intelligence (AI) in project management has prompted research into its applications, evaluation, and relationship with managerial work [6]. A forecast, however, addresses only part of the decision problem. An anticipated integration delay may lead to additional testing, temporary resource reallocation, a revised release sequence, or postponement of a nonessential requirement. The preferred response depends on the affected interfaces, available engineering capacity, budget commitments, and operational priorities. Forecasting and intervention selection therefore require different forms of evidence, even when they are supported by the same project information.

The industrial decision problem is also multicriteria. Increasing verification effort may reduce technical exposure while consuming resources needed for delivery. Deferring a change may protect a near-term milestone while creating additional migration or rework requirements later. Stakeholder agreement can introduce further considerations when production, maintenance, information technology, and enterprise management assign different priorities to the same release. These consequences cannot always be represented adequately by a single schedule or cost measure. A comparison procedure must make the criteria and their relative importance explicit, while preventing favorable scores from compensating for violations of mandatory engineering requirements.

This study investigates a predictive decision-support framework that connects project information, MBSE context, agile review, and evaluation based on distance from average solution (EDAS). The framework distinguishes four tasks: assessing project conditions, identifying feasible responses, comparing those responses against management criteria, and reviewing their implementation in a subsequent iteration. Predictive information describes anticipated conditions; the system model identifies relevant engineering relationships; EDAS expresses the preference implied by specified assessments and weights; and agile review provides the setting for authorization and planning updates. The resulting decision record links the preferred response to the information and assumptions supporting it.

The study makes three contributions within this scope. First, it specifies the information flow between project-state assessment, engineering feasibility, multicriteria comparison, and iteration review. Second, it formulates a project-performance index that distinguishes verified completion, iteration expenditure, cumulative expenditure, and assessed risk. Third, it examines EDAS rankings and their sensitivity to criterion weights using an illustrative comparison of management approaches. The numerical evaluation uses assumed inputs to examine calculation behavior and preference dependence. Implementation and validation of the predictive component, an executable MBSE model, and the complete industrial workflow remain outside the evaluation.

The remainder of the article is organized as follows. Section 2 reviews the literature on MBSE, agile coordination, predictive information, and multicriteria assessment. Section 3 defines the industrial decision context and framework architecture. Sections 4 and 5 present the performance measures, feasibility conditions, and decision procedure. Section 6 reports the numerical examples and criterion-weight sensitivity analysis. Sections 7 and 8 discuss the implications, limitations, and conclusions.

The relevant literature addresses several connected but distinct questions: how engineering relationships are represented, when development commitments are reconsidered, how future project conditions are estimated, and how alternative responses are compared. These questions require different inputs and produce different outputs. Their relationship is examined below to establish the role of each component in the proposed framework and the evidence required to evaluate its use in industrial development.

MBSE relates requirements, system behavior, architecture, interfaces, and verification activities through explicit model representations. For industrial projects, these relationships can help identify the engineering consequences of a proposed change. A modification to a manufacturing software interface, for example, may affect data exchange, downstream functions, and acceptance tests. The management relevance of the model lies in making these connections available when a development plan is reconsidered. Its role therefore depends on how the model is used, rather than on the existence of a model alone.

Wilking et al. [7] classified the utilization of system models within MBSE and identified associated research directions. Their review provides a basis for distinguishing the purposes served by different model uses. Cederbladh et al. [8] examined early validation and verification of system behavior in MBSE, addressing how model-based activities contribute to the examination of engineering behavior before later development commitments. Together, these studies support a more specific account of model use: a model should answer an identifiable engineering question and provide information relevant to the decision being made.

The relationship between model use and project outcomes requires additional care. Campo et al. [2] reviewed perceived MBSE value, metrics, and supporting evidence. Henderson et al. [3] examined organizational adoption experiences. These perspectives concern different levels of analysis. A model may support requirements traceability, while the organizational effort needed to maintain that traceability depends on responsibilities, working practices, and access to current information. Demonstrating a modeling capability is therefore different from demonstrating reduced development expenditure or improved delivery performance.

For iterative industrial development, traceability must extend beyond the requirement–design relationship. A management decision should identify the project condition that prompted it, the interfaces and verification activities affected, and the assumptions used to assess possible responses. After implementation, the record should also allow the resulting outcomes to be examined. This creates a connection between engineering traceability and decision traceability. MBSE supplies the relevant system relationships, while the management procedure specifies how those relationships constrain or inform alternative actions.

In the proposed framework, MBSE consequently serves as the engineering context for feasibility screening and review. It does not assign management priorities or calculate an intervention's expected effectiveness. Those tasks require separate assessments. Keeping these responsibilities explicit allows a later evaluation to distinguish problems arising from incomplete system information from those arising from unsuitable criteria, inaccurate forecasts, or decisions that were not implemented.

Agile project management provides a basis for revisiting priorities and commitments as information changes. Research clarifying its definition shows the importance of specifying what is meant by an agile approach in a particular project [4]. Research on large-scale agile development further examines its application across interconnected teams and activities [5]. These considerations are relevant to industrial systems because development often spans software teams, systems engineers, operational users, and functions responsible for deployment or acceptance.

Coordination across these groups involves more than the frequency of meetings. A local iteration may be completed while a shared interface remains unresolved, or a proposed change may be acceptable to one business unit but disruptive to another. Meckenstock [9] reviewed issues associated with the use of agile software development methods, providing a basis for examining implementation difficulties alongside intended advantages. The availability of short review cycles should therefore be assessed in terms of the decisions they support and the dependencies they help resolve.

Industrial development also contains commitments with different degrees of flexibility. Task assignments and the ordering of noncritical work may be revised at an iteration review. Equipment interfaces, safety requirements, migration conditions, and mandatory verification can require a wider approval process. A useful hybrid arrangement must distinguish these cases. Otherwise, local responsiveness can lead to changes whose consequences have not been examined at system level, while excessive central approval can prevent teams from responding to information that warrants timely action.

MBSE and agile review can address complementary aspects of this coordination problem. The system model identifies the requirements, dependencies, and acceptance conditions associated with a change. The review process determines when new information is examined, who can authorize a response, and how that response enters the development plan. Their connection requires identifiable records: the system configuration being reviewed, the outstanding engineering issues, the proposed alternatives, and the commitments accepted for the next interval.

The present framework uses agile review in this decision-oriented sense. Each review provides an opportunity to update the project state, reconsider feasible responses, and record the reasons for selection. A subsequent review can then examine whether the assumed conditions persisted and whether the authorized action was completed. This interpretation connects iteration planning to engineering governance without treating frequent replanning as evidence of improved project performance.

Predictive information concerns what may occur after the current review. Potential inputs include module completion records, unresolved defects, integration-test results, engineering capacity, and expenditure. Machine learning (ML) has been studied across tasks in model-driven engineering [10], demonstrating the breadth of research connecting learned models with engineering representations. The validity of a particular project forecast nevertheless depends on its own outcome definition, data, and evaluation procedure.

The timing of information is especially important. A model intended to predict release delay at a planning review must use features available at that review. Later defect closures, revised completion dates, or final expenditure can contain information about the outcome that would not have been available to the decision-maker. Kapoor and Narayanan [11] examined information leakage and its consequences for the reproducibility of machine-learning-based research. Their analysis is relevant to project forecasting because apparently strong performance can arise from evaluation procedures that do not reflect the intended prediction setting.

Forecast evaluation also requires suitable baselines and error measures. Hewamalage et al. [12] reviewed common pitfalls and good practices in forecast evaluation. In an industrial project application, the evaluation should identify the prediction horizon, the unit of analysis, and the relationship between training and evaluation records. If a forecast is intended to guide decisions about future releases, the evaluation procedure should represent that use rather than merely reproduce relationships within previously observed records.

Even a well-evaluated forecast does not establish the effectiveness of a management response. Predicting that a module will be late differs from estimating whether additional integration effort will prevent the delay. The latter concerns the consequences of an intervention, which may depend on resource availability, task readiness, and dependencies beyond the affected module. The broader literature on AI in project management provides a context for examining this relationship between analytical capabilities and managerial work [6].

A decision-support process must therefore preserve the distinction between observed information, forecasts, and assumed intervention effects. An observed expenditure records what has occurred. A forecast delay describes an anticipated outcome under specified conditions. An assessed delay reduction describes an expected consequence of a proposed response. Combining these quantities without identifying their sources would obscure what the numerical evaluation can support.

In this study, prediction is a defined function within the proposed architecture. The numerical examples take forecast delay and criterion assessments as illustrative inputs. They examine how such information can enter a decision procedure, while leaving model training and forecast validation to a subsequent implementation. This scope permits analysis of the decision formulation without attributing predictive accuracy to calculations that do not compare forecasts with observed outcomes.

Multicriteria assessment addresses the comparison of alternatives whose consequences span several objectives. In industrial development, these may include expected risk reduction, delivery effects, expenditure control, and stakeholder priorities. Before calculation, the alternatives must be defined over a common decision horizon and the criteria must distinguish favorable outcomes from undesirable quantities. Expected delay and delay reduction, for example, have opposite preference directions even when both are expressed in weeks.

EDAS was introduced for multicriteria inventory classification [13]. It compares alternatives through their positive and negative distances from a criterion-wise average solution. A subsequent review examined its developments, extensions, and applications across decision domains [14]. The method provides an explicit sequence from criterion assessments to weighted distances and appraisal scores, allowing a ranking to be reproduced when the inputs and calculation conventions are reported.

The interpretation of that ranking remains conditional. EDAS evaluates the alternatives included in a specified matrix under the selected criteria and weights. Its appraisal score is not an absolute measure of industrial effectiveness. Changes to the assessment values, preference weights, or alternative set can change the result. In particular, engineering feasibility should be established before ranking, because a compensatory scoring procedure should not allow favorable delivery or expenditure assessments to offset a violation of a mandatory requirement.

Weight sensitivity is consequently part of interpreting the comparison. Więckowski and Sałabun [15] reviewed sensitivity-analysis approaches in multicriteria decision analysis, while Nabavi et al. [16] examined sensitivity analysis of multicriteria methods for engineering applications. These studies provide a methodological basis for investigating whether a reported preference persists when evaluation assumptions change. The relevant question is not simply which alternative ranks first under one weight vector, but which preferences lead to a different selection.

Different sensitivity questions should nevertheless remain separate. Varying criterion weights examines management preferences. Varying assessment values examines uncertainty or disagreement about consequences. Changing the alternative set examines dependence on the comparison being made. The present numerical analysis addresses the first of these questions by retaining the decision matrix and varying one criterion weight at a time. Its results therefore describe the tested preference settings rather than uncertainty across all possible industrial conditions.

These research streams support complementary decision tasks. System models describe engineering relationships, agile reviews organize planning updates, predictive methods estimate future conditions, and multicriteria methods compare alternatives under stated preferences. The connection between them requires a decision procedure that preserves the source and meaning of each input. Project-state information must lead to identifiable candidate responses; engineering constraints must determine feasibility; and the comparison must retain the criteria and weights supporting the preferred choice.

The proposed framework specifies this connection and carries it forward to subsequent review. Its numerical examples examine the project-performance index, EDAS appraisal scores, and preference-dependent rankings. The seven management approaches used in the comparison are broad categories that can coexist within a project, so their ranking illustrates the assessment procedure rather than selecting a complete industrial implementation. Applying the framework operationally would require clearly defined intervention plans, documented input assessments, implemented predictive and modeling functions, and records of the decisions and outcomes observed across successive reviews.

The study develops a decision-support framework for industrial systems projects delivered through successive development and integration cycles. The application context includes manufacturing enterprise software and industrial platforms in which changes to requirements, subsystem interfaces, or resource allocations can affect several engineering activities. The decision problem is to select a management response that accounts for these effects while maintaining an acceptable balance between delivery, cost, risk, and stakeholder priorities.

The analysis followed three stages. First, the roles of predictive analytics, MBSE, agile review, and multicriteria assessment were distinguished. Second, a common notation and decision procedure were established to connect project information with the evaluation of alternatives. Third, numerical examples were evaluated to examine the behavior of the project-performance index and the EDAS ranking procedure. Weight sensitivity was then evaluated using the same decision matrix.

Table 1 defines the scope of the analysis. The numerical examples are illustrative: they examine calculation consistency and preference sensitivity rather than establish performance improvements in an operating industrial enterprise. No interview findings, trained prediction model, or measured deployment outcomes are inferred from these examples.

The industrial context must be specified when defining implementation requirements. Teper et al. [17] examined MBSE implementation considerations across sectors and system types. Their findings support an application-specific account of the information, engineering relationships, and organizational conditions required by the proposed framework.

The proposed framework connects four functions. The predictive component is intended to estimate future project conditions, such as module delivery delay. The MBSE component provides the requirements and subsystem relationships needed to interpret those estimates. Multicriteria assessment compares feasible management responses, while agile review establishes when updated information is considered and approved responses are incorporated into the development plan. Figure 1 shows the proposed information flow from industrial project records and system dependencies to feasibility screening, multicriteria assessment, and iteration review. The numerical evaluation examines the performance index and EDAS calculations; it does not implement the predictive or MBSE components.

These functions address different questions. A forecast indicates where a problem may arise, but does not determine whether additional testing, resource reallocation, or release resequencing is preferable. The system model identifies the affected interfaces and verification obligations, but does not assign management priorities. EDAS makes those priorities explicit through criteria and weights. The review process then determines whether the preferred alternative can be implemented within the current engineering plan.

In a manufacturing ERP project, for example, a delayed interface may affect data migration and acceptance testing in several business units. The framework would associate the delay estimate with the relevant system dependencies before comparing possible interventions. This example describes the intended decision process; it does not imply that a particular ERP implementation was observed or evaluated in this study.

Connecting engineering analyses also requires defined interaction points. Bouhali et al. [18] proposed a workflow linking MBSE and safety assessment in mechatronic systems design. This provides a relevant example of coordinating model-based engineering activities; it does not establish the effectiveness of the project-ranking procedure examined here.

Each evaluation requires a defined set of alternatives, comparable criterion values, and an explicit source for every input. An input may be an observed project measurement, a model prediction, an elicited assessment, or a scenario assumption. These categories must remain distinguishable throughout the analysis.

Industrial project records may include module completion status, unresolved integration issues, verification results, engineering effort, and expenditure. Such records can describe the current project state or provide inputs to a prediction model. Their availability does not, however, establish that they predict future outcomes reliably. Model development requires a separate evaluation using data that were unavailable during training.

Traceability also applies to management decisions. The evaluation record should identify the system configuration, alternatives, criterion definitions, weights, and assumptions used at each review. When new information changes the preferred alternative, the reason for that change should be recoverable from the record. This connection between engineering information and management judgment is the central purpose of the framework.

Operational manufacturing studies provide a reference for the evaluation needed beyond a numerical example. Mo et al. [19] investigated a digital twin-based self-learning decision-making framework through industrial robot applications. The present evaluation differs in scope: it examines a decision formulation without deploying a learning module or physical controller.

Consider an industrial development project reviewed over $K$ iterations. At review $k$, where $k = 1,\ldots,K$, project conditions are represented by

where, the variables are defined in Table 2. Complexity, stakeholder alignment, and feedback delays can be recorded as additional explanatory variables when suitable measurements are available. They are not assumed to be interchangeable with cost, progress, or risk.

Cumulative and iteration expenditure are related by

They must be distinguished because expenditure can vary between releases while cumulative expenditure cannot decrease in the absence of an explicitly recorded adjustment. Resource and budget feasibility require, where applicable,

Verified progress should be calculated from accepted work rather than elapsed time alone. For milestones with predetermined weights $\omega_h$,

where, $v_{hk}=1$ when milestone $h$ has met its acceptance conditions by review $k$, and $v_{hk}=0$ otherwise. Milestones may represent module acceptance, interface verification, or release approval. If milestone weights or acceptance status are unavailable, an iteration-based completion fraction may be used for illustration, but must be identified as an assumption.

A signed performance index combines progress with cost and risk penalties:

subject to

All three terms are dimensionless. The progress contribution increases with accepted completion, while the remaining terms penalize iteration expenditure relative to its limit and the assessed risk level.

This index is not a probability or a percentage of project success. Under the stated bounds,

A negative value therefore does not indicate an arithmetic failure. It means that the weighted cost and risk penalties exceed the weighted progress contribution. Its interpretation also depends on the project stage, because completion normally increases over successive reviews. The index should be reported alongside its component measures rather than used alone to compare projects at different stages.

For a fixed project state, the unconstrained partial derivative with respect to the cost coefficient is

This derivative holds the other coefficients constant and therefore does not describe a weight change constrained by Eq. (6). Under the unit-sum constraint, a sensitivity calculation must specify which other coefficients change and by how much. Eq. (8) is reported only as a local property of the index; it is not part of the numerical weight-sensitivity analysis in Section 6.4.

Let $\mathbf{z}_k$ contain the project information available at review $k$. A prediction model may estimate a subsequent outcome through

For delay forecasting, the outcome must specify the relevant module or release, prediction horizon, and time unit. Evaluation requires a data-partitioning procedure and error measures appropriate to the forecasting task [12]. Historical features must correspond to information available when the forecast was issued; using later completion or defect information as an earlier predictor would introduce information leakage [11].

Predictive performance and intervention effectiveness are separate quantities. An accurate warning does not automatically reduce risk: the project team must select and implement an appropriate response. Similarly, a reduction in forecast delay is not evidence of improved forecast accuracy unless the predictions are compared with subsequent observed delays.

The present numerical analysis treats forecast delay as an input. It does not estimate the parameters of Eq. (9), report neural-network accuracy, or infer a causal relationship between prediction quality and risk reduction.

At review $k$, let

be the alternatives under consideration. In an operational industrial setting, alternatives should correspond to implementable plans, such as allocating additional integration effort, revising a release sequence, or changing verification priorities. The numerical comparison in Section 6 instead uses broad management approaches to illustrate the ranking procedure. Its results therefore concern those assessed approaches rather than optimized engineering actions.

Alternatives are evaluated against $n$ criteria using

The criterion definitions must distinguish favorable outcomes from undesirable quantities. Risk reduction and delay reduction are criteria to be maximized, whereas residual risk and expected delay are criteria to be minimized. These formulations cannot be exchanged without adjusting the distance calculations.

For clarity, the iteration subscript is omitted in the following equations.

The EDAS calculation uses a non-negative decision matrix:

Each retained criterion must also satisfy

These conditions ensure that the criterion averages used in the distance calculations are positive. A criterion for which all alternatives receive zero has no discriminatory value and should be removed, with the remaining weights renormalized to sum to one. Negative-valued assessments require a justified transformation or a formulation suitable for such data before the present EDAS equations can be applied.

The numerical example uses assumed deterministic assessments. No fuzzy membership functions, rough-set approximations, or uncertainty-propagation calculations are used. Sensitivity analysis therefore concerns criterion weights rather than uncertainty in the assessment values.

The calculation follows the EDAS formulation introduced for multicriteria inventory classification [13]. Subsequent extensions and applications are reviewed in [14]. For each criterion, the average solution is

The following formulation assumes non-negative criterion values and $AV_j>0$. For a criterion to be maximized, the positive and negative distances are

For a criterion to be minimized,

Division by the criterion average expresses deviations on a relative scale before aggregation. Consequently, expressing a reduction as either a fraction or a percentage does not change the resulting relative distances.

The weighted distances are

They are normalized across alternatives:

The appraisal score is

Alternatives are ranked in descending order of $AS_i$. The score lies between 0 and 1, but is relative to the alternatives, criterion values, and weights used in that evaluation. It does not represent an absolute measure of industrial effectiveness. Where all alternatives have identical criterion values, the zero-distance convention assigns an equal score of 0.5.

Ranking should follow feasibility screening. Let

The feasible set contains alternatives satisfying the applicable expenditure, resource, and engineering constraints. Here, $\widehat{c}_{ik}$ denotes the assessed total expenditure for iteration $k$ under alternative $A_{ik}$, and $\widehat{u}_{ik}$ denotes its required mitigation effort. The cumulative-budget constraint applies when a total project budget $B^{\max}$ has been specified; otherwise, it is omitted and cumulative expenditure is reported without a claim of total-budget compliance. The $L$ constraint functions $g_{\ell}$ represent mandatory engineering requirements, such as interface compatibility or required verification activities.

EDAS averages, distances, and normalization terms are calculated over the feasible alternatives only. If feasibility screening changes the alternative set, the EDAS scores must be recomputed because the reference averages and normalization terms depend on that set. For notational simplicity, $m$ in Eqs. (14)–(20) denotes the number of alternatives remaining after screening.

The preferred alternative is

This is a selection rule over the evaluated feasible set, not a claim of global optimization. If no alternative is feasible, the planning problem must be revised. Mandatory engineering conditions should not be compensated for by a high score on another criterion.

After approval, the selected action is associated with the relevant requirements, interfaces, and verification activities in $\mathcal{M}_k$. The subsequent review compares observed outcomes with the assumptions used in the evaluation. Model and planning updates require engineering authorization; a numerical ranking does not automatically establish that a design change is acceptable.

The procedure ends when the project reaches its defined acceptance conditions or is formally terminated. A high appraisal score alone is not a project-completion criterion.

The first example considers an industrial platform developed through five successive releases. The supplied values describe forecast delay, mitigation effort, release expenditure, and normalized risk. They are treated as scenario inputs rather than outputs generated by an estimated dynamic model. Delay denotes lateness relative to a planned delivery date, rather than the time remaining until completion. The delay values are illustrative assumptions and are not evaluated against observed delivery dates.

For this illustration, the project is assumed to contain five equally weighted release milestones, with exactly one additional milestone accepted at each review. The verified completion fraction is therefore $q_k=k/5$. This is a scenario assumption rather than a completion measure derived from project records.

The release budget limit is 5 million United States dollars (USD), and Eq. (5) uses

Table 3 presents the assumed inputs for the five-release scenario and the iteration-level performance indices calculated using Eq. (5). Forecast delay and mitigation effort provide scenario context but do not enter the index calculation, and their relationship with risk is not estimated. The index combines assumed completion, iteration expenditure relative to its budget limit, and normalized risk.

For iteration 3,

No additional normalization is applied. The performance index increases from $-$0.412 to 0.076 as assumed completion increases and the specified risk decreases.

Across the supplied sequence, risk declines by 77.5%, forecast delay declines by 83.3%, and mitigation effort increases by 125%. These changes describe the scenario. They do not establish that greater effort caused the reduction in risk, or that delay forecasts became more accurate. Release costs remain below the specified individual limit, while cumulative expenditure reaches USD 22.8 million. Compliance with a total project budget would require a separately specified $B^{\max}$.

The second example evaluates seven management approaches using the supplied criterion values. The alternatives are agile–systems engineering, MBSE, AI/ML forecasting, structured risk management, digital twin integration, incremental budgeting, and stakeholder-centered planning. These approaches are not mutually exclusive and may be used together in an industrial project. Their treatment as separate alternatives serves the numerical illustration only. An operational application would instead compare specified intervention plans over a common decision horizon.

All four criteria are formulated so that larger values are preferred. Risk and delay reduction are represented by assumed percentage values, while cost control and stakeholder assessment use illustrative 0–1 scales. No baseline project records are supplied from which the percentage reductions could be independently calculated. All values in Table 4 are scenario assumptions used to demonstrate the ranking calculation. They were not obtained from industrial measurements, expert elicitation, or trained prediction models.

Table 4 reports the illustrative decision matrix for the seven management approaches. Higher values indicate more favorable assessments for all four criteria.

Equal weights are used for the baseline:

The criterion averages, calculated before rounding, are

The matrix allows the ranking calculation to be reproduced. Because the assessments have no established sampling basis, the resulting scores should not be interpreted as estimates of the performance of these approaches across industrial projects.

Table 5 reports the weighted distances, normalized values, and appraisal scores. Calculations used unrounded values; displayed results are rounded to six decimal places. Figure 2 presents the resulting appraisal scores in descending order to show the differences between the seven illustrative alternatives.

The baseline ranking is

M3 ranks first because its assessed risk reduction, delay reduction, and cost control exceed their respective averages, while its stakeholder assessment is moderately below average. M5 has the largest positive aggregate distance, driven by its risk and delay values. Its lower cost-control and stakeholder assessments produce a larger negative distance than that of M3.

M6 ranks last despite having the highest cost-control assessment. Under equal weights, this advantage does not offset its below-average values on the other three criteria. This result illustrates the influence of the selected criteria and weights; it does not establish that incremental budgeting is unsuitable for industrial development.

The comparison also concerns individual management approaches rather than the proposed integrated framework. Accordingly, the ranking does not quantify an improvement attributable to combining prediction, MBSE, agile review, and EDAS.

Sensitivity analysis examines the dependence of an evaluation on its preferences and assumptions [15], [16]. Here, one criterion weight was varied at a time, while the remaining three criteria received equal shares of the residual weight. For criterion $j$,

with

The original decision matrix was retained in every calculation. Weighted distances and alternative-level normalization were recomputed for each setting. Table 6 reports the complete rankings for the twelve sensitivity settings. Figure 3 visualizes these rankings alongside the equal-weight baseline at 0.25.

M3 remains first in eight of the twelve tested settings. M5 becomes first when risk reduction or delay reduction receives a weight of 0.70, and when cost control receives a weight of 0.10. M7 becomes first when stakeholder assessment receives a weight of 0.70.

The lower rankings also change substantially. When cost control receives a weight of 0.70, M6 rises from last in the equal-weight baseline to second. Thus, its baseline position reflects the chosen preference structure rather than consistently poor performance on every criterion.

These calculations establish sensitivity only for the tested weight settings. They do not demonstrate stability across all possible weights or uncertainty in the criterion values.

The results illustrate why industrial development decisions require explicit priorities. A program facing a critical integration deadline may place greater weight on delay reduction, whereas a deployment involving substantial operational change may assign greater importance to stakeholder assessment. Such choices should be agreed before inspecting the preferred ranking.

The framework also distinguishes objectives from mandatory conditions. Budget limits, interface compatibility, and required verification remain feasibility constraints. A strong score for expected risk reduction cannot justify an alternative that violates an essential engineering requirement. MBSE supplies the context for checking these conditions, while the multicriteria calculation compares the alternatives that remain feasible.

The numerical analysis demonstrates the calculation procedure and shows how changes in criterion weights affect the ranking under the assumed assessments. It does not establish prediction accuracy, realized cost savings, or causal risk reduction. Operational validation requires documented project inputs, implemented prediction models, explicit intervention records, and comparison with an appropriate planning baseline.

The numerical analysis distinguishes two aspects of industrial project assessment: changes in project conditions across iterations and comparisons between management alternatives at a given review. These assessments serve different purposes. The iteration-level index summarizes progress, expenditure, and risk under specified assumptions, whereas EDAS expresses the relative preference for alternatives under a selected set of criteria and weights. Neither measure independently establishes the effectiveness of an intervention.

In the five-release example, the signed performance index increased from $-$0.412 to 0.076 as assumed completion increased and the specified risk declined. This pattern is consistent with the construction of the index. Its improvement cannot be attributed entirely to risk mitigation because the completion contribution also increased with each release. Moreover, the reduction in forecast delay from 12 to 2 weeks describes a change in the supplied predictions, not an improvement in prediction accuracy. Accuracy requires comparison with subsequently observed delivery outcomes. These distinctions are important when dashboards are used to support industrial development reviews: an improving summary indicator can reflect several underlying changes, each requiring a different management interpretation.

The EDAS calculation addresses a separate question. Under equal criterion weights, AI/ML forecasting received the highest appraisal score, followed by digital twin integration and agile–systems engineering. The result follows from the supplied decision matrix. AI/ML forecasting combined above-average assessments for risk reduction, delay reduction, and cost control with a smaller stakeholder penalty than digital twin integration. Its first-place position therefore reflects the assessed balance between the four criteria, rather than independent evidence that forecasting is the most effective management approach.

The distinction between input assessment and calculated preference also applies to the lower-ranked alternatives. Incremental budgeting ranked last under equal weights despite having the highest cost-control value. When cost control received a weight of 0.70, it rose to second place. Similarly, stakeholder-centered planning became first when stakeholder assessment received a weight of 0.70. These changes show that a baseline ranking can conceal alternatives that become attractive under different priorities. They do not establish that any approach is inherently unsuitable for complex industrial projects.

In industrial systems development, the relevant priorities depend on the engineering conditions at the review point. During subsystem integration, a delay affecting several dependent interfaces may make delivery and risk exposure the principal concerns. During enterprise deployment, user acceptance and agreement between operational units may receive greater attention. The weight analysis provides a way to examine these preference changes explicitly, although the appropriate weights must be justified by the project context.

A manufacturing ERP project illustrates the connection. If a module is expected to miss its integration date, the immediate decision is not simply whether predictive analytics is preferable to MBSE. The project team must choose an implementable response, such as reallocating engineering effort, revising the deployment sequence, or postponing a nonessential requirement. Each response affects different interfaces, verification tasks, and resource commitments. Predictive information describes the anticipated problem; the system model establishes its engineering context; and multicriteria evaluation compares the feasible responses.

This distinction limits the operational interpretation of the present management-approach ranking. The seven alternatives are broad categories that may coexist within the same project. Their scores cannot be translated directly into a release plan or resource allocation. For deployment, the decision matrix should therefore contain clearly specified intervention plans evaluated over a common horizon. The framework provides the structure for that assessment, while the current numerical example illustrates its calculation.

Engineering feasibility must precede preference ranking. An alternative that violates a mandatory interface requirement or omits required verification should not remain eligible merely because it receives favorable cost or delivery assessments. Likewise, an unavailable engineering resource cannot be treated as a feasible mitigation option. The separation between constraints and criteria prevents compensatory scoring from overriding essential technical conditions.

Manufacturing evidence also indicates the need to document how iterative practices are implemented. Fargher et al. [20] reported an industrial application of a combined lean--agile model for product development. Comparable documentation of implementation and observed outcomes would be needed before the operational value of the present framework could be assessed.

The framework assigns predictive analytics, MBSE, and agile review complementary responsibilities. Prediction concerns anticipated project conditions. MBSE relates those conditions to requirements, interfaces, and verification activities. Agile review provides opportunities to reconsider priorities and authorize changes. EDAS supplies a reproducible comparison rule once alternatives and assessments have been established.

The practical value of this arrangement depends on the information exchanged between these functions. A delay prediction must identify the affected module, forecast horizon, and model version. An engineering assessment must identify the dependencies and acceptance conditions that constrain the response. The decision record must then preserve the alternatives, criterion values, and weights used in selection. Without these links, combining several methods may produce additional reports without clarifying why a particular action was chosen.

The same traceability is needed after implementation. At the next review, observed expenditure, completion, and integration outcomes should be compared with the assumptions supporting the previous decision. A discrepancy may arise from forecast error, an inaccurate assessment of intervention effects, incomplete execution, or a subsequent requirement change. These explanations have different implications. Retraining a prediction model, for example, would not resolve a failure caused by an intervention that was never implemented.

Industrial digital-twin research provides a related deployment perspective. Hassan and Björsell [21] examined system- and system-of-systems digital twins for predictive maintenance and root cause analysis. Their work concerns manufacturing-process monitoring rather than project-delay forecasting. It is relevant to the need for operational data and implementation evidence, but it does not validate the predictive function proposed here.

Continuous review should consequently be understood as a means of updating evidence and decisions, rather than a guarantee of continuous improvement. Its effectiveness depends on timely records, consistent measurements, and authority to act on the findings. The present study specifies this decision structure but does not measure the organizational effort required to maintain it.

The contribution of the framework is the explicit connection between project-state assessment, engineering feasibility, multicriteria selection, and subsequent review. The formulation separates iteration expenditure from cumulative cost, verified completion from elapsed time, and prediction accuracy from intervention effectiveness. It also distinguishes the signed project-performance index from the relative EDAS appraisal score. Maintaining these distinctions makes the assumptions and calculations open to examination.

The weight analysis adds a limited robustness assessment. AI/ML forecasting remained first in eight of the twelve tested settings, while digital twin integration or stakeholder-centered planning led in the remaining settings. This finding identifies preference conditions under which the leading alternative changed. The number of first-place appearances is descriptive, however; the tested settings do not constitute a probability distribution over industrial priorities. It would therefore be inappropriate to interpret eight first-place rankings as a probability of superiority.

Several limitations remain. The criterion values are illustrative inputs without a documented sampling or elicitation procedure. The analysis consequently cannot establish realized risk reduction, cost savings, or stakeholder satisfaction. The five-release sequence is also not generated by an estimated transition model, so it cannot demonstrate how changes in mitigation effort cause subsequent project outcomes.

The framework includes a predictive function, but the numerical evaluation does not train or test a forecasting model. Its contribution is therefore a decision-support formulation rather than a new prediction algorithm. Similarly, the MBSE component specifies the role of system information without evaluating an executable system model or a software integration. The calculations do not demonstrate the performance of the complete framework in industrial operation.

Finally, the sensitivity analysis varies criterion weights while retaining the original matrix. Uncertainty in the assessments and changes to the alternative set could also affect the results. Broader evaluation should examine these sources of variation and compare the resulting decisions with a documented baseline. Suitable industrial validation would follow identifiable development modules across successive reviews, record the interventions actually implemented, and assess both forecast quality and decision outcomes. This would establish whether the proposed information flow improves planning sufficiently to justify its implementation effort.

This study developed a predictive decision-support framework for iterative industrial systems engineering by connecting project assessment, MBSE information, agile review, and EDAS evaluation. The framework defines how anticipated project conditions can inform the comparison of feasible management responses while preserving their links to requirements, subsystem interfaces, and verification activities.

The numerical analysis clarified two distinct assessment tasks. In the five-release illustration, the project-performance index increased from $-0.412$ to 0.076 under the assumed completion, expenditure, and risk values. In the multicriteria comparison, AI/ML forecasting ranked first under equal weights, with an EDAS appraisal score of 0.842748, followed by digital twin integration at 0.758206. These values describe the specified scenarios and assessments; they are not estimates of measured industrial effectiveness.

Weight sensitivity showed that the preferred alternative depended on management priorities. AI/ML forecasting remained first in eight of twelve tested settings. Digital twin integration became first under strong emphasis on risk or delay reduction and under reduced emphasis on cost control, while stakeholder-centered planning became first when stakeholder assessment received the largest weight. The results support reporting preference sensitivity alongside the baseline ranking.

The framework provides a structured basis for connecting predictive information with industrial development decisions. Its present contribution is the formulation and examination of that decision process. Validation using traceable industrial records, implemented prediction models, and observed intervention outcomes is required to determine its operational effectiveness.