DEPARTMENT OF INFORMATION TECHNOLOGY

BIT2150 2024/2025
Topic 3: System Development Life Cycle (SDLC)
Expected Learning Outcomes
By the end of the topic, the student should be able to:

1. Understand and explain each phase of the SDLC, from planning to maintenance, and its
significance in system development.
2. Identify the roles of various stakeholders (users, developers, testers, etc.) in each phase of the
SDLC.
3. Apply SDLC phases to real-world scenarios, understanding the importance of each phase in
delivering successful systems.
4. Articulate the core principles of system development, such as user-centered design, flexibility,
and iterative development, and explain their importance in modern system design.
5. Apply the principle of risk management to foresee potential system issues and implement
mitigation strategies.
6. Analyze how quality assurance throughout the SDLC ensures the delivery of high-quality,
bugfree systems.
7. Demonstrate the ability to link information systems to core business needs to enhance
operations, decision-making, and competitive advantage.
8. Develop strategies for aligning system features with specific business goals and ensuring
regulatory compliance.
9. Evaluate information systems' ability to provide competitive advantages, enabling businesses
to differentiate themselves in the market.
10. Understand and explain the critical role that system analysis plays in ensuring a clear
understanding of user requirements and system objectives.
11. Apply design principles to ensure system scalability, flexibility, and cost-efficiency.
12. Analyze the role of effective system analysis and design in reducing risk, improving user
satisfaction, and ensuring long-term success of the system.

Introduction
The System Development Life Cycle (SDLC) is a structured process used for planning,
designing, developing, testing, deploying, and maintaining information systems. It ensures that
systems are developed efficiently, meet their objectives, and maintain high quality throughout their
lifecycle. The SDLC consists of several key phases—planning, analysis, design, development,
testing, deployment, and maintenance—each playing a vital role in ensuring that the final system
is aligned with business needs and user requirements. By following this systematic approach,
organizations can reduce risks, manage resources effectively, and ensure project success.

Page 1 of 116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
Phases of SDLC
Planning Phase
The Planning phase is the foundational stage of the System Development Life Cycle (SDLC). It
helps to establish the overall vision of the system, define its goals, allocate necessary resources,
and create a timeline for its development. This phase ensures that the project has a clear direction
and that all stakeholders are aligned on the purpose and expected outcomes.
Defining the System Scope
The system scope defines the boundaries of the project, outlining what will be included in the
system and what will not. Defining the scope early helps to prevent "scope creep," where additional
features or changes are added during development, potentially leading to delays and increased
costs.

Activities
• Identify the business problem or opportunity that the system will address.
• Define the high-level functionalities the system will provide.
• Determine which departments, users, and processes within the organization the system will
impact.

Example: A retail company plans to implement an e-commerce platform. During the planning
phase, they define the scope to include building an online store that allows customers to view
products, place orders, and pay online. The scope specifically excludes warehouse and logistics
management, which will be handled by a different system.
Setting System Goals and Objectives
System goals and objectives describe what the system is expected to achieve. These goals should
be SMART: specific, measurable, achievable, relevant, and time-bound. Clearly defining the goals
helps the project team stay focused on delivering business value.

Activities
• Define business objectives such as increasing revenue, improving customer service, or
streamlining operations.
• Identify system-specific objectives, such as enhancing user experience or improving system
performance.

Example: The e-commerce platform’s goals are to:

• Increase customer access by providing an online shopping option.

• Integrate multiple payment gateways, such as credit cards and mobile payments.
Enhance customer service through real-time order tracking and online support.

Budgeting and Resource Allocation

Page 2 of 116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
Budgeting ensures that the project is financially viable and that the necessary resources (human,
technical, financial) are allocated to complete the project on time. A well-planned budget accounts
for development, hardware, software, staff, training, and ongoing maintenance.

Activities
• Estimate the cost of system development, including labor, technology, and tools.
• Identify necessary hardware and software purchases. Allocate resources, such as
hiring additional staff or outsourcing certain tasks.

Example: The retail company estimates the cost of developing the e-commerce platform at
$100,000. This includes hosting services, development tools, third-party integrations (such as
payment gateways), and marketing efforts. They also allocate funds for promoting the new online
store.

Creating the Project Timeline

A timeline provides an overview of when each phase of the system development process will
occur. It ensures that the project stays on track and that stakeholders are aware of key deadlines.
The timeline should be realistic and account for potential obstacles or delays.

Activities
• Break the project into phases (e.g., system analysis, design, development, testing, deployment).
• Estimate the duration of each phase. Set milestone dates to monitor progress.

Example: For the e-commerce platform, the project timeline is set to 12 months, with the
following milestones: System analysis: 1 month
• System design: 2 months
• Development: 5 months
• Testing: 2 months
• Deployment: 1 month
• Ongoing maintenance and support The platform is expected to be live by the end of the 12th
month, just before the holiday shopping season.

Identifying Stakeholders
Stakeholders are individuals or groups who have an interest in the development and use of the
system. Engaging stakeholders early in the planning phase ensures that their needs and
expectations are understood and met throughout the project.

Activities
• Identify key stakeholders and their roles in the project.

Page 3 of 116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
• Establish communication channels to maintain regular contact. Gather initial
feedback on system requirements and expectations.

Example: In the e-commerce project, stakeholders include:

• Business owners who want increased sales.
• Customers who will use the platform for online shopping.
• IT and development teams responsible for building and maintaining the system.
• Marketing teams tasked with promoting the platform. Customer service teams who
will support users of the platform.

Conducting Feasibility Studies

Feasibility studies assess whether the project can realistically be completed from different
perspectives: technical, financial, and operational. The feasibility study helps ensure the project is
achievable within the organization’s current structure and resources.

Activities
• Technical feasibility: Can the system be developed with the available technology and
expertise?
• Financial feasibility: Is the project affordable? Will it provide a return on investment (ROI)?
Operational feasibility: Will the system fit into the organization’s existing processes?

Example: The retail company conducts a feasibility study and finds that:
• Technically, the system can be built using existing tools and platforms.
• Financially, the project fits within the budget, and an ROI is expected within two years due to
increased sales.
• Operationally, the system will fit well with the company’s workflow, but additional customer
service staff will need to be hired.

Risk Assessment
Every project carries risks, and identifying them early helps create mitigation strategies to
minimize their impact. Risk assessment ensures the project team is prepared for challenges and
can manage them effectively.

Activities
• Identify potential risks, such as budget overruns, technical difficulties, or timeline delays.
• Develop mitigation plans for each identified risk. Monitor risks throughout the project
and adjust strategies as needed.

Example: For the e-commerce platform, potential risks include:

Page 4 of 116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
• Technical risk: Difficulty integrating multiple payment gateways. Mitigation: Consult with
payment experts early in the project.
• Budget risk: Costs may exceed the budget. Mitigation: Set aside a 10% contingency fund for
unforeseen expenses.
• Timeline risk: Delays in the development phase. Mitigation: Hire additional developers if
necessary to meet deadlines.

Summary of the Planning Phase

Aspect Description Example
Defining the Scope Establishes the system An e-commerce platform that includes
boundaries and what it will online payments but excludes warehouse
and won’t include. and logistics management.
Setting Goals & Outlines business and Increasing customer access with an online
Objectives system-specific goals, which shopping platform and integrating
should be SMART. multiple payment methods.
Budgeting & Estimating financial and Allocating a $100,000 budget for
Resource human resources needed for development, third-party integrations, and
Allocation the project. marketing for an e-commerce site.
Creating a Developing a project Setting a 12-month timeline for the
Timeline timeline with phases and ecommerce platform with key milestones
milestones. for system analysis, design, and testing.
Identifying Identifying and involving key Engaging business owners, IT staff,
Stakeholders stakeholders in the project customers, and marketing teams for
early on. feedback and guidance.
Feasibility Studies Assessing technical, Determining if the e-commerce platform is
financial, and operational technically possible, financially viable, and
feasibility of the project. operationally sustainable.
Risk Assessment Identifying and planning for Recognizing potential budget overruns and
potential risks during the creating a contingency plan.
project.

The Planning phase is critical for laying the groundwork for a successful project. It ensures the
project has clear objectives, well-defined resources, a structured timeline, and is ready to move
forward to the next stages of the SDLC. Proper planning reduces the risk of failure and helps ensure
that the project is completed on time, within budget, and meets its intended goals.
System Analysis Phase
The System Analysis phase is essential in the System Development Life Cycle (SDLC). It ensures
that all the necessary requirements for the system are clearly understood, documented, and aligned
with the needs of users, stakeholders, and the organization. This phase guarantees that the system’s

Page 5 of 116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
functionality and performance are designed to meet expectations, making it a crucial foundation
for the subsequent design and development phases.
Gathering Requirements
The first step in system analysis is to gather detailed information from all relevant stakeholders.
This helps ensure that the system addresses the needs and expectations of those who will use or
benefit from it. Key Activities
• Conducting interviews with key stakeholders such as department heads, end-users,
and technical staff.
• Using surveys and questionnaires to collect feedback from end-users.
Analyzing existing systems to find gaps and areas of improvement.

Example: For a university registration system, interviews with the registrar’s office and IT
department help understand the need to track student enrollment, while surveys of students
highlight the importance of a user-friendly course registration interface and simplified payment
options.
Defining Functional Requirements
Functional requirements describe the system's intended features and operations. They focus on
what the system will do and how users will interact with it.

Key Activities
• Identifying key system functions such as data entry, processing, and reporting.
• Specifying user roles and access permissions (e.g., student, administrator, faculty).
• Developing use cases or scenarios that describe how users will interact with the system.

Example: For a university registration system, functional requirements include:

• Allowing students to register for courses.
• Enabling faculty to manage and update course information.
• Providing real-time updates on course availability and class capacity. Managing
student fee payments and generating invoices.

Defining Non-Functional Requirements

Non-functional requirements define how the system performs rather than what it does. They
include aspects such as security, performance, usability, and scalability.

Key Activities
• Setting performance standards, such as response time and system availability.
• Defining security requirements, including encryption and user authentication.

Page 6 of 116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
• Establishing usability standards, like intuitive user interfaces. Outlining scalability
requirements to ensure future growth.

Example: For the university registration system, non-functional requirements include:

• Performance: Supporting at least 1,000 concurrent users during peak registration periods.
• Security: Implementing data encryption and role-based access controls to protect student
information.
• Usability: Ensuring the system interface is intuitive and requires minimal training for students
and faculty. Scalability: The system must accommodate new academic programs without
major redesigns.

Documenting Requirements
Documenting the requirements ensures that everyone involved in the project has a clear
understanding of the system’s goals, functionalities, and constraints. This formal documentation
is crucial for design, development, and testing.

Key Activities
• Creating a Software Requirements Specification (SRS) document that outlines all
functional and non-functional requirements.
• Organizing requirements into categories (e.g., functional, non-functional).
Reviewing the document with stakeholders to ensure completeness and accuracy.

Example: For the university registration system, the SRS would include:
• Functional Requirements: Managing course enrollments, providing real-time course
availability, and generating fee invoices.
• Non-Functional Requirements: Supporting high traffic during registration weeks and
ensuring data security with encryption.

Analyzing Current Systems (Gap Analysis)

Analyzing the existing system (if any) helps identify the strengths and weaknesses of the current
processes and infrastructure. Gap analysis is used to compare the current system with the new
requirements, highlighting areas for improvement.

Key Activities
• Evaluating the strengths and weaknesses of the current system.
• Identifying missing features or areas for improvement in the existing system.
Comparing the current system’s performance against the newly defined requirements.

Example: For the university registration system, gap analysis might reveal that the current
system lacks mobile access, making it inconvenient for students to register on their phones.

Page 7 of 116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
Additionally, the old system may lack real-time course updates, leading to frustration for students
trying to enroll in full classes.

Modeling and Data Analysis

Modeling helps visualize how the system will work. It involves creating diagrams and models to
represent how data flows, how the system processes information, and how different components
interact.

Key Activities
• Creating process models to show how users interact with the system.
• Developing data models to illustrate how data is structured and managed.
• Using flowcharts and data flow diagrams (DFDs) to map the system’s processes and
workflows.

Example: For the university registration system, an Entity-Relationship Diagram (ERD)

might depict the relationships between students, courses, instructors, and payment entities. A Data
Flow Diagram (DFD) could show how data flows between the student registration interface, the
database, and the payment processing system.

Validating Requirements
Once the requirements are gathered and documented, it is important to validate them with
stakeholders. This ensures that the documented requirements reflect the actual needs and
expectations of users and stakeholders, reducing the risk of misunderstandings before proceeding
to design and development.

Key Activities:
• Conducting review sessions with stakeholders to present the documented requirements.
• Validating the requirements through prototypes, mock-ups, or early-stage models.
Obtaining formal approval from stakeholders to move forward with the design phase.

Example: For the university registration system, stakeholders like university administrators,
faculty, and students would review the requirements. Based on their feedback, features such as a
student’s ability to view their academic history during registration might be added.

Summary of the System Analysis Phase

Aspect Description Example
Gathering Collecting detailed information Interviewing university staff and
Requirements from users and stakeholders to students to determine features like
define what the system should do. course enrollment and fee payment
options.

Page 8 of 116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
Functional Defining what the system will do, The system must allow students to
Requirements focusing on its features and register for courses, faculty to manage
capabilities. courses, and provide real-time
updates.
Non-Functional Defining how the system should The system must support 1,000 users
Requirements perform, focusing on attributes during peak periods, use encryption
like security, performance, and for data, and be easy to navigate.
usability.
Documenting Creating a formal requirements Creating an SRS for a university
Requirements document (SRS) that outlines registration system, detailing both
functional and non-functional functional and performance
needs. specifications.
Analyzing Conducting gap analysis to Identifying that the current system
Current Systems compare the current system with lacks mobile access and real-time
the new requirements. updates, which are essential in the new
system.
Modeling and Using models to visualize how Creating ER diagrams and DFDs to
Data Analysis data and processes will work in show how student data will flow
the new system. through the system during
registration.
Validating Reviewing and confirming Presenting requirements to university
Requirements requirements with stakeholders to stakeholders for feedback and
ensure accuracy and alignment. approval, leading to refinements in the
system design.

The System Analysis phase is essential for laying the groundwork for a successful system. It
ensures that all user and stakeholder needs are understood, documented, and validated, providing
a strong foundation for system design and development.

System Design Phase

The System Design phase is pivotal in the System Development Life Cycle (SDLC). It transforms
the theoretical requirements gathered during the analysis phase into concrete technical
specifications that will guide the development process. The design phase ensures that the system
is built efficiently, is secure, scalable, and meets both functional and non-functional requirements.
It provides a blueprint for developers, outlining the system architecture, hardware and software
components, user interface design, and security protocols.
Defining System Architecture
The system architecture offers a high-level view of the structure of the system. It defines how
different components, such as hardware, software, and networks, interact to deliver the required
functionalities.

Page 9 of 116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025

Key Activities
• Define the architecture framework (e.g., client-server, cloud-based, distributed).
• Determine how different components, like the user interface, databases, and back-end
processing, interact. Ensure that the architecture addresses performance, scalability, security,
and resilience.

Example: In a healthcare system, the architecture might describe how patient data flows between
departments such as radiology, billing, and medical records. A central database server securely
stores patient information and can be accessed by authorized personnel across the hospital.

Hardware and Software Specification

This phase defines the exact hardware and software needed for the system to function optimally.
Ensuring the right components are chosen is crucial for the system’s performance, scalability, and
reliability.

Key Activities
• Specify the hardware required for system operations, including servers, storage devices, and
workstations.
• Choose the appropriate software platforms, such as operating systems, databases, and
applications.
• Identify any third-party tools or software required for the system (e.g., analytics tools or
database management systems).

Example: For a healthcare system, high-performance servers capable of managing large volumes
of patient data might be specified. Oracle or MySQL could be selected as the database
management system, while Linux may be the chosen operating system for secure and reliable
operations.

Database Design
The database design defines how the system will store, retrieve, and manage data. It includes
creating a database structure that ensures efficient data management, security, and scalability.

Key Activities:
• Design the database schema, specifying tables, fields, relationships, and constraints.
• Develop Entity-Relationship Diagrams (ERDs) to illustrate how data entities relate to each
other. Define how data will be secured, accessed, and maintained over time.

Example: For a healthcare system, the database might include tables for patients, doctors,
treatments, billing, and medical records. The relationships between these entities would be
mapped in an ERD, linking patient records to their treatments and billing details.

Page 10 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025

User Interface (UI) Design

UI design focuses on how users will interact with the system, ensuring that the interface is
userfriendly, intuitive, and accessible for various user groups.

Key Activities
• Create wireframes or mockups to represent the system’s user interface.
• Design the layout, navigation, and flow of the user interface to maximize usability.
• Address accessibility requirements for different user groups, such as doctors, nurses, and
patients.

Example: For a healthcare system, the UI might include a dashboard that enables doctors to
quickly access patient information, as well as a search function for retrieving patient records and
forms for entering new patient data.

Network Design
The network design defines how system components will communicate with each other, ensuring
seamless connectivity and secure data flow.

Key Activities
• Design the network topology (e.g., LAN, WAN, or cloud-based) to connect system
components.
• Specify how data will be transmitted securely, using encryption protocols and firewalls.
Ensure the network capacity can handle the required bandwidth and data traffic.

Example: For a multi-location healthcare system, a Virtual Private Network (VPN) might be
designed to securely connect hospitals, clinics, and healthcare facilities, enabling real-time access
to patient data across different locations.

Security Design
Security is critical in protecting sensitive information, particularly in systems that handle
confidential data like healthcare records. Security design ensures that the system is protected from
unauthorized access and cyberattacks.

Key Activities
• Define user authentication and authorization methods (e.g., role-based access control).
• Implement encryption protocols for data storage (at rest) and transmission (in transit).
• Design security measures like firewalls, intrusion detection systems (IDS), and secure
backup procedures.

Page 11 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
Example: In a healthcare system, patient data would be encrypted both at rest (when stored
in the database) and in transit (when transferred between hospitals or departments). Rolebased
access controls would ensure that only authorized personnel, such as doctors, can access
specific patient records.

Prototyping
Prototyping allows for the creation of a working model or mockup of the system or specific
components to test design ideas. Prototyping provides early feedback and helps identify potential
issues before full-scale development.

Key Activities
• Develop a prototype of the system or a specific module.
• Present the prototype to stakeholders or end-users to gather feedback. Refine
the design based on user feedback before proceeding to full development.

Example: For a healthcare system, a prototype of the doctor’s dashboard might be developed.
Doctors and medical staff could provide feedback on the interface's usability, leading to
adjustments before full development.

Defining System Interfaces

System interfaces define how the new system will interact with other internal or external systems.
These interfaces ensure data can be exchanged between the new system and other systems securely
and consistently.

Key Activities
• Identify external systems or services the new system needs to communicate with (e.g., billing
or insurance systems).
• Define Application Programming Interfaces (APIs) or protocols for secure data exchange.
Ensure data consistency and security during integration with external systems.

Example: In a healthcare system, the system might need to interface with external pharmacy
systems to process prescriptions or insurance systems for claims processing. Secure APIs would
be used to ensure that these transactions are handled securely.

Summary of the System Design Phase

Aspect Description Example
System Defining the system's overall Designing the flow of patient data
Architecture architecture and how between hospital departments using a
components interact. centralized database server.

Page 12 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
Hardware and Specifying hardware and Selecting servers and database
Software software requirements for management software like Oracle or
system operation. MySQL for handling large healthcare
data.
Database Structuring the database with Designing tables for patients, doctors,
Design entities, relationships, and data treatments, and billing in a healthcare
flow. system.
User Interface Creating intuitive and accessible Designing a dashboard for doctors to
Design interfaces for users. access patient information quickly and
easily.
Network Defining the network topology Implementing a secure VPN to connect
Design and protocols for data multiple hospital locations for real-time
communication. patient data access.
Security Design Ensuring data security with Encrypting patient data and implementing
encryption, authentication, and role-based access controls for secure data
access control. handling in a healthcare system.
Prototyping Building prototypes to gather Developing a prototype of the patient
feedback and validate design record dashboard for feedback from
choices. doctors and medical staff.
System Designing interfaces for Integrating the healthcare system with
Interfaces interaction with external external pharmacy and insurance systems
systems or services. using secure APIs.

The System Design phase is essential for transforming the system requirements into a practical
design. It ensures that the system’s architecture, components, and security measures are
welldefined, providing a solid foundation for developers to build the system efficiently. This phase
ensures the final system meets the organization’s business objectives, user needs, and technical
specifications.

Development Phase
The Development phase is a key phase in the System Development Life Cycle (SDLC) where
the system is physically built. This is where the actual programming happens, and the system
design is converted into functional code. The primary goal is to develop a working system that
meets all the functional and non-functional requirements established during the earlier phases. This
phase involves several key activities, from writing code to integrating third-party services and
conducting quality assurance checks.
Translating Design into Code
During this step, the design documents are translated into the actual code. This process involves
writing the code that will define the system’s structure, including its back-end processes,

Page 13 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
algorithms, and front-end interface. Developers use programming languages, frameworks, and
tools that are best suited for the system's needs.

Key Activities:
• Write code for individual components of the system based on design documents.
• Develop back-end logic for processing data, calculations, and core functionalities.
• Implement the front-end interface that users will interact with to ensure the system is user-
friendly and intuitive.

Example: For an online banking system, developers may use Python to create features like
balance inquiries, fund transfers, and transaction history tracking. This code will handle
backend operations such as verifying user authentication, processing transfers, and updating
transaction records in real-time.

Developing Database Components

Database development is another essential part of the Development phase, involving the creation
and configuration of the system’s database. Developers create tables, establish relationships, and
write queries that allow the system to store, retrieve, and manage data efficiently.

Key Activities
• Implement the database schema, including tables, fields, and relationships as defined in the
design phase.
• Write database queries and stored procedures for data retrieval, updates, and storage.
Ensure data security by implementing proper access control and encryption mechanisms.

Example: For the online banking system, developers might build tables for customers, accounts,
transactions, and balances. Stored procedures would be written to handle complex tasks such as
transferring funds between accounts or generating monthly account statements.

Implementing System Features and Functionality

This step involves coding the system’s core functionality. Developers work on implementing the
main features of the system, ensuring they work together to achieve the system’s intended goals.

Key Activities
• Implement core functionalities like user authentication, data entry, data processing, and
reporting.
• Ensure that the front-end interface is integrated with the back-end logic to provide a fully
functional system. Develop APIs or integrations with third-party systems as necessary.

Example: In an online banking system, developers may implement features like user login,
balance checks, fund transfers, and transaction histories. These features would be integrated

Page 14 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
into the system, allowing users to securely log in, check their account balance, and transfer funds
to other accounts.

Front-End and Back-End Development

Front-end development focuses on creating the user interface (UI), while back-end development
handles server-side logic and processes. Both are essential to building a fully functional system.

Key Activities
• Front-End Development: Build the user interface using technologies like HTML, CSS, and
JavaScript, ensuring users can easily navigate the system.
• Back-End Development: Develop the server-side logic using programming languages like
Python, Java, or PHP, ensuring data processing and system functionality work as expected.
• Test the integration between front-end and back-end components to ensure smooth
communication.

Example: For the online banking system, front-end developers may design a web interface that
allows users to view their account balance, initiate fund transfers, or view recent transactions.
Back-end developers ensure these requests are processed and stored in the database.

Integration of Third-Party Services

Many systems require integration with external services like payment gateways, email services, or
third-party APIs. Integrating these services ensures that the system offers additional functionalities
and supports external interactions.

Key Activities
Integrate external services like payment gateways, email services, or other APIs.

Page 15 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025

Ensure secure and smooth communication between the system and third-party services.
Write code to handle potential errors or failures in third-party integrations.

Example: For the online banking system, developers may integrate payment gateways like
PayPal or Stripe to allow customers to transfer funds to external accounts. The system would
need APIs that handle these transactions securely and reliably.

Code Review and Quality Assurance

To ensure that the system operates smoothly and securely, developers conduct code reviews and
perform quality assurance tests. This step helps identify potential issues, such as bugs, security
vulnerabilities, or performance inefficiencies.

Key Activities
• Perform peer code reviews to ensure consistency, adherence to coding standards, and logical
accuracy.
• Conduct automated tests and manual testing to verify that system components are
functioning as expected. Optimize the code for performance, security, and
scalability.

Example: In the online banking system, peer reviews might reveal areas where error handling
for failed transactions needs improvement. Automated testing might also identify bugs that cause
incorrect balance updates after a transaction.

Version Control and Collaboration

Using a version control system helps manage changes to the codebase, ensuring that developers
can collaborate efficiently without overwriting each other’s work. Tools like Git are commonly
used to track changes and facilitate team collaboration.

Key Activities
• Use version control systems like Git to manage code changes and maintain a development
history.
• Collaborate with other developers to merge code, resolve conflicts, and track progress.
• Implement continuous integration (CI) pipelines to automatically test and deploy
updates to the system.

Example: In the online banking system, developers might use Git to manage the codebase,
allowing multiple team members to work on different features at the same time. A CI pipeline
could automatically test new code pushed to the repository to ensure the system remains stable.

