Note: This Notes is just for Reference and to understand main Concept.

MODULE 1: OVERVIEW
Software is more than just a program code. A program is an executable code, which serves some
computational purpose. Software is considered to be a collection of executable programming code,
associated libraries and documentations. Software, when made for a specific requirement is called software
product.

Engineering on the other hand, is all about developing products, using well-defined, scientific principles and
methods.

software engineering is the application of a systematic, disciplined, quantifiable approach to the

development, operation and maintenance of software

Key Principles of Software Engineering

1. Modularity
• Divide the software into independent modules.
• Each module handles a specific functionality.
• Helps manage complexity and improves maintainability.
2. Abstraction
• Focus on essential details while hiding the unnecessary ones.
• Simplifies design and enhances clarity.
3. Encapsulation
• Bind data and methods that operate on the data into a single unit.
• Restricts direct access to internal data, increasing security.
4. Separation of Concerns
• Break the system into distinct sections, each handling a separate concern.
• Makes understanding and updating the system easier.
5. Single Responsibility Principle
• Each module or class should have only one responsibility.
• Reduces the risk of changes affecting unrelated features.
6. Reusability
• Write code in a generic way so it can be reused in different parts of the project or in other projects.
• Saves time and effort.
7. Maintainability
• Design software so it can be easily modified or updated.
• Includes good documentation, modular code, and standard coding practices.

Reference Notes
8. Scalability
• Design the system to handle increasing workloads or user demands.
• Ensures long-term usability of the software.
9. Robustness
• Software should handle unexpected situations gracefully.
• Prevents crashes and data loss due to user or system errors.
10. Efficiency
• Use resources (CPU, memory, storage) wisely.
• Ensures fast and optimized performance.
11. Portability
• Software should run on different platforms with minimal changes.
• Useful in cross-platform development.
12. Testability
• Software should be easy to test.
• Improves defect detection and validation of correctness.
13. Consistency
• Follow consistent naming, formatting, and logic across all modules.
• Reduces confusion and improves collaboration.
14. Documentation
• Maintain up-to-date and clear documentation.
• Helps new developers understand and maintain the system.
NEED OF SOFTWARE ENGINEERING
The need of software engineering arises because of higher rate of change in user requirements and
environment on which the software is working.

• Large software - It is easier to build a wall than to a house or building, likewise, as the size of software
become large engineering has to step to give it a scientific process.

• Scalability- If the software process were not based on scientific and engineering concepts, it would be
easier to re-create new software than to scale an existing one.

• Cost- As hardware industry has shown its skills and huge manufacturing has lower down the price of
computer and electronic hardware. But the cost of software remains high if proper process is not adapted.

• Dynamic Nature- The always growing and adapting nature of software hugely depends upon the
environment in which the user works. If the nature of software is always changing, new enhancements need
to be done in the existing one. This is where software engineering plays a good role.

Reference Notes
• Quality Management- Better process of software development provides better and quality software
product.

Ethics To Be followed:
Principle Meaning / Description (in simple words)

Privacy & Data Always protect users’ personal information. Don’t collect or share more than
Protection necessary and ensure it is stored securely.

Design software to prevent misuse, hacking, or data leaks. Regularly update and
Security
test for vulnerabilities.

Transparency & Be clear about how the software works and how data is used. Take
Accountability responsibility for mistakes or failures.

Ensure your software treats everyone equally. Avoid discrimination based on

Fairness & Bias
race, gender, or other factors.

Think about how your software affects society. Don’t create tools that could
Societal Impact
harm or manipulate people.

Safety in Software Design software that avoids physical, emotional, or financial harm. Always
Design consider user safety first.

Respect others’ code, ideas, and digital content. Never use or copy without
Intellectual Property
permission or proper licensing.

Maintain the correctness, trustworthiness, and completeness of software. Avoid

Software Integrity
adding hidden or harmful features.

CHARACTERESTICS OF GOOD SOFTWARE: A software product can be judged by what it offers and
how well it can be used. This software must satisfy on the following grounds:
Operational
This tells us how well software works in operations. It can be measured on:

• Budget

• Usability

• Efficiency

• Correctness

• Functionality

• Dependability

• Security

• Safety
Transitional
This aspect is important when the software is moved from one platform to another:

Reference Notes
• Portability

• Interoperability

• Reusability

• Adaptability
Maintenance This aspect briefs about how well a software has the capabilities to maintain itself in the
everchanging environment:

• Modularity

• Maintainability

• Flexibility

• Scalability

SOFTWARE DEVELOPMENT LIFE CYCLE [ SOFTWARE

PROCESS MODEL]
A standardized plan used to develop software in a structured way.

That mean all the activities required to make a software product transit through its life cycle phases. It also
captures the order in which these activities are to be undertaken.
Need for a Software Life Cycle Model
1. Provides a Structured Approach
Ensures software development is done in a systematic and disciplined way.
2. Avoids Confusion in Teamwork
All team members know what to do and when, avoiding chaos in the development process.
Reference Notes
 3. Defines Clear Phases
