D424 Software Engineering Capstone carries banner number ITEC 4906 and is worth 4 competency units. It challenges you to integrate the skills and knowledge from every domain of your program into a single project. D424 and ITEC 4906 are one requirement. Unlike a written capstone, this one produces working software, which means it can fail in a way an essay cannot: the thing you submit either runs or it does not, and no amount of documentation repairs that.
Scope control is the capstone skill
The single most common way this capstone goes wrong is ambition. Students design an application they would enjoy building, discover in week six that the authentication layer alone is a project, and end up submitting something half finished with an explanation. The capstone rewards a modest application built completely and documented properly far more than an impressive one built partially.
Choose scope by working backwards from the aspects. If the rubric requires persistence, a user interface, business logic, validation, testing and documentation, then the smallest application containing all of those is your target, and anything beyond it is optional work you can add if time allows. Deciding that consciously at the start is what keeps the project finishable.
Integration across domains is the stated requirement, and in a software capstone it usually shows up as breadth rather than depth: data modelling from the database courses, interface design from the front-end work, security thinking from the security courses, and structure from the software engineering material. Each domain should be visible in the artifact, not just in the write-up.
Documentation carries more weight in a capstone than in ordinary coursework, because the evaluator has to understand your design decisions without the conversation you would have in a real handover. Setup instructions that actually work on a clean machine, a clear account of the architecture, and honest limitations are what turn a working program into a submittable capstone.
Your result reads Competent or Not Competent, with no letter grades and no ordinary grade point average behind them, leaving 4 competency units as the only size figure attached to a flat-rate six month term. Because a build can absorb unlimited time, plan the schedule before the features.
Turning a build rubric into a delivery plan
Capstone rubrics for software projects mix behavioural aspects, which your program must demonstrate, with explanatory aspects, which only the documentation can satisfy. WGU requires a score of 2 in each aspect for a task to pass and judges each aspect alone, so a working application with thin documentation loses the explanatory aspects entirely.
Budget both. Take a rubric with thirteen scored aspects and a documentation target near 2,800 words alongside the codebase. Reserve 200 words for an overview and 150 for a close, leaving 2,450. If eight aspects are demonstrated by the software, allow 130 words each to name the requirement, point at the implementing code and state how to verify it, which is 1,040. The remaining 1,410 covers five explanatory aspects at roughly 282 each.
Convert the behavioural aspects into a feature checklist before you write any code, and build in the order the checklist implies rather than in the order that feels interesting. The unglamorous requirement you postponed is the one that will be missing at the deadline.
Schedule a hard freeze at least a week before your intended submission, after which you fix defects and write documentation only. Capstones that are still gaining features on the final weekend are the ones that arrive broken.
Shape for a capstone software submission
D424 deliverables pair a working application with documentation. These proportions apply to the documentation.
| Section | Content | Share |
|---|---|---|
| Application overview | What it does, who it is for, and the requirement each feature satisfies. | 12 percent |
| Setup and run | Environment, versions, dependencies and exact steps to run it on a clean machine. | 11 percent |
| Architecture | Layers, responsibilities and how data flows through the application. | 18 percent |
| Data design | Model, keys, relationships and why the structure suits the application's queries. | 15 percent |
| Design decisions | The choices you made, the alternatives considered and why you rejected them. | 17 percent |
| Testing evidence | What you tested, including boundary and invalid input cases, with actual results. | 17 percent |
| Limitations | What the application does not do, known defects and what you would build next. | 10 percent |
Evidence when the deliverable is software
The codebase is your primary evidence and it is read as such. Consistent naming, comments that explain intent, no commented-out experiments left in place and a structure that matches your architecture section are all part of what is being assessed, whether or not an aspect names them explicitly.
Testing evidence must be real. Show the cases you ran, the inputs you supplied and the output you got, including at least one boundary case and one invalid input. A statement that the application was tested thoroughly is not evidence, and an evaluator who cannot see a failure case handled will assume none was tried.
Anything you did not write yourself needs attribution. Where your task permits libraries or adapted examples, name them at the point of use and be certain you can explain what they do, because an explanatory aspect will find code you cannot account for faster than any similarity check. Where your task does not permit adaptation, do not use it.
Never commit credentials, connection strings with real passwords, or personal data into the repository or the submission. Use configuration supplied at run time and say how. A capstone that leaks a secret has demonstrated the opposite of the security thinking the program spent courses building.
Keep to the citation style the task requires and reference inline rather than in a closing pile.
What closes a software capstone
Competent capstones run from the documented instructions, satisfy every behavioural requirement, explain their architecture and decisions, show real testing including failure cases, and state their limitations honestly.
Returns cluster in four shapes. The application does not run on a clean machine because a dependency or configuration step was assumed. A requirement from the rubric is missing because it was postponed. Testing is asserted with no evidence. Or the documentation narrates the code line by line instead of explaining why the architecture is the way it is.
Version control is worth using properly even when no aspect demands it. Committing as you work gives you a way back when a refactor goes wrong at midnight, and it produces a record of how the project developed that makes the design decisions section far easier to write. Students who work without it lose whole evenings to changes they cannot undo, which is time a capstone schedule does not have spare.
Data seeding also deserves attention because evaluators need something to look at. An application submitted with an empty database demonstrates almost nothing, and asking a reader to create their own test records before they can see any behaviour adds friction exactly where you want none. Ship sample data that exercises the interesting cases, and say in the documentation what it contains and how to reset it.
The check that prevents most of this is a clean environment test. Before submitting, follow your own setup instructions on a machine or account that has none of your development state, and fix whatever breaks. It is the single highest value hour in the whole project.
Performance assessment work at WGU can be revised and resubmitted without a grade penalty, which on a build project is the whole strategy: submit a complete, working, modest application with time left in the term rather than an ambitious one at the deadline. Where your program includes objective assessments, those exams are proctored and our boundary is absolute: we teach, review and help you plan, we take no part during any assessment, and we never ask for or handle portal credentials.
Capstone build growing faster than the term?
Send the D424 rubric and your project idea. We cut scope to the smallest application that satisfies every aspect, then plan the build and the documentation.
Eight mistakes that return software capstones
- Scope chosen by interest. Work backwards from the aspects to the smallest application that satisfies all of them.
- Building the interesting parts first. The postponed requirement is the one missing at the deadline.
- No clean environment test. If your instructions do not work on a machine without your setup, the submission does not run.
- Testing asserted. Show inputs, outputs and at least one invalid case handled.
- Documentation narrating code. Explain architecture and decisions; the evaluator can read the implementation.
- Unattributed borrowed code. Attribute what your task permits and never include what it does not.
- Secrets in the repository. Configuration at run time, redaction in captures, no exceptions.
- Still adding features at the deadline. Freeze a week out and spend that week on defects and documentation.
Three questions students ask about D424
How big should the application be?
Can I reuse a project from an earlier course?
Which language and tools should I use?
Where D424 sits in WGU's programs
The July 2026 catalog places this code in 3 current WGU programs. Open a program page for the complete standard path and term positions. The live Degree Plan remains authoritative after transfer credit, substitutions, and mentor planning.
The assessments, one by one
The public catalog does not publish this course's PA/OA identity or task count. WGU Tutors publishes at most one PA manual per course and only from a WGU-controlled public rubric. Until that source exists, PA help begins from the student's real Course of Study and OA support remains preparation only.