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

Project Planning

Project planning is the management activity of deciding what needs to be done, how it will be done, who will do it, when it will be done, and what resources are required, so that the project objectives are achieved within the agreed time, cost and quality constraints. It produces a documented plan that guides execution and is continuously revised (re-planning) as the project progresses.

Steps in Stepwise Project Planning

The Stepwise framework (Hughes & Cotterell) gives a practical, repeatable sequence of planning steps:

0. Select the project – confirm the project is worth doing (feasibility, business case).
1. Identify project scope and objectives – define what is and is not included, identify stakeholders, set measurable objectives.
2. Identify project infrastructure – relate the project to its organizational, methodological and hardware/software environment.
3. Analyse project characteristics – decide whether it is data-driven or control-driven, objective- or product-driven, and select the most appropriate methodology/technology.
4. Identify project products and activities – build a Product Breakdown Structure (PBS), product flow diagram, and from it the list of activities (Work Breakdown Structure).
5. Estimate effort for each activity – use techniques such as COCOMO or Function Points to size each activity.
6. Identify activity risks – assess risks for each activity and plan how to reduce/monitor them.
7. Allocate resources – assign staff and other resources to activities and produce a schedule (e.g. Gantt chart).
8. Review / publicize the plan – obtain agreement and communicate the plan to all stakeholders. 9 & 10. Execute plan / lower levels of planning – iterate steps 5–8 in more detail for each stage as the project proceeds.

Contents of a Software Project Management Plan (SPMP)

A typical SPMP (per IEEE 1058) contains:

• Introduction – project overview, deliverables, objectives, assumptions and constraints.
• Project organization – process model, organizational structure, roles, responsibilities and interfaces.
• Managerial process plans – objectives and priorities, dependencies, resource and budget plans, risk management plan, monitoring and control mechanisms, staffing plan.
• Technical process plans – methods, tools and techniques, software documentation plan, supporting functions (e.g. quality assurance, configuration management).
• Supporting process plans – configuration management plan, verification & validation plan, quality assurance plan, documentation, reviews and audits, problem resolution, maintenance.
• Work breakdown structure, schedule and budget – activities, milestones, dependencies, resource allocation and cost baseline.

The plan is a living document, baselined and then updated under change control throughout the project.

Software Configuration Management (SCM)

Software Configuration Management is the discipline of identifying, organizing and controlling changes to the artefacts (code, documents, designs, data) produced and maintained during a software project, so that the integrity and traceability of the product are maintained throughout its life cycle.

Importance

• Controls and tracks changes, preventing uncontrolled / conflicting changes to artefacts.
• Maintains the integrity and consistency of all deliverables.
• Supports team coordination by managing concurrent work on shared items.
• Enables reproducibility – any released version (baseline) can be rebuilt.
• Provides traceability and auditability of who changed what, when and why.

Configuration Management Process

1. Configuration Identification – identify and label the configuration items (CIs) (modules, documents, libraries) and define baselines.
2. Configuration / Change Control – manage change requests through a Change Control Board (CCB): raise, evaluate impact, approve/reject, implement and verify changes.
3. Configuration Status Accounting – record and report the status of CIs and change requests (what version is current, which changes are pending/done).
4. Configuration Audits (Verification & Audit) – functional and physical audits confirm that the built product conforms to its requirements and recorded configuration.
5. Release Management & Version Control – manage versions, branches and releases (often using tools such as Git/SVN).

Software Quality Management

Quality management ensures that the software meets its specified requirements and is fit for purpose. It has three parts:

• Quality Assurance (QA) – establishing the organizational procedures and standards that lead to high-quality software (process focused).
• Quality Planning – selecting the standards and procedures appropriate to a particular project and defining the quality targets.
• Quality Control – checking that processes and standards are actually followed (reviews, inspections, testing).

Software Quality Plan

A quality plan defines how quality will be achieved for a specific project. Its contents typically include:

• Product introduction & plans – the product, its market, release and quality milestones.
• Process descriptions – the development and quality processes to be used.
• Quality goals – the key quality attributes (reliability, usability, maintainability, etc.) and how they are measured.
• Risks and risk management – quality-related risks and their mitigation.
• Standards, reviews, and metrics to be applied.

Quality management and SCM are complementary: SCM keeps the artefacts under control while quality management ensures those artefacts meet the required standards.

People Management in Software Projects

Software is built by people, and project success depends heavily on how well people are managed. People management covers selecting, organizing, motivating and leading the team so that individual abilities are used effectively toward project goals. Poor people management is one of the commonest causes of project failure, even when the technology is sound.

