DoAssignment study guide

B4.1 · Describe development phases, milestones, and products

Learn to describe development phases, milestones, and products through clear examples and targeted practice.

Ontario Grade 11 Computer Science

Software Development

A Grade 11 guide to describing how a software project progresses

A software project is easier to understand when you can describe both the work and the evidence that the work is progressing. A development phase is a broad part of that work. A milestone is a significant checkpoint. A product is something created or delivered. These ideas are connected, but they are not interchangeable. This lesson uses a small school-club event registration program as a running example. The sequence and names of phases are a useful way to describe a project; actual projects may organize their work differently.

What you will learn

Describe the main phases of a software development project.
Distinguish a phase from a milestone and a product.
Connect project activities, milestones, and products in a concrete scenario.

Three useful terms

A development phase groups related activities. For example, a planning phase may identify the problem, intended users, and what the program should accomplish. An analysis phase clarifies requirements: what information the program needs and what it should do with that information. A design phase plans how the program will be organized and how a user will interact with it. An implementation phase is when programmers create the program. A testing phase checks whether it behaves as intended and helps identify problems. A maintenance phase involves changes or corrections after a program has been delivered.

A milestone is a significant point used to mark progress. It is not necessarily a phase and is not automatically a physical item. “Requirements approved” could be a milestone because it marks an important decision. “Program ready for a user review” could also be a milestone.

A product is an output of project work. Products can include documents, plans, program code, a test record, or a delivered program. A phase can produce several products; completing a product may provide evidence for a milestone. These links help explain a project without confusing the work, the checkpoint, and the result.

Phase: a broad group of related project activities.
Milestone: a significant checkpoint or point of progress.
Product: an item created or delivered during the project.

Describe progress as input, work, and output

A clear project description can follow a simple pattern: identify what the team starts with, describe what the team does, and name the resulting product or milestone. For example, the team starts with a request for an event registration program. It clarifies the required information, such as a participant’s name and chosen session. A requirements list is a product of that work; approval of the list can be a milestone.

This pattern is a way to explain a project, not a programming formula. Naming the product makes a description more specific. Naming the milestone explains how the team recognizes progress. In the same way, saying “the testing phase” identifies a category of work, while “the team checked the registration steps against its requirements” describes an activity within that phase.

The phases do not have to be treated as a rigid one-way path. A test may reveal a problem that sends the team back to revise the program. For a Grade 11 description, focus on what work is happening, what checkpoint matters, and what product results. Classroom approaches and project schedules may differ.

Describe the work as well as naming the phase.
Use a milestone to identify a meaningful checkpoint.
Name a product that can be reviewed or used.

Connect the phases to project evidence

For the event registration program, planning might produce a brief project outline. Analysis might produce a requirements list. Design might produce a screen sketch or a description of the program’s steps. Implementation produces program code. Testing may produce a record of checks and observed results. After delivery, a corrected program version can be a maintenance product.

These are examples, not mandatory documents for every project. A product should make sense for the work being described. A screen sketch is evidence of a design decision; it is not the finished program. A test record supports a claim about what was checked; it does not by itself prove that every possible problem has been found.

When describing a milestone, make it observable and specific enough that someone can tell what has been reached. “Make progress” is vague. “The requirements list has been reviewed and accepted” identifies a checkpoint. The milestone can be associated with a product, but the two words still mean different things: the accepted list is a product, while reaching agreement on it is the milestone.

Match each example product to the work that creates it.
A milestone marks progress; a product is an output.
Use concrete wording so a project checkpoint is understandable.

Use the model to explain, not just label

A strong description connects the pieces: “During analysis, the team clarifies what registration information is needed. The requirements list is the product, and approval of that list is a milestone.” This sentence identifies a phase, an activity, an output, and a checkpoint.

When looking at another project, ask three questions: What broad work is being done? What significant checkpoint shows progress? What item has been created or delivered? The answers help you describe development without assuming that every team follows an identical schedule.

A complete description links phase, activity, milestone, and product where appropriate.
The same project may revisit earlier work when a later activity reveals a needed change.

Worked example

Clarifying what the program should do

A club wants a program for registering students for one of two event sessions. The team asks what information it needs and writes down the expected registration behaviour. Describe the phase, a possible product, and a possible milestone.

