Decomposition and Stepwise Reasoning: Breaking Problems into Algorithms

Last Updated June 17, 2026

Decomposition is the discipline of breaking a complex problem into smaller parts that can be understood, solved, tested, reused, and recombined. Stepwise reasoning is the discipline of arranging those parts into a coherent sequence of actions, decisions, transformations, and checks. Together, they form one of the most important habits in algorithmic thinking and computational reasoning.

Algorithms rarely begin as polished procedures. They usually begin as messy goals: organize information, search a space, classify a case, schedule work, simulate a system, transform data, or make a decision under constraints. Decomposition asks what smaller tasks are hidden inside the larger problem. Stepwise reasoning asks how those tasks should be ordered, connected, repeated, tested, and stopped. The result is not merely a list of instructions. It is a structured way of making complexity manageable without pretending that complexity has disappeared.

This article explains decomposition and stepwise reasoning as foundations of algorithmic thought. It examines how complex problems become modules, subproblems, functions, cases, workflows, decision rules, and reusable procedures. It also shows why decomposition is not only a coding technique. It is a reasoning practice that shapes how people define problems, distribute responsibility, organize knowledge, test assumptions, handle edge cases, and govern computational systems.

Why Decomposition Matters

Decomposition matters because complex problems overwhelm direct reasoning. A person cannot usually solve a large computational task in one mental step. The problem must be divided into parts: input preparation, representation, validation, transformation, decision rules, search, comparison, error handling, output generation, interpretation, and review.

This is true in programming, but it is also true in scientific modeling, public administration, data analysis, education, logistics, content systems, and institutional workflows. A search engine decomposes information retrieval into crawling, parsing, indexing, query interpretation, ranking, filtering, and presentation. A simulation decomposes a system into states, parameters, transition rules, time steps, scenario settings, and outputs. A public-service workflow decomposes a case into eligibility criteria, evidence, decision rules, review stages, appeals, and documentation.

Good decomposition does three things. First, it reduces cognitive load. Second, it creates units that can be tested and improved. Third, it exposes the structure of the reasoning process. Instead of saying “solve the problem,” decomposition asks, “What are the parts of this problem, what does each part do, and how do the parts fit together?”

Decomposition is not the same as simplification by neglect. It does not mean ignoring complexity. It means organizing complexity into parts that can be reasoned about, tested, and recombined.

Back to top ↑

What Is Decomposition?

Decomposition is the process of dividing a problem, system, workflow, or procedure into smaller components. Each component should have a purpose, boundary, input, output, and relationship to the larger whole. In computational reasoning, decomposition helps transform a vague task into a structured design.

A decomposition might produce subproblems, modules, functions, classes, services, database tables, data pipeline stages, model components, decision rules, test cases, or governance checkpoints. The form depends on the domain, but the reasoning pattern is consistent: separate the whole into parts whose roles can be understood.

A good decomposition should answer:

• What is the whole problem?
• What smaller tasks does it contain?
• Which tasks depend on other tasks?
• What input does each part require?
• What output does each part produce?
• What assumptions does each part make?
• How can each part be tested?
• How do the parts recombine into a complete result?

Decomposition is a design choice. The same problem can be decomposed in multiple ways. One decomposition may emphasize data flow. Another may emphasize user tasks. Another may emphasize mathematical structure. Another may emphasize institutional responsibility. The quality of decomposition depends on whether the parts are meaningful, coherent, testable, and appropriate to the purpose.

Back to top ↑

What Is Stepwise Reasoning?

Stepwise reasoning is the process of arranging actions, decisions, checks, and transformations into an ordered pathway. If decomposition identifies the parts, stepwise reasoning determines how those parts unfold over time or logic.

A step can validate input, transform data, compare values, update state, branch on a condition, repeat an operation, call a subroutine, stop a process, produce an output, or trigger review. Stepwise reasoning asks how these steps connect.

A simple stepwise structure might look like this:

1. receive input;
2. validate the input;
3. choose the relevant rule or procedure;
4. apply the rule;
5. check the result;
6. handle edge cases;
7. return output;
8. record evidence for review.

