Software Engineering

Module 2 :
1. Software Life Cycle Models: (a) Waterfall (b) Prototype (c) Spiral Models
and their Comparison.
2. Software Project Management :
(a) Size Estimation- LOC and FP Metrics
(b) Cost Estimation- Delphi and Basic COCOMO
(c) Introduction to Halstead’s Software Science
(d) Staffing Level Estimation- Putnam’s Model.
-----------------------------------------------------------------------------------------------------------

1.Software Development Life Cycle:

What is SDLC?
• Definition:
SDLC (Software Development Life Cycle) is a systematic process for
building software that ensures the quality and correctness of the software
product.
• Purpose:
o To deliver high-quality software.
o To ensure the software is completed on time, within budget, and
meets user requirements.
o To reduce risks and improve project planning.
• Who uses SDLC?
Developers, testers, project managers, business analysts, clients.

Phases of SDLC (Common 7 Phases)

1. Requirement Gathering & Analysis
Page 1 of 38
 • Understand what the user wants.
• Involve stakeholders, clients, and analysts.
• Final output: Software Requirement Specification (SRS) document.

• Example: A client wants a mobile app to manage personal expenses.

2. System Design
• Create architecture and design based on the requirements.
• Design includes UI/UX design, database structure, class diagrams, etc.
• Tools: UML, ER diagrams, Wireframes.

• Example: Design login screen, dashboard, and database for storing

expenses.

3. Implementation (Coding)
• Developers write code based on the design.
• Code should follow standards and use version control (e.g., Git).

• Example: Developers build Android/iOS app using Java/Kotlin/Flutter.

4. Testing
• Test the application for bugs, errors, and performance.
• Types: Unit Testing, Integration Testing, System Testing, User Acceptance
Testing (UAT).

• Example: QA team tests the expense app by adding, editing, and

deleting expenses.

5. Deployment
Page 2 of 38
 • Deploy the application in a live environment for end users.
• May be done in phases (Beta testing, full release).

• Example: The app is published on the Play Store.

6. Maintenance
• Fix bugs reported by users.
• Update the system with new features.
• Ensure the app runs smoothly over time.

• Example: Adding a feature to track recurring expenses after user

feedback.

7. Evaluation (Optional but Important)

• Review the project success.
• Learn from mistakes or successes for future projects.

Summary Table

Phase Purpose

Requirement Understand what is needed

Design Plan how to build it

Implementation Actually build the software

Testing Ensure it's correct and works well

Deployment Release to users

Maintenance Support and improve after release

Page 3 of 38
 Real-World Example: Food Delivery App

Phase Example

Requirement Users want to order food via mobile

Design Plan the UI: Search bar, Cart, Map

Coding Developers code the app using React Native

Testing QA team tests ordering, payments, and delivery tracking

Deployment App is published to app stores

Bugs are fixed, and new features like “Live order tracking” are
Maintenance
added

What is a Software Model?

• Definition:
A Software Development Model is a structured approach that defines how
to plan, build, and deliver a software product.
• Purpose:
o To organize the software process.
o To improve efficiency, reduce risks, and ensure quality.
o To choose the best method depending on project type and customer
needs.

Common Types of Software Development Models

1. Waterfall Model
• Definition:
A linear and sequential approach where each phase must be completed
before the next starts.
Page 4 of 38
 • Phases:
Requirements → Design → Implementation → Testing → Deployment →
Maintenance
• Pros:
o Simple and easy to manage.
o Works well for small projects with clear requirements.
• Cons:
o Difficult to go back to a previous phase once completed.

• Example: Building a payroll system for a company.

2. V-Model (Verification and Validation Model)

• Definition:
Extension of the Waterfall model where each development phase is
directly associated with a testing phase.
• Shape:
Looks like the letter V.
• Pros:
o Defects are found early.
o High-quality product.
• Cons:
o Not flexible for changing requirements.

• Example: Developing critical software like flight control systems.

3. Incremental Model

Page 5 of 38
 • Definition:
The software is built and delivered in parts (increments). Each increment
adds functionality.
• Pros:
o Working software is delivered early.
o Easier to test and debug smaller parts.
• Cons:
o Requires good planning and design.

