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

Project Monitoring and Control

Project monitoring is the continuous process of collecting data on a project's actual progress (effort spent, cost incurred, tasks completed) and comparing it against the plan. Project control uses that information to take corrective action (re-planning, re-scheduling, reallocating resources) so that the project meets its time, cost and quality targets.

The basic control loop is:

1. Set targets / baseline plan (schedule and budget).
2. Measure actual progress at review points.
3. Compare actual vs. planned.
4. Take corrective action if there is significant deviation.

Earned Value Analysis (EVA)

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

Variance formulas

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

Performance indices are often added:

Example

A project is planned to cost Rs 100,000 over 10 weeks (Rs 10,000/week, even effort). At the end of week 5:

• Work planned to be complete = 50% → BCWS = Rs 50,000
• Work actually complete = 40% → BCWP = Rs 40,000
• Actual money spent so far = ACWP = Rs 45,000

Then:

Interpretation: Both SV and CV are negative and the indices are below 1, so the project is behind schedule and over budget, signalling the manager to take corrective action.

Project Planning

Project planning is the management activity of deciding what has to be done, how it will be done, who will do it, when and at what cost, in order to achieve the project objectives. It produces schedules, budgets, resource and risk plans that act as a baseline for monitoring and control.

Stepwise Project Planning (Hughes & Cotterell)

The stepwise framework gives an ordered set of steps:

0. Select project – feasibility and scope of the project.
1. Identify project scope and objectives – establish goals, success criteria and stakeholders.
2. Identify project infrastructure – relationship to other projects, installation standards, methods and tools.
3. Analyse project characteristics – classify the project (e.g. data-oriented or control-oriented), choose a suitable life-cycle/process model.
4. Identify project products and activities – build the product breakdown structure, product flows and the list of activities (Work Breakdown Structure).
5. Estimate effort for each activity.
6. Identify activity risks – assess and plan responses for risks to each activity.
7. Allocate resources – assign staff and other resources; revise plan and schedule (e.g. via Gantt charts).
8. Review / publicise plan – obtain agreement from stakeholders. 9–10. Execute plan and lower levels of planning – iterate the lower steps as detailed information becomes available.

Contents of a Software Project Management Plan (SPMP)

Following IEEE 1058, a typical SPMP contains:

• Introduction / Overview – project summary, objectives, scope, deliverables, assumptions and constraints.
• Project organisation – process model, organisational structure, roles and responsibilities, external interfaces.
• Managerial process plans – objectives and priorities, assumptions/dependencies/constraints, risk management, monitoring and controlling mechanisms, staffing plan.
• Technical process plans – methods, tools and techniques, software documentation, project support functions.
• Work plans – Work Breakdown Structure, schedule (Gantt/PERT), resource allocation and budget allocation.
• Supporting process plans – configuration management, quality assurance, verification & validation, reviews and audits.

In short: project planning answers what, how, who, when and how much; stepwise planning is an iterative framework to produce that plan; and the SPMP is the document that records scope, organisation, schedule, budget, risk, quality and configuration management.

Software Configuration Management (SCM)

Software Configuration Management is the discipline of identifying, organising and controlling changes to the artifacts (code, documents, designs, test cases) produced during a software project, so that the product's integrity and traceability are maintained throughout its life cycle.

Importance of SCM

• Controls and tracks changes, preventing uncontrolled modification.
• Allows multiple developers to work concurrently without overwriting each other's work.
• Enables reconstruction of any past version (rollback).
• Maintains traceability between requirements, design, code and tests.
• Supports auditing, status reporting and consistent releases/baselines.

Configuration Management Process

1. Configuration Identification – identify the configuration items (CIs) to be controlled and a naming/versioning scheme; establish baselines.
2. Configuration / Change Control – manage change requests through a Change Control Board (CCB): raise → evaluate impact → approve/reject → implement → verify.
3. Configuration Status Accounting – record and report the state of each CI and of change requests.
4. Configuration Audits – verify that the product conforms to its requirements (functional audit) and that the configuration records are accurate (physical audit).

Software Quality Management

Quality management ensures that the software meets defined quality standards and customer expectations. It has three sub-activities:

• Quality Assurance (QA) – defining the processes and standards that lead to quality (procedures, checklists, reviews).
• Quality Planning – selecting which standards/procedures apply to a particular project (see quality plan below).
• Quality Control (QC) – ensuring teams follow the standards, through reviews, inspections and testing.

Quality Plan

A quality plan sets out the desired product qualities and how they will be assessed. Typical contents:

• Product introduction / overview and quality goals.
• Product plans – release dates, responsibilities.
• Process descriptions – development and review processes to be used.
• Quality goals – the key quality attributes (e.g. reliability, maintainability) and their targets/metrics.
• Risks and risk management relevant to product quality.

Summary: SCM controls change through identification, control, status accounting and audit, while quality management (assurance, planning, control) governed by a quality plan ensures the resulting product meets its quality goals.

Software Quality

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

ISO 9126 Quality Attributes

The ISO/IEC 9126 standard defines six high-level quality 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 use the software (understandability, learnability, operability).
4. Efficiency – performance relative to resources used (time behaviour, resource utilisation).
5. Maintainability – ease of modification (analysability, changeability, stability, testability).
6. Portability – ease of transferring to another environment (adaptability, installability, replaceability).

Each characteristic is decomposed into sub-characteristics that can be measured by metrics.

Bottom-up vs. Top-down Estimation

Summary: Top-down works from the whole to the parts and is fast but coarse; bottom-up works from the parts (WBS tasks) up to the whole and is more accurate but needs detailed information.

Team Structures in Software Development

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

1. Democratic / Egoless Team

• No permanent leader; decisions are taken by consensus and leadership rotates.
• All members review each other's work ("egoless programming").
• Good for: research-oriented, long-term, ill-defined problems where creativity matters.
• Weakness: poor for very large teams; can lack accountability.

2. Chief Programmer Team (Hierarchical / Controlled Centralised)

• A highly skilled chief programmer makes the key technical decisions; supported by a backup programmer, a librarian and other specialists.
• Communication flows through the chief programmer.
• Good for: simple, well-understood problems needing fast delivery.
• Weakness: heavy dependence on one person; demotivates skilled juniors.

3. Mixed / Controlled Decentralised Team

• A compromise: a project leader coordinates, but sub-groups work democratically.
• Good for: large projects that are reasonably well understood; combines control with creativity.

Summary: Democratic teams suit complex, novel work; chief-programmer teams suit simple, well-defined work needing speed; mixed teams balance the two for large projects.

Work Breakdown Structure (WBS)

A Work Breakdown Structure is a hierarchical, deliverable-oriented decomposition of the total project work into smaller, more manageable components. The top box is the whole project; each level breaks the work into smaller pieces, until the lowest level — the work packages / tasks — can be estimated, scheduled and assigned.

Purpose

• Ensures all work is identified (nothing missed, nothing extra).
• Provides the basis for estimation, scheduling, resource allocation and cost control.
• Defines clear responsibility for each work package.

Example — "Develop a Library Management System"

1.0 Library Management System (Project)
   1.1 Requirements
        1.1.1 Gather requirements
        1.1.2 Write SRS document
   1.2 Design
        1.2.1 Database design
        1.2.2 UI design
   1.3 Implementation
        1.3.1 Develop book module
        1.3.2 Develop member module
        1.3.3 Develop issue/return module
   1.4 Testing
        1.4.1 Unit testing
        1.4.2 System testing
   1.5 Deployment & Documentation

Here the project is decomposed into phases, then into work packages such as "Database design" that can be individually estimated and assigned.

Techniques for Monitoring Project Progress

Progress monitoring collects data on actual work done and compares it with the plan. Common techniques:

1. Gantt charts – bar chart of activities against a time axis; planned vs. actual bars show which tasks are ahead, on time or slipping.

2. Slip charts – a line drawn through the current dates of activities; the more jagged/skewed the line, the greater the schedule slippage.

3. Milestone charts / reviews – track completion of key milestones; useful for higher-level reporting.

4. Timeline (time–progress) charts – plot planned and actual progress over time to visualise drift.