Page 16 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
Summary of the Development Phase
Aspect Description Example
Translating Design Writing code to implement the Using Python to build features like
into Code system based on design fund transfers and transaction records
specifications. in an online banking system.
Database Creating the system’s database, Developing a database with tables for
Development including tables, relationships, customers, accounts, transactions,
and stored procedures. and balances in the banking system.
Implementing Coding and integrating the core Implementing features like balance
Features functionality of the system. inquiries, transaction history, and
fund transfers for an online banking
system.
Front-End and Building the user interface and Creating a user-friendly dashboard
Back-End server-side logic to create a for customers to view their account
Development functional system. details, while back-end handles data
processing.
Third-Party Integrating the system with Connecting the online banking
Service Integration external services or APIs. system with payment gateways like
PayPal or Stripe for external fund
transfers.
Code Review and Conducting peer reviews and Reviewing code for security
Quality Assurance automated tests to ensure code vulnerabilities and testing features for
quality and functionality. bugs in the online banking system.
Version Control Using version control systems Developers using Git to manage the
and Collaboration and continuous integration to codebase and a CI pipeline to
manage changes automatically test new features in the
and collaboration. banking system.

The Development phase brings the system to life, translating design documents into working
software. By implementing the core features and functionalities, developing the database, and
integrating third-party services, this phase ensures that the system meets its intended business
objectives. Continuous testing, collaboration, and code review help ensure the final product is
efficient, secure, and meets all quality standards.
Testing Phase
The Testing phase of the System Development Life Cycle (SDLC) is crucial for ensuring that
the system functions as intended, is secure, and meets the requirements outlined in the design and
analysis phases. During this phase, various types of testing are conducted to identify and resolve
any bugs or issues, ensuring that the system is reliable, secure, and ready for end-user deployment.
Testing also ensures that the system meets both functional and non-functional requirements, such
as performance and security.

Page 17 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025

Unit Testing
Unit Testing focuses on testing individual components or modules of the system in isolation. The
goal is to ensure that each small part of the system works correctly on its own, without being
impacted by the other parts.

Key Activities
• Test individual components such as functions, methods, or classes to validate their correctness.
• Identify and resolve any bugs or issues within the isolated components.
Ensure that each unit performs according to the design specifications.

Example: In a payroll system, unit testing would involve verifying the tax deduction module to
ensure it accurately calculates deductions based on different salary ranges. Similarly, the overtime
calculation module would be tested to ensure it correctly computes overtime pay based on the
number of extra hours worked by employees.

Integration Testing
Integration Testing verifies that different system components or modules work together as
expected. This type of testing ensures that data flows smoothly between components and identifies
any issues that might arise from their interaction.

Key Activities
• Test how different components of the system interact with each other.
• Identify and fix any issues related to data exchange between components.
Ensure the integration between various modules functions correctly.

Example: In a payroll system, integration testing would verify that the employee database,
payroll processing module, and tax deduction system work together smoothly. It ensures that
data about employee hours flows correctly into the payroll system, and that tax calculations are
accurate based on payroll data.

System Testing
System Testing evaluates the system as a whole to ensure that it meets all functional and
nonfunctional requirements. This type of testing validates the system’s complete functionality,
performance, security, and overall behavior.

Key Activities
• Perform end-to-end testing to validate all functionalities of the system.
• Ensure that both functional requirements (such as payroll processing) and non-functional
requirements (such as performance and security) are met.

Page 18 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
• Conduct stress testing to ensure the system can handle high volumes of data and users without
failure.
• Example: In a payroll system, system testing would involve running payroll for all employees
in the organization. This includes entering employee data, calculating salaries, generating
payroll reports, and ensuring the system can handle large transaction volumes, especially at
peak times like the end of the month.

User Acceptance Testing (UAT)

User Acceptance Testing (UAT) is the final stage of testing, where actual users test the system
in real-world scenarios. UAT ensures that the system meets user expectations and business
objectives before deployment.

Key Activities
• Involve end-users in testing the system to validate that it meets their requirements.
• Identify any usability issues, missing features, or discrepancies from a user perspective.

Page 19 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025

Obtain formal approval from users before moving to the deployment phase.

Example: In a payroll system, UAT might involve HR staff running a payroll cycle for a sample
group of employees. They would check if the system correctly calculates salaries, deductions, and
taxes, and if payroll reports are accurate. Once users are satisfied, the system is deemed ready for
deployment.

Performance Testing
Performance Testing is conducted to ensure that the system performs well under varying
conditions, such as high user loads or peak usage times. This type of testing helps identify
bottlenecks and ensures the system is scalable and responsive under stress.

Key Activities
• Test the system under different workloads, including high transaction volumes or user
activity.
• Identify performance issues like slow response times, system crashes, or bottlenecks.
Ensure the system meets performance benchmarks for speed, scalability, and reliability.

Example: For a payroll system, performance testing might simulate thousands of employees
being processed simultaneously at the end of the month. This ensures that the system can handle
large workloads without slowing down or crashing during peak times, ensuring it remains
responsive under heavy use.

Security Testing
Security Testing ensures that the system is secure from potential threats such as unauthorized
access, hacking attempts, and data breaches. This type of testing helps identify vulnerabilities and
ensures that sensitive data is protected.

Key Activities
• Test the system for potential vulnerabilities, such as SQL injection, cross-site scripting, or
unauthorized access.
• Ensure that user authentication, role-based access controls, and data encryption are
functioning correctly.
• Perform penetration testing to simulate cyberattacks and identify weaknesses in the
system’s security.

Example: In a payroll system, security testing would involve verifying that only authorized
personnel, such as HR staff, can access sensitive employee data. It would also ensure that
payroll information is encrypted both during storage and transmission. Simulating attacks on
the system helps ensure it can prevent unauthorized access.

Page 20 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025

Regression Testing
Regression Testing ensures that any updates, such as bug fixes or new features, do not break
existing functionality or introduce new bugs. This type of testing is often automated to improve
efficiency.

Key Activities
Re-test previously tested components after system updates to ensure they still function as
expected.
Identify any new bugs introduced by recent changes. Use
automated tools to efficiently perform repetitive regression tests.

Example: In a payroll system, after a bug fix is made to the overtime calculation module,
regression testing would ensure that this change does not negatively impact other functions, such
as tax calculation or salary disbursement.

Automation Testing
Automation Testing involves using specialized tools to automate repetitive testing tasks, such as
regression testing or performance testing. This helps increase the efficiency and consistency of
testing.

Key Activities
• Use automation tools like Selenium, JUnit, or LoadRunner to automate repetitive testing
tasks.
• Develop and maintain automated test scripts that can be run regularly during each testing cycle.
Regularly update automated tests to reflect changes in the system, such as new features or
bug fixes.

Example: In a payroll system, automated tests might be set up to verify that calculations for
deductions, overtime, and salaries remain accurate after each system update. This helps ensure that
the system continues to function properly even as changes are made.

Summary of the Testing Phase

Aspect Description Example
Unit Testing Testing individual components in Verifying that the tax deduction
isolation to ensure they work module in a payroll system correctly
correctly. calculates tax deductions for different
salary ranges.

Page 21 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025

Integration Testing the interaction between Testing how the payroll module
Testing system components to ensure integrates with the employee database
smooth data flow. and tax calculation modules.
System Testing Testing the entire system to Running payroll processing for the
ensure it meets functional and entire organization to ensure accurate
non-functional requirements. salary calculations and report
generation.
User Acceptance Involving end-users in testing the HR staff running payroll cycles to
Testing (UAT) system to validate that it meets verify accuracy in salaries, deductions,
their needs and expectations. and taxes before final deployment.
Performance Evaluating the system’s Simulating payroll processing for
Testing performance under varying thousands of employees to ensure the
workloads and peak conditions. system remains responsive during peak
usage.
Security Testing Ensuring that the system is Verifying that only authorized HR
secure from potential threats and personnel can access sensitive payroll
that sensitive data is protected. data and that the data is encrypted.
Regression Ensuring that new changes or Re-testing payroll calculations after
Testing updates do not introduce bugs or bug fixes to ensure other system
break existing functionality. functions are unaffected.
Automation Using automation tools to Automating payroll cycle tests to
Testing automate repetitive testing tasks verify accuracy in tax and salary
for consistency and efficiency. calculations after each system update.

The Testing phase is essential for ensuring the quality, reliability, and security of the system before
it is deployed for real-world use. Through various types of testing—unit, integration, system, and
more—the system is thoroughly evaluated to confirm that it meets business objectives, performs
efficiently, and operates securely. This ensures that the system can handle real-world usage
scenarios and will be stable and dependable upon deployment.

Deployment Phase
The Deployment phase of the System Development Life Cycle (SDLC) is the process of making
the system operational in a live environment after all testing has been completed and the system is
deemed stable. During this phase, the system is transferred from the development and testing
environment to the production environment where it will be accessed and used by actual end-users.
The deployment process requires careful planning and execution to ensure a smooth transition
without disrupting business operations.

Preparing for Deployment

Page 22 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
Before the system can be deployed, several preparatory steps must be taken to ensure the
deployment process goes smoothly. This involves planning for the deployment, creating backup
plans, and ensuring that the production environment is ready for the system.

Key Activities
• Develop a detailed deployment plan, including timelines, tasks, and responsibilities.
• Prepare backup and rollback plans in case issues arise during deployment.
• Ensure the production environment (hardware, software, and network) is set up and ready to
support the new system.

Example: For a school management system, deployment preparation would involve ensuring that
the necessary hardware (e.g., servers, workstations) and software (e.g., database systems, user
interfaces) are in place. Additionally, backup plans are created in case any part of the system fails
during deployment.

Data Migration
If the new system is replacing an old system or if data needs to be transferred from another system,
data migration is a critical step in the deployment process. It involves moving existing data to the
new system while ensuring data integrity and security.

Page 23 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
Key Activities
• Migrate existing data from legacy systems or databases to the new system.
• Ensure data is transferred accurately, maintaining its integrity and structure.
Validate the migrated data to confirm that it is correctly formatted and complete.

Example: In a school management system, data migration would involve transferring student
records, staff information, course details, and attendance records from the old system to the new
one. This ensures that all historical data is available when the new system goes live.

System Configuration
After the system has been migrated to the production environment, it must be configured to meet
the needs of the organization. This involves setting up user roles, permissions, and system
parameters to ensure the system operates correctly for different user groups.

Key Activities
• Configure system settings, including user roles, permissions, and access levels.
• Set up integration with other systems, such as financial systems, payment gateways, or external
databases.
• Ensure that security protocols, such as encryption and user authentication, are properly
configured.

Example: In a school management system, administrators, teachers, and students are assigned
different user roles. Administrators have full access to the system, teachers can manage student
grades and attendance, and students can view their own profiles and course information.

Training and User Support

A successful deployment requires that end-users are properly trained to use the system effectively.
Training ensures that users can perform their tasks efficiently and understand how to use the new
system. Additionally, support mechanisms must be in place to help users resolve any issues they
may encounter.

Key Activities
• Provide training sessions or user guides to teach staff how to use the system.
• Set up a helpdesk or support team to assist users with issues that arise post-deployment.
Collect feedback from users during the initial phase to identify any usability issues.

Example: In the deployment of a school management system, teachers would be trained on how
to enter attendance records, upload grades, and communicate with parents. Students might receive
guidance on how to log in, check their timetables, and view grades.

System Monitoring

Page 24 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
Once the system is deployed, it is important to monitor its performance to ensure that it operates
smoothly and that any issues are addressed quickly. System monitoring involves tracking key
performance indicators (KPIs) and keeping an eye on any potential technical issues.

Key Activities
• Monitor system performance, such as response times, server load, and data processing speed.
• Track user activity to ensure that users can access the system and perform tasks without issues.
Set up alerts for potential issues such as security breaches or system overloads.

Example: After deploying the school management system, the IT team monitors the system’s
performance, such as the speed at which student data is retrieved or how quickly attendance is
recorded. If any issues arise, such as slow response times, the team can take immediate action to
resolve them.

Addressing Post-Deployment Issues

After deployment, users may encounter issues that were not identified during testing. It’s essential
to have a process in place for addressing and resolving these issues quickly to minimize disruption
to operations.

Key Activities
• Set up a system for reporting and tracking post-deployment issues.
• Assign a support team to investigate and resolve issues as they arise. Release patches
or updates to fix any bugs or issues identified after deployment.

Example: In a school management system, if teachers report that the system is not displaying
student grades correctly, the support team can investigate and release a software patch to correct
the issue, ensuring that the system functions correctly.

System Implementation
Once the system is fully configured and all preparatory steps are complete, the system is rolled out
to the entire user base. Depending on the size of the organization, this might be done gradually
(phased rollout) or all at once (full rollout).

Key Activities
• Determine whether to perform a direct rollout or a phased rollout based on the
organization’s size and complexity.
• Ensure that all users have access to the system and can perform their necessary tasks.
Monitor user feedback during the initial rollout period to address any concerns.

The Rolling Out to Users can be executed in several ways depending on the size, complexity, and
specific needs of the organization. Choosing the right rollout strategy is critical for minimizing

Page 25 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
risk, ensuring user satisfaction, and reducing operational disruptions. Below is a detailed overview
of the various rollout strategies, including their advantages, disadvantages, and where they are best
applied.

Direct Implementation
In a Direct Implementation, the entire system is deployed to all users at the same time. This
strategy is often used for smaller systems or organizations where a single, simultaneous transition
is feasible.

Advantages
• Faster deployment: The system is fully operational for all users at once.
• Simplified communication: All users are on the same system immediately, reducing
complexity. Lower operational costs: Only one deployment phase is required, saving time
and resources.

Disadvantages
• Higher risk: If any issues arise, they can impact the entire organization, potentially
leading to significant disruptions.
• Limited opportunity for testing in a live environment before full deployment.
Requires extensive pre-rollout preparation to ensure smooth implementation.

Where Applicable
• Best for small organizations or relatively simple systems where risk can be easily managed.
• Suitable when immediate system-wide access is needed, such as in small schools or small
businesses.

Example: A full rollout might be used to deploy a school management system to all students,
teachers, and administrators simultaneously, allowing everyone to log in, update grades, view
schedules, and communicate immediately.

Phased Implementation
In a phased implementation, the system is deployed to a subset of users or departments initially,
and then gradually rolled out to the rest of the organization. This approach allows for risk
management and incremental feedback.

Advantages
• Reduced risk: Only a small group is impacted initially, allowing issues to be addressed
before the system is rolled out to the entire organization.
• Continuous feedback: Early adopters provide valuable feedback, allowing for
improvements during later phases. Flexibility: The rollout can be adjusted based on the
success of earlier phases.

Page 26 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025

Disadvantages
Longer deployment time: The gradual approach can extend the overall deployment
timeline. Higher operational costs: Multiple phases of rollout require more planning,
monitoring, and communication.

Where Applicable
• Best for large organizations or complex systems where managing risk and user feedback is
critical.
• Suitable for environments where some departments or users can continue using the old system
while others transition to the new one, such as in hospitals, large enterprises, or
multilocation businesses.

Example: A hospital management system might first be rolled out to the radiology and billing
departments, allowing for testing and feedback before extending the system to patient records and
the pharmacy.

Pilot Implementation
In a pilot implementation, the system is deployed to a small group of users who serve as testers.
This method allows for detailed user feedback and system adjustments before a wider rollout.

Advantages
• Low risk: Since only a small group is involved initially, any issues can be resolved with
minimal disruption.
• Valuable feedback: Pilot users can provide detailed feedback on the system’s functionality and
usability, allowing for improvements before full deployment.
• Opportunity for refinement: Issues can be resolved and enhancements made before rolling the
system out to all users.

Disadvantages
• Requires additional planning: Time and resources are needed to set up and support the pilot
group.
• Potential for delays: Depending on feedback and issues uncovered, the full rollout may be
delayed.

Where Applicable:
• Best for highly complex systems or environments where extensive user testing and feedback
are needed before full deployment.
• Suitable for systems where a representative group can provide useful insights, such as HR,
payroll, or finance systems.

Page 27 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
Example: A payroll system could first be piloted with the HR department. They can test payroll
cycles for a small group of employees and provide feedback, ensuring the system works correctly
before organization-wide deployment.

Parallel Implementation (Rollout)

In a parallel implementation, both the old and new systems run simultaneously for a period. Users
gradually transition to the new system while still having access to the old system as a fallback.

Advantages
• Low-risk transition: Users can continue using the old system while familiarizing themselves
with the new one.
• Fallback option: If any issues arise with the new system, users can revert to the old system,
minimizing disruptions. Smoother user adoption: Allows users to adapt to the new system at
their own pace.

Disadvantages
• Higher operational costs: Running both systems concurrently can increase costs and require
additional resources for support.
• Complexity: Maintaining two systems can create confusion and operational complexity.
• Extended transition period: Full adoption of the new system may take longer as users transition
at different rates.

Where Applicable
• Best for mission-critical systems where a fallback option is essential, such as in banking,
government, or healthcare.
• Suitable for organizations where transitioning from the old system to the new system may
take time and requires user adjustment.

Example: In a banking system, both the old and new online banking platforms might run in
parallel for a few months. Customers can switch between the two as they familiarize themselves
with the new platform, ensuring a smooth transition.

Training and User Education

Training and user education are crucial components of any implementation strategy. Regardless of
whether the implementation is direct, phased, pilot, or parallel, ensuring that users are adequately
trained to use the new system is vital for its success.

Benefits
• Improves user adoption: Well-trained users are more likely to embrace the new system and
use it effectively.

Page 28 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
• Reduces errors: Proper training ensures users understand the system’s features and
functionality, reducing the likelihood of mistakes.
• Enhances productivity: Users who are comfortable with the system can complete tasks more
efficiently, improving overall productivity.

Limitations
• Requires time and resources: Training programs can take time to develop and require skilled
trainers to deliver.
• Potential for inconsistent training: If training is not standardized, users may receive varying
levels of instruction.

Example: For a CRM system, sales and marketing teams may receive detailed training on how to
input customer data, generate reports, and manage leads. Providing hands-on training and user
guides ensures they can fully utilize the system.

Monitoring After Rollout

Once the system is rolled out, continuous monitoring is essential to ensure that it is functioning
correctly, meeting user needs, and addressing any issues that arise.

Benefits
• Early detection of issues: Monitoring allows for the quick identification and resolution of
performance problems or bugs.
• User feedback: Continuous monitoring provides insights into how users are interacting with
the system, offering opportunities for further improvement.
• System optimization: Ongoing monitoring helps identify performance bottlenecks or areas
where the system can be optimized for better efficiency.

Limitations
• Requires resources: Monitoring tools and personnel are needed to continuously track system
performance and user activity.
• Can be time-consuming: Ongoing monitoring and troubleshooting require attention over an
extended period.

Example: After deploying an inventory management system, monitoring tools track stock levels,
reorder points, and processing speeds to ensure real-time updates are accurate. Any discrepancies
are addressed promptly to maintain system reliability.

Summary of the Deployment Phase

Aspect Description Example

Page 29 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
Preparing for Developing a detailed Ensuring that hardware and software
Deployment deployment plan and preparing for the school management system
backup strategies. are in place and backed up before
deployment.
Data Migration Transferring data from old Migrating student records, course
systems to the new system while details, and attendance data to the
ensuring data integrity. new school management system.
System Configuring user roles, Setting different user roles for
Configuration permissions, and system settings administrators, teachers, and students
to ensure the system operates in the school management system.
correctly.
Training and User Providing training to end-users Training teachers on how to use the
Support and setting up support to handle system to enter grades and attendance
issues post-deployment. records, and setting up a helpdesk.
System Monitoring system performance Monitoring how quickly student data
Monitoring and identifying any potential is retrieved and ensuring the system
issues during the early stages of can handle large volumes of
deployment. transactions.
Addressing Post- Resolving any issues or bugs that Investigating and fixing issues related
Deployment Issues arise after deployment to ensure to grade display errors in the school
smooth operation. management system.
Rolling Out to Gradually or fully rolling out the Phasing the deployment of the school
Users system to all users and management system, starting with
monitoring their feedback. administrators and then extending to
teachers.

The Deployment phase is a critical step in the SDLC that requires careful planning and execution
to ensure the system is launched smoothly and operates effectively in a live environment. By
following a structured deployment process that includes data migration, system configuration, user
training, and post-deployment monitoring, organizations can minimize disruption and ensure the
system delivers its intended value.

Maintenance Phase
The Maintenance phase of the System Development Life Cycle (SDLC) ensures the system
remains functional, secure, and updated to meet evolving business needs. Once a system is
deployed, it is monitored and maintained to address any post-deployment bugs, improve its
performance, adapt to changing external environments, and make enhancements. This phase is
continuous and essential for the long-term success and sustainability of the system.
Corrective Maintenance

Page 30 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
Corrective maintenance focuses on fixing bugs or errors that are identified after the system is
deployed. Despite extensive testing during the development phase, some issues may only surface
when the system is live and in real-world use.

Key Activities
• Identify bugs and errors reported by users or through system monitoring tools.
• Apply software patches or fixes to resolve these issues.
• Test the fixes to ensure they don’t negatively impact other parts of the system or introduce new
problems.

Example: In an online shopping system, users might report issues with payment processing using
certain credit cards. The development team identifies a bug in the payment gateway and releases a
patch to resolve the issue, ensuring smooth payment processing for all users.

Adaptive Maintenance
Adaptive maintenance involves modifying the system to remain compatible with changes in the
external environment, such as new hardware, software updates, regulatory changes, or third-party
service integrations.

Key Activities
• Modify the system to ensure compatibility with new hardware, operating systems, or thirdparty
services.
• Update the system to comply with new business rules or regulatory requirements.
• Adapt the system to integrate with new platforms or external services.
Example: In an online shopping system, the addition of a new payment gateway to support
mobile transactions requires the system to be updated for compatibility, ensuring a seamless
experience for users preferring mobile payment options.

Perfective Maintenance
Perfective maintenance focuses on improving the system's functionality or performance based on
user feedback or changing business needs. This can involve adding new features, optimizing
existing features, or improving overall system performance.

Key Activities
• Improve system performance by optimizing code or enhancing processing times.
• Add new features to meet evolving user requirements. Refactor the system
for better efficiency, scalability, or ease of maintenance.

Example: In an online shopping system, users may request an advanced search feature that allows
filtering products by price range, availability, or brand. The development team enhances the search
functionality to meet these requests, improving the overall user experience.

Page 31 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025

Preventive Maintenance
Preventive maintenance is proactive, involving actions that prevent future problems from arising.
It ensures that the system remains stable, secure, and up-to-date by addressing potential issues
before they impact system performance.

Key Activities
• Update system components, libraries, or frameworks to avoid future compatibility or security
issues.
• Conduct regular system audits to detect potential vulnerabilities or performance bottlenecks.
Implement security patches to protect against emerging threats.

Example: In an online shopping system, preventive maintenance might involve applying regular
security patches to protect against vulnerabilities and conducting system audits to ensure optimal
performance during peak shopping periods like holidays.

Monitoring and Performance Tuning

To ensure the system continues to operate efficiently, system monitoring and performance
tuning are critical. Regular monitoring allows for the detection of performance issues, while tuning
adjusts the system to enhance speed and stability.

Key Activities
• Monitor system metrics like server response times, data processing speeds, and user activity.
• Identify areas where performance can be improved and apply necessary adjustments.
Set up automated alerts to detect issues such as increased error rates or slow response
times.

Example: In an online shopping system, monitoring may reveal slow performance during peak
shopping periods, like Black Friday. The development team may optimize the system’s database
or increase server capacity to ensure smooth user experiences during high-traffic times.

User Support and Help Desk

User support is crucial during the maintenance phase. Providing timely assistance to users when
issues arise helps ensure a positive user experience. A help desk or support team is typically set up
to resolve user-reported issues efficiently.

Key Activities
• Establish a help desk or support team to handle user queries and issues.
• Track and resolve user-reported problems efficiently using a ticketing system.
• Provide resources such as user guides, FAQs, and training materials to assist users in
navigating the system.

Page 32 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025

Example: In an online shopping system, customers might encounter issues during checkout. The
help desk assists by resetting passwords, troubleshooting payment issues, or guiding users through
the checkout process to ensure a smooth shopping experience.

Security Updates and Patching

Security is a top priority during the maintenance phase. New threats and vulnerabilities are
constantly emerging, and it is vital to apply security updates and patches to protect sensitive data
and the integrity of the system.

Key Activities
• Apply security patches to address new vulnerabilities in the system’s software or third-
party services.
• Conduct regular security audits to identify potential risks and mitigate them.
Ensure that sensitive data is encrypted and user authentication methods are robust.

Example: In an online shopping system, if a vulnerability is discovered in the shopping cart

software, the development team quickly applies a security patch to close the vulnerability and
protect against data breaches.

Continuous Improvement
The system must evolve with changing business needs, industry trends, and user feedback.
Continuous improvement involves implementing incremental updates and enhancements to keep
the system aligned with new developments.

Key Activities
• Review user feedback and usage patterns to identify areas for improvement.
• Implement small, regular updates to enhance functionality, user experience, or performance.
• Stay up-to-date with technological advancements and incorporate them into the system as
needed.

Example: In an online shopping system, the development team may regularly update the user
interface to improve the shopping experience based on user feedback, making it more intuitive
and visually appealing while also ensuring the system remains competitive in a fast-changing
industry.

