SDLC (Software Development Life Cycle)

Software Development Life Cycle (SDLC) is a process used by the software industry to design, develop and test high quality softwares.

Daily Routine of SDE

• Software Development Life Cycle - SDLC
• Model - Waterfall
• Framework – Scrum
• Development tool - Jira
• Development Environment

1 SDLC (Software Development Life Cycle)

1.1 What is SDLC

• SDLC stands for Software Development Life Cycle
• Also known as application development life cycle
• Systematic process for planning, creating, testing and deploying

1.2 Why Do We Need SDLC

• Produce high-quality software that meets or exceed customer expectations
• Reaches completion within time and cost estimates
• With appropriate SDLC model, developers are able to:
• Give correct estimate on time & cost
• Organize efficient communication both inside team or between teams • Increase work transparency, reduce chaos
• Help all the members better evaluate their performance

1.3 SDLC - SAMPLE

1.3.1 SDLC – BASIC STEPS

• Design
• Micro-level
  • How many modules should we have? What are their responsibility?
  • How should we separate the codes and functions into different logic layers?
  • What coding/testing standard should we follow?
  • What are the design patterns the entire team must follow?
• Implementation
• Manage dependencies
• Writing code
• Implement unit test/integration test
• Testing
• Perform local testing
• Deploying to testing environment
• Find/fix bugs
• Deploy to production environment
• Evolution
• Review newly launched features; does it work good?
• Is there anything that can be improved?

Definition: A systematic process for planning, creating, testing, and deploying software.

Purpose: Enhances software quality, meets customer needs, and controls cost and timelines.

Basic Steps:

• Requirement Analysis: Define application purpose, functionalities, and reusability options.
• Design: Macro (programming language, framework, standards) and Micro (modules, code layers, coding standards, design patterns).
• Implementation: Code writing, dependency management, unit and integration testing.
• Testing: Local and environment testing, bug detection, and resolution.
• Deployment: Release to production environment.
• Evolution: Continuous improvements and feedback evaluation.

2 SDLC Models

SDLC Models:

• Waterfall
• Iterative
• Spiral
• V-Model
• Big-Bang
• Agile

2.1 Waterfall Model

• It is the earliest SDLC approach.

• Each phase must be completed entirely before starting the next phase

• When to use?

• Requirements are well documented

• Product definition is stable, technology is not dynamic

• Pros

• Clear definition, simple and easy to understand

• Cons

• Vulnerable to risk and uncertainty, hard to measure progress

gantt
    title Waterfall Model
    dateFormat  YYYY-MM-DD
    section Phases
    1. Requirement Analysis   :done, req, 2024-01-01, 2024-01-10
    2. System Design          :active, des, 2024-01-11, 2024-01-20
    3. Implementation         :impl, 2024-01-21, 2024-02-10
    4. Testing                :test, 2024-02-11, 2024-02-18
    5. Deployment             :dep, 2024-02-19, 2024-02-25
    6. Maintenance            :maint, 2024-02-26, 2024-03-15

Waterfall Model: Sequentially completes each phase; suitable for projects with stable requirements.

Linear process, step by step from Requirement Gathering -> Design -> Implementation -> Test -> Deployment -> Maintenance.

Long iteration. Each step takes from weeks to months.

Hard to change once something is fixed.

graph TD
  A[Requirement Analysis] --> B[Design]
  B --> C[Implementation]
  C --> D[Testing]
  D --> E[Deployment]
  E --> F[Maintenance]

2.2 Agile Model

• A SDLC model focuses on customer satisfaction with rapid delivery as its core idea.

• Breaks product into small incremental pieces/builds, divide and conquer in different iterations

• Each iteration will last for 2 to 4 weeks, team will focus on pre-scheduled task and deliver the result at the end of the time period

• Pros

• Rapid development life cycle, require less resource
• Fast delivery, easy to manage

• Able to give accurate estimate on timeline

• Cons

• No suitable for complex features
• More efforts needed in maintenance
• Leadership is required
• Hard to transfer project knowledge as documentation is lacking

Agile Model: Focuses on rapid delivery and customer satisfaction with iterative and incremental development to handle changing requirements flexibly.

Incremental process. Divide the whole process into small iterations. Easy to change.