Stepwise reasoning is not only about order. It also involves conditions. Some steps happen only if a condition is true. Some steps repeat until a stopping condition is reached. Some steps call other procedures. Some steps produce evidence for later interpretation. Good stepwise reasoning makes these dependencies visible.

Back to top ↑

From Whole Problem to Subproblems

The first move in decomposition is to distinguish the whole problem from its subproblems. The whole problem states the overall goal. The subproblems identify the smaller tasks required to reach that goal.

For example, “build a search system” is too broad to implement directly. It can be decomposed into document ingestion, text cleaning, metadata extraction, indexing, query parsing, matching, ranking, filtering, logging, evaluation, and interface design. Each subproblem has its own inputs, outputs, assumptions, and failure modes.

A scheduling problem can be decomposed into worker availability, task demand, skill matching, legal constraints, fairness constraints, optimization criteria, exception handling, and review workflows. A machine-learning pipeline can be decomposed into data collection, labeling, feature construction, model training, validation, deployment, monitoring, and governance.

A strong decomposition is neither too coarse nor too fragmented. If the parts are too large, the problem remains vague. If the parts are too small, the structure becomes difficult to manage. The goal is to find meaningful units of reasoning.

Back to top ↑

Modules, Functions, and Responsibilities

In computational systems, decomposition often becomes modular design. A module is a bounded unit that performs a defined role. A function is a smaller unit that takes inputs, performs operations, and returns outputs. A service, class, package, database table, or workflow stage can also act as a decomposed component.

The key idea is responsibility. Each part should have a clear responsibility. A validation function should validate. A scoring function should score. A logging component should record. A review module should support review. When one component does too many things, reasoning becomes harder.

A well-decomposed system makes responsibility visible. It becomes easier to ask what each part does, how it can fail, what evidence it uses, and how it should be tested. This matters technically, but it also matters ethically. In consequential systems, responsibility should not disappear into the code.

Back to top ↑

Sequencing, Branching, and Iteration

Stepwise reasoning uses three common control patterns: sequencing, branching, and iteration. Sequencing arranges steps in order. Branching selects different paths under different conditions. Iteration repeats a step or group of steps until a condition is met.

Sequencing is the simplest pattern:

Branching introduces conditional logic:

Iteration repeats:

These patterns are basic, but they are powerful. Most complex computational systems are built from combinations of sequences, branches, loops, nested calls, and pipelines.

Back to top ↑

Recursion and Nested Structure

Recursion is a special form of decomposition. A recursive procedure solves a problem by reducing it to smaller versions of itself. Trees, hierarchies, nested documents, search spaces, mathematical definitions, parsing systems, and divide-and-conquer algorithms often have recursive structure.

A recursive procedure needs two things: a base case and a recursive case. The base case stops the process. The recursive case reduces the problem toward the base case.

A divide-and-conquer pattern often looks like this:

Recursion shows that decomposition is not always flat. Some problems contain the same structure at multiple levels. A document contains sections, sections contain paragraphs, paragraphs contain sentences, and sentences contain words. A tree contains subtrees. A graph search explores neighboring states. A mathematical proof may rely on smaller cases. A computational workflow may contain nested workflows.

Recursive reasoning can be elegant, but it requires care. Without a clear base case, recursion may not terminate. Without a good reduction rule, the problem may not become simpler. Without attention to resources, recursive procedures may use too much memory or repeated work.

Back to top ↑

Testing, Debugging, and Verification

Decomposition improves testing because it creates smaller units to examine. Instead of testing only the whole system, we can test the validator, parser, scoring function, state update, sorting routine, decision rule, database query, output formatter, and audit logger separately.

Stepwise reasoning improves debugging because it provides a path to trace. When output is wrong, the question becomes: at which step did the reasoning fail? Was the input wrong? Was a condition misread? Was a branch taken incorrectly? Did a loop stop too early? Did a subproblem return an unexpected result? Did the output interpretation exceed the evidence?

Testing is not only a software practice. It is a reasoning practice. Decomposition tells us what to test. Stepwise reasoning tells us where to look when something breaks.

