Software Life Cycle

Unit-01
Part-02
Software Life Cycle

· The Software Life Cycle (also known as the Software Development Life
Cycle – SDLC) is a structured process followed for developing high-quality
software in a systematic, efficient, and predictable way.

· It outlines all stages involved from the initial idea to the final retirement of the
software product.

Importance of Software Life Cycle

· Ensures structured development

· Helps manage time and cost
· Improves quality and customer satisfaction
· Enables team coordination and risk management
Phase Description Real-Time Example
A client like Amazon needs a delivery tracking
1. Requirement Gather and analyze customer needs. Understand system. Developers interview stakeholders to
Analysis what the software is supposed to do. understand features like real-time location
tracking, ETA, and delivery history.

Architects create design diagrams: front-end

Plan the architecture and components of the
2. System Design screens for customers, backend APIs, and
system based on the requirements.
database schemas for order and location data.

Software engineers code the tracking interface,

3. Implementation / Developers write the actual code according to the
APIs for updating delivery status, and integrate
Coding design documents.
GPS services.

QA team checks if the delivery status updates

Test the software to identify bugs and verify it
4. Testing correctly, test GPS accuracy, and run
meets the requirements.
performance/load tests.

The tracking feature is released as part of

Release the software for use in the real
5. Deployment Amazon’s delivery app update. Customers and
environment.
delivery agents start using it.

Users report that the app crashes when GPS is

Fix bugs, update features, and make
6. Maintenance weak. Developers release a patch to improve
improvements after deployment.
error handling and optimize battery usage.
Developing a Food Delivery App like Swiggy
· Let's map the SDLC to building such an app:

· Requirement Analysis: Swiggy wants an app to let users order food, track delivery,
make payments.

· Design: Create modules for user registration, restaurant listing, cart, checkout,
payment, and delivery tracking.

· Implementation: Developers write front-end for iOS/Android and back-end APIs

using Django or Node.js.

· Testing: Test restaurant listings, order flow, payment gateway, and delivery updates.

· Deployment: App goes live on Play Store and App Store.

· Maintenance: Add new features like contactless delivery, offers, or fix reported bugs.
 Need for a software life cycle model

· Structured Development Process-A life cycle model breaks down this

complexity into phases (e.g., analysis, design, coding, testing).
· Improved Project Planning and Management-The model offers a framework for
planning, scheduling, and tracking progress.
· Requirement Clarity-The model ensures clear requirement gathering and
documentation before development.
· Risk Management-Models like the Spiral Model include risk analysis at each
stage.
· Quality Assurance-incorporates testing phases to check quality at each level.
· Team Coordination-A model provides a common language and roadmap for all
team members.
· Adaptability to Change-Models like Agile allow frequent updates and iterations.
· Customer Satisfaction-The model ensures continuous customer feedback and
involvement.
· Identify the problem one would face, if he tries to develop a large
software product without using software engineering principles.

· Identify the two important techniques that software engineering

uses to tackle the problem of exponential growth of problem
complexity with its size.

· State five symptoms of the present software crisis.

· Identify at least four basic characteristics that differentiate a

simple program from a software product.

· Identify at least two advantages of using high-level languages

over assembly languages.

· State at least five advantages of object-oriented design

techniques.

· State at least three differences between the exploratory style

and
Model-1

Classical Waterfall Model

· The Classical Waterfall Model is one of the earliest and simplest models of
the Software Development Life Cycle (SDLC).
· It follows a linear and sequential approach where each phase must be
completed fully before the next phase begins — just like water flows
down a waterfall.
Phase Description

All requirements are collected from the

1. Requirement Gathering & Analysis
customer and documented clearly.

High-level and detailed design is created,

2. System Design specifying system architecture,
components, and data flow.
Developers write code according to the
3. Implementation (Coding) design using suitable programming
languages and tools.

All modules are integrated and tested as a

4. Integration & Testing
complete system to find and fix defects.

The final product is installed at the

5. Deployment (Installation)
customer's site and made operational.

Bug fixes, updates, and enhancements are

