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

Risk Management in Software Projects

Risk is any uncertain event or condition that, if it occurs, has a negative (or positive) effect on a project's objectives (cost, schedule, scope, quality). Risk management is the systematic process of identifying, analysing, planning for and controlling these uncertainties so that their impact is minimised and the project's chances of success are maximised.

Risk Management Framework

1. Risk Identification — Recognising and listing the risks that may threaten the project. Techniques include checklists, brainstorming, reviewing past projects, and decomposition of the WBS. Risks are grouped into categories such as project risks (schedule, staffing, resources), product/technical risks (design, implementation, interfacing) and business risks (market, budget, management).

2. Risk Assessment (Analysis) — Estimating the likelihood (probability, $P$) of each risk and its impact (loss, $L$) if it occurs. The two are combined into a Risk Exposure:

Risks are then ranked (e.g. in a probability–impact matrix) so that attention is focused on the most significant ones.

3. Risk Planning (Planning for Risk) — Deciding the response for each prioritised risk:

   • Avoidance (change the plan to remove the risk),
   • Reduction/Mitigation (lower probability or impact),
   • Transfer (e.g. insurance, outsourcing),
   • Acceptance/Contingency (prepare a fallback plan). Contingency plans and reserves are documented.

4. Risk Control (Monitoring) — Continuously tracking identified risks, watching for trigger conditions, executing contingency plans, and re-running the cycle as new risks appear. This is an ongoing activity throughout the project life cycle.

Evaluating Risks to the Schedule using PERT and Z-values

PERT (Program Evaluation and Review Technique) treats activity durations as random variables. For each activity three estimates are taken — optimistic ($a$), most likely ($m$) and pessimistic ($b$) — and the expected duration and variance are:

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

The probability of finishing by a target date $T_s$ is found from the standard normal Z-value:

The area under the standard normal curve up to $Z$ (read from a Z-table) gives the probability of completing on or before $T_s$.

Example: If the critical path has $T_e = 30$ days and $\sigma_T = 4$ days, the probability of finishing within $T_s = 34$ days is:

A negative or low Z indicates a high schedule risk, prompting mitigation such as adding resources or reducing scope.

Project Monitoring and Control

Project monitoring is the continuous collection of data on actual progress (effort, cost, time, deliverables) and comparing it against the plan. Project control is the corrective action taken when monitoring shows that actuals deviate from the plan, bringing the project back on track. Together they form a feedback loop: plan → measure actuals → compare → take corrective action → re-plan.

Monitoring tracks time, cost and scope/quality, while control adjusts schedules, reallocates resources, or revises plans to keep the project within its constraints.

Earned Value Analysis (EVA)

EVA integrates scope, schedule and cost to measure project performance objectively. It is based on three key values:

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

Variances

Interpretation: a positive SV means ahead of schedule, negative means behind; a positive CV means under budget, negative means over budget. Performance indices are $SPI = BCWP/BCWS$ and $CPI = BCWP/ACWP$ (values $\ge 1$ are good).

Example

A project plans 10 tasks of $1,000 each (total budget $10,000) over 10 weeks. After 5 weeks:

• Planned: 5 tasks done → BCWS = $5,000
• Actually completed: 4 tasks → BCWP = 4 × $1,000 = $4,000
• Actual spend so far: ACWP = $4,500

Then:

Both indices are below 1, so the project is behind schedule and over budget, signalling the need for corrective control action.

Project Planning

Project planning is the management activity of defining what must be done, how, by whom, when and at what cost to achieve the project's objectives. It produces the roadmap (schedule, budget, resource plan and risk plan) that guides execution and control. Planning is iterative — plans are refined as the project progresses and more information becomes available.

Steps in Stepwise Project Planning

The classic Stepwise framework (Hughes & Cotterell) gives ten steps:

0. Select the project — confirm it is worth doing (feasibility/business case).
1. Identify project scope and objectives — define goals, deliverables and success criteria, and identify stakeholders.
2. Identify project infrastructure — relationship to other projects, installation standards, methods and tools.
3. Analyse project characteristics — distinguish objective-driven vs product-driven, assess risks, choose a suitable process model (e.g. waterfall, incremental, agile).
4. Identify project products and activities — build the Work Breakdown Structure (WBS), list products, and derive the activities to create them.
5. Estimate effort for each activity — using techniques such as expert judgement, function points or COCOMO.
6. Identify activity risks — assess risks per activity and plan responses.
7. Allocate resources — assign staff and other resources to activities, considering availability.
8. Review/publicise the plan — get sign-off from stakeholders and management.
9. Execute the plan / Lower levels of planning — carry out the work, monitor, and re-plan detail for the next stage (steps 5–8 repeat for each stage).