• Example: First version of a chat app sends text only, next versions add
video and file sharing.

4. Iterative Model
• Definition:
Software is developed in repeated cycles (iterations); each version
improves based on feedback.
• Pros:
o Good for large, complex projects.
o Easy to adapt to new changes.
• Cons:
o Requires heavy user involvement.

• Example: Developing a new online shopping platform, improving

search and cart functionality in cycles.

5. Spiral Model

Page 6 of 38
 • Definition:
Combines iterative and waterfall approaches with emphasis on risk
analysis.
• Phases:
Planning → Risk Analysis → Engineering → Evaluation → (repeat)
• Pros:
o Best for high-risk, complex projects.
o Continuous risk management.
• Cons:
o Expensive and complex.

• Example: Banking software development where security risks are

critical.

6. Agile Model
• Definition:
A flexible and collaborative approach based on rapid delivery, continuous
feedback, and customer involvement.
• Popular Methodologies:
Scrum, Kanban, XP (Extreme Programming).
• Pros:
o Fast delivery.
o Highly flexible to change.
• Cons:
o Requires active customer engagement.

• Example: Developing a food delivery app with frequent updates and

new features based on customer feedback.

Page 7 of 38
7. Prototype Model
• Definition:
A quick working prototype is built to understand requirements, which is
then refined based on user feedback.
• Pros:
o Clear understanding of user needs.
o Early detection of misunderstandings.
• Cons:
o Might increase overall development cost if not managed well.

• Example: Building a prototype of an e-commerce website to show

customers before final design.

Summary Table

Model Best For Key Features

Waterfall Simple, small projects Sequential steps

V-Model High-quality, critical systems Testing at each stage

Incremental Medium-sized projects Build in parts

Iterative Large, complex projects Repeated cycles

Spiral High-risk, big projects Risk-driven approach

Agile Modern, dynamic projects Fast, flexible, customer-driven

Prototype Projects with unclear requirements Early user feedback

Simple Real-World Mapping

Page 8 of 38
Real World Model Used

Banking Software Spiral

Mobile App (Zomato, Swiggy) Agile

Educational Management System Waterfall

Game Development Iterative

(A) What is the Waterfall Model?

• Definition:
The Waterfall Model is a sequential software development model where
the process flows strictly downward like a waterfall through several
phases.
• Key Idea:
Complete one phase fully before moving to the next. No going back!
• Introduced by:
Dr. Winston W. Royce in 1970.
• Best suited for:
Projects with clear, fixed requirements.

Phases of the Waterfall Model

Each phase depends on the deliverables of the previous one:

1. Requirement Gathering and Analysis

• Understand exactly what the client wants.
• Document all requirements (Software Requirements Specification - SRS).

• Example: Client needs an online examination system with features like

login, exams, scoring.

Page 9 of 38
2. System Design
• Plan how to create the software based on requirements.
• Prepare design documents (architecture, database design, UI/UX).

• Example: Designing a student dashboard, question paper database,

and result module.

3. Implementation (Coding)
• Developers write actual code based on the system design.
• Each module is developed and tested independently (unit testing).

• Example: Coding login page, exam page, result generation.

4. Integration and Testing

• Combine all modules together.
• Test the entire system for bugs, security issues, and flow.

• Example: Test login + exam + result module working together properly.

5. Deployment
• Release the software to the client or the public.

• Example: Upload the examination system on a live server.

6. Maintenance
• Handle any issues that come up after deployment.
• Fix bugs, make updates if needed.

Page 10 of 38
 • Example: Fixing bugs if students are not able to submit answers.

Key Characteristics of the Waterfall Model

• Linear process — moves in a straight line.
• Structured and easy to manage.
• Well-documented at each phase.
• No overlapping of phases.
• Changes are difficult to accommodate after moving to the next phase.

When to Use the Waterfall Model

• Requirements are very well understood and unlikely to change.
• The project is small or medium-sized.
• Clear, stable technology is being used.
• Strict government or defense projects.

Limitations of the Waterfall Model

• Rigid and inflexible.
• Late discovery of issues (testing happens after coding).
• Difficult to accommodate changes once the project moves ahead.
• Not ideal for long, complex, or evolving projects.

