Grade by Grade
B. Software Development · Software Development: Managing a Team Software Project

Closing the Project: Acceptance, Delivery, Support and Maintenance

B1.5 B1.3About 70 minutes
Learning goals
  • I can confirm that software meets all user requirements using the traceability matrix and acceptance results.
  • I can prepare a formal acceptance and sign-off document.
  • I can deliver software in an appropriate format, with everything the client needs to own and run it.
  • I can tell apart corrective, adaptive, perfective and preventive maintenance.
  • I can write a support and maintenance plan, and archive a project properly.

Words to know

project closing
The final stage: confirming requirements are met, getting formal acceptance, delivering, planning support and maintenance, archiving, and reviewing.
sign-off
A dated, signed statement by the client that the delivered software meets the agreed requirements.
handover
Transferring the software, documents, data and access (accounts, repository) to the people who will own and support it.
corrective maintenance
Fixing bugs found after release.
adaptive maintenance
Changing software so that it keeps working when its environment changes (new computer, operating system, Python version, law or policy).
perfective maintenance
Improving the software or adding features users ask for after release.
preventive maintenance
Changes that make future problems less likely: tidying code, adding tests, safer data handling.
support plan
A document saying who supports the software, how to report problems, how quickly they will be handled, how data is backed up, and for how long.

The last 5%

Many projects never really end. The software is "basically done", the team drifts to other work, and months later nobody knows whether the client accepted it, where the latest code is, or whom to call when it breaks. A project needs a deliberate closing.

The curriculum asks you to close the project (i.e., confirm that software meets all user requirements, deliver software in appropriate format, plan software support and maintenance) (B1.5). Closing turns "we wrote a program" into "the client owns a working system and knows how to keep it working".

ConfirmeveryrequirementSign-offclientacceptsDeliverin the rightformatSupport planwho, how,how fastArchivetag, docs,accessReviewnextlessonLendIt: acceptance Thu Dec 3, sign-off Fri Dec 4, review report Thu Dec 10, 2026
The closing steps. The project review is the subject of the next lesson.

Step 1: Confirm that every requirement is met

Use the documents you already have. The traceability matrix links each requirement to its tests; the test summary report says which passed; the acceptance test results show what the client saw working; the change log records anything added, removed or deferred by agreement.

Every requirement in the signed scope must be in one of three states: passed, deferred or removed by an approved change, or out of scope from the start. Anything else is unfinished work. A short program can summarize the state for the sign-off meeting:

reqs = [("R1", "Must", "pass"), ("R2", "Must", "pass"), ("R3", "Must", "pass"),
("R4", "Must", "pass"), ("R5", "Must", "pass"), ("N1", "Must", "pass"),
("N2", "Must", "pass"), ("N4", "Must", "pass"),
("R6", "Should", "pass"), ("R7", "Should", "pass"), ("N3", "Should", "pass"),
("R8", "Could", "deferred"), ("N5", "Could", "deferred")]
for level in ["Must", "Should", "Could"]:
group = [r for r in reqs if r[1] == level]
passed = [r for r in group if r[2] == "pass"]
others = [rid for rid, _, status in group if status != "pass"]
note = f" (not passed: {', '.join(others)})" if others else ""
print(f"{level}: {len(passed)}/{len(group)} passed{note}")
ready = all(status == "pass" for _, level, status in reqs if level == "Must")
print("Ready for sign-off:", ready)

Output: Must: 8/8 passed, Should: 3/3 passed, Could: 0/2 passed (not passed: R8, N5) and Ready for sign-off: True. The two Coulds were deferred by agreement, so they do not block sign-off; one failed Must would.

Step 2: Formal acceptance and sign-off

The client confirms in writing that the software meets the agreed requirements. A sign-off document lists what was delivered, the status of each requirement group, any known issues, the support arrangements, and the client's signature and date. It protects both sides: the client knows exactly what they received, and the team has a clear end point.

Model: LendIt's sign-off

Acceptance and Sign-off: LendIt version 1.0.0 · Maple Grove Community Centre · Friday, December 4, 2026

Delivered: LendIt 1.0.0 installed on the front-desk laptop; release package LendIt-1.0.0 on a USB key; source code in the private repository, with read access for the centre; user guide; quick reference card (two laminated copies); training plan and practice data; test summary report; support plan.

