Year 11 · Computer Science · Summer 2

After the exams · Lesson 2 of 5

A project of their choice: plan

Project7.1 The program development life cycle7.2 Systems, decomposition and design tools

Year 11 · Computer Science · After the exams · Lesson 2 of 5

You will learn to

  • Write a short brief for a project of your choice.
  • Use decomposition to split the project into parts, with inputs, processes, outputs and storage.
  • Create a success list where every line can be checked as yes or no.
  • Choose the tools you need and justify the choice.

Year 11 · Computer Science · After the exams · Lesson 2 of 5

Success criteria

You have got it when you can say:

  • I can say what my project is and who it is for in two sentences.
  • I can show a structure diagram of my project's parts.
  • I can show a success list my teacher agrees is checkable.

Year 11 · Computer Science · After the exams · Lesson 2 of 5

Retrieval starter

Questions from before. Write your answers, then show them.

  1. Last unit

    A 10 × 10 image at 8 bits per pixel takes…

    A 80 bytesB 8,000 bitsC 800 bits = 100 bytes

    C. 800 bits = 100 bytes

  2. Earlier this year

    With even parity, the 7 data bits 0110100 need the parity bit…

    A 1B 0C It cannot be worked out

    A. 1

  3. Last year

    Hex B2 in binary is…

    A 1100 0010B 1011 0010C 1011 0100

    B. 1011 0010

Year 11 · Computer Science · After the exams · Lesson 2 of 5

Key words (1 of 3)

Algorithm
A precise, ordered set of steps that solves a problem.
Program development life cycle
The four stages of making a program: analysis, design, coding and testing.
Abstraction
Removing details that do not matter so you can focus on the ones that do.
Decomposition
Breaking a problem into smaller parts that are easier to solve.

Year 11 · Computer Science · After the exams · Lesson 2 of 5

Key words (2 of 3)

Sub-system
A smaller part of a system that does one job.
Structure diagram
A top-down diagram that shows how a system is split into sub-systems.
Flowchart
A diagram of an algorithm using standard shapes joined by flow lines.
Pseudocode
A structured, code-like way of writing an algorithm that is not tied to one language.

Year 11 · Computer Science · After the exams · Lesson 2 of 5

Key words (3 of 3)

Check digit
An extra digit calculated from the other digits, used to catch typing errors.
Normal data
Test data that should be accepted.
Abnormal data
Test data that should be rejected.
Extreme data
The largest and smallest values that should be accepted.

7.1 The program development life cycle · The explanation · step 1 of 7 · part 1 of 3

Four stages, in order

The program development life cycle is the set of stages a programmer goes through to make a program.

There are four stages: analysis, design, coding and testing.

It is called a cycle because problems found in testing send you back to an earlier stage.

7.1 The program development life cycle · The explanation · step 1 of 7 · part 2 of 3

Four stages, in order (continued)

StageQuestion it answersWhat is produced
AnalysisWhat must the program do?A list of requirements
DesignHow will it do it?Structure diagrams, flowcharts, pseudocode
CodingCan we build it?Program code, tested as it is written
TestingDoes it work for all data?Test results with test data
?Why?

Planning before coding is faster overall. A mistake fixed in the design costs minutes. The same mistake found after coding can cost hours.

7.1 The program development life cycle · The explanation · step 1 of 7 · part 3 of 3

Four stages, in order (continued)

!Watch out

Learn the four names exactly. Cambridge uses analysis, design, coding, testing. Words like 'planning' or 'making' do not earn the mark.

7.1 The program development life cycle · The explanation · step 2 of 7 · part 1 of 3

Analysis: understand the problem

In analysis you find out exactly what the problem is and what the program must do. These needs are the requirements.

Abstraction means removing the details that do not matter, so you can focus on what does.

Decomposition means breaking a big problem into smaller parts that are easier to solve.

7.1 The program development life cycle · The explanation · step 2 of 7 · part 2 of 3

Analysis: understand the problem (continued)

e.g.Example
Problem: a school canteen wants a top-up system for student cards. Requirements: input the card number and amount, add the amount to the balance, show the new balance. Abstraction: the colour of the card and the student's hair colour do not matter. Keep card number, name and balance. Decomposition: read card → choose amount → take payment → update balance.

7.1 The program development life cycle · The explanation · step 2 of 7 · part 3 of 3

Analysis: understand the problem (continued)

?Why?

Abstraction stops you wasting time on details that will not affect the program. Decomposition turns one scary problem into several small, easy ones.

7.1 The program development life cycle · The explanation · step 3 of 7 · part 1 of 3

Design, coding and testing

In design you plan how the program will work. You decompose further and use structure diagrams, flowcharts and pseudocode.

In coding you write the program. You test each part as you write it. This is called iterative testing: write a bit, test it, fix it, repeat.

In testing you run the finished program with planned test data to check it works for every kind of input.

7.1 The program development life cycle · The explanation · step 3 of 7 · part 2 of 3

Design, coding and testing (continued)

e.g.Example
Canteen system: Design: a flowchart for 'take payment'. Coding: write 'update balance' and test it with one card before writing the next part. Testing: try a top-up of 10 euros (normal), -5 euros (abnormal) and the largest allowed amount (extreme).

7.1 The program development life cycle · The explanation · step 3 of 7 · part 3 of 3

Design, coding and testing (continued)

!Watch out

Do not mix up iterative testing and final testing. Iterative testing happens during coding, part by part. Final testing uses a full test plan on the finished program.

7.2 Systems, decomposition and design tools · The explanation · step 4 of 7 · part 1 of 3

Sub-systems, and inputs, processes, outputs and storage

A system is a set of parts that work together to do a job. Each part is a sub-system. A sub-system can be split again until each part is small enough to code easily.

Example: a supermarket self-checkout is a system. Scanning, weighing, payment and printing the receipt are its sub-systems.

Every problem can also be decomposed into four parts.

Inputs: the data going in. Processes: what is done to the data. Outputs: the results that come out. Storage: data that must be kept for later.

7.2 Systems, decomposition and design tools · The explanation · step 4 of 7 · part 2 of 3

Sub-systems, and inputs, processes, outputs and storage (continued)

PartSupermarket self-checkout
InputsBarcode of each item, weight, payment card
ProcessesLook up the price, add to the running total, check the weight
OutputsItem name and price on screen, total, receipt
StorageProduct file of barcodes and prices, record of the sale
?Why?

Small parts are easier to write, test and fix. Different programmers can work on different sub-systems at the same time.

7.2 Systems, decomposition and design tools · The explanation · step 4 of 7 · part 3 of 3

Sub-systems, and inputs, processes, outputs and storage (continued)

!Watch out

Do not put the same thing in two places. 'Total' is calculated (process) and then shown (output). Say which one you mean.

The explanation · 3 more steps

More on the lesson page

The lesson page has the rest of the explanation, step by step:

  • Structure diagrams
  • Flowcharts: the six symbols
  • Pseudocode: Cambridge's planning language

Open the lesson page