Each phase (e.g., Requirements, Design, Coding, Testing) has entry and exit criteria.
A phase only begins when the previous one is properly completed.
4. Improves Coordination
All members follow the same sequence, improving communication and coordination.
5. Prevents Project Failure
Without a model, developers may work randomly (e.g., one codes first, another tests first),
leading to disorder and failure.
6. Helps in Project Monitoring
Project managers can track progress easily and ensure each phase is completed on time.
7. Ensures Quality Control
Entry/exit criteria allow review and validation at every stage, improving overall quality.
8. Enables Better Planning
Helps in estimating time, cost, and resources for each phase effectively.

Different software life cycle models or Software Process Models

Water Fall Model.

Feasibility study - The main aim of feasibility study is to determine whether it would be financially
and technically feasible to develop the product.
1. Requirements
Objective: Understand and document what the client needs.
Activities:
o Gather functional and non-functional requirements.
o Performs Feasibility Study.
o Conduct stakeholder interviews and surveys.
o Create a Software Requirements Specification (SRS) document.
Output: Clear and complete requirement specifications.
Reference Notes
 2. System Design
Objective: Plan the overall software architecture.
Activities:
o High-level design (architecture, database design).
o Low-level design (module design, data structures, algorithms).
o Define hardware and software requirements.
Output: Design documents, UML diagrams, and interface designs.

3. Implementation (Coding)
Objective: Convert design into working software.
Activities:
o Developers write code using appropriate programming languages.
o Code is developed according to design specifications.
o Follow coding standards and use version control.
o Unit testing will be performed.
Output: Source code for each module.

4. Testing and Integration

Objective: Ensure the software is bug-free and meets the requirements.
Activities:
o Unit testing, integration testing, system testing.
o Verify that all modules work together.
o Validate against the SRS document.
Output: Tested and verified software.

5. Delivery and Deployment

Objective: Deliver the final product to the customer.
Activities:
o Prepare installation package.
o Deploy the system in the user environment.
o Provide user training and documentation.
Output: Working system deployed in production.

6. Maintenance
• Objective: Correct and improve the system after deployment.
• Activities:
o Bug fixing (corrective maintenance).
o Enhancing features (perfective maintenance).

Reference Notes
 o Adapting to new environments (adaptive maintenance).
• Output: Updated and improved software system.

Advantages of Waterfall Model

1. Easy to understand and follow.
2. Clearly defined stages and goals.
3. Simple to manage with proper documentation.
4. Works well for small, fixed-scope projects.
5. Early planning and design reduce confusion later.

Disadvantages of Waterfall Model

1. Not flexible to changes once started.
2. Testing happens late in the process.
3. Client sees the final product only at the end.
4. High risk if requirements are wrong.
5. Not suitable for large or complex projects.

Incremental Model

1. Requirements

Objective: Gather all possible system requirements.

Activities:
o Entire system requirements are identified upfront.
o Requirements are divided into smaller functional units (modules/increments).
o Prioritize increments based on business or technical value.
Output: List of modular requirements for each release.

Reference Notes
 Each Increment Follows These Phases:

2. Analysis

Objective: Understand the requirements of the specific increment.

Activities:
o Analyze the selected module/function.
o Identify inputs, outputs, and processing needs.
o Determine dependencies with previous increments.
Output: Analyzed specification for the current increment.

3. Design

Objective: Create a technical blueprint of the increment.

Activities:
o High-level and detailed design.
o Define user interface (UI), data models, and interaction flows.
o Consider integration points with earlier releases.
Output: Design documents for implementation.

4. Implementation

Objective: Code the functionality of the increment.

Activities:
o Developers implement the design using programming languages.
o Code is written for just the features of this increment.
o Reuse existing components where applicable.
Output: Working code module for the increment.

5. Testing

Objective: Ensure the increment functions as intended.

Activities:
o Unit testing, integration testing, and regression testing.
o Verify compatibility with previously released increments.
Output: Tested, bug-free software module.

6. Deployment

Objective: Deliver the working increment to the client or user.

Activities:
o Deploy the increment to the production or staging environment.
o Configure it alongside earlier releases.
o Collect feedback from users.
Output: Released increment (e.g., Release 1, Release 2, etc.).

Reference Notes
7. Maintenance

Objective: Support the released increment.

Activities:
o Fix any defects found post-deployment.
o Improve or modify based on user feedback.
o Maintain compatibility with newer or older increments.
Output: Stable and improved version of the increment.

Process Repeats Until Final Product is Completed (Release n)

Advantages of Incremental Model

• Working software is delivered early.

• Easier to test and debug smaller parts.
• User feedback can be incorporated early.
• Flexible to changing requirements.

Disadvantages

• Requires good planning and design.

