CB-403 SOFTWARE ENGINEERING

SYLLABUS

▪ Introduction: Programming in the small vs. programming

in the large; software project failures and importance of
software quality and timely availability; of software
engineering towards successful execution of large software
projects; emergence of software engineering as a
discipline, Software Engineering Historical Development
from Jackson Structured Programming to Agile
Development.
SYLLABUS

▪ Software Project Management: Basic concepts of life cycle

models – different models and milestones; software
project planning –identification of activities and resources;
concepts of feasibility study; techniques for estimation of
schedule and effort; software cost estimation models and
concepts of software engineering economics; techniques of
software project control and reporting; introduction to
measurement of software size; introduction to the
concepts of risk and its mitigation; configuration
management.
SYLLABUS

▪ Software Quality Management and Reliability: Software

quality; Garvin’s quality dimensions, McCall’s quality factor,
ISO 9126 quality factor; Software Quality Dilemma;
Introduction to Capability Maturity Models (CMM and
CMMI); Introduction to software reliability, reliability
models and estimation.
SYLLABUS

▪ Software Requirements Analysis, Design and Construction:

Introduction to Software Requirements Specifications
(SRS) and requirement elicitation techniques; techniques
for requirement modelling – decision tables, event tables,
state transition tables, Petri nets; requirements
documentation through use cases; introduction to UML,
introduction to software metrics and metrics-based control
methods; measures of code and design quality.
SYLLABUS

▪ Object Oriented Analysis, Design and Construction:

Concepts -- the principles of abstraction, modularity,
specification, encapsulation and information hiding;
concepts of abstract data type; Class Responsibility
Collaborator (CRC) model; quality of design; design
measurements; concepts of design patterns; Refactoring;
object-oriented construction principles; object oriented
metrics.
SYLLABUS

▪ Software Testing: Introduction to faults and failures; basic

testing concepts; concepts of verification and validation;
black box and white box tests; white box test coverage –
code coverage, condition coverage, branch coverage; basic
concepts of black-box tests – equivalence classes,
boundary value tests, usage of state tables; testing use
cases; transaction based testing; testing for non-functional
requirements – volume, performance and efficiency;
concepts of inspection; Unit Testing, Integration Testing,
System Testing and Acceptance Testing.
SYLLABUS

▪ Agile Software Engineering: Concepts of Agile Methods,

Extreme Programming; Agile Process Model - Scrum,
Feature; Scenarios and Stories
BREAKING THE MYTHS!!!!
SOFTWARE ENGINEERING IS A
PURELY THEORITICAL SUBJECT
SOFTWARE ENGINEERING HAS
NO FUTURE SCOPE
THE 33+ VERTICALS THEORY
SOFTWARE ENGINEERING IS
BORING
What is Software?

▪ The product that software professionals build and then support over
the long term.
▪ Software encompasses:
(1) instructions (computer programs) that when executed provide
desired features, function, and performance;
(2) data structures that enable the programs to adequately store and
manipulate information and
(3) documentation that describes the operation and use of the
programs.
Why Software is Important?

• The economies of ALL developed nations are dependent on

software.
• More and more systems are software controlled ( transportation,
medical, telecommunications, military, industrial, entertainment,)
• Software engineering is concerned with theories, methods and
tools for professional software development.
• Expenditure on software represents a significant fraction of GNP in all
developed countries.
Software Applications

• 1. System software: such as compilers, editors, file management

utilities
• 2. Application software: stand-alone programs for specific needs.
• 3. Engineering/scientific software: Characterized by “number
crunching”algorithms. such as automotive stress analysis,
molecular biology, orbital dynamics etc
• 4. Embedded software resides within a product or system. (key pad
control of a microwave oven, digital function of dashboard display in a
car)
Software Applications

• Open world computing—pervasive, ubiquitous, distributed

computing due to wireless networking. How to allow mobile
devices, personal computer, enterprise system to
communicate across vast network.
• Netsourcing—the Web as a computing engine. How to
architect simple and sophisticated applications to target
end-users worldwide.
• Open source—”free” source code open to the
computing community (a blessing, but also a potential
curse!)
Product characteristic Description
Software should be written in such a way so that it can evolve to
meet the changing needs of customers. This is a critical attribute
Maintainability because software change is an inevitable requirement of a
changing business environment.
Software dependability includes a range of characteristics
Dependability including reliability, security and safety. Dependable software
and security should not cause physical or economic damage in the event of
system failure. Malicious users should not be able to access or
damage the system.

Software should not make wasteful use of system resources such

Efficiency as memory and processor cycles. Efficiency therefore includes
responsiveness, processing time, memory utilisation, etc.

Software must be acceptable to the type of users for which it is

Acceptability designed. This means that it must be understandable, usable and
compatible with other systems that they use.
Introduction to
Software Engineering
and Why It Is Studied?
Subtitle
What is Software Engineering?

▪ Software Engineering is the process of designing, developing,

testing, and maintaining software applications systematically.
▪ Think of building a house. If you don’t follow proper planning,
architecture, and safety measures, your house might collapse.
Similarly, if software is not engineered properly, it will have bugs,
crashes, and security issues.
▪ Just like Civil Engineers build bridges using structured
methodologies, Software Engineers develop software using rules,
principles, and best practices to ensure it is reliable, scalable, and
efficient.
Software Engineering Definition

▪ The seminal definition:

▪ [Software engineering is] the establishment and use of sound
engineering principles in order to obtain economically software
that is reliable and works efficiently on real machines.
Software Engineering Definition

▪ The IEEE definition:

▪ Software Engineering: (1) The application of a systematic,
disciplined, quantifiable approach to the development, operation,
and maintenance of software; that is, the application of
engineering to software. (2) The study of
approaches as in (1).
Why Do We Need Software Engineering?

▪ Problem Without SE: Before software engineering principles were

developed, software projects failed due to lack of planning, poor
design, and inefficient coding.

▪ Real-World Analogy: Imagine cooking a meal without a recipe—it

might taste bad or not be edible at all. Software development
without engineering leads to bad software that is full of errors and
difficult to use.
Why Do We Need Software Engineering?

Key Reasons for Software Engineering:

1. Better Planning – Reduces errors and improves efficiency.
2. Cost Management – Saves money by preventing costly failures.
3. Scalability – Ensures software grows as users increase.
4.Security – Protects against cyber threats.
5. Maintenance – Makes future updates easier.
Software Engineering vs. Traditional
Coding

Aspect Just Coding (No SE) Software Engineering

No planning, just Structured planning
Planning & Design
writing code before coding
Designed to grow with
Scalability Hard to expand
demand
Many errors, difficult to Fewer bugs, easy
Bug Handling
fix debugging
Hard for teams to work
Collaboration Team-friendly process
together
Easy to modify &
Maintenance Difficult to update
improve
Fields Where Software Engineering is
Used

Software Engineering is everywhere!

1. Healthcare – Hospital management systems, AI for disease
diagnosis.
2. Banking & Finance – Secure online transactions, fraud detection.
3. Entertainment – Video streaming (Netflix, YouTube), gaming (PUBG,
GTA).
4.E-commerce – Amazon, Flipkart, payment gateways.
5. Transport & Automation – Self-driving cars, traffic management.
Programming in the
Small vs. Programming
in the Large
Subtitle
Introduction – What Does This Mean?

▪ When learning programming, you usually start by writing

small programs (like basic calculators, to-do lists, or simple
games).
▪ However, real-world software projects (like Google,
Facebook, or banking systems) are huge and require
teamwork, structure, and planning.
Introduction – What Does This Mean?

This leads us to two types of programming:

▪ Programming in the Small – Writing small, simple programs, often by
a single person.
▪ Programming in the Large – Developing large, complex software
systems with teams, structured planning, and long-term
maintenance.
▪ Real-World Analogy: Think of building a toy car vs. building a real car
factory. A toy car can be built alone with simple tools, but
manufacturing real cars needs hundreds of engineers, machines, and
a production system.
Understanding Programming in the Small

Definition: Writing small-scale programs that are typically developed

by a single person or a small group with minimal complexity.
Key Characteristics:
▪ Few lines of code (100s or a few 1000s of lines).
▪ Written by a single developer or a small team.
▪ No need for advanced tools, just an IDE and basic programming
knowledge.
▪ Less focus on design, documentation, and scalability.
▪ Easier to debug and maintain.
Understanding Programming in the Small

Examples of Small Programs:

▪ A simple calculator.
▪ A weather app for personal use.
▪ A script that renames files in a folder.

Real-World Analogy:Writing a diary entry—it’s just for you, simple, and

easy to edit anytime.
Understanding Programming in the Large

Definition: Developing large-scale software projects that require multiple

developers, structured collaboration, and long-term maintenance.
Key Characteristics:
▪ Millions of lines of code.
▪ Developed by teams spread across the world.
▪ Requires project management, software architecture, and documentation.
▪ Uses version control systems (Git), cloud deployment, and collaboration
tools.
▪ Needs testing, debugging, and regular updates.
Understanding Programming in the Large

Examples of Large Software Systems:

▪ Google Search Engine.
▪ Banking systems.
▪ Operating Systems like Windows or Linux.

Real-World Analogy: Writing a Hollywood movie script—it involves

writers, editors, directors, and producers, each with different
responsibilities. You can’t do it alone!
Key Differences Between Programming in
the Small & Large

Feature Programming in the Small Programming in the Large

Small (hundreds to
Code Size Large (millions of lines)
thousands of lines)
Large teams across
Number of Developers 1 or a small team
locations
High (many
Complexity Low
interconnected modules)
Version control, CI/CD,
Tools Required Basic IDE cloud, project
management tools
Development Time Days or weeks Months to years
Example Personal diary app Facebook, Google Maps
Why is This Important?

▪ As a beginner, you start with programming in the small to build logic

