●​ Classical Waterfall model

●​ Iterative Waterfall model

●​ V-model
●​ Prototype model
●​ Incremental development
●​ Evolutionary model
●​ RAD (Rapid Application Development)
●​ Agile Development
●​ Spiral Model

1. Classical Waterfall Model

Proposed by Winston W. Royce, it divides the development process into sequential phases.
Phases between feasibility study and testing are known as development phases.

1.​ Feasibility Study

○​ Determines if developing the software is financially and technically viable.
○​ Examines multiple solution strategies and their costs.
○​ Conducts cost-benefit analysis.
2.​ Requirements Analysis & Specification
○​ Collects and analyzes customer requirements. Document them.
○​ 2 distinct activities- requirements gathering and analysis | requirements
specifications
○​ Resolves ambiguities and contradictions.
○​ Produces a Software Requirements Specification (SRS) document.
3.​ Design
 ○​ Converts the SRS into software architecture.
○​ Uses two approaches:
■​ Traditional Approach

Consists of 2 activities:

a.​ Structured analysis: Identify all the functions to be performed.

Identify data flow among the functions. Decompose each function
recursively into sub-functions. Carried out using Data Flow
Diagrams (DFDs).
b.​ Structured design: HLD decomposes systems into modules, and
represents invocation relationships among modules. Detailed
Design deals with different modules in greater detail. Data
structures and algorithms for each module are designed.
c.​
■​ Object-Oriented Approach (Identifies real world objects like Employees,
Managers, and identifies relationships between them). Advantages:
Lower development time and cost, better maintainability.
4.​ Implementation (Coding & Unit Testing)
○​ Translates the design into source code.
○​ Each module is coded, tested independently, debugged, and documented.
○​ End product is a set of program modules that have been tested individually.
5.​ Integration & System Testing
○​ Integrates all modules in a planned manner, in a number of steps.
○​ Ensures the system meets requirements.
6.​ Maintenance
○​ Most time-consuming phase (40:60 ratio with development).
○​ Maximum effort. 60%
○​ Includes Corrective, Perfective, and Adaptive Maintenance.

Limitations:

❌ Assumes no defect is introduced in any development activity.​

❌ Rigid (No going back if errors are found).​
❌ Late testing phase (errors discovered too late).

2. Iterative Waterfall Model

Improves on the classical model by introducing feedback loops.
✅ Errors are fixed in earlier stages rather than at the end.​
✅ Phase Containment of Errors: Detecting errors in the same phase they were introduced.​
✅ Most widely used model in practice.

3. V-Model (Verification & Validation)

Enhances the Waterfall Model by pairing each development phase with a corresponding
testing phase.
 ●​ Development Phase → Corresponding Testing Phase
○​ Requirements Analysis → User Acceptance Testing
○​ System Design → System Testing
○​ High-Level Design → Integration Testing
○​ Low-Level Design → Unit Testing

✅ Ensures defects are caught early.​

❌ Not flexible for handling changing requirements.
Best Suited For:

●​ Military & Aerospace Projects

●​ Embedded Systems

4. Prototyping Model
Develops an early working version of the system before full-scale development.

Why Prototyping?

●​ Demonstrates key functionalities to the customer.

●​ Explores technical feasibility (e.g., checking algorithm efficiency).
●​ Reduces design mistakes since users provide feedback early.

Process:

1.​ Gather rough requirements.

2.​ Build a quick design with shortcuts.
3.​ Create a working prototype.
4.​ Get customer feedback.
5.​ Refine until the customer approves.
6.​ Develop the final product using the Waterfall Model.

❌ Disadvantages:
●​ High costs (building and discarding prototypes).
●​ Users might mistake the prototype for the final system.
5. Evolutionary Model
Also known as the Incremental Model, it builds the system in phases.

●​ Develops core modules first and refines them over time.

●​ New features are added in successive versions.
●​ User feedback helps improve the system.

Necessary conditions for implementation:

●​ Customer needs are clear and explained in depth to the developer team.
●​ There might be small changes required in separate parts but not a major change.
●​ As it requires time, there must be some time left for the market constraints.
●​ Risk is high and continuous targets to achieve and report to customers repeatedly.
●​ It is used when working on a technology that is new and requires time to learn.

✅ Best for large projects that can be incrementally implemented, users get a chance to
experiment with a partially developed system much before the full working version is released,
helps finding exact user requirements much before fully working system is developed. Core

❌
modules get tested thoroughly and reduce chances of errors in the final product.​
Difficult to divide all problems into independent modules.
6. Rapid Application Development (RAD)
Combines prototyping and incremental development for faster delivery. Emphasizes quick
and iterative release cycles, primarily focusing on delivering working software in shorter
timelines.
Features:

●​ Uses short development cycles (iterations).

●​ Aims to reduce costs and quickly accommodate change requests.
●​ Prototypes are not discarded but enhanced into final products.

✅ Best for projects where requirements change frequently.​

