Software Projects and Teams: Stages, Models and Roles

Bigger programs need teams

The programs you wrote in Grade 11 were small enough to hold in your head. Real software is not. A banking app, a hospital scheduling system or a video game is far too big for one person, so it is built by teams, often over months or years.

Teams bring new problems that have nothing to do with code: Who does what? What exactly are we building? When will it be ready? How do two people change the same file without wrecking each other's work? How do we know it is good enough to hand over?

This unit answers those questions. Strand B of the Grade 12 course asks you to manage the software development process through all of its stages: planning, development, production and closing, and to apply project management techniques in a student-managed team project. That is exactly what you will do.

Four stages of a project

The curriculum groups project work into four big stages. Each stage ends when its deliverables are finished and approved.

1. Planning. Decide what to build and how the work will be organized: the scope document, the requirements, the list of tasks and deliverables, the schedule and the risks.
2. Development. Design the software and build it according to the plan: the design document, the code (kept in version control), the unit tests and regular status reports.
3. Production. Produce the finished product to specification: code, test, deploy. Write the user documentation and training materials.
4. Closing. Confirm that the software meets all the user requirements, deliver it in the right format, plan support and maintenance, and review how the project went.

The seven life-cycle phases from Grade 11 fit inside these stages: problem definition and analysis happen in planning, design and coding in development, testing and implementation in production, and maintenance is planned during closing.

Waterfall or iterative?

In the waterfall model, each phase is done once: all requirements first, then all the design, then all the code, then all the testing. It is easy to plan and to explain, and it suits projects whose requirements are clear and stable (for example, software for a machine whose rules are fixed by law).

Its weakness is late feedback. The client may not see working software until near the end, which is the most expensive time to discover a misunderstanding.

Iterative (or agile) development builds the software in short cycles called sprints or iterations. Each sprint picks a few of the most important features, builds and tests them, and ends with a working version that the client can try. The client's feedback shapes the next sprint. Popular agile methods include Scrum (with sprints, a product backlog and daily stand-up meetings) and Kanban (with a task board that limits work in progress).

Most real teams use a blend: a clear plan and scope at the start (so there is something to manage), then iterative development inside that plan. That is the approach this unit uses.

Roles on a software team

A team works best when everyone knows what they are responsible for. On a student team of three or four, the usual roles are:

• Project manager (PM): keeps the plan and schedule up to date, runs meetings, writes status reports, and is the main contact with the client. The PM does not boss people around; the PM keeps the team informed and unblocked.
• Lead developer (architect): owns the overall design, sets coding standards, reviews other people's code and merges it into the main version.
• Tester (quality assurance, QA): writes the test plan, automates tests, runs them after every change and reports bugs clearly.
• Documentation lead (technical writer, user experience): writes the user guide, help screens and training materials, and checks that the program is easy to use.

In a small team everyone writes code and tests it; the role says what else you are accountable for. The curriculum asks you to contribute as a team member to the planning, development and production of a large project, so even the PM should own at least one module.

Meet the guided team project: LendIt

Throughout this unit you will follow one project from the first meeting to the final review.

The client: Denise Tremblay, programs coordinator at the Maple Grove Community Centre (a fictional centre). Every winter the centre lends snowshoes, skates, cross-country skis and board games to members. Right now loans are written in a binder, items go missing, and nobody knows what is overdue.

The team: Priya (project manager), Jordan (lead developer), Amara (tester) and Luc (documentation lead), four Grade 12 students. They have six weeks of class time.

The product: LendIt, a Python program that records items, members and loans, shows what is overdue, calculates late fees and saves everything to files.

Your own team project

Alongside LendIt, you will run your own project. Each lesson ends with a project step. If you have friends or family members who can help, give each person a role card. If you are working alone, you play every role, one at a time: put the PM card in front of you when you plan, the tester card when you test, and so on. Writing "Wearing my tester hat:" at the top of a page is a surprisingly good way to switch your thinking.

Project data is data

A project manager tracks a lot of information: tasks, owners, estimates, dates. You can check that information with a program, just as you would check any other data. This short script checks a responsibility list: every task must have exactly one owner, and that owner must be on the team. It then counts each person's tasks so the PM can spot an unfair load.

The dictionary maps each task to one owner, so no task can have two owners by accident. The first loop finds problems; the second loop builds a count with load.get(owner, 0) + 1, which starts each person at zero. In this list every person owns one task, but two tasks still need attention: one has no owner, and one is assigned to someone who is not on the team (probably a typing mistake for Luc).