Requirements: all 8 Must and 3 Should requirements passed acceptance testing on Thursday, December 3 (test summary report, version 3). Could requirements R8 (top-five report) and N5 (French menus) were deferred to a later version by agreement (change log CR-04). R9 (online booking) was out of scope.

Known issues: none open.

Support: as described in the support plan, until Friday, January 29, 2027.

Accepted by: Denise Tremblay, Programs Coordinator ____________ · For the team: Priya Sharma, Project Manager ____________

Worked example

Example 1: Is it ready to close?

On delivery day, Amara finds that R4 (overdue list) passes, but the list is in random order. Denise had mentioned at the design review that she would like it sorted by days late, though it was never written into R4. Should the team delay sign-off?

  1. Check the signed requirement: R4 says "list every overdue item with the member number and the number of days late". It says nothing about order. The acceptance test passed.
  2. Check the design document: the review notes recorded "member name added", not sorting. So sorting is a new request, not a defect.
  3. Treat it through change control: log it as a change request. Sorting by days late is a one-line change (sorted(..., key=..., reverse=True)) plus a test, about 1 hour.
  4. Options: include it now as a small, approved change and re-run the R4 tests before sign-off, or accept 1.0.0 as is and release it as 1.1.0 (a new feature, so MINOR).
  5. Denise chooses to sign off now and receive the sorting in the first update.

No delay is needed: the requirement as signed is met. The new wish is recorded as a change request, so it is neither lost nor allowed to hold delivery hostage.

Step 3: Deliver in an appropriate format

What counts as "appropriate" depends on the client. LendIt's delivery includes:

  • the installed, working program on the computer where it will be used (deployed as in the last lesson);
  • the release package (so it can be reinstalled) and the source code, because the centre owns the software and may want someone else to maintain it;
  • all user documentation and training materials;
  • the data, entered and checked, with a backup;
  • access: the centre gets its own access to the private repository, and any passwords are handed over in person and then changed by the client.

This transfer is called the handover. A short handover meeting walks the client through each item and the support plan.

Step 4: Plan support and maintenance

Software is never truly finished. Once real people use it, they find bugs, their needs grow, and the world around the program changes. Maintenance is usually divided into four kinds:

Correctivefix bugs found after releaseLendIt: 1.0.1: help typo fixedAdaptivekeep working when the world changesLendIt: new laptop, newer PythonPerfectiveimprove or add features users ask forLendIt: 1.1.0: skate sizesPreventivereduce future problemsLendIt: safer saving, more tests
The four kinds of maintenance, with LendIt examples. Only the first is about bugs; in long-lived systems, much of the maintenance work is adapting and improving.

A support plan answers the client's question, "What happens when something goes wrong?":

  • Who supports it, and until when: the LendIt team until Friday, January 29, 2027 (the end of the semester), then the centre's IT volunteer, using the README and design document.
  • How to report a problem: the bug report form in the user guide, emailed to the team's shared address, with steps to reproduce.
  • Response times by severity: critical (LendIt will not start or loses data) within 1 school day; others in the weekly batch of fixes.
  • Backups: the data folder is copied to a USB key at closing time each day; one copy is kept off-site each week; a restore is practised once.
  • Updates: how a new version is installed (release notes, replace program files, keep the data folder), and the version-number rules.
  • Known issues and planned improvements: R8, N5 and the sorting change request, for version 1.1.
  • Maintenance log: every change after release is recorded with its date, type, version and reason.
Worked example

Example 2: Classifying maintenance requests