Identify the work
The team is clarifying what the program must do and what information it needs. This is analysis work.
Name the product
A written requirements list is a possible product because it records the result of the work.
Name the checkpoint
The team’s agreement that the requirements list is ready to guide the next work can be a milestone. Agreement marks progress; the list itself remains the product.

Answer: The team is in the analysis phase. A requirements list is a possible product, and approval of that list is a possible milestone.

Check: The answer separates the broad work, the resulting item, and the progress checkpoint.

Worked example

Planning the program’s screens

After agreeing on the requirements, the team draws a simple screen sketch showing where a student selects a session and enters a name. Describe the phase, product, and a reasonable milestone.

Connect the activity to a phase
The team is deciding how a user-facing part of the program could be arranged. That is design work.
Distinguish sketch from program
The screen sketch is a design product. It communicates an idea but is not the completed registration program.
State a checkpoint
A review in which the team accepts the sketch as a suitable guide for implementation could be a milestone. The review is the checkpoint; the sketch is the product.

Answer: The team is in the design phase. The screen sketch is a product, and accepting it as a guide for the next work is a possible milestone.

Check: The description does not mistake a plan for the finished program.

Worked example

Checking a delivered program

The registration program has been made. A team member follows the registration steps and records whether the program accepts a name and a session choice as intended. The team then corrects a problem found during the check. Describe the phases and possible products.

Identify the check
Following the registration steps and comparing the behaviour with expectations is testing work. A record of the check and its result can be a testing product.
Describe the correction
Changing the program after finding a problem is further development work. If the program has already been delivered, a later correction can be described as maintenance.
Avoid overstating the evidence
The recorded check shows what was examined and what was observed. It should not be described as proof that the program has no other problems.

Answer: The recorded check is a product of testing. Correcting a problem before delivery is part of development; correcting it after delivery can be maintenance. A corrected program version is a possible product.

Check: The answer identifies testing evidence and recognizes that timing affects whether later correction is described as maintenance.

Common mistakes and how to avoid them

Calling a requirements list a phase.

Correction: The analysis phase is a broad group of work; the list is a product created through that work.

Using milestone and product as if they mean the same thing.

Correction: A product is an output, such as an accepted screen sketch. A milestone is the checkpoint of reaching acceptance.

Assuming every project follows one fixed sequence and never revisits earlier work.

Correction: Phases are useful for describing work, but a project may return to earlier work when a check reveals a change is needed.

Lesson summary

Development phases group related work, such as planning, analysis, design, implementation, testing, and maintenance.
Milestones are significant checkpoints that mark progress.
Products are items created or delivered, such as requirements lists, sketches, code, test records, or corrected program versions.
A clear description links a phase to its activity and identifies a relevant product and milestone.

Check your understanding

Question 1

A team completes a screen sketch and agrees it is ready to guide implementation. Which choice correctly identifies the product and milestone?

The sketch is the milestone; agreement is the product.
The sketch is the product; reaching agreement is the milestone.
Both the sketch and agreement are phases.
The implementation phase is the product.

Show answer and explanation

The sketch is the product; reaching agreement is the milestone.

The sketch is an item created. Reaching agreement is a checkpoint that marks progress.

Question 2

A team records what happened while checking a registration program against its requirements. What is the best description of the record?

A product of testing work
A milestone that is itself a development phase
The program’s requirements
The maintenance phase, regardless of when the check occurred

Show answer and explanation

A product of testing work

A test record is an output of testing work. Its existence does not make it a phase or determine whether maintenance has begun.

Key terms

Development phase: A broad part of a software project that groups related activities.
Milestone: A significant checkpoint that marks progress in a project.
Product: An item created or delivered as a result of project work.
Requirements: Descriptions of what a program is expected to do or what information it needs.

Continue through ICS3U

View the complete ICS3U Ontario Grade 11 Computer Science curriculum and lessons

About this lesson and its review

Published by DoAssignment. This reviewed lesson follows Ontario Grade 11 Computer Science (ICS3U), expectation B4.1. It is a study resource, not an official curriculum publication.

Before publication, content is checked for structure, mathematical or chemical notation, calculations, course boundaries, and readability. Errors can still occur, so corrections are welcomed.

Official curriculum reference

Report a correction or ask a question