Summary of the Maintenance Phase

Aspect Description Example
Corrective Fixing bugs or issues that arise Fixing a bug in the online shopping
Maintenance after deployment. system’s payment gateway for
smoother transactions.

Page 33 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
Adaptive Adapting the system to new Updating the system to integrate a
Maintenance external changes, such as new new mobile payment platform.
hardware, software, or
regulations.
Perfective Enhancing system performance Implementing an advanced search
Maintenance or adding new features based on feature in the shopping system based
user feedback. on customer requests.
Preventive Proactively addressing potential Applying regular security patches
Maintenance future issues by applying updates and updating software libraries to
and security patches. protect the system from emerging
threats.
Monitoring and Monitoring system performance Optimizing server capacity to ensure
Performance and making necessary fast response times during peak
Tuning adjustments to ensure optimal shopping periods like Black Friday.
operation.
User Support and Providing assistance and Assisting customers with checkout or
Help Desk resolving user-reported issues account issues in the online shopping
through a help desk or support system.
team.
Security Updates Regularly applying security Applying a security patch to fix a
and Patching patches and updates to protect the vulnerability in the shopping cart
system from potential threats. software to prevent data breaches.
Continuous Continuously enhancing the Regularly updating the shopping
Improvement system by incorporating new system’s interface to improve user
features and staying updated with experience and maintain
technology. competitiveness.
The Maintenance phase of the SDLC is vital for ensuring that the system continues to function
effectively, meets evolving business and user needs, and stays secure against emerging threats. By
addressing bugs, making improvements, and staying current with technological advancements, the
system remains relevant, reliable, and valuable over its lifecycle.

SDLC Models and Methodologies

Even though there are specific steps to SDLC, there’s plenty of flexibility: teams adopt different
methodologies with diverse approaches to the software development process. Each SDLC model
offers a unique approach to development, and the choice of model depends on the project
requirements, complexity, and flexibility. The most popular SDLC models are Waterfall,
VShaped, Iterative, Spiral, Big Bang, Prototype, and Agile.

Page 34 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
Waterfall Model
The Waterfall Model is a traditional SDLC (System Development Life Cycle) model that follows
a linear and sequential approach to software development. It is called "Waterfall" because the
development process flows in one direction, like a waterfall, from the top to the bottom. Each
phase has its own defined objectives and deliverables, and once a phase is completed, the team
cannot move backward to revise it. This model is simple and easy to understand, making it ideal
for small projects with well-defined requirements.

Phases of the Waterfall Model

1. Requirements Gathering and Analysis
• Overview: In this initial phase, all system requirements are collected from stakeholders.
These requirements must be comprehensive, accurate, and documented in a formalized
document to avoid future misinterpretations. The development team needs a clear
understanding of the system’s purpose, functionalities, and limitations.
• Example: For a hospital management system, this phase involves gathering detailed
requirements for patient registration, appointment scheduling, billing, and report
generation. Security requirements for protecting sensitive patient data would also be
discussed in this phase.
• Deliverables:
o Requirement Specification Document (RSD): A formal document that outlines
all functional and non-functional requirements of the system. It serves as the
foundational guide for the rest of the development process.
• Key Activities o Stakeholder meetings and interviews.
o Use case and scenario analysis.
o Creation of user stories and detailed system requirements.

Page 35 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
2. System Design
• Overview: Based on the requirements collected, the system's architecture is designed.
The design phase translates the requirements into a blueprint of the system’s structure,
including both high-level architecture and detailed design of the components,
databases, and user interfaces.
• Example: In the hospital management system, this phase involves designing the
database structure for storing patient information, billing details, and medical history. The
system architecture might include designing how different modules (e.g., billing,
scheduling, and medical records) interact with each other and the database.
• Deliverables:
o System Design Document (SDD): A comprehensive document detailing the
system architecture, database schemas, interface designs, and data flows.
• Key Activities:
o High-level design: Defining system architecture.
o Detailed design: Specifying databases, algorithms, and user interfaces.
o Designing process workflows and data flow diagrams.

3. Implementation (Coding)
• Overview: This phase marks the beginning of actual software development.
The system design is now converted into source code using a suitable
programming language. Developers build each component and integrate
them according to the design specification.
• Example: Developers for the hospital management system start coding
the patient registration and billing modules. The billing system might
include functionalities like generating invoices and calculating payment
dues based on treatments provided.
• Deliverables o Source Code: Code for all components and features.
o Application Components: Modules, user interfaces, and databases.
• Key Activities o Writing code based on the design document. o Building
interfaces and integrating databases.
o Internal code reviews to ensure adherence to coding standards.

4. Testing
• Overview: After coding, the system is rigorously tested to identify defects and verify
that it meets the specified requirements. This phase involves unit testing, integration
testing, and system testing to ensure that the software functions as expected without
errors.
• Example: For the hospital management system, testers would validate whether
patients can register correctly, whether appointment scheduling works across all
departments, and whether the billing system calculates fees correctly. They would also
ensure that patient data is securely stored.

Page 36 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
• Deliverables o Test Cases: A set of defined test cases covering all system
functionalities.
o Test Reports: Detailed reports on testing outcomes, including identified bugs, test
coverage, and areas requiring fixes.
• Key Activities o Running unit tests on individual modules.
o Performing integration tests to check interaction between different system
components.
o System-level testing to validate overall functionality.

5. Deployment
• Overview: Once testing is successfully completed, the system is deployed to the
customer’s environment for use. This phase involves installing the system, configuring it
in the production environment, and training users on how to use the system effectively.
• Example: In the hospital management system, this phase would involve installing the
system on the hospital’s servers, setting up user accounts, and training staff members on
how to use the system to manage patient data, appointments, and billing.
• Deliverables:
o Deployed System: The system is installed in the real-world environment.
o Installation Guide: Documentation to help administrators set up and configure the
system.
o Training Materials: User manuals, training guides, and FAQs for end-users.
• Key Activities o Installing the system in the live environment.
o Performing final checks to ensure the system functions correctly post-deployment.
o Training end-users and system administrators.

6. Maintenance
• Overview: After deployment, the system enters the maintenance phase, where developers
handle any issues, bugs, or new feature requests. Patches and updates are deployed as
necessary to keep the system running smoothly. Ongoing support is provided as part of the
post-deployment service.
• Example: In the hospital management system, maintenance might involve adding new
features as medical regulations change or fixing bugs related to patient data access. Upgrades
to enhance performance or improve user experience may also occur during this phase.
• Deliverables o Patches: Bug fixes and small updates to address system issues.
o System Updates: Periodic updates to improve system performance or add new
features.
o Bug Reports: Documentation of any bugs or issues found during system operation.
• Key Activities o Resolving bugs reported by users. o Providing system upgrades as needed.
o Monitoring system performance to ensure optimal operation.

Page 37 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
Advantages of the Waterfall Model
• Simple and Easy to Understand: The Waterfall model’s sequential nature makes it easy to
follow and manage. Each phase has clearly defined inputs and outputs, reducing confusion.
• Suitable for Small, Well-Defined Projects: It works well when the requirements are clear
from the beginning, with little to no chance of change during the project lifecycle.
• Easier to Manage: Since the phases do not overlap, the project manager can clearly track
progress and allocate resources accordingly.

Disadvantages of the Waterfall Model

• Inflexibility to Changes: Once a phase is completed, it is difficult to go back and make
changes. Any modification in the requirements may require revisiting the design or coding
phases, leading to significant rework.
• Late Discovery of Issues: Testing occurs after the implementation phase, so defects are often
discovered later in the project. Fixing these defects can be costly and time-consuming.
• Not Suitable for Complex, Evolving Projects: The Waterfall model is not ideal for projects
where requirements are likely to change over time or where iterative feedback is necessary
from stakeholders.

When to Use the Waterfall Model

1. Well-Defined Projects: Use the Waterfall model when the project’s requirements are clear,
stable, and unlikely to change during development. o Example: Projects like accounting
software for a small firm, where the functionalities and outputs are well understood from the
outset.
2. Small to Medium-Sized Projects: The model is suitable for smaller projects with
straightforward objectives and clear deliverables. o Example: A website development project
for a local business with predefined content and layout.
3. Short-Term Projects: If the project has a short timeline with a fixed set of deliverables, the
Waterfall model can ensure a systematic and organized approach. o Example: Building a
simple mobile application with a clear set of features.

When Not to Use the Waterfall Model

1. Evolving Requirements: The Waterfall model is not suitable for projects where requirements
are likely to change after development begins. Iterative models like Agile are better for such
projects. o Example: Developing a mobile app where user feedback is essential and
requirements may change frequently.
2. Large and Complex Projects: For complex, long-term projects with multiple layers of
requirements and interactions, the rigidity of the Waterfall model can be a hindrance.
o Example: Building a nationwide healthcare management system that will evolve over
time with government regulations.

Page 38 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
3. High-Risk Projects: The Waterfall model does not handle risks well, as all testing and
feedback occur only after development. Risk-prone projects may benefit from a more flexible
model, such as Spiral. o Example: Projects that involve cutting-edge technologies or high
uncertainty in system integration.

V-Model (Verification and Validation Model)

The V-Model (also known as the Verification and Validation model) is an extension of the
Waterfall model, where each development phase has a corresponding testing phase. The key
emphasis of the V-Model is on verification (ensuring that the system is built correctly according
to design specifications) and validation (ensuring that the correct system is built based on user
requirements). This ensures a systematic approach to both development and testing, with testing
being planned from the start of the project.

The V-Model is highly structured, and the stages follow a V-shaped progression. Each phase in
the development process corresponds to a specific testing phase, ensuring that errors are caught
early, reducing the risk of defects later in the project.

Phases of the V-Model

1. Requirements Analysis User Acceptance Testing (UAT)
• Overview: In this phase, the system's requirements are gathered and documented. Both
functional and non-functional requirements are defined. Functional requirements
describe what the system should do, while non-functional requirements address
performance, security, and usability. This phase is crucial because all subsequent phases
depend on having clear and complete requirements.
• Example: For an e-commerce website, the functional requirements might include features
such as user registration, product search, product catalog, and payment processing.

Page 39 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
Nonfunctional requirements could include system security, load time, and scalability to
handle high traffic.
• Corresponding Testing: The corresponding testing phase for requirements analysis is
User Acceptance Testing (UAT). UAT ensures that the developed system meets the
business requirements and functions as expected in a real-world environment.
o Example for UAT: In the e-commerce website example, UAT would involve
endusers testing if they can register, search for products, add them to their cart, and
make payments successfully. It would also validate that the system performs well
under expected usage scenarios.
• Deliverables:
o Requirement Specifications: A formal document listing all system requirements
in detail.
o UAT Plan: A document that outlines how the user acceptance tests will be
conducted, who will participate, and what criteria will be used to evaluate success.

2. System Design System Testing

• Overview: The System Design phase focuses on creating the high-level design of the
entire system. This includes designing the overall architecture, databases, and module
interactions. At this stage, the system's internal structure is defined, including data flows,
process flows, and communication protocols.
• Example: For the e-commerce website, system design would define how data about users,
products, orders, and payments are stored in the database. It would also outline how
different modules, such as the user registration module and the payment processing
module, interact with each other.
• Corresponding Testing: System Testing ensures that the entire system works as a whole.
It validates that all system components interact properly according to the design and that
the system behaves as expected under different conditions.
o Example for System Testing: In the e-commerce website, system testing would
involve checking if the entire website works as a unified platform — whether users
can register, browse products, place orders, and make payments without issues. It
also tests integration points, such as the interaction between the product catalog and
the payment gateway.
• Deliverables:
o System Design Document (SDD): A document detailing the overall system
architecture, module interaction, database design, and data flow.
o System Test Plan: A plan outlining how the system will be tested, including the
scope of testing, resources required, test cases, and success criteria.

3. Module Design Unit Testing

• Overview: Module Design focuses on the detailed design of individual modules or
components within the system. Each module is designed to fulfill a specific function. This

Page 40 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
phase involves breaking down the system into smaller, manageable modules that can be
developed and tested individually.
• Example: In the e-commerce website, one module might be for processing payments. The
module design phase would involve defining how the payment process works, including
interactions with third-party payment gateways, security protocols for handling sensitive
information, and error-handling procedures.
• Corresponding Testing: Unit Testing focuses on testing individual modules or
components in isolation to ensure that they work as intended. Each module is tested for its
functionality, correctness, and adherence to the design.
o Example for Unit Testing: In the payment processing module, unit testing would
check if the system can accept different payment methods (e.g., credit card, debit
card, and online wallet) and if it handles payment errors, such as declined cards,
appropriately.
• Deliverables:
o Module Design Documents: Detailed design documents for each module,
outlining the functionality, inputs, and outputs.
o Unit Test Results: A record of unit tests conducted, including test cases, results,
and any issues identified.

4. Implementation Integration Testing

• Overview: The Implementation phase is where actual coding takes place. The system
is built based on the design documents, and individual modules are developed. Once
all modules are implemented, they are integrated to form the complete system.
• Example: Developers for the e-commerce website code individual modules such as
user registration, product catalog, and payment processing. Once each module is
implemented, they are integrated to create the full website.
• Corresponding Testing: Integration Testing ensures that the different modules of the
system work together seamlessly. It checks for issues such as data flow between
modules, compatibility, and communication between components. o Example for
Integration Testing: In the e-commerce site, integration testing would involve
checking if user data flows correctly from the registration module to the product
catalog, and whether the payment module correctly processes purchases based on
product selections.
• Deliverables:
o Code: The actual source code for the system, including all modules and
components.
o Integration Test Reports: Detailed reports of integration testing, including test
cases, results, and any defects found.

Advantages of the V-Model

Page 41 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
1. Clear Focus on Verification and Validation: The V-Model emphasizes both verification
(building the system correctly) and validation (building the correct system). This ensures that
all requirements are met and the system functions as intended.
2. Early Detection of Defects: Since testing phases are linked to each development phase,
defects are identified early, reducing the risk of costly fixes in later stages.
3. Structured and Disciplined Approach: The V-Model’s clear structure and sequence of
activities make it highly organized and manageable, ensuring that both development and
testing follow a well-defined process.
4. Thorough Documentation: Each phase of the V-Model requires detailed documentation,
providing clear traceability of requirements, design, and testing. This ensures accountability
and clarity.

Disadvantages of the V-Model

1. Inflexible to Changes: Like the Waterfall model, the V-Model is not flexible. Once the project
moves to the next phase, it is difficult to go back and make changes without affecting the
overall timeline and cost.
2. Rigid Structure: The highly structured nature of the V-Model may not be suitable for projects
with evolving requirements. If new requirements emerge during development, it can be
challenging to accommodate them without revisiting earlier stages.
3. Requires Extensive Documentation: The V-Model requires thorough documentation at every
stage, which can be time-consuming and may increase the administrative burden of the project.
4. Not Ideal for Small or Simple Projects: The level of detail and discipline required by the
VModel may be overkill for smaller, less complex projects. It is better suited for larger projects
where rigorous testing is necessary.

When to Use the V-Model

1. Well-Defined Requirements: The V-Model is best suited for projects where the requirements
are clearly understood and are unlikely to change.
o Example: A project to develop a compliance management system for an organization
with strict legal and regulatory requirements would be a good candidate for the
VModel, as the requirements are stable.
2. Critical Systems: For systems where failures can have severe consequences (e.g., aerospace,
healthcare, or banking systems), the V-Model is ideal due to its strong emphasis on
verification and validation.
o Example: A project to build a banking transaction system would benefit from the V-
Model because the system must be thoroughly tested to ensure accuracy, security, and
reliability.
3. Long-Term, Complex Projects: The V-Model is effective for large, complex projects that
require extensive planning, documentation, and testing. It ensures that each part of the system
is built and tested systematically.

Page 42 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
o Example: Developing an ERP system for a large manufacturing company that
integrates various departments like finance, procurement, and HR.

When Not to Use the V-Model

1. Evolving Requirements: If the project is likely to experience changes in requirements during
the development phase, the V-Model is not suitable, as it does not handle evolving
requirements well.
o Example: A mobile app development project where user feedback continuously shapes
the app’s features and functionality would be better suited to an Agile approach. 2. Small Projects:
The V-Model’s extensive documentation and rigorous testing phases are not always necessary for
smaller

Iterative Model
The Iterative Model is a software development approach where the system is built in small
increments or iterations. Each iteration covers all phases of the software development life cycle
(SDLC), from planning to deployment, allowing the system to evolve over time based on
continuous feedback and refinements. Unlike the Waterfall model, where the process is linear
and sequential, the Iterative Model encourages ongoing development, adjustment, and
improvement after each iteration.
This model is highly suitable for projects where the requirements are not fully understood at the
beginning, or when parts of the system are expected to evolve based on user feedback or testing
results.

Phases of the Iterative Model

1. Planning and Requirements Gathering: The planning phase in the Iterative Model focuses on
defining the goals and requirements for the current iteration rather than gathering all the
system’s requirements upfront. This allows for flexibility and refinement over time. Each
iteration is treated as a mini-project, where the requirements are assessed, prioritized, and
planned in small, manageable portions. The high-level goals for the entire system are outlined,

Page 43 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
but detailed requirements are broken into increments to align with the features being developed
in each iteration.

Example: In a social media application project, the first iteration might focus only on user
registration, basic user profiles, and a news feed. Advanced features like messaging, friend
requests, or profile customization are planned for future iterations. The team defines what
functionality is essential to have a working user registration system and profile management
for the first iteration.

Deliverables
• Iteration Requirements Document: This document outlines specific functional and
nonfunctional requirements for the current iteration.
• Project Timeline and Roadmap: This document provides a high-level view of the
project’s long-term goals, with timelines and milestones for each iteration.

Key Activities
• Gathering requirements that are essential for the current iteration.
• Identifying the key components that will be developed in this iteration. Updating the
project roadmap and aligning short-term goals with long-term objectives.

2. Design: The design phase focuses on creating the architecture and layout for the features that
will be developed during the current iteration. The system design is modular, allowing for
flexibility in future iterations. Each design is created to support incremental development,
meaning future features can easily integrate with existing functionality.

Example: In the first iteration of the social media app, the design might focus on how user
profiles will be stored in a database, how the registration page will be presented, and how
user data flows from the front-end to the back-end. The database design will define where the
user data is stored, and the UI/UX mockups will show how the registration form looks and
behaves.

Deliverables
• Design Documents: These include architectural designs, module designs, and data flow
diagrams for the features developed in the current iteration.
• UI/UX Mockups: These mockups provide a visual representation of the user registration
page and the user profile layout for the iteration.

Key Activities
• Creating a high-level system architecture that supports scalability.
• Designing data structures and user interfaces for the iteration’s features.
Ensuring that the design integrates smoothly with future functionality.

Page 44 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025

3. Implementation (Coding): During the implementation phase, developers focus on coding the
specific functionality outlined in the design documents for the current iteration. This coding is
done incrementally, ensuring that newly developed features integrate seamlessly with the
system's existing components. Developers work collaboratively, often in small teams, to ensure
that the code meets quality standards and is ready for testing.

Example
Developers might work on coding the user registration system for the social media app. This
includes creating a front-end form for users to input their data and writing back-end logic to
validate and store that data in the database. They also implement the news feed, where user
updates can be displayed.

Deliverables
• Source Code: The code developed for the specific features in the current iteration.
• Integrated System Components: These components are integrated into the system,
ensuring they work well with previously developed features.

Key Activities
• Writing code to implement the features outlined in the design.
• Integrating new functionality with the existing system. Conducting peer code
reviews to ensure quality and adherence to coding standards.

4. Testing: In the testing phase, all features developed in the current iteration are rigorously tested
to ensure they function as required. This phase also includes regression testing, which ensures
that the newly added features do not break or interfere with the system's existing functionality.
The system is tested against the requirements outlined in the iteration plan to ensure all
functionalities meet the expected standards.

Example
For the social media app, testers would ensure that users can successfully register, log in, and
create their profiles. They would also check if the news feed updates correctly when users post
content. Regression tests are conducted to verify that adding the registration and news feed
features has not affected any core functionalities in the app.

Deliverables
Test Cases: These test cases cover all aspects of the new features developed in the iteration.
Test Reports: These reports detail the test results, highlighting any bugs or issues discovered
during testing.

Page 45 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
Key Activities
• Running unit tests on individual components.
• Performing system integration tests to ensure the entire system functions as intended.
Documenting any defects and reporting them for resolution before the next iteration begins.

5. Evaluation and Feedback: After testing, the current iteration is reviewed and evaluated by the
development team, stakeholders, and potentially end-users. Feedback is gathered to identify
any improvements or changes that should be implemented in future iterations. This feedback
helps refine the system and adjust the project’s future direction to better meet user needs or
stakeholder expectations.

Example
In the social media app, after the first iteration is deployed, users may report that the
registration process takes too long, or they may request additional functionality like profile
pictures. This feedback is used to adjust the requirements for future iterations, ensuring that
user needs are met as the system evolves.

Deliverables
• Evaluation Report: A detailed summary of the feedback received, the success of the
iteration, and any lessons learned.
• Improvement Plan: A plan that highlights any system refinements or changes based on
feedback.

Key Activities
• Gathering and analyzing feedback from end-users, stakeholders, and team
members.
• Identifying areas of improvement based on the feedback. Reassessing system
requirements and priorities for the next iteration.

6. Deployment: In the deployment phase, the new features developed in the iteration are deployed
into a real or testing environment. Deployment can occur in stages, with some features released
to a test group or beta testers for additional feedback before a full rollout to all users.
Monitoring begins to ensure the system works as expected in the live environment.

Example
The user registration and news feed features from the first iteration of the social media app
might be deployed to a limited group of beta users. This allows the development team to
collect additional feedback and observe how the system performs under real-world conditions
before releasing it to all users.

Page 46 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
Deliverables
• Deployed System/Feature: A live version of the new features developed in the iteration.
• Deployment Guide: Documentation that outlines how the system should be installed and
configured in the deployment environment.

Key Activities
• Deploying the new features to the production or testing environment.
• Monitoring system performance for any potential issues. Ensuring the
system operates correctly in the live environment.

Advantages of the Iterative Model

1. Early Delivery of Working Software: Each iteration produces a working version of the
system, allowing stakeholders and users to see the software early in the development process.
2. Flexible to Changes: The Iterative Model easily accommodates changes in requirements since
the project is broken down into smaller cycles. This allows for adjustments to be made after
each iteration based on feedback or evolving user needs.
3. Continuous Feedback Loop: Users and stakeholders can provide feedback after each
iteration, ensuring the system aligns with their expectations and needs.
4. Risk Management: Risks are identified early in the process, allowing the team to address
them in smaller, manageable parts of the system.
5. Quality Improvement: Continuous testing throughout the development cycle means that
issues and defects are identified early, resulting in higher-quality software at the end of the
project.

Disadvantages of the Iterative Model

1. Incomplete System Until Late in the Process: Because the system is developed
incrementally, the entire system may not be fully functional or available until the later
iterations.
2. Requires Strong Project Management: Constant planning, tracking, and management are
required throughout each iteration, making the process more resource-intensive.
3. Scope Creep Risk: With flexibility comes the risk of scope creep, where additional features
or requirements are added during the iterative process, potentially delaying the project.

When to Use the Iterative Model

• When Requirements Are Incomplete or Evolving: The Iterative Model is ideal when project
requirements are not fully understood at the beginning or are expected to change over time. o
Example: A web-based platform where features are built based on user feedback and industry
trends.
• Large, Complex Projects: For large projects where the risk is high and managing complexity
is essential, the Iterative Model allows for manageable pieces to be developed over time. o

Page 47 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
Example: Enterprise Resource Planning (ERP) systems that involve various modules, such
as finance, HR, and procurement, which can be developed incrementally.
• When Continuous Feedback is Important: The model works well in environments where
frequent feedback from users and stakeholders is necessary.
o Example: Software for e-commerce platforms, where user preferences can rapidly
change.

When Not to Use the Iterative Model

1. Projects with Well-Defined, Fixed Requirements: The Iterative Model is not suitable for
projects where the requirements are fully understood and well-defined from the start. If
there is little to no chance that the requirements will change during the development process,
a more linear model, such as Waterfall, would be more appropriate. The iterative approach
adds unnecessary complexity when requirements are static.
o Example: Developing government compliance software, where the specifications are
dictated by well-defined regulations, making iterations unnecessary since the
requirements are unlikely to evolve.
2. Short-Term Projects with Tight Deadlines: The iterative process can be time-consuming
due to the repeated cycles of planning, design, development, testing, and feedback. For projects
with strict deadlines and short timelines, the iterative model may introduce delays. A more
streamlined approach that focuses on delivering the entire product in one go is better for
shortterm projects.
o Example: A corporate event website with a fixed deadline, where the scope is small,
and the main goal is to launch it quickly, without the need for multiple iterations or
refinements.
3. Projects with Low Risk and Simple Scope: The Iterative Model’s complexity is often
unnecessary for simple, low-risk projects. If the project has minimal complexity, and there is
no need for risk management or extensive testing and feedback loops, an iterative approach
may introduce overhead that is not required.
o Example: Developing a basic calculator app or a static company landing page that
involves minimal features and has no complex interactions or risks.
4. Small, Budget-Constrained Projects: Iterative development requires ongoing revisions,
testing, and feedback gathering, which can consume resources. For small projects with
limited budgets, the cost of managing multiple iterations may outweigh the benefits. A simpler
model that delivers a working product in a single phase can be more cost-effective.
o Example: A small business developing a brochure website where the focus is on
keeping development costs low and delivering a product that meets basic requirements.
5. Projects Where Predictability is Crucial: The Iterative Model is inherently flexible, with
evolving requirements and multiple development cycles. This flexibility can make it difficult
to predict final delivery dates, project timelines, and costs. For projects where strict
predictability is necessary—such as government contracts or large construction projects—an
iterative approach may introduce uncertainty that could be problematic. o Example: A large