Classify each request from the first month after release: (a) LendIt crashes if an item name contains a comma. (b) The centre replaces its laptop and the new one has a newer Python version, which shows a deprecation warning at start-up. (c) Volunteers want to search by member number. (d) Jordan rewrites the file-saving code to write to a temporary file and then rename it, so a power failure cannot damage loans.csv.

  1. (a) A bug in released software: corrective. (Probably the CSV writing does not quote names; Python's csv module does quote them, so look for a place where a line is built by hand.) Severity high: it crashes.
  2. (b) The environment changed: adaptive. Update the code to the newer way of doing things before the old one is removed.
  3. (c) A new capability users want: perfective. It goes through change control and into a MINOR release.
  4. (d) Nothing is broken yet; it reduces future risk (K3 in the risk register): preventive.

(a) corrective, (b) adaptive, (c) perfective, (d) preventive.

Step 5: Archive and release

Before the team moves on:

  • Tag the final version in Git (v1.0.0) and make sure the repository's main matches what was delivered.
  • Put final versions of all documents (scope, design, test plan and reports, user guide, change log, status reports, sign-off) in the docs folder, clearly dated.
  • Record where everything is in the README: repository, release package, documents, contacts.
  • Remove the team's access to anything the client now owns, and make sure no real personal data is left on team members' own computers.
  • Celebrate, and thank the client.

Then comes the last step of closing, the project review, in the next lesson.

Just for fun

In the 1960s and 70s, many programs stored years as two digits ("75" for 1975) to save precious memory. Their authors did not expect the code to still be running in 2000. It was, and in the late 1990s maintenance teams around the world spent years fixing the "Y2K" problem. Plan your maintenance: your code may live longer than you think.

Hands-on activity

Project step 13: Close your project

You need: your traceability matrix, test summary report, change log, release package and your client.

  1. Confirm requirements: fill in the status of every requirement (pass, deferred by change request, out of scope). Run the closing program with your own list.
  2. Sign-off: write a one-page acceptance and sign-off document like LendIt's. Go through it with your client and get their signature and the date.
  3. Deliver: hand over the installed program, the release package, the source code (or access to it), the documentation, the data and a backup. Hold a 15-minute handover meeting.
  4. Support plan: write who supports the program and until when, how to report problems, response times, backups, how to update, and known issues. Give it to your client.
  5. Maintenance: start docs/maintenance-log.md. If your client asks for anything after delivery, classify it (corrective, adaptive, perfective or preventive) and log it.
  6. Archive: tag the release in Git, put final versions of all documents in docs, and update the README.

What to look for: every requirement accounted for; a signed, dated sign-off; a support plan your client understands; a repository that matches what was delivered.

Your turn

1

Name the three things B1.5 says closing a project involves.

2

What three states can each requirement be in at closing?

3

A Should requirement is still failing on delivery day and was never deferred. Can the project be signed off as is?

4

Classify: "Add an option to print the overdue list."

5

Classify: "Update LendIt because the new laptop uses a newer operating system."

6

Give four things a support plan should state.

7

Why should the client receive the source code and repository access, not only the installed program?

More practice: warm-up

1

What is a sign-off?

2

Which kind of maintenance fixes bugs?

3

Which kind of maintenance reduces future problems before they happen?

4

What is a handover?

5

What Git command marks the delivered version?

More practice: on your own

1

Change the closing program's list so that R7 has status "fail". What does it print now?

2

Change the closing program's list so that N2 has status "fail". What is the last line, and why?

3

Write the "how to report a problem" section of a support plan in three sentences.

4

Why keep the paper binder going for one week after delivery?

5

A teammate wants to skip the sign-off because "Denise is happy anyway." Give two reasons it matters.

Challenge

1

Extend the closing program so that "Ready for sign-off" also requires every Should to be either "pass" or "deferred". Write the new condition.

2

Explain why most maintenance effort in long-lived systems tends to be adaptive and perfective rather than corrective, using LendIt as an example.

3

Write a short adaptive-maintenance risk for the support plan and a preventive action that reduces it.

Check your understanding

Quiz

1.

Which is NOT part of closing a project under B1.5?

2.

The centre gets a new laptop and LendIt needs changes to run on it. This is:

3.

A user asks for a new report after release. This is:

4.

A Could requirement was deferred by an approved change request. At sign-off it is:

5.

Why should a support plan state response times by severity?

6.

Which belongs in the handover to the client?

For parents and teachers

Big idea: B1.5 asks students to close the project: confirm the software meets all user requirements, deliver it in an appropriate format, and plan support and maintenance. This lesson covers sign-off, handover, the four kinds of maintenance (corrective, adaptive, perfective, preventive), support plans and archiving.

How to help: As the client, take the sign-off seriously: read the list of what was delivered and check each item before signing. Ask "Who do I call if it breaks in March, and what happens then?" The answer should be in the support plan.

Common difficulties:

  • Letting the project fade out with no sign-off or handover.
  • Treating every new wish at the end as a defect that blocks delivery (it should go through change control).
  • Forgetting that the client needs the source code, documentation and access, not just the running program.
  • No backup plan for the client's data.