and problem-solving skills.
▪ When working in the industry, you will work on programming in the
large, collaborating with teams.
▪ Companies need software engineers, not just programmers—people
who can work in teams, understand project structure, and think
about scalability.
▪ Learning to cook at home is great, but if you want to be a chef in a 5-
star restaurant, you need to learn teamwork, food safety, and large-
scale cooking techniques.
Add a Slide Title - 5
Software Project
Failures, Importance of
Software Quality, and
Timely Availability
Subtitle
Introduction – Why Do Software Projects
Fail?

• Imagine a team is building a skyscraper but doesn’t follow

a proper blueprint, uses weak materials, and misses the
deadline. What will happen? It will collapse!
• The same thing happens in software projects when there
is no proper planning, poor quality, and missed deadlines.
• Statistics: Studies show that over 50% of software
projects fail due to poor management, bad coding, and
delays.
Introduction – Why Do Software Projects
Fail?

Common Reasons for Software Failures:

Poor requirements gathering: Incomplete, inaccurate or
constantly changing requirements can lead to project failure. If
the project requirements are not properly defined, it may lead
to scope creep, missed deadlines, and budget overruns.

Lack of project management: Without proper project

management, it is difficult to ensure that tasks are being
completed on time, within budget, and to the required quality
standards. Poor project management can lead to
communication breakdowns, scope creep, and missed
deadlines.
Introduction – Why Do Software Projects
Fail?

Inadequate resources: Insufficient resources, including

people, tools, and infrastructure can lead to delays, low-
quality output, and project failure.

Poor communication: Lack of communication or

miscommunication among stakeholders, team members,
and other parties involved in the project can lead to
misunderstandings, rework, and ultimately project failure.
Introduction – Why Do Software Projects
Fail?

Technical issues: Technical problems such as poor system

architecture, performance issues, and software defects
can significantly impact project success. These issues can
cause delays, lower quality output, and increased costs.

Unrealistic expectations: Unrealistic expectations

regarding project scope, timeline, and budget can lead to
overpromising and underdelivering, resulting in project
failure.
Introduction – Why Do Software Projects
Fail?

Scope creep: Scope creep occurs when the project scope

expands beyond the original requirements, which can lead
to missed deadlines, budget overruns, and poor quality
output.

Inadequate testing: Inadequate testing, including poor

test planning and execution, can lead to undetected
defects and poor software quality, ultimately leading to
project failure.
Introduction – Why Do Software Projects
Fail?

Lack of user involvement: Failure to involve end-users or

stakeholders in the development process can lead to a
product that does not meet their needs, resulting in a
failed project.

External factors: External factors such as changes in

regulations, unexpected economic or political events, and
technology disruptions can impact project success.
Introduction – Why Do Software Projects
Fail?

Think of a wedding where the decorations are

incomplete, food is not ready, and the guests arrive
late—it’s a complete disaster! That’s what happens
when software projects fail.
Real-World Examples of Software Project
Failures

Famous Software Disasters

1. Windows Vista (2007) – Slow, buggy, and crashed often, leading to failure.
2. Samsung Galaxy Note 7 (2016) – Poor quality control led to batteries
exploding!
3. Heathrow Airport Baggage System (2008) – A software glitch caused
chaos, losing thousands of passengers’ luggage.
4. Knight Capital Trading Software (2012) – A bug lost the company $440
million in 45 minutes.
5. Cyberpunk 2077 (2020) – Released too early with too many bugs, leading to
customer backlash.
Real-World Examples of Software Project
Failures

Lessons from These Failures:

• Rushing software without testing = disaster.
• Ignoring customer needs = waste of effort.
• Poor coding quality = huge financial losses.

Real-World Analogy:
Releasing software without proper testing is like selling a car without
brakes—customers will get hurt, and your company will be sued!
Importance of Software Quality

• What is Software Quality?

• Software quality means the software is reliable, secure, fast,
and easy to use.
• Good software = Happy users + Higher profits.

• Real-World Analogy:
• Think of a restaurant: If the food is bad, service is slow, and
hygiene is poor, no one will return. Similarly, bad software drives
customers away.
Importance of Software Quality

Key Aspects of Software Quality:

1. Reliability – The software should work without crashing.
2. Performance – It should run smoothly without lag.
3. Security – Protects against hacking and data breaches.
4.User Experience (UX) – Should be easy and enjoyable to use.
5. Maintainability – Easy to update and fix in the future.
Why Timely Availability of Software is
Crucial

• What Happens When Software is Delayed?

• Customers move to competitors.

• Company loses money.
• Market trends change, making the software outdated.
Why Timely Availability of Software is
Crucial

Example: Nokia’s Fall

Nokia delayed launching Android smartphones while Apple and
Samsung took over the market.
Result? Nokia lost its position as the world’s top phone company.
Example: Cyberpunk 2077’s Early Release Disaster
The game was released too soon due to pressure.
Bugs and glitches caused refund requests worth millions.
Why Timely Availability of Software is
Crucial

Real-World Analogy:
• A pizza delivery service that always arrives late loses customers.
• In the software industry, delayed software = lost customers &
money.
Why Timely Availability of Software is
Crucial

Meeting stakeholder expectations: High software quality and timely

availability of software engineering can ensure that the project meets
stakeholder requirements and is delivered on time.

Ensuring project success: Poor quality software and delayed software

engineering can result in missed deadlines, budget overruns, and
ultimately project failure.
Why Timely Availability of Software is
Crucial

Minimizing rework: High software quality and timely availability of

software engineering can minimize the need for rework, which can be
costly and time-consuming.

Improving customer satisfaction: Customers expect software that is

reliable, efficient, and meets their needs. By delivering high-quality
software on time, customer satisfaction can be improved.
Why Timely Availability of Software is
Crucial

Reducing costs: High software quality and timely availability of

software engineering can help to reduce project costs. By avoiding
rework and ensuring that the software is delivered on time, project
costs can be minimized.

Maintaining competitiveness: In today's highly competitive software

industry, it is important to deliver high-quality software on time. By
doing so, an organization can maintain its competitiveness and meet
the demands of its customers.
How to Avoid Software Failures?

Best Practices to Ensure Quality & Timely Software Delivery

1. Proper Planning – Define clear goals and scope.
2. Effective Team Communication – Ensure all team members understand
their tasks.
3. Regular Testing – Find and fix bugs before launch.
4. Customer Feedback – Gather user reviews before full release.
5. Agile Development – Work in small iterations instead of waiting for a big
final release.
6. Use Automation – Automate testing and deployment to speed up delivery.
The Emergence of
Software Engineering as
a Discipline and the
Historic Development
from Jackson Structured
Programming to Agile
Development
Why Did Software Engineering Become a
Discipline?

• In the early days of computing (1950s-1960s), software development

was simple—one person could write small programs.
• As computers became more powerful, software grew in complexity,
leading to frequent errors, delays, and project failures.
• This led to the Software Crisis in the late 1960s:
• Projects were too big and unmanageable.
• Software had too many bugs.
• Deadlines were missed, and costs skyrocketed.
• Code was difficult to maintain.
Why Did Software Engineering Become a
Discipline?

Real-World Analogy:
▪ Imagine a small bakery where one person can bake and manage
everything. But if the bakery expands into a big restaurant, the
owner needs chefs, managers, waiters, and proper systems to
handle operations.
▪ This is why software development needed structured approaches—
leading to the birth of Software Engineering.
Why Did Software Engineering Become a
Discipline?

Today, software engineering is an established discipline with its own

body of knowledge, academic programs, and professional
associations. It is recognized as a critical component of the software
industry, enabling organizations to develop high-quality software
systems that meet the needs of their customers and stakeholders.
Why Did Software Engineering Become a
Discipline?

Today, software engineering is an established discipline with its own

body of knowledge, academic programs, and professional
associations. It is recognized as a critical component of the software
industry, enabling organizations to develop high-quality software
systems that meet the needs of their customers and stakeholders.
Why Did Software Engineering Become a
Discipline?

Enables development of high-quality software: Software

engineering provides the tools, techniques, and methodologies
required to develop software systems that are reliable, efficient,
and maintainable.
Ensures software meets user requirements: Software engineering
helps to ensure that software systems meet the needs and
requirements of their users, through rigorous analysis and
requirements engineering.
Why Did Software Engineering Become a
Discipline?

Facilitates teamwork: Software engineering provides a framework

for collaborative teamwork, ensuring that software development
projects are completed by multidisciplinary teams with the
necessary skills and expertise.
Promotes efficiency: Software engineering helps to increase
efficiency in the software development process, through the use of
standardized processes and practices that minimize errors and
rework.
Why Did Software Engineering Become a
Discipline?

Improves project management: Software engineering provides a

structured approach to project management, with well-defined
roles and responsibilities, clear project objectives, and effective
communication among team members.

Enhances software security: Software engineering helps to enhance

software security, by ensuring that security considerations are built
into the software development process from the outset.
Why Did Software Engineering Become a
Discipline?

Supports software maintenance: Software engineering provides a

framework for software maintenance, ensuring that software
systems can be updated and modified as required over their
lifetime.
Enables software reusability: Software engineering encourages the
development of reusable software components, enabling
organizations to save time and resources by reusing existing
software.
Why Did Software Engineering Become a
Discipline?

software testing: Software engineering provides a range of testing

techniques and tools to ensure that software systems are
thoroughly tested before release, minimizing the risk of defects and
errors.
Supports continuous improvement: Software engineering
encourages a culture of continuous improvement, enabling
organizations to learn from their experiences and improve their
software development processes over time.
Early Structured Programming (1960s-1970s) –
Jackson Structured Programming (JSP)

Content:
• What is Jackson Structured Programming (JSP)?
• Introduced by Michael A. Jackson in the 1970s.
• One of the first formal structured programming methods.
• Focused on breaking big programs into smaller, well-organized
modules.
Early Structured Programming (1960s-1970s) –
Jackson Structured Programming (JSP)

▪ Key Features of JSP:

1. Programs were divided into sequence, iteration, and selection
(similar to modern flowcharts).
2. Introduced top-down design—writing the main logic first, then
breaking it into smaller components.
3. Used data-driven design—first analyze data structure, then design
the program.
Early Structured Programming (1960s-1970s) –
Jackson Structured Programming (JSP)

▪ Think of building a house:

• JSP is like creating a blueprint before constructing the house,
ensuring everything is planned and structured.
Phases of JSD:

▪ JSD has 3 phases:

▪ Modelling Phase: In the modelling phase of JSD, the designer creates a
collection of entity structure diagrams and identifies the entities in the
system, the actions they perform, the attributes of the actions and the time
order of the actions in the life of the entities.
▪ Specification Phase: This phase focuses on actually what is to be done?
Previous phase provides the basic for this phase. An sufficient model of a
time-ordered world must itself be time-ordered. Major goal is to map
progress in the real world on progress in the system that models it.
▪ Implementation Phase: In the implementation phase JSD determines how
to obtain the required functionality. Implementation way of the system is
based on the transformation of the specification into an efficient set of
processes. The processes involved in it should be designed in such a manner
that it would be possible to run them on available software and hardware
Phases of JSD:

▪ JSD has 3 phases:

▪ Modelling Phase: In the modelling phase of JSD, the designer creates a
collection of entity structure diagrams and identifies the entities in the
system, the actions they perform, the attributes of the actions and the time
order of the actions in the life of the entities.
▪ Specification Phase: This phase focuses on actually what is to be done?
Previous phase provides the basic for this phase. An sufficient model of a
time-ordered world must itself be time-ordered. Major goal is to map
progress in the real world on progress in the system that models it.
▪ Implementation Phase: In the implementation phase JSD determines how
to obtain the required functionality. Implementation way of the system is
based on the transformation of the specification into an efficient set of
processes. The processes involved in it should be designed in such a manner
that it would be possible to run them on available software and hardware
Evolution to Waterfall Model (1970s-
1980s)

Content:
• As projects grew bigger, structured programming alone wasn’t
enough.
• The Waterfall Model was introduced—software was developed in
phases, like an assembly line.
Evolution to Waterfall Model (1970s-
1980s)

Phases of the Waterfall Model:

1. Requirements Analysis – Understand what the software should do.
2. System Design – Create a technical blueprint.
3. Implementation (Coding) – Write the actual program.
4.Testing – Find and fix bugs.
5. Deployment – Release the software.
6.Maintenance – Update and fix after launch.
Evolution to Waterfall Model (1970s-
1980s)
Evolution to Waterfall Model (1970s-
1980s)

▪ Real-World Analogy:
• The Waterfall Model is like building a skyscraper—if you realize the
foundation is weak at the 10th floor, you can’t go back and fix it
easily.
Rise of Iterative & Agile Development
(1990s-Present)

▪ Content:
• In the 1990s, companies realized Waterfall was too rigid, leading to
the rise of Iterative and Agile models.
• The Agile Manifesto (2001) introduced flexible, fast, and customer-
focused software development.
Rise of Iterative & Agile Development
(1990s-Present)

What is Agile Development?

Breaks projects into small parts (iterations/sprints)..

Each part is tested and improved continuously.

Customers give feedback frequently.

.
Changes are welcomed anytime.
Rise of Iterative & Agile Development
(1990s-Present)

Popular Agile Methods:

1. Scrum – Small teams work in short development cycles (sprints).
2. Kanban – Uses visual boards to track progress.
3. Extreme Programming (XP) – Focuses on frequent releases and
continuous testing.
Rise of Iterative & Agile Development
(1990s-Present)

▪ Real-World Analogy:
• Agile is like building a mobile app in versions:
• Version 1.0: Basic features.
• Version 2.0: Add new features based on user feedback.
• Version 3.0: Improve design and fix issues.
Content:

Rise of Iterative & Agile Development

(1990s-Present)

Era Methodology Key Characteristics

Jackson Structured Modular design,
1970s
Programming (JSP) structured approach
Linear, rigid, phase-wise
1980s Waterfall Model
development
Feedback-based
1990s Iterative Development
improvements
Agile Development Flexible, customer-
2000s
(Scrum, Kanban, XP) driven approach
DevOps & Continuous Automation, cloud-
Present
Integration based rapid delivery
Rise of Iterative & Agile Development
(1990s-Present)

▪ Why Agile is the Future?

▪ Companies like Google, Amazon, and Microsoft use Agile
because it allows rapid innovation.
Software evolves continuously instead of waiting for a big release.
▪ Real-World Analogy:
• The shift from Waterfall to Agile is like moving from old-school
textbook learning to online learning platforms where content is
updated instantly.
Introduction – What is
Software Development
Life Cycle (SDLC)?
What is Software Development Life Cycle
(SDLC)?

▪ Content:
• Imagine you are opening a new restaurant. Would you start cooking
first or plan everything step by step?
• Software development is the same! SDLC is a structured process
that guides how software is built, tested, and delivered efficiently.
What is Software Development Life Cycle
(SDLC)?

▪ Definition of SDLC:
• SDLC is a systematic process used by software engineers to design,
develop, test, and maintain software efficiently.
• It ensures software is high quality, cost-effective, and delivered on
time.
What is Software Development Life Cycle
(SDLC)?

Key Phases of SDLC:

1. Requirement Analysis – Understanding what the software should
do.
2. System Design – Creating a blueprint for development.
3. Implementation (Coding) – Writing the actual code.
4.Testing – Finding and fixing errors.
5. Deployment – Delivering the software to users.
6.Maintenance – Updating and improving software after launch.
What is Software Development Life Cycle
(SDLC)?

Real-World Analogy:
SDLC is like opening a restaurant:
• Step 1: Decide the menu (Requirements).
• Step 2: Design the restaurant layout (System Design).
• Step 3: Hire chefs and start cooking (Implementation).
• Step 4: Taste the food before serving (Testing).
• Step 5: Open the restaurant for customers (Deployment).
• Step 6: Fix issues & update the menu regularly (Maintenance).
Phase 1 – Requirement Analysis

Real-World Analogy:
SDLC is like opening a restaurant:
• Step 1: Decide the menu (Requirements).
• Step 2: Design the restaurant layout (System Design).
• Step 3: Hire chefs and start cooking (Implementation).
• Step 4: Taste the food before serving (Testing).
• Step 5: Open the restaurant for customers (Deployment).
• Step 6: Fix issues & update the menu regularly (Maintenance).
Phase 1 – Requirement Analysis

Content:
• Before starting software development, we must clearly define the
project goals.
• The development team gathers requirements from clients and
users.
Key Activities in Requirement Analysis:
▪ Identify user needs and expectations.
Conduct meetings with stakeholders (clients, end-users,
developers).
Create a Software Requirement Specification (SRS) document.
Phase 1 – Requirement Analysis

Developing a food delivery app like Zomato or Swiggy:

Users want restaurant search, online payment, and delivery
tracking.
Businesses want order management, revenue tracking, and
promotions.
Phase 1 – Requirement Analysis

Real-World Analogy:
• This is like planning a road trip:
• Where do you want to go? (User Needs)
• What vehicle will you use? (Technology Requirements)
• What route will you take? (Project Plan)
Phase 2 – System Design

Content:
• Once requirements are clear, developers create a design plan to
structure the software.
Key Activities in System Design:
▪ Create architectural diagrams.
Decide technologies and databases.
Plan UI/UX design (how the software will look and function).
Phase 2 – System Design

▪ Example:
Designing a food delivery app:
• Decide database structure for orders & users.
• Design restaurant listing page and payment flow.
Phase 3 – Implementation

▪ Content:
• This is the stage where actual coding happens based on the design.
• Developers write code in programming languages like Python, Java,
C++.
• Use Version Control Systems like Git to track changes.
Phase 3 – Implementation

▪ Key Activities in Implementation:

▪ Writing clean, efficient, and well-structured code.
Collaborating with team members using GitHub/GitLab.
Regular code reviews to ensure quality.
Phase 3 – Implementation

▪ Example:
• In a food delivery app, programmers write code to:
• Show nearby restaurants.
• Process payments securely.
• Track delivery location in real-time.
Phase 4 – Testing, Deployment, and
Maintenance

▪ Example:
• In a food delivery app, programmers write code to:
• Show nearby restaurants.
• Process payments securely.
• Track delivery location in real-time.
Testing Phase (Finding & Fixing Errors)

▪ Content:
▪ (A) Testing Phase (Finding & Fixing Errors)
• Before releasing the software, QA engineers test it for bugs.
• Types of testing:
• Unit Testing – Test individual functions.
• Integration Testing – Check if modules work together.
• User Acceptance Testing (UAT) – Ensure software meets user expectations.
Testing Phase (Finding & Fixing Errors)

▪ Example:
• A food delivery app is tested for:
• Placing an order – Does it work correctly?
• Payment security – Are transactions safe?
• Delivery tracking – Is location updating correctly?
Deployment Phase

▪ Deployment Phase (Launching the Software)

• The software is released to users after successful testing.
• Deployment Strategies:
• Big Bang Deployment – Release everything at once.
• Phased Deployment – Release in stages for different regions.
• Beta Testing – Give early access to a small group of users.
Deployment Phase

Example:
• A food delivery app might first launch in one city, gather feedback,
and then expand to other locations.
Maintenance Phase

(C) Maintenance Phase (Keeping Software Updated & Bug-Free)

• After deployment, software needs updates, security fixes, and
improvements.
• Three types of maintenance:
• Corrective Maintenance – Fixing bugs and errors.
• Adaptive Maintenance – Updating software for new OS versions.
• Perfective Maintenance – Adding new features based on user feedback.
Maintenance Phase

▪ Example:
• A food delivery app must:
• Fix crashes reported by users.
• Improve UI for better experience.
• Add new features like voice ordering.
Types of Software
Development Models
Waterfall Model – The
Traditional Approach
Waterfall Model