6. Maintenance done after deployment as per user
feedback.
Relative Effort for Phases

· Phases between feasibility study and testing

- known as development phases.
· Among all life cycle phases
- maintenance phase consumes maximum effort.
· Among development phases,
- testing phase consumes the maximum effort.
Goals of Requirements Analysis

· Collect all related data from the customer:

- analyze the collected data to clearly understand what the
customer wants,
- find out any inconsistencies and incompleteness in the
requirements,
- resolve all inconsistencies and incompleteness.
 Requirements Gathering Process
· One-on-One Interviews : These can be users who interact with the current or new
system, management, project financers or anyone else that would be involved in the
system. Contain open and close ended questions.
· Group Interviews : Important to note which issues are generally agreed upon, and
which issues differ.
· Questionnaires/Surveys : This is especially helpful when stakeholders are spread
out geographically
· User Observation: For optimal results, the consultant should schedule three
different periods of observation: low, normal, and peak times. This may prove
helpful in because the user may interact with the system differently during different
times.
· Analyzing Existing Documents: Reviewing the current process and documentation
can help the analyst understand the business, or system, and its current situation.
Requirements types
c) Design

· Design phase transforms requirements specification:

- into a form suitable for implementation in some
programming language.
· In technical terms:
- during design phase, software architecture is derived from
the SRS document.
· Two design approaches:
- a) traditional approach,
- b) object oriented approach.
a) Traditional approach – Design
Phase

· Consists of two activities:

- Structured analysis
- Structured design
1. Structured Analysis Activity
· Identify all the functions to be performed.
· Identify data flow among the functions.
· Decompose each function recursively into sub-functions.
- Identify data flow among the subfunctions as well.
· Carried out using Data flow diagrams (DFDs).
Data flow diagram example
 Traditional approach – Design Phase

2. Structured Design
After structured analysis, carry out structured design:
- architectural design (or high-level design)
- detailed design (or low-level design).
· High-level design:
- decompose the system into modules,
- represent invocation relationships among the modules.
· Detailed design:
- different modules designed in greater detail:
* data structures and algorithms for each module are designed.
 b) Object Oriented Design

· First identify various objects (real world entities) occurring in the problem:
- identify the relationships among the objects.
- For example, the objects in a pay-roll software may be:
* employees,
* managers,
* pay-roll register,
* Departments, etc.
· Object structure
- further refined to obtain the detailed design.
· OOD has several advantages:
- lower development effort,
- lower development time,
- better maintainability.
Example of object oriented design
 d) Implementation
· Purpose of implementation phase (coding and unit testing phase):
- translate software design into source code.
· During the implementation phase:
- each module of the design is coded,
- each module is unit tested
* tested independently as a stand alone unit, and debugged
- each module is documented.
· The purpose of unit testing:
- test if individual modules work correctly.

· The end product of implementation phase:

- a set of program modules that have been tested individually.
 Integration and System Testing

· Different modules are integrated in a planned manner:

- modules are almost never integrated in one shot.
- Normally integration is carried out through a number of steps.

· During each integration step,

- the partially integrated system is tested.

M1 M2

M3 M4
 e) System Testing

· After all the modules have been successfully integrated and tested:
- system testing is carried out.

· Goal of system testing:

- ensure that the developed system functions according to its requirements as
specified in the SRS document.
 f) Maintenance

· Maintenance of any software product:

- requires much more effort than the effort to develop the product itself.
- development effort to maintenance effort is typically 40:60.
· Corrective maintenance:
- Correct errors which were not discovered during the product development
phases.

· Perfective maintenance:
- Improve implementation of the system
- enhance functionalities of the system.

· Adaptive maintenance:
- Port software to a new environment
* e.g. to a new computer or to a new operating system.
Advantages of Waterfall Model
· Simple to understand and implement

· Works well for short-duration projects

· Easy to manage due to clear structure

· Well-suited for projects with fixed and clear requirements

Disadvantages of Waterfall Model

· No flexibility: Difficult to go back to a previous phase

