e 5 – Detailed Study Notes

Estimation of time, resources and cost: COCOMO, Function Poi

Planning activities and re-planning. Risk Analysis. Release m
Licensing methods and Maintenance. Software Life Cycle Managem
negotiation, delivery, quality aspects.
Table of Contents
1. Software Cost & Effort Estimation
1.1 Why Estimate?
1.2 COCOMO Model (Basic, Intermediate, Advanced)
1.3 Function Point Method
1.4 Putnam Resource Allocation Model

2. Planning & Re-Planning

2.1 Project Planning Activities
2.2 Re-Planning
2.3 Software Life Cycle Management

3. Risk Analysis & Management

3.1 Definition & Characteristics
3.2 Reactive vs Proactive Strategies
3.3 Risk Categories
3.4 Risk Identification
3.5 Risk Projection / Estimation
3.6 Risk Refinement (CTC Format)
3.7 RMMM – Mitigation, Monitoring, Management
3.8 RMMM Plan
3.9 Seven Principles of Risk Management

4. Configuration Management
4.1 What is SCM?
4.2 SCM Activities
4.3 Release Mechanisms
4.4 Licensing Methods

5. Software Maintenance

6. Quality Management
6.1 Quality Concepts
6.2 Quality Control & Assurance
6.3 Cost of Quality
6.4 Software Quality Assurance (SQA)
6.5 Formal Technical Reviews (FTR)

7. Quick Revision
 1. Software Cost & Effort Estimation

Software estimation is the process of predicting the effort, time, cost, and resources required to develop a
software system. Accurate estimation is one of the most challenging — and most critical — activities in
software project management. Poor estimates lead to missed deadlines, cost overruns, and low-quality
products.

1.1 Why Estimate?

Before any project begins, managers and stakeholders need answers to key questions: How long will
development take? How many people are needed? What will it cost? Estimation models provide
structured, repeatable methods to answer these questions based on project characteristics and historical
data.

• To plan schedules and milestones realistically.

• To allocate resources (staff, equipment, budget) appropriately.
• To set customer expectations and contractual commitments.
• To provide a baseline for tracking project progress.
• To support make-or-buy decisions.

1.2 COCOMO Model (Constructive Cost Model)

COCOMO was proposed by Barry Boehm in 1981. It is one of the most widely used algorithmic cost
estimation models. COCOMO estimates the effort (in person-months) and development time based on
the size of the software (measured in KLOC — thousands of lines of code). There are three progressively
detailed levels.

Three Levels of COCOMO:

Level 1: Basic COCOMO

Basic COCOMO provides a rough estimate based solely on KLOC. It classifies software into three project
modes based on team experience and system complexity:

Mode Description Team/Constraints a b c d

Small, simple software developed

by small experienced teams in Small team, familiar 2. 1. 2. 0.
Organic familiar environments. problem 4 05 5 38

Medium-size projects where team

Semi-detach members have mixed experience Medium team, some 3. 1. 2. 0.
ed levels and mixed familiarity. rigid constraints 0 12 5 35

Software that operates under tight

hardware/software/operational
constraints (real-time, avionics, Complex constraints, 3. 1. 2. 0.
Embedded etc.). rigid requirements 6 20 5 32

Basic COCOMO Formulas:

 Effort (E) = a × (KLOC)b [Person-Months]

Development Time (D) = c × Ed [Months]

Average Staff (P) = E / D [Persons]

Productivity = KLOC / E [KLOC / Person-Month]

Where a, b, c, d are constants determined by the project mode (see table above). KLOC = thousands of
lines of code.

■ Worked Example – Basic COCOMO

Project: Semi-detached mode, estimated size = 32 KLOC. E = 3.0 × (32)^1.12 = 3.0 × 40.84 ≈ 122.5
person-months. D = 2.5 × (122.5)^0.35 = 2.5 × 7.08 ≈ 17.7 months. P = 122.5 / 17.7 ≈ 7 persons required.

Level 2: Intermediate COCOMO

Intermediate COCOMO refines the basic model by introducing 15 Cost Driver Attributes (also called
Effort Multipliers — EMs). Each attribute accounts for a specific project characteristic that affects effort.
The cost drivers are rated on a scale and their combined product (EAF — Effort Adjustment Factor) is
applied to the basic effort estimate.

E = a × (KLOC)b × EAF