▪ Content:
• One of the earliest models, used when requirements are fixed.
• Development follows a linear, step-by-step process like a waterfall.
Waterfall Model

▪ Phases of Waterfall Model:

1. Requirement Gathering – Understanding what needs to be built.
2. System Design – Creating blueprints for the software.
3. Implementation (Coding) – Writing the actual software.
4.Testing – Ensuring everything works correctly.
5. Deployment – Delivering the software to users.
6.Maintenance – Fixing bugs and making improvements.
Waterfall Model

▪ Example:
• Developing banking software, where requirements are well-defined
and don’t change frequently.
▪ Advantages:
▪ Simple and easy to follow.
Works well for small projects with clear requirements.
▪ Limitations:
▪ No flexibility – Once a phase is completed, you can’t go back.
Slow delivery – The software is delivered only at the end.
Waterfall Model

▪ Real-World Analogy:
• Like baking a cake – You must mix ingredients, bake, and then
decorate. You can’t go back and change the batter once it’s in the
oven.
V-Model – The
Verification &
Validation Model
V-Model

▪ Content:
• Similar to the Waterfall Model, but testing happens at every stage in
parallel with development.
▪ Phases of V-Model:
1. Requirement Analysis Acceptance Testing
2. System Design System Testing
3. Architecture Design Integration Testing
4. Module Design Unit Testing
5. Implementation (Coding)
V-Model

▪ Example:
• Used in medical software where testing is crucial at every phase.
▪ Advantages:
▪ Testing happens early, reducing bugs.
Works well for high-risk projects (healthcare, aerospace).
▪ Limitations:
▪ Expensive due to extensive testing.
Changes in requirements can’t be easily handled.
V-Model
V-Model

▪ Real-World Analogy:
• Like building a car, where testing is done at each step – engine,
brakes, safety, etc., before final assembly.
Incremental & Iterative
Models – Step-by-Step
Progress
Incremental & Iterative Models

▪ Content:
• Instead of developing the entire software at once, these models
break development into smaller parts.
Incremental Model

▪ Incremental Model:
• The project is divided into small functional units that are developed
and delivered in increments.
▪ Example:
• Developing a learning app where first you build a login system, then
video streaming, then quizzes.
Incremental Model

▪ Advantages:
Get working software faster.
Easier to manage risk.
▪ Limitations:
Initial planning must be strong.
Later stages can become complex.
Incremental Model
Iterative Models

▪ Iterative Model:
• Develop an initial basic version and keep improving it in cycles.
Iterative Models

▪ Example:
• Building a social media app where you first launch a simple posting
feature, then add likes, comments, stories, etc..
▪ Advantages:
Feedback is incorporated early.
Reduces time to market.
▪ Limitations:
Requires strong management and planning.
Iterative Models

▪ Real-World Analogy:
• Incremental Model – Like building a Lego house one block at a
time.
• Iterative Model – Like sculpting a statue; you refine it over time.
Spiral, Agile & DevOps
Models – Modern
Approaches
Spiral Model – Best for High-Risk
Projects

▪ Spiral Model – Best for High-Risk Projects

• A combination of Waterfall + Iterative, focusing on risk analysis.
• Used in high-budget, safety-critical software.
Spiral Model – Best for High-Risk
Projects

▪ Example:
• Military or space projects where risk management is crucial.
▪ Advantages:
Great for risk management.
Works well for large, expensive projects.
▪ Limitations:
Very costly and complex.
▪ Real-World Analogy:
• Like building a rocket, where you test every stage before moving
forward.
Spiral Model – Best for High-Risk
Projects
Agile Model – Fast & Flexible

▪ Agile Model – Fast & Flexible

• Instead of following a strict plan, Agile focuses on frequent updates
& customer collaboration.
Agile Model – Fast & Flexible

▪ Example:
• E-commerce websites like Amazon, which constantly update features
based on user feedback.
▪ Advantages:
Fast delivery & continuous improvement.
Customer involvement ensures satisfaction.
▪ Limitations:
Requires constant communication and teamwork.
▪ Real-World Analogy:
• Like developing a mobile app in phases, adding features based on user
feedback.
The Manifesto for Agile Software
Development

▪ “We are uncovering better ways of developing software

by doing it and helping others do it.
▪ Through this work we have come to value:
• Individuals and interactions over processes and tools
• Working software over comprehensive
documentation
•Customer collaboration over contract negotiation
• Responding to change over following a plan That is, while
there is value in the items on the right, we value the items on
the left more.”
▪ Kent Beck et al
What is “Agility”?

• Effective (rapid and adaptive) response to change (team members, new

▪ technology, requirements)
• Effective communication in structure and attitudes among all team members,
technological and business people, software engineers and managers。
• Drawing the customer into the team. Eliminate “us and them” attitude. Planning

▪ in an uncertain world has its limits and plan must be flexible.

• Organizing a team so that it is in control of the work performed
• Eliminate all but the most essential work products and keep them lean.
• Emphasize an incremental delivery strategy as opposed to intermediate products

▪ that gets working software to the customer as rapidly as feasible.

What is “Agility”?

▪ Yielding …
• Rapid, incremental delivery of software
• The development guidelines stress delivery over analysis and design
although these activates are not discouraged, and active and
continuous communication between developers and customers.
Why and What Steps are“Agility”
important?

• Why? The modern business environment is fast-paced

▪ and ever-changing. It represents a reasonable

▪ alternative to conventional software engineering for

▪ certain classes of software projects. It has been demonstrated to deliver
successful systems quickly.

• What? May be termed as “software engineering lite”

▪ The basic activities- communication, planning,

▪ modeling, construction and deployment remain. But

▪ they morph into a minimal task set that push the team toward construction and
delivery sooner.
• The only really important work product is an operational “software increment”
that is delivered.
Why and What Steps are“Agility”
important?

• Why? The modern business environment is fast-paced

▪ and ever-changing. It represents a reasonable

▪ alternative to conventional software engineering for

▪ certain classes of software projects. It has been demonstrated to deliver
successful systems quickly.

• What? May be termed as “software engineering lite”

▪ The basic activities- communication, planning,

▪ modeling, construction and deployment remain. But

▪ they morph into a minimal task set that push the team toward construction and
delivery sooner.
• The only really important work product is an operational “software increment”
that is delivered.
DevOps Model – Continuous Development &
Deployment

▪ DevOps Model – Continuous Development & Deployment

• Focuses on automation & collaboration between developers and
operations teams.
▪ Example:
• Used in cloud-based applications like Netflix.
DevOps Model – Continuous Development &
Deployment

▪ Advantages:
Fast bug fixes & updates.
Better collaboration between teams.
▪ Limitations:
Requires specialized DevOps tools and expertise.
▪ Real-World Analogy:
• Like fast food delivery services where kitchen and delivery teams
work together for quick service.
Introduction – What is
Software Project
Planning?
Software Project Planning

▪ Content:
• Imagine you are planning a road trip with your friends.
• You need to decide where to go, how much money you need, what vehicle
to use, who will drive, and what stops to take.
• If you don’t plan properly, you might run out of fuel, take the wrong route, or
even cancel the trip!
Software Project Planning

• Software Project Planning works the same way – we need to

define:What needs to be done? (Activities)
• What resources do we need? (People, tools, budget)
• Is the project even possible? (Feasibility Study)
Software Project Planning

▪ Definition:
▪ Software project planning is the process of defining:
1. Activities – Tasks required to complete the project.
2. Resources – Manpower, tools, budget, time.
3. Feasibility Study – Whether the project is realistic and worth doing.
▪ Why is Planning Important?
▪ Avoids delays & budget overruns
Ensures smooth execution
Reduces risk of project failure
Identifying Activities in Software
Project Planning

▪ Content:
▪ Just like in a road trip, where we pack bags, book hotels, fuel the
car, and plan stops, in software project planning, we identify all
major activities needed to complete the project.
Identifying Activities in Software
Project Planning

Just like in a road trip, where we pack bags, book hotels, fuel the car, and
plan stops, in software project planning, we identify all major activities
needed to complete the project.
Key Activities in Software Project Planning:
1️⃣ Requirement Analysis – Understanding what the customer wants.
• Example: Developing an e-commerce app → Needs login, product listing,
cart, payment.
2️⃣ System Design – Deciding the technical structure.
• Example: Choosing database, cloud services, frontend & backend tech
stack.
Identifying Activities in Software
Project Planning

3️⃣ Implementation (Coding & Development) – Writing the

software.
• Example: Developers start writing and integrating code.
4️⃣ Testing – Ensuring the software works correctly.
• Example: Testing payment gateway in an e-commerce app.
Identifying Activities in Software
Project Planning

5️⃣ Deployment – Releasing the software for users.

• Example: Launching the app on Google Play Store or App Store.
6️⃣ Maintenance & Updates – Fixing bugs, adding new features.
• Example: Updating an online banking app with new security
features.
Real-World Analogy:
• Like constructing a building, where we design, lay the foundation,
build floors, paint, inspect, and maintain.
Identifying Resources – What Do We Need?

▪ Just like a road trip needs a car, fuel, and money, software projects
need resources.
Identifying Resources – What Do We Need?

Types of Resources in Software Project Planning:

1. Human Resources (People)
Software Developers – Write the code.
UI/UX Designers – Make the app visually appealing.
Testers – Find and fix bugs.
Project Manager – Ensures the project stays on track.
2. Hardware & Software Resources
Computers, Servers – Where the software runs.
Development Tools – IDEs, databases, frameworks.
Identifying Resources – What Do We Need?

3. Financial Resources (Budget)

Salaries, hardware, cloud services, maintenance costs.
4. Time & Schedule
Planning deadlines for each phase to ensure on-time delivery.
Feasibility Study
Feasibility Study

Analogy: "Opening a Café: Is It a Feasible Business?"