Contents of a Software Project Management Plan (SPMP)

Following the IEEE 1058 standard, an SPMP typically contains:

1. Introduction / Overview — project summary, objectives, scope, deliverables, assumptions and constraints.
2. Project Organisation — organisational structure, roles, responsibilities and external interfaces.
3. Managerial Process Plans — start-up plan (estimation, staffing, resource acquisition), work plan, control plan and risk management plan.
4. Technical Process Plans — process model, methods, tools and techniques, infrastructure, and product acceptance plan.
5. Supporting Process Plans — configuration management, verification & validation, quality assurance, documentation, reviews and audits.
6. Schedule and Budget — WBS, activity dependencies, milestones, Gantt/network charts, and cost estimates.
7. Additional Plans — security, training, and maintenance, as required.

Software Quality

Software quality is the degree to which a software product meets its specified requirements and the implicit expectations of its users — i.e. its fitness for purpose, conformance to requirements, and freedom from defects.

ISO 9126 Quality Attributes

ISO 9126 defines six high-level quality characteristics:

• Functionality — does the software provide the required functions? (suitability, accuracy, interoperability, security, compliance)
• Reliability — can it maintain performance under stated conditions? (maturity, fault tolerance, recoverability)
• Usability — how easy is it to learn and use? (understandability, learnability, operability, attractiveness)
• Efficiency — performance relative to resources used? (time behaviour, resource utilisation)
• Maintainability — how easily can it be modified/corrected? (analysability, changeability, stability, testability)
• Portability — how easily can it be transferred to another environment? (adaptability, installability, co-existence, replaceability)

Top-Down vs Bottom-Up Estimation

Summary: Top-down works from the whole to the parts and is useful early on, whereas bottom-up builds from the parts to the whole and is more accurate when detailed task information exists. In practice both are often combined to cross-check estimates.

Team Structures in Software Development

The way a development team is organised affects communication, control and productivity. Common structures are:

1. Democratic / Egoless (Decentralised-Democratic) Team — No fixed leader; all members participate in decisions, review one another's work and rotate responsibilities. Advantages: high morale, good for complex/research problems, fewer single points of failure. Disadvantages: heavy communication overhead, hard to scale, decisions can be slow.

2. Chief Programmer Team (Centralised-Controlled) — A senior chief programmer makes all key technical decisions; supported by a backup programmer, a librarian and other specialists. Advantages: fast decisions, good for well-understood problems and small teams. Disadvantages: depends heavily on one person; lower morale; chief can become a bottleneck.

3. Mixed-Control (Controlled-Decentralised) Team — A hybrid: a senior leader handles high-level decisions while small sub-groups work democratically. Combines the speed of centralised control with the participation of democratic teams; suits medium-to-large projects.

4. Hierarchical / Project (Chief) Organisation — Traditional pyramid with project manager → team leaders → developers; clear authority lines, suited to large projects.

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

Work Breakdown Structure (WBS)

A Work Breakdown Structure is a hierarchical, deliverable-oriented decomposition of the total work of a project into smaller, manageable components. The top level is the whole project; each level below breaks the work into sub-deliverables, down to the lowest level of work packages — tasks small enough to estimate, schedule, assign and control.

Purposes / Benefits:

• Ensures all work is identified (nothing is missed or double-counted).
• Forms the basis for estimation, scheduling, costing and resource allocation.
• Clarifies responsibility for each work package.
• Improves monitoring and control.

Example — WBS for a Library Management System:

1. Library Management System
   1.1 Requirements Analysis
       1.1.1 Gather requirements
       1.1.2 Prepare SRS document
   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

Each lowest-level item (e.g. 1.3.1 Book module) is a work package that can be estimated and assigned to a team member.

Techniques for Monitoring Software Project Progress

Monitoring tracks actual progress against the plan. Common techniques are:

1. Gantt Charts — Bar chart showing planned vs actual start/finish of each activity along a timeline; quick visual of schedule status and slippage.

2. Milestone / Slip Charts — Track whether key checkpoints (milestones) are met on time; slip charts plot how forecast milestone dates change over reporting periods.