Back to top ↑

Decomposition Risk

Decomposition is powerful, but it can also create risks. A poor decomposition can split a problem in ways that hide important relationships. It can assign responsibility to components that cannot actually bear it. It can create fragmented systems where no one understands the whole. It can make local optimization look successful while system-level outcomes worsen.

For example, a platform might decompose content ranking into engagement prediction, ad placement, moderation, and recommendation. Each component may appear to work locally. But together they may create feedback loops that shape attention in harmful ways. A public agency might decompose eligibility into forms, data checks, scoring rules, and review queues. Each stage may have a purpose, but the combined system may create burden, delay, or unfair outcomes.

Good decomposition therefore requires recomposition. After splitting the problem, we must ask how the parts fit together, what system behavior emerges, and whether the whole still serves the original purpose.

Back to top ↑

Back to top ↑

Mathematics, Computation, and Modeling

Mathematically, decomposition can be represented as a mapping from a whole problem to a structured set of subproblems. The goal is not only to divide the problem, but also to preserve the relationships that make the whole meaningful.

A stepwise procedure can be represented as a sequence of transformations:

A modular system can be represented as a graph:

A quality model for decomposition can be written as:

This mathematical framing helps show why decomposition is not just “breaking things apart.” It is structured reasoning about parts, relationships, sequence, and system integrity.

Back to top ↑

Python Workflow: Decomposition Audit

The Python workflow below creates a simple decomposition audit for synthetic computational systems. It scores decomposition quality using criteria such as subproblem clarity, boundary definition, input-output clarity, sequencing, dependency visibility, testability, traceability, recomposition quality, governance readiness, and risk awareness.

# decomposition_audit.py
# Dependency-light workflow for auditing decomposition and stepwise reasoning.

from __future__ import annotations

from dataclasses import asdict, dataclass
from pathlib import Path
import csv
import json
from statistics import mean

ARTICLE_ROOT = Path(__file__).resolve().parents[1]
TABLES = ARTICLE_ROOT / "outputs" / "tables"
JSON_DIR = ARTICLE_ROOT / "outputs" / "json"


@dataclass(frozen=True)
class DecompositionCase:
    case_name: str
    whole_problem: str
    decomposition_strategy: str
    subproblem_clarity: float
    boundary_definition: float
    input_output_clarity: float
    sequencing_quality: float
    dependency_visibility: float
    testability: float
    traceability: float
    recomposition_quality: float
    governance_readiness: float
    risk_awareness: float


def clamp(value: float, low: float = 0.0, high: float = 100.0) -> float:
    return max(low, min(high, value))


def decomposition_score(case: DecompositionCase) -> float:
    return clamp(
        100.0 * (
            0.12 * case.subproblem_clarity
            + 0.10 * case.boundary_definition
            + 0.10 * case.input_output_clarity
            + 0.10 * case.sequencing_quality
            + 0.10 * case.dependency_visibility
            + 0.12 * case.testability
            + 0.10 * case.traceability
            + 0.10 * case.recomposition_quality
            + 0.08 * case.governance_readiness
            + 0.08 * case.risk_awareness
        )
    )


def decomposition_risk(case: DecompositionCase) -> float:
    weak_points = [
        1.0 - case.boundary_definition,
        1.0 - case.dependency_visibility,
        1.0 - case.traceability,
        1.0 - case.recomposition_quality,
        1.0 - case.governance_readiness,
        1.0 - case.risk_awareness,
    ]
    return clamp(100.0 * mean(weak_points))


def diagnose(score: float, risk: float) -> str:
    if score >= 80 and risk <= 25:
        return "strong decomposition with clear stepwise reasoning"
    if score >= 65 and risk <= 40:
        return "usable decomposition with review needs"
    if risk >= 55:
        return "high decomposition risk; relationships and recomposition need review"
    return "partial decomposition; boundaries, dependencies, or governance need strengthening"