· Not ideal for projects where requirements may change

· Late testing: Bugs found late in development are expensive to fix

· Customer doesn’t see the product until it’s fully built

Model-2

Iterative Waterfall Model

 Iterative Waterfall Model

· The Iterative Waterfall Model is an enhancement of the Classical Waterfall Model.

Unlike the classical version, where each phase is completed once and for all, the
iterative model allows feedback and revision after each phase.

· It retains the sequential nature of the waterfall model but permits iteration (going
back to previous phases) in case errors or changes are identified.

· Errors should be detected

· in the same phase in which they are introduced.
· For example:
· if a design problem is detected in the design phase itself,

· the problem can be taken care of much more easily

· than say if it is identified at the end of the integration and system testing
phase.
 Phase containment of errors

· Reason: rework must be carried out not only to the design but also to code and test
phases.

· The principle of detecting errors as close to its point of introduction as possible:

- is known as phase containment of errors.

· Iterative waterfall model is by far the most widely used model.

- Almost every other model is derived from the waterfall model.
Iterative Waterfall Model
Advantages of Iterative Waterfall Model
· Allows feedback and revision at each stage
· Reduces chances of late discovery of errors
· Better suited for realistic scenarios where requirements evolve slightly

Disadvantages of Iterative Waterfall Model

· Still not fully flexible like Agile or Spiral models
· Cost and time may increase with too many iterations
· Difficult to accommodate major requirement changes
· Testing still comes late in the cycle
Model-3

Prototyping Model
 Prototyping Model

· The Prototyping Model is a software development model where a prototype (an

early approximation or working model) of the software is built, tested, and
reworked until it meets the needs of the user.
· It allows users to visualize and give feedback on the software's functionality early
in the development process.
· This model is especially helpful when the requirements are not well understood
or are evolving.
· Before starting actual development,
- a working prototype of the system should first be built.
· A prototype is a toy implementation of a system:
- limited functional capabilities,
- low reliability,
- inefficient performance.
Prototype model
Reasons for developing a prototype

1) Illustrate to the customer:

- input data formats, messages, reports, or interactive dialogs.

2) Examine technical issues associated with product development:

- Often major design decisions depend on issues like:
* response time of a hardware controller,
* efficiency of a sorting algorithm, etc.
3)The third reason for developing a prototype is:
- it is impossible to ``get it right'' the first time,
- we must plan to throw away the first product
* if we want to develop a good product.
· Start with approximate requirements.
Prototyping Model (CONT.)

· The developed prototype is submitted to the customer for his

evaluation:
- Based on the user feedback, requirements are refined.
- This cycle continues until the user approves the prototype.
· The actual system is developed using the classical waterfall
approach.
· Requirements analysis and specification phase becomes
redundant:
- final working prototype (with all user feedbacks incorporated)
serves as an animated requirements specification.
Prototyping Model
Requirement Gathering and Analysis:
· Gather initial requirements from the client.
· Requirements may be incomplete.
Quick Design:
· Design a simple prototype based on the known requirements.
· Focus on user interface and basic functionalities.
Building Prototype:
· Develop a working prototype (may not be fully functional or efficient).
· Use rapid application development tools for quick creation.
Customer Evaluation:
· Present the prototype to the user.
· Gather feedback on usability, functionality, interface, etc.
Refining Prototype:
· Based on user feedback, modify the prototype.
· Repeat the build-evaluate-refine loop until the user is satisfied.
Product Engineering:
· Once the final requirements are clear, discard the prototype.
· Develop the full-fledged system with proper design and coding.
Testing and Deployment:
· Perform system testing, validation, and deployment of the final product.
Example-
A startup wants to develop an online food delivery app but is unsure about the exact
features and design preferences of the target users.
Requirement Gathering:- The client says: "We want users to view menus, place
orders, and track deliveries."
Exact requirements like payment integration, UI design, notifications are not clearly
defined.
Quick Design:-A basic app screen is sketched showing:Restaurant list, Menu page,
Order button
Building Prototype:-A simple mobile app prototype is built using a tool like Figma or
Flutter.
It may have mock menus and dummy data but no real backend.
Customer Evaluation:
· Users try the prototype.
· Feedback: "Add ratings to restaurants", "Allow payment through UPI", "Live
delivery tracking would be useful".
Refining Prototype:
· Incorporate feedback and refine the app UI.
· Add fake payment and tracking screens.
Product Engineering:
Developers now build the final product with actual backend, database, APIs, and
payment integration.
Testing and Deployment:
· The final app is tested thoroughly and launched on the Play Store/App Store.
Advantages of Prototyping Model
· Enhances user involvement and satisfaction.
· Reduces the chances of software failure due to misunderstood
requirements.
· Early detection of errors and scope of improvement.
· Useful in complex or UI-intensive systems.

