D278 Scripting and Programming - Foundations is banner number ITSW 2113, three competency units in the School of Technology, and it is the course where programming stops being a language and becomes a way of thinking. The catalog describes it as language-agnostic programming basics: variables, data types, flow control and design concepts. That phrasing matters. The competency being built is the ability to describe a solution precisely enough that any language could implement it, which is why D278 sits underneath every later programming course rather than beside them. Whether you searched D278 or ITSW 2113, this is the same three unit foundation course.
What language agnostic actually means for your grade
Students arrive expecting to be taught a programming language and find themselves being taught the parts that are the same in all of them. Variables and the types they hold. The three control structures. The difference between a value and a reference to a value. What a function contract is before any syntax expresses it. This is deliberate, and it is the reason the course transfers so cleanly into whichever language your program takes up next, whether that turns out to be C++, Python, Java or C#.
The consequence for assessment is specific. When the material is language agnostic, you cannot demonstrate competency by producing something that runs. A working program proves that a compiler accepted your syntax. The course wants proof that you understood the logic, which is why foundations work leans on flowcharts, pseudocode, trace tables and plain-language explanation far more than a normal programming course would.
Data types are the quiet difficulty. Students who have written a little code arrive fluent in integers and strings and vague about everything else, then meet a scenario where a numeric input arrives as text, or where integer division silently discards a remainder that the requirement needed. Those are not syntax errors. They are type reasoning errors, and type reasoning is one of the things this course exists to grade.
Flow control is the other half. Selection and repetition are easy to recognize and hard to justify. Knowing that a loop is needed is the entry ticket. Explaining why a pre-test loop rather than a post-test loop suits the requirement, and what happens on the boundary iteration, is the part that scores.
Turning the scored aspects into a working outline
The scoring model at WGU is aspect by aspect and pass or fail per aspect. You need a score of 2 in each one, no aspect can be carried by another, and performance assessment work that misses one comes back for revision without a grade penalty. So the outline is not a writing decision, it is a compliance decision, and it should be built directly from the rubric rows in the order they appear.
Run the numbers before you start. Say your rubric lists five scored aspects and the deliverable is a written design document you expect to run about 1,000 words alongside your pseudocode. Five into 1,000 gives 200 words per aspect as the flat starting split. Now weight it against what each aspect asks for. An aspect that asks you to identify the input and output requirements is a short, factual section, so cut it to 120. An aspect that asks you to justify your control structure choices is argument, so raise it to 300. An aspect asking for a trace of your logic against sample data is mostly table, so budget 150 of prose around whatever the table needs. Those three adjustments hold the total near 1,000 while moving roughly 180 words from the aspects that only need accuracy to the aspects that need reasoning.
Do the same exercise for the code or pseudocode artifact. Every scored aspect that mentions a construct needs a specific, findable place in the artifact where that construct appears, and you should be able to point at a line number for each one before you consider the draft finished.
Stuck on the foundations course?
Send the scored aspects and the scenario you were handed. You get an outline mapped row by row plus a worked model of the design document in the register WGU expects.
The shape of a foundations design deliverable
Foundations work almost always pairs a designed solution with an explanation of the design. The frame below is a starting point that you bend to whatever your own aspects require.
| Section | What an evaluator is checking | Common failure |
|---|---|---|
| Problem restatement | That you read the requirement correctly, including the edge case buried in the last sentence | Copying the prompt instead of restating it |
| Inputs, outputs and types | Every value named, with the type it holds and the range it can take | Listing names without types |
| Algorithm in pseudocode | Logic complete enough to implement, with no language syntax leaking in | Writing actual Python and calling it pseudocode |
| Control structure justification | Why this selection or loop form, and what the alternative would cost | Describing what a loop does |
| Trace or test table | Sample values walked through the logic, including a boundary case | Only tracing the happy path |
| Error and edge handling | What the design does with bad input rather than what it assumes | Assuming valid input throughout |
The trace table is the section students skip and the one that most reliably demonstrates understanding, because a correct trace cannot be produced by someone who did not follow their own logic.
Evidence, notation and citation in a foundations course
Your evidence is your own reasoning made visible, which puts an unusual weight on notation. Pseudocode has no single standard, so pick one convention and hold it for the whole document. If you write SET total TO 0 in one place, do not write total = 0 four lines later. Consistency is legible as care, and inconsistency reads as copying from mixed sources.
Flowcharts follow the standard shapes for a reason: an evaluator scans them faster than prose. A diamond is a decision with two labeled exits, a parallelogram is input or output, a rectangle is a process. Unlabeled arrows out of a decision are the single most common diagram defect in this course.
When you cite, cite what actually defines the behavior. For a claim about how integer division works, the language reference or a recognized textbook is the source, not a forum answer. Course materials from the zyBooks environment can be cited like any electronic textbook when your program requires APA, with the publisher as the source and the section identified. Where your explanation borrows a standard algorithm, name it and attribute it rather than presenting a known approach as an invention.
Keep the code you did not write out of the artifact entirely. A foundations submission that contains a solution pulled from elsewhere is both an integrity problem and a scoring problem, since the aspects ask you to justify choices that were never yours to justify.
What clears on the first pass, and what returns
WGU work is Competent or Not Competent. There is no partial credit inside an aspect and no letter grade to soften a weak section, and the revision route is open without penalty. In practice that means a return costs you queue time, and queue time in a six month term is the real expense.
First-pass submissions in D278 tend to share three properties. The design is complete enough that a stranger could implement it without asking a question. Every construct the aspects mention appears somewhere findable and is pointed to explicitly. The explanations answer why rather than what, because what is already visible in the artifact.
Returns almost always trace to one of two things. Either the design was written after the code, so it describes a program instead of specifying one and inherits every shortcut the code took, or an aspect was answered adjacent to the question, with a definition supplied where a justification was asked for. Writing the design first, before any implementation, prevents most of the first category by construction.
Six time sinks in this course
- Learning a language instead of the concepts. Students pick a favorite language and study its syntax. The scored aspects ask about logic, and syntax knowledge does not answer them.
- Pseudocode that is really source code. If it would compile, it is not pseudocode, and an aspect asking for language-independent design has not been met.
- Skipping the type analysis. Half the tricky requirements in this course turn on a type: text that looks numeric, a division that truncates, a boundary that is inclusive on one side.
- Tracing only the case that works. A trace table with one clean row proves nothing. The boundary and the invalid input are what an evaluator looks for.
- Treating the write-up as documentation. This is an argument for a design, not a manual for a finished product, and the tense and stance are different.
- Waiting on the course instructor before starting. Course instructors are a real resource and they are not a prerequisite. Draft first, bring a specific question, get a faster answer.
How we work on this course
What we build for D278 students is the design thinking, not a shortcut past it. Send the scored aspects and the scenario and you get an outline keyed to the rubric rows, a model design document that shows what full-credit reasoning sounds like at this level, and a walkthrough of the pseudocode decisions so the next programming course does not restart from zero. Where a section of your course is assessed by an objective assessment, support is preparation: concept drills, practice items and a straight answer about whether your preassessment result says sit it now or study another week. Objective assessments are proctored, we prepare students and never sit or assist during any assessment, and we never ask for or use portal credentials.
Three units cleared early in a flat rate term is three units of room for the course that turns out to be harder than expected. Foundations is usually the cheapest place in the technology sequence to buy that room.
Three questions D278 students ask
Is D278 the same thing as ITSW 2113?
Which programming language should I learn for this course?
Does D278 have a proctored exam or a submitted task?
Where D278 sits in WGU's programs
The July 2026 catalog places this code in 6 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.