# Decision Support Systems: Decision Analytics, Optimization, Uncertainty, and Decision Intelligence > Comprehensive engineering notes on decision support systems, from decision processes and architecture to multi-criteria analysis, optimization, simulation, uncertainty, machine learning, decision intelligence, human oversight, and AI risk management. - Author: Muhammet Ali Köker - Language: en - Canonical: https://alikoker.com.tr/en/decision-support-systems - Translation: https://alikoker.com.tr/karar-destek-sistemleri - Published: 2026-09-24T18:56:00+03:00 - Modified: 2026-09-24T18:56:00+03:00 - Verified: 2026-09-24T18:56:00+03:00 - Type: article A decision support system (DSS) is not a single algorithm that replaces a decision maker. It is a **socio-technical system that brings data, models, objectives, constraints, uncertainty, and human judgment into the same decision context**. Reporting can describe what has happened; decision support makes alternatives, assumptions, possible consequences, and trade-offs explicit. The primary output of a DSS is therefore not merely a score, forecast, or recommendation. A defensible decision should remain traceable to the data version, model, constraints, objective function, uncertainty representation, alternatives, and human interventions that shaped it. DSS engineering sits at the intersection of data engineering, optimization, statistics, artificial intelligence, human factors, software engineering, and management. ## Unit 1: Decision Problems, Decision Processes, and the Boundary of Decision Support ### What constitutes a decision problem? A useful decision formulation normally identifies: - the decision maker or accountable actor, - objectives, - available alternatives, - constraints, - evaluation criteria, - current information and uncertainty, - environmental states that influence outcomes, - the decision horizon. A classifier reporting that option A has a 72% probability of success has produced a prediction, not a decision. A decision requires additional context: how the probability was obtained, the cost of A, the value of competing alternatives, the cost of errors, and any operational or policy constraints. ```text data -> prediction | v objective + constraints + costs + risk + alternatives | v decision model | v recommendation / scenario / action ``` ### Structured, semi-structured, and unstructured decisions A **structured decision** can largely be expressed through predefined rules and calculations. A replenishment decision governed by stable thresholds is a typical example. A **semi-structured decision** combines computable elements with expert judgment. Capacity planning may use optimization to generate feasible plans, while service priorities and change risk still require managerial judgment. An **unstructured decision** is one in which objectives, alternatives, or evaluation criteria may themselves evolve during the decision process. Strategic technology direction often falls near this end of the spectrum. DSSs are particularly valuable for semi-structured work: the system organizes data-intensive and computational reasoning while people retain responsibility for purpose, context, exceptions, and accountability. ### Certainty, risk, and uncertainty - Under **certainty**, outcomes are known within the adopted model assumptions. - Under **risk**, outcomes vary but probabilities or credible frequency information are available. - Under **uncertainty**, even the probabilities may be poorly known. - Under **deep uncertainty**, plausible models, distributions, stakeholder values, or future conditions may disagree. The uncertainty representation must match the problem. A probability distribution and a fuzzy membership function answer different questions. [Probability and Statistics](/en/probability-statistics-distributions-sampling-regression) and [Fuzzy Logic](/en/fuzzy-logic) provide the mathematical foundations for these distinct representations. ### The decision loop An engineering view of the decision cycle is: ```text detect a problem -> define objectives and scope -> acquire data and assumptions -> generate alternatives -> model and evaluate -> select / approve -> act -> observe outcomes -> update models and assumptions ``` This turns a decision from a one-time selection into a controlled learning loop. In dynamic environments, post-decision feedback is part of decision quality. ## Unit 2: Decision Support System Architecture Traditional DSS architectures separate data, models, interaction, and method or knowledge management. The implementation technologies have changed, but the separation of responsibilities remains useful. ```text +----------------------+ | Decision Maker | +----------+-----------+ | interaction / explanation | +----------v-----------+ | Dialogue & Presentation| +----------+-----------+ | +--------------+--------------+ | | +---------v---------+ +---------v---------+ | Model Management | | Data Management | | optimization | | source / quality | | simulation | | lineage / access | | prediction / rules| | freshness / history| +---------+---------+ +---------+---------+ | | +--------------+--------------+ | +----------v-----------+ | Knowledge / Policy | | rules, thresholds, | | constraints, vocab. | +----------+-----------+ | +----------v-----------+ | Action & Feedback | +----------------------+ ``` ### Data management Decision data needs more than a successful query. The system should know, where relevant: - source, - event time and freshness, - meaning and unit, - missingness and anomaly status, - transformation lineage, - access policy, - version. Two fields carrying the same label can encode different semantics in different systems. A DSS can be syntactically correct and still make a semantically invalid decision. [Database Management Systems](/en/database-management-systems) covers the underlying data modeling and integrity mechanisms. ### Model management Model management includes code, parameters, assumptions, version, validity domain, and solution procedure. A single DSS may combine: - deterministic optimization, - stochastic simulation, - statistical forecasting, - machine learning, - expert rules, - scenario calculations. The system should expose when a model is applicable rather than presenting it as universally correct. ### Dialogue and explanation A decision interface should help the user answer: - Which data am I looking at? - Which assumption did I change? - Which criteria influenced the recommendation? - How do the alternatives differ? - How sensitive is the result? - Where is the system uncertain? - What changes if I reject or modify the recommendation? This connects DSS design directly to [Cognitive Systems Engineering](/en/cognitive-systems-engineering) and [UI/UX Engineering in Web Applications](/en/ui-ux-engineering-in-web-applications). ## Unit 3: Data Architecture, Data Quality, and Decision Context ### Operational and analytical data serve different workloads Operational systems are designed to record current business events reliably. Decision support often needs historical, integrated, multi-source data at several levels of aggregation. ```text operational sources | v extract / validate / transform | +--> quality rules +--> semantic mapping +--> lineage and versioning | v analytical store / data product | v decision model ``` Choosing ETL or ELT does not by itself create decision quality. The transformation chain must be reproducible and auditable. ### Freshness versus stability The newest value is not necessarily the most reliable value. Late-arriving events, open accounting periods, or temporary source inconsistencies can make an "instantaneous" view unstable. Useful DSS metadata can include: - event time, - ingestion time, - last validation time, - delay or completeness indicators. The decision maker should be able to distinguish fresh-but-partial information from older-but-validated information. ### Data lineage as an evidence chain A recommendation should remain traceable through transformations: ```text source record -> cleaning -> integration -> derived feature -> model input -> model output -> decision recommendation ``` Every transformation contributes to the evidence basis. "The model said so" is not a sufficient explanation for a high-impact decision. ## Unit 4: Building a Decision Model — Objectives, Alternatives, Constraints, and Criteria A sound decision model defines the problem before choosing a solver. ### Decision variables A decision variable is controllable by the decision maker. Demand is usually an environmental input; an order quantity may be a decision variable. ### Objective functions Objectives state what the system is trying to improve: - reduce cost, - improve service, - reduce delay, - increase safety, - reduce energy consumption, - balance several competing objectives. A badly chosen objective can produce a mathematically excellent but operationally harmful solution. Proxy metrics must be distinguished from the real decision objective. ### Constraints Constraints encode capacity, regulation, time, budget, physical safety, staffing, and dependencies. Hard safety or legal limits should not automatically be converted into soft penalty terms merely to simplify optimization. ### Units and scales If one criterion is measured in seconds, another in currency, and another in percentage points, raw values cannot be meaningfully added. Normalization, weighting, and utility transformations are semantic requirements rather than cosmetic mathematics. ## Unit 5: Decision Analysis — Expected Value, Utility, and the Value of Information ### Decision tables A decision table places alternatives against uncertain states: ```text State S1 State S2 State S3 Alternative A 40 20 -5 Alternative B 25 24 18 Alternative C 60 5 -20 ``` The table does not determine the best alternative by itself. Probabilities, preferences, and the meaning of the outcomes are required. ### Expected value and expected utility Under risk, expected value can be written as: `E[X] = Σ p(s) * x(s)` When money, safety, time, or service loss has a nonlinear value to the decision maker, **expected utility** is more appropriate than raw expected monetary value. A risk-averse decision maker may legitimately prefer a lower-variance alternative even when two alternatives have the same expected value. The preference is represented by the utility function rather than dismissed as irrational. ### Decision trees Decision nodes and chance nodes should remain distinct: ```text [Decision] |-- A --> (Uncertain state) -- p1 --> outcome | \-- p2 --> outcome | \-- B --> (Uncertain state) -- p1 --> outcome \-- p2 --> outcome ``` Decision trees are useful for sequential choices in which information arrives over time. ### Value of information Additional sensing or analysis is valuable only if it can improve the decision enough to justify its cost. Conceptually, perfect information value is the difference between: ```text expected best outcome with perfect information - expected best outcome with current information ``` More data is not automatically more valuable data. ## Unit 6: Multi-Criteria Decision Making Operational decisions commonly involve cost, quality, time, risk, resilience, and sustainability at the same time. ### Weighted scoring A simple form is: `score(a) = Σ w_j * r_aj` where `w_j` is a criterion weight and `r_aj` is the normalized performance of alternative `a`. Two conditions dominate the result: 1. criterion values must be normalized consistently; 2. weights must represent real preferences. Making weights sum to one is mathematically convenient; it does not make questionable weights correct. ### TOPSIS TOPSIS ranks alternatives by proximity to an ideal solution and distance from a negative ideal. A typical workflow is: ```text decision matrix -> normalization -> criterion weights -> ideal / negative-ideal points -> distances -> relative closeness -> ranking ``` Sensitivity to weights and normalization should be examined before treating the ranking as stable. ### Pareto reasoning An alternative can be Pareto-efficient when improving one objective necessarily worsens another. Multi-objective problems naturally produce a **set of efficient trade-offs** rather than a single universal optimum. A DSS should help the decision maker understand this frontier instead of silently collapsing every preference into one opaque score. ## Unit 7: Multi-Objective Optimization and Model-Driven DSS ### Linear and mixed-integer optimization Linear programming has a linear objective and linear constraints: ```text min / max c'x subject to Ax <= b x >= 0 ``` When some decisions are discrete, mixed-integer formulations are required. Scheduling, allocation, routing, and capacity planning often contain such discrete structure. ### Weighted-sum objectives Several objectives may be combined: `min w1*f1(x) + w2*f2(x) + wk*fk(x)` The weights are part of decision policy; they should not be hidden as purely technical tuning parameters. ### Goal programming Goal programming penalizes positive and negative deviations from target values. It is useful when the decision language is closer to "stay within budget and approach the service target" than to a single abstract objective. ### Epsilon-constraint method One objective is optimized while others become explicit bounds: ```text min cost subject to service_level >= ε1 risk <= ε2 ``` This can directly encode policies such as "never fall below this service level." ### Verifying solver output An "optimal" solver status does not prove that the real decision problem has been solved correctly. Verification should examine: - units and signs, - boundary conditions, - constraint tolerances, - integrality, - unexpectedly inactive constraints, - sensitivity, - alternate optima, - alignment with real operational constraints. [Genetic Algorithms and Their Applications](/en/genetic-algorithms-and-applications) provides a complementary view of heuristic optimization. ## Unit 8: Simulation-Based Decision Support Optimization typically asks which action is best; simulation often asks how a proposed policy behaves. ### Monte Carlo simulation Random inputs are repeatedly sampled to estimate an outcome distribution: ```text for each trial: demand ~ distribution duration ~ distribution failure ~ distribution compute outcome summarize outcome distribution ``` Percentiles, tail losses, and threshold exceedance probabilities can be more informative than a single mean. ### Discrete-event simulation In queues, maintenance, logistics, and shared-resource systems, state changes when events occur. Discrete-event simulation is well suited to waiting times, utilization, bottlenecks, and congestion. ### Optimization plus simulation The two techniques can be composed: ```text optimization -> candidate policy | v simulation | robustness / risk | v policy choice ``` This filters nominally attractive solutions that are fragile under realistic variability. ## Unit 9: Representing Uncertainty Uncertainty is not one mathematical object. ### Probabilistic uncertainty Probability distributions are appropriate when frequencies or credible probabilistic models are available. Parameter uncertainty should be separated from irreducible stochastic variation where possible. ### Fuzzy uncertainty Concepts such as "high risk" or "acceptable temperature" may have gradual boundaries. Fuzzy membership represents degree of membership, not event probability. ### Model uncertainty The model structure itself may be uncertain. If plausible models disagree, a narrow parameter confidence interval can understate the real uncertainty. Scenario sets or model ensembles may be more appropriate. ### Robust and cautious decisions Robust optimization seeks solutions that perform acceptably across a defined uncertainty set. Caution does not always mean selecting the mathematically worst case; reversibility, monitoring, and the ability to adapt after new information arrives also matter. ### Sequential decisions: MDPs and POMDPs Markov decision processes combine state, action, transition probability, and reward. When the true state is only partially observed, a POMDP reasons over a belief state. These formulations differ from one-shot ranking because they seek a **policy** for acting over time. ## Unit 10: Data-Driven DSS, Prediction, and Machine Learning In a modern DSS, prediction is one layer in a larger decision chain. ```text observation -> features -> prediction | v threshold / cost | v action ``` ### Predictive accuracy is not decision value The more accurate predictive model is not guaranteed to produce better decisions. When false-positive and false-negative costs differ, the operating threshold should reflect those costs. For rare events, a high accuracy number can be achieved by an unusable classifier that predicts the majority class everywhere. Metrics such as precision-recall behavior, calibration, cost matrices, and downstream decision utility should be considered together. [Statistical Learning and Machine Learning](/en/statistical-learning-machine-learning) develops the predictive modeling foundation in more detail. ### Calibration If events assigned an 80% probability occur roughly 80% of the time over an appropriate population, the model is well calibrated in that sense. Calibration can matter more than ranking quality when probabilities feed directly into expected-cost calculations. ### Distribution shift When production data moves away from the training distribution, the decision behavior may change. A DSS should monitor not only model metrics but also: - input distributions, - missingness, - class prevalence, - calibration, - threshold behavior, - post-decision outcomes. ## Unit 11: Intelligent DSS and Decision Intelligence ### From expert systems to intelligent support Rule-based systems encode domain logic as conditions and conclusions. Their strengths include explicit rules and repeatability in narrow domains; their weaknesses include knowledge-acquisition cost, rule conflicts, and maintenance. Modern intelligent DSS architectures can combine rules, machine learning, optimization, search, and agents. [Artificial Intelligence](/en/artificial-intelligence-philosophy-theory-practice) provides the broader theoretical context. ### Assistance, support, augmentation, and automation Human-machine allocation can be viewed at several levels: - **decision assistance:** retrieve information or perform calculations, - **decision support:** expose alternatives and consequences, - **decision augmentation:** combine complementary human and machine strengths, - **decision automation:** select and execute actions within defined authority. As automation increases, validation, authorization, rollback, and operating boundaries become more important. ### Decision intelligence Decision intelligence is a contemporary framing that focuses on how decisions are defined, executed, monitored, and improved, rather than treating AI or data science as prediction-only disciplines. It is not one international standard or a single algorithm family; it is used as an integrative approach connecting organizational decision processes with analytics and AI. ## Unit 12: Human Factors, Explanations, and Group Decisions ### Bounded rationality Real decision makers have limited time, attention, and computational capacity. The role of a DSS is not to maximize dashboard density but to make the decision-relevant distinctions visible. ### Automation bias A consistent-looking system recommendation can receive more trust than its evidence warrants. Interfaces can reduce this risk by exposing: - missing data, - model validity limits, - uncertainty, - critical assumptions, - contradictory evidence, - alternatives. ### Explanation is not correctness An articulate explanation does not prove that a recommendation is correct. An explanation should state which question it answers: - Which inputs mattered? - Which rule fired? - Which constraint limited the solution? - Why was an alternative rejected? - Which change would reverse the decision? ### Group decisions Group DSSs are not merely electronic voting systems. Stakeholders may differ in: - objectives, - authority, - access to information, - risk tolerance, - objection and approval rights. A useful decision record can retain rationale and dissent rather than only the final selection. [Cognitive Systems Engineering](/en/cognitive-systems-engineering) provides a deeper treatment of human factors and situation awareness. ## Unit 13: Generative AI and RAG Inside Decision Support Large language models can be valuable for natural-language interaction, document analysis, explanation, and hypothesis generation from unstructured information. Their output is not, by itself, authoritative decision evidence. ### Separation of roles ```text user question | v LLM: interpret intent and information need | +--> validated data query +--> document retrieval / RAG +--> deterministic calculation tool +--> optimization / simulation | v evidence + result + uncertainty | v LLM: produce an understandable presentation | v human approval / authorized action ``` The LLM routes work to verifiable tools instead of imitating reliable computation. [Retrieval-Augmented Generation (RAG)](/en/rag) covers grounded generation in more detail. ### Principal risks - hallucination, - stale or incorrect context, - fabricated attribution, - prompt injection and authority boundary violations, - using text generation for structured arithmetic, - assigning nondeterministic generation to decisions that require deterministic execution. For high-impact settings, generative models are better positioned as retrieval and explanation layers around validated decision services than as unconstrained decision authorities. ## Unit 14: DSS Software Engineering and Lifecycle The gap between a DSS prototype and a production DSS is often defined by engineering controls rather than by the core algorithm. ### Spreadsheet prototypes Spreadsheets remain effective for making small models visible, exploring what-if questions, conducting sensitivity analysis, and working interactively with domain experts. Their limits become significant in multi-user, high-volume, or critical production use: - hidden cell dependencies, - version divergence, - concurrent editing, - access control, - automated testing, - data-source integrity. Production migration should turn formulas and assumptions into explicit model contracts, service boundaries, and testable components. ### Versioning These elements should be versioned together when they jointly determine a decision: ```text data schema + data transformation + feature definition + model + optimization parameters + business rules + decision threshold + decision explanation ``` Versioning only the model artifact is not enough for reproducibility. ### Verification and validation - **Verification:** did we implement the specified model correctly? - **Validation:** is the model sufficiently appropriate for the real decision problem? Correct solver implementation is verification; checking whether the objective reflects real operational value is validation. [Software Engineering](/en/software-engineering-process-requirements-design-quality) provides the broader lifecycle context. ## Unit 15: Performance, Reliability, and Operational Design A recommendation can lose all value if it arrives after the decision window closes. Algorithmic quality and temporal behavior are both requirements. ### Latency, throughput, and freshness Three notions must remain separate: - computation latency, - end-to-end decision latency, - age of the data used. A model may respond in 20 ms while using data that is 24 hours old. That is fast computation, not necessarily real-time decision support. ### Controlled degradation Fallback behavior should be designed before failures occur: ```text normal decision support -> advanced model unavailable -> validated baseline rule / last trusted model -> explicit degraded state -> human approval ``` Silently switching to stale data or a different model makes the decision trail ambiguous. ### Caching Expensive results may be cached, but a correct cache key may need data version and model version in addition to user inputs. Otherwise the system can return an incorrect answer very efficiently. ## Unit 16: Measuring Decision Quality ### Model metrics and decision metrics DSS evaluation can be separated into four levels: 1. **Data quality:** completeness, accuracy, freshness, representativeness. 2. **Model quality:** predictive performance, calibration, optimization validity, robustness. 3. **Decision-process quality:** decision time, user workload, explainability, override behavior. 4. **Outcome quality:** cost, service, safety, loss, objective attainment. A model metric can improve while the real outcome worsens. Controlled rollout should therefore measure downstream effects. ### Counterfactual evaluation Production systems normally observe the outcome of the selected action but not what would have happened under the unselected alternatives. Evaluating decision policies is therefore harder than evaluating a static predictor. Where randomization is infeasible, historical controls, matching, causal models, or simulation may help, but each introduces assumptions that should be documented. ### Human override A rejected recommendation is not automatically a user error. Override patterns may reveal: - contexts where the model is weak, - information missing from the system, - inadequate explanations, - excessive false alarms. Override behavior is a diagnostic signal rather than a metric that should always be minimized. ## Unit 17: Governance, Risk, and Responsible AI As decision impact grows, model management becomes part of organizational risk management. NIST AI Risk Management Framework 1.0 provides a voluntary, sector-agnostic structure for managing AI risks across the lifecycle. NIST's 2024 Generative AI Profile specializes that framework for generative-AI risks. ISO/IEC 23894:2023 provides AI risk-management guidance, while ISO/IEC 42001:2023 specifies an organizational AI management system. ISO/IEC 25010:2023 defines the current product quality model for software and ICT products. These standards do not replace the decision model. Their value is in structuring questions of responsibility, lifecycle control, measurement, and governance. ### Minimum control areas for high-impact decisions - data and model lineage, - access control and authorization, - data minimization, - threat modeling, - independent testing, - representation and bias analysis, - human approval and override, - action boundaries, - rollback, - incident records, - periodic reassessment. Decision risk is not limited to systems labeled as AI. A wrong optimization target, corrupted data, or a misleading interface can create severe decision risk without machine learning. ## Unit 18: End-to-End Example — Maintenance and Capacity Planning DSS Consider a system that schedules maintenance across many assets while preserving service capacity. ### Inputs - equipment health indicators, - predicted failure probabilities, - maintenance duration, - spare-parts availability, - workforce capacity, - service demand, - maintenance windows. ### Decision variables - which asset to maintain and when, - which team to assign, - which reserve resource to activate. ### Objectives - reduce unexpected failure risk, - reduce total maintenance cost, - preserve service capacity, - limit overtime. ### Architecture ```text sensors / maintenance records | v data quality + temporal alignment | +--> health prediction | +--> failure probability | v mixed-integer optimization | v candidate maintenance plans | +--> Monte Carlo stress test | v risk / cost / service trade-offs | v decision-maker interface | v approval -> work order -> observed outcome | +--------------------> feedback ``` The predictive model estimates failure risk; it does not determine the maintenance plan by itself. Optimization combines capacity, cost, staffing, and timing constraints. Simulation evaluates how robust the nominal plan is under uncertainty. A human decision maker can alter the recommendation when relevant field information is absent from the model. This is why a DSS is an end-to-end decision system rather than a synonym for an AI model. ## Common Design Failures - Treating a reporting dashboard as a DSS. - Converting a prediction score directly into an action. - Hiding data freshness. - Confusing probability with fuzzy membership. - Hiding preference weights as technical constants. - Assuming the optimization objective is identical to the real organizational objective. - Reducing model uncertainty to one narrow confidence interval. - Treating every human override as an error. - Treating explanation as evidence of correctness. - Using an LLM as a deterministic calculator or unrestricted decision authority. - Versioning models, data, and thresholds independently. - Leaving fallback behavior unspecified. - Measuring success only through model metrics. ## Related Courses Decision support is inherently multidisciplinary. [Probability and Statistics](/en/probability-statistics-distributions-sampling-regression) covers uncertainty and sampling; [Statistical Learning and Machine Learning](/en/statistical-learning-machine-learning) develops predictive models; [Artificial Intelligence](/en/artificial-intelligence-philosophy-theory-practice) covers AI foundations; [Fuzzy Logic](/en/fuzzy-logic) addresses linguistic uncertainty; [Genetic Algorithms and Their Applications](/en/genetic-algorithms-and-applications) covers heuristic optimization; [Cognitive Systems Engineering](/en/cognitive-systems-engineering) addresses joint human-machine decision work; [Engineering Management and Project Management](/en/engineering-management) provides the managerial setting; and [Software Engineering](/en/software-engineering-process-requirements-design-quality) provides lifecycle and quality foundations. ## References - Bubnicki, Zdzislaw. *Analysis and Decision Making in Uncertain Systems*. Springer, 2004. ISBN 1-85233-772-9. - Gupta, Jatinder N. D.; Forgionne, Guisseppi A.; Mora, Manuel (eds.). *Intelligent Decision-making Support Systems: Foundations, Applications and Challenges*. Springer, 2006. ISBN 978-1-84628-228-7. - ISO. *ISO 31000:2018 Risk management — Guidelines*. International Organization for Standardization, 2018. - ISO/IEC. *ISO/IEC 23894:2023 Information technology — Artificial intelligence — Guidance on risk management*. International Organization for Standardization / International Electrotechnical Commission, 2023. - ISO/IEC. *ISO/IEC 25010:2023 Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality model*. 2023. - ISO/IEC. *ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system*. 2023. - NIST. *Artificial Intelligence Risk Management Framework (AI RMF 1.0)*. NIST AI 100-1, 2023. DOI: https://doi.org/10.6028/NIST.AI.100-1 - NIST. *Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile*. NIST AI 600-1, 2024. DOI: https://doi.org/10.6028/NIST.AI.600-1 - O'Callaghan, Miriam. *Decision Intelligence: Human–Machine Integration for Decision-Making*. CRC Press, 2023. DOI: https://doi.org/10.1201/b23322 ## Cite This Work Köker, M. A. (2026). Decision Support Systems: Decision Analytics, Optimization, Uncertainty, and Decision Intelligence. alikoker.com.tr. https://alikoker.com.tr/en/decision-support-systems - BibTeX: https://alikoker.com.tr/en/decision-support-systems.bib - RIS: https://alikoker.com.tr/en/decision-support-systems.ris - CSL-JSON: https://alikoker.com.tr/en/decision-support-systems.csl.json