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

Software Configuration Management (SCM)

Software Configuration Management is the discipline of identifying, organizing, and controlling changes to the software and its related artifacts (code, documents, requirements, design, test cases, builds) throughout the software development life cycle. Its goal is to maintain the integrity and traceability of the product as it evolves and as multiple people work on it concurrently.

A configuration item (CI) is any deliverable that is placed under version control (e.g., source files, requirement specs, design models, build scripts).

Importance of SCM

• Change control: Manages and approves changes so that uncontrolled, conflicting changes do not corrupt the product.
• Version control: Keeps a history of every version so any baseline can be reproduced or rolled back.
• Concurrent development: Allows many developers to work in parallel through branching and merging without overwriting each other's work.
• Traceability and accountability: Records who changed what, when, and why.
• Reproducible builds & releases: Guarantees the correct components are assembled for each release.
• Quality and audit support: Provides the records needed for reviews, audits and standards compliance (e.g., ISO 9001, CMMI).

Configuration Management Process

1. Configuration Identification – Identify the configuration items, give them unique IDs, and define baselines (a formally reviewed, frozen reference version).
2. Configuration / Change Control – All change requests go through a Change Control Board (CCB): request → impact analysis → approval/rejection → controlled implementation.
3. Configuration Status Accounting – Record and report the status of each CI and each change request (current version, pending changes, history).
4. Configuration Auditing – Verify (functional and physical audits) that the built product matches its specification and that the records are complete and correct.
5. Version & Release Management – Manage versions, branches, builds, and the controlled release of products to customers.

Tools commonly used: Git, Subversion, ClearCase, CVS.

Software Quality Management

Software Quality Management (SQM) ensures that the software meets its specified requirements and the customer's expectations, balancing functional correctness with non‑functional attributes (reliability, usability, maintainability, efficiency, portability).

It has three principal activities:

• Quality Assurance (QA): Establishes the processes and standards that lead to high‑quality software (process oriented, preventive).
• Quality Planning: Selects which quality attributes and standards apply to the specific project and documents them.
• Quality Control (QC): Checks the products against the standards through reviews, inspections and testing (product oriented, detective).

Quality Plan

A Software Quality Assurance Plan (SQAP) is a document that defines, for a project, the quality goals and how they will be achieved. It typically contains:

• Product introduction & quality goals (which quality attributes matter most and target values).
• Quality assessment plan – schedule of reviews, inspections, audits and testing.
• Standards, practices and conventions to be followed (coding standards, documentation standards).
• Metrics to be collected (defect density, MTBF, review effectiveness).
• Roles and responsibilities for quality activities.
• Risks to product quality and their mitigation.

Conclusion

SCM keeps the evolving product consistent and reproducible, while SQM and the quality plan ensure that the product produced actually satisfies its requirements—together they are essential to delivering a reliable software project.

People Management in Software Projects

Software is built by people, and software productivity depends far more on the people involved than on technology. People management is the set of activities concerned with selecting, organizing, motivating and leading the staff so that the project's objectives are met while keeping the team productive and satisfied.

Four critical factors (sometimes summarised as CCCM) influence people management:

• Consistency – team members must be treated fairly and comparably.
• Respect – respect the different skills and contributions of each member.
• Inclusion – involve people and value their views.
• Honesty – be truthful about progress and problems.

Organizational Behaviour

Organizational behaviour studies how individuals and groups act within an organization. In software projects it covers how people communicate, how decisions are made, group dynamics, conflict, and the culture of the organization. Understanding it helps the manager assign people to suitable roles, anticipate conflicts, and create an environment that fosters cooperation and productivity.

Motivation Theories

Motivated people work harder and produce better software. Key theories:

• Maslow's Hierarchy of Needs: physiological → safety → social (belonging) → esteem → self‑actualization. People are motivated by the lowest unmet need; once basic needs are met, higher needs (recognition, growth) drive performance.
• 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.
• McGregor's Theory X and Theory Y: Theory X assumes people dislike work and must be controlled; Theory Y assumes people are self‑motivated and seek responsibility—software professionals respond best to a Theory Y approach.

Motivation types: achievement‑oriented, affiliation‑oriented, and power/influence‑oriented people, each needing different management.

Team Structures