Page 48 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
infrastructure project where clients need a fixed timeline and cost estimates upfront, and
there is little room for changes during the project.
6. Projects with Limited Stakeholder Involvement: The Iterative Model relies heavily on
regular feedback from stakeholders to guide each iteration. If stakeholders are not available
to participate actively in the feedback and refinement process, the model may not function
effectively. Limited or delayed feedback can hinder the project’s progress.
o Example: A government IT project where the stakeholders are not available for
frequent feedback and review sessions due to bureaucratic processes or time
constraints.
7. Highly Regulated Projects Requiring Extensive Documentation: Iterative models tend to
focus more on delivering functional software rather than comprehensive documentation. For
projects that require extensive documentation (e.g., for regulatory approval or compliance),
the iterative approach may not be the best fit, as the focus on continuous iteration may conflict
with the need for detailed documentation at each step.
o Example: Developing medical device software, where every step of the development
process requires detailed documentation to meet regulatory standards.

Agile Model
The Agile model is an iterative and incremental approach to software development that focuses on
flexibility, customer feedback, and adaptability. Instead of developing the entire system at once,
the project is broken down into small units called sprints (typically lasting 2-4 weeks). Each sprint
produces a working, usable version of the product with a specific set of features. Agile emphasizes
collaboration between cross-functional teams and customers, allowing frequent adaptations to
changing requirements.

Agile is often used when the end-product is not entirely clear at the outset or when continuous
feedback from users and stakeholders is crucial. Unlike traditional models (e.g., Waterfall), Agile
provides working features of the system after each sprint, allowing users to interact with the
product early and provide feedback, leading to incremental improvements.

Page 49 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025

Phases of the Agile Model

1. Planning: The Planning phase of Agile focuses on defining high-level goals for the project
and specific objectives for each sprint. Instead of gathering exhaustive requirements upfront,
Agile teams define user stories—short, simple descriptions of a feature from the user’s
perspective. The scope of each sprint is determined by these user stories, which go into the
sprint backlog. The product owner, in collaboration with the development team, prioritizes
these stories based on their importance and the team’s capacity for the sprint.
Example: In a mobile banking application project, the first sprint might include user stories
like "As a user, I want to check my account balance" or "As a user, I want to transfer
funds to another account". These stories define the goals for the sprint, and planning focuses
on how to implement these features.

Deliverables
• Sprint Backlog: A prioritized list of user stories and tasks to be completed during the
sprint.
• User Stories: Simple descriptions of the features from the end-user’s perspective, each
defining an individual requirement for the sprint.

Key Activities
• Defining and prioritizing user stories.
• Identifying team capacity and assigning tasks. Determining the
sprint’s duration and high-level goals.

2. Design and Development: Once planning is complete, the team moves on to the Design and
Development phase, where the actual coding and feature implementation takes place. Each
feature from the sprint backlog is developed incrementally, focusing on producing functional

Page 50 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
components by the end of the sprint. Agile teams work collaboratively to ensure rapid
development, and features are continuously integrated into the evolving product.

Example
In the first sprint of the mobile banking app, the team might focus on developing the login
feature and account balance display. Developers work on building the back-end logic for
user authentication and creating a simple UI to display account balances.

Deliverables
• Functional Code for the Sprint: Completed, functional code that meets the user stories
defined in the sprint backlog.
• UI Mockups: Visual representations of user interfaces for the current sprint’s features,
such as the login screen and account balance interface.

Key Activities
• Writing and testing code for the user stories.
• Collaborating with designers and testers to ensure that the functionality aligns with user
requirements.
• Integrating new features into the existing system, ensuring smooth functioning with
previously developed components.

3. Testing: In Agile, testing is integrated throughout the development process, but a dedicated
testing phase occurs at the end of each sprint. The development team conducts unit testing,
integration testing, and user acceptance testing (UAT) to ensure that the new features work
as expected and don’t negatively impact the existing system. Agile’s frequent testing helps
catch issues early and ensures that the product remains stable as new features are added.
Example
In the mobile banking app, testers would check whether the login feature works correctly,
including validating user credentials and ensuring the secure handling of sensitive data. They
would also test whether the account balance is displayed accurately and updated in real time.

Deliverables
• Test Cases: Specific scenarios for testing the new features developed during the sprint,
covering all edge cases and functionalities.
• Test Results: A report on the outcome of testing, including any identified bugs or issues
that need to be fixed.

Key Activities
• Conducting unit tests on newly developed features.

Page 51 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
• Running integration tests to ensure smooth interaction between new and existing
components. Performing user acceptance testing to verify that the new features meet user
requirements.

4. Review: At the end of each sprint, the team conducts a review meeting with stakeholders and
users to present the completed features and gather feedback. This is a critical phase of Agile,
as it allows the team to make adjustments based on stakeholder input before moving on to the
next sprint. The team demonstrates what was accomplished during the sprint, and the product
owner gathers suggestions for future improvements or modifications.

Example
After the sprint focused on login and account balance features, the team presents these to
the product owner and stakeholders in the mobile banking app project. Feedback might
include requests for improvements to the login process or suggestions to enhance the user
interface for displaying account information.

Deliverables
• Sprint Review Document: A summary of the sprint’s completed features and a record of
feedback gathered from stakeholders.
• Feedback: Comments, suggestions, and ideas for improvement that will be considered in
future sprints.

Key Activities
• Demonstrating the completed features to stakeholders.
• Gathering feedback and discussing what went well and what needs improvement.
Adjusting the backlog to reflect new priorities based on the feedback.

5. Repeat (Next Sprint): Once the current sprint is completed, the next sprint begins. The Agile
process is cyclical, meaning each sprint follows the same process of planning, design,
development, testing, and review. The backlog is adjusted, new user stories are prioritized, and
the team continues working until the full product is developed. This iterative approach allows
for constant refinement of the product based on user feedback and evolving requirements.
Example: In the second sprint of the mobile banking app, based on feedback from the first
sprint, the team might work on enhancing the fund transfer feature. This includes developing
the ability to select recipients, input amounts, and complete secure transactions.

Deliverables
• New Features: Completed features for the second sprint, such as fund transfer
functionality.
• Continuous Integration: New features are continuously integrated into the existing
system to ensure smooth operation.

Page 52 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025

Key Activities
• Reviewing the backlog and adjusting priorities based on feedback.
• Planning the next sprint with new user stories and objectives.
Continuously integrating and refining the system with each sprint.

Advantages of the Agile Model

1. High Adaptability to Changing Requirements: Agile’s incremental nature allows for
flexibility and adaptability. If customer requirements change mid-project, the development
team can adjust priorities and incorporate changes in future sprints without significantly
disrupting the overall process.
2. Continuous Delivery and Feedback: Agile delivers working software early and frequently,
allowing users to provide continuous feedback. This enables teams to make improvements
based on real-world feedback, leading to a product that better meets user needs.
3. Improved Customer Satisfaction: By involving the customer in each sprint review, Agile
fosters closer collaboration and communication. Frequent updates help build trust, as
customers can see tangible progress and influence the development process.
4. Risk Management: Since each sprint delivers a working component, Agile minimizes risks
by addressing them early. This allows the team to identify potential issues and make
adjustments before they grow into larger problems.
5. Efficient Use of Resources: Agile allows teams to focus on the most important tasks first.
Since work is done in small, manageable chunks, the team can avoid spending time on
unnecessary features and prioritize those that provide the most value.

Disadvantages of the Agile Model

1. Requires Constant Customer Involvement: Agile relies heavily on customer feedback and
engagement throughout the project. This can be time-consuming for both customers and the
development team, and it may be challenging to maintain continuous involvement over long
periods.
2. Potential for Scope Creep: Because Agile encourages flexibility, there is a risk of scope
creep—the gradual expansion of project goals and requirements. Without careful management,
the project may deviate from its original objectives, leading to delays and budget overruns.
3. Not Suitable for All Projects: Agile works best for projects where the end product is not
welldefined upfront or when requirements are expected to evolve. For projects with a fixed
set of requirements, the flexibility of Agile might not be necessary, and a more structured
approach like the Waterfall model may be better.
4. Requires Skilled Teams: Agile development requires cross-functional teams that work
closely together, communicate effectively, and are able to adapt quickly. If the team lacks the
necessary skills or collaboration abilities, the Agile approach may not succeed.

Page 53 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
When to Use the Agile Model
1. Projects with Evolving or Uncertain Requirements: Agile is particularly well-suited for
projects where the requirements are likely to change or are not fully defined at the start. The
iterative nature of Agile allows the team to adapt as new requirements or changes emerge,
providing flexibility in planning and execution. o Example: Developing a mobile app for a
startup, where new ideas and features may evolve based on market feedback and user
preferences.
2. Customer-Centric Projects: Agile thrives in environments where continuous customer
feedback is necessary. If the customer needs to be heavily involved in the development
process, reviewing progress after each sprint, and making suggestions for improvements, Agile
is the best choice. o Example: Creating a custom enterprise solution for a client, where the
client’s input is needed at regular intervals to ensure the product meets business requirements.
3. Projects with Frequent Deliverables: Agile is designed to deliver working software at the
end of every sprint. It works best in projects where it’s critical to have a working version of
the software early in the process, and each iteration brings the team closer to the final product.
o Example: Building a SaaS (Software as a Service) platform, where continuous delivery of
new features and improvements keeps customers engaged.
4. Complex, Large-Scale Projects: Agile can handle complex and large projects by breaking
them into manageable pieces. The project is developed in small, incremental releases, which
helps mitigate risks and ensures the system is built efficiently over time.
o Example: Developing a large e-commerce platform where multiple teams work on
different features such as payment integration, inventory management, and user
profiles.
5. Projects Requiring Risk Management: Agile minimizes risks by delivering a working
version of the product early in the project. Problems are discovered early on and addressed
before they become major issues, reducing the risk of failure. o Example: Developing a
healthcare app that integrates with various external systems, where risk management and
compliance are critical throughout development.
6. Cross-Functional Team Collaboration: Agile works well when there is a cross-functional
team that can work together effectively. Each sprint requires collaboration between
developers, testers, designers, and product managers to ensure that every aspect of the system
is considered and built incrementally.
o Example: A web development team working closely with marketing and customer
service teams to create a user-friendly website.

When Not to Use the Agile Model

1. Projects with Well-Defined, Fixed Requirements: If the project requirements are clear,
welldefined, and unlikely to change throughout the development process, Agile may not be the
best choice. In such cases, a more structured model like the Waterfall model would be more
efficient, as it follows a linear process that focuses on meeting fixed requirements.

Page 54 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
o Example: Developing compliance software for a financial institution, where the
requirements are driven by regulations that are clearly outlined from the start.
2. Short-Term Projects with Tight Deadlines: Agile's iterative approach may not work well for
projects with short deadlines or those that need to be completed in one go. Agile focuses on
continuous improvement and iterative releases, which may add unnecessary overhead to
shortterm projects.
o Example: Building a promotional website for a marketing campaign that has to
launch by a fixed date. In this case, the focus would be on completing the project as
quickly as possible.
3. Projects with Limited Customer Involvement: Agile depends heavily on constant
customer collaboration. If the customer cannot be involved in regular sprint reviews or is
unavailable for frequent feedback, it can be difficult to use Agile effectively. Customer input
is crucial for setting priorities and ensuring the product meets their expectations.
o Example: A government software project where the stakeholders are not readily
available to review progress or provide feedback during the development process.
4. Projects Requiring Extensive Documentation: Agile focuses on working software over
comprehensive documentation. If the project requires extensive documentation for
compliance, legal, or regulatory purposes, Agile may not provide the structure needed for
producing and managing that documentation. o Example: Developing a mission-critical
aerospace system that requires extensive documentation, certification, and approvals at every
stage.
5. Projects Requiring Clear Milestones and Predictable Costs: If the project’s timeline, costs,
and deliverables need to be predicted accurately, Agile may not be the best approach. Agile’s
iterative and flexible nature means the scope can change frequently, making it harder to
estimate the total time and budget needed to complete the project.
o Example: A large construction software project with a strict budget and a fixed
timeline, where cost overruns could be a major issue.
6. Teams Without Adequate Agile Experience: Agile requires a skilled and experienced team
that can collaborate effectively, manage their own tasks, and communicate openly. If the team
is unfamiliar with Agile methodologies or lacks the discipline needed for self-organization, the
project may face significant challenges. o Example: A team of developers who are used to
following a Waterfall approach and may struggle with the flexibility and self-management
Agile demands.

Scrum Model (a Type of Agile)

Scrum is a specific Agile framework used to manage and control software development. It
focuses on delivering small, incremental improvements to the product in a time-boxed manner
through sprints (typically 2-4 weeks). Scrum is based on three primary pillars: transparency,
inspection, and adaptation. It emphasizes teamwork, accountability, and continuous progress
towards well-defined goals.

Page 55 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
Scrum relies heavily on collaboration between a cross-functional team led by the Scrum Master,
who ensures the team follows Scrum practices. The Product Owner is responsible for managing
the product backlog and ensuring the team builds the most valuable features first, while the
Development Team is self-organizing and responsible for delivering the increments.

Key Components of the Scrum Model

1. Scrum Team o Product Owner: Defines and prioritizes the product backlog.
o Scrum Master: Facilitates the Scrum process, removes obstacles, and ensures that the
team adheres to Scrum practices.
o Development Team: The cross-functional team responsible for building the product
increment during each sprint.
2. Product Backlog o An ordered list of features, bugs, and tasks that need to be
completed. It evolves as the project progresses, with the Product Owner constantly refining
and prioritizing items based on value and feedback.
3. Sprint o A time-boxed iteration, usually lasting 2-4 weeks, during which the Scrum team
works to complete a set of tasks from the backlog. The sprint culminates in a potentially
shippable product increment.
4. Sprint Backlog o The subset of the product backlog that the Scrum team commits to
completing within the current sprint. It is created during sprint planning and reflects the team's
capacity for that iteration.
5. Daily Scrum (Stand-up Meetings) o A short, daily meeting (usually 15 minutes) where the
development team synchronizes their work, discusses progress, and identifies any blockers.
Each team member answers three key questions:
▪ What did I do yesterday?
▪ What will I do today?
▪ Are there any impediments in my way?
6. Sprint Review o A meeting at the end of each sprint where the team demonstrates the work
completed and gathers feedback from stakeholders and the Product Owner. The sprint review
allows the team to assess the increment's value and decide what to focus on next.

Page 56 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
7. Sprint Retrospective
o A post-sprint meeting focused on process improvement. The Scrum team reflects on the
sprint, discussing what went well and what could be improved in the next sprint.

Phases of the Scrum Model

1. Product Backlog Creation: The Product Backlog is a prioritized list of all the work that needs
to be done for the product. The Product Owner manages this backlog, adding user stories and
defining features based on customer needs. Items in the backlog are continuously refined,
estimated, and re-prioritized as the project progresses.

Example: For an e-commerce platform, the Product Owner might add items like user
registration, product catalog, shopping cart functionality, and payment integration to the
product backlog. These items are then prioritized based on the project’s goals and customer
feedback.

Deliverables
• Product Backlog: A complete list of features, bugs, and tasks to be addressed, organized
by priority.
• User Stories: Brief, user-focused descriptions of the functionality, such as "As a user, I
want to search for products by category."

Key Activities
• Defining and prioritizing user stories and tasks.
• Estimating the size and complexity of backlog items. Continuously refining
the backlog based on feedback and evolving needs.

2. Sprint Planning: Before the start of each sprint, the team holds a sprint planning meeting to
decide what work will be done during the upcoming sprint. The team selects items from the
Product Backlog to create the Sprint Backlog, which contains tasks the team commits to
completing by the end of the sprint. The team estimates what they can achieve based on
capacity and the complexity of each task.

Example: In the first sprint of the e-commerce platform, the team might choose to work on
user registration and product catalog features. These tasks are added to the sprint backlog,
and the team commits to delivering these features in two weeks.

Deliverables
• Sprint Backlog: A list of items the team commits to completing in the sprint.
• Sprint Goal: A clear objective for the sprint, such as "Enable users to create accounts
and view products."

Page 57 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
Key Activities
• Selecting user stories from the product backlog.
• Breaking down user stories into tasks. Estimating the effort
required for each task.

3. Sprint Execution (Development and Daily Scrum): During the sprint, the development team
works on completing the tasks in the sprint backlog. The team holds a Daily Scrum (stand-up)
to synchronize progress, address any blockers, and adjust the sprint backlog if necessary. The
Scrum Master facilitates these meetings and ensures the team stays on track.

Example: The development team might spend the first few days building the user registration
system, followed by work on the product catalog feature. Each day, the team meets to discuss
progress, resolve issues, and plan the day’s work.

Deliverables
Working Product Increment: A shippable piece of the product, such as the user registration
and product catalog features, developed and integrated into the system. Daily Scrum
Report: Informal progress tracking based on daily discussions.

Key Activities
• Developing code for the features in the sprint backlog.
• Holding daily Scrum meetings to discuss progress and obstacles.
Continuously integrating and testing the code to ensure functionality.

4. Sprint Review: At the end of the sprint, the team holds a Sprint Review to demonstrate the
work completed. This meeting is an opportunity for the Product Owner and stakeholders to
review the increment and provide feedback. The team discusses whether the sprint goal was
met and what additional features or improvements should be prioritized next.

Example: After completing the first sprint for the e-commerce platform, the team
demonstrates how users can create accounts and browse the product catalog. Stakeholders
provide feedback on the user interface and suggest improvements to the search functionality.

Deliverables
• Sprint Review Document: A record of what was accomplished during the sprint and
feedback from stakeholders.
• Working Product Increment: A completed, working feature that can be deployed or
tested
further.

Page 58 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
Key Activities
• Demonstrating the completed work to stakeholders.
• Gathering feedback on the product increment. Adjusting the product
backlog based on new feedback and priorities.

5. Sprint Retrospective: After the Sprint Review, the Scrum team holds a Sprint Retrospective
to evaluate their own performance during the sprint. The focus is on process improvement—
what went well, what didn’t go as expected, and how the team can improve for the next sprint.
This phase ensures continuous improvement and team development.

Example: In the e-commerce project, the team might discuss how the user registration
feature was delayed due to unclear requirements and suggest better communication with the
Product Owner. They might also agree to improve their code review process to avoid
integration issues.

Deliverables
• Retrospective Report: A summary of the lessons learned and actionable steps for
improvement.
• Action Plan for Next Sprint: A list of process changes or adjustments to be made in the
next sprint.

Key Activities
• Reflecting on the sprint’s successes and challenges.
• Identifying areas for improvement. Planning changes to enhance
team performance in the next sprint.

6. Repeat (Next Sprint): Once the current sprint is completed and the team has conducted their
review and retrospective, the cycle repeats with the next sprint. The team begins planning for
the next set of features from the product backlog, refining their approach based on what was
learned from the previous sprint.

Example: In the next sprint, the e-commerce team might focus on implementing the shopping
cart feature, taking into account the feedback from the previous sprint and ensuring smoother
communication and task tracking.

Deliverables
New Features: Additional features developed in the next sprint. Process
Improvements: Changes made to improve team efficiency and product quality.

Key Activities
• Reassessing and adjusting the product backlog.

Page 59 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
• Planning the next sprint with improved processes. Continuing the
iterative cycle until the product is complete.

Advantages of the Scrum Model

1. Adaptability to Changing Requirements: Scrum allows for frequent inspection and
adaptation of the product, making it highly flexible. Teams can quickly adapt to changing
requirements or customer needs because the project is broken into short sprints with defined
goals.
o Example: In a mobile app project, if user feedback reveals the need for a new feature
or a change in design, it can be added to the product backlog and prioritized in the next
sprint without disrupting the entire project.
2. Continuous Delivery of Working Software: Scrum focuses on delivering a working product
increment at the end of every sprint. This ensures that the customer or stakeholders always
have a usable version of the product and can provide feedback, which improves overall product
quality.
o Example: In a SaaS development project, the team delivers new features every 2-4
weeks, keeping customers engaged and ensuring that they always have access to the
latest updates.
3. Improved Customer Satisfaction: Scrum ensures that customers or stakeholders are actively
involved throughout the development process. Regular sprint reviews and feedback loops help
align the product with customer expectations, leading to higher satisfaction. o Example: A
custom software project where the client is regularly updated, allowing them to refine
requirements and ensure the product meets their needs.
4. Focus on High-Value Features: Scrum prioritizes features in the product backlog based on
value. The team always focuses on delivering the most important and valuable features first,
ensuring that the highest-impact work is completed early.
o Example: For an e-commerce platform, the team might prioritize the shopping cart
and payment integration features first, as they provide the most business value.
5. Enhanced Team Collaboration and Accountability: Scrum promotes strong
crossfunctional collaboration. Teams work together closely, and daily Scrum meetings
ensure everyone stays aligned. The self-organizing nature of Scrum teams also enhances team
ownership and accountability.
o Example: In a game development project, designers, developers, and testers
collaborate daily to ensure all aspects of the game are developed in sync, reducing
communication gaps.
6. Transparency and Clear Communication: Scrum ensures transparency through regular
meetings, such as Daily Scrums and Sprint Reviews. Everyone is aware of the project’s
progress, and any issues are addressed promptly.
o Example: In a web development project, daily meetings allow team members to
discuss progress, share any blockers, and adjust their plans as needed to ensure smooth
delivery.

Page 60 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
7. Risk Mitigation: Scrum’s incremental delivery minimizes risk by regularly reviewing
progress and incorporating feedback. Problems are identified early in the development process,
reducing the likelihood of significant issues at later stages.
o Example: In a financial software development project, regular sprint reviews help
identify bugs early on, ensuring that the final product is secure and compliant with
regulations.

Disadvantages of the Scrum Model

1. Requires High Customer Involvement: Scrum relies heavily on continuous customer or
stakeholder engagement. If the customer is unavailable or unable to provide regular feedback,
it can disrupt the process and slow down decision-making.
o Example: In a government project, if stakeholders are not available for regular sprint
reviews, it can delay progress and create ambiguity around priorities.
2. Scope Creep Risk: Because Scrum is so flexible, there is a risk of scope creep, where new
requirements are continuously added, potentially causing the project to deviate from its original
goals. Without strong control over the product backlog, the project can expand beyond initial
expectations.
o Example: In a marketing software project, if the client keeps adding new features
during sprint reviews without properly prioritizing them, it can lead to delays and cost
overruns.
3. Requires Skilled and Committed Teams: Scrum depends on the self-organization of teams
and requires that team members take responsibility for their work. Teams that lack experience
in Agile methodologies or are not fully committed to the Scrum process may struggle to
collaborate effectively.
o Example: A team used to the Waterfall model may face challenges adjusting to
Scrum, especially if they are not used to managing their own tasks or communicating
openly in daily Scrum meetings.
4. Difficult for Long-Term, Predictable Planning: Scrum’s iterative nature can make longterm
planning difficult. Since priorities can shift from sprint to sprint, it’s harder to predict project
completion dates and long-term budgeting, which can be problematic for stakeholders who
require fixed timelines or budgets.
o Example: In a large enterprise software project, stakeholders might find it
challenging to estimate when all features will be completed, leading to concerns about
overall project timelines.
5. Not Suitable for Small, Simple Projects: For small projects with limited scope and a clear
set of requirements, the overhead of Scrum’s processes (such as daily stand-ups, sprint reviews,
and retrospectives) might be unnecessary and could slow down progress. o Example:
Developing a simple corporate website with fixed requirements may not need the iterative
and incremental nature of Scrum, as the entire project can be planned and executed in a linear
fashion.

Page 61 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
6. Potential for Frequent Rework: Due to the continuous inspection and feedback loops, there
may be frequent revisions or rework of previously completed features. While this flexibility
can be beneficial, it can also lead to inefficiencies and delays if the team repeatedly revisits
certain aspects of the project. o Example: In a UI/UX redesign project, the team may have to
redo sections of the interface multiple times based on ongoing feedback, delaying overall
progress.
7. Scrum is Not Ideal for Complex Dependencies: Scrum can struggle in projects that have
complex dependencies between teams or features. The iterative nature of Scrum may not
account for certain external factors, which can cause bottlenecks or delays when features need
to be integrated with other systems or teams.
o Example: In a multinational project where teams in different time zones or
organizations need to coordinate, Scrum’s short sprints might not align with the
dependency-heavy nature of the project.

When to Use the Scrum Model

