BSc CSIT (TU) Science Software Project Management (BSc CSIT, CSC466) Question Paper 2074 Nepal

Software Cost Estimation

Software cost estimation is the process of predicting the effort, time (schedule), and cost required to develop a software system, usually before or during the early phases of a project. It is essential for budgeting, bidding, resource allocation and scheduling. Estimation is based on a measure of software size (lines of code, KLOC, or function points) and on project/personnel characteristics.

COCOMO Model

COCOMO (Constructive Cost Model), proposed by Barry Boehm (1981), is an empirical regression-based model that estimates effort and schedule from program size measured in KLOC (thousands of delivered lines of code). It classifies projects into three modes:

1. Basic COCOMO

Estimates effort and time as a function of size only:

Example (Organic, 33 KLOC):

2. Intermediate COCOMO

Refines the estimate by multiplying the nominal effort by an Effort Adjustment Factor (EAF) — the product of 15 cost drivers (e.g., product reliability, database size, complexity, analyst capability, programmer capability, tool use, schedule). Each driver is rated very-low … extra-high and mapped to a multiplier.

with adjusted coefficients $a$ = 3.2 (organic), 3.0 (semi-detached), 2.8 (embedded). EAF > 1 increases effort; EAF < 1 reduces it.

3. Detailed (Complete) COCOMO

Applies the intermediate model phase by phase (requirements, design, coding, integration/test). Each cost driver is given a different rating in each phase, giving more accurate effort distribution across the lifecycle and accounting for the three-level hierarchy (module, subsystem, system).

Summary

Basic = size only (quick, rough); Intermediate = size + 15 cost drivers (more accurate); Detailed = intermediate applied per phase (most accurate, most data needed).

Network Planning Models

Network planning represents a project as a graph of activities and events, showing precedence (which task must finish before another can start). It lets the manager compute project duration, identify which activities are critical, and find slack. The two principal techniques are CPM and PERT.

Critical Path Method (CPM)

CPM is a deterministic technique that uses a single (known) estimate of each activity's duration. By a forward and backward pass it computes:

• EST/EFT – Earliest Start / Earliest Finish (forward pass: $EFT = EST + duration$)
• LST/LFT – Latest Start / Latest Finish (backward pass: $LST = LFT - duration$)
• Total Float (slack) $= LST - EST = LFT - EFT$

The critical path is the longest path through the network; its activities have zero float and determine the minimum project completion time. Delaying any critical activity delays the whole project.

Program Evaluation and Review Technique (PERT)

PERT is a probabilistic technique for projects with uncertain durations (research/new development). Each activity gets three estimates — optimistic $a$, most likely $m$, pessimistic $b$ — combined as:

The expected times $t_e$ are then used like CPM durations to find the critical path, and path variance is the sum of activity variances. This allows probability statements about meeting a deadline.

Example Activity Network

Consider activities with precedence and durations (weeks):

Paths and lengths:

• A→B→D→F = 3+4+5+3 = 15
• A→C→E→F = 3+2+6+3 = 14

Critical path = A → B → D → F, project duration = 15 weeks. Activities A, B, D, F have zero float; C and E have float = 15 − 14 = 1 week, so each may slip up to 1 week without delaying the project.

Risk Management in Software Projects

A risk is a future event or condition that has a probability of occurring and, if it does, causes a loss or adverse effect on the project (schedule, cost, quality). Risk management is the systematic process of identifying, analysing and responding to such uncertainties to minimise the probability and impact of negative events.

Risk Management Framework

1. Risk Identification – discover possible risks (technical, schedule, cost, staffing, requirements, external) using checklists, brainstorming and historical data; produce a risk register.
2. Risk Assessment (Analysis) – estimate each risk's probability $P$ and impact $I$, and rank by risk exposure $RE = P \times I$. Separates major from minor risks.
3. Risk Planning (Response) – decide how to handle each risk: avoid, transfer, mitigate/reduce, or accept (contingency); prepare contingency plans for high-exposure risks.
4. Risk Monitoring & Control – continuously track identified risks, watch for trigger conditions, re-assess, and execute mitigation/contingency actions as the project proceeds.