• Integration of increments can be challenging.
• Not suitable if requirements are not clearly defined upfront.

Prototype Model

Reference Notes
The prototype model is a software development approach where a working model of the software (a
prototype) is built quickly to understand requirements better. It allows continuous feedback from users before
the final system is developed.

Steps in the Prototype Model

1. Requirement Gathering and Analysis

o Developers discuss with clients to understand initial requirements.
o Only important features are identified at this stage (not all details).
o The focus is on what needs to be demonstrated in the prototype.
2. Quick Design
o A basic design (UI mockups, screen flow, data flow) is prepared.
o This design is not the final architecture it’s just enough to build a sample version.
3. Prototype Development
o A small, working model (prototype) of the software is created.
o It shows major features, user interfaces, and workflows without full functionality.
4. User Evaluation & Feedback
o The prototype is shown to the client or end-users.
o They interact with it and provide feedback on functionality, look, and feel.
5. Refinement of Prototype
o Based on feedback, changes are made to improve the prototype.
o This loop of evaluate → modify → evaluate continues until the client is satisfied.
6. Final Product Development
o Once the prototype meets expectations, full-scale development begins.
o The complete system is coded, tested, and implemented based on refined requirements.
7. Deployment & Maintenance
o The final product is delivered to the client.
o Maintenance ensures bug fixes, updates, and new features as required.

Advantages of Prototype Model

1. Helps clarify requirements early, reducing misunderstandings.

2. Allows users to see and interact with the system early in development.
3. Encourages active user involvement and satisfaction.
4. Reduces risk of building the wrong product.
5. Helps in identifying missing or confusing features before final development.

Reference Notes
Disadvantages of Prototype Model

1. Can lead to scope creep due to continuous changes.

2. Time-consuming if too many iterations are made.
3. May increase overall project cost if not managed well.
4. Developers might focus too much on the prototype and neglect quality in the final product.
5. Not suitable for large, complex systems requiring extensive planning.

Spiral Model

The Spiral Model is a combination of the waterfall model, iterative model and the Prototype Model. It
provides support for Risk Handling.

The Spiral Model is a software development process that develops the system in repeated cycles (spirals).

Each cycle goes through planning, risk analysis, engineering, and evaluation to ensure continuous
improvement and risk management.

1. Requirements Planning

• Identify system goals, define alternatives, and constraints.

• Understand user needs and document them clearly.
• Begin planning the next steps based on initial input.
Reference Notes
2. Risk Analysis

• Analyze risks like cost overruns, technical failure, etc.

• Explore solutions and build small prototypes to reduce risks.
• Decide whether to continue, change direction, or cancel.

3. Engineering / Development

• Design the software system in detail.

• Develop code, perform unit testing, and integrate modules.
• A working version (partial or full) of the software is created.

4. Evaluation and Verification

• Test the integrated system using various techniques.

• Users evaluate the current product and provide feedback.
• Verify that requirements are met and plan necessary changes.

5. Planning the Next Iteration

• Review results and decide objectives for the next cycle.

• Plan new features, updates, and improvements.
• The cycle repeats with increased refinement in each loop.

Advantages of Spiral Model

1. Focuses on early risk identification and reduction.

2. Allows customer feedback at each iteration.
3. Flexible for changes and improvements during development.
4. Suitable for large, high-risk, and complex projects.
5. Combines features of Waterfall and Prototyping models.

Disadvantages of Spiral Model

1. Complex and costly to implement.

2. Requires skilled risk analysts.
3. Not ideal for small or low-budget projects.
4. Development can be time-consuming due to repeated cycles.
5. Difficult to manage deadlines and cost estimation.

Reference Notes
V – Model

The V-Model (Verification and Validation Model) is a sequential software development process where each
development phase is directly associated with a testing phase. It emphasizes that testing starts in parallel with
development activities.

The V shape represents the relationship between the left side (Verification) and the right side (Validation).

Steps in the V-Model

Verification Phase (Left Side of V) – Planning & Designing

1. Requirement Analysis

o Understand and document business requirements.

o Acceptance test criteria are defined at this stage.

2. System Design

o High-level design of the system’s architecture.

o Defines system components and their interactions.

3. High-Level Design (HLD)

o Break down the system into modules/subsystems.

o Focus on data flow, database design, and module relationships.

4. Low-Level Design (LLD)

Reference Notes
 o Detailed design of each module.

o Includes pseudocode, interface specifications, and internal logic.

5. Coding

o Actual programming based on the LLD.

o After coding, the process moves to the Validation phase.

Validation Phase (Right Side of V) – Testing & Deployment

6. Unit Testing

o Tests individual components/modules for correctness.

o Based on LLD.

7. Integration Testing

o Checks the interaction between integrated modules.

o Based on HLD.

8. System Testing

o Verifies the complete system as per requirements.

o Based on system design.

9. Acceptance Testing

o Performed by end-users to ensure the product meets their needs.

o Based on requirement analysis.