def build_cases() -> list[DecompositionCase]:
    return [
        DecompositionCase(
            case_name="Search system",
            whole_problem="Help users find relevant information.",
            decomposition_strategy="Crawl, parse, index, query, rank, filter, evaluate.",
            subproblem_clarity=0.82,
            boundary_definition=0.78,
            input_output_clarity=0.80,
            sequencing_quality=0.82,
            dependency_visibility=0.72,
            testability=0.76,
            traceability=0.68,
            recomposition_quality=0.72,
            governance_readiness=0.58,
            risk_awareness=0.62,
        ),
        DecompositionCase(
            case_name="Public decision-support workflow",
            whole_problem="Prioritize cases while preserving fairness and accountability.",
            decomposition_strategy="Evidence checks, scoring, review, appeal, documentation, monitoring.",
            subproblem_clarity=0.74,
            boundary_definition=0.66,
            input_output_clarity=0.70,
            sequencing_quality=0.68,
            dependency_visibility=0.60,
            testability=0.66,
            traceability=0.72,
            recomposition_quality=0.58,
            governance_readiness=0.76,
            risk_awareness=0.80,
        ),
        DecompositionCase(
            case_name="Scientific simulation",
            whole_problem="Explore how a dynamic system changes under scenarios.",
            decomposition_strategy="States, parameters, transition rules, numerical method, scenarios, outputs.",
            subproblem_clarity=0.86,
            boundary_definition=0.82,
            input_output_clarity=0.84,
            sequencing_quality=0.80,
            dependency_visibility=0.78,
            testability=0.76,
            traceability=0.78,
            recomposition_quality=0.82,
            governance_readiness=0.70,
            risk_awareness=0.76,
        ),
        DecompositionCase(
            case_name="Knowledge architecture",
            whole_problem="Organize a research library for discovery, navigation, and reuse.",
            decomposition_strategy="Categories, article maps, metadata, internal links, search, update workflow.",
            subproblem_clarity=0.80,
            boundary_definition=0.76,
            input_output_clarity=0.72,
            sequencing_quality=0.74,
            dependency_visibility=0.70,
            testability=0.64,
            traceability=0.72,
            recomposition_quality=0.80,
            governance_readiness=0.68,
            risk_awareness=0.70,
        ),
    ]


def run_audit() -> list[dict[str, object]]:
    rows: list[dict[str, object]] = []
    for case in build_cases():
        score = decomposition_score(case)
        risk = decomposition_risk(case)
        rows.append({
            **asdict(case),
            "decomposition_score": round(score, 3),
            "decomposition_risk": round(risk, 3),
            "diagnostic": diagnose(score, risk),
        })
    return rows


def write_csv(path: Path, rows: list[dict[str, object]]) -> None:
    path.parent.mkdir(parents=True, exist_ok=True)
    with path.open("w", newline="", encoding="utf-8") as handle:
        writer = csv.DictWriter(handle, fieldnames=list(rows[0].keys()))
        writer.writeheader()
        writer.writerows(rows)


def write_json(path: Path, payload: object) -> None:
    path.parent.mkdir(parents=True, exist_ok=True)
    path.write_text(json.dumps(payload, indent=2, sort_keys=True), encoding="utf-8")


def summarize(rows: list[dict[str, object]]) -> dict[str, object]:
    return {
        "case_count": len(rows),
        "average_decomposition_score": round(mean(float(row["decomposition_score"]) for row in rows), 3),
        "average_decomposition_risk": round(mean(float(row["decomposition_risk"]) for row in rows), 3),
        "highest_score_case": max(rows, key=lambda row: float(row["decomposition_score"]))["case_name"],
        "highest_risk_case": max(rows, key=lambda row: float(row["decomposition_risk"]))["case_name"],
        "interpretation": "Decomposition quality depends on clear subproblems, boundaries, inputs, outputs, sequencing, dependencies, tests, traceability, recomposition, governance, and risk awareness."
    }


def main() -> None:
    rows = run_audit()
    summary = summarize(rows)

    write_csv(TABLES / "decomposition_audit.csv", rows)
    write_csv(TABLES / "decomposition_audit_summary.csv", [summary])
    write_json(JSON_DIR / "decomposition_audit.json", rows)
    write_json(JSON_DIR / "decomposition_audit_summary.json", summary)

    print("Decomposition audit complete.")
    print(TABLES / "decomposition_audit.csv")