These steps form a continuous cycle repeated throughout the project.

Evaluating Schedule Risk with PERT and Z-values

Using PERT, each activity has expected time $t_e=(a+4m+b)/6$ and variance $\sigma^2=((b-a)/6)^2$. For the critical path:

• Expected completion $T_e = \sum t_e$
• Path variance $\sigma_p^2 = \sum \sigma^2$ (along the critical path)
• Standard deviation $\sigma_p = \sqrt{\sigma_p^2}$

To find the probability of finishing by a target date $T_s$, assume the path total is normally distributed and compute the Z-value:

The area under the standard normal curve up to $Z$ gives $P(\text{finish} \le T_s)$.

Example: if $T_e = 30$ weeks, $\sigma_p = 4$ weeks and target $T_s = 36$ weeks:

so there is about a 93% chance of completing within 36 weeks. A negative or low Z indicates high schedule risk and the need for mitigation (more resources, scope reduction).

Basic COCOMO (Constructive Cost Model) is the simplest form of Boehm's model. It estimates effort and development time as a function of program size only, measured in KLOC (thousands of delivered lines of code), classifying projects as organic, semi-detached or embedded.

The effort equation is:

and the schedule equation is $D = c\,(E)^{d}$ months, where coefficients depend on mode:

Example (organic, 33 KLOC): $E = 2.4\times(33)^{1.05}\approx 95$ person-months. It is quick but rough because it ignores cost drivers like reliability and team skill.

Function Point Analysis (FPA), developed by Allan Albrecht, measures software size from the functionality delivered to the user, independent of programming language or technology (unlike LOC). It counts five external components of the system:

1. External Inputs (EI) – inputs that update data
2. External Outputs (EO) – reports/messages to the user
3. External Inquiries (EQ) – input-output query pairs
4. Internal Logical Files (ILF) – internally maintained data
5. External Interface Files (EIF) – data shared with other systems

Procedure:

1. Count each component and weight it by complexity (simple/average/complex) to get the Unadjusted Function Points (UFP).
2. Compute the Value Adjustment Factor (VAF) from 14 General System Characteristics (each rated 0–5):

3. Adjusted Function Points: $FP = UFP \times VAF$.

FP can be converted to KLOC (via language-specific factors) or directly to effort, and is useful for early, language-independent estimation.

The Critical Path Method (CPM) is a deterministic network scheduling technique that models a project as activities with known durations and precedence relations, and computes the longest path through the network to determine the minimum project completion time.

Determining the critical path:

1. Draw the activity network with durations and dependencies.
2. Forward pass – compute Earliest Start (EST) and Earliest Finish ($EFT = EST + d$) for every activity, left to right.
3. Backward pass – compute Latest Finish (LFT) and Latest Start ($LST = LFT - d$), right to left.
4. Total float $= LST - EST = LFT - EFT$.
5. The critical path is the chain of activities with zero float (the longest-duration path). Any delay on a critical activity delays the entire project.

Example: if paths are A-B-D (15 weeks) and A-C-E (14 weeks), the critical path is A-B-D with project duration 15 weeks.

PERT (Program Evaluation and Review Technique) is a probabilistic network-scheduling technique used when activity durations are uncertain (e.g., novel R&D projects). It is event-oriented and incorporates uncertainty through three-point estimation.

For each activity, three estimates are made:

• Optimistic ($a$) – shortest time if everything goes well
• Most likely ($m$) – most probable time under normal conditions
• Pessimistic ($b$) – longest time if problems occur

The expected (mean) duration uses a Beta-distribution weighting:

and the uncertainty is measured by:

These $t_e$ values are used (like CPM) to find the critical path, and summing the variances of critical activities allows probability estimates (via Z-values) of meeting a deadline.

Example: $a=2,\ m=4,\ b=12 \Rightarrow t_e = (2 + 16 + 12)/6 = 5$ weeks, $\sigma = (12-2)/6 \approx 1.67$ weeks.

A risk is an uncertain future event or condition that has a probability of occurring and, if it occurs, has a negative impact on the project's objectives (schedule, cost, scope or quality). Risk = probability × loss.