1. Projects with Evolving or Unclear Requirements: Scrum works well when the
requirements are expected to change over time. Since Scrum follows an iterative approach,
it allows teams to adjust and reprioritize tasks based on continuous feedback from users or
stakeholders. o Example: A mobile app development project where users' needs and market
trends may evolve, requiring frequent updates and modifications.
2. Complex Projects with Undefined Scope: For large, complex projects where the full scope
isn’t known at the beginning, Scrum helps by allowing the team to build the product
incrementally, refining and clarifying the scope as the project progresses.
o Example: Developing a SaaS (Software as a Service) product, where the full feature
set and user requirements might evolve after initial versions are tested and released.
3. Projects Requiring Frequent Customer Feedback: Scrum encourages continuous customer
involvement throughout the development process. This makes it ideal when stakeholders need
to provide frequent feedback on the product, ensuring that their input is incorporated into
every sprint. o Example: A custom software project for a client where the client provides
ongoing feedback and wants regular updates on progress.
4. Projects with Cross-Functional Teams: Scrum is designed for cross-functional teams
where members from different disciplines (development, testing, design) collaborate closely.
It encourages strong communication and teamwork to solve complex problems quickly. o
Example: A website development team where front-end developers, back-end engineers, and
designers work together to develop features iteratively.
5. High-Priority, High-Value Deliverables: When a project’s success depends on delivering
high-value features quickly, Scrum is a great choice. Scrum allows the team to prioritize the
most critical features and deliver working software early and often.
o Example: Building a minimum viable product (MVP) for a startup, where delivering
a core set of high-priority features quickly is essential to get user feedback or attract
investors.

Page 62 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
6. Projects that Require Frequent Deliverables: Scrum excels when there is a need for
frequent, incremental delivery of working software. Sprints (typically 2-4 weeks) ensure
that the team delivers functional, shippable products at regular intervals.
o Example: An e-commerce platform where new features such as payment gateways
or product search filters are continuously added over time.

When Not to Use the Scrum Model

1. Projects with Well-Defined, Fixed Requirements: Scrum is not ideal for projects where the
requirements are fixed upfront and unlikely to change. In such cases, a more structured
approach like the Waterfall model might be more efficient, as it focuses on completing the
project in a linear fashion with no need for frequent feedback or revisions.
o Example: Developing a regulatory compliance system where the requirements are
driven by well-defined legal regulations that do not change during the project.
2. Projects with Tight Deadlines and Limited Scope: Scrum might not be the best choice for
short-term projects with tight deadlines, where the scope is limited, well-understood, and
must be completed quickly. Scrum’s iterative process might slow things down due to sprint
cycles, reviews, and retrospectives.
o Example: Building a simple marketing website for a product launch with a fixed
deadline where the goal is to get the project completed as soon as possible without
multiple iterations.
3. Projects Requiring Extensive Documentation: Scrum focuses more on delivering working
software than on comprehensive documentation. If the project requires detailed, structured
documentation due to legal, regulatory, or contractual requirements, a more traditional
approach like Waterfall or V-Model might be more suitable. o Example: Developing software
for a medical device that requires rigorous documentation for regulatory approval and
certification.
4. Projects with Low Customer Involvement: Scrum relies heavily on frequent customer or
stakeholder involvement. If the client or stakeholders cannot dedicate the time to participate
in sprint reviews or provide regular feedback, Scrum may not work effectively.
o Example: A government software project where stakeholders are not available for
regular feedback due to limited availability or bureaucratic processes.
5. Projects with Clear and Unchanging Milestones: For projects where the scope is
welldefined and the project plan is unlikely to change, Scrum’s flexibility can become
unnecessary overhead. If all project milestones are clear and fixed from the start, a linear model
might be more appropriate. o Example: Developing mission-critical software for an
aerospace company, where the project follows strict milestones and must adhere to a pre-
defined plan.
6. Teams or Organizations Lacking Scrum Experience: Scrum requires a dedicated,
experienced team that understands Agile principles and Scrum practices. If the team or
organization has little experience with Agile or Scrum, adopting it without proper training or
experience can lead to confusion, lack of coordination, or missed deadlines.

Page 63 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
o Example: A development team used to following a Waterfall approach, where the
transition to Scrum may require significant training, adjustments, and time.

Spiral Model
The Spiral Model is a risk-driven, iterative approach to software development that combines
elements of both the Waterfall and Iterative models. It is particularly well-suited for large,
complex, and high-risk projects. The model emphasizes risk management, with each cycle or
"spiral" involving planning, risk analysis, engineering, and evaluation. This model allows for
continuous refinement of the product, enabling teams to manage risks more effectively while
addressing system development incrementally.

The Spiral Model is ideal for projects where uncertainty is high and continuous assessment is
necessary to mitigate risks. Unlike linear models like Waterfall, the Spiral Model is iterative and
flexible, allowing for adjustments at any point based on feedback, new requirements, or emerging
risks.

Phases of the Spiral Model

The Spiral Model consists of several cycles, with each cycle going through the following key
phases:

1. Planning: In the Planning phase, the objectives for the current iteration (or spiral) are
identified. The team determines what part of the system will be developed or refined in this
cycle. The planning also includes identifying constraints, setting project goals, selecting
alternatives, and determining the scope of work. This phase sets the foundation for the cycle
and informs how risk analysis and development will proceed.

Example
In the development of a medical records system, the planning phase might focus on
understanding the requirements for data security, patient privacy, and system accessibility.

Page 64 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
The team might prioritize features such as secure login mechanisms and encryption of patient
data.

Deliverables
• Planning Document: Outlines the goals, scope, and constraints for the current cycle.
• Risk Mitigation Strategies: A set of strategies outlining how potential risks will be
handled during the cycle.

Key Activities
• Identifying goals for the current iteration.
• Defining the scope and objectives.
• Considering alternatives and selecting the best approach. Outlining constraints and risk
mitigation strategies.

2. Risk Analysis: The Risk Analysis phase is the core of the Spiral Model. In this phase, the team
evaluates the potential risks that could impact the project or system development. Risks are
identified, assessed for their likelihood and potential impact, and risk mitigation plans are
created. The goal is to proactively address any challenges that could arise during the
development process, ensuring that risks are minimized or eliminated.

Example: For the medical records system, risks might include data breaches,
noncompliance with healthcare regulations (such as HIPAA in the U.S.), or system
downtime affecting patient access. The team would assess the severity of these risks and
propose mitigation strategies, such as implementing encryption standards, regular security
audits, and backup systems.

Deliverables
• Risk Assessment Report: A detailed analysis of potential risks, their severity, and their
likelihood.
• Risk Mitigation Plans: A document outlining strategies to mitigate or resolve identified
risks.

Key Activities
• Identifying potential risks.
• Assessing the severity and probability of each risk.
• Developing risk mitigation strategies to address risks during development.
• Reviewing and adjusting the risk mitigation plan throughout the project.

3. Engineering: The Engineering phase is where the actual development and testing take place.
The team designs, codes, and tests the system components based on the objectives outlined in
the Planning phase. This phase produces functional parts of the system, which are later
Page 65 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
integrated into the whole. Engineering in the Spiral Model occurs incrementally, so with each
cycle, more of the system is developed and refined.

Example: In the medical records system, the engineering phase might involve building the
secure login mechanism or encryption features for storing patient records. The team might
also develop the user interface for doctors to access patient data. Testing is conducted to
ensure that these components meet the requirements and are free from vulnerabilities.

Deliverables
• Code and System Components: Functional software modules that fulfill the objectives
set for the cycle.
• Test Results: Detailed results from testing the developed features, including unit tests,
integration tests, and security tests.

Key Activities
• Developing code for system features.
• Conducting unit, integration, and system-level tests.
• Reviewing the code and test results to ensure the system meets the required standards.
Refining components based on testing outcomes.

4. Evaluation: At the end of each cycle, the system is evaluated by stakeholders, including users,
developers, and product owners. The feedback gathered during this phase is crucial for refining
the product and setting new goals for the next cycle. This continuous evaluation helps ensure
that the system evolves in alignment with user needs and project objectives. It also allows the
team to identify any adjustments or improvements necessary before proceeding with the next
iteration.

Example: After developing the login mechanism for the medical records system,
stakeholders, such as healthcare professionals and security experts, might evaluate the feature.
Feedback could include concerns about the usability of the login system or suggestions to
enhance security protocols. This feedback informs the next cycle, allowing the team to make
necessary changes or add additional features.

Deliverables
• Evaluation Report: A document summarizing feedback from stakeholders and the overall
success of the cycle.
• Feedback and Lessons Learned: Insights gathered from the evaluation that will inform
the next cycle.

Key Activities
• Gathering feedback from stakeholders.

Page 66 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
• Evaluating the system against the objectives set in the Planning phase.
• Identifying areas for improvement and adjustments. Setting goals for the next
cycle based on feedback and lessons learned.

Advantages of the Spiral Model

1. Focus on Risk Management: The Spiral Model’s focus on continuous risk analysis makes
it ideal for high-risk projects. Risks are identified and addressed early in the project lifecycle,
reducing the likelihood of major issues later on.
o Example: In the development of a banking system, potential risks like data breaches
or regulatory non-compliance are identified and mitigated in each cycle, reducing
long-term project risks.
2. Highly Adaptable and Iterative: The Spiral Model is flexible, allowing teams to adapt based
on new information, risks, or feedback. Since the system is developed incrementally,
adjustments can be made at the end of each cycle, which helps prevent costly changes later on.
o Example: A telecommunications infrastructure project might start with basic
network features, allowing the team to adjust their approach based on feedback from
regulators and engineers in each cycle.
3. Emphasizes Customer Feedback: Stakeholder involvement is an integral part of the Spiral
Model. Frequent evaluations and feedback help ensure that the product aligns with customer
expectations and business needs. o Example: In the development of an online learning
platform, feedback from teachers and students can be incorporated into each spiral to refine
features like course content delivery or user interaction tools.
4. Improves Product Quality: Because each cycle includes a development and testing phase,
the system is evaluated and improved with each iteration. Continuous testing helps identify
issues early, resulting in higher product quality.
o Example: A healthcare software company can continuously test and refine features
like patient record management to meet industry standards and avoid security issues.
5. Efficient Use of Resources: By focusing on high-risk areas first, the Spiral Model allows
teams to prioritize resources where they are needed most. This helps avoid wasting resources
on low-priority or non-critical features early in the project.
o Example: A large-scale infrastructure project may allocate more resources to ensure
safety features in the early spirals, reducing the risk of failure.

Disadvantages of the Spiral Model

1. Expensive and Resource-Intensive: The repeated cycles of planning, risk analysis,
development, and evaluation can make the Spiral Model costly in terms of both time and
resources. Projects may require significant investment to manage these cycles effectively.
o Example: A defense project that uses the Spiral Model might have high costs
associated with continuous risk analysis, regulatory evaluations, and testing, making
the overall project expensive.

Page 67 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
2. Requires Specialized Expertise in Risk Management: The success of the Spiral Model
depends heavily on effective risk management. Teams need specialized expertise to correctly
identify and assess risks, which can be a challenge in organizations without such skills.
o Example: A startup developing a cybersecurity tool might struggle with the Spiral
Model if they lack an experienced risk management team to identify and mitigate
technical or compliance risks.
3. Complex to Manage for Large Projects: Managing multiple cycles, each with its own set of
objectives, risks, and evaluations, can be complex, especially for large-scale projects involving
numerous stakeholders. Coordination between cycles can be challenging, leading to delays or
miscommunication. o Example: A government IT project with many departments and
external vendors may face challenges managing the iterative cycles and aligning objectives
across stakeholders.
4. Not Ideal for Small Projects: The Spiral Model’s complexity and resource requirements make
it unsuitable for smaller projects with limited scope. The overhead associated with planning,
risk analysis, and evaluation can outweigh the benefits for simple or low-risk projects.
o Example: A small business developing a basic website with fixed requirements might
find the Spiral Model unnecessary, as simpler approaches like the Waterfall Model or
Agile could meet their needs with less complexity.

When to Use the Spiral Model

1. Large, Complex Projects: The Spiral Model is ideal for large-scale, complex projects where
requirements are unclear at the start or are expected to evolve over time. Its iterative approach
allows for incremental development and continuous refinement.
o Example: Developing an enterprise resource planning (ERP) system for a
multinational corporation, where various modules such as finance, HR, and logistics
need to be integrated and refined over time.
2. High-Risk Projects: The Spiral Model excels in projects where risk management is a critical
component. It’s particularly useful in high-risk environments where new technologies or
regulatory requirements are involved. The model's focus on early risk identification and
mitigation makes it a strong choice for projects that cannot afford major risks down the line.
o Example: A defense project where security, compliance, and operational risks must be
continually monitored and mitigated.
3. Projects with Frequent Customer or Stakeholder Involvement: Projects where frequent
feedback from stakeholders is essential benefit from the Spiral Model. Since each cycle
involves gathering feedback and adjusting the system accordingly, it allows teams to ensure
that the product meets customer expectations.
o Example: Developing a healthcare management system, where doctors, nurses, and
administrators need to continuously provide input to ensure the system meets clinical
and operational requirements.
4. Projects Involving New Technology: The Spiral Model is well-suited for projects using
emerging or unproven technologies, where there is significant uncertainty about how the

Page 68 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
technology will behave or integrate with existing systems. The risk analysis phase helps teams
address these uncertainties early. o Example: A virtual reality (VR) training system for
pilots, where technical risks such as performance, scalability, and user interface design need to
be carefully managed and tested in each cycle.
5. Long-Term, High-Budget Projects: The Spiral Model is beneficial for projects with long
timelines and substantial budgets, where repeated iterations and thorough risk management
are crucial to success. These projects often involve multiple stakeholders, and the iterative
nature helps in continuously refining the product.
o Example: Developing a national transportation system that includes multiple
subsystems like traffic management, public transportation integration, and road safety
monitoring.

When Not to Use the Spiral Model

1. Small, Low-Risk Projects: The Spiral Model’s complexity and focus on risk management
make it unnecessary for small projects with limited scope and low risk. The overhead of
repeated cycles of planning, risk analysis, and evaluation would add unnecessary complexity
to a simple project. o Example: Developing a basic informational website for a small
business, where the requirements are clear and there is little risk involved.
2. Projects with Fixed, Well-Defined Requirements: If a project has well-defined
requirements from the start and these requirements are unlikely to change, the Spiral Model
might be overkill. A more structured, linear model like Waterfall would be more efficient for
such projects, as it does not require continuous iterations or risk management.
o Example: Building a government tax compliance system, where the specifications
are driven by regulatory standards that are unlikely to change during the project.
3. Short-Term Projects with Tight Deadlines: The Spiral Model involves multiple cycles of
planning, risk analysis, development, and evaluation, making it time-consuming. For
shortterm projects with fixed deadlines, this iterative process can introduce delays, as each
phase requires thorough planning and review. o Example: A promotional campaign website
for a product launch, where the focus is on completing the project quickly and efficiently.
4. Projects with Limited Budgets: The Spiral Model requires significant resources for repeated
risk analysis, planning, and testing. For projects with limited budgets, the cost of managing
these repeated cycles might outweigh the benefits, making it an inefficient choice.
o Example: A non-profit organization’s internal project, such as a volunteer
management system, where budget constraints demand a simpler, more cost-effective
development approach.
5. Teams Lacking Expertise in Risk Management: Since risk management is central to the
Spiral Model, it is not ideal for teams that lack experience in identifying, assessing, and
mitigating risks. Projects that do not require specialized risk management processes can
become bogged down by the model’s complexity.
o Example: A small startup developing a mobile app, where the team’s primary focus
is on speed and innovation, rather than risk mitigation.

Page 69 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025

DevOps Model
DevOps is a modern software development approach that combines software development (Dev)
and IT operations (Ops). The primary goal of DevOps is to increase collaboration between
development and operations teams, enabling faster development cycles, continuous integration and
deployment, and more reliable releases. By fostering a culture of shared responsibility, DevOps
eliminates silos between teams, integrates automation tools, and streamlines workflows.

DevOps emphasizes continuous integration (CI) and continuous delivery (CD), allowing teams
to develop, test, and release software more frequently and with higher quality. It uses various tools
to automate manual processes, such as infrastructure provisioning, testing, and deployment,
leading to faster and more consistent delivery of software.

Phases of the DevOps Model

The DevOps process is continuous, involving several key phases that integrate both development
and operational tasks.

1. Continuous Development: This phase focuses on the planning and coding aspects of the
software development life cycle. Developers work collaboratively to plan the features,
functionalities, and architecture of the software. After planning, they start coding, and the code
is continuously updated and improved over time.

Example: For a banking application, the development team plans the features for online
fund transfers and account statements. As the features are developed, the code is
continuously updated in the shared repository.

Key Activities
• Planning software features and goals.
• Writing code for new features and updates. Updating and refining
code in small, manageable increments.

Deliverables
• Feature List: A detailed plan of the features to be developed.
• Source Code: The actual code for the product or its features, maintained in a shared
repository.

2. Continuous Integration (CI): In the Continuous Integration phase, developers frequently

merge their code into a shared repository multiple times a day. Automated builds and tests are
triggered whenever new code is committed, ensuring that any issues or bugs are identified and
addressed early. This process helps prevent the accumulation of errors or defects and maintains
the integrity of the codebase.

Page 70 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025

Example: In the banking application, after new code is committed (such as an update to the
fund transfer functionality), the system automatically builds the code and runs tests to ensure
that the new changes do not break any existing features.

Key Activities
• Merging code into the main repository frequently.
• Running automated builds and tests to catch issues early. Integrating
new code with the existing system continuously.

Deliverables
Automated Build: A new version of the software, generated automatically. Test Results:
Results from automated tests that show whether the code works as expected.

3. Continuous Testing: In the Continuous Testing phase, automated tests are used to validate the
code after every update or build. This ensures that each code increment is thoroughly tested
before it moves to production. Automated tests include unit tests, integration tests,
performance tests, and security tests. The goal is to detect issues early and reduce the risk of
releasing faulty code.

Example: For the banking application, automated tests are run on new features, such as fund
transfers, to ensure they meet performance and security standards. The tests might simulate
high volumes of transactions to check the system’s performance under load.

Key Activities
• Running various automated tests (e.g., unit, integration, performance).
• Identifying bugs, performance issues, and vulnerabilities early.
Reporting test results to the development team for quick fixes.

Deliverables
Test Reports: A comprehensive summary of test results showing the performance, security,
and functionality of the new code. Bug Reports: Any bugs or issues identified during testing.

4. Continuous Deployment (CD): In the Continuous Deployment phase, the validated code is
automatically deployed to production or a staging environment. DevOps uses automated
deployment tools to ensure that new code is released frequently and consistently without
manual intervention. This automation reduces the time between development and release,
making it possible to deliver features or updates faster to end-users.

Page 71 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
Example: Once the banking app’s fund transfer feature passes all automated tests, it is
automatically deployed to a staging environment for final checks. After the staging review,
it is deployed to the live production environment without manual intervention.

Key Activities
• Automatically deploying tested code to staging and production
environments.
• Monitoring deployments to ensure they work as intended.
Reducing the time between feature development and release.

Deliverables
Deployed Application: A live version of the software with the newly integrated features.
Deployment Logs: Records of the deployment process for tracking and troubleshooting.

5. Continuous Monitoring: Once the software is deployed, the Continuous Monitoring phase
involves tracking the application’s performance in real-time. Monitoring tools are used to
gather data on user behavior, system performance, security, and operational issues. This data
helps teams identify any problems or bottlenecks that occur in production so that they can be
addressed quickly.

Example: In the banking app, monitoring tools track the response time for fund transfers,
the load on the server, and any security threats such as unauthorized login attempts. If any
issues arise, such as slow response times, alerts are generated to notify the team for immediate
action.

Activities
• Monitoring the application’s performance, availability, and security.
• Using monitoring tools to detect system failures or issues in real-time.
Collecting data and metrics to improve system performance.

Deliverables
• Monitoring Dashboard: A real-time interface showing the current state of the
application’s performance and availability.
• Alert Reports: Notifications or alerts generated when the system encounters performance
issues or security threats.

6. Continuous Feedback: The final phase of the DevOps lifecycle is Continuous Feedback,
where feedback is gathered from users, stakeholders, and monitoring tools. This feedback is
then used to refine the product and improve future iterations. This phase ensures that developers
are aware of any issues in production and that they can make adjustments to meet user
expectations.

Page 72 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025

Example: After the banking app is deployed, feedback from customers about the usability
of the fund transfer feature is collected. Additionally, feedback from monitoring tools reveals
areas where performance can be optimized. This feedback is fed back into the development
cycle for the next iteration.

Key Activities
• Collecting feedback from end-users and stakeholders.
• Analyzing system metrics to identify areas for improvement. Refining
the product based on the feedback.

Deliverables
• User Feedback: A summary of feedback collected from customers and stakeholders.
• Performance Reports: Detailed reports on system performance, gathered from monitoring
tools.

Advantages of the DevOps Model

1. Faster Time to Market: DevOps emphasizes continuous integration (CI) and continuous
delivery (CD), allowing organizations to develop, test, and deploy software more frequently
and rapidly. This reduces the time it takes to bring new features and updates to the market,
keeping companies competitive. o Example: A retail company using DevOps can release
updates to its online shopping platform more frequently, such as adding new payment methods
or improving the user interface, reducing the time from concept to release.
2. Improved Collaboration and Communication: One of the core principles of DevOps is to
break down the traditional silos between development and operations teams. This promotes
a culture of shared responsibility and accountability, leading to better communication, faster
issue resolution, and more cohesive workflows.
o Example: A social media platform development team ensures that developers and
operations staff work together to ensure high availability and performance during
feature releases.
3. Automation Improves Efficiency: DevOps relies heavily on automation for tasks like testing,
building, deploying, and monitoring software. Automation reduces the risk of human error,
accelerates processes, and ensures more consistent outcomes, leading to higher overall
efficiency.
o Example: In a cloud services company, automated deployment tools ensure that
updates are consistently and reliably deployed across different environments without
manual intervention, reducing the chance of configuration errors.
4. Higher Product Quality: Continuous testing, integration, and feedback loops ensure that
software is consistently reviewed, tested, and validated before release. This helps in identifying
and resolving bugs early, leading to a more stable and high-quality product.

Page 73 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
o Example: A financial services app can regularly run automated security tests and load
tests to ensure that the platform remains secure and performs well, even under heavy
use.
5. Increased Deployment Frequency: DevOps allows for more frequent and smaller updates,
making deployments less risky. The team can release new features, security patches, or
improvements multiple times per day if needed, without disrupting operations.
o Example: A streaming service may roll out new features like personalized
recommendations or content categories more frequently to improve user experience.
6. Rapid and Reliable Recovery from Failures: DevOps promotes quick detection of issues
through continuous monitoring and ensures that systems are resilient through automated
rollback and recovery mechanisms. In case of failure, teams can react faster, minimizing
downtime and business impact.
o Example: A telecommunications company can quickly roll back a failed network
update to restore services, reducing the impact of outages for customers.
7. Cost Savings Over Time: By automating many manual processes and improving efficiency,
DevOps can result in long-term cost savings. It reduces the time and resources required for
development, testing, and deployment, while improving system stability and uptime.
o Example: A software development firm implementing DevOps can reduce the time
spent on repetitive tasks like manual testing or deployment, freeing up team members
to focus on higher-value activities.
8. Continuous Feedback for Continuous Improvement: DevOps emphasizes feedback loops
from users, system monitoring, and stakeholders. This feedback helps teams to make
datadriven decisions, constantly improving the product based on real-world data and user input.
o Example: A mobile banking app gathers user feedback through monitoring tools,
adjusting features such as transaction speed or user interface elements based on realtime
data.

Disadvantages of the DevOps Model

1. Cultural and Organizational Challenges: One of the biggest challenges in adopting DevOps
is the cultural shift required within an organization. Teams that are used to working in silos
(development separate from operations) may resist the changes that come with DevOps,
making it difficult to implement successfully. o Example: A traditional enterprise may face
internal resistance, as development and operations teams may be reluctant to take on new
responsibilities or work outside their familiar roles.
2. Requires Significant Investment in Automation: DevOps relies on automation tools for
continuous integration, testing, deployment, and monitoring. Implementing these tools requires
an upfront investment in technology, infrastructure, and training, which can be costly.
o Example: A small startup might struggle with the initial cost of integrating
automation tools such as Jenkins for CI/CD, Docker for containerization, or Kubernetes
for orchestration.