Advantages of V-Model

1. Clear structure with well-defined stages.

2. Testing is planned early, reducing defects.

3. Easy to manage due to step-by-step approach.

4. Suitable for small to medium-sized projects with clear requirements.

5. Errors are found early in the development cycle.

Disadvantages of V-Model

1. Very rigid changes in requirements are hard to implement.

2. Not suitable for unclear or evolving requirements.

3. Early stages heavily depend on correct requirement gathering.

Reference Notes
 4. No working software is produced until late in the cycle.

5. Can be costly for large, complex projects.

Differences Between All models

Waterfall Incremental Prototype

Aspect Spiral Model V-Model
Model Model Model

Cyclical with
Linear, Development is
Build a repeated
sequential done in Similar to Waterfall but
prototype first, phases
phases from increments, each development phase
Process Flow refine based on (planning, risk
requirements each adding has a corresponding
feedback until analysis,
to new testing phase.
final product. engineering,
maintenance. functionality.
evaluation).

Very rigid; More flexible; Very flexible;

Highly Less flexible; changes
changes are changes iterative with
flexible; after a phase require
Flexibility costly after a possible in scope for
encourages rework in both dev and
phase is future changes at each
changes early. test.
completed. increments. cycle.

Medium risk Good for Excellent; risk

Poor risk
Risk handling; risks reducing analysis is a Low risk handling unless
handling; risks
Management can be fixed in requirement core part of found in testing phase.
identified late.
next increment. risks early. each cycle.

Moderate; Low to medium;

Minimal after High; constant High; customer
Customer feedback involvement mostly in
requirement feedback on involved in
Involvement possible after requirement &
phase. prototypes. each iteration.
each increment. acceptance testing.

When product
When When
can be When project
requirements requirements When requirements are
delivered in is high-risk,
When to Use are well- are unclear & clear & high emphasis on
parts & complex, or
defined & need verification/validation.
priorities costly.
stable. validation.
change.

Reference Notes
 Waterfall Incremental Prototype
Aspect Spiral Model V-Model
Model Model Model

Delivered in Prototype
Delivered after
Delivered once functional parts delivered early, Delivered at the end after
Delivery each cycle’s
at the end. after each final product verification.
completion.
increment. later.

Lower than
Moderate;
Waterfall; Low in early
Cost of Very high in changes High if changes occur
changes stages,
Changes later stages. possible every after verification starts.
possible in new increases later.
iteration.
increments.

Web Military,
Banking UI-heavy
applications, aerospace,
Example Use systems, ERP, systems, R&D Medical devices, safety-
mobile apps large-scale
Cases embedded projects, proof critical systems, avionics.
with evolving government
software. of concept.
features. projects.

Process activities

Simple
Step Detailed Explanation Example
Meaning

This is where the client, users, and

developers talk to decide requirements. It
Client says: “I need
includes functional requirements (what
Deciding what an online store with
1. Software features it must have) and non-functional
the software login, product
Specification requirements (speed, security,
should do. catalog, and
performance). The output is a Software
payment system.”
Requirement Specification (SRS)
document.

First, design the software architecture,

Planning the Plan database
2. Software database, and user interface. Then,
structure and tables for users,
Design & developers write the actual program. This
then writing products, orders →
Implementation step turns requirements into a working
the code. Code login page
product.

Reference Notes
 Simple
Step Detailed Explanation Example
Meaning

and payment
module.

This step ensures the software meets the

requirements and works without bugs. Test login with
3. Software Checking if it Includes unit testing (testing small parts), correct and wrong
Validation works integration testing (testing combined passwords; check if
(Testing) correctly. parts), system testing (testing the whole cart updates
system), and user acceptance testing correctly.
(UAT).

Add “Wishlist”
Once delivered, the software is maintained
4. Software Updating and feature later
to fix bugs, improve features, or adapt to
Evolution improving because customers
new needs. This is ongoing throughout the
(Maintenance) after release. requested it; fix a
product’s life.
payment bug.

Coping with Change

Simple
Step Detailed Explanation Example
Meaning

Use flexible architecture, modular Prepare database so extra

Expect changes
1. Anticipating coding, and scalable databases so payment methods can be
and prepare in
Change changes can be made without added later without
advance.
rewriting everything. redesign.

Agile, Scrum, and Kanban allow

Use methods changes even in later stages. Use Scrum so client can
2. Flexible
that welcome Waterfall is less flexible. Choose a request “Add UPI
Process Models
change. model based on expected change payment” mid-project.
frequency.

Reference Notes
 Simple
Step Detailed Explanation Example
Meaning

Instead of building the whole

Build in small
software at once, deliver small First deliver product
3. Iterative cycles and get
working parts (increments) so search, then cart, then
Development feedback each
client can review and suggest payment.
time.
changes early.

Keep a change log, review impact Client fills a change

