C968 Software I - C# is banner number ITSW 3215 and six competency units in the School of Technology, which makes it one of the two heaviest single courses in the software sequence. The catalog describes it as building object-oriented programming expertise in C# through class design, exception handling and application development constructs. Six units signals a substantial application rather than an exercise, so the competency being built is sustained: designing types that hold together across a whole program rather than solving one problem in one file.
Six units means an application, not an exercise
The unit weight tells you the shape of the work. A one or three unit programming course can be satisfied by a focused program. Six units usually means something with several screens or several entities, a data model that persists across an execution, validation rules that come from a written specification, and enough surface area that a design mistake made early is felt in three places later.
Class design carries most of the grading weight in a course with this description. The questions are always the same: what types exist, what each one is responsible for, what each protects, and where behavior lives. C# gives you properties rather than raw getter and setter methods, and using them properly matters: a property with validation in its setter, or with a private setter and a method that changes state through a rule, is real encapsulation. A property auto-implemented with a public setter on every field is a public field with a capital letter.
Exception handling is named directly in the catalog description, which puts it beyond the level of a supporting topic. The distinction that matters is between an exception and an expected condition. A user typing letters into a numeric field is expected and should be handled by validation, not by catching a parse failure. A file that vanishes mid-operation is exceptional. Using exceptions for ordinary control flow is a defect that a reviewer notices immediately.
Application development constructs is the catalog's phrase for the rest: collections, interfaces, events where the platform uses them, and the separation of interface code from logic. In a six unit application that last separation is what keeps the program testable and the code readable, and it is a structural aspect that evaluators can check by looking at where the calculations live.
Turning scored aspects into a build plan and a word budget
Every rubric aspect at WGU is scored on its own, a 2 in each is what passes, and one shortfall returns the task regardless of how strong the rest is. In a six unit course the aspect list is long, so the mapping matters more here than anywhere: aspect to class, to method, to validation rule, or to a documented decision.
Work the arithmetic on the larger shape a six unit course tends to produce. Suppose fourteen scored aspects and a document of about 2,000 words. Fourteen into 2,000 is roughly 143 each. Sort them. Eight are implementation aspects that the application itself proves, needing about 70 words each of pointer text naming the class and method, which comes to 560 and releases about 580. Two ask you to justify the class design, at 350 each, or 700. One asks about your exception and validation strategy, 350. One asks about data handling or persistence, 250. Two are lighter, covering setup and a summary, at 100 each, or 200. Totalling: 560 plus 700 plus 350 plus 250 plus 200 gives 2,060, close to target, and the design and strategy arguments now carry more than half the prose while eight aspects are answered in a sentence or two apiece.
Then order the build by dependency: data model, then the classes that own the rules, then the interface, then the validation, then the reports or outputs. Building the interface first is the standard way to lose a week in a six unit course.
In the six unit C# course now?
Send the aspects and the specification. You get a class map, a validation matrix and a model design document.
The validation matrix a specification-driven application needs
Specifications in a course this size contain rules stated in ordinary sentences, and the reliable way to make sure none is missed is to extract every one into a row before coding.
| Rule from the specification | Where it is enforced | What the user sees when it fails |
|---|---|---|
| A value must fall between a minimum and a maximum | The property setter or a guard in the domain class | A message naming the field and the allowed range |
| One quantity must not exceed another | The method that changes either quantity | A message naming both values |
| A required field cannot be empty | Input handling, before an object is constructed | The field highlighted with a specific message |
| An item cannot be removed while it is in use | The service or collection that owns the relationship | An explanation of what is blocking the removal |
| Identifiers must be unique | The collection that assigns or stores them | Nothing, because the program assigns them correctly |
| A confirmation is required before deletion | The interface layer only | A prompt naming the item |
Every row that ends up with an empty middle column is a rule stated in your specification and enforced nowhere, which is the most common source of a return in a specification-driven course.
Documenting a program too big to read in one sitting
At six units the evaluator will not read every line, so your documentation has to guide them. Structure it by aspect, name the file and the class for each, and include a short map of the solution saying what each project or folder holds. That map costs a paragraph and changes how quickly everything else can be verified.
Use the language's documentation comment convention on public types and members: what it does, what each parameter means, what it returns, what it throws. Inline comments then carry the reasoning that the code cannot express, particularly around any rule that came from the specification, where a comment naming the requirement is worth more than a comment explaining the syntax.
Test evidence should cover the validation matrix rather than the happy path. A table of attempted invalid inputs with the message each produced demonstrates the rules are enforced, which is the claim your document is making. For citation, the platform documentation is the authority for library behavior and cites in APA as an organizational web source where your program requires it. Any adapted example code needs a comment naming its origin, and you should be able to explain every line of anything you did not write, since aspects that ask for justification are about your decisions.
What clears a six unit task on the first attempt
WGU marks work Competent or Not Competent. There are no letter grades and no ordinary grade point average, and a task that misses an aspect returns for revision without penalty. In a six month flat rate term the return costs days, and in a six unit course those days are the ones you were counting on for the next course.
Applications that clear the first time build from a clean solution folder with no leftover artifacts, run without a debugger attached, and enforce every rule the specification stated. Their calculations live in classes rather than in interface event handlers. Their documentation points at code by name. Their validation produces messages a user could act on.
Returns cluster around scale problems rather than knowledge problems. A rule from paragraph nine of the specification that was read and never implemented. Business logic sitting in the interface layer, making structural aspects unanswerable. A file path that exists only on the author's machine. And an exception handler that catches everything and continues, which turns a bug into an intermittent mystery.
Six time sinks in a six unit course
- Starting with the interface. Screens built against an unsettled data model get rebuilt. Model first, then rules, then interface.
- Reading the specification once. Extract every rule into a row before coding, then check the rows off. Rules hide in ordinary sentences.
- Putting logic in event handlers. Calculations in a button handler cannot be tested or reused and make design aspects hard to answer.
- Using exceptions for expected input. Validate before parsing. Catching a conversion failure as the way to detect a typo is a defect a reviewer sees instantly.
- Committing at the end. In a course this size, an unrecoverable mistake without version history costs days. Commit as you go.
- Adding features nobody asked for. Every unrequested screen is build risk with no aspect behind it.
How we work on this course
Support for C968 is scaled to the size of the course. Send the scored aspects and the specification and you get a rule extraction matrix, a class map with responsibilities and validation ownership, a build order that avoids the rewrite, and a model design document in the register WGU evaluators expect. Reviews name the structural defect and the rule it breaks so you can fix it yourself, because the justification aspects are about decisions you made. Where an objective assessment is part of your course, support is preparation only, and objective assessments are proctored: we never sit one, never assist during one, and never ask for or use your WGU portal credentials.
Six units is the largest single block most technology students carry, and it is the course where planning most obviously changes how much of a six month flat rate term is left afterwards.
Three questions C968 students ask
Is C968 the same course as ITSW 3215?
Why is C968 worth six competency units?
Do I need C968 before C969?
Where C968 sits in WGU's programs
The July 2026 catalog places this code in 1 current WGU program. 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.