Page 74 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
3. Complexity in Managing Tools and Infrastructure: DevOps introduces several tools and
processes to automate development and deployment, but managing these tools can become
complex, especially as the project or organization grows. Integrating tools, ensuring they work
together smoothly, and maintaining them can be challenging.
o Example: A large e-commerce company using multiple cloud providers and DevOps
tools like AWS, Docker, and Jenkins may face complexity in managing dependencies,
tool integrations, and updates.
4. Not Suitable for All Projects: DevOps may not be the best fit for small-scale projects or
those that do not require frequent updates. For projects with well-defined, static requirements
or short-term deadlines, the overhead of setting up and maintaining DevOps processes may not
be justified. o Example: Developing a simple landing page for a promotional campaign might
not need DevOps tools or processes, as the scope is limited and changes are infrequent.
5. Security Concerns with Automation: While automation increases efficiency, it can also
introduce security risks if not managed properly. Automated deployments and continuous
integration require secure configurations and processes to ensure that sensitive data is
protected, and vulnerabilities are not inadvertently introduced into production.
o Example: A healthcare provider using automated DevOps pipelines must ensure that
patient data remains secure during automated testing and deployment, which requires
additional security protocols.
6. Monitoring and Maintenance Overhead: Continuous monitoring and feedback collection in
DevOps can create an ongoing maintenance burden for the operations team. Teams must
ensure that monitoring systems are properly configured, alerts are meaningful, and false
positives are minimized to avoid overwhelming team members.
o Example: A large-scale SaaS platform may face challenges managing the monitoring
of thousands of microservices, each generating its own logs, performance data, and
alerts.
7. Steep Learning Curve: DevOps requires a deep understanding of both development and
operations practices, along with the various tools used for automation, testing, and monitoring.
Training teams to adopt DevOps can be time-consuming and require significant effort.
o Example: A company transitioning from Waterfall to DevOps may need to invest
in extensive training for developers and operations staff to become proficient with tools
like Docker, Kubernetes, and CI/CD pipelines.

When to Use the DevOps Model

1. Projects Requiring Frequent Updates and Rapid Releases: DevOps is ideal for projects
where speed to market is critical, and there’s a need to continuously deliver new features,
updates, or fixes.
o Example: A mobile app development company releasing frequent updates to stay
competitive in the app market can benefit from DevOps practices to ensure smooth,
regular releases.

Page 75 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
2. Large, Complex Systems with Continuous Integration Needs: For projects with complex
infrastructure that requires constant integration and testing, DevOps helps maintain
consistency and quality across the system.
o Example: A cloud-based platform with multiple microservices benefits from DevOps
automation to manage frequent changes across the system and ensure that all services
work seamlessly together.
3. Projects with High Availability and Reliability Requirements: DevOps is well-suited for
systems that require high availability, real-time monitoring, and quick recovery from
failures. Continuous monitoring and automated recovery mechanisms reduce downtime and
improve system reliability.
o Example: A financial services provider using DevOps to ensure its online banking
platform remains available 24/7, with rapid recovery processes in place for system
failures.
4. Scalable Projects with Ongoing Maintenance Needs: For projects that need to scale over
time, DevOps enables ongoing maintenance and updates without interrupting service. The
model ensures that the system can grow and evolve while remaining operational. o Example:
A video streaming platform that frequently adds new features and servers to accommodate
more users benefits from DevOps’ continuous deployment and scaling capabilities.

When Not to Use the DevOps Model

1. Small, Simple Projects with Limited Updates: For small projects with well-defined, static
requirements and limited scope for ongoing updates, the overhead of implementing and
maintaining DevOps processes might not be justified. DevOps thrives in environments where
continuous delivery, integration, and frequent updates are necessary. For smaller, one-off
projects, simpler development and deployment methods are often more efficient.
o Example: A static website for a local business with basic content like contact
information, service details, and a few images. Since the website is unlikely to require
frequent updates or complex infrastructure, implementing a full DevOps pipeline
would be overkill.
2. Short-Term Projects with Tight Deadlines: DevOps may not be suitable for short-term
projects where quick delivery is the main priority. The time and resources needed to set up the
necessary DevOps automation tools, processes, and pipelines might not align with the short
lifecycle of the project. In such cases, a simpler approach that focuses on rapid delivery without
the overhead of DevOps may be more appropriate.
o Example: A campaign microsite for a limited-time marketing event with a fixed
launch date and short operational life span. In this case, the focus is on delivering the
website quickly without the need for continuous updates or operational management.
3. Projects with Fixed Requirements and Minimal Changes: If a project has fixed
requirements that are unlikely to change over time, such as legacy systems or
compliancedriven applications, DevOps may not provide significant value. These projects

Page 76 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
typically do not require frequent updates, so continuous integration and delivery pipelines may
not be necessary. A more linear approach, such as Waterfall, may suffice.
o Example: A government compliance system that adheres to strict regulatory
requirements. The software is built to meet specific, unchanging criteria, and updates
are rare. In such cases, the overhead of DevOps automation may not provide enough
benefits to justify its use.
4. Organizations Without Sufficient DevOps Expertise or Culture: DevOps requires a
cultural shift and technical expertise in automation, continuous integration, deployment, and
monitoring. If an organization lacks the necessary DevOps skills or is resistant to adopting a
DevOps culture, implementing the model can be difficult. Without the proper support, tools,
and training, the benefits of DevOps may not be fully realized.
o Example: A small business or organization with a traditional IT structure where
development and operations teams work in silos. If there is no willingness to change or
invest in new tools and training, adopting DevOps may lead to confusion and
inefficiencies rather than improvements in delivery speed and quality.
5. Highly Regulated Industries with Strict Documentation Requirements: In some highly
regulated industries, such as healthcare or aerospace, compliance requires detailed
documentation and strict approval processes for each stage of development and deployment.
In such cases, the rapid and continuous delivery nature of DevOps may conflict with the need
for rigorous, controlled, and documented processes.
o Example: Developing medical device software, where each step of development
requires extensive documentation, testing, and approval before moving forward. In
such cases, a more traditional approach that focuses on comprehensive documentation
and sign-off processes may be more suitable than the fast-paced, iterative approach of
DevOps.

Big Bang Model

The Big Bang Model is a non-structured and informal approach to software development.
Unlike other models, it doesn’t follow predefined phases or processes such as planning, design, or
testing. In this model, all resources are pooled together, and the entire effort is focused on
developing the product with little or no formal planning. Developers essentially "throw" everything
into the project (hence the name "Big Bang") with the expectation that the end result will meet
user requirements.

The Big Bang Model is most commonly used in small projects with vague or evolving
requirements. It emphasizes coding and development over analysis and documentation, making
it a highly flexible but also risky approach. Due to its unstructured nature, the model is best suited
for projects where both the customer and developers are unsure of the final product or where quick
prototyping is needed without a full-scale development process.

Page 77 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025

Phases of the Big Bang Model

The Big Bang Model doesn’t have formal phases like other models. Instead, the development
process occurs without much planning or structure, and the team focuses on writing code directly
based on any initial requirements or ideas that are provided. The phases are loosely defined and
can be broken down into:

1. Initial Requirements Gathering (if any): In many cases, the Big Bang Model starts with vague
or incomplete requirements. Sometimes, the developers receive little more than a basic idea
of the product they need to create, and there is minimal analysis or documentation of these
requirements.

Example: For a mobile game development project, the only guidance the development team
might receive is that the game should involve "shooting zombies." No detailed
documentation or specifications regarding gameplay, mechanics, or user interface are
provided.

Key Activities
• Gathering any existing ideas or requirements.
• Understanding the high-level vision of the product (if provided). Little to
no formal documentation.

2. Development and Coding: In the Big Bang Model, the primary focus is on coding. The
development team starts writing code immediately, often without a clear design or long-term
plan. Developers make decisions on the fly, and the code evolves based on trial and error,
feedback from users, and the developer’s intuition. There is no formal structure, so the coding
effort is often ad-hoc.

Example: The mobile game development team might start building the basic mechanics of
zombie shooting, such as creating characters, designing basic levels, and coding player
movement and interactions, without thinking about scalability or long-term development.

Page 78 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
Key Activities
• Writing code based on immediate ideas or input.
• Making design and development decisions as the project progresses.
Iterating through trial and error, continuously building the product.

3. Testing (Usually Minimal): Testing in the Big Bang Model is often informal and may not
follow structured testing procedures like in more formal models. Testing is typically done at
the end of the development process or in small batches as the product evolves. In many cases,
testing is limited to basic functionality and bug fixes, and there is no thorough documentation
of test cases or formal test plans.

Example: In the mobile game project, the developers may only test basic interactions such
as shooting mechanics or player movement to ensure they work. However, more complex
testing, such as user experience or performance testing, may be overlooked.

Key Activities
• Informal or ad-hoc testing of code functionality.
• Fixing bugs as they arise, but without a structured testing approach.
Limited documentation of testing activities or results.

4. Delivery: After coding and basic testing, the product is delivered to the customer. In some cases,
the delivered product may be incomplete, or it might differ from what the customer originally
envisioned due to the lack of formal planning and documentation.

Example: The mobile game might be delivered to the client as a basic prototype with working
shooting mechanics but no fully developed gameplay or levels. The customer might provide
feedback, requesting additional features, which could lead to further development.

Key Activities
• Delivering the product based on what has been built.
• Gathering feedback from the customer (if applicable). Making
post-delivery adjustments as needed.

Advantages of the Big Bang Model

1. Simplicity and Flexibility: The Big Bang Model is extremely simple to implement because
it doesn’t require formal planning, design, or structure. Developers can start coding right away
without spending time on upfront documentation or analysis, allowing for high flexibility in
how the project evolves.
o Example: A small startup developing an experimental mobile app prototype can
benefit from the flexibility of the Big Bang Model, as they can iterate quickly without
formal processes.

Page 79 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
2. Ideal for Small, Experimental Projects: The Big Bang Model is a good choice for small
projects or experimental products where the scope is undefined, or where quick prototyping
is required. The focus on rapid development allows for fast feedback and iteration. o Example:
A prototype of a new AI-based tool that needs to be built quickly for a presentation or proof
of concept.
3. Low Initial Investment in Planning: Since there is no formal planning phase, the Big Bang
Model can save time and resources upfront. Projects that don’t require extensive upfront
investment in planning can move forward quickly. o Example: A personal project where a
developer wants to quickly build a simple app to test an idea without worrying about long-
term planning.
4. Allows for Creative Freedom: Without predefined structures or constraints, developers can
be creative and explore different approaches as they build the product. This creative freedom
can lead to innovative solutions in some cases.
o Example: In a creative project like building an experimental game, developers might
have more freedom to explore unique mechanics or design elements without worrying
about traditional development constraints.
5. Fast Start to Development: The absence of formal planning means that teams can begin
coding immediately, which can be beneficial when a quick prototype or early version of the
product is required.
o Example: A marketing team might ask for a quick prototype of a new web feature for
a demonstration, and the development team can deliver it rapidly using the Big Bang
Model.

Disadvantages of the Big Bang Model

1. Lack of Planning and Structure: The Big Bang Model lacks formal planning, which can lead
to disorganized development and misalignment with customer expectations. Since there’s no
clear vision or roadmap, the final product may deviate significantly from the original idea or
requirements. o Example: A mobile app might end up having features the customer never
wanted, or important features might be missing due to the lack of initial planning.
2. High Risk of Failure: The lack of defined requirements, documentation, and structured testing
makes the Big Bang Model very risky, especially for large or complex projects. If the product
does not meet the customer’s expectations, significant rework may be required. o Example: A
business management system developed using this model might fail because key features
were not properly thought through or integrated.
3. Poor Scalability: Since the Big Bang Model doesn’t focus on long-term design or planning,
the resulting product might be difficult to scale or maintain. If the product grows or additional
features are needed, the codebase may become difficult to manage.
o Example: A startup's e-commerce platform that was built quickly using the Big
Bang Model might struggle to handle more traffic or new features as the business
grows.

Page 80 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
4. Unpredictable Outcomes: The lack of formal structure can lead to unpredictable outcomes.
Without a clear plan, it’s hard to determine whether the final product will meet the customer’s
needs. Additionally, the end product might lack important functionality or performance
optimization. o Example: A mobile game developed without proper testing might have critical
bugs, poor performance, or missing features when it’s delivered to the client.
5. No Formal Testing Process: Testing in the Big Bang Model is often informal and minimal,
leading to potential bugs, performance issues, or security vulnerabilities that aren’t identified
until after the product is delivered. This increases the risk of delivering a low-quality product.
o Example: A financial app developed using the Big Bang Model might not have been
thoroughly tested for security vulnerabilities, potentially leading to data breaches.
6. Not Suitable for Large or Complex Projects: The Big Bang Model is not appropriate for
large, complex projects where detailed planning, structured development, and risk
management are crucial. Such projects require more formal methodologies to ensure successful
outcomes.
o Example: Developing an enterprise-level ERP system using the Big Bang Model
would likely result in chaos due to the lack of structured phases and risk management.

When to Use the Big Bang Model

1. Small Projects with Simple Requirements: The Big Bang Model is best used for small
projects where the requirements are simple, and there is little need for complex planning or
documentation. These projects benefit from the fast-paced, informal development approach. o
Example: A small personal app or experimental tool that is being developed for internal use
or as a quick prototype.
2. Prototyping and Experimentation: For projects where a quick prototype or proof of
concept is required, the Big Bang Model allows for rapid development without spending time
on formal planning or documentation.

RAD Model (Rapid Application Development)

Rapid Application Development (RAD) is a software development methodology that
emphasizes quick prototyping and iterative delivery over strict planning and testing cycles seen
in traditional models like Waterfall. It focuses on developing a system through continuous user
feedback and fast iterations, enabling teams to quickly deliver functional components or prototypes
and refine them based on stakeholder input.

RAD involves working closely with users to ensure that the system evolves based on their needs
and feedback. It is most effective for projects where requirements are flexible or not fully known
at the outset. The RAD model reduces development time by using component-based construction
and by relying on reusable software components.

The key characteristics of RAD include:

Page 81 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
• User involvement throughout the development process.
• Rapid prototyping to quickly test and refine functionality.
• Iterative cycles that produce working software in short timeframes. Reuse of
components to speed up development.

Phases of the RAD Model

The RAD Model can be broken down into four distinct phases that enable fast development cycles,
iterative prototyping, and continuous feedback.
1. Requirements Planning: In the Requirements Planning phase, the team works closely with
stakeholders to gather high-level requirements. Unlike traditional models where extensive
documentation is created, this phase is short and focuses on understanding the project’s goals,
scope, and initial requirements. This phase also emphasizes user involvement, ensuring that
the development team fully understands what the customer wants.

Example: For a customer relationship management (CRM) system for a small business,
the requirements planning phase might involve gathering basic needs such as contact
management, customer history tracking, and sales reporting. The customer may express a need
for an easy-to-use dashboard, but other details remain flexible.

Key Activities
• Meeting with stakeholders to gather initial requirements.
• Discussing project goals and user expectations. Identifying the
general scope of the system.

Deliverables
Initial Requirements Document: A high-level outline of the features and functionalities the
system should have. Project Scope: Definition of the project’s overall objectives and
boundaries.

2. User Design: The User Design phase is where the team and stakeholders collaborate to create
prototypes and mockups of the system. This is an iterative phase where user feedback is
continuously gathered, and the design is refined accordingly. The goal is to create working
prototypes that users can interact with, allowing them to provide feedback before the system is
fully developed.

Example: In the CRM system, developers might create a basic prototype of the dashboard
and contact management system. Users interact with this prototype and provide feedback on
what works and what doesn’t. The developers then refine the design, adding or removing
features based on user input.

Page 82 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
Key Activities
Creating user interface (UI) mockups and prototypes.
Gathering feedback from stakeholders and end-users.
Refining the prototype based on feedback and user
interaction.

Deliverables
User Interface Prototypes: Early versions of the system’s interface that users can test.
Refined Requirements: Adjusted requirements based on user feedback.

3. Rapid Construction: In the Rapid Construction phase, the actual system is built using rapid
prototyping, component reuse, and iterative development. Developers focus on quickly
turning the prototypes into functional software. This phase is fast-paced, with developers
continuously integrating user feedback to improve the system as it evolves.

During this phase, teams build the system’s components and features incrementally, ensuring
that each iteration brings them closer to the final product.

Example: For the CRM system, the development team starts turning the prototype of the
contact management and reporting features into fully functional code. As this is done, the users
are continuously involved, testing and providing feedback on how the system functions in
realtime.

Key Activities
• Coding and implementing the system based on user feedback.
• Continuously integrating and testing the software.
• Reusing components to speed up development.
Deliverables
Functional Components: Parts of the system that are fully developed and ready for use.
Incremental Versions: Regularly updated versions of the software for users to test.

4. Cutover: The Cutover phase is similar to the deployment phase in traditional models. The
system is finalized and moved into production after rigorous testing and feedback iterations. In
this phase, user training, system testing, and data migration (if required) take place. The
system is deployed to the live environment, and any remaining bugs or issues are resolved.

Unlike traditional models, the RAD model keeps this phase relatively short since much of the
testing and refinement occurs earlier in the development process.

Page 83 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
Example: For the CRM system, once the features have been refined through feedback and
iteration, the system is deployed in the client’s environment. Training sessions are conducted
to ensure that the client’s team can use the system effectively.

Key Activities
• Finalizing the system and testing for bugs or performance issues.
• Migrating data from any old systems. Training users on
how to use the system.

Deliverables
• Deployed System: The final, fully functional system.
• Training Materials: Documentation and resources for end-users. Test Results: Reports
from final system tests to ensure the system meets quality standards.

Advantages of the RAD Model

1. Faster Time to Market: One of the biggest advantages of RAD is its ability to deliver software
quickly. The focus on rapid prototyping and iterative development means that functional
prototypes can be developed and released early in the project lifecycle. This is especially
beneficial for projects where time to market is critical.
o Example: A startup developing a new e-commerce platform can quickly release a
prototype to test the market, gather customer feedback, and make adjustments, rather
than spending months in development before launch.
2. Increased User Involvement and Feedback: RAD promotes continuous user involvement,
allowing users to see and interact with prototypes at various stages of development. This close
collaboration ensures that the final product aligns with user expectations, significantly reducing
the risk of misaligned requirements.
o Example: A company developing a CRM system for their sales team can iteratively
involve users to test features like customer tracking, reporting, and communication
tools, refining the system to ensure it fits the sales process.
3. Flexibility in Requirements: Unlike traditional models like Waterfall, RAD is highly flexible
and can easily accommodate changing requirements. Since the development is iterative, new
functionalities can be added without disrupting the entire project. This makes RAD ideal for
projects where requirements are not clearly defined upfront or may evolve over time.
o Example: A marketing analytics tool might start with basic features, but as users
provide feedback, more complex features like data visualization or predictive analytics
can be added in subsequent iterations.
4. Reduced Development Time: The use of pre-built, reusable components allows
development teams to build and integrate features faster. Rather than building everything from
scratch, developers can reuse existing modules, reducing both development time and effort.

Page 84 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
o Example: A team working on an HR management system might reuse pre-built
modules for employee records, payroll, and attendance tracking, significantly speeding
up the development process.
5. Early Detection of Errors: Since RAD involves continuous testing and user feedback, errors
and issues are identified and resolved early in the development process. This reduces the
likelihood of large-scale problems surfacing later in the project, which can be expensive and
time-consuming to fix.
o Example: In developing a financial dashboard, potential performance bottlenecks or
integration issues can be identified during early iterations, allowing the team to address
them before the full system is completed.
6. Encourages Reusability: RAD emphasizes the reuse of existing code, components, and
systems, which leads to higher efficiency and reduced redundancy. By using pre-tested,
reliable components, developers can focus on custom features and specific business needs
rather than reinventing the wheel.
o Example: A billing system for an ISP can reuse existing components for generating
invoices and tracking payments, allowing the developers to focus on integrating new
customer-facing features.
7. Less Need for Extensive Planning: RAD allows the team to start building and iterating
without needing extensive upfront planning or requirement analysis. This is particularly
beneficial when starting a project with unclear or rapidly changing requirements.
o Example: A software startup with an innovative idea can use RAD to start coding and
prototyping immediately, gradually refining the product as feedback and clearer
requirements emerge.
8. Lower Risk of Project Failure: Continuous feedback from users and stakeholders throughout
the process ensures that the project remains on track. This reduces the risk of a project being
derailed by misaligned goals or incorrect assumptions that may only become apparent at the
end of a traditional development process.
o Example: A company building a warehouse management system can avoid major
rework by allowing warehouse managers to test and refine the system during each
iteration, reducing the risk of delivering an unusable final product.

Disadvantages of the RAD Model

1. Dependency on Strong, Skilled Teams: RAD requires a highly skilled development team
capable of working in short, fast-paced cycles. The ability to quickly prototype and iterate
requires expertise in both development and system architecture, as well as excellent
communication and collaboration skills. Without a capable team, the quality of the final
product may suffer. o Example: A small startup with limited technical resources might
struggle to implement RAD effectively, as their developers may lack the expertise to build,
test, and refine prototypes at a rapid pace.
2. Limited Scalability: RAD’s focus on quick iterations and early prototyping may lead to a lack
of focus on long-term architecture and scalability. This can cause problems when the system

Page 85 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
needs to be scaled up or when new features are added later. Systems developed using RAD
might become more difficult to maintain or expand as the project grows. o Example: A local
retail system built using RAD might work well initially but could face issues scaling when the
business expands to multiple locations, requiring significant rework to improve scalability and
performance.
3. Unsuitable for Large, Complex Projects: RAD is better suited for small to medium-sized
projects with clearly defined modules that can be quickly prototyped. Large, complex projects
that require detailed planning and integration across many systems or teams may struggle with
RAD’s fast-paced, iterative approach.
o Example: Developing a nationwide public health management system with
complex interdependencies and regulatory requirements might not be suited for RAD,
as such projects require more planning, coordination, and risk management.
4. Requires Constant User Feedback: RAD depends heavily on continuous user involvement.
If stakeholders are not available or committed to providing timely feedback, the development
process can stall or end up delivering features that do not align with the actual user needs.
Additionally, if users change their feedback frequently, it may lead to project delays.
o Example: A corporate expense management system that requires feedback from
multiple departments may face delays if key users are unavailable for prototype reviews
or change their requirements midway through the project.
5. High Dependency on Prototyping: While prototyping is a key strength of RAD, it can also
be a limitation. Prototypes are often built rapidly and may not be optimized for performance,
security, or scalability. If the team tries to scale up the prototype into the final system without
re-architecting, it can lead to issues down the road.
o Example: A mobile banking app built using RAD might suffer from performance and
security flaws if the initial prototypes weren’t designed with those aspects in mind,
requiring significant rework to meet industry standards.
6. Potential for Scope Creep: Since RAD emphasizes flexibility and continuous iteration, there
is a risk of scope creep, where new features or changes are continuously added based on user
feedback. This can lead to longer development times, increased costs, and a system that
deviates from the original goals.
o Example: A content management system (CMS) might start with basic features but
could expand into a more complex project if stakeholders keep requesting new features
like social media integration, multi-language support, and advanced analytics.
7. Difficult to Manage for Fixed Budgets or Timelines: RAD’s flexibility can be a doubleedged
sword. While it allows for quick adjustments and refinements, it can also make it difficult to
predict costs and timelines. Projects with strict budgets or fixed deadlines may struggle with
the iterative nature of RAD, as each iteration could introduce new requirements or rework.
o Example: A government contract with a fixed budget and timeline might not be
suitable for RAD, as the project scope could expand with each iteration, causing delays
or exceeding the budget.

Page 86 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
8. Inadequate Focus on Documentation: RAD emphasizes rapid prototyping and development,
which may lead to insufficient documentation. While this speeds up the development process,
it can create issues later when new team members join the project or when maintenance is
required. o Example: A software-as-a-service (SaaS) provider might struggle with
onboarding new developers if the system was built quickly using RAD, but there is minimal
documentation explaining the architecture and design decisions.

When to Use the RAD Model

1. When Requirements Are Unclear or Evolving: The RAD model is ideal for projects where
the requirements are not well-defined upfront or are expected to change during the
development process. Its iterative nature allows teams to adapt to evolving business needs or
user feedback, refining the product continuously until it meets expectations.
o Example: A startup building an innovative social media platform may not have a
clear understanding of the final product’s features at the beginning. Using RAD, they
can develop prototypes, gather user feedback, and adjust features like post interactions
or user profiles as the project evolves.
2. When Speed is a Priority: RAD is perfect when there is a high priority on rapid delivery.
If you need to get a working product to market quickly, RAD’s focus on quick prototyping and
iterative improvements allows for faster delivery of functional components, making it suitable
for time-sensitive projects.
o Example: A mobile app for a promotional campaign that needs to be ready for an
upcoming event can be developed rapidly using the RAD model. Initial features can be
built quickly and refined through user feedback to meet tight deadlines.
3. For Small to Medium-Sized Projects: RAD works best for small to medium-sized projects
where the scope is manageable, and the focus is on delivering specific features or modules
rapidly. Projects that can be broken down into independent components or where prototypes
can be developed quickly are ideal candidates for RAD.
o Example: A customized reporting tool for a small business can be developed using
RAD. The basic functionalities, such as data input and report generation, can be built
and tested in iterations, allowing for fast delivery and refinements based on user input.
4. When User Involvement is High: RAD is suitable when there is strong user or stakeholder
involvement throughout the development process. Frequent feedback helps ensure that the
final product meets the user’s expectations. RAD works well in environments where users can
frequently engage with prototypes and provide ongoing feedback to guide development.
o Example: A company developing a customer relationship management (CRM)
system for its sales team can involve the users in every iteration, refining features like
lead tracking and sales forecasting based on their real-world needs and feedback.
5. When You Need a Working Prototype for Testing: RAD is ideal when you need a working
prototype early in the development process to test concepts, functionalities, or market demand.
You can develop a quick, functional prototype, test it with users or stakeholders, and use their
feedback to refine the product before full-scale development.