if __name__ == "__main__":
    main()

The workflow treats decomposition as a reviewable reasoning layer. It asks whether the problem has been divided into meaningful parts, whether those parts have clear boundaries, whether their dependencies are visible, and whether the parts can be recombined into a coherent whole.

Back to top ↑

R Workflow: Decomposition Summary and Visualization

The R workflow reads the Python-generated audit table and creates summary outputs and visualizations using base R. It compares decomposition score and decomposition risk across synthetic cases.

# decomposition_audit_summary.R
# Base R workflow for summarizing decomposition quality and risk.

args <- commandArgs(trailingOnly = FALSE)
file_arg <- grep("^--file=", args, value = TRUE)

if (length(file_arg) > 0) {
  script_path <- normalizePath(sub("^--file=", "", file_arg[1]), mustWork = TRUE)
  article_root <- normalizePath(file.path(dirname(script_path), ".."), mustWork = TRUE)
} else {
  article_root <- getwd()
}

setwd(article_root)

tables_dir <- file.path(article_root, "outputs", "tables")
figures_dir <- file.path(article_root, "outputs", "figures")

if (!dir.exists(tables_dir)) {
  dir.create(tables_dir, recursive = TRUE)
}

if (!dir.exists(figures_dir)) {
  dir.create(figures_dir, recursive = TRUE)
}

input_path <- file.path(tables_dir, "decomposition_audit.csv")

if (!file.exists(input_path)) {
  stop(paste("Missing", input_path, "Run the Python workflow first."))
}

data <- read.csv(input_path, stringsAsFactors = FALSE)

summary_table <- data.frame(
  case_count = nrow(data),
  average_decomposition_score = mean(data$decomposition_score),
  average_decomposition_risk = mean(data$decomposition_risk),
  highest_score_case = data$case_name[which.max(data$decomposition_score)],
  highest_risk_case = data$case_name[which.max(data$decomposition_risk)]
)

write.csv(
  summary_table,
  file.path(tables_dir, "r_decomposition_audit_summary.csv"),
  row.names = FALSE
)

comparison_matrix <- rbind(
  data$decomposition_score,
  data$decomposition_risk
)

colnames(comparison_matrix) <- data$case_name
rownames(comparison_matrix) <- c("Decomposition score", "Decomposition risk")

png(
  file.path(figures_dir, "decomposition_score_vs_risk.png"),
  width = 1400,
  height = 800
)

barplot(
  comparison_matrix,
  beside = TRUE,
  las = 2,
  ylim = c(0, 100),
  ylab = "Score",
  main = "Decomposition Score vs. Decomposition Risk"
)

legend(
  "topleft",
  legend = rownames(comparison_matrix),
  pch = 15,
  bty = "n"
)

grid()
dev.off()

png(
  file.path(figures_dir, "decomposition_risk_by_case.png"),
  width = 1400,
  height = 800
)

barplot(
  data$decomposition_risk,
  names.arg = data$case_name,
  las = 2,
  ylim = c(0, 100),
  ylab = "Decomposition risk",
  main = "Decomposition Risk by Case"
)

grid()
dev.off()

print(summary_table)

This workflow supports the article’s argument that decomposition should be assessed, not assumed. A system can be divided into parts and still fail if boundaries, dependencies, tests, and recomposition are weak.

Back to top ↑

GitHub Repository

The companion repository for this article will provide reproducible code, synthetic datasets, workflow documentation, generated outputs, and decomposition-audit diagnostics that extend the article into executable examples.