3. Earned Value Analysis (EVA) — Quantitative method using BCWS, BCWP and ACWP to compute schedule and cost variances ($SV = BCWP-BCWS$, $CV = BCWP-ACWP$) and performance indices.

4. Progress / Status Reports — Regular written or verbal reports and timesheets from team members on tasks completed, effort spent and problems faced.

5. Checkpoints, Reviews and Walkthroughs — Periodic technical reviews and meetings to verify deliverables and quality.

6. Cost–Schedule (Budget) Tracking — Comparing actual cost and effort against budgeted figures over time.

7. PERT/CPM Network Updates — Re-evaluating the critical path and float as activities complete to forecast the finish date.

These techniques provide the data needed to detect deviations early and trigger corrective control action.

Resource Allocation

Resource allocation is the process of assigning available resources — staff, hardware, software, money and time — to project activities in the most effective way, so that the schedule can be met without over- or under-utilising any resource. After scheduling activities, the manager builds a resource histogram (resource usage over time) and adjusts the plan to remove conflicts and peaks.

Resource Smoothing

Resource smoothing adjusts activities within their available float (slack) so that resource usage is made as even as possible without extending the project's end date. The project duration (and critical path) stays fixed; only non-critical activities are shifted within their float to flatten peaks and troughs in the resource histogram. (Time-constrained: deadline is the priority.)

Resource Leveling

Resource leveling is applied when resources are limited or fixed. Activities are delayed (even beyond their float) so that resource demand never exceeds the available supply. Because critical activities may be moved, the project end date can be extended. (Resource-constrained: resource availability is the priority.)

Key Difference

Change Management and Change Control

Change management is the structured process of handling requests to alter a software product's requirements, design, code or documentation during the project, so that changes are evaluated, approved and implemented in a controlled way rather than being made ad hoc. Uncontrolled change leads to scope creep, schedule slippage and quality problems.

Change control is the formal procedural part of change management that governs how a change request flows through the project. A typical change-control procedure:

1. Submit Change Request (CR) — a stakeholder logs a request describing the proposed change.
2. Evaluate / Impact Analysis — assess effect on scope, cost, schedule, quality and risk.
3. Review by Change Control Board (CCB) — the CCB approves, rejects or defers the request.
4. Implement — if approved, update the affected baselines (requirements, design, code).
5. Verify and Close — test the change, update the version, and record it in the change log.

Role of Configuration Management: Change control works hand-in-hand with Software Configuration Management (SCM), which baselines and version-controls all work products so that approved changes are tracked and the product's integrity is maintained. Benefits: prevents scope creep, maintains traceability, keeps cost/schedule under control and preserves product quality.

Agile Project Management

Agile project management is an iterative, incremental approach to managing software projects that emphasises flexibility, continuous customer collaboration and the rapid delivery of working software. Instead of one long sequence, work is delivered in short iterations (sprints), typically 1–4 weeks, each producing a potentially shippable increment.

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 and incremental delivery; frequent releases.
• Embraces changing requirements, even late in development.
• Close, daily collaboration between the team and the customer.
• Self-organising, cross-functional teams.
• Continuous feedback through reviews and retrospectives.

Common Frameworks: Scrum (roles: Product Owner, Scrum Master, Development Team; artefacts: product backlog, sprint backlog, increment; events: sprint planning, daily stand-up, review, retrospective), Kanban, and Extreme Programming (XP).

Advantages: faster delivery, adaptability to change, higher customer satisfaction, early detection of problems. Limitations: less suited to fixed-scope/contract projects, needs experienced teams and active customer involvement, light documentation.

Stakeholder Analysis

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

Stakeholder analysis is the process of identifying the project's stakeholders, assessing their interests, expectations, influence and attitude (positive/neutral/negative), and planning how to engage and communicate with each so as to gain their support and manage their concerns. A common tool is the power–interest grid, which classifies stakeholders by their power/influence and level of interest:

• High power, high interest → Manage closely
• High power, low interest → Keep satisfied
• Low power, high interest → Keep informed
• Low power, low interest → Monitor

Why It Is Important

1. Identifies requirements and expectations early, reducing misunderstandings.
2. Secures support and resources from influential stakeholders.
3. Manages opposition/conflicts by addressing concerns of negative stakeholders.
4. Guides communication planning — the right information to the right people.
5. Reduces risk of project failure caused by neglected or hostile stakeholders, increasing the chance of success.