Page 87 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
o Example: A software startup looking to test a new AI-driven chatbot can build a
prototype using RAD, gather user feedback on its performance and usability, and iterate
on the design before launching a full version.
6. When Flexibility is Critical: If the project needs the flexibility to accommodate changes in
requirements, RAD is the right choice. Its iterative approach allows for ongoing adjustments
without the rigid structure of traditional models like Waterfall. This makes it easier to pivot
and adapt when new requirements or ideas emerge.
o Example: An e-commerce platform developing a new recommendation engine can
use RAD to experiment with different algorithms and user interface designs, allowing
for flexibility as the project progresses.

When Not to Use the RAD Model

1. For Large, Complex Projects: The RAD model is not suitable for large, complex projects
that require extensive planning, integration, and coordination. Large-scale systems often
involve multiple teams, dependencies, and integration with other systems, which makes the
quick and iterative approach of RAD difficult to manage. These projects typically require more
structured development and long-term architectural planning.
o Example: Developing a nationwide healthcare management system for a
government organization, where the project spans multiple subsystems (like patient
records, billing, and treatment management), would not work well with RAD due to
the high complexity and need for long-term architectural design.
2. When Requirements are Fixed and Well-Defined: If the project has fixed requirements
that are fully understood from the start and unlikely to change, the RAD model may introduce
unnecessary complexity. Traditional models like Waterfall are better suited for projects where
the scope is well-defined and where changes are minimal.
o Example: Building a regulatory compliance system for a financial institution, where
the project must adhere to strict, predefined legal requirements, might not benefit from
RAD. The project scope is fixed, and there is little need for iterative feedback.
3. When the Project Requires Scalability and Robust Architecture: RAD emphasizes rapid
development and prototyping, which may lead to inadequate attention to long-term
architecture and scalability. For systems that need to handle significant scalability,
performance, or security considerations, RAD may not provide the necessary structure for
robust architectural planning.
o Example: A large-scale enterprise resource planning (ERP) system for a
multinational corporation, where future growth and scalability are critical, may not be
suitable for RAD. A more structured approach with a focus on scalable architecture
would be a better fit.
4. When User Involvement is Low or Inconsistent: RAD heavily relies on constant user
feedback and interaction with prototypes. If stakeholders or users are not available to provide
timely feedback or are inconsistent in their participation, the development process can suffer.
RAD is not effective when users cannot be actively involved throughout the project.

Page 88 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
o Example: A government procurement system where end-user feedback is difficult
to gather or delayed due to bureaucratic processes may not be ideal for RAD.
Inconsistent or absent user input can derail the iterative development process.
5. For Projects with Tight Budgets or Fixed Timelines: Although RAD can accelerate
development, the iterative nature of the model can lead to scope creep, causing the project to
go beyond the original budget or timeline. If the project has strict financial constraints or needs
to be delivered by a specific deadline, the flexibility of RAD might lead to uncontrolled
changes or delays.
o Example: A fixed-cost project for a public sector client with a predetermined budget
and strict deadline for delivery might not work well with RAD. The iterative process
may expand the scope of the project and increase costs.
6. When Extensive Documentation is Required: RAD does not prioritize documentation,
focusing instead on rapid prototyping and iterative development. In highly regulated
industries or environments where extensive documentation is required (for legal or
compliance reasons), RAD may not provide the level of documentation needed to meet those
standards.
o Example: Developing software for a medical device that needs to comply with
stringent regulatory documentation requirements (such as FDA approvals) might not
align with RAD’s limited focus on formal documentation.

Prototype Model
The Prototype Model is a software development methodology where a working prototype is
created early in the project lifecycle to visually demonstrate and test the basic functionalities of
the system. This model helps in understanding and refining user requirements by allowing users to
interact with an early version of the product. Unlike traditional development models, which start
with detailed documentation and move through design and coding before testing, the Prototype
Model involves building a working model of the system first, gathering feedback, and refining
the prototype iteratively.
The Prototype Model is particularly effective when requirements are unclear or rapidly evolving.
The user can see and interact with a basic version of the product early on, providing feedback that
shapes the final product. This process leads to a better understanding of user expectations and a
product that is closely aligned with their needs.
Phases of the Prototype Model
The Prototype Model consists of the following general phases:

1. Initial Requirements Gathering

2. Quick Design
3. Building the Prototype
4. User Evaluation and Feedback
5. Refining the Prototype

Page 89 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
6. Final Development and Deployment

1. Initial Requirements Gathering: In this phase, developers and stakeholders work together to
gather high-level requirements for the system. Unlike traditional models, this phase focuses on
gathering basic functional requirements without extensive documentation. The goal is to
capture the core needs of the users so that a prototype can be built quickly.

Example: For a hotel booking system, the initial requirements might include features like
checking room availability, booking a room, and managing user reservations. Detailed aspects
such as payment integration or advanced reporting may not be covered in this phase.

Key Activities
• Meeting with stakeholders to gather basic functional requirements.
• Defining the core objectives and features of the system. Creating an
initial list of features for the prototype.

Deliverables
Requirements Outline: A high-level document listing the key features and
functions. Project Objectives: A clear understanding of what the prototype should
demonstrate.

2. Quick Design: In this phase, the development team creates a basic design of the system based
on the gathered requirements. The design is not meant to be comprehensive; instead, it focuses
on the user interface (UI) and basic system architecture that supports the core functionalities.
The idea is to quickly produce a layout or mockup of how the system will look and function.

Example: For the hotel booking system, the quick design might involve creating mockups of the
booking page, a calendar for checking availability, and a basic user registration form.

Key Activities
• Designing a basic user interface (UI).
• Outlining the architecture for core functionality. Identifying the
components needed for the prototype.

Page 90 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
Deliverables
UI Mockups: Visual representations of how the system will look.
Basic Architecture Plan: An outline of the technical components for the prototype.

3. Building the Prototype: In this phase, the development team builds a working prototype based
on the quick design. The prototype is a simplified version of the final product, including only
the most essential features. The purpose is to provide users with an interactive model that
allows them to experience key aspects of the system and provide feedback.

Example: For the hotel booking system, the prototype might allow users to search for available
rooms and make reservations, but the payment processing feature might not be functional yet.

Key Activities
• Coding and developing the core features of the prototype.
• Integrating user interfaces and system components. Ensuring the prototype is
functional enough for users to interact with.

Deliverables
• Working Prototype: A basic version of the system with core functionalities for user
interaction.
• Basic User Interaction: The prototype allows users to perform basic tasks like booking a
room.

4. User Evaluation and Feedback: Once the prototype is built, it is presented to the users for
evaluation. Users interact with the system, test the functionalities, and provide feedback on
what works and what doesn’t. This phase is crucial for understanding how the system meets
user needs and identifying areas for improvement.

Example: Users of the hotel booking system might test the prototype and provide feedback such
as "the booking process is confusing" or "it would be helpful to have a filter for room types."

Key Activities
• Demonstrating the prototype to stakeholders and users.
• Collecting user feedback on the design, functionality, and usability.
Analyzing feedback to identify improvements.

Deliverables
• Feedback Report: A document summarizing user feedback and recommendations for
improvement.
• Usability Insights: Information on how users interact with the system and potential
improvements.

Page 91 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025

5. Refining the Prototype: Based on the feedback from users, the prototype is refined and
adjusted. This phase may involve making changes to the user interface, adding new features,
or correcting flaws in the system. The cycle of refinement continues until the users are satisfied
with the prototype.

Example: In the hotel booking system, after feedback is gathered, the development team might
add new features like room filtering or simplify the booking process to improve user experience.

Key Activities
• Implementing changes based on user feedback.
• Testing the refined prototype with users. Repeating the
refinement process as necessary.

Deliverables
Improved Prototype: A more refined and functional version of the system.
Feature Enhancements: New or improved features added based on
feedback.

6. Final Development and Deployment: Once the prototype is refined to the point where it meets
user expectations, the system moves into full-scale development. The development team takes
the refined prototype and builds out the complete system, adding features, security, and
scalability to create the final product.
Example: For the hotel booking system, the final product would include all previously omitted
features, such as payment integration, advanced reporting, and backend management tools for hotel
administrators.

Key Activities
• Developing the full system based on the refined prototype.
• Conducting thorough testing of all system features. Deploying the
final product to the live environment.

Deliverables
Final Product: The complete system, ready for deployment and use.
Deployment Documentation: Materials for setting up the system in a live environment.

Advantages of the Prototype Model

1. Improved User Involvement and Feedback: One of the biggest strengths of the Prototype
Model is that it allows for early user involvement. Users can interact with the system early in

Page 92 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
the development process, providing feedback on functionality and usability. This continuous
interaction ensures that the final product is closely aligned with user expectations.
o Example: In the development of a learning management system, users can test a
prototype of the course creation feature early on and suggest improvements for user
experience and functionality before full-scale development begins.
2. Better Understanding of Requirements: The Prototype Model helps both developers and
users to gain a clearer understanding of requirements by providing a tangible representation
of the system early in the process. This reduces the likelihood of misunderstandings and
ensures that all stakeholders are on the same page regarding the system’s functionality.
o Example: In a hospital management system, creating a prototype for patient data
entry helps clarify exactly how doctors and nurses will input and access patient
information, ensuring that the final system matches their workflow.
3. Reduced Risk of Project Failure: By obtaining user feedback early and often, the Prototype
Model reduces the risk of building a system that does not meet user needs. Early detection
of issues or gaps in functionality helps avoid large-scale rework later in the project, which can
be costly and time-consuming.
o Example: In a financial software system, users testing an early prototype might
identify critical issues in report generation, allowing developers to fix the problem early
before more complex features are added.
4. Flexibility to Accommodate Changes: The Prototype Model is highly flexible and allows for
changes to be made to the system throughout the development process. As new requirements
emerge or user needs evolve, developers can easily adapt the prototype to include these changes
without major disruptions.
o Example: A retail point-of-sale system might start with basic transaction
functionalities, but after user feedback, additional features like real-time inventory
tracking or customer loyalty integration can be added without disrupting the overall
development process.
5. Early Detection of Design Flaws: Prototyping provides an opportunity to identify and correct
design flaws or inconsistencies before full-scale development. Since the prototype is
functional, users can interact with the system and provide feedback on user interface and
system behavior, allowing developers to refine the design iteratively.
o Example: In developing a hotel booking system, users testing the prototype may point
out that the room selection process is cumbersome, leading developers to simplify the
design for the final product.
6. Encourages Innovation: The iterative and flexible nature of the Prototype Model encourages
creative problem-solving and experimentation. Developers can try out new ideas in the
prototype and receive quick feedback, allowing them to refine or pivot their approach without
the commitment to a final design. o Example: A mobile app for fitness tracking might
initially test different approaches to workout suggestions, experimenting with AI-driven
recommendations versus userselected plans based on early user feedback.

Page 93 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
7. Saves Time in the Long Run: By resolving issues early, the Prototype Model can save
development time in the long run. Early feedback helps to refine the system before major
development begins, reducing the likelihood of costly changes or rework later in the project
lifecycle.
o Example: A customer relationship management (CRM) system prototype might
reveal that the workflow for adding new clients is too complex, allowing developers to
streamline the process early on rather than addressing it after full deployment.

Disadvantages of the Prototype Model

1. Potential for Scope Creep: The Prototype Model’s flexibility and continuous user feedback
can sometimes lead to scope creep. As users interact with the prototype, they may continuously
request additional features or changes, leading to increased development time and costs.
Without proper management, the project can expand far beyond its original scope. o Example:
A travel booking website may begin with basic flight and hotel booking features, but users
may request features like car rentals, tours, and loyalty programs, causing the project to grow
in complexity and timeline.
2. Lack of Focus on Long-Term Scalability and Robustness: The focus on quick prototyping
often means that the long-term architecture of the system is not given sufficient attention. This
can lead to problems when the system needs to scale or handle more complex features later in
the project. A prototype is typically built for speed rather than robustness, which can result in
technical debt.
o Example: A small business e-commerce platform built using the Prototype Model
may work well for a few products, but as the business expands and traffic increases,
performance and scalability issues might arise.
3. Over-Emphasis on User Interface: Since users interact with the prototype, there is a tendency
to focus heavily on the user interface (UI) while neglecting back-end functionality or system
integration. This can result in a product that looks good but lacks the necessary depth or
performance behind the scenes. o Example: In a job recruitment portal, the prototype may
focus too much on the user interface for job searching while overlooking essential features like
automated candidate matching or detailed employer reports.
4. May Lead to Inadequate Documentation: The rapid nature of prototyping can sometimes
lead to a lack of documentation, as developers focus on building and refining the prototype
rather than documenting processes, decisions, and system architecture. This can cause
problems later, particularly when new team members join or when maintenance is required.
o Example: A mobile payment app prototype might be built and refined quickly based
on user feedback, but the lack of documentation on how the system processes
transactions or manages security could create issues when scaling or troubleshooting.
5. Risk of Misleading Stakeholders: Prototypes are often incomplete and may lack the full
functionality or performance of the final product. Stakeholders or users might misunderstand
the prototype’s limitations and assume the system is further along in development than it
actually is. This can lead to unrealistic expectations about delivery times or system capabilities.

Page 94 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
o Example: A healthcare management system prototype might demonstrate basic patient
registration but not include complex features like billing or medical record integration, leading
stakeholders to believe the system is near completion when significant development work
remains.
6. May Lead to Over-Reliance on Prototypes: Some projects may become over-reliant on the
prototype, treating it as the final system rather than using it as a stepping stone. This can lead
to situations where the prototype is prematurely scaled up without proper optimization for
performance, security, or robustness, creating issues in the final product.
o Example: A real estate listing platform prototype may function well with a few
listings, but scaling it to handle thousands of properties and user interactions without
re-architecting can cause performance bottlenecks and security vulnerabilities.
7. Increased Costs Due to Iterative Refinement: Although the Prototype Model can save time
by identifying issues early, continuous refinement of the prototype based on user feedback
can also drive up costs if not managed properly. Multiple iterations and user-requested changes
may extend the development timeline and increase the overall project budget.
o Example: A restaurant reservation system might initially be built as a simple
prototype, but as more features like table management, integration with food ordering,
and customer loyalty programs are requested, the project’s cost may rise significantly.

When to Use the Prototype Model

1. When Requirements Are Unclear: The Prototype Model is ideal for projects where
requirements are vague or evolving. If users are unsure about what they need or if the project
involves new or untested ideas, the Prototype Model allows users to see and interact with the
system early, helping to clarify their expectations.
o Example: A startup developing a new social media platform can use the Prototype
Model to explore different user interface designs and core functionalities, refining the
product as user needs become clearer.
2. For Complex Projects Requiring Frequent User Feedback: If a project requires frequent
user input due to its complexity or user-specific needs, the Prototype Model is a good choice.
It allows users to evaluate and refine the system continuously, ensuring that the final product
meets their requirements. o Example: A custom-built ERP system for a large organization
might use the Prototype Model to ensure that each module (e.g., inventory, finance, HR)
functions according to the specific workflows of the company.
3. When You Need to Demonstrate Feasibility Early: The Prototype Model is useful when you
need to demonstrate feasibility early in the project lifecycle. A working prototype can help
stakeholders or investors visualize the product, assess its potential, and provide valuable
feedback before significant development resources are committed.
o Example: A new AI-powered chatbot system might use a prototype to demonstrate
how the chatbot interacts with users and handles queries, allowing investors to see the
potential of the technology early on.

Page 95 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
4. For Systems Requiring High User Interaction: Projects where user interaction and
experience are critical, such as websites, mobile apps, or customer-facing systems, benefit from
prototyping. By refining the user interface and workflows based on real user feedback, the final
product is more likely to be user-friendly and effective.
o Example: A mobile banking app prototype allows users to test how they navigate
through account management, transfers, and bill payments, leading to refinements that
make the app more intuitive.

When Not to Use the Prototype Model

1. For Large, Complex Projects Requiring Long-Term Planning: The Prototype Model is not
suitable for large, complex projects that require extensive long-term architectural planning
and coordination. Such projects often involve multiple teams, detailed documentation, and
long-term strategic goals, which cannot be fully addressed by a rapid prototyping approach.
Prototypes typically focus on specific parts of the system and may lack the comprehensive
planning necessary for large-scale solutions.
o Example: Developing a national healthcare management system with multiple
interdependencies (such as patient records, billing, insurance, and treatment
management) would require extensive planning and risk management, which a
prototype might not adequately cover.
2. When Requirements Are Well-Defined and Unlikely to Change: The Prototype Model is
unnecessary if the project’s requirements are clearly defined from the outset and unlikely to
change. In such cases, traditional models like Waterfall, which emphasize comprehensive
planning and step-by-step implementation, would be more efficient. Prototyping could add
complexity without providing much benefit. o Example: A regulatory compliance system
for financial institutions, where legal and regulatory requirements are fully specified and fixed,
may not benefit from the iterative nature of the Prototype Model, as the system's scope and
functionality are already well understood.
3. When the Project Requires High Scalability and Robust Architecture: Prototypes are often
built for speed and flexibility rather than long-term performance and scalability. If the project
demands a scalable, highly robust architecture to handle large user bases, data volumes, or
high traffic, the Prototype Model may overlook these critical aspects during early development.
In such cases, a more structured approach focused on scalability is necessary.
o Example: A global e-commerce platform requiring high availability and
performance, especially during peak times (such as Black Friday sales), would not
benefit from prototyping, as scalability and infrastructure planning are critical from the
start.
4. For Systems Requiring High Security and Compliance: Systems that require high levels of
security or compliance with industry regulations (such as healthcare, finance, or
government projects) are not ideal for the Prototype Model. Security and compliance concerns
may not be addressed in early prototypes, leading to vulnerabilities or non-compliance. These

Page 96 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
projects typically require thorough planning, extensive documentation, and strict adherence to
standards from the beginning.
o Example: Developing a banking system or payment processing platform with
stringent security protocols (such as PCI-DSS) would require detailed planning and
testing for security features. A prototype might not adequately address all compliance
or security requirements.
5. When Stakeholders Expect a Fully Functional System Early On: If stakeholders or clients
are unfamiliar with the concept of prototyping, they may mistakenly expect the prototype to
be a fully functional system rather than an early working model. This can lead to unrealistic
expectations and frustration when the prototype is incomplete or lacks key features, potentially
damaging stakeholder confidence. o Example: In a government procurement system, where
officials might expect fully functional software early on, using a prototype could lead to
misunderstandings and dissatisfaction if the early version lacks required functionalities.
6. When Budget or Time is Strictly Limited: The iterative nature of the Prototype Model can
lead to scope creep and increased development costs as users continuously request changes
or additional features. If the project has a fixed budget or strict deadline, prototyping might
extend the timeline or lead to budget overruns, making it difficult to stay within the original
constraints.
o Example: A public sector project with a strict deadline and budget for delivering a
citizen portal might suffer from delays and cost increases if continuous changes are
made based on prototype feedback.
7. For Projects Requiring Extensive Documentation: Prototypes focus on quick development
and testing rather than detailed documentation. If the project requires comprehensive
documentation (such as for regulatory approvals or future maintenance), the Prototype Model
may not be suitable. Prototyping often lacks the rigor needed to produce the extensive
documentation required in regulated industries or for long-term maintenance.
o Example: A medical device control system being developed for FDA approval would
require thorough documentation of every phase of the development process, which a
prototype-based approach may not adequately provide.
8. When Development Teams Lack Experience with Prototyping: Prototyping requires a
specific mindset and set of skills, particularly the ability to rapidly iterate and adjust designs
based on feedback. If the development team lacks experience in iterative development or the
ability to effectively manage scope and feedback cycles, the Prototype Model might lead to
inefficiencies and poor outcomes. o Example: A team accustomed to Waterfall development
may struggle to adapt to the fast-paced, iterative nature of the Prototype Model, leading to
confusion, rework, and delays in delivering a usable system.

Principles of System Development

Developing an effective system requires adhering to several key principles that ensure the system
meets user requirements, is reliable, secure, and adaptable. These principles form the foundation

Page 97 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
of a disciplined approach to system development, helping to manage risks, enhance collaboration,
and deliver value to the organization.

User-Centered Design (UCD)

User-Centered Design (UCD) places end-users at the forefront of the system development process.
By prioritizing their needs and feedback throughout the design and development stages, the goal
is to create a system that is intuitive, user-friendly, and aligns with user expectations.

Key Activities
• User Involvement: Engage users early in the design phase to gather requirements and gain
insights into their workflows and preferences.
• User-Friendly Interface: Design interfaces with an emphasis on ease of use, ensuring
accessibility for different user groups, and minimizing complexity.
• Continuous Feedback: Regularly gather feedback from users during prototyping, testing, and
implementation phases to ensure the system aligns with user needs.

Example: In developing a customer service application, designers work closely with customer
service agents to ensure the interface is easy to use, incorporating features such as quick access to
customer records, intuitive navigation, and efficient issue tracking.

Advantages
Enhances user satisfaction and increases system adoption rates.
Reduces the time and cost associated with user training and
support.

Challenges
Requires frequent user involvement, which can extend development timelines.
Balancing user desires with business objectives can sometimes lead to conflicting priorities.

Flexibility and Scalability

Flexibility ensures that the system can adapt to changes in business needs or technology without
requiring a complete redesign. Scalability ensures that the system can grow to handle an increased
number of users, data, or functionalities without performance degradation.

Key Activities
• Modular Design: Implement modular design principles that allow different components to be
upgraded or replaced independently.
• Scalable Architecture: Ensure the system’s architecture is capable of handling increased load,
data storage, and user access as the business expands.
• Future-Proofing: Design with future integrations in mind, such as cloud services, APIs, or
new technologies, to extend functionality without disruption.

Page 98 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025

Example: In a retail inventory management system, flexibility might involve integrating the
system with new suppliers, while scalability ensures it can handle additional store locations,
product lines, and customer orders as the business grows.

Advantages
Prevents the system from becoming obsolete as the business
evolves. Reduces the cost and complexity of future upgrades or
expansions.

Challenges
Requires detailed planning and foresight during the initial design
phase. Increased upfront investment in scalable infrastructure may be
necessary.

Incremental and Iterative Development

Incremental and iterative development breaks the system into smaller, manageable pieces that are
developed and tested over several iterations. This allows for early user feedback and reduces the
risk of project failure.

Key Activities
• Incremental Delivery: Divide the project into smaller increments, delivering functional pieces
of the system one at a time.
• Feedback Loops: After each iteration, gather feedback from stakeholders and users to make
necessary adjustments before proceeding to the next phase.
• Continuous Improvement: Continuously refine and improve the system based on feedback
and performance reviews after each iteration.

Example: When developing a mobile banking application, the first iteration might deliver basic
features such as balance inquiries and transaction history. Later iterations could include features
like bill payments, fund transfers, and customer support chat.

Advantages
Reduces risks by delivering working components early and allowing for
adjustments. Provides flexibility to change course based on feedback or emerging
needs.

Challenges
Requires strong project management to prevent feature creep and maintain timelines. Each
iteration must be thoroughly tested to ensure seamless integration with previous versions.

Page 99 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
Risk Management
Risk management is essential in identifying, assessing, and mitigating potential risks that could
impact the project’s success. Proactive risk management helps prevent budget overruns, security
breaches, or technology failures.

Key Activities
• Risk Identification: Identify potential risks early, such as technological failures, budget
overruns, or regulatory changes.
• Risk Mitigation: Develop contingency plans and strategies to mitigate risks, such as
increasing testing or creating backup systems.
• Continuous Monitoring: Continuously assess and adjust risk management strategies
throughout the development process.

Example: In the development of a financial trading platform, risk management might include
implementing failover systems to ensure trading continues even if one part of the system fails.
Additional security measures, such as multi-factor authentication, mitigate the risk of unauthorized
access.

Advantages
Reduces the likelihood of project failure and enhances the system’s reliability and
security. Helps ensure the project stays on budget and meets deadlines.

Challenges
Some risks, such as changing market conditions, are difficult to
anticipate. Requires dedicated resources to monitor and manage risks
effectively.

Quality Assurance (QA)

Quality Assurance (QA) ensures that the system meets high standards for performance, security,
usability, and reliability. QA processes, implemented throughout the development cycle, detect
and address issues early, ensuring that the system is free from defects before deployment.

Key Activities
• Comprehensive Testing: Perform a variety of tests, including unit tests, integration tests,
system tests, and user acceptance tests (UAT), to ensure functionality and stability.
• Code Reviews: Conduct code reviews to ensure adherence to best practices, detect
inconsistencies, and address security vulnerabilities.
• Performance Monitoring: Regularly monitor system performance to ensure it meets defined
benchmarks, especially in high-demand environments.

Page 100 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
Example: In the development of an e-commerce platform, performance testing ensures the
system can handle high traffic volumes during peak shopping times, while security testing ensures
customer data is protected from breaches or hacking attempts.

Advantages
Enhances system reliability and security, reducing the likelihood of post-deployment
issues. Increases user confidence by delivering a well-tested, high-quality system.

Challenges
QA processes can extend development timelines as thorough testing and debugging are
timeconsuming. Requires specialized skills and tools to conduct comprehensive testing
effectively.

Collaboration and Communication

Effective collaboration and communication between stakeholders, developers, and users are
critical for the successful development of any system. Clear communication helps to align goals,
reduce misunderstandings, and ensure that the system delivers on business needs.