Simple Real-World Example

Page 11 of 38
Scenario Description

Building a university admission portal. All forms, payment gateways,

Example and documents uploading features are pre-decided and fixed at the
start.

(B) What is the Prototype Model?

• Definition:
The Prototype Model is a software development model where a
prototype (early sample) is quickly built, shown to the customer for
feedback, and improved repeatedly until the final system is developed.
• Key Idea:
Build → Show → Get Feedback → Improve → Final Product.
• Focus:
Understand user needs more clearly and reduce misunderstandings.

Phases of the Prototype Model

1. Requirement Gathering
• Collect initial requirements from the client.
• Focus only on the important features to start with.

• Example: Client says they want a mobile app for booking hotel rooms.

2. Quick Design
• Make a basic design (rough version) with major screens/features.
• No full system yet, just rough screens, menus, and flows.

• Example: A rough homepage with "Book Now", "View Bookings",

"Login" options.
Page 12 of 38
3. Build Prototype
• Develop a working prototype (partial functionality).
• The goal is speed, not perfection.

4. Customer Evaluation
• Show the prototype to the client/user.
• Gather feedback: What they like, dislike, what needs to change.

5. Refine Prototype
• Based on feedback, update and improve the prototype.
• Repeat the build-show-feedback cycle multiple times.

6. Final Product Development

• Once the client is satisfied, the final system is built properly (full design,
coding, and testing).

Key Characteristics of the Prototype Model

• Interactive development with customer feedback.
• Focus on user involvement.
• Useful for unclear or incomplete requirements.
• Helps identify missing functionalities early.
• Saves time and money by avoiding major errors later.

Page 13 of 38
 When to Use the Prototype Model
• Requirements are not clear at the start.
• There is high user interaction (UI/UX heavy projects).
• Complex systems where visuals matter a lot (e.g., websites, apps).
• Projects where risk reduction is important.

Limitations of the Prototype Model

• Costly if too many changes happen.
• Can create confusion if prototype is mistaken for the final product.
• Not suitable for projects requiring stable, well-planned development
(e.g., critical banking or medical systems).

Simple Real-World Example

Scenario Description

Building an online food ordering app. Initially, a simple app is built

where customers can select food and place an order. Based on
Example
feedback, features like "order tracking", "wallet payments" are added
later.

© What is the Spiral Model?

• Definition:
The Spiral Model is a software development process that combines the
idea of iterative development (repeated cycles) with the systematic
aspects of the Waterfall Model and strong risk analysis.
• Key Idea:
Develop the software in small parts while analyzing and managing risks at
each cycle.
Page 14 of 38
 • Introduced by:
Barry Boehm in 1986.
• Structure:
Shaped like a spiral with many loops. Each loop represents a phase of the
project.

Phases of the Spiral Model (in each loop)

Every loop (cycle) of the spiral has 4 main phases:

1. Planning Phase
• Define objectives, alternatives, and constraints.
• Identify requirements for the part being developed.

• Example: Decide to build a "Login system" in this cycle.

2. Risk Analysis Phase

• Identify and evaluate risks (e.g., security risks, technical challenges).
• Plan how to eliminate or minimize these risks.

• Example: Analyze the risk of weak password protection.

3. Engineering Phase
• Build and test the software (small part).
• Develop a prototype or part of the full system.

• Example: Implement and test the basic login form and database
connection.

Page 15 of 38
4. Evaluation Phase
• Get feedback from the customer/user.
• Evaluate the product and plan the next phase.

• Example: User tests the login, gives feedback like "add forgot password
feature."

After completing one loop →

New requirements are added → New risks are analyzed → Next spiral cycle
starts!

Important Features of Spiral Model

• Risk-driven approach: Risk analysis is a primary focus.
• Iterative releases: Software is built in stages.
• User involvement: Users review after each loop.
• Flexibility: Easy to add changes.
• Project visibility: Progress is clear after each cycle.

When to Use the Spiral Model

• For large and high-risk projects.
• When requirements are not clearly understood at the beginning.
• For complex and expensive projects like defense, aerospace, banking.
• When frequent changes are expected.

