Software Engineering: Standing on the Shoulders of Giants

First Edition, 1.0b16.

📖 Read the book online at www.swebook.org.

This book is freely available and openly licensed, providing instruction in the principles and best practices of modern software engineering: how software is built in industry using agile methods, how to discover and analyze requirements, how to design and architect modular systems, how to check and test code, and how to measure quality with metrics.

The book is structured into fifteen chapters and a team project appendix, following the topic progression of the ACM/IEEE software‑engineering curriculum guidelines (SE2014/SEEK).¹ Each chapter contains original explanatory prose rather than material copied from other textbooks and is accompanied by a curated map of free or openly accessible resources — MOOCs, university courseware, primary specifications, and papers — with licenses noted where known. The material is designed to support a complete software‑engineering course.

An independent open educational resource. This is a complete, standalone book. Except for clearly attributed quotations and linked external resources, its explanatory prose, examples, diagrams, and exercises are original, and the book is released under Creative Commons. See curriculum/open-resources-map.md for the mapping from each chapter to complementary open materials. The prose was drafted with AI assistance under the author's direction, review, and fact-checking — see How this book was made below.

---

Who this book is for

This book is intended for upper-division undergraduate students who have completed at least two programming courses and are comfortable reading modular or object-oriented code, using a command line, and working with basic data structures. Prior experience with Git, automated testing, statistics, or cloud deployment is helpful but not required — each is taught from first principles in its chapter. Instructors will find ready-made course plans in curriculum/course-plan.md; self-learners can follow the suggested paths below.

Why this book exists

Most significant software is developed by teams, under evolving requirements, and with inevitable defects, at a scale that exceeds the capacity of any individual to fully comprehend. A typical programming course teaches students to write individual functions, whereas a software engineering course instructs students in building and evolving complete systems collaboratively. The discipline emphasizes enduring principles over proficiency in any single programming language:

1. Software is complex → we manage complexity with design and architecture.
2. Requirements change → we use iterative, agile methods to adapt.
3. Defects are inevitable → we use reviews, static checking, and testing to catch them.
4. Teams need coordination → we use processes, and a healthy balance of structure and flexibility.

These four foundational concepts are integrated throughout every chapter.

How the book is organized

The chapters are organized into thematic arcs:

Suggested paths through the book