Key Factors (the 4 C's of people management)

• Consistency – team members treated fairly and comparably.
• Respect – recognising and using each person's skills.
• Inclusion – involving people and listening to their views.
• Honesty – being truthful about progress and problems.

Organizational Behaviour

Organizational behaviour studies how individuals and groups act within an organization. A manager must understand individual differences (skills, personality, attitude), group dynamics, communication patterns and the working environment to get the best from the team.

Motivation Theories

• Maslow's Hierarchy of Needs – needs are satisfied in order: physiological → safety → social → esteem → self-actualization; a manager addresses higher-level needs (recognition, challenging work) once basic needs are met.
• Herzberg's Two-Factor Theory – hygiene factors (salary, conditions) prevent dissatisfaction, while motivators (achievement, recognition, responsibility) create genuine satisfaction.
• McGregor's Theory X and Theory Y – Theory X assumes people dislike work and need control; Theory Y assumes people are self-motivated and seek responsibility (more appropriate for skilled software staff).

Software professionals are typically motivated by interesting work, achievement, recognition and professional growth more than by money alone.

Team Structures

• Democratic / Decentralized (Egoless) team – decisions shared, good for complex, research-type problems; improves morale but can be slower.
• Chief Programmer (Hierarchical/Centralized) team – a senior leader makes key decisions; efficient for well-understood, schedule-driven projects.
• Mixed / Matrix structure – combines hierarchy for management with democracy at the technical level.

Ideal team size is small (≈ 5–9), because communication channels grow as $n(n-1)/2$, so large teams suffer high communication overhead (Brooks's Law: adding people to a late project makes it later).

Challenges in Managing People

• High demand and scarcity of skilled staff; staff turnover and knowledge loss.
• Communication overhead in larger teams and distributed/remote teams.
• Balancing individual creativity with project discipline and deadlines.
• Resolving conflicts and maintaining motivation under pressure.
• Estimating productivity, which varies greatly between individuals.

Effective managers combine good organization, suitable team structure, appropriate motivation and clear communication to overcome these challenges.

Basic COCOMO Model

The Constructive Cost Model (COCOMO), proposed by Barry Boehm, is an empirical model that estimates effort, duration and staffing for a software project from its estimated size in KLOC (thousands of Lines of Code).

Basic COCOMO classifies projects into three modes and applies the equations:

with the constants:

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

Average staffing $= E / D$ persons. Basic COCOMO is quick but rough; the Intermediate and Detailed models refine it using 15 cost-driver multipliers.

Function Point Analysis (FPA)

Function Point Analysis is a technique (developed by Allan Albrecht) for measuring the size of software in terms of its functionality delivered to the user, independent of the programming language or technology used. Unlike LOC, it can be estimated early from the requirements.

Step 1 – Count the five function types

Each is weighted as simple / average / complex:

• External Inputs (EI) – inputs that update data (e.g. data entry screens).
• External Outputs (EO) – outputs such as reports, messages.
• External Inquiries (EQ) – interactive query/response.
• Internal Logical Files (ILF) – internal data maintained by the system.
• External Interface Files (EIF) – data shared with other systems.

Multiply each count by its weight and sum to get the Unadjusted Function Points (UFP):

Step 2 – Compute the Value Adjustment Factor (VAF)

Rate 14 General System Characteristics (e.g. performance, reliability, reusability) on a 0–5 scale; let their total be the Total Degree of Influence (TDI):

Step 3 – Adjusted Function Points

The resulting FP count can be converted to effort or to LOC using a language-specific productivity factor. Advantages: language-independent, available early; limitation: the weighting is somewhat subjective.

Critical Path Method (CPM)

CPM is a deterministic, network-based scheduling technique used to plan project activities, determine the minimum project duration, and identify the critical activities that directly control the completion date. Each activity has a single, known duration.

Determining the Critical Path

1. List activities and dependencies and draw an activity network (Activity-on-Node or Activity-on-Arrow).
2. Forward pass – compute the Earliest Start (ES) and Earliest Finish (EF) of every activity:

3. Backward pass – compute the Latest Finish (LF) and Latest Start (LS) working from the end:

4. Compute float (slack) for each activity:

5. The critical path is the longest path through the network, made up of all activities with zero float. Its length equals the shortest possible project duration.

Any delay on a critical activity delays the whole project, so these activities must be monitored most closely. There can be more than one critical path.

PERT (Program Evaluation and Review Technique)

PERT is a probabilistic network scheduling technique used when activity durations are uncertain. Instead of a single time, each activity is given three time estimates, and PERT computes an expected duration and a measure of uncertainty.

Three-Point Estimation

For each activity, estimate:

• Optimistic time ($t_o$) – shortest time if everything goes well.
• Most likely time ($t_m$) – the most probable duration.
• Pessimistic time ($t_p$) – longest time if problems occur.

The expected (mean) duration follows the Beta distribution:

The variance and standard deviation of the activity are:

Project-level analysis

The expected project duration is the sum of $t_e$ along the critical path, and the project variance is the sum of variances of critical activities. Using a normal approximation, one can compute the probability of completing the project by a target date with the $Z$-score:

Example: if $t_o=4,\ t_m=6,\ t_p=8$, then $t_e = (4 + 24 + 8)/6 = 6$ days. Thus PERT, unlike CPM, accounts for risk and uncertainty in scheduling.

Risk and the Risk Management Process

Risk is an uncertain event or condition that, if it occurs, has a negative (or sometimes positive) effect on a project's objectives (schedule, cost, scope or quality). A risk is characterized by its probability of occurrence and its impact; the combined exposure is often expressed as:

Risks may be project risks (affect schedule/resources), product risks (affect quality/performance) or business risks (affect the organization).

Steps of the Risk Management Process

1. Risk Identification – discover possible risks (technology, people, organizational, requirements, estimation risks) using checklists, brainstorming and past experience.
2. Risk Analysis (Assessment) – estimate the probability and impact (seriousness) of each risk and prioritize them (e.g. low/medium/high) to produce a risk table.
3. Risk Planning – devise strategies for the important risks:
   • Avoidance – reduce the probability of the risk arising.
   • Minimization/Mitigation – reduce its impact.
   • Contingency plans – plan what to do if the risk occurs.
4. Risk Monitoring (and Control) – regularly review and reassess risks, check whether risk indicators are changing, and trigger contingency plans as needed throughout the project.

Risk management is iterative – it is repeated at each stage of the project, and a risk register is maintained and updated continuously.

Earned Value Analysis (EVA)

Earned Value Analysis (Earned Value Management) is a technique for measuring project progress and performance by integrating scope, schedule and cost. It compares the value of work actually completed against what was planned and what was actually spent, giving objective early warning of overruns.

Three Basic Values

• PV (Planned Value / BCWS) – budgeted cost of work scheduled up to the status date.
• EV (Earned Value / BCWP) – budgeted cost of work actually performed (the value 'earned').
• AC (Actual Cost / ACWP) – actual cost incurred for the work performed.

Schedule Variance (SV)

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)

Measures whether the project is under or over budget:

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

Related performance indices are the Schedule Performance Index $SPI = EV/PV$ and the Cost Performance Index $CPI = EV/AC$; a value $> 1$ is favourable. EVA thus quantifies project health at any point in time.

Project Scheduling

Project scheduling is the activity of breaking a project into separate tasks/activities, estimating the time and resources each needs, ordering them according to their dependencies, and assigning them to people and calendar dates, so that the project can be completed within the planned time and cost. The schedule is represented as activity networks and bar charts and is monitored and revised throughout the project.

The scheduling process involves: defining activities (from the WBS), estimating durations, identifying dependencies, allocating resources, and producing a timetable that minimizes idle time and resource conflicts.

Gantt Chart

A Gantt chart (bar chart) is a graphical tool that shows project activities along the vertical axis against time on the horizontal axis. Each activity is drawn as a horizontal bar whose position shows the start date and whose length shows the duration.

Uses of a Gantt Chart

• Shows the start, finish and duration of every activity at a glance.
• Displays overlapping (parallel) and sequential activities and their dependencies.
• Marks milestones (key events, usually as diamonds) and deadlines.
• Shows slack/float and which tasks are on the critical path.
• Supports resource allocation and tracking of actual vs planned progress (e.g. by shading completed portions of each bar).

It is simple to read and is widely used to communicate the schedule to stakeholders and to monitor progress, though it shows dependencies less explicitly than a network diagram.

Software Configuration Management (SCM)

Software Configuration Management is the discipline of identifying, organizing, controlling and tracking changes to the work products (source code, documents, designs, test data, libraries) of a software project throughout its life cycle, so that their integrity, consistency and traceability are preserved.

It is built on a few key concepts:

• Configuration items (CIs) – the artefacts placed under control.
• Baselines – formally reviewed, approved versions that act as a basis for further work and can only be changed through controlled procedures.
• Version/Change control – managing successive versions and processing change requests (often via a Change Control Board).

Why SCM is Important

• Controls change – changes are made in a systematic, approved way, avoiding chaos and conflicting modifications.
• Maintains integrity & consistency of all deliverables, especially when many people work concurrently.
• Enables traceability and auditing – records who changed what, when and why.
• Supports reproducibility – any released version (baseline) can be reconstructed.
• Improves quality and reduces errors caused by using wrong or out-of-date components.
• Aids team coordination and communication on shared artefacts.

In short, SCM keeps a project's artefacts under control so that the right versions are always known and the product can be reliably built and maintained.

Types of Contracts in Software Acquisition

When software is acquired/outsourced, the buyer and supplier sign a contract that allocates cost and risk between them. The main types are:

1. Fixed-Price (Lump-Sum) Contract

The supplier agrees to deliver the specified product for a fixed, pre-agreed price.

• Buyer's view: low risk, known cost; Supplier's view: high risk (any overrun is the supplier's loss).
• Suitable when requirements are clear and stable.

2. Time-and-Materials (Cost Reimbursable) Contract

The buyer pays for the actual effort (time) and materials/resources used, usually at agreed rates, plus a fee.

• Risk lies mainly with the buyer (final cost is uncertain).
• Suitable when requirements are unclear or likely to change.

3. Fixed-Price per Unit Delivered (Measured/Unit-Price) Contract

Payment is based on the quantity of work delivered, e.g. a price per function point, per module or per delivered KLOC.

• Useful when the total size is uncertain but the unit of work can be measured; risk is shared.

Choosing a contract

The choice depends on how well the requirements are defined and who should bear the risk: fixed-price for well-defined work, time-and-materials for exploratory/uncertain work, and unit-price when volume is the main uncertainty. Incentive clauses (bonus/penalty) may be added to align supplier and buyer interests.