articles/decomposition-and-stepwise-reasoning/
├── python/
│   ├── decomposition_audit.py
│   ├── problem_decomposer.py
│   ├── stepwise_reasoning_trace.py
│   ├── dependency_graph_builder.py
│   ├── recomposition_checks.py
│   ├── calculators/
│   │   ├── decomposition_score_calculator.py
│   │   └── dependency_risk_calculator.py
│   └── tests/
├── r/
│   ├── decomposition_audit_summary.R
│   ├── decomposition_risk_visualization.R
│   └── stepwise_reasoning_report.R
├── julia/
│   ├── recursive_decomposition_simulation.jl
│   └── dependency_graph_model.jl
├── sql/
│   ├── schema_decomposition_cases.sql
│   ├── schema_dependency_traces.sql
│   └── decomposition_queries.sql
├── haskell/
│   ├── DecompositionTypes.hs
│   ├── RecursiveReasoning.hs
│   └── Main.hs
├── rust/
│   └── src/
├── go/
│   └── main.go
├── c/
│   └── decomposition_audit.c
├── cpp/
│   └── decomposition_audit.cpp
├── fortran/
│   └── decomposition_model.f90
├── java/
│   └── src/main/java/org/contentcatalyst/algorithms/
├── typescript/
│   └── src/
├── prolog/
│   └── decomposition_rules.pl
├── racket/
│   └── recursive_decomposition_interpreter.rkt
├── docs/
│   ├── methodology.md
│   ├── article-notes.md
│   ├── decomposition-and-stepwise-reasoning.md
│   ├── governance-notes.md
│   └── responsible-use.md
├── data/
│   └── synthetic_decomposition_cases.csv
├── outputs/
│   ├── tables/
│   ├── figures/
│   ├── json/
│   ├── logs/
│   └── reports/
├── notebooks/
│   └── decomposition_stepwise_reasoning_walkthrough.ipynb
├── canvas/
│   ├── canvas_manifest.json
│   ├── canvas_cards.json
│   └── canvas_index.md
└── shared/
    ├── schemas/
    ├── templates/
    ├── taxonomies/
    ├── benchmarks/
    └── governance/

Back to top ↑

A Practical Method for Decomposition and Stepwise Reasoning

A practical decomposition method begins with the whole problem and ends with a recomposed, testable workflow. The purpose is not merely to divide work. The purpose is to create a structure that supports understanding, execution, testing, interpretation, and governance.

This method keeps decomposition connected to the whole problem. Each part should be understandable on its own, but the final system must also make sense when the parts are recombined.

Back to top ↑

Common Pitfalls

The most common pitfall is decomposing too quickly. When a problem is split before it is understood, the decomposition may reflect habit, software convenience, organizational structure, or available data rather than the actual problem.

Another pitfall is treating decomposition as purely technical. In real systems, the way a problem is divided can shape responsibility, visibility, burden, and accountability. A decision-support system that separates data collection, scoring, review, and appeal may appear orderly, but if those parts do not communicate well, affected people may be left without meaningful explanation or recourse.

Common pitfalls include:

• premature decomposition: splitting a problem before understanding its purpose and context;
• over-fragmentation: creating too many small parts with unclear relationships;
• under-decomposition: leaving large vague components that cannot be tested;
• weak boundaries: allowing components to perform too many unrelated responsibilities;
• hidden dependencies: failing to document how parts rely on one another;
• interface confusion: producing outputs that other components cannot use responsibly;
• local optimization: improving components while degrading system-level outcomes;
• context loss: removing meaning when the problem is split into fields, scores, or tasks;
• testing gaps: testing parts separately without testing recomposition;
• responsibility diffusion: spreading accountability across modules until no one owns the outcome.

Good decomposition is reversible in thought. A person should be able to move from the whole to the parts and back again. If the parts cannot be recomposed into a meaningful explanation of the whole, the decomposition needs review.

Back to top ↑

Why Decomposition Is More Than Splitting Things Apart

Decomposition and stepwise reasoning are foundational because they make complex problems tractable. They help us name subproblems, define responsibilities, order operations, test components, trace errors, and build reusable procedures. Without them, computational work remains vague or brittle.

But decomposition is more than splitting things apart. It is a disciplined way of preserving meaning while reducing complexity. The parts must be meaningful. Their boundaries must be clear. Their relationships must be visible. Their outputs must support interpretation. Their recomposition must still serve the original purpose.