Where EAF = product of all 15 cost driver ratings.

The 15 Cost Drivers are grouped into 4 categories:

Category Cost Driver Attributes

Product Attributes Required software reliability (RELY), Database size (DATA), Product complexity (CPLX)

Execution time constraint (TIME), Main storage constraint (STOR), Virtual machine volatility
Hardware Attributes (VIRT), Computer turnaround time (TURN)

Analyst capability (ACAP), Application experience (AEXP), Programmer capability (PCAP),

Personnel Attributes Virtual machine experience (VEXP), Language experience (LEXP)

Use of modern programming practices (MODP), Use of software tools (TOOL), Required
Project Attributes development schedule (SCED)

Each cost driver is rated as: Very Low, Low, Nominal, High, Very High, or Extra High. Ratings below
Nominal reduce effort (EAF < 1); above Nominal increase it (EAF > 1). Nominal rating = 1.00 for all drivers.

Level 3: Advanced (Detailed) COCOMO

Advanced COCOMO (also called COCOMO II) extends intermediate COCOMO by considering three
phases of the development lifecycle — requirements/design, coding, and integration/testing — separately.
It allows cost drivers to vary across phases and applies a phase-specific effort distribution. This provides
much more accurate estimates for large projects.

• Effort is estimated separately for each development phase.

• Cost driver weights can differ between phases.
• Accounts for modern development approaches: reuse, object-oriented design, prototyping.
• COCOMO II adds scale factors (SF) for team precedentedness, architecture flexibility, risk resolution,
team cohesion, and process maturity.

E (COCOMO II) = A × SizeSF × ∏EMi

Where A is a calibration constant (~2.94), Size is in KSLOC or function points, SF is the composite scale
factor (sum of 5 scale factor ratings × 0.01 + 1.01), and EM are effort multipliers.

1.3 Function Point (FP) Method

Proposed by Allan Albrecht (IBM) in 1979. Function Points measure the functional size of software from
the user's perspective — independent of programming language, development methodology, or
technology. FP is particularly useful when LOC cannot yet be estimated (early design phase).

Step 1 – Count the 5 Information Domain Values:

Abbrev
Information Domain Value iation Description

Inputs entering the system boundary from outside (user screens, data
External Inputs (EIs) EI feeds). Each unique input is counted once. Not inquiries.

Reports, screens, messages, error messages generated by the system for

External Outputs (EOs) EO users. Individual data items within a report are not counted separately.

Online input-output pairs — a query in, an immediate response out. Both

External Inquiries (EQs) EQ input and output are simple; no complex processing.

Logical data groups maintained (created, updated, deleted) inside the

Internal Logical Files (ILFs) ILF system boundary by external inputs.

Data groups that reside OUTSIDE the system boundary but are
External Interface Files (EIFs) EIF referenced/read by the system (shared data).

Step 2 – Assign Complexity Weights:

Each of the 5 domain values is assessed as Simple, Average, or Complex and multiplied by a weight
defined in the FP counting standard:

Domain Value Simple Average Complex

External Inputs (EI) 3 4 6

External Outputs (EO) 4 5 7

External Inquiries (EQ) 3 4 6

Internal Logical Files (ILF) 7 10 15

External Interface Files (EIF) 5 7 10

 UFP = Σ (count × weight) for all 5 domain values

UFP = Unadjusted Function Points = raw count before complexity adjustment.

Step 3 – Compute Complexity Adjustment Factor (CAF):

14 General System Characteristics (GSCs) are each rated 0–5 based on their influence:

Scale Value Meaning

0 No Influence

1 Incidental

2 Moderate

3 Average

4 Significant

5 Essential

The 14 General System Characteristics (GSCs) / Value Adjustment Factors:

• 1. Reliable backup and recovery
• 2. Data communications
• 3. Distributed processing functions
• 4. Performance-critical requirements
• 5. Heavily utilized operational environment
• 6. Online data entry
• 7. Multi-screen / multi-operation input transactions
• 8. Online update of internal logical files
• 9. Complex inputs, outputs, files, or inquiries
• 10. Complex internal processing
• 11. Code designed for reuse
• 12. Conversion and installation included in design
• 13. Multiple installations in different organizations
• 14. Ease of use and ease of change

CAF = 0.65 + (0.01 × ΣFi) where i = 1 to 14