▪ "Before starting a software project, we conduct a feasibility study, just
like how an entrepreneur analyzes whether opening a café is a good
idea!"
Feasibility Study

"Before opening a café, an entrepreneur checks if the idea will work—Will

people visit? Can I afford it? Will I make a profit?"
Without this study, the café might fail due to poor planning!
Feasibility Study

"Before opening a café, we check if we have the necessary technology: Do

we have a coffee machine, an oven, and trained baristas?"
Can we source high-quality coffee beans?
Do we need specialized espresso machines?
Are there skilled chefs and baristas available?
Key Takeaway:
• If the technology (or kitchen setup) isn’t available, the project
may not be feasible!
Feasibility Study

"How much does it cost to start and run the café? Will we make a profit?"
Cost of renting a place vs. expected income.
Investment in furniture, ingredients, and staff salaries.
Expected customer footfall and pricing strategy.
Key Takeaway:
• If a café can't be profitable, it's not worth opening—just like an
unprofitable software project shouldn't be developed!
Feasibility Study

"Do we have the right licenses and permissions to run a café?"

Food safety licenses and health permits.
Compliance with zoning laws (residential or commercial area?).
Copyright and trademark check for the café name and branding.
Key Takeaway:
• Legal issues can shut down both a café and a software project if
not handled properly!
Feasibility Study

"Even if the café idea is great, can we manage day-to-day operations

efficiently?"
Do we have a reliable supplier for ingredients?
Can staff handle busy hours without delays?
Is the workflow efficient (kitchen, service, cash register)?
Key Takeaway:
• A great idea is useless if it can't be implemented smoothly!
Feasibility Study

"Can we open the café by the grand opening date?"

Do we have time to renovate, hire staff, and buy equipment?
Can we advertise and build customer interest before opening?
Will unexpected delays (construction, licensing) affect the
launch?
Key Takeaway:
• If the café can't open on time, we might lose customers—just like
a delayed software project loses market value!
Feasibility Study

"Does the location have enough demand for a new café?"

Are there enough coffee lovers in the area?
Who are the competitors (other cafes nearby)?
What makes our café unique (specialty drinks, ambiance,
pricing)?
Key Takeaway:
• A café without demand is like software nobody wants—it will fail!
Feasibility Study

"A well-researched café is more likely to succeed—just like well-planned

software projects!"
▪ Would you invest in a café without checking if people will buy
coffee? No!
Then why start a software project without a feasibility study?
The Concept of Feasibility Study

Content:
• Before starting any software project, we need to check if it's
possible and worth doing.
• Imagine you want to build a flying car – exciting, but is it
technically possible, affordable, and useful?
The Concept of Feasibility Study

What is a Feasibility Study?

A Feasibility Study is an analysis of whether a project is viable. It
helps avoid wasting money, time, and effort on an impractical
project.
The Concept of Feasibility Study

Types of Feasibility Analysis:

1️⃣ Technical Feasibility – Can we build this with existing
technology?
• Example: A startup wants to build AI-powered self-driving bicycles
– is the technology ready?
2️⃣ Economic Feasibility – Can we afford it? Will it be profitable?
• Example: A small company wants to compete with Amazon – do
they have the budget?
The Concept of Feasibility Study

3️⃣ Operational Feasibility – Will people use it? Does it solve a real
problem?
• Example: An app that reminds people to drink water – is it really
useful?
4️⃣ Schedule Feasibility – Can we complete it on time?
• Example: A company wants to launch a shopping app before
Christmas – is there enough time?
5️⃣ Legal Feasibility – Are there any legal restrictions?
• Example: Building a cryptocurrency exchange platform – are there
laws regulating it?
The Concept of Feasibility Study

Content:
Without proper planning, software projects fail due to:
Poor budgeting
Missed deadlines
Lack of skilled resources
Unclear requirements
Unexpected risks
The Concept of Feasibility Study

Successful vs. Failed Projects:

Example of a Well-Planned Project:
• Google Search Engine – Started with a simple idea, feasibility study
ensured technical success, scaled gradually.
Example of a Failed Project Due to Poor Planning:
• Google Glass – Amazing concept, but failed due to lack of demand,
privacy concerns, and high cost.
The Concept of Feasibility Study

Key Takeaways:
Planning ensures success, cost savings, and efficiency.
Identifying activities and resources helps in better execution.
Feasibility Study prevents failure before starting the project.
What is Software
Engineering Economics?
What is Software Engineering Economics?

Content:
• Imagine you are opening a restaurant . You need to:
• Estimate how much money is needed (cost).
• Decide how big the restaurant should be (size).
• Plan for staff, ingredients, furniture, and marketing.
What is Software Engineering Economics?

• Software development is similar!

• Companies need to estimate how much money, time, and effort is required
before developing a software product.
• If estimates are wrong, projects might run out of budget, take too long, or
fail entirely.

▪ Definition:
• Software Engineering Economics focuses on estimating the cost,
time, and effort required for software development.
What is Software Engineering Economics?

▪ Why is it important?
▪ Helps in budget planning
Ensures on-time delivery
Avoids overspending
Prevents project failure
What is Software Cost Estimation?

Factors Affecting Software Cost:

1️⃣ Project Size – More features = More cost.
2️⃣ Complexity – Simple apps cost less, complex systems cost more.
3️⃣ Team Size & Salaries – More developers = Higher cost.
4️⃣ Development Time – Faster delivery = Higher cost.
5️⃣ Technology & Tools – Special software/hardware = More
expensive.
Real-World Example:
• WhatsApp vs. Microsoft Windows:
• WhatsApp (small app) = lower cost
• Windows OS (huge system) = very high cost
Size Estimation
Techniques
What is Software Size Estimation?

How Do We Measure Software Size?

1️⃣ Lines of Code (LOC) – Counting the total number of lines in the
program.
• Example:
• Calculator app: ~5,000 LOC
• Facebook: Millions of LOC

2️⃣ Function Points (FP) – Measuring the number of functions a software

provides.
• Example:
• Simple website = 50 FP
• Banking system = 10,000 FP
What is Software Size Estimation?

3️⃣ Story Points (Used in Agile Development) – Measuring

software complexity based on tasks.
• Example: Small task = 1 point, Large task = 10 points.

Real-World Example:
• A mobile game might need 100,000 lines of code, while a self-
driving car software might need 100 million lines!
Line of Code estimation
Line of Code estimation

LOC is the simplest among all metrics available to estimate project

size.
This metric is very popular because it is the simplest to use. Using
this metric, the project size is estimated by counting the number of
source instructions in the developed program.
Obviously, while counting the number of source instructions, lines
used for commenting the code and the header lines should be
ignored.
Line of Code estimation

LOC gives a numerical value of problem size that can vary widely
with individual coding style – different programmers lay out their
code in different ways. For example, one programmer might write
several source instructions on a single line whereas another might
split a single instruction across several lines.
A good problem size measure should consider the overall complexity
of the problem and the effort needed to solve it. That is, it should
consider the local effort needed to specify, design, code, test, etc.
and not just the coding effort. LOC, however, focuses on the coding
activity alone; it merely computes the number of source lines in the
final program.
Line of Code estimation

▪ LOC measure correlates poorly with the quality and efficiency of the
code. Larger code size does not necessarily imply better quality or
higher efficiency.
▪ LOC metric penalizes use of higher-level programming languages,
code reuse, etc. The paradox is that if a programmer consciously uses
several library routines, then the LOC count will be lower. This would
show up as smaller program size.
▪ It is very difficult to accurately estimate LOC in the final product from
the problem specification. The LOC count can be accurately
computed only after the code has been fully developed.
Function point analysis
Function point analysis

One of the important advantages of using the function point metric is

that it can be used to easily estimate the size of a software product
directly from the problem specification. This is in contrast to the LOC
metric, where the size can be accurately determined only after the
product has fully been developed.
The conceptual idea behind the function point metric is that the size
of a software product is directly dependent on the number of
different functions or features it supports. A software product
supporting many features would certainly be of larger size than a
product with less number of features.
Function point analysis

Function point is computed in two steps.

The first step is to compute the unadjusted function point (UFP).
The technical complexity factor (TCF) is computed next.
TCF refines the UFP measure by considering fourteen other factors
such as high transaction rates, throughput, and response time
requirements, etc. Each of these 14 factors is assigned from 0 (not
present or no influence) to 6 (strong influence). The resulting
numbers are summed, yielding the total degree of influence (DI).
Function point analysis

UFP = (Number of inputs)*4 + (Number of

outputs)*5 + (Number of inquiries)*4 + (Number of
files)*10 + (Number of interfaces)*10
TCF is computed as (0.65+0.01*DI).
FP=UFP*TCF.
Consider a C++ program with the
following specifications

Number of inputs: 3

Number of outputs: 2

Number of inquiries: 1

Number of files: 1

Number of interfaces: 1
Line of codes: 150

Degree of Influence (DI) is 10:

Popular Software Cost & Size Estimation
Techniques

Content:
• Just like estimating a budget for a vacation , there are different
ways to estimate software cost and size.
Popular Software Cost & Size Estimation
Techniques

1️⃣ Expert Judgment – Asking experienced professionals for a rough

estimate.
• Example: A senior developer estimates the cost of an e-commerce
website.
2️⃣ Analogous Estimation – Comparing with similar past projects.
• Example: If an accounting app cost $50,000, a similar app might
cost the same.
Popular Software Cost & Size Estimation
Techniques

3️⃣ COCOMO Model (Constructive Cost Model) – A mathematical

formula that estimates cost based on project size.
• Example: If the software has 10,000 lines of code, COCOMO
calculates how many developers and how much money is needed.
4️⃣ Use-Case Estimation – Estimating based on the number of use
cases (features).
• Example: A food delivery app has login, order, payment, tracking
→ each feature has a cost estimate.
5️⃣ Parametric Estimation – Using statistical models to predict cost.
• Example: A formula like Cost = (Size × Productivity) ÷ Efficiency.
COCOMO Model
COCOMO Model