Disadvantages
· Might increase cost and time if the prototype is over-developed.
· Clients may confuse prototype with the final system.
· Not suitable for all types of software.
Different Types of Prototypes:
· Throwaway Prototype:- This type of prototype is built quickly to
gather requirements and feedback, but it is discarded after the final
product is developed.

· Evolutionary Prototype:- This prototype evolves and is refined

iteratively, becoming the basis for the final product.
Model-4

Evolutionary Model
Evolutionary Model
· Combination of iteration and incremental.

· The Evolutionary Model is a software development approach where the system is

developed incrementally over time.

· Instead of delivering the final product in one go, software is built, improved, and
released in successive versions or stages, based on continuous feedback and
evolving requirements.

· It is suitable for large and complex systems where:

Requirements are not completely understood at the beginning.
The client needs to see progressive versions of the software.

· 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:
- reduces chances of errors in final product.
Initial Requirements Gathering
· Understand and gather basic requirements.
· High-level system architecture is designed.

Build the First Version (Core Features)

· Develop a simple working version with essential features.
· Delivered to the customer early.

Customer Evaluation and Feedback

· Customer uses and tests the system.
· Provides feedback and suggests improvements or additional features.

Refinement and Enhancement

· Based on feedback, the next improved version is developed.
· This cycle continues until the complete and satisfactory system is achieved.

Final System Deployment

· Once the system meets all customer expectations, it is finalized, tested thoroughly, and
deployed.
Evolutionary Model
Evolutionary Model

C
A A A
B B

Evolutionary model (aka successive versions or incremental model):

The system is broken down into several modules which can be incrementally implemented
and delivered.
First develop the core modules of the system.
The initial product skeleton is refined into increasing levels of capability:
by adding new functionalities in successive versions.
Successive version of the product:
functioning systems capable of performing some useful work.
A new release may include new functionality:
also existing functionality in the current release might have been enhanced.
Disadvantages of Evolutionary Model
· Poor documentation due to continuous changes

· Frequent rework may increase overall cost

· Design changes might become complex over time

· Not suitable when full system requirements are known early

Advantages of Evolutionary Model

· Early delivery of working software

· Adaptable to changing requirements

· Users can provide continuous feedback

· Risk of failure is reduced due to incremental validation

· Suitable for AI, cloud-based, or user-driven apps

Evolutionary Model with Iteration
Evolutionary Development in Practice for an e-learning platform: Step 1: Initial Version
· The company launches Version 1 with:
Basic user registration, Course listing, Video playback
Step 2: Feedback from Users
Students ask for:, Download feature, Quizzes and certificates, Discussion forum
Step 3: Develop Version 2
Add:, Quiz support, Basic certification system, In-app announcements
Step 4: More Feedback
Users now ask for:, Live class integration, Mobile app, Payment and subscription system
Step 5: Version 3 and Beyond
Implement:, Zoom/Google Meet API for live sessions
Android/iOS apps, Secure payment gateway
Final System
Fully functional e-learning platform with:, Multiple roles (students, teachers, admins),
Interactive content, forums, certificates, mobile support, etc.
This entire cycle reflects evolutionary development — the system "evolved" based on real-
world use and feedback.
Model-5

Spiral Model
 Spiral Model

