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

Network Planning Models in Project Management

Network planning models are graphical/mathematical techniques that represent a project as a network of activities and events, used to plan, schedule and control the project. They show the logical sequence and dependencies of activities, help compute project duration, and identify which activities are critical. The two most widely used models are CPM and PERT.

Critical Path Method (CPM)

• A deterministic technique that assumes activity durations are known and fixed.
• Activity-oriented; primarily used for projects (e.g. construction, maintenance) where durations can be estimated reliably from experience.
• Allows time-cost trade-off (crashing) to shorten the project.
• The critical path is the longest path through the network; it determines the minimum project duration. Activities on it have zero float (slack).

Program Evaluation and Review Technique (PERT)

• A probabilistic technique used when activity durations are uncertain (e.g. research/software projects).
• Uses three time estimates per activity: optimistic ($a$), most likely ($m$), pessimistic ($b$).
• Expected duration:

• Event-oriented; focuses on meeting deadlines under uncertainty.

Computing the Critical Path (Example)

Consider activities (predecessor in brackets) with durations:

Forward pass (Earliest Start ES / Earliest Finish 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=14

Project duration = 14 days.

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

• F: LF=14, 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

Float = LS − ES: A=0, B=0, D=0, F=0 (critical); C=5, E=1.

Critical Path = A → B → D → F, length 14 days. Any delay on these activities delays the whole project.

Conclusion: Network models let managers compute project duration, find the critical path, identify float for non-critical activities (resource flexibility), and use PERT to assess the probability of meeting deadlines under uncertainty.

Risk Management in Software Projects

Risk is the possibility of an undesirable outcome — an event whose occurrence is uncertain but, if it occurs, has a negative impact on project objectives (cost, schedule, quality). Risk management is the systematic process of identifying, analysing, planning for and controlling risks throughout the project so their probability or impact is reduced.

Risk Management Framework

1. Risk Identification — Find potential risks before they become problems. Techniques: checklists, brainstorming, lessons learned, decomposition. Categories include project risks (schedule, resources), product risks (technical/quality), and business risks (market, organizational).

2. Risk Assessment (Analysis) — Estimate each risk's probability (likelihood) and impact, then prioritise. Risk Exposure = Probability × Impact. Risks are ranked (e.g. high/medium/low) so attention goes to the most serious ones.

3. Risk Planning — Decide a response for each significant risk:

• Avoidance – change the plan to remove the risk.
• Mitigation/Reduction – reduce probability or impact.
• Transfer – shift to a third party (insurance, outsourcing).
• Acceptance/Contingency – accept and prepare a contingency plan.

4. Risk Monitoring and Control — Continuously track identified risks, watch for risk triggers, reassess, and execute contingency plans. The risk register is updated regularly.

Evaluating Schedule Risk with PERT and Z-values

PERT models each activity duration with three estimates and gives expected time $t_e = \frac{a+4m+b}{6}$ and variance $\sigma^2 = \left(\frac{b-a}{6}\right)^2$.

For the critical path, the expected project duration is $T_e = \sum t_e$ and the variance is $\sigma_T^2 = \sum \sigma^2$ (summed over critical activities), so $\sigma_T = \sqrt{\sigma_T^2}$.

The probability of completing the project by a target date $T_s$ is found using the standard normal Z-value:

The probability is then read from the standard normal table as $P(Z)$.

Example: If $T_e = 50$ days, $\sigma_T = 4$ days, and the target $T_s = 54$ days:

So there is about an 84% chance of finishing within 54 days. A negative Z means the target is earlier than the expected time, giving a probability below 50%, signalling high schedule risk.

Conclusion: PERT/Z-value analysis quantifies schedule risk, letting managers state the confidence of meeting a deadline and decide whether to add buffer time or take corrective action.

Project Monitoring and Control

Project monitoring is the ongoing collection and review of data on actual progress (work done, time, cost) against the plan. Project control uses this information to take corrective action so the project stays on track for its time, cost and quality goals. The cycle is: plan → monitor actual → compare with plan → identify variance → take corrective action → re-plan.

Earned Value Analysis (EVA)

EVA integrates scope, schedule and cost to measure performance objectively using three core values:

• BCWS (Budgeted Cost of Work Scheduled) = Planned Value (PV) — budgeted cost of work planned to be done by a given date.
• BCWP (Budgeted Cost of Work Performed) = Earned Value (EV) — budgeted cost of work actually completed.
• ACWP (Actual Cost of Work Performed) = Actual Cost (AC) — money actually spent on the completed work.

Variances:

• $SV > 0$ → ahead of schedule; $SV < 0$ → behind schedule.
• $CV > 0$ → under budget; $CV < 0$ → over budget.

Performance indices: $SPI = \dfrac{BCWP}{BCWS}$, $CPI = \dfrac{BCWP}{ACWP}$ (≥ 1 is good).

Worked Example

A project has a total budget of $100{,}000$. By the end of week 5, the plan said 40% of work should be complete; in fact 30% is complete, and $35{,}000$ has been spent.

• $BCWS = 40\% \times 100{,}000 = 40{,}000$
• $BCWP = 30\% \times 100{,}000 = 30{,}000$
• $ACWP = 35{,}000$

Then:

Interpretation: Both SV and CV are negative and both indices are below 1, so the project is behind schedule and over budget, requiring corrective action (re-planning, adding resources, or scope adjustment).

Conclusion: EVA gives the manager an early, quantitative warning of cost/schedule problems and supports forecasting the final cost (EAC) and completion date.

Software Quality and ISO 9126 Attributes

Software quality is the degree to which a software product meets its specified requirements and the implicit needs/expectations of its users — i.e. conformance to requirements and fitness for purpose. It covers both correctness and characteristics like reliability, usability and maintainability.

ISO 9126 Quality Model (six characteristics)

1. Functionality — Does it provide the required functions correctly? (suitability, accuracy, interoperability, security, compliance).
2. Reliability — Ability to maintain performance under stated conditions (maturity, fault tolerance, recoverability).
3. Usability — Effort needed to learn and operate the software (understandability, learnability, operability, attractiveness).
4. Efficiency — Performance relative to resources used (time behaviour, resource utilisation).
5. Maintainability — Ease of modifying the software (analysability, changeability, stability, testability).
6. Portability — Ability to transfer to another environment (adaptability, installability, co-existence, replaceability).

Each characteristic is broken into measurable sub-characteristics, allowing quality to be assessed objectively.

Bottom-up vs Top-down Estimation

Top-down estimation derives an overall estimate for the whole project first (from analogy with past projects or a parametric model such as COCOMO), then distributes it among components. Bottom-up estimation estimates each individual task/work package separately, then sums them up to get the total.

Summary: Top-down is quick and useful for initial feasibility/budgeting but less accurate; bottom-up is more accurate and accountable but needs detailed information and more effort. In practice both are often used and reconciled.

Team Structures in Software Development

Team structure defines how members are organised, how authority and communication flow, and who makes decisions. Common structures are:

1. Democratic / Egoless (Decentralized-Control) Team

• No fixed leader; decisions made by group consensus; goals are shared.
• Work and review are shared among members.
• Advantages: high morale, knowledge sharing, good for complex/research problems and long projects.
• Disadvantages: much communication overhead; not suitable for very large teams.

2. Chief Programmer (Centralized-Control) Team

• A senior chief programmer makes all key technical decisions and delegates tasks; supported by a backup programmer, librarian and specialists.
• Advantages: fast decisions, less communication, good for simple, well-understood projects.
• Disadvantages: heavy dependence on one person; low morale; single point of failure.

3. Mixed / Controlled-Decentralized Team

• Combines the two: a senior leader controls overall direction, while sub-teams work democratically internally.
• Balances efficiency and morale; suitable for large projects split into modules.

4. Hierarchical / Matrix structures are also used in large organisations, where members report both to a project manager and a functional manager.

Choice depends on project size, complexity, problem difficulty and team experience.

Work Breakdown Structure (WBS)

A Work Breakdown Structure (WBS) is a hierarchical, deliverable-oriented decomposition of the total project work into smaller, manageable components. Each descending level represents an increasingly detailed definition of the work, ending in work packages — the lowest level that can be estimated, scheduled, assigned and tracked.

Purpose / benefits:

• Ensures all work is identified (nothing missed, no overlap).
• Forms the basis for estimating effort/cost, scheduling, and assigning responsibility.
• Improves monitoring and control.

Example — WBS for a Library Management System:

1. Library Management System
   1.1 Requirements
       1.1.1 Gather requirements
       1.1.2 Prepare SRS
   1.2 Design
       1.2.1 Database design
       1.2.2 UI design
   1.3 Implementation
       1.3.1 Book module
       1.3.2 Member module
       1.3.3 Issue/Return module
   1.4 Testing
       1.4.1 Unit testing
       1.4.2 System testing
   1.5 Deployment & Documentation

Here the project is split into phases, each phase into deliverables, and each deliverable into work packages that can be assigned and estimated.

Techniques for Monitoring Software Project Progress

Monitoring compares actual progress with the plan to detect deviations early. Common techniques include:

1. Gantt Charts — Bar chart of activities against a time scale; planned vs actual bars show which tasks are ahead or behind.
2. Milestone / Slip charts — Track achievement of key milestones; a slip chart shows how planned dates have moved over time.
3. Network diagrams (PERT/CPM) with critical-path tracking — Recompute the critical path to see the effect of delays on completion.
4. Earned Value Analysis (EVA) — Uses BCWS, BCWP and ACWP to compute schedule variance ($SV = BCWP - BCWS$) and cost variance ($CV = BCWP - ACWP$) for an objective progress measure.
5. Progress / Status reports and meetings — Regular timesheets, status reports and review meetings to collect actuals.
6. Cost-schedule (S-curve) graphs — Cumulative cost/effort plotted over time; comparing planned and actual curves reveals trends.
7. Checkpoints / reviews and metrics — Defined checkpoints, code reviews and metrics (defects found, modules completed) to gauge quality and quantity of work.

These techniques together give the manager visibility of time, cost and quality so corrective action can be taken promptly.

Resource Allocation, Smoothing and Leveling

Resource allocation is the process of assigning the available resources (people, equipment, money, materials) to project activities over time so that the project can be completed efficiently. Because resources are limited, allocation must balance availability against the schedule.

After the initial schedule, the resource histogram often shows uneven demand (peaks and valleys) or demand exceeding capacity. Two techniques smooth this out:

1. Resource Smoothing (Time-constrained)

• The project end date is fixed and must not change.
• Activities are rescheduled within their available float (slack) to even out resource usage and remove peaks.
• The critical path and project duration remain unchanged; only non-critical activities are shifted.
• Goal: reduce peak demand and idle time without delaying the project.

2. Resource Leveling (Resource-constrained)

• The resource availability is fixed (a hard limit) and must not be exceeded.
• Activities are delayed (even beyond float) until enough resources are free.
• This may extend the project duration because over-allocation is removed by spreading work out.
• Goal: keep resource usage within available capacity.

Key difference: Smoothing keeps the deadline fixed and adjusts within float (time-constrained); leveling keeps resource limits fixed and may push the deadline out (resource-constrained).

Change Management and Change Control

Change management is the overall process of handling changes to project scope, requirements, design or schedule in a controlled way, so that changes are recorded, evaluated and approved before being implemented. Software requirements inevitably evolve, and uncontrolled changes cause scope creep, cost/schedule overruns and quality problems; change management keeps this under control.

Change control is the formal procedure within change management for requesting, reviewing, approving/rejecting and tracking individual changes. A typical change-control process is:

1. Submit a Change Request (CR) documenting the proposed change.
2. Impact analysis — assess effect on cost, schedule, scope, quality and risk.
3. Review by a Change Control Board (CCB) which approves, rejects or defers.
4. Implement the approved change and update affected work products and baselines.
5. Verify and record the change; update the configuration/version (configuration management).

Benefits: prevents unauthorized changes, maintains traceability, keeps baselines consistent, and ensures stakeholders agree to the cost/schedule impact before work proceeds. Change control is closely tied to Software Configuration Management (SCM) and version control.

Agile Project Management

Agile project management is an iterative, incremental approach to delivering software in which requirements and solutions evolve through collaboration between self-organising, cross-functional teams. Instead of one big upfront plan (as in Waterfall), work is delivered in short iterations (sprints), typically 1–4 weeks, each producing a potentially shippable increment.

Core values (Agile Manifesto):

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Key characteristics:

• Iterative & incremental delivery with frequent customer feedback.
• Embracing change even late in development.
• Continuous communication (e.g. daily stand-ups) and close customer involvement.
• Self-organising teams and adaptive planning.
• Continuous integration and testing.

Common frameworks: Scrum (roles: Product Owner, Scrum Master, Team; artefacts: product/sprint backlog; events: sprint, daily scrum, review, retrospective), Extreme Programming (XP), and Kanban.

Advantages: flexibility, early and regular delivery of value, high customer satisfaction, early detection of problems. Limitations: less predictability in cost/schedule, needs experienced teams and strong customer engagement, lighter documentation.

Stakeholder Analysis

Stakeholders are all the individuals, groups or organisations who have an interest in, can affect, or are affected by the project — e.g. customers/clients, users, the project team, sponsors, managers, suppliers and regulators.

Stakeholder analysis is the process of identifying the project's stakeholders, understanding their interests, expectations, influence and attitude (supportive/opposed), and planning how to communicate with and manage each of them. A common tool is the power/interest grid, which classifies stakeholders by their level of power (influence) and interest:

Why it is important in project management:

• Ensures the right requirements and expectations are captured early.
• Helps secure support and resources, and identify and manage opposition.
• Guides a tailored communication and engagement strategy for each group.
• Reduces risk of conflict, rework and project failure caused by neglected or hostile stakeholders.
• Improves the chance of project acceptance and success by aligning the project with stakeholder needs.