Limitations of the Spiral Model

Page 16 of 38
 • Expensive (requires highly skilled people for risk analysis).
• Complicated to manage (needs proper documentation at every cycle).
• Not ideal for small, simple projects (overkill).

Simple Real-World Example

Scenario Description

Building a hospital management system. Start by building the

appointment booking module (first spiral), then add billing system
Example
(second spiral), then add patient records management (third spiral),
and so on — each with its own risk analysis.

Important Comparison: Waterfall vs Prototype vs Spiral

Waterfall Model
• Linear and sequential development process.
• Move to next phase only after completing the current phase.
• No going back once a phase is completed.
• Low customer interaction during development.
• No risk analysis is done.
• Best suited for simple, stable, and clear requirement projects.
• Late error detection (only at testing phase).

Prototype Model
• Build a quick working model (prototype) first.
• Get customer feedback early and frequently.

Page 17 of 38
 • Frequent updates and improvements based on feedback.
• Useful when requirements are not clear.
• No major risk analysis (only changes after feedback).
• Best suited for UI/UX focused and dynamic requirement projects.
• Can become costly if too many changes happen.

Spiral Model
• Iterative development combined with risk analysis.
• Development happens in loops (spirals).
• Each spiral has Planning → Risk Analysis → Engineering → Evaluation
phases.
• High customer involvement and frequent releases.
• Best for large, complex, and high-risk projects.
• Can be costly and complex to manage.

Tabular Comparison:

Feature/Aspect Waterfall Model Prototype Model Spiral Model

Sequential (one Iterative (improve Iterative + Risk

Process Type
after another) prototype) Analysis

Customer High (frequent

Very Low Very High (every cycle)
Interaction feedback)

Flexibility Rigid Flexible Highly Flexible

No formal risk Strong risk

Risk Handling No risk handling
handling management

Page 18 of 38
Feature/Aspect Waterfall Model Prototype Model Spiral Model

Requirement Must be very

Can be unclear Can be unclear
Clarity clear at start

Medium to High High (needs expert

Cost Low to Medium
(due to rework) handling)

Small to
Small to Medium Large and Complex
Project Size Medium
(user-driven apps) projects
projects

Late (at testing Early (through

Error Detection Early (each spiral loop)
phase) prototypes)

Food Delivery App,

Payroll System, Hospital Management
Example Project E-commerce
Library System System, Banking App
Website

Key Takeaway:
• Use Waterfall when requirements are fixed and clear.
• Use Prototype when requirements are unclear and need lots of user
feedback.
• Use Spiral when the project is huge, complex, risky, and requires careful
planning.

What is Size Estimation in Software Engineering?

• Definition:
Size estimation refers to predicting how big a software system will be. It's
the first step in estimating cost, effort, and time required for software
development.
• Helps in:
o Project planning
Page 19 of 38
 o Budgeting
o Resource allocation
o Effort and cost estimation (used in COCOMO, etc.)

1. LOC (Lines of Code) Metric

Definition:
• LOC measures the total number of lines in a program's source code
(excluding comments and blank lines).
• It is a physical measure of the software's size.

Key Features:
• Simple and easy to calculate.
• Language-dependent (differs for C, Java, Python, etc.).
• Used in models like COCOMO for effort estimation.

Types of LOC:
• Physical LOC: Count of all code lines in the file.
• Logical LOC: Count of actual statements (e.g., if-else, loops, etc.).

Example:
java
Copy code
public class HelloWorld {

Page 20 of 38
 public static void main(String[] args) {
System.out.println("Hello, World!"); // 1 statement
}
}
• Physical LOC = 4 (including class and method lines)
• Logical LOC = 1 (only the print statement)

Limitations:
• Doesn't measure functionality — just quantity.
• Discourages reuse (more code = higher LOC).
• Cannot compare projects written in different languages easily.

2. FP (Function Point) Metric

Definition:
• Function Point (FP) measures functionality provided to the user —
independent of the programming language.
• It is a logical measure of size.

Key Components of FP:

1. External Inputs (EI): Inputs from users (e.g., form submissions).
2. External Outputs (EO): Output to users (e.g., reports).
3. External Inquiries (EQ): Input + Output with no data change (e.g., search).
4. Internal Logical Files (ILF): User-managed data stored internally (e.g.,
databases).
Page 21 of 38
 5. External Interface Files (EIF): External data used by the system (e.g., APIs).

Function Point Formula:

text
Copy code
FP = UFP × CAF
Where:
• UFP = Unadjusted Function Point
• CAF = Complexity Adjustment Factor (based on 14 factors like
performance, security, etc.)

Example:
If your system has:
• 3 External Inputs = 3 × 4 = 12
• 2 External Outputs = 2 × 5 = 10
• 1 External Inquiry = 1 × 4 = 4
UFP = 12 + 10 + 4 = 26
If CAF = 1.1
FP = 26 × 1.1 = 28.6

Advantages:
• Language independent.
• Focuses on user functionality.
• Encourages better design and reuse.

Page 22 of 38
 Limitations:
• Complex to calculate compared to LOC.
• Needs trained professionals to estimate accurately.
• Still somewhat subjective in rating components.

Comparison: LOC vs FP

LOC (Lines of
Feature FP (Function Point)
Code)

Type Physical measure Logical measure

Language Dependence Yes No

Focus Code size User functionality

Accuracy for Cost

Less accurate More accurate
Estimation

Reuse Encouragement No Yes

Complexity to Calculate Simple Complex

Large or business-oriented
Better for Small systems
systems

Summary
• LOC is best for code-based size estimation, quick and easy to use.
• FP is better for user functionality-based estimation and multi-language
projects.
• Use FP for early-stage planning, and LOC once coding starts.

What is Cost Estimation?

Page 23 of 38
 • Definition:
Cost estimation is the process of predicting the amount of effort, time,
and money required to develop a software product.
• Purpose:
o Helps in budget planning.
o Helps in scheduling the project.
o Helps in resource allocation.
• Depends on:
o Size of software (LOC, FP).
o Complexity.
o Experience of developers.
o Technology being used.

Popular Cost Estimation Techniques:

Technique Purpose

Delphi Technique Expert-based estimation

COCOMO Model Algorithmic model-based estimation

1. Delphi Technique

Definition:
• The Delphi Technique is a group decision-making method where multiple
experts estimate cost/effort independently and iteratively refine their
answers until a consensus is reached.

Page 24 of 38
 Steps Involved:
1. Coordinator selects a group of experienced experts.
2. Each expert gives an independent estimate for cost/effort.
3. Coordinator summarizes all estimates and shares the summary
anonymously.
4. Experts revise their estimates based on feedback.
5. Repeat steps 3-4 until consensus is achieved.

Example:
• 5 software engineers independently estimate project effort:
o Estimates: 500 hours, 550 hours, 530 hours, 520 hours, 510 hours.
• After 2-3 rounds of discussion and refinement, they agree on 525 hours.

Advantages:
• Reduces bias (anonymous).
• Useful when historical data is missing.
• Takes multiple expert opinions into account.
• Flexible and adaptable to different projects.

Disadvantages:
• Time-consuming if many rounds are needed.
• Depends heavily on expert availability.
• Not very effective if experts lack experience.

Page 25 of 38
 2. COCOMO (Constructive Cost Model)

Definition:
• COCOMO is an algorithmic model for software cost estimation, introduced
by Barry Boehm in 1981.
• It uses mathematical formulas based on project size (LOC) to estimate
effort, cost, and schedule.

Versions of COCOMO:
• COCOMO 81 (original version).
• COCOMO II (updated for modern software like web apps, agile projects).

Basic COCOMO Model Formula:

text
Copy code
Effort (in person-months) = a × (KLOC)^b
Development Time (months) = c × (Effort)^d
Where:
• KLOC = Thousands of Lines of Code
• a, b, c, d = Constants based on the type of project

Three Project Categories:

Page 26 of 38
Project Type Description Examples

Organic Simple, small teams, familiar systems Inventory system

Semi- Medium complexity, mixed experience Compiler

Detached team development

Complex, tight hardware+software

Embedded Aircraft control
systems