• One-semester course (14–16 weeks). Cover the complete conceptual spine: most chapters get a week, Chapter 13's AI material is distributed across the term through its per-stage sections (§13.2), and selected advanced sections work as optional or independent reading — with the Appendix A team project running in parallel from week 2. Two ready-made week-by-week plans (a milestone track and a two-week-sprint track) are in curriculum/course-plan.md.
• One-quarter course (~10 weeks). Keep the spine and compress: Chapters 1–2 (week 1), 3–4 (weeks 2–3, folding Chapter 5's use-case notation into the requirements work), 6–8 (weeks 4–5, design, patterns, and version control), 9–10 (weeks 6–7, checking and testing), 11–12 (week 8, security and metrics), and 14–15 (week 9, delivery and evolution), with Chapter 13 (AI) read alongside each topic through its per-stage sections (§13.2). Run a scoped-down project: proposal, two sprints, final demo.
• For self-study, chapters should be read sequentially. Each chapter concludes with key takeaways, exercises, and free resources for further study. Alternatively, readers may use the arc table above to focus on a specific goal, such as Chapters 9–10 for checking and testing or Chapter 14 for CI/CD. Chapters cross-reference the earlier ideas they depend on.

Code examples in six languages

Every code example in the book is provided in Python, Java, JavaScript, Go, Ruby, and TypeScript, plus a language-agnostic Generic tab written in pseudocode, behind language tabs — pick your language once and the whole site follows (or open any page with ?lang=go to pre-select one). Each snippet also lives in code/ as a runnable file with a test, executed by continuous integration on every change.

The book is also available as an EPUB and a PDF, one edition per language plus a Generic (pseudocode) edition — identical prose, published with each tagged release:

EPUB: Generic · Python · Java · JavaScript · Go · Ruby · TypeScript   PDF: Generic · Python · Java · JavaScript · Go · Ruby · TypeScript

All editions, including past versions, are on the releases page.

Table of contents

The sidebar provides a complete, linked table of contents, including chapters and sections. Alternatively, readers may begin with any chapter of interest:

1. Introduction — what SE is, the requirements challenge, complexity, defects, the iron triangle, professional ethics.
2. Software Development Processes — plan vs. grow, Scrum, XP, waterfall/V, spiral & risk.
3. User Requirements — eliciting needs, user stories, features, scenarios, goals, security attack trees.
4. Requirements Analysis — estimation, planning poker, MoSCoW, Kano, value/cost/risk, COCOMO.
5. Use Cases — actors & goals, basic and alternative flows, use‑case diagrams and relationships.
6. Design and Architecture — modularity, coupling & cohesion, UML class diagrams, 4+1 views.
7. Architectural Patterns — layering, shared‑data, observer, pub‑sub, MVC, dataflow, client‑server, broker, REST, product lines.
8. Version Control with Git — the commit graph, branching/merging/rebase, remotes and pull requests, merge conflicts, team workflows, and Markdown for READMEs and documentation.
9. Static Checking — architecture reviews, inspections, code reviews, automated static analysis.
10. Testing — levels of testing, control‑flow & MC/DC coverage, black‑box coverage, combinatorial testing.
11. Software Security — the CIA triad and defense in depth, the OWASP Top 10:2025, SAST/DAST/SCA and AI‑assisted security testing, the open‑source supply chain (Log4Shell, xz‑utils, and continuous verification of components), and building security in.
12. Quality Metrics — meaningful metrics, defect measures, boxplots/histograms, statistics, confidence intervals, regression.
13. Software Engineering in the Age of AI — how AI reshapes every lifecycle stage, the productivity/quality/security evidence, and the o16g Outcome Engineering manifesto.
14. Delivery: CI/CD, DevOps, and Operations — SaaS and the cloud, CI pipelines, continuous deployment (the Knight Capital and CrowdStrike case studies), packaging with Docker, DNS/TLS/the edge, security pipelines, DORA metrics.
15. Maintenance and Evolution — legacy code, characterization tests, refactoring under green tests, technical debt, and the strangler-fig alternative to rewrites.

• Appendix A: The Team Project — proposal, sprint and status reports, team reviews, and final-report templates.

How to use this repository

• Learners are advised to read the chapters sequentially. Each chapter concludes with Key Takeaways, Exercises, and Open resources pointing to free courses and readings for deeper study.
• Instructors will find that the chapters align with a 14–16 week semester. Two ready-made plans (a milestone track and a two-week-sprint track) live in curriculum/course-plan.md. Run the team project from Appendix A on a parallel track. Reusable document templates (idea pitch, proposal, sprint and status reports, team review, final report, individual write-up) are linked from Appendix A.
• Contributors should consult CONTRIBUTING.md. This resource is intended to be a living, community‑improved resource.
• Apply the book to your own project. This repository ships a repository scorecard under .claude/skills/repo-scorecard/ — instructions an AI coding agent follows, with two modes. Adopt writes the book's practices into your project's AGENTS.md (TDD, BDD, requirements, design, commits, security, CI/CD, stewardship, and a definition of done), tailored to your stack and working on a new or existing project. Score then audits the repository against the nine parts of the book that cover the software lifecycle, returning a letter grade per area and findings that cite the chapter teaching each fix. Copy the folder into your project and ask your agent to set it up or score it; setup is in AGENTS.md and the classroom workflow is in Appendix A §A.6. Students can track progress across sprints; practitioners can switch scoring to a practitioner profile that weights quality, security, and delivery more heavily. It is plain Python, runs offline, and uploads nothing.

Building the book

The chapters are plain Markdown and render on GitHub as‑is. To build a browsable website with mdBook (for a PDF, print the site's built-in print page from your browser):

cargo install mdbook mdbook-mermaid   # one-time
mdbook serve                          # live preview at http://localhost:3000
mdbook build                          # outputs static site to ./book-output

SUMMARY.md is the mdBook table of contents; book.toml holds configuration.

How this book was made (AI assistance)

This book was written in collaboration with an AI assistant (Anthropic's Claude) under the author's direction. The author set the scope, chapter progression, and course alignment; supplied source material and corrections; fact-checked claims against the primary sources cited in each chapter's Open Resources page; and edited the prose throughout. The author has reviewed, and stands behind, every chapter. If you find an error, please open an issue, regardless of how it was introduced.

Chapter 13 teaches that professional AI use means disclosing the assistance, verifying the output, and owning the result. This note applies that standard to the book itself.

About the author

Thomas Hastings teaches software engineering at the University of Colorado Colorado Springs. This book started as part of his combined undergraduate and graduate course, CS 4300/5300. He also serves as an assistant professor (reservist) at the United States Air Force Academy, where he teaches in the Department of Computer and Cyber Sciences. He earned his Ph.D. in Engineering and M.Eng. in Software Engineering from UCCS, and his B.S. from Colorado Christian University. His research focuses on open-source software security and software supply chains, including the continuous verification of components.

The focus on testing, delivery, and running code in this book comes from real-world experience. Thomas has worked as a software engineer for over twenty years and is currently at Amazon Web Services. He keeps this book as an open, ongoing project. The views in this book are his own and do not reflect those of his employers.

Links: Google Scholar · tom.hastings.dev · GitHub

If this book helped you

If it helped you learn a topic, teach a course, or build something, the most useful thing you can do in return is star the repository on GitHub — it takes a second, and a star is how I get to see who the book is reaching: students, instructors, teams, and self‑learners. Knowing where it lands is what tells me the work is worth continuing, and it shapes what I write and fix next. If you have a moment for more than a click, I would genuinely love to hear how you are using it — a quick note in an issue naming your course, team, or project makes my week.

Citing this book

If you use this book in a course or reference it in your writing, please cite it. GitHub's "Cite this repository" button (from CITATION.cff) gives APA and BibTeX directly, or copy the BibTeX below.

Whole book:

@book{hastings2026swe,
  author    = {Hastings, Thomas},
  title     = {Software Engineering: Standing on the Shoulders of Giants},
  year      = {2026},
  publisher = {Self-published},
  url       = {https://www.swebook.org/},
  note      = {Open textbook, licensed CC BY-SA 4.0. Source:
               \url{https://github.com/tghastings/open-swe-book}}
}

A single chapter (adjust title, chapter, and url):

@inbook{hastings2026swe-ch14,
  author    = {Hastings, Thomas},
  title     = {Delivery: CI/CD, DevOps, and Operations},
  booktitle = {Software Engineering: Standing on the Shoulders of Giants},
  chapter   = {14},
  year      = {2026},
  publisher = {Self-published},
  url       = {https://www.swebook.org/chapters/14-delivery/}
}

The \url in note needs \usepackage{url} (or hyperref) in your LaTeX preamble; with biblatex you can move it to a urldate/addendum field instead. If you use a classic BibTeX style (plain, plainnat), swap @inbook for @incollection — those styles ignore booktitle inside @inbook.

Copyright and license

Copyright © 2026 Thomas Hastings. Unless otherwise noted, the text and figures are licensed CC BY‑SA 4.0; code examples are licensed MIT. You are free to share and adapt with attribution. All trademarks, product names, and company names are the property of their respective owners and are used for identification and educational purposes only. See also the LICENSE file.

Footnotes

1. ACM/IEEE‑CS Joint Task Force on Computing Curricula, Software Engineering 2014: Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering (SE2014), which defines the SEEK body of knowledge. acm.org/education/curricula-recommendations. ↩