Steps of the risk management process:

1. Risk Identification – list potential risks (technical, schedule, budget, staffing, requirements, external) using checklists and brainstorming; record in a risk register.
2. Risk Analysis / Assessment – estimate each risk's probability and impact, and compute risk exposure $RE = P \times I$ to prioritise them.
3. Risk Planning – decide a response for each significant risk: avoid, transfer, mitigate (reduce), or accept with a contingency plan.
4. Risk Monitoring and Control – track risks throughout the project, watch for triggers, re-evaluate, and execute mitigation/contingency actions when needed.

This is an iterative cycle performed continuously over the project lifecycle.

Earned Value Analysis (EVA / EVM) is a project-control technique that integrates scope, schedule and cost to objectively measure progress and forecast performance. It compares the value of work actually completed against what was planned and what it actually cost. Three basic measures:

• PV (Planned Value / BCWS) – budgeted cost of work scheduled to date
• EV (Earned Value / BCWP) – budgeted cost of work actually performed
• AC (Actual Cost / ACWP) – actual cost of the work performed

Schedule Variance (SV): how far ahead/behind schedule the project is, in cost terms:

SV > 0 (SPI > 1) → ahead of schedule; SV < 0 → behind schedule.

Cost Variance (CV): whether the work is under or over budget:

CV > 0 (CPI > 1) → under budget; CV < 0 → over budget.

Example: PV = 100k, EV = 90k, AC = 110k → SV = −10k (behind schedule), CV = −20k (over budget).

Project scheduling is the process of converting the project plan into a calendar-based timetable — listing the activities, estimating their durations, establishing dependencies, allocating resources, and assigning start and finish dates to each task so the project can be completed within the deadline. It builds on the work breakdown structure and network analysis (CPM/PERT).

Gantt chart: A Gantt chart is a horizontal bar chart that displays the project schedule against a time axis. Each activity is a horizontal bar whose position shows start/finish dates and whose length shows duration.

Uses:

• Shows all tasks, their durations and the overall timeline at a glance
• Depicts dependencies and overlaps between activities
• Marks milestones and current progress (shaded bars)
• Helps with resource allocation and tracking actual vs planned progress
• Easy to understand for stakeholders and useful for monitoring and control

Its limitation is that it does not show task interdependencies as clearly as a network diagram for large projects.

Software Configuration Management (SCM) is the discipline of systematically managing changes to software artifacts (code, documents, requirements, designs, test cases) throughout the development lifecycle, so that the integrity and traceability of the product are maintained. Key activities include:

1. Configuration Identification – identify and label configuration items (CIs) and baselines.
2. Version / Change Control – control how changes are requested, evaluated, approved and applied (via a Change Control Board and version control tools).
3. Configuration Status Accounting – record and report the state of CIs and change requests.
4. Configuration Audit – verify that the product matches its configuration records and requirements.

Importance:

• Prevents confusion from uncontrolled, conflicting changes
• Maintains a single source of truth and reproducible baselines
• Enables multiple developers to work concurrently without overwriting each other
• Provides traceability and the ability to roll back to a previous stable version
• Improves quality, reduces errors, and supports auditing and release management.

When software/services are acquired from an external supplier, the contract defines how the supplier is paid and who bears the risk. The main types are:

1. Fixed-Price Contract – the supplier agrees to deliver the product for a single, agreed price regardless of actual cost. Low risk to the buyer; high risk to the supplier. Requires well-defined, stable requirements.

2. Cost-Plus (Cost-Reimbursable) Contract – the buyer pays the supplier's actual costs plus a fee (fixed fee or a percentage). Suitable when requirements are unclear; risk lies mainly with the buyer.

3. Time-and-Materials (T&M) Contract – payment is based on time spent (labour at agreed rates) plus materials used. Flexible; suited to small or evolving jobs where the scope is hard to fix in advance. Risk is shared.

Incentive variants (e.g., fixed-price-incentive, cost-plus-incentive-fee) add bonuses for meeting cost/schedule targets.