Example:
Suppose you have a simple Inventory System project estimated at 10 KLOC.
Constants for Organic type:
• a = 2.4, b = 1.05, c = 2.5, d = 0.38

Effort = 2.4 × (10)^1.05 ≈ 26 person-months

Development Time = 2.5 × (26)^0.38 ≈ 10 months

Advantages:
• Gives quantitative estimates.
• Simple calculations once constants are known.
• Helps early-stage estimation based on LOC.

Disadvantages:
• Needs accurate LOC estimation early (which is hard).
• Ignores modern development practices (COCOMO II improves it).
• Assumes that project size is the only major factor.

Page 27 of 38
 Comparison: Delphi vs COCOMO

Feature Delphi Technique COCOMO Model

Type Expert-based estimation Algorithmic estimation

Data Requirement Expert knowledge LOC (or FP)

Speed Slow (discussion rounds) Fast (formula-based)

Accuracy Depends on expert quality Depends on correct LOC estimate

Suitable for New, innovative projects Projects with known size

Quick Summary
• Delphi: Best when you need human expert judgment.
• COCOMO: Best when you have a measurable project size (like KLOC).
Both are often used together — Delphi for refining COCOMO estimates!
Introduction to Halstead’s Software Science

What is Halstead’s Software Science?

• Halstead’s Software Science is a complexity measure for software that
helps evaluate the effort required to write a program, as well as its
complexity.
• It was introduced by Maurice Halstead in 1977 as a way to quantify various
aspects of software, such as the number of operations, operands, and
overall program complexity.

Key Concepts in Halstead’s Software Science:

Page 28 of 38
Halstead introduced seven key metrics to measure different aspects of software,
each of which can be used to calculate complexity and effort. These metrics are
derived from the operators and operands in the code.

Operators:
• Operators are the symbols or words that perform operations (e.g., +, -, *,
if, for).
• Example: a = b + c — + is an operator.

Operands:
• Operands are the values or variables that the operators act on (e.g., a, b, c
in the above example).
• Example: a = b + c — a, b, and c are operands.

Halstead’s Seven Key Metrics:

1. n₁ (Number of Operators):
o Total distinct operators in the program.
o Example: In if (x > 5) { x = x + 1; }, operators are if, >, =, and +.
o n₁ = 4 in this case.
2. n₂ (Number of Operands):
o Total distinct operands used in the program.
o Example: In if (x > 5) { x = x + 1; }, operands are x, 5, and 1.
o n₂ = 3 in this case.
3. N₁ (Total Number of Operators):
o Total count of all the operators in the program.
o Example: In if (x > 5) { x = x + 1; }, we have the operators if, >, =, +.
o N₁ = 4 if each appears once.

Page 29 of 38
 4. N₂ (Total Number of Operands):
o Total count of all operands in the program.
o Example: In if (x > 5) { x = x + 1; }, operands are x, 5, and 1.
o N₂ = 3 in this case.
5. V (Volume):
o Program volume is the measure of the amount of information in the
program.
o Formula:
V=(n1+n2)×log⁡2(n1+n2)V = (n₁ + n₂) \times \log₂(n₁ + n₂)V=(n1+n2)×log2(n1+n2
)
o Example: If n₁ = 4 and n₂ = 3:
V=(4+3)×log⁡2(4+3)=7×log⁡27≈7×2.807≈19.649V = (4 + 3) \times \log₂(4 + 3) =
7 \times \log₂7 ≈ 7 \times 2.807 ≈ 19.649V=(4+3)×log2(4+3)=7×log2
7≈7×2.807≈19.649
o So, V ≈ 19.649.
6. D (Difficulty):
o Program difficulty measures how difficult it is to understand the
program.
o Formula:
D=n12×N2n2D = \frac{n₁}{2} \times \frac{N₂}{n₂}D=2n1×n2N2
o Example: If n₁ = 4 and n₂ = 3, and N₂ = 3:
D=42×33=2×1=2D = \frac{4}{2} \times \frac{3}{3} = 2 \times 1 = 2D=24×33
=2×1=2
o So, D = 2.
7. E (Effort):

Page 30 of 38
 o Effort measures the total mental effort required to develop the
