Computer Science › Software + Distributed Computing
The IEEE Computer Society's SWEBOK Guide splits software engineering into eighteen knowledge areas, and Software Construction (writing, testing, and debugging individual units of code, already covered in full by this curriculum's sibling discipline) is only one of them: this concept draws the real, citable boundary between that already-published discipline and the four knowledge areas this one actually covers, Software Requirements, Software Engineering Process, Software Engineering Management, and the newly added Software Engineering Operations, plus Software Engineering Economics for the technical-debt closing concept.
Ward Cunningham coined the technical debt metaphor in a 1992 OOPSLA experience report about a real system, WyCash, writing that shipping not-quite-right code is like going into debt, tolerable only if it gets paid back promptly, because every minute spent afterward working around not-quite-right code counts as interest, and this concept treats that metaphor as a genuine tool of Software Engineering Economics (SWEBOK's own name for the knowledge area), not a vague complaint, giving debt a concrete owner, a concrete interest rate, and a concrete payoff point, with refactoring named honestly as the real repayment mechanism.
Martin Fowler credits Kent Beck's Extreme Programming with the practice and defines Continuous Integration precisely: every team member merges changes into a shared mainline at least daily, and every merge triggers an automated, self-testing build that must stay fast enough to give feedback within minutes, and this concept works through why each of Fowler's eleven practices (a single source repository, a fully automated and self-testing build, fixing a broken build immediately) exists to defend that one property, fast feedback on whether the mainline still works.
Fowler draws the exact line between two terms routinely used as synonyms: Continuous Delivery means every change that passes the pipeline is proven ready to release, but a human still decides when to actually release it, while Continuous Deployment removes that decision and releases every change that passes the pipeline straight to production automatically, and this concept works through why Continuous Deployment is strictly a stronger, riskier commitment built on top of Continuous Delivery, never a separate, independent choice.
A real CI/CD pipeline is a strict sequence of gated stages, typically build, then automated test, then package, then deploy, where each stage's job is to fail fast and cheaply on the kind of problem it is best positioned to catch, and this concept traces a commit through all four stages of a concrete pipeline, including why the package stage packaging the application into a container image is the step that finally makes the tested artifact and the deployed artifact provably identical.
Blue-green deployment, per Fowler, keeps two complete production environments and cuts traffic from one to the other in a single switch, buying an instant, clean rollback at the cost of running double the infrastructure during the switch, while canary release routes only a small slice of real traffic to the new version first and grows that slice as confidence builds, buying earlier detection of a bad release at the cost of running two versions side by side for longer, and this concept lays out honestly which real failure each strategy actually catches and which it does not.
Cindy Sridharan's practitioner writing popularized the now-standard framing of observability as three complementary data types, logs (discrete, timestamped events), metrics (aggregated numeric measurements over time), and traces (the causal path of one request across every service it touched), and this concept works through why a production incident that only one of the three can actually explain is common, then grounds the framing in two real, already-published applied examples at two different scales, a single Spring Boot service's health endpoint and a distributed system's tracing infrastructure.
Winston Royce's 1970 paper is the source everyone cites for the waterfall model (requirements, then design, then implementation, then testing, then maintenance, strictly in sequence with no going back), but Royce's own paper described that strict sequential version as risky and recommended against it in the very same document, an irony worth stating honestly rather than repeating the misattribution, before this concept turns to why the model nonetheless spread, what it actually gets right (a shared vocabulary for phases every later model still uses), and where iterative and incremental models arose specifically as its correction.
Software Engineering Management, SWEBOK's knowledge area for the activities that plan and control a project rather than the code inside it, treats estimation and risk as two sides of the same problem: an estimate is a probability distribution, not a single number, and a risk register turns unknowns identified during estimation into tracked items with a likelihood, an impact, and an owner, which this concept demonstrates against a small, concrete project plan rather than leaving both ideas at the level of vocabulary.
David Anderson's Kanban Method, formalized in his 2010 book after years of applying manufacturing-style kanban systems to knowledge work at Corbis and Microsoft, replaces Scrum's fixed timebox with a continuous pull system limited by explicit work-in-progress (WIP) limits per stage, and this concept works through why a WIP limit, not a burndown chart, is the mechanism that actually surfaces a bottleneck, using a cumulative flow diagram to make a stalled stage visible before it becomes a missed deadline.
Scrum, as defined precisely by its own official guide rather than by how a certification course markets it, prescribes exactly three accountabilities (Developers, Product Owner, Scrum Master), five events (the Sprint itself as a timebox, Sprint Planning, the Daily Scrum, Sprint Review, Sprint Retrospective), and three artifacts (Product Backlog, Sprint Backlog, Increment), and this concept walks through what each one actually requires and, honestly, what tradeoff Scrum's fixed timebox makes against a continuously flowing alternative.
XP's concrete practices, such as pair programming, test-first development, continuous integration, refactoring, and small releases, as a set that reinforces itself, with the real evidence on pair programming and an honest account of which practices became common.
The Lean principles as applied to software by the Poppendiecks (eliminating waste, deciding as late as responsibly possible, and seeing the whole), with flow, queues, and how they relate to Kanban, XP, and Scrum.
Requirements engineering, per Sommerville's standard textbook treatment, is not a single step but three distinct activities performed in a loop, elicitation (discovering what stakeholders actually need, often despite stakeholders themselves not knowing precisely), specification (writing that need down in a form precise enough to build against), and validation (checking the written specification actually matches the real need before a single line of implementation code exists), and this concept works through why skipping any one of the three, not just skipping requirements altogether, is the failure mode that actually shows up on real projects.
User stories and their acceptance criteria, splitting epics, and ordering a product backlog, as the agile counterpart of a requirements specification.
Velocity, burndown, and burnup charts: how to read them, what they forecast, and why velocity is not a productivity measure.
Barry Boehm's data from TRW, IBM, GTE, and the Bell Labs Safeguard program, gathered across dozens of real waterfall projects and published in Software Engineering Economics (1981), showed the cost of fixing a defect rising roughly an order of magnitude at each phase it goes undetected, but the popularized 1:10:100 rule oversimplifies a real range (roughly 3x to 8x by design, 30x to 200x by operations, varying by project type), and this concept states the honest version of the finding, including why the specific multipliers should never be quoted as a fixed law.
A functional requirement states what a system must do (a specific behavior, given a specific input), while a non-functional requirement constrains how well or under what conditions it must do it (latency, availability, security, maintainability), and the two fail differently in practice: a missed functional requirement produces a visible, reportable bug, while a missed non-functional requirement often produces a system that passes every functional test and still cannot survive its first real week in production.
Why teams model at all, UML as sketch versus blueprint, and which diagrams are still drawn in practice.
Classes, attributes, operations, associations, multiplicity, aggregation, composition, and inheritance, with object diagrams as concrete snapshots.
Actors, use-case diagrams, include and extend, and writing a use-case description with main and alternative flows.
Lifelines, synchronous and asynchronous messages, activation, and combined fragments, for reading and drawing an interaction over time.
BPMN's events, activities, gateways, and swimlanes, and how to model a business process that crosses several roles.
The product quality model of ISO/IEC 25010:2023, its nine characteristics, what the 2023 revision changed from 2011 (including moving the quality-in-use model out), and how a quality characteristic becomes a measurable requirement.
A short history of CMM and CMMI: why they appeared, what the five maturity levels said and did not say, who owns CMMI today, and what industry practice added. Framed as book versus today, never as current practice.
Defect density, churn, complexity, coverage, and delivery metrics, what each one can and cannot tell you, and how any of them degrades once it becomes a target.
A non-functional requirement (a target latency, an availability number, an expected request volume) is what actually forces an architecture decision, not taste or fashion, and this concept treats the moment a team commits to client-server versus layered versus something more distributed as a decision that should be written down as an Architecture Decision Record naming the requirement that drove it, deliberately not re-deriving architecture styles this curriculum already covers elsewhere, at two different depths, in two different sibling disciplines.
This capstone traces one written requirement through the entire lifecycle this discipline has covered end to end: elicited and specified, turned into a non-functional target that forces an architecture decision, built and tested at the unit level (handed off explicitly to the sibling discipline that owns that step), carried through a CI/CD pipeline into a canary deployment, watched in production by exactly the observability signal that would catch its specific failure mode, and finally closed with a deliberate, logged technical debt entry for a shortcut taken under real deadline pressure, the same amarra-tudo pattern every capstone on this platform uses, applied here to the surrounding process rather than to the code.
Requirements do not hold still once written down, they change as stakeholders learn more, and requirements management is the discipline of tracking a live link from each requirement forward to the design decisions, code, and tests that satisfy it, and backward from any proposed change to every requirement it would affect, through a traceability matrix and a change control process that decides, deliberately, whether a given change is worth its ripple effect.
Part of the Computer Science curriculum.
The IEEE Computer Society's SWEBOK Guide splits software engineering into eighteen knowledge areas, and Software Construction (writing, testing, and debugging individual units of code, already covered in full by this curriculum's sibling discipline) is only one of them: this concept draws the real, citable boundary between that already-published discipline and the four knowledge areas this one actually covers, Software Requirements, Software Engineering Process, Software Engineering Management, and the newly added Software Engineering Operations, plus Software Engineering Economics for the technical-debt closing concept.
Ward Cunningham coined the technical debt metaphor in a 1992 OOPSLA experience report about a real system, WyCash, writing that shipping not-quite-right code is like going into debt, tolerable only if it gets paid back promptly, because every minute spent afterward working around not-quite-right code counts as interest, and this concept treats that metaphor as a genuine tool of Software Engineering Economics (SWEBOK's own name for the knowledge area), not a vague complaint, giving debt a concrete owner, a concrete interest rate, and a concrete payoff point, with refactoring named honestly as the real repayment mechanism.
Martin Fowler credits Kent Beck's Extreme Programming with the practice and defines Continuous Integration precisely: every team member merges changes into a shared mainline at least daily, and every merge triggers an automated, self-testing build that must stay fast enough to give feedback within minutes, and this concept works through why each of Fowler's eleven practices (a single source repository, a fully automated and self-testing build, fixing a broken build immediately) exists to defend that one property, fast feedback on whether the mainline still works.
Fowler draws the exact line between two terms routinely used as synonyms: Continuous Delivery means every change that passes the pipeline is proven ready to release, but a human still decides when to actually release it, while Continuous Deployment removes that decision and releases every change that passes the pipeline straight to production automatically, and this concept works through why Continuous Deployment is strictly a stronger, riskier commitment built on top of Continuous Delivery, never a separate, independent choice.
A real CI/CD pipeline is a strict sequence of gated stages, typically build, then automated test, then package, then deploy, where each stage's job is to fail fast and cheaply on the kind of problem it is best positioned to catch, and this concept traces a commit through all four stages of a concrete pipeline, including why the package stage packaging the application into a container image is the step that finally makes the tested artifact and the deployed artifact provably identical.
Blue-green deployment, per Fowler, keeps two complete production environments and cuts traffic from one to the other in a single switch, buying an instant, clean rollback at the cost of running double the infrastructure during the switch, while canary release routes only a small slice of real traffic to the new version first and grows that slice as confidence builds, buying earlier detection of a bad release at the cost of running two versions side by side for longer, and this concept lays out honestly which real failure each strategy actually catches and which it does not.
Cindy Sridharan's practitioner writing popularized the now-standard framing of observability as three complementary data types, logs (discrete, timestamped events), metrics (aggregated numeric measurements over time), and traces (the causal path of one request across every service it touched), and this concept works through why a production incident that only one of the three can actually explain is common, then grounds the framing in two real, already-published applied examples at two different scales, a single Spring Boot service's health endpoint and a distributed system's tracing infrastructure.
Winston Royce's 1970 paper is the source everyone cites for the waterfall model (requirements, then design, then implementation, then testing, then maintenance, strictly in sequence with no going back), but Royce's own paper described that strict sequential version as risky and recommended against it in the very same document, an irony worth stating honestly rather than repeating the misattribution, before this concept turns to why the model nonetheless spread, what it actually gets right (a shared vocabulary for phases every later model still uses), and where iterative and incremental models arose specifically as its correction.
Software Engineering Management, SWEBOK's knowledge area for the activities that plan and control a project rather than the code inside it, treats estimation and risk as two sides of the same problem: an estimate is a probability distribution, not a single number, and a risk register turns unknowns identified during estimation into tracked items with a likelihood, an impact, and an owner, which this concept demonstrates against a small, concrete project plan rather than leaving both ideas at the level of vocabulary.
David Anderson's Kanban Method, formalized in his 2010 book after years of applying manufacturing-style kanban systems to knowledge work at Corbis and Microsoft, replaces Scrum's fixed timebox with a continuous pull system limited by explicit work-in-progress (WIP) limits per stage, and this concept works through why a WIP limit, not a burndown chart, is the mechanism that actually surfaces a bottleneck, using a cumulative flow diagram to make a stalled stage visible before it becomes a missed deadline.
Scrum, as defined precisely by its own official guide rather than by how a certification course markets it, prescribes exactly three accountabilities (Developers, Product Owner, Scrum Master), five events (the Sprint itself as a timebox, Sprint Planning, the Daily Scrum, Sprint Review, Sprint Retrospective), and three artifacts (Product Backlog, Sprint Backlog, Increment), and this concept walks through what each one actually requires and, honestly, what tradeoff Scrum's fixed timebox makes against a continuously flowing alternative.
XP's concrete practices, such as pair programming, test-first development, continuous integration, refactoring, and small releases, as a set that reinforces itself, with the real evidence on pair programming and an honest account of which practices became common.
The Lean principles as applied to software by the Poppendiecks (eliminating waste, deciding as late as responsibly possible, and seeing the whole), with flow, queues, and how they relate to Kanban, XP, and Scrum.
Requirements engineering, per Sommerville's standard textbook treatment, is not a single step but three distinct activities performed in a loop, elicitation (discovering what stakeholders actually need, often despite stakeholders themselves not knowing precisely), specification (writing that need down in a form precise enough to build against), and validation (checking the written specification actually matches the real need before a single line of implementation code exists), and this concept works through why skipping any one of the three, not just skipping requirements altogether, is the failure mode that actually shows up on real projects.
User stories and their acceptance criteria, splitting epics, and ordering a product backlog, as the agile counterpart of a requirements specification.
Velocity, burndown, and burnup charts: how to read them, what they forecast, and why velocity is not a productivity measure.
Barry Boehm's data from TRW, IBM, GTE, and the Bell Labs Safeguard program, gathered across dozens of real waterfall projects and published in Software Engineering Economics (1981), showed the cost of fixing a defect rising roughly an order of magnitude at each phase it goes undetected, but the popularized 1:10:100 rule oversimplifies a real range (roughly 3x to 8x by design, 30x to 200x by operations, varying by project type), and this concept states the honest version of the finding, including why the specific multipliers should never be quoted as a fixed law.
A functional requirement states what a system must do (a specific behavior, given a specific input), while a non-functional requirement constrains how well or under what conditions it must do it (latency, availability, security, maintainability), and the two fail differently in practice: a missed functional requirement produces a visible, reportable bug, while a missed non-functional requirement often produces a system that passes every functional test and still cannot survive its first real week in production.
Why teams model at all, UML as sketch versus blueprint, and which diagrams are still drawn in practice.
Classes, attributes, operations, associations, multiplicity, aggregation, composition, and inheritance, with object diagrams as concrete snapshots.
Actors, use-case diagrams, include and extend, and writing a use-case description with main and alternative flows.
Lifelines, synchronous and asynchronous messages, activation, and combined fragments, for reading and drawing an interaction over time.
BPMN's events, activities, gateways, and swimlanes, and how to model a business process that crosses several roles.
The product quality model of ISO/IEC 25010:2023, its nine characteristics, what the 2023 revision changed from 2011 (including moving the quality-in-use model out), and how a quality characteristic becomes a measurable requirement.
A short history of CMM and CMMI: why they appeared, what the five maturity levels said and did not say, who owns CMMI today, and what industry practice added. Framed as book versus today, never as current practice.
Defect density, churn, complexity, coverage, and delivery metrics, what each one can and cannot tell you, and how any of them degrades once it becomes a target.
A non-functional requirement (a target latency, an availability number, an expected request volume) is what actually forces an architecture decision, not taste or fashion, and this concept treats the moment a team commits to client-server versus layered versus something more distributed as a decision that should be written down as an Architecture Decision Record naming the requirement that drove it, deliberately not re-deriving architecture styles this curriculum already covers elsewhere, at two different depths, in two different sibling disciplines.
This capstone traces one written requirement through the entire lifecycle this discipline has covered end to end: elicited and specified, turned into a non-functional target that forces an architecture decision, built and tested at the unit level (handed off explicitly to the sibling discipline that owns that step), carried through a CI/CD pipeline into a canary deployment, watched in production by exactly the observability signal that would catch its specific failure mode, and finally closed with a deliberate, logged technical debt entry for a shortcut taken under real deadline pressure, the same amarra-tudo pattern every capstone on this platform uses, applied here to the surrounding process rather than to the code.
Requirements do not hold still once written down, they change as stakeholders learn more, and requirements management is the discipline of tracking a live link from each requirement forward to the design decisions, code, and tests that satisfy it, and backward from any proposed change to every requirement it would affect, through a traceability matrix and a change control process that decides, deliberately, whether a given change is worth its ripple effect.