Problem Analysis and Algorithms

Outcome 1: Problem Analysis and Algorithms · Blueprint Pillar 3 · PGCC INT-1700 (interim) · Download .docx

Objectives

Define algorithm and explain why it must be finite, unambiguous, and produce output.
Write pseudocode for a problem that includes at least one decision and one loop.
Draw a flowchart using standard symbols: oval (start/end), diamond (decision), rectangle (action), parallelogram (I/O).
Trace an algorithm with sample data to verify its correctness before coding.
Apply problem decomposition to break a large problem into smaller solvable sub-problems.

Key terms

algorithm: A finite, ordered sequence of unambiguous steps that takes input, processes it, and produces output for a well-defined problem.
pseudocode: Informal, language-independent notation that describes an algorithm's logic in plain English, close to natural language but structured like code.
flowchart: A visual diagram using standardized shapes — oval (start/end), diamond (decision), rectangle (process), parallelogram (I/O) — to represent an algorithm.
decomposition: The practice of breaking a complex problem into smaller, manageable sub-problems that can each be solved independently.
trace: Manually stepping through an algorithm with specific input values to verify it produces the expected output.
input: The data provided to an algorithm or program that is processed to produce a result.
output: The result produced by an algorithm after processing its input.

The concept

Every program you will ever write starts as a problem. Before touching a keyboard, the best programmers spend time understanding what needs to be solved and designing a solution. That solution is an algorithm.

An algorithm is a finite, ordered sequence of unambiguous steps that solves a well-defined problem. Every algorithm must have three properties: it must terminate (finish in a reasonable amount of time), it must be unambiguous (each step has exactly one interpretation), and it must produce output. These properties separate a real algorithm from vague instructions like 'figure it out.'

The two most common ways to express an algorithm before coding are pseudocode and flowcharts. Pseudocode uses plain English with a code-like structure. You might write: INPUT score, IF score >= 90 THEN PRINT 'A', ELSE IF score >= 80 THEN PRINT 'B'. This is readable by any programmer regardless of language. A flowchart shows the same logic visually. Ovals mark where execution starts and ends. Rectangles show processing steps (compute the average). Diamonds show decision points (is score >= 90?). Parallelograms show input and output. Arrows connect the shapes.

Decomposition is the skill of dividing a large problem into smaller ones. A program to manage a grade book might decompose into: get input from the user, store grades, calculate statistics, display results, and save to a file. Each sub-problem becomes a function once you start coding. The programming becomes easier because each piece is independently solvable and testable.

Tracing is how you verify an algorithm before coding it. Take a sample input, step through each line of pseudocode, track the value of every variable, and confirm the output matches what you expect. A trace that finds a flaw saves hours of debugging later. Professional programmers trace unfamiliar or complex algorithms routinely.

Blueprint Pillar 3 — Technology and Society: Problem analysis applies to real-world contexts. Well-designed algorithms power search engines, navigation apps, medical diagnosis tools, and financial systems. Understanding how to structure a solution — not just write code — is what separates a programmer from someone who can only copy and paste.

When you sit down to solve a programming problem, follow this order: (1) restate the problem in your own words, (2) identify the inputs and outputs, (3) break the problem into sub-problems, (4) write pseudocode for each piece, (5) trace with sample data, and only then (6) write code. This sequence prevents the most common error in new programmers: starting to type before they understand what they are building.

Worked examples

Example 1: Pseudocode for finding the largest number in a list: Step 1 — Set largest = first item in the list. Step 2 — For each remaining item in the list: IF item > largest THEN SET largest = item. Step 3 — OUTPUT largest. Trace with [5, 2, 8, 3]: Start largest=5. Compare 2: 2 > 5? No. Compare 8: 8 > 5? Yes, largest=8. Compare 3: 3 > 8? No. Output 8. Correct.

Example 2: Decomposing a Student Report Card program: Sub-problem 1 — Read student name and grades from a file. Sub-problem 2 — Calculate the average grade. Sub-problem 3 — Determine the letter grade from the average. Sub-problem 4 — Print the report card. Each sub-problem becomes one function. Sub-problem 3 is itself a selection problem (if average >= 90 → 'A', etc.).

Common mistakes

Writing code before understanding the problem. If you cannot explain the algorithm to a classmate in plain English, you are not ready to write code.
Skipping the trace step. Pseudocode that looks correct often has off-by-one errors or wrong conditions. Tracing with a small sample takes two minutes and can save two hours.
Using vague steps in pseudocode. 'Process the data' is not a step — 'Add each score to the running total' is a step. Every pseudocode line should be translatable into one or two lines of code.

Self-check

Try each one before you look. A miss here costs nothing and tells you exactly what to reread.

1. Which of the following must be true of every valid algorithm?

2. What is the purpose of tracing an algorithm before coding it?

3. What does the diamond shape in a flowchart represent?

4. Decomposing a problem means:

5. Pseudocode is best described as:

Canvas is the official record. This companion enhances the PGCC curriculum; it does not replace it. Last name and class year only. Students with a 504 plan or IEP: your accommodations apply.

↑ Back to top