program.
o Formula:
E=D×VE = D \times VE=D×V
o Example: If D = 2 and V ≈ 19.649:
E=2×19.649≈39.298E = 2 \times 19.649 ≈ 39.298E=2×19.649≈39.298
o So, E ≈ 39.298.

Additional Metrics in Halstead’s Software Science:

• Time: Estimated time to implement the program.
o Formula:
T=E18T = \frac{E}{18}T=18E
▪ Example: If E ≈ 39.298:
T=39.29818≈2.18 hoursT = \frac{39.298}{18} ≈ 2.18 \text{ hours}T=1839.298
≈2.18 hours
• Bugs (Error Estimate): Estimated number of errors in the program.
o Formula:
B=E2/33000B = \frac{E^{2/3}}{3000}B=3000E2/3
▪ Example: If E ≈ 39.298:
B=39.2982/33000≈0.167 bugsB = \frac{39.298^{2/3}}{3000} ≈ 0.167 \text{
bugs}B=300039.2982/3≈0.167 bugs

Halstead’s Metrics in Action (Example):

Consider the following simple code:
java
Page 31 of 38
Copy code
int x = 5;
if (x > 2) {
x = x + 1;
}
• Operators (n₁): =, >, + → 3 distinct operators.
• Operands (n₂): x, 5, 2, 1 → 4 distinct operands.
• Total operators (N₁): 4
• Total operands (N₂): 4
Let’s calculate:
1. V (Volume):
V=(3+4)×log⁡2(3+4)=7×log⁡27≈7×2.807=19.649V = (3 + 4) \times \log₂(3 + 4) =
7 \times \log₂7 ≈ 7 \times 2.807 = 19.649V=(3+4)×log2(3+4)=7×log2
7≈7×2.807=19.649
2. D (Difficulty):
D=32×44=1.5D = \frac{3}{2} \times \frac{4}{4} = 1.5D=23×44=1.5
3. E (Effort):
E=1.5×19.649≈29.474E = 1.5 \times 19.649 ≈ 29.474E=1.5×19.649≈29.474
4. Time:
T=29.47418≈1.64 hoursT = \frac{29.474}{18} ≈ 1.64 \text{ hours}T=1829.474
≈1.64 hours
5. Bugs:
B=29.4742/33000≈0.13 bugsB = \frac{29.474^{2/3}}{3000} ≈ 0.13 \text{
bugs}B=300029.4742/3≈0.13 bugs

Page 32 of 38
 Advantages of Halstead’s Software Science:
1. Quantitative: Provides a numerical measure for complexity, effort, and
size.
2. Language Independent: Can be used across different programming
languages.
3. Easy to Calculate: Once you know the operators and operands, it’s simple
to compute the metrics.
4. Helps with Project Estimation: Helps in predicting the effort, time, and
resources required for a project.

Limitations:
1. Doesn’t Measure Quality: Measures quantity but doesn't account for code
quality or design.
2. Over-simplified for Complex Systems: Does not capture higher-level
complexities such as design intricacies.
3. Depends on LOC: Relies on line of code, which may not always reflect the
true complexity of the codebase.

Summary
• Halstead’s Software Science provides an algorithmic way to measure the
complexity and effort required to develop software.
• It calculates various metrics like volume, difficulty, effort, and time to help
estimate the cost and resources for a project.
• Useful for software quality management and project estimation.

Staffing Level Estimation - Putnam’s Model

Page 33 of 38
 What is Putnam’s Model?
Putnam's model, also known as Putnam's Software Productivity Model, is a
mathematical model used to estimate the staffing requirements for a software
development project. It relates the effort (or size) of a project to the time and
number of developers (staff) required for completing the project.
• Developed by: Larry Putnam in 1978.
• Used for: Estimating the required staffing levels and effort needed to
complete a software project.

Key Concepts in Putnam’s Model:

1. Effort and Staff:
o The model calculates the effort required to complete the project in
terms of person-months.
o It also calculates the optimal staffing level to achieve the desired
completion time and effort.
2. Software Development Time:
o The model helps estimate how much time is needed for different
stages of development based on the size and complexity of the
software.
3. Productivity:
o The productivity of the team is impacted by the staff size, and
Putnam’s model helps determine the optimal balance between the
two.
4. Cocomo-like Relationship:
o Similar to COCOMO, the model is used for estimating effort, but it
also incorporates staffing levels and project size.

Page 34 of 38
 Key Variables in Putnam’s Model:
1. K (Total Effort):
o The total effort required for the project, measured in person-
months.
2. T (Development Time):
o The development time for the project, in months.
3. S (Staffing Level):
o The staffing level or the number of people working on the project.
4. M (Total Person-Months):
o The total manpower effort (number of developers multiplied by the
time they work on the project).

The Basic Formula of Putnam’s Model:

The fundamental relationship in Putnam’s model is:
K=a×(T×S)bK = a \times (T \times S)^bK=a×(T×S)b
Where:
• K = Total Effort (in person-months)
• T = Development Time (in months)
• S = Staffing Level (number of staff members)
• a, b = Constants based on the project type (like software size, complexity,
and environment)
This formula can be used to estimate the effort required for a project based on
the time and staff available.

Putnam’s Model in Practice:

Page 35 of 38
 • The model assumes that the effort for completing the project follows a
non-linear relationship with time and staffing.
• It shows that:
o Small teams of developers working for long periods can still achieve
a large effort.
o Large teams working for short periods can also complete the project
with the desired effort, but it’s important to find the right balance
between time and staffing.

The Ideal Staffing Curve (Putnam’s Model):

Putnam's model emphasizes the trade-off between the number of developers
and the time taken to complete the project. The relationship can be visualized as
a staffing curve:
• If too many developers are involved in the project, the productivity may
decrease due to the coordination overhead.
• If too few developers are involved, the project will take longer and may
miss deadlines.

Key Constants in the Model:

• a: A constant related to project size and complexity.
• b: A constant that reflects the time-effort relationship and project-specific
factors.
These constants are determined by historical data from similar projects, and
they vary based on the project’s size and complexity.

Example of Using Putnam’s Model:

Consider a software development project with the following parameters:
Page 36 of 38
 • Project Size: 10,000 lines of code (LOC).
• Development Time: 12 months.
• Staffing Level: 50 developers.
• Constants for this project type are: a = 0.3, b = 1.2.
Using Putnam’s formula:
K=0.3×(12×50)1.2K = 0.3 \times (12 \times 50)^{1.2}K=0.3×(12×50)1.2
K=0.3×(600)1.2≈0.3×1522.78=456.83 person-monthsK = 0.3 \times (600)^{1.2}
\approx 0.3 \times 1522.78 = 456.83 \text{ person-
months}K=0.3×(600)1.2≈0.3×1522.78=456.83 person-months
This means the project will require approximately 457 person-months of effort
to complete.

Advantages of Putnam’s Model:

1. Effective Staffing Estimates:
o The model provides valuable insight into how many developers
should be assigned to the project and helps in determining the
optimal team size.
2. Time and Effort Prediction:
o Helps in forecasting the effort, time, and staffing required for the
software project.
3. Simplicity:
o The model is relatively simple to apply and offers a quick estimate
for the project based on its size and complexity.

Disadvantages of Putnam’s Model:

1. Assumption of Constant Productivity:

Page 37 of 38
 o The model assumes a constant productivity rate over the entire
project, which may not be the case, especially if the team
composition changes.
2. Project-Specific Constants:
o The constants (a and b) need to be adjusted based on historical data,
which may not always be available for every project.
3. Complexity with Large Projects:
o The model becomes less accurate when estimating very large
projects, as it oversimplifies the relationship between effort, staffing,
and time.
4. Human and Organizational Factors:
o The model doesn't take into account human and organizational
factors, such as team dynamics, experience levels, and
communication issues.

Putnam’s Model - Conclusion:

• Putnam's Model is a powerful tool for staffing level estimation, helping
project managers determine how many developers are needed to
complete a software project on time and within the required effort.
• It’s most effective when applied to medium to large projects with known
project constants.
• Historical data from similar projects is crucial for adjusting the constants
for accurate estimations.

Page 38 of 38