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

People Management in Software Projects

Software is built by people, and software project management is therefore largely a people management problem. Because productivity between individual programmers can vary by an order of magnitude, the success of a project depends heavily on selecting, motivating, organising and retaining capable staff.

Key concerns of people management

According to Mayer and Sutton, four critical factors are:

1. Consistency — all team members should be treated fairly and comparably.
2. Respect — recognising different skills and respecting individual contributions.
3. Inclusion — listening to and considering everyone's views.
4. Honesty — being open about what is going well and what is going badly.

Organizational Behaviour

Organizational behaviour studies how people act within an organisation. A manager must understand group dynamics, communication patterns, the informal organisation (who actually talks to whom), and how organisational culture and structure (functional, project-based, or matrix) affect the way work gets done.

Motivation Theories

Motivating staff means organising work and its environment to encourage people to work effectively.

• Maslow's Hierarchy of Needs — needs are satisfied in order: physiological → safety → social (belonging) → esteem → self-actualisation. Lower needs must be met before higher ones motivate.
• Herzberg's Two-Factor Theory — hygiene factors (salary, working conditions, job security) prevent dissatisfaction but do not motivate; motivators (achievement, recognition, responsibility, growth) produce real satisfaction.
• People are also classified by what drives them: task-oriented (motivated by the work itself), self-oriented (motivated by personal success), and interaction-oriented (motivated by colleagues).

Team Structures (Team Organisation)

The way a team is organised affects decision-making and communication:

Group cohesion improves quality, knowledge sharing and productivity. Effective communication (size of group, status, structure and physical workspace) is essential.

Challenges of Managing People