3 Framework - Scrum

• SDLC is principles, not actual implementation
• Need a practice or framework to implement the idea
• Java Web development – spring framework / servlet
• Agile uses SCRUM

3.1 SDLC SCRUM

• A SDLC framework used by Agile principle, popular among enterprise level development team
• Backlog: place where we store all the information about our application/project, including tasks that need to be accomplished.
• Sprint: repeated fixed time-box. Development life cycle is composed of Sprints. Each sprint tasks will be assigned to team members.
• Meeting: in each sprint, the team will hold multiple meetings to plan for the tasks, solve issues, and improve overall performance

graph LR
    A[1 Backlog]
    B[2 Planning Meeting]
    E[4 Review Meeting]

    subgraph Daily
        F[Daily Stand-up]
        D[Day Work]
        F --> D
    end

    A --> B 
    B --> Daily 
    Daily --> E 
    E --> A

3.2 Scrum Terminology

• Important concepts in Scrum:
• Three Roles
• Three Work Pieces
• Five Events

3.2.1 Three Roles

• Normally, an application will be assigned to a team.This team is in charge of design, maintain and make improvement.
• To apply Scrum framework, a team must have the following part:
• Product Owner: owner of the product (application). Act as the bridge between tech team and business team. Help tech team understand the business requirement and help business team understand the tech efforts needed.
• Scrum Master: also known as Agile lead. Responsible for organizing meetings, checking team status and making sure everything is on schedule.Work closely with PO.
• Develop team: regular tech team. Usually consists of BE, FE and QE developers.

3.2.2 Three Work Pieces

• Product Backlog: contains all the tasks of this application
• Sprint Backlog: subset of Product backlog. Each Sprint, PO will pick tasks from product backlog and move into sprint backlog. So the team can narrow down the range and focus on certain tasks.
• Increment: list possible improvements for existing features

3.2.3 Five Events

• Sprint: Sprint itself is an event, it composed of the following part
• Sprint Planning Meeting: Planning for the upcoming Sprint. Including narrow down the task range and assign the tasks to team members.
• Daily Stand Up: Daily report or your personal progress.
• Sprint Review Meeting: Review the completeness of the tasks in this sprint.
• Sprint Retrospective Meeting: Look back at the tasks, self evaluate and make improvement.

Scrum workflow:

A popular approach of Agile, each iteration is one sprint.

• Sprint - The iteration itself. Usually lasts 2 weeks. (2-4)
• User Story - General explanation of a requirement from the perspective of the users.
• Product backlog - A prioritized list of all work/stories.
• Points - The scale to estimate the workload.
• Sprint Planning Meeting - The starting meeting of each sprint. Tasks are assigned to the team. Scrum
• Meeting (Daily Standup Meeting) - Tell the team what I did, what I will do and roadblockers.
• Sprint Review Meeting - Show the work to the team.
• Demo - Show the work to the stakeholders(clients)
• Retrospective Meeting - Lesson learning meeting.

eg.

Sample Project Timeline: Forum Website Development

This timeline outlines how to develop a forum website using the Scrum framework over a 3-month period, with sprints lasting 2 weeks.

Project Background

• Goal: Build a forum website with features like user registration, post creation, comment functionality, user profiles, and moderation tools.
• Team: 1 Product Owner (PO), 1 Scrum Master, 4 Developers, 1 Tester.
• Sprint Duration: 2 weeks.
• Total Sprints: 6.

Project Timeline

Kickoff Phase (Week 1)

1. Project Kickoff Meeting: - Define project objectives, scope, and priorities. - Identify stakeholders and potential risks.
2. Product Backlog Creation: - Product Owner drafts the initial backlog, including:
   • User registration and authentication.
   • Forum structure (categories and threads).
   • Post creation and commenting.
   • User profile and role management (e.g., moderator roles).
3. Team Setup and Tools: - Set up tools like Jira/Trello for task management. - Establish development tools (e.g., Git, CI/CD).

Sprint 1: Core User Features (Weeks 2-3)