5. Earned Value Analysis (EVA) – compute BCWS, BCWP and ACWP and derive Schedule Variance and Cost Variance to objectively measure both schedule and cost performance.

6. Progress / status reports and review meetings – periodic collection of completed work, effort spent and problems faced; partial-completion reporting (e.g. 0/50/100 or percentage complete).

7. Ball charts – use circles changing colour/shape to show whether targets for milestones are being met.

Together these give the manager visibility of schedule and cost status so corrective action can be taken.

Resource Allocation

Resource allocation is the process of assigning the available resources (people, hardware, software, money) to the project activities in an efficient way, so that activities can be carried out within the schedule and budget. After the activity network is built, resources are mapped to activities and the schedule is adjusted to fit the available resources.

Resource Smoothing

• Adjusts activities within their available float (slack) so that resource usage is as even as possible.
• The project end date (and critical path) is NOT changed — only non-critical activities are moved.
• Goal: avoid peaks and troughs in resource demand while keeping the deadline. (Time-constrained.)

Resource Leveling

• Used when resources are limited / fixed and demand exceeds availability.
• Activities are delayed (even beyond their float, if necessary) so that resource usage never exceeds the available capacity.
• The project end date MAY be extended as a result. (Resource-constrained.)

Key difference

Summary: smoothing evens out resource use without delaying the project, whereas leveling resolves resource shortages even at the cost of a longer schedule.

Change Management and Change Control

Change Management

Change management is the overall process of handling changes to a software product or project in a controlled and systematic way during its life cycle. Changes arise from new requirements, defects, changing business needs or environment changes. Its aim is to ensure that beneficial changes are made while uncontrolled, harmful or unrecorded changes are avoided, keeping cost, schedule and quality under control.

Change Control

Change control is the procedural part of change management — the formal procedure used to evaluate and approve or reject each individual change request, usually administered by a Change Control Board (CCB). Typical steps:

1. Submit a change request (CR).
2. Log / record the request.
3. Analyse impact on cost, schedule, scope and quality.
4. Decide – CCB approves, rejects or defers the change.
5. Implement the approved change (update code/documents under configuration management).
6. Verify and close – test the change and update status accounting.

Importance

• Prevents scope creep and uncontrolled modifications.
• Maintains traceability and product integrity.
• Ensures changes are evaluated for impact before being made.

Change control is closely tied to software configuration management, since each approved change is applied to controlled configuration items and recorded in status accounting.

Agile Project Management

Agile project management is an iterative, incremental approach to managing software projects that emphasises flexibility, customer collaboration and rapid delivery of working software, in contrast to the heavyweight, plan-driven (waterfall) approach.

Agile Manifesto values

• 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

• Work is delivered in short iterations / sprints (typically 1–4 weeks), each producing a potentially shippable increment.
• Continuous customer involvement and frequent feedback.
• Self-organising, cross-functional teams.
• Embrace changing requirements, even late in development.
• Frequent inspect-and-adapt through reviews and retrospectives.

Common frameworks

• Scrum – product backlog, sprints, daily stand-ups, sprint review and retrospective; roles of Product Owner, Scrum Master and Development Team.
• Extreme Programming (XP) – pair programming, test-driven development, continuous integration.
• Kanban – visualise the workflow and limit work-in-progress.

Advantages

Faster delivery of value, better adaptability to change, higher customer satisfaction and early detection of problems.

Stakeholder Analysis

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

Stakeholder analysis is the process of identifying the project stakeholders, assessing their interests, expectations, influence and attitude towards the project, and planning how to manage and communicate with each of them. Stakeholders are often classified by their power (influence) and interest (e.g. a power/interest grid: manage closely, keep satisfied, keep informed, monitor).

Why it is important in project management

1. Identifies needs and expectations early, helping to define correct requirements and success criteria.
2. Manages influence — engaging powerful stakeholders gains support and resources; ignoring them creates risk.
3. Improves communication — tailors the type and frequency of communication to each group.
4. Reduces conflict and resistance by addressing concerns proactively.
5. Increases the chance of project success and acceptance of the final product.

Summary: stakeholder analysis identifies and prioritises everyone affected by the project so they can be managed and communicated with appropriately, which is essential for gaining support and delivering a successful project.