Stepwise reasoning adds motion to decomposition. It turns parts into a pathway: first this, then that, under these conditions, until this stopping rule is reached. Together, decomposition and stepwise reasoning give algorithmic thinking its structure. They also give computational reasoning a way to inspect, test, and govern how complexity becomes procedure.

Back to top ↑

Related Articles

• What Is Algorithms & Computational Reasoning?
• Algorithmic Thinking vs. Computational Reasoning
• Problems, Procedures, and Formalization
• Abstraction in Computational Reasoning
• Inputs, Outputs, States, and Stopping Conditions
• From Pseudocode to Programs
• Debugging as Computational Reasoning
• Algorithm Design Principles

Further Reading

• Cormen, T.H., Leiserson, C.E., Rivest, R.L. and Stein, C. (2022) Introduction to Algorithms. 4th edn. Cambridge, MA: MIT Press. Available at: MIT Press.
• Abelson, H., Sussman, G.J. and Sussman, J. (1996) Structure and Interpretation of Computer Programs. 2nd edn. Cambridge, MA: MIT Press. Available at: MIT Press.
• Sedgewick, R. and Wayne, K. (2011) Algorithms. 4th edn. Boston, MA: Addison-Wesley. Companion materials available at: Princeton University.
• Dasgupta, S., Papadimitriou, C.H. and Vazirani, U.V. (2008) Algorithms. New York: McGraw-Hill. Available at: University of California, Berkeley.
• Knuth, D.E. (1997) The Art of Computer Programming, Volume 1: Fundamental Algorithms. 3rd edn. Reading, MA: Addison-Wesley. Author information available at: Stanford University.
• Wirth, N. (1976) Algorithms + Data Structures = Programs. Englewood Cliffs, NJ: Prentice-Hall. Author archive available at: ETH Zürich.
• Dijkstra, E.W. (1968) ‘Go To Statement Considered Harmful’, Communications of the ACM, 11(3), pp. 147–148. Available at: ACM Digital Library.
• Parnas, D.L. (1972) ‘On the criteria to be used in decomposing systems into modules’, Communications of the ACM, 15(12), pp. 1053–1058. Available at: ACM Digital Library.
• Hoare, C.A.R. (1969) ‘An axiomatic basis for computer programming’, Communications of the ACM, 12(10), pp. 576–580. Available at: ACM Digital Library.
• Brooks, F.P. Jr. (1987) ‘No Silver Bullet: Essence and Accidents of Software Engineering’, Computer, 20(4), pp. 10–19. Available at: ACM Digital Library.
• Jackson, M. (2001) Problem Frames: Analysing and Structuring Software Development Problems. Boston, MA: Addison-Wesley. Bibliographic record available at: Google Books.
• Polya, G. (1957) How to Solve It: A New Aspect of Mathematical Method. 2nd edn. Princeton, NJ: Princeton University Press. Available at: Princeton University Press.
• Simon, H.A. (1996) The Sciences of the Artificial. 3rd edn. Cambridge, MA: MIT Press. Available at: MIT Press.
• Wing, J.M. (2006) ‘Computational thinking’, Communications of the ACM, 49(3), pp. 33–35. Available at: ACM Digital Library.
• National Research Council (2010) Report of a Workshop on the Scope and Nature of Computational Thinking. Washington, DC: The National Academies Press. Available at: National Academies Press.
• ISO/IEC/IEEE (2018) ISO/IEC/IEEE 29148:2018 Systems and Software Engineering — Life Cycle Processes — Requirements Engineering. Geneva: International Organization for Standardization. Available at: ISO.
• National Institute of Standards and Technology (2023) Artificial Intelligence Risk Management Framework (AI RMF 1.0). Gaithersburg, MD: NIST. Available at: NIST.
• Mitchell, M., Wu, S., Zaldivar, A., Barnes, P., Vasserman, L., Hutchinson, B., Spitzer, E., Raji, I.D. and Gebru, T. (2019) ‘Model Cards for Model Reporting’, in Proceedings of the Conference on Fairness, Accountability, and Transparency. New York: ACM, pp. 220–229. Available at: ACM Digital Library.

References