• Goal: Implement user registration, login, and basic profile management.
• Tasks:
• Design the database (e.g., users, roles, and profiles).
• Backend APIs: User registration, login, and profile management.
• Frontend: Registration and login pages.
• Basic unit testing and frontend-backend integration.
• Sprint Review: Demo user registration, login, and basic profile functionality.
• Sprint Retrospective: Review the setup process and identify potential bottlenecks.

Sprint 2: Forum Structure (Weeks 4-5)

• Goal: Build the forum structure with categories and threads.
• Tasks:
• Database tables for categories and threads.
• Backend APIs: Fetch categories, create threads.
• Frontend: Forum homepage with categories and threads listing.
• Integration testing for forum browsing.
• Sprint Review: Showcase forum categories and thread creation.
• Sprint Retrospective: Discuss ways to improve task estimation and communication.

Sprint 3: Post Creation and Commenting (Weeks 6-7)

• Goal: Enable users to create posts and comment on threads.
• Tasks:
• Database tables for posts and comments.
• Backend APIs: Create, edit, and delete posts and comments.
• Frontend: Post creation and comment sections.
• Testing: Ensure functionality for creating/editing posts and comments.
• Sprint Review: Demonstrate post and comment functionality.
• Sprint Retrospective: Focus on debugging processes and reducing blockers.

Sprint 4: Moderation Tools (Weeks 8-9)

• Goal: Add admin and moderator features to manage posts and users.
• Tasks:
• Implement role-based access control.
• Backend APIs: Approve/delete posts, ban users.
• Frontend: Admin dashboard for moderators.
• Testing: Ensure security and role-based access are functional.
• Sprint Review: Present moderation tools and admin dashboard.
• Sprint Retrospective: Gather feedback on how to streamline workflows.

Sprint 5: User Experience and Performance Optimization (Weeks 10-11)

• Goal: Improve website performance and user experience.
• Tasks:
• Add search functionality for posts and threads.
• Optimize page load times and database queries.
• Ensure mobile responsiveness and accessibility.
• Conduct performance testing.
• Sprint Review: Showcase improved search and faster load times.
• Sprint Retrospective: Reflect on user experience improvements.

Sprint 6: Deployment and Launch (Weeks 12-13)

• Goal: Finalize and deploy the forum website.
• Tasks:
• Conduct end-to-end testing across all modules.
• Prepare deployment scripts and CI/CD pipelines.
• Deploy to production and monitor post-launch performance.
• Collect initial user feedback for future improvements.
• Sprint Review: Present the live website and walk through features.
• Sprint Retrospective: Summarize the project and discuss future iterations.

4 Development Tools - Jira

4.1 Backlog Mangement

• To manage backlog means we need to store our application information in certain format: word doc, Google doc, pdf, etc.
• Software development tool – Jira, Trello
• Ticket – Each task is called a ticket
• Task type
• Description
• Comments

Jira: Tool for task and project management.

4.1.1 JIRA

A popular Issue tracking system. Can be used to track Agile progress.

1. Sprint Structure: - Duration: Two weeks per sprint. - Goal: Deliver a specific set of functionalities or user stories planned during the Sprint Planning Meeting.
2. Sprint Planning Meeting: - Participants: Project Manager (PM), Team Lead, and all team members. - Duration: 2-4 hours. - Agenda:
   • Identify user stories to address in the sprint.
   • Break down larger tasks into smaller tickets.
   • Assign story points to tickets to estimate effort and relative complexity.
