WGU C968: Software I – C#
C968 Software I asks you to build a working C# inventory management application, not sit a multiple-choice exam. This independent guide walks you through what the performance assessment expects, how much time to budget, and the class-design and validation details that decide whether your submission passes on the first review.
WGU C968, Software I – C#, is where a lot of software students stop reading about programming and finally build something real. Instead of a proctored multiple-choice exam, this course asks you to write a complete desktop application in C# and submit the source code for evaluation. It sits in the School of Technology and is worth 6 competency units, typically taken after you have picked up C# fundamentals and object-oriented basics, and just before the more demanding Software II course.
Direct answer: There is no test to memorize for C968. You pass by building a working C# Windows Forms inventory management application that meets every line of the task rubric, then documenting it. Follow the requirements literally, validate all user input, handle errors gracefully, and check your code against the rubric wording before you submit.
The application you build is an inventory system that tracks products and the parts used to make them. Users need to add, modify, delete, and search both parts and products, and the program has to prevent nonsense entries such as an inventory count that falls outside its minimum and maximum. It sounds modest, and it is intentionally scoped, but it exercises the exact skills employers expect from an entry-level developer: class design, inheritance, collections, input validation, exception handling, and a usable interface. That is why it matters — this is the first course where an evaluator reads your code and decides whether it holds together.
What the C968 Performance Assessment Asks You to Build
The deliverable is a C# application (most students use Windows Forms in Visual Studio) plus supporting documentation. While exact rubric wording changes over time, the core requirements have been stable and revolve around these areas:
- Class design and inheritance — an abstract or base Part class with two derived types (typically an in-house part and an outsourced part), plus a Product class that contains a list of associated parts.
- An inventory container — a class that holds collections of all parts and all products and exposes methods to add, look up, update, and remove them.
- Full CRUD screens — a main form plus add and modify forms for both parts and products, wired so the data on screen matches the data in memory.
- Search — the ability to find a part or product by ID or name and surface the result to the user.
- Input validation and exception handling — rejecting empty fields, non-numeric values in numeric fields, min/max logic that is actually enforced, and a product that cannot be built from a nonexistent set of parts.
- Business rules — for example, a product with associated parts cannot simply be deleted, and inventory levels must stay within their bounds.
- Documentation — a short written piece explaining your design decisions and, in some versions, a class relationship diagram.
Because the interface is a real part of the grade, the visual-design habits from D279 User Interface Design transfer directly here — clear labeling, sensible layout, and forms that guide the user rather than confuse them.
How Hard Is C968, Really?
Many students report that C968 is one of the more approachable programming courses in the technology programs, provided you are already comfortable writing basic C#. The task is well-defined, the scope is fixed, and the course materials plus program mentors give you a clear target. Students who struggle almost always fall into one of two groups: those who are still learning the language itself while trying to build the app, and those who rush the rubric and get their submission returned for a small missing requirement.
On timing, experiences vary widely. Students with prior programming experience sometimes finish the build over a focused week or a couple of weekends, while those newer to C# report spending several weeks. Treat any single number you see online as one person's pace, not a promise. Budget generously, because a performance assessment can be sent back for revision, and each round of feedback adds days.
A Study Plan That Fits a Build-It Course
Studying for a coding PA is different from cramming for a knowledge test. Your "review" is iterative building. Here is a sequence that works well for this course:
- Read the full task and rubric first — twice. Before writing any code, list every requirement as a checklist item. The rubric is literally your grading key, so turn it into a to-do list you can tick off.
- Sketch the classes on paper. Draw Part, its two subclasses, Product, and Inventory, and the relationships between them. Ten minutes of design saves hours of refactoring.
- Build in vertical slices. Get "add a part" working end to end — form, validation, save to the collection, display on the main screen — before moving to modify, delete, and then products. Each slice you finish is one you can test with active recall: close the file, then explain aloud how the data flows from the form to the inventory list.
- Test each rule deliberately. After every feature, try to break it. Enter letters in a number field, set a minimum above the maximum, delete a product that still has parts. Practice testing your own app is the single highest-value habit in this course.
- Commit your work as you go. Using source control the way D197 Version Control teaches lets you experiment without fear and roll back a broken change in seconds.
- Do a rubric pass at the end. Read each requirement and point to the exact line of code or screen that satisfies it. If you cannot point to it, it is not done.
Spacing this work across several sittings rather than one marathon lets the tricky parts — inheritance and validation especially — settle in memory, and you will write cleaner code on day three than you did on day one.
Mistakes That Get C968 Submissions Returned
- Skimming the rubric. A single unmet requirement — a missing search feature, an unhandled error, an absent business rule — sends the whole submission back. Evaluators grade against the rubric, not against how nice the app looks.
- Weak input validation. Letting a blank name, a text value in a numeric field, or an out-of-range inventory count slip through is the most common reason for revision. Validate everything, and show the user a clear message.
- Letting the UI and the data drift apart. If you modify a part but the main list still shows the old values, your update logic is not refreshing the display. Test that every change is reflected on screen.
- Copying code you cannot explain. Public repositories and walkthroughs exist, but submitting work you do not understand is both an integrity risk and useless preparation for Software II. Learn the pattern, then write your own.
- Ignoring the required exceptions and business rules. The min/max logic and the "cannot delete a product with associated parts" style rules are explicit requirements, not optional polish.
- Thin documentation. The written explanation and any required diagram are graded too. Describe your design honestly and completely.
C968 Submission Readiness Checklist
Before you submit, make sure you can honestly answer yes to each of these:
- Can you point to a line in the rubric and show exactly where your code satisfies it — for every requirement?
- Can you add, modify, delete, and search both parts and products without the app crashing?
- Can you explain how your Part base class and its two subclasses relate, and why you used inheritance?
- Can your program reject blank fields, non-numeric input, and inventory values outside the min/max range?
- Can you demonstrate that a product with associated parts cannot be deleted, and that products stay in sync with their parts?
- Can you show that changes made on an edit form are reflected on the main screen immediately?
- Can you walk a stranger through your class design in a few clear sentences?
- Have you run the app one last time from a clean build to confirm it launches and behaves as documented?
C968 FAQ
Is C968 an objective assessment or a performance assessment?
It is a performance assessment only. You submit a C# application and its documentation for evaluation rather than sitting a proctored exam, so there is no test bank to study.
How many competency units is C968 worth?
Public WGU program documentation lists Software I – C# at 6 competency units. Because it is a build project, plan your calendar around the work involved rather than the CU number alone.
Do I need to know C# before starting?
You will be far more comfortable if you do. C968 assumes you can already write basic C#, so the course focuses on applying object-oriented design rather than teaching the language from zero. If you are shaky, spend a few days on fundamentals before building.
How long does C968 usually take?
It varies a lot. Students with programming experience often finish in one to three focused weeks, while those newer to coding report longer. Leave buffer time in case your submission comes back for a small revision.
Can I use tutorials and sample projects?
Use them to learn patterns, not to copy. Understanding someone's approach and then writing your own code is legitimate and good preparation; submitting work you cannot explain risks an integrity violation and leaves you unready for the next course.
What comes after C968?
Software II builds directly on these skills, and later courses such as D385 Software Security and Testing assume you can design and reason about working code. The habits you form here — reading rubrics closely, validating input, testing your own work — carry through the rest of the program.
For more study guides in this program, browse the School of Technology hub or the full index of WGU course guides. This guide is an independent study resource and is not affiliated with or endorsed by WGU.
Want a human in your corner for C968?
Book 1-on-1 OA prep coaching, a tutoring session or a study-plan review with our team.
Prefer WhatsApp? Message us on +1 646 980 4914.