Have a formal
4. Change on time and budget, and only request for “Dark Mode”
process to track
Management implement approved changes. → Project manager
and approve
System Prevents random unplanned approves → Developer
changes.
changes. adds in next release.

Agile software development

What is Agile?

Agile is a way of developing software (or products) that is flexible, quick, and customer-focused.
Instead of making the whole product in one go (like Waterfall), Agile makes it step-by-step in small
parts called iterations.

• Keep tasks small and easy to test.

• Choose tasks that give the most value first.
• Write clear “done” rules for every task.
• Get feedback quickly and often.
• Improve one small thing each sprint.

In simple way if I am working on application which is used to maintain Feedback, I will write a
prototype and build it, then I will release it, later I will collect the feedback from client or users, I
will implement changes or I will use advance features in it.

Main Ideas of Agile

• Talk to people more than relying on tools and documents.

• Make working software more than writing big reports.

• Work with customers instead of just following contracts.

Reference Notes
 • Change the plan anytime if needed.

Agile principles

1. Customer satisfaction through early & continuous delivery

Deliver usable pieces often so customers get value fast and can give feedback.

2. Welcome changing requirements

If needs change, adapt even late in the project because change often improves the product.

3. Deliver working software frequently

Release small, working parts every few weeks (not months) so progress is visible.

4. Business people and developers work together daily

Regular cooperation keeps priorities clear and removes misunderstandings.

5. Build projects around motivated people

Trust the team, give them what they need, and they’ll produce better work.

6. Face-to-face (or direct) communication is best

Quick conversations (or short calls) beat long emails for solving problems fast.

7. Working software is the main measure of progress

Functioning features matter more than long documents or charts.

8. Sustainable pace
Work at a steady rate that can be kept long-term avoid burning out the team.

9. Technical excellence & good design

Clean code and good design reduce future problems and speed up change.

10. Simplicity maximizes what’s not done

Do only what brings value avoid unnecessary features.

11. Self-organizing teams

Teams decide how to do the work; they know best how to deliver.

12. Regular reflection and adaptation

After each cycle, the team looks back, learns, and improves the process.

How Agile Works

1. Idea / Vision
Someone (client or stakeholder) decides what product to make and what problem it should
solve.

Reference Notes
 2. Make a To-Do List (Product Backlog)
Write down all features, fixes, and improvements. This is a priority list.

3. Arrange & Estimate

The client (Product Owner) puts the most important items on top.
The team estimates how much work each will take.

4. Plan the Sprint

Choose the top items you can finish in the next short cycle (1–4 weeks).
This is your Sprint Backlog.

5. Do the Work (Build & Test)

Team creates the features, tests them, and keeps the code updated.

6. Daily Small Meeting

Every day, have a 15-minute stand-up to share:

o What you did yesterday

o What you will do today

o Problems stopping you

7. Show & Tell (Review/Demo)

At the end of the sprint, show the finished work to the client/stakeholders and get feedback.

8. Look Back (Retrospective)

Discuss what went well, what went wrong, and how to do better next time.

9. Release (if ready)

If the work is complete and meets the rules for “done,” send it to users.

10. Repeat
Use the feedback, update the to-do list, and start the next sprint.

Example:

2-Week Sprint

• Before Sprint – Break big tasks into smaller ones and write clear “done” rules.

• Day 0 – Sprint Planning – Decide what you can finish in 2 weeks and set a sprint goal.

• Days 1–10 – Work Time

o Have daily 15-min stand-ups.

Reference Notes
 o Build, test, and fix problems quickly.

o If new info comes in mid-sprint, adjust small things.

• Day 11 – Sprint Review – Show the work to the client/stakeholders and get feedback.

• Day 12 – Retrospective – Team talks about improvements for the next sprint.

• After Sprint – Deploy if ready, update the to-do list, plan the next sprint.

Main Roles (People Involved)

• Product Owner – Client who sets priorities.

• Scrum Master – Helps the team work smoothly.

• Development Team – Builds and tests the product.

• Stakeholders – Users/clients who give feedback.

Types Of Agile Methodologies

A. Scrum

How it works:

Scrum Step What Happens Example (E-commerce Website Project)

1. Product The Product Owner creates a Product Owner lists: “Add product
Backlog prioritized list of all features, fixes, search,” “User login,” “Shopping cart,”
Creation and improvements. “Payment gateway,” etc.

The team selects a set of high-

2. Sprint priority items from the Product For a 2-week Sprint: choose “User login”
Planning Backlog to work on in the next Sprint and “Shopping cart” as Sprint goals.
(usually 2–4 weeks).

“User login” → front-end login form,

3. Sprint Break down selected tasks into
backend authentication, database setup.
Backlog smaller, actionable items and assign
“Shopping cart” → add item button, view
Preparation them to team members.
cart page, update quantity function.

Dev A: “Yesterday I completed login

4. Daily Scrum Every day, a short 15-minute meeting
form, today I’ll integrate backend, no
(Stand-up) is held where each member says:
blockers.” Dev B: “Working on cart

