Introduction

It may be better for one person to complete an ambitious software development project, though realistic, production-standard, secure projects are usually done by teams. The reason for this can be as simple as the fact that software development is labor-intensive and involves different phases of the product cycle with different objectives (getting the software online is just the beginning), and one person's energy is really limited.

A team can be defined as a collaboration between a group of people with different specialties and roles. Take a scrum team for example, there are three major roles: Product Owner, Scrum Master, and Developers, which can be subdivided into different roles: front-end, back-end, design, testing, maintenance, and so on. At different stages in a software development life cycle, they are responsible for different aspects

Role Responsibilities Across SDLC Phases
Role	Planning	Analysis	Design	Implementation	Testing	Deployment	Maintenance
Product Owner	✓	✓	✓		✓	✓	✓
Scrum Master	✓	✓	✓	✓	✓	✓	✓
Front-end Developer		✓	✓	✓	✓		✓
Back-end Developer		✓	✓	✓	✓	✓	✓
UX/UI Designer	✓	✓	✓	✓
QA Engineer		✓			✓	✓	✓
DevOps Engineer			✓	✓	✓	✓	✓
Project Manager	✓	✓	✓	✓	✓	✓	✓

Note

This documentation provides an overview of the SDLC process and its various phases. Each organization may implement SDLC differently based on their specific needs and constraints.

SDLC

The Software Development Life Cycle (SDLC) is a widely used procedural framework for developing high-quality software that meets user requirements.


The seven phases of software development life cycle:

    1. Planning:    Project goals, objectives, and requirements

    2. Feasibility Analysis:    Technical and financial evaluation

    3. Design:    System architecture, user interface, database schema, and security measures...

    4. Implementation:    Coding...

    5. Testing:   ensuring the software operates as intended before being deployed to users

    6. Deployment:    On-premise or in the cloud, deployment determines the accsessibility and performance of the software

    7. Maintenance:   Ongoing support, address issues, apply updates, add new features, ensure software remain functional over time

SDLC Methodologies

Various methodologies can be used to implement SDLC, each with its own approach to the development process.

Methodology	Description
Waterfall	Sequential approach where each phase must be completed before the next begins
Agile	Iterative approach with frequent reassessment and adaptation
Scrum	Agile framework with fixed-length iterations (sprints)
DevOps	Combines development and operations with continuous integration and delivery
Spiral	Combines iterative development with systematic aspects of waterfall

Example

Suppose we want to make a sign-up/log-in page like this. The example below demonstrates a form with validation using Zod and React Hook Form, styled with shadcn/ui components.

Notes

TIn order to make this application fully functional, we also need a backend, a database, an API for front-end and back-end communication, and tests to make sure it works correctly.

Frontend: Inputs, receives and displays data, adapts the display of web pages according to status
Backend: Receives and processes data, stores data in database, sends data to frontend
Database: Stores, updates, retrieves, or deletes data
API: A protocol communication layer defined between the frontend and backend
Test: Whether it can operate properly and safely (data security) under various simulated destructive, and normal environments

A broader pattern also includes deployment, maintenance, user feedback, and other aspects, which also vary depending on the process of each project.

Software Development Architecture Diagram

A simple software architecture diagram

In a development process using Scrum as an example, the team develops in iterative cycles called Sprints. A Scrum team completes a certain amount of work within a short time-box period called sprint. The team sets the length of the sprint cycle, the amount of work, and ensures that each member has a good understanding of the task through clear communication.

A Sprint Cycle Has 4 Key Components:

Sprint Planning

Create clear user stories and sub-tasks according to the current epic.

Daily Scrum

A daily short meeting between team members to exchange information and progress, keeping things on track.

Sprint Review

Reviewing and demonstrating the work done during the sprint and discussing the future scope of work for the product (work-oriented).

Retrospective

Focusing on how the team worked collaboratively during the sprint, thinking about how to make the team more efficient (collaboration-oriented).

Sprint cycle

Applying Scrum to Our Example

Step 1: Planning with User Stories

For our registration/login interface, we begin by using the User Story method to determine user needs and implementation requirements. Since this is a relatively simple project, the team sets a time limit of 2 days for the sprint.

Step 2: Daily Collaboration

During this cycle, the team holds a short daily meeting to exchange information, track progress, and ensure everything stays on track.

Step 3: Sprint Review

After the project is completed, the team reviews and demonstrates the work through a Sprint Review and discusses the future scope of work for the product (work-oriented).

Step 4: Retrospective

Finally, the team conducts a sprint retrospective, focusing on how they collaborated during the sprint and considering ways to improve team efficiency (collaboration-oriented).

User Stories

A user story in Scrum is a short, simple description from the perspective of the end user. It follows the format:

"As a [user], I want [goal] so that [benefit]."

Example: Registration Form

As a new website visitor,

I want to create an account with my email and password,

So that I can access personalized features and save my preferences.

Example: Login Form

As a registered user,

I want to log in with my credentials,

So that I can access my account and use the application's features.

Writing Effective User Stories

Be Clear and Concise

Keep your user stories simple and to the point. Avoid technical jargon and focus on the user's perspective.

Focus on User Needs

Emphasize what the user wants to accomplish, not how the system should implement it. The "so that" part helps clarify the value to the user.

Include Acceptance Criteria

Define clear conditions that must be met for the story to be considered complete. This helps developers understand when they've successfully implemented the feature.

Make it Small and Testable

Each user story should be small enough to complete within a single sprint and should be testable to verify that it works as expected.

Pro Tip

User stories are not meant to be comprehensive requirements documents. They serve as conversation starters between the product owner, developers, and stakeholders. The details emerge through discussions and are captured in acceptance criteria and task breakdowns.

Try it out

About Toronto Scrum Team

We are a team of interested individuals dedicated to practicing software development in the real world task sets. We implement a full Scrum process to enable team members to master and utilize the tools and gain valuable experience.

Our Team

Experienced employed developers with diverse skills
UX/UI designers from multiple backgrounds

Our Approach

Scrum management methodology
Weekly-based sprints
Continuous integration and development
Regular process refinement and adaptation

Current Projects

As an early-stage club, we started with small projects:

User sign-up and log-in system
Research and demonstration of different technology stacks

However, we will gradually start working on more challenging projects. You will also meet some interesting people.