❌ Not suitable for large-scale enterprise applications requiring stability.
●​ Development takes place in a series of short cycles or iterations.
●​ At any time, the development team focuses on the present iteration only, and therefore
plans are made for one increment at a time.
●​ The time planned for each iteration is called a time box.
●​ Each iteration is planned to enhance the implemented functionality of the application by
only a small amount.
●​ During each time box, a quick-and-dirty prototype-style software for some functionality is
developed.
●​ The customer evaluates the prototype and gives feedback on the specific improvements
that may be necessary. The prototype is refined based on the customer feedback.
●​ The development team almost always includes a customer representative to clarify the
requirements. ​

Why is RAD unsuitable?

●​ Generic products (wide distribution)
●​ Requirement of optimal performance and/or reliability
●​ Lack of similar products
●​ Monolithic entity- uses one code base to perform multiple business functions.
●​ Though RAD is expected to lead to faster software development compared to the
traditional models (such as the prototyping model), the quality and reliability would be
inferior. ​

7. Spiral Model (Proposed by Boehm, 1988)

●​ Risk-driven approach: Every phase assesses risks and creates alternatives.
 ●​ Divides development into loops with four quadrants:
1.​ Objective Setting (Define goals & identify risks).
2.​ Risk Assessment & Reduction (Mitigate risks like unclear requirements).
3.​ Development & Validation (Build & test product incrementally).
4.​ Planning the Next Phase (Review with customer and iterate).

✅ Best for high-risk, large projects.​

❌ Expensive due to continuous risk evaluation.
Spiral as a meta model:
●​ Subsumes all discussed models:
●​ A single loop spiral represents a waterfall model.
●​ Uses an evolutionary approach -- iterations through the spiral are evolutionary levels.
●​ Enables understanding and reacting to risks during each iteration along the spiral.
●​ Uses- prototyping as a risk reduction mechanism, retains the step-wise approach of the
waterfall model.

1. Determine Objectives & Identify Risks (Planning)

●​ Similar to the Requirement Phase in Waterfall.

●​ Involves feasibility study and goal setting.
2. Risk Assessment & Prototyping

●​ Prototyping Model is used to test high-risk areas.

●​ Technical risks (e.g., performance, security) are evaluated.
●​ Risk-driven approach makes it unique.

3. Development & Testing

●​ If risk is low, it follows a linear Waterfall approach.

●​ If risk is high, Prototyping or Incremental approaches are used.

4. Review & Plan Next Iteration

●​ Each loop refines the product, similar to Agile iterations.

●​ Incorporates feedback-driven improvement.

8. Agile Development
Designed for fast-changing business environments.

Key Features:

●​ Iterative & Incremental (multiple small releases).

●​ Customer Involvement throughout development.
●​ Lightweight documentation (compared to traditional methods).

Popular Agile Methods:

●​ Scrum
●​ Extreme Programming (XP)
●​ Kanban
9. Extreme Programming
In XP, requirements are expressed as scenarios (called user stories), which are implemented
directly as a series of tasks. Takes an extreme approach to iterative development.

❌
XP was created to solve problems in traditional software development, such as:​
Late deliveries due to long development cycles.​
❌ Unclear or changing requirements causing rework.​
❌ Poor communication between developers and customers.​
❌ Defects and bugs discovered late in testing.
✅ XP focuses on rapid, continuous feedback to create high-quality software with minimal
waste.

2. Core Principles of XP
XP is based on five key values:

1.​ Communication
○​ Continuous collaboration between developers, customers, and stakeholders.
○​ Pair Programming ensures that code is reviewed in real-time.
2.​ Simplicity
○​ Build only what is needed—no unnecessary complexity.
○​ Refactoring keeps code clean and maintainable.
3.​ Feedback
○​ Frequent releases help get real user feedback quickly.
○​ Automated testing ensures early bug detection.
4.​ Courage
○​ Developers should be willing to make bold changes if needed.
○​ Fixing problems immediately instead of delaying them.
5.​ Respect
○​ Teams trust and support each other to produce the best software.

3. Practices of XP
XP uses specific engineering and project management practices to maintain quality and
adaptability.

1. Project Management Practices

●​ Two developers work on one codebase at a time.

●​ One writes code (Driver), the other reviews it (Navigator).
●​ Reduces errors, improves design.

2. Project Management Practices

✅ User Stories
●​ Small, well-defined requirements written in plain language.
●​ Example: "As a user, I want to reset my password via email."

✅ Small Releases
●​ Deliver working software in short cycles (1-2 weeks).
●​ Allows customers to give early feedback.

✅ On-site Customer
●​ A customer representative is part of the team.
●​ Ensures requirements are clear and changes can be made quickly.

✅ Sustainable Pace (40-hour Workweek)

●​ No overwork! Avoid burnout by maintaining a steady work rhythm.
●​ Promotes a healthy work-life balance.

✅ Coding Standards
●​ Follows consistent naming conventions, indentation, and structure.
●​ Ensures readability and maintainability.

