|GRADE 12 ICT| 7.
SYSTEM ANALYSIS AND DESIGN
Software Development Life Cycle
2. Iterative and Incremental Model
This model combines the concepts of iteration (repetition of a process) and incremental development
(small parts are developed and added over time). The system evolves through repeated cycles, allowing
refinement at each iteration.
|SASHIKA CHANDRASENA|
|GRADE 12 ICT| 7. SYSTEM ANALYSIS AND DESIGN
Iterative Model
The Iterative Model begins with a basic version of the software that implements a subset of the required
features. This initial version is then repeatedly enhanced through cycles (iterations), where feedback is
incorporated, design changes are made, and additional functionality is added.
Each iteration results in an improved version of the software until the final system is complete.
Incremental Model
The Incremental Model is a software development approach where the overall system is divided into
multiple standalone modules (increments). Each increment goes through the full development cycle—
requirements, design, implementation, and testing—and delivers a functional component of the final
product.
Each new increment adds functionality to the existing system. This continues until the complete system
is developed.
“Build some of it before you build all of it” summarizes the philosophy of this model.
|SASHIKA CHANDRASENA|
|GRADE 12 ICT| 7. SYSTEM ANALYSIS AND DESIGN
Iterative and Incremental Model
The Iterative and Incremental Model combines the strengths of both approaches. The system is
developed through repeated cycles (iteration) and built in smaller portions (incrementally).
In each iteration, a functional component is developed, tested, and refined based on feedback. Over
time, these increments evolve into the final, complete system.
Major Phases (repeated per iteration):
1. Planning
2. Requirements
3. Design
4. Implementation
5. Testing
6. Evaluation
When to Use It:
• When requirements are not fully known upfront
• For large and complex projects
• When early partial product delivery is valuable
When Not to Use It:
• In very short projects where overhead of iteration isn’t justified
• Where rigid structure or fixed scope is mandated
Special Highlights:
• Allows for user feedback at each iteration
• Reduces risk by addressing high-risk features early
• More flexible and adaptive than Waterfall
|SASHIKA CHANDRASENA|
|GRADE 12 ICT| 7. SYSTEM ANALYSIS AND DESIGN
|SASHIKA CHANDRASENA|
|GRADE 12 ICT| 7. SYSTEM ANALYSIS AND DESIGN
3. Prototype Model
it is:
The Prototype Model involves creating a working model (prototype) of the software early in the
development process to better understand requirements and expectations.
Types of Prototyping
1. Throwaway (Rapid) Prototyping
Also known as close-ended prototyping, this involves developing a prototype quickly with
minimal effort and limited requirement analysis. Once the requirements are better understood,
the prototype is discarded, and the actual system is developed from scratch based on the
improved understanding.
2. Evolutionary Prototyping
In this approach, a functional core is developed initially, and further features are added over
time. Unlike throwaway prototypes, the initial version evolves into the final system. It’s
especially useful when requirements are not fully known at the outset.
3. Incremental Prototyping
This involves building multiple functional prototypes representing various components or
modules of the system. These prototypes are then integrated into a single complete system. It
allows for parallel development and continuous integration.
Major Phases:
1. Requirements Gathering
2. Quick Design
3. Prototype Building
4. Prototype Evaluation
5. Refinement
6. Final Product Development
|SASHIKA CHANDRASENA|
|GRADE 12 ICT| 7. SYSTEM ANALYSIS AND DESIGN
When to Use It:
• When user requirements are unclear or not well documented
• In systems with high user interaction (e.g., UI/UX-driven systems)
• For proof-of-concept development
When Not to Use It:
• When requirements are well-understood
• For projects with tight budgets and timelines
• When end-users are not available for feedback
Special Highlights:
• Helps clarify requirements early
• Encourages user involvement
• Risk of excessive iteration and scope creep if not managed properly
Advantages of the Prototyping Model:
• Helps identify missing or unclear requirements early
• Reduces the risk of complete system failure
• Encourages user involvement and improves customer satisfaction
• Supports innovation and experimentation in design
• Provides early training for users
• Improves communication between developers and stakeholders
• Helps refine technical and usability aspects
• Acts as a basis for deriving system specifications
• May reduce development time through early validation
|SASHIKA CHANDRASENA|
|GRADE 12 ICT| 7. SYSTEM ANALYSIS AND DESIGN
Disadvantages of the Prototyping Model:
• Can be time-consuming and resource-intensive
• The prototype may be mistaken as the final system, creating unrealistic expectations
• Frequent changes may cause scope creep
• Poor documentation due to ongoing changes
• Users may become overly dependent on prototypes
• Developers may prioritize speed over quality, resulting in poor solutions
• Customers may lose interest if early versions are unsatisfactory
|SASHIKA CHANDRASENA|
|GRADE 12 ICT| 7. SYSTEM ANALYSIS AND DESIGN
4. Rapid Application Development
Rapid Application Development (RAD) is a software development methodology that prioritizes rapid
prototyping, iterative delivery, and user feedback over strict planning and extensive documentation. It is
designed to accelerate the software development lifecycle, enabling teams to build functional
applications in significantly shorter timeframes than traditional models like the Waterfall model. RAD
promotes adaptability, user involvement, and the reuse of software components.
Key Principles of RAD
• Iterative Development: Projects are divided into small, manageable iterations, allowing
continuous refinement and feedback incorporation.
• Prototyping: Functional prototypes are created early and continuously refined based on user
feedback.
• User Involvement: Stakeholders actively participate throughout the development process to
ensure the software meets user needs.
• Reusability: RAD encourages the use of reusable software components and pre-built modules to
speed up development.
• Flexibility and Adaptation: Changes in requirements can be integrated at any stage with
minimal disruption.
Phases of the RAD Model
1. Requirements Planning
Preliminary discussions are held to define the project scope and high-level objectives. Detailed
documentation is minimized.
2. User Design
Users and developers collaborate closely to design and prototype the system’s interface and
features. Feedback loops are frequent and rapid.
3. Rapid Construction
Prototypes are developed into fully functional applications using iterative coding and
component reuse. Ongoing feedback is integrated.
4. Cutover (Deployment)
Final testing, user training, data conversion, and deployment are completed. The product is
moved to production.
|SASHIKA CHANDRASENA|
|GRADE 12 ICT| 7. SYSTEM ANALYSIS AND DESIGN
When to Use RAD
RAD is particularly suitable for:
• Projects with tight deadlines
• Applications where user experience (UX) is critical
• Projects with unclear or evolving requirements
• Web, mobile, or business applications that benefit from rapid feedback loops
When Not to Use RAD
1. Large, Complex Systems with Rigid Requirements
• Examples: Banking systems, aerospace software, medical devices
• Reason: These projects require strict compliance, thorough documentation, and
exhaustive validation, which RAD does not emphasize.
2. Fixed-Requirement Projects
• Examples: Government contracts, legacy migrations
• Reason: RAD’s adaptive nature clashes with environments where requirements are fixed
from the start.
3. Low User Involvement
• Examples: Internal tools with unavailable stakeholders
• Reason: RAD relies heavily on continuous feedback; absence of active users leads to
misaligned outputs.
4. Limited Budgets with No Flexibility
• Examples: Small businesses with one-time budgets
• Reason: Iterative changes can increase development costs if not controlled.
5. High-Risk, Safety-Critical Systems
• Examples: Nuclear power plant software, defense systems
• Reason: The RAD model’s emphasis on speed and iteration may compromise reliability
and safety.
6. Inexperienced Teams
• Examples: Teams unfamiliar with prototyping or rapid development
|SASHIKA CHANDRASENA|
|GRADE 12 ICT| 7. SYSTEM ANALYSIS AND DESIGN
Advantages of RAD
• Accelerated delivery of working software
• Enhanced user satisfaction through continuous feedback
• Early detection and resolution of issues
• Flexible adaptation to changing requirements
• Encourages active collaboration and user involvement
Disadvantages of RAD
• Requires continuous user involvement, which may not always be feasible
• Not suitable for large, complex, or highly regulated systems
• Risk of scope creep due to flexible requirement changes
• May produce lower-quality code if prototyping is rushed
• Potential for inadequate documentation
|SASHIKA CHANDRASENA|
|GRADE 12 ICT| 7. SYSTEM ANALYSIS AND DESIGN
5. Spiral Model
The Spiral Model is a risk-driven process model that combines aspects of Waterfall and iterative and
incremental development.
It focuses on early risk identification and mitigation through repeated cycles (spirals), making it ideal for
large, complex, and high-risk projects.
Key Characteristics of the Spiral Model
▪ Iterative & Incremental – The project progresses in loops (spirals), each refining the product.
▪ Risk-Driven – Each spiral begins with risk analysis to avoid costly failures.
▪ Flexible & Adaptive – Changes can be incorporated at any stage.
▪ Hybrid Approach – Combines Waterfall (planning) + Prototyping (experimentation) + iterative
and incremental.
|SASHIKA CHANDRASENA|
|GRADE 12 ICT| 7. SYSTEM ANALYSIS AND DESIGN
Phases of the Spiral Model (Each Spiral Cycle)
Each cycle of the Spiral Model consists of four major phases, which are repeated iteratively until the
software is fully developed:
1. Planning & Requirements Gathering
• Purpose: Identify the objectives, explore alternatives, and define system requirements (at a high
or detailed level depending on the iteration).
• Activities:
• Define system functionality, performance, constraints.
• Identify stakeholder needs and business goals.
• Example: For an e-commerce application, identify core features such as shopping cart, user
login, product listing, and payment integration.
2. Risk Analysis & Mitigation
• Purpose: Evaluate potential project risks (technical, operational, cost, time) and devise
mitigation strategies.
• Activities:
• Perform risk identification and prioritization.
• Develop prototypes or simulations to address high-risk areas.
• Example: Risk: Payment gateway might not integrate with the backend.
• Mitigation: Build a quick prototype to test early integration.
3. Design, Development & Testing
• Purpose: Design and implement the product features identified for this iteration.
• Activities:
• Software design, coding, unit testing, integration testing.
• Techniques from models like Waterfall or Agile can be embedded here depending on the
team’s context.
• Output: A functional version or component of the system.
|SASHIKA CHANDRASENA|
|GRADE 12 ICT| 7. SYSTEM ANALYSIS AND DESIGN
4. Evaluation & Planning for the Next Spiral
• Purpose: Review the current cycle with stakeholders and decide on the next course of action.
• Activities:
• Conduct user evaluation, stakeholder review, and technical assessments.
• Update plans and requirements for the next cycle.
• Decide whether to proceed with the next spiral, modify scope, or terminate the project.
• Example: Stakeholders test the current build of the e-commerce cart. Feedback suggests UI
changes → planned for next cycle.
When to Use the Spiral Model
1. High-Risk Projects
Examples: Military defense systems, aerospace control software, medical imaging systems.
Why: The Spiral Model's built-in risk analysis at each iteration helps identify and mitigate critical
risks early in the development process.
2. Large and Complex Systems
Examples: Enterprise-level ERP systems, AI-driven platforms, national e-governance systems.
Why: The model breaks development into manageable iterations, making it suitable for
handling scale and complexity.
3. Projects with Unclear or Evolving Requirements
Examples: R&D-focused software, innovative tech startups, emerging technologies.
Why: The iterative and exploratory nature of the model supports progressive refinement of
requirements.
4. Long-Term Projects with Flexible Budgets and Timelines
Examples: Government infrastructure IT systems, defense procurement projects.
Why: The model allows for ongoing changes and refinements, trading speed for reliability and
adaptability.
5. Critical Systems Where Failure Is Not Acceptable
Examples: Nuclear control systems, autonomous vehicle algorithms, air traffic control software.
Why: The model’s risk-driven approach ensures reliability, safety, and thorough validation.
|SASHIKA CHANDRASENA|
|GRADE 12 ICT| 7. SYSTEM ANALYSIS AND DESIGN
When Not to Use the Spiral Model
1. Small or Low-Complexity Projects
Examples: Static websites, basic inventory apps.
Why: The Spiral Model introduces unnecessary overhead—simpler models like Waterfall or
Agile are more efficient.
2. Tight Budgets and Rigid Deadlines
Examples: MVPs for startups, quick prototypes for clients.
Why: Spiral’s emphasis on repeated risk analysis and prototyping consumes more time and
resources.
3. Well-Defined and Stable Requirements
Examples: Data entry systems, basic CRUD applications.
Why: In projects with fixed requirements, traditional models (like Waterfall) are more time-
efficient.
4. Lack of Experienced Risk Management or Technical Teams
Examples: Academic student projects, new development teams.
Why: Spiral requires experienced analysts and developers to properly identify and manage risks.
5. Fixed-Scope, Fixed-Contract Projects
Examples: Government tenders with strict deliverables and deadlines.
Why: Spiral assumes flexibility for change, which is often incompatible with fixed-contract
constraints.
|SASHIKA CHANDRASENA|
|GRADE 12 ICT| 7. SYSTEM ANALYSIS AND DESIGN
6. Agile Software Development
Agile is an iterative and incremental approach to software development that emphasizes flexibility,
collaboration, customer feedback, and rapid delivery of functional software. Unlike traditional models
such as the Waterfall model, Agile focuses on delivering working software in small, manageable
increments called sprints, rather than as a single final release.
In general, agility is defined as
"The ability to both create and respond to change in order to profit in a turbulent environment “
Changes in Requirements
Changes in Design, Implementation
Changes in Technology
Changes in Team
Changes in users/client contacts
Core Principles of Agile (Based on the Agile Manifesto)
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a fixed plan
These principles prioritize adaptability, teamwork, and continuous improvement throughout the
development lifecycle.
|SASHIKA CHANDRASENA|
|GRADE 12 ICT| 7. SYSTEM ANALYSIS AND DESIGN
The Agile Development Process
Agile development follows iterative cycles, commonly referred to as sprints, typically lasting between 1
to 4 weeks. The typical Agile process includes:
1. Product Backlog Creation
A prioritized list of features, bug fixes, and enhancements, written as user stories.
2. Sprint Planning
The team selects a set of backlog items to complete during the upcoming sprint.
3. Daily Stand-ups (Scrum Meetings)
Short (usually 15-minute) team meetings to report progress, highlight blockers, and coordinate
efforts.
4. Development & Testing
Features are designed, implemented, and tested continuously. Testing is integrated throughout
the development cycle.
5. Sprint Review (Demonstration)
Completed work is demonstrated to stakeholders to gather feedback.
6. Sprint Retrospective
The team reflects on the sprint and identifies improvements for the next cycle.
7. Next Sprint Begins
The process repeats until the final product meets the required specifications.
|SASHIKA CHANDRASENA|
|GRADE 12 ICT| 7. SYSTEM ANALYSIS AND DESIGN
When to Use Agile
• Requirements are uncertain or frequently changing.
• Projects demand quick, incremental delivery.
• Close collaboration with stakeholders is essential.
• Teams are cross-functional and communicate regularly.
Examples:
• Mobile applications (e.g., WhatsApp, Instagram)
• SaaS platforms (e.g., Trello, Slack)
• MVPs for startups
When Not to Use Agile
• Projects with strict regulatory or compliance requirements (e.g., medical, aerospace, defense).
• Fixed-scope, fixed-budget contracts, where flexibility is limited.
• Teams that are not experienced in Agile practices or lack collaborative culture.
• Large, poorly coordinated teams, where Agile ceremonies and feedback loops become
inefficient.
|SASHIKA CHANDRASENA|