Key Activities
• Regular Communication: Maintain regular communication between all stakeholders
throughout the development cycle.
• Collaboration Tools: Use project management tools to track progress, share updates, and
ensure that everyone involved is on the same page.
• Defined Roles: Establish clear roles and responsibilities for each team member to avoid
confusion and streamline collaboration.

Example: In the development of a CRM system, close collaboration between the developers and
the sales team ensures that features such as lead tracking and sales forecasting are aligned with the
business’s needs and improve the sales team’s efficiency.

Advantages
Facilitates quick decision-making and ensures that the system aligns with business
goals. Reduces misunderstandings, minimizing delays and ensuring smooth progress.

Challenges
Coordination among stakeholders can be time-consuming, especially in large teams.
Communication gaps or conflicting priorities can lead to delays or misaligned
features.

Page 101 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
Summary of Principles of System Development
Principle Description Example
User-Centered Focuses on designing the Involving customer service agents
Design system to meet user needs and in the design of an intuitive service
improve usability. application.
Flexibility and Ensures the system can adapt Designing an inventory system that
Scalability to future changes and growth scales as more store locations are
without major redesigns. added.
Incremental and Breaks the project into Developing a mobile banking app in
Iterative manageable iterations, stages, starting with balance checks
Development allowing for regular feedback. and adding fund transfer
functionality later.
Risk Management Proactively identifies and Implementing backup systems in a
mitigates risks to prevent financial trading platform to prevent
project failures. downtime.
Quality Assurance Ensures the system meets high Performing stress testing on an
(QA) standards for performance, ecommerce platform to handle high
security, and usability. traffic during peak shopping
seasons.
Collaboration and Encourages active Close collaboration between
Communication collaboration between developers and sales staff to ensure
stakeholders and clear CRM features meet business needs.
communication.

These principles of system development provide a structured approach to ensure that the system is
reliable, scalable, and user-friendly while minimizing risks and enhancing collaboration across all
stakeholders.

Linking Information Systems to Business Needs

To maximize the effectiveness of an information system, it must be aligned with the organization’s
core business objectives. When information systems are properly integrated into business
operations, they streamline processes, improve decision-making, and create a competitive
advantage. By supporting business needs, information systems enhance value creation and
contribute to overall strategic success.

Enhancing Business Operations

One of the primary functions of an information system is to enhance business operations by
streamlining and automating processes. This reduces manual effort, increases efficiency, and helps
the organization save time and resources.

Page 102 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
Key Activities
• Process Automation: Automate repetitive tasks such as data entry, report generation, and
scheduling, freeing up employees to focus on higher-value activities.
• Inventory and Resource Management: Use the system to track inventory levels, monitor
resource usage, and manage supply chains to ensure optimal stock levels.
• Workflow Optimization: Streamline workflows to eliminate bottlenecks and improve the
speed and accuracy of operations.

Example: In a retail management system, automation of inventory tracking ensures that stock
levels are updated in real time. The system automatically triggers reordering when stocks are low,
preventing stockouts and overstock. This improves operational efficiency, ensuring that products
are always available without overstocking, which reduces storage costs.

Benefits
• Increases operational efficiency by reducing the need for manual interventions.
• Ensures that critical resources such as inventory or staff are always available when needed.
Improves overall business productivity and reduces operational costs.

Supporting Decision-Making
Information systems provide businesses with real-time data analysis and insights, enabling
informed decision-making. These systems give decision-makers access to relevant data and
analytical tools, allowing them to identify trends, forecast outcomes, and optimize strategies.

Key Activities
• Real-Time Data Collection: Gather and process data in real time, enabling faster and more
accurate decision-making.
• Data Analysis Tools: Use built-in tools such as dashboards, reports, and visualizations to
analyze key performance indicators (KPIs) and trends.
• Scenario Modeling: Use predictive analytics to model potential outcomes of different business
strategies, enabling more informed choices.

Example: A business intelligence (BI) system provides detailed sales trend data and customer
behavior analysis. This allows management to identify which products are performing well, which
markets are underperforming, and how customer preferences are shifting. With this information,
managers can adjust their marketing strategies to target high-demand products or focus on specific
customer segments, ultimately optimizing sales and revenue.

Benefits
• Empowers leaders with data-driven insights to make better strategic decisions.
• Reduces decision-making time by providing immediate access to relevant information.
Enhances business agility, allowing organizations to respond quickly to market changes.

Page 103 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025

Enabling Competitive Advantage

A well-aligned information system can give businesses a significant competitive advantage by
enabling them to operate more efficiently, serve customers better, or innovate faster than their
competitors. These systems often incorporate advanced technologies that differentiate a business
in the marketplace.

Key Activities
• Optimization Algorithms: Implement advanced algorithms that enhance operational
efficiency, such as route optimization, demand forecasting, or inventory management.
• Customer Engagement: Use the system to enhance customer experiences through
personalized services, faster response times, and more convenient transactions.
• Innovation Support: Support product or service innovation by providing insights and
capabilities that allow businesses to develop new offerings faster.

Example: An online food delivery service uses an advanced algorithm to optimize delivery
routes. This reduces delivery times, cuts fuel costs, and improves customer satisfaction by ensuring
that orders arrive faster than those delivered by competitors. The system also tracks customer
preferences, allowing the business to offer personalized recommendations and promotions, further
enhancing the customer experience.

Benefits
o Helps businesses stay ahead of competitors by offering better products, services, or customer
experiences.
o Increases customer loyalty and retention by consistently delivering high-quality service.
o Supports innovation, enabling businesses to introduce new products or services more quickly.

Ensuring Compliance and Security

Information systems play a critical role in ensuring that businesses comply with regulations and
standards while safeguarding sensitive data. Proper compliance and security features within a
system help organizations avoid legal penalties and protect their reputation.

Key Activities
• Compliance Monitoring: Ensure that the system supports compliance with relevant
regulations such as GDPR, HIPAA, or industry-specific standards.
• Data Security: Implement robust security measures such as encryption, access controls, and
secure authentication to protect sensitive information from unauthorized access.
• Audit Trails: Use the system to maintain detailed logs of data access and modifications to
ensure transparency and accountability.

Page 104 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
Example: A banking system designed to comply with the General Data Protection Regulation
(GDPR) ensures that customer data is stored securely and access is limited to authorized personnel
only. By encrypting data and using role-based access controls, the system helps the bank avoid
regulatory penalties and enhances customer trust by ensuring their personal information is well
protected.

Benefits
• Reduces the risk of legal penalties by ensuring compliance with applicable regulations.
• Enhances customer trust by safeguarding their data and ensuring their privacy.
Protects the organization’s reputation and reduces the likelihood of data breaches.

Summary of Linking Information Systems to Business Needs

Aspect Description Example
Enhancing Streamline and automate Automating inventory tracking and
Business business processes to improve reordering in a retail system to prevent
Operations efficiency and reduce costs. stockouts and reduce storage costs.
Supporting Provide real-time data analysis to A BI system analyzing sales trends and
Decision-Making enable informed, data-driven customer behavior to optimize
decisions. marketing strategies.
Enabling Use advanced technologies to A food delivery service using route
Competitive gain a competitive edge through optimization algorithms to reduce
Advantage efficiency or customer delivery times and improve customer
engagement. satisfaction.
Ensuring Ensure the system helps the A banking system that complies with
Compliance and business comply with regulations GDPR by encrypting customer data
Security and secure sensitive data. and limiting access to authorized
personnel.

Conclusion: Aligning information systems with business needs is essential for creating value and
achieving strategic success. By enhancing business operations, supporting decision-making,
enabling competitive advantage, and ensuring compliance and security, an organization can
maximize the benefits of its information systems and stay competitive in a rapidly evolving
marketplace.

Importance of Effective System Analysis and Design

Effective system analysis and design are essential components of the System Development Life
Cycle (SDLC). They ensure that the system meets user requirements, is cost-effective, scalable,
flexible, and minimizes risks. Here’s a detailed look at why system analysis and design are so
critical:

Page 105 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
Clear Requirements Understanding
One of the key reasons for project failures is the lack of clarity in understanding the user’s needs.
Effective system analysis ensures that requirements are thoroughly gathered, documented, and
understood before any development begins. This reduces the likelihood of miscommunication and
errors, leading to a system that aligns with the organization’s objectives.

Key Activities
• Conduct interviews, surveys, and workshops with users and stakeholders to gather
requirements.
• Analyze both functional and non-functional requirements to capture everything the system
should do. Document requirements clearly and review them with stakeholders for validation.

Example: In a school management system, detailed requirements analysis ensures that key
modules like attendance tracking, grading, parent-teacher communication, and student progress
reporting are included. This reduces the risk of missing features or requiring expensive
modifications later in the development phase.

Benefits
• Ensures that the system meets user expectations and business needs.
• Reduces the risk of misunderstandings or missing requirements that could lead to costly
rework. Provides a clear roadmap for developers to follow, improving the development
process.

Cost Efficiency
A well-designed system helps organizations stay within budget and timeline constraints by
avoiding unnecessary rework or modifications. By investing in effective system design early in the
process, businesses can prevent costly issues that arise from poorly planned systems.

Key Activities
• Create a detailed system design based on requirements analysis, outlining the technical
architecture, data structures, and system components.
• Develop a timeline and budget that accounts for potential changes, future growth, and
integration needs.
• Build a flexible, modular design that allows components to be added or modified without
significant rework.

Example: In an e-commerce system, careful design ensures that the payment system integrates
smoothly with product databases and customer records. This prevents issues like data mismatches
or payment failures that could require costly corrections or redesigns after the system is launched.

Page 106 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
Benefits
• Prevents costly design changes or rework during later phases of the project.
• Helps businesses stay on budget by anticipating and addressing potential challenges early.
Reduces the time and resources needed for development and integration.

User Satisfaction
Systems that are designed with the user in mind have a higher likelihood of being adopted and used
effectively. A well-structured design focuses on creating user-friendly interfaces and workflows
that meet the needs of the target users, which leads to higher satisfaction and more efficient usage.

Key Activities
• Design user interfaces (UI) that are intuitive, easy to navigate, and accessible for all users.
• Conduct usability testing with a sample of end-users to ensure the design aligns with their
expectations and is easy to use.
• Regularly gather feedback from users during the development and post-deployment phases to
refine the system.

Example: A hospital management system with a user-friendly interface that allows doctors and
nurses to quickly access patient records, input treatment details, and update diagnoses ensures
smoother workflows and better patient care. This results in improved staff efficiency and higher
user satisfaction.

Benefits
• Increases user satisfaction and system adoption rates.
• Reduces the need for extensive user training or support. Improves overall
productivity by designing systems that users find easy and efficient to use.

Scalability and Flexibility

A well-designed system is built with scalability and flexibility in mind, allowing it to grow and
adapt as business needs evolve. Proper system analysis helps in forecasting future requirements,
ensuring that the system can handle increased traffic, more users, or additional features without
requiring a complete overhaul.

Key Activities
• Use scalable architecture and technologies that allow for easy expansion (e.g., cloud
computing, microservices architecture).
• Design modular components that can be updated or replaced without affecting the entire
system. Plan for potential future needs, such as additional users, data storage, or system
integrations.

Page 107 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
Example: A cloud-based ERP system designed for a medium-sized company might initially
include finance and inventory management modules. As the company grows, it can easily add HR,
sales, and customer relationship management (CRM) modules without needing a complete
redesign.

Benefits
• Ensures the system can grow alongside the organization’s needs, without requiring a
complete overhaul.
• Reduces future costs by building scalability into the system from the start. Provides
flexibility to accommodate new technologies, users, or business models.

Reduction of Risk
Effective system analysis and design play a critical role in identifying potential risks early in the
project. By analyzing the system thoroughly and incorporating risk mitigation strategies into the
design, businesses can avoid issues that could lead to project delays, security breaches, or system
failures.

Key Activities
• Conduct risk assessments during the analysis phase to identify potential issues such as security
vulnerabilities, scalability challenges, or integration risks.
• Incorporate mitigation strategies into the system design, such as implementing robust security
features, scalability planning, or redundant backup systems.
• Monitor risks throughout development, testing, and deployment to ensure they are effectively
managed.

Example: During the analysis phase of a financial management system, potential security risks
such as data breaches or unauthorized access are identified. The system design includes encryption,
multi-factor authentication, and secure role-based access control to mitigate these risks and protect
sensitive financial data.

Benefits
• Helps prevent security breaches, system failures, or costly disruptions.
• Reduces project delays by addressing risks before they escalate into serious issues.
Improves system reliability and user confidence by proactively managing potential risks.

Summary of Importance of Effective System Analysis and Design

Aspect Description Example
Clear Thoroughly understanding Conducting detailed requirement
Requirements user needs to avoid project analysis for a school management
Understanding failure and costly changes. system to ensure it includes all
necessary features.

Page 108 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
Cost Efficiency Proper design prevents Designing an e-commerce system to
expensive rework and ensures avoid integration problems between
the system is built within payment systems and product
budget. databases.
User Satisfaction A user-friendly system A hospital management system with
improves satisfaction and an intuitive interface that increases
adoption rates. staff efficiency and patient care.
Scalability and Ensures the system can grow A cloud-based ERP system that scales
Flexibility with the business and adapt to as the company adds new departments
changes. and features without a complete
redesign.
Reduction of Risk Identifies and mitigates risks Incorporating encryption and
early in the development multifactor authentication to mitigate
process. security risks in a financial system.

Conclusion
Effective system analysis and design are essential for building reliable, user-friendly, scalable, and
cost-efficient systems. By thoroughly understanding user needs, designing flexible and scalable
systems, managing risks early, and ensuring high levels of user satisfaction, organizations can
significantly improve the success rate of their system development projects.

Revision Materials
Lab Manual
Lab 1: Planning and Requirement Gathering
• Objective: To identify system requirements and define the scope of a proposed system.
• Tasks:
1. Choose a business domain (e.g., retail, education, healthcare).
2. Gather requirements through stakeholder interviews and document both functional
and non-functional requirements.
3. Define the project scope, goals, budget, and timeline.
• Takeaway Activity: Prepare a requirement specification document.
Lab 2: System Design
• Objective: To create a system design based on gathered requirements.
• Tasks:
1. Design the architecture of the system, including data flow diagrams, database
schema, and user interface prototypes.
2. Define the hardware, software, and network requirements.
• Takeaway Activity: Create detailed diagrams such as ERDs (Entity Relationship
Diagrams) and system flowcharts.

Page 109 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
Lab 3: Development
• Objective: To implement a small feature from the design phase.
• Tasks:
1. Use a programming language (e.g., Python) to develop one module of the system.
2. Implement core functionality based on the system design.
3. Perform basic code testing for accuracy.
• Takeaway Activity: Document the development process and any issues encountered.
Lab 4: Testing
• Objective: To test the system for bugs and performance issues.
• Tasks:
1. Develop test cases for the system and perform unit testing.
2. Test the system’s user interface for usability.
3. Perform load testing to ensure system scalability.
• Takeaway Activity: Prepare a test report with identified bugs and their resolutions.
Lab 5: Deployment and Maintenance
• Objective: To deploy a system and implement updates.
• Tasks:
1. Deploy the developed system in a virtual environment.
2. Conduct post-deployment testing.
3. Implement a minor update and perform regression testing.
Takeaway Activity: Write a post-deployment review report.
Lab 6: Introduction to SDLC Models
• Objective: Understand the different SDLC models and their applications.
• Tasks:
1. Define SDLC and its importance in software development.
2. Identify and describe the common SDLC models (Waterfall, Agile, V-Model,
Spiral, etc.).
3. Compare the advantages and disadvantages of each model using a table.
4. Analyze the phases of the Waterfall model, providing examples for each phase. Lab
7: Waterfall Model - Hands-On
• Objective: Gain experience with the Waterfall model through a structured case study.
• Tasks:
1. Define the project scope for a Library Management System.
2. Break down the project into the Waterfall phases: Requirements, Design,
Implementation, Testing, Deployment, and Maintenance.
3. Prepare a Gantt chart to track project progress in the Waterfall model.
4. Develop a mini prototype for the system’s user registration feature and document
each Waterfall phase.
Lab 8: Agile Model - Simulation
• Objective: Apply Agile principles using sprints.

Page 110 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
• Tasks:
1. Work in teams to simulate 2 Agile sprints to develop a To-Do List application.
2. Prepare user stories for each sprint.
3. Implement and demonstrate the minimum viable product (MVP) after the first
sprint.
4. Gather feedback, refine the product, and develop the next iteration in Sprint 2.
5. Document sprint planning and retrospective meetings. Lab 9: V-Model -
Verification and Validation
• Objective: Understand the parallel development and testing phases in the V-Model.
• Tasks:
1. Choose a Hospital Management System and outline the system’s requirements.
2. Prepare test cases for the Unit Testing, Integration Testing, System Testing, and
User Acceptance Testing (UAT) stages.
3. Map each development phase (Requirements, Design, Implementation) to its
corresponding testing phase (UAT, System Testing, etc.).
Lab 10: Spiral Model - Risk Management
• Objective: Apply risk management principles within the Spiral model.
• Tasks:
1. Define a case study for a Secure Online Banking System.
2. Identify potential risks in each cycle of the Spiral model and propose mitigation
strategies.
3. Develop a prototype for a secure login module, following the Spiral model's
planning, risk analysis, and engineering phases.
4. Document feedback and refinement for each Spiral iteration. Lab 11: RAD Model
- Rapid Prototyping
• Objective: Practice rapid prototyping in RAD.
• Tasks:
1. Work in pairs to design a small e-commerce website with basic functionalities
(product search, add to cart, checkout).
2. Build a prototype using RAD tools such as Figma or a simple web development
framework.
3. Present the prototype to classmates for feedback.
4. Iterate based on user feedback and refine the prototype.

Revision Questions
1. Define SDLC.
2. Explain the key objectives of the planning phase in the SDLC.
3. How do functional and non-functional requirements differ? Provide examples for each.
4. What are the potential risks involved during the deployment phase, and how can they be
mitigated?

Page 111 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
5. Define user-centered design and explain its importance in system development.
6. How can flexibility in system development reduce future costs?
7. Discuss how risk management helps ensure the success of a system project.
8. Why is it important for a system to align with business objectives?
9. How can a well-implemented information system give a company a competitive advantage?
10. How does clear requirements analysis reduce the risk of project failure?
11. In what ways does effective system design contribute to long-term scalability?
12. Why SDLC is important for software development projects
13. Compare the Waterfall and Agile models. List three differences.
14. Explain the V-Model. How does it ensure software verification and validation?
15. What are the advantages and disadvantages of the Spiral Model?
16. When would you recommend using the RAD Model over the Waterfall Model?
17. What is meant by risk management in the Spiral model? 18. How does user feedback impact
the Agile and Prototype models?

Examination Questions
1. Describe the role of system analysis in the SDLC and explain its importance for successful
system development.
2. Outline the principles of quality assurance during system development and provide examples
of quality assurance methods.
3. Compare and contrast the waterfall model and agile methodology in the context of the SDLC.
What are the strengths and weaknesses of each?
4. Discuss the importance of aligning information systems with business objectives. Use
examples to support your points.
5. Describe the key phases of the Waterfall Model.
6. What is the significance of user stories in Agile methodology?
7. How does the Spiral model handle risks differently from other SDLC models?
8. Name two scenarios where the RAD Model is most appropriate.
9. Explain continuous integration in the Agile SDLC approach.
10. Discuss how the V-Model integrates testing at every phase of development. Provide examples.
11. Compare and contrast the Agile Model and the Waterfall Model in terms of flexibility,
development speed, and risk management.

Page 112 of
116
 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
12. Explain the core principles of the Spiral Model. How does it mitigate risks during software
development?
13. Discuss the evolution of SDLC models from traditional models like Waterfall to modern Agile
methodologies. How has this shift impacted software project management?
14. Compare and contrast the Waterfall Model and Spiral Model with a focus on risk management,
time efficiency, and cost.
15. Evaluate the importance of user feedback in the Prototype and RAD models. How does it
influence the final software product’s success?
16. Analyze the V-Model’s effectiveness in safety-critical systems, such as in healthcare or
aerospace industries, and explain why verification and validation are crucial.
17. Explain the role of iterative cycles in Agile development. How do Agile practices support
fastpaced, rapidly changing projects?

Practical Questions
1. Create a data flow diagram for a library management system that includes user registration,
book lending, and inventory management.
2. Develop a testing plan for an e-commerce system, including both functional and non-
functional testing requirements.
3. You are asked to build a Travel Booking System using the Waterfall Model. Identify and
describe the six phases of the Waterfall model and how you would apply them to this project.
• Provide sample deliverables for each phase (e.g., Requirements Document, Design
Document).
4. Develop a prototype for a food delivery app using the Prototype Model.
• Create an initial user interface and core functionality (e.g., select food items, add to cart).
Gather feedback and refine the prototype based on user input.

Group Discussion Questions

1. Discuss the importance of user-centered design and its impact on user satisfaction. How can
developers ensure that user requirements are accurately reflected in the final product?
2. How do system analysis and design phases interact to ensure a scalable and efficient system?
Provide real-world examples where poor system design led to system failure.
3. In a world where business operations are increasingly reliant on data, how can information
systems be developed to support real-time decision-making?
4. What are the benefits and challenges of applying iterative development models (e.g., agile) in
large-scale system development projects?
5. Analyze the role of risk management in the SDLC. How can risks such as changing business
requirements or technology failures be addressed early in the system development process?
6. Which SDLC model is best suited for mobile app development, and why?
7. How does the Agile Model ensure adaptability to changing customer requirements?
8. In what situations might the Spiral Model outperform the V-Model?

Page 113 of 116

 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
9. How can RAD (Rapid Application Development) help reduce time-to-market for startups with
limited resources?
10. What are the challenges of implementing the Waterfall Model in modern software
development?

Case Studies
Case Study 1: Healthcare Management System Development
Scenario: A hospital is looking to implement a new system to manage patient records, staff
schedules, and billing. The existing manual system is slow and prone to errors.
• Objective: Evaluate the hospital’s business needs and recommend an SDLC approach.
• Key Questions:
1. What business needs should the system address (e.g., improve patient care,
streamline billing)?
2. Which SDLC model (waterfall, agile, etc.) would be most appropriate and why?
3. How would you ensure user-centered design for both medical staff and
administrators?

Case Study 2: E-Commerce System Redesign

Scenario: A retail company is struggling with an outdated e-commerce platform that is slow and
does not integrate with their inventory system.
• Objective: Develop a system analysis and design proposal to address the company’s
challenges.
• Key Questions:
1. What functional and non-functional requirements should be prioritized in the
redesign?
2. How can the new system be designed to accommodate future growth (e.g., scaling
to handle more users)?
3. What risks should be considered during system deployment, and how can they be
mitigated?

Case Study 3: University Enrollment System

Scenario: A university is planning to shift its enrollment process from paper-based to an
automated online system. The system needs to handle student applications, course registration,
and fee payments.
• Objective: Analyze the system requirements and recommend design strategies.
• Key Questions:
1. What steps should be taken during the requirement gathering phase to ensure the
system meets both administrative and student needs?
2. How can the system be designed to ensure security, particularly for sensitive
student data?

Page 114 of 116

 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
3. What are the key testing phases that should be undertaken before deploying the
system?

Case Study 4: Implementing Agile in an E-Commerce Platform

• Scenario: A growing e-commerce company wants to introduce new features such as
personalized product recommendations and multi-currency payment options. The
customer demands frequent updates and the ability to quickly respond to competitor
features.
• Questions:
1. How can the Agile Model benefit this project in terms of adaptability and user
satisfaction?
2. Design an Agile sprint that would cover the development of the new personalized
recommendations feature. Include user stories and sprint goals.

Case Study 5: Waterfall Model for Banking Software

• Scenario: A bank is developing a new loan management system that must comply with
strict regulations. The development process needs to be controlled and well-documented.
• Questions:
1. Explain why the Waterfall Model is suitable for this project.
2. Describe the documentation required at each phase of the Waterfall Model for this
banking system.

Case Study 6: Spiral Model in a Government Project

• Scenario: A government organization is developing a secure citizen portal that involves
handling sensitive personal information. The project has a high level of risk due to
security concerns and privacy regulations.
• Questions:
1. How does the Spiral Model help in managing risks for this project?
2. Describe the potential risks and how the risk analysis phase of the Spiral Model
can mitigate them.

Case Study 7: Prototype Model for a Healthcare App

• Scenario: A healthcare startup is building an app for remote patient monitoring. The
requirements are still evolving as the team gathers feedback from doctors and patients.
• Questions:
1. How would the Prototype Model help the developers understand user needs?
2. Describe how user feedback during the prototyping phase could lead to changes in
the app’s features.

Page 115 of 116

 DEPARTMENT OF INFORMATION TECHNOLOGY
BIT2150 2024/2025
Case Study 8: RAD Model for a Restaurant Management System
• Scenario: A restaurant chain needs a management system that can handle orders, track
inventory, and manage staff scheduling. The project is time-sensitive, and the client
wants a fast turnaround with room for adjustments.
• Questions:
1. Explain why RAD (Rapid Application Development) would be an effective
choice for this project.
2. Describe how rapid prototyping could help in refining the system before the final
product is delivered.

Page 116 of 116