▪ COCOMO (Constructive Cost Estimation Model) was

proposed by Boehm [1981]. According to Boehm, software
cost estimation should be done through three stages: Basic
COCOMO, Intermediate COCOMO, and Complete
COCOMO.
COCOMO Model

any software development project can be classified into

one of the following three categories based on the
development complexity: organic, semidetached, and
embedded.
COCOMO Model

Organic: A development project can be considered of organic type, if the project

deals with developing a well understood application program, the size of the
development team is reasonably small, and the team members are experienced in
developing similar types of projects.
Semidetached: A development project can be considered of semidetached type, if
the development consists of a mixture of experienced and inexperienced staff.
Team members may have limited experience on related systems but may be
unfamiliar with some aspects of the system being developed.
Embedded: A development project is considered to be of embedded type, if the
software being developed is strongly coupled to complex hardware, or if the
stringent regulations on the operational procedures exist.
COCOMO Model
COCOMO Model
COCOMO Model
Intermediate COCOMO Model

a host of other project parameters besides the product size affect the
effort required to develop the product as well as the development
time.
Therefore, in order to obtain an accurate estimation of the effort and
project duration, the effect of all relevant parameters must be taken
into account.
The intermediate COCOMO model recognizes this fact and refines
the initial estimate obtained using the basic COCOMO expressions
by using a set of 15 cost drivers (multipliers) based on various
attributes of software development.
Intermediate COCOMO Model

Product: The characteristics of the product that are considered include the
inherent complexity of the product, reliability requirements of the product,
etc.
Computer: Characteristics of the computer that are considered include the
execution speed required, storage space required etc.
Personnel: The attributes of development personnel that are considered
include the experience level of personnel, programming capability, analysis
capability, etc.
Development Environment: Development environment attributes capture
the development facilities available to the developers. An important
parameter that is considered is the sophistication of the automation (CASE)
tools used for software development.
Complete COCOMO Model

Product: The characteristics of the product that are considered include the
inherent complexity of the product, reliability requirements of the product,
etc.
Computer: Characteristics of the computer that are considered include the
execution speed required, storage space required etc.
Personnel: The attributes of development personnel that are considered
include the experience level of personnel, programming capability, analysis
capability, etc.
Development Environment: Development environment attributes capture
the development facilities available to the developers. An important
parameter that is considered is the sophistication of the automation (CASE)
tools used for software development.
Complete COCOMO Model

A major shortcoming of both the basic and intermediate COCOMO

models is that they consider a software product as a single
homogeneous entity.
However, most large systems are made up several smaller sub-
systems.
These sub-systems may have widely different characteristics. For
example, some sub-systems may be considered as organic type,
some semidetached, and some embedded.
Complete COCOMO Model

A distributed Management Information System (MIS) product for an

organization having offices at several places across the country can
have the following sub components: • Database part • Graphical User
Interface (GUI) part • Communication part
Of these, the communication part can be considered as embedded
software.
The database part could be semi-detached software, and the GUI
part organic software.
The costs for these three components can be estimated separately,
and summed up to give the overall cost of the system.
Software Configuration
management
Software Configuration management

Imagine you're part of the organizing team for your college's cultural
fest. Multiple people are working on different things—dance events,
music, food stalls, decor, and publicity. Now imagine the chaos if:
• Two people print different versions of the schedule
• A poster is edited and re-edited, but no one knows which is final
• Someone makes changes in the event list but doesn’t inform others

• The sponsorship list gets lost in WhatsApp chats

This is exactly what can go wrong in software development
without Software Configuration Management!
Software Configuration management

▪ "Managing software changes is just like organizing a fest: If everyone

makes random changes and no one tracks anything, chaos will
follow!“
▪ "Imagine your PR team made 5 different versions of the poster.
Which one is final? Who made what change?“
▪ "You finalized the event schedule, but someone casually adds
another flash mob without informing the stage team!“
 Software Configuration management

In Software Development In College Fest

Code versions get mixed up Event schedules get mixed up

Volunteers follow outdated

Team unaware of latest changes
instructions
Posters or sponsor lists get deleted
Risk of data loss
or lost
Fest execution fails due to poor
Deployment fails due to confusion
coordination
Software Configuration management

▪ "SCM is like the central coordination team of your cultural fest who
keeps track of which team is doing what, maintains latest copies of
schedules and posters, and ensures everyone is on the same page."
Software Configuration management

SCM is a set of activities that track and control changes in software so

that everyone works on the correct version and all components are in
sync.
It involves:
• Version control
• Change tracking
• Team coordination
• Backup and recovery
 Software Configuration management

SCM Activity Fest Example

Track versions of posters, brochures,
1. Version Control
schedules
Get permission before changing fest
2. Change Control
schedule or events
Label each task: Stage Setup, Food
3. Configuration Identification
Stalls, etc.
Check if what was planned is what’s
4. Configuration Auditing
actually done
Daily update on progress of each
5. Configuration Status Reporting
team
Version Control – Keep Track of Changes

In software, we keep different versions of code, so we don’t lose

anything and can revert if needed.
Change Control – Don’t Allow Random
Changes

In software, if anyone can change anything anytime—it creates

bugs and conflicts.
Configuration Identification – Label
Everything Clearly

In SCM, every file, module, and version is clearly named and

documented.
Configuration Auditing – Check Before
You Launch

Ensure the delivered software matches the required configuration.

Configuration Status Reporting – Keep
Everyone in the Loop

Keep track of what’s done, what’s in progress, and what’s pending.

Tools Used in SCM (Software Side)

Tools like:
• Git, GitHub, GitLab
• Subversion (SVN)
• Bitbucket
These tools help developers to:
• Track changes
• Work together without conflicts
• Restore old versions
Tools Used in SCM (Software Side)

Tools like:
• Git, GitHub, GitLab
• Subversion (SVN)
• Bitbucket
These tools help developers to:
• Track changes
• Work together without conflicts
• Restore old versions
Software risks and
mitigation techniques
Software risks and mitigation techniques

▪ "Just like planning a road trip can go wrong if we don’t plan for risks
— flat tires, bad weather, lost routes — software projects too can face
surprises. Let’s see how to prepare for them!"
Software risks and mitigation techniques

Planning a road trip? Risks could include:

• Roadblocks or detours
• Sudden weather changes
• A friend falls sick
• GPS stops working
Software risks and mitigation techniques

▪ Software risk is a potential problem that might impact the success

of a project — before it even happens.
Similarly, in software projects, risks include:
• Delays
• Budget overruns
• Technical failures
• Miscommunication
• Requirement changes
Software risks and mitigation techniques

1. Delay in Delivery
1. Trip: You reach the hill station after sunset, can’t enjoy the view.
2. Software: Deliver product late → customer unhappy.

2. Budget Overrun
1. Trip: You didn’t plan food & fuel → end up overspending.
2. Software: Lack of cost control → overshoots budget.
Software risks and mitigation techniques

1. Requirement Misunderstanding
1. Trip: You thought you were going to mountains, friend thought it was a beach
trip.
2. Software: Developers misunderstood the client.

2. Technical Failure
1. Trip: GPS stops working in remote area.
2. Software: App crashes on launch due to ignored bug.
 Software risks and mitigation techniques

Type of Software Risk Road Trip Analogy

Friends backing out last minute, no
Project Risk
budget planning
Technical Risk Car breaks down, or road is closed
No one enjoys the place you picked
Business Risk

External Risk Storm ruins your beach trip plan

Driver falls sick or someone forgets
People Risk
their ID
 Risk Management Process

Step Road Trip Example

List things that can go wrong (flat
1. Risk Identification
tire, rain)
2. Risk Analysis What’s the chance & impact of each?
Focus more on likely/critical ones (no
3. Risk Prioritization
spare tire)
4. Risk Mitigation Carry extra tire, check weather app

5. Risk Monitoring Keep track during the journey

 Risk Mitigation Techniques

Technique Road Trip Version

Avoidance Don’t travel during monsoon

Reduction Carry first-aid, spare battery, offline map

Transfer Hire a driver instead of self-driving

Acceptance Can’t avoid delays, just plan buffer time

Contingency Planning Backup plan: Visit local museum if it rains

Tools to Help with Risk Management

In Software we use:
• Risk Registers
• Jira / Trello (to track)
• Gantt charts
• SWOT analysis
• PERT/CPM charts
Software Quality and
the Software Quality
Dilemma
What is Software Quality?

Imagine you are buying a smartphone

• You want a phone that:
Works smoothly without crashing
Has a good battery life
Is secure and doesn’t get hacked easily
Looks great and is easy to use
• Would you buy a phone with frequent crashes, security issues,
and slow performance?
Dimensions of Software Quality

▪ Content:
• Just like a car’s quality is judged by mileage, safety, engine
power, and design, software quality has different aspects too.
What is Software Quality?

▪ Definition of Software Quality

• Software Quality means how well a software product meets
customer expectations, functions correctly, and is free of errors.
• High-quality software is:
Reliable – Works without crashing.
Efficient – Runs fast and uses minimal resources.
Secure – Protects user data from hackers.
Usable – Easy to navigate and understand.
Dimensions of Software Quality

1️⃣ Functionality – Does the software do what it’s supposed to?

(Example: A banking app should process payments correctly.)
2️⃣ Reliability – Does the software run without crashing? (Example:
WhatsApp rarely crashes even with millions of users.)
3️⃣ Usability – Is the software easy to use? (Example: Google Search
is simple and user-friendly.)
Dimensions of Software Quality

4️⃣ Efficiency – Does it run fast and smoothly? (Example: A slow-

loading website frustrates users.)
5️⃣ Maintainability – Can it be updated and fixed easily? (Example:
Windows receives regular updates to fix bugs and improve security.)
6️⃣ Security – Is the software protected from hackers? (Example:
Online banking apps use encryption to keep transactions safe.)
The Software Quality Dilemma – Balancing
Cost, Time, and Quality