Reference Notes
Scrum Step What Happens Example (E-commerce Website Project)

what they did yesterday, what they update feature, facing issue with quantity
will do today, and blockers. update.”

Team works on the Sprint Backlog Developers build login and cart features;
5. Development
items, collaborating and solving Scrum Master helps solve quantity update
Work
blockers with help of Scrum Master. bug.

At the end of the Sprint, the team Team shows working “User login” and
6. Sprint
demonstrates the completed work to “Shopping cart” in the live demo to the
Review
stakeholders for feedback. Product Owner.

“Stand-ups were effective, but task

Team discusses what went well, what
7. Sprint estimation needs improvement” → decide
can be improved, and makes changes
Retrospective to break tasks into smaller pieces next
for the next Sprint.
time.

8. Repeat Next The cycle repeats with new backlog Next Sprint focuses on “Payment
Sprint items. gateway” and “Product search.”

Pros:

• Regular feedback keeps product relevant.

• Predictable delivery every Sprint.

• Easy to track progress.

• Clear roles and responsibilities.

• Encourages teamwork.

Cons:

• Mid-sprint changes are tricky.

• Meetings can feel like too many.

• Needs disciplined team.

• Can be rigid for fast-changing needs.

Reference Notes
B. Kanban

How it works:

Example (E-commerce Website

Kanban Step What Happens
Project)

All tasks are listed on a Kanban board, Board shows: To Do – “User login,”
1. Visualize Work divided into columns like To Do → In “Shopping cart,” “Payment
Progress → Testing → Done. gateway.”

2. Set Work in Team decides how many tasks can be in

Progress (WIP) each column at a time to avoid WIP limit: In Progress max 3 tasks.
Limits overload.

Team members pull the next highest-

Dev A finishes login backend →
3. Pull Work, priority task when they have capacity,
pulls “Shopping cart UI” from To Do
Don’t Push rather than being assigned everything
to In Progress.
upfront.

4. Work on Tasks Team works on items, moving them “User login” moves from In Progress
Continuously across columns as progress is made. → Testing after completion.

5. Review and As soon as a task reaches Done, it’s “User login” tested → moved to
Deliver ready for release (no waiting for a sprint Done → deployed live for users
Continuously to end). immediately.

Notice “Payment gateway” took 5

Team tracks how long tasks take (Lead
6. Monitor Flow & days due to API issues → improve
Time, Cycle Time) and adjusts process
Improve documentation for future
for efficiency.
integrations.

Regular meetings (if needed) to discuss Team adds a new column Blocked
7. Continuous
process improvements and update for tasks waiting on third-party
Feedback Loop
board. approval.

Pros:

• Super flexible adapt anytime.

Reference Notes
 • Visual system makes status clear.

• Reduces multitasking and overload.

• Works well for support/maintenance work.

• Quick to set up.

Cons:

• No deadlines can slow pace.

• Less structure needs self-disciplined team.

• Harder to plan long-term timelines.

• Can get messy if WIP limits ignored.

C. Extreme Programming (XP)

How it works:

1. Aim for very high-quality code.

2. Practices:

o Test-Driven Development, write test first, then code.

o Pair Programming, 2 people work on same code.

o Continuous Integration, merge code often.

o Frequent small releases.

3. Client is closely involved daily.

4. Code is constantly improved (refactoring).

Example (E-commerce
XP Step What Happens
Website Project)

Customer and team decide Decide to build “User

1. Planning what features to build next login” and “Shopping cart”
(small releases). first.

Release “User login” after 3

Deliver software in very
2. Small Releases days, “Shopping cart” after
small, frequent updates.
another 4 days.

Reference Notes
 Example (E-commerce
XP Step What Happens
Website Project)

Keep the design simple Only create basic login form

3. Simple Design and only build what is now, skip extra animations
needed now. for later.

Two developers work

Dev A writes cart code, Dev
4. Pair together on one computer –
B reviews and suggests
Programming one codes, one reviews in
improvements instantly.
real-time.

5. Test-Driven Write a test: “Login fails if

Write tests before writing
Development password is wrong” → then
the actual code.
(TDD) code to pass the test.

Frequently merge and test Merge changes into main

6. Continuous
code to avoid big issues project after every small
Integration
later. feature is done.

Simplify long login code

Improve code quality
7. Refactoring into smaller reusable
without changing behavior.
functions.

Customer says: “Add

Customer tests each release
8. Customer ‘Forgot Password’ to login”
and suggests changes
Feedback → team adds in next
quickly.
release.

Pros:

• Very few bugs if done right.

• Easy to change features.

• Great for complex or unclear requirements.

• Encourages teamwork and learning.

• Code is clean and easy to maintain.

Reference Notes
Cons:

• Pair programming can double labour cost.

• Demands skilled developers.

• Can be tiring due to high pace.

• Needs full-time client availability.