• The Spiral Model is a risk-driven software development process model that

combines elements of both design and prototyping in stages.

• It is designed to manage large, complex, and high-risk projects.

• Introduced by Barry Boehm in 1986, the model represents the software

development process as a spiral, where each loop (or phase) focuses on risk
assessment and mitigation.
Phase Description

Requirements are gathered from stakeholders.

1. Planning Phase Objectives, constraints, and alternatives are
identified.

Potential risks (technical, schedule, cost) are

2. Risk Analysis identified. Prototypes may be created to
clarify or reduce risks.

Actual development and testing of the

3. Engineering (Development & Testing)
identified features take place.

Stakeholders evaluate the product and provide

4. Evaluation (Customer Feedback) feedback. This helps determine whether to
proceed to the next phase.
 First Quadrant)
· Identify objectives of the phase,
· Examine the risks associated with these objectives.
- Risk:
* any adverse circumstance that might hamper successful completion of a software
project.
· Find alternate solutions possible.
2nd Quadrant
· For each identified project risk,
- a detailed analysis is carried out.

· Steps are taken to reduce the risk.

· For example, if there is a risk that the requirements are inappropriate:

- a prototype system may be developed.
Spiral Model (CONT.)

· Development and Validation (Third quadrant):

- develop and validate the next level of the product.

· Review and Planning (Fourth quadrant):

- review the results achieved so far with the customer and plan the next iteration
around the spiral.

· With each iteration around the spiral:

- progressively more complete version of the software gets built.
Risks associated
Complexity in Risk Assessment
· The Spiral Model relies heavily on accurate risk analysis in each phase.
· If the risk assessment is incorrect or incomplete, the entire project can go off-
track.
High Cost and Time
Due to its iterative nature and continuous evaluation, the Spiral Model can be
expensive and time-consuming.
Requires Skilled Professionals
Needs experienced developers, designers, and risk managers.
Risk of Endless Spiral (Project Overrun)
Without strict control and management, the project may enter a loop of repeated
refinements and never reach completion.
Frequent Changes Can Disrupt Planning
As the model encourages changes and refinements, frequent changes in
requirements can destabilize planning and budgeting.
1st Spiral Loop – Concept and Planning
· Stakeholders define basic requirements: login, balance check, and transaction view.
· Initial planning is done for these features.
· Risks: Security concerns, data privacy issues.
2nd Spiral Loop – Prototype & Risk Handling
· A prototype login module is created.
· Risk: Is two-factor authentication needed?
· Feedback is collected; customers want OTP via SMS.
· Decision made to integrate OTP service provider.
3rd Spiral Loop – Develop Core Modules
· Core modules: login, view balance, transaction history developed.
· Unit and integration testing are done.
· Risk: System scalability for high traffic.
· Load testing is performed.
4th Spiral Loop – Add Fund Transfer Features
· Add NEFT, IMPS, RTGS fund transfer options.
· Security enhancements implemented (e.g., transaction PIN, session timeout).
· Risk: Handling failed transactions & rollback.
· Testing includes failure simulation and response handling.
5th Spiral Loop – Final Integration and Deployment
· Full system is integrated.
· Final testing and user feedback.
· Training provided to bank staff.
Advantages of Spiral Model
· Risk Management: Identifies and resolves risks early.

· Flexibility: Can incorporate changes at any stage.

· Prototyping: Helps users visualize and refine requirements.

· Customer Involvement: Continuous feedback improves quality.

Disadvantages
Costly: Suitable for large, expensive projects only.

Complex: Requires expertise in risk assessment.

Time-Consuming: Multiple iterations may increase timeline.

 Circumstances to use spiral model

· The spiral model is called a meta model since it encompasses all

other life cycle models.

· Risk handling is inherently built into this model.

· The spiral model is suitable for development of technically

challenging software products that are prone to several kinds of
risks.

· However, this model is much more complex than the other models –
this is probably a factor deterring its use in ordinary projects.
Model-5

Rapid Application
Development Model
 RAD
