Detailed Class Notes on Software Engineering Topics (Based on Roger S.
Pressman)
📅 1. Metrics for Size Estimation
🔹 Overview
Metrics are essential in software engineering for quantitative analysis of software processes and products.
Size estimation metrics particularly help in estimating effort, cost, and schedule.
🔹 Types of Size Metrics:
✉ Lines of Code (LOC)
• Definition: Measures the number of lines in the source code.
• Theory: LOC is a traditional metric used in early project estimation. It’s simple and easy to apply but
has drawbacks due to its language dependency and lack of consideration for complexity or reuse.
• Pros: Simple and direct.
• Cons: Language-dependent, doesn’t reflect complexity or productivity.
• Example:
int add(int a, int b) {
return a + b;
}
// LOC = 3 (including method signature and return statement)
✉ Function Points (FP)
• Definition: Measures functionality delivered to the user.
• Theory: Introduced by Albrecht, FP is a better alternative to LOC, particularly useful for business
applications. It evaluates software based on user interactions, interfaces, and logical files.
• Components:
• External Inputs (EI)
• External Outputs (EO)
• External Inquiries (EQ)
• Internal Logical Files (ILF)
• External Interface Files (EIF)
• Example:
• EI: 3 (Weight = 4), EO: 2 (Weight = 5), EQ: 4 (Weight = 3)
• ILF: 2 (Weight = 7), EIF: 1 (Weight = 5)
• FP = (34 + 25 + 43 + 27 + 1*5) = 12 + 10 + 12 + 14 + 5 = 53 FP
✉ Feature Points
• Theory: A refinement of Function Points. Adds weighting for algorithmic complexity.
• Use Case: Real-time and scientific software.
1
✉ Use Case Points (UCP)
• Theory: Uses actors and use case scenarios to determine complexity.
• Formula: UCP = UUCP × TCF × ECF
• UUCP = Unadjusted Use Case Points
• TCF = Technical Complexity Factor
• ECF = Environmental Complexity Factor
📅 2. Estimation Techniques
🔹 Objective:
To estimate the effort, cost, and time required to complete a software project based on its size and
complexity.
🔹 Techniques:
✉ Expert Judgment
• Theory: Leverages past experience and intuition of experts.
• Use: Common in early phases or in small teams.
• Pros/Cons: Quick but subjective.
• Example: Based on similar past projects, estimated effort is 6 person-months.
✉ Delphi Technique
• Theory: A consensus-based method. Iterative feedback leads to convergence of estimates.
• Use: Useful when multiple experts are available.
✉ Decomposition Techniques
• Theory: Divide the project into smaller components and estimate each.
• LOC-based Estimation Example:
• Module A: 200 LOC, Module B: 300 LOC
• Productivity: 50 LOC/hour
• Total time: (200 + 300) / 50 = 10 hours
✉ Function Point-based Estimation
• Theory: Uses calculated FP to derive time/cost.
• Example:
• FP = 53
• Productivity = 5 FP/person-day
• Effort = 53 / 5 = 10.6 person-days
2
✉ COCOMO Model (Basic)
• Theory: Empirical model developed by Barry Boehm.
• Formula: Effort = a*(KLOC)^b
• Example:
• KLOC = 5, a = 2.4, b = 1.05
• Effort = 2.4 * (5)^1.05 = 13.35 person-months
✉ Planning Poker
• Theory: Agile estimation technique where teams assign story points through consensus.
• Use: Helps uncover risks, misalignments.
📅 3. Scheduling
🔹 Objective:
To allocate time resources effectively to various project tasks, ensuring timely completion.
🔹 Key Concepts:
✉ Work Breakdown Structure (WBS)
• Theory: Hierarchical decomposition of tasks.
• Benefit: Clear understanding of scope.
• Example:
• Project → Frontend → Login Page, Dashboard
✉ Gantt Chart
• Theory: Bar chart showing task durations and overlaps.
• Tool: Microsoft Project, GanttProject
✉ PERT (Program Evaluation Review Technique)
• Theory: Incorporates uncertainty with three estimates.
• Formula: TE = (O + 4M + P) / 6
• Example:
• O = 2, M = 4, P = 8
• TE = (2 + 4×4 + 8)/6 = 4.33 days
✉ CPM (Critical Path Method)
• Theory: Identifies the sequence of dependent tasks that determine minimum project duration.
3
📅 4. Organization and Team Structure
🔹 Team Structures:
✉ Hierarchical (Centralized)
• Theory: Command flows top-down. Best for stable environments.
✉ Chief Programmer Team
• Theory: A lead programmer (chief) makes decisions with assistance.
✉ Democratic/Egoless Team
• Theory: Equal participation. Encourages creativity and learning.
✉ Agile Team
• Theory: Cross-functional, adaptive team working in sprints.
🔹 Example:
• Project: E-commerce Website
• Agile team: 2 Devs, 1 Tester, 1 UX, 1 Scrum Master
📅 5. Risk Management
🔹 Steps:
✉ Risk Identification
• Theory: Brainstorm to list potential internal and external risks.
✉ Risk Analysis
• Theory: Determine probability and impact.
• Risk Exposure = Probability x Impact
✉ Risk Prioritization
• Theory: Focus on highest exposure.
✉ RMMM Plan
• Theory: Create strategies to Mitigate, Monitor, and Manage risks.
4
🔹 Example:
Risk Probability Impact Exposure Strategy
Key Developer leaves 0.4 8 3.2 Mitigation: Cross-training
📅 6. Configuration Management
🔹 Key Activities:
✉ Configuration Identification
• Theory: Label CIs such as code, test plans, documents.
✉ Version Control
• Theory: Maintain a history of changes.
• Example Git Workflow:
• main , dev , feature/* , hotfix/*
✉ Change Control
• Theory: Approve/reject changes via a structured process.
✉ Status Reporting
• Theory: Communicate the state of CIs, versions.
🔹 Example:
• CI: [Link]
• Version: v1.2.3
• Changes: Fixed OAuth bug
🔹 Summary Activity:
• Group Activity: Create a WBS, risk table, and simulate GitHub commits.
• Quiz: Match estimation techniques, define CI, pick suitable team type for a project.