XP Workflow
XP follows a simple but structured workflow:

1️⃣ User writes a story → 2️⃣ Developers write test cases → 3️⃣ Code is implemented (Pair
Programming, Refactoring) → 4️⃣ Automated Tests are Run → 5️⃣ Code is Integrated &
Released → 6️⃣ Customer gives feedback

The process repeats in short iterations (1-2 weeks).

Advantages of XP
✔️ Faster Development – Continuous feedback allows quick changes.​
✔️ Fewer Bugs – Test-driven development (TDD) ensures all code is tested.​
✔️ Better Collaboration – Pair programming and on-site customers improve communication.​
✔️ Customer Satisfaction – Frequent releases ensure software meets needs.​
✔️ High Code Quality – Refactoring and coding standards keep code clean.

Challenges of XP
❌ Requires High Discipline – Teams must strictly follow XP practices.​
❌ Not Suitable for Large Teams – XP works best with small, co-located teams.​
❌ Customer Involvement Needed – A customer representative must be available daily.​
❌ Pair Programming Resistance – Some developers prefer working alone.

9. Scrum Framework
A widely used Agile project management framework with three key roles:

1.​ Product Owner: Defines system features based on customer needs.

2.​ Scrum Master: Facilitates meetings and ensures smooth workflow.
3.​ Development Team: Implements features.

Scrum Workflow:

1.​ Product Backlog (List of features to be developed).

2.​ Sprint Planning (Decide which features to develop in the next sprint).
3.​ Sprint Execution (2-4 weeks of development).
4.​ Daily Stand-up Meetings (Track progress & address issues).
5.​ Sprint Review & Retrospective (Evaluate and plan improvements).
✅ Benefits:
●​ The product is broken down into a set of manageable and understandable chunks.
●​ Flexible and adapts to changing requirements.

❌
●​ Continuous customer feedback improves product quality.​
Not suitable for projects with strict regulatory requirements.
●​ Unstable requirements do not hold up the progress.

Teamwork in Scrum
1.​ Product owner: The product owner is responsible for communicating the customer’s
perspective of the software to the development team. The product owner in consultation
with the team members defines the features of the software to be developed in the next
sprint, decides on the release dates, and also may reprioritize the required features that
are yet to be developed if necessary.

2.​ Team member: A scrum team usually consists of cross-functional team members with
expertise in areas such as quality assurance, programming, user interface design, and
testing.

3.​ Scrum master: The ‘Scrum master’ is a facilitator who arranges daily meetings, tracks
the backlog of work to be done, records decisions, measures progress against the
backlog and communicates with customers and management outside of the team.

Scrum Artifacts

1.​ Product Backlog: The Product Backlog is a prioritized list of all features,
enhancements, bug fixes, and requirements needed in the product.

Key Features:

●​ Owned by the Product Owner

●​ Constantly updated and refined (Backlog Refinement).
●​ Items (User Stories, Features, Bugs, Enhancements) are prioritized.
●​ High-priority items are detailed, low-priority items are broad.
●​ Written in the form of User stories.
●​ new features may get added to the product backlog and some features may even
get deleted.

2.​ Sprint Backlog: The Sprint Backlog contains the Product Backlog items selected for the
current sprint + a plan to complete them.
 Key Features:

●​ The team identifies one or more features (user stories) from the product backlog
●​ From sprint backlog lists, the tasks that are identified and committed by the team
to develop and complete during the ensuing sprint.

3.​ Sprint burndown chart: A Burn-Down Chart visually tracks work completed vs. work
remaining in a sprint.

Key features:
●​ The sprint burndown chart is used as a tool to visualize the progress made and
the work remaining to be undertaken on a daily basis.
●​ daily stand-up meeting.

10. Lean Software Development (LSD)

Inspired by Toyota's Lean Manufacturing, it focuses on:

●​ Eliminating waste (e.g., redundant code, unclear requirements).

●​ Empowering teams to make decisions.
●​ Rapid releases to get early market feedback.

✅ Best for startups and companies using MVP (Minimum Viable Product) strategies.
Lean development can be summarized by seven principles, very close in concept to lean
manufacturing principles:

●​ Eliminate waste
●​ Amplify learning
●​ Decide as late as possible
●​ Deliver as fast as possible
●​ Empower the team
●​ Build in integrity
●​ Optimize the whole
11. Kanban

●​ Visual workflow management using a Kanban Board.

●​ Work items move through stages: To Do → In Progress → Done.
●​ Focuses on continuous improvement.

✅ Best for teams that handle multiple ongoing tasks.

12. Scaling Agile for Large Systems

●​ Large projects involve multiple teams working on different components.
●​ Scaling Agile requires:
○​ Cross-team communication (video calls, shared documentation).
○​ Frequent integration (even though full system integration is difficult).
○​ More upfront design than traditional Agile.

✅ Best for large enterprises with distributed teams.