Rapid Application Development (RAD) is a software development model that
emphasizes:
· Quick development and delivery of high-quality software
· Rapid prototyping
· Frequent user feedback
· Iterative development
· Instead of planning and building the software as a single monolithic process (like
the Waterfall model), RAD breaks the project into smaller, manageable parts that
are developed in parallel and refined based on continuous user input.
· It is a type of incremental model.
· In RAD model the components or functions are developed in parallel as if they
were mini projects.
· The developments are time boxed, delivered and then assembled into a working
prototype.
· This can quickly give the customer something to see and use and to provide
feedback regarding the delivery and their requirements.
 RAD

Feature Description
Develop functional prototypes
Prototyping
quickly and iterate
Continuous customer feedback
User Involvement
throughout the process
Divide system into modules, built by
Modularization
small teams
Evolve prototypes through multiple
Iterative Process
cycles
Each phase has strict time limits to
Time-boxed Phases
ensure speed
Requirement Planning Phase:
· Stakeholders define business needs, scope, and goals.
· Team collects broad requirements (not in deep detail).
User Design Phase:
· Users work with developers to create system mockups/prototypes.
· Heavy use of tools like CASE tools, screen generators, etc.
· Frequent user-developer communication.
Construction Phase:
· Actual application coding is done quickly.
· Uses code generated during prototyping.
· Integration and system testing performed.
Cutover Phase:
· Final implementation, testing, training, and deployment.
· Move to production environment.
When to Use RAD:
· When project needs to be delivered quickly.
· When requirements are clear and well-understood.
· When users are available for constant interaction.
· When the system can be modularized.
Advantages
Fast development and delivery
High user involvement
Flexible to changes
Encourages reusable components
Better risk management
Disadvantages
Not suitable for large, complex systems
Requires frequent user involvement
Difficult if requirements keep changing
Requires skilled developers and designers
Poor documentation if not managed carefully
Model-6

V shaped Model
 V-Shaped Model
· It is an extension for waterfall model, Instead of moving down in a linear
way, the process steps are bent upwards after the coding phase, to form
the typical V shape.

· The major difference between v-shaped model and waterfall model is the
early test planning in v-shaped model.
· The usage
- Software requirements clearly defined and known
- Software development technologies and tools is well-
known

· Advantages
- Simple and easy to use.
- Each phase has specific deliverables.
- Higher chance of success over the waterfall model due to the
development of test plans early on during the life cycle.
- Works well for where requirements are easily understood.
- Verification and validation of the product in early stages of
product development
Disadvantages

· Very inflexible, like the waterfall model.

· Little flexibility and adjusting scope is difficult and expensive.

· Software is developed during the implementation phase, so no early

prototypes of the software are produced.

· Model doesn’t provide a clear path for problems found during

testing phases.

· Costly and required more time, in addition to detailed plan

Model-7

Agile Model
 Agile Model

· Combination of iterative and incremental process models with focus on

process adaptability and customer satisfaction by rapid delivery of working
software product.
· Agile Methods break the product into small incremental builds.

· These builds are provided in iterations. Each iteration typically lasts from
about one to three weeks.

· Every iteration involves cross functional teams working simultaneously on

various areas like planning, requirements analysis, design, coding, unit
testing, and acceptance testing.

· At the end of the iteration a working product is displayed to the customer

and important stakeholders.
Feature Description

Development occurs in repeated cycles

Iterative and Incremental
with added functionality in each iteration.

Frequent communication with the

Customer Collaboration customer ensures the product meets real
needs.
Changes are welcome even late in
Embraces Change
development.
The focus is on delivering a working
Working Software
product in each iteration.
Developers, testers, designers, and users
Cross-functional Teams
work together.
Each sprint has a fixed duration (e.g., 2
Time-boxed Sprints
weeks).
· Requirement Gathering (Just enough for the first sprint)

· Planning (Sprint planning meeting)

· Designing (Basic design for current sprint)

· Coding (Small features or modules)

· Testing (Unit + Integration + User Testing)