▪ Imagine you are ordering a custom-made suit

• The tailor gives you three choices:
High quality but expensive and takes a long time
Cheap and fast but low quality
Balanced option: good quality, reasonable price, moderate
time
• Software development faces the same dilemma!
The Software Quality Dilemma – Balancing
Cost, Time, and Quality

The Software Quality Dilemma

• Companies must balance three factors:
1️⃣ Cost – Higher quality = More expensive
2️⃣ Time – High quality takes longer to develop
3️⃣ Quality – If rushed or made cheaply, quality suffers
The Iron Triangle of Software Development
You can only pick two:
Fast + Cheap = Low Quality
Fast + High Quality = Expensive
Cheap + High Quality = Slow Development
Consequences of Poor Software Quality

What happens when quality is ignored?

1️⃣ Project Failure – If quality is bad, the software might never
succeed.
• Example: Healthcare.gov (2013) – Launched with too many
bugs, causing crashes.
2️⃣ Security Breaches – Low-quality software can be hacked easily.
• Example: Yahoo Data Breach – Millions of user accounts were
hacked due to weak security.
Consequences of Poor Software Quality

3️⃣ User Dissatisfaction – If the app is slow and crashes, users will
stop using it.
• Example: Windows Vista – Slow performance led to poor
adoption.
4️⃣ High Maintenance Cost – Fixing bugs and security issues later is
more expensive than doing it right the first time.
How to Ensure High Software Quality?

Ways to Ensure Software Quality:

1️⃣ Follow Best Practices – Write clean, structured, and well-
documented code.
2️⃣ Code Reviews – Have other developers check for errors before
release.
3️⃣ Automated Testing – Use tools to find bugs before users do.
4️⃣ Security Testing – Ensure hackers can’t break into the system.
5️⃣ Continuous Updates & Bug Fixes – Keep improving software
after release.
Garvin’s Software
Quality Dimensions
Garvin’s Software Quality Dimensions

▪ "Just like people look for different things in a phone — camera quality,
speed, design — software is also judged on different dimensions of
quality."
Garvin’s Software Quality Dimensions

David A. Garvin introduced 8 dimensions of quality in 1984,

originally for manufacturing — but they perfectly apply to software
too!
Each dimension reflects how different users define “quality” in
their own way.
▪ Key Idea: Quality is multi-dimensional and subjective — like
your reason for loving a specific phone.
 Garvin’s Software Quality Dimensions

Garvin's Dimension Smartphone Analogy

Performance How fast & smooth is the phone?
Does it have cool extras? (Camera, Face
Features
ID)
Reliability Does it hang or crash?
Conformance Does it do what the company promised?
Durability Can it survive drops and last for years?
Serviceability Is it easy to repair or update?
Aesthetics Does it look and feel premium?
Perceived Quality Is it considered a “status symbol”?
Garvin’s Software Quality Dimensions

Slide 4: 1. Performance
Software Angle:
How efficiently and effectively the software performs its core tasks.
• Example: A payment app should be fast, accurate, and glitch-free.
Key Insight: Users want the software to be quick, responsive,
and reliable in its core tasks.
Garvin’s Software Quality Dimensions

Slide 5: 2. Features
Software Angle:
Additional functionalities beyond the basics.
• Example: Dark mode, voice commands, chat support in an app.
Key Insight: Features differentiate software, but too many can
also confuse users.
Garvin’s Software Quality Dimensions

Slide 6: 3. Reliability
Software Angle:
Can the software run for long periods without crashing?
• Example: Zoom app staying stable during a 2-hour call.
Key Insight: Reliable software builds trust over time.
Garvin’s Software Quality Dimensions

Slide 7: 4. Conformance
Software Angle:
Does the software conform to its specifications and standards?
• Example: A calculator app that gives wrong answers = bad
conformance.
▪ Key Insight: Customers expect software to do what it claims.
Garvin’s Software Quality Dimensions

Slide 8: 5. Durability
Software Angle:
How long the software stays usable and relevant.
• Example: An app that still works after years with new OS versions.
Key Insight: Long-lasting software = value for money and low
maintenance.
Garvin’s Software Quality Dimensions

Slide 9: 6. Serviceability
Software Angle:
How easy it is to maintain, update, debug, and fix the software.
• Example: Web-based tools that auto-update vs. old desktop software
that crashes often.
Key Insight: Serviceable software is easy to support and
improves user satisfaction.
Garvin’s Software Quality Dimensions

Slide 10: 7. Aesthetics

Software Angle:
Visual design, user interface, font, animations, layout.
• Example: Instagram’s clean layout vs. a cluttered news app.
Key Insight: People judge the book by its cover — same with
software!
Garvin’s Software Quality Dimensions

Slide 11: 8. Perceived Quality

Software Angle:
What users believe about the quality of the software.
• Example: People trust Microsoft Word more than a random text
editor.
▪ Key Insight: Brand reputation, reviews, and marketing shape
perception.
Garvin’s Software Quality Dimensions

Slide 11: 8. Perceived Quality

Software Angle:
What users believe about the quality of the software.
• Example: People trust Microsoft Word more than a random text
editor.
Key Insight: Brand reputation, reviews, and marketing shape
perception.
Garvin’s Software Quality Dimensions

Dimension Smartphone Clue Software Relevance

Performance Speed, battery Core function performance

Features Camera, 5G, extras Bonus functionalities

Fewer bugs, consistent
Reliability No crashes
results
Conformance Specs match real use Matches design specs

Durability Works over time Sustainable with updates

Serviceability Easy repairs/updates Easy to fix & maintain

Aesthetics Cool design, display Beautiful, user-friendly UI

Perceived Quality Brand, reviews Market image, user trust

Garvin’s Software Quality Dimensions

Software High in...

WhatsApp Reliability, Performance
Canva Aesthetics, Features
Notepad++ Performance, Serviceability
Perceived Quality, Durability,
iOS
Conformance
GUPTA PAV BHAJI CENTRE
Prop: Raju Bhaiya
 Level 1 – Initial (Ad hoc & Chaotic)

Raju Bhaiya's Setup:

• One roadside stall
• No menu, no fixed timings
• He cooks based on mood
• Sometimes customers love it, sometimes food is half-
cooked
 Level 2 – Repeatable (Basic Project
Management)

Raju Bhaiya Gets Smart:

• Fixes a menu (Pav Bhaji, Bhel, Dosa)
• Opens from 6 PM to 10 PM regularly
• Starts keeping a diary for how much material is needed
daily
• Hires one helper
 Level 3 – Defined (Standardized
Process)

Raju Bhaiya Expands:

• Opens 3 more stalls across the city
• Trains all cooks using his recipe manual
• Follows standard process for cooking, cleaning, and billing
• Decor is same, menu is same, taste is same across all stalls
 Level 4 – Managed (Measured and
Controlled)

Raju Bhaiya Measures Everything:

• Uses POS machines to track which dish sells most
• Knows which stall earns more, and why
• Monitors staff performance, customer reviews, wastage
levels
• Uses this data to make decisions (e.g., add cheese pav
bhaji?)
 Level 5 – Optimizing (Continuous
Improvement)

Raju Bhaiya Goes Global:

• Launches a 5-star restaurant chain
• Starts experimenting with fusion food (Pasta Pav Bhaji?!
)
• Gets feedback through apps, improves based on customer
suggestions
• Runs workshops for chefs and constantly upgrades
Capability Maturity
Model (CMM)
Capability Maturity Model (CMM)

The Capability Maturity Model is a framework that

helps software organizations assess how mature their
processes are — from completely chaotic to well-
managed and continuously improving.
Capability Maturity Model (CMM)
 Level 1 – Initial (Ad hoc & Chaotic)

In Software Terms:
• No defined processes
• Success depends on individual heroism
• Results are inconsistent
 Level 2 – Repeatable (Basic Project
Management)

In Software Terms:
• Basic project management is in place
• Processes can be repeated for similar projects
• Still no standardization across all tasks
 Level 2 – Repeatable (Basic Project
Management)

In Software Terms:
• Basic project management is in place
• Processes can be repeated for similar projects
• Still no standardization across all tasks
 Level 3 – Defined (Standardized
Process)

In Software Terms:
• Company has defined, documented, and standardized
processes
• Teams follow organization-wide policies
 Level 4 – Managed (Measured and
Controlled)

In Software Terms:
• Processes are measured using data
• Management makes decisions based on metrics
 Level 5 – Optimizing (Continuous
Improvement)

In Software Terms:
• Focus on continuous improvement
• Feedback loops and innovation are part of the culture
Capability Maturity Model (CMM)

CMM Level Stage Name Raju Bhaiya’s Journey

Random cooking, no
Level 1 Initial
planning
Fixed menu and schedule,
Level 2 Repeatable
basic planning
Standardized recipes and
Level 3 Defined
processes across branches

Tracks sales, staff, feedback;

Level 4 Managed
data-driven decisions

Constantly innovating,
Level 5 Optimizing improving recipes and
service
Imagine Raju Bhaiya now owns
a chain of 20+ restaurants, a
cloud kitchen, and even a
mobile app for online orders.
He wants to make sure that
every part of his food
business is consistently
excellent and constantly
improving. That’s where CMMI
comes in!
Development (CMMI-DEV)

Focus: Building & Delivering Products or Services

Example in Raju’s World:
• R&D team developing new dishes (e.g., Chocolate Pav
Bhaji )
• Testing before launching on the menu
• Training chefs to replicate the new dish across branches
Services (CMMI-SVC)

Focus: Delivering Great Customer Experience

Example in Raju’s World:
• Ensuring delivery is fast and accurate
• Staff is polite and trained
• Complaint handling system is efficient
Acquisition (CMMI-ACQ)

Focus: Dealing with Vendors & Buying Stuff Smartly