• Abelson, H., Sussman, G.J. and Sussman, J. (1996) Structure and Interpretation of Computer Programs. 2nd edn. Cambridge, MA: MIT Press. Available at: https://mitpress.mit.edu/9780262510875/structure-and-interpretation-of-computer-programs/.
• Brooks, F.P. Jr. (1987) ‘No Silver Bullet: Essence and Accidents of Software Engineering’, Computer, 20(4), pp. 10–19. doi: 10.1109/MC.1987.1663532.
• Cormen, T.H., Leiserson, C.E., Rivest, R.L. and Stein, C. (2022) Introduction to Algorithms. 4th edn. Cambridge, MA: MIT Press. Available at: https://mitpress.mit.edu/9780262046305/introduction-to-algorithms/.
• Dasgupta, S., Papadimitriou, C.H. and Vazirani, U.V. (2008) Algorithms. New York: McGraw-Hill. Available at: https://people.eecs.berkeley.edu/~vazirani/algorithms.html.
• Dijkstra, E.W. (1968) ‘Go To Statement Considered Harmful’, Communications of the ACM, 11(3), pp. 147–148. doi: 10.1145/362929.362947.
• Hoare, C.A.R. (1969) ‘An axiomatic basis for computer programming’, Communications of the ACM, 12(10), pp. 576–580. doi: 10.1145/363235.363259.
• ISO/IEC/IEEE (2018) ISO/IEC/IEEE 29148:2018 Systems and Software Engineering — Life Cycle Processes — Requirements Engineering. Geneva: International Organization for Standardization. Available at: https://www.iso.org/standard/72089.html.
• Jackson, M. (2001) Problem Frames: Analysing and Structuring Software Development Problems. Boston, MA: Addison-Wesley. Bibliographic record available at: https://books.google.com/books/about/Problem_Frames.html?id=j6hQAAAAMAAJ.
• Knuth, D.E. (1997) The Art of Computer Programming, Volume 1: Fundamental Algorithms. 3rd edn. Reading, MA: Addison-Wesley. Author information available at: https://www-cs-faculty.stanford.edu/~knuth/taocp.html.
• Mitchell, M., Wu, S., Zaldivar, A., Barnes, P., Vasserman, L., Hutchinson, B., Spitzer, E., Raji, I.D. and Gebru, T. (2019) ‘Model Cards for Model Reporting’, in Proceedings of the Conference on Fairness, Accountability, and Transparency. New York: ACM, pp. 220–229. doi: 10.1145/3287560.3287596.
• National Institute of Standards and Technology (2023) Artificial Intelligence Risk Management Framework (AI RMF 1.0). Gaithersburg, MD: NIST. Available at: https://www.nist.gov/itl/ai-risk-management-framework.
• National Research Council (2010) Report of a Workshop on the Scope and Nature of Computational Thinking. Washington, DC: The National Academies Press. doi: 10.17226/12840.
• Parnas, D.L. (1972) ‘On the criteria to be used in decomposing systems into modules’, Communications of the ACM, 15(12), pp. 1053–1058. doi: 10.1145/361598.361623.
• Polya, G. (1957) How to Solve It: A New Aspect of Mathematical Method. 2nd edn. Princeton, NJ: Princeton University Press. Available at: https://press.princeton.edu/books/paperback/9780691164076/how-to-solve-it.
• Sedgewick, R. and Wayne, K. (2011) Algorithms. 4th edn. Boston, MA: Addison-Wesley. Companion materials available at: https://algs4.cs.princeton.edu/home/.
• Simon, H.A. (1996) The Sciences of the Artificial. 3rd edn. Cambridge, MA: MIT Press. Available at: https://mitpress.mit.edu/9780262691918/the-sciences-of-the-artificial/.
• Wing, J.M. (2006) ‘Computational thinking’, Communications of the ACM, 49(3), pp. 33–35. doi: 10.1145/1118178.1118215.
• Wirth, N. (1976) Algorithms + Data Structures = Programs. Englewood Cliffs, NJ: Prentice-Hall. Author archive available at: https://people.inf.ethz.ch/wirth/.

Back to top ↑