· Review (Sprint review and feedback)

· Retrospective (Team discussion on what went well/needs improvement)

· Next Sprint (Refined planning with new insights)

Advantage Explanation
Customer Satisfaction Continuous delivery and involvement of stakeholders
Flexibility to Change Easy to accommodate changes in requirements
Functioning software is delivered early and
Early & Frequent Delivery
frequently
Frequent testing and code reviews improve product
Improved Quality
quality
Enhances communication among team members and
Team Collaboration
clients
Limitation Description

Less Predictability Not ideal for fixed-scope and fixed-budget projects

Requires Skilled Team Team must be well-versed in agile principles

Not Ideal for All Projects Large, safety-critical systems may not fit agile well

Client Availability Requires active and frequent client involvement

Extreme programming
· Extreme Programming (XP) is an Agile software development methodology designed
to improve software quality and responsiveness to changing customer requirements.
· It is particularly suited for dynamic projects where requirements evolve frequently.
· Technical excellence
· Customer satisfaction
· Frequent releases
· Simplicity in design
· Team collaboration

Practice Description
Code is integrated and tested frequently
Continuous Integration
(several times a day).

Deliver working software frequently (weekly

Small Releases
or even daily).

Sustainable Pace Work at a steady pace—avoid overtime.

XP utilizes specific practices such as:

· Pair Programming: Two programmers work together on the same code, enhancing code
quality and knowledge sharing.
· Test-Driven Development (TDD): Writing tests before code, driving development and
ensuring code correctness.
· Continuous Integration: Integrating code changes frequently and automatically, allowing
for early detection of integration issues.
· Simple Design: Focusing on simplicity in design and code, making it easier to understand
and maintain.
· Planning Game: Collaboratively planning work in short iterations, allowing for flexibility
and adaptation to changing requirements.
· Small Releases: Delivering software in small, incremental releases, providing faster
feedback and quicker value to customers.
· Refactoring: Continuously improving the code structure and design without changing
functionality, ensuring maintainability and quality.
Life Cycle of XP
Benefits of Extreme Programming
· High Quality Code-TDD + Refactoring + Pair Programming improves reliability.
· Rapid Delivery-Frequent small releases provide real value early.
· Customer Satisfaction-Constant feedback ensures product meets user needs.
· Flexibility-Easy to adapt to changing requirements.
· Strong Collaboration- Developers, testers, and customers work closely together.

Limitation Explanation

Teams must strictly follow practices like TDD

Requires High Discipline
and CI.

Not for Large Teams XP works best for small, co-located teams.

Needs full-time access to a customer

Customer Availability
representative.

Difficult to Implement in Legacy Systems XP is best for greenfield (new) projects.

Scrum
· Scrum is a lightweight, iterative and incremental framework used to manage
product development.
· It’s structured around small, cross-functional teams who deliver working
software in short, time-boxed iterations called Sprints (typically 2-4 weeks).
Components-
· Product Owner: Represents the stakeholders and users, responsible for
defining and prioritizing the product backlog (a prioritized list of features).
· Scrum Master: Facilitates the Scrum process, removes impediments, and
ensures the team adheres to Scrum principles. They are a servant-leader, not
a manager.
· Development Team: A self-organizing and cross-functional group
responsible for delivering increments of potentially shippable product.
Scrum Artifacts
Product Backlog
· A prioritized list of features, enhancements, bug fixes, etc.
· Managed by the Product Owner.
Sprint Backlog
· Subset of Product Backlog items selected for the current sprint, along with a plan.
Increment
· The usable end product delivered at the end of each sprint.
 Scrum Events

Sprint
A time-boxed iteration (typically 2–4 weeks) during which a usable product
increment is developed.
Sprint Planning
Meeting where team selects what work to do in the sprint.
Daily Scrum (Daily Stand-up)
A 15-minute daily meeting for team members to update on progress and blockers.
Sprint Review
Demonstration of the increment to stakeholders at the end of the sprint.
Sprint Retrospective
Team reflects on the sprint and discusses how to improve in the next one.