ΣFi = sum of all 14 GSC ratings (range: 0 to 70). Therefore CAF ranges from 0.65 to 1.35.

FP = UFP × CAF

■ Worked Example (from PPT Slide 43)

EI=3, EO=2, EQ=2, ILF=1, EIF=4 → UFP = 50 | ΣFi = 46 CAF = 0.65 + (0.01 × 46) = 0.65 + 0.46 = 1.11 FP =
UFP × CAF = 50 × 1.11 = 55.5 ≈ 56 Function Points

What can FP be used to Estimate?

• Cost or effort required to design, code, and test the software.
 • Number of errors likely to be encountered during testing.
• Number of projected source code lines (using language-specific conversion ratios).
• Number of components and module complexity.
• Historical productivity comparisons across projects.

FP to LOC Conversion Ratios (approximate):

Language LOC per Function Point

C 128

COBOL 91

C++ 53

Java 46

Python 33

SQL 12

1.4 Putnam Resource Allocation Model

The Putnam model (1978) is a dynamic multivariable model that assumes software effort is not distributed
uniformly over the development lifecycle — it follows a Rayleigh curve. The model was derived
empirically from data on hundreds of large U.S. Army software projects.

Core Concept – The Rayleigh Curve:

Staff effort starts low, ramps up to a peak (typically at system test), then decreases. The area under the
Rayleigh curve gives the total effort E in person-years. The curve peaks at time td (delivery time).

L = Ck × K1/3 × td4/3

Where: L = delivered source lines of code (SLOC), Ck = technology constant (reflects process maturity,
tools, environment; typically 610–57,314 with 2,000 being poor, 8,000 good, 11,000+ excellent), K = total
life-cycle effort in person-years, td = development time in years.

Minimum Development Time: tdmin = 0.95 × (L / Ck)3/8

Minimum Effort: Kmin = L3 / (Ck3 × td4)

Key Implications of the Putnam Model:

• Compressing development time significantly INCREASES total effort (exponentially).
• A 75% schedule reduction doubles effort; 50% reduction quadruples it.
• The model predicts that you cannot simply add people at the end of a project to speed it up (confirms
Brooks' Law).
• SLIM (Software Lifecycle Management) is the automated tool based on the Putnam model.

Model Input Output Best For

Basic COCOMO KLOC, Project Mode Effort, Time, Staff Quick rough estimates
 Model Input Output Best For

Intermediate
COCOMO KLOC + 15 Cost Drivers Adjusted Effort Better accuracy early

Advanced COCOMO KLOC + SFs + EMs Phase-level effort Large complex projects

Early design,
Function Point Domain counts + GSCs FP (size measure) language-independent

Putnam (SLIM) SLOC, Ck, td Effort, team size over time Long large projects
 2. Planning, Re-Planning & Software Lifecycle Management

Project planning is the activity of creating a detailed roadmap for a software project. It covers scope
definition, task scheduling, resource allocation, risk identification, and quality planning. Re-planning is the
ongoing process of revising the plan as new information becomes available.

2.1 Project Planning Activities

Scope Definition
Define what the system will and will not do. Establish project boundaries, deliverables, and constraints
(schedule, budget, technology).

Estimation
Use COCOMO, FP, or Putnam to estimate effort, time, and cost. Always provide a range (best, expected,
worst case).

Risk Planning
Identify risks early. Classify by probability and impact. Develop mitigation strategies.

Scheduling
Create a work breakdown structure (WBS). Assign tasks to milestones. Use Gantt charts or PERT/CPM
networks to visualise the schedule.

Resource Allocation
Assign people, equipment, and budget to tasks. Balance workload across the team.

Quality Planning
Define quality standards, review procedures, and testing strategies up front.

Communication Planning
Define how information will flow between team members, management, and stakeholders. Frequency,
format, and responsibility for status reports.

Tracking & Control

Compare actual progress against the plan. Use earned value analysis (EVA) or milestone burndown
charts to detect deviations early.

2.2 Re-Planning

No plan survives first contact with reality unchanged. Re-planning is a routine, expected part of good
project management — not a sign of failure.

• Triggers for re-planning: scope change, requirement change, team member departure, technology
failure, discovered underestimation.
• Always baseline the original plan before revising it — baselines allow variance analysis.
• Communicate changes to all stakeholders immediately.
 • Evaluate the impact on: schedule, cost, quality, and risk before committing to the new plan.
• Agile approaches (Scrum, XP) build re-planning in by design through sprints and backlog refinement.

2.3 Software Life Cycle Management (SLCM)

SLCM encompasses all management disciplines applied across the complete software lifecycle — from
initial concept through development, deployment, and eventual retirement. The syllabus identifies six key
aspects:

• Planning: Establish objectives, select lifecycle model (waterfall, spiral, agile), create the project plan.
Define entry and exit criteria for each phase.
• Tracking: Monitor progress against the plan using metrics: planned vs actual effort, schedule
variance (SV), cost variance (CV), defect density. Use milestone reviews.
• Communication: Regular status reports to all stakeholders. Team meetings, code reviews, change
control boards. Clear escalation paths for issues.
• Negotiation: Manage competing constraints (scope, schedule, budget, quality). Negotiate
requirement changes and priority with customers. Document all agreed changes.
• Delivery: Release planning, deployment strategy, user training, cutover plan. Define acceptance
criteria and verify them before delivery.
• Quality Aspects: SQA plan, formal technical reviews, testing strategies, defect tracking, process
compliance audits. Post-delivery support and measurement.
 3. Risk Analysis & Management

A risk is a potential problem — it might happen, it might not. Risk management is the discipline of
identifying, analysing, prioritising, and controlling risks before they become actual problems.

3.1 Definition & Characteristics of Risk

Conceptual definition: Risk concerns future happenings — it involves choice and the uncertainty that
choice entails.

• Uncertainty: The risk may or may not happen. 100% probable risks are called constraints, not risks.
• Loss: If the risk becomes reality, unwanted consequences or losses occur.

Who manages risks? Managers, software engineers, and stakeholders — collectively. The motto:
understand risks and take proactive measures to avoid them.

3.2 Reactive vs Proactive Risk Strategies

Dimension Reactive Proactive

When After the problem occurs Before technical work begins

Approach 'Fire fighting' — scramble to fix Systematic identification & avoidance

Plan No contingency plan Contingency plan defined in advance

Cost High (late discovery is expensive) Lower (early prevention)

Quality Impact High — defects slip through Low — risks addressed early

Example Team scrambles after a deadline is missed Risk register created at project start

Proactive Risk Management Steps (PPT Slide 48):

Step 1: Identify possible risks — recognize what can go wrong.

Step 2: Analyse each risk: estimate the probability it will occur and the impact if it does.

Step 3: Rank risks by probability × impact (risk exposure).

Step 4: Develop contingency plans for risks with high probability and high impact.

3.3 Risk Categories

Category Threats Examples

Project plan — schedule slips, Unrealistic delivery date, budget cuts, personnel loss,
Project Risks cost increases resource unavailability

Design problems, implementation difficulties, interface

Technical Risks Quality and timeliness of software complexity, verification failures

Market risk (nobody wants it), strategic risk, sales risk,

Business Risks Viability of software / project management risk, budget risk

Known Risks Discoverable by careful evaluation Unrealistic delivery date, no documented requirements
 Category Threats Examples

Predictable Risks Extrapolated from past experience Staff turnover, poor communication with client

Occur but extremely hard to

Unpredictable Risks identify Natural disasters, sudden technology obsolescence

Sub-categories of Business Risk:

• Market risk – building an excellent product that nobody wants.
• Strategic risk – product no longer fits company business strategy.
• Sales risk – sales force doesn't understand how to sell the product.
• Management risk – losing senior management support.
• Budget risk – losing budgetary or personnel commitment.

3.4 Risk Identification

Risk identification is a systematic attempt to specify threats to the project plan. Two types of risks must be
identified:

• Generic risks — potential threats to every software project (e.g., staff turnover, unrealistic
schedules).
• Product-specific risks — risks specific to this project's technology, people, and environment.

Risk Item Checklist Categories:

• Product size – risks from overall size and complexity of the software.
• Business impact – constraints imposed by management or marketplace.
• Customer characteristics – sophistication of customer, communication ability.
• Process definition – degree to which the software process is defined and followed.
• Development environment – availability and quality of tools.
• Technology to be built – complexity and 'newness' of technology.
• Staff size and experience – technical and project experience of the team.

3.5 Risk Projection / Estimation

Risk projection (estimation) rates each risk in two dimensions: the probability it will occur and the
consequence (damage) if it does. This leads to prioritisation so limited resources go where they have
most impact.

Four Risk Projection Steps:

1. Establish a scale reflecting perceived likelihood (e.g., 1=low … 10=high).

2. Delineate the consequences of each risk.

3. Estimate impact on project and product.

4. Note overall accuracy of the risk projection to prevent misunderstandings.

Risk Exposure (RE) Formula:

 RE = P × C

Where P = probability of occurrence, C = cost to the project if the risk occurs.

■ RE Example (PPT Slide 65)

18 of 60 components may need to be re-developed. P = 0.80. Each component = 100 LOC × $14/LOC → C =
18 × 100 × 14 = $25,200 RE = 0.80 × 25,200 = $20,160

Risk Table (Developing a Risk Table):

• Risk Summary — short description of the risk.
• Risk Category — project / technical / business / known / predictable.
• Probability — estimated likelihood (0–1 or 1–10 scale).
• Impact — 1=Catastrophic, 2=Critical, 3=Marginal, 4=Negligible.
• RMMM — pointer to Risk Mitigation, Monitoring, Management plan paragraph.

Once compiled, sort by probability × impact descending. Draw a cutoff line — risks above the line get full
RMMM treatment.

3.6 Risk Refinement – CTC Format

Risk refinement decompose a high-level risk into more specific sub-conditions using the
Condition-Transition-Consequence (CTC) format:

Given that [condition], there is concern that (possibly) [consequence]

Example — Reusable Component Risk (PPT Slide 67):

• Sub-condition 1: Certain reusable components were developed by a third party with no knowledge of
internal design standards.
• Sub-condition 2: The design standard for component interfaces has not been solidified and may not
conform to certain existing reusable components.
• Sub-condition 3: Certain reusable components have been implemented in a language that is not
supported on the target environment.

3.7 RMMM – Risk Mitigation, Monitoring & Management

An effective risk strategy must address three issues:

Risk Mitigation (Avoidance)

Primary strategy. Proactively plan to avoid or reduce the risk before it occurs. Example (staff turnover):
meet with staff to determine turnover causes, mitigate controllable causes before project starts, document
widely, conduct peer reviews, assign backup members for critical roles.
Risk Monitoring
A project tracking activity. Monitor factors indicating whether a risk is becoming more or less likely. Three
objectives: (1) assess whether predicted risks actually occur; (2) ensure risk aversion steps are properly
applied; (3) collect data for future risk analysis. Example: monitor team morale, interpersonal relations,
compensation satisfaction.

Risk Management & Contingency Planning

Assumes mitigation has failed — the risk became reality. Contingency plan specifies what to do when the
risk occurs. Must be defined BEFORE the risk occurs, not after.

3.8 RMMM Plan

The RMMM plan may be part of the Software Development Plan or a separate document. Once written
and the project begins, risk mitigation and monitoring steps start. Large projects may have 30–40 identified
risks, each with its own RMMM entry.

• Note: RMMM steps incur additional project cost — they must be budgeted.
• Risk is not limited to development — risks can occur AFTER software is delivered to the user.
• The Risk Management Team assists the project team in defining risks, assessing impact/probability,
and tracking risks throughout the project.

3.9 Seven Principles of Risk Management (PPT Slide 73)

• Principle 1 – Maintain a global perspective: View software risks within the context of the overall
system and the business problem it is intended to solve.
• Principle 2 – Take a forward-looking view: Think about risks that may arise in the future; establish
contingency plans.
• Principle 3 – Encourage open communication: All stakeholders and users should be encouraged
to point out risks at any time.
• Principle 4 – Integrate risk management: Integrate risk consideration into the software process
itself — not as an add-on activity.
• Principle 5 – Emphasise a continuous process: Modify identified risks as more is known; add new
risks as better insight is achieved.
• Principle 6 – Develop a shared product vision: A shared vision by all stakeholders facilitates
better risk identification and assessment.
• Principle 7 – Encourage teamwork: Pool the skills and experience of all stakeholders when
conducting risk management activities.
 4. Configuration Management, Release Mechanisms & Licensing

Software Configuration Management (SCM) is the set of activities designed to control change throughout
the software lifecycle. SCM identifies, organises, and controls modifications to software. The goal is to
maximise productivity by minimising mistakes.

4.1 What is SCM?

Change is inevitable in software projects. SCM is not the same as software support — it is a set of tracking
and control activities that begin when a software project begins and terminate only when the software is
taken out of operation.

Key Concepts:
• Configuration Item (CI): Any work product that is subject to change control: source code, data
structures, documents, test cases, build scripts.
• Baseline: A formally reviewed and agreed specification or product that serves as the basis for further
development. Changes to a baseline must follow formal change control.
• Software Repository: A database of all configuration items and their relationships. Provides version
control, access control, and audit trails.
• Version Control: Tracks every change to every CI. Enables rollback to any previous version. Tools:
Git, SVN, Mercurial.
• Change Control Board (CCB): A group that evaluates proposed changes and approves or rejects
them based on technical and business impact.

4.2 SCM Activities

SCM Activity Description

Identify all items that will be placed under configuration control. Assign unique
Configuration Identification identifiers to each CI.

Track and manage all versions and variants of each CI. Control who can change
Version Control what and when.

Evaluate change requests, approve/reject them, implement approved changes, and

Change Control verify the changes are correctly incorporated.

Verify that the software being built conforms to its specifications and that all
Configuration Auditing approved changes have been correctly implemented.

Record and report the current status of each CI — what version it is, what changes
Configuration Status Accounting have been made, who made them.

Release Management Control the creation, testing, and distribution of software releases to users.

4.3 Release Mechanisms

A software release is a distribution of a specific version of the software to users. Release management
controls the timing, content, and method of each release.

• Major Release: Significant new functionality; often changes the major version number (e.g., v1.0 →
v2.0). Requires full testing cycle.
 • Minor Release: Minor new features, enhancements, or non-critical bug fixes (e.g., v1.1, v1.2). Partial
regression testing.
• Patch / Hotfix: Emergency fix for a critical defect in production. Minimal testing — focused on the
specific fix.
• Alpha Release: Early internal testing release — software incomplete, may have known bugs. Tested
by in-house team.
• Beta Release: Feature-complete release given to a limited set of external users for real-world testing
before final release.
• Release Candidate (RC): A build that could become the final product if no critical bugs are found.
Undergoes final acceptance testing.
• General Availability (GA): The final, production-ready release distributed to all users.

■ Release Planning

A release plan defines: what features go into each release, release dates, testing requirements, deployment
strategy, rollback plan (if the release fails), and communication to users.

4.4 Licensing Methods

Software licensing defines the legal terms under which software may be used, copied, modified, and
distributed. Different licensing models serve different commercial and community purposes:

License Type Key Characteristics Examples

Source code not shared. Restrictions on use,

copying, modification. Must purchase or Microsoft Office, Adobe Photoshop,
Proprietary / Commercial subscribe. Oracle DB

Source code freely available. Can use, modify,

Open Source – Permissive distribute. Modified versions need not be open. MIT, BSD, Apache 2.0 licenses

Source code freely available. Any derivative work

Open Source – Copyleft must also be open source under the same
(Strong) license. GPL v2, GPL v3

Open Source – Copyleft Library can be linked to proprietary code; only

(Weak/LGPL) changes to the library itself must remain open. LGPL, Mozilla Public License (MPL)

Free to use but source code not provided. No

Freeware modification rights. Adobe Reader (historically), Skype

Free trial period; payment required for continued

Shareware or full use. WinRAR, many older utilities

Basic features free; advanced features require

Freemium / SaaS subscription. Software delivered as a service. Slack, Dropbox, Zoom, GitHub

No copyright restrictions. Anyone can use, SQLite, some US government

Public Domain modify, distribute freely without attribution. software

End User License Agreement (EULA): The legal contract between the software publisher and the end
user. It defines permitted uses, restrictions, warranties, and liability. Accepting the EULA is required before
installation or use.
 5. Software Maintenance

Software maintenance is the process of modifying a software system or component after delivery to
correct faults, improve performance, or adapt to a changed environment. Studies show that 60–80% of
total software lifecycle cost is spent on maintenance.

Four Types of Software Maintenance (IEEE 1219):

% of Effort
Type Trigger Purpose (typical)

Bug/fault discovered Fix defects — incorrect logic, crashes, data

Corrective post-delivery corruption. ~17%

Environment changes (OS

upgrade, new hardware, law Adapt software to work in the new
Adaptive change) environment without changing functionality. ~18%

User requests new/enhanced Add new features, improve performance,

Perfective functionality enhance usability. ~60%

Restructure/refactor code to improve

Preventive Anticipating future problems maintainability and prevent future faults. ~5%

Maintenance Challenges:
• Understanding legacy code written by others, often without documentation.
• Regression — fixing one defect may introduce another.
• Keeping documentation in sync with code changes.
• Technical debt accumulation — shortcuts taken during development compound over time.
• Difficulty estimating effort — maintenance tasks are often unpredictable.

■ Maintainability Metrics

Mean Time to Repair (MTTR): average time to fix a defect. Change Request Backlog: number of pending
changes. Defect Density: defects per KLOC. Cyclomatic Complexity: higher complexity = harder to maintain.
 6. Quality Management

Quality management ensures that the software product meets defined standards and satisfies user
requirements. It encompasses quality planning, quality control, quality assurance, and process
improvement.

6.1 Quality Concepts

Software quality is defined as conformance to explicitly stated functional and performance

requirements, explicitly documented development standards, and implicit characteristics expected
of professionally developed software.

• Quality of Design: The characteristics specified by designers — requirements, specifications,

system design. If the design is wrong, the final product will not be quality even if perfectly implemented.
• Quality of Conformance: The degree to which the design specifications are followed during
implementation. If implementation perfectly follows the design, conformance quality is high.
• User Satisfaction (Glass's formula): Compliant product + Good quality + Delivery within budget
and schedule.

McCall's Quality Factor Model (11 Factors in 3 Groups):

Group Quality Factors

Product Operation (How well it

runs) Correctness, Reliability, Efficiency, Integrity, Usability

Product Revision (How easy to

change) Maintainability, Flexibility, Testability

Product Transition (How easy to

move) Portability, Reusability, Interoperability

Factor Definition

Extent to which a program satisfies its specifications and fulfills customer mission
Correctness objectives.

Reliability Extent to which a program performs its intended function with required precision.

Efficiency Computing resources and code required to perform the function.

Integrity Extent to which access to software or data by unauthorised persons can be controlled.

Usability Effort required to learn, operate, prepare input, and interpret output.

Maintainability Effort required to locate and fix an error.

Flexibility Effort required to modify an operational program.

Testability Effort required to test a program to ensure it performs its intended function.

Portability Effort required to transfer the program from one hardware/software environment to another.

Reusability Extent to which a program or parts can be reused in other applications.

Interoperability Effort required to couple one system to another.

6.2 Quality Control & Quality Assurance

Quality Control (QC): A series of inspections, reviews, and tests used throughout the software process to
ensure each work product meets its requirements. QC is product-focused — it finds defects in the product.

Quality Assurance (QA): Auditing and reporting functions that assess the effectiveness and
completeness of quality control activities. QA is process-focused — it ensures the right process is being
followed correctly.

Variation Control: The heart of quality control. Minimise the difference between predicted and actual
resources (staff, equipment, time). Statistical process control (SPC) measures variation and drives
improvement.

6.3 Cost of Quality (CoQ)

The Cost of Quality includes all costs incurred in pursuing quality and in dealing with the results of poor
quality. It comprises three components:

Cost Category Sub-Categories Examples

Prevention Costs (Cost Quality planning, FTRs, test Writing a test plan, conducting design reviews, training
to avoid defects) equipment, training staff in coding standards.

Appraisal Costs (Cost In-process inspection, equipment Unit testing, integration testing, peer code reviews,
to evaluate quality) calibration, testing acceptance testing.

Internal Failure Costs

(Found before Rework, repair, failure mode Fixing a bug found during testing, redesigning a
delivery) analysis component.

External Failure Costs Complaint resolution, returns, Fixing bugs after release, processing refunds,
(Found after delivery) warranty, help line emergency patches.

■ Cost Impact Rule

The earlier a defect is found, the cheaper it is to fix. Relative costs (from industry data): Design review: 1.0× |
Pre-test: 6.5× | During testing: 15× | After release: 60–100×. This justifies investing heavily in prevention and
early appraisal.

6.4 Software Quality Assurance (SQA)

SQA is a planned and systematic pattern of actions required to ensure high quality in software. SQA
encompasses:

• (1) A software quality assurance process.

• (2) Effective software engineering technology (methods and tools).
• (3) Quality control activities: formal technical reviews, multi-tier testing.
• (4) Control of software documentation and changes.
• (5) Procedures to ensure compliance with development standards.
• (6) Measurement and reporting mechanisms.

SQA Group Activities:

• Prepare an SQA plan for the project.
• Participate in development of the project's software process description.
 • Review software engineering activities to verify compliance with the defined process.
• Audit designated work products for compliance with process-defined standards.
• Ensure that deviations in work products are documented and handled per documented procedure.
• Record noncompliance items and report to senior management.

6.5 Formal Technical Reviews (FTR)

FTR is the most effective quality filter from a QA standpoint. Conducted by software engineers for software
engineers, it finds errors during the process before they become defects after release.

Objectives of FTR:
• Uncover errors in function, logic, or implementation.
• Verify software meets its requirements.
• Ensure software is represented according to predefined standards.
• Achieve uniformly developed software.
• Make projects more manageable.

FTR Meeting Procedure:

1. Producer informs project leader that work product is complete and review is requested.

2. Review leader evaluates for readiness, distributes materials to 2–3 reviewers.

3. Each reviewer spends 1–2 hours preparing independently.

4. Review meeting: 3–5 people, ≤ 2 hours, focused on a small portion of the work product.

5. One reviewer acts as recorder — documents all issues raised.

6. At end: decide to (1) accept, (2) reject for major rework, or (3) accept provisionally.

7. All attendees sign off indicating participation and concurrence.

FTR Review Summary Report answers:

• What was reviewed?
• Who reviewed it?
• What were the findings and conclusions?

FTR Guidelines (Key):

1. Review the product, not the producer.

2. Set an agenda and maintain it.

3. Limit debate and rebuttal.

4. Enunciate problem areas — don't attempt to solve every problem in the meeting.

5. Take written notes.

6. Limit participants — keep it to the necessary minimum.

7. Develop a checklist for each product type.

8. Allocate resources and schedule FTR as a formal task.

9. Conduct meaningful training for all reviewers.

10. Review your early reviews (debrief the process itself).

■ Defect Amplification

Without reviews: errors from design propagate into code unchanged, then multiply in testing. With FTR: up to
75% of design errors caught during review. This prevents exponential cost amplification at each lifecycle
stage.
7. Quick Revision – Key Definitions & Formulas

Term / Formula Definition / Value

COCOMO Effort E = a × (KLOC)^b [person-months]

COCOMO Dev Time D = c × E^d [months]

Organic mode (a,b,c,d) 2.4, 1.05, 2.5, 0.38

Semi-detached (a,b,c,d) 3.0, 1.12, 2.5, 0.35

Embedded (a,b,c,d) 3.6, 1.20, 2.5, 0.32

Intermediate COCOMO E = a × (KLOC)^b × EAF (15 cost drivers)

Function Point FP = UFP × CAF

CAF formula CAF = 0.65 + (0.01 × ΣFi) where ΣFi = sum of 14 GSC ratings (0–70)

CAF range 0.65 (min) to 1.35 (max)

Putnam model L = Ck × K^(1/3) × td^(4/3)

Risk Exposure RE = P × C

Risk Potential problem — uncertainty + loss

Reactive strategy Fix after problem occurs (fire fighting)

Proactive strategy Identify, analyse, rank, plan before problems occur

RMMM Risk Mitigation, Monitoring, Management

CTC Format Given [condition], concern that [consequence]

Corrective maintenance Fix defects after delivery (~17% effort)

Perfective maintenance Add/improve features (~60% effort)

Adaptive maintenance Adapt to new environment (~18% effort)

Preventive maintenance Refactor to prevent future faults (~5% effort)

SQA Planned systematic actions to ensure high quality in software

FTR Formal Technical Review — 3-5 people, ≤2 hrs, find errors before release

CoQ Prevention + Appraisal + Internal Failure + External Failure costs

Correctness, Reliability, Efficiency, Integrity, Usability | Maintainability, Flexibility,

McCall's 11 Factors Testability | Portability, Reusability, Interoperability

Formally agreed CI that serves as basis for further development; changes via
Baseline formal change control

Version Control Tracks all changes to all CIs; enables rollback; e.g., Git, SVN

End of Module 5 Notes | Software Engineering | 2024