• Democratic / Decentralized (Egoless) team: No permanent leader; decisions by consensus. Good for complex, research‑type problems; high morale but can be slow.
• Chief Programmer (Centralized) team: A senior chief programmer makes decisions and others support. Fast decisions, good for well‑understood problems; but heavily dependent on one person.
• Mixed / Hierarchical (Chief–Egoless) team: Combines both—small egoless sub‑teams coordinated through a hierarchy. Used for large projects.

An effective team needs a manageable size (typically 5–8), a balanced mix of skills, good communication, shared goals, and a sense of group identity.

Challenges of Managing People

• Recruiting and retaining skilled staff in a competitive market.
• Communication overhead grows rapidly with team size (n(n-1)/2 channels).
• Resolving personality conflicts and avoiding group‑think.
• Keeping highly skilled professionals motivated and avoiding burnout.
• Managing distributed/remote teams across time zones and cultures.
• Dealing with staff turnover and the resulting loss of knowledge.

Conclusion

Good people management—understanding behaviour, applying motivation theory, choosing the right team structure, and addressing human challenges—is the single most important contributor to software project success.

Software Cost Estimation

Software cost estimation is the process of predicting the effort (person‑months), time/schedule (months) and cost required to develop a software product. Accurate estimation is needed for budgeting, bidding, scheduling and resource planning. Estimation usually begins from a size measure—Lines of Code (LOC/KLOC) or Function Points—from which effort and time are derived.

COCOMO (Constructive Cost Model)

Proposed by Barry Boehm (1981), COCOMO is an empirical, algorithmic model that estimates effort and schedule from the size of the software (in KLOC = thousands of delivered lines of code). Projects are first classified into one of three modes:

1. Basic COCOMO

Estimates effort and time from size only, using the equations:

$$E = a \times (KLOC)^{b} \quad \text{(person-months)}$$ $$T_{dev} = c \times (E)^{d} \quad \text{(months)}$$ $$\text{Staff} = E / T_{dev} \quad \text{(persons)}$$

with constants:

2. Intermediate COCOMO

Adds accuracy by multiplying the nominal effort by an Effort Adjustment Factor (EAF), the product of 15 cost drivers (e.g., required reliability RELY, product complexity CPLX, analyst capability ACAP, use of tools TOOL). Each driver is rated very‑low to very‑high, giving a multiplier (≈0.7–1.66):

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

3. Detailed (Advanced) COCOMO

Applies the intermediate model's cost drivers separately at each phase of the life cycle (requirements, design, coding, testing) and at module/subsystem/system level. This gives phase‑wise effort distribution and the most accurate estimates.

Example (Basic, Organic mode)

For a 40 KLOC organic project (a=2.4, b=1.05, c=2.5, d=0.38):

$$E = 2.4 \times (40)^{1.05} = 2.4 \times 48.6 \approx 117 \text{ person-months}$$ $$T_{dev} = 2.5 \times (117)^{0.38} = 2.5 \times 6.06 \approx 15.2 \text{ months}$$ $$\text{Staff} = 117 / 15.2 \approx 8 \text{ persons}$$

So about 117 person‑months, ~15 months schedule, with an average team of 8 people.

Conclusion

COCOMO provides a simple yet adaptable family of models: Basic for rough early estimates, Intermediate for cost‑driver‑adjusted estimates, and Detailed for phase‑wise precision.

Basic COCOMO Model

Basic COCOMO (Constructive Cost Model, Boehm 1981) is the simplest form of COCOMO. It estimates software effort and development time purely as a function of program size measured in KLOC (thousands of delivered lines of code), after classifying the project into one of three modes.

The effort estimation equation is:

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

and the development‑time equation:

$$T_{dev} = c \times (E)^{d} \quad \text{(months)}$$

where the constants depend on the project mode:

Example: A 10 KLOC organic project gives $E = 2.4 \times 10^{1.05} \approx 26.9$ person‑months and $T_{dev} = 2.5 \times 26.9^{0.38} \approx 9$ months.

Basic COCOMO is quick and useful for early, rough estimates but is less accurate because it ignores product, hardware and personnel factors (which the Intermediate model adds).

Function Point Analysis (FPA)

Function Point Analysis is a technique (Allan Albrecht, IBM, 1979) for measuring the size/functionality of software from the user's point of view, independent of the programming language or technology used. The size is expressed in Function Points (FP).

FP is computed from five types of user‑observable components:

1. External Inputs (EI) – inputs that update internal data (e.g., forms, screens).
2. External Outputs (EO) – outputs to the user (reports, messages).
3. External Inquiries (EQ) – input‑output queries with no data update.
4. Internal Logical Files (ILF) – internal data maintained by the system.
5. External Interface Files (EIF) – data referenced but maintained by another system.

Steps

1. Count each component and rate its complexity (Simple, Average, Complex) to get weighted counts:

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

where $UFP$ = Unadjusted Function Points.

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

$$VAF = 0.65 + 0.01 \times \sum_{i=1}^{14} F_i$$

3. Compute final Function Points:

$$FP = UFP \times VAF$$

Uses & Advantages

FP can be estimated early (from requirements) before any code exists, is language‑independent, and supports productivity (FP/person‑month) and effort estimation. FP can also be converted to LOC using a language‑specific factor for use in models like COCOMO.

Critical Path Method (CPM)

CPM is a deterministic network‑analysis technique used in project scheduling to model a project as a network of activities with known durations and dependencies, and to find the longest path through that network. This longest path is the critical path—it determines the minimum total duration of the project. Any delay in an activity on the critical path delays the whole project.

Determining the Critical Path

1. Build the activity network showing all activities, their durations and precedence relationships.
2. Forward pass – starting from the start node, compute for each activity:
   • Earliest Start (ES) and Earliest Finish (EF = ES + duration).
3. Backward pass – starting from the end node, compute:
   • Latest Finish (LF) and Latest Start (LS = LF − duration).
4. Compute Slack (Float) for each activity:

$$Slack = LS - ES = LF - EF$$

5. Identify the critical path as the path whose activities all have zero slack. It is the longest‑duration path from start to finish.

Significance

• The length of the critical path = minimum project completion time.
• Critical activities have no scheduling flexibility and must be managed closely.
• Non‑critical activities have positive slack and can be delayed within their float without affecting the project end date.

PERT (Program Evaluation and Review Technique)

PERT is a probabilistic project‑scheduling technique used when activity durations are uncertain. Like CPM it models the project as a network of activities, but instead of a single fixed duration it uses three time estimates for each activity to account for uncertainty, and computes an expected duration with a measure of variability.

Three‑Point Estimation

For each activity three estimates are made:

• 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 things go badly.

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

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

The variance and standard deviation of the activity are:

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

Use

The $t_e$ values are used to find the critical path (as in CPM). The project's expected duration is the sum of $t_e$ along the critical path, and its variance is the sum of the variances of the critical activities. Using the Normal approximation, PERT can then estimate the probability of finishing the project by a given deadline.

Example: if $t_o=4$, $t_m=6$, $t_p=14$ days, then $t_e = (4 + 24 + 14)/6 = 7$ days and $\sigma = (14-4)/6 = 1.67$ days.

Risk and the Risk Management Process

Risk is a future, uncertain event or condition that, if it occurs, has a negative effect on the project's objectives (cost, schedule, scope or quality). A risk has two attributes: the probability of occurrence and the impact/loss if it occurs. Risk exposure is often expressed as:

$$\text{Risk Exposure} = \text{Probability} \times \text{Impact (loss)}$$

Typical software risk categories: project risks (budget, schedule, staffing), product/technical risks (changing requirements, performance) and business risks (market, dependencies).

Steps of the Risk Management Process

1. Risk Identification – Discover possible risks (project, technical, business) using checklists, brainstorming and past experience.
2. Risk Analysis (Assessment) – Estimate the probability and impact of each risk, then prioritise them (e.g., high/medium/low or by risk exposure).
3. Risk Planning (Mitigation) – Develop strategies for important risks:
   • Avoidance – change the plan to remove the risk.
   • Minimization/Reduction – reduce probability or impact.
   • Contingency plans – prepare a fallback if the risk occurs.
4. Risk Monitoring (and Control) – Continuously track identified risks, watch for new risks, and review whether mitigation is working throughout the project; update the risk register accordingly.

These steps are iterative—repeated throughout the project life cycle so that risk exposure is kept under control.

Earned Value Analysis (EVA)

Earned Value Analysis is a project‑monitoring technique that integrates scope, schedule and cost to objectively measure project performance and progress against the plan. It compares the value of work actually completed with the planned value and the actual cost.

Three Key Values