3. User Story to Ticket Workflow: - User Story: Created by the PM to define a feature or requirement (e.g., "As an owner, I want to add a property to the platform"). - Tickets:
   • PM breaks the user story into Jira tickets.
   • Tickets have unique identifiers (e.g., HGP-35) and story points (e.g., one story point equals one day's work for a senior developer).
4. Team Workflow: - Daily Standup Meeting (9:30 AM):
   • Each team member reports progress, blockers, and next steps (e.g., "Branch created, testing done, PR submitted with ticket HGP-35").
   • Blockers are addressed by the Team Lead assigning a helper.
   • Development and Collaboration:
   • Tasks are performed sequentially or in parallel, depending on dependencies.
   • Developers assist teammates, particularly newcomers, to maintain velocity.
5. Mid-Sprint Backlog Meeting: - Purpose: Review unfinished tasks, identify issues, and adjust the backlog if needed. - Outcome: Unfinished tickets are carried over to the next sprint or addressed if time allows.
6. Retrospective Meeting: - Final sprint meeting to summarize outcomes and gather feedback on what went well, what didn’t, and areas for improvement.

SDLC Integration

1. Story Points and Metrics: - A typical sprint includes ~10 story points, with adjustments based on complexity and team capacity.
2. Security Considerations: - Implement CSRF protection for APIs to ensure secure data handling.
3. Final Delivery: - The finished feature is validated across all environments and delivered in production.

This Agile workflow ensures that tasks are delivered efficiently while allowing flexibility to address blockers and evolving requirements. Let me know if you'd like to refine any part!

4.2 Kanban

A popular approach of Agile. Focus on Continuous flow of work instead of iterations.

Trello:

Agile Sprint Board:

Kanban Template:

5 Development Environment

• Software development usually have many different environment:
• Local: application deployed to local machine, laptop/desktop, for local testing
• Staging: deployed to remote cloud service, testing in real environment; for internally use only.
• Production: live version, customers will use this endpoint. Everything should be tested.
• Pre-Production: also for internally use, but environment is pretty much similar to production.

For example :

• Software development usually have many different environment:
• Local: localhost:8080
• Staging: www.testing.ebay.com
• Production: www.ebay.com
• Pre-Production: www.preprod.ebay.com

5.1 Jenkins

• Open source automation server
• Enable developers to reliably build, test and deploy software application
• Used by QE to do automation job
• Also used as part of CI/CD, generate code manifest

Frontend not use Jenkins CI/CD, use aws amplify

6 Deployment Strategies

https://youtu.be/AWVTKBUnoIg

Questions List

• What is SDLC? Why is it important?

SDLC, or Software Development Life Cycle, is a systematic process used for planning, creating, testing, and deploying software. It encompasses several structured stages, including requirement analysis, design, implementation, testing, deployment, and evolution or maintenance. Each phase has a specific purpose and provides checkpoints to ensure software development aligns with quality standards, timelines, and costs.

SDLC is important because it allows teams to produce high-quality software that meets or exceeds customer expectations. By following a defined process, teams can better estimate timelines and budgets, maintain clear communication within and across teams, and create an organized, transparent workflow that reduces chaos and errors. This approach also enables teams to continuously evaluate their work, identify areas for improvement, and ensure that development stays aligned with both technical and business objectives.

• Describe the basic steps of SDLC and explain the purpose of each step.

"The Software Development Life Cycle (SDLC) consists of several key steps, each designed to ensure that software development is structured, efficient, and aligned with project goals:

1. Requirement Analysis: This first step involves gathering and understanding the purpose and requirements of the application. The goal is to define what the software needs to accomplish and any constraints. This helps ensure the final product meets user expectations and business objectives.
2. Design: Design has two levels—macro and micro. At the macro level, teams select the programming languages, frameworks, and determine if the application will interact with other systems. At the micro level, it involves defining modules, setting coding standards, and establishing design patterns. This step provides a clear blueprint for development.
3. Implementation: Here, the actual coding takes place. Developers write code, manage dependencies, and conduct unit testing to verify that each component works as expected. The purpose of this phase is to build the application according to the design.
4. Testing: Testing is essential for quality assurance. The team conducts both local and environment testing to detect and fix any bugs, ensuring that the application functions correctly and meets requirements. Testing minimizes defects before the software reaches production.
5. Deployment: After testing, the software is deployed to the production environment, where end users can access it. The purpose of this step is to make the application available to users in a fully operational state.
6. Evolution/Maintenance: In this final stage, the team monitors and evaluates the software to see if improvements or updates are needed. Any necessary adjustments are made to enhance functionality, adapt to changes, or fix issues that arise after deployment.

Each step in SDLC is vital for building high-quality software, allowing teams to work methodically, maintain clear focus, and address potential issues at each stage to ensure the product is reliable and aligned with user needs."

• Explain the difference between the Waterfall model and the Agile model, including their use cases.

The Waterfall and Agile models are two fundamental approaches within the Software Development Life Cycle (SDLC), each with unique characteristics and suited for different project types.

1. Waterfall Model: The Waterfall model is a linear, sequential approach where each phase—such as requirement analysis, design, implementation, testing, and deployment—must be completed before the next one begins. It is straightforward and easy to manage since each stage has clear objectives. The Waterfall model is typically best suited for projects with well-defined requirements that are unlikely to change, such as government or manufacturing projects. - Pros: It is easy to understand and implement, with a clear structure and documentation for each phase. - Cons: It lacks flexibility, making it challenging to handle changes once a phase is completed. This rigidity can lead to issues if requirements evolve.
2. Agile Model: In contrast, the Agile model is an iterative and incremental approach that emphasizes flexibility and customer satisfaction. Development is divided into smaller cycles or iterations, where features are continuously designed, developed, and tested. Agile is ideal for projects where requirements are expected to evolve, such as software products for startups or technology-driven markets. Agile promotes frequent feedback, adaptability, and collaboration. - Pros: Agile allows for rapid adjustments, continuous user feedback, and incremental delivery, which helps teams respond effectively to changing requirements. - Cons: Agile can be resource-intensive, requiring strong communication and commitment from team members. It also lacks the detailed documentation typical in Waterfall.

In summary, Waterfall is better for projects with stable, predictable requirements, while Agile suits projects where requirements are expected to change or where user feedback is valuable throughout the development process.

• What is Scrum? Describe the roles and work pieces in Scrum.

Scrum is an Agile framework that organizes work into short, iterative cycles called Sprints to improve collaboration, adapt to changes quickly, and continuously deliver value. It emphasizes flexibility, teamwork, and customer-focused product development.

In Scrum, there are three main roles:

1. Product Owner: The Product Owner acts as the bridge between the technical team and the business side. They manage the Product Backlog, prioritize tasks, and clarify requirements, ensuring the development team is always aligned with customer needs.
2. Scrum Master: Often called the Agile Lead, the Scrum Master ensures that the Scrum process runs smoothly. They organize and facilitate meetings, help remove obstacles, and support the team to ensure they stay on track and meet deadlines.
3. Development Team: This is the group responsible for building the product. It typically includes backend and frontend developers, quality engineers, and other technical members who collaborate to deliver increments of the product during each Sprint.

Scrum Work Pieces include:

• Product Backlog: A prioritized list of all tasks and features needed for the project. The Product Owner is responsible for maintaining this list.
• Sprint Backlog: A subset of the Product Backlog. For each Sprint, the Product Owner selects high-priority tasks for the team to focus on during the Sprint.
• Increment: The work completed during a Sprint that contributes to a potentially shippable product. It represents the sum of all Product Backlog items completed so far.

In summary, Scrum helps teams deliver high-quality software by breaking down work into manageable pieces and ensuring constant communication and feedback, which is essential for projects where requirements may evolve over time

• Explain the five events in Scrum and their purposes.

Scrum has five main events, each designed to structure and support the iterative process, ensuring clear goals, efficient collaboration, and continuous improvement.

1. Sprint: The core of Scrum, a Sprint is a fixed time-boxed period (usually 2–4 weeks) during which the team works to complete a set of tasks from the Sprint Backlog. The purpose of the Sprint is to create a potentially releasable increment of the product.
2. Sprint Planning: This meeting marks the beginning of each Sprint. The Product Owner, Scrum Master, and Development Team come together to define what work will be accomplished in the upcoming Sprint, selecting high-priority tasks from the Product Backlog. The goal is to establish a clear Sprint goal and plan the tasks required to achieve it.
3. Daily Stand-up: A short, daily meeting (often about 15 minutes) where each team member shares their progress, planned tasks, and any obstacles they face. The purpose is to keep everyone aligned and identify any potential blockers early on.
4. Sprint Review: Held at the end of the Sprint, this meeting involves presenting the completed work to stakeholders for feedback. The purpose is to inspect the outcome and gather insights to inform the next Sprint, ensuring that the product evolves according to user needs.
5. Sprint Retrospective: This final event allows the team to reflect on the Sprint process itself, discussing what went well, what didn’t, and how to improve. The goal is to continuously enhance team performance by making adjustments that will make future Sprints more effective.

In summary, these five events create a structured framework for planning, executing, reviewing, and improving work, allowing the team to continuously adapt and deliver value.

• How is Jira used for task management? What are "backlog" and "sprint"?

Jira is a popular tool used in Agile project management, particularly for managing tasks and tracking progress in software development. In Scrum-based projects, Jira helps teams create, assign, and monitor tasks through various stages of the project life cycle. It provides visibility into each task’s status, allowing for better collaboration and prioritization.

Key terms in Jira include:

1. Backlog: The backlog is a prioritized list of all tasks or features that need to be completed for the project. It’s managed by the Product Owner, who organizes and updates it regularly based on feedback and business needs. Tasks in the backlog are typically high-level and can be broken down further as they move closer to being implemented. The backlog helps the team focus on what’s most important, providing a clear view of upcoming work.
2. Sprint: A Sprint is a time-boxed iteration, usually lasting 1–4 weeks, during which the team works on a specific subset of tasks from the backlog. In Jira, a Sprint Backlog is created for each Sprint, where tasks are moved from the main backlog based on priority and the team’s capacity. This subset of tasks becomes the focus of the Sprint, allowing the team to work in short, achievable cycles, measure progress, and deliver incremental value at the end of each Sprint.

In summary, Jira is a powerful tool for managing Agile workflows by organizing tasks in backlogs and Sprints, ensuring the team works on the right priorities, and providing a transparent view of progress for all stakeholders.

• Describe the different environments commonly used in software development and their purposes (e.g., local, production).

In software development, multiple environments are commonly used to support the development, testing, and release process, each serving a distinct purpose.

1. Local Environment: This is the developer’s personal workspace, usually on their local machine, where initial coding, unit testing, and debugging occur. The local environment allows developers to work independently, experimenting and fixing issues without affecting other environments or team members.
2. Development Environment: Sometimes separate from local, this environment is where the latest code from multiple developers is integrated and tested. It’s used to ensure that new code works well with the existing codebase, allowing for collaborative testing and troubleshooting.
3. Testing Environment: This environment is often isolated and configured to mirror production closely. It’s used by quality assurance (QA) teams to conduct thorough testing, including integration, system, and user acceptance tests, to identify and fix bugs before moving to the next stages.
4. Staging Environment: The staging environment replicates the production environment as closely as possible. It is the final testing ground for new code, allowing teams to validate deployment processes, run load tests, and verify that everything functions correctly in a real-world setting. Staging acts as a “dress rehearsal” for production.
5. Production Environment: This is the live environment where the application is accessible to end-users. Production is a stable and highly monitored environment, and any updates or changes go through rigorous checks before deployment here. The goal is to provide users with a reliable and high-performing application.

In summary, these environments create a structured workflow, enabling developers to code and test safely at different stages, while protecting the production environment to ensure a stable experience for end-users

• What role does Jenkins play in SDLC?

Jenkins is an open-source automation server that plays a critical role in the Software Development Life Cycle (SDLC) by supporting Continuous Integration (CI) and Continuous Deployment (CD) practices. Jenkins helps automate various stages of the SDLC, making the development and release process faster, more reliable, and less prone to errors.

Key roles Jenkins plays in SDLC include:

1. Continuous Integration (CI): Jenkins automates the process of integrating code from multiple developers. Whenever new code is committed, Jenkins can automatically build and test it. This ensures that issues are identified early, helping to prevent integration conflicts and maintain a stable codebase.
2. Automated Testing: Jenkins supports running unit tests, integration tests, and even end-to-end tests automatically. By integrating with testing frameworks, Jenkins can provide real-time feedback to developers, showing if their changes introduce any bugs or break existing functionality.
3. Continuous Deployment (CD): Jenkins automates the deployment process, allowing new builds to be deployed to staging or even production environments with minimal manual intervention. This makes it easier for teams to release features quickly and frequently.
4. Monitoring and Reporting: Jenkins provides detailed reports on build history, test results, and deployment status, giving teams insight into the health of the project. It can be configured to send alerts when builds fail, helping teams quickly address issues.

In summary, Jenkins streamlines SDLC by enabling continuous integration, automated testing, and deployment, creating a more efficient development pipeline. It reduces the need for manual steps, improves collaboration, and accelerates the delivery of high-quality software.