D. Lean

How it works:

Lean Step What Happens Example (E-commerce Website Project)

Understand what the customer Customers want fast checkout and easy
1. Identify Value
really needs and focus on it. product search.

Checkout process mapped: Select → Cart →

List all steps needed to deliver
2. Map the Value Payment → Confirmation. Remove
value and remove wasteful
Stream unnecessary steps like extra confirmation
steps.
page.

Ensure work moves smoothly Make sure adding to cart, payment, and
3. Create Flow
without delays or bottlenecks. confirmation happen without slow page loads.

Work on features only when Don’t build “Wishlist” now because

4. Establish Pull there is demand (no customers are asking for “One-click payment”
overproduction). first.

5. Continuous Keep improving based on

After launch, reduce checkout clicks from 4 to
Improvement feedback and performance
2 based on customer complaints.
(Kaizen) data.

Avoid unnecessary work,

6. Eliminate Waste Remove unused “Gift Card” feature because
waiting, extra features,
(7 Types) no one is using it.
defects, etc.

Pros:

• Saves time and money.

Reference Notes
 • Adapts easily to change.

• Fast delivery.

• Motivates team with freedom to decide.

• Improves efficiency over time.

Cons:

• Risk of removing important steps by mistake.

• Needs mature and responsible team.

• Can push speed over quality if not careful.

• Requires constant monitoring.

E. Crystal

How it works:

1. No single fixed process changes depending on:

o Team size.

o Project type.

o Urgency.

2. Communication is key prefer talking over writing.

3. Deliver working product often.

4. Adapt process as the project changes.

5. Focus on people, not tools or documents.

Example (E-
Crystal Step What Happens commerce Website
Project)

Crystal has different versions

Small team (6
1. Identify Project (Crystal Clear, Yellow,
members) → use
Size & Team Type Orange…) depending on team
Crystal Clear method.
size & project criticality.

Reference Notes
 Example (E-
Crystal Step What Happens commerce Website
Project)

Release “User login” in

2. Frequent Deliver working software
week 1, “Shopping
Delivery regularly in small increments.
cart” in week 2.

Daily chats in the

Prioritize face-to-face,
3. Focus on office to discuss
informal communication over
Communication progress instead of
heavy documentation.
long reports.

Team decides to use a

Hold reflection workshops to
4. Reflect & shared code repository
see what’s working and what
Improve after facing merge
to improve.
issues.

Developers choose
Trust skilled people to choose
5. Prioritize People their own testing
the best tools and methods for
Over Processes framework instead of
the job.
being forced into one.

Switch from 2-week

6. Adapt to Project Processes are flexible and can cycles to weekly cycles
Needs be changed if needed. when urgent bug fixes
are required.

Developer reports a
Encourage open discussion
7. Maintain Safety payment bug without
without blame to solve
in Work fear of criticism, and
problems.
team fixes it together.

Pros:

• Fits many different team types.

• Light and easy to change.

Reference Notes
 • Encourages direct communication.

• Less paperwork.

• Team can design its own best process.

Cons:

• Can be too loose may confuse new teams.

• Relies heavily on skilled people.

• Not great for very large projects.

• Needs strong self-management.

F. DSDM (Dynamic Systems Development Method)

How it works:

1. Time, cost, quality are fixed scope can change.

2. Deliver in stages (increments).

3. Involve users throughout the project.

4. Agree on priorities before starting.

5. Focus on delivering what’s most important first.

6. Stick to deadlines by cutting lower-priority features if needed.

Example (E-commerce Website

DSDM Step What Happens
Project)

Check feasibility and

Decide if building an e-commerce site
1. Pre-Project business case before
is worth the cost and resources.
starting.

Assess if the project is

Check if payment gateway integration
2. Feasibility Study technically and financially
and hosting are affordable and doable.
possible.

Understand business needs Identify that customers need fast

3. Business Study and create a high-level checkout, mobile-friendly design, and
plan. secure payments.

Reference Notes
 Example (E-commerce Website
DSDM Step What Happens
Project)

Build and improve

4. Functional Model Create a working prototype of product
functional prototypes in
Iteration search → get feedback → improve.
short cycles.

Develop the actual system Build shopping cart module, release it

5. Design & Build
in small chunks with for testing, and enhance it in next
Iteration
feedback. iteration.

Deploy the system for real

Launch the e-commerce website and
6. Implementation use and train users if
provide admin training.
needed.

Review success, ensure

Monitor site performance, fix bugs,
7. Post-Project system works, and
and plan new features.
maintain it.

Pros:

• Meets deadlines and budgets reliably.

• Strong user input keeps product relevant.

• Flexible in choosing features.

• Clear priorities from start.

• Reduces scope creep risk.

Cons:

• Needs committed clients.

• Can be tough to balance priorities.

• Less flexible with time and cost.

• Requires experienced planning.

Reference Notes
Differences Between Agile methods