Example in Raju’s World:
• Buying pav, butter, masala, vegetables in bulk
• Choosing reliable vendors
• Ensuring quality of raw materials
Capability Maturity
Integration (CMMI)
Capability Maturity Integration (CMMI)

CMMI stands for Capability Maturity Model Integration.

It is:
• A more refined version of CMM
• Designed not just for software, but for any organization or
domain (software, hardware, services)
• It integrates multiple improvement models into one
single, consistent framework
Development (CMMI-DEV)

Focus: Building & Delivering Products or Services

Developing quality software products — code, test, deploy
Services (CMMI-SVC)

Focus: Delivering Great Customer Experience

Managing IT services, handling client queries, post-
deployment support
Acquisition (CMMI-ACQ)

Focus: Dealing with Vendors & Buying Stuff Smartly

Working with external contractors or vendors for
hardware/software needs
Capability Maturity Integration (CMMI)

Let’s say Raju Bhaiya uses a mobile app to manage everything —

kitchen inventory, customer orders, delivery tracking, chef
schedules, etc.
With CMMI:
• He ensures the app is developed well → (CMMI-DEV)
• Ensures deliveries and services run smoothly → (CMMI-SVC)
• Chooses the right delivery partners and food vendors → (CMMI-
ACQ)
He’s not just focusing on one thing (like software or food) — he’s
improving everything together. THAT is CMMI.
McCall’s Quality
Factors
McCall’s Quality Factors

▪ "Think of a software product like a car. Just like a car needs to be fast,
safe, stylish, easy to use, and maintainable — so does software!"
Each of McCall’s factors is like a checklist someone might use while
evaluating a car they want to buy or own.
McCall’s Quality Factors

Category Software Aspect Car Analogy

While using the How it feels when
Product Operation
software you’re driving the car
How easy it is to
Product Revision Maintenance & updates
service/repair the car

Portability and Can the car adapt to

Product Transition
upgrades new roads or climates?
McCall’s Quality Factors

Developed by Jim McCall in the 1970s to define software quality in

real terms.
The model classifies quality into:
• Product Operation
• Product Revision
• Product Transition
PRODUCT OPERATION

1. Correctness
Does Instagram do what it’s supposed to?
• You upload a photo — it posts.
• You type a comment — it appears.
• You tap “Like” — the heart turns red.
If it behaves exactly how you expect it to, it’s correct.
PRODUCT OPERATION

2. Reliability
Does Instagram work without crashing?
• Imagine you’re uploading a reel and the app suddenly crashes.
Annoying, right?
• A reliable Instagram means you can scroll, post, and message
without unexpected problems.
▪ If it works every time without breaking — it’s reliable.
PRODUCT OPERATION

3. Efficiency
Does Instagram work fast and smooth?
• It loads your feed instantly.
• It doesn't drain your phone battery too fast.
• Videos don’t buffer forever.
▪ If it runs quickly without lagging — it’s efficient.
PRODUCT OPERATION

4. Integrity
Is Instagram safe from hackers or misuse?
• You don’t want someone logging into your account or stealing your
private chats.
• Instagram uses password protection, two-factor authentication, etc.
▪ If your data is protected — it has integrity.
PRODUCT OPERATION

5. Usability
Is Instagram easy to use?
• Can your younger sibling or your grandma figure it out in 5 minutes?
• Buttons are simple, icons are familiar, and it just feels natural.
If it's easy for anyone to use — it has usability.
PRODUCT REVISION

6. Maintainability
Can Instagram fix bugs or add features easily?
• If something breaks, the Instagram team should be able to fix it fast.
• Example: A bug in Stories gets fixed in the next update.
▪ If the app can be repaired or updated easily — it’s
maintainable.
PRODUCT REVISION

7. Flexibility
Can Instagram adapt to changes?
• Adding new filters, reels, notes, and messaging features?
• Keeping up with trends?
▪ If it can evolve without starting from scratch — it’s flexible.
PRODUCT REVISION

8. Testability
Can Instagram be tested easily before going live?
• Before launching a new feature, they check it with internal teams.
• If it’s easy to check whether things work properly — that’s good
testability.
▪ If developers can easily test what works and what doesn’t —
it’s testable.
PRODUCT TRANSITION

9. Portability
Can Instagram run on different devices?
• Android, iPhone, iPad, even web browser version — same app.
• You don’t have to learn it all over again.
If it works well on many devices — it’s portable.
PRODUCT TRANSITION

10. Reusability
Can parts of Instagram be reused in other apps?
• Maybe the chat feature or photo editing tools are reused in Facebook
or Threads.
• Developers don’t need to build everything from scratch.
▪ If code/components are reusable — it has reusability.
PRODUCT TRANSITION

11. Interoperability
Can Instagram talk to other apps?
• You share an Insta story to WhatsApp.
• You log in using your Facebook account.
• Insta links open inside Twitter or Chrome.
▪ If it works smoothly with other apps — it’s interoperable.
McCall’s Quality Factors

Product Operation (Car Driving Experience)

Includes the following quality factors:
1. Correctness
2. Reliability
3. Efficiency
4.Integrity
5. Usability
McCall’s Quality Factors

Product Revision (Car Maintenance)

Includes:
1. Maintainability
2. Flexibility
3. Testability
McCall’s Quality Factors

Product Transition (Changing Roads)

Includes:
1. Portability
2. Reusability
3. Interoperability
Factor Instagram Example (Simple Line)
Correctness Posts and features work exactly as expected
Reliability Doesn’t crash or freeze randomly
Efficiency . Loads quickly, doesn’t eat your battery
Integrity Keeps your data and account secure
Usability Even your grandma can figure out how to post
Maintainability Bugs get fixed in the next update
Flexibility Keeps adding trendy new features like Reels

Testability New features are tested before reaching you

Portability Works on iOS, Android, browser, tablets

Reusability Chat or filter features reused in other Meta apps

Interoperability Lets you log in with Facebook or share to WhatsApp

ISO 9126 Quality
Factors Using Netflix
App
Functionality – Does it work and meet
your needs?

a. Suitability
Netflix has just the right features — play, pause, rewind, subtitles, multi-
language, profiles.
It does what it promises: stream content perfectly.
b. Accuracy
When you watch a show rated PG-13, it follows the guidelines. The data
shown (like ratings, episode info) is correct.
c. Interoperability
Netflix runs smoothly on smart TVs, mobile apps, web browsers, Firestick — it
works with all your devices.
Functionality – Does it work and meet
your needs?

d. Security
Only you can access your profile. It has login passwords, parental
control, and even allows you to log out devices remotely.
It keeps your binge-watching private!
e. Compliance
Netflix follows international laws like copyright rules and country-
specific content laws.
 Reliability – Can you trust it to
work all the time?

a. Maturity
Netflix doesn’t randomly crash. It’s stable, even when many users are
watching at once.
b. Fault Tolerance
Even if your internet flickers, Netflix handles it — it reduces video quality
instead of stopping playback.
c. Recoverability
If your app crashes or you log out accidentally, it resumes from where you left
off in a series.
It’s like your friend who remembers your last watched episode.
Usability – Is it easy and fun to use?

a. Understandability
You instantly know how to browse, play, and search. No training needed!
b. Learnability
Even your younger sibling or grandparents can learn it fast.
c. Operability
The buttons are clear, UI is friendly, and the experience is smooth.
d. Attractiveness
Come on! Netflix looks sleek with its dark theme, thumbnails, trailers — it pulls you in.
Easy, fun, and addictive — just how an app should be!
Efficiency – Does it work without
wasting time or resources?

a. Time Behavior
It loads fast. Shows start playing quickly. Downloads are quick. No one
likes buffering!
b. Resource Utilization
Even on low-end phones or smart TVs, it works without overheating or
crashing.
Works fast, eats less!
Maintainability – Can developers easily
fix or upgrade it?

(We see this behind the scenes )

a. Analyzability
If there’s a bug (e.g., subtitle not syncing), developers can analyze the
logs to find out what’s wrong.
b. Changeability
Netflix frequently updates the UI or adds new features (like “Play
Something”).
Easy for developers to improve!
Maintainability – Can developers easily
fix or upgrade it?

c. Stability
Even after updates, it works fine without breaking other features.
d. Testability
Netflix runs tests before releasing new features (like testing ads or
interactive shows).
Portability – Can it run on various
devices or systems?

a. Adaptability
It adapts to your screen — phone, laptop, tablet, smart TV.
b. Installability
Easy to install from App Store/Play Store. Takes a minute!
c. Co-existence
Works well alongside other apps. No conflict with your music or WhatsApp.
d. Replaceability
You can uninstall Netflix and try alternatives like Prime Video. They can “replace”
each other.
Works everywhere, plays nicely, and can be swapped — if you ever dare!
Portability – Can it run on various
devices or systems?

a. Adaptability
It adapts to your screen — phone, laptop, tablet, smart TV.
b. Installability
Easy to install from App Store/Play Store. Takes a minute!
c. Co-existence
Works well alongside other apps. No conflict with your music or WhatsApp.
d. Replaceability
You can uninstall Netflix and try alternatives like Prime Video. They can “replace”
each other.
Works everywhere, plays nicely, and can be swapped — if you ever dare!
Quality Factor Netflix Example

Functionality Streams shows accurately, securely, and legally

Reliability Doesn’t crash; remembers your episode

Usability Easy and fun interface; anyone can use it
Efficiency Loads fast, minimal battery and data use
Maintainability Frequent updates; bugs fixed fast
Portability Works on phones, TVs, browsers; installs easily
Two Content Layout with Table

First bullet point here Class Group A Group B

Second bullet point here Class 1 82 95

Third bullet point here Class 2 76 88

Class 3 84 90
Two Content Layout with SmartArt

First bullet point here

Group A
Second bullet point here
• Task 1
• Task 2 Third bullet point here
Group B
• Task 1
• Task 2

Group C
• Task 1
Add a Slide Title - 1
Add a Slide Title - 2
Add a Slide Title - 3
Add a Slide Title - 4