UPI Study › Courses › C++ Programming › Free lessons › Lesson 3.5 Free with a free account
Planning and Scoping Your First Project
C++ Programming · Chapter 3: Program Design and the Object ModelSection 3.5 · lesson 20 of 84video coming soon
← Capturing Input and Printing ResultsNext lesson: Comparing Values in Code →
In this lesson
From a one-sentence requirement to a buildable plan.
- Write a four-part specification
- Sketch the steps and the screen before coding
- Plan test runs, especially at the boundaries
- Build in runnable milestones and estimate honestly
Transcript
Everything said in the video, section by section (1,268 words). Read along, or search it.
Opening Claim
Planning Is the Only Free Change
A project fails long before anyone types anything. It fails when nobody wrote down exactly what goes in, exactly what comes out, and what it will deliberately not do. A misunderstanding costs almost nothing while it's still a sentence in a document. Noticed while sketching, it costs about an hour. Once the code is written, most of a day. After everything depends on it, the whole build. And after submission, it can't be fixed at all. A half-working program is visible and encouraging. A document is neither. But planning is the only hour in a project when changing your mind is free.
Core Idea
A Specification Is Four Lists
A specification isn't an essay. It's four short lists, and a project is ready to build when all four are written, with no vague word in any of them. Inputs: what arrives, in what form, and what counts as valid? Rules: what turns inputs into outputs, stated precisely enough to follow? Outputs: what leaves, in what layout, to how many decimals? And out of scope: what will this program deliberately not do? That's the one people leave out. Here's the requirement we're handed: work out a household electricity bill from the units consumed. That one sentence hides at least six unanswered questions.
Worked Example
Pinning Down the Electricity Bill
So, pinned down. Units consumed is a whole number typed by the user, from zero to five thousand. If it's out of range, report the problem and ask again. The month is one word of text, printed on the bill. If it's empty, use the word unspecified. Then the rules, numbered so later documents can refer to them. Rule one: a fixed charge of 85 rupees on every bill. Rules two to four set the slabs: the first hundred units at 4.20 each, units 101 to 300 at 6.10, and above 300, 8.05 each. Rule five applies six percent tax to the fixed charge plus the energy charge. And rule six rounds money to two decimals at the point of display only. That one matters more than it looks.
Scoping
Out of Scope Lets You Say No
Now the most valuable list: out of scope. Each entry is a decision made now, instead of an argument later. No commercial tariffs: a different rate structure, doubling the rules. No multiple billing periods, since that needs storage that comes later. No saving or loading files, which would dominate the work. No graphical window, since text shows every rule. And no late fees or arrears: more rules, nothing new learned. Half-finished projects usually die of additions, not difficulty. Each one sounds small, like: it should also handle two meters. And each silently doubles the remaining work. This list lets you say no without re-arguing. If a new idea genuinely belongs, add it as a future item, and finish what you scoped.
First Sketch
Pseudocode Before the First Line
Two quick, disposable sketches come between the specification and the first line of code. Both regularly expose holes in the specification. The first is the pseudocode: the steps in order, ignoring any language's rules. Input the month. Input the units, re-asking until they're in range. Set the energy charge from the slab rates, the fixed charge to 85, and the tax to six percent of their sum. Then the total, and output the itemized bill: the only place rounding applies. Notice the rule numbers in the comments. They tie each step back to the specification.
Second Sketch
Writing Out the Screen Conversation
The second sketch is the screen design: the exact conversation the program will have with its user, written out as though it had already run. The month, August. Units, 250. Then the bill: a fixed charge of 85, an energy charge of 1335, tax of 85.20, and 1505.20 payable. Writing this answers questions the specification never asked. What does the prompt say? Is the currency on every line? How wide are the columns? Answering now takes five minutes. Answering while debugging takes an afternoon. A program built to match this transcript is finished when the two agree.
Quick Check
Hand-Worked Tests at the Boundaries
Turning the specification into concrete test runs, with answers worked out by hand, gives you something to check the program against. Do it now, while the rules are fresh. Test one, 250 units: ordinary, spanning two slabs. Test two, zero: the lower boundary. Test four, 101: one past the slab edge, which catches an off-by-one fault. Tests five and six are invalid: minus four, and the letters a b c. Both should be rejected before any calculation. Quick check: test three is exactly 100 units, on the slab edge. What should it expect? Pause, and work it out. A hundred units at 4.20 is 420. Add the fixed 85, and that's 505. Six percent tax is 30.30, so the total is 535.30. Notice how many runs live at the edges. Middle values confirm what you already believed. The runs that find faults are at the boundaries, and the invalid ones.
Milestones
Six Runnable Stopping Points
A milestone is a stopping point where the program does less than it eventually will, but does it completely, and can be run. One is the specification and both sketches. Two is input and echo. Three computes charges for one slab, checked against test three. Four handles all slabs, tax and total. Five matches the screen sketch, line for line. And six handles invalid input, the fiddliest part, and usually underestimated. Each milestone runs, so progress is visible, and the risky calculation sits in the middle, while there's still time. If time runs out, you submit something that works, and is honest about its limits.
Time Estimates
Coding Is Under Half the Hours
Estimates are usually wrong in one direction. Everyone plans for the part they can picture, the coding, and forgets the parts they can't. For this project: an hour of planning and sketching, about four and a half hours of building, an hour and a half of testing and fixing, and an hour and a half writing up. Eight and a half hours in all, and writing code is under half of it. Write your estimate down before you start, and the actual time beside it afterward. Most people are optimistic by about half.
Submission
The Whole Package You Hand In
Projects here are assessed on the whole package, not just on whether the program runs. And everything in it is a by-product of work you've already done. The specification, whose most common omission is the out-of-scope list. The design sketches: rewritten afterward to match the code, they're worth nothing. The source, commented with why, not what. Testing evidence, including the runs that failed. Notes on decisions the requirement left open. And proof of work, gathered as you go, not from memory at the end. You'll be questioned on your own submission, which is easy if you built it. Tools may help you understand a concept, but never produce any part of what you submit.
Marking Rubric
Six Dimensions of Assessment
Rubric weights vary, but the dimensions are stable. Read them before you start. Correctness against the specification. The quality of the specification itself. Design before code. Handling bad input. Clarity of the code. And evidence and explanation. Four of the six are earned before or after the coding. A program that runs perfectly, with no specification, sketches or evidence, can't reach the 70 percent pass mark.
Key Takeaways
Specify, Sketch, Test, Build in Steps
To summarize. A specification is four lists: inputs with valid ranges, numbered rules, outputs, and a justified out-of-scope list. Sketch the steps and the screen before writing code, and make the program match the design. Plan test runs early, with hand-worked answers, concentrating on the boundaries and on invalid input. And build in milestones that each run, estimating the testing and write-up, not just the coding.
Think About It
Rewriting the Vague Discount Rule
Here's something to think about. A rule reads: apply a discount to large bills. Give two reasons nobody can build from that, and rewrite it so they can.
About C++ Programming at UPI Study
C++ Programming (Computer Science 242) is a self-paced online course of 84 video lessons in 11 chapters, from your first program to decisions, loops, arrays, functions, classes, files, pointers and inheritance. It carries a NCCRS credit recommendation for 3 semester credits.
Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Enroll now → Course details Download the syllabus Every course with PRO →
Why take it here
Why students take C++ Programming with UPI Study
Where the credit goes
Universities that work with NCCRS
C++ Programming carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Thomas Edison State UniversitySigned partner
University of the PeopleSigned partner
Charter Oak State CollegeSigned partner
Strayer UniversitySigned partner
Columbia Southern UniversitySigned partner
Indiana TechSigned partner
Penn StateWorks with NCCRS
Southern New Hampshire UniversityWorks with NCCRS
SUNYWorks with NCCRS
+many more cooperating universitiesFind my college →Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.
FAQ
Questions students ask us
About Planning and Scoping Your First Project
What goes into a software project specification before I start coding?
Why should I write pseudocode and a screen sketch before writing C++ code?
Which test cases should I plan for a program, and why test the boundaries?
How do I break a first project into milestones and estimate the time honestly?
About the C++ Programming course
How many college credits is C++ Programming?
How much does C++ Programming cost and what is included?
Which universities accept UPI Study credits?
How long does C++ Programming take?
How are the exams done?
How do my credits reach my college?
Ready for the full course? Earn 3 credits in C++ Programming.
84 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.
3 credits · NCCRSEnroll →