Agile Timefra How Work is Key Flexibili Main Main

Best For
Method me Organized Focus ty Pros Cons

Fixed Medium
Product Predictabl Hard to
short Team (changes
Backlog → Projects with e delivery, change
cycles roles & mostly
Scrum Sprint clear short- strong mid-sprint,
(Sprints: regular after
Backlog → term goals team many
2–4 feedback sprint
Sprint structure meetings
weeks) ends)

Limit No
Continuo Visual board Very Support,
work in Simple, deadlines
us (no (To Do → High maintenance,
Kanban progress visual, can slow
fixed Doing → (change continuous
, smooth flexible pace, less
cycles) Done) anytime) work
flow structure

Short High
Test-first
cycles + High- (frequent Fewer Needs
Extreme coding, pair Software
continuou quality releases bugs, easy skilled
Programmi programming, needing high
s clean allow to change, devs, can
ng (XP) frequent reliability
integratio code quick clean code be tiring
releases
n changes)

Can cut
Saves
Flexible Remove Efficien Projects too much,
time/mone
Lean small waste, deliver cy & High needing speed needs
y, adapts
deliveries value fast value & cost control disciplined
fast
team

Flexible Communicati People Adapts to Can be too

Small to
(depends on-driven, over Very any team, loose, hard
Crystal medium
on team tailored processe High light for
unique projects
size/type) process s process beginners

Fixed Deliver in Medium Meets Needs

Meeting Projects with
DSDM time & stages, cut (features deadlines, experience
deadline strict
cost, low-priority change, strong d

Reference Notes
Agile Timefra How Work is Key Flexibili Main Main
Best For
Method me Organized Focus ty Pros Cons

flexible features if s& but not budgets/timeli user planning,

scope needed budgets time/cost nes involveme client
) nt commitme
nt

Differences Between Agile method and Water Fall model:

Feature Agile Method Waterfall Model

Iterative (work in small cycles, Sequential (finish one phase before

Process Style
repeat) next)

Very flexible — changes can be Rigid — changes are hard and costly
Flexibility
made anytime after starting

Delivery Deliver small parts early and often Deliver full product at the end

Customer High — client gives feedback Low — client usually sees product only
Involvement regularly at the end

Testing happens continuously during

Testing Testing happens after all coding is done
development

Risk Handling Low risk — issues found early Higher risk — issues found late

Less paperwork, focus on working

Documentation Heavy documentation before starting
product

Team
Daily or frequent meetings Limited to phase reviews
Communication

Best For Projects with changing requirements Projects with clear, fixed requirements

Slower to adapt, final delivery might

Speed Fast to adapt, delivers value quickly
take long

Reference Notes
Feature Agile Method Waterfall Model

Building an app where features can Building a bridge where design can’t
Example
change often change mid-way

Plan-Driven Development (Traditional / Predictive Approach)

This approach is sometimes called Heavyweight Process or Waterfall-style development.

Characteristics

• Upfront planning: All requirements are gathered and documented before coding begins.

• Sequential stages: Development moves step by step (Requirements → Design →

Implementation → Testing → Deployment → Maintenance).

• Documentation-heavy: Every step is well-documented for future reference.

• Rigid structure: Once a stage is completed, going back is very costly.

• Change resistance: Requirements are expected to stay stable, so handling changes is

difficult.

When to use?

• Requirements are well-known and unlikely to change.

• Project is large and critical (e.g., defense, aviation, banking systems).

• Clients want predictability (fixed cost, fixed deadline).

Advantages

Clear structure and well-defined process.

Easier for large teams with strict roles.
Suitable for safety-critical projects (where every step must be verified).

Disadvantages

Very rigid — difficult to adapt to changes.

Customer sees product only at the end → risk of dissatisfaction.
is late → errors may remain hidden for long.

Example

Reference Notes
 • Building a railway system → You cannot keep changing requirements midway, everything
must be fixed early.

Agile Development (Adaptive / Iterative Approach)

Agile is a lightweight, flexible, and iterative way of developing software.

Characteristics

• Incremental development: Work is divided into small iterations (sprints, usually 1–4 weeks).

• Customer involvement: Customers review product after each iteration and give feedback.

• Embraces change: Requirements can evolve at any stage.

• Working software focus: Deliver a small but working product quickly, then improve it step
by step.

• Team collaboration: Developers, testers, and customers work closely together.

When to use?

• Requirements are unclear or keep changing.

• Project is innovative (e.g., mobile apps, startups, games).

• Customer wants to see progress early and frequently.

Advantages

Flexible to changes.
Customer satisfaction (continuous involvement).
Faster delivery of working features.
Problems are detected early (testing in every iteration).

Disadvantages

Hard to predict final cost and time.

Requires active customer involvement.
Not ideal for very large, safety-critical projects.

Example

• Developing a mobile app → You can release version 1 with basic features, then add more
features based on user feedback.

Reference Notes