• Wide variation in individual productivity and skill.
• High staff turnover and the cost of losing knowledge (Brooks' Law: adding people to a late project makes it later).
• Communication overhead grows as $n(n-1)/2$ with team size $n$.
• Maintaining motivation under schedule pressure and deadlines.
• Balancing technical and interpersonal conflicts.
• Coordinating geographically distributed or virtual teams.

Conclusion

Good people management — selecting the right people, motivating them, choosing an appropriate team structure, and fostering communication and group cohesion — is the single most important determinant of software project success.

Software Cost Estimation and the COCOMO Model

Software Cost Estimation

Software cost estimation is the process of predicting the effort (person-months), time/schedule (months) and ultimately the cost required to develop a software system. It is done early, when little is known, and is refined as the project progresses. Accurate estimation is essential for bidding, budgeting, staffing and scheduling.

COCOMO (COnstructive COst MOdel)

Proposed by Barry Boehm (1981), COCOMO is an algorithmic, empirical model that estimates effort and time as a function of program size measured in KLOC (thousands of delivered lines of code). It classifies projects into three modes:

• Organic — small teams, well-understood, familiar problems.
• Semi-detached — medium size, mixed experience.
• Embedded — large, tightly constrained, complex (real-time/hardware) projects.

---

1. Basic COCOMO

Gives a rough estimate using size only:

$$E = a \times (KLOC)^b \quad\text{(person-months)}$$ $$D = c \times (E)^d \quad\text{(months)}$$

where $E$ = effort, $D$ = development time. Staff size $= E / D$.

Example — Organic project of 32 KLOC:

$$E = 2.4 \times 32^{1.05} = 2.4 \times 37.9 \approx 91 \text{ person-months}$$ $$D = 2.5 \times 91^{0.38} = 2.5 \times 5.55 \approx 13.9 \text{ months}$$ $$\text{Staff} = 91 / 13.9 \approx 6.5 \approx 7 \text{ persons}$$

---

2. Intermediate COCOMO

Refines the basic estimate by multiplying by an Effort Adjustment Factor (EAF), the product of 15 cost drivers (product, hardware, personnel and project attributes), each rated very low → extra high:

$$E = a \times (KLOC)^b \times EAF$$

If the nominal EAF = 1.0; values < 1 reduce effort, > 1 increase it.

---

3. Detailed (Complete) COCOMO

Incorporates all features of intermediate COCOMO and applies the cost drivers at each phase of the software life cycle (planning/requirements, design, coding, integration & test). This phase-sensitive estimation gives the most accurate result because different cost drivers have different impact in different phases.

Conclusion

COCOMO moves from a quick size-only estimate (basic) → cost-driver-adjusted estimate (intermediate) → phase-wise adjusted estimate (detailed), trading effort for accuracy.

Network Planning Models in Project Management

Network planning models represent a project as a directed graph of activities (tasks) and events (milestones), showing dependencies and durations. They are used to schedule activities, identify critical tasks, and compute the minimum project duration. The two principal techniques are CPM and PERT.

Critical Path Method (CPM)

• A deterministic technique that uses a single, known duration for each activity.
• Activity-oriented; emphasises time–cost trade-off (crashing) to shorten duration at minimum cost.
• The critical path is the longest path through the network; it determines the shortest possible project duration. Activities on it have zero slack/float.

Program Evaluation and Review Technique (PERT)

• A probabilistic technique used when durations are uncertain (e.g. R&D projects).
• Event-oriented; uses three-point estimation for each activity:

$$t_e = \frac{t_o + 4t_m + t_p}{6}, \qquad \sigma = \frac{t_p - t_o}{6}$$

where $t_o$ = optimistic, $t_m$ = most likely, $t_p$ = pessimistic. Project variance = sum of activity variances on the critical path.

Computing the Critical Path (Example)

Consider activities with durations (weeks):

Forward pass (Earliest Start ES / Earliest Finish EF), EF = ES + duration:

• A: ES=0, EF=3
• B: ES=3, EF=7 ; C: ES=3, EF=5
• D: ES=7, EF=12 ; E: ES=5, EF=11
• F: ES = max(EF_D, EF_E) = max(12,11) = 12, EF=15

Project duration = 15 weeks.

Backward pass (Latest Finish LF / Latest Start LS), LS = LF − duration:

• F: LF=15, LS=12
• D: LF=12, LS=7 ; E: LF=12, LS=6
• B: LF=7, LS=3 ; C: LF=10, LS=8
• A: LF=3, LS=0

Slack = LS − ES. Activities with zero slack: A, B, D, F.

Critical Path

$$A \rightarrow B \rightarrow D \rightarrow F = 3+4+5+3 = 15 \text{ weeks}$$

Any delay on these activities delays the whole project; activities C and E have float and can slip without affecting the deadline.

Basic COCOMO Model

Basic COCOMO (Boehm, 1981) is the simplest level of the model. It estimates software development effort and time as a function of program size in KLOC (thousands of delivered lines of code) using only the project mode.

Effort equation:

$$E = a \times (KLOC)^{b} \quad \text{(person-months)}$$

Development time: $D = c \times E^{d}$ (months), and average staff $= E/D$.

The constants depend on the project mode:

Example: For an organic project of 8 KLOC, $E = 2.4 \times 8^{1.05} \approx 21$ person-months.

Basic COCOMO is quick and good for early rough estimates, but ignores cost drivers such as personnel capability and tool quality, so it is the least accurate level.

Function Point Analysis (FPA)

Function Point Analysis (Albrecht, 1979) measures the size/functionality of software from the user's point of view, independent of programming language or technology — unlike LOC, which is language-dependent.

Five Function Types (External user-visible components)

1. External Inputs (EI) — data entered by the user.
2. External Outputs (EO) — reports, messages output to the user.
3. External Inquiries (EQ) — interactive query/response.
4. Internal Logical Files (ILF) — internally maintained data stores.
5. External Interface Files (EIF) — data shared with other systems.

Computation Steps

1. Count each function type and classify its complexity as simple, average, or complex, assigning a weight.
2. Sum to get the Unadjusted Function Point (UFP):

$$UFP = \sum (\text{count} \times \text{weight})$$

3. Compute the Value Adjustment Factor (VAF) from 14 General System Characteristics (each rated 0–5):

$$VAF = 0.65 + 0.01 \times \sum F_i$$

4. Final Function Points:

$$FP = UFP \times VAF$$

Function points can then be converted to effort or to LOC using a language-specific factor. FPA is useful for early estimation and for comparing productivity across projects.

Critical Path Method (CPM)

CPM is a deterministic network-planning technique that models a project as a network of activities with known, fixed durations to find the minimum time needed to complete the project and identify which activities are most time-critical.

The Critical Path

The critical path is the longest path (in total duration) from the start node to the end node of the activity network. Its length equals the shortest possible project duration. Activities on it have zero float (slack) — any delay in them delays the entire project.

How the critical path is determined

1. Draw the network of activities and their dependencies.
2. Forward pass — compute Earliest Start (ES) and Earliest Finish (EF) for every activity: $EF = ES + \text{duration}$, taking the maximum EF of predecessors as the next ES.
3. Backward pass — compute Latest Finish (LF) and Latest Start (LS): $LS = LF - \text{duration}$, taking the minimum LS of successors.
4. Compute float: $\text{Slack} = LS - ES = LF - EF$.
5. Critical path = the chain of activities with zero slack; equivalently, the longest path through the network.

CPM also supports time–cost trade-off (crashing) to shorten the project at the least extra cost.

PERT and Three-Point Estimation

PERT (Program Evaluation and Review Technique) is a probabilistic network-planning technique used when activity durations are uncertain (e.g. research or first-of-a-kind projects). It is event-oriented and computes the expected project duration and the probability of meeting a deadline.

Three-Point Estimation

For each activity, three time estimates are made:

• $t_o$ = optimistic time (everything goes well).
• $t_m$ = most likely time (normal conditions).
• $t_p$ = pessimistic time (things go wrong).

Assuming a Beta distribution, the expected (mean) duration is:

$$t_e = \frac{t_o + 4\,t_m + t_p}{6}$$

The standard deviation and variance of an activity:

$$\sigma = \frac{t_p - t_o}{6}, \qquad \sigma^2 = \left(\frac{t_p - t_o}{6}\right)^2$$

Using PERT

The $t_e$ values are used like CPM durations to find the critical path. The project variance is the sum of the variances of the critical-path activities, allowing computation (via the normal distribution / Z-score) of the probability of completing the project within a target time.

Example: if $t_o=2$, $t_m=4$, $t_p=12$, then $t_e = (2 + 16 + 12)/6 = 5$ and $\sigma = (12-2)/6 = 1.67$.

Risk and the Risk Management Process

What is Risk?

A risk is an uncertain event or condition that, if it occurs, has a negative effect on a project's objectives (cost, schedule, scope or quality). It has two key attributes: probability (likelihood of occurrence) and impact (severity of loss). Risk exposure = probability × impact. Common categories include project risks (schedule/resources), technical risks, and business risks.

Steps of the Risk Management Process

1. Risk Identification — list possible risks (technology, people, organisational, requirements, estimation risks) using checklists, brainstorming, and past experience.
2. Risk Analysis (Assessment) — for each risk, estimate its probability (low/medium/high) and impact/seriousness, and compute risk exposure to prioritise.
3. Risk Planning (Prioritisation & Response) — decide a strategy for each significant risk:
   • Avoidance — reduce the probability the risk arises.
   • Minimisation/Mitigation — reduce the impact if it occurs.
   • Contingency plans — prepare a plan to cope if it does occur.
   • (also transfer/acceptance.)
4. Risk Monitoring (Control) — continuously track identified risks, watch for new ones, and check whether the chosen strategies are working, repeating the cycle throughout the project.

Risk management is an iterative activity carried out for the whole project life cycle.

Earned Value Analysis (EVA)

Earned Value Analysis is a project-tracking technique that integrates scope, schedule and cost to measure project performance and progress objectively. It compares the work actually performed against the work planned and the cost incurred.

Three basic values

• PV / BCWS (Planned Value / Budgeted Cost of Work Scheduled) — budgeted cost of work planned to date.
• EV / BCWP (Earned Value / Budgeted Cost of Work Performed) — budgeted cost of work actually completed to date.
• AC / ACWP (Actual Cost / Actual Cost of Work Performed) — actual cost of the work completed.

Schedule Variance (SV)

$$SV = EV - PV \;=\; BCWP - BCWS$$

Measures whether the project is ahead of or behind schedule (in cost terms).

• $SV > 0$ → ahead of schedule; $SV < 0$ → behind schedule; $SV = 0$ → on schedule.

Cost Variance (CV)

$$CV = EV - AC \;=\; BCWP - ACWP$$

Measures whether the project is under or over budget.

• $CV > 0$ → under budget; $CV < 0$ → over budget; $CV = 0$ → on budget.

Performance indices

$$SPI = \frac{EV}{PV}, \qquad CPI = \frac{EV}{AC}$$

Values $\geq 1$ indicate good schedule/cost performance respectively. EVA gives early warning of cost and schedule overruns.

Project Scheduling and Gantt Charts

Project Scheduling

Project scheduling is the process of deciding how the work of a project is organised as separate tasks, when and how those tasks will be executed, and which resources (people, time, money) are allocated to each. It involves splitting work into activities, estimating each activity's duration, identifying dependencies, and assigning start/finish dates and resources so the project completes on time and within budget. The output is a project schedule, usually shown as activity networks (CPM/PERT) and bar charts.

Gantt Chart

A Gantt chart (bar chart) is a graphical tool that displays the project schedule as a set of horizontal bars against a calendar time axis.

• The vertical axis lists the activities/tasks; the horizontal axis represents time.
• Each bar shows an activity's start date, duration and finish date; bar length is proportional to duration.
• Milestones are marked as diamonds; dependencies can be shown with linking arrows; shaded portions show percentage complete.

Uses / Advantages

1. Shows at a glance which tasks run in parallel and which are sequential.
2. Helps allocate and track resources and staff assignments.
3. Allows easy progress monitoring by comparing planned vs actual bars.
4. Simple to read, so it is excellent for communicating the schedule to the team and stakeholders.

Its limitation is that, unlike a network diagram, it does not directly show the critical path or complex inter-task dependencies.

Software Configuration Management (SCM)

Definition

Software Configuration Management is the discipline of identifying, organising, controlling and tracking changes to the software artifacts (source code, documents, designs, test cases, etc.) — called configuration items — throughout the software life cycle, so that the integrity and traceability of the product are maintained.

Key Activities

1. Configuration Identification — identify and name the configuration items and establish baselines.
2. Change Control (Change Management) — manage change requests through a defined procedure / Change Control Board so changes are reviewed and approved.
3. Version (Release) Control — manage multiple versions/releases of items using tools (e.g. Git, SVN).
4. Configuration Status Accounting — record and report the state of items and changes.
5. Configuration Auditing — verify that the product matches its specification and that changes were done correctly.

Why SCM is important

• Prevents confusion and loss of work when many developers change the same files concurrently.
• Provides traceability and an audit trail of what changed, when, why and by whom.
• Enables rollback to a known-good baseline if a change introduces defects.
• Ensures correct versions/releases are built and delivered, supporting parallel development and maintenance.
• Improves overall quality, control and reproducibility of the software, especially as the product evolves.

Types of Contracts in Software Project Acquisition

When a software product or service is acquired (outsourced) from a supplier, the agreement is formalised in a contract. The type of contract determines how the buyer pays and who bears the risk. The main types are:

1. Fixed-Price (Lump-Sum) Contract

The supplier agrees to deliver the product for a fixed, agreed price regardless of actual cost.

• Buyer's risk: low (cost is known up front).
• Supplier's risk: high (must absorb cost overruns).
• Best when requirements are clear and stable.
• Variants: Firm Fixed Price (FFP), Fixed Price with Incentive Fee (FPIF), Fixed Price with Economic Price Adjustment (FP-EPA).

2. Cost-Reimbursable (Cost-Plus) Contract

The buyer pays the supplier's actual allowable costs plus a fee/profit.

• Buyer's risk: high (final cost is uncertain).
• Best when the scope is not well defined or likely to change.
• Variants: Cost Plus Fixed Fee (CPFF), Cost Plus Incentive Fee (CPIF), Cost Plus Award Fee (CPAF).

3. Time-and-Materials (Unit-Price) Contract

A hybrid: the buyer pays a fixed rate per unit of effort (e.g. per person-day) plus materials.

• Flexible; useful for staff augmentation or work that cannot be fully scoped in advance.
• Risk is shared; total cost grows with time, so it suits smaller or short-term engagements.

Summary

Choice depends on how well requirements are understood and how risk is to be allocated between buyer and supplier.