• PV (Planned Value / BCWS): the budgeted cost of work scheduled up to a point in time.
• EV (Earned Value / BCWP): the budgeted cost of work actually performed (the value earned).
• AC (Actual Cost / ACWP): the actual cost incurred for the completed work.

Schedule Variance (SV)

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

$$SV = EV - PV$$

• $SV > 0$ → ahead of schedule
• $SV < 0$ → behind schedule
• Schedule Performance Index: $SPI = EV / PV$

Cost Variance (CV)

Measures whether the project is under or over budget:

$$CV = EV - AC$$

• $CV > 0$ → under budget
• $CV < 0$ → over budget
• Cost Performance Index: $CPI = EV / AC$

Interpretation

Using SV/CV (and SPI/CPI) a manager can detect cost and schedule overruns early and forecast final cost (e.g., $EAC = BAC / CPI$), enabling corrective action.

Project Scheduling

Project scheduling is the process of deciding which tasks are needed, in what order, how long each takes, who does them, and when they should be carried out, so that the project is completed on time and within budget. It involves splitting the project work into activities (using a Work Breakdown Structure), estimating effort and duration, identifying dependencies, allocating people and resources, and laying activities out on a timeline. A good schedule supports planning, progress tracking and resource management.

Gantt Chart

A Gantt chart (Henry Gantt) is a horizontal bar chart used to display a project schedule visually:

• The vertical axis lists the activities/tasks.
• The horizontal axis represents time (days/weeks/months).
• Each task is drawn as a bar whose position shows its start date and whose length shows its duration.
• Milestones are shown as markers; bars can be shaded to show percentage completed; dependencies can be shown by linking bars.

Uses: it shows at a glance the start/end of each task, which tasks overlap (run in parallel), overall project timeline, current progress versus plan, and resource allocation. It is simple to read and ideal for communicating schedules to stakeholders, though it shows task dependencies less clearly than a network (CPM/PERT) diagram.

Software Configuration Management (SCM)

Software Configuration Management is the discipline of identifying, organizing and controlling changes to all the artifacts of a software system (source code, documents, requirements, designs, test cases, builds) throughout its life cycle, so that the integrity and traceability of the product are maintained as it evolves.

The items placed under control are called configuration items (CIs), and a reviewed, frozen version is called a baseline. SCM's core activities are: configuration identification, change control, status accounting, and configuration auditing, supported by version‑control tools (e.g., Git, SVN).

Why is it important?

• Controls change: changes are reviewed and approved (via a Change Control Board) so they do not corrupt the product.
• Version control & rollback: keeps a full history; any previous baseline can be rebuilt or restored.
• Supports teamwork: lets many developers work in parallel (branch/merge) without overwriting each other.
• Traceability & accountability: records who changed what, when and why.
• Reproducible builds and releases: ensures the right components are assembled for each release.
• Quality & audit: provides records needed for reviews, audits and standards compliance (ISO, CMMI).

Without SCM, large evolving projects quickly suffer from lost changes, conflicting versions and unrepeatable builds—so SCM is essential for delivering reliable software.

Types of Contracts in Software Project Acquisition

When software (or services) is acquired from an external supplier, the buyer and supplier sign a contract that defines the work, deliverables and how the supplier will be paid. The main contract types differ in how cost and risk are shared between buyer and supplier.

1. Fixed‑Price Contract

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

• Buyer's risk: low (price is fixed). Supplier's risk: high.
• Best when requirements are well defined and stable.
• Variant: Fixed Price with Incentive (bonus for early/cheaper delivery).

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 uncertain). Supplier's risk: low.
• Best when scope is uncertain or likely to change (e.g., R&D projects).
• Variants: Cost‑Plus‑Fixed‑Fee (CPFF), Cost‑Plus‑Incentive‑Fee (CPIF), Cost‑Plus‑Percentage‑of‑Cost (CPPC).

3. Time‑and‑Materials (T&M) Contract

The buyer pays an agreed rate per hour/day for labour plus the cost of materials used. It is a hybrid of fixed‑price and cost‑reimbursable, used for small or short‑term work where the exact effort is not known in advance. Risk is shared, but the buyer should cap the total.

Summary

The choice depends mainly on how well the requirements are defined: clear requirements favour fixed‑price; uncertain requirements favour cost‑reimbursable or T&M.